내 토큰을 누가 먹고 있나 — Claude Code /context로 컨텍스트 해부하기
2026.04.30
컨텍스트는 안 보이는 지갑이다
Claude Code를 오래 쓰다 보면 어느 순간 응답이 느려지고, 갑자기 "대화를 압축했습니다" 메시지가 뜬다. 컨텍스트 창이 꽉 찼다는 신호다. 문제는 뭐가 그 창을 채웠는지 안 보인다는 것이다. 지갑은 비어가는데 어디에 썼는지 모르는 상태와 같다.
1M 컨텍스트의 함정 글에서 길게 넣는다고 똑똑해지지 않는다고 썼다. 그럼 지금 내 컨텍스트에 뭐가 들어 있는지부터 봐야 한다. 그걸 보여주는 게 /context 명령어다. 이번 글부터 토큰을 아끼고 관리하는 실전 방법을 시리즈로 다루는데, 첫 단추는 "측정"이다. 안 보이면 못 줄인다.
/context가 보여주는 것
세션에서 /context를 치면 현재 컨텍스트 창이 컬러 그리드로 그려진다. 색깔 블록 하나하나가 컨텍스트의 한 조각이고, 카테고리별로 토큰 수와 퍼센트가 붙는다. 한눈에 "아, 지금 이게 절반을 먹고 있구나"가 보인다.
카테고리는 대략 이렇게 나뉜다.
/context all을 치면 항목별로 더 잘게 쪼개서 뭐가 공간을 먹는지까지 보여준다. 그리고 대개 최적화 제안이 같이 뜬다. "안 쓰는 MCP 도구는 tool-search로 미뤄라", "큰 출력은 정리해라" 같은 것들이다.
범인은 보통 셋 중 하나다
내 경험상 컨텍스트를 잡아먹는 범인은 거의 정해져 있다.
1. MCP 도구 정의
이게 가장 흔한 범인이다. MCP 서버를 여러 개 연결해두면, 각 서버의 모든 도구 정의가 컨텍스트에 상주한다. 한 번도 안 쓴 서버의 도구까지 자리를 차지한다. /context를 보면 MCP 블록이 통째로 큰 경우가 많다.
대응은 두 가지다. 안 쓰는 MCP 서버는 그 프로젝트에서 아예 연결을 끊는다. 자주 안 쓰지만 가끔 필요한 서버는 도구를 미리 로드하지 않고 필요할 때 검색해서 부르는 방식으로 돌린다. 이른바 tool-search 지연 로딩이다. 이것만 정리해도 컨텍스트가 눈에 띄게 넉넉해진다.
2. CLAUDE.md와 메모리
CLAUDE.md는 매 세션 컨텍스트에 들어온다. 편하다고 이것저것 다 적으면 그만큼 매번 토큰을 낸다. CLAUDE.md 안티패턴 글에서 다뤘듯, 일반론과 디렉토리 구조 설명 같은 건 빼고 이 프로젝트만의 규칙만 남긴다. /context로 메모리 블록이 예상보다 크면 다이어트 신호다.
3. 쌓인 메시지와 큰 툴 출력
세션이 길어지면 대화 자체가 무거워진다. 특히 한 번 읽은 거대한 파일이나 긴 로그 출력이 대화에 그대로 남아 계속 토큰을 낸다. 다시 참조하지도 않을 출력인데 말이다.
여기 대응이 두 갈래다. 대화를 정리하는 /compact와 /clear(다음 글에서 다룬다), 그리고 애초에 큰 탐색을 서브에이전트에 맡겨서 메인 대화에 안 들어오게 하는 방법(시리즈 마지막 글)이다.
언제 /context를 보나
나는 이걸 세 시점에 습관적으로 친다.
특히 새 프로젝트를 열자마자 한 번 보는 게 좋다. 아직 대화를 시작하지도 않았는데 컨텍스트의 30~40%가 이미 차 있다면, 그건 MCP나 CLAUDE.md가 무겁다는 뜻이다. 대화를 시작하기도 전에 빚을 지고 출발하는 셈이다. 이건 프롬프트 캐싱 글에서 말한 캐시 효율과도 연결된다. 고정 영역이 잘 정리돼 있어야 캐시도 잘 먹는다.
직접 겪은 일: 결국 상태 표시줄로 옮겼다
컨텍스트를 분해해서 보는 법을 적었는데, 지금 내가 실제로 하는 건 조금 다르다. 사용률을 상태 표시줄에 상시로 띄운다.
계기가 있었다. 명령어로 확인하는 방식은 이상하다고 느낀 다음에야 치게 된다. 그런데 컨텍스트는 이상하다고 느끼기 전에 이미 차 있다. 답이 흐려지거나 갑자기 압축이 걸리고 나서 확인하면 늦다.
그래서 상태 표시줄 스크립트에 사용률을 읽는 줄을 넣었다. 그 뒤로 명령어를 치는 횟수가 확 줄었다. 대신 숫자가 올라가는 걸 보면서 미리 정리하는 쪽으로 습관이 바뀌었다.
명령어가 필요 없어진 건 아니다. 상태 표시줄은 얼마나 찼는지만 알려주고, 무엇이 채웠는지는 안 알려준다. 이상하게 빨리 차는 날에는 여전히 분해해서 봐야 한다.
정리하면 이렇다. 상시 표시는 «언제 볼지»를 해결하고, 명령어는 «무엇이 범인인지»를 해결한다. 둘 중 하나만 있으면 반쪽이다.
정리
토큰 관리의 출발점은 절약 기술이 아니라 측정이다. 뭐가 얼마나 먹는지 모르면, 줄이는 것도 감으로 하게 된다. /context는 그 감을 데이터로 바꿔준다.
세 줄로 요약하면 이렇다.
/context— 컨텍스트 창을 카테고리별로 분해해서 본다- 범인은 셋 — MCP 도구, CLAUDE.md, 쌓인 메시지·큰 출력
- 측정 먼저 — 안 보이면 못 줄인다
다음 글에서는 이미 쌓인 메시지를 다루는 두 도구, /compact와 /clear를 언제 어떻게 쓰는지 정리한다. /context로 범인을 찾았다면, 그 다음은 치우는 법이다.
같이 읽으면 좋은 글
컨텍스트를 비우는 두 도구 — /compact와 /clear는 언제 다르게 쓰나
/context로 범인을 찾았다면 다음은 치우는 법이다. 대화를 요약해 이어가는 /compact와 아예 비우고 새로 시작하는 /clear를, 언제 어느 쪽을 써야 하는지 기준과 함께 정리한다.
Claude Code토큰관리생산성2026.05.01AI에게 '일단 만들어줘'라고 하지 마라 — brainstorming 스킬
코드부터 시키면 잘못된 걸 빠르게 만든다. 승인 전 구현을 막는 brainstorming 스킬을 HARD-GATE, 한 번에 한 질문, 2-3 접근법 제시까지 실전 사용법으로 정리한다.
AI설계Claude Code2026.04.29AI에게 '일단 고쳐봐'라고 하지 마라 — systematic-debugging 스킬
버그를 만나면 AI에게 던지고 랜덤하게 고치던 습관을 systematic-debugging 스킬 하나가 바꿨다. Iron Law, 4단계 방법론, 3번 실패하면 아키텍처를 의심하라는 규칙까지 실전 사용법으로 정리한다.
AI디버깅Claude Code2026.04.28