보내기 전 파일 압축: 크기 줄이고 시간 절약

텍스트, 소스 코드, 로그, CSV, .bmp나 .tiff 같은 비압축 이미지 형식은 전송 전에 압축하면 3~10배 크기를 줄일 수 있습니다. 반면 .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf, .zip 파일은 압축하지 마세요. 이미 내부적으로 압축되어 있어 두 번째 압축은 기껏해야 2~3%의 절약을 더하면서 CPU만 낭비합니다. 여러 작은 파일을 하나의 업로드로 묶으려면 "store" 모드(비압축) .zip을 사용하세요. 압축 가능한 데이터에서 최대 비율을 원한다면 LZMA2 방식의 7z가 .zip보다 일반적으로 30~40% 더 우수합니다. RAR은 7z와 비슷하지만 수신자가 WinRAR 또는 7-Zip을 설치해야 합니다. .zip은 모든 환경에서 범용으로 지원됩니다.

압축이 실제로 도움되는 경우

텍스트 파일은 극적으로 압축됩니다. 10 MB 서버 .log 파일은 .zip으로 800 KB(12배), 7z로 550 KB(18배)까지 줄어드는 경우가 많습니다. 로그에는 타임스탬프, IP 주소, HTTP 상태 코드처럼 압축 알고리즘이 효율적으로 활용하는 반복 패턴이 많기 때문입니다.

압축이 잘 되는 파일 유형:

• 소스 코드: .js, .py, .java, .cs, .go — 일반적으로 3~5배 압축
• CSV 데이터: 내용의 중복성에 따라 4~10배
• JSON/XML: 필드 이름이 반복되기 때문에 5~8배
• 비압축 이미지: .bmp(5~10배), 비압축 .tiff(4~8배)
• 데이터베이스: .sql 덤프, 여유 페이지가 있는 SQLite 파일(2~4배)
• PSD 평면 레이어: 내부 RLE 압축이 없는 경우 2~3배

중간 규모 프로젝트의 Git 저장소 tarball은 종종 4~5배 압축되며, 이것이 git archive가 기본적으로 .tar.gz으로 감싸는 이유입니다.

압축이 무의미한 경우

이미 압축된 형식은 더 작아지지 않습니다. 해당 데이터는 이미 DEFLATE, H.264, JPEG DCT 양자화 등의 방식을 거쳐 엔트로피가 이론적 최솟값에 가깝습니다.

압축 효과가 없는 파일:

• .jpg, .jpeg, .heic: 이미 손실 압축 적용
• .png: DEFLATE 압축 내장
• .mp4, .mov, .mkv: H.264 또는 H.265 압축 이미 적용
• .mp3, .aac, .flac, .ogg: 오디오 이미 압축됨
• .pdf: 내부 객체 스트림이 DEFLATE로 압축됨
• .docx, .xlsx, .pptx: 실제로 XML의 ZIP 아카이브라 재압축이 불필요
• .zip, .7z, .rar, .gz, .bz2, .xz: 이미 압축된 아카이브
• .apk, .jar, .war: ZIP 기반 Java/Android 아카이브

이런 파일을 압축하면 CPU만 낭비하고, 아카이브 메타데이터 오버헤드 때문에 파일이 오히려 약간 커질 수도 있습니다.

ZIP vs 7z vs RAR 비교

| 형식 | 일반적인 압축률 | 속도 | 수신자 호환성 | 암호화 | |---|---|---|---|---| | .zip (DEFLATE) | 기준 | 빠름 | 범용(Windows, macOS, Linux 내장) | ZIP 2.0(취약), AES-256(최신 도구) | | 7z (LZMA2) | .zip보다 30~40% 우수 | 느림 | 7-Zip, Keka, The Unarchiver 필요 | AES-256 내장 | | .rar (RAR5) | .zip보다 약 25~35% 우수 | 중간 | WinRAR 또는 7-Zip 필요 | AES-256 내장 | | .tar.gz | .zip과 유사 | 빠름 | macOS, Linux 내장. Windows는 7-Zip 필요 | 없음 | | .tar.zst (Zstandard) | .zip과 7z 사이 | 매우 빠름 | zstd 필요(아직 범용 아님) | 없음 |

이식성 면에서는 .zip이 가장 안전합니다. 압축률이 중요하면 7z가 최선입니다. 속도와 효율의 균형에서는 Zstandard(.zst)가 우수하지만 수신자도 도구를 설치해야 합니다.

묶음용 "store" 모드

.jpg 사진 200장을 한 번의 전송으로 보내는 경우에도 수신자가 한 번만 클릭하도록 단일 아카이브로 묶는 것이 좋습니다. 압축 레벨 0("store" 모드)으로 .zip을 사용하세요. 파일 크기의 합계에 디렉터리 오버헤드 몇 KB만 더해지며 CPU 비용은 거의 없습니다.

7-Zip에서: 압축 파일에 추가 → 압축 수준 → 저장. macOS Finder에서: 마우스 오른쪽 버튼 클릭 → 압축(기본값은 DEFLATE지만 .jpg에는 큰 해가 없음). 명령줄: zip -0 bundle.zip *.jpg.

압축 시 암호화 설정

AES-256(레거시 ZIP 2.0 암호화가 아닌)을 사용하는 비밀번호 보호 ZIP 파일은 전송 채널의 보안에 의존할 수 없을 때 민감한 데이터를 위한 합리적인 수단입니다. WinRAR, 7-Zip, macOS의 Archive Utility 모두 AES-256 ZIP 암호화를 지원합니다.

단, 비밀번호 교환에 주의하세요. ZIP 파일과 같은 이메일에 비밀번호를 보내지 마세요. 파일을 먼저 보내고, Signal, iMessage 또는 별도 채널로 비밀번호를 공유하세요. GDPR, HIPAA, PIPA(개인정보 보호법) 등 데이터 보호 규정을 준수해야 하는 환경이라면 보안 채널에 내장된 비밀번호 보호를 제공하는 전송 서비스를 사용하는 것이 더 좋습니다.

레거시 ZIP 2.0 암호화는 암호학적으로 이미 깨진 방식이며, 알려진 평문 공격으로 수초 만에 복구됩니다. 보안 목적으로 아카이브 암호화를 사용한다면 반드시 AES-256을 사용하고 있는지 확인하세요.

CPU 시간 vs 절약된 바이트 트레이드오프

압축은 시간과 크기 사이의 트레이드오프입니다. 5 GB 텍스트 아카이브의 최대 7z 압축은 노트북에서 30분이 걸리고 .zip보다 2 GB를 절약할 수 있습니다. 전송 서비스의 용량 제한이 있다면 충분히 가치 있습니다. 하지만 광섬유 연결에서 같은 5 GB가 90초 만에 업로드된다면 30분의 압축 시간이 오히려 손해입니다.

경험칙: 네트워크가 CPU보다 느릴 때 압축하고, 네트워크가 빠를 때는 생략하세요.

손실 압축을 대안으로 활용하기

때로는 아카이브 압축이 아닌 파일 형식 변환 자체가 목적입니다. 200 MB .wav 파일을 15 MB 320 kbps .mp3로, 60 MB 비압축 .tiff 사진을 5 MB 고품질 .jpg로, 4K .mov 동영상을 H.265로 재인코딩하면 3~5배 축소될 수 있습니다.

단, 마스터 파일에는 손실 변환을 적용하지 마세요. 미리보기나 납품물에만 적절히 활용하세요. 도구: 비디오/오디오용 FFmpeg, 비디오용 Handbrake, 이미지용 ImageMagick, Photoshop이나 Final Cut Pro의 내보내기 기능.

내용에 따라 판단하기

흔한 실수는 "보내기 전에 항상 zip"이라는 반사적 습관입니다. .pdf 문서 20개를 받는 클라이언트에게는 ZIP 묶음이 편리합니다. 하지만 800 MB .mp4 하나를 받는 클라이언트에게 ZIP은 양쪽 모두의 시간을 낭비합니다.

확신이 없다면 그냥 보내세요. 여러 파일을 묶어야 한다면 store 모드 .zip을, 텍스트 중심 콘텐츠라면 7z를 사용하세요. E2EE(종단 간 암호화) 서비스를 사용한다면 암호화된 암호문은 압축되지 않으므로, 반드시 압축 먼저 하고 그 다음 암호화하세요.

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