AX LABS
← 블로그 에이전트 제품 설계

긴 창보다 예산이 먼저다

토큰은 기억이 아니라 운영 예산이다

AX LABS 5분 읽기

현장에서 에이전트가 느려지고 비싸지는 순간은 대개 모델이 약해서가 아니다. 회의록, 정책 문서, 고객 이력, 코드, 툴 결과를 한 번에 밀어 넣고 “모델이 알아서 판단하겠지”라고 둔 순간부터 문제가 시작된다. 컨텍스트 윈도우는 넓어졌지만, 토큰은 여전히 비용이고 지연이고 리스크다.

OpenAI API 문서는 GPT-4.1의 1M 토큰 컨텍스트를 제공하고, Anthropic은 Claude Sonnet 4의 1M 컨텍스트를 API에서 지원한다고 밝혔다. Google의 Gemini 2.5 Pro 모델 카드도 1M 토큰 컨텍스트를 명시한다. 긴 창은 이미 제품 스펙이 됐다. 그래서 설계 질문이 바뀌었다. “얼마나 넣을 수 있나”가 아니라 “무엇에 토큰을 쓸 것인가”다. (platform.openai.com)

컨텍스트 윈도우는 저장소가 아니다

긴 컨텍스트를 메모리처럼 쓰면 에이전트 품질이 흔들린다. 창 안에 정보가 있다는 사실과, 모델이 필요한 순간에 정확히 그 정보를 써먹는다는 사실은 다르다. 특히 업무 에이전트는 대화 기록보다 현재 업무의 판단 근거가 중요하다.

컨텍스트 예산 관리는 “덜 넣기”가 아니라 “판단에 필요한 정보만 끝까지 살아남게 하기”다.

에이전트 하네스는 네 종류의 토큰을 분리해야 한다.

토큰 영역 넣는 기준 운영 원칙
지시문 역할, 금지, 출력 계약 짧고 고정한다
작업 상태 현재 목표, 결정, 미해결 이슈 매 턴 갱신한다
근거 자료 문서, 정책, 코드, 고객 이력 검색 후 필요한 조각만 넣는다
툴 결과 API 응답, 로그, 실행 결과 원문과 요약을 분리한다

이 구분이 없으면 모든 것이 “참고 자료”가 된다. 그때부터 시스템 프롬프트는 비대해지고, 대화 기록은 쓰레기장이 되고, 툴 결과는 다음 판단을 방해한다.

토큰은 네 곳에만 써야 한다

첫째, 의사결정 규칙에 쓴다. 에이전트가 언제 답하고, 언제 묻고, 언제 사람에게 넘길지 모르면 긴 문서를 읽어도 운영에 못 들어간다.

둘째, 현재 상태에 쓴다. 장기 프로젝트형 에이전트는 과거 대화 전체보다 “지금까지 확정된 결정”이 중요하다. 원문 로그는 보관하고, 실행 컨텍스트에는 결정 상태만 올린다.

셋째, 검증 가능한 근거에 쓴다. RAG를 붙였다고 끝이 아니다. 검색 결과를 그대로 붙이면 비용만 늘어난다. 문서 ID, 발췌 위치, 적용 조건을 함께 넣어야 한다.

넷째, 실패 복구 정보에 쓴다. 직전 툴 호출의 오류, 재시도 조건, 사용자가 거부한 선택지는 다음 행동을 바꾼다. 이런 정보는 요약하면 안 되는 경우가 많다.

캐시는 절감 기능이 아니라 설계 신호다

OpenAI, Anthropic, Google 모두 반복되는 긴 입력을 캐시하는 기능을 제공한다. OpenAI 문서는 반복 프롬프트의 접두부를 캐시해 비용과 지연을 낮추는 구조를 설명하고, Google Gemini API 문서는 명시적 context caching으로 같은 콘텐츠를 재사용하는 방식을 안내한다. Anthropic 가격 문서는 cache write, cache hit 가격을 별도 항목으로 둔다. (platform.openai.com)

캐시가 잘 먹는 구조는 좋은 컨텍스트 구조다. 고정 지시문, 정책 묶음, 제품 매뉴얼처럼 반복되는 덩어리는 앞쪽에 안정적으로 둔다. 매번 바뀌는 사용자 입력, 검색 결과, 툴 응답은 뒤쪽에 둔다. 캐시 히트율을 보면 프롬프트가 운영 자산인지 임시 문서 더미인지 드러난다.

최근 연구도 같은 방향을 가리킨다. 장기 소프트웨어 에이전트를 다룬 2025년 논문은 안정적인 작업 의미, 압축된 장기 기억, 고해상도 단기 상호작용을 분리한 컨텍스트 작업공간을 제안한다. 2026년 prompt caching 평가 논문은 장기 에이전트 작업에서 캐싱 전략 자체가 비용과 응답시간에 영향을 준다는 점을 실험으로 다룬다. (arxiv.org)

예산표 없이 에이전트를 열지 마라

운영에 올릴 에이전트는 프롬프트가 아니라 예산표로 설계한다. 한 요청에서 지시문, 상태, 검색 근거, 툴 결과, 출력 여지를 각각 얼마까지 허용할지 정한다. 초과하면 자르는 순서도 미리 정한다.

AX Ops 관점의 기본 순서는 단순하다.

  1. 업무별 필수 판단 근거를 정의한다.
  2. 컨텍스트 영역을 고정·상태·검색·툴로 분리한다.
  3. 각 영역의 최대 토큰과 삭제 순서를 정한다.
  4. 캐시 히트, 검색 실패, 툴 오류를 운영 로그로 남긴다.

긴 창은 좋은 보험이다. 그러나 보험을 운영 방식으로 삼으면 비용 구조가 무너진다. 토큰을 어디에 쓸지 정하는 팀만 에이전트를 제품이 아니라 업무 시스템으로 만든다. 컨텍스트 예산부터 설계하려면 AX Ops 방법론 →

참고