8. 토큰 경제 — 컨텍스트에 무엇을 들이고 무엇은 막는가

이 글은 시리즈 Alice 활용법의 8편이다. 1편부터 7편까지가 모두 mind를 어디에, 어떻게, 누구와 분담해서 들 것인가의 답이었다면 — 이 글은 그 모든 결정이 의존하는 가장 근본적인 자원에 대한 기록이다. 컨텍스트 윈도우, 즉 토큰.

0. 토큰 경제는 mind에 들이는 것을 의도적으로 줄이는 일이다

협업자의 컨텍스트 윈도우는 유한하다. 그 안에 모든 것을 다 넣을 수는 없다. 그러나 더 중요한 사실 — 무엇을 들이느냐가 결정의 질을 좌우한다. 잡음으로 차 있으면 결정의 신호가 약해지고, 신호로 압축되어 있으면 같은 윈도우에서 훨씬 깊은 결정이 나온다.

토큰 경제는 그래서 단순한 비용 절감이 아니다. mind에 들이는 것을 의도적으로 선별하는 일이다. 자동 로드 vs 필요시 로드, 메모리 vs 메모리 외부, 메인 vs 서브 — 시리즈 전체가 다룬 결정들이 모두 이 한 가지 자원의 분배 문제로 수렴된다.

이 글은 그 분배의 4계층 배치, 토큰 절약이 결정 품질을 어떻게 끌어올리는지, 그리고 누적된 컨텍스트를 정리하는 감사 도구에 대한 기록이다.

1. 4계층 배치 — 토큰이 들어오는 통로

운영자가 수렴한 토큰 배치는 4계층이다.

계층	무엇	언제 들어오는가	토큰 비용
L1 인라인	페르소나·결정 권한·안전성 가드	매 세션 자동	항상 (가장 비쌈)
L2 자동 로드	메모리 인덱스 첫 N줄, 프로젝트 CLAUDE.md	매 세션 / 디렉토리 진입 시	항상 (조건부)
L3 필요시 Read	메모리 본문, 언어별 규칙, 코드 파일	작업이 그 영역 진입 시	그 작업에서만
L4 외부 참조	코드 전체, 빌드 로그, 외부 API 응답	서브에이전트가 받음 / 요약만 메인으로	메인에는 요약만

핵심은 — L1·L2는 자주 봐야 하니 짧게, L3·L4는 깊어도 되니 길게. 같은 정보가 잘못된 계층에 있으면 토큰이 낭비된다.

잘못된 배치	결과
L4가 L1으로 (전체 코드를 페르소나에)	매 세션 거대한 컨텍스트 소비
L1이 L4로 (역할 정의를 외부 파일로)	매 세션 협업자가 페르소나를 모름
L2가 L3으로 (메모리 인덱스를 필요시 Read로)	협업자가 자기 메모리 존재를 모름
L3이 L2로 (모든 메모리 본문을 매 세션 로드)	인덱스 자동 로드 의미 사라짐

2. 토큰 절약 → 결정 품질 — 인과 관계

토큰 절약이 단순히 비용 문제가 아니라 결정 품질의 문제인 이유.

2.1 신호 대 잡음 비율

컨텍스트 윈도우가 100k라 가정. 페르소나 + 메모리 + 무관한 자동 로드로 80k가 차 있으면 — 결정에 쓸 수 있는 신호 자리는 20k다. 같은 윈도우에서 자동 로드를 30k로 줄이면 신호 자리가 70k가 된다. 같은 결정도 훨씬 깊게 풀 수 있다.

결정 품질은 컨텍스트 크기가 아니라 신호 비율에 비례한다.

2.2 주의 분산

협업자도 사람과 같이 — 컨텍스트가 클수록 무엇이 중요한지 판단이 흔들린다. 100k 안에서 핵심 한 줄을 찾는 것보다 30k 안에서 찾는 것이 더 정확하다. 잡음을 줄이는 것은 그 자체로 결정 품질을 올린다.

2.3 첫 단어 응답 속도

토큰이 적으면 응답이 빠르다. 응답이 빠르면 운영자의 흐름이 끊기지 않는다. 끊기지 않은 흐름은 운영자의 mind 부담을 줄인다. 결정의 질은 운영자 쪽에서도 올라간다.

3. 운영 중 절약 패턴

운영자가 실제로 운영 중인 토큰 절약 장치.

3.1 메모리 인덱스 200줄 제한

MEMORY.md 인덱스는 항상 200줄 이내로 유지. 200줄을 넘어가면 자동 로드 범위 밖으로 나가서 의미가 사라진다. 200줄 압박이 가지치기 동기가 됨.

3.2 디렉토리 전체 Read 금지

큰 디렉토리를 한 번에 Read하면 토큰이 폭발한다. ls로 목록만 본 뒤 grep으로 좁히고, 그 후 특정 파일만 Read. 페르소나에 안전성 가드로 박혀 있음.

3.3 500줄 넘는 파일은 헤더·범위 우선

큰 파일을 한 번에 다 Read하지 않는다. 처음 100줄로 구조 파악 후 필요한 범위만 추가 Read. 같은 결정을 1000줄 컨텍스트가 아니라 200줄 컨텍스트에서 내리게 됨.

3.4 서브에이전트로 깊은 작업 위탁

검색·검토·빌드·테스트는 서브가 깊게 수행하고, 메인에는 요약만. 메인 컨텍스트가 결정 모드로 유지된다. (6편 참조)

3.5 메모리 가지치기 주기

월 1회 project 메모리, 분기 1회 feedback 메모리, 반기 1회 reference 메모리 가지치기. stale 컨텍스트가 의미 없는 자리를 차지하지 않게.

3.6 토큰 감사 도구

운영자가 주기적으로 호출하는 /token-audit 같은 도구가 있다. 메모리 어떤 항목이 60일 이상 참조되지 않았는지, 어떤 메모리가 비대해졌는지, 어떤 자동 로드가 실제 사용되지 않는지를 보고. 가지치기 결정의 근거.

4. 비싼 컨텍스트 위치 — 어디를 제일 먼저 가지치는가

토큰 비용은 위치마다 다르다. 같은 100줄이 어디에 있느냐에 따라 비용이 10배 차이가 난다.

위치	한 줄당 비용 (상대)	우선 가지치기 대상
페르소나 (L1)	× 매 세션 × 모든 응답	★★★ 최우선
메모리 인덱스 (L2)	× 매 세션	★★
프로젝트 CLAUDE.md (L2)	× 그 프로젝트 매 세션	★★
메모리 본문 (L3)	× 그 메모리가 Read될 때만	★
코드 파일 (L4)	× 그 파일이 Read될 때만	(가지치기 아닌 분할)

페르소나가 가장 비싸다. 같은 100줄이라도 페르소나에 있으면 매 세션 × 모든 응답마다 소비된다. 그래서 페르소나는 가장 적게, 가장 자주 가지치는다.

5. 함정 — 토큰 경제가 잘못되는 패턴

5.1 "혹시 필요할까봐" 인라인

운영자가 가끔 쓸 수도 있다는 이유로 페르소나에 가드 한 줄, 정책 한 줄, 예시 한 줄을 계속 추가. 1년 뒤 페르소나가 1000줄. → "두 번 이상 실제로 트리거된 것만 페르소나로 승급" 기준을 지킬 것.

5.2 메모리 본문을 인덱스에 복사

인덱스에 메모리 본문 일부를 "요약"이라며 복사. 인덱스 자체가 비대해진다. → 인덱스는 항상 1줄 hook만. 본문은 그 파일에서.

5.3 토큰 사용량 점검 안 함

매일 쓰면서도 어디서 얼마나 소비되는지 모름. → 정기적인 토큰 감사. 어떤 자동 로드가 큰가, 어떤 메모리가 안 쓰이는가.

5.4 서브 결과를 통째로 메인 흡수

서브가 1000줄 결과를 냈는데 메인이 그걸 다 받아 흡수. 서브를 쓴 의미가 사라짐. → 서브 결과는 항상 요약(메인 흡수용) + 전체(파일 또는 다음 서브 호출용)로 분리.

5.5 컨텍스트 끝까지 가서 잘림

토큰이 컨텍스트 윈도우 끝에 닿으면 — 자동 압축이 일어나거나 가장 오래된 컨텍스트가 잘린다. 잘린 위치가 운영자가 의식하지 못한 자리일 수 있음. → 컨텍스트 사용량을 항상 의식, 80% 도달 시 정리 작업.

6. 누적된 토큰 경제 — 어떤 일이 일어나는가

운영자가 토큰 경제를 의식하기 시작한 후로 일어난 변화.

항목	전	후
매 세션 시작 컨텍스트	평탄하게 60-70k	인덱스 + 페르소나만 = 15-20k
깊은 작업 가능 토큰	30-40k	80-85k
컨텍스트 압축 발생 빈도	자주	거의 없음
같은 작업 결정 품질	보통	깊음 (잡음 적음)
응답 속도	보통	빠름

핵심은 마지막 두 항목 — 같은 작업이 더 깊은 결정으로 풀리고, 더 빠르게 풀린다. 토큰 절약이 직접 결정 품질로 환산된다.

7. 한 원칙으로 압축

토큰 경제 설계의 핵심은 한 문장으로 줄어든다.

"매 세션 봐야 할 것만 인라인, 자주 봐야 할 것은 자동 로드, 가끔 봐야 할 것은 필요시 Read, 거의 안 봐야 할 것은 외부. 잘못된 계층에 있는 것이 가장 비싸다."

이 원칙이 지켜지면 토큰 경제는 결정 품질의 가속기가 된다. 지켜지지 않으면 — 잡음이 결정 자리를 잡아먹고, 협업자가 무엇이 중요한지 헷갈리기 시작한다.

다음 글은 시리즈의 마지막이다. 이 모든 — 페르소나·메모리·스킬·훅·멀티에이전트·검증·토큰 — 이 매일 어떻게 시작되고 끝나는지의 절차, 세션 프로토콜에 대해 다룬다.