에이전트 3명을 동시에 돌렸더니, 컨플릭트 지옥이 열렸다
"더 빠르게." 이 한마디가 모든 걸 바꿉니다. 기술 조사 30분, API 설계 15분, 백엔드 40분, 프론트엔드 40분, 테스트 20분 — 직렬로 돌리면 2시간 30분이 통째로 날아가는 구조. Claude Code의 Agent Teams 기능은 이 직렬 병목을 정면으로 돌파하려는 시도입니다. FE, BE, 테스트 에이전트를 동시에 스폰해서 병렬로 굴리는 거죠. Velog에 올라온 한 실전 아키텍처 공략 시리즈에서는 이걸 '군단 지휘'라고 표현하더군요. 그런데 1시간 후 벌어진 일은 군단이 아니라 내전이었습니다. 3개 에이전트가 전부 같은 API 타입 정의 파일을 수정하고 있었거든요.
여기서 핵심 교훈이 나옵니다. 팀을 만든다고 끝이 아니라, 의존성 그래프를 먼저 설계해야 한다는 것. 이건 사람 팀에서도 똑같은 원리인데, AI 에이전트 팀에서는 그 대가가 '토큰 비용'이라는 형태로 즉시 청구됩니다. 해당 아티클에 따르면 Agent Teams는 Teammate 수만큼 Claude 인스턴스가 뜨기 때문에 일반 세션 대비 토큰 소모가 3~7배에 달합니다. 공유 리소스(타입 정의, 공통 인터페이스)를 Team Lead 에이전트가 먼저 확정하고 배포한 뒤에야 FE/BE가 동시에 움직이는 구조 — 이게 병렬 개발의 전제 조건입니다. 실전 기준으로 3인 팀(Lead + 2)이 가장 가성비가 좋고, 5인 이상은 조정 비용이 급격히 올라간다는 점도 주목할 만합니다.
SPEC 프롬프트와 CLAUDE.md: 에이전트에게 '팀 규칙'을 심는 법
병렬 에이전트를 돌리든, 단일 세션을 쓰든, AI가 생성하는 코드의 품질은 결국 프롬프트의 구조와 컨텍스트 파일의 정밀도에 달려 있습니다. dev.to에 올라온 한 팀의 6개월 회고가 이걸 숫자로 증명합니다. AI 도입 초기에 생산성은 30% 올랐지만 버그도 20% 증가했고, PR 리뷰 시간은 두 배로 늘었다고요. 문제는 AI가 아니라 "사용자처럼 프롬프트를 던졌지, 엔지니어처럼 던지지 않았다"는 겁니다.
이 팀이 정립한 SPEC 프레임워크(Situation–Problem–Expectations–Constraints)는 Claude Code한테 물어볼 때 저도 바로 적용해봤는데, 체감이 확실합니다. 특히 Constraints(하지 말 것)를 명시하는 '네거티브 프롬프트'의 효과가 큽니다. "any 타입 쓰지 마", "동기식 bcrypt 쓰지 마", "에러를 조용히 삼키지 마" — AI 모델은 수백만 코드 예제 중 나쁜 관행도 학습하고 있으니, 금지 목록이 곧 품질 방어선인 셈이죠. 이 팀은 SPEC 도입 후 버그가 AI 도입 이전 대비 10% 감소하는 역전을 이뤄냈고, 순 생산성 향상은 약 35%로 안정화됐습니다.
같은 맥락에서, CLAUDE.md 파일의 역할도 재조명됩니다. @railway-ts라는 신규 라이브러리를 AI 도구와 함께 쓸 때의 사례가 인상적입니다. Claude Code에게 폼을 만들어달라고 하면, 학습 데이터에 압도적으로 많은 Zod+react-hook-form 패턴을 "자신 있게 잘못" 생성합니다. 이건 환각이 아니라 훈련 분포에서 가장 높은 확률의 답을 매칭한 것이니까요. 프로젝트 루트에 CLAUDE.md를 두고 "Zod 패턴 쓰지 마", "node_modules 안의 실제 문서를 읽어"라고 지시하면, AI는 훈련 데이터 대신 실제 라이브러리 API를 기반으로 추론하기 시작합니다. 팀 단위로 이 파일을 표준화하면, 모든 팀원의 AI 에이전트가 동일한 규칙으로 코드를 생성하게 됩니다. 이게 AI-First 팀의 진짜 온보딩입니다.
AI 비용은 '새로운 클라우드 비용'이다
병렬 에이전트, SPEC 프롬프트, CLAUDE.md까지 갖추면 속도와 품질은 올라갑니다. 하지만 한 가지가 빠져 있습니다. 비용 가시성. 50명 이상의 Cursor Enterprise 팀을 관리하는 한 엔지니어링 매니저는 이 문제를 이렇게 표현했습니다: "AI 비용이 새로운 클라우드 비용 문제가 됐는데, 이걸 위한 Datadog은 없다." 청구서가 날아와야 비용 스파이크를 알게 되는 구조라는 거죠.
이 매니저가 MCP 기반으로 만든 Cursor 플러그인 cursor-usage의 접근법이 흥미롭습니다. 자연어로 "지난 주 팀 비용 얼마?"라고 물으면 Enterprise API를 호출해서 답해주는 구조인데, 진짜 가치는 API 데이터의 함정을 사전에 인코딩해둔 데 있습니다. 예를 들어 totalLinesAdded에는 수동 편집, 탭 자동완성, 에이전트 생성 코드가 전부 섞여 있어서 AI 생산성 지표로 쓰면 안 됩니다. 한 개발자가 Sonnet에서 Opus로 모델만 바꿔도 일일 비용이 10배 뛸 수 있고요. "건강한 팀의 AI 코드 수용률은 40~70%"라는 벤치마크를 기준선으로 깔아두고, 모델별 비용과 교차 검증하는 구조가 팀 거버넌스의 출발점이 됩니다.
시사점: AI-First 팀의 운영 체계는 세 겹이다
이 세 소스를 관통하는 메시지는 명확합니다. AI-First 팀 운영은 도구 선택이 아니라 시스템 설계입니다.
- 첫째, 병렬화 이전에 의존성 설계. 에이전트를 늘린다고 속도가 비례하지 않습니다. 공유 리소스를 선확정하고, 의존성 그래프를 그린 뒤에야 병렬의 이점이 살아납니다.
- 둘째, 프롬프트와 컨텍스트의 팀 표준화. SPEC 프레임워크로 프롬프트 품질을 올리고,
CLAUDE.md로 프로젝트별 규칙을 AI에게 주입하면, 개인의 AI 활용 편차가 줄어듭니다. - 셋째, 비용 거버넌스의 내재화. 모델 선택 한 번이 비용을 10배 바꾸는 세계에서, 실시간 비용 추적과 이상 탐지는 선택이 아니라 필수입니다.
기존에 배포했던 'AI 코딩 도구, 쓰는 것에서 길들이는 것으로'에서는 개인 수준의 기준 수립을 다뤘다면, 이번 이야기의 핵심은 팀 단위 운영 체계입니다. 에이전트를 '동료'로 쓰려면, 동료에게도 조직도와 규칙과 예산이 필요합니다. 2026년 하반기, Agent Teams가 GA로 전환되고 비용 구조가 안정화되면, 이 세 겹의 운영 체계를 미리 갖춘 팀과 그렇지 못한 팀의 격차는 더 벌어질 겁니다.