블로그 목록
Media18분 읽기

RTC 구현 비교 — libwebrtc와 서비스별 미디어 계층

Zoom, Discord, LiveKit, Agora, Slack, Meta가 공개한 자료를 바탕으로 표준 WebRTC, libwebrtc, 자체 미디어 계층의 경계를 비교합니다. 클라이언트 엔진과 서버 토폴로지, 전송 최적화, 운영 모델을 분리해 설명하고 공개 자료로 확인되지 않는 내부 구현은 추정하지 않습니다.

WebRTClibwebrtcZoomDiscordLiveKitAgoraSlackMetaSFURustAUT
목차(21개 항목)
  1. 0. 핵심 명제 — 출발점은 비슷하지만, 차별화는 인프라에서 갈린다
  2. 1. 먼저 정리: "libwebrtc" 라는 단어가 가리키는 것
  3. 2. 벤더별 한 줄 매트릭스 — 코어 기반 + 차별화
  4. 3. Zoom — 공개 문서 밖의 코어 구현은 단정하지 않는다
  5. 4. Discord — 가장 흔한 오해를 정정한다
  6. 5. LiveKit — "libwebrtc"도 "Rust"도 아닌, Go/Pion
  7. 6. Slack Huddles — 공개 AWS 사례에서 확인되는 범위
  8. 7. Meta — "fork 탈출"이라는 가장 정교한 사례
    1. 7.1 왜 fork를 버렸나 — shim 아키텍처
    2. 7.2 코덱: AV1 도입과 커스텀 스케일러
    3. 7.3 검증되지 않은 부분은 단정하지 않는다
  9. 8. Agora — 공개된 제품 범위와 비공개 구현을 구분한다
    1. 8.1 AUT — 문서에 등장하는 명칭
    2. 8.2 NOVA — 공식 제품 문서 범위에서 확인
    3. 8.3 SD-RTN 네트워크 수치
    4. 8.4 패킷 손실 복구 — 수치는 조심해서
  10. 9. 곁가지 정정 — Twilio Video와 Daily
  11. 10. 그래서 차별화는 어디서 나오나 — 코덱 < 인프라
  12. 11. 한 줄 결론
  13. 관련 글
  14. 참고 자료

"주요 RTC 벤더들은 모두 libwebrtc 기반인가요?" WebRTC 표준 준수와 Google의 C++ 구현인 libwebrtc 사용은 다른 말입니다. 각 제품의 비공개 미디어 스택은 추정하지 않고 공식 자료가 공개한 범위만 비교합니다.

이 글은 Zoom·Discord·LiveKit·Agora·Slack·Meta 여섯 벤더가 각각 "코어를 무엇으로 깔았고", "그 위에 무엇을 얹어 차별화했는지"를 검증된 출처 기준으로 정리합니다. 인터넷에 떠도는 "Discord가 미디어 엔진을 Rust로 재작성했다", "Twilio Video가 종료됐다" 같은 흔한 오해는 본문에서 "정정:"으로 명확히 바로잡습니다.

0. 핵심 명제 — 출발점은 비슷하지만, 차별화는 인프라에서 갈린다

RTC 제품은 표준 호환 여부, client implementation, media server, 지역 네트워크, 운영 도구, 암호화와 배포 모델에서 차이가 난다. 공개 출처 없이 특정 벤더의 코덱·프로토콜·서버 언어를 단정하지 않는다.

먼저 흔히 도는 일반화와 정확한 이해를 대조합니다.

흔한 일반화정확한 이해
"RTC 벤더는 다 libwebrtc 기반이다"표준 호환과 libwebrtc 사용을 구분하고 제품별 공식 문서 확인
"차별화는 코덱에서만 나온다"미디어 서버, 네트워크, 운영·보안 모델도 제품을 가르는 요소입니다.
"Discord는 미디어 엔진을 Rust로 재작성했다"공개 글의 Rust 전환 대상은 'Read States' 서비스입니다. 미디어 엔진으로 확대하면 안 됩니다.
"Twilio Video는 EOL됐다"Twilio는 종료 계획을 번복했습니다. 현재 상태는 공식 FAQ에서 다시 확인해야 합니다.
"LiveKit은 Rust로 쓰였다"공개 SFU 서버는 Go/Pion 기반입니다. Rust 사용을 서버 전체로 일반화하면 안 됩니다.
"Meta는 구글 fork를 그대로 쓴다"최신 upstream을 골격으로 옮겼지만 핵심 구성요소에 자체 구현·패치를 계속 사용
"Slack Huddles는 자체 구현이다"공개 AWS 사례에 따르면 Amazon Chime SDK 기반입니다.

1. 먼저 정리: "libwebrtc" 라는 단어가 가리키는 것

벤더 비교에서 혼란이 생기는 첫 번째 이유는 "WebRTC"라는 단어가 최소 세 가지를 동시에 가리키기 때문입니다. 비유하자면 "리눅스"가 커널·배포판·생태계를 동시에 뜻하는 것과 같습니다. 다만 비유는 여기까지고, 기술적 실체로 환원하면 다음 셋을 구분해야 합니다.

용어실체누가 관리
WebRTC 표준W3C/IETF가 정의한 API·프로토콜 명세(SRTP, ICE, SDP 등)W3C, IETF
libwebrtc구글이 webrtc.org에서 유지하는 C++ 레퍼런스 구현Google
호환 구현표준을 따르되 libwebrtc가 아닌 별도 코드베이스(예: Pion/Go)각 프로젝트
"WebRTC 기반" 이라는 말의 3가지 의미

  ① 표준만 준수    → 코드베이스는 자유 (Pion, aiortc 등)
  ② libwebrtc 사용 → 구글 C++ 구현을 직접 링크/fork
  ③ 비표준 확장    → 공식 제품 문서가 공개한 범위에서만 확인

이 구분을 깔고 보면, "다 libwebrtc 기반"이라는 일반화가 왜 절반만 맞는지 보입니다. ②만 진짜 libwebrtc고, ①은 표준 호환일 뿐이며, ③은 아예 표준 밖입니다.

2. 벤더별 한 줄 매트릭스 — 코어 기반 + 차별화

먼저 큰 그림부터. 검증된 출처 기준 한 줄 요약입니다.

벤더코어 기반핵심 차별화표준 WebRTC 여부
Zoom공식 SDK 문서 기준으로 확인비공개 코덱·WASM 내부는 이 글에서 단정하지 않음제품별 상이
Discord공식 공개 범위만 확인Read States의 Rust 전환을 음성 스택으로 확대하지 않음제품별 상이
LiveKitGo 기반 Pion WebRTC (libwebrtc C++ 아님)오픈소스 SFU, Go 서버, 다언어 SDKWebRTC 호환
Agora웹 SDK는 브라우저 WebRTC API 사용SD-RTN과 제품 운영 기능플랫폼별 공식 문서 확인
Slack HuddlesAmazon Chime SDK공개 AWS 사례 기준 관리형 구성요소 사용Chime SDK 기반
Meta최신 upstream 골격 + 자체 구성요소·패치shim 아키텍처, AV1 도입, 커스텀 스케일러libwebrtc 계열

핵심 패턴은 WebRTC 표준 준수와 특정 구현 사용을 구분하는 것입니다. 차이는 공개된 클라이언트 capability, 네트워크·서버·운영 레이어와 보안 모델에서 비교합니다.

3. Zoom — 공개 문서 밖의 코어 구현은 단정하지 않는다

Zoom의 현재 SDK가 지원하는 브라우저·코덱·WebRTC 모드는 공식 SDK 문서와 런타임 capability로 확인해야 합니다. 이 글이 확보한 1차 출처만으로 미디어 코어 구현을 확인할 수 없어 특정 기술을 사용하거나 사용하지 않는다고 분류하지 않습니다.

WebRTC를 지원한다와 libwebrtc를 코어로 사용한다는 다른 주장입니다. 공개 자료가 후자를 밝히지 않으면 추정하지 않습니다.

4. Discord — 가장 흔한 오해를 정정한다

Discord에 대해 인터넷에 가장 널리 퍼진 오해가 "Discord가 미디어 엔진을 Rust로 재작성했다"입니다. 이건 부정확합니다.

정정: Discord가 Go에서 Rust로 재작성한 것은 'Read States' 서비스이지, 음성 미디어 엔진이 아닙니다. Read States는 "어느 채널/메시지를 읽었는지" 추적하는 서비스입니다. Go의 GC(가비지 컬렉션)가 일으키는 지연 스파이크를 제거하려고 Rust로 옮긴 것입니다. Discord 엔지니어링 팀이 명시적으로 'Read States'로 특정했습니다.

두 컴포넌트를 헷갈리면 안 됩니다.

컴포넌트역할언어
Read States 서비스채널/메시지 읽음 여부 추적Go → Rust (GC 지연 제거 목적)
음성 미디어 스택실시간 음성 전송이 글이 인용한 공식 자료로 언어·토폴로지 확인 불가

Discord 공식 글은 Read States의 Go→Rust 전환만 설명합니다. 음성 미디어 스택의 언어·토폴로지는 공개 근거를 확보하지 못했으므로 비교표에서 미확인으로 둡니다.

5. LiveKit — "libwebrtc"도 "Rust"도 아닌, Go/Pion

LiveKit은 두 가지가 동시에 오해받습니다. ① "libwebrtc 기반" ② "Rust로 쓰였다" — 둘 다 정확히는 다릅니다.

정정 1: LiveKit의 SFU 서버는 Go로 작성되었고, Pion(Go로 구현된 WebRTC 라이브러리) 기반입니다. 구글의 C++ libwebrtc가 아닙니다. 즉 "WebRTC 표준 준수"는 맞지만 "libwebrtc 기반"은 아닙니다.

정정 2: LiveKit이 Rust를 쓰긴 하지만 SDK 레벨(다언어 클라이언트 SDK 중 하나)에서입니다. 핵심 서버는 Go입니다. "LiveKit = Rust"는 과장입니다.

레이어LiveKit 구현
SFU 서버Go (Pion 기반)
클라이언트 SDKJavaScript, Swift, Android, Rust, Python 등 다언어
코어 라이브러리Pion (Go, WebRTC 표준 구현)

LiveKit의 공개된 차별점은 오픈소스 SFU와 셀프 호스팅·관리형 배포 선택지, 다언어 SDK 생태계입니다.

6. Slack Huddles — 공개 AWS 사례에서 확인되는 범위

AWS의 공개 사례에 따르면 Slack Huddles는 Amazon Chime SDK를 사용했고 캡션에 Amazon Transcribe를 사용합니다. 이것만으로 Slack의 전체 RTC 스택이 자체 구현 없이 구성됐다고 확대하지 않습니다.

Slack Huddles 스택

  Slack 앱 UI
     │
     └──> Amazon Chime SDK (실시간 미디어)
              └──> Amazon Transcribe (캡션 — Chime SDK와 연동)

이는 벤더 비교의 한 축인 **"빌드 vs 바이"**를 보여줍니다. 관리형 구성요소는 출시와 운영 부담을 줄일 수 있지만 미디어 경로에 대한 통제 범위와 공급자 의존성이 달라집니다.

7. Meta — "fork 탈출"이라는 가장 정교한 사례

Meta는 이 글에서 가장 깊게 볼 가치가 있는 사례입니다. "구글 fork를 그대로 쓴다"는 통념이 가장 크게 바뀐 곳이기 때문입니다.

Meta는 50개가 넘는 use case를 오래된 fork에서 최신 upstream을 골격으로 쓰는 모듈형 구조로 옮겼습니다. 핵심 구성요소에는 자체 구현과 패치를 계속 주입합니다. 이 작업을 2020년 Rsys 프로젝트와 직접 연결하는 근거는 공식 글에 없으므로 두 사례를 별도로 다룹니다.

7.1 왜 fork를 버렸나 — shim 아키텍처

Meta 엔지니어링 블로그는 2026년 4월 'Escaping the Fork' 포스트에서 shim(프록시 라이브러리) 아키텍처를 문서화했습니다.

shim layer는 'flavor' 설정을 보유하고, 런타임에 각 호출을 legacy WebRTC 또는 최신 WebRTC 구현 중 하나로 dispatch합니다. AST(Abstract Syntax Tree) 기반 자동 코드 생성으로 구현했습니다.

Meta shim 아키텍처 (개념)

  앱 코드
    │  webrtc:: 호출
    ▼
  ┌──────────── shim layer ────────────┐
  │  flavor 설정에 따라 런타임 dispatch    │
  │     ├─> webrtc_latest::  (upstream) │
  │     └─> webrtc_legacy::  (구 fork)   │
  └─────────────────────────────────────┘

엔지니어링적으로 영리한 부분:

문제Meta의 해법
두 버전 동시 링크 → 바이너리 폭증(38MB)자동 renamespacing으로 5MB 증가로 억제
네임스페이스 충돌 (webrtc::)webrtc_latest:: / webrtc_legacy:: 자동 분리
shim 수작업 생성 느림AST 기반 자동화로 하루 1개 → 3~4개로 가속

비유하자면 "옛집(fork)과 새집(upstream) 사이에 자동 통역사(shim)를 두고, 가구를 하나씩 옮기는" 점진적 이사입니다. 기술적 실체로 환원하면 — 빅뱅 교체의 위험 없이, 호출 단위로 신/구 구현을 전환하며 검증한 것입니다.

7.2 코덱: AV1 도입과 커스텀 스케일러

Meta는 AOMedia의 AV1을 모바일 RTC에 도입했습니다. 2024년 글은 해당 테스트에서 약 2dB 품질 향상을, 커스텀 스케일러는 libyuv box filter 대비 평균 0.75dB PSNR 이득을 보고합니다. 서로 다른 실험의 수치를 합산하지 않습니다.

항목수치/내용출처 검증
AV1 vs H.264 품질해당 Meta 실험에서 약 +2dBMeta 2024 글
커스텀 스케일러 PSNR 이득해당 Meta 실험에서 평균 +0.75dBMeta 2024 글
AV1 CPU·배터리기기·설정별 측정 필요고정 배수·증가율은 삭제

AV1의 royalty-free 특성과 라이선스 비용은 선택 기준 가운데 하나였습니다. 적용 여부는 기기 capability와 제품 정책에 따라 H.264와 협상합니다.

7.3 검증되지 않은 부분은 단정하지 않는다

이 글이 인용한 Meta 공식 자료는 전 세계 SFU 배포 구조를 설명하지 않습니다. 따라서 P2P→SFU 전환과 worldwide media server 배포 주장은 삭제하고 Rsys의 signaling 통합만 기술합니다.

Meta는 AV1 선택에서 royalty-free 특성과 codec licensing을 고려했다고 밝혔지만 구체적인 절감액은 공개하지 않았습니다. 공개되지 않은 절감액을 추정하지 않습니다.

8. Agora — 공개된 제품 범위와 비공개 구현을 구분한다

Agora Web SDK는 브라우저 WebRTC API를 사용하고, 네이티브 SDK의 세부 전송·코덱 구현은 공개 문서 범위에서만 확인합니다.

Agora는 제품별 암호화와 전송 보안 기능을 제공합니다. Server Gateway 문서의 AUT 언급을 모든 네이티브 SDK의 packet format이나 SRTP 대체 관계로 일반화하지 않습니다.

8.1 AUT — 문서에 등장하는 명칭

AUT라는 명칭은 일부 Agora 문서에 등장하지만 상세 packet format과 다른 프로토콜의 관계는 공개되지 않았습니다.

AUT의 UDP 멀티플렉싱, QUIC 연관성, SRTP 대체 여부는 공개 문서만으로 단정하지 않습니다. 보안 검토에서는 현재 Agora security 문서와 실제 SDK 설정을 기준으로 합니다.

8.2 NOVA — 공식 제품 문서 범위에서 확인

NOVA의 세부 codec mode와 AI 사용 여부는 현재 공식 제품 문서가 확인하는 범위만 기술합니다. 공개 근거 없이 협대역·광대역 전환 구조를 단정하지 않습니다.

8.3 SD-RTN 네트워크 수치

현재 공식 SD-RTN 페이지가 공개하는 제품 지표:

항목수치
커버리지200+ 국가/지역
end-to-end latency400ms 이하라는 Agora 제품 주장

8.4 패킷 손실 복구 — 수치는 조심해서

Agora는 네트워크 복원력을 제품 특성으로 설명하지만 테스트 조건이 없는 손실 복구율을 일반화하지 않습니다. 대상 지역·기기·비트레이트에서 impairment test를 수행합니다.

제품 내부에서 FEC와 재전송을 어떻게 조합하는지는 공개 자료 없이 도식화하지 않습니다. FEC가 코덱과 별개 계층이라는 일반 원리는 #43에서 다룹니다.

9. 곁가지 정정 — Twilio Video와 Daily

벤더 지형도에서 자주 잘못 인용되는 두 가지를 짚습니다.

정정 (Twilio Video): Twilio는 종료 계획을 번복하고 2024년 10월 지속 투자를 공지했습니다. 현재 제품 상태는 공식 FAQ에서 다시 확인해야 하며 비공개 코어 구현은 여기서 단정하지 않습니다.

Daily: 공식 room API는 P2P/SFU 전환 설정을 제공하며, 공식 security 페이지는 true E2EE 지원을 안내합니다. E2EE 사용 가능 범위와 녹화·스트리밍 등 서버 측 기능의 제약은 현재 문서에서 확인해야 합니다.

10. 그래서 차별화는 어디서 나오나 — 코덱 < 인프라

RTC 벤더 비교에서는 다음 축을 확인해야 합니다.

차별화 축설명예시
SFU 아키텍처미디어 라우팅 방식·확장성LiveKit 오픈소스 SFU 등 공개 구현
글로벌 네트워크엣지·라우팅 최적화Agora SD-RTN의 현재 공식 지표로 검증
손실 복구 전략FEC·재전송·적응형 비트레이트공식 기능과 impairment test로 비교
암호화 모델E2EE 지원 범위와 서버 기능의 교환Daily는 true E2EE 지원
빌드 vs 바이자체 구축 vs 관리형 구성요소공개 아키텍처 자료와 계약 범위로 비교
운영 모델셀프 호스팅 vs 매니지드LiveKit(셀프 가능) vs CPaaS

왜 코덱이 차별화가 약한가? Opus(IETF RFC 6716, 2012)·VP8/9·H.264·AV1 모두 표준이거나 사실상 표준이기 때문입니다. 참고로 Opus는 단일 조직이 만든 게 아니라 Broadcom·Google·IETF·Microsoft(Skype)·Mozilla·Octasic·Xiph.Org의 다중 조직 협력 결과입니다(SILK+CELT 하이브리드). 모두가 같은 표준 코덱을 쓸 수 있으니, 코덱만으로는 갈리지 않습니다.

코덱 선택과 자체 미디어 처리도 차이를 만들 수 있지만, 비공개 구현은 추정하지 않습니다. 실제 비교에서는 공개된 capability, 네트워크·운영 기능과 측정 결과를 함께 봅니다.

11. 한 줄 결론

WebRTC 표준 준수와 libwebrtc 사용은 다르다. 제품 비교에서는 공개된 client implementation, media topology, 지역 네트워크, 보안, 운영 모델과 비용을 각각 검증한다. 비공개 코덱·전송 내부와 조건 없는 성능 수치는 단정하지 않는다.

관련 글

참고 자료

© 2026 Frank Kim. All rights reserved.