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

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

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

내가 생각하는 토큰 경제는 — 비용 절감이 아니라, 컨텍스트 안의 신호 비율을 높이는 구조 설계다. 협업자의 컨텍스트 윈도우는 유한하다. 그 안에 모든 것을 다 넣을 수는 없다. 그러나 더 중요한 사실 — 무엇을 들이느냐가 결정의 질을 좌우한다. 잡음으로 차 있으면 결정의 신호가 약해지고, 신호로 압축되어 있으면 같은 윈도우에서 훨씬 깊은 결정이 나온다.

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

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

Loading diagram…

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 부담을 줄인다. 결정의 질은 운영자 쪽에서도 올라간다.

2.4 주(week) 단위로 누적되는 효과

한 세션의 토큰 절약은 작다. 그러나 절약은 누적된다. 한 주의 작업 — 50번의 세션, 수십 번의 긴 논의 — 동안 세션 시작 오버헤드가 65k에서 20k로 줄어든 차이는 분 단위가 아니라 시간 단위의 결정 시간으로 돌아온다. 이 효과는 우연히 알아챘다. 컨텍스트 관리가 습관이 된 순간, 오후만 되면 "공간이 빠듯하다"고 느끼던 같은 프로젝트가 더 이상 빠듯하게 느껴지지 않았다. 작업이 작아진 게 아니라 작업을 담을 자리가 커진 것이다.

반대도 성립한다. 토큰 경제를 한 주 방치하면 점심 무렵부터 협업자가 자동 압축에 부딪히고, 운영자가 의지하던 컨텍스트가 잘려나간다. 잘리면 질문은 조용히 사라진다 — 운영자는 어느 조각이 잘렸는지 알지 못한 채 그 자리만 흔적 없이 끝난다.

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 서브에이전트로 깊은 작업 위탁

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

3.5 메모리 가지치기 주기

월 1회 project 메모리, 분기 1회 feedback 메모리, 반기 1회 reference 메모리 가지치기. stale 컨텍스트가 의미 없는 자리를 차지하지 않게. 이 주기가 작동하는 메모리 구조 자체는 Part 3 — Memory 시스템에서 다룬다.

3.6 토큰 감사 도구

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

3.7 감사가 실제로 드러내는 것

1년 누적된 메모리에 /token-audit을 처음 돌리면 특정 패턴이 드러난다 — 한 주의 집중적인 작업 중에 그 시점의 디테일로 기록되었지만 사실은 일회성 프로젝트 상태였던 항목들. 세 달이 지나면 그 디테일은 매 세션마다 죽은 무게다.

두 번째 패턴은 겹치는 메모리 — 같은 관찰을 약간 다른 제목 아래에 세 번 적어 놓은 것. 개별로 보면 어느 것도 가지치기 대상이 아닌 듯하다. 셋이 나란히 놓여야 비로소 잡힌다. 그래서 정기적인 감사는 선택이 아니라 — 단일 세션의 눈이 보지 못하는 것을 유일하게 볼 수 있는 장치다.

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% 도달 시 정리 작업.

5.6 보이지 않는 토큰 — 프리픽스 비용

운영자가 보이는 컨텍스트에서 추적할 수 있는 것 너머에 — 모든 모델 호출마다 숨겨진 프리픽스가 따라간다. 페르소나, 도구 스키마, 하네스가 주입하는 시스템 지시문. 이 토큰들은 보이는 transcript에는 나타나지 않지만 매 호출마다 청구된다. 40k의 보이는 컨텍스트가 운영자가 통제하지 못하는 또 다른 15k 위에 올라가 있을 수 있다.

이것은 가장 음험한 형태의 부풀림이다 — 운영자 쪽에서 가지치기할 수 없기 때문. 방어는 구조적이다 — 페르소나를 작게 유지(프리픽스에 들어가 있으므로), 도구 표면을 최소로, 그리고 하네스 자체의 내부 정리에 맡길 것. 운영자의 1계층은 하네스가 위에 얹는 것과 공유 자원이다.

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

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

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

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

보이지 않던 시프트를 구체적으로 만드는 단일 워크플로 사례가 있다. 예전엔 세 세션으로 쪼개야 했던 다국어 리팩토링 — 작업이 끝나기 전에 컨텍스트가 차서 — 가 이제는 한 세션 안에서 끝부터 끝까지 이어진다. 작업이 짧아진 게 아니다. 작업을 담을 자리가 커졌고, 세션 사이 전환 비용(메모리 다시 로드하기, 의도 다시 정립하기)이 사라졌다.

7. 한 원칙으로 압축

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

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

이 원칙이 지켜지면 토큰 경제는 결정 품질의 가속기가 된다. 지켜지지 않으면 — 잡음이 결정 자리를 잡아먹고, 협업자가 무엇이 중요한지 헷갈리기 시작한다. 컨텍스트는 비용이 아니라 결정의 공간이기 때문이다.

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