TL;DR

Headroom은 LLM에 전달되기 전의 툴 출력, 로그, 파일, RAG 청크를 대상으로 토큰 수를 크게 줄이는 미들웨어와 라이브러리·서버 구현을 제공한다. 프로젝트 설명에는 전송 토큰이 60~95% 줄어들고 응답은 동일하게 유지된다고 명시돼 있다. 이 프로젝트는 애플리케이션 내 라이브러리 호출, 프록시를 통한 가로채기, MCP 서버 형태의 중앙화된 전처리 등 복수의 배포 방식을 제공해 다양한 파이프라인에 통합 가능한 점을 핵심으로 삼는다. 핵심 작동은 전송 직전 텍스트 압축·청크 병합 같은 전처리를 적용해 LLM에 전달되는 토큰 볼륨을 축소하는 것이다. 이 접근은 입력 길이 제한과 토큰 기반 비용 문제를 직접적으로 완화할 여지를 보이지만, 품질·정합성 유지 조건과 압축 방법의 구체적 구현·제약(예: 손실 여부, 처리 지연)은 메타데이터만으로 확인되지 않는다. README·실험 코드·벤치마크 세부가 없으면 실제 성능과 트레이드오프는 검증이 필요하다.

주요 기능

• 툴 출력과 로그를 압축하여 전송 토큰 수를 줄임
• 파일과 RAG 청크의 청크 병합·압축을 수행
• 프록시로 요청을 가로채어 중간 처리(middleware) 역할 수행
• 라이브러리 형태로 애플리케이션에 직접 통합 가능
• MCP 서버 형태로 중앙화된 전처리 파이프라인 제공

어떻게 동작하는가

툴 출력·로그·파일·RAG 청크를 LLM에 전달하기 전에 가로채어 텍스트 압축·청크 병합 등의 전처리를 수행해 전송되는 토큰 수를 줄인다. 라이브러리 호출, 프록시 경유, 또는 MCP 서버로 배포하는 형태를 지원한다.

해결 문제

LLM으로 전송되는 툴 출력·로그·파일·RAG 청크의 토큰 수를 크게 줄여 입력 길이 문제를 완화한다.

차별점

• 전달 전 단계에서 압축을 수행해 '60-95% 적은 토큰'을 주장함
• 라이브러리·프록시·MCP 서버 등 여러 배포 형태를 동시에 제공함
• 압축 후에도 동일한 응답을 유지한다고 명시함(semantic fidelity 유지 주장)

사용 사례

• 툴 출력과 디버그 로그가 길어 LLM 입력 한도를 자주 초과하는 애플리케이션의 전처리 파이프라인
• RAG 파이프라인에서 청크 전처리를 통해 컨텍스트 길이를 줄이려는 상황
• 프록시 계층에서 모든 LLM 요청을 중앙 제어·전처리해야 하는 서비스 아키텍처

벤치마크