실시간 통신, 미디어 처리, AI 통합에 대한 심층 분석.
Agora SDK를 중심으로 프로덕션 레벨의 구현을 다룹니다.
primary 카테고리 또는 태그로 Fundamentals에 속한 글을 모두 표시합니다.
화상회의에 10명이 들어가면 왜 서버가 필요할까요? 브라우저끼리 직접 연결하면 공짜 아닌가요? 이 질문에 답하려면 세 가지를 순서대로 설명해야 합니다 — 왜 실시간 미디어는 TCP가 아닌 UDP여야 하는지(Head-of-Line Blocking), 왜 P2P는 인원이 늘면 업로드 회선부터 무너지는지, 그리고 SFU라는 중간 서버가 정확히 무슨 일을 하는지. WebRTC를 처음 접하는 분도 따라올 수 있게 택배·우체국 비유와 다이어그램으로 풀고, 프리세일즈 미팅의 단골 심화 질문 두 가지 — 인코딩·디코딩은 기기와 서버 중 어디서 하는가, 1:1 통화도 SFU를 거치는가 — 까지 논리적으로 정리합니다. 마지막에는 고객 질문별 30초 답변 치트시트를 붙였습니다.
"WebRTC 엔진이 C++라는데, iOS랑 Android에서 그 코드를 같이 쓰는 건가요? 플랫폼마다 다시 짜는 거 아닌가요?" 모바일 RTC 도입 자리에서 자주 나오는 질문입니다. 답은 코어 로직을 C++ 하나로 짜고 플랫폼마다 얇은 연결 계층만 따로 붙인다는 것입니다. 왜 코어가 C++인지, ABI가 다르면 왜 .so 하나로 안 되는지, 정적과 동적 라이브러리의 진짜 구분 기준은 무엇인지, Android는 JNI로 iOS는 Objective-C++로 어떻게 잇는지, 그리고 코어가 앱에 박혀 있어 업데이트하려면 앱을 다시 빌드해야 한다는 대가까지 차근히 짚어 드립니다.
B-frame은 대체 어떻게 미래 프레임을 미리 알고 압축하는 걸까요? 답은 의외로 단순합니다. 카메라가 이미 다 찍어 버퍼에 쌓아둔 데이터를 인코더가 꺼내 쓰는 것뿐입니다. 이 글은 앞뒤 프레임을 모두 참조하는 B-frame의 원리를 비유와 그림으로 따라가며, 촬영 순서와 전송 순서가 왜 달라지는지, 그리고 압축률이 가장 높은데도 영상통화 같은 WebRTC 환경에서는 왜 쓰지 않는지를 인코딩 지연과 패킷 손실의 관점에서 풀어냅니다.
"720p의 p가 뭐예요?", "I-frame은 뭐고 P-frame은 뭐예요?" 영상 품질 이슈를 파다 보면 늘 같은 질문에 막힙니다. 이 글은 프레임이라는 개념부터 시작해 인터레이스와 프로그레시브의 차이, I·P·B 프레임이 각각 무엇을 담는지, GOP가 왜 2초인지, 그리고 PLI와 FIR가 어떻게 끊긴 화면을 되살리는지까지 현실 예시로 풀어냅니다. 다 읽고 나면 WebRTC가 왜 B-frame을 피하고 I와 P만 쓰는지, 그 구조적 이유가 손에 잡힐 겁니다.
마이크에 대고 말한 소리가 상대방 스피커에서 나기까지, 그 사이에는 ADC와 전처리, 코덱 인코딩, RTP 패킷화, UDP 전송, Jitter Buffer, 디코딩이 차례로 일어납니다. 이 글은 각 단계에서 왜 그런 선택을 하는지를 시니어 엔지니어 시선으로 짚습니다. 실시간 통신이 정확성 대신 지연을 줄이려 UDP를 쓰는 이유, Opus와 µ-law와 AAC를 언제 갈라 쓰는지, Jitter Buffer가 끊김을 흡수하는 방식, 그리고 RTMP와 WebRTC를 오가는 변환과 Voice AI의 VAD까지 하나의 흐름으로 연결해 봅니다.
"WAV는 무조건 44바이트 헤더 다음부터 데이터다", "PCM이면 다 비압축이다" 이런 말을 믿고 코딩하다 소리가 깨진 적 있나요? PCM은 소리를 숫자로 저장한 인코딩 방식이고 WAV는 그 숫자에 설명서를 붙인 컨테이너라는 차이부터, µ-law 같은 압축 PCM의 존재, 그리고 오프셋 44 하드코딩이 왜 위험한지까지 짚습니다. 샘플레이트와 채널, 비트 깊이를 잘못 해석하면 어디서 음성이 망가지는지, 브라우저와 STT 실무에서 무엇을 챙겨야 하는지 정리했습니다.
MP3가 어떻게 음질은 거의 그대로 둔 채 용량만 10분의 1로 줄이는지 궁금했던 적 있나요? 비밀은 데이터가 아니라 사람 귀의 한계에 있습니다. 이 글은 공기의 진동이 마이크에서 전기 신호가 되고, 샘플링과 양자화를 거쳐 PCM 숫자로 바뀐 뒤, 심리음향 압축으로 MP3가 되고, 다시 디코딩되어 스피커에서 소리로 돌아오는 전 과정을 그림과 함께 따라갑니다. 읽고 나면 44,100Hz와 16비트가 왜 CD 표준인지, MP3가 왜 손실 압축인지 직관적으로 이해하게 됩니다.
Google TTS는 MP3를 JSON 응답에 base64 문자열로 담아 보냅니다. 그냥 바이너리를 넣으면 안 되는 걸까요? JSON 파서가 ff f3 같은 바이트를 만나면 왜 깨지는지, MP3 파일 안에는 실제로 뭐가 들어 있는지, base64가 어떻게 비트를 6개씩 재배치하는지를 바이너리 기초부터 풀어냅니다. 용량이 33% 늘어나는 이유와 패딩 기호의 정체까지 따라가다 보면, base64가 압축도 암호화도 아닌 안전한 표현 방식이라는 점이 분명해집니다.