에이전트 하나에게 탐색, 구현, 리뷰를 모두 시키면 일단 코드는 나온다. 하지만 그 코드가 정말 요구사항에 맞는지, 아키텍처를 해치지는 않는지 확인하는 주체가 사라진다. 구현자와 리뷰어가 같은 에이전트라면, 그 리뷰어는 필연적으로 자기 코드가 맞다고 생각하는 확증 편향에 빠지기 때문이다. 복잡한 프로젝트에서 우리가 한 명의 만능 에이전트가 아닌, 여러 전문 에이전트의 조율에 집중해야 하는 이유가 바로 여기에 있다.
오케스트레이션은 개별 에이전트의 페르소나를 선명하게 유지하면서, 이들이 서로의 결과를 주고받으며 하나의 큰 목표를 달성하게 만드는 설계 기법이다. 역할이 분리될수록 각 에이전트의 프롬프트는 단순해지고 결과의 정확도는 높아진다. 또한 특정 단계에서 문제가 발생했을 때 어떤 전문가의 판단이 틀렸는지 추적하기도 훨씬 쉬워진다.
순차 패턴(Sequential): 신뢰의 파이프라인
가장 기본이 되는 조율 방식은 단계별로 에이전트를 배치하는 순차 패턴이다. 탐색 전문가가 먼저 상황을 파악하고, 구현 전문가가 코드를 짜며, 마지막으로 리뷰 전문가가 검증하는 흐름이다. 이 과정에서 각 에이전트는 앞선 에이전트의 결과물을 바탕으로 자신의 임무를 수행한다.
1. @project-explorer가 관련 파일과 의존성 구조를 탐색한다.
2. 탐색된 구조를 바탕으로 @project-worker가 수정을 진행한다.
3. 수정 완료 후 테스트와 타입체크로 자가 검증을 수행한다.
4. 마지막으로 @project-reviewer가 read-only로 최종 검토를 수행한다.이 패턴의 핵심은 세션 연속성과 컨텍스트 전달이다. 에이전트들은 서로의 대화를 자동으로 공유하지 않으므로, 오케스트레이터가 앞 단계의 핵심 결과를 요약하여 다음 단계에 전달해야 한다. “아까 그 파일” 같은 표현은 사람 사이에서도 위험한데, 에이전트 사이에서는 거의 재난 초대장이다.
병렬 패턴(Parallel): 효율적인 동시 검토
병렬 패턴은 서로 독립적인 판단을 동시에 얻고 싶을 때 사용한다. 예를 들어 큰 리팩터링을 앞두고 코드베이스 탐색, 외부 문서 확인, 보안 위험 검토를 동시에 돌릴 수 있다. 단, 병렬화는 같은 질문을 여러 에이전트에게 던지는 것이 아니다. 같은 질문을 던지면 답이 세 개가 아니라 혼란이 세 배가 된다.
explore -> 내부 코드 구조와 기존 패턴
librarian -> 공식 문서와 public example
security -> 권한, secret, 외부 호출 위험
ux/review -> 사용자 흐름과 접근성 위험병렬 패턴에서 오케스트레이터의 일은 결과를 합치는 것이다. 서로 충돌하는 제안이 나오면 더 안전한 쪽을 기본값으로 삼고, 변경 범위가 커지는 제안은 별도 단계로 분리한다. 특히 외부 문서와 내부 패턴이 다를 때는 무조건 최신 문서를 따르기보다, 현재 코드베이스가 왜 다르게 되어 있는지 먼저 확인해야 한다. 오래된 코드가 항상 틀린 것은 아니고, 최신 예제가 항상 우리 프로젝트에 안전한 것도 아니다.
계층 및 이벤트 기반 패턴(Hierarchical & Event-Driven)
계층 패턴은 상위 오케스트레이터가 목표와 제약을 정하고, 하위 에이전트가 세부 작업을 수행하는 방식이다. 이때 상위 역할은 직접 구현을 많이 하지 않는 편이 좋다. 대신 작업을 나누고, 결과를 검토하고, 실패 시 어느 단계로 되돌아갈지 결정한다.
이벤트 기반 패턴은 특정 조건이 발생했을 때 다음 에이전트를 호출한다. 예를 들어 테스트 실패가 발생하면 debugger를 호출하고, 보안 관련 파일이 바뀌면 security reviewer를 호출하며, UI 컴포넌트가 바뀌면 accessibility reviewer를 호출하는 식이다.
if tests fail:
call debugger with exact failure output
if auth/payment/deploy files changed:
call security reviewer
if UI files changed:
call accessibility reviewer이 방식은 자동화처럼 보이지만 사실은 안전장치에 가깝다. 사람이 매번 기억해야 하는 검토 조건을 시스템이 대신 기억하게 만드는 것이다. 좋은 오케스트레이션은 일을 더 많이 시키는 것이 아니라, 빼먹으면 안 되는 확인을 자동으로 떠올리게 만든다.
컨텍스트 전달 규칙
에이전트 조율에서 가장 많이 망가지는 부분은 컨텍스트 전달이다. 앞 단계 에이전트가 200줄짜리 분석을 냈다고 해서 다음 에이전트에게 그대로 던지면, 중요한 정보가 오히려 묻힌다. 오케스트레이터는 다음 역할에 필요한 정보만 요약해야 한다.
좋은 전달문은 이렇게 생겼다.
목표: posts API의 PATCH payload를 최소화한다.
관련 파일: app/api/posts/[slug]/route.ts, blog-write skill
기존 패턴: 변경 필드만 보내고 status는 유지한다.
금지: 토큰 출력, 전체 metadata replacement, publish 상태 변경
검증: GET 재조회로 slug/status/content 확인이 정도면 builder는 작업을 시작할 수 있고, reviewer는 무엇을 확인해야 하는지 알 수 있다. “전체 맥락은 위에 있음” 같은 문장은 사람에게도 불친절하지만, 에이전트에게는 거의 방치에 가깝다.
자가 치유(Self-Healing) 루프와 안티패턴
자가 치유 루프는 실패가 발생했을 때 자동으로 원인을 분석하고 수정하는 패턴이다. 하지만 이 루프는 매우 조심해서 써야 한다. 실패 로그를 제대로 전달하지 않거나 최대 반복 횟수를 정하지 않으면, 에이전트는 같은 수정을 조금씩 바꿔가며 무한히 시도할 수 있다. 이것은 치유가 아니라 디지털 민간요법이다.
안전한 자가 치유 루프는 세 가지 조건을 가진다.
- 실패 출력이 그대로 전달된다.
- 시도 횟수와 중단 조건이 있다.
- 같은 실패가 반복되면 더 높은 판단 역할에 넘긴다.
attempt 1: builder fixes obvious issue
attempt 2: debugger checks failure output
attempt 3: oracle reviews root cause
then stop and report오케스트레이션의 목적은 에이전트를 오래 달리게 만드는 것이 아니다. 언제 멈춰야 하는지 아는 구조를 만드는 것이다. 멈춤이 없는 자동화는 결국 사람이 뒤늦게 멈추러 뛰어가야 한다. 그리고 대체로 그때는 로그가 너무 길다.
댓글
댓글을 불러오는 중...