[AI 멀티 에이전트 개발 효과성 분석]

스프린트를 통째로 맡겨봤습니다 — 되긴 됩니다, 조건이 있습니다

AI 소프트웨어 개발 수명주기(AI-SDLC)·Agentic Coding 주제로 또 하나의 실험을 했습니다. 혼자 순차적으로 할 일을 병렬로 쪼개서, 각각의 AI에게 동시에 시켰습니다. 결과는 흥미로웠습니다. 되긴 됩니다. 근데 조건이 있습니다.

프로젝트 파이프라인(모듈 54개, 테스트 1,426개)에 9가지 개선을 한꺼번에 적용하고 싶었습니다.

혼자 68분, 팀 모드 46분 — 코드는 한 줄도 치지 않았습니다

4개 스프린트로 나눠 병렬 실행했습니다. 토큰은 15% 더 썼지만 시간은 32% 줄었습니다. 산출물은 파일 30개, +4,339/−1,704 LOC, 테스트 126개 추가. 저는 코드를 한 줄도 치지 않았습니다.

11명 중 3명은 실패했습니다 — 실패에는 패턴이 있었습니다

에이전트가 반드시 성공하는 것은 아닙니다. 11명 중 3명이 문제를 일으켰습니다. 한 명은 2,768줄짜리 모듈을 분할하다 순환 참조를 만들었습니다. 의존성 그래프를 분석하지 못한 것이죠. 리더가 5분간 직접 수정해야 했습니다.

흥미로운 패턴이 보였습니다. 신규 파일 생성(CI 설정, 테스트)은 품질이 높았고, 크로스-모듈 리팩토링은 품질이 낮았습니다. 최종 결과는 1,552개 테스트 전체 통과, 롤백 0건. 하지만 멀티 에이전트는 100% 자동화가 아닙니다. 85% 자동화 + 15% 감독. 시스템 사고는 여전히 사람 몫입니다.

“같은 파일을 건드리는가” — 질문 하나가 병렬화의 성패를 갈랐습니다

이번 실험에서 가장 크게 느낀 것은, 팀 모드에서 PM의 역할이 완전히 달라진다는 점이었습니다. “이 두 아이템이 같은 파일을 건드리는가?” — 이 질문 하나가 병렬화의 성패를 갈랐습니다. CI 설정 3종(독립 파일)은 에이전트 3명이 완벽하게 동시 처리했습니다. 반면 모듈 리팩토링(의존성 높음)은 에이전트가 만든 버그를 제가 직접 고쳐야 했습니다.

하나 더 있습니다. tmux team 방식보다 Task subagent 방식이 오류가 적었습니다. Sprint 4가 Sprint 1-3보다 안정적이었습니다.

코드를 잘 치는 것보다, 코드를 잘 나누는 것입니다

Agentic Coding에서 멀티 에이전트의 본질은 속도가 아닙니다. 태스크 분해 능력입니다. 즉 Architect/Domain/Spec 전문가가 일을 잘 쪼개면 32% 빨라집니다. 잘못 쪼개면 순환 참조를 디버깅하는 데 시간을 씁니다. 코드를 잘 나누는 것 — 그것이 AI 시대 PM의 핵심 역량이라는 것을, 이번 실험이 숫자로 증명했습니다.

시리즈 네트워크에서 이 편과 연결된 글

• A-1 · 실전 실험
  AI 코딩 에이전트 시대, 거버넌스 없이 괜찮을까?
• A-2 · 실전 실험
  AI가 코딩하고, AI가 관리한 1주일의 기록
• A-3 · 실전 실험
  AI-SDLC 도입, 그 첫 실험의 소회
• K-3 · 사고 체계
  Karpathy의 autoresearch: PM에서의 적용 사례
• K-5 · 사고 체계
  Karpathy LLM OS 시각으로 본 AX PM/PL 역량 — Claude Code 소스의 교차 분석
• P-0 · AI 인물 탐구
  7인의 사고 체계 종합 프레임워크