압축이 곧 예측이다: gzip부터 LLM까지 관통하는 하나의 원리

“파일을 잘 압축하는 것과 다음에 올 데이터를 잘 예측하는 것은 수학적으로 같은 문제다.” ngrok 엔지니어링 블로그에 올라온 글이 파고드는 문장인데요. ngrok은 로컬 서버를 인터넷에 노출시켜주는 터널링 서비스를 만드는 회사예요. 터널로 오가는 트래픽의 대역폭을 줄이려고 압축을 연구하다가, 아예 압축이라는 주제의 밑바닥까지 내려가 본 기록이에요. 읽고 나면 gzip과 GPT가 같은 뿌리에서 나온 물건이라는 게 보이거든요.

섀넌이 남긴 공식 하나

출발점은 정보 이론의 아버지 클로드 섀넌이에요. 어떤 심볼(문자, 바이트)이 나올 확률이 p라면, 그 심볼을 표현하는 데 필요한 최적의 비트 수는 -log₂(p)라는 게 섀넌의 결론이거든요. 이게 무슨 뜻이냐면, 자주 나오는 것은 짧은 코드로, 드물게 나오는 것은 긴 코드로 적으면 전체 크기가 최소가 된다는 거예요. 그러니까 “다음 바이트가 뭘지 잘 맞히는 예측기”만 있으면, 그 확률을 코드 길이로 바꿔주는 기계적인 절차를 거쳐 최고의 압축기가 되는 거죠. 예측과 압축은 동전의 양면인 셈이에요.

글에서는 이걸 말로만 하지 않고 Go 언어 60줄짜리 산술 부호화(arithmetic coding) 코드로 직접 보여줘요. 산술 부호화가 뭐냐면, 예측기가 내놓은 확률 분포를 받아서 데이터 전체를 0과 1 사이의 아주 긴 소수 하나로 인코딩하는 기법이에요. 재미있는 건 인코더는 그대로 두고 예측기만 갈아끼우는 실험인데요. 모든 바이트가 똑같은 확률로 나온다고 가정하는 균등 예측기, 바이트별 빈도를 세는 예측기, 앞의 두 바이트를 보고 다음을 맞히는 문맥 예측기 순으로 바꿔 끼우니까, 100KB짜리 HTTP 로그가 12KB까지 줄어들어요. 압축률을 결정하는 건 인코더가 아니라 예측기라는 사실이 눈으로 확인되는 거죠.

현대 압축기는 '트렌치코트를 입은 예측기'

zstd나 Brotli 같은 요즘 압축기들도 결국 같은 구조예요. zstd의 FSE/tANS 엔트로피 단계, Brotli의 문맥 모델링, 그리고 PPM/PAQ 계열까지, 전부 “데이터를 얼마나 잘 예측하느냐”로 성능이 갈려요. 글에서는 이걸 “예측기가 트렌치코트를 입고 압축기인 척하는 것”이라고 표현해요.

그럼 예측을 제일 잘하는 물건은 뭘까요? 요즘이라면 LLM이죠. 실제로 딥마인드는 'Language Modeling Is Compression'이라는 논문에서 언어 모델 Chinchilla를 압축기로 썼더니, 이미지에서는 PNG를, 오디오에서는 FLAC을 능가하는 압축률이 나온다는 걸 보여줬어요. 텍스트만 배운 모델인데도요. 반대 방향도 성립해요. 한때 유명했던 'gzip이 BERT를 이긴다'는 실험, 그러니까 gzip 압축 크기를 유사도 척도로 삼아 kNN으로 텍스트를 분류하는 트릭이 바로 “압축을 잘하면 이해한 것이다”의 사례거든요.

그래서 ngrok은 뭘 했나

실무 파트가 알짜예요. ngrok은 터널 트래픽 중 반복적인 JSON API 트래픽에 딕셔너리 학습(dictionary training)을 적용한 zstd 모드를 프로토타이핑했는데, 일반 zstd 대비 약 3.4배의 압축률을 CPU 부담 거의 없이 얻었대요. 딕셔너리 학습이 뭐냐면, 자주 오가는 데이터 샘플을 미리 분석해서 '이 트래픽에 특화된 사전'을 만들어두는 거예요. 흥미로운 건 ML 예측기를 실시간 경로에 넣지 않기로 한 이유도 솔직하게 적었다는 점이에요. 지연 시간, 결과가 매번 달라질 수 있는 비결정성, 버전 간 딕셔너리 불일치 문제 때문이라고요. 이론적으로 최선인 것과 프로덕션에 넣을 수 있는 것 사이의 간극을 보여주는 좋은 사례죠.

한국 개발자 입장에서 바로 써먹을 수 있는 건 zstd 딕셔너리 모드예요. 마이크로서비스 간 JSON 통신이나 로그 저장처럼 비슷한 구조의 데이터가 반복되는 곳이라면 설정 몇 줄로 큰 이득을 볼 수 있거든요. 그리고 정보 이론 기초는 LLM 시대에 오히려 더 중요한 교양이 됐어요. '손실 압축으로서의 LLM' 같은 논의를 제대로 따라가려면 결국 섀넌부터 시작해야 하니까요.

한 줄 정리: 더 좋은 압축을 원하면 데이터를 더 잘 예측하는 모델을 만들면 되고, 모델이 데이터를 얼마나 이해했는지 궁금하면 압축을 시켜보면 돼요. 여러분 서비스에는 어디에 압축 최적화 여지가 남아 있을까요? zstd 딕셔너리를 실무에서 써보신 분이 있다면 경험담도 궁금하네요.