context-mode: AI 코딩 에이전트 토큰 비용 98% 절감 도구, 진짜인지 뜯어봤다
"토큰 비용을 98% 줄인다"는 GitHub 레포가 있다. context-mode: 스타 21,000개, Hacker News 1위(570포인트). 컨텍스트 최적화라는 새 카테고리를 연 도구다. 어떤 메커니즘으로 줄이는지, 98%라는 숫자에 어떤 조건이 붙는지, 도입 전에 알아야 할 한계까지 검증했다.
AI 코딩 에이전트를 쓰다 보면 비용의 실체를 알게 된다. 모델이 "생각"하는 데 쓰는 토큰보다, 도구가 반환하는 출력(파일 내용, 로그, API 응답)이 컨텍스트 윈도를 채우는 토큰이 훨씬 크다는 것. 터키의 개발자 Mert Köseoğlu가 2026년 2월 23일 공개한 context-mode는 정확히 이 지점을 공략한다. 공개 6개월여 만에 스타 21,194개, npm 릴리스 100회 이상, 지원 플랫폼 17개. 2월 말 Hacker News에서는 "Claude Code 컨텍스트 소비를 98% 줄이는 MCP 서버"라는 글이 570포인트로 1위에 올랐다.
| 항목 | 내용 |
|---|---|
| 레포 | mksglu/context-mode (TypeScript) |
| 공개 | 2026년 2월 23일 · 스타 21,194개 (2026년 9월 기준) |
| 핵심 주장 | 멀티스텝 코딩 루프에서 토큰 60~98% 절감 |
| 대표 수치 | 315KB 도구 출력 → 5.4KB (98% 감소) |
| 메커니즘 | ① 도구 출력 샌드박싱 ② 세션 메모리(SQLite+BM25) ③ Think in code |
| 지원 | Claude Code, Cursor, Copilot CLI, Gemini CLI 등 17개 (MCP + hooks) |
| 라이선스 | Elastic License 2.0 (소스 공개형, OSI 오픈소스 아님) |
context-mode는 어떤 도구인가?
context-mode는 AI 코딩 에이전트의 컨텍스트 윈도를 최적화하는 MCP 서버 + 훅(hooks) 레이어다. 도구 출력을 컨텍스트에 그대로 넣지 않고 로컬에 저장한 뒤, 요약본만 모델에게 전달하는 방식으로 토큰 비용을 줄인다. npm 전역 설치(npm i -g context-mode) 후 ctx stats로 절감량을 확인할 수 있다.
발상의 전환은 이것이다. 에이전트가 315KB짜리 MCP 응답을 받았을 때, 그 전체가 컨텍스트에 들어갈 필요가 없다. 모델이 실제로 필요로 하는 건 그중 몇 줄이다. context-mode는 원본을 로컬 스토리지에 두고 5.4KB 다이제스트만 컨텍스트에 넣는다. 이것이 "98%"의 출처다. 턴별 토큰 사용량과 달러 비용(cost_usd)도 추적해준다.
토큰을 줄이는 세 가지 메커니즘은 무엇인가?
context-mode의 절감은 세 축으로 이뤄진다. ① 도구 출력 샌드박싱 ② SQLite 기반 세션 메모리 ③ 순차 파일 읽기를 스크립트 실행으로 대체하는 "Think in code"다.
① 도구 출력 샌드박싱: 원본은 밖에, 요약만 안에
도구를 격리된 서브프로세스에서 실행하고, 원본 출력은 로컬에 기록한다. 컨텍스트 윈도에는 짧은 다이제스트만 들어간다. 315KB → 5.4KB가 대표 사례다. 모델이 상세가 필요하면 저장된 원본을 다시 조회하는 구조다.
② 세션 메모리: 컴팩션 후에도 기억이 남는다
모든 편집·git 작업·에러·결정 사항을 SQLite에 기록하고, 컨텍스트가 압축(compaction)될 때 FTS5 인덱스에서 BM25 검색으로 관련 발췌만 다시 불러온다. 제작자는 이 방식으로 유효 세션 시간이 30분에서 3시간으로 늘었다고 주장한다(자체 측정치).
③ Think in code: 47번 읽지 말고 한 번 실행하라
모델이 파일을 순차적으로 47번 읽으면 700KB가 컨텍스트에 쌓인다. context-mode는 그 대신 모델이 추출 스크립트 하나를 작성해 로컬에서 실행하게 하고, 스크립트가 남긴 3.6KB 로그만 컨텍스트로 가져온다. "읽으면서 생각"하는 대신 "코드로 생각"하게 만드는 접근이다.
98%라는 숫자, 그대로 믿어도 되는가?
조건부로만 사실이다. Hacker News 스레드의 검증에 따르면 context-mode는 서드파티 MCP 도구의 응답은 가로채지 못하고, 내장 도구(Bash, Read, WebFetch 등)의 출력에만 작동한다. "최대 98%"는 특정 시나리오의 상한이지 평균 절감률이 아니다.
도입 전에 알아야 할 한계는 네 가지다:
- 적용 범위 제한: 헤드라인의 "MCP 출력 98% 절감"과 달리, 외부 MCP 서버 응답은 최적화 대상이 아니라는 검증이 HN 스레드에서 제기됐다
- 정보 손실 위험: 요약본에서 빠진 디테일이 환각으로 이어질 수 있다. 모델이 추출 스크립트를 첫 시도에 정확히 짜야 한다는 전제도 있다
- 과잉 차단: 200바이트짜리 응답에도 curl/wget을 일괄 차단하거나, git 커밋 153개를 107바이트로 뭉개는 등 절감이 과할 때가 있다
- 품질 벤치마크 부재: 공개된 지표는 토큰 절감량뿐이다. 답변 품질이 유지된다는 독립 검증은 아직 없다
그럼에도 같은 스레드에서 실사용자들이 "실제로 체감되는 절감"을 여럿 보고했다. 과장된 마케팅과 실질적 효용이 공존하는, 전형적인 초기 인기 도구의 프로필이다.
context-mode의 진짜 가치는 98%라는 숫자가 아니라, "도구 출력 전체를 컨텍스트에 넣을 필요가 없다"는 설계 원칙을 대중화한 것이다.
컨텍스트 엔지니어링 관점에서 어떤 의미인가?
context-mode의 인기는 AI 에이전트 운영 비용의 병목이 모델 가격이 아니라 컨텍스트 설계에 있다는 인식이 확산되고 있다는 증거다. 하네스 엔지니어링 프레임워크(Prompt → Context → Harness → Loop)의 두 번째 단계, Context가 독립 도구 카테고리로 성장하고 있다.
실제로 2026년 상반기 GitHub 트렌딩에서 context-mode는 유사 도구들과 함께 "컨텍스트 최적화"라는 신규 카테고리를 형성했다. 흐름을 읽는 방법은 이렇다. AutoHarness가 에이전트의 행동을 통제하는 Harness 레이어를 학술적으로 증명했다면, context-mode는 모델에게 무엇을 보여줄지 결정하는 Context 레이어를 도구화했다. 같은 문제의식이 다른 층위에서 제품화되고 있는 것이다.
도입을 검토하는 팀을 위한 실무 가이드는 세 줄이다. ①내장 도구 출력이 큰 워크플로(로그 분석, 대용량 파일 탐색)에서 먼저 테스트하라 ②절감률만 보지 말고 결과물 품질을 같이 검증하라, 검증 에이전트를 붙이면 품질 저하를 자동 감지할 수 있다 ③Elastic License 2.0은 OSI 오픈소스가 아니므로, 상용 서비스에 임베드할 계획이라면 라이선스 조항을 먼저 확인하라.
context-mode는 "토큰 비용 98% 절감"이라는 헤드라인으로 유명해졌지만, 숫자의 조건을 알고 쓰면 더 유용한 도구다. 내장 도구 출력이 큰 워크플로에서는 실질적 절감이 보고되고 있고, 서드파티 MCP 응답과 품질 검증은 아직 열린 문제다. 더 중요한 건 방향이다. AI 에이전트 비용 최적화의 격전지가 모델 선택에서 컨텍스트 설계로 옮겨가고 있고, JetBrains의 go-modern-guidelines처럼 에이전트의 입력을 다듬는 도구들이 하나의 생태계가 되어가고 있다. 컨텍스트는 이제 프롬프트만큼 중요한 설계 대상이다.
참고: mksglu/context-mode, GitHub · MCP server that reduces Claude Code context consumption by 98% — Hacker News (570pts) (2026.02)
이 주제의 전체 그림: Claude Code 기업 활용 가이드
AI 코딩 에이전트, 비용까지 설계하고 계신가요?
컨텍스트 설계부터 결과물 검증 체계까지: 개발팀의 AI 도구 활용 수준을 끌어올리는 실전 교육을 설계합니다.
AI 개발 교육 상담하기