병렬 업로드 기술: 전송 대역폭 극대화

병렬 업로드는 파일을 청크(일반적으로 각 5~100 MB)로 분할하고 여러 동시 TCP 연결을 통해 전송해, 단일 스트림이 고지연 링크에서 부딪히는 처리량 상한을 우회합니다. Amazon S3 multipart upload, Google Cloud Storage resumable uploads, tus.io 모두 이를 구현합니다. 대상 서버까지 80 ms 지연이 있는 1 Gbps 회선에서, 단일 HTTP PUT은 보통 150 Mbps에서 포화되는 반면 8개의 병렬 스트림은 900 Mbps를 넘어갑니다. 이 이득은 실제이며 예측 가능합니다. 이유를 이해하면 명확해집니다.

단일 스트림으로는 부족한 이유

TCP의 혼잡 제어는 슬라이딩 윈도우를 사용해 전송 중인 미확인 데이터 양을 결정합니다. 두껍고 고지연인 파이프에서 기본 윈도우 크기(Linux 5.x에서 약 16 MB)는 ACK가 반환되기 전에 가득 차서 송신자가 대기 상태가 됩니다. 이것이 "대역폭-지연 곱(BDP)" 문제입니다. 파리에서 싱가포르 서버로의 단일 FTP 전송이 기가비트 회선에서도 30 Mbps 수준에 머무르는 이유가 바로 여기에 있습니다.

여러 병렬 연결을 실행하면 각 연결이 자체 윈도우를 갖게 되어 이 문제를 우회합니다. 8개의 30 Mbps 스트림은 240 Mbps가 되며, 여기에 CDN 엣지 선택이 다른 연결을 다른 진입 지점으로 라우팅하는 경우가 더해집니다.

청크 크기와 병렬 수 결정하기

최적 설정은 지연 시간과 패킷 손실에 따라 다릅니다. 50 ms RTT 미만의 같은 대륙 전송에서는 4개 병렬 워커로 10 MB 청크가 대부분의 소비자 회선을 포화시킵니다. 대륙 간 또는 손실이 있는 모바일 링크(100 ms RTT 이상, 0.5% 패킷 손실 이상)에서는 5 MB 청크에 8~16개 워커를 사용하세요.

S3 multipart API는 부분당 최소 5 MB(마지막 부분 제외), 최대 5 GB, 업로드당 최대 10,000개 부분을 요구합니다. 이론적 상한은 객체당 약 48.8 TB입니다. Google Cloud Storage는 합성당 32개 부분을 허용하고 최대 1주일 지속되는 재개 가능 세션 URI를 지원합니다. Azure Blob 블록 blob은 각 4000 MiB의 최대 50,000개 블록을 수용합니다.

브라우저 기반 전송에서는 100 MB 이상의 청크가 이미 로드된 탭의 RAM에 부담을 주기 시작하므로, 대부분의 웹 UI는 5~20 MB 범위를 유지합니다.

실제 전송 서비스의 구현 방식

WeTransfer의 웹 업로더는 파일을 6 MB 청크로 분할하고 3~5개의 병렬 XHR 요청을 실행합니다. Smash는 더 공격적으로 분할하여 최대 8개 워커에 걸쳐 4 MB 청크를 사용합니다. SwissTransfer는 4개 병렬 스트림으로 50 MB 청크를 사용하는데, 스위스 광섬유 회선에서는 처리량에 유리하지만 불안정한 연결에서는 단일 실패 청크가 50 MB 재전송을 의미해 불리합니다. Dropbox Transfer는 8 MB 청크로 자체 청크 업로드 API를 사용합니다.

차이는 실제 테스트에서 나타납니다. 500 Mbps 업로드에서 5 GB 파일을 WeTransfer로 전송하면 약 95초, 비슷한 처리량의 SwissTransfer는 간헐적인 청크 재시도 오버헤드로 약 105초가 걸립니다.

재개 가능 업로드: 병렬 처리의 숨겨진 장점

청크 업로드는 재개를 가능하게 합니다. Wi-Fi가 120개 청크 중 47번째에서 끊기면 0부터 재시작하는 것이 아니라 48번째 청크에서 재개합니다. tus.io 프로토콜(현재 버전 2.0의 오픈 표준)은 이를 공식화합니다. HEAD 요청으로 업로드 오프셋을 쿼리하고, Upload-Offset 및 Upload-Length 헤더를 사용한 PATCH 요청으로 이어서 전송합니다.

Google Drive의 재개 가능 업로드 API는 7일간 지속되는 세션 URI를 사용합니다. 노트북이 갑자기 꺼지고 재부팅해도 탭을 다시 열면 중단된 위치에서 정확히 재개할 수 있습니다. 이것이 사용 가능한 10 GB 전송과 운에 맡기는 전송의 차이입니다.

클라이언트 사이드 암호화가 계산을 바꿉니다

종단 간 암호화 전송 서비스는 전송 전에 클라이언트에서 각 청크를 암호화해야 합니다. 최신 노트북 CPU에서 AES-256-GCM은 500 MB/s로 처리되므로 병목이 아닙니다. 하지만 순서가 중요합니다. 청크 암호화 → 청크 업로드 → 다음 청크 암호화. 여기서 워커 풀을 사용한 파이프라이닝이 중요합니다. 단순한 구현은 암호화와 업로드를 직렬로 처리해 유효 처리량을 절반으로 줄입니다. 제대로 된 구현은 2~4개의 암호화 워커가 경계가 있는 큐를 통해 4~8개의 업로드 워커에 데이터를 공급합니다.

HexaTransfer가 병렬 XHR 풀과 함께 Web Workers에서 AES-256-GCM 암호화를 실행하는 이유가 바로 이 때문입니다. 10 GB 상한이 암호화 중단 없이 브라우저에서 실제로 달성 가능합니다.

백프레셔와 서버 측 제한

병렬 처리가 많을수록 항상 빠른 것은 아닙니다. 수신 서비스가 IP별로 속도를 제한한다면(CloudFront에서 배포당 초당 25,000 요청이 일반적), 32개의 동시 청크를 밀어내면 503 Slow Down 응답을 유발할 수 있습니다. HTTP/2는 단일 TCP 연결에서 멀티플렉싱하여 도움이 되지만, 많은 CDN은 여전히 엣지에서 HTTP/2를 종료하고 오리진으로 HTTP/1.1을 팬아웃하므로 유효 병렬 처리는 엣지 구성에 따라 다릅니다.

과도한 병렬화 전에 테스트하세요. 8개 워커는 거의 항상 안전합니다. 16개가 클라우드 오브젝트 스토리지가 안정적으로 처리하는 상한입니다. 32개부터는 절약하는 것보다 더 많은 재시도 비용이 발생하기 시작합니다.

알아야 할 브라우저 제한

Chrome과 Firefox는 HTTP/1.1로는 오리진당 동시 연결을 6개로 제한하지만 HTTP/2로는 사실상 무제한입니다. 전송 서비스가 아직 HTTP/1.1을 사용한다면(드물지만 일부 레거시 FTP-over-HTTP 게이트웨이), 설정한 워커 수와 관계없이 병렬 처리 상한은 6입니다. DevTools의 네트워크 패널 "폭포(Waterfall)" 열에서 대기 중인 요청이 쌓이는지 확인하세요.

iOS 17 이상의 Safari는 6개의 병렬 XHR을 안정적으로 처리하지만 RAM 압력이 약 1.5 GB에 달하면 백그라운드 탭을 추방하기 시작합니다. 청크 업로드 버퍼에 영향을 미칠 수 있습니다.

병렬 업로드가 도움이 되지 않는 경우

비대칭 가정용 연결(일반적: 1 Gbps 다운, 40 Mbps 업)에서는 업로드가 병목이지 서버의 수신이 아닙니다. 8개의 병렬 스트림을 40 Mbps 파이프를 통해 밀어내도 1개 스트림보다 빠르지 않습니다. 병렬 처리는 단일 스트림 상한이 파이프의 실제 용량 아래에 있을 때 효과가 있습니다.

셀룰러에서도 마찬가지입니다. LTE 신호가 약하다면 추가 워커는 주로 재전송만 만들어냅니다.

서비스 선택 시 확인해야 할 것

자주 대용량 파일을 보내는 전송 도구를 고른다면 세 가지를 확인하세요. 재개 가능 청크 업로드를 지원하는지, 웹 UI가 몇 개의 병렬 워커를 실행하는지, 엣지로 HTTP/2 또는 HTTP/3을 사용하는지. 세 가지를 모두 갖춘 서비스는 적절한 연결 환경에서 10 GB 파일을 몇 분 만에 이동시킵니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.