작성자 주: Agent의 장기 작업에서 발생하는 Token 비용 구조를 살펴보고, 입력 Token이 대부분을 차지하는 이유와 컨텍스트 구성을 조정해 프리픽스 캐시 재사용률을 높이는 방법을 설명해요.
많은 팀이 다단계 Agent를 제품에 도입한 뒤 월말 청구서를 보고 놀라곤 해요. 사용자는 요청 하나만 했는데, 소비한 Token은 일반 대화의 수십 배에 달하죠. 보통 “모델 출력이 너무 길다”고 생각해 출력 길이부터 줄이지만, 실제로 비용의 대부분은 입력에서 발생해요. 특히 매 라운드마다 다시 전달해야 하는 이전 컨텍스트가 주된 원인이에요.
단순히 경험에 근거한 추측이 아니에요. 최근 공개된 엔지니어링 사례에는 구체적인 수치가 나와 있어요. 중국 내 실제 서비스 환경에서 사용자 요청 한 건당 평균 약 7.2회의 모델 호출이 발생했어요. 50단계로 이어지는 호출에서는 입력 Token이 약 99.4%, 출력 Token은 약 0.6%를 차지했죠. 추론 엔진 팀도 Agent 워크로드를 비슷하게 설명해요. 긴 프리픽스, 짧은 출력, 반복되는 다중 라운드가 특징이라는 거예요.
핵심 내용: 이 글을 읽으면 Agent 장기 작업의 Token 비용 구조와 프리픽스 캐시가 비용을 줄이는 원리를 이해하고, 애플리케이션에서 바로 적용할 수 있는 컨텍스트 구성 방법 5가지를 알아볼 수 있어요.
Agent 장기 작업의 토큰 비용 핵심 요약
먼저 표로 핵심 내용을 살펴보고, 이어지는 섹션에서 하나씩 자세히 설명할게요.
| 핵심 요점 | 설명 | 알아두면 좋은 점 |
|---|---|---|
| 호출 횟수가 늘어나요 | 사용자 요청 한 번에 평균 약 7.2회 모델을 호출하며, 복잡한 작업은 50단계를 넘기는 경우도 흔해요 | 비용은 ‘요청’이 아닌 ‘작업’ 단위로 추정해야 해요 |
| 입력 토큰이 대부분을 차지해요 | 50단계 호출 체인에서 입력은 약 99.4%, 출력은 약 0.6%를 차지해요 | 비용을 줄이려면 입력을 먼저 관리해야 해요. 출력을 줄이는 효과는 제한적이에요 |
| 반복되는 컨텍스트가 주요 원인이에요 | 매 단계에서 이전 컨텍스트를 다시 전달하므로 같은 내용에 반복해서 비용이 발생해요 | 실제 비용이 발생하는 원인을 파악할 수 있어요 |
| 프리픽스 캐시를 재사용할 수 있어요 | 동일한 프리픽스가 캐시에 적중하면 반복적인 prefill 계산을 줄일 수 있어요 | 구조가 안정적인 컨텍스트는 비용이 더 저렴해요 |
| 구조가 캐시 적중률을 결정해요 | 프롬프트와 도구 구조는 고정하고, 변하는 정보는 끝에 배치하며, 필요할 때 이력을 압축해요 | 모델을 바꾸지 않고도 비용을 줄일 수 있어요 |
Agent 장기 작업의 토큰 비용 자세히 알아보기
Agent와 일반 채팅의 가장 큰 차이는 ‘반복’에 있어요. PPT 제작을 예로 들면, 시스템은 자료 읽기, 내용 기획, 슬라이드별 생성, 도구를 이용한 제작, 결과 확인을 차례로 수행해요. 사용자에게는 하나의 작업이지만, 시스템 내부에서는 여러 차례 추론과 도구 호출이 이루어져요. 각 단계에서 컨텍스트를 다시 읽을 수도 있고, 결과가 기대에 미치지 못하면 이전 단계로 돌아가 수정해야 해요.
매번 모델에 전달되는 내용은 ‘시스템 프롬프트 + 도구 정의 + 현재까지의 전체 이력 + 이번 단계의 새 정보’예요. 이력은 계속 길어지지만 한 번에 추가되는 내용은 적어요. 수십 차례 반복하다 보면 같은 프리픽스에 수십 번 비용이 청구돼요. 입력 비중이 99.4%까지 늘어나는 이유예요.
Agent의 장시간 작업에서 입력 Token이 출력보다 훨씬 많은 이유
추론 엔진 관점에서 보면 이 구조가 더 명확해져요. TokenSpeed는 코딩 에이전트를 예로 들었어요. 모델은 계속 사고하고 도구를 호출해 결과를 받은 뒤 다시 사고하는데, 이 과정은 여러 차례의 짧은 요청이 반복되는 방식으로 이뤄져요. 첫 요청부터 수십 K 길이의 프리픽스 컨텍스트가 포함될 수 있지만, 이후 각 반복에서 출력되는 token은 대개 수백 개에 불과해요.
아래 표에서 채팅 워크로드와 Agent 워크로드를 비교해 보세요. 자신의 애플리케이션이 어느 쪽에 해당하는지 판단하는 데 도움이 될 거예요.
| 구분 | 기존 Chat 워크로드 | Agent 장시간 작업 워크로드 |
|---|---|---|
| 요청 형태 | 한 번 묻고 완전한 답변을 생성 | 여러 차례의 짧은 요청을 반복하며 도구 호출 |
| 프리픽스 길이 | 보통 짧음 | 처음부터 수십 K에 달할 수 있으며 매 라운드 증가 |
| 라운드당 출력 | 상대적으로 김 | 대개 수백 개의 token |
| 컨텍스트 재사용 | 한 번 로드한 뒤 해제 | 작업 중 같은 프리픽스를 반복해서 전달 |
| 비용의 주요 요인 | 입력과 출력 모두 비중이 있음 | 입력, 특히 반복되는 프리픽스가 대부분을 차지 |
Agent 장시간 작업에서 프리픽스 캐시가 작동하는 방식
추론 엔진의 요청 처리는 두 단계로 나뉘어요. prefill 단계에서 입력 전체를 계산해 KV Cache를 생성하고, decode 단계에서 출력 token을 하나씩 생성해요. Agent 환경에서는 수십 K에 달하는 프리픽스를 매 라운드 prefill해야 하므로 이 계산이 비용의 주요 원인이에요. 같은 프리픽스를 이미 계산했고 결과가 캐시에 남아 있다면 이를 재사용해 해당 prefill을 생략할 수 있어요.
추론 엔진 팀은 KV Cache 재사용률을 추론 비용을 결정하는 핵심 변수로 봐요. 발표에 따르면 DeepSeek의 캐시 재사용률은 99% 이상이라고 하며, 업계의 많은 시스템은 현재 70~80% 수준이에요. Agent 워크로드의 prefill 단계에서 프리픽스 캐시 적중률은 보통 90% 이상이며, 캐시에 적중하면 수백 개의 token만 추가로 계산하면 돼요.
놓치기 쉬운 세부 사항도 있어요. 프리픽스 캐시는 처음부터 구간별로 일치 여부를 확인해요. TokenSpeed는 초기에 SGLang을 참고해 Radix Tree로 프리픽스 캐시를 관리했어요. 트리의 각 노드는 token 시퀀스의 한 구간에 대응하며, 요청은 루트부터 트리를 따라 일치 여부를 확인해요. 이후 Flat KV 설계로 바뀌었지만, 재사용은 여전히 고정 크기의 논리 블록(128개 token) 단위로 이뤄져요. 애플리케이션 개발자에게 중요한 결론은 간단해요. 앞부분에서 token 하나라도 다르면 그 뒤의 내용은 재사용할 수 없어요.
Agent 장기 작업의 프리픽스 캐시 적중률을 높이는 컨텍스트 구성법
캐시의 매칭 방식을 이해했다면 최적화 방향도 명확해져요. 매 요청의 시작 부분을 최대한 길고 변하지 않게 유지하는 거예요. WorkBuddy 팀은 프롬프트와 도구 구조를 고정하고, 바뀌는 정보는 컨텍스트 끝에 배치한 뒤 컨텍스트가 길어지면 이전 대화를 압축하는 방식을 사용했어요. 이를 실행할 수 있는 5가지 방법으로 정리해 볼게요.
| 방법 | 구체적인 조치 | 흔한 반례 |
|---|---|---|
| 1. 시스템 프롬프트 고정 | 시스템 프롬프트의 문구를 그대로 유지하고, 버전 변경은 한꺼번에 배포 | 시작 부분에 현재 시간, 사용자 이름, 임의의 예시 삽입 |
| 2. 도구 구조 고정 | 도구 목록의 순서와 매개변수 설명 유지 | 매 턴 필요에 따라 도구를 추가·삭제하거나 직렬화 순서가 달라짐 |
| 3. 바뀌는 정보는 끝에 배치 | 타임스탬프, 이번 턴의 관찰 결과, 동적 상태를 맨 뒤에 추가 | 시스템 프롬프트 상단에 ‘현재 진행 상황’ 작성 |
| 4. 이전 대화는 수정하지 않고 추가만 | 이미 보낸 대화는 그대로 유지하고 새 내용만 뒤에 추가 | 매 턴 이전 메시지의 형식을 다시 지정하거나 순서를 바꿈 |
| 5. 이전 대화를 주기적으로 압축 | 컨텍스트가 너무 길어지면 체크포인트에서 한 번 압축하고 이후 계속 추가 | 매 턴 요약을 새로 만들어 프리픽스가 계속 바뀜 |
프롬프트와 도구 구조를 고정하는 Agent 장기 작업 실전 방법
1번과 2번은 놓치기 쉬워요. 많은 프레임워크가 시스템 프롬프트에 현재 날짜를 붙이거나 단계에 따라 도구를 동적으로 선택해요. 두 방식 모두 요청의 시작 부분이 매 턴 달라져 첫 번째 토큰부터 프리픽스 캐시가 무효화돼요. 더 안정적인 방법은 시스템 프롬프트에 규칙과 역할만 넣고, 날짜 등의 정보는 일반 메시지로 끝에 추가하는 거예요. 도구는 전체 목록을 한 번에 제시하고, 목록 자체를 바꾸는 대신 프롬프트로 ‘이 단계에서 사용할 도구’를 제한하면 돼요.
직렬화 방식도 살펴봐야 해요. 같은 도구 정의라도 프로세스마다 JSON 필드 순서가 다르면 바이트 수준에서는 서로 다른 프리픽스가 돼요. 도구 정의를 일정한 순서로 정렬한 뒤 전송하고, 로그에 프리픽스의 해시값을 기록해 두면 ‘변경한 게 없는데 캐시가 적중하지 않는’ 상황을 조사하기 쉬워요.
Agent 장기 작업에서 이전 대화 압축과 캐시 재사용 사이의 균형
5번에는 고려할 점이 있어요. 이전 대화를 압축하면 입력 길이는 줄지만, 압축 후에는 프리픽스가 바뀌므로 해당 턴의 캐시는 반드시 무효화돼요. 매 턴 압축한다면 매번 캐시 재사용을 포기하는 셈이에요. 따라서 컨텍스트가 특정 길이에 도달하거나 하위 작업이 끝났을 때처럼 기준을 정해 한 번씩 압축하는 편이 합리적이에요. 압축한 버전을 새로운 고정 프리픽스로 삼고, 이후에는 수정하지 않고 내용만 계속 추가하세요.
위의 두 구성은 한 번의 요청만 보면 차이가 거의 없지만, 수십 턴에 걸친 장기 작업에서는 비용 차이가 확연해져요. 내 애플리케이션이 어느 쪽에 속하는지 확인하려면 호출 로그에서 매 턴의 입력 Token 변화를 살펴보는 것이 가장 직접적이에요. APIYI apiyi.com은 통합 결제, 사용량 통계, 호출 로그를 제공해 여러 모델의 데이터를 한곳에서 비교할 수 있으므로 이런 비용 구조를 진단하는 데 유용해요.
Agent 장기 작업의 토큰 비용 최적화 빠른 시작
이 섹션에서는 코드 없이 실행할 수 있는 점검 단계만 소개해요. 순서대로 따라 하면 됩니다.
1단계: 토큰 비용을 작업별로 나누기
- 사용자 작업마다 작업 ID를 생성하고, 작업 내 모든 모델 호출을 해당 ID와 함께 로그에 기록해요.
- 각 응답의
usage정보에서 입력 및 출력 토큰 수를 기록해요. 일부 공급자는 캐시 적중 토큰 수도 별도로 반환하므로, 정확한 필드명은 공식 문서에서 확인하세요. - 작업별로 호출 횟수, 입력/출력 비율, 캐시 적중 비율을 집계해요.
여러 공급자의 모델을 함께 사용하면 로그 기준이 제각각인 경우가 많아요. APIYI로 통합 연결하면 하나의 콘솔에서 각 모델의 사용량과 호출 기록을 확인할 수 있어요. 여기에 직접 기록한 작업 ID를 더하면 ‘작업별 비용과 단계별 지출’을 한눈에 파악할 수 있습니다.
2단계: 접두사가 달라지는 지점 찾기
- 같은 작업에서 연속된 두 요청을 추출해 시스템 프롬프트, 도구 정의, 대화 기록이 한 글자까지 동일한지 구간별로 비교해요.
- 타임스탬프, 난수, 사용자 상태 같은 동적 필드가 어디에 있는지 중점적으로 확인해요.
- 여러 요청에서 도구 정의와 메시지의 직렬화 순서가 일정한지 확인해요.
3단계: 5가지 방법에 따라 조정하고 다시 테스트하기
- 동적 콘텐츠를 맨 뒤로 옮기고, 시스템 프롬프트와 도구 목록을 고정해요.
- 대화 기록 압축 임계값을 설정하고, 매번 압축하는 대신 체크포인트에서 압축하도록 변경해요.
- 같은 테스트 작업 묶음으로 변경 전후 버전을 실행하고, 작업당 입력 토큰 수와 캐시 적중 비율을 비교해요.
🚀 시작하기 전 팁: 변경 전후 비교는 반드시 같은 작업과 같은 모델로 진행하세요. 그렇지 않으면 데이터를 비교하기 어려워요. APIYI의 통합 인터페이스를 이용하면 모델을 바꿔 재테스트할 때 인터페이스를 각각 수정할 필요가 없고, 사용량도 한곳에서 집계할 수 있어 ‘구조 최적화’와 ‘모델 차이’를 구분해 살펴보기 편해요.
비용 추정의 한계
WorkBuddy는 자체 작업 규모와 TokenHub 플래그십 등급의 정가를 기준으로 비용을 추정한 바 있어요. 캐시 적중률이 90%에 도달하면 작업당 추정 비용이 약 21.06위안에서 약 3.36위안으로 줄어든다는 결과예요. 다만 이 수치는 특정 컨텍스트 길이와 가격 조건에 해당해요. 전체 조건이 공개되지 않아 다시 계산할 수 없으며, 여러분의 애플리케이션에 그대로 적용할 수도 없어요.
| 영향 요인 | 결과가 달라지는 이유 | 확인할 사항 |
|---|---|---|
| 컨텍스트 길이 | 접두사가 길수록 캐시 재사용으로 절약되는 비용이 커져요 | 실제 작업의 평균 접두사 길이 |
| 캐시 과금 방식 | 캐시 적중 부분에 대한 할인율이 공급자마다 달라요 | 대상 모델의 공식 문서에 명시된 캐시 가격 |
| 캐시 적용 조건 | 최소 길이, 유효 기간 등의 규칙이 제각각이에요 | 공식 문서에 명시된 적용 및 만료 규칙 |
| 호출 간격 | 두 호출 사이의 간격이 너무 길면 캐시가 이미 만료됐을 수 있어요 | 도구 실행 시간이 캐시 유효 기간에 맞는지 여부 |
| 작업 단계 수 | 단계가 많을수록 반복되는 접두사가 더 많이 누적돼요 | 실제 작업의 단계 수 분포 |
Agent 장기 작업의 토큰 비용을 줄이는 추가 전략
컨텍스트 구조를 최적화하는 것 외에도, 같은 자료에서는 프리픽스 캐시와 함께 사용할 수 있는 두 가지 애플리케이션 측 전략을 소개해요.
- 단계별로 모델 선택하기: WorkBuddy 팀에 따르면 간단한 단계의 약 80%를 경량 모델에 맡겨 작업당 비용을 약 57% 줄였어요. 자료 정리나 형식 변환 같은 단계에는 반드시 플래그십 모델이 필요한 것은 아니에요.
- 원인에 따라 장애 처리하기: 타임아웃, 요청 거부, 공급업체 장애가 발생하면 원인에 따라 재시도 횟수를 제한하거나 컨텍스트를 조정하고, 필요하면 모델을 전환해요. 무한 재시도를 하면 같은 긴 프리픽스에 반복해서 비용이 청구돼요.
다만 모델을 전환하면 다른 캐시를 사용하므로 프리픽스 재사용을 처음부터 시작해야 해요. 따라서 라우팅을 설계할 때는 같은 하위 작업의 연속된 단계를 되도록 같은 모델에서 처리하고, 모델 전환은 하위 작업의 경계에서 하는 것이 좋아요.
자주 묻는 질문 FAQ
Q1: Agent 장기 작업에서 프리픽스 캐시란 무엇인가요?
프리픽스 캐시는 추론 서비스가 이미 계산한 입력 프리픽스의 KV Cache를 저장해 두었다가, 이후 요청의 시작 부분이 같으면 재사용하는 방식이에요. 이를 통해 해당 부분의 prefill 계산을 생략할 수 있어요. Agent는 매 라운드마다 긴 대화 기록을 반복해서 전달하므로 특히 효과적이에요.
Q2: 프리픽스 캐시와 이전 컨텍스트 압축은 어떻게 다른가요?
프리픽스 캐시는 입력 내용을 줄이지 않고 반복되는 부분의 계산 비용만 낮춰요. 반면 이전 컨텍스트를 압축하면 입력이 짧아지지만 프리픽스가 바뀌어 해당 라운드의 캐시가 무효화돼요. 평소에는 내용을 추가만 해 캐시 적중을 유지하고, 체크포인트에서 한 번씩 압축하는 식으로 함께 사용하면 좋아요.
Q3: 입력 토큰이 99.4%를 차지한다는 수치는 모든 Agent에 적용되나요?
반드시 그렇지는 않아요. 이 수치는 50단계 호출 체인에 관한 공유 자료에서 나온 것이에요. 단계가 더 적거나 라운드당 출력이 긴 작업은 입력 비중이 더 낮을 수 있어요. 다만 ‘긴 프리픽스, 짧은 출력, 여러 라운드 반복’ 구조라면 대체로 입력이 대부분을 차지해요. 직접 로그를 측정해 확인하는 것이 좋아요.
Q4: 어떤 Agent 시나리오에서 프리픽스 캐시를 우선적으로 최적화해야 하나요?
– **코딩 Agent**: 저장소 컨텍스트가 길고 파일 읽기, 코드 수정, 테스트 실행을 자주 반복해요
– **문서 또는 PPT 생성**: 자료를 읽은 뒤 페이지별로 생성하므로 프리픽스가 많이 반복돼요
– **데이터 분석 Agent**: 테이블 구조와 지표 설명은 고정되고, 매 라운드에 쿼리 결과만 추가돼요
Q5: 내 애플리케이션의 입력/출력 토큰 구성을 빠르게 파악하려면 어떻게 해야 하나요?
가장 간단한 방법은 작업 ID별로 각 라운드의 usage 데이터를 집계하는 거예요. 여러 모델을 사용하는 애플리케이션이라면 APIYI apiyi.com을 통해 통합 호출할 수 있어요. 플랫폼에서 사용량 통계와 호출 로그를 제공하므로 모델별, 기간별 입출력 구성을 확인하기 편해요. 모델별 프롬프트 캐싱 지원 여부와 과금 방식은 플랫폼 문서의 실제 안내를 확인해 주세요.
Q6: 프리픽스 캐시에는 어떤 제한이 있나요?
– 최소 길이와 유효 기간 등 캐시 적용 조건이 공급업체마다 다르므로 공식 문서를 각각 확인해야 해요
– 도구 실행 시간이 너무 길면 다음 라운드가 시작되기 전에 캐시가 만료될 수 있어요
– 모델을 전환하거나 시스템 프롬프트를 수정하면 캐시가 전체적으로 무효화돼요
– 캐시 적중 부분의 할인율은 모델마다 다르므로 절감 폭을 직접 측정해야 해요
Agent 장기 작업의 토큰 비용 핵심 요점 Key Takeaways
- 비용은 작업 단위로 계산해요: 요청 한 번에 약 7.2회 호출하며, 긴 작업은 50단계를 넘길 수 있어요.
- 핵심은 입력이에요: 50단계 체인에서 입력이 약 99.4%를 차지하므로 출력을 줄여도 효과가 제한적이에요.
- 캐시는 처음부터 일치해야 해요: 앞부분에서 토큰 하나만 달라도 뒤의 내용은 재사용할 수 없어요.
- 모델보다 구조가 더 중요해요: 프롬프트와 도구 구조는 고정하고, 변하는 정보는 끝에 배치하세요.
- 압축에도 주기가 필요해요: 체크포인트에서 한 번씩 압축해 매 라운드마다 접두부가 바뀌지 않게 하세요.
- 비용 추정치를 그대로 적용하면 안 돼요: 공개된 비용 수치는 특정 길이와 가격을 기준으로 하므로 직접 다시 측정해야 해요.
- 관찰한 뒤 최적화하세요: APIYI의 사용량 통계와 호출 로그로 비용 구조를 분석하세요.
정리
Agent 장기 작업의 토큰 비용에 관한 핵심 결론은 다음과 같아요.
- 비용 구조: 비용 대부분은 매 라운드마다 반복해서 전달하는 이전 컨텍스트에서 발생하며, 입력 토큰이 절대적인 비중을 차지해요.
- 비용 절감 원리: 접두부 캐시를 사용하면 반복되는 접두부의 prefill 계산을 건너뛸 수 있으며, 적중률은 컨텍스트 구조에 따라 달라져요.
- 적용 방법: 프롬프트와 도구를 고정하고, 변하는 정보는 끝에 배치하세요. 이력은 뒤에만 추가하고, 단계별로 압축하면서 각 단계에 맞는 모델을 선택하세요.
먼저 일주일 동안 로그를 작업별로 나눠 입력 비중과 캐시 적중 현황을 확인한 다음, 이 글의 5가지 방법을 하나씩 적용해 보세요. 여러 모델을 사용하는 경우 APIYI apiyi.com을 통해 통합 연동하고 사용량과 호출 기록을 한곳에서 확인할 수 있어요. 같은 데이터를 기준으로 각 최적화 단계의 실제 효과도 평가할 수 있습니다.
📚 참고 자료
- 에이전틱 추론을 위한 차세대 LLM 추론 엔진 구축: TokenSpeed의 AICon 2026 선전 발표 내용 정리
- 링크:
infoq.cn/article/YwAayF1ylWb7oN4P0lyC -
설명: 에이전트 워크로드의 ‘긴 접두사, 짧은 출력’ 특성과 KV Cache 재사용률, 접두사 캐시의 구조 설계를 소개해요.
-
모델 호출부터 작업 완료까지: MaaS는 에이전트 운영에 어떻게 적용될까: 텐센트 클라우드 MaaS 세션 내용 정리
- 링크:
infoq.cn/article/zZutPTX8bsr6NWQYNC3A - 설명: WorkBuddy가 공유한 호출 횟수, 입력 비중, 접두사 캐시, 모델 라우팅 관련 데이터가 포함되어 있어요.
작성자: APIYI 기술팀
기술 문의: 여러 모델의 호출과 사용량 분석에 관한 질문은 APIYI apiyi.com을 통해 문의해 주세요. 더 자세한 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
