핵심 주장

  • AI 코딩 에이전트용 컨텍스트 파일(AGENTS.md)을 /init 명령으로 자동 생성하면, 에이전트 성능이 오히려 떨어지고 비용이 20% 이상 증가함
  • 에이전트가 스스로 발견할 수 있는 정보를 중복으로 제공하는 것이 문제의 핵심
  • AGENTS.md에는 에이전트가 코드를 읽어서는 알 수 없는 정보만 넣어야 함

연구 결과: AGENTS.md는 도움이 되나, 해가 되나

  • Lulla et al. (ICSE JAWs 2026): GitHub PR 124개를 대상으로 AGENTS.md 유무만 바꿔 비교하는 페어드 실험
    • AGENTS.md가 있을 때 실행 시간 28.64% 감소, 출력 토큰 16.58% 감소
    • 이 연구에서 사용된 파일은 개발자가 실제로 유지보수하던 것으로, 프로젝트 고유의 지식이 담겨 있었음
  • ETH Zurich 연구: 4개 에이전트를 SWE-bench 등에서 테스트하되, LLM 자동 생성 파일과 개발자 작성 파일을 구분
    • LLM이 자동 생성한 컨텍스트: 작업 성공률 2~3% 하락, 비용 20%+ 증가
      • README 등 기존 문서를 전부 제거한 환경에서는 LLM 생성 파일이 오히려 성능을 2.7% 끌어올림
    • 개발자가 직접 작성한 파일: 성공률 약 4% 향상, 비용 최대 19% 증가
  • 결론: 자동 생성 내용이 나쁜 게 아니라 중복이 문제임
    • 같은 정보를 두 번 주면 노이즈만 추가되고, 개발자가 작성한 발견 불가능한 지식만이 실질적 도움이 됨

왜 자동 생성이 해로운가

  • 자동 생성된 AGENTS.md는 대부분 에이전트가 이미 스스로 발견하는 정보를 포함함
    • 코드베이스 개요 (Sonnet 4.5 출력의 100%, GPT-5.2 출력의 99%가 이를 포함)
    • 디렉토리 구조, 기술 스택, 모듈 설명
  • 이미 알고 있는 정보를 다시 제공하면 토큰만 소비하고 가치가 없음
  • 앵커링 효과: 레거시 패턴을 언급하면, 더 좋은 대안이 있어도 에이전트가 그 패턴에 고착됨
    • "Lost in the Middle" 연구(Liu et al., 2024)와 일치 — 긴 컨텍스트는 주의력을 분산시켜 성능을 떨어뜨림

AGENTS.md에 넣어야 할 것 vs 넣지 말아야 할 것

  • 넣어야 할 것 (에이전트가 발견 불가능한 정보)
    • 도구 지정: "uv를 패키지 관리에 사용할 것"
    • 비직관적 규칙: "테스트는 반드시 --no-cache로 실행, 안 하면 fixture가 false positive 발생"
    • 시스템 제약: "auth 모듈은 커스텀 미들웨어 사용 중, 표준 Express로 리팩토링 금지"
    • 도구가 문서에 언급되면 에이전트가 작업당 1.6~2.5회 사용하지만, 미문서화 시 0.05회 미만으로 급감함
  • 넣지 말아야 할 것 (에이전트가 스스로 발견 가능)
    • 디렉토리 구조, 모노레포 레이아웃
    • 기술 스택 개요, 표준 아키텍처 패턴

정적 파일의 구조적 한계

  • 잘 작성된 AGENTS.md라도 근본적 약점이 있음 — 파일은 정적인데 작업은 동적
  • 단일 파일의 지시는 작업 유형에 따라 조건 분기할 수 없음
    • 문서 수정 작업에도 "커밋 전 전체 테스트 실행" 지시가 적용되어 토큰과 시간이 낭비됨
    • CSS 리팩토링에 DB 마이그레이션 경고가 로드되고, 보안 수정에 성능 최적화 힌트가 딸려옴
  • ACE 프레임워크(ICLR 2026): 정적 파일 대신 generator/reflector/curator 파이프라인으로 컨텍스트를 동적으로 진화시키는 Agentic Context Engineering 접근법이 정적 방법 대비 12.3% 높은 성능을 기록함

더 나은 구조, 아직 만들어지지 않은

  • AGENTS.md와 관련하여 여러 사람이 독립적으로 같은 결론에 도달함
    • 단일 파일이 아니라 라우팅 계층 + 필요 시 로드되는 집중 컨텍스트가 올바른 구조임
  • Layer 1 - 프로토콜 파일: 코드베이스 개요나 스타일 가이드가 아닌 라우팅 문서
    • 사용 가능한 페르소나와 호출 조건, 스킬과 담당 작업 유형, MCP 연결과 용도를 정의
    • 에이전트가 발견할 수 없는 최소한의 레포 사실만 포함하고 그 외에는 아무것도 넣지 않음
  • Layer 2 - 페르소나/스킬 파일: 작업 유형에 따라 선택적으로 로드됨
    • UX 에이전트와 백엔드 에이전트가 서로 다른 컨텍스트를 로드하고, 상대방의 컨텍스트는 로드하지 않음
  • Layer 3 - 유지보수 서브에이전트: 프로토콜 파일의 정확성을 유지하는 전담 에이전트
    • 문서는 부패함 — ETH Zurich 연구도 갓 생성된 파일로 테스트했는데도 성능 하락이 나타남
    • 6개월간 방치된 AGENTS.md가 이미 교체된 의존성이나 변경된 디렉토리 구조를 기술하고 있다면 훨씬 심각함
  • 현재 주요 코딩 에이전트 중 이 아키텍처를 쉽게 구현할 라이프사이클 훅을 제공하는 것은 없음 — 서브에이전트와 스코프드 컨텍스트로 근사할 수는 있지만, 아직 채워지지 않은 도구 공백임

자동 최적화

  • Arize AI는 CLAUDE.md 지시문을 수동으로 작성하는 대신 자동 최적화 루프를 사용함
    • 에이전트를 학습용 작업에 실행 → 결과 평가 → 실패 원인에 대한 LLM 피드백 생성 → 메타프롬프팅으로 지시문 개선 → 반복
    • cross-repo 테스트에서 +5.19%, in-repo 테스트에서 +10.87% 정확도 향상
  • 옵티마이저가 밝힌 불편한 사실: 사람이 코드베이스를 이해하는 데 도움이 되는 것과 LLM이 탐색에 필요한 것은 다름
    • "이 서비스는 repository 패턴 사용" 같은 정보는 개발자에게 당연히 유용해 보이지만 모델에게는 노이즈일 수 있음
    • 반대로 모델이 실제로 필요한 것(특정 import 경로 구분, 비직관적 파일 명명 규칙 등)은 개발자가 내재화해서 적을 생각조차 못 함
  • AGENTS.md 수동 작성은 개발자가 에이전트에게 필요한 것을 안다고 가정
    • 경험적 증거는 아마 모른다고 시사함
    • 옵티마이저는 "중요하다고 생각하는 것"과 "실제로 결과를 바꾸는 것" 사이의 차이를 찾아냄
  • 그렇다고 작성을 포기하라는 뜻은 아님 — 5%는 의미 있지만 변혁적이지는 않음. 직관을 느슨하게 잡고 실제로 테스트하라는 뜻

AGENTS.md를 바라보는 올바른 마인드셋

  • AGENTS.md를 아직 고치지 못한 과정의 기록으로 볼 것
  • 추가하는 모든 줄은 코드베이스에서 AI 에이전트를 혼란시킬 만큼 불명확한 부분이 있다는 신호이며, 이는 새로운 인간 기여자도 마찬가지로 헤맬 가능성이 높음
  • 올바른 대응은 컨텍스트 파일을 키우는 것이 아니라 근본 원인을 수정하는 것
    • 에이전트가 유틸리티를 엉뚱한 디렉토리에 넣음 → 디렉토리 구조 자체가 혼란스러운 것이므로 재편할 것
    • 에이전트가 폐기된 의존성을 계속 사용함 → import 구조가 잘못된 것을 너무 쉽게 잡게 만드는 것이므로 수정할 것
    • 에이전트가 타입 검사를 빠뜨림 → 지시에 의존하지 말고 빌드 파이프라인에서 자동으로 잡을 것
  • AGENTS.md는 영구 설정이 아니라 진단 도구임 — 줄을 추가하고, 에이전트가 왜 이 실수를 반복하는지 조사하고, 근본 원인을 고친 뒤, 그 줄을 삭제함
  • 시도해볼 기법: AGENTS.md를 거의 비운 채 시작하고 "이 프로젝트에서 놀랍거나 혼란스러운 것을 발견하면 코멘트로 남겨라"는 지시 하나만 넣을 것. 에이전트가 제안하는 추가 사항 대부분은 영구 보관할 것이 아니라 코드베이스가 불명확한 지점의 표지

실용적 권장사항

  • /init 실행을 중단할 것 — 레포에 문서가 아예 없는 경우가 아니라면 자동 생성 결과물은 기존 문서와 중복됨
  • AGENTS.md에 한 줄을 추가하기 전에 "에이전트가 코드를 읽으면 알 수 있는가?" 자문할 것. 그렇다면 적지 말 것
  • 에이전트가 반복적으로 실패할 때 컨텍스트 파일을 키우기 전에 코드베이스 자체를 먼저 수정할 것
    • 코드 구조를 개선하고, 린터 규칙을 추가하고, 테스트 커버리지를 확대한 뒤 — 그래도 안 될 때만 AGENTS.md에 손을 댈 것
  • CI/CD나 자동 리뷰 파이프라인에서 에이전트를 대규모로 운용한다면, 15~20% 비용 오버헤드가 수천 회 실행에 걸쳐 복리로 누적됨을 인식할 것
  • 에이전트를 신입 사원처럼 온보딩하려는 본능(사무실 투어, 조직도, 아키텍처 설명)은 자연스럽지만, 코딩 에이전트는 신입이 아님 — 프롬프트를 다 입력하기도 전에 코드베이스 전체를 grep할 수 있음. 에이전트에게 필요한 건 지도가 아니라 지뢰의 위치