Headroom 으로 LLM 컨텍스트 60% 압축, 사내 AX 에 붙일 때 평가
LLM 토큰 비용을 60-95% 줄이는 오픈소스 Headroom 을 사내 AX 컨텍스트에서 평가한 노트입니다. Karpathy 의 LLM OS 비유에서 RAM 압축 layer 역할이고 사내 시스템 AI 도입의 컨텍스트 윈도우 한계를 정면으로 풉니다. 강점 4 가지와 한계 4 가지를 정리했습니다.
오늘 GitHub 트렌딩에서 Headroom 이라는 오픈소스를 봤습니다. LLM 에 들어가는 토큰을 60% ~ 95% 압축해주는 도구입니다. 이전 ChatGPT Agent OS 글에서 사내 AX 도입의 함정 1 번으로 적은 "컨텍스트 윈도우 한계" 를 정면으로 푸는 접근입니다.
이 글은 베비투스랩이 실제 운영 투입한 경험은 없는 도구입니다. 공식 문서·GitHub 코드·라이선스 기준으로 평가한 노트입니다.
핵심 결론부터 말씀드리면 Headroom 은 Karpathy 의 LLM OS 비유에서 "RAM 페이지 압축" 역할을 합니다. 진짜 OS 가 가상 메모리·스왑으로 한정된 RAM 을 효율적으로 쓰듯 Headroom 은 컨텍스트 윈도우를 압축으로 늘립니다.
Headroom 의 정체
github.com/chopratejas/headroom. 2026 년 1 월 출시. 별 1.4 만, 포크 약 1 천. Apache-2.0 라이선스 (표준 OSS, 깔끔). Python 중심.
도구 출력·로그·RAG 청크·파일을 LLM 에 보내기 전에 압축합니다. 60% ~ 95% 토큰 절감이 가능하다고 명시합니다.
핵심 기능 4 가지입니다.
첫째 Content-aware compression. JSON 은 SmartCrusher, 코드는 CodeCompressor (AST 기반), 일반 텍스트는 Kompress-base 가 처리합니다.
둘째 Reversible compression. 원본은 로컬에 저장되고 LLM 이 필요할 때 가져옵니다.
셋째 Cross-agent memory. Claude·Codex·Gemini 간 공유 컨텍스트와 자동 중복 제거가 됩니다.
넷째 Cache alignment. provider KV cache hit 률을 안정화합니다.
배포는 4 가지 모드입니다. Python/TypeScript 라이브러리, 프록시, 에이전트 래퍼, MCP 서버.
Karpathy 의 LLM OS 에서 Headroom 의 위치
이전 글에서 정리한 Karpathy 의 LLM OS 비유를 다시 보면 RAM 은 컨텍스트 윈도우입니다. 진짜 OS 의 RAM 은 페이지 교체와 압축으로 한정된 물리 메모리를 효율적으로 굴립니다. Linux 의 zswap, macOS 의 메모리 압축 같은 메커니즘입니다.
Headroom 이 정확히 같은 layer 입니다. 압축으로 컨텍스트 RAM 의 유효 용량을 늘리고 필요 시 원본으로 복원합니다.
이게 사내 AX 컨텍스트에서 의미 있는 이유는 단순합니다. ChatGPT Agent 나 Claude API 를 사내 시스템에 붙일 때 가장 자주 부딪히는 함정이 컨텍스트 윈도우 한계입니다. 5 년치 회의록·ERP 영업 기록·CRM 고객 데이터를 한 번에 못 넣습니다. RAG (벡터 DB) 가 우회 전략이지만 RAG 자체의 정확도 문제와 추가 architecture 부담이 생깁니다.
Headroom 은 다른 접근입니다. RAG 가 "디스크 검색" 이라면 Headroom 은 "RAM 압축" 입니다. 이미 컨텍스트에 넣어야 할 데이터를 60% ~ 95% 적은 토큰으로 보내고 LLM 이 필요할 때 원본을 가져옵니다.
사내 AX 에 붙일 때의 강점
1. 토큰 비용 직접 절감
60% ~ 95% 토큰 압축이 사실이라면 운영 비용에 직접 영향입니다. 사내 시스템 AI 도입의 5 가지 패턴 중 하나가 "데이터 분석 보고 자동화" 인데 매주·매월 정기 보고서 자동 생성에 들어가는 LLM 비용이 가장 큰 비중입니다. Headroom 이 그 비용을 한 자릿수로 줄일 수 있다면 ROI 가 직접 올라갑니다.
2. Apache-2.0 라이선스
이전 OpenClaw 의 NOASSERTION 라이선스와 비교해 깔끔합니다. 상업적 사용·수정·재배포 모두 자유입니다. 사내 도입 결정 시 변호사 검토 부담이 적습니다.
3. 4 가지 배포 모드
라이브러리 (Python/TS), 프록시, 에이전트 래퍼, MCP 서버 4 가지로 도입 깊이를 선택할 수 있습니다. 가장 가벼운 시작은 프록시. 기존 LLM API 호출 앞에 끼워 넣기만 하면 됩니다.
4. Cross-agent memory
Claude·Codex·Gemini 간 공유 컨텍스트. 사내 자동화에서 하나의 작업이 여러 LLM 도구를 거치는 경우 (예 코드 작성은 Claude, 리뷰는 GPT-5) 컨텍스트가 자동으로 이어집니다.
사내 AX 에 붙일 때의 한계와 위험
1. 압축 손실 위험
60% ~ 95% 압축이 정말 의미를 보존하는가가 핵심 질문입니다. 도구의 주장은 "same answers" 이지만 사내 시스템 특수 도메인 (의료 용어·법무 조문·사내 줄임말) 에서 동일한 정확도가 유지되는지는 직접 측정해야 합니다.
이전 글에서 정리한 Karpathy 의 "5 의 9" 관점이 그대로 적용됩니다. 90% 정확도면 데모 단계입니다. 사내 자동 결재까지 가려면 99.9% 이상 정확도가 필요한데 압축이 그 9 의 개수를 줄이지 않는다는 보장이 필요합니다.
2. Reversible compression 의 추가 호출 비용
원본 복원 시 LLM 의 추가 호출이 일어납니다. 압축으로 절감한 토큰을 복원 호출로 다시 쓰면 순 절감이 작아질 수 있습니다. 실제 사용 패턴에 따라 측정해야 합니다.
3. 신생 프로젝트의 API 변화 위험
2026 년 1 월 출시. 약 5 개월 된 도구입니다. 별 1.4 만은 빠른 성장이지만 그만큼 breaking change 위험도 큽니다. 사내 시스템에 깊이 통합하면 매 버전 업그레이드마다 검증 부담이 생깁니다.
4. 사내 도메인 특화 압축 알고리즘 부재
JSON·AST·일반 텍스트 3 가지 압축기를 기본 제공하지만 사내 시스템의 특수 데이터 (의료 차트·금융 거래·법무 조문) 에 최적화된 압축기는 직접 만들어야 합니다. 그 부분이 누가 책임지느냐가 도입 결정의 변수입니다.
베비투스랩의 결론
Headroom 은 사내 AX 도입의 컨텍스트 윈도우 함정을 정면으로 푸는 도구입니다. Karpathy 의 LLM OS 비유에서 RAM 압축 layer 를 채우고 비용 ROI 에 직접 영향을 줍니다.
다만 베비투스랩이 매일 쓰는 5 가지 하네스 관점에서 보면 Headroom 도 "코어 엔진" 이지 "완제품" 이 아닙니다. 사내 시스템에 붙이려면 quality gate (압축 손실 측정), permissions (어떤 데이터까지 압축할지), sub-agent isolation (압축기 종류 분리), monitoring (압축률 vs 정확도 모니터링) 4 가지 하네스가 추가로 필요합니다.
가장 안전한 도입 순서는 단순합니다. 프록시 모드로 가장 가볍게 시작합니다. 첫 3 개월은 정확도 측정 기간으로 잡습니다. 압축이 사내 도메인에서 의미를 보존하는지 그리고 정확도 9 의 개수를 줄이지 않는지 측정합니다. 그 다음 단계적으로 라이브러리·MCP 서버 통합으로 깊이를 늘립니다.
도구 (Headroom·RAG·ChatGPT Agent 등) 는 갈아끼울 수 있습니다. 그러나 압축 손실을 측정하고 9 의 개수를 솔직히 잡는 운영 architecture 는 5 년을 갑니다. 이게 시니어 PE 가 채워야 하는 부분이고 베비투스랩이 4 가지 약속 중 Foundation 을 첫 약속으로 두는 이유입니다.
솔직히 말씀드리면 베비투스랩도 Headroom 을 클라이언트 시스템에 직접 투입한 경험은 아직 없습니다. 6 개월 자체 운영해보고 한계를 직접 체득한 다음 권하는 단계로 가야 합니다. 그때까지는 "참고할 만한 외부 도구" 단계에 둡니다.
우리 회사 LLM 비용이 운영 부담이 되고 있다면 3 분 AX 진단 으로 회사 단계부터 확인하시거나 30 분 무료 상담 에서 압축·캐싱 architecture 를 함께 정리합니다.
공유