[Topology 딥다이브] Full Mesh, Partial Mesh, Star 구조를 나눠서 보기

Topology를 처음 그릴 때는 선이 많을수록 더 분산된 구조라고 생각했다. 모두가 모두에게 직접 연결되면 중앙 서버 부담이 줄고, 덜 연결되면 어딘가에 의존한다고 느꼈다. 그런데 실제 제품 관점에서 보니 질문은 조금 달랐다. 로그를 다시 펼쳤을 때 눈에 들어온 건 예쁜 성공 화면이 아니라, Topology 주변에서 반복되던 작은 끊김이었다.

Full Mesh가 커진 문제

실패 이름을 나누면 사용자 행동도 나뉜다. 기다릴지, 다시 초대할지, 우회 경로로 바꿀지, cloud 경로로 올릴지, 아예 중단하고 나중에 받을지 선택지가 생긴다. 운영자도 같은 사건을 로그에서 찾을 수 있다. 반대로 모든 것을 “네트워크 오류”로 덮으면 사용자는 계속 버튼을 누르고, 운영자는 재현되지 않는 문의를 쌓는다. Full Mesh, Partial Mesh, Star, Relay를 같은 축에 놓으면 구조보다 책임 차이가 먼저 보인다. P2P를 공부하면 Mesh라는 단어가 먼저 보인다.

하지만 topology는 Full Mesh 하나로 끝나지 않는다. 모든 피어가 서로 연결될 수도 있고, 필요한 피어끼리만 연결될 수도 있고, 중심 노드를 두고 주변 노드가 그 노드와만 이야기할 수도 있다. 직접 연결이 실패했을 때 Relay 경로로 우회하는 경우도 있다. 처음 헷갈렸던 지점은 “P2P면 반드시 모두가 모두에게 연결되어야 한다”는 가정이었다. 실제로는 방 상태, 권한, 채팅, 파일 바이트, 미디어 스트림이 같은 길을 갈 필요가 없다.

어떤 정보는 서버가 잡고 있어야 하고, 어떤 바이트는 브라우저끼리 직접 주고받아도 된다. 또 어떤 순간에는 직접 경로보다 우회 경로가 사용자에게 더 나은 선택이 된다.

처음에는 모두가 모두에게 붙는 줄 알았다

Star는 중앙형이라는 단어 하나로 끝내기 쉽지만, 실제로는 중심 노드가 무엇을 맡는지 다시 나눠야 한다. 중심은 권한만 확인할 수도 있고, 상태를 보관할 수도 있고, payload를 중계할 수도 있다. 중심이 피어일 수도 있고 서버일 수도 있다. Star를 쓰는 순간 P2P가 모두 사라지는 것이 아니라, 책임 일부를 중심으로 모으는 선택이 생긴다. 그래서 topology 다이어그램을 그릴 때는 노드 이름보다 책임을 먼저 적는다.

세션을 만드는 주체, 권한을 확인하는 주체, 후보를 교환하는 주체, 실제 데이터를 운반하는 주체, 실패를 보고하는 주체를 따로 둔다. 이 순서로 보면 같은 “서버”라도 인증 서버, signaling 서버, TURN Relay, SFU, 저장소 서버가 전혀 다른 역할이라는 점이 드러난다. 두 선이 같은 길을 갈 수도 있지만 항상 그렇지는 않다. WebRTC 연결에서는 signaling 서버가 후보와 세션 정보를 주고받게 도와도, 실제 미디어나 DataChannel payload는 브라우저끼리 직접 흐를 수 있다.

직접 경로가 막히면 TURN 같은 Relay가 payload를 운반할 수 있다. 반대로 채팅 상태나 방 권한은 서버 중심으로 두는 편이 운영상 더 단순할 수 있다. 여기서 이 글의 범위를 넘기지 않는 것도 중요하다. 화상회의에서 Mesh가 CPU, 업로드, packet loss, 모바일 배터리 때문에 무너지는 순간은 다음 글의 주제다. SFU가 영상을 섞지 않고 중계하는 내부 방식도 별도 글에서 다룰 문제다.

여기서는 topology 이름을 책임 경계로 번역하고, 언제 다른 구조로 넘어갈지 기준을 잡는 데 집중한다. PonsLink와 PonsWarp를 다시 보면 이 감각이 남는다. PonsLink에서는 방, 권한, 요청, 세션 상태처럼 중앙에서 일관성을 가져야 하는 정보가 있었다. PonsWarp에서는 파일 바이트가 반드시 서버 소유일 필요는 없지만, 직접 경로 실패와 backpressure와 중단 후 복구를 사용자가 이해할 수 있게 설명해야 했다.

Direct와 Cloud Drop은 경쟁하는 이름이 아니라 서로 다른 실패 조건을 받는 선택지에 가깝다.

구조별로 드러난 차이

• [ 기능별 데이터 흐름을 따로 그렸는가: 방 상태, 권한, 채팅, 파일 바이트, 미디어가 같은 경로를 써야 하는지 분리한다.
• [ 제어선과 데이터선을 나눴는가: signaling, 후보 교환, 실제 payload 전송, 저장 경로를 같은 화살표로 합치지 않는다.
• [ 중심 노드 장애 시 동작을 정의했는가: Star나 Relay를 쓰는 경우 중심이 느려지거나 사라졌을 때 사용자 문장과 재시도 기준을 정한다.
• [ Partial Mesh 경로 정책을 문서화했는가: 어떤 피어끼리 직접 연결하고, 언제 경로를 바꾸며, 바꾼 뒤 상태 일관성을 어떻게 확인할지 남긴다.
• [ topology 전환 기준을 숫자로 잡았는가: 방 크기, p95 연결 시간, Relay 비율, 재시도 횟수, chunk 크기, 중단 후 복구 시간을 본다.
• [ 사용자 문구와 운영 로그가 같은 상태 전이를 가리키는가: 화면의 기다림과 로그의 원인 이름이 서로 연결되어야 한다. | 구조 | 연결 모양 | 책임이 놓이는 곳 | 잘 맞는 장면 | 조심할 지점 | |---|---|---|---|---| | Full Mesh | 모든 노드 쌍이 직접 연결된다 | 각 피어가 전송과 수신을 모두 감당한다 | 소수 인원, 짧은 세션, 직접 전달이 중요한 기능 | 인원이 늘면 연결 수와 업로드 부담이 빠르게 커진다 | | Partial Mesh | 필요한 일부 쌍만 직접 연결된다 | 경로 정책이 어떤 피어를 연결할지 결정한다 | 기능별 데이터 흐름이 다르거나 일부 노드가 동기화 역할을 맡는 경우 | 경로 선택 기준과 일관성 관리가 없으면 디버깅이 어려워진다 | | Star | 중심 노드와 주변 노드가 연결된다 | 중심 노드가 조정, 중계, 집계 중 일부를 맡는다 | 방 상태, 권한, 채팅, 작은 제어 메시지처럼 일관성이 중요한 기능 | 중심 장애와 중심 비용을 별도로 설계해야 한다 | | Relay | 직접 경로 실패 시 중간 노드나 서버가 payload를 운반한다 | 우회 노드가 실제 바이트 비용을 떠안는다 | NAT, 회사망, 모바일망 때문에 직접 연결이 막힌 경우 | 성공률은 높아질 수 있지만 비용과 지연이 다른 곳으로 이동한다 | Topology와 관련해서 같이 읽을 만한 글은 [과 [이다. 두 글을 같이 보면 topology가 실제 제품 판단으로 내려오는 경로가 조금 더 보인다. Full Mesh, Partial Mesh, Star, Relay를 나누는 이유는 이름표를 외우기 위해서가 아니다. 누가 권한을 확인하는지, 누가 실제 payload를 옮기는지, 누가 실패를 감지하고 다음 경로로 넘기는지 정하기 위해서다. 선의 개수보다 그 선이 CPU, 업로드, 비용, 사용자 대기를 누구에게 남기는지가 더 중요했다. 처음에는 선의 모양을 봤지만, 제품에 넣을 때는 각 선의 책임을 다시 적어야 했다. 특히 Topology에서는 재현 조건을 같이 적어야 의미가 있었다. 제품 문장은 기술 구조를 그대로 노출하지 않는다. “P2P 실패”보다 “직접 전송이 어려워 우회 경로를 준비하고 있다”가 낫다. 무엇을 서버가 처리하는지 문서와 UI에서 분리해야 사용자 약속도 흐려지지 않는다. Topology를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

토폴로지별 경계 나누기

topology를 나누고 나면 화상회의에서 Mesh가 어디서 무너지는지도 더 선명해진다.에서 이어진다.에서 이어서 정리한다. 구조 선택이 구현으로 내려가기 전에 확인할 항목을 한 번 더 모았다. 특히 Topology에서는 재현 조건을 같이 적어야 의미가 있었다. 현실적인 제품은 기능별로 topology를 섞는다. 방 상태와 권한은 서버 중심이 편하다. 파일 바이트는 직접 경로가 맞을 수 있다. 직접 경로가 막힌 사용자를 위해 Relay나 Cloud Drop 같은 대체 경로를 열 수도 있다. 대규모 미디어는 별도 중계 구조를 검토해야 하지만, 이 노트의 역할은 SFU 내부를 설명하는 것이 아니라 그 전 단계의 taxonomy를 분리하는 데 있다. Full Mesh와 Star의 차이는 숫자로 보면 더 선명하다. 10명의 Full Mesh는 45개 연결이다. 같은 10명을 Star로 두면 중심 기준 9개 연결이다. Partial Mesh는 정책에 따라 그 사이 어딘가에 놓인다.

흐름이 바뀐 지점

Partial Mesh는 모든 연결이 필요하지 않거나 일부 노드만 동기화와 중계 역할을 맡을 때 쓴다. 다만 “일부만 연결한다”는 말만으로는 부족하고, 왜 그 일부인지 정책이 있어야 한다. Star는 중심이 있다는 이유만으로 나쁜 구조가 아니다. 중심이 권한만 보는지, 상태를 보관하는지, payload까지 운반하는지 분리하면 된다. 한 제품 안에서 topology를 섞어도 된다. 서버가 방 상태를 알고, 브라우저가 파일을 직접 보내고, 실패한 사용자는 Relay나 Cloud Drop으로 넘어가는 식이다.

Full Mesh는 단순하게 설명하기 좋다. 모든 피어가 서로 연결되니 구조가 투명해 보인다. 하지만 투명하다는 말은 부담도 각 피어에게 보인다는 뜻이다. 각 브라우저는 여러 상대에게 보내고 받아야 하며, 업로드가 약한 한 명이 방 전체 경험을 흔들 수 있다. 이 체크리스트는 정답표가 아니다. 구현 중에 성공 경로가 너무 매력적으로 보일 때 다시 돌아오는 난간이다.

실시간 네트워크는 실패가 사용자 환경에 흩어져 있어서 한 개발자의 노트북에서는 끝까지 보이지 않을 수 있다. 그래서 topology 선택은 코드가 돌아간 뒤가 아니라, 실패 조건을 말로 적을 수 있을 때 비로소 제품 결정에 가까워진다. 가장 안전한 구조도 하나로 정해지지 않는다. 실패 비용, 확장 목표, 운영 능력, 사용자에게 약속한 대기 시간에 따라 답이 달라진다.

어떤 방 크기인지, 어떤 파일 크기인지, 어떤 네트워크인지, 어떤 실패를 허용할 수 있는지 빠지면 좋은 기술도 엉뚱한 선택이 된다. '[Topology 딥다이브 Full Mesh, Partial Mesh, Star 구조를 나눠서 보기'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

여기서 남겨 둘 기준은 단순하다. topology 전환은 장애가 난 뒤에 붙이는 예외가 아니라, 방 크기와 데이터 종류가 바뀔 때 실행되는 정상 경로여야 한다. Full Mesh에서 Partial Mesh로 줄일지, Star로 모을지, Relay를 열지는 코드 안의 분기가 아니라 사용자에게 보이는 대기 시간과 운영자가 보는 사건 이름을 함께 바꾼다. 마지막에 남는 기준은 단순하다. topology는 선의 모양이 아니라 책임의 배치다.

어떤 선이 payload를 옮기고, 어떤 선이 권한을 붙잡고, 실패했을 때 어떤 문장을 사용자에게 보여 줄지까지 정해야 실제 서비스 설계 도구가 된다. Partial Mesh는 그 중간에 있다. 모든 연결이 필요하지 않은 기능에서는 일부 피어만 직접 연결하면 된다. 예를 들어 상태 동기화, 파일 조각 전달, 특정 그룹 안의 협업처럼 데이터의 범위가 제한된 기능은 전체 연결보다 정책이 더 중요하다.

대신 이 정책이 문서와 로그에 남지 않으면 “왜 이 피어와는 직접 연결되고 저 피어와는 안 되는지”를 나중에 설명하기 어렵다. 이 숫자는 어느 구조가 항상 낫다는 증거가 아니다. 부담이 이동한다는 신호다. Full Mesh에서는 서버의 payload 부담이 줄 수 있지만 각 브라우저의 업로드, CPU, 배터리 부담이 늘어난다. Star에서는 주변 노드의 연결 수가 단순해지지만 중심 노드가 병목과 단일 장애점이 된다.

Partial Mesh는 연결 수를 줄일 수 있지만 정책을 잘못 만들면 경로가 바뀔 때 상태 일관성이 흔들린다. Relay는 직접 연결 성공률을 보완하지만, 실제 바이트 비용을 중간 경로가 부담한다. 다이어그램에서 가장 자주 생기는 실수는 제어선과 데이터선을 같은 색으로 칠하는 일이다. 제어선은 약속을 움직인다. 누가 방에 들어왔는지, 어떤 후보가 생겼는지, 어떤 권한을 가졌는지 같은 정보다.

데이터선은 실제 payload를 움직인다. 파일 조각, 오디오, 비디오, 화면 공유, 메시지 본문처럼 사용자가 체감하는 바이트다. 실패를 하나의 오류로 뭉치지 않고 구조별로 나눠 두면 전환 기준을 더 빨리 잡을 수 있다.

구조마다 실패 이름이 다르다. Full Mesh는 연결 수와 클라이언트 부담이 문제로 드러난다. Star는 중심 노드 장애와 중심 비용이 앞에 나온다. Partial Mesh는 경로 정책과 상태 일관성이 흔들릴 수 있다. Relay는 성공률을 높이는 대신 비용, 지연, 개인정보 기대치를 다시 계산하게 만든다. topology 판단에는 p95 연결 시간, Relay 비율, 재시도 후 성공률, 중단 후 복구 가능성, 사용자가 취소한 상태를 같이 둔다.

성공한 한 번의 데모보다 “어디까지 약속할 수 있고 어디부터 다른 경로가 필요한가”가 더 오래 남는 기준이다. Relay는 topology 이름이라기보다 경로 선택의 안전망에 가깝다. 직접 경로가 열리지 않을 때 중간 경로가 실제 바이트를 옮긴다. 이때 signaling처럼 약속만 전달하는 서버와 Relay처럼 payload를 운반하는 서버를 섞어 부르면 비용 계산이 틀어진다. 사용자에게는 둘 다 “연결 중”으로 보일 수 있지만 운영자에게는 완전히 다른 사건이다.

그래서 평균 방 크기만 보면 부족하다. 보통은 2명이어도 한 번 8명, 10명이 들어오는 순간이 있다. 대부분 직접 연결이 되더라도 회사망, VPN, 모바일 핫스팟에서 Relay 비율이 튈 수 있다. 파일이 작을 때는 괜찮아도 5GB, 20GB, 장시간 전송으로 가면 backpressure와 재시도 정책이 제품의 핵심이 된다.

마치며

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