3명짜리 팀이 같은 레포에 코딩 에이전트 10개 이상을 동시에 돌린다. 이미 현실이다. 문제는 속도가 아니라 조율이다. 에이전트 둘이 같은 파일을 동시에 수정하거나, 한쪽이 git stash를 날려 다른 에이전트의 작업을 통째로 날려버리는 일이 실제로 벌어진다. dev.to에 공개된 Shepherd 개발기는 이 문제를 정면으로 다룬다. 팀이 영역을 나눠 소통했음에도 에이전트는 경계를 지키지 않았다. 공유 헬퍼를 건드리고, 이미 누군가의 에이전트가 리팩터링 중인 모듈을 다른 방향으로 재작성했다. 충돌은 머지 타임에 터지고, 그때는 이미 한쪽 작업 한 시간을 버리는 게 가장 빠른 해결책이 된다.
이 팀이 도달한 핵심 인사이트는 날카롭다. "충돌은 모든 에이전트가 서로를 모른 채 코딩하기 때문에 생긴다." 머지 시점에 패치를 반복하는 건 증상 치료다. 근본 해결은 에이전트들이 서로의 작업을 실시간으로 인지하고 코드를 함께 맞춰가는 것이다. 그 결과물이 Shepherd다. MCP(Model Context Protocol)를 통해 Claude Code, Codex, Cursor 등 주요 AI 코딩 도구와 연결되고, 레포 특정 영역에 대한 리스/락 관리와 실시간 작업 현황 피드를 제공한다. 오픈소스(@korso/shepherd)로 셀프 호스팅이 가능하다. 팀은 충돌 해소 시간이 줄었을 뿐 아니라 에이전트들이 서로의 작업을 인식하고 코드를 작성하면서 코드 품질 자체가 올라갔다고 보고한다.
그런데 병렬 에이전트가 충돌 없이 빠르게 달린다고 해서 프로덕션이 빨라지는가? 여기서 두 번째 현실이 끼어든다. AI로 SaaS 프로토타입을 만든 경험을 공유한 또 다른 dev.to 글은 솔직하다. 프로토타입은 빨랐다. 프로덕션은 3개월이 걸렸다. "코드를 생성하는 것이 가장 어려운 부분이었던 적이 없다." 실제 시간을 잡아먹은 건 아키텍처 결정이었다. 어떤 필드 매칭을 AI에 맡기고 어떤 건 로컬 결정론적 로직으로 처리할 것인가, 어디까지 외부 API를 호출하고 어디서부터 프라이버시 리스크가 시작되는가. 이 판단들은 LLM이 내릴 수 없다. 비용 구조도, 사용자 신뢰 기준도, 6개월 뒤 유지보수 부담도 에이전트는 모른다.
두 사례를 팀 리드 관점에서 겹쳐 읽으면 패턴이 보인다. AI-First 팀의 병목은 이제 코드 생성 속도가 아니다. 병목은 두 곳에 있다. 첫째는 에이전트 간 조율—같은 레포에서 병렬로 달리는 에이전트들이 서로를 인식하지 못하면 속도가 빠를수록 충돌 비용도 커진다. 둘째는 아키텍처 판단—에이전트가 코드를 아무리 빠르게 뽑아도 "이 코드가 존재해야 하는가", "이 설계가 석 달 뒤에도 유효한가"를 결정하는 건 여전히 사람이다. Shepherd 같은 조율 레이어가 첫 번째 병목을 건드린다면, 두 번째 병목은 팀의 아키텍처 판단력을 워크플로우에 얼마나 명시적으로 녹이느냐에 달려 있다.
여기에 Anthropic의 Claude Cowork 'Record a skill' 기능을 더하면 그림이 더 선명해진다. 이코노미트리뷴이 보도한 대로, 사용자가 화면을 녹화하며 업무를 한 번 시연하면 Claude가 이를 재사용 가능한 스킬로 변환한다. OpenAI Codex의 'Record & Replay'도 같은 방향이다. 에이전트 자동화의 진입 장벽이 낮아지는 속도가 이미 팀이 흡수할 수 있는 속도를 위협하기 시작했다는 신호다. 도구는 준비됐는데 팀의 조율 구조와 판단 프로세스가 따라가지 못하면, 에이전트가 많아질수록 혼돈도 같이 커진다.
팀 리드로서 지금 당장 할 수 있는 설계는 세 가지다. 첫째, 병렬 에이전트 환경에 조율 레이어를 심는다. Shepherd/MCP처럼 에이전트가 서로의 작업 범위를 인식하게 하는 메커니즘—CLAUDE.md에 작업 영역 컨벤션을 명시하는 것도 시작점이 될 수 있다. 둘째, 에이전트에게 위임할 수 있는 결정과 반드시 사람이 내려야 하는 결정을 워크플로우 레벨에서 구분한다. 스캐폴딩과 반복 코드는 에이전트에게, 아키텍처 경계와 데이터 흐름 설계는 사람이 명시적으로 리뷰한다. 셋째, 자동화 스킬이 팀에 빠르게 쌓이는 만큼 그 스킬의 품질과 유효성을 주기적으로 감사하는 루틴을 만든다. 에이전트가 학습한 업무 패턴이 팀 기준과 맞는지 검증하는 책임은 여전히 팀 리드 몫이다.
프로토타입 속도는 이미 충분히 빠르다. 지금 팀이 풀어야 할 문제는 "AI를 더 빠르게 쓰는 법"이 아니라 "병렬로 달리는 에이전트들을 어떻게 하나의 제품으로 수렴시키는가"다. 조율 설계 없이 에이전트 수만 늘리는 팀은 속도가 빠른 혼돈을 경험하게 된다. 워크플로우 재설계가 AI-First 팀 리빌딩의 진짜 과제인 이유가 여기 있다.