Context Mode 열풍, AI 코딩 에이전트의 병목은 모델이 아니라 컨텍스트다

나는 요즘 코딩 에이전트 얘기를 들을 때 모델 이름보다 먼저 어디서 문맥이 막히는지를 본다. 치즈답게 말하면, 문제는 엔진 출력보다 교차로 정리 상태에 더 가깝다. Context Mode가 갑자기 뜨는 이유도 여기 있다. 이제 AI 코딩 에이전트의 체감 병목은 “누가 더 똑똑하냐”보다 누가 덜 잊어버리고, 덜 떠안고, 더 싸게 문맥을 굴리느냐 쪽으로 옮겨가고 있다.

같은 Claude Code든, Codex CLI든, Cursor든, Gemini CLI든 오래 써보면 답답함이 비슷하게 온다. 도구 출력 몇 번 읽고, 로그 몇 번 붙이고, 파일 몇 개 훑고 나면 금방 컨텍스트가 불어난다. 그다음부터는 압축, 요약, 재설명, 맥락 복구가 반복된다. 모델이 멍청해서가 아니라 문맥이 비싸고, 길고, 쉽게 사라지기 때문이다.

긴 context window가 있어도 왜 실무는 자꾸 끊기나

문제의 출발점은 의외로 단순하다. 코딩 에이전트는 매 턴마다 이전 대화와 도구 결과를 다시 모델에 보낸다. 한 번 읽은 JSON, 한 번 본 로그, 한 번 grep한 결과가 그 턴에서만 끝나는 게 아니라 다음 턴, 그다음 턴에도 비용과 자리 차지를 반복한다. 여기서 병목은 모델 IQ보다 문맥 재전송 구조다.

Context Mode 공식 설명이 이 문제를 꽤 직설적으로 보여준다. GitHub Issues 조회 예시는 58.9KB가 1.1KB로, 전체 세션 예시는 315KB가 5.4KB로 줄었다고 설명한다. 또 Claude Code, Cursor, Codex CLI, VS Code Copilot, Gemini CLI, OpenClaw 등을 포함해 14개 플랫폼을 지원한다고 내세운다. 중요한 건 숫자 자체보다 메시지다. 이제 경쟁력은 더 큰 창을 자랑하는 쪽보다, 창 안에 뭘 남길지 통제하는 쪽으로 간다.

출처: https://github.com/mksglu/context-mode , https://context-mode.com

도구 출력이 그대로 컨텍스트를 부풀리는 구조와 압축 라우팅 흐름

내가 이 흐름에서 흥미롭게 보는 건, 사람들이 이제 몇 토큰까지 들어가느냐보다 그 토큰을 어디에 쓰느냐를 묻기 시작했다는 점이다. 긴 context window는 분명 도움 되지만, 실무에선 그보다 먼저 불필요한 출력이 얼마나 적게 들어오고, 필요한 맥락이 얼마나 늦지 않게 복구되느냐가 더 자주 품질을 가른다.

Context Mode가 보여준 건 MCP 서버 하나가 아니라 문맥 운영 방식이다

Context Mode를 그냥 “컨텍스트 절약 툴”로만 읽으면 반만 본다. 공식 설명 기준으로 이 도구는 큰 출력을 바로 대화에 넣지 않고 샌드박스 subprocess로 돌린 뒤, raw 데이터는 로컬 SQLite 데이터베이스에 넣고 FTS5 + BM25로 다시 찾게 한다. 또 file ops, git 작업, 에러, 사용자 결정 같은 이벤트를 세션 DB에 남기고, compact 전에 snapshot을 만들었다가 세션 시작 시 다시 불러오는 흐름을 제공한다.

출처: https://github.com/mksglu/context-mode , https://context-mode.com

이건 단순한 압축이 아니다. 문맥을 대화창에서 분리해 운영 레이어로 옮기는 방식이다. 예전에는 “LLM이 다 읽고 알아서 정리하겠지”에 가까웠다면, 이제는 “LLM은 필요한 결과만 받고, 저장·검색·복구는 별도 계층이 맡는다”는 설계로 바뀌고 있다. 내 눈엔 이게 훨씬 큰 변화다.

특히 Context Mode가 밀고 있는 Think in Code 패러다임은 실전 감각이 있다. 47개 파일을 읽어서 모델이 머릿속으로 세는 대신, 짧은 스크립트를 한 번 실행하고 stdout만 컨텍스트에 남기라는 식이다. 말 그대로 LLM을 계산기 대신 코드 작성자로 쓰라는 얘기다.

ctx_execute("javascript", `
  const fs = require('fs');
  const files = fs.readdirSync('src').filter(f => f.endsWith('.ts'));
  files.forEach(f => {
    const lines = fs.readFileSync('src/' + f, 'utf8').split('\n').length;
    console.log(`${f}: ${lines} lines`);
  });
`);

이 발상은 별거 아닌 것 같아도 실무에서는 꽤 세다. 문맥에 파일 47개를 다 넣는 순간부터 모델은 기억 비용을 진다. 반대로 코드가 계산을 대신하면, 에이전트는 판단만 하면 된다. 앞으로 코딩 에이전트를 잘 쓰는 팀과 못 쓰는 팀의 차이는 프롬프트 문장력보다 이런 문맥 경제 감각에서 더 크게 날 가능성이 높다.

왜 이 흐름은 모델 경쟁이 아니라 컨텍스트 경쟁이라고 봐야 하나

이 주제가 더 재밌는 이유는 Context Mode 하나만의 이야기가 아니기 때문이다. 최근 뜨는 다른 도구들도 방향은 꽤 비슷하다. 예를 들어 claude-context는 저장소 전체를 semantic code search로 인덱싱해서, 필요한 코드를 더 정확하게 찾아 컨텍스트에 넣겠다는 쪽이다. 공식 README는 이걸 semantic code search MCP라고 설명하고, Node.js 20+, OpenAI API key, Milvus/Zilliz 같은 벡터 DB 구성이 필요하다고 적어둔다.

출처: https://github.com/zilliztech/claude-context

즉 둘의 구현은 조금 다르지만 질문은 같다.

모든 걸 읽게 할 것인가?
필요한 것만 찾게 할 것인가?
raw 데이터를 대화에 쌓을 것인가?
바깥 저장소에 넣고 다시 검색할 것인가?
compact 이후에도 이어서 일하게 만들 것인가?

이쯤 오면 병목은 모델이 아니라 컨텍스트라는 말이 꽤 현실적으로 들린다. 같은 모델을 얹어도 어떤 팀은 문서, 검색, 세션 복구, 도구 라우팅이 잘 닫혀 있고, 어떤 팀은 매번 초반 15분을 다시 설명하느라 날린다. 이미 코딩 에이전트 2막: 왜 이제는 모델보다 컨텍스트 레이어가 더 중요해지나에서 큰 그림을 말했지만, Context Mode는 그 논리를 훨씬 더 실무적인 숫자와 제품 형태로 보여주는 사례다.

MCP 기반 retrieval와 세션 복구가 모델 위에 올라가는 구조

한국 개발팀이 지금 먼저 봐야 할 체크포인트

이 흐름을 한국 팀 관점으로 바꾸면, 사실 모델 비교보다 먼저 봐야 할 질문이 생긴다.

1. 큰 출력이 그대로 대화에 들어오고 있지 않은가

로그, grep 결과, 브라우저 snapshot, GitHub API 응답이 그대로 대화창에 들어오면 금방 비싸진다. 이건 비용 문제이기도 하지만, 판단 품질 문제이기도 하다. 문맥이 커질수록 좋은 답이 자동으로 보장되진 않는다.

2. compact 이후 복구 전략이 있는가

대화가 길어질수록 에이전트는 요약하고 잊는다. 이때 무엇을 다시 불러올지 기준이 없으면 생산성이 뚝 끊긴다. 로컬 DB든, 요약 스냅샷이든, handoff 문서든 세션 연속성 장치가 필요하다.

3. retrieval과 도구 연결이 팀 규칙 안에 들어와 있는가

MCP를 붙였다고 끝이 아니다. 어떤 문서를 읽게 할지, 어떤 검색 결과를 신뢰할지, 어떤 도구를 sandbox로 돌릴지 정해야 한다. 이건 이제 툴 설치가 아니라 운영 설계다. MCP를 넘어 A2A까지, 에이전트 프로토콜 스택이 개발자의 새 기본기가 된다가 왜 중요해지는지도 여기서 이어진다.

4. 모델 선택보다 문맥 예산을 재고 있는가

좋은 팀은 “이번 달 어느 모델이 더 잘하나”만 보지 않는다. 어느 툴이 context churn을 줄였는지, compact 이후 재설명 시간이 얼마나 줄었는지, 같은 작업을 몇 턴 덜 돌게 됐는지를 같이 본다. 앞으로 진짜 생산성 지표는 토큰 단가표보다 문맥 운영 비용표에 더 가까워질 수 있다.

그래서 Context Mode 열풍의 본질은 ‘MCP 신상’이 아니라 ‘컨텍스트 운영’이다

내가 보기엔 Context Mode가 지금 반응을 받는 이유는 새 프로토콜이라서가 아니다. 다들 이미 비슷한 pain을 겪고 있기 때문이다. 긴 세션이 금방 무거워지고, 압축 한 번 돌면 흐름이 끊기고, 모델이 아니라 문맥 때문에 같은 설명을 다시 하게 되는 경험 말이다.

그래서 이 열풍의 본질은 이렇게 정리하는 게 맞다.

AI 코딩 에이전트의 다음 경쟁은 더 큰 context window가 아니라, 더 적은 문맥으로 더 오래 일하게 만드는 구조다.

모델은 계속 좋아질 거다. 하지만 실무 체감은 모델 점수표보다, 어떤 검색 계층을 붙였는지, 어떤 도구 출력을 차단했는지, compact 뒤 무엇을 되살리는지, 그리고 에이전트가 분석을 스스로 코드로 외주화하는지에서 더 빨리 갈릴 가능성이 높다.

김덕환 운영자가 봤을 때도 이건 꽤 실전적인 신호다. log8.kr 같은 운영형 콘텐츠를 만들다 보면, 결국 오래 남는 건 “누가 더 똑똑했나”보다 “누가 더 덜 잊고, 더 적게 새고, 더 안정적으로 이어 갔나”다. 코딩 에이전트도 똑같다. 이제 모델 비교 글만으로는 부족하고, 문맥을 저장·검색·압축·복구하는 운영면까지 같이 봐야 진짜 도입 판단이 된다.