# 토큰 절약

모듈 크기 제한, 스크립트 자동화, 역할 분담을 통한 실전 토큰 절약 기법을 공유합니다.

원본 URL: https://abc.noco.kr/practice/token-saving

[에이전트](/glossary#agent) 작업에서 [토큰](/glossary#token)은 곧 비용이다. 같은 작업을 더 적은 토큰으로 처리하면, 같은 요금제로 더 많은 일을 할 수 있다. 토큰 절약은 거창한 설정이 아니라 작업 방식에서 나온다.

기준일: 2026-09-30. 아래 기준은 공식 규칙이 아니라 실무에서 써 온 휴리스틱이다.

## 반복 작업의 스크립트화

같은 작업을 매번 에이전트에게 맡기면, 매번 같은 설명을 읽고 같은 판단을 반복하는 데 토큰을 쓴다.

- 반복되는 작업은 셸, Python, Node.js 같은 스크립트로 만들어 둔다.
- 스크립트는 한 번 검토해 두면 이후에는 실행하고 결과만 확인하면 된다. 읽고 판단할 내용이 줄어든다.
- 스크립트 자체가 작업 절차를 기록한 문서가 되므로, 설명을 다시 길게 쓰지 않아도 된다.

특히 빌드, 검증, 배포처럼 매번 반복되는 작업에 효과가 크다. 사람이 매번 판단하던 절차를 코드로 옮겨 두는 셈이다.

## 컨텍스트 읽기 범위 축소

에이전트는 작업할 때 관련 파일을 읽는다. 파일이 크고 얽혀 있을수록 한 번에 읽는 컨텍스트가 커진다. 코드를 역할별로 나누면 읽는 범위가 줄어든다.

- [레이어드 아키텍처](/glossary#layered-architecture)는 화면, 처리, 데이터 접근을 층으로 나눈다. 각 층이 자기 역할만 맡으므로 고칠 위치가 분명해진다.
- [클린 아키텍처](/glossary#clean-architecture)는 의존 방향을 도메인 쪽으로 모은다. 바깥 기술이 바뀌어도 도메인 규칙은 그대로 남는다.
- [도메인 주도 설계](/glossary#ddd)는 업무 규칙을 도메인별 모듈로 나눈다. 관련 파일이 한곳에 모인다.
- 모듈 하나의 길이를 제한한다. 모듈당 128줄, 2000자 정도를 기준으로 삼는다.

```mermaid
flowchart TB
  UI[프레젠테이션] --> APP[애플리케이션]
  APP --> DOM[도메인]
  INFRA[인프라] --> APP
```

경계가 분명하면 에이전트가 저장소 전체를 훑지 않는다. 수정에 필요한 레이어와 도메인 모듈만 읽고 고치므로, 한 번에 읽는 컨텍스트가 줄어든다.


> 삽화: 모듈을 작게 나누면 한 번에 읽는 범위가 줄어든다

128줄, 2000자라는 숫자는 공식 규칙이 아니다. 컨텍스트 범위를 줄이기 위한 휴리스틱이므로 프로젝트 성격에 맞게 조정한다.

## 긴 작업 기록의 압축

긴 작업 기록을 그대로 다음 작업에 넘기면, 그 기록을 다시 읽는 데 토큰을 쓴다. 기록은 계속 쌓이므로 그대로 두면 읽을 양이 계속 늘어난다.

- 긴 작업 기록에서 중요한 결정만 추출한다.
- 추출한 내용을 [ADR](/glossary#adr)이나 문서로 남긴다.
- 이후에는 원래 기록 대신 이 문서를 참고한다.

긴 기록은 정기적으로 압축한다. 결정을 압축해 둔 문서는 짧게 유지되고, 다음 작업에서 읽는 양이 줄어든다.

## Head·Worker 분담

모든 일을 가장 비싼 모델에게 맡기지 않는다. 역할을 나누면 같은 작업을 더 낮은 비용으로 처리할 수 있다.

- 비싼 모델은 Head로 두고 작업 분할, 지시, 검토만 맡긴다.
- 실제 작성과 반복 작업은 더 저렴한 Worker가 맡는다.
- 예를 들어 [Opus](/glossary#opus-5-5)-[Sonnet](/glossary#sonnet-5-5), [Sol](/glossary#sol-6-1)-Luna처럼 상위 모델과 하위 모델을 짝지어 쓴다.

현재 운영에서는 Opus·Sol을 Head로, Sonnet·[Gemini Flash](/glossary#gemini-flash-3-8)·[DeepSeek Flash](/glossary#deepseek-4-1-flash)를 Worker·Reviewer로, [GLM](/glossary#glm-5-3)을 여유가 있을 때 추가 Worker로 둔다. 이 방식은 [herdr](/glossary#herdr)로 에이전트 단위에서 운영한다.

## 무료 스텔스 모델 활용 {#stealth-model}

유료 모델의 사용량을 아끼는 또 다른 방법은 무료 [스텔스 모델](/glossary#stealth-model)을 작업 흐름에 섞는 것이다.

스텔스 모델은 개발사나 실제 모델 이름을 숨긴 채 성능 시험과 평가를 위해 무료 또는 저비용으로 공개되는 임시 모델을 뜻한다. [OpenCode Zen](/glossary#opencode-zen)에서 제공하는 [Space Bunny](/glossary#space-bunny)(MiniMax 계열로 추정되나 공식 확인 전까지는 추정)가 대표적이다.

### 별도 한도와 풀 절약

스텔스 모델의 가장 큰 장점은 [Claude](/glossary#anthropic), [Codex](/glossary#codex), [OpenCode Go](/glossary#opencode-go) 같은 유료 풀과 독립된 별도 사용량 한도를 제공한다는 점이다. 유료 풀 잔량을 보존하는 완충재로 쓸 수 있다.

- **저위험 작업 전담**: 초안 작성, 반복 수정, 파일 목록 정리, 검토 보조처럼 결과가 틀려도 다시 시도하기 쉬운 일에 우선 투입한다.
- **Worker 배치와 검토 루프**: Head·Worker 구조에서 스텔스 모델을 Worker로 두고, 작성 결과는 다른 모델(Sol, DeepSeek 등)이나 사람이 검토하도록 역할을 나눈다.
- **잔량 등급 기반 배정**: 유료 풀이 ‘주의’ 등급으로 떨어지거나 주간 잔량이 빠듯할 때, 스텔스 모델 Worker의 작업 비중을 높여 유료 풀 소진을 늦춘다.

### 사용량 등급별 배정

| 잔량 상태 | 유료 풀 (Head·검토) | 스텔스 모델 (Worker) |
|---|---|---|
| 여유 (정상) | 고난도 설계, 전체 검토 | 선택적 활용, 단순 반복 작업 |
| 주의 (한도 임박) | 방향 제시, 최종 검토만 수행 | 본문 초안 작성, 린트 수정 전담 |
| 소진 (차단) | 잔량 회복 대기 | 허용 범위 내 독립 작업 수행 |

### 도입 시 주의점

무료 스텔스 모델을 실무 작업에 활용할 때는 세 가지 한계를 고려한다.

- **임시성과 변경**: 예고 없이 제공이 중단되거나 다른 모델로 대체될 수 있다. 특정 모델의 고유 동작에 의존하지 않는 표준 룰과 스킬을 사용한다.
- **데이터 정책**: [OpenCode Zen 공식 문서](https://opencode.ai/docs/zen/)에 따르면 Space Bunny Free는 데이터 보관 정책(zero-retention)을 적용해 모델 학습에 데이터를 사용하지 않는다고 밝힌다. 반면 다른 무료·스텔스 모델은 개선 목적으로 입력을 수집할 수 있다. 정책이 확인되지 않은 모델은 '공식 문서에서 확인 필요'로 두고, 개인정보나 회사 기밀 코드는 일절 입력하지 않는다.
- **품질 편차**: 상위 모델보다 맥락 유지와 긴 지시 수행에서 결과가 흔들릴 수 있다. 지시 단위를 좁히고, 완료 조건에 빌드나 테스트 검증을 둔다.

## 최상위 모델의 필요 조건

- [Astra](/glossary#astra), [Fable](/glossary#fable) 같은 최상위 모델은 문서화가 어느 정도 되어 있고 엔지니어링 지식이 있으면 굳이 쓸 필요가 없다.
- 최상위 모델은 비용이 가장 높다. 그래서 아껴 쓰는 편이 낫다.
- 최상위 모델이 정말 필요하다면, 차라리 사람이 방향성과 개요를 학습하는 편이 더 저렴하다.

## 정리

이 방법들은 토큰을 아끼는 것 자체가 목적이 아니다. 같은 비용으로 더 많은 작업을 하고, 아낀 토큰을 더 어려운 문제에 쓰기 위한 방법이다.