Reorder token management strategies by ROI

Author: serithemage

content/posts/vibe-coding-token-management-strategy.md

@@ -28,7 +28,50 @@ Perplexity를 통해 정리한 ideation 메모를 다시 읽어보면 핵심은
 
 이 현상은 단순히 컨텍스트 창 크기로 해결되지 않는다. 긴 컨텍스트는 더 많은 정보를 담을 수 있게 해주지만, 그 안의 정보가 잘 정리되어 있다는 보장은 해주지 않기 때문이다. 그래서 토큰 관리의 핵심은 절약 자체보다 **선별**에 있다.
 
-## 전략 1: 세션을 오래 끌지 말고 `/clear`, `/compact`를 의식적으로 써라
+## 전략 1: `.claudeignore`로 애초에 읽지 말아야 할 것을 차단하라
+
+실측 기준으로 가장 ROI가 높은 단일 조치는 `.claudeignore` 설정이다. ideation 문서에 인용된 사례들에서는 `node_modules`, 빌드 산출물, 로그, 바이너리, 대용량 이미지, lock 파일을 제외하는 것만으로도 **30~40% 수준의 절감 효과**가 보고된다.[^6][^7]
+
+예를 들면 이런 식이다.
+
+```text
+node_modules/
+.next/
+dist/
+build/
+coverage/
+.cache/
+*.log
+*.db
+*.sqlite
+.env*
+*.png
+*.jpg
+*.gif
+*.mp4
+```
+
+이 전략의 본질은 절약이 아니다. 모델이 애초에 봐도 도움이 안 되는 정보를 보지 않게 막는 것이다. 특히 lock 파일이나 빌드 산출물은 토큰을 많이 먹지만 추론 가치가 거의 없다.
+
+## 전략 2: `tasks.md`를 하나로 몰아넣지 말고, 인덱스 구조로 쪼개라
+
+ideation 문서에서 가장 인상적인 사례 중 하나는 단일 대형 `tasks.md`를 도메인별 문서와 `INDEX.md` 구조로 나누어 **76.1% 절감**을 달성한 케이스다.[^8]
+
+```text
+tasks/
+├── INDEX.md
+├── backend.md
+├── frontend.md
+├── infra.md
+├── security.md
+└── archive/
+```
+
+이 구조가 좋은 이유는 간단하다. 모든 작업에서 모든 태스크를 읽을 필요가 없기 때문이다. 일반 현황은 `INDEX.md`만 보면 되고, 특정 작업은 해당 도메인 파일만 읽으면 된다. 완료된 이력은 `archive/`로 치워 두면 현재 세션의 작업대에서 사라진다.
+
+토큰 관리란 결국 문서 정보 아키텍처의 문제이기도 하다.
+
+## 전략 3: 세션을 오래 끌지 말고 `/clear`, `/compact`를 의식적으로 써라
 
 Claude Code를 기준으로 보면 가장 즉효성이 높은 방법은 `/clear`와 `/compact`를 전략적으로 쓰는 것이다.[^1][^2]
 
@@ -38,7 +81,7 @@ Claude Code를 기준으로 보면 가장 즉효성이 높은 방법은 `/clear`
 
 핵심은 긴 대화를 계속 유지하는 것이 생산적이라는 착각에서 벗어나는 것이다. 세션은 길게 이어가는 것보다, **짧게 끊고 재시작할 수 있어야** 한다.
 
-## 전략 2: handoff 문서를 남기고 새 세션으로 넘어가라
+## 전략 4: handoff 문서를 남기고 새 세션으로 넘어가라
 
 세션을 자주 끊으려면 재개 비용이 낮아야 한다. 이때 가장 단순하고 강력한 방식이 `HANDOFF.md` 같은 짧은 인계 문서를 두는 것이다.[^3]
 
@@ -55,7 +98,20 @@ Claude Code를 기준으로 보면 가장 즉효성이 높은 방법은 `/clear`
 
 이 문서의 목적은 장문의 기록 보존이 아니다. 다음 세션이 **즉시 일할 수 있을 정도의 방향성**만 남기는 것이다.
 
-## 전략 3: 반복되는 설명은 `CLAUDE.md`로 빼고, 계층적으로 관리하라
+## 전략 5: Plan mode를 먼저 거치고 구현은 나중에 하라
+
+큰 작업을 곧바로 실행 모드로 던지면, 모델은 탐색과 설계와 구현을 같은 비용 센터 안에서 한꺼번에 처리한다. 이 방식은 시행착오가 많고 토큰도 많이 든다. ideation에서는 Plan mode를 먼저 거쳐 범위를 줄인 뒤 구현으로 들어가는 습관이 **20~30% 절감**에 기여한다고 정리하고 있다.[^7]
+
+이 원칙은 아주 단순하다.
+
+1. 먼저 관련 파일과 영향 범위를 찾는다.
+2. 수정 후보 파일과 접근 방식을 짧게 계획한다.
+3. 계획에서 불필요한 범위를 잘라낸다.
+4. 그 뒤에만 구현한다.
+
+즉, 토큰 절약은 프롬프트를 짧게 쓰는 기술보다 **불필요한 시행착오를 사전에 제거하는 설계 습관**에 더 가깝다.
+
+## 전략 6: 반복되는 설명은 `CLAUDE.md`로 빼고, 계층적으로 관리하라
 
 매 세션마다 프로젝트 구조와 스타일 가이드, 금지 규칙, 테스트 방식까지 다시 설명하는 팀이 많다. 이건 장기적으로 가장 비싼 토큰 낭비다. ideation 문서에서도 `CLAUDE.md`를 전역, 프로젝트, 모듈 단위로 레이어링하는 패턴을 권장하고 있다.[^4]
 
@@ -80,7 +136,7 @@ project/
 
 즉, 좋은 `CLAUDE.md`는 모든 것을 다 담는 문서가 아니라, **무엇을 바로 읽고 무엇은 나중에 읽을지 결정해주는 인덱스**에 가깝다.
 
-## 전략 4: Skills를 적극적으로 써서 문서를 "항상 로드"가 아니라 "필요시 로드"로 바꿔라
+## 전략 7: Skills를 적극적으로 써서 문서를 "항상 로드"가 아니라 "필요시 로드"로 바꿔라
 
 여기서 한 단계 더 나아가면 `CLAUDE.md`만으로는 부족하다. 반복적으로 호출되는 워크플로, 특정 도메인 절차, 리뷰 기준, 배포 체크리스트, 보안 검토 루틴 같은 것은 **skill로 외부화**하는 편이 훨씬 낫다.
 
@@ -122,62 +178,6 @@ Anthropic의 공식 Skills 가이드는 이 점을 꽤 명확하게 설명한다
 - `SKILL.md`는 짧게 유지하고, 상세 문서는 `references/`로 분리한다.
 - 실제로 참조될 문서는 작게 쪼개 두어 on-demand 로딩이 의미 있게 작동하도록 만든다.
 
-## 전략 5: `.claudeignore`로 애초에 읽지 말아야 할 것을 차단하라
-
-실측 기준으로 가장 ROI가 높은 단일 조치는 `.claudeignore` 설정이다. ideation 문서에 인용된 사례들에서는 `node_modules`, 빌드 산출물, 로그, 바이너리, 대용량 이미지, lock 파일을 제외하는 것만으로도 **30~40% 수준의 절감 효과**가 보고된다.[^6][^7]
-
-예를 들면 이런 식이다.
-
-```text
-node_modules/
-.next/
-dist/
-build/
-coverage/
-.cache/
-*.log
-*.db
-*.sqlite
-.env*
-*.png
-*.jpg
-*.gif
-*.mp4
-```
-
-이 전략의 본질은 절약이 아니다. 모델이 애초에 봐도 도움이 안 되는 정보를 보지 않게 막는 것이다. 특히 lock 파일이나 빌드 산출물은 토큰을 많이 먹지만 추론 가치가 거의 없다.
-
-## 전략 6: `tasks.md`를 하나로 몰아넣지 말고, 인덱스 구조로 쪼개라
-
-ideation 문서에서 가장 인상적인 사례 중 하나는 단일 대형 `tasks.md`를 도메인별 문서와 `INDEX.md` 구조로 나누어 **76.1% 절감**을 달성한 케이스다.[^8]
-
-```text
-tasks/
-├── INDEX.md
-├── backend.md
-├── frontend.md
-├── infra.md
-├── security.md
-└── archive/
-```
-
-이 구조가 좋은 이유는 간단하다. 모든 작업에서 모든 태스크를 읽을 필요가 없기 때문이다. 일반 현황은 `INDEX.md`만 보면 되고, 특정 작업은 해당 도메인 파일만 읽으면 된다. 완료된 이력은 `archive/`로 치워 두면 현재 세션의 작업대에서 사라진다.
-
-토큰 관리란 결국 문서 정보 아키텍처의 문제이기도 하다.
-
-## 전략 7: Plan mode를 먼저 거치고 구현은 나중에 하라
-
-큰 작업을 곧바로 실행 모드로 던지면, 모델은 탐색과 설계와 구현을 같은 비용 센터 안에서 한꺼번에 처리한다. 이 방식은 시행착오가 많고 토큰도 많이 든다. ideation에서는 Plan mode를 먼저 거쳐 범위를 줄인 뒤 구현으로 들어가는 습관이 **20~30% 절감**에 기여한다고 정리하고 있다.[^7]
-
-이 원칙은 아주 단순하다.
-
-1. 먼저 관련 파일과 영향 범위를 찾는다.
-2. 수정 후보 파일과 접근 방식을 짧게 계획한다.
-3. 계획에서 불필요한 범위를 잘라낸다.
-4. 그 뒤에만 구현한다.
-
-즉, 토큰 절약은 프롬프트를 짧게 쓰는 기술보다 **불필요한 시행착오를 사전에 제거하는 설계 습관**에 더 가깝다.
-
 ## 전략 8: 큰 로그와 검색 작업은 서브에이전트나 별도 세션으로 격리하라
 
 웹 검색, 긴 로그 분석, 빌드 출력 검토, 광범위한 코드 탐색은 결과물이 길다. 이런 작업을 메인 세션에서 직접 처리하면 컨텍스트가 빠르게 오염된다. ideation에서도 이런 고노이즈 작업은 서브에이전트에 위임하고, **결과 요약만 메인 컨텍스트로 돌려받는 방식**을 권장한다.[^9]
@@ -228,14 +228,14 @@ ideation은 Claude Code, Codex, Gemini를 각각 다른 특성으로 정리한
 
 ## 현실적인 적용 우선순위
 
-ideation 메모의 제안은 합리적이다. 투자 대비 효과 기준으로 보면 보통 아래 순서가 맞다.
+본문도 대체로 절감 효율 순서로 다시 정리했지만, 실제 착수 순서는 팀의 규모와 투자 여력에 따라 조금 달라질 수 있다. 실무적으로는 보통 아래 세 단계로 보는 편이 이해하기 쉽다.
 
-1. `.claudeignore` 또는 동등한 ignore 파일부터 잡는다.
-2. `tasks.md`와 작업 문서를 인덱스 구조로 쪼갠다.
-3. Plan mode와 handoff 문서를 습관화한다.
-4. `CLAUDE.md`를 슬림하게 재구성하고, 반복 절차는 skill로 승격한다.
-5. skill의 `SKILL.md`는 짧게 유지하고 상세 문서는 잘게 쪼갠 `references/`로 분리한다.
-6. 그 다음에야 검색 기반 컨텍스트 서빙이나 MCP 최적화를 고려한다.
+1. 즉시 적용
+`.claudeignore`, `tasks.md` 분할, `/clear`·`/compact`, handoff 문서
+2. 이번 주 안에 정착
+`Plan mode`, `CLAUDE.md` 슬림화, 반복 절차의 skill 승격
+3. 그 다음 구조 투자
+서브에이전트 격리, 검색 기반 컨텍스트 서빙, MCP 최소화, 도구별 역할 분리
 
 즉, 대부분의 팀은 고급 인프라보다 먼저 **문서 구조와 세션 습관**만 바꿔도 큰 차이를 체감할 수 있다.