AI 토크노믹스 개발자 가이드: 코딩 에이전트가 몇 분 만에 크레딧을 소진하는 이유

컨텍스트 한계에 근접하지 않았는데도 팀의 AI 크레딧 잔액이 급격히 떨어진 경우. 에이전트 루프(agent loops), 숨겨진 컨텍스트(hidden context), 추론 토큰(reasoning tokens) 및 프롬프트 캐싱(prompt caching) 뒤에 숨겨진 실제 계산법을 알아봅니다.

개발자나 QA 자동화 엔지니어가 새로운 작업을 맡습니다. 조직은 AI 코딩 어시스턴트(Cursor, GitHub Copilot, Claude Code 또는 내부 에이전트 하네스)를 배포하고 모두에게 월별 크레딧 할당량을 부여합니다.

사용자는 어시스턴트에게 불안정한 테스트 몇 개를 수정하고, 목업 데이터 일부를 생성하며, 통합 타임아웃을 디버깅하도록 요청합니다. 그런 다음 커피를 마시러 나갑니다.

돌아왔을 때, 사용량 대시보드에는 월 할당량의 큰 부분이 이미 소진된 것이 표시되어 있습니다.

가장 먼저 드는 생각은 불신입니다: "UI 상으로는 컨텍스트가 100만 토큰 중 45,000 토큰밖에 안 남았다고 하는데, 몇 분간의 작업이 어떻게 이렇게 많은 비용을 발생시킨 거죠?"

AI 가격 책정이 잘못된 것은 아닙니다. 도구들이 단일 턴 완료(single-turn completions)에서 자율 에이전트 루프(autonomous agent loops)로 이동했으며, 대부분의 엔지니어는 토큰 소비가 내부적으로 실제로 어떻게 작동하는지 보여준 적이 없습니다.

참고 사항: 아래 제시된 가격, 크레딧 변환 및 토큰 수는 예시입니다. 이는 공급업체, 플랜, 모델 및 도구에 따라 매우 광범위하게 다릅니다. 실제 수치를 확인하려면 사용자가 직접 제공업체의 가격 페이지와 사용량 대시보드를 확인하십시오.

1. 핵심 오해: 컨텍스트 창(context window) vs. 누적 사용량(cumulative usage)

두 가지 측정 항목을 분리하여 유지해야 합니다.

1. 컨텍스트 창 용량(Context window capacity): 모델이 한 순간에 담을 수 있는 텍스트의 크기입니다.
2. 누적 토큰 소비량(Cumulative token consumption): 모든 호출에서 모델로 전송되고 생성된 모든 것을 의미합니다.

"1M 컨텍스트 창"이라는 것은 모델이 실패하지 않고 단일 요청으로 대략 그 많은 토큰을 담을 수 있다는 뜻입니다. 사용자는 책상의 크기에 대해 청구되는 것이 아닙니다. 종이가 그 위에 한 번씩 슬라이드될 때마다 비용이 부과됩니다.

만약 50,000 토큰의 코드를 대화에 로드하고 왕복으로 10번 주고받는다면, 모델은 매 턴마다 이 50,000 토큰 분량의 기반 정보를 다시 읽게 됩니다(프롬프트 캐싱(prompt caching)이 이를 완화하지만, 이는 섹션 5에서 다룹니다).

UI에는 Current context: 58,000 / 1,000,000으로 표시될 수 있지만, 청구 미터는 이미 오십만 개 이상의 입력 토큰을 기록했습니다.

2. 에이전트 승수(The agent multiplier): 프롬프트 하나가 API 호출 하나를 의미하지 않는다

초기 채팅 비서들은 단순했습니다. 사용자가 프롬프트를 보내면 답변을 받는 식이었죠.

오늘날의 코딩 어시스턴트는 에이전트입니다. 예를 들어, _"실패하는 결제 테스트를 수정해 줘"_와 같이 입력하면, 모델은 한 번에 답하지 않습니다. 파일 목록화(list files)부터 시작하여 일부 파일을 읽고, 구현 내용을 읽고, 테스트를 실행하고, 오류를 읽고, 코드를 수정하고, diff를 확인하고, 다시 테스트를 실행하는 루프가 돌아갑니다.

각 단계는 별도의 모델 호출이며, 각 호출마다 그 결과를 늘어나는 히스토리에 추가합니다.

누적 계산(예시)

각 호출마다 이전 내용을 모두 다시 보내기 때문에, 전체 입력량은 단계 수의 제곱에 비례하여 증가합니다. 지수 함수적이지는 않지만 빠르게 늘어납니다. 만약 에이전트가 시행착오(편집, 실패, stdout 읽기, 8~12회 재시도)에 빠지면, 단 하나의 무해한 프롬프트만으로도 녹색 체크 표시를 보기 전에 수십만 토큰을 소모할 수 있습니다.

3. 숨겨진 컨텍스트: 프롬프트 외에 무엇이 전송되는가

IDE에서 작성된 12단어짜리 프롬프트는 결코 단지 12개의 토큰만을 의미하지 않습니다. 여러 가지 요소들이 함께 실려갑니다.

A. 시스템 지침 및 도구 정의

에이전트 역할을 수행하려면, 모델은 어떻게 행동해야 하는지에 대한 지침과 호출할 수 있는 모든 도구(터미널, 파일 검색, 편집기, 브라우저 등)에 대한 설명이 필요합니다. 도구의 종류에 따라, 이 정보가 매 요청 상단에서 수천 개 또는 심지어 만 단위 토큰까지 차지할 수 있습니다.

B. 에디터 컨텍스트

많은 IDE 어시스턴트는 사용자가 무엇을 의미하는지 추측하기 위해 추가 컨텍스트를 가져옵니다. 여기에는 현재 파일, 최근에 본 파일, 선택 영역, 그리고 때로는 열려 있는 탭이나 검색 결과의 스니펫이 포함됩니다. 얼마나 많은 정보가 포함되는지는 도구와 설정에 크게 좌우됩니다. 모든 열린 탭 전체가 포함되기는 드물지만, 관련 없는 파일이라도 의미 있는 노이즈를 추가할 수 있습니다.

C. 거대한 터미널 출력

테스트 스위트(test suite)가 충돌하면, 전체 터미널 출력을 붙여넣고 싶은 유혹을 느낍니다. 경고, 사용 중단 알림(deprecation notices), 그리고 원시 JSON이 포함된 전체 스택 트레이스(stack trace)는 한 번의 붙여넣기로 쉽게 수천 개의 토큰을 추가할 수 있습니다. 에이전트 루프(agent loop) 내에서는 이 출력이 이후 단계마다 재전송됩니다.

4. 가격 비대칭성: 입력, 출력 및 추론

모든 토큰의 가격이 같은 것은 아닙니다. 주요 제공업체 전반에 걸친 일반적인 패턴은 다음과 같습니다:

숨겨진 추론 비용 (The hidden reasoning cost)

추론 모델(Reasoning models)과 확장된 사고 기능이 켜진 모델은 답변을 하기 전에 내부적인 숙고 과정을 거칩니다. 이 토큰들은 채팅에서 결코 보이지 않을 수 있지만, 일반적으로 출력 비율로 청구됩니다. 까다로운 아키텍처 질문 하나만으로도 보이는 답변 외에 수천 개의 추론 토큰이 생성될 수 있습니다.

5. 프롬프트 캐싱: 구세주이자 함정

방대한 히스토리(history)를 재전송하는 것은 파멸적일 수 있으므로, 주요 제공업체들은 **프롬프트 캐싱(prompt caching)**을 제공합니다.

작동 방식

모델이 텍스트를 처리할 때, 토큰의 내부 키-값(key-value, KV) 표현을 구축합니다. 캐싱 기능을 사용하면, 제공업체가 반복되는 **접두사(prefix)**에 대한 이 값들을 저장합니다. 다음 요청이 정확히 동일한 토큰으로 시작하는 경우, 그 부분은 재계산되는 대신 캐시에서 큰 할인율로 읽어올 수 있습니다.

함정: 접두사 일치 (Prefix matching)

캐싱은 프롬프트의 시작부터 작동하며, 비활성 상태가 지속되면 보통 몇 분 후에 캐시가 만료됩니다.

만약 상단 근처(시스템 프롬프트를 수정하거나, 대화 위에 파일을 삽입하거나, 초반 컨텍스트를 변경하는 설정을 뒤집는 경우)에 무언가를 변경하면, 그 지점 이후의 모든 내용은 캐시에서 누락되어 다시 전체 입력 요율로 청구됩니다.

실질적인 교훈은 안정적인 콘텐츠를 상단에 유지하고, 새로운 콘텐츠는 하단에 추가하며, 초반 컨텍스트를 불필요하게 재배열하는 것을 피하는 것입니다.

6. SKILL.md 또는 규칙 파일이 더 많은 비용을 발생시키나요, 아니면 적게 발생시키나요?

많은 팀들이 재사용 가능한 지침을 SKILL.md, .cursorrules 또는 유사한 규칙 파일로 패키징합니다.

• 턴당 비용 (Turn cost): 도구가 항상 규칙 파일을 첨부한다면, 그 크기를 모든 요청에 추가합니다. 만약 도구가 관련성이 있을 때만 스킬을 로드한다면, 해당 턴에서만 비용을 지불하게 됩니다. 사용 중인 도구가 어떻게 작동하는지 확인해 보세요.
• 시스템 비용 (System cost): 모듈식 지침은 회사가 가진 모든 프레임워크, 린트 규칙 및 관례를 다루는 거대한 항상 활성화된(always-on) 프롬프트보다 우수합니다.
• 반복 요인 (Iteration factor): 가장 비싼 토큰은 불필요한 재시도에서 발생합니다. 짧은 스킬 파일이 에이전트에게 필요한 정확한 테스트 설정을 제공한다면, 5번의 실패한 실행을 반복하는 대신 첫 번째 시도에 성공할 수 있습니다.

사전에 준비된 좋은 지침 1,000 토큰은 피해야 할 재시도를 여러 배로 절약해 줄 수 있습니다.

7. 토큰이 어디로 가는지: 개발 및 테스트 라이프사이클에서 가장 무거운 활동들

어떤 작업들은 본질적으로 저렴합니다. 다른 작업들은 긴 에이전트 루프, 거대한 입력 또는 무거운 추론으로 변모합니다. 여기는 일반적인 주요 비용 발생원들을 라이프사이클 단계별로 대략 분류하고, 각각이 왜 토큰을 소모하는지, 그리고 어떻게 이를 억제할 수 있는지 설명합니다.

계획 및 설계 (Planning and design)

테스트 및 QA

코드 리뷰, 보안 및 유지보수

공통 패턴

거의 모든 비용이 많이 드는 활동은 다음 중 하나 이상을 결합합니다:

1. 광범위한 입력: 여러 파일, 큰 로그, 전체 diff 또는 전체 보고서.
2. 많은 반복: 재시도 루프(retry loops), 반복적인 테스트 실행, 시행착오.
3. 큰 출력: 일괄 테스트(bulk tests), 대규모 데이터셋, 긴 문서.
4. 심층 추론: 어려운 문제를 사고 모델(thinking models)에 보내기.

네 가지 중 하나만 잘라내도 비용이 떨어집니다. 두 개를 잘라내면 급격히 감소합니다.

8. 개발자 및 테스터 플레이북: AI 비용 제어를 위한 5가지 규칙

AI 비용을 합리적으로 유지하기 위해 FinOps 팀이 필요하지 않습니다. 기본적인 프롬프트 위생(prompt hygiene)만 있으면 됩니다.

규칙 1: 각 개별 작업마다 새로 시작하기

긴 대화 스레드에는 오래된 파일 내용, 이전 테스트 출력, 막다른 길 등이 쌓입니다. 일부 도구는 긴 스레드를 자동으로 요약하거나 자르지만, 남아 있는 노이즈(noise) 역시 토큰을 소모하고 모델을 혼란스럽게 할 수 있습니다.

규칙: 각 별도의 티켓(ticket), 버그 또는 하위 작업마다 새로운 세션을 시작하세요. 디버깅의 짐을 기능 개발에 끌어오지 마세요.

규칙 2: 어떤 컨텍스트를 포함할지 제어하기

관련 없는 탭을 닫는 것이 열린 파일에서 정보를 가져오는 에디터에서는 도움이 될 수 있지만, 명시적인 컨텍스트가 더 중요합니다.

규칙: 원하는 파일만 정확히 첨부하고 (예를 들어 @-멘션 사용), 범위를 명시하세요: "오직 `billing_service.py`와 `test_billing.py`만 변경합니다."

규칙 3: 광범위한 크롤링 대신 명시적 포인터 사용하기

"테스트가 왜 실패하는지 찾아 고쳐줘" 와 같은 프롬프트는 피하세요. 에이전트는 디렉토리 트리, 설정 파일 및 여러 파일을 탐색하며 전체 과정에서 토큰을 소모해야 합니다.

더 좋은 방법: 직접 테스트를 실행하여 실패 원인을 격리하고, 그 지점을 명시적으로 가리키세요:
"tests/test_billing.py의 `test_refund_rounding`에서 이 어설션(assertion)으로 인해 실패합니다. 로직은 `billing/refunds.py`의 `calculate_refund()`에 있습니다. 반올림 처리를 수정하세요."

규칙 4: 모델 크기 적정화 (Right-size the model)

모의 JSON Fixture, 정규 표현식(regex), 또는 단위 테스트(unit-test) 반복 코드(boilerplate)를 위해 가장 무거운 추론 모델을 사용하지 마세요.

• 일상적인 스캐폴딩(scaffolding), 구문 및 반복 코드를 위해서는 빠르고 저렴한 모델을 사용하세요.
• 최첨단 추론 모델은 다중 파일 버그, 동시성 문제(concurrency issues), 복잡한 리팩토링에 아껴두세요.

규칙 5: 로그 및 출력 간소화 (Trim logs and output)

터미널 출력을 400줄 분량으로 붙여넣지 마세요. 실패하는 어설션, 가장 관련성이 높은 몇 개의 스택 프레임(stack frames), 그리고 그것을 유발한 입력을 유지하세요. 에이전트가 직접 명령을 실행할 때는 조용한 출력(quiet output)을 요청하세요. 예를 들어 pytest -q 또는 pytest -x --tb=short를 사용합니다.

보너스: 재시도 횟수를 제한하세요. 만약 에이전트가 동일한 수정 사항에 대해 세 번 연속 실패했다면, 작업을 중단하고 스스로 검토하여 더 날카로운 포인터를 제공하세요.

요약 (Summary)

AI 도구는 시간당 또는 답변의 지능 수준으로 비용을 청구하지 않습니다. 그들은 **볼륨과 반복 횟수(volume and iteration)**로 비용을 청구합니다: 모든 입력 토큰, 생성된 모든 토큰, 추론에 사용된 모든 토큰, 그리고 모든 루프의 모든 단계가 그렇습니다.

비서 역할을 하는 에이전트를 전지전능한 오라클처럼 취급하고 레포지토리 전체를 헤매도록 내버려 두면, 에이전트 루프(agent loops)가 사용량을 빠르게 늘릴 것입니다. 작업을 범위 한정하고, 정확한 파일로 포인팅하며, 노이즈가 많은 출력을 간소화하고, 적절한 모델을 선택하며, 캐싱(caching) 기능을 활용하세요. 그러면 비용은 훨씬 적게 들면서도 동일한 엔지니어링 속도를 유지할 수 있습니다.

본문은 Medium에 최초 게재되었습니다.