비하인드
AI 에이전트에서의 토큰 절약 팁

ChatGPT Image 2026년 9월 11일 오후 01_54_23.png

회사에서 토큰을 지원해주는 경우는 모르겠지만, 저희 같은 헝그리 스타트업은 토큰의 가성비(혹은 결제액)가 항상 중요한 이슈로 다루어집니다. 고성능 모델이 찰떡같이 알아듣고 좋은 결과를 낸다는 데에는 이견이 없지만, 어떻게 하면 더 값싼 모델로 더 많은 일을 해낼 수 있을까 끊임없이 고민하게 됩니다.

비용의 계산법

우리가 쓰는 AI 에이전트가 쓰는 LLM의 비용은 아래와 같이 책정됩니다.

토큰당 단가(모델) x 토큰 수(입력과 출력) = 비용

앞의 토큰당 단가가 모델별로 다르다는 건 대다수의 사람들이 알고 있습니다. 토큰 수도 대충 글자 수에 비례한다는 것까지는 알고 있을 것입니다.

문제는 이 토큰 수의 계산법인데.. 토큰 수는 오고가는 글자 수에 비례한다고 보시면 쉽습니다. 대충 짧은 질문 짧은 답변하면 되는 건가? 싶지만 그렇게 단순한 문제는 아닙니다. 바로 LLM AI가 일을 하는 구조 때문입니다. 냉정하게 말하면 LLM은 의식도 없고 관계도 없고 나에 대해서 알지도 프로젝트에 대해서 알지도 못합니다. 그저 텍스트를 토큰화하고 모델에 돌려서 결과값을 제공하는 게 전부입니다.

그래서 AI 에이전트들은 매끄럽게 일을 하기 위해서 어떤 환경인지 어떤 프로젝트인지 사용자가 방금 전까지 무슨 말을 했는지를 다 같이 보내줍니다. 매 질문마다 모든 정보를 매번 새롭게 보냅니다. 추가 요청만 보내는 것이 아닙니다. 만약 오늘 날씨부터 시작해서 별별 시답잖은 이야기를 하다가 개발 이야기를 했다가 마케팅 이야기를 했다면, 지금 마케팅 이야기를 하는 와중에도 처음에 했던 날씨 이야기와 심지어 AI가 답변했던 그 내용까지 다시 들어갑니다.

질문과 답변 회차당 들어가는 토큰은 아래처럼 도식화가 가능합니다.

1회 : A질문
2회 : A질문 + A답변 + B질문
3회 : A질문 + A답변 + B질문 + B답변 + C질문
4회 : A질문 + A답변 + B질문 + B답변 + C질문 + C답변 + D질문
....

더 정확히 도식화하면 아래처럼 될 수 있습니다.

1회 : 자체프롬프트 + 전역프롬프트 + 메모리프롬프트 + A질문
2회 : 자체프롬프트 + 전역프롬프트 + 메모리프롬프트 + A질문 + A답변 + B질문
3회 : 자체프롬프트 + 전역프롬프트 + 메모리프롬프트 + A질문 + A답변 + B질문 + B답변 + C질문
4회 : 자체프롬프트 + 전역프롬프트 + 메모리프롬프트 + A질문 + A답변 + B질문 + B답변 + C질문 + C답변 + D질문
....

여기서 말하는, 매 요청마다 함께 실려가는 이전 대화 전체가 바로 컨텍스트입니다.

물론 최근의 AI 에이전트는 자동으로 컨텍스트도 압축하고, 최신의 채팅 내역을 더 중요하게 취급하며, 일정 부분 캐시하여 비용을 감소시키기도 합니다. 다만 컨텍스트 압축(compaction) 자체도 요약이라는 별도의 연산을 쓰는 것이라 공짜는 아닙니다. 이것들은 아래에서 다시 다루도록 하겠습니다. 어쨌든 여러 보완 장치들이 있지만, 기본적으로는 위와 같은 구조로 대화가 이루어진다고 보시면 됩니다.

그래서 가끔 이런 사항을 모르는 분들은 "새 대화"로 시작하면 했던 말 다시 하는 그런 게 좀 싫어서 대화창 하나에서 스크롤바가 터질 때까지 이 업무 저 업무를 이어가기도 합니다. 이렇게 써도 어떻게든 답변은 나오지만, 불필요하게 많은 토큰을 낭비하는 셈입니다.

우리는 이 컨텍스트를 여러 가지 방법으로 최소화 혹은 효율화하고 있습니다. 매번 이 세션(대화창)의 컨텍스트가 얼마지? 하고 확인하면서 진행하는 것이 아니라 기본적인 원칙들만 지키고 습관화되면 좋습니다.

프롬프트 캐시의 극대화

위에서 기본 원리를 설명했지만, 최근의 AI 제공사들은 AI 서버에서 모든 내용을 매번 토큰화하고 계산하지 않습니다. 특정 사용자의 대화가 활성화되면 기존에 계산된 결과에 추가 계산만 덧붙여 더 빠르고 효율적으로 응답을 합니다. 이것을 프롬프트 캐시라고 합니다. 캐시된 프롬프트는 쌩으로 연산하는 것에 비해 대폭 할인된 가격으로 제공됩니다. 어? 그러면 그냥 계속 신경 안 쓰고 써도 되는 거 아닌가?

하지만 여기에 함정이 있습니다. 프롬프트 캐시는 발동 조건이 까다롭습니다. 대화가 5분 이내에 이루어져야 유효하며, 그리고 모델이나 추론 깊이가 변경되지 않아야 하며, 메모리나 전역 지침 프롬프트 변동이 없어야 합니다. 이 중에 하나라도 어긋나면 모든 컨텍스트가 쌩으로 연산되면서 다시 비용이 됩니다.

하지만 반대로 이야기하면 이런 조건을 유지하면 프롬프트 캐시의 혜택을 받을 수 있다는 말이 됩니다. 여러 개의 에이전트로 이 일 저 일을 시킨다면 되도록 빨리 두루 살펴보며 프롬프트 캐싱이 끊기지 않는 시간 안에 다음 작업을 이어가며 작업을 마무리하는 요령도 필요합니다.

이 원리를 위의 '컨텍스트' 이야기와 같이 놓고 보면, 결국 화제가 바뀔 때는 새 세션을 열어 컨텍스트 오염과 캐시 낭비를 막고, 같은 주제를 다루는 동안에는 텀을 두지 않고 몰아붙여 캐싱이 끊기지 않게 하는 것이 핵심입니다.

곁가지 이슈의 분리

작업을 진행하다 보면 내가 해결하고자 하는 이슈만 딱 동떨어져 있지는 않은 경우가 많습니다. 백엔드, 인증, 사용자 데이터, UI, 테스트, 같은 배를 타고 있는 다른 기능 등이 얽혀 있습니다. 모르고 넘어가면 모를까, 요즘의 에이전트들은 작업하다 발견하게 되는 오류 사항들을 같이 알려줍니다. 이때 갑갑한 마음에 혹은 가벼운 오류라 생각해서 빨리 수정하고 다시 집중하고 싶은 유혹이 생길 수도 있습니다.

이럴 때에는 과감하게 곁가지 이슈들을 따로 떼어놓고 다시 원래의 이슈를 계속 파는 것이 중요합니다. 컨텍스트가 불필요한 정보로 오염되는 것을 막아 토큰 낭비를 줄이는 것입니다. 동시에 발견된 이슈를 기록해두어 절대 누락되지 않도록 챙기는 것입니다.

도식화하면 아래와 같은 흐름입니다.

결제 실패 알림 버그 수정 시작
      │
알림 발송 로직 확인
      │
      ├─── 곁가지 발견: 로그인 세션 만료 시간이 이상함 → GitHub Issue #111 등록
      │
원인 파악 계속
      │
      ├─── 곁가지 발견: 관리자 페이지 캐시가 안 지워짐 → GitHub Issue #112 등록
      │
원래하던 업무 계속...

떼어놓는 요령은 여러 가지가 있는데, 간단하게 별도의 md 파일로 생성해두어도 되고, 저희 같은 경우는 깃헙 이슈와 연동하여 정리를 해두고 있습니다. 간단한 정리 스킬을 만들어서 곁가지를 특정 형식으로 정리(당시의 컨텍스트 요약/예상문제 등)해두면 본 문제를 해결하고 난 후 새로운 세션 깨끗해진 컨텍스트에서 해당 이슈를 점검할 수 있습니다.

계층적 문서 관리

이전 포스팅에서도 언급했듯이 매뉴얼이나 전역 지침이나 거의 모든 문서 시스템은 계층적 구조로 유지합니다. 가령 전역 지침에 1000 라인에 해당하는 여러 가지 보안/결제/운영/코딩/테스팅 규칙이 있다고 했을 때 작동 자체는 아주 잘 될 겁니다. 하지만 현 세션에서 알 필요가 없는 온갖 정보들이 포함되어 쓸데없는 토큰 낭비를 유발합니다.

따라서 전역 지침에는 꼭 필요한 필수 사항만 언급하고, 각 영역에서 알아야 하는 정보는 별도 문서에 두고 있습니다. 중요한 것은 파일이 동떨어져서 있으면 모르니, 진입되는 문서(여기에서는 전역 지침)에 어떠어떠한 사항은 이 문서 저 문서를 참고하면 된다고 연결 구조를 만들어두는 것입니다.

예를 들어 다음과 같이 구성할 수 있습니다.

// AGENTS.md
- 결제 흐름은 결제 요청과 웹훅, 내부 상태 동기화로 구성되며 자세한 내용은 `docs/payments.md` 참조
- 로그는 개발 환경과 운영 환경의 저장·조회 방식이 다르며 자세한 내용은 `docs/logging.md` 참조

// docs/payments.md
# 결제 상세
결제 요청 → 외부 결제 승인 → 웹훅 검증 → 내부 구독 상태 반영
- 결제 상태가 변경되는 진입점
- 웹훅 재시도와 중복 처리 규칙
- 환불·취소·실패 상태의 처리 방법
- (중략)...

// docs/logging.md
# 로깅 상세
- 개발 로그: 로컬 파일에서 확인
- 운영 로그: 중앙 로그 시스템에서 서버와 기능별로 조회
- 장애 조사: 사용자 식별자, 작업 ID, 발생 시각을 기준으로 관련 로그를 연결
- (중략)...

AI 에이전트는 스스로 필요한 정보들을 추가 파악하는 툴 콜링이라는 구조를 갖추고 있습니다. 먼저 필수인 전역 지침을 파악해보고, 지금 자신이 하려는 업무가 언급된 추가 문서를 파악해야 하는 경우 에이전트는 해당 문서를 추가적으로 읽어들입니다. 결과적으로 현재의 업무에 필요한 최소한의 문서만 접근하고 작업에 임하게 되므로 토큰의 낭비를 줄일 수 있게 됩니다.

다만 툴 콜링으로 문서를 읽어들이는 것 자체도 턴과 토큰을 쓰고, 한 번 읽은 내용은 그대로 이후 대화 내내 컨텍스트에 남습니다. 그래서 원칙은 "거의 매번 필요한 내용은 진입 문서에 두고, 가끔만 필요한 내용은 바깥 문서로 분리한다"는 빈도 기준입니다. 만약에 그보다 더 빈도가 낮은 문서는 `/docs`에만 유지하고 필요한 상황에서 임의 언급을 통해 끌어들이는 식으로 할 수 있습니다.

메모리 지침의 주기적 정리

AI 에이전트를 사용하다가 사용자가 어떤 명령을 강하게 하거나, 혹은 반복되는 문제가 생기면 에이전트는 메모리 지침을 제안하거나 스스로 추가합니다. 이 말은 곧 추후 모든 대화 내역에 이 메모리 프롬프트가 같이 들어간다는 이야기입니다. 전역 지침은 문서상으로 있기에 수시로 보고 커밋으로 관리할 수 있지만, 메모리 지침은 신경 안 쓰면 계속 쌓여서 토큰 낭비의 주범이 될 수 있습니다.

사용 중에 자연스럽게 쓰이는 것은 그대로 내버려두다가, 전역 지침을 다이어트하는 타이밍에서 자주 쓰는 유용한 메모리는 전역 지침으로 옮겨주고 한때만 사용했던 메모리 지침들은 제거해주는 정비 작업을 주기적으로 해줍니다.

라우터 모델과 고성능 모델 분리

고성능 모델(fable / astra)을 쓰게 되면 확실히 타이핑을 덜 해도 알아서 똑똑하게 알아먹고, 실수도 덜하고 작업을 의도대로 착착 하게 됩니다. 하지만 "고성능=비용"이기 때문에 다른 절약 방침을 생각해보게 됩니다.

실제로 모든 것을 에이전트 기반으로 일을 하게 되면 적어도 절반 가까운 일은 정형화된 파일 읽기/검색/툴 호출, 단순 수정과 로그 확인 정도에 해당됩니다. 그래서 저희는 기본 모델을 중간급 모델(sonnet / terra)로 설정하고, 복잡한 일에 한정해서 고성능 모델로 자동 전환하도록 설정을 해두고 사용 중입니다. 기본 모델이 일종의 라우팅 모델 역할을 하는 셈입니다.

중간급 모델은 일 자체는 해결하지 못해도 이 일이 복잡한 일인지 단순한 일인지 정도는 파악할 수 있습니다. 혹은 단순한 일이라고 생각했지만 하다 보니 복잡한 일이라는 것도 알 정도의 수준은 됩니다. 사실 라우팅만을 위한 모델은 더 가벼운 모델을 써도 되지만, 라우팅만을 위한 것이 아니라 어느 정도 일 처리도 해야 하므로 중간급 모델을 선호하고 있습니다.

에이전트에는 서브에이전트라는 기능이 있습니다. 우리가 새로운 세션을 만들 듯이 에이전트 스스로 자기가 관리하는 새끼 세션을 만들어서 그 안에 일을 시키고 응답을 받을 수 있는 기능입니다. 현재 내가 유지하고 있는 세션의 모델을 에이전트가 전환하는 기능은 없으므로, 지금은 서브 에이전트를 통해서 우회하는 방안으로 사용합니다.

서브에이전트를 쓰면 모델을 바꿔 부르는 것 이상의 부수 효과도 있습니다. 서브에이전트가 파일을 수십 개 뒤지고 여러 번 시행착오를 거쳐도, 그 과정에서 나온 툴 호출 결과들은 서브에이전트 안에만 쌓이고 메인 세션의 컨텍스트로는 결론만 돌아옵니다. 앞서 이야기한 '곁가지 이슈의 분리'와 같은 원리로, 탐색 과정 자체를 메인 컨텍스트 밖으로 떼어놓는 셈입니다.

"작업이 무겁거나 고난이도 혹은 보안과 관련된 중요한 업무라고 판단이 되면 서브에이전트를 고성능 모델로 호출하여 맥락을 전달하고 계획을 위임하라. 서브에이전트의 응답을 대기하고 계획서가 나오면 지침대로 코드 수정을 진행하라" 라는 느낌의 전역 지침을 생성해둡니다. 실제로 사용하다 보면 어느 선을 넘어가면 안 되는지, 어느 선이면 넘겨야 하는지 조금씩 지침을 수정 보완해 가면 프로젝트 수준에 딱 맞는 경계가 생기게 됩니다. 이렇게 되면 내가 매번 이건 무거운지 아닌지 신경 쓸 필요 없이 기본 모델을 고정해두고 역할에 따라 적합한 모델을 사용할 수 있습니다.

무조건 구독 모델 활용

API 요금제는 대부분 종량제를 기반으로 합니다. 반면 구독 모델은 플랜별 정해진 리밋은 있지만, 리밋 자체가 일반적인 종량제 요금보다 훨씬 풍족한 사용량을 제공합니다. 아무래도 티어드 프라이싱은 낙전수입도 있을 것이고 브랜드 충성도를 쌓기 위한 전략도 있기 때문일 거라 판단됩니다.

대화형 작업이 아니라 정형화된 대량 작업(예: 수백 건의 데이터를 일괄 분류·요약)이라면, 구독과는 별개로 API의 배치(Batch) 처리를 쓰면 정가 대비 절반 가격으로 처리되는 경우도 있어 종량제 쪽에서도 비용을 줄일 여지가 있습니다.

CLI들은 1회성 실행 모드가 있는데, 클로드를 제외한 메이저 제공사들은 여기에서 소비되는 토큰을 구독 요금제에 포함시키는 정책을 유지하고 있습니다.

codex exec "이 파일의 버그를 찾아줘"

이는 스킬 등에서 활용 가능성이 대폭 늘어나는 이야기이기도 합니다. 가령 스킬에서 코드 리뷰를 함에 있어서 독립적인 다른 모델을 호출하여 상호 간 토론 및 교차 검증을 시킬 수도 있는 자유도가 주어집니다. 당연히 API로도 구현 가능하지만, 중요한 점은 최대한의 경제성 있는 소비를 위해서 구독 요금제로 소비되는 구도로 유도하는 것입니다.