gzip / deflate / zlib 압축 및 압축 해제

gzip 압축이란?#

gzip은 웹 전반에 쓰이는 범용 무손실 텍스트·바이트 압축기입니다. HTTP의 Content-Encoding: gzip, 서버에서 받아오는 .gz 파일, 수많은 로그 전송기의 전송 포맷을 뒤에서 떠받칩니다. 반복되는 바이트 패턴을 찾아 짧은 참조로 치환하는 방식으로 동작하므로, 반복이 많은 텍스트(소스 코드, JSON, CSV, 로그 라인)는 극적으로 줄어드는 반면, 이미 압축되었거나 무작위에 가까운 데이터(JPEG, 암호화된 바이트)는 거의 줄지 않습니다.

이 페이지는 일상적으로 “gzip”이라 한데 묶어 부르는 세 가지 관련 알고리즘 을 제공합니다. 세 알고리즘은 같은 DEFLATE 코어를 감싸는 래퍼만 다릅니다.

• gzip (RFC 1952) — 완전한 꾸러미. 매직 바이트가 있는 헤더, 압축된 페이로드, CRC32와 크기 트레일러로 이루어집니다. .gz 파일과 HTTP gzip이 사용하는 형태입니다.
• deflate (RFC 1951) — 래퍼이 없는 원시 압축 스트림. 출력이 가장 작지만 무결성 검사가 없습니다. 일부 API(오래된 Content-Encoding: deflate)가 정확히 이것을 기대합니다.
• zlib (RFC 1950) — 2바이트짜리 가벼운 헤더에 Adler-32 체크섬이 붙는, 나머지 둘의 중간 형태입니다.

압축 출력은 이진이므로, 이 도구는 출력을 Base64 또는 Hex 텍스트로 보여 주어 복사하거나 JSON에 붙여 넣거나 다른 곳으로 파이프하기 쉽게 합니다. 압축 해제는 그 반대로, Base64 또는 Hex를 읽어 원래의 UTF-8 텍스트를 돌려줍니다.

사용 방법#

1. 도구 모음에서 알고리즘 을 고르세요. gzip, deflate, zlib 중 하나입니다.
2. 방향 을 고르세요. 압축 (텍스트 입력 → Base64/Hex 출력) 또는 압축 해제 (Base64/Hex 입력 → 텍스트 출력)입니다.
3. 출력 인코딩을 고르세요. Base64 또는 Hex (압축 해제 모드에서는 도구가 인코딩을 자동으로 감지하므로 이 선택기는 잠겨 있습니다).
4. 왼쪽 입력 패널에 붙여넣으세요. 입력 크기는 패널 헤더에 표시됩니다. 결과는 출력 패널을 채우며, 역시 헤더에 크기가 나타납니다.
5. 압축 후에는 전/후 크기 막대 가 나타나 페이로드가 늘었는지 줄었는지 보여줍니다. 복사 로 결과를 가져가거나, 다운로드 로 .gz 파일로 저장하세요. 예제 는 전형적인 로그 라인을 불러오고, 지우기 는 모두 초기화합니다.

주요 기능#

• 세 알고리즘, 하나의 조작부. gzip, deflate, zlib 사이를 전환하며 같은 입력에서 래퍼 오버헤드가 출력 크기를 어떻게 바꾸는지 정확히 볼 수 있습니다.
• 정직한 크기 비교. 전/후 크기 막대는 실제 바이트 수와 부호 있는 백분율 변화를 보여줍니다. 압축이 페이로드를 더 크게 만드는 경우까지 포함해서 말이죠. 그 사실이야말로 gzip에 대해 알아야 할 가장 유용한 한 가지입니다.
• 압축 해제 시 자동 인코딩 감지. Base64 또는 Hex를 붙여넣으면 도구가 어느 쪽인지 스스로 알아내므로, 사용자가 기억할 필요가 없습니다.
• 되돌릴 때 엄격한 UTF-8. 압축 해제한 바이트가 올바른 UTF-8이 아니라면(알고리즘을 잘못 골랐거나 페이로드가 잘린 경우), 도구는 실수를 감추는 대체 문자를 내뱉는 대신 그 사실을 분명히 알려줍니다.
• 브라우저에서 동작. 압축은 작고 지연 로딩되는 라이브러리로 로컬에서 실행됩니다. 붙여넣은 어떤 것도 페이지를 떠나지 않습니다.

실전 예시#

짧은 로그 라인 하나 — 예제 입력 2026-08-06 INFO request handled path=/api/stats status=200 (58바이트) — 를 gzip 과 Base64 출력으로 압축하면 다음이 나옵니다.

H4sIAHcNdmoAAzMyMDLTNbDQNTBT8PRz81coSi0sTS0uUchIzEvJSU1RKEgsybDVTyzI1C8uSSwpVgCRpcW2RgYGACs/7EA6AAAA

전/후 크기 막대는 직관에 반하는 사실을 드러냅니다. 평문 58바이트가 gzip 압축과 Base64 인코딩을 거치면 75바이트 가 됩니다. 입력이 너무 짧고 너무 무작위적이라 DEFLATE가 압축할 만한 것을 찾지 못한 탓에, gzip 헤더와 트레일러, 그리고 Base64 오버헤드(약 33%)가 그냥 위에 쌓인 것입니다. 작은 페이로드에 gzip을 쓰는 것이 무의미한 이유가 바로 이것입니다.

반복적인 텍스트와 비교해 보세요. transaction_id=txn_00001 status=paid amount=100 currency=usd\n 라인 여덟 복사본은 모두 488바이트이고, gzip은 이를 84바이트 로 줄입니다. 원본의 약 17% 입니다. 압축이 진가를 발하는 지점이 바로 여기입니다. 반복이 많을수록 줄어드는 폭도 깊어집니다.

같은 짧은 로그 라인을 deflate 로 바꾸면 출력은 57바이트(헤더/트레일러 없음)로 떨어지고, zlib 은 63바이트가 됩니다. 특정 전송 포맷을 겨냥해서 상대편과 정확히 맞춰야 할 때 요긴합니다.

FAQ#

gzip, deflate, zlib 중 어느 것을 골라야 하나요?#

상대편에 맞추세요. .gz 파일, HTTP Content-Encoding: gzip, 그리고 “압축됨”이라고 하는 거의 모든 API 페이로드에는 gzip 을 쓰세요. API가 원시 DEFLATE를 명시적으로 요구할 때만(일부 레거시 Content-Encoding: deflate 서버) deflate 를 쓰세요. 라이브러리나 프로토콜이 zlib를 명시적으로 지칭할 때 zlib 을 쓰세요. 의심스러울 때는 gzip이 안전한 기본값입니다.

출력이 입력보다 큽니다. 버그인가요?#

아닙니다. 무손실 압축이 작거나 엔트로피가 높은 입력에 어떻게 동작하는지를 보여주는 것입니다. 스트림마다 고정 오버헤드(헤더, 트레일러, 딕셔너리 웜업)가 있고, 내용에 반복이 거의 없으면 DEFLATE는 이를 회수하지 못합니다. 실용적인 규칙은 이렇습니다. gzip은 수백 바이트 이상의 페이로드, 특히 반복이 있는 텍스트에서 안정적으로 이득을 보기 시작합니다. 아주 작은 값이라면 압축을 건너뛰세요.

압축 해제가 데이터가 올바른 UTF-8이 아니라고 합니다. 무엇이 잘못된 건가요?#

보통 셋 중 하나입니다. 알고리즘을 잘못 골랐다(데이터는 zlib로 압축되었는데 gzip을 선택했거나, 그 반대). Base64/Hex가 잘렸거나 중간에 의도치 않은 공백이 끼어 있다. 원래 것이 텍스트가 아니라 이진이었다. 다른 알고리즘들을 차례로 시도해 보고, 붙여넣은 페이로드를 잘린 것이 없는지 확인하세요.

이 도구로 이미지, 비디오, 이미 압축된 파일을 압축할 수 있나요?#

무엇이든 붙여넣을 수는 있지만, 거의 아무 이득도 없을 것입니다. JPEG, PNG, MP4, .zip/.gz 같은 포맷은 이미 압축되어 있어 DEFLATE가 더는 짜낼 것이 없습니다. 출력은 비슷한 크기이거나 살짝 더 커집니다. gzip은 텍스트와 구조화된 데이터를 위한 도구이지, 이진 미디어를 다시 한번 압축하는 도구가 아닙니다.