동일한 토큰에 비용을 두 번 지불하는 것을 멈추는 방법

저는 16K 토큰 분량의 PR(Pull Request)에 대해 5개의 리뷰어 에이전트(reviewer agents)를 실행했습니다. 단순한(naive) 설정에서는 1.32달러가 들었습니다. 두 가지 아키텍처 변경을 통해 이를 0.49달러로 낮췄습니다. 여기 그 비용 명세서와 실험 과정에서 저를 놀라게 했던 점들을 정리했습니다.

다섯 명의 전문가 에이전트가 동일한 풀 리퀘스트(pull request)를 검토했습니다. 보안(Security), 테스트(tests), 성능(perf), 관측 가능성(observability), API 디자인(API design) 분야입니다. 각 에이전트는 전체 디프(diff)를 다시 읽었습니다. 각 에이전트는 전체 비용을 지불했습니다. Claude Opus 4.6을 사용하여 단 한 번의 PR 패스(pass)를 수행하는 데 1.32달러가 청구되었습니다.

단 하나의 PR. 단 한 번의 리뷰 패스. 1.32달러.

만약 여러분이 어떤 규모로든 멀티 에이전트(multi-agent) 코드 리뷰를 실행하고 있다면, 여러분은 매번 전체 비용을 지불하며 정확히 동일한 토큰에 대해 반복적으로 돈을 낭비하고 있는 것입니다.

저는 이 낭비를 측정하고 두 가지 명백한 해결책을 테스트하기 위한 하네스(harness)를 구축했습니다. 수치는 예상보다 더 날카로웠으며, 그중 하나는 프롬프트 캐싱(prompt caching)에 대한 저의 가정을 뒤집어 놓았습니다.

내가 구축한 것

세 가지 모드와 하나의 공유된 49K 글자 분량의 풀 리퀘스트(pull request) 디프(diff)를 가진 작은 Python 하네스(harness)입니다. 다섯 명의 리뷰어 역할이 있으며, 각 역할은 엄격한 시스템 프롬프트(system prompt)를 가집니다:

REVIEWER_ROLES = {
    "security":      "Auth, injection, secrets, access control...",
    "tests":         "Missing tests, skipped tests, weak assertions...",
...

동일한 디프(diff)에 대해 세 가지 모드를 적용했습니다:

Naive (단순 방식). 각 리뷰어는 사용자 메시지(user message)에 전체 디프(diff)를 포함하여 개별적으로 호출을 생성합니다. 역할 텍스트가 먼저 오기 때문에 호출마다 접두사(prefix)가 달라집니다. 아무것도 캐싱(cached)되지 않습니다.
Cache (캐싱 방식). 각 리뷰어는 디프(diff)를 시스템 메시지(system message)에 넣으며, 이는 다섯 번의 호출 모두에서 동일합니다. 첫 번째 호출이 제공업체의 프롬프트 캐시(prompt cache)에 기록합니다. 두 번째부터 다섯 번째 호출은 90% 할인된 가격으로 이를 읽어옵니다.
Librarian (사서 방식). 첫 번째 패스(pass)가 디프(diff)를 압축된 JSON 요약본으로 소화합니다. 리뷰어들은 원본 디프(diff)가 아닌 요약본을 대상으로 실행됩니다. 이는 에이전트 간의 중복된 탐색 토큰(exploration tokens)을 억제하기 위해 지속적인 검색 서브 에이전트(search sub-agent)를 사용하는 Cho 등의 arXiv 논문 Long Live the Librarian!에서 영감을 얻었습니다.

Anthropic의 API 목록 요율을 기준으로 모든 호출 비용을 책정했습니다: 입력 $15/M, 캐시 읽기 $1.50/M, 출력 $75/M. 여기에 실제 측정된 토큰 수와 목록 가격 산술 계산이 더해졌습니다.

수치 분석

(49K 문자, 호출당 대략 16K 토큰) 큰 차이, 리뷰어 5명, 단일 신규 검토 패스:

모드	입력 (Input)	캐시 (Cached)	출력 (Output)	총합 (Total)
Naive	80,248	0	1,500	$1.316
...
Naive는 터무니없이 비용이 많이 듭니다. 캐시와 라이브러리안(librarian) 모두 이를 약 3분의 2로 줄여줍니다.

캐시는 라이브러리안보다 3센트 더 적게 지출합니다. 이것은 실제 수치이며, 제가 어떤 레버를 먼저 당겨야 할지 생각하는 방식 자체를 바꿉니다.

캐싱이 실제로 라이브러리안보다 나을 때

캐싱은 따뜻한(warm) 시리즈에서 승리합니다. 첫 번째 호출이 캐시에 쓰기(write)를 하고, 다음 네 번의 호출이 그것을 읽습니다. 만약 5명의 리뷰어가 동일한 공유 접두사(shared prefix)에 대해 연속적으로 같은 따뜻한 세션(warm session)에서 실행될 것이라고 보장할 수 있다면, 프롬프트 캐싱은 할 수 있는 가장 깔끔한 방법입니다. 시스템 메시를 두 줄로 리팩토링하는 것만으로 비용이 66% 절감됩니다.

문제는 다음과 같습니다: 코드 리뷰 봇은 프로덕션 환경에서 거의 그렇게 작동하지 않습니다.

각 PR(Pull Request)은 새로운 세션입니다. PR은 서로 다른 개발자, 다른 리포지토리, 다른 브랜치에서 예측할 수 없는 간격으로 들어옵니다. '따뜻한 시리즈'는 없습니다. 차가운 시작(cold start)의 행렬이 있을 뿐입니다.

모든 호출이 차갑다면, 캐시 모드는 다시 네이티브 모드로 붕괴합니다. 호출당 동일한 비용을 지불하게 됩니다. 똑같은 손실입니다.

라이브러리안 패턴은 세션이 따뜻하든 차갑든 신경 쓰지 않습니다. 각 리뷰어는 원본 diff가 아닌 작은 요약(digest)만 읽습니다. 절감액은 캐시의 어느 곳에 있는 런타임 상태에 달려있는 것이 아니라, 호출 자체의 형태에 내재되어 있습니다.

모드	따뜻한 시리즈 (연속 5회 호출)	매번 차가운 호출 (실제 운영 환경)
Naive	$1.32	$1.32
...
만약 리뷰어들이 단일 세션 내에서 짧은 간격으로 실행된다면 캐싱을 사용하세요. 만약 독립적으로 차가운 시작을 거쳐 실행된다면, 라이브러리안을 사용하세요. 대부분의 실제 시스템은 후자에 해당합니다.

캐싱에 대해 놀라웠던 점

저는 실패 시 즉시 경고를 보내는 가드레일(guardrail)을 갖춘 하네스(harness)를 구축했습니다. 캐시 모드(cache mode)에서 2번째부터 N번째 호출까지 캐시된 토큰(cached tokens)이 0으로 보고되면, 하네스는 중단되고 진단 결과(diagnostics)를 출력합니다. 캐시된 접두사(cached prefix)가 적중(hit)해야 하며, 만약 그렇지 않다면 해당 실험은 유효하지 않은 것입니다.

작은 차이(small-diff)를 실행했을 때 두 번의 오류가 발생했습니다.

동일한 코드, 동일한 5회 호출 시퀀스, 4,003 토큰에서의 동일한 시스템 메시지(system message). 두 실행 모두 모든 호출에 대해 cached_tokens=0을 반환했습니다. 캐시 모드(cache mode)와 단순 모드(naive mode)의 비용은 소수점 넷째 자리까지 정확히 동일한 $0.413이었습니다.

그 후 호출당 16,000 토큰인 큰 차이(large diff)를 실행했습니다. 5번의 호출 중 4번이 캐시에 깔끔하게 적중했습니다. 각각 15,992개의 토큰이 캐시되었습니다.

따라서 OpenAI 형태의 요청(OpenAI-shape request)을 Copilot 프록시를 통해 claude-opus-4.6에 보낼 때, 4K에서 16K 토큰 사이의 동일한 접두사(identical prefix) 구간에서 프롬프트 캐싱(prompt caching)이 활성화됩니다. 이 임계값(threshold) 아래에서는 활성화되지 않습니다. Anthropic 문서에는 최소치가 대략 1024에서 2048 토큰이라고 명시되어 있습니다. 경험적으로 볼 때, 활성화 곡선(activation curve)은 평탄하지 않습니다.

명시된 캐시 할인율을 기준으로 예산을 세우고 있다면, 적중률(hit rate)을 하나의 범위(band)로 모델링하세요. 실제 페이로드(payload) 크기로 실험을 수행하십시오. 마케팅 수치가 여러분이 실제로 사용하는 호출 형태(call shapes)에도 그대로 적용될 것이라고 가정하지 마세요.

직접 시도해 보세요

전체 하네스(harness)는 github.com/AndreaGriffiths11/librarian-demo에 있습니다. 세 개의 Python 파일, 하나의 차이(diff) 시나리오, 하나의 가격 책정(pricing) 모듈로 구성되어 있습니다. 다음과 같이 실행하세요:

export COPILOT_OAUTH_TOKEN=$(sqlite3 ~/.copilot/data.db \
  "SELECT access_token FROM github_accounts WHERE is_default=1;")

...

GitHub Copilot CLI가 설치되어 있다면, 이미 ~/.copilot/data.db에 OAuth 토큰이 저장되어 있습니다. OpenAI SDK를 https://api.githubcopilot.com으로 지정하고 Copilot-Integration-Id: copilot-cli 헤더를 추가하면, chat-completions 형태의 전체 모델 카탈로그(Anthropic, OpenAI, Google)를 사용할 수 있으며, prompt_tokens_details.cached_tokens 보고 기능도 제공됩니다. PAT(Personal Access Token)나 별도의 토큰 교환도 필요 없습니다. 약 30줄의 접착 코드(glue code)면 충분합니다:

import sqlite3, pathlib
from openai import OpenAI

...

한 가지 과금 관련 참고 사항: GitHub Copilot은 2026년 6월 1일에 사용량 기반 과금 (usage-based billing) 방식으로 전환됩니다. 새로운 모델 하에서는 토큰 소비가 Anthropic의 공개 API 요율에 따른 GitHub AI Credits로 직접 매핑되므로, 이 글에 언급된 달러 수치는 API를 직접 호출하는 사람뿐만 아니라 현재의 Copilot 사용자들에게도 적용됩니다. 아키텍처 측면의 교훈은 어느 쪽이든 동일합니다. 유료 Copilot 플랜을 사용 중이라면, 이러한 절감액은 월간 크레딧 할당량에서 실제로 아껴지는 달러 금액이 됩니다.

내가 실제로 배포한다면

만약 내가 이 데이터를 바탕으로 내일 당장 리뷰 파이프라인 (review pipeline)을 다시 구축한다면 다음과 같이 하겠습니다:

모든 공유 컨텍스트 (shared context)를 시스템 메시지 (system message)로 이동합니다. 이는 소프트웨어 개발에서 가장 저렴한 리팩터링 (refactor)이며, 캐시 (cache)가 활성화되지 않더라도 비용이 전혀 들지 않습니다.
리뷰어가 3명을 넘어서거나, 공유 컨텍스트가 충분히 커져서 활성화 임계값 (activation threshold)이 실제로 작동하기 시작하면 '사서 패스 (librarian pass)'를 구축합니다. 요약본 (digest)은 콜드 세션 (cold sessions) 전반에 걸쳐 비용을 스스로 충당합니다.
캐시 히트율 (cache hit rate)을 상수로 취급하는 것을 중단합니다. 당신의 페이로드 (payloads), 당신의 환경, 그리고 당신이 배포하는 모델을 기준으로 이를 측정하십시오. 실패 시 명확히 알리는 가드레일 (guardrail)을 작성하고, 가정이 깨질 때 그것이 비명을 지르게 두십시오.

Cho 등의 논문은 SWE-Bench Verified에서 멀티 에이전트 (multi-agent) 실행 시 GPU 에너지 절감을 최대 25%까지 측정했습니다. 나의 테스트 프레임워크 (harness)는 하나의 PR 리뷰 패스에 대한 실제 소요 시간 대비 비용 (wall-clock dollars)을 측정합니다. 대리 지표 (proxy)는 다르지만 교훈은 같습니다. 에이전트 간의 지속적인 공유 컨텍스트는 바닥에 놓여 있는 무료 아키텍처 레버 (architectural lever)입니다.

_논문: Cho, Choi, Heo, Choi. "Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems" (arXiv:2605.27787, 2026년 5월).

모든 수치는 2026년 5월 29일 GitHub Copilot 프록시를 통해 claude-opus-4.6를 대상으로 측정되었습니다. 호출당 상세 내역과 테스트 프레임워크 소스 코드는 해당 리포지토리의 runs/findings.md에 있습니다.