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

이 편이 답하는 질문

11명 AI 에이전트에게 9개 아이템을 병렬 분해했을 때, 시간은 32% 단축(68분→46분)되었지만 토큰은 15% 증가(1,225K→1,409K). 이 트레이드오프가 ROI 관점에서 합리적인 범위는 어디이며, 병렬화 오버헤드가 이득을 역전시키는 임계점은?
신규 파일 생성(CI·테스트)은 품질 높았지만 크로스 모듈 리팩토링은 품질 낮았던 의존성 패턴이 발견되었을 때, PM이 태스크 분해 단계에서 사전 감지할 체크리스트는?
11명 중 3명 실패(순환 참조·한국어 IME 버그·중간 중단)가 “에이전트 한계”인지 “PM의 분배 실패”인지 구분하는 기준은 무엇이고, Sprint 4의 “Task Subagent 방식”을 언제부터 적용해야 하는가?
최종 1,552 테스트 전부 통과·롤백 0건이라는 결과가 “85% 자동화 + 15% 감독”으로 이뤄졌다면, 그 15% 감독이 구체적으로 어디에 집중되었고, 이 비율을 30%로 올렸을 때의 품질 향상 가능성을 어떻게 측정하는가?

이 시리즈를 읽는 세 개의 눈

PO: 멀티 에이전트 병렬화는 속도 게임이 아니라 태스크 분해 능력 게임이므로, 빠른 실행보다 정확한 분해에 PM 에너지를 집중해야 한다.
PM: 아이템당 50 LOC 미만이면 오케스트레이션 오버헤드가 이득을 잡아먹고, 파일 겹침이 있으면 순환 참조 리스크가 급증하므로, 이 두 조건을 팀 모드/솔로 모드 게이트로 명시해야 한다.
PL: 신규 파일 생성과 크로스 모듈 리팩토링의 품질 격차는 에이전트가 “함수 이동”은 능숙하지만 “이동 후 부작용 분석”은 약한 구조적 한계에서 비롯되므로, 이를 명시적으로 감시하는 테스트를 설계해야 한다.

1. AI 에이전트 11명에게 스프린트를 통째로 맡겨봤습니다
—
AI-SDLC / Agentic Coding 주제로 또 하나의 실험을 했습니다. 혼자 순차적으로 할 일을 병렬로 쪼개서, 각각의 AI에게 동시에 시켰습니다. 결과는 흥미로웠습니다. 되긴 됩니다. 근데 조건이 있습니다.

2. 70분, 에이전트 11명, 아이템 9개
—
프로젝트 파이프라인(모듈 54개, 테스트 1,426개)에 9가지 개선을 한꺼번에 적용하고 싶었습니다. CI 커버리지, 보안 스캐닝, 야간 E2E 테스트, 영문 가독성 지표, 챕터 간 일관성 검증, 대형 모듈 분할, 멀티에이전트 테스트 보강, HTML5 출력, 에디터 피드백 루프.

4개 스프린트로 나눠 병렬 실행했습니다. 혼자 하면 68분, 팀 모드로 돌리니 46분. 토큰은 15% 더 썼지만(1,225K→1,409K) 시간은 32% 줄었습니다. 시간당 처리량은 18K→30.6K tokens/분, 70% 증가. 산출물은 30개 파일, +4,339/-1,704 LOC, 테스트 126개 추가. 나는 코드를 한 줄도 치지 않았습니다.

3. 에이전트는 반드시 성공하는 것은 아니다.
—
11명 중 3명이 문제를 일으켰습니다. 한 명은 2,768줄짜리 모듈을 분할하다 순환 참조를 만들었습니다. 의존성 그래프를 분석하지 못한 거죠. 리더가 5분간 직접 수정해야 했습니다. 다른 한 명은 한국어 IME 버그로 tmux 명령에 "한글" 프리픽스가 붙어 실행 자체가 깨졌고, 또 한 명은 중간에 멈춰서 Task 에이전트로 전환해 재실행했습니다. (이는 claude 공식 bug report 했습니다.)

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

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

판단 기준은 단순합니다. 독립 아이템 3개 이상이면 팀 모드, 파일이 겹치면 단독 모드. 아이템당 50 LOC 미만이면 오케스트레이션 오버헤드가 이득을 잡아먹으니 단독 모드. 하나 더, tmux team 방식보다 Task subagent 방식이 오류가 적었습니다. Sprint 4가 Sprint 1-3보다 안정적이었습니다.

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