Claude Code의 Dynamic Workflow가 공개되면서 숫자 하나가 업계를 조용히 흔들었다. Bun 런타임을 Zig에서 Rust로 포팅하는 데 걸린 시간, 11일. 75만 줄의 Rust 코드, 기존 테스트 스위트 99.8% 통과. 사람 팀이라면 몇 달은 잡았을 작업이다. 수백 개의 병렬 서브에이전트가 파일 단위로 분산 작업하고, 어드버서리얼 에이전트가 결과를 의도적으로 깨뜨리려 시도하며, 답이 수렴될 때까지 반복한다. 이건 단순히 빠른 AI가 아니다. 구조를 갖춘 에이전트 팀이다.
같은 시점, dev.to에서 한 개발자가 claude-dev-pipeline이라는 Claude Code 플러그인을 공개했다. 9개의 전문화된 AI 에이전트—Discovery, Exploration, PM, Architect, Backend, Frontend, QA, Reviewer, DevOps—가 피처 요청 하나를 받아 PRD 작성부터 CI/CD 배포 설정까지 처리하는 파이프라인이다. Backend와 Frontend는 병렬로 실행되고, Reviewer가 크리티컬 이슈를 3개 이상 발견하면 파이프라인이 멈춘다. 두 사례는 서로 다른 규모지만 같은 방향을 가리킨다. 에이전트는 이제 보조 도구가 아니라 팀 구조 그 자체로 작동하기 시작했다.
이 두 사례를 나란히 놓고 보면, 테크 리드에게 불편한 질문이 하나 떠오른다. 에이전트들이 PM, 아키텍트, QA, DevOps 역할을 수행한다면—테크 리드는 무엇을 설계해야 하는가?
답은 생각보다 구체적이다. claude-dev-pipeline 개발자가 "가장 어려웠던 건 에이전트 프롬프트를 쓰는 것이 아니라 핸드오프였다"고 고백한 지점이 힌트다. PM 에이전트의 출력이 Architect 에이전트가 파싱 가능한 구조여야 하고, Architect의 결정이 Backend와 Frontend가 서로 충돌 없이 구현할 만큼 구체적이어야 한다. 에이전트의 지능보다 에이전트 간 계약이 시스템의 품질을 결정한다.
핸드오프 스키마가 설계의 핵심이다. Dynamic Workflow가 자랑하는 자기 검증 루프—한 에이전트가 결과를 내면 다른 에이전트가 반박 시도—도 따지고 보면 구조화된 핸드오프 없이는 작동하지 않는다. 각 에이전트가 무엇을 받아 무엇을 내보내는지, 어떤 포맷으로 어떤 조건을 만족해야 다음 단계로 넘어가는지. 이걸 설계하는 사람이 테크 리드다.
claude-dev-pipeline이 .pipeline/*.md 파일을 에이전트 간 공유 메모리로 쓰는 방식은 영리하다. PM이 pm.md를 쓰고, Architect가 그것을 읽어 architect.md를 쓰고, Backend와 Frontend가 동일한 architect.md를 기반으로 병렬 구현한다. 아티팩트가 계약이 된다. 테크 리드가 설계해야 할 첫 번째 레이어는 이 아티팩트의 스키마다.
승인 게이트는 속도의 적이 아니라 품질의 레버다. 9에이전트 파이프라인에서 인간 개입 지점은 세 곳이다. PRD 검토, 아키텍처 옵션 선택, Reviewer 경보. 이 게이트들은 파이프라인을 늦추기 위한 게 아니라, 에이전트가 내린 결정을 인간이 이해하고 책임질 수 있는 구조를 만들기 위한 것이다. 프로덕션에서 뭔가 터졌을 때 "AI가 그렇게 짰어요"는 답이 아니다. "제가 이 아키텍처를 선택했습니다"가 답이어야 한다.
Dynamic Workflow가 처음 실행 시 사용자 확인을 요청하고, Enterprise 플랜에서 관리자가 별도 활성화해야 하는 것도 같은 맥락이다. 자율도가 높아질수록 승인 설계가 더 정교해져야 한다.
토큰 비용은 아키텍처 결정이다. Anthropic은 Dynamic Workflow 사용 시 "일반 세션 대비 토큰 소비가 대폭 증가한다"며 범위가 명확한 작업부터 시작하라고 권고한다. 수백 개 병렬 에이전트가 돌아가는 구조에서 비용은 선형이 아니다. 어떤 작업을 단일 에이전트로, 어떤 작업을 Dynamic Workflow로, 어떤 작업을 인간이 직접 처리할지—이 결정이 팀의 월 인프라 비용을 결정한다. 테크 리드의 설계 책임 중 하나가 ROI 경계를 긋는 일임을 잊지 말자.
두 사례가 함께 드러내는 전망은 뚜렷하다. 멀티 에이전트 시스템은 이미 실험 단계를 넘어 프로덕션 워크플로우 안으로 들어오고 있다. 11일에 75만 줄은 예외적 사례가 아니라 이 구조가 어디까지 갈 수 있는지를 보여주는 신호다.
하지만 에이전트가 팀을 대체하는 것과 테크 리드가 필요 없어지는 것은 전혀 다른 이야기다. 오히려 반대다. 에이전트가 늘어날수록 오케스트레이션 설계, 핸드오프 계약, 승인 게이트 위치, 비용-품질 트레이드오프—이 결정들의 무게는 더 무거워진다. 에이전트는 설계된 대로만 작동한다. 그 설계를 책임지는 사람이 테크 리드다.