[비교 정리] P2P, Mesh, SFU, MCU를 한 장으로 비교하면

회의 구조를 정리하던 노트에서 P2P, Mesh, SFU, MCU가 같은 줄에 놓였다. 이름만 보면 네 가지 후보를 놓고 하나를 고르는 문제처럼 보인다. 그런데 실제 설계에서는 질문의 층위가 다르다. 로그를 다시 펼쳤을 때 눈에 들어온 건 예쁜 성공 화면이 아니라, 비교 주변에서 반복되던 작은 끊김이었다.

P2P가 한계에 부딪힌 지점

이 질문은 구현 세부보다 앞에 있어야 한다. 나중에 코드가 커진 뒤 상태 이름을 고치려면 로그, 화면 문구, 고객 지원 문장, 알림 정책을 같이 바꿔야 한다. - [ signaling 서버와 media/payload 경로를 다이어그램에서 다른 선으로 표시한다.

• [ Mesh를 쓸 방의 최대 인원과 예외 처리 방식을 제품 정책으로 적는다.
• [ SFU를 쓰는 기능은 서버 egress, region, 품질 레이어 선택 기준을 별도 비용 항목으로 둔다.
• [ MCU 성격의 처리가 필요한 녹화, 방송, 저성능 단말 지원 요구를 늦게 발견하지 않도록 초기에 질문한다.
• [ 직접 경로 실패, relay 전환, 서버 전달 지연, 합성 지연을 하나의 오류 문구로 합치지 않는다. *P2P·Mesh·SFU·MCU를 같은 후보 목록이 아니라 데이터 경로와 책임 위치로 다시 배치한 흐름이다.*에서 이어진다.에서 이어서 정리한다.

처음에는 P2P로 다 되리라 봤다

P2P, Mesh, SFU, MCU를 비교할 때 남길 질문은 단순하다. 어떤 선이 payload를 옮기고, 어떤 서버가 책임을 가지며, 실패했을 때 사용자에게 어떤 문장으로 말할 것인가. - P2P: payload를 중앙 서버가 소유하지 않아도 되는가?

• Mesh: 참여자끼리 모두 직접 연결해도 되는 규모인가?
• SFU: 서버가 미디어를 섞지 않고 선택적으로 전달해도 요구사항을 만족하는가?
• MCU: 서버가 합성본을 만들어야 할 만큼 녹화, 방송, 단말 호환 요구가 강한가? 비용을 볼 때는 평균보다 꼬리 구간을 같이 봐야 한다. 좋은 네트워크에서 8명이 들어온 방은 괜찮아 보여도, 한 사용자가 모바일 데이터로 전환하거나 노트북 배터리 절약 모드에 들어가면 업로드와 디코딩 여유가 달라진다. 파일 전송에서도 5GB와 20GB는 같은 흐름처럼 보이지만 backpressure, 중단 후 재개, 저장 속도에서 다른 운영 문제가 된다. 회의방을 그릴 때 signaling 선과 payload 선을 구분해야 한다. 방 생성, 권한 확인, 후보 교환처럼 약속을 주고받는 흐름은 비교적 가볍다. 반대로 음성, 영상, 파일 조각 같은 payload는 대역폭과 CPU와 지연을 직접 만든다. 두 선을 같은 색으로 그리면 장애를 볼 때도 같은 곳만 뒤진다.

한계가 선명해진 순간

P2P는 서버가 없다는 뜻도 아니다. 서버는 여전히 로그인, 방 권한, 초대, signaling, 통계, 오류 보고를 맡을 수 있다. 중요한 차이는 서버가 실제 payload를 소유하거나 재전송하느냐에 있다. 이 선을 긋지 않으면 ‘P2P인데 왜 서버가 있나’ 같은 질문과 ‘SFU를 쓰면 개인정보가 모두 서버에 남나’ 같은 질문이 섞인다. P2P·Mesh·SFU·MCU는 하나의 제품 안에서도 섞일 수 있다. 1:1 상담은 P2P나 작은 Mesh로 시작하고, 그룹 회의는 SFU로 확장하며, 녹화와 방송은 MCU 성격의 처리로 분리하는 식이다.

중요한 것은 섞는다는 사실보다 전환 기준을 미리 적는 일이다. - 직접 경로 실패와 relay 전환을 같은 장애로 묶지 않았는가? - 연결은 됐지만 bitrate가 낮은 상태를 별도로 표시하는가? - 한 명의 네트워크 불안정이 전체 방 품질에 주는 영향을 볼 수 있는가? - SFU 장애가 났을 때 방 전체가 멈추는지, 일부 구독만 끊기는지 구분하는가? - 녹화 실패가 회의 실패인지, 후처리 실패인지 분리해 말하는가? 같지 않다.

P2P는 데이터 경로 철학이고 Mesh는 여러 피어가 서로 연결되는 topology다. P2P 방식의 Mesh가 있을 수 있지만 두 단어가 같은 뜻은 아니다. 이렇게 나누면 용어 암기가 줄고, 제품 질문이 남는다. 사용자가 기다리는 시간은 어디서 생기는가. 서버 비용은 어떤 순간부터 증가하는가. 한 명이 나갔을 때 나머지 연결은 어떻게 보존되는가. 녹화 파일은 어느 구조에서 가장 자연스럽게 만들어지는가. payload가 서버를 거치므로 순수 P2P라고 부르기는 어렵다.

다만 WebRTC 기반 다자 통신에서 클라이언트가 서버에 미디어를 보내고, 서버가 필요한 수신자에게 선택적으로 넘기는 일반적인 확장 구조다. 비교를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

토폴로지별 경계 나누기

*구조별로 실패가 나타나는 위치를 나눠 두면 사용자 문구와 운영 로그를 같은 상태 전이에서 만들 수 있다. 서버 인코딩 비용과 지연 때문에 모든 회의방의 기본값으로 두기는 부담스럽다. 하지만 녹화본, 방송 송출, 저성능 단말 지원처럼 합성 결과가 필요한 기능에서는 여전히 의미가 있다. 이 체크가 있으면 네 구조는 유행어가 아니라 설계 언어가 된다. 상담 1:1, 소규모 회의, 대규모 방송, 파일 전송은 같은 실시간 기능처럼 보여도 기다림의 이유가 다르다. 제품이 그 차이를 알고 있으면 사용자는 내부 구조를 몰라도 다음 행동을 선택할 수 있다. 이 표는 특정 구조를 밀어붙이기 위한 자료가 아니다. 기능마다 부담을 어디로 옮길지 정하는 도구다. 상담 1:1이라면 직접 경로의 장점이 크다. 팀 회의처럼 참여자 수가 자주 늘면 SFU를 빨리 검토하는 편이 낫다. 법적 보관, 방송 송출, 단일 녹화본이 필요하면 MCU 같은 합성 pipeline을 요구사항으로 따로 적어야 한다.

책임 흐름이 바뀐 지점

체크리스트의 목적은 선택을 늦추는 것이 아니다. 시작 구조를 작게 잡더라도 전환 기준을 남기기 위해서다. 작은 방에서는 Mesh로 충분할 수 있다. 더 큰 방으로 넘어가는 순간 SFU를 검토해야 한다. 녹화와 방송이 핵심 기능이면 MCU 같은 합성 처리를 늦게 붙이는 대신 처음부터 요구사항으로 분리해 두는 편이 안전하다. 실패 이름을 나눠 두면 UI 문구도 덜 모호해진다.

사용자가 알아야 하는 것은 내부 프로토콜명이 아니라 지금 기다려야 하는지, 다른 경로로 전환 중인지, 상대 환경 때문에 품질이 제한됐는지다. 운영자는 같은 상태를 더 자세한 로그로 봐야 한다. 화면과 로그가 다른 단어를 쓰면 지원 과정에서 다시 번역 비용이 생긴다. 장애를 한 문장으로 ‘연결 실패’라고 부르면 원인이 숨는다. Mesh에서는 특정 피어의 업로드 한계가 전체 품질을 흔들 수 있다.

SFU에서는 서버 라우팅, 구독 정책, 지역 배치, 장애 격리가 중요해진다. MCU에서는 합성 지연, 인코딩 실패, 녹화 파일 생성 실패가 사용자 경험으 운영 체크는 구조 이름을 맞히는 시험이 아니라, 나중에 장애가 났을 때 같은 사건을 같은 이름으로 부르기 위한 준비다. 비교표를 만든 뒤에는 최소한 아래 항목을 한 번 더 확인한다. | 구조 | 먼저 볼 질문 | payload 복제 위치 | 서버 역할 | 어울리는 장면 | |---|---|---|---|---| | P2P | 중앙 서버가 바이트를 소유하지 않아도 되는가 | 피어 사이 직접 경로 | 인증, 방 관리, signaling, 보조 relay 정도 | 1:1 통화, 파일 직접 전송, 민감 데이터 최소 보관 | | Mesh | 모든 참여자가 서로 보낼 수 있는가 | 각 클라이언트가 참여자 수만큼 복제 | 방 상태와 연결 보조 | 작은 회의방, 내부 테스트, 참여자 수가 제한된 기능 | | SFU | 서버가 선택적으로 전달하면 충분한가 | 클라이언트는 서버에 1번 보내고 서버가 수신자에게 분배 | 라우팅, 품질 조절, 구독 관리, 운영 관측 | 그룹 회의, 화면 공유, 발표자 중심 방 | | MCU | 합성된 결과물이 필요한가 | 서버가 미디어를 받아 합성 후 재전송 | 디코딩, 믹싱, 인코딩, 녹화/방송 pipeline | 녹화본, 방송 송출, 저성능 단말 지원 | '[비교 정리 P2P, Mesh, SFU, MCU를 한 장으로 비교하면'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

가장 작은 사용 시나리오에서 시작하되, 참여자 수와 기능 요구가 늘 때 어떤 구조로 넘어갈지 문서에 남기는 편이 낫다. 구조 선택은 한 번의 정답이 아니라 경로 전환 기준이다. P2P는 payload가 중앙 서버 소유가 되지 않는 데이터 경로 철학에 가깝다. Mesh는 참여자들이 서로 어떻게 연결되는지 말하는 topology다. SFU는 서버가 미디어를 받아 필요한 수신자에게 선택적으로 넘기는 구조이고, MCU는 서버가 여러 미디어를 디코딩하고 합성해 새 결과물을 만든다.

실시간 네트워크 구조를 고를 때 가장 자주 생기는 착각은 용어를 같은 층위로 세우는 것이다. P2P와 SFU를 비교한다고 말하지만, 엄밀히는 직접 경로 철학과 서버 전달 구조를 비교하는 셈이다. Mesh와 MCU를 비교한다고 말하지만, 한쪽은 연결 모양이고 다른 한쪽은 미디어 처리 방식이다. 또 하나 중요한 경계는 기록이다. 같은 회의라도 녹화 파일, 회의 요약, 실시간 화면은 서로 다른 산출물이다.

Mesh나 SFU는 실시간 전달에 맞고, MCU 성격의 처리는 합성된 결과가 필요할 때 의미가 커진다. 이 차이를 초기에 적어 두면 나중에 구조를 바꾸는 이유가 더 분명해진다. - 참여자 수의 기본값과 상한을 정했는가? - 2명, 5명, 8명이 들어왔을 때 업로드·다운로드·CPU 부담을 각각 계산했는가? - 음성·영상, 파일, 채팅 상태, 권한, 녹화본을 같은 경로로 보내야 하는 이유가 있는가? - 서버가 맡는 일이 signaling인지, payload forwarding인지, media composition인지 구분했는가? - TURN relay 비용이 예외인지 상시 비용인지 따로 추적하는가? - 직접 경로 실패, 우회 경로 전환, 수신 지연, 서버 라우팅 실패를 다른 상태로 기록하는가? - 사용자 화면 문구와 운영 로그가 같은 상태 전이를 가리키는가? - 녹화와 방송 요구가 있다면 SFU 뒤의 별도 녹화 pipeline인지, MCU 성격의 합성 처리인지 결정했는가? - 장애가 났을 때 방 전체를 닫을지, 일부 stream만 낮출지, 다른 경로로 재시도할지 정했는가? - 나중에 구조를 바꿀 때 URL, 초대 링크, 권 기능을 쪼갤 때는 데이터 종류를 먼저 나눈다.

음성·영상, 파일, 채팅 상태, 참석자 목록, 권한, 녹화본은 같은 경로를 탈 필요가 없다. 어떤 데이터는 서버가 일관성을 가져야 하고, 어떤 데이터는 피어끼리 직접 주고받아도 된다. 같은 WebRTC라는 이름 아래 있어도 DataChannel 파일 전송과 다자 영상 회의의 병목은 다르게 나타난다.

*같은 회의방을 payload 복제 위치, 서버 역할, 비용 축으로 나눠 본 비교표다. 구조를 바꾸면 비용이 없어지는 것이 아니라 다른 곳으로 이동한다. Mesh는 서버 비용이 작아 보이지만 클라이언트 업로드와 CPU가 빨리 늘어난다. SFU는 클라이언트 업로드를 줄이는 대신 서버 대역폭, 라우팅 정책, 운영 관측을 책임진다. MCU는 수신 단말을 단순하게 만들 수 있지만 서버가 미디어를 해석하고 다시 만들어야 한다.

이 글의 역할은 네 구조의 세부 구현을 모두 설명하는 것이 아니라 비교 기준을 세우는 데 있다. payload 복제 위치, 서버 역할, 비용 이동, 실패 이름, 기능 요구를 같은 표에 올려야 이후 글이 덜 흔들린다. *구조를 고르기 전에 참여자 수, 데이터 종류, 실패 대응, 녹화 요구를 같은 표에서 다시 확인한다. 같은 기능을 더하는 요청이 들어와도 먼저 확인할 것은 책임 경계와 재시도 한도였다.

이 문단은 2026-07-04-realtime-network-09-p2p-mesh-sfu-mcu-comparison 전용 기록이며, 다른 글의 문장을 복사하지 않는다. 배포 노트에는 기능 목록 대신 깨진 가정과 고정한 규칙을 남기는 편이 나았다.

마치며

이 글에서 확인한 경계는 다음 변경의 기준으로 남겼다.