AI 코딩 에이전트의 토큰 비용, 왜 세션이 길어질수록 급격히 비싸질까

목차

• 왜 AI 코딩 에이전트의 토큰 비용이 갑자기 뛰는가
• 프롬프트 캐싱은 실제로 어떻게 비용을 줄이는가
• 트랜스크립트 방식이 장기 세션에서 불리한 이유
• 구조화된 상태가 비용과 품질을 동시에 잡는 이유
• 토큰 비용을 줄이기 위한 실전 체크리스트
• 자주 묻는 질문

이 글은 Token Economics: The Real Cost of AI Coding Agents와 Anthropic Prompt caching 공식 문서를 참고해, 토큰 비용에 민감한 AI 사용자 관점으로 다시 정리한 글입니다. 수치는 모델과 플랫폼에 따라 달라질 수 있습니다.

왜 AI 코딩 에이전트의 토큰 비용이 갑자기 뛰는가

AI 코딩 에이전트의 요금은 단순히 “이번에 몇 토큰을 썼는가”만으로 결정되지 않습니다. 실제 체감 비용은 어떤 부분이 캐시되었는지, 세션이 얼마나 길어졌는지, 중간에 요약(compaction)이 일어났는지에 따라 크게 달라집니다.

특히 코드 작업은 대화가 길어질수록 도구 출력, 에러 로그, 재시도 기록, 수정 제안이 계속 누적됩니다. 이 누적 정보가 그대로 프롬프트에 남아 있으면, 모델은 같은 내용을 반복해서 읽게 되고, 결국 처리해야 하는 토큰도 불필요하게 늘어납니다.

• 짧은 세션에서는 캐시 덕분에 비용이 낮아 보입니다.
• 세션이 길어지면 컨텍스트 창과 요약 단계가 비용을 흔듭니다.
• 변하지 않는 정보와 매번 바뀌는 정보를 분리하지 않으면 낭비가 커집니다.

즉, 토큰 비용은 “한 번의 요청 가격”보다 “세션 전체의 구조”에서 더 크게 갈립니다. 비용을 줄이려면 토큰을 아끼는 것보다 먼저, 어떤 토큰이 반복되어도 괜찮은지를 설계해야 합니다.

프롬프트 캐싱은 실제로 어떻게 비용을 줄이는가

Anthropic 공식 문서에 따르면 프롬프트 캐싱은 입력의 prefix를 재사용하는 방식입니다. 다시 말해, 요청이 반복될 때 시작 부분이 동일하면 그 앞부분 계산을 다시 하지 않고 재사용할 수 있습니다.

이 구조는 장기 대화에서 특히 유리합니다. 다만 캐시는 “대충 비슷한 내용”을 보는 것이 아니라 정확히 같은 prefix를 전제로 하기 때문에, 앞부분이 조금만 달라져도 효율이 크게 줄어듭니다.

Anthropic 문서에서 확인되는 핵심 포인트는 다음과 같습니다.

• 기본 캐시 TTL은 5분입니다.
• 1시간 TTL 옵션도 있으며, 더 높은 비용이 붙습니다.
• 캐시 read 토큰은 base input의 10% 수준입니다.
• 5분 TTL의 cache write는 base input의 1.25배로 청구됩니다.
• 모델과 플랫폼에 따라 최소 캐시 가능 토큰 수가 있으며, 일부 모델은 1,024 토큰 이상이 필요합니다.

이 때문에 “캐시가 켜져 있으니 거의 무료”라고 단정하면 안 됩니다. 캐시는 유지될 때만 강력합니다. 세션이 바뀌거나 prefix가 조금만 흔들리면, 바로 새 비용 구조로 돌아갑니다.

트랜스크립트 방식이 장기 세션에서 불리한 이유

많은 코딩 에이전트는 매 턴마다 대화 전체를 이어붙이는 “트랜스크립트 방식”으로 동작합니다. 처음에는 캐시가 잘 먹어서 저렴해 보이지만, 실제로는 불안정한 구조 위에 올라가 있는 경우가 많습니다.

문제는 세션이 길어질수록 누적되는 내용이 전부 가치 있는 정보가 아니라는 점입니다. 실패한 시도, 임시 로그, 이미 끝난 토론까지 함께 쌓이면서, 모델이 읽어야 할 프롬프트는 점점 비대해집니다.

• 컨텍스트 창이 차면 요약이 개입하고, 캐시가 끊깁니다.
• 일정 시간 지나면 TTL 만료로 캐시가 사라집니다.
• 도구 출력이 길수록 잡음까지 함께 비용을 냅니다.
• 한 번의 캐시 미스가 체감 비용을 크게 튀게 만들 수 있습니다.

즉, 트랜스크립트 방식은 “짧게 끝날 때는 싸 보이지만, 길어지면 급격히 불안정해지는 구조”입니다. 비용 민감 사용자가 진짜 봐야 할 것은 평균값이 아니라 비용의 변동성입니다.

구조화된 상태가 비용과 품질을 동시에 잡는 이유

대안은 대화 전체를 보내는 대신, 중요한 정보만 구조화된 상태로 유지하는 것입니다. 예를 들어 목표, 결정 사항, 아직 남은 질문, 변경된 파일, 다음 행동만 남기면 프롬프트는 훨씬 작아지고, 중요한 맥락은 더 선명해집니다.

이 방식의 장점은 단순히 토큰을 줄이는 데 그치지 않습니다. 잡음을 줄이기 때문에 모델의 주의력이 분산되지 않고, 결과물의 품질도 더 일관되게 유지됩니다.

상태 설계에 꼭 들어가면 좋은 항목

• 현재 목표와 성공 조건
• 이미 확정된 결정 사항
• 보류된 질문과 불확실성
• 변경된 파일 또는 작업 단위
• 다음 한 단계 행동

아래는 이런 상태를 단순화한 예시입니다.

goal: "워드프레스 글 발행"
decisions:
  - "톤은 격식 있는 한국어로 작성"
  - "출처는 상단에 클릭 가능한 링크로 노출"
open_questions:
  - "추가 이미지가 필요한가"
changed_files:
  - "/tmp/blog-draft/post.html"
next_step: "공개 페이지 렌더링 확인"

이런 식으로 상태를 설계하면, 새 세션이 시작돼도 처음부터 거대한 대화 기록을 되살릴 필요가 없습니다. 즉, 세션 종속성을 줄일 수 있습니다.

토큰 비용을 줄이기 위한 실전 체크리스트

토큰 비용에 민감한 AI 사용자는 아래 체크리스트만 적용해도 체감 차이가 큽니다.

• 변하지 않는 지시문, 스타일 규칙, 프로젝트 정보는 앞부분에 고정합니다.
• 매 턴 전체 로그를 붙이지 말고, 핵심 상태만 남깁니다.
• 툴 출력은 그대로 축적하지 말고, 요약과 결론만 보존합니다.
• 세션이 길어지면 수동으로 “결정/미결정/다음 행동”으로 압축합니다.
• 캐시가 전제되는 설계를 하지 말고, 캐시가 끊겨도 견딜 수 있게 만듭니다.
• 크로스 세션 작업은 대화 기록보다 외부 상태 저장소를 우선합니다.

정리하면, 가장 싸게 쓰는 방법은 무조건 “짧게 쓰는 것”이 아니라, 반복 가능한 prefix를 안정적으로 설계하는 것입니다. 이 차이가 장기적으로는 총비용을 크게 가릅니다.

자주 묻는 질문

Q. 캐시가 있으면 토큰 비용은 거의 신경 쓰지 않아도 되나요?

A. 아닙니다. 캐시는 세션이 유지될 때만 강력합니다. TTL 만료, 컨텍스트 압축, prefix 변경이 생기면 비용이 다시 올라갈 수 있습니다.

Q. transcript 방식이 완전히 나쁜가요?

A. 완전히 나쁘지는 않습니다. 짧고 단순한 작업에서는 유리할 수 있습니다. 다만 장기 세션과 재시작이 잦은 작업에서는 비용 변동성이 커집니다.

Q. 비용을 가장 확실하게 줄이는 방법은 무엇인가요?

A. 변하지 않는 정보를 구조화해 고정하고, 매번 바뀌는 로그와 잡음을 최소화하는 것입니다. 즉, “대화 전체”보다 “상태”를 관리하는 편이 더 안정적입니다.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!