AI 코딩 비용은 왜 예상보다 커질까? 코딩 에이전트의 토큰 사용량 읽는 법

AI 코딩 도구를 사용하다 보면 간단한 기능 하나를 요청했을 뿐인데 사용량이 예상보다 빠르게 줄어드는 경험을 하게 된다. 처음에는 프롬프트 한두 줄만 입력했기 때문에 비용도 그만큼 작을 것이라고 생각하기 쉽다.

하지만 코딩 에이전트는 사용자가 입력한 문장만 처리하지 않는다. 프로젝트 구조를 읽고, 관련 파일을 찾고, 코드를 수정하고, 테스트를 실행하고, 오류 로그를 분석한 뒤 다시 수정한다. 이전 대화와 프로젝트 기록까지 함께 전달되면 하나의 요청 뒤에 여러 차례의 모델 호출이 발생할 수 있다.

Ben’s Bites의 「Fable 5.1 — where do my tokens go?」는 이런 현상을 이해하는 데 참고할 만한 사례를 소개한다. 이 글에서는 해당 뉴스레터에 등장한 토큰 사용 사례를 살펴보고, 코딩 에이전트의 사용량이 어떤 과정에서 증가하는지 정리한다. 특히 원문에 직접 제시된 수치와, 그 사례를 바탕으로 확장한 분석을 구분해 설명한다.

출처: Fable 5.1 — where do my tokens go?, Ben’s Bites, 2026년 9월 3일

1. 토큰은 프롬프트에만 사용되지 않는다

LLM을 처음 사용할 때는 토큰을 사용자가 입력한 문장과 모델이 생성한 답변의 길이 정도로 생각하기 쉽다. 물론 이것도 토큰 사용량의 중요한 부분이다. 그러나 코딩 에이전트가 실제 개발 작업을 수행할 때는 훨씬 많은 정보가 모델에 전달된다.

예를 들어 다음과 같은 작업을 생각해 보자.

로그인 화면에 비밀번호 찾기 기능을 추가해 줘.

사용자에게는 한 문장이지만 에이전트에게는 다음과 같은 여러 단계가 필요할 수 있다.

1. 프로젝트의 디렉터리 구조 확인

2. 로그인 화면과 인증 관련 파일 검색

3. 사용자 모델과 API 구조 확인

4. 기존 라우팅과 상태 관리 방식 파악

5. 관련 코드를 수정

6. 테스트 실행

7. 오류 로그 확인

8. 오류가 발생하면 다시 코드 수정

9. 수정된 코드에 대한 테스트 재실행

이 과정에서 모델이 읽는 소스 코드, 설정 파일, README, 테스트 결과, 오류 로그가 모두 컨텍스트로 사용될 수 있다. 따라서 비용은 사용자가 입력한 문장 하나의 길이만으로 결정되지 않는다.

코딩 에이전트의 사용량을 이해하려면 다음 네 가지를 함께 봐야 한다.

• 모델에 전달된 입력 토큰

• 모델이 생성한 출력 토큰

• 이전 대화와 프로젝트 맥락의 크기

• 오류 수정과 재시도에 따른 추가 호출 횟수

즉, 에이전트의 비용은 프롬프트의 길이보다 작업 전체의 흐름에 더 크게 좌우될 수 있다.

2. Ben’s Bites가 보여준 토큰 사용 사례

Ben Tossell은 뉴스레터에서 에이전트를 활용해 여러 가지 제품과 도구를 직접 구축한 경험을 공유했다. 이 과정에서 OpenRouter의 공개 사용량을 스크래핑해 실시간 토큰 사용량을 보여주는 도구도 만들었다.

그가 소개한 사례 중에는 다음과 같은 내용이 있다.

• OpenRouter 상위 20개 앱에서 당시 초당 약 5,350만 토큰이 처리되고 있었다.

• 공개 정부 정보 약 1억 500만 행을 수집·분석하는 작업에 20억 토큰을 사용했다.

• 에이전트를 이용해 이미지 배경 제거 서비스의 대체 서비스를 구축했다.

• 에이전트를 활용한 빌드 작업을 이어가면서 Fable의 주간 사용량을 모두 소진했다.

이 사례들은 AI 에이전트가 단순히 코드를 한 번 생성하는 도구가 아니라, 탐색·구현·실행·검증을 반복하는 개발 환경으로 사용되고 있다는 점을 보여준다.

다만 각각의 수치를 해석할 때는 주의가 필요하다. 특히 5,350만 토큰/초와 20억 토큰은 서로 다른 성격의 수치다.

2.1 5,350만 토큰/초는 개인 사용량이 아니다

Ben이 소개한 초당 약 5,350만 토큰이라는 수치는 OpenRouter의 공개 사용량을 통해 관찰한 생태계 전체의 순간적인 처리 규모다. 특정 사용자가 소비한 토큰이나 Ben 개인의 코딩 비용을 의미하지 않는다.

따라서 다음과 같이 이해해야 한다.

OpenRouter 상위 앱에서 초당 약 5,350만 토큰이 처리되는 장면은 다양한 애플리케이션에서 LLM 사용량이 얼마나 빠르게 커지고 있는지를 보여주는 지표다. 이것을 특정 개발자의 사용량이나 청구 금액으로 해석해서는 안 된다.

개인의 비용을 계산하려면 자신의 API 호출 기록, 모델별 입력·출력 토큰, 캐시된 토큰, 요금제와 단가를 별도로 확인해야 한다.

2.2 20억 토큰은 대규모 데이터 작업의 누적 사용량이다

Ben은 공개 정부 정보 약 1억 500만 행을 수집하고 분석하는 작업에 20억 토큰을 사용했다고 밝혔다. 이 수치는 일반적인 기능 하나를 추가하는 코딩 작업의 비용이라기보다, 대규모 데이터를 다루는 별도 빌드 작업에서 발생한 누적 사용량으로 보는 것이 적절하다.

또한 20억 토큰을 곧바로 특정 금액의 비용으로 환산해서는 안 된다. 원문만으로는 다음 사항이 명확하지 않기 때문이다.

• 입력 토큰과 출력 토큰이 각각 얼마나 포함됐는지

• 캐시된 입력 토큰이 포함됐는지

• 어떤 모델을 사용했는지

• 여러 차례의 실행과 재시도가 합산됐는지

• API 사용량인지, 구독형 서비스의 사용량인지

• 모델 호출 외에 데이터 수집·저장·처리 비용이 얼마나 발생했는지

토큰 수와 실제 비용은 관련이 있지만 같은 개념은 아니다. 실제 청구액은 모델별 단가와 토큰 종류, 캐싱 정책, 사용 방식에 따라 달라진다.

3. 코딩 에이전트의 토큰 사용량이 증가하는 네 가지 상황

이제 코딩 에이전트의 사용량이 증가하는 과정을 네 가지로 나누어 보자.

다만 먼저 한 가지를 분명히 할 필요가 있다. 아래의 네 가지 구분은 Ben’s Bites 원문에서 직접 측정해 제시한 공식 분류가 아니다. 원문에 소개된 에이전트 개발 사례를 바탕으로, 코딩 에이전트의 토큰 소비 구조를 이해하기 위해 추가한 분석 틀이다.

3.1 새 기능을 추가할 때

새 기능을 요청하면 에이전트는 새 코드만 생성하지 않는다. 기존 코드와의 연결 관계를 먼저 이해해야 한다.

예를 들어 결제 기능을 추가한다고 하자. 에이전트는 다음 내용을 확인할 수 있다.

• 기존 사용자와 주문 데이터 모델

• 결제 관련 API

• 인증과 권한 처리 방식

• 프런트엔드의 상태 관리 방식

• 오류 처리 규칙

• 테스트 코드

• 환경 변수와 외부 서비스 설정

프로젝트가 작다면 읽어야 할 파일이 적다. 그러나 프로젝트가 커지거나 구조가 복잡하면 기능 하나를 구현하기 전에 상당한 양의 코드와 문서를 읽어야 한다.

따라서 기능 추가에 필요한 토큰은 생성된 코드의 길이만으로 결정되지 않는다. 에이전트가 새 기능을 기존 시스템에 연결하기 위해 읽어야 하는 맥락의 범위가 더 큰 영향을 미칠 수 있다.

3.2 반복 수정과 디버깅을 할 때

실제 개발에서 첫 번째 코드가 한 번에 완성되는 경우는 많지 않다. 테스트를 실행하면 오류가 발생하고, 예상하지 못한 예외 상황이 발견되며, 요구사항과 구현의 차이도 드러난다.

에이전트는 다음과 같은 과정을 반복할 수 있다.

1. 코드를 작성한다.

2. 테스트나 빌드 명령을 실행한다.

3. 오류 메시지를 읽는다.

4. 원인을 추정한다.

5. 코드를 수정한다.

6. 테스트를 다시 실행한다.

이 과정에서 각 단계마다 새로운 모델 호출이 발생할 수 있다. 특히 오류 로그가 길거나 여러 파일의 코드가 함께 전달되면 한 번의 재시도에도 상당한 토큰이 사용될 수 있다.

처음 요청한 문장은 짧았지만, 디버깅 과정에서 생성되는 오류 설명과 수정 코드, 테스트 결과가 누적되면서 전체 사용량이 커지는 이유다.

3.3 대화가 길어질 때

에이전트와의 대화가 길어지면 이전 요구사항과 결정 사항이 다음 요청의 맥락으로 사용될 수 있다.

처음에는 다음 정도의 내용만 전달될 수 있다.

• 구현할 기능

• 수정할 파일

• 간단한 요구사항

하지만 작업이 진행되면 다음 정보가 추가된다.

• 이전에 선택한 설계 방식

• 변경한 코드

• 테스트 실패 내역

• 사용자가 추가한 조건

• 에이전트가 제시한 대안과 그에 대한 결정

이런 정보가 계속 유지되면 에이전트가 현재 작업을 이해하는 데 도움이 된다. 반면 모든 대화가 계속 컨텍스트에 포함되면 입력 토큰이 증가할 수 있다.

다만 “대화가 길어지면 이전 토큰이 항상 같은 비율로 다시 과금된다”고 단정해서는 안 된다. 모델 제공업체와 도구에 따라 입력 캐싱, 컨텍스트 압축, 대화 요약 방식이 다르기 때문이다. 긴 대화가 비용을 증가시킬 가능성은 있지만, 실제 과금량은 사용 중인 서비스의 정책과 구현을 확인해야 한다.

3.4 이전 기록과 프로젝트 맥락을 전달할 때

새로운 세션에서 작업을 다시 시작하거나 다른 에이전트에게 작업을 넘길 때는 이전 기록을 전달해야 할 수 있다.

전달 대상은 다음과 같다.

• README와 설계 문서

• 프로젝트의 작업 규칙

• 이전 대화 요약

• 이슈와 작업 기록

• 관련 소스 코드

• 테스트 결과

• 오류 로그

• 기존에 내린 설계 결정

이전 기록은 에이전트가 같은 실수를 반복하지 않도록 돕는다. 하지만 현재 작업과 직접 관련이 없는 기록까지 모두 전달하면 컨텍스트만 커질 수 있다.

따라서 중요한 것은 모든 기록을 보존하는 것이 아니라, 현재 작업에 필요한 정보만 선별하는 것이다. 예를 들어 결제 화면의 버튼 위치를 수정하는 작업이라면 전체 데이터베이스 설계 문서보다 해당 화면의 컴포넌트 구조와 스타일 규칙이 더 중요할 수 있다.

4. 토큰 비용과 실제 비용은 다르다

토큰 사용량을 확인했다고 해서 바로 비용을 알 수 있는 것은 아니다. 실제 비용을 계산하려면 최소한 다음 항목을 구분해야 한다.

입력 토큰

모델에 전달되는 정보다. 사용자의 프롬프트뿐 아니라 코드, 문서, 이전 대화, 로그가 포함될 수 있다.

출력 토큰

모델이 생성한 답변과 코드다. 코드 변경량이 많거나 설명이 길면 출력 토큰도 증가한다.

캐시된 토큰

이전에 전달된 입력을 모델 제공업체가 재사용하는 경우다. 캐시된 입력은 일반 입력보다 낮은 단가가 적용될 수 있으므로, 같은 입력 토큰 양이라도 실제 비용이 달라질 수 있다.

모델별 단가

같은 토큰 수라도 사용하는 모델에 따라 가격이 다르다. 고성능 모델을 모든 탐색과 수정 작업에 사용하면 비용이 커질 수 있다.

구독형 서비스와 API의 차이

API는 일반적으로 호출된 토큰을 기준으로 직접 과금한다. 반면 구독형 코딩 도구는 사용량 제한, 모델별 가중치, 일정 기간의 사용 한도 등 별도의 정책을 사용할 수 있다.

그러므로 “20억 토큰을 사용했으니 비용은 얼마다”라고 단순하게 계산하려면 먼저 토큰의 구성과 모델, 요금 체계를 확인해야 한다.

5. 코딩 에이전트의 토큰 사용량을 줄이는 방법

토큰 비용을 줄이는 가장 좋은 방법은 프롬프트를 무조건 짧게 만드는 것이 아니다. 에이전트가 불필요한 파일과 기록을 읽지 않도록 작업 범위를 설계하고, 반복 작업을 줄이는 것이 더 중요하다.

5.1 작업 범위를 구체적으로 제한하기

다음과 같이 요청하면 에이전트가 탐색해야 할 범위를 줄일 수 있다.

src/auth 디렉터리 안에서만 수정해 주세요. 로그인 API의 응답 형식은 변경하지 말고, 관련 테스트 파일도 함께 수정해 주세요.

반대로 “프로젝트 전체를 개선해 줘”처럼 범위가 넓은 요청은 많은 파일 탐색과 추가 작업을 유발할 수 있다.

5.2 필요한 파일만 먼저 전달하기

저장소 전체를 매번 읽히기보다 현재 작업과 관련된 파일을 먼저 지정하는 것이 좋다.

• 수정 대상 파일

• 해당 파일이 호출하는 인터페이스

• 관련 테스트 파일

• 오류가 발생한 로그

필요한 경우에만 추가 파일을 요청하도록 작업 흐름을 나누면 불필요한 컨텍스트를 줄일 수 있다.

5.3 긴 대화를 요약하기

하나의 대화에서 모든 작업을 계속 이어가기보다, 일정한 단계가 끝나면 다음 내용을 요약해 새 작업으로 넘길 수 있다.

• 현재 구현 상태

• 확정된 설계 결정

• 아직 해결하지 못한 문제

• 수정한 파일

• 실행한 테스트와 결과

• 다음에 해야 할 작업

이렇게 하면 오래된 시행착오와 불필요한 설명을 계속 전달하지 않아도 된다.

5.4 로그 출력을 제한하기

전체 로그를 그대로 모델에 전달하면 오류 원인과 관련 없는 정보까지 포함될 수 있다. 로그의 범위를 제한하거나 오류가 발생한 부분 주변만 전달하면 입력량을 줄일 수 있다.

예를 들어 다음과 같은 방법을 사용할 수 있다.

• 최근 오류만 추출하기

• 특정 요청 ID의 로그만 전달하기

• 스택 트레이스의 핵심 구간만 전달하기

• 테스트 실패 목록만 먼저 확인하기

• 대용량 응답을 요약한 뒤 원문을 필요한 경우에만 전달하기

5.5 탐색과 최종 구현에 다른 모델 사용하기

모든 작업에 가장 비싼 모델을 사용할 필요는 없다. 파일 탐색, 간단한 형식 변환, 반복적인 코드 설명에는 상대적으로 저렴한 모델을 사용하고, 복잡한 설계 검토나 최종 리뷰에는 고성능 모델을 사용하는 방법도 있다.

다만 모델을 나누는 기준은 단순한 가격이 아니라 작업의 실패 비용까지 고려해야 한다. 저렴한 모델을 사용해 오류가 반복되면 오히려 전체 토큰 사용량이 늘어날 수 있기 때문이다.

6. 토큰 사용량을 읽을 때 확인할 질문

AI 코딩 도구의 사용량을 확인할 때는 단순히 총 토큰 수만 보지 말고 다음 질문을 함께 확인하는 것이 좋다.

1. 입력 토큰과 출력 토큰은 각각 얼마인가?

2. 캐시된 입력 토큰이 포함되어 있는가?

3. 어떤 모델이 사용되었는가?

4. 한 번의 요청에서 모델 호출이 몇 번 발생했는가?

5. 테스트 실패와 재시도가 얼마나 있었는가?

6. 전체 저장소를 읽었는가, 일부 파일만 읽었는가?

7. 대화 기록과 로그가 얼마나 전달되었는가?

8. 토큰 수가 실제 API 비용인가, 구독 서비스의 사용량 지표인가?

이 질문에 답할 수 있어야 토큰 사용량을 실제 비용과 연결해 해석할 수 있다.

7. 중요한 것은 토큰을 적게 쓰는 것이 아니라 낭비를 줄이는 것이다

AI 코딩 에이전트의 목표를 단순히 토큰 사용량 최소화로 설정하면 안 된다. 토큰을 아끼려다 필요한 맥락을 빼면 잘못된 코드가 생성되고, 이후 디버깅 과정에서 더 많은 토큰이 사용될 수 있다.

중요한 것은 다음의 균형이다.

• 에이전트가 작업을 이해하는 데 필요한 맥락은 충분히 제공한다.

• 현재 작업과 관련 없는 파일과 기록은 제외한다.

• 테스트와 검증을 통해 잘못된 결과를 빠르게 발견한다.

• 반복되는 작업은 명확한 규칙과 자동화로 줄인다.

• 모델 호출과 재시도 과정을 확인할 수 있도록 기록한다.

Ben’s Bites의 사례가 보여주는 것도 바로 이 지점이다. 에이전트는 단순한 코드 자동완성 기능을 넘어 실제 제품과 데이터 처리 도구를 구축하는 데 사용될 수 있다. 그만큼 많은 작업을 수행할 수 있지만, 탐색·생성·실행·검증이 반복되면 사용량도 빠르게 늘어난다.

마무리

AI 코딩 비용은 사용자가 입력한 프롬프트의 길이만으로 결정되지 않는다. 에이전트가 읽는 코드, 전달되는 대화 기록, 실행 결과, 오류 로그, 재시도 횟수, 사용하는 모델이 함께 비용을 만든다.

Ben’s Bites에 소개된 수치도 맥락을 구분해서 해석해야 한다. OpenRouter에서 관찰된 초당 약 5,350만 토큰은 특정 개인의 사용량이 아니라 생태계 전체의 순간적인 처리 규모다. 공개 정부 데이터 약 1억 500만 행을 처리하는 과정에서 사용한 20억 토큰은 대규모 데이터 작업의 누적 사용량이며, 그 자체가 곧바로 특정 금액의 청구 비용을 의미하지 않는다.

또한 새 기능 추가, 반복 수정, 긴 대화, 이전 기록 전달이라는 네 가지 구분은 원문에서 직접 측정한 공식 분류가 아니다. 원문의 사례를 바탕으로 코딩 에이전트의 토큰 소비 구조를 이해하기 위해 확장한 분석 틀이다.

결국 토큰 비용을 관리하는 핵심은 프롬프트를 짧게 만드는 데 있지 않다. 에이전트가 읽어야 할 범위를 적절히 제한하고, 필요한 맥락을 선별하며, 오류와 재시도를 줄이는 개발 프로세스를 만드는 데 있다.

AI 코딩 도구를 잘 사용하는 개발자는 토큰을 무조건 적게 쓰는 사람이 아니다. 어떤 작업에서 토큰이 발생하고, 어떤 호출이 실제 가치를 만들며, 어디에서 사용량이 낭비되는지 파악하는 사람이다.

참고

• Ben’s Bites — Fable 5.1: where do my tokens go?

• Ben Tossell — Realtime Tokens