실시간 통신, 미디어 처리, AI 통합에 대한 심층 분석.
Agora SDK를 중심으로 프로덕션 레벨의 구현을 다룹니다.
WebRTC 아키텍처 글을 읽기 전에 먼저 보는 추천 자료입니다. Mesh, SFU, MCU, Hybrid 구조를 다이어그램과 시퀀스 흐름으로 비교합니다.
HLS, HTTP-FLV, MP4를 같은 종류의 포맷처럼 비교하면 선택 기준이 흐려집니다. HLS와 HTTP-FLV는 전달 방식이고, FLV와 MP4는 미디어를 담는 컨테이너입니다. 이 글은 HLS가 반드시 .ts만 쓰는지, HTTP-FLV가 Flash 종료와 함께 사라졌는지, 1~3초·10~30초라는 지연 수치를 어디까지 믿어야 하는지 검증하고, ABR·브라우저 호환성·CDN 확장성·실시간성에 따라 무엇을 선택할지 정리합니다.
OBS encoder에서 ingest, transcoding, ABR packaging, CDN, player buffer까지 일반적인 glass-to-glass 경로를 설명합니다. YouTube와 Twitch가 공개한 입력 요구사항과 latency 설정은 공식 문서로 확인하고, 공개되지 않은 내부 topology는 참조 구조와 구분합니다.
stream은 논리적인 미디어 흐름이고 RTP는 그 미디어를 네트워크로 운반하는 패킷 프로토콜입니다. 하지만 WebRTC API의 MediaStream, Agora 운영 문맥의 stream, RTP의 SSRC packet stream은 같은 말이 아닙니다. 이 글은 track, stream, RTP, RTCP의 층위를 분리하고, muteLocalVideoStream, enableLocalVideo, stopPreview, leaveChannel이 Cloud Recording에서 어떻게 다르게 보이는지 검증된 기준으로 정리합니다.
인증서의 Not After 확인, 고객 제공 인증서와 관리형 인증서의 갱신 책임, ACME DNS-01 challenge를 설명합니다. `_acme-challenge` TXT 값과 CNAME 위임을 구분하고 `dig`·`openssl`로 DNS propagation, certificate chain, CAA 영향을 확인하는 운영 절차를 정리했습니다.
WebRTC가 ICE를 통해 host·server-reflexive·relay candidate를 점검하고, 환경에 따라 UDP 또는 TURN/TCP·TURN/TLS relay를 사용하는 방식을 설명합니다. Full Mesh에서는 참가자 수에 따라 각 client의 연결과 송신 복제량이 늘고, SFU는 일반적으로 media frame을 decode·mix·re-encode하지 않은 채 RTP packet을 선택 전달합니다. 실제 topology는 device·network·recording·E2EE 요구를 기준으로 부하 시험해 결정해야 합니다.
TEN Framework main의 OpenAI·ElevenLabs TTS extension을 실제 소스 기준으로 읽습니다. Extension이 config와 client 생성을 맡고 vendor client가 합성·취소·정리를 처리하는 경계, OpenAI의 재사용 HTTP/2 client, ElevenLabs의 WebSocket 입력 흐름을 비교합니다. 지연과 chunk 크기는 고정 권장값 대신 provider 문서와 서비스 환경의 계측값으로 판단합니다.
Mesh, SFU, MCU, Hybrid의 media path와 처리 경계를 토폴로지·시퀀스 다이어그램으로 비교합니다. Mesh의 direct path에는 TURN relay 예외가 있고, SFU는 선택 전달, MCU는 서버 합성을 담당합니다. 참가자 수만으로 결론을 내리지 않고 codec·subscription·layout·region·hardware·recording 요구를 함께 검증하는 기준을 제시합니다.
HLS와 DASH를 매니페스트 문법, 세그먼트 형식, ABR, DRM, 저지연 확장 기준으로 비교합니다. 두 프로토콜이 fMP4를 사용할 때 CMAF 미디어 세그먼트를 공유할 수 있는 조건과 Apple 플랫폼의 HLS 요구사항도 함께 설명합니다. LL-HLS는 HTTP/2 Push가 아니라 blocking playlist reload와 preload hint를 사용한다는 점을 현재 사양에 맞춰 정리했습니다.
OBS의 RTMP·RTMPS 출력이 ingest, transcoding, ABR packaging, CDN, player buffer를 거쳐 재생되는 경로를 분해합니다. 전체 지연은 세그먼트 길이 하나가 아니라 인코더, 패키저, 배포망, 플레이어 설정의 합으로 결정됩니다. AWS MediaLive와 MediaConvert의 역할 차이와 상호작용 요구에 따라 HLS 계열과 WebRTC를 선택하는 기준도 다룹니다.
Full Mesh, 단일 SFU, 지역 간 SFU cascading, CDN 기반 방송 구조의 부하 특성을 비교합니다. SFU 용량은 참가자 수만으로 정해지지 않고 publish·subscribe 수, simulcast layer, bitrate, packet rate, 암호화, 하드웨어에 따라 달라집니다. 따라서 예시 계산은 용량 계획의 출발점으로만 사용하고 실제 트래픽 모델로 부하 시험해야 합니다.
Zoom, Discord, LiveKit, Agora, Slack, Meta가 공개한 자료를 바탕으로 표준 WebRTC, libwebrtc, 자체 미디어 계층의 경계를 비교합니다. 클라이언트 엔진과 서버 토폴로지, 전송 최적화, 운영 모델을 분리해 설명하고 공개 자료로 확인되지 않는 내부 구현은 추정하지 않습니다.
카메라 캡처부터 색공간 변환, 인코딩, 디코딩, 렌더링까지 모바일 영상 경로에서 메모리 복사와 CPU·GPU·하드웨어 코덱 사용이 발열에 미치는 영향을 설명합니다. Android SurfaceTexture와 iOS CVPixelBuffer 같은 플랫폼별 버퍼 공유 방식도 비교합니다. 실제 전력 효과는 단말과 코덱 지원에 따라 달라지므로 계측 기준을 함께 제시합니다.
공통 C++ 코어를 Android와 iOS에 배포할 때 필요한 ABI별 빌드와 플랫폼 바인딩을 설명합니다. Android의 JNI와 shared library, iOS의 Objective-C++와 static library·XCFramework를 구분하고, 네이티브 코어 업데이트가 앱 재빌드와 배포를 요구하는 이유도 함께 다룹니다.
Meta가 공개한 엔지니어링 글을 기준으로 장기 유지한 libwebrtc fork를 upstream 계열로 전환한 과정을 정리합니다. 두 구현의 호출 경계를 shim으로 통제하고 use case별로 이동한 방식, fork가 보안 패치와 기능 추적에 만드는 비용, 공개된 사실과 추정을 구분하는 방법을 다룹니다.
브라우저의 WebRTC API와 코덱 협상 범위, Agora Web SDK가 제공하는 채널·미디어 API, SD-RTN으로 설명되는 서비스 네트워크의 역할을 분리합니다. 네이티브 SDK의 비공개 내부 구현은 단정하지 않고, FEC와 retransmission 같은 손실 대응 기법도 표준과 공개 문서 범위에서 설명합니다.
I·P·B frame과 GOP가 압축과 random access에 맡는 역할을 설명하고, frame 기반 keyint 설정이 실제 시간 길이로 어떻게 환산되는지 살펴봅니다. 입력 frame rate 저하, keyframe 간격, HLS segment duration이 함께 변하는 장애를 log와 ffprobe로 구분하는 절차도 다룹니다.
AI 콜봇의 동시 발신에서 call leg와 dialog 상태가 분리되지 않을 때 나타나는 증상을 SIP 메시지 흐름으로 분석합니다. 특정 장비의 Bridge·IVR 명칭을 표준 용어로 일반화하지 않고, B2BUA의 세션 제어와 180 Ringing·183 Session Progress·200 OK 시점이 미디어 재생에 미치는 영향을 구분합니다.
HLS, LL-HLS, WebRTC를 지연 구성 요소, 호환성, 상호작용, 배포 방식, 운영 비용으로 비교합니다. 고정된 지연 수치로 프로토콜을 선택하지 않고 목표 latency와 audience 규모, 양방향 media 요구, device 지원 범위를 측정해 결정하는 절차를 제시합니다.
H.264·H.265 SEI NAL unit의 payload type과 payload size를 읽는 방법을 설명합니다. Agora Media Push가 제공하는 metadata 형식은 공식 계약에 맞춰 처리하고, Annex B와 AVCC 입력을 구분해 emulation-prevention byte 제거, payload type 100·송출 경로·JSON schema를 확인합니다.
ABR 전환을 위해 rendition 간 segment boundary와 random access point를 맞추는 이유를 설명합니다. FFmpeg의 GOP·force_key_frames·scene-cut 설정은 입력 timestamp와 encoder 동작까지 함께 확인해야 하며, 최종 정렬 여부는 ffprobe와 Apple media tooling 등으로 산출물을 검증합니다.
Encoder GOP와 streaming platform의 keyframe 요구사항, HLS segment 경계가 서로 영향을 주는 지점을 정리합니다. 플랫폼별 권장값을 보편 규칙으로 일반화하지 않고, frame rate와 keyframe interval 단위를 확인한 뒤 실제 manifest와 frame timestamp로 결과를 검증하는 방법을 다룹니다.
일반 APNs 알림과 PushKit VoIP push의 token·topic·payload·처리 수명주기를 구분합니다. PushKit callback에서 CallKit 통화를 보고하고 RTC 연결을 시작하는 흐름, server-side push 인증, Apple 정책상 주의사항을 공식 문서 기준으로 설명합니다. 관리형 알림 연동과 직접 구축의 책임 범위도 비교합니다.
PushKit 수신, CallKit transaction, AVAudioSession activation, RTC SDK audio module의 책임을 네 계층으로 나눕니다. `didActivate`와 `didDeactivate`, interruption·route change callback을 어떤 상태 전이에 연결할지 설명하며, channel join 시점과 audio module 제어는 사용 중인 SDK 계약에 맞춰 검증합니다.
TTFB를 DNS 조회, connection, TLS handshake, request 전송, server 처리, first-byte 전송 구간으로 나눕니다. curl timing 값과 browser Network panel을 함께 읽고 connection reuse·HTTP version·cache 상태를 기록해 병목을 구분합니다. ICMP ping만으로 HTTP 지연 원인을 판단할 수 없는 이유도 설명합니다.
녹화 파일을 중간 위치로 탐색할 때 멈추는 문제를 MP4 index, HLS playlist 종료 상태, timestamp discontinuity 관점에서 진단합니다. `ffprobe`, manifest 검사, ffmpeg remux가 각각 확인하거나 복구할 수 있는 범위를 구분하고, 원본 segment 누락처럼 후처리로 복구할 수 없는 경우도 명시합니다.
SIP·RTSP의 signaling/control message와 RTP·RTCP media 흐름을 분리해 설명합니다. 협상이 성공해도 NAT, firewall, address advertisement, codec 조건 때문에 한쪽 media만 실패할 수 있습니다. packet capture와 SDP를 대조해 control plane과 media plane을 따로 진단하는 순서를 정리했습니다.
RTSP 등 live input의 연결 상태, stream metadata, packet·frame timestamp를 ffprobe와 GStreamer 도구로 확인합니다. timeout을 둔 probe, PTS·DTS 출력, frame CSV 추출, `gst-discoverer-1.0` 사용법을 나누고 각 명령이 실제 media 수신까지 보장하는지 여부도 구분합니다.
x264의 reference frame 수, tune, keyint, scenecut 설정이 압축 효율·encoder latency·random access에 미치는 영향을 설명합니다. 실시간 통신과 HLS·VOD의 요구사항을 구분하고, 특정 값을 보편적인 정답으로 제시하지 않고 수신기 호환성과 실제 frame output으로 검증합니다.
B-frame이 이전·이후 reference picture를 이용하는 방식과 display order·decode order가 달라지는 이유를 설명합니다. 재정렬 buffer와 timestamp, 압축 효율, latency의 tradeoff를 다루고, 실시간 전송에서 B-frame 사용 여부는 codec profile과 encoder·decoder 협상 결과로 확인합니다.
H.264 profile과 packetization mode, software·hardware encoder, bitrate control이 WebRTC 호환성과 품질에 미치는 영향을 정리합니다. 해상도만으로 bitrate를 고정하지 않고 frame rate, 화면 움직임, codec implementation, network 조건을 포함해 시험하는 절차와 browser stats·bitstream 검사 항목을 제시합니다.
Interlaced와 progressive scan, intra·predictive·bi-predictive picture, GOP의 관계를 설명합니다. RTP video session에서 decoder가 reference picture를 잃었을 때 RTCP PLI·FIR가 요청하는 동작도 구분합니다. GOP 길이와 B-frame 사용 여부는 서비스 유형과 codec 협상에 따라 달라집니다.
RTMP ingest를 WebRTC로 변환하는 경로에서 timestamp rollback과 freeze가 나타난 사례를 진단합니다. B-frame 재정렬, PTS·DTS 변환, transcoder·gateway 처리 경계를 각각 격리하며, 특정 H.264 profile을 원인으로 단정하기 전에 bitstream과 단계별 timestamp를 비교하는 절차를 설명합니다.
RTC 품질 문제를 패킷 캡처로 확인하는 절차를 정리했습니다. TCP 재전송과 Zero Window, RTP sequence number와 timestamp, RTCP 품질 보고서, TLS·DTLS handshake를 Wireshark에서 찾는 방법을 설명하고 서버에서는 tcpdump로 캡처한 뒤 로컬에서 분석하는 흐름까지 다룹니다.
RTC 채널의 압축 프레임이 RTP로 패킷화되는 과정과 서버 측 미디어 제품이 그 흐름에 개입하는 지점을 추적합니다. Media Gateway·Media Pull·Cloud Transcoding·Media Push·Cloud Recording을 입력, 변환, 출력 기준으로 구분하고 CDN 송출과 stream fallback까지 같은 데이터 경로 위에서 설명합니다.
마이크 입력이 ADC, audio processing, codec, RTP packetization, network, jitter buffer, decoder, DAC를 거쳐 재생되는 경로를 설명합니다. Opus·G.711·AAC의 사용 맥락과 packet loss·jitter 대응, RTMP-WebRTC 변환, Voice AI의 VAD·STT 경계를 구분합니다.
PCM encoding과 RIFF/WAVE container를 서로 다른 계층으로 구분합니다. WAVE의 chunk 구조 때문에 audio data offset을 44로 고정하면 안 되는 이유, linear PCM과 G.711 µ-law의 차이, sample rate·channel count·sample format을 잘못 해석했을 때 생기는 증상을 설명합니다.
공기 진동이 microphone과 ADC를 거쳐 sampled·quantized PCM이 되고, MP3 encoder의 filter bank·quantization·entropy coding을 거쳐 저장되는 흐름을 설명합니다. 재생 단계의 decode와 DAC까지 연결하고, sample rate·bit depth·bitrate가 각각 무엇을 제어하는지 구분합니다.
Google TTS 결과를 R2에 캐시하고 브라우저에 전달하는 서버 파이프라인을 다룹니다. 음성 출력에 영향을 주는 모든 설정을 canonical JSON으로 묶어 캐시 키를 만들고, 동시 cache miss와 stale metadata를 처리하며, R2 저장 후 DB를 갱신하는 순서를 설명합니다. 인증·rate limit·내구성 있는 후속 작업까지 포함한 운영 기준도 함께 정리했습니다.
Google TTS의 `audioContent`처럼 JSON 문자열 필드에 바이너리를 담을 때 Base64가 필요한 이유를 설명합니다. MP3 frame header와 ID3 tag, Base64의 6비트 인코딩과 패딩, `4 × ceil(n/3)` 길이 공식을 살펴보고 Node.js `Buffer`, 브라우저 `Uint8Array`, data URL 변환 시 복사와 메모리 비용도 구분합니다.
Bitrate는 해상도·frame rate·codec·장면 복잡도와 함께 압축 화질을 좌우합니다. 이 글은 송출 설정, 네트워크 적응, Cloud Recording 출력 설정을 구분하고 `ffprobe`로 실제 결과를 측정하는 절차를 설명합니다. 출력 bitrate를 높여도 원본에서 이미 잃은 디테일은 복원되지 않으므로 실제 콘텐츠로 품질을 비교해야 합니다.
Individual recording 결과를 참가자별 VOD나 하나의 composite 화면으로 후처리하는 FFmpeg 파이프라인을 설명합니다. M3U8과 TS를 점검하고 기록된 track의 시작 시각을 맞춘 뒤, audio-only·video-only 입력과 참가자 수를 검증해 레이아웃을 구성합니다. 입력값 제한, 경로 검증, 실패 복구를 포함한 자동화 기준도 함께 다룹니다.
FFmpeg에서 컨테이너, 코덱, 스트림을 구분하고 probe·demux·decode·filter·encode·mux 단계가 어떻게 연결되는지 설명합니다. `-c copy`는 입력 코덱과 출력 컨테이너, timestamp와 keyframe 조건이 맞을 때만 안전합니다. remux, transcoding, stream mapping, seek, concat을 선택하는 기준을 실제 명령으로 정리했습니다.
Cloud Recording 결과에 포함된 M3U8 재생목록과 MPEG-TS 세그먼트를 읽는 방법을 설명합니다. MP4의 `moov` 위치와 fragmented MP4를 구분하고, TS packet·PES·codec frame의 관계, HLS 태그, target duration 규칙을 살펴봅니다. Agora의 track event와 slice 파일명은 공식 형식에 맞춰 해석합니다.
Individual, Composite(`mix`), Web page recording의 출력과 처리 범위를 비교합니다. Individual은 참가자별 track 후처리에, Composite는 서버 합성과 고정 레이아웃 출력에, Web page recording은 웹 화면 캡처에 맞습니다. 과금은 모드 이름이 아니라 스트림 수·시간·합산 해상도 등 공식 가격 기준으로 확인해야 합니다.
데이터 위치·처리자·보유 방식에 대한 계약이나 규제 요구가 Cloud Recording의 데이터 흐름과 맞지 않을 때 On-Premise Recording을 검토할 수 있습니다. 이 글은 배포 위치, 운영 책임, 후처리 통제 범위를 Cloud 방식과 비교하고 raw-data callback은 사용하는 SDK 버전의 API 계약으로 확인해야 한다는 기준을 제시합니다.
WebRTC는 미디어 저장 방식을 정의하지 않으므로 녹화가 필요하면 별도 파이프라인을 설계해야 합니다. 이 글은 브라우저 `MediaRecorder`, 자체 미디어 서버, Agora Cloud Recording의 통제 범위와 운영 부담을 비교합니다. Cloud Recording의 non-streaming client 모델, `acquire → start → query → stop` 수명주기, REST 인증과 RTC token의 역할도 구분합니다.
Cloud Recording 산출물이 object storage에 기록되는 방식과 장애 후 처리 절차를 설명합니다. TS·M3U8·MP4의 분할 조건, recording server failover 시 생성되는 backup playlist, stop·query 응답의 file list를 구분합니다. 애플리케이션에서는 사용자 소유권을 확인한 뒤 저장된 object key로 짧은 수명의 presigned URL을 발급해야 합니다.
Agora Real-Time STT 작업이 RTC channel의 audio를 전사하고 Beta 번역 결과를 DataStream으로 전달하는 흐름을 설명합니다. 공식 `SttMessage.proto` schema로 payload를 역직렬화하고 `(uid, sentence_id)` 단위로 중간 결과를 갱신합니다. UI debounce는 protocol 규칙이 아닌 application 정책으로 분리합니다.
제한된 enterprise network에서 Agora RTC에 필요한 domain·port allowlist와 Cloud Proxy를 비교합니다. UDP 차단, 고정 outbound 정책, TLS inspection 같은 조건에 따라 적용 범위가 달라지며 어느 방식도 모든 방화벽 통과를 보장하지 않습니다. 운영망에서 join·publish·subscribe를 검증하는 절차를 함께 제시합니다.
NAT mapping과 filtering 동작 때문에 endpoint끼리 직접 연결되지 않는 경우를 설명합니다. ICE agent가 host·server-reflexive·relay candidate pair를 검사하고 STUN binding과 TURN relay를 사용하는 흐름을 현재 RFC 기준으로 정리합니다. 오래된 NAT 네 가지 분류는 진단의 참고 모델로만 다룹니다.
WebRTC의 media·data 연결과 signaling의 경계를 소개하고, NAT와 firewall 환경에서 ICE가 candidate pair를 검사하는 과정을 설명합니다. STUN으로 server-reflexive candidate를 얻고 TURN relay를 사용하는 경우를 구분하며, Agora Web SDK가 제공하는 channel·track API와 browser WebRTC 구현의 관계도 정리합니다.
Cloud Recording의 non-streaming client가 RTC channel에 참여해 media를 기록하는 방식과 `acquire → start → query → stop` 수명주기를 설명합니다. REST 인증과 RTC token을 구분하고, individual·composite·web page recording mode, object storage 설정, resource 만료와 stop 처리를 구현 예제로 다룹니다.
Agora Web SDK의 client 생성, channel join, local track publish, remote user subscribe, leave·track cleanup 흐름을 구현합니다. 화면 공유와 mute 동작, backend token 발급, React·Next.js의 client-only 실행 경계와 event listener 정리까지 포함합니다.
Agora RTM의 login, channel subscribe, publish, unsubscribe, logout 수명주기로 채팅을 구현합니다. RTC channel과 RTM channel의 식별자를 함께 사용할 수 있지만 연결과 token 권한은 별도라는 점을 구분하고, message validation·rate limit·한글 IME composition 처리도 다룹니다.
Agora Web SDK client를 live mode로 설정하고 host·audience role에 따라 publish·subscribe 동작을 나눕니다. 화면 공유, role 변경, leave cleanup, token 권한을 구현하며 채팅과 손들기 같은 application data는 별도 messaging 경로로 설계합니다.
Agora Conversational AI session 생성과 RTC·RTM 권한, provider credential의 server-side 보관, client event 처리 흐름을 구현합니다. Transcript chunk는 사용하는 toolkit의 schema와 sequence 정보를 기준으로 조립하고, agent 상태·microphone permission·cleanup을 명시적으로 관리합니다.
시리즈: 실시간 통화, 어떻게 녹화하는가
포스트 12–17은 연재 글입니다. 순서대로 읽으시면 전체 맥락을 이해할 수 있습니다.