AI 코딩 도구를 하나 더 도입할 때마다 팀은 뭔가 편해질 거라고 기대한다. 그런데 현장에서 일어나는 일은 다르다. 도구가 늘수록 누군가 직접 관리해야 할 것들이 같이 늘어난다. 설정 파일, 에이전트 지시문, 품질 기준, 역할 분담—이것들은 AI가 자동으로 정리해주지 않는다. 오히려 도구가 많아질수록 조용히 흐트러진다.
111개 파일, 19가지 다른 내용
dev.to에 올라온 글 하나가 이 문제를 숫자로 보여줬다. 개발자 한 명의 노트북을 스캔했더니 AGENTS.md 파일이 111개, CLAUDE.md가 38개 발견됐다. 그런데 고유한 내용은 각각 19개뿐이었다. 같은 내용을 담아야 할 파일들이 이미 19가지 버전으로 분기해 있다는 뜻이다. 팀 규모가 세 명만 넘어가도 이 숫자는 훨씬 나빠진다고 저자는 말한다.
어떻게 이렇게 됐을까. 경로는 세 가지다. 첫째, 손으로 복사하는 경우—마음에 드는 규칙을 다음 레포에 붙여넣고 나중에 한 곳만 수정하면 나머지는 조용히 틀려진다. 둘째, 장비 경계—글로벌 설정은 레포 밖 ~/.claude/CLAUDE.md나 ~/.gemini/GEMINI.md에 산다. 노트북 두 대 쓰면 두 버전이 생기고 "내 로컬에서는 되는데"가 나온다. 셋째, 제너레이터를 믿는 경우—AGENTS.md에서 자동 생성한 파일들은 누군가 생성 파일을 직접 수정하는 순간 드리프트가 시작된다. 디스크 어디에도 "이건 생성된 파일입니다"라고 표시된 곳이 없으니까.
문제는 도구마다 읽는 파일이 다르다는 데 있다. Claude Code는 CLAUDE.md, Codex CLI와 Copilot, Cursor, Windsurf는 각자 다른 경로와 파일 이름을 사용한다. AGENTS.md가 사실상 포맷 표준으로 수렴하고 있긴 하지만 예외 목록은 아직 존재한다. 팀이 도구를 여러 개 쓴다면 에이전트 지시문도 여러 벌 관리해야 한다는 현실은 그대로다. 저자가 공개한 agent-drift라는 오픈소스 스크립트는 이 파편화 정도를 수치로 보여주는 도구다. 고치진 않는다. 얼마나 나쁜지 보여줄 뿐이다. 하지만 숫자 없이는 프로세스 개선을 논의조차 할 수 없다는 게 핵심이다.
더 많은 도구, 더 높은 기대치
GeekNews에 소개된 Stripe Staff Engineer의 회고는 다른 각도에서 같은 문제를 건드린다. AI 도구가 좋아질수록 편해지는 게 아니라 기대치가 같이 올라간다는 것이다. Stripe에는 Developer Productivity 조직이 있어 최신 Anthropic, OpenAI 모델을 새 버전 출시 후 며칠 안에 파일럿으로 제공한다. 도구가 이미 주어진 상태에서 Staff Engineer가 성과를 못 내면 AI를 탓할 변명이 사라진다.
그래서 Staff 레벨에서 요구되는 새로운 능력은 병렬 에이전트 관리다. 직접 코드를 짜는 것보다 N개의 에이전트가 동시에 돌아가는 상태를 파악하고, 각각의 진행 상황을 추적하고, 결과물 품질을 검증하는 일이 진짜 과제가 됐다. 재미있는 건 Stripe조차 이 문제에 대한 표준 워크플로우가 없다고 인정한다는 점이다. 몇 가지 권장사항과 도구를 제공하고 각자 맞는 방식을 찾아가게 한다. 지금은 아무도 최선의 방법을 명확하게 모르는 시기다.
설계 공백이 만드는 역설
두 이야기를 겹치면 같은 역설이 보인다. AI 도구가 늘어날수록 사람이 직접 설계해야 할 구조가 줄어드는 게 아니라 오히려 늘어난다.
에이전트 지시문 파편화는 도구가 자동으로 해결해주지 않는다. 어느 시점에 누군가 레포지토리 간 지시문 동기화 정책을 설계해야 한다. 단일 소스 파일과 배포 파이프라인, 생성 파일 표시 규약, 드리프트 감지 자동화—이것들을 설계하지 않으면 도구 수가 늘수록 파편화 속도도 같이 빨라진다.
에이전트 병렬 운용도 마찬가지다. 여러 에이전트를 동시에 돌리겠다는 의도만으로는 부족하다. 각 에이전트에게 주는 컨텍스트 범위, 진행 상태 파악 방법, 품질 검증 체크포인트, 결과 병합 방식—이것들을 사전에 설계해두지 않으면 에이전트가 많아질수록 관리 오버헤드도 함께 커진다. 실행은 에이전트가 하더라도 조율 구조는 사람이 만들어야 한다.
팀 리드가 지금 당장 설계해야 할 것
실용적인 관점에서 정리하면 세 가지다.
첫째, 에이전트 지시문 단일 소스 정책. 팀에서 사용하는 AI 도구 목록을 먼저 확인하고, 각 도구가 읽는 파일 경로를 정리한다. agent-drift 같은 스캐너를 CI에 걸어 드리프트를 측정 가능한 숫자로 바꾸는 것부터 시작하자. 고치는 건 그다음이다. 숫자 없이 설득은 안 된다.
둘째, 에이전트 상태 가시화 구조. 에이전트를 몇 개 병렬로 돌리든 각 에이전트가 지금 무엇을 하는지, 어디까지 진행됐는지, 어떤 품질 기준으로 검증할지를 팀이 한 눈에 볼 수 있어야 한다. Stripe처럼 표준 워크플로우가 없더라도 최소한 팀 내 공유 기준은 있어야 한다.
셋째, 기대치 재보정. AI 도구 도입이 팀의 업무량을 줄여주지 않는다는 걸 명시적으로 인정하자. Stripe의 경험처럼 도구가 좋아지면 처리할 수 있는 일의 기준도 올라간다. "AI 덕분에 편해졌다"가 아니라 "AI 덕분에 더 많은 것을 설계해야 한다"가 현실에 가깝다.
도구는 계속 늘어날 것이다. 그리고 도구가 늘 때마다 팀이 직접 설계해야 할 구조도 같이 늘어난다. 이것을 미리 인정하고 설계하는 팀과, 도구가 알아서 해줄 거라고 기대하는 팀의 차이는 6개월 뒤에 코드베이스와 팀 워크플로우에서 고스란히 드러난다.