처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.06.27 26

압축률을 끝까지 올렸더니 지옥처럼 느려진 이야기 (feat. deflate)

Hacker News 원문 보기

파일 압축, 다들 한 번쯤 써보셨죠. zip으로 묶고, 웹 서버에서 gzip으로 응답을 줄이고요. 그런데 이 압축에도 ‘세기’를 조절하는 다이얼이 있다는 거 아세요? 더 세게 압축할수록 파일은 작아지지만 시간은 더 걸리거든요. 오늘은 이 다이얼을 끝까지, 그것도 보통은 잘 안 쓰는 극단까지 돌렸을 때 무슨 일이 벌어지는지에 대한 이야기예요.

먼저 deflate가 뭐냐면

gzip, zip, PNG 이미지… 이것들이 속으로 다 쓰는 압축 방식이 바로 deflate예요. 원리는 크게 두 가지를 조합한 거예요.

첫 번째는 LZ77이라는 기법인데요, 쉽게 말하면 “앞에서 나왔던 똑같은 부분을 또 적지 말고, ‘아까 그거 그대로’라고 가리키자”는 아이디어예요. 예를 들어 “서울 사람 서울 사람”이라는 문장이 있으면, 두 번째 “서울 사람”은 통째로 적는 대신 “몇 글자 앞에 있던 그 부분을 복사”라고만 적는 거죠. 반복이 많을수록 효과가 커요.

두 번째는 허프만 부호화(Huffman coding)예요. 자주 나오는 글자엔 짧은 코드를, 드물게 나오는 글자엔 긴 코드를 붙여서 전체 길이를 줄이는 방식이죠. 모스 부호에서 자주 쓰는 ‘E’를 짧게 표현하는 거랑 비슷한 발상이에요.

압축 ‘세기’는 뭘 조절하는 걸까

여기서 압축 레벨(세기)이 등장해요. 표준 zlib은 보통 1단계부터 9단계까지 있는데, 이 숫자가 클수록 압축기가 ‘반복되는 부분을 더 악착같이, 더 멀리까지 뒤져서 찾는다’는 뜻이에요. 대충 찾고 넘어가면 빠르지만 압축이 덜 되고, 모든 가능성을 샅샅이 뒤지면 파일은 작아지지만 시간이 오래 걸리죠.

그런데 일부 압축 구현체는 표준인 9단계를 넘어 더 높은 레벨을 제공하기도 해요. 이 글은 바로 그 극단적인 레벨까지 올렸을 때 어떤 일이 벌어지는지를 파헤쳐요. 결론부터 말하면 ‘지옥처럼 느리다’는 거예요. 레벨을 한두 칸 더 올리는 것만으로 압축 시간이 몇 배, 심하면 수십 배로 폭발하는데, 정작 줄어드는 파일 크기는 고작 몇 퍼센트, 때로는 1퍼센트도 안 되거든요.

왜 이런 일이 벌어질까

이게 바로 수확 체감(diminishing returns)의 전형이에요. 압축기가 더 좋은 매칭을 찾으려고 더 긴 후보 목록을 끝까지 비교하고, 여러 선택지 중 최적의 조합을 따지는 ‘최적 파싱’ 같은 무거운 작업을 하거든요. 탐색 범위를 두 배로 넓혔는데 정작 더 좋은 결과는 거의 안 나오는, 그런 비효율의 구간에 들어선 거예요. 들이는 노력은 기하급수로 늘어나는데 보상은 찔끔인 거죠.

더 나은 선택지들

재미있는 건, 요즘은 이렇게 deflate를 극한까지 쥐어짤 이유가 별로 없다는 거예요. 더 똑똑한 압축 알고리즘들이 나왔거든요. 페이스북이 만든 zstd(Zstandard)는 deflate보다 비슷하거나 더 좋은 압축률을 훨씬 빠른 속도로 내줘서 요즘 사실상 표준처럼 쓰이고 있어요. 구글의 brotli는 특히 웹 텍스트 압축에서 강하고, lz4는 압축률은 좀 양보하더라도 속도가 미친 듯이 빨라서 실시간 처리에 잘 맞아요.

그러니까 “deflate 레벨을 끝까지 올려서 1퍼센트 더 줄일까”를 고민할 시간에, 차라리 zstd 같은 현대 알고리즘으로 갈아타는 게 압축률·속도 둘 다 이기는 길인 경우가 많아요.

한국 개발자에게는?

실무에서 이건 의외로 자주 마주치는 함정이에요. “압축은 셀수록 좋은 거 아냐?” 하면서 무심코 최고 레벨을 박아두는 경우가 많거든요. 그런데 웹 서버에서 매 응답마다 최고 레벨로 압축하면, 파일은 찔끔 작아지는데 서버 CPU는 불타고 응답은 느려져요. 정작 사용자가 받는 이득은 거의 없고요.

CI 빌드에서 산출물을 압축할 때도 마찬가지예요. 빌드 시간이 압축 때문에 몇 분씩 늘어나는데 결과물 크기 차이는 미미하다면, 그건 명백한 손해죠. ‘압축 레벨은 무조건 최대’가 아니라, 내 상황에서 속도와 크기의 균형점을 찾는 것이 핵심이에요. 한 번 올려두고 여러 번 내려받는 정적 파일이라면 미리 세게 압축해둘 만하지만, 실시간으로 매번 압축하는 거라면 중간 레벨이 훨씬 합리적이거든요.

정리하며

핵심 한 줄. 압축 레벨을 끝까지 올리는 건 대부분 노력 대비 손해다. 진짜 필요한 건 더 높은 레벨이 아니라 더 똑똑한 알고리즘이다.

여러분은 프로젝트에서 압축 레벨이나 알고리즘을 의식적으로 골라 쓰는 편이세요, 아니면 기본값 그대로 두고 계셨나요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.