AI로 짠 코드가, AI의 토큰을 아낀다 — 넷플릭스 엔지니어의 Headroom을 까보고

지난 글에서 트렌딩 레포 네 개를 까보며 “사람들이 진짜 원한 건 더 똑똑한 모델이 아니라 모델 주변”이라고 썼다. 이번 달 또 하나가 그 흐름을 정확히 탔다. Headroom — 넷플릭스 시니어 엔지니어 Tejas Chopra가 만든 오픈소스로, LLM에 프롬프트가 도달하기 전에 컨텍스트(툴 출력·로그·RAG 청크·파일·대화 기록)를 압축해 토큰을 60~95% 줄여준다. 1월에 공개됐는데 누적 2,000억 토큰, 약 $70만을 아꼈다고 주장한다.

늘 하던 대로 /tmp에 클론해서 코드를 읽었다. 압축 엔진이 마케팅 문구만큼 진짜인지 보려고. 결론부터 — 진짜였다. 그런데 코드를 읽다가 더 흥미로운 걸 발견했다. 이 도구가 어떻게 만들어졌는지가 레포 곳곳에 노골적으로 남아 있었고, 그게 도구 자체보다 더 많은 걸 말해주고 있었다.

무슨 수요에 답하나 — “에이전트가 토큰을 너무 먹는다”

지난 글의 codegraph가 답한 문제와 뿌리가 같다. 코딩 에이전트를 써본 사람은 안다. 로그 한 번 붙이면 수만 토큰, grep 결과 100줄, 거대한 JSON 응답 — 정작 모델이 필요로 하는 건 그중 몇 줄인데, 나머지가 전부 컨텍스트 창을 채우고 과금된다. 게다가 컨텍스트가 길어질수록 회수 정확도는 떨어진다(context rot).

Headroom의 답은 “모델에 닿기 전에 가지치기”다. 에이전트와 LLM 사이에 끼어서, 보내려는 내용을 콘텐츠 타입별로 알아서 압축한다. 데모의 한 줄이 핵심을 요약한다 — 10,144 토큰을 1,260으로 줄였는데, 찾던 FATAL 로그는 그대로 있었다. 비용은 1/8인데 답은 같다는 것.

5개월 만에 1,389 커밋, 외부 기여자 수십 명, v0.22 — 이 숫자들이 모인다는 건 “에이전트가 토큰을 너무 먹는다”가 누군가의 막연한 불편이 아니라 돈이 새는 실재하는 고통이라는 뜻이다.

코드를 까보니 — 압축은 진짜였다

마케팅 톤이 강한 README라 의심부터 했다. “압축”이라더니 사실은 그냥 잘라내는(truncate) 거 아닐까? 아니었다. 엔진이 콘텐츠 타입별로 갈라져 있고, 각각 제대로 된 기법을 쓴다.

JSON(SmartCrusher) — Rust로 구현. 필드별 분산을 분석해 변화 없는 행, 서로 닮은 행을 골라 버리되 앞 30%·뒤 15%는 경계로 보존한다. 단순 자르기가 아니라 “중복을 식별해서” 버린다.
코드(CodeCompressor) — tree-sitter로 AST를 파싱한다. 호출 그래프를 분석해 어떤 함수가 중요한지 점수를 매기고, 본문을 완전한 구문(statement) 단위로 절단한다. 시그니처·import·타입 주석은 남긴다. 표현식 중간을 끊어 문법을 깨뜨리지 않는다.
산문(Kompress-base) — 진짜 ML 추론이다. HuggingFace에서 ModernBERT 기반 모델을 내려받아, 토큰마다 “남길지 버릴지”를 이진 분류한다. 휴리스틱 흉내가 아니라 학습된 모델이 돈다.
로그·검색·diff — 역시 Rust. 로그 레벨로 점수를 매기고, 스택 트레이스는 상태 머신으로 끝까지 보존한다.

가장 인상적이었던 건 설계 철학 하나였다. 의존성(tree-sitter, ML 모델)이 설치돼 있지 않으면, 어설픈 휴리스틱으로 대충 압축하는 게 아니라 원본을 그대로 통과시킨다. “조용한 fallback 금지” — 압축할 자신이 없으면 손대지 않는다. 토큰을 아끼겠다고 정보를 망가뜨리는 것보다, 못 아끼는 게 낫다는 판단이다. 이건 정직한 엔지니어링이다.

언제 쓰면 좋은가 코딩 에이전트를 매일 돌리는데 토큰 청구서가 부담될 때. headroom proxy로 코드 한 줄 안 바꾸고 끼울 수 있고, headroom wrap claude 한 줄로 에이전트를 감쌀 수 있다. 데이터는 로컬에 머문다(아래 단서 참고).

그리고 README와 코드 사이의 거리

진짜인 만큼, 과장도 있었다. 균형을 위해 짚는다. (AI가 만든 코드는 한 줄당 더 길게 봐야 한다는 게 블로그 #11의 결론이기도 했다.)

CacheAligner — README의 아키텍처 그림엔 “KV 캐시가 실제로 히트하도록 프리픽스를 안정화한다”는 당당한 박스가 있다. 코드를 열어보면 이 모듈은 현재 탐지만 하는 no-op이고 기본 비활성이다. 예전의 프리픽스 재작성 경로는 “시스템 프롬프트(캐시 핫존)는 절대 변형하면 안 된다”는 불변식을 위반해서 제거됐다는 주석이 그대로 남아 있다. 그림이 약속하는 것과 실제 동작 사이에 거리가 있다.

CCR(reversible compression) — “원본은 절대 삭제되지 않고, LLM이 필요하면 되찾는다”는 게 핵심 셀링 포인트다. 코드를 보면 원본은 로컬 메모리에 해시 키로 보관되고, LLM이 headroom_retrieve(hash)라는 MCP 도구를 직접 호출해야 복구된다. 단서가 둘 있다. (1) 모델이 끝내 호출하지 않으면 정보는 그냥 사라진다. (2) 보관에는 5분 TTL(프록시 모드)이 걸려 있다. “reversible”은 맞지만 영구 보관이 아니라 5분짜리 임시 캐시다.

흠집을 내려는 게 아니다. 이건 잘 만든 도구다. 다만 README의 그림과 실제 코드를 같은 무게로 믿으면 안 된다는 것 — AI 시대에 오픈소스를 평가하는 기본기다.

가장 흥미로운 신호 — 이 도구는 AI로 만들어졌다

여기서부터가 진짜 하고 싶은 얘기다. 코드를 읽다 보니 레포 루트에 REALIGNMENT/라는 폴더가 있었다. 열어보니:

REALIGNMENT/
  00-overview.md
  01-bug-list.md          (26KB)
  02-architecture.md
  03-phase-A-lockdown.md
  04-phase-B-live-zone.md
  05-phase-C-rust-proxy.md
  ... phase-D ~ phase-I ...
  12-decisions-needed.md

이건 사람이 노트로 끄적인 게 아니다. 에이전트에게 던지는 대규모 리팩토링 작업 명세서다. 버그 리스트, 단계별(phase-A~I) 실행 계획, “결정이 필요한 항목” 목록 — 코딩 에이전트가 한 단계씩 집어 처리하라고 차려놓은 밥상이다. 코드 주석도 마찬가지였다. 곳곳에 PR-A2 / P2-23 fix, invariant I2를 위반해서 제거됨 같은, 사람이 손으로 달기엔 너무 기계적이고 추적 번호가 붙은 흔적이 깔려 있다.

즉 Headroom은 AI 에이전트(정황상 클로드 같은)로 개발된, AI 에이전트의 토큰을 아끼는 도구다.

이 재귀가 이 글의 핵심이다. 한 발 물러서서 보면 이런 그림이다.

에이전트가 토큰을 너무 먹는다 → 그걸 줄이는 도구를 만들자 → 그 도구를 에이전트로 만든다 → 그 과정에서 또 토큰을 태운다 → …

블로그 #14에서 “에이전트 엔지니어가 진짜 설계하는 건 모델 바깥의 레이어”라고 썼다. Headroom은 그 명제를 가장 극단적으로 증명한다. 도구의 기능(컨텍스트 압축)도 모델 주변 레이어고, 도구의 제작 방식(에이전트 주도 개발)도 모델 주변 레이어다. 안과 밖이 같은 문제를 다루고 있다.

그래서 무엇이 보이나

① 컨텍스트는 이제 명시적으로 ‘관리하는 비용’이다. 한때 컨텍스트 창은 그냥 채우는 거였다. 이제는 무엇을 넣고 무엇을 버릴지가 돈이고 정확도다. Headroom 같은 도구에 $70만 절감 서사가 붙고 별이 모이는 건, 토큰이 청구서의 한 줄이 됐다는 뜻이다. 압축은 그 청구서를 깎는 첫 번째 레버다.

② 압축은 도구가 하지만, ‘무엇을 남길지’는 여전히 설계의 몫이다. SmartCrusher가 앞 30%·뒤 15%를 남기는 것도, CodeCompressor가 시그니처를 보존하는 것도 전부 누군가의 판단이 코드로 굳은 것이다. 도구가 자동화하는 건 실행이지 판단이 아니다. 컨텍스트 엔지니어링이 사라지는 게 아니라, 도구 안으로 들어가 굳는 것이다.

③ “AI로 만든 코드”는 곧 평범해진다 — 그래서 읽는 법이 중요해진다. Headroom이 특이해서 AI로 만들어진 게 아니다. 곧 대부분의 활발한 OSS가 이렇게 만들어질 것이다. REALIGNMENT/phase-A~I 같은 산출물이 레포에 남는 게 흠이 아니라 기본값이 된다. 그럴수록 평가자에게 필요한 건 README가 아니라 코드를, 그림이 아니라 동작을 보는 눈이다. CacheAligner가 no-op이라는 걸 그림만 보고는 알 수 없다.

마치며

처음엔 “60~95% 압축이 진짜인가” 하나만 확인하려 했다. 압축은 진짜였다(과장 둘은 덤으로 찾았다). 그런데 코드를 끝까지 읽고 나니, 더 오래 남는 그림은 따로 있었다.

AI가 AI의 비용 문제를 푸는 도구를, AI로 만들고 있다. 이 재귀가 어색하지 않게 느껴진다면, 그게 바로 컨텍스트 엔지니어링이 취미에서 산업으로 넘어갔다는 신호다. 모델은 충분히 강하다. 이제 사람들은 그 모델을 무엇을 먹이고, 얼마나 효율적으로 굴리고, 안에 뭐가 들어가는지 들여다보는 데 돈과 코드를 쓴다 — 심지어 그 일조차 모델에게 시키면서.

다음에 트렌딩 레포를 까면 던질 질문이 하나 늘었다. “이건 무슨 문제를 푸는가” 옆에 — “이건 어떻게 만들어졌는가, 그리고 그게 무엇을 말해주는가.”

참고 자료

Headroom (chopratejas/headroom) — LLM 컨텍스트 압축 레이어 (라이브러리·프록시·MCP)
Kompress-base on HuggingFace — 텍스트 압축에 쓰이는 모델
관련 글: 트렌딩 레포 4개로 읽는 개발자의 진짜 수요 · 에이전트 엔지니어가 진짜 설계하는 것 · 인지 부채와 에이전트 코딩