마지막 업데이트: 2026년 8월 20일

GZIP vs BZIP2 vs XZ: Which Linux Compression Format Is Best?

GZIP vs BZIP2 vs XZ: 최고의 리눅스 압축 포맷은 무엇인가요?

일일 데이터베이스 덤프를 압축하든, 수 기가바이트 규모의 웹 서버 로그를 순환시키든, 수천 대의 노드에 컴파일된 바이너리를 배포하든, 압축은 리눅스 관리에서 일상적인 현실입니다.

tar를 호출하거나 표준 입력을 통해 스트리밍 데이터를 처리할 때, 일반적으로 세 가지 표준 유틸리티를 접하게 됩니다: GZIP (.gz), BZIP2 (.bz2), 그리고 XZ (.xz).

세 도구 모두 원시 바이트를 압축된 아카이브로 압축하려 하지만, 압축 비율, CPU 실행 시간, 메모리 오버헤드 사이에서 근본적으로 다른 엔지니어링 트레이드오프를 합니다. 잘못된 형식을 선택하면 자동 배포가 조용히 병목 현상이 되거나, 예정된 백업 창이 지연되거나, 시간이 지나면서 귀중한 저장 공간을 낭비할 수 있습니다.

이 가이드는 각 형식이 내부에서 어떻게 작동하는지, 실제 워크로드에서 어떻게 성능을 발휘하는지, 그리고 인프라에 맞는 올바른 형식을 선택하는 방법을 상세히 설명합니다.

1. 간략한 기술 프로필: 세 경쟁자

GZIP (GNU Zip)

  • 기본 알고리즘: DEFLATE (LZ77 및 Huffman 코딩의 조합)
  • 기본 확장자: .tar.gz, .tgz, .gz
  • 출시 연도: 1992 (Jean-loup Gailly와 Mark Adler가 compress에 대한 특허 없는 대안으로 만들었습니다)
  • 핵심 장점: 무적의 실행 속도와 거의 보편적인 생태계 지원.
  • 핵심 단점: 현대의 통계 및 사전 기반 인코더에 비해 낮은 압축 비율.

GZIP은 30년 넘게 Unix 환경의 기본 작업 도구로 사용되어 왔습니다. DEFLATE 알고리즘이 작은 슬라이딩 윈도우(32 KB)로 작동하기 때문에, GZIP은 압축 및 해제 시 메모리 오버헤드가 거의 필요하지 않습니다.

BZIP2

  • 기본 알고리즘: Burrows-Wheeler Transform (BWT)와 Move-to-Front (MTF) 변환 및 Huffman 코딩의 결합
  • 기본 확장자: .tar.bz2, .tbz2, .bz2
  • 출시 연도: 1996 (Julian Seward가 생성)
  • 핵심 장점: 반복적인 ASCII 및 구조화된 로그 파일에서 GZIP보다 더 나은 압축 비율.
  • 핵심 단점: 전체적으로 느리며, 특히 압축 해제 시 느리고, 최신 알고리즘에 의해 대부분 구식이 되었습니다.

BZIP2는 데이터를 개별 블록(보통 900KB)으로 처리하며, 인코딩 전에 유사한 문자를 함께 그룹화하는 가역적인 순열을 사용합니다. 1990년대 후반과 2000년대에 GZIP보다 파일 크기를 줄인 것으로 널리 찬사를 받았지만, 계산 비용이 상대적으로 높습니다.

XZ (LZMA2)

  • 기본 알고리즘: LZMA2 (Lempel-Ziv-Markov chain Algorithm, improved)
  • 기본 확장자: .tar.xz, .txz, .xz
  • 출시 연도: 2009 (이전 lzma 포맷을 대체하기 위해 도입)
  • 핵심 장점: 극도로 높은 압축 비율과 빠르고 가벼운 압축 해제.
  • 핵심 단점: 초기 압축 중에 높은 RAM 사용량과 장시간 CPU 실행 시간이 필요합니다.

XZ는 가변 사전 크기(기본값으로 종종 32 MB 또는 64 MB까지)를 활용하여 GZIP보다 훨씬 넓은 데이터 창에서 중복 바이트 패턴을 찾습니다. 이로 인해 OS 설치 미디어, 커널 소스 트리, 펌웨어 이미지와 같은 크고 중복된 파일을 압축하는 데 매우 효과적입니다.

2. 성능 비교 매트릭스

아래 표는 표준 서버 하드웨어에서 기본 설정으로 실행할 때 각 유틸리티의 실제 성능 동향을 요약한 것입니다:

지표 / 차원GZIP (-6)BZIP2 (-9)XZ (-6)
압축 비율보통 (~65-75% 감소)좋음 (~75-80% 감소)우수함 (~80-88% 감소)
압축 속도매우 빠른느림매우 느림
압축 해제 속도매우 빠름느림에서 보통빠른
압축 RAM 사용량무시할 정도 (~1–2 MB)낮음 (~8–10 MB)높음 (~100–700 MB+)
압축 해제 RAM 사용량무시할 정도 (< 1 MB)낮음 (~4 MB)보통 (~10–65 MB)
주요 최적 지점로그, CI/CD 파이프라인, 실시간 스트림레거시 아카이브 호환성패키지 저장소, OS ISO, 콜드 스토리지

3. 실제 벤치마크 인사이트

현실적인 부하 하에서 이러한 도구들의 동작을 이해하려면, 대표적인 1 GB 원시 서버 액세스 로그와 압축되지 않은 500 MB 소프트웨어 소스 코드 디렉터리를 고려하십시오.

시나리오 A: 대용량 로그 파일 압축 (1 GB 텍스트)

  • GZIP: 12초 미만에 완료되어 약 180 MB의 아카이브를 제공합니다.
  • BZIP2: 약 45–50초에 완료되어 파일을 약 130 MB로 줄입니다.
  • XZ: 기본 설정에서 80–90초가 걸리며, 약 95 MB의 아카이브를 생성합니다.

시나리오 B: 압축 해제 작업 부하

자주 간과되는 중요한 지표는 비대칭입니다.

  • GZIP은 2–3초 안에 압축을 해제하며 메모리 사용량이 극히 적습니다.
  • XZ는 4–6초에 압축을 해제합니다. 초기 압축은 느렸지만, .xz를 추출하는 속도는 .gz를 추출하는 것과 거의 동일합니다.
  • BZIP2는 풀기만 해도 대략 25–30초가 필요합니다. 이는 Burrows-Wheeler 변환을 역전하는 것이 인코딩과 계산적으로 대칭이기 때문입니다.

4. BZIP2가 인기를 잃는 이유

현대 인프라에서는 BZIP2가 어색한 중간 지점에 끼어 있습니다:

  1. GZIP에 속도에서 뒤처짐: 처리 지연이나 낮은 CPU 사용량이 중요하다면, GZIP가 훨씬 빠릅니다.
  2. XZ에 압축률에서 뒤처짐: 대역폭 절약과 저장 효율성이 중요하다면, XZ는 훨씬 작은 아카이브를 생성합니다.
  3. 두 압축 방식 모두에 압축 해제 속도에서 뒤처짐: 소프트웨어 배포 시스템에서, 클라이언트는 .tar.bz2 파일을 추출할 때 .tar.gz 또는 .tar.xz에 비해 눈에 띄는 CPU 비용을 지불합니다.

그 결과, 주요 Linux 배포판(예: Debian, Arch, Fedora)은 공식 패키지 배포 및 커널 tarball을 BZIP2에서 XZ로 전환했으며(최근에는 런타임 작업을 위해 Zstandard로도 이동했습니다).

5. 실용적인 명령줄 사용법

Tar 통합 (가장 일반적인 워크플로우)

GNU tar의 최신 구현은 파일 확장자를 기반으로 압축 형식을 자동으로 인식하지만, 명시적인 플래그를 사용하는 것이 여전히 표준 관행입니다:

# GZIP: Fast archive creation
tar -czvf project-backup.tar.gz /var/www/project/

# BZIP2: Legacy high-ratio archive
tar -cjvf project-backup.tar.bz2 /var/www/project/

# XZ: Maximum space savings
tar -cJvf project-backup.tar.xz /var/www/project/

# Generic extraction (tar auto-detects the format)
tar -xvf archive-name.tar.*

독립형 파일 압축

파일을 묶지 않고 개별 파일을 압축하려면:

# Compress keeping the original file intact (-k)
gzip -k access.log      # Output: access.log.gz
bzip2 -k access.log     # Output: access.log.bz2
xz -k access.log        # Output: access.log.xz

# Decompress individual files
gzip -d access.log.gz
bzip2 -d access.log.bz2
xz -d access.log.xz

멀티코어 시스템 활용

기본적으로 이러한 도구들의 단일 스레드 구현은 하나의 CPU 코어만 사용합니다. 최신 다중 코어 서버에서 수 기가바이트 규모의 아카이브를 압축한다면, 단일 스레드 처리에 몇 시간이 걸릴 수 있습니다.

  • XZ 멀티스레딩: -T 또는 --threads를 통한 기본 지원:
    xz -T0 -k database_dump.sql   # Uses all available CPU cores
  • 병렬 GZIP (pigz): 모든 CPU 코어를 사용하여 GZIP 작업을 수행하는 즉시 대체 도구:
    pigz -k database_dump.sql
  • 병렬 BZIP2 (pbzip2): BZIP2를 위한 멀티스레드 구현:
    pbzip2 -k database_dump.sql

6. 선택 방법: 실용적인 의사결정 프레임워크

워크플로우의 주요 제약 조건에 따라 도구를 선택하세요:

GZIP를 사용할 경우:

  • 처리량이 제한 요소인 실시간 스트림 압축 또는 네트워크 전송을 설정하고 있습니다.
  • 프로덕션 서버에서 자동 로그 회전(logrotate)을 관리하고 있으며, CPU 자원을 애플리케이션 워크로드에 할당해야 합니다.
  • 레거시 임베디드 시스템과 표준 베이스 이미지 전반에 걸친 최대 이식성이 필요합니다.

XZ를 사용할 경우:

  • 릴리스 아티팩트, 커널 빌드, 컨테이너 베이스 이미지 또는 제3자가 자주 다운로드하는 정적 패키지 저장소를 배포하고 있습니다.
  • 스토리지 비용이 일회성 압축 시간보다 큰 장기 콜드 아카이브(오프사이트 주간/월간 백업)를 준비하고 있습니다.
  • 작은 파일 크기가 필요하지만, 소비자는 여전히 빠른 다운로드와 신속한 압축 해제 시간을 요구합니다.

BZIP2를 유지해야 하는 경우만:

  • 레거시 스크립트, 기존 백업 복원 루틴 또는 XZ 압축 해제 프로그램을 제공하지 않는 소프트웨어 어플라이언스와의 하위 호환성을 유지하고 있습니다.

7. 자주 묻는 질문 (FAQ)

Q1. 어떤 포맷이 가장 작은 아카이브 크기를 제공합니까? XZ는 더 큰 LZMA2 사전 윈도우 덕분에 세 가지 중 가장 작은 아카이브 크기를 지속적으로 제공합니다.

Q2. 파일을 압축 해제할 때 XZ가 GZIP보다 느린가요? XZ는 압축 해제 속도가 GZIP보다 약간 느리지만, BZIP2보다 훨씬 빠릅니다.

Q3. GZIP와 XZ가 여러 CPU 코어를 활용할 수 있나요? XZ는 -T0 플래그를 사용하여 네이티브 멀티스레딩을 지원하고, GZIP는 pigz 대체 유틸리티를 사용해 코어별로 병렬화할 수 있습니다.

Q4. 리눅스 배포판이 BZIP2를 없애는 이유는 무엇인가요? 배포판들은 XZ가 더 작은 파일을 압축하고 해제 속도가 빠르기 때문에 BZIP2를 대부분 단계적으로 제거했습니다. 반면 GZIP는 빠른 작업에 여전히 더 빠릅니다.

Q5. -9와 같은 높은 압축 레벨이 눈에 띄는 차이를 만들까요? 레벨 -9를 설정하면 평균적으로 1%에서 3% 정도의 미미한 크기 감소만 얻을 수 있지만, CPU 사이클 사용량과 메모리 오버헤드가 크게 증가합니다.

관련 항목