기술을 이해하고,
정리합니다.

OBS의 RTMP·RTMPS 출력이 ingest, transcoding, ABR packaging, CDN, player buffer를 거쳐 재생되는 경로를 분해합니다. 전체 지연은 세그먼트 길이 하나가 아니라 인코더, 패키저, 배포망, 플레이어 설정의 합으로 결정됩니다. AWS MediaLive와 MediaConvert의 역할 차이와 상호작용 요구에 따라 HLS 계열과 WebRTC를 선택하는 기준도 다룹니다.

Google TTS 결과를 R2에 캐시하고 브라우저에 전달하는 서버 파이프라인을 다룹니다. 음성 출력에 영향을 주는 모든 설정을 canonical JSON으로 묶어 캐시 키를 만들고, 동시 cache miss와 stale metadata를 처리하며, R2 저장 후 DB를 갱신하는 순서를 설명합니다. 인증·rate limit·내구성 있는 후속 작업까지 포함한 운영 기준도 함께 정리했습니다.

데이터 위치·처리자·보유 방식에 대한 계약이나 규제 요구가 Cloud Recording의 데이터 흐름과 맞지 않을 때 On-Premise Recording을 검토할 수 있습니다. 이 글은 배포 위치, 운영 책임, 후처리 통제 범위를 Cloud 방식과 비교하고 raw-data callback은 사용하는 SDK 버전의 API 계약으로 확인해야 한다는 기준을 제시합니다.

Cloud Recording 산출물이 object storage에 기록되는 방식과 장애 후 처리 절차를 설명합니다. TS·M3U8·MP4의 분할 조건, recording server failover 시 생성되는 backup playlist, stop·query 응답의 file list를 구분합니다. 애플리케이션에서는 사용자 소유권을 확인한 뒤 저장된 object key로 짧은 수명의 presigned URL을 발급해야 합니다.