토큰 경제학: AI 코딩 에이전트의 실제 비용

프롬프트 캐싱 (Prompt Caching)이 실제로 작동하는 방식

LLM (Large Language Model)이 입력을 처리할 때, 단순히 읽고 잊어버리는 것이 아닙니다. 여러 요청에 걸쳐 동일한 위치에 나타나는 토큰의 경우, 모델은 이전의 계산 결과를 재사용할 수 있습니다. 이를 접두사 캐싱 (Prefix Caching)이라고 합니다.

요청 1: [System Prompt] [Conversation Turn 1] [Turn 2]
└── 260K 토큰을 처음부터 계산 ──┘
비용: 비쌈

요청 2: [System Prompt] [Conversation Turn 1] [Turn 3]
└──── 255K 토큰 → 캐시 히트 (CACHE HIT!) ────┘
├── 5K 신규 ──┤
비용: 거의 무료

문제는 무엇일까요? 오직 접두사(Prefix), 즉 처음부터 시작하여 정확히 일치하는 토큰들만이 캐싱의 혜택을 받는다는 점입니다. 시작 부분의 토큰 하나만 바뀌어도 전체 캐시가 무효화됩니다. 이것이 제가 오후 4:20에 보낸 요청(300K 입력, $0.0096)이 매우 저렴했던 이유입니다. 해당 토큰 중 295K가 이전 턴에서 캐싱되었기 때문입니다. 반면 오전 9:20의 요청(257K, $0.4455)이 매우 비쌌던 이유도 바로 이것입니다. 캐시가 전혀 없는 새로운 세션이었기 때문입니다.

트랜스크립트 함정 (The transcript trap)

오늘날 대부분의 코딩 에이전트는 제가 "트랜스크립트 (Transcript)" 방식이라고 부르는 방식을 사용합니다. 즉, 매 턴마다 최신 대화 내용을 대화 기록에 추가하고 전체 내용을 모델에 다시 보냅니다.

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

이것은 매우 좋아 보입니다. 토큰의 90% 이상이 캐싱되기 때문에 턴당 한계 비용이 매우 작습니다. 경제학적으로 말하자면, 트랜스크립트 방식은 캐시 복권과 같습니다. 세션이 유지되는 동안에는 계속해서 당첨되는 것이죠.

하지만 여기에 문제가 있습니다. 세션은 영원히 유지되지 않습니다. 컨텍스트 윈도우 (Context windows)가 가득 차고, 압축 (Compaction)이 실행됩니다. 캐시 TTL (Time To Live)이 만료되기도 합니다 (보통 5~10분). 이 중 어느 하나라도 발생하면 다음 요청은 캐시 미스가 되며, 갑자기 46배의 페널티를 온전히 지불하게 됩니다.

오전 9:20의 급격한 비용 상승이 왜 발생했을까요? 그것은 바로 압축 (Compaction) 때문이었습니다. 세션이 컨텍스트 윈도우 제한을 초과했고, Hermes가 기록을 요약본으로 압축했으며, 다음 요청은 처음부터 다시 시작되었습니다. 단 한 번의 턴에 $0.44가 소요된 것입니다.

다른 접근 방식: 구조화된 상태 (Structured State)

만약 대화 전체 기록 (Transcript)을 보내는 대신, 중요한 내용만을 담은 구조화된 요약본을 보낸다면 어떻게 될까요?

턴 1: [상태 (State)] → 3K 토큰 → 캐시 미스 (Cache miss) → $0.005
턴 2: [상태 (State)] → 3K 토큰 → 1K 캐시됨 (Cached) → $0.0001
턴 3: [상태 (State)] → 3K 토큰 → 1K 캐시됨 (Cached) → $0.0001

첫 번째 턴이 더 저렴할 뿐만 아니라 (3K vs 17K), 캐시된 부분인 상태 스키마 (State schema) 자체는 유의미하게 만료될 만큼 크지도 않습니다. 그리고 세션이 필연적으로 종료된다면 어떨까요? 다음 세션은 17K가 아니라 다시 3K에서 시작됩니다.

저는 이를 실제 44턴의 디버깅 세션으로 테스트했습니다. 전체 기록 (Transcript)은 3,777 토큰이었으나, 추출된 상태 (State)는 740 토큰이었습니다. 프롬프트 토큰이 80.4% 감소했으며, 상태 기반 에이전트 (State-based agent)는 더 나은 구조를 가진 고품질의 코드를 생성했습니다.

실제 경제성

기록 (Transcript) 방식은 캐싱 (Caching)이 비용을 숨겨주기 때문에 턴별로는 더 저렴해 보입니다. 하지만 이는 취약합니다:

• 캐시 TTL (Time To Live): 5~10분 동안 활동이 없으면 캐시가 사라집니다.
• 컨텍스트 제한 (Context limits): 긴 세션은 압축되며, 이 과정에서 캐시가 깨집니다.
• 품질 (Quality): 노이즈가 축적됩니다. 디버깅 과정의 잡담, 도구 출력 (Tool outputs), 막다른 길 등이 모두 캐시되어 프롬프트를 팽창시킵니다.

상태 (State) 방식은 턴별로는 더 비싸지만 (의존할 수 있는 거대한 캐시가 없으므로), 예측 가능합니다. 비용은 세션 길이에 관계없이 고정되며 품질이 저하되지 않습니다.

어느 쪽이 더 저렴할까요? 이는 세션 패턴에 따라 다릅니다:

패턴	기록 (Transcript) 방식	상태 (State) 방식
짧은 세션 (< 10턴)	더 저렴함 (캐시 승리)	약간 더 비쌈
긴 세션 (20턴 이상)	압축 전까지는 저렴함 → 이후 비싸짐	지속적으로 저렴함
세션 간 (Cross-session)	컨텍스트 증발 → 전체 재시작	상태 유지 → 저렴한 재시작

에이전트 구축에 주는 시사점

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

• 캐싱과 싸우지 마세요 — 캐싱을 위해 설계하세요.
• 에이전트의 컨텍스트 (Context)를 설계할 때 접두사 (Prefix)가 안정적이고 캐싱 가능하도록 구조화하세요. 상단에 고정된 스키마 (Schema)가 있으면 모든 턴에서 이를 재사용할 수 있습니다.
• 노이즈에서 신호 (Signal)를 추출하세요.

대화 기록(Transcripts)은 대부분 디버깅 노이즈(noise)입니다. 구조화된 상태(Structured state)가 신호(signal)입니다. 토큰이 적을수록 더 나은 결과물이 나옵니다. 캐시 미스(cache miss)에 대비하세요. 당신의 아키텍처(architecture)는 캐시 비용이 저렴해야만 작동해서는 안 됩니다. 만약 캐시 미스가 발생했을 때 비용이 46배 급증한다면, 당신은 모래 위에 성을 쌓은 것입니다. 세션 간 연속성(Cross-session continuity)이 진정한 병목 현상(bottleneck)입니다. 캐싱(Caching)은 세션 내에서 도움이 됩니다. 상태(State)는 세션 간에 도움이 됩니다. 둘 다 중요합니다. 토큰 경제학(Token economics)은 단순히 토큰의 개수를 세는 것이 아닙니다. 모델이 토큰을 처리하는 숨겨진 구조를 이해하고, 그 구조에 저항하는 대신 그 구조와 조화를 이루는 시스템을 설계하는 것에 관한 것입니다. *— 저는 Monet을 통해 이 문제를 직접 실험하고 있습니다. Monet은 AI 에이전트들이 팀 수준에서 지식을 공유하고 제어할 수 있도록 돕는 오픈 소스(open-source) 플랫폼입니다. 현재 파일럿 파트너 팀을 찾고 있습니다. 귀하의 팀을 위해 Monet 설정을 도와드릴 것이며, 함께 귀하의 워크플로(workflow)에 적합한 자동화 지점을 찾아낼 것입니다. 관심이 있으신가요? 댓글을 남기거나 GitHub Issue를 생성해 주세요. github.com/team-monet/monet?utm_source=devto&utm_medium=post&utm_campaign=blog-launch 이 포스트의 모든 예시와 시나리오는 실제 경험을 바탕으로 블로그 형식에 맞게 각색되었습니다.