WebRTC 첫걸음 — 왜 UDP인가, P2P는 왜 무너지나, 그리고 SFU라는 우체국

"화상회의에 10명 들어가면 왜 서버가 필요한가요? 브라우저끼리 직접 연결하면 서버 비용도 안 들고 좋은 거 아닌가요?" 프리세일즈 미팅에서 자주 받는 질문입니다. 그리고 이 질문에 제대로 답하려면 세 가지를 순서대로 설명해야 합니다 — 왜 실시간 미디어는 UDP여야 하는지, 왜 P2P는 인원이 늘면 무너지는지, 그리고 SFU라는 중간 서버가 정확히 무슨 일을 하는지.

이 글은 WebRTC를 처음 접하는 분(비개발 직군 포함)도 따라올 수 있게, 네트워크 관점과 실제 사용 관점을 오가며 이 세 가지를 예제와 다이어그램으로 풀어냅니다. 덤으로 고객 미팅에서 반드시 나오는 두 가지 심화 질문 — "인코딩·디코딩은 어디서 하나요?" 와 "1:1 통화도 SFU를 거치나요?" — 까지 논리적으로 정리합니다. (아키텍처 4종 비교는 #51, SFU가 100명·1000명을 감당하는 방법은 #48에서 더 깊이 다룹니다.)

0. 핵심 명제 — SFU는 "미디어를 만지는 서버"가 아니라 "미디어를 배달하는 우체국"이다

WebRTC는 브라우저가 UDP로 미디어를 내보낼 수 있는 사실상 유일한 통로다. P2P는 1:1에선 완벽하지만 참가자가 늘면 각자의 업로드 회선이 먼저 무너진다. SFU는 이 문제를 "각자 1번만 업로드하면, 서버가 대신 뿌려주는" 구조로 푼다. 이때 SFU는 영상을 열어보지 않는다 — 인코딩과 디코딩은 여전히 각자의 기기(device)에서 일어나고, 서버는 압축된 패킷을 그대로 전달(forward)만 한다. 이 분업이 SFU의 낮은 지연·낮은 서버 비용의 비밀이자, MCU와의 결정적 차이다.

먼저 흔한 오해부터 정정하고 시작합니다:

1. 왜 WebRTC인가 — 브라우저에서 UDP를 쓰는 유일한 문

웹은 원래 전부 TCP다

브라우저가 하는 일 대부분 — 웹페이지 로딩(HTTP), 파일 다운로드, 유튜브 시청(HLS) — 은 TCP 위에서 돌아갑니다. TCP는 "보낸 데이터가 순서대로, 빠짐없이 도착하는 것"을 보장하는 프로토콜입니다. 파일 다운로드라면 완벽한 선택이죠. 1바이트라도 깨지면 파일이 열리지 않으니까요.

그런데 이 "보장"에는 비용이 있습니다. 패킷 하나가 유실되면 TCP는 그 패킷이 재전송되어 도착할 때까지 뒤에 온 패킷을 전부 대기실에 세워둡니다. 순서를 보장해야 하니까요. 이걸 Head-of-Line Blocking(HOL 블로킹) 이라고 합니다.

TCP의 세계 — 패킷 #2 하나가 유실되면:

 보낸 순서:  [#1] [#2] [#3] [#4] [#5]
                   ✗ 유실
 받는 쪽:   [#1] ....... 대기 ....... 
                  │
                  │ #2 재전송 요청 → 왕복 시간(RTT)만큼 기다림
                  ▼
            [#1] [#2] [#3] [#4] [#5]   ← #3~#5는 이미 도착해 있었는데
                                          #2 때문에 전부 묶여 있었음

택배로 비유하면: 3권짜리 전집을 주문했는데 2권이 배송 중 분실됐다고 이미 도착한 3권을 경비실이 안 내주는 상황입니다. 소설책이라면 순서대로 읽어야 하니 합리적이지만…

실시간 미디어는 다르다 — "늦은 프레임은 죽은 프레임"

화상회의에서 0.2초 전 영상 프레임 하나가 유실됐다고 칩시다. 그 프레임을 재전송받으면 이미 0.5초가 지나 있습니다. 그 프레임은 이제 아무 쓸모가 없습니다. 대화는 계속 흘러가고 있으니까요. 재전송을 기다리느라 화면 전체가 0.5초 멈추는 것(TCP)보다, 그 프레임을 그냥 버리고 다음 프레임을 보여주는 것(UDP)이 압도적으로 낫습니다.

문제는 브라우저가 웹 개발자에게 UDP 소켓을 직접 열어주지 않는다는 겁니다. 보안상 아무 사이트나 UDP 패킷을 마구 쏘게 둘 수 없으니까요. 그래서 브라우저 안에 "안전장치(암호화 필수, 상대방 동의 기반 연결)를 갖춘 UDP 통로"를 표준으로 박아 넣은 것이 WebRTC입니다. 앱 설치 없이, 브라우저만으로 UDP 실시간 미디어를 주고받을 수 있는 사실상 유일한 방법입니다.

💡 프리세일즈 포인트: 고객이 "그냥 WebSocket으로 영상 보내면 안 되나요?"라고 물으면 — WebSocket은 TCP라서 HOL 블로킹을 그대로 상속받습니다. 네트워크가 좋을 땐 티가 안 나지만, 유실률 1~2%의 모바일 환경에서 화면이 주기적으로 얼어붙습니다. "잘 되는 데모"와 "출시 가능한 품질"의 차이가 여기서 갈립니다.

2. P2P의 세계 — 아름답게 시작해서 수학적으로 무너진다

1:1 — P2P가 완벽한 순간

WebRTC의 출발점은 브라우저끼리 직접(Peer-to-Peer) 연결하는 것입니다. 중간 서버 없이 내 브라우저에서 상대 브라우저로 미디어가 바로 갑니다.

      A ◀━━━━━━ 미디어 (UDP) ━━━━━━▶ B

  · 최단 경로 = 최저 지연
  · 서버 미디어 비용 = 0원
  · 1:1 에서는 이보다 좋을 수 없음

n명 — 업로드 회선이 먼저 죽는다

그런데 3명, 5명, 8명이 되면? P2P 구조(풀 메시, full mesh)에서는 각자가 나머지 전원에게 자기 영상을 따로따로 업로드해야 합니다.

        4명 회의의 P2P (Mesh):

         A ◀━━━━▶ B          각 참가자:
         ▲ ╲    ╱ ▲           · 업로드 3줄기 (n-1)
         ┃  ╲  ╱  ┃           · 다운로드 3줄기 (n-1)
         ┃   ╲╱   ┃           · 연결 관리 3개
         ┃   ╱╲   ┃
         ▼  ╱  ╲  ▼          전체 연결 수: n(n-1)/2 = 6개
         C ◀━━━━▶ D

숫자를 넣어보면 문제가 선명해집니다. 720p 영상 한 줄기를 1.5Mbps라고 하면:

포인트는 두 가지입니다:

1. 인터넷 회선은 업로드가 다운로드보다 훨씬 좁습니다. 100Mbps 요금제라도 업로드는 그 몇 분의 일인 경우가 많습니다. P2P는 이 좁은 쪽을 (n-1)배로 쓰는 구조입니다.
2. 같은 영상을 (n-1)번 인코딩하거나, 같은 인코딩 결과를 (n-1)번 밀어내야 합니다. 노트북 팬이 돌고, 스마트폰이 뜨거워지고, 배터리가 녹는 게 이 지점입니다. (모바일 발열의 구조적 원인은 #46 참고)

그래서 P2P Mesh의 실무 상한은 보통 4~6명으로 봅니다. "우리 서비스는 최대 몇 명까지 들어가나요?"라는 고객 질문에 P2P 기반이라면 이 숫자 이상을 약속할 수 없습니다.

3. SFU — "각자 1번만 올려, 배달은 내가 할게"

우체국 모델

SFU(Selective Forwarding Unit) 는 이 문제를 구조로 풉니다. 중앙에 미디어 라우팅 허브(서버)를 두고:

• 각 참가자는 자기 영상을 SFU에 딱 1번만 업로드
• SFU가 "이 스트림을 지금 누가 봐야 하지?"를 판단해서 선택적으로(Selective) 전달(Forwarding)

        4명 회의의 SFU:

         A ━━1줄기━━▶ ┌─────────┐ ━━━▶ B (A,C,D의 영상 수신)
         B ━━1줄기━━▶ │   SFU   │ ━━━▶ A (B,C,D의 영상 수신)
         C ━━1줄기━━▶ │ (서버)  │ ━━━▶ C (A,B,D의 영상 수신)
         D ━━1줄기━━▶ └─────────┘ ━━━▶ D (A,B,C의 영상 수신)

  각 참가자: 업로드 1줄기 고정 (인원과 무관!)
  다운로드: 보는 사람 수만큼 (이건 SFU가 화질 조절로 관리)

같은 표를 SFU로 다시 계산하면:

업로드가 인원수와 무관하게 상수가 됩니다. 이게 SFU가 현대 화상회의(Zoom, Meet, Teams 모두 이 계열)의 표준 구조가 된 이유입니다.

"Selective"가 핵심 — 그냥 중계기가 아니다

SFU의 S(선택적)는 장식이 아닙니다. 25명 회의에서 내 화면에 보이는 건 크게 잡아도 9칸입니다. SFU는:

• 화면에 보이는 사람의 영상만 골라 보냅니다 (안 보이는 16명의 영상은 아예 전달 안 함)
• 발화자는 고화질, 썸네일은 저화질로 — 송신자가 여러 화질을 동시에 올리는 Simulcast를 이용해 수신자 사정에 맞는 층(layer)만 골라 보냅니다
• 수신자 네트워크가 나빠지면 그 사람에게만 화질을 낮춥니다 (다른 참가자는 영향 없음)

즉 SFU는 "복사해서 뿌리는 기계"가 아니라 참가자별 맞춤 배달 정책을 실행하는 라우터입니다.

SFU vs MCU — 열어보느냐, 그대로 배달하느냐

SFU와 자주 비교되는 것이 MCU(Multipoint Control Unit) 입니다. MCU는 모든 참가자의 영상을 서버에서 디코딩 → 한 화면으로 합성 → 다시 인코딩해서 완성된 영상 1줄기를 내려보냅니다.

  SFU: 포장 그대로 배달                MCU: 열어서 재포장

  A ━▶ ┌─────┐ ━▶ (A,B,C 각각)       A ━▶ ┌──────────┐
  B ━▶ │ SFU │      압축된 채로       B ━▶ │   MCU    │ ━▶ 합성된
  C ━▶ └─────┘      그대로 전달       C ━▶ │ 디코딩   │    영상 1줄기
                                           │ 합성     │
       서버 CPU: 거의 안 씀                │ 재인코딩 │  서버 CPU: 매우 비쌈
       지연 추가: 수 ms                    └──────────┘  지연 추가: 수백 ms

현대 서비스의 기본값은 SFU이고, MCU는 "구형 회의실 장비 연동", "전화망 연결", "방송 송출용 합성" 같은 특수 구간에 부분적으로 씁니다. (4종 아키텍처 선택 기준은 #51에서 상세히)

4. 그래서 인코딩·디코딩은 어디서 하나요 — Device인가 Server인가

고객 미팅에서 정말 자주 나오는 질문이고, 답은 아키텍처마다 다릅니다. 결론부터 표로:

SFU 세계의 분업 — 무거운 일은 전부 기기에서

SFU 구조에서 한 프레임의 여정을 따라가 보면:

 [송신자 기기]                [SFU 서버]              [수신자 기기]
                                
 카메라 캡처                                          
   ↓                                                  
 인코딩 ◀━ 하드웨어 코덱      패킷 헤더만 보고          
 (H.264/VP8/AV1)             누구에게 보낼지 결정      
   ↓                          (영상 내용은 안 봄)      
 암호화(SRTP)                    ↓                    
   ↓                          구간별 재암호화 후        복호화
 UDP 송신 ━━━━━━━━━━━▶       전달(forward) ━━━━━━▶     ↓
                                                     디코딩 ◀━ 하드웨어 코덱
                                                       ↓
                                                     화면 렌더링

• 인코딩은 송신자 기기에서 1회. 요즘 스마트폰·노트북엔 H.264/HEVC 하드웨어 인코더 칩이 있어서 CPU를 거의 안 쓰고 처리합니다. Simulcast를 쓰면 고/중/저화질 23벌을 동시에 인코딩하는데, 이것도 기기 몫입니다 (업로드 대역폭 +2030% 정도의 비용).
• SFU는 디코딩하지 않습니다. 패킷의 겉면(RTP 헤더 — 어느 스트림인지, 어느 화질 층인지)만 읽고 라우팅합니다. 택배 기사가 상자를 열지 않고 송장만 보고 배달하는 것과 같습니다. 그래서 서버 1대가 수천 스트림을 감당할 수 있고, 통과 지연이 밀리초 단위입니다.
• 디코딩은 수신자 기기에서, 받는 스트림 수만큼. 9분할 화면이면 9개 스트림을 동시에 디코딩합니다. 이게 수신 측 부담의 정체이고, SFU가 Selective하게 저화질 층을 골라주는 이유입니다.

💡 프리세일즈 포인트: "서버 사양을 얼마나 준비해야 하나요?"라는 질문에 — SFU는 CPU보다 네트워크 대역폭(특히 egress) 이 병목입니다. 반대로 MCU를 섞는 순간 서버 GPU/CPU 견적이 뛰기 시작합니다. 견적서의 구조가 아키텍처 선택에서 결정됩니다.

한 가지 정확히 해둘 점: SFU도 암호화는 구간별로 다시 합니다(A→SFU 구간, SFU→B 구간이 별도의 SRTP 세션). "서버가 기술적으로는 미디어에 접근 가능한 위치에 있다"는 뜻이라, 금융·의료 고객이 종단간 암호화(E2EE)를 요구하면 Insertable Streams 같은 별도 계층을 얹어야 합니다. 컴플라이언스 질문이 나오면 이 구분(전송 암호화 vs E2EE)을 짚어주는 것이 신뢰를 얻습니다.

5. 전통 SFU의 골칫거리들 — "서버를 어디에 둘 것인가"라는 저주

SFU가 만능이라면 이야기가 끝났겠지만, 전통적인 SFU 운영에는 구조적인 고민이 따라옵니다. 최근 Cloudflare 같은 사업자들이 차별화 포인트로 공격하는 지점이 바로 여기입니다.

① 방 배정 문제 — 첫 입장자의 저주

전통 SFU는 "방(room) 하나 = SFU 서버 1대"로 묶는 경우가 많습니다. 그럼 그 서버를 어느 리전에 둘까요? 흔한 방식이 "방을 만든 첫 사용자와 가까운 리전"인데:

  서울에 사는 A가 방 개설 → 방이 서울 SFU에 배정
  그런데 참가자 B,C,D,E가 전부 상파울루에서 접속하면?

  B(브라질) ━━ 지구 반대편 ━━▶ [서울 SFU] ━━ 지구 반대편 ━━▶ C(브라질)
  
  같은 도시의 B와 C가 대화하는데
  미디어는 서울을 왕복 (RTT +250~300ms)

첫 입장자 위치라는 우연이 회의 전체의 품질을 결정해버립니다. 해법은 참가자를 각자 가까운 SFU에 붙이고 SFU끼리 잇는 Cascading(#48)이나, 아예 "특정 서버에 방을 고정하지 않는" Anycast 설계인데, 어느 쪽이든 직접 구축 난이도가 급격히 올라갑니다.

② Egress 비용 — SFU 경제학의 본체

SFU는 1줄기를 받아 (보는 사람 수)줄기로 내보냅니다. 즉 트래픽이 서버에서 증폭됩니다. 10명 회의, 각자 1.5Mbps, 1시간이면:

• 수신(ingress): 10 × 1.5Mbps ≈ 6.75GB/시간 — 대개 무료
• 송신(egress): 10명이 각자 나머지 9명 영상 수신 ≈ 60GB/시간 — 클라우드가 과금하는 것이 바로 이것

일반 클라우드 VM에서 egress 단가로 이 트래픽을 감당하면 회의 비용이 무섭게 쌓입니다. CPaaS 벤더들이 자체 백본/전용망(#43의 SD-RTN 같은)을 깔거나, Cloudflare가 "이미 전 세계에 깔린 우리 네트워크에선 egress 걱정을 지우겠다"고 마케팅하는 배경이 전부 이 경제학입니다.

③ 그 외 반복되는 고민들

💡 프리세일즈 포인트: "직접 구축(오픈소스 SFU) vs CPaaS" 논쟁의 실체가 이 표입니다. mediasoup/LiveKit로 SFU 1대 띄우는 건 하루면 됩니다. 비싼 것은 글로벌 배치, Cascading, egress 최적화, 피크 스케일링의 운영이고, CPaaS 요금은 그 운영의 외주 비용입니다.

6. 1:1 전화도 SFU를 쓰나요 — "사용자가 많으면"의 진짜 의미

마지막으로, 논리적으로 헷갈리기 쉬운 질문입니다. "SFU는 다인원용이라면서요. 그럼 1:1 통화는 P2P로 하면 되는 것 아닌가요? 그런데 왜 대형 서비스들은 1:1도 서버를 거친다고 하죠?"

혼동의 원인은 "사용자가 많다"의 두 가지 의미를 섞어 쓰기 때문입니다:

• 방 안의 참가자 수가 많다 → 이건 §2~3의 이야기. 방에 사람이 많으면 SFU가 필수.
• 서비스 전체의 동시 통화 수가 많다 → 1:1 통화 100만 건을 운영하는 문제. 여기서도 SFU(서버 경유)를 택하는 이유가 따로 있습니다.

1:1인데도 서버를 거치는 이유를 하나씩 쌓아보면:

첫째, 어차피 일부는 P2P가 안 됩니다. P2P는 두 기기가 서로의 공인 IP:포트를 알아내 직접 연결(NAT 통과)해야 하는데, 회사 방화벽·통신사 Symmetric NAT 환경에서는 실패합니다. 실무에서 통화의 약 10~20%는 직접 연결이 불가능해서 TURN이라는 중계 서버를 거쳐야 합니다. 즉 "서버 없는 아키텍처"는 애초에 성립하지 않고, 최소한 일부 트래픽용 중계 인프라는 무조건 필요합니다.

둘째, 두 갈래 코드 경로는 운영의 적입니다. "80%는 P2P, 20%는 TURN 경유"로 가면 통화마다 품질 특성이 다르고, 장애 재현이 어렵고, 품질 데이터의 절반이 서버에 안 남습니다. 100만 통화를 운영하는 입장에선 모든 통화가 같은 경로를 지나는 것 자체가 가치입니다 — 모니터링, 품질 통계, 이슈 재현이 한 벌로 끝나니까요.

셋째, 서버 경유가 필요한 기능들이 있습니다.

• 녹취/컴플라이언스: 금융권 상담 통화 녹음은 미디어가 서버를 지나야 가능
• 1:1 → 그룹 확장: 통화 중 3번째 참가자 초대 시, P2P였다면 SFU로 갈아타는 재협상(수 초 끊김)이 필요. 처음부터 SFU면 무중단
• 프라이버시: P2P는 상대방에게 내 IP가 노출됨. 데이팅/커머스 앱에선 그 자체가 리스크
• 경로 품질 제어: 공인 인터넷의 혼잡 구간 대신 사업자 백본으로 라우팅 → 국제 통화에서 P2P보다 서버 경유가 오히려 안정적인 경우가 많음

넷째, 그럼에도 비용 때문에 P2P를 고수하는 진영도 있습니다. 1:1을 P2P로 처리하면 그 통화의 미디어 서버 비용이 0이니까요. 소비자용 무료 메신저 통화(대표적으로 WhatsApp 계열)가 1:1은 P2P 우선, 그룹만 서버 경유로 설계해온 이유입니다.

정리하면:

💡 프리세일즈 포인트: "1:1인데 왜 분당 과금이 붙나요? P2P면 공짜 아닌가요?"라는 질문에 대한 답이 이 표입니다. 과금은 단순 중계비가 아니라 NAT 통과 실패분의 처리 + 균일한 품질 경로 + 녹취·모니터링·확장성이 포함된 값입니다.

7. 한 장 요약 — 고객 질문 → 답변 치트시트

WebRTC 이야기의 뼈대는 결국 하나입니다 — 실시간성은 "완벽한 전달"을 포기하는 대신(UDP), "누가 무엇을 받을지"를 똑똑하게 관리하는 것(SFU)으로 완성된다. 이 문장 하나를 고객의 언어로 풀어내는 것이 프리세일즈에서 이 기술을 설명하는 일의 전부라고 생각합니다.

함께 보면 좋은 글

• #51 WebRTC 아키텍처 가이드 — Mesh, SFU, MCU, Hybrid를 어떻게 고를까
• #48 SFU는 어떻게 100명·1000명을 감당하나 — 단일 노드 한계와 Cascading
• #43 Agora 자체 코덱과 Web SDK의 정체 — WebRTC 표준, SD-RTN 전용망, FEC의 분업
• #46 모바일 영상 파이프라인의 발열 — 메모리 복사, GPU Texture, Zero-Copy, 하드웨어 코덱