모노레포에 Claude Code를 붙이고 나서 처음 한 행동은 루트에 AGENTS.md 하나를 두고 생각나는 모든 것을 밀어 넣는 거였다. 새 팀원에게 온보딩하듯, 많이 줄수록 더 잘 이해하겠지 싶었다. 결과는 예상과 달랐다. 같은 지시가 어떤 모듈에선 정확히 먹히고, 다른 모듈에선 조용히 무시됐다. 패턴을 찾을 수 없었고, 파일에 내용을 더할수록 오히려 나빠졌다.
dev.to에 올라온 한 엔지니어의 경험담이 그 이유를 명쾌하게 설명해줬다. Augment Code의 실증 연구에 따르면 프론티어 모델이 안정적으로 따를 수 있는 지시의 수는 약 150~200개다. Claude Code의 시스템 프롬프트만으로 이미 약 50개를 소진한다. 결정적인 건 이 한계를 넘는 순간 마지막 지시만 흐려지는 게 아니라, 모든 지시를 따르는 품질이 균등하게 저하된다는 점이다. 과부하된 AGENTS.md는 파일이 없는 것보다 더 나쁜 결과를 낳는다. 컨텍스트는 사다리가 아니라 예산이다.
해법은 계층화였다. 루트 AGENTS.md는 120줄을 상한으로 고정하고, 레포 레이아웃·공통 서브모듈 규칙·유니버설 런타임 컨벤션·포인터만 남겼다. 모듈별 맥락은 각 폴더 안의 AGENTS.md로 분산했다. "왜 이렇게 설계했는가"라는 설명은 전부 잘라냈다. 이유가 있으면 위키에 두고, 에이전트에게는 규칙만 준다. 아키텍처 설명이 길수록 에이전트는 "더 읽어야 할 게 있다"는 신호로 받아들여 불필요한 파일 탐색을 시작한다. 그리고 "하지 마라" 목록 옆엔 반드시 "대신 이걸 써라"를 병기했다. 금지어만 있으면 에이전트는 관련 코드를 다 뒤지고 나서야 멈춘다.
이 구조화 전략을 따라가다 보면 한 가지 불편한 패턴이 보인다. 에이전트의 컨텍스트 창은 정밀하게 관리하면서, 정작 나 자신의 컨텍스트 창은 방치하고 있다는 것. 또 다른 글이 이 역설을 날카롭게 짚는다. 저자는 한 주말 동안 에이전트로 깔끔한 PR 12개를 만들었지만, 3주가 지나도록 제품은 배포되지 않았다. 에이전트를 감싼 하네스는 동작했다. 개발자 자신을 감싼 하네스는 애초에 없었다.
2025년 METR의 실측 연구는 이 문제를 수치로 보여준다. 숙련 개발자들이 AI 도구를 쓸 때 오히려 19% 느려졌다. AI가 쉽고 보람 있는 부분을 처리해버리면, 남는 건 지루하고 힘든 부분뿐이다. 빌드가 빨라질수록 "거의 다 됐는데 멈춘" 레포의 무덤은 오히려 늘어난다. 병목이 사라진 게 아니라 한 층 위로 올라간 것이다.
그렇다면 개발자 자신을 위한 하네스는 무엇인가. 대시보드나 스트릭 카운터가 아니다. 그것들은 활동을 보여줄 뿐, 당신이 조용해질 때 아무것도 하지 않는다. 에이전트의 컨텍스트 엔지니어링이 "모델에게 무엇을 읽힐지 설계하는 것"이라면, 개발자의 하네스는 "내가 멈추는 지점을 미리 특정하고 그 지점에 트리거를 거는 것"이다. 스코프를 좁히고, 루프를 명시하고, 이탈을 감지할 외부 체크를 두는 것. 에이전트에게 자율 루프에 검증 없이 돌리지 않는 것처럼, 자신의 사이드 프로젝트에도 같은 원칙이 필요하다.
두 기사가 함께 가리키는 지점은 하나다. 컨텍스트 엔지니어링은 에이전트를 위한 기술이기 전에 나 자신을 위한 설계 습관이다. 무엇을 읽힐지, 무엇을 자를지, 어디서 루프를 닫을지—이 질문은 AGENTS.md를 짤 때와 내 주간 워크플로우를 짤 때 구조적으로 같다. 에이전트의 instruction budget을 의식하게 된 순간, 나의 attention budget도 유한하다는 사실을 직시하게 된다.
프로토타입을 빠르게 만들고 검증하고 고도화하는 흐름에서, 이제 진짜 속도 제한 요소는 모델 성능도 번들 크기도 아니다. 에이전트의 컨텍스트를 설계하는 것만큼 자신의 완료 루프를 설계하는 일에 같은 에너지를 쓰고 있는가—그게 2025년 에이전트 시대 프론트엔드 개발자에게 남은 진짜 질문이다.