[PonsLink] 특정 Wi-Fi에서 파일 전송이 느려지는 문제를 추적하다

PonsWarp의 파일 전송 기능이 완성되어 가던 어느 날, 특정 Wi-Fi 환경에서 전송 속도가 현저히 떨어지는 보고가 나왔다. 같은 파일을 같은 브라우저에서 보내도, 어떤 네트워크에서는 정상이지만 다른 네트워크에서는 마지막 몇 퍼센트에서 멈추거나 수 초 동안 진행률이 움직이지 않았다.

가장 쉽게 떠올릴 수 있는 설명은 NAT였다. 그런데 그 설명 하나로는 충분하지 않았다.

같은 코드, 다른 결과

PonsWarp의 전송 로직은 브라우저 안에서 돌아간다. DataChannel을 열고, chunk를 보내고, ACK를 기다리고, 저장하는 흐름은 네트워크와 무관하게 동일하다. 그런데 LAN에서는 안정적으로 동작하던 전송이 특정 Wi-Fi 환경에서 느려지거나 멈추는 것이다.

반복 테스트를 통해 확인한 것은 세 가지였다.

1. 네트워크 대역폭 자체는 충분했다. speed test로 확인한 수치와 전송 속도의 괴리가 컸다.
2. 중간 라우터의 buffering이 원인일 수 있었다. Wi-Fi 라우터 중에는 대용량 UDP 패킷을 처리할 때 문제를 일으키는 것이 있다.
3. NAT 유형에 따라 WebRTC 연결 품질이 달라졌다. Symmetric NAT에서는 TURN 서버를 경유해야 하는데, 이 경유 자체가 병목이 되기도 했다.

NAT를 탓하기 전에 확인할 것

NAT traversal이 왜 실패하는지, TURN 비용이 어떻게 계산되는지는 이미 다른 글에서 다루었다. 이 글은 이론이 아니라, 실제로 코드를 고치고 테스트를 반복하면서 추적한 경험에 관한 것이다. NAT는 편리한 설명이다. "NAT 때문에 느리다"라고 하면 대화가 쉽게 끝난다. 하지만 실제 추적 과정에서 NAT 하나로 설명되지 않는 경우가 많았다.

Wi-Fi 라우터의 경우, 같은 NAT 유형이라도 브랜드와 펌웨어에 따라 동작이 달랐다. 특정 라우터에서는 STUN 응답이 느렸고, 다른 라우터에서는TURN relay를 사용해도 여전히 속도가 나지 않았다. 반면에 NAT를 통과하지 못하는 환경에서도 WebRTC가 직접 연결되면 속도가 충분했던 케이스도 있었다.

이 차이를 좁히기 위해 테스트한 것은 네 가지 환경이었다: 같은 Wi-Fi의 같은 라우터, 같은 Wi-Fi의 다른 라우터, Wi-Fi에서 Ethernet으로 전환, 그리고 완전히 다른 네트워크. 각각에서 전송 테스트를 반복하고 결과를 기록했다.

재현 조건을 같이 적어야 의미가 있었다

문제를 좁히는 데 가장 큰 도움이 된 것은 정밀한 기록이었다. "느리다"는 표현으로는 원인을 추적할 수 없었다. 대신 파일 크기, 브라우저 종류, Wi-Fi 대역폭 측정값, STUN/TURN 사용 여부, 전송 시작 시점의 ACK 패턴까지 적어야 했다.

이 기록들이 쌓이면서 보인 것은 느린 원인이 하나가 아니었다는 사실이었다. 라우터 buffering, TURN relay 병목, SCTP overbuffering, Wi-Fi 대역폭 변동이 각각 다른 비율로 영향을 주고 있었다. NAT도 그중 하나였지 전부는 아니었다.

서버가 없는 전송의 무게

PonsWarp는 서버가 파일을 갖지 않는 전송을 목표로 했다. 이 원칙은 서버 비용과 개인정보 문제를 해결했지만, 대신 브라우저와 네트워크의 모든 불안정성을 제품이 직접 감당해야 한다는 뜻이기도 했다.

특정 Wi-Fi에서 느려지는 문제는 이 무게를 가장 선명하게 보여 주는 장면이었다. 서버가 중간에 있으면 문제를 회피할 수 있지만, 서버가 없는 구조에서는 모든 불일치를 브라우저와 프로토콜 수준에서 설명해야 한다.

NAT도, Wi-Fi도 하나의 변수일 뿐

이 추적에서 배운 것은 NAT나 Wi-Fi 특정 모델을 탓하는 것으로는 답이 나오지 않는다는 것이었다. 전송 속도는 여러 변수가 겹쳐 만들어지는 결과다. 그 변수들을 분리하고, 각각이 어느 정도 영향을 미치는지 확인한 뒤에야 의미 있는 개선을 할 수 있었다.

현재로서는 전송이 느린 환경에서 보여 줄 수 있는 것이 명확한 상태 안내다. "지금 이 속도가 왜 나오는지"를 사용자에게 설명할 수 있어야 한다는 것이 이 추적의 실제 결론이었다.

마치며

특정 Wi-Fi에서 파일 전송이 느려지는 문제를 추적하면서, NAT를 탓하는 것만으로는 충분하지 않다는 것을 확인했다. 전송 속도는 라우터 buffering, TURN relay 경로, SCTP 설정, Wi-Fi 환경이 합쳐진 결과였다. 이 변수들을 분리해 기록한 것이 가장 큰 수확이었고, 다음에 같은 증상이 나왔을 때 어디를 먼저 의심할지 기준이 되었다.