Product

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%"는 특정 시나리오의 상한이지 평균 절감률이 아니다.

도입 전에 알아야 할 한계는 네 가지다:

그럼에도 같은 스레드에서 실사용자들이 "실제로 체감되는 절감"을 여럿 보고했다. 과장된 마케팅과 실질적 효용이 공존하는, 전형적인 초기 인기 도구의 프로필이다.

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 개발 교육 상담하기