▲

Claude Code의 컨텍스트 소비를 98% 줄이는 MCP 서버

 (mksg.lu)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • Claude Code에서 외부 도구 호출 시 발생하는 대량의 원시 데이터가 컨텍스트 창을 빠르게 소모하는 문제를 해결
  • Context Mode는 Claude Code와 도구 출력 사이에 위치해 데이터를 압축·필터링, 315KB를 5.4KB로 축소(98% 절감)
  • 샌드박스 구조를 통해 각 실행을 격리하고, stdout만 컨텍스트에 포함해 로그·스냅샷 등의 원본 데이터 유출을 차단
  • SQLite FTS5 기반 지식베이스로 마크다운 콘텐츠를 인덱싱하고, BM25 랭킹과 Porter stemming을 적용해 정확한 코드 블록 검색 지원
  • 동일한 200K 토큰 한도에서 세션 지속 시간이 30분에서 3시간으로 늘어나며, AI 에이전트의 효율적 컨텍스트 관리 가능

문제점

  • Claude Code의 MCP 도구 호출은 각 호출마다 원시 데이터를 200K 컨텍스트 창에 직접 덤프함
    • Playwright 스냅샷 56KB, GitHub 이슈 20개 59KB, 액세스 로그 45KB 등
    • 약 30분 사용 시 전체 컨텍스트의 40%가 소모됨
  • MCP는 외부 도구 사용의 표준이 되었지만, 입력 정의와 출력 데이터 모두 컨텍스트를 채우는 구조적 한계 존재
  • 81개 이상의 도구가 활성화된 상태에서 첫 메시지 전 이미 72%(143K 토큰)가 소비됨

Context Mode의 구조

  • Claude Code와 도구 출력 사이에 위치한 MCP 서버로, 원시 데이터를 최소화해 전달
    • 315KB의 출력이 5.4KB로 줄어듦 (98% 감소)
  • 각 execute 호출은 격리된 서브프로세스에서 실행되어 메모리·상태 공유 없이 독립 수행
    • stdout만 컨텍스트에 포함되고, 로그·API 응답·스냅샷 등은 샌드박스 내부에 유지
  • 10개 언어 런타임 지원: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
    • Bun 자동 감지로 JS/TS 실행 속도 3~5배 향상
  • 인증 CLI(gh, aws, gcloud, kubectl, docker)는 환경 변수 상속 방식으로 자격 증명을 안전하게 전달

지식베이스(knowledge base)

  • index 도구가 마크다운을 헤딩 단위로 분할하고 코드 블록을 그대로 유지한 채 SQLite FTS5 가상 테이블에 저장
  • 검색 시 BM25 랭킹 알고리듬을 사용해 단어 빈도, 역문서 빈도, 문서 길이 정규화를 기반으로 관련성 계산
  • Porter stemming 적용으로 “running”, “runs”, “ran”이 동일 어근으로 매칭
  • search 호출 시 요약이 아닌 정확한 코드 블록과 헤딩 계층을 반환
  • fetch_and_index는 URL을 가져와 HTML을 마크다운으로 변환 후 인덱싱, 원본 페이지는 컨텍스트에 포함되지 않음

성능 수치

  • 11개 실제 시나리오(테스트 트리아지, TypeScript 오류 진단, git diff 검토 등)에서 모두 출력 1KB 이하 유지
    • Playwright 스냅샷: 56KB → 299B
    • GitHub 이슈(20개): 59KB → 1.1KB
    • 액세스 로그(500건): 45KB → 155B
    • CSV 분석(500행): 85KB → 222B
    • Git 로그(153커밋): 11.6KB → 107B
    • 리포지토리 조사(subagent): 986KB → 62KB (5회 호출 vs 37회)
  • 전체 세션 기준 315KB → 5.4KB로 축소, 세션 지속 시간 30분 → 3시간
  • 45분 후 남은 컨텍스트: 기존 60% → 99%

설치 및 사용

  • Plugin Marketplace를 통한 자동 라우팅 훅 및 슬래시 명령 지원
  • MCP 전용 설치도 가능
  • Claude Code 재시작 후 바로 사용 가능

실제 변화

  • 사용 방식 변경 없이 PreToolUse 훅이 자동으로 출력 라우팅
  • 서브에이전트는 batch_execute를 기본 도구로 사용
  • Bash 서브에이전트는 general-purpose로 업그레이드되어 MCP 도구 접근 가능
  • 결과적으로 컨텍스트 창이 더 이상 빠르게 채워지지 않음, 동일 토큰으로 더 긴 세션 유지 가능

개발 배경

  • MCP Directory & Hub 운영 중 모든 MCP 서버가 원시 데이터를 컨텍스트에 덤프하는 공통 패턴을 발견
  • Cloudflare의 Code Mode가 도구 정의를 압축한 것에서 착안, 출력 데이터 압축 방향으로 확장
  • Claude Code 세션에서 6배 더 오래 작업 가능함을 확인 후 MIT 라이선스로 오픈소스 공개
  • GitHub: mksglu/claude-context-mode
▲
GN⁺ 8시간전  [-]
Hacker News 의견들

  • 여기서 제안된 FTS5 인덱스 접근법은 맞지만, 나는 한 단계 더 나아가야 한다고 생각함
    도구 출력은 구조화된 데이터(JSON, 테이블, 설정)와 자연어(주석, 오류 메시지, docstring)가 섞여 있어서 순수 BM25는 성능이 떨어짐
    나는 비슷한 문제를 해결하기 위해 Model2Vec + sqlite-vec + FTS5를 결합한 하이브리드 검색기를 만들었음. 두 검색 결과를 Reciprocal Rank Fusion(RRF) 으로 합쳐서, BM25의 정확한 키워드 매칭과 벡터 검색의 의미 기반 매칭을 동시에 얻을 수 있음
    증분 인덱싱도 중요함. 내 인덱서는 --incremental 플래그로 변경된 청크만 다시 임베딩함. 전체 15,800개 파일 재인덱싱은 4분, 일일 증분은 10초 미만임
    캐싱 측면에서도 이 방식은 유리함. 동일한 쿼리에 대해 압축된 출력이 결정적(deterministic) 이라 프롬프트 캐시가 안정적으로 작동함
    Context Mode 아키텍처에 추가할 점은, 같은 검색기를 PostToolUse 훅으로 실행해 출력이 대화에 들어가기 전에 압축되도록 하는 것임

    • OP의 접근법에서 구조화된 응답이 그대로 남는 점이 문제였는데, 나는 샌드박스 실행이 불가능한 MCP 게이트웨이를 만들고 있어서 이 방법이 매우 유용해 보임. 오늘 하루 이걸 시도해볼 예정임
    • 이 내용에 대한 심화 글을 꼭 읽어보고 싶음. HN의 꼼꼼한 노트테이커들이 좋아할 것 같음
    • 나도 이 Obsidian 인덱싱 작업의 배경과 구현 과정을 자세히 보고 싶음

  • 글 작성자임. 며칠 전 GitHub 저장소를 공유했는데 좋은 피드백을 받았음. 이번 글은 그 아키텍처 설명임
    핵심 아이디어는 MCP 도구 호출이 덤프하는 원시 데이터를 200K 컨텍스트 창에 넣는 대신, Context Mode가 격리된 서브프로세스를 생성해 stdout만 컨텍스트로 전달하는 것임. LLM 호출 없이 순수 알고리즘 기반으로, SQLite FTS5 + BM25 + Porter stemming을 사용함
    최근에는 228개의 스타와 실제 사용 데이터를 얻었고, 서브에이전트 라우팅이 얼마나 중요한지 깨달았음. Bash 서브에이전트를 일반형으로 자동 업그레이드해 batch_execute를 쓰면 원시 출력으로 컨텍스트를 채우지 않아도 됨

    • 블로그 글에 Cloudflare Code Mode 포스트 링크를 추가하면 좋겠음. README에는 있지만 본문에는 없음
    • 매우 흥미로워서 직접 시도해볼 예정임. 다만 Context Mode가 MCP 컨텍스트 사용 자체를 다루는 건 아닌 것으로 이해했는데, 맞는지 확인하고 싶음. 여러 Claude 환경에서 MCP를 쓰는 입장이라 CLI만으로는 한계가 있음
    • 이걸 Zed Agent 같은 다른 에이전트와도 쓸 수 있는지 궁금함
    • Codex를 지원하지 않는 이유가 있는지 알고 싶음. 구조상 에이전트 독립적으로 보이는데
    • 이 방식이 캐시를 깨뜨리지는 않는지 궁금함

  • 왜 mcp-cli 모드를 쓰지 않는지 모르겠음. 나는 wener-mcp-cli로 복제 버전을 만들어둠

  • 멋진 작업임. 컨텍스트 윈도 관리에는 아직 더 많은 개선 여지가 있다고 생각함. 예를 들어 모델이 여러 번 시도 끝에 정답을 찾으면, 실패한 시도들을 컨텍스트에서 제거하는 백트래킹 접근이 유용할 것 같음

    • 나도 동의함. 디버깅 중 생긴 로그나 실패 기록은 버그를 고친 후에는 제거할 수 있어야 함. 현재 IDE에서는 수동으로 하기 번거로움. 에이전트가 스스로 컨텍스트를 관리하고, 로그 같은 건 일정 횟수 후 자동으로 정리되면 좋겠음. 컨텍스트는 단순한 스택이 아니라 자유롭게 조작 가능한 공간으로 봐야 함
    • 실패한 시도는 결국 노이즈임. 재시도 패턴을 자동 감지해 마지막 성공 버전만 남기는 건 충분히 구현 가능함
    • 지금은 1990년대 후반처럼 느껴짐. 그때는 HTML과 SQL이었다면, 지금은 코딩 에이전트임. 우리는 이미 숙련된 엔지니어라 Claude Code를 쓰며 자연스럽게 최적화를 찾아냄
    • 서브에이전트를 활용하는 것도 방법임. 문제가 생기면 서브에이전트를 포크해 해결하고 결과만 가져오면 됨. 모델이 스스로 메모리를 지우고 과거 상태로 되돌아가는 상상도 흥미로움
    • 나는 실제로 이렇게 함. 각 작업 호출은 별도 서브프로세스로 실행되어 부모 컨텍스트를 오염시키지 않음. 완료 후 결과, 과정 요약, 실패 시도, 배운 점을 4가지로 정리해 부모에게 전달함. 도구 출력은 파일로 저장하고, LLM은 필요한 부분만 읽음. 예를 들어 “Success!”로 끝나면 마지막 줄만 보면 됨. 실패 시엔 오류 메시지만 읽음. 로컬 모델로 로그를 요약해 클라우드 모델에 전달하는 실험도 하고 있음. 최신 기술은 아니더라도 내 환경에서는 잘 작동함

  • 이 글을 보고 Claude Code 토큰 사용량을 전혀 모른다는 걸 깨닫고, 아침에 claude-trace라는 CLI를 만들었음
    ~/.claude/projects/*/*.jsonl을 파싱해 세션, 도구, 프로젝트, 타임라인별 사용량과 비용(캐시 읽기/생성 포함)을 분석함
    Context Mode가 출력 압축을 잘 해결한다면, 이건 측정 레이어로써 변경 전후의 소비를 시각화함

    • “/context?”라는 질문처럼, 실제로 토큰이 어디로 쓰이는지 가시화하는 게 핵심임

  • 많은 토큰 사용은 MCP 대신 CLI 앱을 쓰면 줄일 수 있음. 예를 들어 GitHub CLI는 MCP보다 훨씬 적은 토큰으로 같은 일을 함

  • 훅이 너무 공격적으로 느껴짐. 모든 curl/wget/WebFetch를 차단하고 샌드박스로 56KB 스냅샷을 만드는 건 좋지만, 단순한 curl api.example.com/health처럼 200바이트만 필요한 경우엔 과함
    153개의 git 커밋을 107바이트로 압축하면, 모델이 완벽한 추출 스크립트를 작성해야만 데이터를 볼 수 있음. 잘못된 명령을 쓰면 필요한 정보가 사라짐
    벤치마크는 모델이 항상 올바른 요약 코드를 작성한다고 가정하지만, 실제로는 그렇지 않음

    • 나도 동의해서 그 기능을 제거했음

  • 나쁘지 않지만, 정확도 손실과 환각 위험이 있음. 불완전한 데이터나 잘못된 추출 로직 때문에 Claude가 잘못된 결론을 낼 수 있음. MCP가 좋은 추출 스크립트와 검색 쿼리를 모두 작성할 만큼 똑똑해야 한다는 가정이 있음. 정보 보존이 실제로는 큰 문제라고 생각함

  • 압축률은 인상적이지만, 압축된 컨텍스트로도 모델이 동일한 품질의 출력을 내는지가 궁금함. 세션을 30분에서 3시간으로 늘려도, 2시간째의 추론 품질이 유지되어야 의미가 있음
    esafak이 말한 캐시 경제성도 중요함. 프롬프트 캐싱이 잘 되면 장황한 컨텍스트도 사실상 무료임. 하지만 압축이 캐시 연속성을 깨면 오히려 비용이 늘 수 있음
    더 근본적인 문제는 대부분의 MCP 도구가 SELECT *로 모든 데이터를 가져온다는 것임. 요약과 드릴다운을 지원하는 프로토콜 설계 문제임

    • 캐시가 무료처럼 보여도 실제로는 주의력 저하와 속도 저하를 유발함. 긴 프리픽스를 재사용하더라도 계산량은 여전히 커짐

  • 80개 이상의 도구를 컨텍스트에 넣을 필요가 있는지 의문임. 컨텍스트는 금과 같아서, 문제와 무관한 걸 많이 넣을수록 결과가 나빠짐. 데이터 압축보다는 서브에이전트 분리가 더 나은 접근임

    • 맞는 말임. 하지만 대부분은 작업별로 MCP 서버를 직접 관리하지 않음. 5~6개 서버만 설치해도 기본으로 80개 도구가 로드됨. Context Mode는 도구 정의의 과잉을 해결하지는 않음. 대신 도구 실행 후 덤프되는 출력 측면을 다룸. 예를 들어 Playwright 스냅샷이나 git log 하나만으로도 5만 토큰이 날아가는데, 그걸 샌드박스로 처리함
답변달기