한 에이전트 작업의 실제 비용 비교 약 100K 입력 토큰과 5K 출력 토큰, 약 10스텝 기준

원문 작성자는 개인의 잔여 크레딧으로 실측을 진행해 산출물을 공유했으며 댓글에서 세부 요금표와 출처를 보강하는 링크가 추가되었다. 여러 참여자는 입력 중심 비용 구조와 캐싱 전략의 실효성에 공감했고 자신의 사례에서 유사한 패턴이 관찰되었다는 실무적 경험을 덧붙였다. 일부 의견에서는 툴 출력 누적을 줄이는 설계 변경과 캐시 쓰기 수수료를 고려한 비용 모델링의 필요성이 강조되어 토론이 실용적 방향으로 이어졌다.

• 매 스텝 재전송되는 컨텍스트를 줄이는 것이 비용 최적화의 가장 직접적인 수단이다. 시스템 프롬프트와 불변 도구 정의만 캐시에서 읽도록 구성하고 가변 툴 결과는 요약하거나 외부 스토리지로 이동시켜 다음 스텝에 필요한 최소 정보만 포함시키는 설계가 권장된다. 이러한 접근은 캐시 효율을 높이고 불필요한 입력 토큰 전송을 줄여 요금 청구 항목을 낮추는 직접적인 효과를 낳는다.
• 툴 호출 결과가 빈번히 누적되는 워크로드에서는 캐시보다 툴 결과의 구조적 축소가 더 실효적일 수 있다. 예를 들어 툴 결과를 원시 텍스트로 붙이는 대신 핵심 메타데이터만 전송하거나 요약을 생성해 컨텍스트 꼬리를 억제하는 방식이 비용과 응답 속도 측면에서 유리하다. 또한 캐시를 도입할 때는 쓰기 수수료와 읽기 비율을 산정해 실제 절감 효과를 시뮬레이션해야 한다.

Token

— 모델 입력과 출력을 구성하는 최소 단위 문자 단위 또는 서브워드 단위의 단위이며 토큰 수에 따라 과금과 처리 시간이 결정된다. 에이전트 루프에서 매 스텝에 재전송되는 입력 토큰이 누적되면 비용이 급격히 증가한다. 이 글에서는 입력 토큰의 누적이 전체 비용을 좌우하는 핵심 변수로 다뤄졌다.

Context Window

— 한 번의 추론에서 모델이 참조할 수 있는 최대 토큰 범위를 의미하며 길이가 클수록 더 많은 이전 대화와 도구 결과를 포함할 수 있다. 에이전트는 매 스텝에서 누적 컨텍스트를 재전송하므로 컨텍스트 윈도우와 비용이 직접적으로 연결된다. 본문에서는 약 10스텝 루프와 큰 입력 토큰 집합을 전제로 비용 분포를 산정했다.

Context Caching

— 매 스텝 동일하게 유지되는 컨텍스트 부분을 캐시에서 읽어 모델 요청으로 재전송하지 않도록 하는 기법으로 읽기 캐시 비율에 따라 비용 절감 효과가 달라진다. 시스템 프롬프트나 도구 정의와 같이 고정된 접두부를 캐싱하면 입력 토큰 비용을 크게 낮출 수 있다. 본문에서는 캐시 읽기 비율의 최적 사례와 쓰기 수수료가 절감 효과에 미치는 영향을 분리해 논의했다.

Tool Output

— 에이전트가 외부 툴을 호출해 얻는 결과물로, 각 스텝에서 누적되면 컨텍스트의 가변 꼬리 부분을 형성해 캐싱 효과를 감소시킨다. 툴 출력은 매 스텝 전체 가격이 적용되며 캐시에 저장하려면 쓰기 수수료가 추가로 발생한다. 본문에서는 툴 출력의 누적이 캐싱으로 해결되지 않을 때 비용 절감이 제한된다고 판정됐다.