압축 프로그램이 다음 글자를 맞힌다고요?
gzip이라고 하면 보통 배포 파일 용량을 줄이거나 웹 서버에서 응답을 압축할 때 쓰는 도구로만 알고 계실 거예요. 그런데 이 gzip을 '언어 모델'처럼 써서 다음 글자를 예측하고 텍스트를 생성해보는 실험이 있어요. 장난처럼 들리지만, 이 실험은 정보 이론에서 아주 오래된 통찰 하나를 손으로 직접 만져보는 거거든요. 바로 '압축을 잘하는 것과 다음에 뭐가 올지 잘 예측하는 것은 사실 같은 문제다'라는 이야기예요.
이게 뭐냐면, 압축기는 자주 나오는 패턴에 짧은 코드를, 드물게 나오는 패턴에 긴 코드를 배정해서 전체 크기를 줄여요. 어떤 문자열이 나올 확률이 p라면 가장 효율적인 코드 길이는 -log2(p) 비트라는 게 섀넌의 정보 이론이고요. 그러니까 '다음 글자가 뭘지'에 대한 확률 분포를 정확히 아는 만큼 압축이 잘 되고, 반대로 압축이 잘 된다는 건 그만큼 좋은 확률 모델을 갖고 있다는 뜻이에요. 실제로 2023년 딥마인드가 낸 논문 'Language Modeling Is Compression'에서는 대형 언어 모델을 산술 부호화와 결합해 압축기로 썼더니 이미지는 PNG보다, 오디오는 FLAC보다 더 작게 압축했다는 결과를 보여줬어요. 언어 모델이 곧 압축기라는 걸 실험으로 증명한 셈이죠.
gzip을 언어 모델로 쓰는 트릭
그럼 반대 방향은 어떨까요? 압축기를 언어 모델로 쓰는 거요. 방법은 의외로 단순해요. 지금까지의 문맥 뒤에 후보 글자를 하나씩 붙여서 압축해보고, 압축 결과가 가장 조금 늘어나는 후보를 '가장 그럴듯한 다음 글자'로 보는 거예요. 압축기가 덜 놀란다는 건 그 글자가 예상 범위 안에 있었다는 뜻이니까요.
조건부 확률로 표현하면 이렇게 근사할 수 있어요.
delta = len(gzip(context + c)) - len(gzip(context))
P(c | context) ∝ 2 ** (-delta)
후보 글자마다 delta를 구해서 소프트맥스처럼 정규화하면 확률 분포가 나오고, 거기서 샘플링하면 텍스트가 생성돼요. 파이썬이면 zlib 모듈로 몇 줄이면 짜져요. 학습 데이터 역할은 context 앞에 붙여둔 말뭉치가 대신하고요.
그런데 gzip의 속을 알면 결과가 왜 그렇게 나오는지 이해가 돼요. gzip은 DEFLATE라는 알고리즘을 쓰는데, 이건 LZ77과 허프만 코딩의 조합이에요. LZ77이 뭐냐면 '앞에서 나왔던 문자열이 또 나오면, 그걸 다시 쓰는 대신 몇 바이트 앞에 있던 걸 몇 글자 복사하라는 참조로 바꾸는' 방식이에요. 그러니까 gzip 언어 모델은 결국 말뭉치에서 이미 본 구절을 이어 붙이는 것을 가장 좋아하게 돼요. 통계적으로 보면 가변 길이 n-gram 모델에 가깝죠. 문법 비슷한 흉내는 내지만 의미를 이해하는 것과는 거리가 멀어요.
한계도 분명해요. 첫째, LZ77의 참조 창이 32KB라서 그보다 앞의 문맥은 아예 못 봐요. 둘째, 출력 크기가 바이트 단위인 데다 허프만 블록 경계 때문에 계단식으로 변해서, 글자 하나 차이가 압축 길이에 아예 반영되지 않는 경우가 많아요. 그러면 여러 후보의 delta가 똑같아져서 확률 분포가 뭉개져요. 셋째, 후보마다 압축을 통째로 다시 돌려야 하니까 엄청나게 느려요. 그래서 이건 실용적인 모델이라기보다 '압축 = 예측'이라는 원리를 확인하는 장난감이에요.
업계 맥락, gzip이 BERT를 이겼다던 그 논문
이 이야기가 낯설지 않다면 2023년에 나온 'gzip + kNN이 BERT를 이긴다'는 논문을 기억하실 거예요. 두 문서를 각각 압축한 크기와 합쳐서 압축한 크기를 비교하는 NCD(정규화 압축 거리)로 텍스트 분류를 했더니 학습 없이도 BERT급 성능이 나왔다는 내용이었죠. 나중에 평가 코드의 kNN 동점 처리 방식에 문제가 있어서 성능이 과장됐다는 게 밝혀지긴 했지만, 압축 기반 접근이 완전히 틀린 건 아니에요. 위키피디아 1GB를 가장 작게 압축하는 사람에게 상금을 주는 Hutter Prize는 아예 '압축이 곧 지능'이라는 전제로 20년 가까이 운영되고 있고요. 트랜스포머가 잘하는 것도 결국 엄청나게 정교한 압축이라고 보면, gzip 실험은 그 스펙트럼의 가장 단순한 끝에 있는 셈이에요.
한국 개발자에게 주는 시사점
실무에서 gzip으로 챗봇을 만들 일은 당연히 없어요. 하지만 배워둘 만한 게 세 가지 있어요.
첫째, NCD는 여전히 쓸 만한 도구예요. 문서 중복 탐지, 로그 클러스터링, 언어 감지 같은 작업에서 모델 학습 없이 빠르게 기준선을 잡을 때 zlib 몇 줄로 끝나거든요. 임베딩 API 비용을 쓰기 전에 '이 정도로 충분한가'를 확인하는 용도로 좋아요.
둘째, 언어 모델의 손실 함수인 크로스 엔트로피가 곧 '한 토큰당 몇 비트로 압축되는가'라는 걸 몸으로 이해하게 돼요. perplexity 숫자가 낮을수록 좋다는 걸 외우는 것과, 그게 압축률이라는 걸 아는 건 다르거든요.
셋째, 모델을 평가할 때 벤치마크 점수 말고 '내 도메인 텍스트를 얼마나 잘 압축하는가'라는 관점을 하나 더 가질 수 있어요. 도메인 특화 데이터에 대한 압축률은 그 모델이 그 분야를 얼마나 '알고' 있는지에 대한 꽤 정직한 지표예요.
마무리
한줄 정리: gzip은 다음 글자를 예측할 수 있지만 그건 이미 본 구절을 복사하는 수준이고, 이 실험의 진짜 가치는 '좋은 압축기 = 좋은 예측기'라는 원리를 직접 확인하는 데 있어요.
여러분은 압축 기반 방법을 실무에서 써본 적 있으신가요? 임베딩 모델 대신 NCD 같은 단순한 방법으로 충분했던 경험, 혹은 반대로 실패했던 경험이 있다면 공유해 주세요.
🔗 출처: Hacker News