
AI 에이전트 시대의 토큰 절감 기법 정리
요약
GitHub Copilot의 과금 체계 변화에 따라 AI 에이전트 운영 시 토큰 비용 관리가 중요해졌습니다. 본 기사는 입력, 출력, 모델 선택, 컨텍스트 관리를 통한 효율적인 토큰 절감 기법을 제안합니다.
핵심 포인트
- GitHub Copilot의 AI Credits 기반 사용량 과금 체계 이해
- 프롬프트 캐싱을 활용한 입력 토큰 비용 및 레이턴시 절감
- 불필요한 서론이나 반복을 줄이는 출력 토큰 최적화
- 에이전트 작업의 단계별 분리(조사, 구현, 요약)를 통한 안정성 확보
2026년 6월 1일부터, GitHub Copilot의 과금 체계는 GitHub AI Credits 기반의 사용량 과금으로 이행되었습니다.
GitHub 공식 문서에서는 Copilot 이용 시 다음과 같은 토큰이 소비된다고 설명하고 있습니다.
- 입력 토큰 (Input Token)
- 출력 토큰 (Output Token)
- 캐시된 토큰 (Cached Token)
또한, 1 AI credit은 $0.01 USD 상당으로 취급됩니다.
코드 보완(Code Completion)과 Next Edit Suggestions는 적어도 GitHub 공식 문서상으로는 AI Credits의 과금 대상에서 제외됩니다. 반면, Copilot Chat, CLI, Cloud Agent, Spaces, Spark, 서드파티 coding agent 등은 AI Credits를 소비합니다.
즉, 앞으로는 "AI를 사용할 것인가"뿐만 아니라, 얼마나 많은 토큰을 사용하는가가 개발 비용과 직결되기 쉬워집니다.
이 기사에서는 AI 에이전트나 LLM API를 사용할 때의 토큰 절감 기법을 정리합니다.
특정 도구의 비책이 아니라, LLM API나 AI 에이전트 전반에서 사용할 수 있는 사고방식을 중심으로 정리합니다.
- 토큰 절감은 입력, 출력, 모델 선택, 컨텍스트 관리(Context Management)로 나누어 생각한다
- 가장 효과가 큰 것은 정적 컨텍스트를 캐시하고, 불필요한 문맥을 보내지 않는 것이다
- AI 에이전트에서는 긴 대화를 이어가기보다 "조사", "구현", "요약"을 나누는 편이 안정적이기 쉽다
먼저, LLM API의 비용은 대략 다음과 같이 결정됩니다.
비용 = 입력 토큰 × 입력 단가
+ 출력 토큰 × 출력 단가
+ 캐시 관련 토큰 × 캐시 단가
실제 단가나 캐시 취급은 모델이나 프로바이더(Provider)에 따라 다릅니다.
중요한 것은 토큰 절감에는 여러 방향이 있다는 점입니다.
| 절감 대상 | 예 |
|---|---|
| 입력 토큰 | 긴 설계서, 대화 이력, 로그, JSON, 코드 전문 |
| ... |
"프롬프트를 짧게 한다"는 것만으로는 불충분합니다.
AI 에이전트 시대에는 어떤 정보를, 어떤 모델에, 몇 번 보내고 있는가를 살펴볼 필요가 있습니다.
입력 토큰 절감에서 우선적으로 고려해야 할 것이 프롬프트 캐싱(Prompt Caching)입니다.
프롬프트 캐싱은 동일한 프롬프트의 전반부 부분을 재사용하기 쉽게 만드는 메커니즘입니다.
대표적으로 다음과 같은 정보가 캐시와 궁합이 좋습니다.
- 시스템 프롬프트 (System Prompt)
- 프로젝트 규약
- 코딩 규칙
- API 사양
- 고정된 설계 방침
- 도구 정의
반대로, 다음은 매번 바뀌기 쉬우므로 캐시의 방해가 되기 쉽습니다.
- 최신 사용자 메시지
- 도구 실행 결과
- 현재 시각
- 랜덤 ID
- 매번 바뀌는 로그
- 최근의 차이점(Diff)
기본 형태는 다음과 같습니다.
[상단: 잘 변하지 않는 정보]
- 시스템 프롬프트
- 프로젝트 규약
...
Anthropic의 공식 설명에 따르면, 프롬프트 캐싱을 통해 캐시된 내용의 읽기는 통상적인 입력보다 훨씬 저렴합니다. 다만, 캐시의 쓰기나 TTL, cache control 지정 방법은 모델이나 API에 따라 다릅니다.
OpenAI의 API에도 Prompt Caching이 있어, 긴 공통 접두사(Prefix)를 재사용함으로써 레이턴시(Latency)나 입력 비용을 낮출 수 있는 경우가 있습니다.
사용하는 서비스마다 사양이 다르므로, "캐시가 있는 것 같다"가 아니라 실제 API 사양과 과금표를 확인하는 것이 안전합니다.
다음에 효과적인 것이 출력 토큰의 절감입니다.
AI 에이전트는 방치하면 다음과 같은 출력을 하기 쉽습니다.
- 긴 서론
- 이미 알고 있는 배경 설명
- 유사한 내용의 반복
- 코드 전문 재게시
- 변경하지 않은 파일에 대한 설명
- 마지막의 일반적인 요약
이를 줄이기 위해서는 출력 포맷을 명시합니다.
예를 들어, 조사만 해주길 원하는 경우:
조사 결과만 반환해 주세요.
코드 전문은 불필요합니다.
출력 형식:
...
코드 리뷰의 경우:
중대한 문제만을 우선해 주세요.
문제가 없다면 "중대한 문제 없음"이라고만 반환해 주세요.
설명은 각 지적 사항당 최대 3문장으로 제한합니다.
설계 상담의 경우:
선택지를 3개 이내로 좁혀 주세요.
각 안은 다음 항목만으로 비교해 주세요.
- 장점
...
이른바 "Caveman Prompt"와 같이 극단적으로 짧은 출력을 요구하는 프롬프트도 화제가 되고 있습니다.
다만, 이러한 압축 프롬프트가 만능은 아닙니다.
적합한 상황은 다음과 같습니다.
- 에이전트의 설명이 너무 길 때
- 요점만 파악하면 될 때
- 동일한 형식으로 결과를 반복해서 반환할 때
- 코드가 아닌 조사, 분류, 요약이 중심일 때
적합하지 않은 상황은 다음과 같습니다.
- 초보자를 위한 설명
- 설계서나 사양서 작성
- 오해를 피해야 하는 리뷰
- 고객용 문서
- 코드 블록 자체가 출력의 대부분을 차지하는 경우
단순히 짧으면 좋은 것은 아닙니다.
인간이 이해할 수 있는 최소량을 목표로 하는 것이 현실적입니다.
로그, JSON, CSV, DB 쿼리 결과, 긴 에러 트레이스 (Error Trace)를 그대로 LLM에 전달하면 입력 토큰 (Input Token)이 급격히 증가합니다.
그전에 기계적으로 깎아낼 수 있는 것을 먼저 제거합니다.
예를 들어, 로그라면 다음을 제거할 수 있습니다.
- 중복 행
- 타임스탬프만 다른 동일 에러
- 디버그 (debug) 로그
- 성공한 요청
- 관계없는 서비스 (service) 이름
- 너무 긴 스택 트레이스 (stack trace)의 중간 부분
JSON이라면 다음을 제거할 수 있습니다.
- null 항목
- 빈 배열
- UI 표시와 관계없는 메타데이터 (metadata)
- 중복되는 필드
- 거대한 본문
예:
{
"request_id": "req_123",
"status": 500,
...
LLM에게 보여주기 전에, 인간도 읽을 수 있을 정도까지 깎아내는 것이 기본입니다.
AI에게 "이 거대한 로그를 요약해줘"라고 던지기 전에, 먼저 프로그램으로 전처리할 수 없는지 고민해야 합니다.
모든 태스크에 고성능 모델을 사용하면 비용이 증가합니다.
태스크마다 필요한 능력은 다릅니다.
| 태스크 | 고성능 모델 필요 여부 |
|---|---|
| 오타 수정 | 낮음 |
| ... |
모델 라우팅 (Model Routing)의 기본은 다음과 같은 사고방식입니다.
가벼운 태스크:
저렴하고 빠른 모델
일반적인 개발 태스크:
...
단, 저렴한 모델을 사용한다고 해서 반드시 비용이 저렴해지는 것은 아닙니다.
정확도가 부족하여 여러 번 다시 시도하게 되면 결과적으로 비용이 더 높아집니다.
봐야 할 것은 1회당 단가뿐만 아니라, 완료까지의 총 비용입니다.
AI 에이전트를 장시간 사용하면 대화 컨텍스트 (Conversation Context)가 커집니다.
특히 무거운 항목은 다음과 같습니다.
- 파일 탐색
- grep 결과
- 테스트 로그
- 차이점 (diff) 읽기
- 여러 파일의 코드 전체
- 조사 중인 가설
이것들을 메인 대화에 전부 남겨두면, 다음 요청에서도 입력 토큰으로 쌓이게 됩니다.
그래서 조사 태스크를 분리합니다.
예:
src/auth 하위 디렉토리만 조사해 주세요.
코드 전체는 반환하지 마세요.
반환할 것:
...
메인 세션에는 요약본만 되돌립니다.
조사 결과:
- login.ts 가 입구
- session.ts 에서 Cookie를 발행
...
이렇게 하면 파일 탐색으로 인한 대량의 토큰을 메인 컨텍스트로 가져오기 어려워집니다.
코드로 설계서를 만들 때도 마찬가지입니다.
처음부터 모든 코드를 읽게 하는 것이 아니라, 먼저 "필요한 클래스와 함수만 추출"하게 한 뒤, 그 후에 설계서를 작성합니다.
API를 직접 사용하는 경우, 출력 상한을 설정할 수 있는 경우가 있습니다.
예를 들어, OpenAI SDK에서는 max_tokens나 max_completion_tokens 등 모델 및 API 형식에 따른 출력 상한 파라미터가 있습니다.
실제로 사용할 수 있는 파라미터 이름은 모델, SDK, API 버전에 따라 다르므로 최신 문서를 확인하십시오.
사고방식은 다음과 같습니다.
분류: 20~100 tokens
짧은 요약: 100~300 tokens
리뷰 지적 사항: 300~800 tokens
...
분류나 라우팅 같은 태스크에 긴 문장 출력은 불필요합니다.
종료 조건도 명시합니다.
해당 사항이 없는 경우 "없음"이라고만 답해 주세요.
이유 설명은 필요 없습니다.
이것만으로도 불필요한 출력을 줄일 수 있습니다.
긴 대화는 편리하지만 토큰 비용이 증가하기 쉽습니다.
특히 AI 에이전트에서는 대화가 길어질수록 다음과 같은 것들이 섞입니다.
- 이미 해결된 가설
- 오래된 에러
- 사용하지 않은 방침
- 도중에 버린 코드 안
- 관계가 없어진 로그
어느 정도 진행되었다면 대화를 압축합니다.
예:
지금까지의 결정 사항만 10줄 이내로 요약해 주세요.
미결된 논점도 구분해 주세요.
그리고 새로운 세션에 요약본만 가져옵니다.
이는 인간의 작업에서도 마찬가지입니다.
긴 회의록을 전부 읽는 것보다, 결정 사항과 다음 할 일 (TODO)만 보는 것이 더 빠릅니다.
AI 코딩 툴 (AI coding tool)을 사용하는 경우, 프로젝트 고유의 지시 사항을 매번 채팅창에 직접 입력하는 것보다 고정 파일에 정리해 두는 것이 다루기 쉽습니다.
예를 들어, GitHub Copilot에서는 .github/copilot-instructions.md와 같은 커스텀 지시 파일 (custom instruction file)을 사용할 수 있습니다.
작성 내용의 예:
# Project instructions
- TypeScript를 사용한다
- 패키지 매니저 (package manager)는 pnpm을 사용한다
...
포인트는 매번 바뀌지 않는 규칙만을 작성하는 것입니다.
다음과 같은 내용은 포함하지 않는 것이 좋습니다.
- 오늘의 날짜
- 이번에만 해당하는 태스크 (task)
- 일시적인 로그 (log)
- 미확정된 가설
- 매번 바뀌는 파일 목록
정적인 지시는 정적인 장소에 두고, 동적인 요청은 채팅으로 전달한다.
이것이 캐싱 (caching)하기 쉬운 구조입니다.
토큰 절감은 감으로만 하면 빗나갑니다.
가장 먼저 확인해야 할 것은 실제 이용량입니다.
LLM API나 AI 게이트웨이 (AI gateway)를 사용하고 있는 경우, 다음과 같은 항목을 확인할 수 있는 상태로 만들어 두면 개선하기 쉽습니다.
- 요청 수 (request count)
- 모델별 이용량
- 입력 토큰 (input token)
- 출력 토큰 (output token)
- 성공 / 실패
- 레이턴시 (latency)
- 이용 이력
- 모델 요금
예를 들어, 비용 증가의 원인이 다음 중 무엇인지에 따라 대책이 달라집니다.
| 원인 | 대책 |
|---|---|
| 입력이 길다 | 요약, 전처리, 캐싱 |
| ... |
로그가 없으면 어디를 줄여야 할지 알 수 없습니다.
Flatkey는 OpenAI / Anthropic 호환 API로 사용할 수 있는 AI 토큰 게이트웨이입니다.
이미 공개된 기사나 관리 화면 설명에서 언급된 범위 내에서는 다음과 같은 항목을 확인할 수 있습니다.
- API 키 생성
- 크레딧 추가
- 요청 전송
- 잔액
- 이용량
- 요청 수
- 이용 이력
- 모델 요금
따라서 base_url을 전환하며 작게 검증하면서, 어떤 모델과 어떤 요청에서 비용이 증가하고 있는지 확인하는 용도에 적합합니다.
단, Flatkey 자체가 프롬프트 (prompt)를 자동으로 짧게 만들거나, 캐시를 반드시 최적화하거나, 모든 모델에서 동일한 절감률을 보장한다는 의미는 아닙니다.
토큰 절감은 애플리케이션 측의 설계, 모델 선택, 프롬프트 구조, 로그 확인을 조합하여 수행하는 것입니다.
| 상황 | 우선 시도할 것 |
|---|---|
| 매번 동일하게 긴 지시를 보내고 있다 | 프롬프트 캐싱 (prompt caching)을 의식한 구조로 만든다 |
| ... |
토큰 절감은 단순히 "짧은 프롬프트를 쓰는 것"만이 아닙니다.
실제로는 다음과 같은 것들을 조합합니다.
- 정적 컨텍스트 (static context)를 캐싱하기 쉽게 만든다
- 동적 정보를 아래에 배치한다
- 출력 형식을 짧게 지정한다
- 큰 로그나 JSON을 전처리한다
- 태스크에 맞는 모델을 사용한다
- 조사와 구현을 분리한다
- 긴 대화를 요약하여 리셋한다
- 이용량 로그를 확인한다
AI 에이전트 (AI agent)의 이용이 늘어날수록, 토큰은 보이지 않는 곳에서 쌓여갑니다.
우선 자신의 사용 방식에서 "입력", "출력", "모델", "재시도 (retry)" 중 어디가 큰지 확인하는 것부터 시작하는 것이 현실적입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기