[PonsWarp] Zero-Copy Pool은 빠른 전송보다 GC를 피하기 위한 선택이었다

Zero-Copy Pool을 고른 이유는 전송 속도를 더 내고 싶어서가 아니었다. 브라우저에서 큰 파일을 다룰 때 복사와 가비지 컬렉션이 전송의 마지막 구간을 망가뜨리는 일이 무서워졌기 때문이다.

처음에는 PonsLink 방 안에서 파일을 보내면 충분할 줄 알았다. 파일 크기가 커지면서 회의방의 리듬까지 흔들렸다. 파일을 보내는 일과 대화하는 일이 같은 메모리 압박을 공유하고 있었다.

복사가 만든 마지막 실패

작은 파일에서는 복사가 보이지 않는다. 큰 파일에서는 버퍼를 만들고, 옮기고, 해제하는 시간이 겹친다. 수신 속도가 저장 속도보다 느려지면 브라우저 안에 데이터가 쌓이고, 마지막 몇 퍼센트에서야 문제가 드러난다.

사용자는 전송률이 거의 100%에 도달한 뒤 실패한 것으로 기억한다. 내부에서는 메모리 정리 한 번이 늦어진 것일 수 있지만, 제품에서는 파일 전체를 잃은 사건이다.

풀로 버퍼의 수명을 관리하다

Zero-Copy Pool은 모든 복사를 없애겠다는 구호가 아니었다. 재사용할 버퍼를 정하고, 전송 단계가 끝날 때 반환하고, 필요 이상으로 메모리를 늘리지 않기 위한 경계였다.

전송 조각의 수명과 ACK, 수신 측의 백프레셔를 같은 흐름으로 봐야 했다. 보내는 속도만 올리면 수신과 저장이 따라오지 못한다. 속도를 낮추는 것이 실패를 줄이는 경우도 있었다.

Rust와 WASM을 붙인 이유

Rust와 WASM은 멋진 기술을 보여 주기 위한 장식이 아니었다. 브라우저 안에서 큰 파일을 다룰 때 복사와 메모리 경계를 더 엄격하게 관리하고 싶었다. 동시에 웹 제품이라는 제약 때문에 모든 것을 네이티브처럼 다룰 수도 없었다.

그래서 PonsWarp는 PonsLink 방의 작은 기능에서 별도 전송 흐름으로 분리됐다. 서버가 파일을 들고 있지 않는다는 원칙은 유지하되, 브라우저가 버틸 수 있는 저장과 흐름 제어를 제품의 중심에 놓았다.

마치며

Zero-Copy Pool의 기준은 가장 빠른 전송이 아니다. 파일이 커지고 수신자가 느려져도 마지막 구간에서 무너지지 않는 전송이다. 다음 메모리 최적화에서도 먼저 버퍼의 수명과 실패 시 복구 경계를 적는다.