프롬프트 한 줄인데 요청이 여러 번? 코딩 에이전트의 과금 구조

짧은 프롬프트를 한 줄 입력했는데, 나중에 보면 하루 할당량의 한 획이 사라졌거나 — 종량제라면 — 답변 값어치보다 큰 청구가 찍혀 있습니다. "내가 입력한 것"과 "과금된 것" 사이의 이 간극은 버그가 아니라 코딩 에이전트의 동작 방식 그 자체입니다. 이 구조를 이해하면 쿼터가 하루를 넘기는지, 오전에 끝나는지를 가르게 됩니다.

프롬프트 1개 = 모델 호출 1개가 아니다

최신 코딩 에이전트는 루프를 돕니다. 루프의 매 턴이 하나의 모델 요청이고, 프롬프트 하나가 이 루프를 여러 번 돌게 만드는 건 드문 일이 아닙니다. Google은 Gemini CLI와 Gemini Code Assist 에이전트 모드에 대해 이를 문서로 명시합니다: "에이전트 모드나 Gemini CLI에서는 프롬프트 하나가 여러 모델 요청으로 이어질 수 있으며", 일일 요청 한도는 사용된 모든 모델 버전에 걸쳐 합산됩니다 (Google Cloud, "Quotas and limits", 2026-09-17 확인).

루프는 대체로 이렇게 생겼습니다:

프롬프트 한 줄 입력
├─ 모델 요청 1: 계획 + 도구 정의를 읽고 다음 단계 결정
├─ 모델 요청 2: 첫 파일을 읽은 뒤, 그 내용을 처리
├─ 모델 요청 3: 수정 후 검증 방법 결정
├─ 도구 실행(셸 명령, 테스트) — 요청 사이에서, 요청 안이 아니라
└─ 모델 요청 N: 최종 요약 생성

같은 패턴이 계량 방식만 다르게 다른 도구에도 있습니다. Anthropic의 Claude Code 문서는 매 턴마다 전체 대화를 다시 보내며, 도구를 사용할 때마다 그 결과 배치를 싣은 또 다른 요청이 나간다고 설명합니다 — 그래서 프롬프트가 짧아도 하루 종일 켜둔 세션의 사용량은 계속 오릅니다 (Anthropic, "Manage costs effectively", 2026-09-17 확인).

무엇이 계량되고, 카운터는 어디에 있나

모든 에이전트가 같은 단위를 계량하지 않습니다. 소비되는 단위는 접속 방식과 제품 표면에 따라 달라집니다:

각 벤더 문서의 숫자는 움직이지만 구조는 그렇지 않습니다. Google의 Gemini API 문서는 분당 요청 수, 분당 토큰 수, 일일 요청 수를 세 가지 기본 차원으로 꼽으면서, 셋 중 하나만 넘겨도 요율 제한 오류가 트리거된다고 밝힙니다 — 나머지에 여유가 있어도 말이죠 (Google AI, "Rate limits", 2026-09-17 확인).

여기서 두 가지는 기억할 가치가 있습니다:

짧은 프롬프트가 비싼 프롬프트일 수 있습니다. 비용은 문장 길이가 아니라 에이전트가 한 일 — 읽은 파일 수, 수정, 검증 실행, 재시도 — 에 비례합니다. 답하기 전에 파일 열 개를 읽은 에이전트는 눈에 보이는 호출 위에, 컨텍스트를 나르는 열 요청분의 작업을 추가로 한 것입니다.

재시도와 오류도 루프의 일부입니다. 요율 제한 오류로 실패한 요청도 그 요청을 만든 분당·요청당 예산은 이미 소모했을 수 있습니다(실패한 요청이 청구되는지는 벤더와 표면마다 다르니 — "분당 한도는 아마 소모, 청구서로 확인"이 정답이지 양쪽 다 단정하는 건 아닙니다).

예시 트레이스 (템플릿이지 실제 로그가 아닙니다)

루프를 구체적으로 보여드리자면, 전형적인 작은 작업은 대략 이런 모양이 됩니다. 이건 실측 기록이 아니라 여러분의 텔레메트리와 비교해볼 예시 형태입니다:

프롬프트: "로그인 함수에 입력 검증 추가"          (예시)
├─ 요청 1   계획 + 도구 스키마 읽기              ~2k 토큰 입력
├─ 도구: auth.ts 읽기 (150줄)
├─ 요청 2   파일 처리 + 수정 제안               ~20k 토큰 입력
├─ 도구: 수정 적용
├─ 요청 3   검증 패스                          ~25k 토큰 입력
├─ 도구: 테스트 파일 실행
└─ 요청 4   결과 요약                          ~30k 토큰 입력

눈에 보인 프롬프트는 한 줄입니다. 계량된 활동은 누적된 컨텍스트를 매번 싣고 간 모델 요청 네 번, 그리고 도구 실행 네 번입니다. 요청 수 쿼터라면 하루의 4개가 간 셈이고, 토큰 계량 플랜이라면 요청 2~4가 같은 컨텍스트의 상당 부분을 매번 다시 읽습니다 — 실제 비용이 앉는 자리는 여기입니다.

내 세션을 측정하라 (체크리스트 + 기록표)

벤더들은 추측을 멈출 만한 텔레메트리를 이미 제공합니다. 도구별로 확인할 것:

• Gemini CLI: 세션 중 /stats model 실행 — 현재 세션의 토큰 사용량과 현재 쿼터에 연관된 한도를 보여줍니다(CLI 자체 문서 기준, 2026-09-17 확인).
• Claude Code: /usage 실행 — 세션 블록이 모델별 토큰 수와 비용을 보여주고, 구독자는 플랜 사용량 바를, 프롬프트 캐시 라인은 입력 중 캐시에서 온 비중을 보여줍니다. /insights는 세션 패턴을 분석해 줍니다.
• 모든 에이전트 공통: 요청별 토큰 수를 로그로 남기는지 확인 — 많은 도구가 세션 트랜스크립트나 디버그 파일을 쓰니 grep으로 뽑을 수 있습니다.

그다음, 찾은 값을 기록해 두세요. 숫자가 일화로 끝나지 않게:

실제 세션 몇 개를 기록하면 내 프롬프트 대 요청 비율이 나옵니다 — 위의 모든 쿼터 설명이 뒤에 숨어 있는 바로 그 숫자입니다. 도구가 요청 수를 노출하지 않으면 그 열에는 추정 대신 "N/A"라고 쓰세요. 솔직한 N/A가 확신에 찬 허구보다 낫습니다.

이걸로 뭘 할까

예산은 프롬프트가 아니라 요청 단위로 세세요. 플랜이 하루 1,000 요청이라면, 중간 크기 코딩 작업 하나가 몇 개를 먹는지 계산하고 그에 맞춰 배분하세요 — 소비 단위는 "프롬프트"가 아닙니다.

컨텍스트는 의도적으로 가볍게. 루프의 뒤쪽 요청들은 앞선 컨텍스트를 다시 보냅니다. 작게 유지된 세션은 싸고, 하루치 이력을 누적한 세션은 이후 모든 턴을 비싸게 만듭니다. 작업이 끝나면 압축하거나 새로 시작하는 편이, 관련 없는 작업에 이력을 끌고 가는 것보다 셉니다.

습관이 아니라 작업 무게로 라우팅하세요. 기계적 수정과 보일러플레이트에 가장 귀한 쿼터를 쓸 필요는 없습니다. 프론티어 요청은 필요한 작업에 아껴 쓰는 것 — 이게 결국 싼 종량 모델을 곁에 두고 작은 작업을 거기로 보내는 논리이기도 합니다.

meshcode는 여러 에이전트를 병렬 창으로 돌리게 해 주므로, 기계적인 작업은 싼 계량기로 보내고 희소한 일일 요청은 필요한 작업에 남겨둘 수 있습니다 — 각 도구는 자기 계정, 자기 한도 안에서 연결됩니다.

관련 글: Gemini 표면마다 상한이 하나의 숫자가 아닌 이유 · AI 코딩 에이전트 토큰 비용 비교 · 첫 프롬프트 전에 이미 드는 토큰 대신, 컨텍스트를 줄이는 법.

👉 meshcode 다운로드