프로세스 2 — 에이전트 오케스트레이션

이 장에서 배우는 것 역할이 나뉜 에이전트들이 어떻게 협업하는지, 그리고 왜 사람 팀 구조를 그대로 옮기면 안 되는지.

역할을 나눕니다

한 에이전트가 전부 하지 않습니다. 역할별로 나눕니다.

왜 나누나

한 에이전트에게 전부 시켜도 되는데 왜 나눌까요? 이유가 셋입니다.

1. 컨텍스트가 깨끗해집니다

각자 자기 일에 필요한 것만 봅니다. 아키텍트는 전체 구조를, 코딩은 자기가 만들 부분을 봅니다. 컨텍스트가 차는 문제가 완화됩니다.

2. 관점이 분리됩니다

같은 에이전트가 만들고 검토하면 자기 결정을 옹호하는 방향으로 봅니다. 검토를 별도 역할로 두면 만든 것을 전제하지 않고 봅니다.

3. 병렬이 가능해집니다

이게 사람 팀과 가장 다른 점입니다.

사람 위계를 옮기면 안 됩니다

흔한 오해가 이것입니다.

리뷰가 코딩이 끝나기를 기다리지 않습니다. 부분이 나오는 대로 검토가 들어가고, 문제가 발견되면 바로 반영됩니다.

graph TD
  S["명세"] --> A["아키텍트: 구조 설계"]
  A --> C["코딩: 구현"]
  A --> R["리뷰: 설계 검토"]
  C --> R2["리뷰: 구현 검토"]
  R -.->|"문제 발견"| A
  R2 -.->|"문제 발견"| C
  C --> T["검증 단계로"]

점선이 되돌아가는 경로입니다. 순차 파이프라인이 아니라 서로 주고받는 구조입니다.

공유 작업 공간

에이전트들은 같은 작업 공간을 봅니다. 사람 팀에서 인수인계 문서가 필요했던 이유는 각자 다른 곳에서 일했기 때문인데, 이 구조에서는 그 비용이 없습니다.

사람은 어디에 있나

이 단계에서 사람이 개입하는 지점은 둘입니다.

1. 설계 방향이 명세와 어긋날 때 — 아키텍트의 결정이 의도와 다르면 잡습니다
2. 되돌릴 수 없는 결정 — 스키마 변경, 외부 계약 변경 등

나머지는 지켜보다가 결과를 봅니다.

실무에서 조심할 것

에이전트를 너무 많이 나누지 마세요

역할을 늘릴수록 조율 비용이 다시 생깁니다. 사람 팀에서 없앤 문제를 에이전트 구성에서 되살리는 셈입니다. 3~4개 역할이면 대개 충분합니다.

리뷰 에이전트에게 무엇을 볼지 알려주세요

"검토해줘"만 시키면 일반적인 지적이 나옵니다. 이렇게 좁혀야 유용합니다.

확인

1. 역할을 나누는 이유 세 가지는?

2. 사람 팀의 위계를 그대로 옮기면 안 되는 이유는?

3. 에이전트 역할을 계속 늘리면 무엇이 문제가 됩니까?

만들어진 것이 맞는지 판정하는 단계입니다 → 프로세스 3 — 자동 검증