AI 코딩 에이전트를 팀에 배치하는 방법을 묻는 질문이 쏟아지고 있다. 그런데 실제로 운영해보면 금방 벽에 부딪힌다. 에이전트가 스택 컨벤션을 무시하거나, 두 에이전트가 같은 파일을 동시에 수정하다 충돌을 내거나, 어느 날 갑자기 도구가 생각했던 모델이 아닌 전혀 다른 모델로 구동되고 있다는 사실을 뒤늦게 알게 된다. 이 세 가지 문제는 사실 하나의 뿌리에서 나온다. 컨텍스트가 없고, 조율이 없고, 신뢰 근거가 없는 것이다.
1축: 컨텍스트 — AGENTS.md로 에이전트의 장기 기억을 설계하라
dev.to에 올라온 실전 사례 분석에 따르면, AGENTS.md 없이 AI 코딩 도구를 쓰는 팀은 잠재 역량의 20%만 쓰는 셈이다. Claude Code는 이 파일을 자동으로 읽고, Cursor도 이를 존중한다. GitHub Copilot과 Codex도 유사한 패턴을 채택하는 방향으로 움직이고 있다. 사실상 AI 코딩 에이전트의 표준 컨텍스트 주입 인터페이스가 되고 있는 것이다.
실전에서 검증된 AGENTS.md 패턴은 다섯 가지로 정리된다. 컨텍스트 피라미드는 스택, 컨벤션, 절대 하지 말 것을 한 번만 선언하면 모든 인터랙션에 적용된다. 태스크 라우터는 디렉토리별로 다른 AI 행동 규칙을 지정해, 에이전트가 어느 파일을 건드리느냐에 따라 자동으로 다른 패턴을 따르게 한다. 결정 로그(ADR)는 팀이 이미 검토하고 기각한 기술 선택지를 에이전트가 다시 제안하지 못하도록 막는다. 세이프티 넷은 rm -rf나 프로덕션 DB 직접 쓰기처럼 돌이킬 수 없는 명령에 명시적 허가 레이어를 붙인다. 마지막으로 리빙 독스는 현재 스프린트 컨텍스트, 최근 변경사항, 알려진 기술 부채를 주간 단위로 갱신해 에이전트가 프로젝트의 '지금'을 아는 상태로 유지한다.
테크 리드 입장에서 가장 중요한 패턴을 꼽으라면 결정 로그다. 에이전트는 '모범 사례'를 제안하는 경향이 있는데, 그 모범 사례가 팀이 이미 이유 있게 거부한 선택일 때가 많다. ADR 형식으로 왜 Prisma 대신 Drizzle을 쓰는지, 왜 REST 대신 tRPC를 쓰는지를 명시해두면, 에이전트는 그 결정에 역행하는 제안을 멈춘다. 프롬프트마다 설명하는 반복 비용이 사라진다.
2축: 조율 — 에이전트끼리 대화하지 않으면 사람이 라우터가 된다
멀티 에이전트 운영의 현실적인 한계는 명확하다. 각 Claude Code 인스턴스는 독립된 프로세스로 자기만의 컨텍스트 윈도우를 가진다. 백엔드를 리팩토링하는 에이전트와 프론트엔드를 수정하는 에이전트가 같은 코드베이스를 건드릴 때, 둘은 서로가 무엇을 하는지 전혀 모른다. 결과는 예측 가능하다. API 응답 포맷이 바뀐 걸 모른 채 구 포맷을 소비하는 코드가 생기고, 머지 충돌이 터지고, 이미 한 작업을 다시 하느라 토큰을 낭비한다. 그리고 사람이 탭을 오가며 컨텍스트를 복붙하는 인간 라우터 역할을 하게 된다.
이 문제를 해결하는 접근이 claude-peers-mcp다. MCP(Model Context Protocol) 서버를 로컬 메시지 버스로 활용해 Claude Code 인스턴스들이 서로 메시지를 주고받게 한다. 중앙 오케스트레이터 없이 에이전트 간 직접 통신이 가능하다. 데이터 레이어 에이전트가 인터페이스를 변경하면 API 라우트 에이전트에게 새 타입 시그니처를 알리고, API 에이전트는 그 메시지를 받아 핸들러를 수정하기 전에 변경사항을 반영한다.
단, 이 도구를 모든 상황에 쓸 필요는 없다. 도구 글쓴이도 솔직하게 인정한다. 격리된 피처 작업이나 순차적 태스크에선 단일 에이전트로 충분하다. 멀티 에이전트 조율이 필요한 시나리오는 명확하다. 여러 레이어를 동시에 건드리는 대형 리팩토링, 서로 의존하는 패키지를 병렬로 작업하는 모노레포 작업, 한 에이전트가 리뷰하고 다른 에이전트가 구현하는 분업 워크플로다. 에이전트가 많을수록 빠른 게 아니다. 조율 오버헤드가 있다. 잘 소통하는 두 에이전트가 서로 모르는 다섯 에이전트보다 낫다.
조율 이전에 구조 설계가 먼저다. 에이전트에게 명확한 소유 경계를 주는 것이 툴보다 더 중요하다. /src/api는 A 에이전트, /src/data는 B 에이전트. 공유 타입 정의 파일을 계약의 원본으로 삼고, 한 에이전트가 정의하면 다른 에이전트는 그것을 읽어 구현한다. 이건 AI 조언이 아니라 인간 팀에도 통하는 소프트웨어 엔지니어링 원칙이다.
3축: 신뢰 — 도구의 '두뇌'가 누구인지 알아야 한다
컨텍스트와 조율을 잘 설계했어도 무너질 수 있는 지점이 있다. 도구 자체의 신뢰도다. PANews의 보도에 따르면, Cursor가 3월에 출시한 Composer 2의 기반 모델이 중국 Moonshot AI의 오픈소스 모델 Kimi K2.5라는 사실이 커뮤니티에 의해 뒤늦게 밝혀졌다. API 반환값에 kimi-k2p5-rl-0317-s515-fast라는 모델 ID가 노출된 것을 개발자들이 포착한 것이다. Cursor 측은 이틀 후 공식 입장을 밝히며 "블로그에서 Kimi를 언급하지 않은 것은 실수"라고 인정했다.
이것이 Cursor의 첫 번째 불투명 사례도 아니다. Composer 1 출시 때도 DeepSeek 토크나이저 사용이 공식 채널이 아닌 커뮤니티에 의해 밝혀졌다. 기술적 선택 자체가 문제는 아니다. Kimi K2.5는 MoE 아키텍처로 코드 생성 성능이 뛰어나고, 오픈소스라 비용 효율도 높다. 코딩 에이전트 도구가 성능 좋은 외부 모델을 파인튜닝해 쓰는 건 합리적인 선택이다. 애플이 TSMC 칩을 쓴다고 아무도 속았다고 느끼지 않는 것처럼.
진짜 문제는 사용자가 그 사실을 알지 못했다는 것이다. 특히 Kimi K2.5의 수정된 MIT 라이선스는 월 매출 2천만 달러 이상의 서비스에 "Kimi K2.5" 표기를 UI에 명시할 것을 요구한다. Cursor의 연간 매출은 약 20억 달러로, 이 기준치의 약 8배다. 라이선스 컴플라이언스 문제가 명백히 존재한다. 더 근본적으로는, 금융·의료·공공 분야에서 규제를 받는 기업의 개발자가 모델 출처를 모른 채 코드를 처리하고 있다면, 규정 준수 팀은 자신들이 직면한 리스크를 전혀 파악하지 못하는 상황이 된다.
시사점: 3축을 갖추지 않은 에이전트 팀은 절반짜리다
AI-First 팀 리빌딩을 설계할 때 이 세 축은 독립적이지 않다. 컨텍스트 없는 에이전트는 매번 설명을 반복하게 만들고, 팀의 결정을 무시하는 코드를 생성한다. 조율 없는 멀티 에이전트는 개발자를 탭 전환 라우터로 만든다. 신뢰 근거 없는 도구는 어느 날 컴플라이언스 감사에서 조직의 발목을 잡는다.
소프트웨어 업계가 Log4j 사태 이후 SBOM(소프트웨어 구성 요소 명세서)을 표준으로 받아들인 것처럼, AI 도구에도 AI-BOM(AI Bill of Materials) 개념이 도입될 가능성이 높다. 기반 모델, 학습 데이터 출처, 파인튜닝 방법, 데이터 흐름을 명시한 목록이다. npm audit이 일상이 된 것처럼 model audit이 표준이 될 날이 온다. 이미 그 방향으로 논의가 시작됐다.
팀 리더 입장에서 내일 당장 할 수 있는 것은 명확하다. 첫째, AGENTS.md를 프로젝트에 추가하고 최소한 컨텍스트 피라미드와 세이프티 넷 패턴부터 적용한다. 둘째, 멀티 에이전트 운영을 고려하고 있다면 에이전트 간 경계와 계약을 먼저 설계하고, 필요할 때 MCP 기반 조율 레이어를 추가한다. 셋째, 팀이 쓰는 AI 코딩 도구의 기반 모델이 무엇인지 확인하고, 규제 산업에 있다면 법무·보안팀과 함께 모델 출처 리스크를 검토한다.
AI 에이전트는 점점 더 많은 코드, 데이터, 의사결정을 처리하게 된다. 그 에이전트의 두뇌가 실제로 누구인지, 팀원들끼리 어떻게 소통하는지, 그리고 어떤 맥락 위에서 작동하는지를 설계하지 않으면—아무리 좋은 도구를 써도 그 역량의 20%만 쓰는 팀에 머물게 된다.