AI 코딩 에이전트 비용 관리: 토큰 로그·컨텍스트·모델 라우팅 실무 가이드

AI 코딩 에이전트는 일반 챗봇보다 비용이 빨리 커진다. 이유는 단순하다. 코드베이스 설명, 파일 내용, 터미널 출력, 테스트 로그, 이전 대화, 도구 호출 결과가 계속 컨텍스트에 쌓인다. 에이전트가 한 번에 문제를 해결하면 좋지만, 실패한 테스트를 다시 읽고 계획을 수정하고 다른 파일을 열면 토큰이 누적된다.

Anthropic의 Claude Code 비용 문서는 엔터프라이즈 배포에서 활성 개발자 1명당 평균 비용이 하루 약 13달러, 월 150~250달러 수준이며, 90% 사용자는 활성일 기준 30달러 미만이라고 안내한다. 이 숫자는 팀마다 달라질 수 있지만, 한 가지는 분명하다. 코딩 에이전트 비용은 모델 단가보다 작업 방식과 컨텍스트 관리에 크게 좌우된다.

왜 코딩 에이전트는 토큰을 많이 쓰는가

일반 채팅은 사용자의 질문과 모델의 답변이 주된 비용이다. 코딩 에이전트는 여기에 파일 읽기, 검색, 계획, 패치, 테스트, 오류 분석이 붙는다. 특히 큰 레포에서 “전체 구조를 파악하고 고쳐줘”라고 요청하면 에이전트는 많은 파일을 읽는다. 테스트가 실패하면 실패 로그를 다시 읽고, 수정한 코드를 다시 설명하고, 또 테스트한다.

또 하나의 비용 요인은 병렬 에이전트다. 여러 하위 에이전트를 동시에 띄우면 각 에이전트가 자기 컨텍스트를 가진다. 같은 레포 설명과 규칙을 여러 번 읽을 수 있다. 병렬화는 속도를 높이지만, 토큰 비용도 거의 에이전트 수에 비례해서 늘 수 있다.

따라서 코딩 에이전트 비용 관리는 “싼 모델을 쓰자”로 시작하면 안 된다. 먼저 에이전트가 무엇을 읽고, 몇 번 실패하고, 어떤 작업에서 컨텍스트가 커지는지 측정해야 한다.

비용 로그는 세션 단위와 작업 단위로 나눈다

코딩 에이전트 로그는 API 요청 단위만으로는 부족하다. 개발자는 “이 버그 수정 하나에 얼마가 들었는가”를 알아야 한다. 그래서 세션 단위, 작업 단위, 요청 단위 로그를 모두 남기는 것이 좋다.

작업 단위에는 다음 필드가 필요하다.

• task_id: 버그 수정, 리팩터링, 테스트 작성 같은 작업 식별자
• repository: 레포 이름
• branch: 작업 브랜치
• model_policy: 사용한 모델 라우팅 정책
• files_read: 읽은 파일 수
• files_changed: 수정한 파일 수
• tests_run: 실행한 테스트 수
• test_failures: 실패 횟수
• total_input_tokens, total_output_tokens
• total_cost_estimate
• human_interventions: 사람이 중간에 개입한 횟수
• final_status: merged, pr_opened, failed, abandoned

이렇게 보면 단순한 비용보다 더 중요한 지표가 나온다. 예를 들어 비용이 높은 작업이라도 PR이 바로 머지된다면 가치가 있을 수 있다. 반대로 5달러밖에 안 들었지만 매번 실패하고 사람이 다시 고친다면 싼 게 아니다.

컨텍스트를 줄이는 작업 지시 방식

코딩 에이전트에게 작업을 줄 때 가장 비싼 문장은 “알아서 전체를 보고 고쳐줘”다. 에이전트가 레포 전체를 탐색하게 만들기 때문이다. 더 나은 지시는 범위를 좁힌다.

나쁜 예시는 다음과 같다.

• “로그인이 안 되는데 고쳐줘.”
• “앱이 느린데 최적화해줘.”
• “테스트 깨지는 것 다 봐줘.”

좋은 예시는 다음과 같다.

• “로그인 버튼 클릭 후 /api/session이 401을 반환한다. auth/session.ts와 middleware.ts를 우선 확인하고, 관련 테스트만 실행해줘.”
• “홈 화면 첫 렌더링이 느리다. 이미지 로딩과 API waterfall을 중심으로 원인을 좁혀줘. UI 변경은 하지 말고 측정 결과부터 보고해줘.”
• “CI에서 user-profile.spec.ts만 실패한다. 실패 로그는 아래에 붙인다. 테스트 의도를 유지하면서 최소 수정해줘.”

좋은 지시는 파일 후보, 증상, 재현 절차, 금지 범위, 완료 기준을 포함한다. 이것만으로도 에이전트가 읽는 파일 수와 재시도 횟수가 줄어든다.

모델 라우팅은 단계별로 한다

코딩 작업 전체를 항상 최고급 모델에 맡기면 비용이 커진다. 반대로 전부 저렴한 모델에 맡기면 실패율이 올라가 재시도 비용이 생긴다. 단계별 라우팅이 현실적이다.

• 탐색 단계: 파일 후보 찾기, 로그 분류, 영향 범위 추정은 중간급 모델로 시작한다.
• 계획 단계: 아키텍처 판단이 필요한 경우 강한 모델로 올린다.
• 수정 단계: 작은 패치와 테스트 수정은 중간급 모델로 충분할 수 있다.
• 리뷰 단계: 보안, 결제, 데이터 손실 가능성이 있는 변경은 강한 모델 또는 사람 리뷰를 넣는다.

라우팅 정책에는 승격 조건이 필요하다. 같은 테스트가 2회 이상 실패하면 강한 모델로 올린다. 수정 파일이 10개를 넘으면 사람 확인을 받는다. 마이그레이션, 인증, 결제, 삭제 로직은 자동 머지를 금지한다. 이런 규칙이 있어야 비용과 위험을 동시에 줄일 수 있다.

병렬 에이전트는 작게 시작한다

여러 에이전트를 동시에 쓰면 멋져 보이지만, 모든 작업에 필요한 것은 아니다. 하위 에이전트마다 컨텍스트 창이 생기고, 공통 지시문과 레포 설명이 반복될 수 있다. 작은 버그 수정에 5개 에이전트를 띄우면 회의 비용이 개발 비용보다 커진다.

병렬화가 맞는 경우는 작업이 명확히 분리될 때다. 예를 들어 “프론트 UI 원인 분석”, “백엔드 API 로그 분석”, “테스트 재현 스크립트 작성”처럼 산출물이 다르면 병렬화할 수 있다. 반대로 같은 파일을 여러 에이전트가 동시에 고치면 충돌과 중복 분석이 늘어난다.

팀 정책으로는 기본 1개 에이전트, 복잡도 높음이면 2~3개, 그 이상은 사람 승인으로 두는 것이 안전하다. 비용 로그에는 하위 에이전트 수와 각 에이전트의 토큰 사용량을 따로 남긴다.

비용 절감보다 중요한 것은 실패 중단 조건이다

코딩 에이전트 비용이 폭증하는 순간은 대개 실패가 반복될 때다. 테스트가 계속 깨지는데 에이전트가 비슷한 수정을 반복하면 토큰은 계속 쌓인다. 그래서 중단 조건이 필요하다.

예를 들어 다음 조건에서는 멈추게 한다.

• 같은 테스트가 3회 연속 실패했다.
• 수정 파일이 최초 범위보다 2배 이상 늘었다.
• 데이터 삭제, 결제, 인증 토큰, 권한 체크 코드가 변경 대상에 포함됐다.
• 빌드 시간이 20분을 넘었다.
• 에이전트가 문제 원인을 설명하지 못한 채 패치만 반복한다.

중단은 실패가 아니라 비용과 리스크를 막는 안전장치다. 멈춘 뒤 사람에게 현재 가설, 읽은 파일, 실패 로그, 다음 후보를 요약해 주면 다시 이어갈 수 있다.

실행 체크리스트

• 작업 지시에는 증상, 재현 절차, 후보 파일, 금지 범위, 완료 기준을 포함한다.
• 세션 단위가 아니라 task_id 단위로 토큰과 비용을 집계한다.
• 읽은 파일 수, 수정 파일 수, 테스트 실행 횟수, 실패 횟수를 남긴다.
• 탐색·계획·수정·리뷰 단계별로 모델 라우팅 정책을 만든다.
• 같은 실패가 반복되면 강한 모델로 승격하거나 사람 확인을 받는다.
• 하위 에이전트는 기본 1개로 시작하고, 분리 가능한 작업일 때만 늘린다.
• 인증, 결제, 삭제, 권한 코드는 자동 적용하지 않고 별도 리뷰한다.
• 비용 대시보드에는 성공한 PR당 비용, 실패 작업당 비용, 재시도 비용을 함께 표시한다.
• 참고 출처: Claude Code 비용 관리 문서 https://code.claude.com/docs/en/costs.