2부 8장. Orchestrator-Workers 패턴: 일을 나누고 다시 합치기

길을 나누는 것만으로는 부족할 때가 있다

앞 장에서 우리는 라우팅과 병렬 처리를 다뤘다. 요청을 적절한 경로로 보내고, 서로 독립적인 작업은 동시에 처리하면 시스템이 더 빨라지고 더 안정적이 된다는 이야기였다. 그런데 실전으로 한 걸음만 더 들어가면, 곧 이런 순간이 찾아온다.

"경로는 골랐는데, 이 큰 일을 이제 어떻게 잘게 나누지?"

예를 들어 사용자가 이렇게 요청한다고 해보자. "경쟁사 세 곳의 최근 전략을 조사해서 우리 제품팀 회의용 메모를 만들어줘." 이 요청은 단순히 한 경로로 보낸다고 끝나지 않는다. 경쟁사별 조사도 필요하고, 제품 포지셔닝 비교도 필요하고, 가격 정책도 봐야 하고, 마지막에는 회의용 문서 형식으로 다시 정리해야 한다.

이때 필요한 것이 바로 Orchestrator-Workers 패턴이다. 이름은 조금 거창하지만, 생각은 의외로 익숙하다. 팀장이 일을 쪼개고, 각 담당자에게 배정하고, 결과를 모아 최종 산출물을 만드는 방식과 거의 같다.

중요한 차이는 하나다. 앞 장의 라우팅이 "어느 길로 보낼까?"를 다뤘다면, 이번 장의 오케스트레이션은 "이 큰 일을 어떤 조각으로 나누고, 누구에게 맡기고, 어떻게 다시 합칠까?"를 다룬다. 즉, 분기보다 한 단계 더 적극적인 조정이다.

Orchestrator와 Worker는 각각 무슨 역할을 할까

이 패턴의 핵심은 역할 분담이 아주 분명하다는 데 있다.

Orchestrator는 중앙 조정자다. 목표를 이해하고, 작업을 분해하고, 어떤 워커에게 무엇을 맡길지 결정하고, 중간 결과를 보고 필요하면 다시 지시를 내린다. 오케스트레이터는 직접 모든 실무를 처리하기보다, 전체 그림을 책임진다.

반면 Worker는 실행 담당자다. 맡겨진 범위 안에서 구체적인 일을 수행한다. 어떤 워커는 문서를 찾고, 어떤 워커는 표를 만들고, 어떤 워커는 요약을 쓰고, 어떤 워커는 오류를 검토한다. 워커는 보통 자신에게 주어진 역할 안에서만 움직이는 편이 좋다.

이 둘의 관계를 가장 쉽게 비유하면 오케스트라 지휘자와 연주자다. 지휘자는 모든 악기를 직접 연주하지 않는다. 대신 누가 언제 들어오고, 어떤 흐름으로 곡을 만들지 조정한다. 연주자는 각자 자기 파트를 정확하게 수행한다. 음악이 좋아지려면 둘 다 잘해야 한다.

에이전트 시스템도 마찬가지다. 오케스트레이터만 똑똑하고 워커가 엉성하면 결과가 흔들린다. 반대로 워커는 훌륭한데 오케스트레이터가 일을 이상하게 나누면 전체가 어수선해진다.

왜 이 패턴이 강할까

복잡한 목표는 한 번에 처리하려고 할수록 자주 흔들린다. 모델이 해야 할 일이 너무 많아지기 때문이다. 조사도 해야 하고, 비교도 해야 하고, 형식도 맞춰야 하고, 누락도 없어야 한다. 한 번의 거대한 프롬프트에 이 모든 기대를 담으면, 결과는 그럴듯하지만 군데군데 빈틈이 생기기 쉽다.

Orchestrator-Workers 패턴은 이 문제를 정면으로 다룬다. 큰 목표를 더 다루기 쉬운 단위로 나누고, 각 단위에 더 좁고 선명한 임무를 준다. 그러면 각 워커는 "모든 것을 조금씩" 하는 대신 "하나를 분명하게" 하게 된다.

이 패턴이 특히 강한 이유는 세 가지다.

• 복잡한 목표를 작은 작업으로 분해할 수 있다.

• 서로 다른 전문성을 가진 실행 단위를 만들 수 있다.

• 부분 결과를 바탕으로 다시 계획을 수정할 수 있다.

여기서 마지막이 중요하다. 오케스트레이터는 한 번 나누고 끝나는 존재가 아니다. 중간 결과를 보고 "이건 더 파고들자", "이 부분은 충분하다", "이 둘이 충돌하니 다시 확인하자" 같은 판단을 할 수 있다. 그래서 이 구조는 단순 병렬 처리보다 더 유연하다.

단순 병렬 처리와 무엇이 다를까

겉으로 보기엔 헷갈릴 수 있다. "작업 여러 개를 동시에 돌리는 거라면 앞 장 병렬 처리랑 같은 것 아닌가요?"라고 느낄 수 있다. 비슷하지만 초점이 다르다.

병렬 처리는 주로 독립적인 작업을 동시에 실행하는 데 초점이 있다. 예를 들어 서로 다른 세 문서를 한꺼번에 요약하는 일은 병렬 처리에 잘 맞는다. 구조는 비교적 단순하다. 나누고, 동시에 실행하고, 모은다.

Orchestrator-Workers 패턴은 그보다 더 적극적이다. 여기서는 중앙 조정자가 단순히 "동시에 돌려"라고만 하지 않는다. 먼저 일을 해석하고, 어떤 작업이 필요한지 구성하고, 워커별 역할을 나누고, 중간 결과를 바탕으로 다음 행동을 바꿀 수도 있다.

즉, 병렬 처리가 차선을 늘리는 기술이라면, 오케스트레이션은 아예 공사를 총괄하는 현장소장에 가깝다.

예를 들어 "제품 출시 회의 자료를 만들어라"라는 요청을 생각해보자. 오케스트레이터는 이를 시장 조사, 경쟁사 비교, 내부 일정 확인, 리스크 정리, 발표 슬라이드 초안 작성으로 나눌 수 있다. 이 중 일부는 병렬로 돌릴 수 있지만, 어떤 것은 앞 결과를 받아 다시 세분화해야 한다. 이 전체 흐름을 관리하는 것이 오케스트레이터의 역할이다.

좋은 오케스트레이터는 직접 바쁘지 않다

초보 설계에서 자주 나오는 실수가 있다. 오케스트레이터가 계획도 세우고, 조사도 하고, 초안도 쓰고, 검토도 하는 식으로 모든 일을 거의 다 해버리는 것이다. 이렇게 되면 이름만 오케스트레이터일 뿐, 실제로는 거대한 단일 에이전트와 다를 바가 없다.

좋은 오케스트레이터는 직접 바빠지지 않는다. 오히려 바쁜 척을 덜 해야 한다. 자신의 핵심 책임은 세 가지 정도로 좁혀지는 편이 좋다.

첫째, 목표를 작업 단위로 분해한다. 둘째, 작업을 적절한 워커에게 배분한다. 셋째, 결과를 모아 일관된 최종 산출물로 만든다.

오케스트레이터가 이 범위를 넘어 실무까지 깊게 파고들기 시작하면, 두 가지 문제가 생긴다. 하나는 병목이다. 결국 중앙에서 다 막히게 된다. 다른 하나는 역할 불명확성이다. 워커가 할 일과 오케스트레이터가 할 일이 겹치면서 구조가 흐려진다.

좋은 팀장을 떠올리면 이해가 쉽다. 좋은 팀장은 모든 발표 자료를 직접 만들지 않는다. 대신 누가 무엇을 맡아야 가장 잘 나올지 판단하고, 결과를 모아 방향을 맞춘다.

좋은 워커는 똑똑한 만능 비서보다, 믿을 수 있는 전문가에 가깝다

워커를 설계할 때도 비슷한 함정이 있다. 모든 워커를 "뭐든지 다 하는 작은 에이전트"로 만들고 싶어지는 것이다. 하지만 그렇게 만들면 워커마다 차별점이 사라지고, 결국 오케스트레이터가 누구에게 맡겨도 큰 차이가 없는 구조가 된다.

좋은 워커는 대개 더 좁고 더 선명하다. 예를 들어 이런 식이다.

• 조사 워커는 자료를 수집하고 핵심 사실을 정리한다.

• 분석 워커는 수집된 사실을 기준에 따라 비교하고 해석한다.

• 작성 워커는 분석 결과를 문서 형식에 맞게 풀어쓴다.

• 검토 워커는 누락, 충돌, 형식 오류를 확인한다.

이렇게 역할이 분명하면 장점이 많다. 프롬프트가 짧아지고, 기대 결과도 명확해지고, 실패했을 때 어디가 문제인지 찾기 쉬워진다. 무엇보다 재사용이 가능해진다. 오늘은 경쟁사 조사에 쓰고, 내일은 기술 문서 비교에 써도 된다.

워커는 대개 "작고 전문적일수록" 다루기 쉽다. 물론 너무 잘게 쪼개면 반대로 합치는 비용이 커질 수 있다. 그래서 좁되, 의미 있는 단위로 자르는 감각이 중요하다.

오케스트레이터는 어떤 기준으로 일을 나눌까

작업 분해는 이 패턴의 심장이다. 일을 잘못 자르면 그다음부터는 모두 꼬인다. 너무 크게 나누면 워커가 다시 만능 비서가 되고, 너무 잘게 나누면 워커가 많아져서 조정 비용이 폭증한다.

좋은 분해는 보통 다음 질문에서 시작된다.

이 목표를 완수하려면 어떤 중간 산출물이 필요한가? 어떤 단계는 서로 독립적인가? 어떤 단계는 다른 결과를 받아야만 시작할 수 있는가? 어느 부분은 전문성이 다르게 필요한가?

예를 들어 "월간 운영 리포트를 작성하라"는 요청이 있다고 해보자. 이를 다음과 같이 나눌 수 있다.

• 매출 지표 수집

• 사용자 행동 지표 수집

• 이상 징후 탐지

• 주요 변화 원인 해석

• 최종 리포트 작성

여기서 지표 수집은 병렬로 돌릴 수 있다. 하지만 변화 원인 해석은 수집 결과를 받은 뒤에야 제대로 할 수 있다. 마지막 리포트 작성은 모든 결과가 모인 뒤에 해야 한다. 즉, 분해는 단순한 목록 만들기가 아니라 의존 관계를 이해하는 일이다.

좋은 오케스트레이터는 작업 목록을 만들기만 하지 않고, 어떤 순서로 묶이고 어디서 다시 합쳐져야 하는지도 함께 본다.

워커를 기준으로 자를까, 결과물을 기준으로 자를까

실전에서는 작업을 나누는 기준이 두 방향으로 갈린다. 하나는 역할 중심 분해이고, 다른 하나는 산출물 중심 분해다.

역할 중심 분해는 조사 담당, 분석 담당, 작성 담당처럼 전문성에 따라 나누는 방식이다. 이 방식은 역할이 뚜렷한 조직이나 반복 업무에서 강하다. 워커를 재사용하기 쉽고, 프롬프트 템플릿도 안정적이다.

산출물 중심 분해는 경쟁사 A 보고서, 경쟁사 B 보고서, 경쟁사 C 보고서처럼 결과물 단위로 나누는 방식이다. 이 방식은 비슷한 형식의 결과물을 여러 개 만들어야 할 때 유용하다.

둘 중 무엇이 정답인지는 작업에 따라 다르다. 경쟁사 세 곳을 같은 형식으로 조사해야 한다면 산출물 중심 분해가 자연스럽다. 반대로 하나의 긴 기획서를 만들기 위해 조사, 분석, 집필, 검토가 필요하다면 역할 중심 분해가 더 적합할 수 있다.

실전에서는 이 둘이 섞이기도 한다. 먼저 경쟁사별로 조사 워커를 돌린 뒤, 그 결과를 받아 분석 워커와 작성 워커가 이어받는 식이다. 즉, 분해 방식은 하나가 아니라 계층적으로 조합될 수 있다.

결과를 다시 합치는 단계가 가장 중요하다

많은 사람이 이 패턴을 떠올릴 때 "일을 잘 나누는 것"에만 집중한다. 하지만 실제 품질을 가르는 지점은 거의 항상 마지막 합성 단계다.

워커가 다섯 명이라면, 결과도 다섯 조각으로 나온다. 이 조각들은 그 자체로는 유용할 수 있지만, 그대로 이어 붙이면 좋은 산출물이 되지 않는다. 중복이 생기고, 표현 수준이 다르고, 서로 모순되는 내용이 섞일 수 있다. 어떤 워커는 아주 조심스럽게 썼고, 어떤 워커는 단정적으로 썼을 수도 있다.

그래서 오케스트레이터는 마지막에 단순 편집자가 아니라 재구성자가 되어야 한다. 이 단계에서 해야 할 일은 생각보다 많다.

• 중복된 내용을 정리한다.

• 서로 충돌하는 내용을 확인한다.

• 전체 목표에 맞게 우선순위를 다시 조정한다.

• 사용자에게 필요한 형식으로 다시 배열한다.

예를 들어 워커 A는 "가격 인상 가능성이 높다"고 쓰고, 워커 B는 "단기 가격 안정성이 유지될 수 있다"고 쓸 수 있다. 둘 다 틀리지 않을 수 있다. 다만 전제 조건이 다를 뿐이다. 이때 오케스트레이터는 둘 중 하나를 무시하는 대신, 조건을 밝혀 정리해야 한다. 바로 이런 조율이 최종 품질을 만든다.

중간 결과를 보고 다시 지시할 수 있어야 한다

Orchestrator-Workers 패턴이 단순 분업과 다른 결정적인 이유는, 오케스트레이터가 중간 결과를 바탕으로 계획을 수정할 수 있다는 점이다.

예를 들어 경쟁사 분석을 시켰더니, 한 워커가 "자료가 너무 부족하다"는 결과를 가져왔다고 해보자. 그러면 오케스트레이터는 그냥 그 빈칸을 둔 채 진행할 수도 있지만, 더 나은 선택은 추가 조사를 다시 요청하는 것이다. 또는 다른 자료원으로 바꿔보게 할 수도 있다.

반대로 어떤 워커가 이미 충분한 정보를 모아왔다면, 원래 계획했던 후속 단계를 생략할 수도 있다. 즉, 오케스트레이터는 처음 계획의 노예가 되어서는 안 된다. 좋은 중앙 조정자는 계획을 세우지만, 더 좋은 중앙 조정자는 계획을 수정할 줄 안다.

이 점 때문에 오케스트레이션은 정적인 파이프라인보다 훨씬 강하다. 정적인 파이프라인은 미리 정한 순서를 벗어나기 어렵지만, 오케스트레이터는 상황을 보고 다음 수를 바꿀 수 있다.

예시 1: 시장 조사 메모를 만드는 시스템

이 패턴을 가장 쉽게 이해할 수 있는 사례는 리서치 업무다. 예를 들어 사용자가 "국내 생성형 AI 협업 도구 시장을 정리해주고, 우리 제품이 어디에서 기회가 있는지 회의용 메모로 써줘"라고 요청했다고 하자.

오케스트레이터는 먼저 이 목표를 몇 개의 작업으로 나눌 수 있다. 시장 크기와 최근 흐름 파악, 주요 경쟁사 조사, 가격 정책 조사, 기능 포지셔닝 비교, 마지막 회의용 메모 작성이 그것이다.

이때 시장 흐름 조사와 경쟁사 조사는 병렬로 돌릴 수 있다. 경쟁사 조사도 다시 경쟁사별 워커로 나눌 수 있다. 예를 들어 A사 워커, B사 워커, C사 워커가 각각 자사 자료를 정리해 올 수 있다.

그다음 오케스트레이터는 각 결과를 보고 빈칸을 채운다. 어떤 경쟁사는 가격 정보가 불분명할 수 있고, 어떤 경쟁사는 최근 업데이트가 많아 기능 변화가 중요할 수 있다. 오케스트레이터는 필요한 부분에만 추가 조사를 시킨다.

마지막에는 단순 요약이 아니라 "회의용 메모"라는 형식에 맞게 재구성한다. 지금 시장이 어떤 방향인지, 경쟁사들은 어디에 집중하는지, 우리에게 어떤 틈이 있는지, 당장 논의할 질문은 무엇인지로 정리하면 비로소 사용자가 쓸 수 있는 결과가 된다.

이 사례에서 중요한 것은 워커의 수가 아니라, 중앙 조정자가 전체 목적을 잃지 않고 각 조각을 다시 의미 있는 이야기로 묶는다는 점이다.

예시 2: 코드 변경 검토와 배포 준비

개발 조직에서도 이 패턴은 매우 유용하다. 예를 들어 하나의 큰 변경 사항이 들어왔다고 해보자. 사용자 인증, 결제 흐름, UI 문구, 로그 처리까지 함께 바뀌었다. 이걸 한 번에 읽고 "괜찮습니다" 혹은 "문제 있습니다"라고 판단하는 것은 어렵다.

오케스트레이터는 먼저 변경 범위를 나눈다. 보안 영향 검토, 테스트 누락 확인, 성능 리스크 점검, 사용자 경험 변화 요약, 배포 체크리스트 정리 같은 작업으로 분해할 수 있다.

이 중 보안과 테스트와 성능은 각각 다른 워커에게 맡기기 좋다. 보안 워커는 권한 상승이나 민감 정보 노출 가능성을 살핀다. 테스트 워커는 바뀐 로직에 비해 테스트가 충분한지 본다. 성능 워커는 병목 가능성을 점검한다.

오케스트레이터는 결과를 모아 "즉시 수정해야 할 문제", "배포 전 확인 항목", "권장 개선 사항"으로 다시 정리한다. 이런 식이면 여러 관점을 함께 반영하면서도, 최종 출력은 배포 의사결정에 바로 쓸 수 있는 형태가 된다.

여기서 핵심은 워커들이 각자 의견만 던지고 끝나는 것이 아니라, 오케스트레이터가 그것을 운영 가능한 판단으로 바꾼다는 점이다.

예시 3: 백오피스 업무 자동화

백오피스 업무는 겉보기에 단순해 보여도 실제로는 여러 확인 단계를 필요로 하는 경우가 많다. 예를 들어 "고객의 환불 요청을 검토하고 처리안을 작성하라"는 작업을 보자.

오케스트레이터는 이를 주문 내역 확인, 환불 정책 조회, 예외 조건 검토, 과거 상담 이력 확인, 최종 응답 초안 작성으로 나눌 수 있다. 주문 내역과 상담 이력, 정책 조회는 일부 병렬로 돌릴 수 있다. 하지만 최종 판단은 이 정보가 모두 모인 뒤에 해야 한다.

또 하나 중요한 점은 위험도다. 환불은 금전과 연결되므로, 워커가 각자 정보를 모아왔다고 해서 자동으로 승인해버리면 안 된다. 오케스트레이터는 결과를 취합한 뒤, 규칙에 맞는지 확인하고, 애매한 경우 사람 승인 단계로 넘겨야 한다.

즉, 오케스트레이터는 단순한 관리자일 뿐 아니라 책임의 관문 역할도 한다. 이 점 때문에 이 패턴은 실제 운영 시스템에 특히 잘 맞는다.

상태를 어떻게 들고 갈 것인가

오케스트레이션 구조에서는 상태 관리가 매우 중요하다. 중앙 조정자가 여러 워커에게 일을 맡기고 결과를 모으려면, 현재 무엇이 끝났고 무엇이 남았는지 분명히 알아야 하기 때문이다.

최소한 다음 정도는 상태로 관리하는 편이 좋다.

• 전체 목표와 완료 조건

• 생성된 작업 목록과 각 작업의 상태

• 각 워커에게 전달한 입력과 받은 결과

• 실패한 작업과 재시도 여부

• 최종 합성에 필요한 중간 산출물

이 상태가 없으면 시스템은 금방 헷갈린다. 이미 끝난 일을 다시 시키거나, 실패한 워커의 결과를 성공으로 착각하거나, 어떤 버전이 최신인지 모르게 된다.

특히 오케스트레이터가 중간 결과를 보고 다시 계획을 바꾸는 구조라면 상태는 더 중요하다. 왜 새로운 작업이 생겼는지, 어떤 판단 때문에 기존 계획이 수정됐는지 남아 있어야 나중에 디버깅이 가능하다.

쉽게 말해 오케스트레이터는 머리만 좋은 지휘자가 아니라, 메모도 꼼꼼한 지휘자여야 한다.

컨텍스트를 모두 다 주면 오히려 망가진다

워커에게 일을 맡길 때 흔히 하는 실수는 전체 상황을 전부 다 넣어주는 것이다. "혹시 필요할지 모르니까" 하며 대화 기록, 이전 결과, 관련 문서, 사용자 프로필, 정책 모음까지 몽땅 넣어준다. 그러면 워커는 풍부해지기는커녕 오히려 산만해진다.

워커에게는 필요한 만큼만 주는 것이 좋다. 가격 비교 워커라면 가격 관련 자료와 비교 기준만 있으면 된다. 회의록 초안 작성 워커라면 이미 정리된 핵심 사실과 원하는 문서 형식이 더 중요하다.

오케스트레이터의 큰 역할 중 하나가 바로 이것이다. 전체 맥락을 다 안고 있으면서도, 각 워커에게는 그 워커가 집중해야 할 범위만 전달하는 것. 이것이 잘되면 워커의 품질이 좋아지고 비용도 줄어든다.

모든 정보를 모두에게 공유하는 조직이 항상 효율적인 것은 아닌 것처럼, 에이전트 시스템도 적절한 정보 배급이 중요하다.

실패는 워커보다 오케스트레이터에서 관리해야 한다

워커가 실패하는 일은 자연스럽다. 검색 결과가 부족할 수도 있고, 파일을 읽지 못할 수도 있고, 프롬프트 해석이 엇나갈 수도 있다. 중요한 것은 실패 자체보다 실패를 누가, 어떻게 관리하느냐다.

이 패턴에서는 대개 오케스트레이터가 실패 정책을 가져가는 편이 좋다. 예를 들어 이런 판단이 가능하다.

• 실패한 워커만 다시 실행한다.

• 다른 워커로 대체한다.

• 일부 결과만으로 계속 진행한다.

• 위험이 크면 전체 작업을 중단한다.

• 사람 검토 단계로 넘긴다.

예를 들어 경쟁사 다섯 곳 중 한 곳의 정보가 부족하다면, 나머지 네 곳으로 먼저 메모 초안을 만들고 "한 업체는 정보 부족"을 표시할 수 있다. 하지만 결제 승인이나 계정 권한 변경처럼 위험한 작업에서는 하나라도 핵심 정보가 비면 멈추는 편이 맞다.

즉, 실패 복구는 워커별로 알아서 처리하게 두기보다, 전체 목적과 위험도를 아는 오케스트레이터가 결정하는 것이 더 안전하다.

이 패턴이 특히 잘 맞는 문제들

모든 곳에 오케스트레이터를 붙일 필요는 없다. 하지만 어떤 문제에서는 이 패턴이 유난히 강하다.

첫째, 최종 목표는 하나지만 그 안에 서로 다른 하위 작업이 섞여 있을 때다. 조사, 계산, 작성, 검토가 한꺼번에 필요한 경우가 그렇다.

둘째, 부분 결과를 중간에 보고 방향을 바꿔야 할 때다. 처음 계획대로 끝까지 밀어붙이는 것보다, 중간 학습이 중요한 작업에 잘 맞는다.

셋째, 작업마다 필요한 능력이나 도구가 다를 때다. 어떤 것은 검색이 필요하고, 어떤 것은 코드 실행이 필요하고, 어떤 것은 문서 작성 감각이 중요할 수 있다.

넷째, 최종 산출물이 단순한 답변이 아니라 정리된 문서, 보고서, 체크리스트, 실행 계획처럼 구조를 가져야 할 때다. 이런 결과는 부분 작업을 모아 다시 설계하는 과정이 필요하다.

다섯째, 운영상 추적 가능성이 중요할 때다. 누가 어떤 판단을 했는지, 어느 단계에서 실패했는지, 어떤 근거로 최종 결과가 나왔는지 보고 싶다면 중앙 오케스트레이션이 큰 도움이 된다.

반대로, 언제는 과한가

이 패턴은 멋져 보이기 쉬워서 남용되기도 한다. 하지만 단순한 질의응답이나 짧은 작업에는 과할 수 있다. 사용자의 질문이 한 문서에서 답을 찾으면 끝나는 수준이라면, 굳이 오케스트레이터가 일을 분해하고 여러 워커를 호출할 필요가 없다.

또한 작업이 충분히 짧고, 서로 의존성이 강하고, 최종 출력도 단순하다면 오케스트레이션의 이점보다 오버헤드가 더 커질 수 있다. 일을 쪼개는 시간, 결과를 넘기는 비용, 다시 합치는 복잡성 때문에 오히려 느려질 수 있기 때문이다.

특히 이런 경우는 조심해야 한다.

• 목표가 작고 명확하다.

• 워커를 나눠도 전문성 차이가 거의 없다.

• 합성 비용이 큰데 얻는 이득이 작다.

• 상태 관리 부담이 너무 커진다.

쉽게 말해 팀을 꾸린다고 해서 늘 일이 빨라지는 것은 아니다. 메모 하나 쓰는데 부장, 팀장, 담당자, 검토자, 승인자를 다 붙이면 더 느려진다. 에이전트 시스템도 똑같다.

자주 하는 설계 실수

Orchestrator-Workers 패턴을 처음 설계할 때는 몇 가지 실수가 반복된다.

첫 번째 실수는 워커의 역할이 서로 겹치는 것이다. 조사 워커와 분석 워커가 둘 다 요약까지 해버리면, 어디까지가 수집이고 어디부터가 해석인지 경계가 흐려진다.

두 번째 실수는 오케스트레이터가 지나치게 세세한 지시를 내리는 것이다. 워커에게 사실상 완성 답안을 강요하면, 워커는 독립된 실행 단위가 아니라 단순 복사기가 된다.

세 번째 실수는 중간 산출물 형식이 제각각인 것이다. 어떤 워커는 긴 문단을 주고, 어떤 워커는 표를 주고, 어떤 워커는 메모 몇 줄만 남기면 마지막 합성이 몹시 어려워진다.

네 번째 실수는 재계획 기준이 없는 것이다. 중간 결과가 부족할 때 언제 추가 워커를 호출할지, 언제 멈출지, 언제 사람에게 넘길지 기준이 없으면 오케스트레이터는 우왕좌왕한다.

다섯 번째 실수는 성공 기준이 최종 단계에만 있는 것이다. 사실은 워커 단계마다 기대 산출물이 분명해야 한다. 그래야 오케스트레이터가 "이 결과는 쓸 만하다" 혹은 "다시 시켜야 한다"를 판단할 수 있다.

이 패턴은 구조가 화려해 보이지만, 실제로는 역할 정의와 인터페이스 설계가 아주 중요하다. 결국 협업 구조의 품질은 소통 규칙에서 나온다.

출력 형식은 가능한 한 구조화하라

워커 간 협업이 안정적이려면 출력 형식을 구조화하는 편이 좋다. 자유로운 산문도 읽기에는 좋지만, 다음 단계 에이전트가 처리하기에는 불안정할 수 있다.

예를 들어 조사 워커라면 다음처럼 결과를 정리하게 할 수 있다. 핵심 주장, 근거, 수치, 확신 수준, 추가 확인 필요 항목. 분석 워커라면 비교 기준, 차이점, 잠재 리스크, 해석 주의점. 작성 워커라면 제목, 요약, 본문, 권장 액션 항목.

이렇게 틀을 맞추면 오케스트레이터는 각 워커의 결과를 더 쉽게 검토하고 조합할 수 있다. 또한 실패 시 어느 항목이 비었는지도 빠르게 알 수 있다.

사람끼리 일할 때도 "그냥 정리해서 보내줘"보다 "이 양식에 맞춰 보내줘"가 훨씬 덜 헷갈리는 것과 같다. 구조화는 창의성을 막는 장치가 아니라 협업을 가능하게 하는 장치다.

중앙 조정이 강하다는 것은 책임도 중앙에 모인다는 뜻이다

이 패턴의 장점은 명확하다. 전체 흐름이 보이고, 조정이 쉽고, 추적 가능성도 높다. 하지만 단점도 있다. 중앙 조정자가 약하면 전체가 흔들린다. 즉, 오케스트레이터는 편리한 중심이면서 동시에 단일 실패 지점이 될 수 있다.

그래서 오케스트레이터를 설계할 때는 두 가지를 함께 생각해야 한다. 하나는 의사결정 품질이고, 다른 하나는 운영 안정성이다. 오케스트레이터가 실패했을 때 어디까지 복구할 수 있는지, 중간 상태를 저장하는지, 같은 작업을 다시 시작할 수 있는지 같은 문제가 중요해진다.

또 하나 생각할 점은 책임 분리다. 워커가 외부 도구를 호출하거나 실제 시스템을 바꾸는 행동을 한다면, 그 실행 권한을 아무렇게나 나눠주면 안 된다. 중앙 조정자는 일을 배정하되, 중요한 변경은 제한된 워커만 하게 하거나 승인 단계를 끼워 넣어야 한다.

즉, Orchestrator-Workers 패턴은 협업을 쉽게 만들지만, 동시에 권한과 책임을 더 정교하게 설계하게 만든다. 이것은 단점이라기보다, 실전 시스템으로 가기 위해 반드시 지나야 하는 단계에 가깝다.

실전 감각: 처음에는 워커 수를 적게 시작하라

처음부터 워커를 여섯, 일곱 개씩 만드는 것은 대개 좋지 않다. 역할은 많아 보이지만 실제로는 각 워커의 차이가 애매하고, 디버깅도 복잡해진다. 시작할 때는 보통 두세 개의 분명한 워커로 충분하다.

예를 들어 조사 워커, 작성 워커, 검토 워커 정도만 있어도 꽤 많은 업무를 다룰 수 있다. 실제 운영에서 병목이나 누락이 발견되면 그때 분석 워커를 따로 떼거나, 정책 검토 워커를 추가하는 식으로 확장하는 편이 낫다.

이 접근이 좋은 이유는 간단하다. 시스템 구조는 처음 생각한 그림보다, 실제로 어디서 자주 실패하는지가 훨씬 더 중요한 설계 근거이기 때문이다. 멋진 조직도보다, 자주 막히는 지점을 줄이는 구조가 더 쓸모 있다.

한 문장으로 정리하면

Orchestrator-Workers 패턴은 복잡한 목표를 중앙에서 계획하고, 전문적인 실행 단위에 나눠 맡긴 뒤, 그 결과를 다시 하나의 일관된 산출물로 만드는 협업 구조다.

핵심은 단순히 여러 에이전트를 쓰는 데 있지 않다. 무엇을 나눌지, 누구에게 맡길지, 언제 다시 지시할지, 어떻게 합칠지에 있다. 결국 이 패턴의 본질은 "많은 손을 쓰는 것"이 아니라 "많은 손이 한 방향을 보게 만드는 것"이다.

다음 장과의 연결

이번 장에서는 중앙 오케스트레이터가 일을 분해하고, 워커가 각자 맡은 일을 수행하고, 마지막에 결과를 재조합하는 구조를 살펴봤다. 이 패턴은 복잡한 목표를 다루는 데 강하고, 팀처럼 일하는 에이전트 시스템의 기본 감각을 만들어준다.

하지만 일이 나뉘고 다시 합쳐졌다고 해서 언제나 품질이 좋아지는 것은 아니다. 누가 이 결과가 충분히 좋은지 판단할까? 초안이 별로면 어떻게 더 나아지게 만들까?

다음 장에서는 바로 그 문제를 다룬다. 결과를 평가하는 역할과, 그것을 바탕으로 다시 개선하는 역할을 분리한 Evaluator-Optimizer 패턴을 통해, 에이전트가 스스로 검토하고 더 나아지도록 만드는 구조를 살펴보자.