에이전트 하나한테 다 안 시킵니다. 13개로 쪼갠 이유

오늘 사내 랜딩 레포를 정리하다가 .claude/agents/ 폴더를 다시 열었다. 전문 에이전트 13개가 들어 있다. 최근 에이전트 도입 조사를 보면 프로덕션에 올라간 배포 중 22%가 에이전트 세 개 이상을 묶어서 돌린다. 1년 전만 해도 "에이전트 하나가 알아서 다 한다"가 그림이었다. 지금은 역할을 나눠 협력시키는 쪽으로 옮겨가고 있다.

왜 하나로 안 하나

처음엔 통짜 에이전트 하나한테 "이 섹션 만들어"라고 시켰다. 결과가 어정쩡했다. 구조도 보고 디자인도 보고 보안도 보려니 어느 하나 깊지 않았다. 사람으로 치면 기획·디자인·개발·QA를 한 명이 동시에 하는 꼴이다.

그래서 쪼갰다. architect는 컴포넌트 구조와 폴더만 본다. design-system은 shadcn/ui 토큰과 스타일만 본다. security-auditor는 입력 검증과 취약점만 본다. 각 에이전트 파일에 model도 따로 박아뒀다. 무거운 판단이 필요한 architect와 code-reviewer는 opus, 반복이 많은 design-system이나 test-engineer는 sonnet이다. 전부 opus로 돌리면 비용이 의미 없이 샌다.

순서가 정해져 있다

CLAUDE.md에 체이닝 규칙을 박아뒀다. 새 기능을 만들 때는 architect가 구조를 먼저 잡는다. 그다음 design-system이 UI를 입히고 responsive-architect가 반응형을 본다. security-auditor가 검증하면 마지막에 performance-optimizer가 성능을 본다. 폼 작업이면 순서가 또 다르다. 입력 검증이 먼저라 security-auditor가 앞으로 온다.

이게 22%라는 숫자가 말하는 멀티 에이전트 오케스트레이션의 실제 모습이다. 거창한 게 아니라 "누가 무엇을 먼저 보는가"를 정해둔 것뿐이다.

솔직한 한계

에이전트가 많다고 좋은 게 아니다. 13개가 매번 다 도는 것도 아니다. 작은 수정은 한두 개만 부른다. 오히려 사소한 작업에 오케스트레이션을 끼우면 통짜 한 번이 더 빠르다. 에이전트를 나누는 비용은 분명히 있다. 역할 경계를 잘못 그으면 같은 걸 두 번 보거나 아무도 안 보는 틈이 생긴다.

그래도 일정 규모를 넘어가면 쪼개는 쪽이 이긴다. 한 명한테 다 몰아주면 그 사람이 휴가 갔을 때 멈추는 구조와 같다. AX도 똑같다. 베테랑 머릿속에만 있던 판단을 에이전트 하나에 통째로 옮기면 그 에이전트가 블랙박스가 된다. 역할을 나눠야 어디서 틀렸는지 보인다.

다음에 새 레포를 세팅할 때도 이 13개 구성을 출발점으로 쓸 생각이다.