[PonsWarp] 대용량 전송에서는 속도보다 흐름 제어가 먼저였다

대용량 파일 전송을 처음 볼 때는 속도가 가장 중요한 숫자처럼 보였다. 하지만 큰 파일을 실제 브라우저로 보내 보니 문제는 전송률이 아니었다. 보내는 쪽이 계속 밀어 넣는 동안 받는 쪽의 메모리와 저장 속도가 따라오지 못했고, 실패는 마지막 몇 퍼센트에서야 드러났다.

ACK를 표시가 아니라 브레이크로 보기

PonsWarp에서 ACK는 “받았다”는 표시만을 위한 메시지가 아니었다. 수신자가 다음 데이터를 받을 준비가 됐다는 신호로 써야 했다. 보내는 쪽이 자기 속도만 믿고 앞서가면 전송은 잠깐 빨라 보이지만, 브라우저가 버티지 못하는 순간 전체 작업이 무너진다.

그래서 흐름 제어와 저장 전략을 속도 최적화보다 먼저 봤다. 서버가 파일을 들고 있지 않는다는 원칙을 유지하더라도, 브라우저 안에서 어느 만큼을 읽고 어느 시점에 다음 조각을 보낼지는 조절해야 했다.

마지막 구간이 가장 잔인했다

작은 파일에서는 문제가 잘 보이지 않는다. 파일이 커지면 수신 속도, 메모리, 저장 방식이 동시에 영향을 준다. 전송이 거의 끝난 것처럼 보이는데 마지막 조각에서 실패하면 사용자는 전체 기능을 믿기 어렵다. 이 경험 때문에 PonsWarp를 별도 제품으로 생각하게 됐다. 회의방에 파일 기능을 하나 더 넣는 문제가 아니라, 끝까지 살아남는 전송 흐름을 설계하는 문제였기 때문이다.

속도를 낮추는 선택이 항상 좋은 것은 아니다. 다만 수신자가 감당할 수 없는 속도를 계속 유지하는 것보다, 현재 상태를 반영해 다음 전송을 늦추는 편이 결과적으로 더 빠른 경험을 만든다. 백프레셔는 성능을 포기하는 장치가 아니라 실패를 뒤로 미루지 않는 장치였다.

제품 기준을 바꾼 것

이후 PonsWarp의 기준은 최고 속도가 아니라 재시작하지 않고 끝까지 도착하는 흐름이 됐다. 브라우저 메모리와 수신 상태를 무시한 벤치마크보다, 실제로 파일이 마지막까지 남는지 확인하는 것이 더 중요했다.

큰 파일을 다루는 기능은 “빠르게 보낸다”는 한 문장으로 설명할 수 없다. 보내는 쪽, 받는 쪽, 저장하는 쪽이 서로 기다릴 수 있어야 한다. 그 기다림을 코드에 명시하는 일이 속도를 늦추는 게 아니라 제품을 성립시키는 일이었다.

마치며

대용량 전송에서 가장 먼저 고쳐야 했던 것은 속도가 아니었다. 누가 언제 멈춰야 하는지 정하는 일이었다. PonsWarp는 그 기준을 ACK와 백프레셔, 저장 흐름으로 구체화한 기록이다.