[PonsWarp] LAN에서 WebRTC가 한계에 부딪혔을 때, stripe가 아니라 cloud로 갈라졌다

대용량 파일을 브라우저끼리 직접 보내는 작업을 하면서 속도 문제를 만났을 때 가장 처음 떠올린 것은 더 빠른 채널을 여는 일이었다. 하지만 LAN에서도 WebRTC DataChannel은 일정 수준 이상으로 올라가지 않았고, 멀티 PC에서 striping을 시도했을 때는 오히려 복잡도만 커졌다.

그 실패 뒤에 남은 질문은 단순했다. 전송 속도가 아니라 전송 경로의 다양성이 문제를 해결할 수 있는 것은 아닐까.

DataChannel의 LAN 천장

PonsWarp에서 DataChannel의 LAN throughput을 측정했을 때, 물리적 Wi-Fi 대역폭에 비해 상당한 갭이 있었다. 256KB chunk로 전송하고, unordered DataChannel을 쓰고, 8MB 버퍼까지 올려도 속도는 벽에 부딪혔다.

한 대의 host에서 멀티 PC striping을 시도했을 때는 더 복잡해졌다. 병렬 PeerConnection lane을 열고, 각 lane의 준비 상태를 기다린 뒤, partition ACK를 기준으로 striping을 시작하는 구조를 만들었다. LAN 테스트에서 10MB/s 경로가 보이기도 했지만, 신뢰성 있는 경로가 되려면 수많은 edge case를 잡아야 했다.

결국 striping은 기본으로 켜지 않는 실험으로 남았다. 기능은 작동하지만, 모든 환경에서 안정적인 경로는 아니었다.

Hybrid transport로 갈라진 이유

LAN ceiling에 부딪힌 뒤에 실험한 것은 WebRTC와 encrypted HTTP의 hybrid 경로였다. 같은 파일을 동시에 두 경로로 보내되, 하나가 막히면 다른 하나가 몫을 가져가는 구조다.

cross-network 상황, 예를 들어 LTE hotspot으로 파일을 전송할 때 이 hybrid 접근이 효과를 보였다. 단일 DataChannel이 감당할 수 없는 구간을 HTTP assist가 메웠다. 이 방식은 속도 자체를 올리는 것이 아니라, 어떤 상황에서든 전송이 멈추지 않도록 경로를 나누는 선택이었다.

PonsWarp 문서에는 이 비교가 기록되어 있다: LAN WebRTC ceiling vs. hybrid bulk transport vs. multi-PC striping. 세 가지 모두 같은 문제에 대한 답이었지만, 어떤 것이 실제 제품으로 쓸 수 있는지는 완전히 달랐다.

PonsLink의 채팅과 라우팅도 동시에 변했다

같은 시기 PonsLink에서도 변화가 있었다. room 채팅을 Socket.IO로 라우팅하고, P2P data-channel 채팅은 멈췄다. 멀티 파일 ZIP64 번들링이 추가되었고, MSP personal session desk도 자르고 다시 만들었다.

채팅 경로를 바꾼 것은 단순한 refactoring이 아니었다. 모든 실시간 메시지를 하나의 channel에 태웠을 때 방 안에서 어떤 문제가 생겼는지, 파일 전송 중에 채팅이 끊긴 경험이 어떤 불신을 만드는지를 확인한 뒤의 판단이었다. 이 이야기는 별도 글에서 더 자세히 다루겠지만, 여기서 짚어야 할 것은 동시에 여러 방향이 움직이고 있었다는 사실이다.

속도보다 경계를 먼저 정했다

PonsWarp의 최근 작업에서 가장 크게 바뀐 것은 특정 숫자를 높이는 것이 아니라, 어떤 경로를 언제 선택할지 경계를 정한 것이다. LAN에서는 DataChannel이 충분할 수 있지만, Wi-Fi가 불안정하거나 cross-network이면 hybrid가 필요하다. striping은 특정 조건에서만 쓸 수 있는 도구다.

이 경계를 정하는 과정은 속도 테스트보다 훨씬 느렸다. 두 대의 기기에서 파일을 보내고, 각 환경의 결과를 기록하고, 어떤 선택이 어떤 대가를 가져오는지 확인하는 일이 반복되었다.

마치며

LAN에서도 WebRTC의 한계는 분명했다. 하지만 그 한계를 해결하는 방법이 단 하나일 필요는 없었다. striping, hybrid, cloud assist—각각 다른 상황에서 쓸 수 있는 도구이고, 어떤 도구를 쓸지는 환경이 정한다. 속도를 높이는 것보다 경로를 선택하는 기준을 먼저 정하는 것이 결과적으로 더 빠른 전송을 만들었다.