SFU는 왜 Mesh보다 큰 방에 강할까

SFU가 Mesh보다 확장에 강하다는 말은 맞다. 다만 이유를 “서버를 쓰니까”로 외우면 핵심이 빠진다. 같은 입력인데 어떤 환경에서만 SFU가 도드라졌다. 그래서 용어 사전 대신, 그 날 무엇을 보고 무엇을 바꿨는지부터 적는다.

Mesh가 버거워진 지점

*SFU의 실패는 서버 하나로 단순화되지 않는다. 업로드, 서버 전달, 지역, 품질 선택을 나눠서 봐야 한다. | 구조 | 업로드 책임 | 좋아지는 점 | 새로 생기는 책임 | | --- | --- | --- | --- | | Mesh | 각 참여자가 상대마다 복제 | 서버 미디어 비용이 작고 1:1이 단순하다 | 방이 커질수록 클라이언트 업로드와 CPU가 무거워진다 | | SFU | 서버가 수신자별로 복제 | 참여자 업로드 부담을 낮추고 품질 정책을 중앙에서 다룬다 | 서버 egress, region, 장애 격리, 관측 비용이 생긴다 | 반대로 1:1 통화나 아주 작은 방에서는 Mesh가 더 나을 수도 있다. 서버 비용을 거의 쓰지 않고, 경로도 단순하다. 그래서 기준은 “SFU냐 Mesh냐”가 아니라 다음 질문이어야 한다. SFU는 이 책임을 바꾼다. 사용자는 서버에 한 번 보내고, 서버가 수신자들에게 나눠 보낸다. 책임이 사라지는 것은 아니다. 클라이언트의 업로드 부담은 줄고, 서버의 egress, region, 관측, 장애 대응 부담이 커진다.

처음에는 Mesh면 충분할 줄 알았다

SFU 그림에서는 각 참여자의 업로드 선이 서버로 모이고, 서버에서 다시 퍼진다. 중앙에 선이 모이면 서버가 병목이 될 수 있지만, 대신 정책을 걸 수 있는 지점도 생긴다. 누가 어떤 품질을 받을지, 화면 공유는 별도 정책으로 다룰지, 약한 네트워크의 참여자에게 낮은 레이어를 줄지 같은 판단이 가능해진다. 다만 SFU에서도 정책이 필요하다. 약한 네트워크의 한 사람 때문에 전체 화면 공유 품질을 낮출 것인지, 그 사람에게만 낮은 레이어를 줄 것인지 정해야 한다. 화면 공유는 프레임보다 해상도가 중요한 순간이 많다. 카메라 영상과 같은 규칙으로 다루면 안 된다. - 몇 명부터 업로드 fan-out이 문제가 되는가?

• 화면 공유가 있는가?
• 모바일/회사망/해외 사용자가 섞이는가?
• 서버 egress 비용을 감당할 수 있는가?
• 장애가 났을 때 방 전체가 영향을 받아도 되는가? 차이는 서버 유무가 아니라 누가 미디어를 복제하느냐에 있다. Mesh에서는 각 참여자가 다른 참여자에게 직접 스트림을 보낸다. 방이 8명이라면 한 사람은 나머지 7명에게 자기 영상을 보내야 한다. 다운로드가 충분해도 업로드가 약하면 통화 품질은 흔들린다.

SFU가 유리해진 순간

PonsLink가 상담이나 협업 세션을 그룹으로 넓힌다면 어느 시점부터 사용자 uplink에 모든 부담을 맡기지 않을지 정해야 한다. PonsWarp도 파일 전송 서비스라 SFU와 직접 같지는 않지만, 질문은 비슷하다. payload를 누가 운반하고, 실패를 누가 설명할 것인가. 그 경계를 정하는 순간부터 제품 설계는 네트워크 구조가 아니라 운영 구조가 된다. SFU는 Mesh보다 항상 좋은 답이 아니다.

참여자가 늘 때 업로드 fan-out을 줄이는 강한 선택지다. 서버가 미디어를 복제하므로 수신자별 품질 선택과 장애 관측을 넣기 쉽다. 대신 서버 egress, region, 장애 격리, 미디어 서버 운영 비용을 감수해야 한다. 특히 SFU에서는 재현 조건을 같이 적어야 의미가 있었다. *비교표를 만들 때는 “누가 바이트를 복제하는가”, “누가 비용을 낸다고 보는가”, “실패가 어디서 보이는가”를 함께 적어야 한다.

**어떤 책임을 사용자에서 서버로 옮기고, 그 대가를 어떻게 관측하고 설명할 것인가를 정하는 일이다. 특히 노트북은 와이파이에 붙어 있고, 한 명은 모바일 핫스팟을 쓰고, 다른 한 명은 회사 VPN을 켠 상태라면 평균 대역폭보다 약한 uplink가 전체 경험을 끌어내린다. 이때 SFU는 약한 사용자의 업로드 부담을 줄이는 선택지가 된다. Mesh에서는 한 참여자의 uplink가 약하면 그 사람이 보내는 모든 상대에게 영향이 간다.

NAT나 방화벽 때문에 직접 연결이 안 되면 TURN relay가 필요하고, 그때 비용은 relay 서버로 돌아온다. 특히 SFU에서는 재현 조건을 같이 적어야 의미가 있었다. SFU를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

큰 방에서 경계 다시 그리기

좋은 출발점은 작은 실험이다. 내부 플래그로 3명 이상 방을 SFU로 보내고, 1:1은 Mesh로 둔다. 그 상태에서 연결 시간, 사용자 취소율, 서버 비용, relay 비율을 비교한다. 문서로만 보던 차이가 숫자로 잡히면 제품 기준을 세우기 쉽다. SFU에서는 참여자가 서버까지는 잘 보내도, 서버가 특정 region에만 있으면 먼 사용자의 지연이 커진다. 서버 egress가 폭증하면 비용 문제가 먼저 오고, 단일 region 장애가 생기면 방 전체가 영향을 받을 수 있다. 클라이언트 부담을 서버로 옮긴 만큼 서버 운영을 대충 할 수 없다. 단, “몇 명부터 SFU인가”를 고정 숫자로만 보면 안 된다. 4명이라도 짧은 카메라 통화라면 Mesh가 버틸 수 있다. 3명이라도 고해상도 화면 공유, 모바일망, 녹화가 함께 있으면 중앙 경로가 더 안전할 수 있다.에서 SFU의 기본 동작을 봤다면, 여기서는 그 동작이 왜 확장성으로 이어지는지 확인한 셈이다.

구현과 운영에 남긴 조건

이렇게 나눠야 “통화가 느렸다”는 문의를 서버 문제, 업로드 문제, region 문제, 품질 선택 문제로 다시 볼 수 있다. 그래서 SFU를 도입한다는 것은 미디어 payload를 운영한다는 뜻이다. 확장성은 좋아질 수 있지만 서버 비용, 지역 지연, 장애 범위도 같이 설계해야 한다. Mesh 그림에서는 참여자가 늘 때마다 선이 서로 엉킨다. 선 하나하나가 실제 미디어 payload를 담고 있으니, 그림이 복잡해지는 만큼 브라우저가 할 일도 늘어난다.

여기서 조심할 점은 SFU를 마법 상자처럼 보지 않는 것이다. Signaling 서버는 약속, 권한, ICE 후보를 주고받게 도와줄 뿐이고 미디어 바이트를 계속 들고 있지 않는다. SFU는 참여자의 미디어를 받아서 선택적으로 전달한다. 카메라 영상은 조금 흐려져도 대화가 이어질 수 있다. 하지만 화면 공유에서 글자가 뭉개지면 기능 자체가 실패한다. Mesh에서는 발표자가 모든 사람에게 고해상도 화면을 보내느라 uplink가 버거울 수 있다.

SFU에서는 발표자가 한 번 올리고 서버가 나눠 줄 수 있어 유리하다. 'SFU는 왜 Mesh보다 큰 방에 강할까'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

아직 열어 둔 비용

8명 회의를 예로 들면 Mesh에서는 각 사용자가 7개 방향으로 업로드한다. SFU에서는 보통 한 번, simulcast를 쓰면 품질 레이어 몇 개를 서버로 올린다. 수신 쪽에서는 여전히 여러 스트림을 받을 수 있지만, 업로드 한계가 먼저 터지는 환경에서는 차이가 크다. Mesh와 SFU를 비교할 때는 연결 개수보다 업로드 책임이 어디에 놓이는지 먼저 보는 편이 이해가 빠르다. 1. 방 크기별 Mesh/SFU 경계를 정한다. 2. egress 비용을 미리 계산한다. 3. region과 latency 목표를 정한다. 4. 화면 공유와 카메라 영상을 다른 정책으로 다룬다. 운영 로그도 이 구조를 따라가야 한다. 사용자에게 SFU egress saturation 같은 말을 보여줄 수는 없다. 대신 “상대방 네트워크에 맞춰 화질을 낮추는 중”, “가까운 미디어 서버로 다시 연결하는 중”, “화면 공유 품질을 조정하는 중”처럼 행동 가능한 문장이 필요하다. 그래서 SFU 확장성을 이해한다는 것은 “서버를 쓰면 확장된다”가 아니다. 이 표에서 중요한 것은 “SFU가 더 현대적이다”가 아니다. 어떤 책임을 사용자 기기에서 서버로 옮길 것인가다.

마치며

마지막 점검은 기술 이름보다 운영 기준에 가깝다. 경계, 비용, 지역, 화면 공유 정책을 먼저 적어 둔다. SFU의 실패는 서버 하나로 단순화되지 않는다. 업로드, 서버 전달, 지역, 품질 선택을 나눠서 봐야 한다.

| 구조 | 업로드 책임 | 좋아지는 점 | 새로 생기는 책임 | | --- | --- | --- | --- | | Mesh | 각 참여자가 상대마다 복제 | 서버 미디어 비용이 작고 1:1이 단순하다 | 방이 커질수록 클라이언트 업로드와 CPU가 무거워진다 | | SFU | 서버가 수신자별로 복제 | 참여자 업로드 부담을 낮추고 품질 정책을 중앙에서 다룬다 | 서버 egress, region, 장애 격리, 관측 비용이 생긴다 |

반대로 1:1 통화나 아주 작은 방에서는 Mesh가 더 나을 수도 있다. 서버 비용을 거의 쓰지 않고, 경로도 단순하다. 그래서 기준은 “SFU냐 Mesh냐”가 아니라 다음 질문이어야 한다. 특히 realtime-network-11-why-sfu-scales-better-than-mesh가 관여하는 경로에서는 '일단 동작'보다 '중단 후에도 설명 가능'이 우선이었다.