결론 먼저 — 1:1 음성 상담의 미디어 토폴로지 비교
| 토폴로지 | 서버 CPU | 대역폭 | 지연 | 구현 복잡도 | 1:1 상담 적합성 |
|---|---|---|---|---|---|
| P2P (Mesh) | 0 | 매우 낮음 | 최저 | 중 | NAT 통과 실패 시 대안 없음 → 운영 불안정 |
| MCU (믹싱) | 매우 높음 | 낮음 | 중-높음 | 매우 높음 | 음성 1:1엔 과잉 — 디코딩/믹싱/재인코딩 비용 낭비 |
| Dumb Pipe SFU | 낮음 | 중 | 낮음 | 낮음 | 적합 |
“패킷을 디코딩하지 않는다”는 한 줄 원칙이, 1:1 음성 상담 SFU의 거의 모든 운영 결정을 지배한다.
왜 P2P가 아니라 서버 경유인가
P2P (mesh) 토폴로지는 가장 가볍지만 1:1 상담 환경에서 두 가지 약점이 운영 차원의 risk가 된다.
- NAT 통과 실패 시 대안이 없다. Symmetric NAT 양쪽에 놓이는 경우 STUN만으로는 연결이 성립하지 않고, TURN으로 fall-through하려면 결국 서버 경유 경로가 필요하다.
- 관찰성이 단말에 갇힌다. 서버를 거치지 않으면 운영자가 통화 품질을 직접 측정·기록할 수 없고, 사후 디버깅이 거의 불가능하다.
특히 상담 도메인은 “어제 통화에서 음성이 떨렸다”는 신고가 운영자에게 들어오는 환경이다. 서버에서 RTP가 흐른 흔적(패킷 수, jitter, packet loss)을 남길 수 없다면 지원이 곧 추측이 된다. 그래서 시작점이 P2P일 수는 없었다.
왜 MCU가 아니라 SFU인가
MCU(Multipoint Control Unit)는 서버에서 모든 참여자의 미디어를 디코딩 → 믹싱 → 재인코딩한다. 회의실(N:N)에서는 단말의 다운스트림 대역폭을 줄이고 단일 출력 화면을 만들 수 있어 의미가 있지만, 1:1에서는 그 모든 비용이 낭비가 된다.
- 1:1은 어차피 한 사람이 한 사람의 오디오만 듣는다 — 믹싱할 게 없다.
- 디코딩→재인코딩 과정에서 codec 손실과 latency가 추가된다.
- 서버 CPU 비용이 SFU 대비 한 자리 수 이상 비싸다.
SFU(Selective Forwarding Unit)는 도착한 패킷을 디코딩 없이 그대로 전달한다. 서버 CPU는 라우팅 비용 정도이고, 단말의 codec 그대로 도달한다. 1:1 상담에는 정확히 SFU가 맞다.
“Dumb Pipe”란 — SFU 안에서 가장 단순한 변형
SFU에도 다양한 기능이 들어갈 수 있다. Simulcast 레이어 선택, RTCP 재작성, 비디오 키프레임 강제 요청, NACK/PLI 가공 등. “Dumb Pipe”는 그 모든 기능을 빼고 RTP 패킷을 받아 그대로 흘려보내는 단 하나의 동작만 남긴 형태다.
| 기능 | 풀 SFU | Dumb Pipe SFU |
|---|---|---|
| RTP forward | O | O |
| Simulcast layer 선택 | O | X (단일 스트림 가정) |
| RTCP 가공 | O | X (passthrough) |
| 키프레임 요청 처리 | O | 제한적 |
| 구현 라인 수 | 수천 줄 | 수십~수백 줄 |
| 장애 표면적 | 크다 | 좁다 |
1:1 음성 상담은 단일 오디오 스트림이라 simulcast가 필요 없고, 키프레임 같은 비디오 RTCP도 거의 등장하지 않는다. 풀 SFU의 기능 80%는 코드만 무거워질 뿐 실제로 사용되지 않는다. 그래서 의도적으로 Dumb Pipe로 둔다.
의사결정 기준 — 어떤 환경이면 풀 SFU로 가야 하는가
- 참여자가 3명 이상으로 늘어날 가능성이 있다 → 풀 SFU 필요 (simulcast/SVC 선택)
- 비디오가 주력이고 모바일 다운스트림 대역폭을 동적으로 맞춰야 한다 → 풀 SFU
- 녹화·트랜스코딩을 서버에서 하기로 했다 → 어차피 디코딩 필요 → MCU 또는 별도 미디어 처리 파이프라인
- 위 셋 모두 아니다 → Dumb Pipe로 시작하는 게 가장 안전하다
개인 메모 — “필요해지면 더 무겁게 만들 수 있다”
데모를 시작할 때 “혹시 나중에 N:N으로 확장될 수도 있으니 풀 SFU 기능을 미리 깔아두자”는 유혹이 컸다. 그런데 그 결정으로 추가될 코드 무게와 학습 부담을 가늠해 보니, 1:1을 제대로 굴려보기 전까지는 거의 모두 미사용 자산이 될 것 같았다.
결국 “필요해진 시점에 무거워질 수 있다”는 방향으로 정했다. 그 결정 덕분에 데모에서 다뤄야 할 미디어 단의 이슈 표면적이 좁게 유지됐고, 디버깅 순서도 connection 단계 → 단말 → 미디어 코드 식으로 자연스럽게 잡혔다. “지금 안 쓰는 기능은 지금 안 짠다”는 원칙이 SFU에는 특히 잘 맞는 결로 보인다.
답글 남기기