Agents · ARTICLE · 2026

Building Cost-Efficient Agents with Headroom: Context Compression for LLM Applications

Subrat Pati · subratpati.medium.com ↗ · ↳ 8 links

요약

Subrat Pati가 Headroom을 비용 관점에서 소개한 Medium 글이다. Headroom은 에이전트와 LLM 사이에 놓여 컨텍스트를 줄이는 오픈소스 context optimization layer이고, 이 글은 그 도구를 압축률만으로 설명하지 않고 지출액을 함께 제시한다. 즉 토큰을 얼마나 줄이는지에 더해, 줄이지 않으면 하루에 얼마가 드는지를 같이 말한다.

논지의 중심에는 계산 하나가 놓여 있다. 입력 45,000 토큰을 소비하는 에이전트 세션은 GPT-4o 가격 기준으로 유저당 하루 약 11.25달러가 든다는 것이다. 저자는 Headroom이 토큰 소비를 40~90% 줄인다는 수치를 이 지출에 대응시켜, 압축률을 절감액으로 읽게 한다.

이 페이지는 저자의 비용 논지만 다룬다. 제품 스펙, 아키텍처 전체, 설치와 라이선스는 이 저장소의 1차 자료 Headroom: The context compression layer for AI agents가 담당한다.

배경

에이전트의 토큰 지출은 사람이 쓴 지시문의 길이가 아니라 실행 구조에서 나온다. 지시문 자체는 짧아도, 에이전트가 도구를 호출하고 그 결과를 다시 컨텍스트에 넣는 순환이 반복되면서 입력이 커진다. 저자는 그 증가가 발생하는 지점을 세 가지로 나눈다.

지점	내용	글이 제시한 규모
큰 tool 출력	도구 하나의 실행 결과가 그대로 컨텍스트에 들어간다	검색 결과 하나가 2,000 토큰을 넘는다
동적 콘텐츠	timestamp와 UUID처럼 호출마다 값이 바뀌는 문자열이 섞여 캐싱을 무력화한다	글에 규모 언급 없음
누적되는 중간 단계	멀티턴 대화에서 앞선 단계의 중간 산출이 컨텍스트에 계속 남는다	글에 규모 언급 없음

두 번째 지점은 성격이 다르다. 첫째와 셋째가 컨텍스트의 절대 크기 문제라면, 동적 콘텐츠는 크기가 아니라 재사용 가능성의 문제다. 요청의 앞부분이 매번 달라지면 provider는 이전 요청과 같은 부분을 재활용할 수 없고, 같은 내용이 다시 계산된 값으로 청구된다.

이 글은 그 메커니즘을 설명하지 않고 현상만 적는다. 같은 지점을 Headroom: The context compression layer for AI agents의 저장소 README는 "prefix를 안정화해 provider의 KV 캐시가 실제로 hit하도록 만든다"라는 Cache Aligner 설명으로 규정하며, 여기서 문제의 정체가 캐시 hit 실패라는 점이 드러난다.

비용으로 환산한 규모

저자가 압축률에 금액을 덧붙이는 이유는 의사결정 단위가 다르기 때문이다. "토큰 40% 절감"은 엔지니어의 지표이고, "유저당 하루 11.25달러"는 예산 담당자의 지표다. 유저 수와 사용 일수를 곱하면 그 값이 그대로 월 청구액의 규모가 된다.

다만 이 계산의 중간 단계는 수집본에 남아 있지 않다. 세션 하나의 입력이 45,000 토큰이라는 값과 하루 11.25달러라는 값 사이에 세션 횟수, 출력 토큰 분량, 적용 단가 중 무엇이 곱해졌는지가 적혀 있지 않다. 따라서 이 수치는 규모의 감각을 주는 예시로 읽어야 하고, 자기 워크로드에 그대로 옮기기 전에는 단가와 세션 수를 다시 계산해야 한다.

핵심 개념

context optimization layer는 에이전트와 LLM 사이에 놓여 모델에 도달하기 전의 컨텍스트를 줄이는 중간 계층을 뜻한다. 에이전트 코드를 고치지 않고 그 사이 지점에서만 개입한다는 점이 이 구조의 특징이다.

content-aware 압축은 입력의 종류를 먼저 판별하고 종류마다 다른 압축 방식을 적용하는 접근이다. 이 글은 Headroom이 로그, 코드, JSON, RAG chunk를 이 방식으로 라우팅한다고 원문 아키텍처 다이어그램을 근거로 설명한다. 로그와 코드는 반복 구조가 다르므로 같은 압축을 쓰면 한쪽이 손해를 보는데, 종류별 라우팅이 그 손해를 줄인다.

가역 압축은 버린 정보를 되돌릴 수 있는 압축을 말한다. 일반적인 요약은 되돌릴 수 없어서 요약 단계의 판단이 틀리면 뒤에서 복구할 방법이 없다. Headroom의 CCR은 원본을 캐시에 남겨 두고 필요할 때 다시 꺼내는 방식으로 이 문제를 다룬다.

방법

세 구성 요소

저자는 Headroom의 아키텍처를 세 부분으로 요약한다.

구성 요소	역할	대응하는 소비 지점
Cache Aligner	동적 콘텐츠를 안정화해 캐싱을 개선한다	동적 콘텐츠
Smart Crusher	tool 출력을 지능적으로 압축한다	큰 tool 출력
Context Manager	토큰 할당을 최적화한다	누적되는 중간 단계

세 구성 요소는 앞에서 나눈 세 소비 지점에 하나씩 대응한다. 원인을 셋으로 나누고 대응 수단도 셋으로 제시하는 구성이라 소개글로서 읽기 쉽다.

다만 이 요약은 저자의 축약이라는 점을 유의해야 한다. Cache Aligner와 Smart Crusher는 Headroom: The context compression layer for AI agents의 저장소 README에도 CacheAligner와 SmartCrusher라는 이름으로 등장하지만, Context Manager는 같은 이름으로 나오지 않는다. 실제 구성 요소 목록은 1차 자료 쪽이 더 길고 세분화되어 있다.

가역 압축 CCR

CCR은 Compress-Cache-Retrieve의 약어이고, 저자가 Headroom의 시그니처 기능으로 지목하는 것이다. 동작은 이름 그대로 세 단계다.

압축한다. 모델에 보낼 컨텍스트를 줄인 형태로 바꾼다.
캐시한다. 줄이기 전의 원본 데이터를 따로 보관한다.
되불러온다. 압축본만으로 판단이 어려우면 LLM이 전용 retrieval 도구를 호출해 전체 컨텍스트를 다시 받는다.

여기서 중요한 지점은 판단의 주체다. 압축 단계에서 무엇이 필요한지 미리 다 맞히려 하지 않고, 부족하다는 판단을 모델에 맡긴 뒤 그때 원본을 제공한다. 정보를 영구히 잃는 대신 필요할 때 되불러오는 구조라서, 압축 판단이 틀렸을 때의 손실이 회복 가능한 비용으로 바뀐다.

통합 방식

글은 세 가지 통합 경로를 제시한다.

방식	코드 변경	설명
proxy server	불필요	요청 경로에 proxy를 두고 그 지점에서 압축한다
client wrapping	필요	애플리케이션이 쓰는 client 객체를 직접 감싼다
LangChain 및 LangGraph 통합	프레임워크 설정	두 프레임워크의 네이티브 통합을 사용한다

세 경로는 도입 비용의 순서로 놓여 있다. proxy는 애플리케이션을 건드리지 않으므로 도입 장벽이 가장 낮고, client wrapping은 코드를 수정하는 대신 압축 적용 범위를 세밀하게 조절할 수 있다. 프레임워크 통합은 이미 LangChain이나 LangGraph 위에 올려 둔 에이전트에 적합하다.

결과

글이 제시하는 수치는 다음과 같다.

항목	값	성격
토큰 소비 감소	40~90%	정확도 손실 없음이라고 서술
정확도 보존	95% 이상	내장 평가 도구의 결과로 서술
커뮤니티 누적 절약 토큰	590억 개	커뮤니티 대시보드 집계
커뮤니티 누적 비용 절감	약 23만 5,900달러	커뮤니티 대시보드 집계
최적화된 요청 수	190만 건	커뮤니티 대시보드 집계

앞의 두 항목과 뒤의 세 항목은 성격이 다르다. 감소율과 정확도 보존은 도구의 성능 주장이고, 대시보드 집계는 사용자 전체의 누적 사용량이다. 후자는 도구가 얼마나 쓰이고 있는지를 보여주지만 개별 워크로드의 성능을 보증하지는 않는다.

압축률 표기는 자료 사이에 차이가 있다. 이 글은 40~~90%로 적는데, Headroom: The context compression layer for AI agents의 저장소 README는 60~~95%를 표제로 내세운다. 어느 쪽이 갱신된 값인지는 두 자료의 시점만으로는 판정할 수 없으므로, 수치를 인용할 때는 출처를 함께 밝히는 것이 안전하다.

한계

수집본이 전하는 범위

raw/에 저장된 이 자료는 원문 전문이 아니라 WebFetch로 받은 요약 추출본이다. raw 상단 수집 메모가 "verbatim 전문이 아니라 fetch 시점의 정리 추출"이라고 스스로 밝히고 있으며, 실제로 원문 표기상 약 9분 분량인 글이 1,861자로 줄어 있다. 절 제목과 불릿만 남고 산문 문단, 코드 예시, 인용은 남지 않았다.

그래서 이 페이지가 다룰 수 있는 범위는 저자의 논지 골격까지다. 비용 프레이밍, 세 구성 요소, CCR, 통합 3종, 수치는 확인되지만, 각 주장의 논증 과정과 저자가 들었을 코드 예시나 개별 사례는 확인할 수 없다. 통합 방식을 다루는 원문 절에 코드가 한 줄도 남지 않은 것이 그 손실의 단적인 사례다. 원문을 다시 다뤄야 하면 scripts/fetch_article.py로 재수집해야 한다.

자료 자체의 한계

수집 손실과 별개로 자료 자체도 소개글의 범위 안에 있다.

압축 손실의 도메인별 편차를 다루지 않는다. 어떤 종류의 입력에서 정확도가 떨어지는지에 대한 구분이 없다.
재현 방법론이 없다. 40~90%와 95% 이상이 어떤 워크로드와 어떤 측정 절차에서 나온 값인지 적혀 있지 않다.
비용 수치가 특정 시점의 GPT-4o 가격에 기대고 있다. 모델과 단가가 바뀌면 값이 달라진다.
수치의 측정 주체가 밝혀져 있지 않다. 저자의 독립 측정인지 Headroom 쪽 공개 집계의 인용인지 구분되지 않는다.

핵심 용어

용어	뜻
context optimization layer	에이전트와 LLM 사이에 놓여 모델에 도달하기 전의 컨텍스트를 줄이는 중간 계층
CCR (Compress-Cache-Retrieve)	원본을 캐시에 남겨 두고 필요할 때 retrieval 도구로 되불러오는 가역 압축
Cache Aligner	동적 콘텐츠를 안정화해 캐싱을 개선하는 구성 요소
Smart Crusher	tool 출력을 압축하는 구성 요소
Context Manager	토큰 할당을 최적화하는 구성 요소. 저자의 요약에만 등장하는 이름이다
content-aware 압축	입력의 종류를 판별하고 종류마다 다른 압축 방식을 적용하는 접근

요약

배경