Post

컨텍스트 윈도우는 쓰레기통이 아니다: AI 에이전트의 멱살을 잡는 'Context Mode' 아키텍처 심층 해부

Posted
The Context Window is Not a Trash Can: A Deep Dive into the 'Context Mode' Architecture Saving AI Agents
The Context Window is Not a Trash Can: A Deep Dive into the 'Context Mode' Architecture Saving AI Agents
By
17 min read
컨텍스트 윈도우는 쓰레기통이 아니다: AI 에이전트의 멱살을 잡는 'Context Mode' 아키텍처 심층 해부

Metadata

  • Project: mksglu/context-mode (Elastic License 2.0)
  • Architecture: MCP (Model Context Protocol) Virtualization Layer
  • Core Tech: Subprocess Sandboxing, SQLite (FTS5/BM25), Event Hooks
  • Compatibility: Claude Code, Gemini CLI, Cursor, Copilot 등 14개 이상 플랫폼

최근 프로젝트에서 Claude Code나 Cursor 같은 AI 코딩 에이전트에게 복잡한 디버깅을 맡겨본 분이라면 십중팔구 제 말에 공감하실 겁니다. 처음 한두 시간은 기가 막히게 코드를 쫓아갑니다. 감탄이 절로 나오죠. 하지만 복잡한 버그를 추적하기 위해 에이전트가 서버 로그를 뒤지거나 grep 명령어를 몇 번 날리는 순간, 녀석은 갑자기 멍청해집니다. 분명 아까 고쳤던 코드를 다시 원복하려 들거나, 방금 내렸던 지시를 까맣게 잊어버린 채 “제가 파일을 다시 읽어보겠습니다” 같은 헛소리를 반복하죠.

왜 그럴까요? 컨텍스트 윈도우가 쓰레기 데이터로 꽉 찼기 때문입니다. 우리는 200K, 1M 토큰 시대라고 환호했지만, 현실은 처참합니다. 에이전트가 Playwright 스냅샷 하나를 읽을 때마다 56KB가 증발하고, GitHub 이슈 20개를 긁어오면 59KB가 날아갑니다. 도구(Tool)를 쓸 때마다 쏟아지는 날것의(Raw) 데이터가 LLM의 단기 기억을 무참히 박살 내는 겁니다. 이 문제를 해결한답시고 모델의 컨텍스트 제한을 더 늘리는 건 비용만 태우고 모델의 집중력(Attention)만 분산시키는 하수들의 접근법입니다.

솔직히 처음엔 저도 의구심이 들었습니다. ‘그냥 프롬프트 엔지니어링으로 출력 길이를 줄이라고 하면 되는 거 아닌가?’ 하고요. 하지만 실무 수준의 복잡도에서는 어림도 없습니다. 그래서 오늘 다룰 기술은, 이 무식한 데이터 덤프를 원천 차단하고 에이전트의 세션 연속성을 보장하는 가장 우아한 아키텍처, 바로 Context Mode입니다.

TL;DR (The Core)

Context Mode는 AI 에이전트와 도구(Tool) 사이에 위치하여, 무거운 출력값을 독립된 샌드박스에서 실행하고 핵심 요약본만 컨텍스트에 전달함으로써 토큰 낭비를 98% 줄여주는 ‘프라이버시 우선 로컬 메모리 가상화 레이어’입니다.

Deep Dive: Under the Hood (핵심 아키텍처 심층 분석)

단순히 ‘컨텍스트를 아껴준다’는 마케팅 용어는 치워버리고, 밑바닥 아키텍처를 뜯어보겠습니다. Context Mode가 기존 MCP(Model Context Protocol) 환경과 구분되는 가장 큰 특징은 ‘가로채기(Interception)’와 ‘격리(Sandboxing)’입니다.

기존 MCP는 에이전트가 도구를 호출하면 그 결과값을 그대로 컨텍스트 윈도우에 때려 박았습니다. 반면 Context Mode는 에이전트의 도구 호출을 프로토콜 레이어에서 가로채어, 자신만의 Subprocess 샌드박스에서 실행합니다.

비교 항목기존 MCP 아키텍처 (Standard)Context Mode 아키텍처 (Virtualization Layer)
도구 실행(Execution)LLM 컨텍스트와 강하게 결합된 상태로 직접 실행독립된 Subprocess 샌드박스에서 격리 실행 (60+ 환경변수 차단)
출력 데이터(Output)수십~수백 KB의 Raw Data가 컨텍스트 윈도우로 직행315KB의 데이터를 5.4KB 수준으로 요약/압축 전달 (약 98% 감소)
세션 연속성(Continuity)컨텍스트 압축(Compaction) 발동 시 이전 대화/컨텍스트 영구 증발SQLite 기반 FTS5/BM25 검색을 통해 세션 스냅샷 저장 및 지연 복구
보안 및 프라이버시에이전트가 시스템 환경변수나 시크릿 키에 무방비 노출될 위험완전한 로컬 처리(~/.context-mode/), API Key/Token 등 서브프로세스 격리

이 마법이 가능하려면 에이전트의 라이프사이클에 강제로 개입할 수 있는 Hook(훅) 메커니즘이 필수적입니다. 아래는 JetBrains Copilot이나 Cursor 같은 환경에서 Context Mode를 주입하기 위해 구성하는 전형적인 JSON 훅 설정 예시입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "hooks": {
    "PreToolUse": [
      { "type": "command", "command": "context-mode hook jetbrains-copilot pretooluse" }
    ],
    "PostToolUse": [
      { "type": "command", "command": "context-mode hook jetbrains-copilot posttooluse" }
    ],
    "SessionStart": [
      { "type": "command", "command": "context-mode hook jetbrains-copilot sessionstart" }
    ]
  }
}

이 훅들이 동작하는 과정은 예술에 가깝습니다.

  1. PreToolUse: 에이전트가 curl, wget, 혹은 대용량 파일 읽기를 시도하면 이 훅이 발동해 명령을 차단하고 샌드박스로 우회시킵니다. 데이터 덤프를 사전에 방어하는 1차 방어선이죠.
  2. PostToolUse: 도구 실행이 끝난 후, 원본 Raw Data는 샌드박스에 남겨두고 LLM에게는 극단적으로 압축된 요약본(Output Compression)만 반환합니다. 동시에 백그라운드에서는 파일 변경, Git 작업, 에러 로그 등 15가지 카테고리의 이벤트를 로컬 SQLite 데이터베이스에 기록합니다.
  3. PreCompact & SessionStart (세션 영속성의 핵심): 대화가 길어져 에이전트가 자체적으로 컨텍스트를 잘라내는(Compact) 순간, 기존 에이전트들은 치매에 걸립니다. 하지만 Context Mode는 PreCompact 훅을 통해 현재까지의 논리적 흐름을 SQLite에 스냅샷으로 굽습니다. 이후 에이전트가 기억을 잃고 헤맬 때, SessionStart 훅과 FTS5(Full-Text Search) DB의 BM25 랭킹 알고리즘을 통해 지금 당장 필요한 과거의 단서만 정확히 검색해 컨텍스트에 다시 주입합니다. “아까 우리가 이 파일을 이렇게 고치기로 했었지?” 하고 에이전트 스스로 깨닫게 만드는 겁니다.

Pragmatic Use Cases (실무 적용 시나리오)

이 아키텍처가 현업에서 어떻게 우리를 구원하는지, 뻔한 Hello World 예제가 아닌 진짜 딥한 실무 시나리오로 살펴보죠.

1. CI/CD 파이프라인 및 대규모 레거시 로그 분석 시나리오 Spring Boot나 Node.js로 엮인 마이크로서비스 아키텍처에서 E2E 테스트(예: Playwright)가 실패했다고 가정해 봅시다. 에이전트에게 “에러 원인 좀 찾아줘”라고 명령하면, 이 멍청하고도 부지런한 녀석은 docker logs나 브라우저의 DOM 스냅샷 전체를 읽어오려고 시도합니다. 순식간에 10만 줄의 텍스트가 컨텍스트 윈도우로 쏟아지고, 에이전트는 환각(Hallucination)에 빠집니다. Context Mode가 켜져 있다면? PreToolUse가 이를 감지하여 서브프로세스에서 로그를 파싱합니다. 그리고 에이전트에게는 이렇게만 던져줍니다. “[결과] Login.jsx 42번 라인에서 NullPointerException 발생. 타겟 버튼 DOM 렌더링 지연이 원인임. [다음 단계] Timeout 로직 수정 제안.” 수십 MB의 로그가 5KB의 명확한 컨텍스트로 정제되는 순간입니다.

2. 장기 리팩토링 마라톤에서의 치매 예방 (Session Continuity) 수만 라인의 모노리포를 리팩토링하는 4시간짜리 세션. 한 2시간쯤 지났을 때, 에이전트가 컨텍스트 한계를 맞고 초기화(Compact)됩니다. 기존 방식이라면 “우리가 지금까지 어떤 패턴으로 리팩토링을 진행했지?”부터 다시 설명해야 합니다. 지옥이 따로 없죠. 하지만 Context Mode 환경에서는 에이전트가 새로운 지시를 받았을 때 로컬 SQLite를 BM25로 쿼리합니다. “아, 2시간 전에 UserAuth 모듈 리팩토링할 때 JWT 만료 예외 처리를 커스텀 클래스로 빼기로 합의했었지.” 과거의 의사결정 맥락(User Decision)이 파괴되지 않고 유지되므로, 실무자는 같은 설명을 두 번 할 필요가 없습니다.

Honest Review & Trade-offs (진짜 장단점과 한계)

시니어의 시선에서 냉정하게 평가해 봅시다. 이 기술이 마법의 은탄환일까요? 아닙니다. 도입 시 반드시 감수해야 할 뼈아픈 트레이드오프가 존재합니다.

1. Lossy Compression(손실 압축)의 치명적 리스크 데이터를 샌드박스에서 요약하고 잘라낸다는 것은, 필연적으로 정보의 손실을 의미합니다. 만약 C++ 메모리 누수나 비동기 레이스 컨디션처럼 로그의 아주 미세한 타이밍 차이나 엣지 케이스가 디버깅의 핵심 힌트라면 어떨까요? Context Mode의 요약 모듈이 이를 ‘불필요한 쓰레기 데이터’로 치부해버리고 날려버릴 수 있습니다. 이 경우 에이전트는 영원히 버그의 원인을 찾지 못하고 헛바퀴만 돌게 됩니다.

2. 플랫폼 파편화와 불안정한 Hook 생태계 현재 Context Mode는 14개의 플랫폼을 지원한다고 자랑하지만, 각 IDE와 에이전트(Cursor, Windsurf, JetBrains 등)마다 Hook을 지원하는 수준이 천차만별입니다. 당장 최근 포럼 리포트만 봐도 Cursor에서는 밸리데이터가 sessionStart 훅을 거부하는 버그가 있어 .cursor/rules 파일로 억지 라우팅을 태워야 하는 실정입니다. 즉, 내가 쓰는 툴체인에 완벽히 녹아들기까지는 지속적인 설정 튜닝과 버그 픽스가 강제되는 ‘가파른 러닝 커브’가 존재합니다.

3. Subprocess I/O 레이턴시 증가 모든 툴 호출이 샌드박스를 거치고 SQLite에 R/W 작업을 수행하므로, 단순한 파일 읽기에도 약간의 오버헤드가 발생합니다. 체감 상 짧게는 수백 ms에서 길게는 1~2초의 지연이 추가되는데, 성격 급한 개발자들에게는 이 미세한 버벅임이 거슬릴 수 있습니다.

Closing Thoughts

결론적으로 Context Mode는, 무작정 LLM의 컨텍스트 윈도우 크기만 늘리며 토큰 장사를 하던 업계에 던지는 묵직한 일침입니다. 진정으로 강력한 AI 에이전트 시스템은 ‘얼마나 많은 데이터를 한 번에 밀어 넣을 수 있는가’가 아니라, ‘무엇을 모델의 시야에서 치워버릴 것인가’를 통제하는 능력에서 나옵니다.

물론 아직 훅 연동의 불안정성이나 손실 압축의 리스크 등 성숙해져야 할 부분은 많습니다. 하지만 에이전트를 장난감이 아닌 실무 수준의 복잡한 엔지니어링 파트너로 격상시키기 위해, 이와 같은 ‘컨텍스트 가상화 레이어’는 선택이 아닌 필수 아키텍처로 자리 잡을 것입니다. 현업에서 컨텍스트 고갈로 고통받고 계셨다면, 당장 오늘 오후에 로컬 머신에 context-mode를 올려보시길 권합니다. 98% 줄어든 토큰 사용량과, 3시간이 지나도 치매에 걸리지 않는 에이전트의 든든함을 직접 체감해 보시기 바랍니다.

References

  • https://github.com/mksglu/context-mode
  • https://modelcontextprotocol.io
Tech
This post is licensed under CC BY 4.0 by the author.