프롤로그

WebRTC로 실시간 영상 상담 서비스를 개발하면서 항상 궁금했던 질문이 있었습니다.

답은 코덱(Codec)에 있었습니다.
같은 화상 회의라도 어떤 코덱을 사용하느냐에 따라 화질, 데이터 사용량, CPU 사용률이 완전히 달라집니다.

이번 글에서는 WebRTC에서 사용되는 미디어 코덱을 실무 관점에서 정리했습니다.
복잡한 압축 알고리즘 이론은 제외하고, 실제로 필요한 핵심 내용만 담았습니다.

코덱이 필요한 이유

압축 없이는 불가능합니다

HD 영상(1920x1080) 1초 분량을 단순 계산해보겠습니다.
(대략치이며, 단순화를 위해 4바이트 색상, 30프레임, 10진 단위 표기를 사용합니다.)

1920 × 1080 픽셀 × 4바이트 × 30프레임  
= 약 249MB/초  

30분 화상 회의라면 약 447GB 내외의 데이터가 필요합니다.
이를 실시간으로 전송하려면 약 2Gbps 수준의 대역폭이 필요한데, 일반 가정용 인터넷(예: 100Mbps)으로는 어렵습니다.

💡 코덱(Codec)이란?
Coder + Decoder의 합성어입니다.
영상과 음성을 압축(인코딩)하고 다시 푸는(디코딩) 기술을 의미합니다.

코덱의 압축 효과

같은 HD 영상을 코덱으로 압축하면 대략 이런 수준으로 내려갑니다.
(콘텐츠/설정/장면 복잡도에 따라 크게 달라집니다.)

무려 1,000배 이상까지 압축이 가능합니다.

💡 손실 압축 vs 무손실 압축
손실 압축: 원본과 완전히 동일하지는 않지만, 사람이 인지하기 어려운 수준으로 압축 (H.264, VP9 등)
무손실 압축: 원본과 100% 동일하게 복원 가능 (예: FLAC)

WebRTC는 실시간성이 중요하기 때문에 손실 압축을 주로 사용합니다.

코덱 기초 개념

비트레이트(Bitrate)

1초에 전송되는 데이터의 양을 의미합니다.

비트레이트가 높을수록 화질은 좋아지지만, 네트워크 부담과 데이터 사용량이 증가합니다.

해상도(Resolution)

영상의 가로×세로 픽셀 수를 나타냅니다.

WebRTC에서는 주로 720p를 사용합니다.
1080p는 네트워크와 CPU 부담이 커서, 서비스 성격에 따라 720p로도 충분한 경우가 많습니다.

프레임레이트(Frame Rate)

1초에 표시되는 프레임(장) 수를 의미합니다.

WebRTC는 프레임레이트를 “표준값”으로 고정하지 않습니다.
실무에서는 24~30fps를 목표로 두는 경우가 많지만, 실제 값은 네트워크/기기 성능에 따라 가변적으로 내려갑니다.

인코딩과 디코딩

인코딩(Encoding): 원본 영상을 압축하는 과정
디코딩(Decoding): 압축된 영상을 재생 가능한 형태로 복원하는 과정

양쪽 모두 같은 코덱을 지원해야 통신이 가능합니다.

비디오 코덱 비교

VP8

2010년 Google이 On2 Technologies를 인수하면서 오픈소스로 공개한 코덱입니다.

• WebRTC 호환 구현에서 필수로 지원해야 하는 비디오 코덱(MTI) 중 하나로 언급됩니다.
• 로열티-프리(royalty-free)로 다뤄지는 경우가 많아 라이선스 부담이 상대적으로 낮은 편으로 정리됩니다.
• 빠른 인코딩/디코딩
• 압축 효율은 VP9/AV1 계열 대비 낮은 편

사용 시나리오

성능 지표

지연은 코덱만으로 결정되지 않고, 지터버퍼/패킷화/네트워크 상태/인코딩 설정의 영향을 크게 받습니다.

장점: 호환성/안정성, 구현 난이도/부하가 상대적으로 낮은 편
단점: 같은 화질 대비 데이터 사용량이 더 많아질 수 있음

VP9

2013년 Google이 공개한 VP8의 후속작입니다.
같은 화질을 VP8보다 더 적은 데이터로 구현하는 것을 목표로 합니다(절감률은 상황 의존).

• VP8 대비 압축 효율 개선(콘텐츠/설정에 따라 편차 큼)
• 인코딩 비용(연산량)이 더 큼
• 오래된 기기/환경에서는 부담이 될 수 있음

사용 시나리오

VP8 vs VP9 비교

장점: 데이터 사용량 감소(조건이 맞으면 효과 큼)
단점: 인코딩 부담 증가, 오래된 기기에서 성능 저하 가능

브라우저/환경 메모

• Chrome/Firefox/Chromium 계열에서는 VP9 사용이 비교적 수월한 편입니다.
• Safari는 기기/운영체제/정책/가속 여부에 따라 달라질 수 있어, 서비스에서는 VP9를 “가능하면 사용” 정도로 두고 H.264/VP8 폴백을 함께 설계하는 편이 안전합니다.

H.264

2003년 표준화된, 매우 널리 쓰이는 비디오 코덱입니다.

• WebRTC 호환 구현에서 VP8과 함께 필수로 지원해야 하는 비디오 코덱(MTI)로 언급되며, 보통 Constrained Baseline 프로파일을 전제로 이야기됩니다.
• 하드웨어 가속이 잘 되는 환경이 많아(특히 모바일) 전력/부하 측면에서 유리한 경우가 많음
• 매우 안정적이고 검증된 생태계
• 압축 효율은 VP9/AV1 계열 대비 낮을 수 있음
• 특허/라이선스 체계 존재(사용/배포 형태에 따라 이슈가 달라짐)

사용 시나리오

성능 지표

💡 라이선스 관련

H.264는 특허 라이선스 체계가 있어, 인코더/디코더의 배포 방식, 서비스 형태/규모에 따라 비용 이슈가 달라질 수 있습니다.
“대부분 무료”처럼 단정하기보다, 배포·상용 조건을 기준으로 확인하는 편이 안전합니다.

H.264 프로파일

비디오 코덱 선택 가이드

오디오 코덱 비교

Opus

2012년 표준화된 오디오 코덱으로, WebRTC에서 핵심 오디오 코덱으로 필수 지원(MTI)에 포함됩니다.

• 낮은 비트레이트에서도 품질이 좋음
• 6 kbit/s ~ 510 kbit/s 범위를 지원하며, 그 범위 안에서 동적으로 변경할 수 있습니다.
• 지연은 프레임 크기/설정에 따라 수 ms~수십 ms 수준(상황 의존)
• 음성과 음악 모두 준수

비트레이트별 품질 비교

용도별 권장 설정

G.711

1972년 표준화된 오래된 오디오 코덱으로, 전통 전화망과 호환성이 큽니다.
WebRTC 호환 구현에서는 Opus와 함께 G.711(PCMU/PCMA)도 필수 지원(MTI)로 언급됩니다.

• 코덱 처리 자체는 매우 단순하고 빠른 편
• 64 Kbps 고정
• 전화 음질 수준

사용 시나리오

G.711 vs Opus 비교

💡 체감 지연 메모
코덱 처리 지연이 낮아도, 실제 통화 지연은 지터버퍼/패킷화/네트워크 상태 영향이 훨씬 큽니다.

크롬에서 실제 코덱 확인하기

webrtc-internals 활용

1) 접속 방법

WebRTC 연결 중에 새 탭에서 아래 주소로 접속합니다.

2) 연결 정보 확인

3) 코덱 정보 찾기

예시:

SDP 확인

해석: 96, 97, 98은 코덱 “우선순위 번호”가 아니라 페이로드 타입(payload type) 입니다.
보통 앞에 둔 코덱을 선호하도록 제안하는 경우가 많지만, 최종 선택은 양쪽 지원 교집합 + 응답(answer) + 브라우저 정책에 의해 결정됩니다.

코덱 설정 예시

일반 화상 회의

모바일 데이터 절약 모드

예상 데이터 사용량(극단적인 예시, 1시간)

차세대 코덱

AV1

2018년 Alliance for Open Media가 발표한 차세대 코덱입니다.

• VP9 대비 더 높은 압축 효율을 목표로 설계
• 로열티 부담을 줄이는 방향(로열티-프리 정책을 목표로 확산)
• 인코딩 비용이 크고, 실시간 적용은 환경(기기 성능/가속/정책) 영향이 큼
• WebRTC에서는 “가능하면 사용” 정도로 두고 폴백을 함께 설계하는 방식이 안전합니다.

AV2

AV2는 AV1의 후속으로 개발 중인 차세대 코덱입니다.

• AV1 대비 추가 압축 효율 개선을 목표로 개발
• 구체적인 개선 폭은 평가 방법/콘텐츠/설정에 따라 달라질 수 있음
• 표준화/적용 일정은 브라우저/구현체/하드웨어 생태계 진행 상황에 따라 변동될 수 있음 ([Alliance for Open Media][5])

마무리

핵심 정리

비디오 코덱

오디오 코덱

• 대부분: Opus
• 레거시/연동: G.711(PCMU/PCMA)

실무 팁

1. webrtc-internals로 확인
   실제 협상된 코덱(mimeType), 해상도, 프레임, 수신량을 숫자로 확인하기

2. 폴백 전략은 필수
   Safari/기기/정책 변수 때문에 단일 코덱만 믿고 가면 운영에서 흔들릴 수 있습니다.

3. 네트워크 적응
   불안정하면 해상도/프레임/비트레이트 상한을 낮추는 방향이 효과적입니다.

[발신자]  
카메라 → 인코딩 → 전송

[수신자]  
수신 → 디코딩 → 화면 표시  

호환성이 최우선인 경우  
안정적인 기본 코덱이 필요한 경우  

대역폭 절약이 중요한 경우  
최신 환경(브라우저/기기) 중심인 경우  

모바일 배터리/발열이 중요한 경우  
하드웨어 가속에 기대고 싶은 경우  
레거시 호환이 중요한 경우  

모바일 배터리/가속이 최우선인가?  
└─ 예 → H.264 우선(가능하면) + 폴백 설계  
└─ 아니오 ↓

대역폭 절약이 최우선인가?  
└─ 예 → VP9(가능하면) + 폴백 설계  
└─ 아니오 ↓

호환성이 최우선인가?  
└─ 예 → VP8(안전 기본)  

전화 시스템 연동이 중요한 경우  
레거시 호환이 필요한 경우  

chrome://webrtc-internals  

inbound-rtp (video)  
├─ codecId: 사용 중인 코덱 참조(id)  
├─ frameWidth / frameHeight: 해상도  
├─ framesPerSecond: 초당 프레임 수  
└─ bytesReceived: 수신 데이터량  

검색창에 "codec" 입력  
→ codec 통계 항목에서 mimeType 확인  

{  
  "type": "codec",  
  "mimeType": "video/VP9",  
  "clockRate": 90000,  
  "payloadType": 98  
}  

m=video 9 UDP/TLS/RTP/SAVPF 96 97 98  
a=rtpmap:96 VP8/90000  
a=rtpmap:97 VP9/90000  
a=rtpmap:98 H264/90000  

const configuration = {  
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]  
};  

const constraints = {  
  video: {  
    width: { ideal: 640 },  
    height: { ideal: 480 },  
    frameRate: { ideal: 15 }  
  },  
  audio: {  
    echoCancellation: true,  
    noiseSuppression: true  
  }  
};  

VP8 720p (약 2Mbps)   → 약 900MB  
VP9 480p (약 600Kbps) → 약 270MB