모델을 바꿔도 같은 곳에서 틀린다
팀에서 AI 코딩 어시스턴트를 쓰다 보면 주기적으로 똑같은 장면이 반복된다. GPT-4에서 GPT-5로 올렸는데 여전히 deprecated API를 추천한다. Claude Sonnet을 Opus로 바꿨는데 Next.js 버전을 혼동한다. 그래서 또 다음 모델을 기다린다. dev.to에 올라온 한 분석은 이 반복을 "모델 업그레이드 트레드밀"이라고 정확히 짚는다. 벤치마크는 계속 올라가는데 틀리는 패턴은 바뀌지 않는다면, 문제는 모델이 아니다.
실제로 최신 LLM의 환각률은 잘 정제된 컨텍스트 조건에서 0.7~0.9% 수준까지 내려간다. 그런데 업계 평균은 9.2%에 머문다. 이 열 배 이상의 격차는 모델 능력의 차이가 아니라 컨텍스트 품질의 차이다. ETH Zurich가 AGENTS.md 파일 연구에서 확인한 것도 같은 결론이다. 동일한 모델에 프로젝트 전용 컨텍스트 파일을 주었을 때 정확도가 극적으로 올랐다. 모델은 그대로였다.
컨텍스트 실패의 세 가지 유형
AI 어시스턴트가 틀리는 원인을 분해하면 거의 항상 세 가지 중 하나다.
첫째, 누락(Missing Context). 라이브러리 문서 자체를 한 번도 본 적이 없어서 유사 패턴으로 API를 추측한다. 그럴듯하지만 존재하지 않는 메서드를 자신 있게 반환한다.
둘째, 부패(Stale Context). v3 기준으로 학습했는데 팀은 v6를 쓴다. 틀린 것을 아는 것이 아니라, 옛날 것이 맞다고 확신하는 상태다. 라이브러리가 모델 학습 주기보다 빠르게 업데이트되는 현실에서 이건 구조적 문제다.
셋째, 노이즈(Noisy Context). 200KB 문서를 통째로 컨텍스트 창에 던졌더니 정작 필요한 단락이 묻혀버린다. 컨텍스트 창이 커질수록 오히려 이 실패 유형이 심해진다. "더 큰 파이프"가 아니라 "더 깨끗한 파이프"가 필요한 이유다.
처방은 명확하다. 버전 고정된 문서를 로컬에서 10ms 이내로 조회할 수 있는 파이프라인을 만들어야 한다. 네트워크 레이턴시가 300ms를 넘어가면 에이전트는 "간단한 질문"에 대해 문서 조회를 생략하기 시작한다. 레이턴시가 행동을 바꾼다. 이 문제를 해결하는 접근이 @neuledge/context 같은 MCP 기반 문서 서버다. 로컬 SQLite DB에 버전별 패키지 문서를 사전 인덱싱해 두고, 어떤 에디터에서든 동일한 소스를 참조하게 만드는 구조다. 도구 자체보다 중요한 것은 이 설계 원칙이다. 버전 고정, 로컬 우선, 사전 인덱싱. 이 세 조건을 만족하는 것을 써야 한다.
세션이 비대해지면 어시스턴트가 기억을 잃는다
컨텍스트 품질만큼 팀이 간과하는 문제가 있다. 세션 자체의 비대화다. dev.to에 올라온 Claude Code 세션 최적화 사례를 보면, 4시간 코딩 세션 파일이 73MB에 달했다. 내용을 열어보면 실제 대화 텍스트는 4MB에 불과하다. 나머지 69MB는 이미 디스크에 존재하는 파일 Read 결과(28MB), 완료된 빌드 로그(9MB), 어제의 UI 스크린샷(22MB), 각종 diff 프리뷰(6MB)다. 이 상태로 --resume하면 Claude는 컨텍스트 창의 절반을 어제 로그를 읽는 데 써버리고 정작 오늘 나눈 얘기를 잊기 시작한다.
이 문제의 핵심은 LLM이 쓸 컨텍스트와 스토리지가 필요한 데이터를 구분하지 않는다는 것이다. 해결책은 요약이 아니라 필터링이다. 해당 프로젝트는 Claude Code Organizer에 세션 디스틸러를 구현했는데, 핵심 설계 결정이 흥미롭다. LLM을 거치지 않는 결정론적 규칙으로 도구 결과를 처리한다. Read 결과는 파일이 디스크에 있으니 전부 삭제, Bash 출력은 첫 5줄+마지막 5줄만 유지, 이미지는 [image redacted]로 치환. 대화 텍스트는 한 글자도 건드리지 않는다. 결과는 70MB → 7MB, 90% 감소. 컨텍스트 창에 올라가는 토큰도 15~20M에서 1~2M으로 줄어든다. LLM 요약을 쓰지 않은 이유가 설득력 있다. "AI가 요약하다가 내가 필요한 딱 그 디테일을 날려버리는" 리스크를 원천 차단한다.
MCP는 비싸다, 그리고 그래도 쓸 때가 있다
컨텍스트 파이프라인 이야기를 하면 MCP를 빠뜨릴 수 없다. 그런데 여기서 냉정한 수치를 직시해야 한다. velog에 올라온 실측 비교 데이터에 따르면, 동일한 작업을 MCP 방식으로 수행하면 CLI 대비 43배 많은 토큰을 쓴다. CLI가 94% 더 저렴하다. 이유는 구조적이다. MCP는 연결된 모든 도구 정의를 시스템 컨텍스트에 상시 올려둔다. 도구 22개를 연결하면 아무 작업도 시작하기 전에 전체 토큰의 8.1%가 소진된다. 여기에 MCP 서버 응답 자체도 텍스트로 컨텍스트에 쌓인다.
그렇다고 MCP를 무조건 피하라는 말이 아니다. 선택 기준이 명확하다. LLM이 이미 잘 아는 도구(git, AWS CLI, kubectl 등)는 CLI가 압도적으로 효율적이다. 학습 데이터에 수없이 등장한 도구들이라 별도 정의 없이도 정확하게 실행한다. 반면 사내 배포 도구, 팀 전용 스크립트, 최근에 출시된 신규 서비스 CLI는 LLM이 전혀 모른다. 이 경우 CLI를 줘도 자판기 비유처럼 동작하지 않는다. 명령어 자체를 모르기 때문이다. MCP로 도구 정의를 넘겨주는 방식이 오히려 적합하다. 팀 단위 권한 관리, 중앙 인증, 일괄 업데이트가 필요한 환경도 원격 MCP가 제값을 한다.
한 줄 판단 기준을 정리하면 이렇다. LLM이 이미 아는 도구 → CLI, 팀 단위 제어가 필요한 내부 도구 → 원격 MCP. 지금 MCP를 쓰고 있는데 응답이 느리고 불안정하다면, 첫 번째로 확인할 것은 불필요하게 연결된 MCP 서버 수다. 연결된 도구가 줄면 시스템 컨텍스트 점유가 줄고 체감 속도가 달라진다.
진단을 팀 워크플로우에 연결하는 법
세 기사가 공통으로 가리키는 것을 팀 리드 입장에서 정리하면 이렇다. AI 어시스턴트 성능 저하는 대부분 세 레이어에서 발생한다. 컨텍스트 품질(무엇을 주입하는가), 세션 관리(무엇을 들고 다니는가), 도구 선택(MCP vs CLI 비용 구조). 모델 버전은 이 세 가지를 정비한 다음에 논의해도 늦지 않다.
내일 팀에 당장 적용할 수 있는 것부터 꺼내면 세 가지다. 첫째, 현재 쓰는 라이브러리 버전을 명시한 컨텍스트 파일(AGENTS.md 또는 동등한 것)을 프로젝트 루트에 두어라. 둘째, 정기적으로 Claude Code 세션 파일 크기를 확인하라. 50MB를 넘기 시작하면 세션 디스틸러나 이미지 트리밍 같은 정리 루틴이 필요하다는 신호다. 셋째, MCP 서버 목록을 감사하라. 실제로 자주 쓰는 것만 남기고 나머지는 끊어라.
모델은 계속 좋아질 것이다. 하지만 컨텍스트를 정비하지 않으면 더 좋은 모델은 그냥 더 자신 있게 틀릴 뿐이다. 업그레이드하기 전에 현재 모델이 실패하는 이유를 먼저 진단하는 것, 그게 AI-First 팀이 모델 트레드밀에서 내려오는 유일한 방법이다.