headroom 컨텍스트 압축으로 LLM 에이전트 비용 줄이기

LLM 호출 앞에 압축 레이어를 둔다

2026년 들어 에이전틱 AI 워크플로우가 프로덕션으로 확산되면서 장기 대화와 멀티스텝 태스크의 컨텍스트 토큰 비용이 운영 부담으로 떠올랐다. PyTorch Korea 커뮤니티를 통해 알려진 오픈소스 전처리 레이어 headroom은 LLM에 컨텍스트를 넘기기 전에 의미 구조를 보존하면서 토큰을 최대 95%까지 줄이는 방식을 제시한다.

단순히 오래된 내용을 잘라내거나 전체 대화를 요약하는 접근과는 다르다. 에이전트와 LLM API 사이에서 호출 직전의 컨텍스트를 가로채 압축한 뒤 전달하는 미들웨어 패턴이며, 기존 비즈니스 로직을 거의 건드리지 않고 적용할 수 있다는 점이 핵심이다.

의미 단위를 가려내고 압축률을 조절하는 과정

압축은 의미 단위 분절, 중요도 스코어링, 동적 압축 순서로 진행된다.

먼저 입력을 문장 길이에 맞춰 기계적으로 자르지 않고 의미 단위로 나눈다. 같은 주제를 다루는 연속 발화와 중복 설명, 반복된 지시문을 클러스터로 묶고 임베딩 유사도로 서로 가까운 청크를 식별한다.

분절한 청크에는 중요도 점수를 매긴다. 현재 쿼리와의 cosine similarity, 최근 발화에 더 높은 값을 주는 위치 가중치, token-per-information 비율로 본 정보 밀도, 다른 청크에서 언급된 참조 빈도가 판단 기준이다.

마지막으로 목표 압축률과 품질 임계값에 따라 중요도가 낮은 청크를 제외하거나 요약한다. 높은 압축률은 비용을 더 낮추지만 정보 손실 가능성도 키운다. headroom은 이 균형을 태스크 유형에 맞춰 동적으로 조절한다.

⤢✕

기존 에이전트에 래퍼로 연결하기

headroom은 LangChain, LlamaIndex, AutoGen 같은 에이전트 프레임워크용 어댑터를 제공한다. 통합 지점은 LLM 래퍼 계층이다. 기존 ChatOpenAI 또는 AnthropicClaude 인스턴스를 headroom 래퍼로 감싸 압축 처리를 호출 경로에 넣는다.

# 기존 코드
llm = ChatAnthropic(model="claude-opus-4-5")

# headroom 적용 후
from headroom import HeadroomWrapper
llm = HeadroomWrapper(
    base_llm=ChatAnthropic(model="claude-opus-4-5"),
    compression_ratio=0.7,   # 70% 압축 (토큰 30%만 유지)
    quality_threshold=0.85,  # 품질 임계값 85%
    task_type="reasoning"    # 태스크 유형별 최적화
)

이 패턴에서는 에이전트의 업무 로직을 수정하지 않아도 압축된 컨텍스트를 LLM에 투명하게 전달할 수 있다.

압축 정책은 비용과 품질의 우선순위에 따라 나뉜다.

모드	압축률	품질 우선순위	적합 태스크
`aggressive`	~95%	비용 우선	요약, 분류, 키워드 추출
`balanced`	~70%	균형	일반 Q&A, 코드 리뷰
`conservative`	~30%	품질 우선	추론, 수학, 정밀 분석

런타임에는 토큰 예산과 태스크 복잡도, 직전 응답의 품질 점수를 기준으로 모드를 바꾸는 adaptive scheduling도 사용할 수 있다.

프로덕션 전환은 측정과 섀도우 검증부터

처음부터 전체 트래픽을 압축 대상으로 삼기보다 현재 사용량을 기준선으로 남겨야 한다. headroom.profiler를 켜고 기존 파이프라인의 컨텍스트 토큰 패턴을 2주간 측정한다. 이 구간에는 압축을 적용하지 않고 메타데이터만 수집하므로 운영 영향이 없다.

수집 결과를 이용해 태스크를 압축 적합 유형과 비적합 유형으로 나눈 다음 섀도우 모드로 넘어간다. 실제 LLM에는 원본 컨텍스트를 보내되 압축본도 병렬 생성해 두 응답의 차이를 측정한다. 품질 지표로는 ROUGE-L, BERTScore와 태스크별 정확도를 사용한다.

섀도우 검증을 통과한 태스크는 초기 20%에서 50%, 100% 트래픽 순으로 전환한다. 운영 중에는 압축 품질과 비용 절감량을 대시보드에서 함께 추적하고, 품질 저하가 감지되면 압축률을 낮추는 회로 차단기(circuit breaker)를 둔다.

태스크별 파라미터는 평가 데이터로 찾는다

적정 압축률과 품질 임계값은 태스크 및 도메인마다 달라진다. headroom.tune()을 이용하면 평가 데이터에 맞춘 파라미터 탐색을 실행할 수 있다.

from headroom import HeadroomTuner

tuner = HeadroomTuner(
    eval_dataset="path/to/eval_pairs.jsonl",  # (context, expected_answer) 쌍
    metric="bertscore",
    budget_per_run=0.10  # 튜닝에 사용할 최대 API 비용 (USD)
)

best_config = tuner.run(
    compression_range=(0.3, 0.95),
    quality_threshold_range=(0.75, 0.95),
    n_trials=50
)
print(best_config)
# {'compression_ratio': 0.72, 'quality_threshold': 0.83, 'mode': 'balanced'}

이 유틸리티는 Optuna 기반 베이지안 최적화로 50회 트라이얼 안에서 설정을 탐색하며, 튜닝 과정의 API 비용도 지정한 예산 범위로 제한한다.

대화가 길어질수록 달라지는 절감 폭

headroom 공개 벤치마크는 대화 길이에 따른 결과를 다음과 같이 제시한다.

단기 대화(10턴 이하): 평균 45% 토큰 절감, 응답 품질 저하 2% 미만
중기 대화(10-50턴): 평균 72% 토큰 절감, 응답 품질 저하 5% 미만
장기 대화(50턴 이상): 평균 91% 토큰 절감, 응답 품질 저하 8% 미만

코드베이스 분석이나 문서 작업 에이전트처럼 동일 정보를 반복해서 참조하는 흐름에서는 최대 95% 압축이 실현된다. 비용 감소액은 토큰 단가와 호출량에 비례하며, 사용량이 많은 프로덕션 환경에서는 월 수천 달러를 절감한 사례가 보고되고 있다.

압축해도 되는 작업과 피해야 할 작업

긴 문서 요약과 분류, 대화 이력 기반의 단순 Q&A, 키워드 추출과 태깅, 코드 린팅 및 포맷 검사는 aggressive 모드가 권장되는 압축 적합 태스크다.

일반 코드 리뷰와 중간 복잡도의 지시 따르기, RAG 기반 답변 생성에는 balanced 모드가 맞는다. 다단계 수학·논리 추론이나 정밀 사실 확인, 법률·의료 도메인 분석은 정보 손실에 더 민감하므로 conservative 모드로 접근해야 한다.

문체의 연속성이 필요한 창의적 롤플레이와 픽션 생성, 정확한 인용이나 출처 확인을 요구하는 작업에는 압축을 적용하지 않는 편이 권장된다. 토큰 수가 20 미만인 초단문 쿼리도 headroom 적용 대상에서 제외한다.

LLMLingua와 프롬프트 캐싱은 쓰임이 다르다

headroom은 런타임에서 의미론적으로 토큰을 덜어내 컨텍스트 자체의 전송량을 줄인다. 모든 LLM과 프레임워크에 적용할 수 있지만 수십~수백 ms의 전처리 오버헤드가 생기며, 압축률과 품질 사이의 균형을 관리해야 한다.

Microsoft의 LLMLingua는 소형 LLM이 토큰별 중요도를 판단해 불필요한 토큰을 삭제한다. 단일 프롬프트 최적화에 강한 대신 소형 LLM을 실행할 환경이 필요하고, 수백 ms~수 초의 추론 시간이 더해진다. 에이전트의 누적 대화 흐름에 대한 최적화도 부족하다.

Anthropic과 OpenAI의 프롬프트 캐싱은 반복되는 컨텍스트의 동일 prefix를 서버 측 캐시에서 처리한다. 캐시 히트 시 지연 시간은 거의 없고 고정 시스템 프롬프트를 되풀이하는 패턴에 적합하다. 반면 계속 변하는 에이전트 대화 이력에서는 캐시 히트율이 낮다.

시나리오	최적 전략	이유
고정 시스템 프롬프트 + 짧은 대화	프롬프트 캐싱	캐시 히트율 최대
단일 긴 문서 분석	LLMLingua	단발성 토큰 삭감에 강점
장기 에이전트 대화 (50턴 이상)	headroom	누적 컨텍스트 압축에 최적화
멀티에이전트 병렬 워크플로우	headroom + 프롬프트 캐싱 병행	시너지 효과
비용 민감 + 단순 분류 태스크	headroom (aggressive 모드)	95% 압축으로 최대 절감

호출량 가정으로 본 비용 차이

Claude Sonnet 4.5의 입력 토큰 가격을 $3/M으로 두고, 에이전트가 하루 10만 회 API를 호출하며 평균 컨텍스트 길이가 8,000토큰이라고 가정한다.

압축 없음: $2,400/일
프롬프트 캐싱만 적용 (캐시 히트율 60%): ~$1,440/일 (40% 절감)
headroom balanced 모드 (70% 압축): ~$720/일 (70% 절감)
headroom + 캐싱 병행: ~$432/일 (82% 절감)
headroom aggressive 모드 (95% 압축): ~$120/일 (95% 절감)

aggressive 모드는 절감 폭이 큰 만큼 품질 저하 위험도 있다. 모든 호출에 일괄 적용하지 않고 분류 결과에 따라 적합한 태스크만 선택하는 방식이 현실적이다.

운영에서는 압축 전후를 모두 추적해야 한다

압축 레이어가 들어가면 에이전트가 만든 원본 컨텍스트와 LLM이 실제로 받은 컨텍스트가 달라진다. 장애 분석과 응답 품질 추적을 위해 양쪽 내용을 모두 로깅하고 압축률과 품질 점수를 별도 파이프라인에서 관찰해야 한다.

임베딩 계산을 외부 API에 맡기는 구성에서는 PII 노출 위험도 검토해야 한다. 완전 로컬 임베딩 모드를 활성화하거나 온프레미스 배포를 고려할 수 있다.

초기 도입 단계에는 같은 태스크를 압축 적용 그룹과 미적용 그룹으로 나누는 A/B 테스트가 필요하다. 비용 지표만 개선되고 답변 품질이 떨어지는 상황을 놓치지 않기 위해서다.

압축 파라미터 역시 운영 설정이 아니라 응답 동작을 바꾸는 배포 항목으로 다뤄야 한다. 변경 이력을 코드와 같은 수준으로 관리하고 문제가 생겼을 때 되돌릴 롤백 계획을 마련한다.

headroom은 장기 대화와 고사용량 멀티에이전트 환경에서 누적되는 컨텍스트 비용을 호출 전 단계에서 줄인다. 프롬프트 캐싱이나 LLMLingua와 경쟁 관계로만 보기보다, 고정 prefix와 단일 문서, 누적 대화라는 각 방식의 적용 지점을 구분해 함께 설계할 수 있다. 프로덕션 적용 여부는 태스크 분류와 섀도우 검증, 점진적 롤아웃에서 확인한 품질 결과를 기준으로 판단해야 한다.