WebRTC 벤더 지형도 — 누가 libwebrtc 위에 무엇을 얹었나 (Zoom·Discord·LiveKit·Agora·Slack·Meta)

"주요 RTC 벤더들은 결국 다 구글 libwebrtc 위에 얹은 거 아닌가요? 그럼 차별화는 어디서 나오나요?". 기술 검토나 벤더 비교 자리에서 자주 나오는 질문입니다. 답은 "절반만 맞다"입니다 — 대부분이 libwebrtc 또는 WebRTC 표준에서 출발한 건 맞지만, 그 일반화에는 분명한 예외(Zoom)가 있고, 진짜 차별화는 코덱이 아니라 인프라 레이어에서 일어납니다.

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

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

현대 RTC 벤더의 코어는 대부분 libwebrtc이거나 WebRTC 표준 호환 구현이다. 코덱(Opus, VP8/9, H.264, AV1)은 표준화되어 있어 차별화 요인이 약하다. 진짜 차별화는 SFU 아키텍처, 글로벌 네트워크 인프라, 라우팅 최적화, FEC/ARQ 같은 손실 복구 전략, 그리고 스케일링 능력에서 나온다. 단 하나의 큰 예외가 Zoom인데, Zoom은 독자 코덱/프로토콜 비중이 크다.

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

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

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

"WebRTC 기반" 이라는 말의 3가지 의미

  ① 표준만 준수    → 코드베이스는 자유 (Pion, aiortc 등)
  ② libwebrtc 사용 → 구글 C++ 구현을 직접 링크/fork
  ③ 표준 무시      → 자체 proprietary 프로토콜 (Agora 네이티브, Zoom 일부)

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

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

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

핵심 패턴: 코어 기반은 비슷한데(WebRTC 표준/libwebrtc), 그 위에 무엇을 얹었느냐가 다르다. 그리고 그 "얹은 것"은 거의 다 코덱이 아니라 네트워크·서버·운영 레이어입니다. 예외는 Zoom과 Agora 네이티브뿐입니다.

3. Zoom — "다 libwebrtc"라는 일반화의 가장 큰 예외

Zoom은 "대부분 libwebrtc 기반" 일반화가 깨지는 지점입니다.

🟢 사실: Zoom은 고유 H.264 구현을 보유한 독자 비디오 스택을 사용합니다. Zoom 웹 SDK는 표준 WebRTC 코덱 대신 WebAssembly 기반 커스텀 인코딩/디코딩 모듈을 사용합니다. 이 때문에 표준 WebRTC 스택보다 CPU 사용률이 높다는 보고가 있습니다.

일반 WebRTC 웹 클라이언트          Zoom 웹 SDK
┌─────────────────────┐          ┌─────────────────────┐
│ 브라우저 내장 코덱     │          │ 브라우저 내장 코덱     │
│ (VP8/H.264 하드웨어)  │          │      ↓ (우회)         │
│                     │          │ WASM 커스텀 코덱       │
│                     │          │ (CPU 인코딩)          │
└─────────────────────┘          └─────────────────────┘
   브라우저가 코덱 결정              Zoom이 코덱 통제

⚠️ 주의: Zoom도 WebRTC 지원을 추가하긴 했습니다. 다만 "WebRTC를 지원한다"와 "WebRTC가 코어다"는 다릅니다. Zoom의 차별점은 여전히 독자 구현에 있습니다.

왜 이렇게 했을까? 비유하자면 "남의 집 부엌(브라우저 코덱)을 빌려 쓰지 않고, 어디서든 똑같이 동작하는 자기 주방기구(WASM)를 들고 다니는" 전략입니다. 기술적 실체로 환원하면 — 브라우저 벤더가 지원하는 코덱·설정에 종속되지 않고, 플랫폼 간 일관된 화질/동작을 자체 통제하려는 것입니다. 대가는 CPU 부담입니다.

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

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

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

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

🟢 Discord의 실제 차별화: 음성 스택은 단일 언어가 아니라 Rust·Elixir·WebRTC의 혼합 구성이며, 커스텀 SFU를 사용합니다. 즉 차별화는 "Rust로 재작성"이라는 단일 사건이 아니라, 컴포넌트별로 최적 도구를 고른 아키텍처 선택에 있습니다.

Discord 음성 (개략)

  클라이언트 ──WebRTC──> [커스텀 SFU]
                          │
        시그널링/오케스트레이션: Elixir (대규모 동시 연결)
        성능 핵심 경로:        Rust (저지연·GC 없음)

⚠️ 위 다이어그램은 출처(블로그/미디엄 분석)에 근거한 개략도이며, Discord의 내부 토폴로지 세부는 공개 자료로 전부 확인되지는 않습니다.

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 기반이라 운영/배포가 단순하다는 점, 그리고 폭넓은 다언어 SDK 생태계. 코덱이 아니라 "셀프 호스팅 가능한 SFU"라는 운영 모델이 핵심입니다.

6. Slack Huddles — 직접 만들지 않았다

Slack Huddles는 흥미로운 사례입니다. Slack은 RTC 스택을 직접 빌드하지 않았습니다.

🟢 사실: Slack Huddles는 Amazon Chime SDK 기반으로 구축되었습니다. 캡션 기능에는 Amazon Chime SDK가 Amazon Transcribe(AWS의 독립 음성 인식 서비스)와 연동해 제공합니다. Slack과 AWS의 전략적 파트너십의 일환입니다.

Slack Huddles 스택

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

이건 벤더 지형도에서 중요한 한 축입니다 — "빌드 vs 바이". Discord/Agora가 스택을 직접 만든 쪽이라면, Slack은 검증된 클라우드 RTC(Chime)에 위탁한 쪽입니다. 트레이드오프는 명확합니다. ✅ 빠른 출시·운영 부담 감소 vs ❌ 미디어 경로 통제권·차별화 여지 축소.

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

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

정정: Meta는 과거에 구글 libwebrtc를 fork해서 썼지만, 현재는 upstream webrtc로 마이그레이션을 완료했습니다. 오랫동안 upstream과 벌어졌던 fork를 최신 upstream으로 교체했고, 2026년 현재 50개 이상의 use case가 upstream 기반으로 운영 중입니다. ([NEEDS VERIFICATION] Rsys(2020)와의 직접 연계는 'Escaping the Fork' 기사에 명시되지 않음)

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)   │
  └─────────────────────────────────────┘

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

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

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

🟢 사실(검증됨): Meta는 모바일 RTC에 AV1 코덱을 도입했습니다. H.264 대비 2dB 품질 향상을 달성했고, 커스텀 비디오 스케일러로 PSNR 평균 0.75dB를 추가로 얻었습니다(표준 libyuv 스케일러 대비 우수). 관심 영역(ROI) 인코딩 — 얼굴 영역 우선 — 등 콘텐츠 인식 최적화도 적용했습니다.

⚠️ AV1은 royalty-free라 코덱 라이선스 비용 회피가 주요 동기였습니다. 다만 공식 문서 기준 AV1 인코딩은 H.264 대비 CPU 부담이 약 3배(three-fold)로 CPU-intensive해서 저사양 기기에서는 비활성화했고, 배터리 문제는 하이브리드 인코더로 해결했습니다. 즉 "무조건 AV1"이 아니라 디바이스 조건부 적용입니다.

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

정정/주의: "Meta가 자체 SFU/미디어 서버 인프라를 전 세계 구축했다(P2P→SFU 전환)"는 공식 문서로 확인되지 않습니다 [NEEDS VERIFICATION]. Rsys 블로그는 P2P와 group calling을 통합한 '상태 머신 기반 시그널링'을 언급하지만, worldwide SFU 인프라 배포는 명시하지 않습니다. P2P→SFU 전환은 업계 일반 관행이나, Meta의 실제 구현 여부는 공개 자료로 확인 불가입니다.

정정/주의: "라이선스 비용 조 단위 회피가 동기"라는 주장은 부분만 사실입니다. Meta는 AV1 채택 동기가 'royalty-free'이며 "codec licensing/concurrent fees가 의사결정의 중요한 측면"이라고 명시했지만, 구체적인 '조 단위' 절감 수치는 공개한 적이 없습니다 [NEEDS VERIFICATION]. 참고로 H.264 라이선스는 연간 최대 약 $9.75M, HEVC는 더 복잡한 multi-pool 구조입니다.

8. Agora — 표준 밖으로 나간 네이티브 스택

Agora는 "표준을 따르되 위에 얹는" 다른 벤더들과 달리, 네이티브에서는 표준 밖으로 나간 사례입니다. (이 주제는 블로그 #43에서 코덱/네트워크 레이어 분리로 더 깊게 다뤘습니다.)

🟢 사실(검증됨): Agora 네이티브 SDK는 WebRTC 표준을 그대로 따르지 않고 자체 proprietary 전송/암호화를 사용합니다. 공식 문서(Server Gateway 보안 설명서)는 "Agora uses the AUT (Agora Universal Transport) encryption protocol, Agora's proprietary secured transport layer" 라고 명시합니다 — 즉 표준 DTLS-SRTP가 아닌 자체 보안 전송 계층(AUT)을 씁니다. 단, 웹 SDK는 브라우저 WebRTC 호환성을 유지합니다.

8.1 AUT — 실존하는 전송 프로토콜 (단, 세부 구현은 비공개)

✅ AUT(Agora Universal Transport)는 공식 Agora 문서에 실제로 등장하는 기술입니다(환각 아님). 공식 문서가 확인해 주는 범위는 "Agora의 독자 보안 전송 계층(proprietary secured transport layer)" 까지입니다.

⚠️ 정정/주의: 인터넷에 도는 "AUT는 UDP 기반 멀티플렉싱이고 QUIC 설계를 참고했다"는 설명은 공식 보안 문서에는 명시되어 있지 않습니다 [NEEDS VERIFICATION]. 전송 계층이 UDP 위에서 동작한다는 것은 RTC 특성상 합리적 추정이지만, "QUIC 기반/참고"는 2차 출처(블로그)에서 나온 주장이므로 단정하지 말아야 합니다. 확실한 것은 ① AUT라는 이름의 독자 보안 전송 계층이 존재하고 ② 표준 SRTP를 대체한다는 두 가지뿐입니다.

8.2 NOVA 코덱 — 명칭은 맞되 "AI 코덱"은 정정

정정: Agora는 NOVA라는 자체 오디오 코덱을 보유합니다(협대역/광대역/초고주파 지원, 모드 간 전환 가능). 다만 일부에서 부르는 'AI 오디오 코덱'이라는 표현은 부정확합니다. NOVA가 AI/머신러닝 기반이라는 공식 설명은 찾기 어렵습니다. 그냥 **'Agora NOVA 코덱'**으로 부르는 것이 정확합니다.

8.3 SD-RTN 네트워크 수치

🟢 사실(공식 백서 검증됨):

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

정정/주의: Agora가 ARQ+FEC를 결합해 손실 복구력을 높이는 건 사실입니다. 다만 인터넷에 도는 "70~80% 패킷 손실에도 통화 유지" 수치는 Agora 공식 문서로 확인되지 않습니다 [NEEDS VERIFICATION]. 이 수치는 제3자 테스트(Medium 기사)에서 나온 것입니다. 검증된 표현은 "Agora의 테스트에 따르면 경쟁 SDK가 60% 손실에서 끊길 때 계속 작동했다"는 주장 정도까지입니다. 구체적 % 수치를 쓸 때는 반드시 "일부 보고에 따르면"을 붙여야 합니다.

Agora 손실 복구 레이어 (개념)

  미디어 패킷
    ├─ FEC: 손실 대비 여분 패킷 미리 전송 (재전송 없이 복원)
    └─ ARQ: 손실 감지 시 재전송 요청
              ↑ 둘을 결합 — 손실률에 따라 가중치 조절

(FEC가 코덱이 아니라 별개 채널 코딩 레이어라는 점은 #43에서 자세히 다뤘습니다.)

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

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

정정 (Twilio Video): "Twilio Video가 2024년 EOL/종료됐다"는 사실이 아닙니다. Twilio는 초기에 종료를 발표했으나 이를 번복했고(reversal), 2024년 10월 지속 투자를 재공표했습니다. 현재 계속 개발 중입니다. 정확한 상태는 "종료"가 아니라 "번복"(종료 결정을 취소하고 지속)입니다. (코어는 libwebrtc.jar 채택)

🟢 Daily: WebRTC 표준 기반 SFU 아키텍처를 사용하며, P2P/SFU를 동적으로 전환합니다. LiveKit과 마찬가지로 "표준 준수"이지 "libwebrtc 기반"과는 구분해야 합니다. (참고: Daily는 완전 종단간 암호화(E2EE)를 미지원 — SFU 재암호화 모델. 이 선택 자체도 벤더 차별점입니다.)

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

🟢 사실(업계 일반화로 검증됨): 현대 RTC 벤더의 주요 차별화 포인트는 다음입니다.

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

예외는 ① 코덱을 직접 통제하는 Zoom(WASM)·Meta(AV1+커스텀 스케일러), ② 전송 자체를 표준 밖에서 푸는 Agora(AUT/SD-RTN) 정도입니다. 그리고 이 예외들조차 진짜 무기는 코덱 그 자체보다 인프라·운영 통제권에 있습니다.

11. 한 줄 결론

"다 libwebrtc 기반"은 절반만 맞다 — 대부분 WebRTC 표준/libwebrtc에서 출발하지만, Zoom은 독자 구현, Agora 네이티브는 표준 밖이다. 그리고 어느 쪽이든 진짜 차별화는 코덱이 아니라 SFU·글로벌 네트워크·손실 복구·운영 모델 같은 인프라 레이어에서 나온다. 마지막으로, 'Discord가 미디어 엔진을 Rust로 재작성', 'Twilio Video EOL', 'NOVA는 AI 코덱', '70~80% 손실에도 통화 유지' 같은 미검증 명제는 단정하지 말고 출처를 붙여라.

관련 글

• WebRTC/ICE/STUN/TURN/NAT 기초
• Agora 자체 코덱 vs Web SDK, SD-RTN, FEC
• 라이브 스트리밍 프로토콜 선택 HLS/LL-HLS/WebRTC
• 오디오 파이프라인 (Opus/RTP/Jitter Buffer)
• Agora 방화벽 우회 Cloud Proxy

참고 자료

• Meta Engineering — Escaping the Fork: How Meta Modernized WebRTC: https://engineering.fb.com/2026/04/09/developer-tools/escaping-the-fork-how-meta-modernized-webrtc-across-50-use-cases/
• Meta Engineering — Rsys 아키텍처: https://engineering.fb.com/2020/12/21/video-engineering/rsys/
• Meta Engineering — Mobile RTC Video with AV1: https://engineering.fb.com/2024/03/20/video-engineering/mobile-rtc-video-av1-hd/
• Meta Engineering — AV1 video codec on mobile (white paper): https://engineering.fb.com/2025/09/24/video-engineering/video-streaming-with-av1-video-codec-mobile-devices-meta-white-paper/
• Discord — Why Discord is switching from Go to Rust (Read States): https://discord.com/blog/why-discord-is-switching-from-go-to-rust
• Discord 음성 스택 분석 (Rust/Elixir/WebRTC): https://medium.com/@theopinionatedev/discords-voice-stack-how-rust-elixir-and-webrtc-power-150-million-voices-9c03465aa194
• LiveKit SFU internals: https://docs.livekit.io/reference/internals/livekit-sfu/
• LiveKit server (Go): https://pkg.go.dev/github.com/livekit/livekit-server
• AWS — Slack chooses Amazon Chime SDK: https://aws.amazon.com/blogs/business-productivity/customers-like-slack-choose-the-amazon-chime-sdk-for-real-time-communications/
• Zoom WebRTC Video SDK 분석 (webrtc.ventures): https://webrtc.ventures/2025/05/zooms-webrtc-powered-video-sdk-a-powerful-addition-to-the-cpaas-landscape/
• Zoom Web SDK technical notes (Daily): https://www.daily.co/blog/zoom-web-sdk-technical-notes/
• Twilio Programmable Video 상태 (bloggeek): https://bloggeek.me/twilio-programmable-video-back/
• Twilio Video EOL Notice (공식): https://help.twilio.com/articles/20950630029595-Programmable-Video-End-of-Life-Notice
• Agora Server Gateway — Security (AUT): https://docs.agora.io/en/server-gateway/reference/security
• Agora Platform Advantage / Network: https://www.agora.io/en/the-agora-platform-advantage/
• Agora Network Performance Whitepaper: https://explore.agora.io/hubfs/Landing%20pages/Agora-Network-Performance-Whitepaper.pdf
• libwebrtc 가이드 및 대안 (webrtc.ventures): https://webrtc.ventures/2024/05/native-webrtc-development-a-guide-to-libwebrtc-and-alternatives/
• Opus codec (RFC 6716 / opus-codec.org): https://opus-codec.org/
• Daily 비디오 아키텍처: https://www.daily.co/guides/architecture-and-monitoring/intro-to-video-arch