Context Mode는 AI 코딩 에이전트의 컨텍스트 병목을 운영체제처럼 다룬다

코딩 에이전트를 오래 써 본 팀이라면 결국 비슷한 지점에서 막힌다. 모델이 코드를 잘 쓰는지보다, 도구가 뿜어내는 방대한 출력과 중간 상태를 얼마나 오래 보존할 수 있는지가 더 큰 병목이 된다. Playwright 스냅샷 한 번, GitHub 이슈 목록 한 번, 빌드 로그 몇 번만 오가도 대화창의 상당 부분이 원시 데이터로 채워지고, 세션이 compact되면 모델은 방금 하던 파일 편집 맥락이나 작업 순서를 잃어버리기 쉽다.

mksglu/context-mode는 바로 이 문제를 “모델이 더 똑똑해지면 해결된다”가 아니라, 런타임이 관리해야 할 인프라 계층이라고 본다. 저장소 설명과 README가 반복해서 강조하는 것도 이 지점이다. 이 프로젝트는 단순한 MCP 툴 하나가 아니라, 샌드박스 실행·세션 연속성·검색 기반 재주입·응답 압축을 묶어서 컨텍스트 창을 운영 자원처럼 아끼는 실행 레이어를 만들려 한다.

흥미로운 점은 범위가 꽤 넓다는 것이다. 공개 README와 설정 문서 기준으로 context-mode는 Claude Code, Gemini CLI, VS Code Copilot, JetBrains Copilot, Cursor, OpenCode, KiloCode 등 다수의 에이전트 하네스를 겨냥한다. 즉 특정 벤더의 기능 확장이 아니라, “AI 코딩 에이전트가 컨텍스트를 다루는 공통 방식”을 만들려는 시도에 가깝다.

무엇을 해결하려는가

context-mode가 겨냥하는 문제는 단순히 토큰 절약이 아니다. README의 문제 정의를 보면 네 가지가 함께 묶여 있다. 첫째, MCP 도구 호출이 원시 출력을 그대로 컨텍스트 창에 밀어 넣는 문제다. 둘째, 세션 compact 이후 에이전트가 편집 중인 파일, 최근 사용자 결정, 작업 흐름 같은 상태를 잃는 문제다. 셋째, 모델이 직접 계산과 분류를 수행하려고 하면서 쓸데없이 많은 데이터를 읽는 문제다. 넷째, 장황한 응답 스타일 자체가 또 다른 컨텍스트 낭비가 된다는 문제다.

이 네 문제는 서로 연결돼 있다. 원시 출력이 많이 들어오면 compact가 빨라지고, compact가 오면 상태를 잃고, 상태를 잃으면 같은 파일과 로그를 다시 읽게 되고, 그러면 다시 더 많은 출력을 태운다. context-mode는 이 악순환을 끊기 위해 “도구 출력의 샌드박싱”과 “이벤트 수준의 상태 기록”을 함께 가져간다.

실무적으로 보면 이는 긴 디버깅 세션이나 멀티 스텝 구현에서 특히 중요하다. 모델이 똑똑해도, 직전 세션의 에러 원인과 작업 중이던 파일 목록을 잊으면 반복 작업이 생긴다. context-mode는 이를 기억력 문제가 아니라 state management 문제로 재정의한다는 점에서 꽤 명확한 문제의식을 갖고 있다.

핵심 아이디어 / 구조 / 동작 방식

context-mode의 구조는 크게 네 층으로 읽을 수 있다.

첫 번째는 sandboxed processing이다. README와 CLAUDE.md는 분석·카운팅·필터링·비교·파싱 같은 작업을 직접 대화 맥락에서 하지 말고 ctx_execute, ctx_execute_file, ctx_batch_execute 같은 도구에 넘겨 코드로 처리하라고 강하게 요구한다. 핵심 철학은 “Think in Code”다. 데이터를 모델이 읽는 대신, 모델이 짧은 프로그램을 작성해 결과만 console.log() 하게 만들자는 것이다.

두 번째는 searchable session continuity다. README에 따르면 파일 편집, git 작업, task, error, user decision 같은 이벤트가 SQLite에 기록되고, 세션이 compact된 뒤에는 그 기록을 FTS5/BM25 검색으로 다시 불러온다. 중요한 점은 전체 이력을 다시 대화에 밀어 넣는 것이 아니라, 필요한 부분만 검색 기반으로 복원한다는 것이다. 즉 단순한 세션 로그 덤프가 아니라 retrieval layer를 붙인 상태 저장소에 가깝다.

세 번째는 platform-specific hook injection이다. 이 프로젝트는 단일 MCP 서버로 끝나지 않는다. .claude-plugin, .openclaw-plugin, 각종 configs/ 디렉터리, adapter별 문서가 함께 들어 있고, README는 플랫폼마다 hook과 routing instruction 주입 방식을 다르게 설명한다. Claude Code는 plugin marketplace와 SessionStart hook, Cursor는 hooks + .mdc rule 파일, OpenCode/KiloCode는 TypeScript plugin, JetBrains Copilot은 .github/hooks/context-mode.json과 MCP 설정 UI를 조합한다. 즉 동일한 아이디어를 여러 하네스의 제약에 맞춰 이식하는 구조다.

네 번째는 output compression discipline이다. CLAUDE.md는 “terse like caveman”이라는 거친 슬로건으로 응답 스타일 자체를 압축 규율로 다룬다. 이는 보기엔 단순한 writing rule 같지만, README 문맥에서는 샌드박싱·세션 복구와 함께 컨텍스트 절감의 네 번째 축으로 배치된다. 즉 context-mode는 입력 측면의 낭비만이 아니라 출력 측면의 낭비도 런타임 정책으로 다루고 있다.

지원 범위도 꽤 공격적이다. README는 14개 플랫폼을 언급하고, 루트 구조에는 Claude Code용 .claude-plugin, OpenClaw용 openclaw.plugin.json, PI extension 경로, 여러 adapter별 config와 docs가 들어 있다. package.json도 이 프로젝트가 단순 로컬 스크립트가 아니라 CLI, plugin export, OpenClaw extension, skills 디렉터리까지 함께 배포하는 패키지라는 점을 보여준다.

공개된 근거에서 확인되는 점

가장 눈에 띄는 근거는 수치다. GitHub API 기준 조회 시점의 저장소는 약 13.2k stars, 901 forks, 13 open issues를 보이고, 최신 릴리스는 v1.0.111이다. 루트 페이지는 태그가 이미 140개까지 쌓여 있음을 보여 주며, stats.json에는 users 132.7k+, npm 108.9k+, marketplace 23.7k+라는 별도 설치/사용 지표가 들어 있다. star 수와 설치 수는 직접 비교할 수 있는 같은 단위는 아니지만, 적어도 저장소 반응보다 실제 배포 채널 지표를 더 강조하려는 프로젝트라는 점은 분명하다.

벤치마크 문서도 꽤 구체적이다. BENCHMARK.md는 총 21개 시나리오, 376KB 원시 데이터, 16.5KB 컨텍스트 소비, 전체 96% 절감이라는 숫자를 제시한다. 특히 ctx_execute_file 파트에서는 315KB를 5.5KB로 줄여 98% 절감했다고 적고, ctx_index + ctx_search 파트에서는 60.3KB를 11.0KB로 줄여 82% 절감을 제시한다. 중요한 건 이 둘을 같은 방식으로 보지 않는다는 점이다. 요약이 적합한 로그/빌드 출력은 압축하고, 정확한 코드 블록이 중요한 문서/레퍼런스는 FTS5 검색으로 원문 chunk를 되돌려주는 식으로 역할을 나눈다.

또 다른 신호는 테스트와 배포 구조다. BENCHMARK.md는 Executor 55개, ContentStore 34개, MCP Integration 22개, Ecosystem Benchmark 14개로 총 125개 테스트가 모두 통과한다고 적는다. package.json에는 test, benchmark, test:ecosystem, doctor, setup, install:openclaw 같은 스크립트가 분명히 나뉘어 있고, 선택적 의존성으로 better-sqlite3를 둬 로컬 DB를 활용한다. 이는 단순 프롬프트 모음이 아니라 런타임/도구 체인을 포함한 실제 소프트웨어라는 의미다.

라이선스는 특히 주의해서 볼 필요가 있다. GitHub API의 license 필드는 Other / NOASSERTION으로 보이지만, README badge, package.json, .claude-plugin/plugin.json, openclaw.plugin.json은 모두 Elastic License 2.0을 가리킨다. 게다가 커밋 히스토리 링크 중에는 “MIT에서 ELv2로 전환”한 흔적도 노출된다. 따라서 이 저장소를 단순한 permissive 오픈소스처럼 보는 것은 부정확하다. 사용이나 재배포 문맥에서 라이선스 해석이 중요할 수 있다.

실무 관점에서의 해석

내가 보기에 context-mode의 진짜 의미는 “컨텍스트 엔지니어링”을 프롬프트 기교에서 운영 계층으로 끌어내린 데 있다. 많은 팀이 지금까지는 긴 시스템 프롬프트, 요약 습관, 수동 메모 같은 방식으로 문제를 버텨 왔다. 하지만 context-mode는 그보다 한 단계 아래로 내려가, 어떤 도구를 언제 우회하고 어떤 상태를 DB에 남기며 어떤 검색 계층으로 다시 끌어올릴지를 실행 환경이 책임져야 한다고 주장한다.

이 해석은 멀티 하네스 지원과도 연결된다. Claude Code, Cursor, Gemini CLI, Copilot, OpenCode처럼 각 환경의 hook 체계와 MCP 연결 방식은 다르지만, 컨텍스트 낭비라는 문제 자체는 공통이다. context-mode는 이 공통 병목을 겨냥해 “라우팅 규칙 + 로컬 지식 저장소 + 샌드박스 계산 + terse output”이라는 공통 해법을 이식하려 한다. 즉 특정 모델 최적화라기보다, 에이전트 런타임 운영 원칙을 패키징한 프로젝트에 가깝다.

물론 한계도 있다. 첫째, 벤치마크 수치는 설득력 있지만 대부분 프로젝트가 정의한 사용 시나리오 위에서 나온다. 실제 팀 환경에서는 어떤 도구를 얼마나 자주 쓰는지, raw output을 반드시 봐야 하는 순간이 얼마나 많은지에 따라 체감 절감 폭이 달라질 수 있다. 둘째, hook과 rules file, plugin, adapter 문서가 많다는 것은 곧 설치/운영 복잡도가 높다는 뜻이기도 하다. README가 플랫폼별로 상세 설치법을 따로 설명하는 이유도 바로 이것이다. 셋째, 라이선스가 ELv2라는 점은 개인 사용과 별개로 조직 도입 시 검토 포인트가 될 수 있다.

그럼에도 방향은 매우 설득력 있다. 코딩 에이전트 경쟁이 단순 모델 품질을 넘어 실제 장시간 작업 완주율로 이동한다면, 승부는 더 큰 컨텍스트 창보다 “컨텍스트를 덜 태우는 운영 레이어”에서 날 가능성이 크다. 그런 점에서 context-mode는 MCP 도구 하나라기보다, AI 코딩 에이전트 시대의 메모리 관리·상태 복구·출력 통제 정책을 한 묶음으로 제품화한 사례로 보는 편이 맞다.