일괄 업로드 최적화: 폴더를 더 빠르게 전송

가장 빠른 일괄 업로드 전략은 폴더 전체를 store 모드(비압축) .zip 하나로 묶어 수천 개의 작은 파일 대신 하나의 큰 객체를 업로드하는 것입니다. 각 500 KB짜리 .jpg 파일 5,000개를 개별로 업로드하면 총 2.5 GB이지만 단일 2.5 GB 아카이브 대비 10~20배 더 오래 걸립니다. 각 파일마다 TLS 핸드셰이크, HTTP 헤더, 서버 확인이 반복되기 때문입니다. 병렬 업로드를 지원하는 서비스(HexaTransfer, Dropbox, rclone)는 청크가 크고 많을 때 특히 효과적입니다. 중복 파일 제거와 .DS_Store, Thumbs.db 같은 OS 쓰레기 파일 제외까지 더하면 단순 업로드 대비 시간을 크게 단축할 수 있습니다.

수천 개의 작은 파일이 느린 이유

HTTPS를 통한 모든 파일 업로드에는 고정된 오버헤드가 따릅니다. TLS 핸드셰이크(연결 유지로 재사용 가능), HTTP 헤더(약 500 바이트), 서버 확인, 수신 측의 디스크 플러시. 50 KB 파일의 경우 해당 오버헤드가 파일 자체 크기를 초과할 수 있습니다. 500 KB 파일의 경우 오버헤드는 회선상의 총 바이트의 10~20%를 차지합니다.

5,000개 파일로 곱하면 페이로드 대신 메타데이터에 시간의 절반을 소모합니다. 많은 작은 파일이 있는 큰 폴더를 외부 저장소로 복사하는 것이 같은 크기의 단일 아카이브보다 항상 느린 이유가 바로 여기에 있습니다.

아카이브 먼저, 업로드는 그 다음

폴더 업로드에서 가장 큰 속도 향상을 가져오는 것은 먼저 .zip, .7z 또는 .tar 파일로 묶는 것입니다. 이미 압축된 콘텐츠(사진, 동영상, 오피스 문서)의 경우 store 모드(비압축)를 사용하면 CPU 비용 없이 묶음 이점을 얻을 수 있습니다. 텍스트 위주 폴더(로그, 소스 코드)의 경우 기본 압축을 사용하면 크기 절약도 함께 얻을 수 있습니다.

명령어:

• macOS/Linux: zip -0 -r archive.zip folder/(비압축), zip -r archive.zip folder/(기본 압축)
• Windows: 폴더 마우스 오른쪽 클릭 → 보내기 → 압축(zip) 폴더. 또는 7-Zip으로 압축 파일에 추가 → 압축 수준 → 저장
• 대용량 폴더: tar -cf archive.tar folder/(비압축) 또는 tar -czf archive.tar.gz folder/(gzip)

아카이브 전 중복 파일 제거

폴더에는 시간이 지남에 따라 중복 파일이 쌓입니다. 디자인 프로젝트에는 "final_v2.psd", "final_v2_COPY.psd", "final_v2_BACKUP.psd"처럼 내용은 같지만 이름이 다른 파일이 넘칩니다. 20 GB 폴더가 중복 제거 후 12 GB로 줄어드는 경우도 흔합니다.

도구: fdupes(Linux), rmlint(Linux/macOS), Duplicate File Finder(macOS), dupeGuru(크로스 플랫폼). 대부분은 파일을 해싱하여 동일한 해시를 가진 파일을 표시하는 방식으로 작동합니다. 결과를 검토하고 중복을 삭제한 다음 아카이브하세요.

사진가라면 Lightroom 카탈로그에서 이미 고유한 사진을 추적하고 있으니, 전체 캡처 폴더 대신 플래그 지정된 선택 항목만 내보내세요.

OS 쓰레기 파일 제외하기

모든 macOS 폴더에는 .DS_Store 파일(숨겨진 메타데이터)이 쌓입니다. Windows 폴더에는 Thumbs.db가, KDE에서는 Linux .directory 파일이 나타납니다. 이런 파일은 수신자에게 아무 가치도 없고 아카이브 파일 수만 늘립니다.

macOS에서 zip할 때:

zip -r archive.zip folder/ -x "*.DS_Store" "__MACOSX"

7-Zip을 사용하는 Windows에서는 UI 또는 명령줄에서 -xr!Thumbs.db -xr!desktop.ini로 패턴을 제외하세요. rsync 방식의 전송에서는 --exclude='.DS_Store' --exclude='Thumbs.db'를 사용하세요.

병렬 청크 업로드 활용하기

서비스가 지원한다면, 병렬 HTTP 스트림은 단일 TCP 연결로는 채울 수 없는 대역폭을 고지연 경로에서 포화시킵니다. tus.io 프로토콜은 동시 청크 업로드를 지원합니다. tus-js-client 라이브러리는 기본적으로 동시 요청 1개이지만 더 높게 설정할 수 있습니다.

대륙 간 업로드(예: 한국에서 유럽 서비스로)의 경우, 병렬 처리는 유효 처리량을 두 배 또는 세 배로 늘릴 수 있습니다. 로컬 업로드는 단일 스트림이 이미 업로드 대역폭을 포화시키는 경우가 많아 병렬 처리의 추가 이득이 없습니다.

청크 크기 조정

큰 청크는 요청당 오버헤드를 줄이고, 작은 청크는 네트워크 장애 시 더 빠르게 복구됩니다. 트레이드오프는 연결 상태에 따라 달라집니다.

| 연결 유형 | 권장 청크 크기 | |---|---| | 기가비트 광섬유, 유선 | 32~64 MB | | 가정용 광섬유, Wi-Fi | 10~20 MB | | 사무실 광대역 | 10 MB | | 모바일 4G/5G | 2~5 MB | | 불안정한/호텔 Wi-Fi | 1~2 MB |

대부분의 소비자용 서비스는 합리적인 기본값(5~10 MB)을 선택하고 설정을 노출하지 않습니다. rclone, aws s3 cp, gsutil 같은 명령줄 도구는 정밀하게 조정할 수 있습니다.

폴더 구조보다 전체 파일 수가 중요

흔한 오해: "깊게 중첩된 폴더는 업로드 속도를 늦춥니다." 그렇지 않습니다. 아카이브 형식은 경로 깊이에 관계없이 경로를 문자열 헤더로 평탄화합니다. 3단계 깊이의 10,000개 파일은 아카이브 후 10단계 깊이의 10,000개 파일과 동일하게 업로드됩니다.

실제로 중요한 것은 개별 파일 수입니다. 평탄한 10,000개의 작은 파일과 중첩된 10,000개의 작은 파일은 같은 문제입니다. 반드시 아카이브하세요.

콘텐츠 유형별 압축 전략

• 혼합 사진(.jpg/.heic): store 모드 .zip. CPU 낭비 없음.
• RAW 사진(.cr3/.arw/.nef): store 모드 .zip. 이미 내부적으로 압축됨.
• 동영상 프로젝트(.mp4, .mov, .prproj): store 모드 .zip.
• 소스 코드: 최대 압축률을 위한 LZMA2의 7z.
• 로그 파일: LZMA2의 7z. 10~20배 감소 기대.
• PDF: store 모드. 대부분의 PDF에는 내부 압축이 있음.
• 혼합 오피스 문서(.docx, .xlsx): store 모드. 이미 ZIP 압축된 XML.
• 데이터베이스 덤프(.sql): LZMA2의 7z. 뛰어난 압축률.

완료 후 반드시 확인하기

대용량 일괄 업로드는 시작하고 그냥 잊어버리고 싶은 유혹이 강합니다. 노트북을 닫기 전에 다음을 확인하세요.

• 업로드 페이지가 "완료"를 표시하는지 확인("진행 중"이 아닌지)
• 다른 브라우저나 시크릿 창에서 링크를 열어 수신자 경험 확인
• 아카이브가 올바르게 열리는지 확인(업로드 중 손상된 .zip은 드물지만 발생 가능)
• 만료 설정이 원하는 것과 일치하는지 확인

5분의 검증이 다음 날 파일 수신 여부를 묻는 어색한 이메일보다 훨씬 낫습니다.

결론: 빠른 경로

폴더 업로드의 빠른 경로: 모든 것을 .zip 하나로 묶고(미리 압축된 콘텐츠는 store 모드, 텍스트는 실제 압축), OS 쓰레기 파일 제외, 가치 있는 곳에서 중복 제거, 청크 재개 가능 업로드를 지원하는 서비스 사용. 매우 큰 일괄은 데스크톱 클라이언트가 유리합니다. 단순 폴더 직접 업로드와 최적화된 경로의 차이는 경우에 따라 10배에 달합니다.

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