토큰 이코노믹스: AI 코딩 에이전트의 진짜 비용

지난주 코딩 에이전트 실험을 돌리다가 이상한 걸 봤습니다.

OpenCode Go 사용량 대시보드에 말이 안 되는 숫자가 찍혀 있었습니다:

같은 프로바이더. 같은 모델. 입력 토큰 수도 비슷합니다(30만 vs 25.7만). 그런데 한쪽이 다른 쪽보다 46배 비쌉니다.¹

무슨 일이 벌어진 걸까요? 답은 프롬프트 캐싱입니다 — 그리고 이걸 이해하고 나서 에이전트 아키텍처를 보는 눈이 완전히 달라졌습니다.

프롬프트 캐싱은 실제로 어떻게 동작하나

LLM은 입력을 읽고 그냥 잊어버리지 않습니다. 여러 요청에서 같은 위치에 같은 토큰이 나타나면, 이전 계산을 재사용할 수 있습니다. 이게 프리픽스 캐싱입니다.

요청 1: [시스템 프롬프트] [대화 턴 1] [턴 2]
        └── 26만 토큰을 처음부터 계산 ──┘
        비용: 비쌈

요청 2: [시스템 프롬프트] [대화 턴 1] [턴 3]
        └──── 25.5만 토큰 → 캐시 히트! ────┘├── 신규 5천 ──┤
        비용: 거의 공짜

함정이 하나 있습니다. 캐싱의 혜택은 프리픽스 — 앞에서부터 정확히 일치하는 토큰 — 에만 적용됩니다. 앞부분의 토큰 하나만 바뀌어도 캐시 전체가 무효화됩니다.

제 오후 4:20 요청(입력 30만, $0.0096)이 그렇게 쌌던 이유가 이겁니다 — 그중 29.5만 토큰이 이전 턴들에서 캐시돼 있었습니다. 그리고 오전 9:20 요청(25.7만, $0.4455)이 비쌌던 이유도 같습니다 — 캐시가 하나도 없는 새 세션이었으니까요.

트랜스크립트의 함정

요즘 코딩 에이전트 대부분은 제가 “트랜스크립트” 방식이라고 부르는 걸 씁니다. 턴마다 최신 대화를 히스토리에 덧붙이고, 전체를 통째로 모델에 다시 보냅니다.

턴 1:  17K 토큰 → 캐시 미스 → $0.029
턴 2:  22K 토큰 → 17K 캐시 → $0.0007
턴 3:  27K 토큰 → 22K 캐시 → $0.0008
...
턴 10: 62K 토큰 → 57K 캐시 → $0.0019

겉보기엔 훌륭합니다. 토큰의 90% 이상이 캐시되니 턴당 한계 비용이 아주 작습니다. 경제적으로 보면 트랜스크립트 방식은 캐시 복권입니다 — 세션이 살아 있는 동안은 계속 당첨됩니다.

문제는, 세션이 영원히 살아 있지 않다는 겁니다.

컨텍스트 윈도우가 차오릅니다. 컴팩션이 발동합니다. 캐시 TTL이 만료됩니다(보통 5–10분). 이 중 하나라도 일어나면 다음 요청은 캐시 미스 — 그 순간 46배 페널티를 그대로 냅니다.

그 오전 9:20의 스파이크가 바로 컴팩션이었습니다. 세션이 컨텍스트 한도를 넘자 Hermes가 히스토리를 요약으로 압축했고, 다음 요청은 맨바닥에서 시작했습니다. 한 턴에 $0.44.

다른 접근: 구조화된 상태

대화 트랜스크립트 전체 대신, 중요한 것만 담은 구조화된 요약을 보내면 어떨까요?

턴 1:  [상태] → 3K 토큰 → 캐시 미스 → $0.005
턴 2:  [상태] → 3K 토큰 → 1K 캐시  → $0.0001
턴 3:  [상태] → 3K 토큰 → 1K 캐시  → $0.0001

첫 턴부터 더 싼 것(3K vs 17K)은 물론이고, 캐시되는 부분 — 상태 스키마 자체 — 이 워낙 작아서 만료가 사실상 의미가 없습니다. 그리고 세션이 언젠가 끝나면? 다음 세션도 17K가 아니라 3K에서 다시 시작합니다.

실제 44턴짜리 디버깅 세션으로 테스트해봤습니다. 트랜스크립트는 3,777 토큰. 추출한 상태는 740 토큰. 프롬프트 토큰 80.4% 절감 — 그리고 상태 기반 에이전트가 더 나은 구조의, 더 높은 품질의 코드를 냈습니다.

진짜 경제학

트랜스크립트 방식은 캐싱이 비용을 가려주기 때문에 턴 단위로는 더 싸 보입니다. 하지만 취약합니다:

• 캐시 TTL: 5–10분만 손을 놓으면 사라집니다
• 컨텍스트 한도: 긴 세션은 컴팩션되고, 그 순간 캐시가 깨집니다
• 품질: 노이즈가 쌓입니다. 디버깅 잡담, 툴 출력, 막다른 길 — 전부 캐시되고, 전부 프롬프트를 불립니다

상태 방식은 턴 단위로는 더 비싸지만(기댈 대형 캐시가 없으니), 예측 가능합니다. 세션 길이와 무관하게 비용이 고정되고, 품질이 퇴화하지 않습니다.

어느 쪽이 싼가? 세션 패턴에 달렸습니다:

에이전트를 만드는 사람에게 주는 의미

저는 AI 에이전트를 위한 오픈소스 메모리 플랫폼 Monet을 만들고 있습니다. 이 토큰 경제학 분석이 아키텍처를 다시 생각하게 만들었습니다:

1. 캐싱과 싸우지 말고, 캐싱을 위해 설계하라. 프리픽스가 안정적으로 캐시되도록 에이전트 컨텍스트를 구조화하세요. 맨 위의 고정 스키마는 매 턴 재사용됩니다.

2. 노이즈에서 신호를 추출하라. 트랜스크립트는 대부분 디버깅 노이즈입니다. 구조화된 상태는 신호입니다. 토큰은 줄고, 출력은 좋아집니다.

3. 캐시 미스를 계획에 넣어라. 캐시가 있어야만 싸지는 아키텍처는 곤란합니다. 캐시 미스 한 번에 비용이 46배 튄다면, 모래 위에 지은 겁니다.

4. 진짜 병목은 세션 간 연속성이다. 캐싱은 세션 안에서 돕고, 상태는 세션을 넘어 돕습니다. 둘 다 중요합니다.

토큰 경제학은 토큰 개수 세기가 아닙니다. 모델이 토큰을 처리하는 숨은 구조를 이해하고, 그 구조를 거스르는 대신 그 구조와 함께 작동하는 시스템을 설계하는 일입니다.

—

이 문제는 Monet으로 직접 실험하고 있습니다 — AI 에이전트가 팀 수준에서 지식을 공유하고 통제하게 하는 오픈소스 플랫폼입니다. 파일럿 파트너 팀을 찾고 있습니다. 관심 있으시면 GitHub 이슈로 연락 주세요.

이 글의 모든 예시와 시나리오는 실제 경험을 블로그 형식에 맞게 정리한 것입니다.