중단된 전송 재개: 처음부터 다시 시작하지 않는 방법

재개 가능한 전송은 파일을 청크로 분할하고 어떤 청크가 성공적으로 수신되었는지 추적합니다. 연결이 끊기면 클라이언트는 바이트 0에서 다시 시작하는 대신 아직 전송되지 않은 다음 청크에서 이어갑니다. 이를 위한 웹 표준은 tus.io(오픈 재개 가능 업로드 프로토콜)이며, SwissTransfer, HexaTransfer, Vimeo, Cloudinary 및 많은 최신 전송 서비스에서 구현됩니다. 다운로드의 경우 HTTP Range 요청(RFC 7233)을 통해 브라우저와 curl, aria2 같은 도구가 중단된 다운로드를 재개할 수 있습니다. 재개 기능이 없으면 9.5 GB에서 실패하는 9.8 GB 업로드는 처음부터 다시 해야 합니다. 재개 기능이 있으면 잃는 것은 최대 50 MB에 불과합니다.

재개 불가능한 업로드의 문제

단순한 파일 업로드는 전체 파일을 하나의 HTTP POST 요청으로 보냅니다. Wi-Fi 끊김, VPN 타임아웃, 노트북 절전 모드 전환, ISP 일시 장애 등 무엇이든 연결을 중단시키면 TCP 연결이 닫히고 서버는 받아놓은 부분 데이터를 버립니다. 클라이언트는 바이트 0부터 다시 시작해야 합니다.

50 Mbps 연결에서 5 GB 업로드라면 13분의 작업이 사라집니다. 50 GB 업로드라면 2시간 이상입니다. 모바일 연결에서 재개 불가능한 업로드의 실패율은 상당히 높습니다. 4G 연결에서 30분 업로드가 첫 시도에 성공하는 경우는 많지 않습니다.

재개 가능한 프로토콜의 작동 방식

최신 재개 가능 업로드는 대략 다음과 같이 작동합니다.

생성: 클라이언트가 파일의 총 크기와 메타데이터를 담아 서버에 POST를 보냅니다. 서버는 이 특정 업로드에 대한 고유 URL을 반환하고 저장 공간을 예약합니다.
청킹: 클라이언트가 파일을 청크(일반적으로 각 5~64 MB)로 자릅니다.
업로드: 클라이언트가 각 청크를 청크 위치를 나타내는 Content-Range 또는 Upload-Offset 헤더와 함께 PATCH 요청으로 보냅니다.
확인: 서버가 청크를 저장소에 쓰고 새 오프셋을 확인합니다.
재개: 연결이 끊기면 클라이언트가 업로드 URL에 HEAD 요청을 보냅니다. 서버는 현재 오프셋(얼마나 많은 바이트를 받았는지)으로 응답합니다. 클라이언트는 해당 오프셋에서 재개합니다.
완료: 마지막 청크가 확인되면 업로드가 완료됩니다.

이 모델은 tus.io 사양(버전 1.0.0이 널리 배포됨)으로 정의됩니다. 다른 변형으로는 S3 Multipart Upload(직접 S3 업로드용)와 Google Cloud Storage Resumable Uploads가 있습니다.

Tus.io: 오픈 표준

Tus("transloadit upload server")는 Transloadit이 관리하는 무료 오픈 프로토콜입니다. 사양은 tus.io에서 확인할 수 있으며 다음에서 구현됩니다.

클라이언트 라이브러리: tus-js-client(브라우저 + Node.js), TUSKit(iOS), tus-android-client, tus-java-client
서버 구현: tusd(Go 참조 서버), tus-node-server, 다양한 프레임워크 통합
상용 서비스: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, Uppy 컴패니언 서버

프로토콜은 의도적으로 최소한으로 설계되었습니다. HTTP 동사 4개(POST, HEAD, PATCH, OPTIONS), 소수의 헤더(Upload-Offset, Upload-Length, Tus-Resumable). 이런 단순함이 구현을 쉽게 하고 상호 운용성을 보장합니다.

청크 크기 결정

청크 크기는 재개 세분성과 HTTP 오버헤드 사이의 트레이드오프입니다.

| 청크 크기 | 실패 시 복구 손실 | 오버헤드 | |---|---|---| | 1 MB | 최대 1 MB 손실 | 높음(요청 수 많음) | | 5 MB | 최대 5 MB 손실 | 중간 | | 16 MB | 최대 16 MB 손실 | 낮음 | | 64 MB | 최대 64 MB 손실 | 최소 | | 256 MB | 최대 256 MB 손실 | 오버헤드는 무시할 수준, 실패 시 고통 큼 |

안정적인 연결에서는 32~64 MB 청크가 처리량을 극대화합니다. 모바일이나 불안정한 Wi-Fi에서는 2~5 MB 청크가 각 실패에서 더 빠르게 복구됩니다. 서비스는 보통 타협점으로 5~10 MB 범위의 기본값을 사용합니다.

실제로 전송을 중단시키는 요인들

실패 모드를 이해하면 서비스의 재개 구현이 얼마나 견고한지 평가하는 데 도움이 됩니다.

Wi-Fi 끊김: 네트워크 전환, 신호 손실, 라우터 재부팅. 매우 흔함.
노트북 절전: macOS/Windows에서 덮개 닫기. OS가 네트워크를 일시 중지하고, 깨어날 때 연결이 재설정되어야 합니다.
탭 일시 중단: 최신 브라우저는 메모리를 절약하기 위해 백그라운드 탭을 일시 중단합니다. 일시 중단된 탭의 업로드는 멈출 수 있습니다.
ISP/백홀 문제: 순간적인 라우팅 변경, TLS 재핸드셰이크 필요.
VPN 재연결: VPN 클라이언트는 주기적으로 재협상하며, TCP 연결이 종료됩니다.
서버 측 재시작: 전송 서비스가 새 버전을 배포하면 진행 중인 요청이 실패합니다.
기업 방화벽: 트래픽을 검사하는 방화벽이 장시간 유지되는 연결을 강제 종료하는 경우가 있습니다.

견고한 재개 가능 구현은 동일한 메커니즘으로 이 모든 경우를 처리합니다. 재연결하고, HEAD로 오프셋을 확인하고, 해당 위치에서 재개합니다.

다운로드 재개

HTTP Range 요청(RFC 7233)은 재개 가능한 다운로드를 지원합니다. 응답 헤더에 Accept-Ranges: bytes를 광고하는 서버는 범위 요청을 지원합니다. 클라이언트는 Range: bytes=1000000-을 발행하여 오프셋 1,000,000 이후의 바이트만 가져올 수 있습니다.

브라우저는 다운로드 관리자에서 "재개"를 누를 때 자동으로 이를 사용합니다. Chrome, Firefox, Safari 모두 규격을 준수하는 서버에서 다운로드 재개를 지원합니다. 대부분의 CDN(Cloudflare, Fastly, CloudFront)도 범위 요청을 지원합니다.

명령줄 도구는 더 세밀한 제어를 제공합니다.

curl -C - -O url — 중단된 곳에서 다운로드 재개
wget -c url — 같은 기능
aria2c -c -s 16 url — 속도를 위해 16개 병렬 범위 요청 스트림으로 다운로드

재개를 지원하는 서비스 비교

| 서비스 | 업로드 재개 | 다운로드 재개 | |---|---|---| | SwissTransfer | 예(tus 기반) | 예(HTTP 범위) | | HexaTransfer | 예(청크 + tus 호환) | 예 | | WeTransfer | 예(청크 업로드) | 예 | | Dropbox Transfer | 예 | 예 | | Google Drive | 예(재개 가능 업로드 API) | 예 | | OneDrive | 예 | 예 | | Box | 예 | 예 |

무료 플랜이 유료 업그레이드를 유도하기 위해 재개를 비활성화하는 경우도 있지만 2026년에는 드뭅니다. 재개 지원이 없는 구형 서비스는 사용자가 실패에 지쳐 추천 목록에서 사라지고 있습니다.

종단 간 암호화와 재개의 결합

클라이언트 사이드 암호화와 결합된 재개 가능 업로드는 신중한 청킹이 필요합니다. 파일을 청크로 분할하고, 각 청크를 고유한 IV(초기화 벡터)를 사용해 AES-256-GCM으로 암호화한 다음 업로드합니다. 재개 시 클라이언트는 어떤 청크가 완료되었는지 파악하고 다음 청크에서 계속해야 합니다.

각 청크가 독립적으로 암호화되고 인증되므로(GCM의 AEAD 모드), 부분 업로드는 변조될 수 없습니다. 5 GB 오프셋에 악의적인 데이터를 삽입한 서버는 수신자가 복호화할 때 GCM 태그 불일치로 즉시 감지됩니다. HexaTransfer는 마스터 키와 청크 인덱스에서 결정론적으로 파생된 청크별 IV를 사용하므로 재개 시 IV를 별도로 저장할 필요가 없습니다. GDPR, HIPAA, PIPA(개인정보 보호법) 준수 환경에서 이러한 암호학적 무결성은 필수적입니다.

클라이언트 측 모범 사례

재개 성공률을 높이려면 다음을 실천하세요.

업로드 중 탭을 활성 상태로 유지하세요. 브라우저 탭 일시 중단은 진행 중인 업로드를 종료합니다.
가능하면 유선 네트워크에 연결하세요. Wi-Fi 끊김이 대부분의 실패를 유발합니다.
긴 업로드 중 절전 모드를 비활성화하세요. macOS: caffeinate -i. Windows: Powertoys Awake 유틸리티 또는 전원 계획 변경.
업로드 중 Wi-Fi 네트워크를 전환하지 마세요. TCP 연결의 IP가 변경되면 연결이 종료됩니다.
업로드가 완료되기 전에 노트북 덮개를 닫지 마세요.

2026년의 필수 기능

재개 가능한 전송은 2026년에는 기본 중의 기본입니다. 이 기능이 없는 서비스는 몇백 메가바이트를 넘는 파일에는 즉각적인 기각 사유입니다. tus.io 준수 또는 동등한 청크 업로드 동작을 찾으세요. 대용량 전송을 시작하기 전에 작은 파일에서 의도적으로 네트워크를 끊어 재개 기능을 테스트하세요.

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