코딩 에이전트, 모델보다 설정이 성패를 가른다

코딩 에이전트, 모델보다 설정이 성패를 가른다

AGENTS.md 과잉 설정이 성능을 갉아먹는다—ETH 취리히 연구와 실전 사례로 보는 AI 에이전트 아키텍처의 진짜 병목

AGENTS.md 컨텍스트 엔지니어링 코딩 에이전트 Claude Code AI 에이전트 아키텍처 자동 생성 세금 에이전트 설정 AI-First 워크플로우
광고

"어떤 모델 써요?" 코딩 에이전트 도입을 고민하는 팀에서 가장 많이 듣는 질문입니다. GPT-5.2냐, Claude Sonnet이냐, Qwen이냐. 근데 솔직히 말하면, 이건 잘못된 질문이에요. 제가 Claude Code 기반으로 팀 워크플로우를 세팅하면서 절실히 느낀 건데—에이전트가 망가지는 이유의 대부분은 모델이 아니라 설정에 있습니다.

이걸 수치로 증명한 연구가 나왔습니다. 스위스 ETH 취리히 연구진이 최근 발표한 논문 'Evaluating AGENTS.md'는 꽤 충격적인 결과를 담고 있어요. 많은 팀이 코딩 에이전트 성능을 높이려고 공들여 작성하는 AGENTS.md 같은 저장소 수준 컨텍스트 파일이, 오히려 작업 성공률을 3~4% 떨어뜨리고 비용은 20% 이상 올린다는 겁니다. AI가 자동 생성한 컨텍스트 파일을 제공했을 때는 성공률이 약 3% 하락했고, 사람이 직접 작성한 파일도 평균 4% 개선에 그쳤습니다. 연구진은 이 현상을 '자동 생성 세금(Auto-Generated Tax)'이라고 표현했는데, 표현이 정확합니다. 도움을 주려고 만든 파일이 세금처럼 성능과 비용을 갉아먹는 거니까요.

왜 이런 일이 벌어질까요? 핵심은 에이전트가 지시를 너무 잘 따른다는 데 있습니다. AGENTS.md에 폴더 구조 설명을 적어두면 에이전트는 그걸 다 읽으려 합니다. 그런데 에이전트는 이미 파일을 직접 탐색해서 구조를 파악할 수 있어요. 이미 스스로 할 수 있는 일을 텍스트로 읽게 강요하면, 토큰과 연산 자원만 낭비됩니다. 강력한 모델일수록 이 문제가 더 두드러지는데, GPT-5.2처럼 이미 라이브러리와 코드 패턴에 대한 충분한 내재 지식을 가진 모델에게 일반적인 정보를 추가 제공하면 그게 오히려 '노이즈'가 됩니다.

이 관점에서 dev.to에 올라온 실전 사례가 눈에 띕니다. Claude 기반 에이전트를 오랫동안 운영해온 한 개발자는 "모델은 거의 병목이 된 적이 없다. 거의 모든 실패는 아키텍처 문제였다"고 단언합니다. APEX-Agents 벤치마크 기준 pass@1이 24%에 불과한데, 그 실패의 대부분이 모델 추론 한계가 아니라 오케스트레이션 레이어에서 발생한다는 데이터도 공유했어요. Vercel의 사례는 더 극적입니다. 15개 도구를 쓰던 에이전트의 정확도가 80%였는데, 도구를 2개로 줄이자 100%로 올랐습니다. 모델 교체 없이, 도구 정리만으로요.

"이거 Claude한테 물어보니까..." 식의 단순 프롬프팅을 넘어서 팀 차원의 AI-First 워크플로우를 설계할 때, 이 연구들이 주는 시사점은 명확합니다. 컨텍스트 엔지니어링의 핵심은 정보를 많이 넣는 것이 아니라, 불필요한 것을 줄이는 것입니다. ETH 취리히 연구진이 제시한 실용적인 가이드라인을 정리하면 이렇습니다.

AGENTS.md에 꼭 넣어야 할 것: - 프로젝트의 설계 의도와 아키텍처 선택 이유 (모노레포 구조인지, 왜 그 아키텍처를 선택했는지) - 비표준 도구 사용 방식 — 예를 들어 pip 대신 uv, npm 대신 bun을 쓴다는 것. 연구 결과에 따르면 uv를 명시했을 때 사용 빈도가 160배 증가했습니다. 에이전트가 지침을 충실히 따른다는 걸 역으로 활용해야 해요.

빼야 할 것: - 상세한 폴더 구조 설명 (에이전트가 직접 탐색 가능) - 코딩 스타일 가이드 (camelCase 같은 건 린터에 맡기세요) - 일부 케이스에만 해당하는 범용적이지 않은 규칙 - AI가 자동 생성한 내용을 그대로 붙여넣은 것

구조적으로: - 300줄 이하, 이상적으로는 60줄 이하 유지 - 핵심만 루트 파일에, 세부 내용은 링크로 연결 - 코드 예시 직접 복사 대신 file:line 형태로 참조

비슷한 맥락에서 흥미로운 경험담도 있었습니다. 한 시니어 개발자가 AI에게 의존성 취약점 패치를 맡겼더니 20개 파일을 수정하고 의존성 6~8개를 새로 추가했다고 해요. 기술적으로는 맞는 결과였지만, 경험에서 우러난 판단—부모 의존성 하나만 올리면 대부분 해결된다—은 AI가 제안하지 못했습니다. 결국 AI 변경사항을 전부 버리고 직접 처리했고, 훨씬 깔끔하게 마무리됐죠. 이 이야기가 중요한 이유는 AGENTS.md 설계와 맞닿아 있기 때문입니다. 에이전트가 스스로 판단해야 하는 영역을 텍스트 지침으로 과도하게 통제하면, 오히려 더 나쁜 결과를 냅니다.

팀에 AI-First 문화를 정착시키려는 입장에서 이 연구들이 주는 교훈은 하나로 수렴합니다. "AI는 설정한 대로 움직인다. 그러니 설정을 제대로 해야 한다." AGENTS.md를 처음 작성하거나 리팩토링하는 팀이라면 지금 당장 파일 줄 수를 세어보세요. 300줄이 넘는다면, 그 초과분은 성능이 아니라 비용으로 전환되고 있을 가능성이 높습니다. 모델 업그레이드를 논의하기 전에 컨텍스트 파일부터 다이어트시키는 것—이게 지금 팀에 가장 빠른 ROI를 주는 AI 최적화일 수 있습니다.

앞으로의 방향도 분명합니다. 에이전트 성능 경쟁이 모델 파라미터가 아니라 아키텍처 설계 역량으로 이동하고 있어요. 도구 설명을 얼마나 정밀하게 쓰는지, 상태 관리를 어떻게 구조화하는지, 에러를 모델이 해석할 수 있는 형태로 어떻게 가공하는지—이런 '에이전트 스캐폴딩' 역량이 팀의 AI 생산성을 가르는 핵심 변수가 됩니다. "AI가 생성해준 걸 기반으로 우리가 다듬으면 된다"는 접근은 맞지만, 다듬는 방향이 컨텍스트 축소와 구조 명확화여야 한다는 걸 이번 연구들이 다시 한번 확인시켜 줍니다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요