최근 LLM 기반 개발 도구, 특히 Claude Code 와 MCP(Model Context Protocol) 생태계가 폭발적으로 성장하고 있습니다. 저도 처음엔 “와, 터미널에서 바로 도구를 쓴다고?” 하며 신나서 온갖 MCP 서버를 연결했습니다. GitHub, AWS, Postgres, Playwright… 다 연결했죠.

그런데 30분 정도 코딩하다 보면 익숙한 벽에 부딪힙니다. Context Window 가 꽉 찼다는 경고입니다. 모델은 점점 멍청해지고, 응답 속도는 느려지며, 비용은 치솟습니다. 도대체 왜일까요?

오늘 소개할 내용은 이 문제를 해결하기 위해 등장한 context-mode 라는 오픈소스 프로젝트와, 그 뒤에 숨겨진 기술적 원리에 대한 이야기입니다.

문제는 “입력”이 아니라 “출력”이다

MCP는 AI 에이전트가 외부 도구를 사용하는 표준입니다. 하지만 여기엔 치명적인 맹점이 있습니다. 도구 실행의 결과값(Output) 이 Raw Data 그대로 Context Window에 덤프된다는 점입니다.

예를 들어보겠습니다:

• Playwright 스냅샷: 한 번 찍으면 약 56KB입니다.
• GitHub 이슈 리스트: 20개만 가져와도 59KB입니다.
• 액세스 로그: 500줄만 읽어도 45KB가 날아갑니다.

이게 쌓이면 200K 토큰도 순식간입니다. Cloudflare는 최근 Code Mode 를 통해 도구의 정의(Schema)를 압축하는 방법을 제시했지만, 정작 실행 결과가 뿜어내는 데이터 폭탄은 해결하지 못했습니다. context-mode는 바로 이 Output Side 를 공략합니다.

작동 원리: LLM에게 “요약”만 던져라

이 프로젝트의 핵심 아이디어는 간단하면서도 강력합니다. “Raw Data는 샌드박스에 가두고, LLM에게는 검색 가능한 인덱스만 제공하자” 는 것입니다.

1. 프로세스 격리 (Sandbox)

Claude Code가 도구를 실행할 때, context-mode는 이를 가로채서 별도의 Subprocess 를 띄웁니다. Node.js의 child_process를 생각하시면 됩니다. 여기서 중요한 건 격리입니다.

• 스크립트는 서로의 메모리나 상태에 접근할 수 없습니다.
• 오직 stdout 만 캡처됩니다.
• 인증 정보(AWS 키, GitHub 토큰 등)는 화이트리스트 방식으로 필요한 것만 주입됩니다.

2. SQLite FTS5와 BM25 (RAG가 아닙니다)

여기서 재미있는 기술적 선택이 나옵니다. 보통 요즘 AI 트렌드라면 “임베딩해서 벡터 DB에 넣자”고 했을 겁니다. 하지만 이 프로젝트는 SQLite FTS5(Full-Text Search 5) 를 사용합니다.

왜 벡터가 아닐까요? 코드나 로그 데이터는 ‘의미론적 유사성’보다 ‘정확한 키워드 매칭’ 이 훨씬 중요하기 때문입니다. context-mode는 마크다운 헤딩 단위로 청크를 나누고, BM25 알고리즘 과 Porter Stemming 을 사용해 인덱싱합니다. 덕분에 “running”, “runs” 같은 단어 변형도 처리하면서, 정확한 로그 라인이나 코드 블록을 찾아낼 수 있습니다.

3. 결과: 315KB → 5.4KB

결과적으로 LLM의 Context에는 거대한 로그 파일 대신 “작업 완료. ID: 1234. 필요하면 검색해.” 정도의 짧은 스텁(Stub)만 들어갑니다. 모델이 세부 내용이 필요하면 그때 비로소 search 툴을 호출해서 필요한 부분만 긁어옵니다.

제작자가 공개한 벤치마크에 따르면, 30분이면 꽉 차던 세션이 3시간까지 유지된다고 합니다. 98%의 압축률이죠.

Hacker News의 반응과 인사이트

이 글이 HN에 올라왔을 때 엔지니어들의 반응은 뜨거웠습니다. 특히 “Context 관리의 주체” 에 대한 논의가 인상적이었습니다.

• 캐시 무효화(Cache Invalidation) 문제: 한 유저가 “이렇게 데이터를 빼버리면 프롬프트 캐시가 깨지는 거 아니냐?”고 물었습니다. 제작자의 답변이 명쾌합니다. “아니요, 애초에 거대한 데이터가 Context History에 들어간 적이 없으니 깨질 것도 없습니다.”
• Agentic Memory: 어떤 유저는 이 방식을 “Agentic Memory Management”라고 불렀습니다. 인간이 모든 것을 작업 기억(Working Memory)에 담아두지 않고 노트에 적어두는 것처럼, AI도 외부 저장소를 활용해야 한다는 것이죠.
• Backtracking: 실패한 시도(디버깅 로그 등)를 Context에서 가지치기(Pruning)하는 아이디어도 나왔습니다. context-mode는 사실상 이걸 Pre-compaction (선제적 압축) 형태로 구현한 셈입니다.

Principal Engineer의 시선: 이건 “필수”가 될 것이다

솔직히 말해서, 지금의 MCP 구조는 너무 순진합니다(Naive). 모든 출력을 Context에 때려 박는 방식은 데모에서는 멋져 보이지만, 실무 레벨의 복잡한 디버깅 세션에서는 지속 불가능합니다.

저는 이 패턴이 결국 LLM OS 나 에이전트 프레임워크의 기본 기능으로 흡수될 것이라 봅니다. 하지만 그전까지는 context-mode 같은 미들웨어가 필수적입니다.

특히 인상적인 부분은 기술 스택의 실용성 입니다. 유행하는 Vector DB 대신 SQLite FTS5를 쓴 점은 엔지니어링 관점에서 아주 칭찬할 만합니다. 로컬에서 가볍게 돌려야 하는 MCP 서버 특성상, 무거운 의존성 없이 빠르고 정확한 검색을 구현한 건 탁월한 선택입니다.

적용 팁: 만약 팀에서 Claude Code를 헤비하게 쓰고 있다면, 당장 이 서버를 도입하세요. 특히 Playwright나 대량의 Git 로그를 다루는 작업에서는 체감 성능이 10배 이상일 겁니다. 다만, 샌드박스 구조상 일부 복잡한 환경 변수 의존성이 있는 사내 툴은 설정에 손이 좀 갈 수 있습니다.

결론적으로, 우리는 이제 AI에게 “모든 걸 기억해”라고 강요하는 대신, “필요한 건 찾아봐”라고 가르쳐야 할 때가 왔습니다.