TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 28 READS

압축은 곧 예측이다: LLM과 데이터 압축이 같은 문제를 푸는 이유

압축은 곧 예측이다: LLM과 데이터 압축이 같은 문제를 푸는 이유
SOURCE IMAGE · HACKER NEWS

데이터를 줄이는 방법은 여러 가지지만, 그 원리를 파고들면 뜻밖의 결론에 닿는다. 압축기와 대규모 언어 모델(LLM)이 근본적으로 완전히 같은 문제, 즉 '다음에 무엇이 올지 예측하기'를 풀고 있다는 것이다. ngrok 블로그의 한 글은 압축의 기초부터 짚어가며 이 둘의 깊은 관계를 설명한다. 예측이 정확해질수록 데이터는 더 작아지고, 이 원리는 오늘날 언어 모델의 작동 방식과 직접 맞닿아 있다.

압축은 왜 '중복'을 먹고 사는가

코드를 줄이는 대표적 기법인 미니피케이션(minification)부터 보자. 이는 기계가 파싱하는 데 필요 없는 것을 걷어내는 방식이다. 사람이 읽기 쉬운 변수명을 한 글자로 줄이고, 공백과 주석을 지운다. 원문에서 든 예시에서는 이렇게 파일이 62자, 즉 60% 작아졌다. 그런데도 미니피케이션은 데이터 압축 분야에서 거의 언급되지 않는다. 이유는 단순하다. 미니피케이션은 그저 불필요한 문법을 버릴 뿐이지만, '진짜' 압축은 중복(redundancy)에 기대어 데이터를 응축하기 때문이다.

예를 들어 A가 9개, B가 4개, C가 2개, D가 1개, 다시 A가 3개, D가 9개로 이어지는 28자짜리 문자열을 생각해보자. 각 문자가 몇 번 반복되는지만 적으면 'A9B4C2D1A3D9'라는 12자로 줄어든다. 8비트 ASCII 기준으로 224비트가 96비트로, 57% 작아진다. 이것이 런렝스 인코딩(run-length encoding)이다. 다만 gzip, Brotli 같은 실제 압축기는 이보다 훨씬 정교하게, 여러 기법을 조합해 데이터를 줄인다.

압축기의 세 기관: 변환·모델·엔트로피 코더

현대 압축 도구는 크게 세 개의 '기관'으로 나눌 수 있다. 변환(transforms), 모델(models), 엔트로피 코더(entropy coders)다. 변환은 데이터를 압축하기 쉽게 만드는 전처리 단계로, 앞서 본 런렝스 인코딩이 그 예다. 흥미롭게도 변환이 항상 데이터를 줄이는 것은 아니다. 오히려 중복을 더 만들어내기 위해 쓰이기도 하는데, 중복이 많을수록 이후 단계에서 더 많이 압축할 수 있기 때문이다.

모델은 각 심벌(문자, 숫자, 토큰 등 중복을 찾는 단위)의 빈도를 바탕으로 데이터의 형태를 기술한다. 쉽게 말해 각 심벌을 그 확률에 대응시킨 표다. 마지막으로 엔트로피 코더는 이 확률들을 받아 최종 결과물, 즉 압축된 비트스트림을 만들어낸다. 확률이 들어가면 압축된 비트열이 나온다. 여기서 핵심은 모델이 넘겨준 확률의 품질이 압축의 성패를 좌우한다는 점이다.

하나의 숫자로 데이터를 표현하는 산술 부호화

확률이 어떻게 실제 압축으로 이어지는지 보려면 산술 부호화(arithmetic coding)가 좋은 예다. 이 방식은 데이터셋 전체를 단 하나의 숫자로 표현한다. 'ABABAAC'라는 7자 문자열에서 각 문자의 확률을 구하면, A는 0부터 0.571, B는 0.571부터 0.857, C는 0.857부터 1까지의 구간을 차지한다. 문자를 하나씩 읽을 때마다 그 문자의 구간에 맞게 범위를 좁혀 나가면, 마지막에는 [0.38730, 0.38855)라는 아주 작은 범위가 남는다. 이 범위 안의 숫자 하나(0.3876953125)면 문자열 전체를 복원할 수 있다. 원래 56비트가 필요하던 문자열이 단 10비트로 줄어드는 셈이다. 복원할 때는 압축에 쓴 것과 같은 확률표를 이용해, 그 숫자가 어느 구간에 들어가는지를 따라가며 문자를 하나씩 되찾는다.

여기서 결정적인 사실이 드러난다. 데이터가 한쪽으로 치우칠수록, 즉 특정 심벌의 확률이 높을수록 압축률이 좋아진다는 것이다. A가 10개, B와 C가 하나씩인 문자열(A의 확률 0.833)은 심벌당 평균 0.82비트로 압축된 반면, 앞선 문자열은 1.38비트가 필요했다. 이 '심벌당 평균 비트 수'가 바로 엔트로피이며, 압축의 근간이다.

엔트로피, 그리고 예측이 압축을 결정한다

엔트로피의 직관은 '스무고개'로 설명할 수 있다. 어떤 동물을 맞힐 때 흔한 동물일수록 적은 질문으로, 드문 동물일수록 많은 질문으로 도달한다. 예/아니오 결정 트리에서 각 갈래를 1과 0으로 바꾸면, 질문 횟수가 곧 그 심벌을 표현하는 데 필요한 비트 수가 된다. 흔한 새(bird)는 '1', 드문 곰(bear)은 '0000'처럼 긴 코드워드를 받는다. 이렇게 심벌마다 코드워드를 부여하는 방식이 허프만 부호화(Huffman coding)이며 gzip과 Brotli에도 쓰인다. 다만 확률이 정확히 절반으로 나뉘지 않을 때는 비트를 반올림해야 하고, 그만큼 불필요한 비트를 지불하게 된다. 수학적으로 한 심벌에 필요한 최소 비트는 -log2(확률)이고, 모든 심벌에 대한 그 평균이 엔트로피다.

중요한 것은 엔트로피가 '바닥'이라는 점이다. 주어진 확률 분포에서 심벌당 이보다 더 적은 비트로 압축하는 것은 불가능하다. 그렇다면 왜 모든 데이터를 압축하는 만능 압축기가 없을까. 엔트로피는 특정 확률 분포에 종속되기 때문이다. 확률 분포를 더 치우치게 만들 수 있다면, 더 많이 압축할 수 있다. 그리고 확률 분포를 개선하는 열쇠가 바로 문맥(context)이다. 영어 전체에서 U의 확률은 약 0.028에 불과하지만, 바로 앞에 Q가 오면 약 0.999로 치솟는다. 문맥을 알수록 다음 심벌을 더 정확히 예측할 수 있고, 예측이 정확할수록 더 적은 비트로 압축된다.

바로 이 지점이 LLM과 압축이 만나는 자리다. 언어 모델이 하는 일도 결국 '주어진 문맥에서 다음 토큰의 확률 분포를 추정하는 것'이며, 압축기가 원하는 것과 정확히 같다. 실무자 입장에서 이 관점은 두 가지를 시사한다. 첫째, 더 좋은 모델(더 정확한 예측)은 곧 더 좋은 압축이라는 등가 관계이므로, LLM의 성능을 '다음 심벌을 얼마나 낮은 비트로 표현하느냐'로 바라볼 수 있다. 둘째, 엔트로피라는 이론적 하한이 존재하는 만큼, 어떤 압축도 데이터에 담긴 정보량 자체를 뛰어넘을 수는 없다. 다만 이 글은 산술 부호화와 허프만 부호화라는 두 엔트로피 코더, 그리고 빈도·문맥 기반 모델까지를 다루는 입문적 설명에 초점을 두고 있어, 실제 상용 압축기의 변환 단계나 LLM의 구체적 학습 메커니즘까지 파고들지는 않는다. 그럼에도 '압축은 곧 예측'이라는 한 문장은, 두 기술을 하나의 렌즈로 다시 보게 만드는 값진 출발점이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://ngrok.com/blog/compression-is-prediction
SHARE
처리 중...