에이전트를 건드리지 않고 에이전트 토큰 사용량을 89% 줄인 방법
출처: Dev.to
에이전트가 LLM을 호출할 때마다 전체 대화 기록을 전송합니다.
Turn 20에는 1–19턴이 포함됩니다. Turn 50에는 1–49턴이 포함됩니다. 에이전트 내부에서 조용히, 모든 요청마다 일어나기 때문에 아무도 눈치채지 못합니다.
저는 Trooper — 에이전트와 LLM 사이에 위치하는 Go 프록시 — 를 만들면서 이를 발견했습니다. 긴 디버깅 세션 동안 토큰 수가 점점 늘어나는 것을 보면서, 에이전트가 같은 컨텍스트를 반복해서 재생하고 있다는 것을 깨달았습니다. 대부분은 잡음에 불과했습니다.
모델은 전사(transcript)를 필요로 하지 않았습니다. 상태(state)가 필요했을 뿐입니다.
상태가 실제로 의미하는 것
몇 차례 턴이 지나면 세션에서 중요한 내용은 네 가지 범주로 나뉩니다:
- 내린 결정 — 무엇을 선택했으며 그 이유
- 고정된 제약 — 변경될 수 없는 것
- 열린 루프 — 아직 해결해야 할 것
- 배제된 항목 — 시도했지만 거부된 것
그게 전부입니다. 그 외의 모든 것 — 앞뒤 대화, 장황한 LLM 응답, 반복된 컨텍스트 — 은 재생일 뿐이며, 모델은 다시 필요로 하지 않습니다.
SITREP
저는 Trooper에 구조화된 세션 메모리를 추가했습니다. 충분히 턴이 쌓이면 Trooper의 로컬 Llama 모델이 세션의 사용자 메시지로부터 SITREP(상황 보고서)를 생성합니다.
예시는 다음과 같습니다:
INTENT: Build a RAG pipeline with ChromaDB and nomic-embed-text
DECISIONS: Use cosine similarity over MMR — focused queries not broad;
Chunk size 256, overlap 30 — locked;
Pure vector search — ChromaDB no hybrid support;
Top k set to 5
CONSTRAINTS: Node 18 locked — platform team constraint, no exceptions;
Re-ranking ruled out — latency jumped 200ms to 800ms
OPEN: Poor recall on technical queries — nomic-embed-text struggles with domain jargon;
Evaluating bge-small as alternative그 시점부터 LLM에 대한 모든 요청은 다음과 같이 전송됩니다:
Anchor (첫 2턴 그대로)
+ SITREP (구조화된 상태)
+ Tail (마지막 N턴 그대로)전체 히스토리를 보내는 대신에 말이죠.
수치
실제 15턴 세션을 기준으로 하면:
Full history: 10,820 tokens per request
With Trooper: 1,157 tokens per request
Reduction: 89%대시보드에 실시간으로 표시됩니다.
LLM이 여전히 올바르게 답변하나요?
이것이 핵심 질문이었습니다. 토큰을 절감해도 모델이 일관성을 잃는다면 의미가 없으니까요.
검증 방법: 자동 생성된 SITREP을 가져와서 히스토리가 전혀 없는 완전히 새로운 채팅을 시작하고, 원래 세션에서 내린 결정에 대해 질문했습니다.
질문들
- 청크 크기는 얼마였나요?
- 왜 하이브리드 검색을 배제했나요?
- 어떤 검색 방법을 선택했고 그 이유는?
- 아직 열려 있는 항목은 무엇인가요?
결과: 네 가지 모두 정확히 답변되었습니다. 모델은 전적으로 SITREP만을 사용했으며, 히스토리나 컨텍스트 누수는 없었습니다.
즉, 구조화된 상태만 있으면 모델이 올바르게 추론을 이어갈 수 있으며, 전송 비용을 89% 절감할 수 있다는 주장입니다.
작동 원리
Trooper는 Go 프록시이며, 하나의 바이너리만 있으면 됩니다. SDK나 추가 계측이 필요 없습니다. 기존 에이전트가 가리키는 URL만 하나 바꾸면 됩니다.
# Before
export ANTHROPIC_BASE_URL=https://api.anthropic.com
# After
export ANTHROPIC_BASE_URL=http://localhost:3000그 외에는 아무 것도 바뀌지 않습니다. Trooper는 모든 요청을 가로채 세션 상태를 유지하고, SITREP이 준비되면 LLM에 전달하기 전에 messages 배열을 재작성합니다.
SITREP은 Ollama를 통해 실행되는 로컬 Llama 3.1 8b 모델이 생성합니다— 빠르고, 프라이빗하며, 클라우드 비용이 없습니다. 추출 작업은 백그라운드에서 비동기적으로 이루어지며, 메인 요청 경로는 차단되지 않습니다.
// GetTripleAnchor assembles what gets sent to the LLM
func (s *SessionStore) GetTripleAnchor(sessionID string) []map[string]string {
payload := append([]map[string]string{}, state.Anchor...)
if state.SITREP != "" {
payload = append(payload, map[string]string{
"role": "system",
"content": fmt.Sprintf("[STATE_SITREP: %s]", state.SITREP),
})
}
return append(payload, state.Tail...)
}대시보드에서는 압축 비율을 실시간으로 확인할 수 있습니다:
HISTORY COMPRESSED 89%
TOKENS SAVED 459
CONFIDENCE 100%대화 요약과의 차이점
대부분의 요약 도구는 말한 내용을 압축합니다. SITREP은 다음 행동에 필요한 핵심만을 추출합니다.
Copilot의 컨텍스트 압축은 전체 대화를 요약해 인간이 긴 채팅을 이해하도록 돕습니다. 반면 SITREP은 에이전트를 위해 특별히 설계된 구조—결정, 제약, 열린 루프, 배제된 경로—를 제공합니다. 서술형 요약이 아니라 상태 스냅샷입니다.
그 결과, 이후 턴은 잡음을 재생하지 않고도 의도에 일관성을 유지합니다. 반복적인 구조화 워크플로를 수행하는 에이전트에 더 적합합니다.
제한점
SITREP은 구조화된 에이전트 워크플로—디버깅 세션, 연구 파이프라인, 다단계 빌드 작업—에 가장 잘 맞습니다. 창의적인 자유형 작업처럼 나중에 주변 컨텍스트가 중요해질 가능성이 있는 경우, 더 큰 tail 윈도우나 높은 충실도의 압축이 필요합니다.
tail 윈도우는 설정 가능하므로, 덜 구조화된 세션에서는 더 많은 원시 컨텍스트를 유지할 수 있습니다.
Trooper가 추가로 하는 일
압축은 최신 기능일 뿐이며, Trooper는 다음도 지원합니다:
- 클라우드 할당량 초과 시 로컬 Ollama로 자동 전환 — 전환 중에도 컨텍스트 유지
- 간단한 턴을 자동으로 Ollama에 라우팅 — 클라우드에 절대 접속하지 않음
- 민감 요청을
x_force_local로컬 라우팅 - 실시간 대시보드 — 의도, 열린 루프, 완료된 단계, 전사
- 서브에이전트 복구 —
/recovery/{session_id}로 정확한 재시작 지점 제공
모두 URL 하나만 바꾸면 적용됩니다.
더 큰 질문
우리는 대화 기록을 메모리라고 생각합니다. 하지만 전사는 로그일 뿐이고, 메모리는 상태입니다.
사람은 매번 이전 대화를 모두 재생하지 않고, 결론, 제약, 미해결 질문, 관련 컨텍스트 등 구조화된 스냅샷만을 가지고 다음 결정을 내립니다.
오래 지속되는 에이전트도 같은 방식이 필요할 수 있습니다. 토큰 비용 절감 때문만은 아니며—비용 절감도 도움이 되지만—상태가 히스토리보다 에이전트 메모리에 더 적합한 추상화이기 때문입니다.
SITREP은 그 방향을 탐색한 실험입니다.
trooper GitHub 저장소 — Go, MIT 라이선스, Ollama 외 의존성 없음.