Claude Code 컨텍스트 절감, Context Mode 하나로 171세션 돌려본 결과
Claude Code나 Cursor 같은 AI 코딩 에이전트 오래 쓰다 보면 토큰 비용이 생각보다 빠르게 쌓입니다. 특히 Playwright로 페이지 캡쳐하거나, find 같은 명령으로 파일 목록 받거나, GitHub API 호출하면 raw 출력이 그대로 컨텍스트에 들어가서 한 번에 수만 토큰씩 먹어버립니다.
이걸 잡아주는 도구 중에 Context Mode라는 게 있습니다. 저는 이걸 깔고 171세션 정도 써봤는데, 누적 통계가 꽤 흥미로웠습니다. 후기 공유합니다.
Context Mode가 정확히 뭐하는 도구인가?
한 줄 요약: MCP tool이 반환하는 대량 출력을 SQLite에 격리시키고, 요약만 LLM 컨텍스트에 올려주는 도구입니다.
Claude Code 플러그인으로 깔리고, 다른 에이전트에도 어댑터 형태로 설치 가능합니다.
예를 들어 find . -type f 같은 명령을 돌리면 보통은 수천 줄짜리 raw 출력이 그대로 LLM 컨텍스트에 박힙니다. Context Mode가 깔린 상태에서는 그 출력이 DB로 빠지고, conversation에는 "N개 파일" 같은 요약만 들어갑니다. 원본은 필요할 때 LLM이 다시 꺼낼 수 있게 sandbox에 남아 있습니다.
설치는 GitHub README 기준 2분 미만이고, Claude Code에 한 줄로 끝납니다.
깃허브
GitHub - mksglu/context-mode: Context window optimization for AI coding agents. Sandboxes tool output, 98% reduction. 15 platfor
Context window optimization for AI coding agents. Sandboxes tool output, 98% reduction. 15 platforms - mksglu/context-mode
github.com
171세션 누적 통계
터미널에서 ctx_stats 한 줄 쳐서 나온 실제 데이터입니다.
- 171세션 누적
- 6,900건의 tool output 처리
- 누적 절감액 $26.61
- 설치 시간 2분 미만
이 $26.61이 정확히 뭘 의미하는지 짚고 가겠습니다. Context Mode가 sandbox로 우회시킨 tool output을 만약 그대로 컨텍스트에 박았다면 추가로 들었을 비용의 추정치입니다. 다시 말해 "안 들어간 토큰의 가격 환산값"입니다.
그래서 다음 두 가지는 이 수치만으로 보장되지 않습니다.
- 우회된 정보가 없어도 작업 품질이 동일하게 유지됐는지
- LLM이 정보를 다시 요청하느라 추가 호출이 발생하지 않았는지
저는 171세션 쓰면서 체감상 품질 저하는 느끼지 못했습니다. 하지만 이건 어디까지나 주관적인 후기이고, "절감액 = 순이익"이라는 보장은 도구가 해주지 못합니다. 그래도 raw 출력 통째로 컨텍스트에 박는 것보다 효율적이라는 점은 명확합니다.
세션 단위로 환산해봤습니다
위 lifetime 값들을 Node.js에서 그냥 산수만 돌렸습니다.
- 세션 평균 $0.156 절감
- 이벤트 평균 $0.0039 절감
- 세션 평균 이벤트 수 40개
세션당 $0.156이면 작아 보이지만, 171세션 쌓이니까 $26.61이 됩니다. 토큰으로는 Claude Sonnet 4 input $3/Mtok 기준 약 887만 토큰이 컨텍스트 진입에서 차단된 셈입니다.
작업이 무거워질수록 (Playwright 자동화, 대규모 grep, find, GitHub API 등) 이벤트당 절감이 커지는 구조입니다.
실측 - find 한 번에 얼마나 차이 나는가
체감만 말하면 신빙성이 떨어지니까 직접 돌려봤습니다. 제 로컬의 /home/shell/projects에서 find . -maxdepth 5 -type f를 두 방식으로 실행한 결과입니다.
- 일반 Bash로 호출: 15,429개 파일, raw 출력 1,121 KB, 추정 287,050토큰이 컨텍스트에 그대로 진입
- ctx_execute로 호출: 12 바이트, 추정 3토큰만 진입, 실제 데이터는 SQLite sandbox
압축률 95,683 : 1. 토큰 추정은 4 chars per token 룰 기준입니다.
다만 한 가지 짚어야 할 게 있습니다. 이 압축은 "파일 개수만 알면 충분한 작업"일 때 유효합니다. 만약 후속 질문에서 "node_modules 빼고 .ts 파일만 보여줘" 같이 원본 데이터가 필요해지면, LLM이 sandbox에서 꺼내거나 ctx_execute를 한 번 더 호출해야 합니다. 그래도 raw를 통째로 한 번에 컨텍스트에 박는 것보단 압도적으로 효율적이라는 점은 변함이 없습니다.
어떤 사람에게 추천하나요?
잘 맞는 경우
- Playwright, Puppeteer 등 브라우저 자동화 자주 쓰시는 분 (raw HTML/DOM이 토큰 폭탄)
- 대규모 모노레포에서
find,grep,ls -R자주 돌리시는 분 - GitHub MCP, Jira MCP 같이 응답이 큰 MCP 도구 자주 호출하시는 분
- 코딩 에이전트 세션이 자주 컨텍스트 한계 부딪히시는 분
굳이 필요 없는 경우
- 한 세션에 짧은 질문 한두 개만 던지는 워크플로우
- 출력 작은 명령(
git status,ls -1등)만 주로 쓰는 경우 - MCP 도구 거의 안 쓰고 직접 코드 작성에만 LLM 쓰는 경우
저는 첫 번째 그룹이라 도입 효과가 컸지만, 두 번째 그룹이면 도구 자체가 컨텍스트 토큰을 살짝 먹는 비용이 절감보다 클 수도 있습니다.
토큰 절감 도구 고를 때 팁
토큰 절감 도구는 요즘 GitHub에 검색하면 십수 개씩 나옵니다. 다 깔면 좋겠다 싶지만, 같은 레이어를 잡는 도구를 여러 개 쌓아도 절감은 거의 0입니다. 유지보수 부담만 늘고, 도구 자체가 컨텍스트를 먹습니다.
그래서 추천 순서는 이렇습니다.
- 본인 워크플로우에서 토큰이 가장 많이 새는 레이어를 먼저 측정합니다 (셸인지, MCP인지, 파일 읽기인지)
- 그 레이어 하나만 잡는 도구를 선택합니다
- 일정 기간 써본 다음, 작업 품질이나 호출 횟수가 이상해지지 않았는지 체감 확인합니다
- 추가 설치는 그다음입니다
저는 MCP tool output이 압도적으로 컸고, Context Mode 하나로 정리됐습니다.
참고 링크
- Context Mode: https://github.com/mksglu/context-mode