에이전트 조직 설계

한 에이전트에게 모든 걸 맡기지 마세요. 역할을 나누고, 역할마다 쓸 수 있는 도구를 하드 경계로 제한하는 것이 핵심입니다.

왜 역할을 나누는가

"무엇이든 하는" 만능 에이전트는 통제가 어렵습니다. 검증을 맡은 에이전트가 코드를 고칠 수 있다면 그 검증은 신뢰할 수 없습니다. 역할을 나누고 도구를 제한하면, 각 에이전트의 행동 범위가 예측 가능해집니다.

기본 6역할

이름은 무엇이든 상관없습니다. 처음엔 그리스 신화 이름을 썼다가, "이름만 봐도 하는 일을 알 수 있게" 기능어로 바꿨습니다. 아래는 그 기본형입니다.

규모가 커지면 writer(집필)·translator(번역)·critic(반증)·recorder(기록)처럼 세분화합니다. 실적이 없는 역할은 인접 역할로 흡수하세요 — 이름만 지우지 말고, 그 역할이 지키던 기준(무엇을 하면 안 되는지)은 흡수한 역할의 정의에 반드시 옮겨 적어야 경계가 함께 사라지지 않습니다.

도구 경계 = 진짜 안전장치

캐릭터 설정('너는 신중한 검증자야')은 지켜지지 않을 수 있지만, 도구 목록에서 Edit·Write를 빼면 물리적으로 코드를 못 고칩니다. OIYO는 각 역할을 에이전트 정의 파일(~/.claude/agents/*.md)로 만들고 tools: 필드로 허용 도구를 명시합니다. 이것이 프롬프트 지시보다 강한 경계입니다.

위임 흐름

오케스트레이터가 큰 작업을 받아 역할별로 쪼갭니다: planner가 스코프 → architect가 설계 → builder가 구현 → verifier가 검증 → 사람이 배포 승인. 각 단계 산출물은 두뇌에 기록되어 다음 에이전트가 이어받습니다. 병렬로 돌릴 수 있는 조사·검증은 동시에 던지면 속도가 붙습니다.

주의: 과잉 위임

모든 작업에 서브에이전트를 부르지 마세요. 서브에이전트는 맥락 없이 시작하므로 비용이 큽니다. 단순 작업은 오케스트레이터가 직접 하고, 여러 파일을 넓게 훑거나 독립적으로 병렬화할 때만 위임하는 것이 효율적입니다.

← 시작하기 · 다음 장: 회사 두뇌 운영 →