AI 에이전트 컨텍스트 비용: 반복 프롬프트와 도구 호출을 측정하는 방법
멀티스텝 AI 에이전트의 컨텍스트 비용 측정 및 최적화 실무 가이드: 도구 스키마 분해, 기준선 측정, 품질 검증을 다룹니다.
목차
Claude Code, Cline, Roo Code 또는 자체 멀티스텝 파이프라인 같은 AI 에이전트를 개발할 때 컨텍스트가 쌓일수록 API 사용량이 늘 수 있습니다. 각 요청의 구체적인 구성은 클라이언트에 따라 달라집니다. 시스템 프롬프트, 사용 가능한 도구 스키마, 메시지 이력, 함수 호출 결과가 포함될 수 있습니다.
기능을 잃지 않고 예산을 관리하려면 고정된 작업에서 baseline을 측정하고, 불필요한 토큰의 주된 원인을 찾아 에이전트 환경을 한 번에 한 변수씩 최적화해야 합니다.
AI 에이전트 컨텍스트의 구조: 각 단계에서 토큰이 과금되는 항목
측정을 위해 모델로 전송되는 컨텍스트를 네 가지 관찰 가능한 구성 요소로 나눌 수 있습니다.
- 시스템 지침과 규칙(System Prompt): 기본 스타일 요구 사항, 보안 제약, 리포지토리 컨텍스트.
- 도구 스키마(Tool Schemas): 클라이언트가 요청에 포함하는 경우의 연결된 함수, 매개변수, 데이터 유형에 대한 JSON 설명.
- 메시지 이력(Message History): 작업이 진행되며 누적되는 이전 사용자 메시지와 에이전트 응답.
- 도구 결과(Tool Outputs): 읽은 파일 내용, 터미널 명령 로그, API 덤프.
첫 요청의 크기에 단계 수를 무작정 곱하지 마세요. 각 호출의 usage를 내보내야 합니다. 이력은 증가할 수 있고, 클라이언트는 데이터를 자를 수 있으며, 제공자는 cached tokens를 별도로 계산할 수 있습니다.
컨텍스트 원천과 최적화의 비교표
| 컨텍스트 구성 요소 | 측정할 항목 | 주요 과다 지출 위험 | 분리된 테스트에서의 변경 |
|---|---|---|---|
| Tool Schemas | 실제로 전송된 목록의 크기 | 공용 집합 안의 미사용 도구 | 작업에 필요한 tools만 남기기 |
| Tool Outputs | 각 결과의 크기 | 필요한 부분 대신 파일 전체를 읽기 | 줄 범위와 로그 양 제한하기 |
| 단계 이력 | 호출마다 늘어나는 input | 더 이상 필요 없는 결과가 누적됨 | 클라이언트가 지원하는 이력 축소 확인하기 |
| System Prompt | 접두사의 크기와 안정성 | 반복되는 지침 | 필수 규칙을 유지하며 중복 제거하기 |
단계별 가이드: baseline을 측정하고 지출을 줄이는 방법
먼저 현재 모델 요금을 기록하세요. baseline 계산에는 오래된 예시의 값이 아니라 현재 BetterToken 가격을 사용합니다. 현재 BetterToken 가격 보기
객관적인 최적화를 위해 한 변수만 바꾸는 측정 방법을 사용합니다.
1단계. 테스트를 위한 제어 작업 고정하기
재현 가능한 엔지니어링 시나리오를 선택합니다. 예를 들어 “리포지토리에서 검증 함수를 찾아 엣지 케이스 처리를 추가하고 unit test를 실행하기”입니다. 작업에는 pytest 또는 bun test의 종료 코드 0처럼 분명한 완료 기준이 있어야 합니다.
2단계. Baseline 측정하기(Input, Output, Cache)
표준 에이전트 설정으로 작업을 실행합니다. 로그나 모니터링 패널에 다음을 기록합니다.
- 실행한 단계 수
- 총 input tokens
- 총 output tokens
- 캐시된 토큰 양(
cached tokens) - 현재 요금 기준의 비용
선택한 모델의 현재 요금은 BetterToken 가격 페이지에서 확인합니다. Workspace에서는 승인된 요청의 모델, 시각, 상태, input/output tokens, 모델이 지원하는 경우 cached tokens, 호출 비용을 확인할 수 있습니다. 하나의 에이전트 단계가 여러 요청을 만들었다면 요청 수준 기록을 완성된 단계별 분석으로 제시하지 마세요. 시각과 자체 클라이언트 데이터를 사용해 연결해야 합니다.
3단계. 컨텍스트 변수 하나 변경하기
반복마다 정확히 하나의 매개변수만 바꾸며 분리된 테스트를 수행합니다.
- 실험 A(Tool Filtering): 제어 작업에 필요한 도구만 남기고 input tokens 차이를 측정합니다.
- 실험 B(Output Truncation): 2,000줄 전체 덤프 대신 오류의 처음 50줄로 터미널 출력을 제한합니다.
- 실험 C(Prefix Stability): 모델과 endpoint가 prompt caching을 지원한다면 시스템 프롬프트와 도구 스키마의 순서를 바꾸지 말고 실제 cached tokens 데이터를 확인합니다.
4단계. 경제성과 해결 품질 평가하기
최종 지표를 원래 baseline과 비교합니다. 제어 작업이 계속 같은 품질 기준을 충족하고, 측정된 시간 또는 지출이 자신의 실행 집합에서 개선될 때에만 변경을 유지합니다.
에이전트 환경 구성 권장 사항
- 역할별로 도구 집합을 좁히세요: 읽기 에이전트에는 쓰기 기능이 필요 없습니다. 결과를 해치지 않고 실제 input을 줄이는지 확인합니다.
- 안정적인 접두사를 유지하세요: caching이 지원되면 공통 규칙의 순서를 불필요하게 바꾸지 말고, 할인을 가정하는 대신 cached tokens를 확인합니다.
- 루프에 한계를 두세요: 구체적인 작업에 맞는 유한한 시도 횟수와 명시적인 중지 조건을 설정합니다.
경계 사례와 흔한 실수
- 실수: 중요한 검증 스키마를 끄는 것. 도구 스키마 설명을 지나치게 줄이면 모델이 잘못된 JSON을 보내고 반복 요청의 연쇄가 생길 수 있습니다.
- 실수: 소셜 미디어의 절감 주장을 무비판적으로 믿는 것. 컨텍스트 최적화의 효과는 리포지토리 구조와 평균 파일 크기에 따라 달라집니다.
- 실수: 투명한 텔레메트리가 없는 것. endpoint가 input/cache tokens를 분리한 통계를 반환하지 않으면 가정으로 캐시 사용량을 추정하지 말고, 값을 unknown으로 표시합니다.
