Gzip과 Deflate는 데이터 크기를 줄이는 압축 알고리즘이지만, 결과물은 텍스트가 아니라 바이너리입니다. 이 압축된 데이터가 텍스트용으로 설계된 채널(URL, 쿠키, JSON 필드)을 거쳐야 한다면, 추가로 Base64로 인코딩됩니다 — 그래서 "Gzip/Deflate ↔ Base64"라는 조합이 생기며, 다이어그램 도구들이 문서 전체 상태를 공유 가능한 링크에 담을 때 자주 이 방식을 씁니다.
한글 텍스트의 압축률을 영어와 단순 비교하기 어려운 이유
한글 음절 하나는 UTF-8에서 3바이트를 차지해, 같은 글자 수라면 영어 텍스트보다 바이트 수가 훨씬 큽니다. 하지만 한글 음절 하나가 영어 단어 하나에 가까운 정보량을 담는 경우가 많아, 같은 내용을 표현하는 데 필요한 글자 수 자체는 영어보다 적어지는 경향이 있습니다. 게다가 조사나 어미 같은 문법 요소가 텍스트 곳곳에서 반복되기 때문에, Gzip이 이런 반복 패턴을 짧은 참조로 바꾸면서 바이트당 비용 차이를 상당 부분 상쇄합니다.
일반적인 작업 순서
- 원본 텍스트를 Gzip이나 Deflate로 압축한다 — 크기가 줄어든다.
- 압축된 바이너리 결과를 Base64로 인코딩한다 — 크기가 다시 조금 늘지만 데이터가 텍스트가 된다.
- 결과 문자열을 텍스트 채널을 통해 안전하게 전송한다.
디코딩은 역순으로 진행됩니다: 먼저 Base64 → 바이너리 데이터, 그다음 Gzip/Deflate 압축 해제 → 원본 텍스트.
일반적인 사용 사례
- 애플리케이션의 전체 상태를 URL에 담아, 공유한 링크를 열면 저장했던 화면이 그대로 재현되게 할 때.
- 압축된 데이터를 쿠키나 데이터베이스의 텍스트 필드에 저장할 때.
- 디버깅: 타사 시스템이나 API가 이런 방식으로 인코딩한 콘텐츠를 압축 해제해 읽을 때.
Gzip 대 "원시" Deflate
Gzip은 사실상 Deflate 알고리즘을 감싸는 형식으로, 압축된 데이터 위에 자체 헤더와 체크섬(CRC32)을 추가합니다. "원시" Deflate에는 이런 부가 바이트가 없어 결과가 조금 더 작지만, raw 형식임을 명시적으로 알려주지 않으면 gzip 유틸리티로 압축을 풀 수 없습니다. 이 두 방식을 혼동하는 것은 데이터 압축 해제 시 "invalid header" 오류의 흔한 원인입니다.