어느 날 Claude Code가 갑자기 지시를 따르지 않기 시작했다면, 먼저 의심해야 할 건 모델 업데이트가 아니다. 모델은 바뀌지 않았다. 바뀐 건 모델이 읽어야 하는 컨텍스트 창 안의 내용물이다. dev.to에 올라온 세 편의 실전 경험담이 같은 지점을 각자 다른 방향에서 정확히 짚고 있다.
첫 번째: 에이전트는 잘못이 없다, 리뷰를 안 한 당신이 문제다
HandyFEM 프로젝트를 Claude Code로 스캐폴딩하던 개발자가 포착한 장면이 인상적이다. 에이전트가 기존 CLAUDE.md를 보호하기 위해 Next.js 생성기가 만든 파일을 조용히 폐기했다. 행동 자체는 합리적이었다. 문제는 그 파일 안에 "이 버전은 당신이 학습한 Next.js가 아니다, 코드 쓰기 전에 반드시 내부 docs를 읽어라"는 중요한 경고가 들어 있었다는 것이다. 에이전트가 한 줄짜리 사이드 노트로 넘어간 그 문장을 개발자가 놓쳤다면, 이후 생성되는 모든 프레임워크 코드는 구버전 패턴으로 자신있게 틀리게 된다.
이 케이스가 전하는 메시지는 단순하다. "AI가 나쁜 코드를 썼으니까 리뷰한다"가 아니라 "AI가 충분히 좋기 때문에 내가 멈추지 않아서 리뷰를 놓친다"는 역설이다. 에이전트의 출력은 능력 있는 주니어 개발자의 PR처럼 다뤄야 한다. 무엇을 추가했는가보다 무엇을 제거했는가를 먼저 질문하는 습관이 필요하다.
두 번째: 컨텍스트 창이 클수록 썩기 쉽다
"지시를 200줄 써넣었더니 오히려 더 안 따른다"는 경험을 한 팀이라면, 이건 버그가 아니라 구조다. LLM은 시스템 룰, CLAUDE.md, 코드, 실제 요청을 하나의 평탄한 토큰 스트림으로 읽는다. 우선순위 계층이 없다. 연구에서 "double the instructions, halve the compliance"라는 표현이 나오는 이유가 여기 있다. 지시가 컨텍스트 중간에 파묻히면 모델의 어텐션은 정확히 그 지점에서 처진다.
dev.to의 한 개발자는 더 극단적인 사례를 공개했다. 100만 토큰 컨텍스트 창으로 이전한 뒤 오히려 에이전트 품질이 나빠졌다. 원인을 파고들었더니 세션 시작 전부터 이미 약 38,000토큰짜리 고정 스캐폴딩이 로드되고 있었다. 60KB짜리 메모리 인덱스, 33KB짜리 CLAUDE.md, 200개 스킬 설명, 180개 MCP 툴 이름. 모델은 실제 작업에 집중하기 전에 이미 자기 가구 목록을 읽느라 어텐션 예산을 소진하고 있었다.
가장 충격적인 발견은 따로 있었다. 수개월 전 설치한 메모리 플러그인이 죽어 있었는데, 그 플러그인이 활성 시절 생성한 CLAUDE.md 파일이 개발 트리 전역에 4,648개 남아 있었다. 각 파일에는 "최근 활동: 없음"이라는 자동 생성 블록이 들어 있었다. 에이전트는 3개월째 죽은 시스템의 조각들을 읽으며 세션마다 "이 개발자는 아무것도 한 게 없다"는 정보를 주입받고 있었던 셈이다. 죽은 도구가 여전히 컨텍스트를 소비하고 있었다. 이게 컨텍스트 로트다.
진단 체크리스트는 간단하다. 매 턴마다 로드되는 파일의 토큰 합계를 계산해보라. 수만 토큰이 넘는다면 실제 지시는 건초더미 안에 있다. 설치한 적 있는 플러그인, 훅, MCP 서버 목록을 점검하고 지금도 실제로 실행 중인지 확인하라. 그리고 규칙은 프롬프트가 아니라 코드로 강제하라. CLAUDE.md 안의 규칙은 모델이 합리화해서 우회할 수 있는 요청이다. PreToolUse 훅은 모델의 판단과 무관하게 실행되는 법이다.
세 번째: 메모리는 구조 없이 쌓으면 짐이 된다
컨텍스트 로트의 반대편 문제도 있다. 매 세션마다 아키텍처를 다시 설명하고, 배포 구조를 다시 가르치고, 지난번에 실패한 접근을 또 시도하는 반복이다. 흔한 해결책들—README를 세션마다 붙여넣기, 끝없이 늘어나는 플랫 마크다운 파일—은 로트를 만들거나 토큰을 낭비한다.
Project Brain은 이 문제를 구조적으로 접근한다. 핵심 아이디어는 단순하다. 경량 인덱스 파일(.project-brain/index.md)이 전체 지도 역할을 하고, 실제 세부 정보는 프로젝트·토픽별 파일로 분리되어 필요할 때만 로드된다. 상태 추적(✅ verified / ✗ failed / ⚠ in-progress)이 포함되어 있어 모델이 이미 실패한 접근을 다시 시도하는 상황을 줄인다. 현재 상태가 아니라 왜 그렇게 결정했는지의 히스토리까지 보존하는 것이 핵심 설계 원칙이다.
중요한 것은 이 구조가 기술적 혁신이 아니라는 점이다. 벡터 DB에 모든 것을 쏟아붓는 방식이 아니라, 인간 엔지니어가 실제로 시스템을 생각하는 방식—전체 지도 먼저, 필요할 때 드릴다운, 결정 이유 보존—을 그대로 모방한 구조다. 거창한 RAG 파이프라인이 아닌 평범한 마크다운 파일로 구현된다는 것도 현실적인 장점이다.
팀 리드로서 정리하는 진단 프레임
세 편의 사례를 하나로 모으면 에이전트가 망가지는 패턴은 세 가지로 수렴한다. 리뷰 없는 신뢰(에이전트 출력을 검토하지 않아 조용히 사라진 컨텍스트를 놓침), 컨텍스트 로트(죽은 도구와 과적된 스캐폴딩이 어텐션을 소진), 메모리 부재(세션마다 제로에서 시작하거나, 반대로 구조 없이 쌓다가 무너짐).
모델은 바뀌지 않았다. 팀이 만든 환경이 모델이 작동하는 조건을 바꾼 것이다. 에이전트를 고치는 가장 빠른 방법은 모델 버전을 바꾸는 게 아니라 컨텍스트 창을 청소하고, 죽은 훅을 제거하고, 리뷰 루틴을 팀 워크플로우에 박아두는 것이다.
앞으로 달라질 것과 달라지지 않을 것
컨텍스트 창은 계속 커질 것이다. 하지만 창이 커질수록 규율 없이 쌓이는 쓰레기도 함께 커진다는 것이 이번 사례들의 공통된 교훈이다. 모델 자체의 컨텍스트 관리 능력이 개선되더라도, 팀이 무엇을 주입하고 무엇을 제거할지 의식적으로 설계하지 않으면 에이전트의 품질은 팀의 컨텍스트 위생 수준을 절대 초과하지 못한다.
에이전트는 여전히 코드를 쓴다. 엔지니어의 역할이 바뀌는 게 아니라, 판단과 리뷰의 밀도가 높아진다. 타이핑이 싸진 만큼, 판단은 더 비싸진다.