멀티 에이전트 시스템 설계 패턴: Orchestrator와 Worker 역할 나누기

에이전트를 여러 개 붙이면 복잡한 작업을 더 잘 처리할 것 같지만, 실제로는 역할이 흐려지는 순간부터 결과가 오히려 불안정해진다. 모든 에이전트가 계획도 세우고 조사도 하고 파일도 고치고 검토까지 함께 맡으면, 누가 최종 결정을 내리는지조차 알기 어려워진다. 작업이 실패했을 때 어느 단계에서 문제가 생겼는지 추적하기도 쉽지 않다.

멀티 에이전트 구조를 안정적으로 만들려면 무엇보다 역할부터 나눠야 한다. 가장 기본이 되는 구분은 Orchestrator와 Worker다. Orchestrator는 작업을 해석하고 나누고 결과를 취합하는 역할을, Worker는 맡겨진 작은 작업을 실제로 수행하는 역할을 담당한다. 이 구분이 뚜렷할수록 시스템 전체가 단순해지고 문제가 생겼을 때 디버깅도 훨씬 수월해진다.

Orchestrator와 Worker는 각각 무엇을 책임지는가

Orchestrator가 맡는 범위

Orchestrator는 작업 전체의 맥락을 잡고 어떤 하위 작업이 필요한지 결정하는 역할을 맡는다. 사용자의 요청을 그대로 여러 에이전트에게 흩어 던지는 것이 아니라, 목표와 제약 조건을 먼저 읽고 필요한 순서를 구성한다. 예컨대 기능 개발 요청이 들어오면 코드 조사, 구현, 테스트, 검토 단계를 나누고 각 단계에 어떤 입력이 들어가고 어떤 출력이 나와야 하는지를 정리한다.

여기서 중요한 점은 Orchestrator가 모든 세부 작업을 직접 처리할 필요가 없다는 것이다. 오히려 너무 많은 실행을 직접 떠안으면 정작 전체를 조율하는 역할이 약해진다. Orchestrator는 작업 범위, 완료 조건, 실패했을 때의 재시도 기준을 관리하는 데 집중하는 편이 시스템 전체를 건강하게 유지하는 데 유리하다.

Worker가 맡는 범위

Worker는 작고 명확한 작업을 맡아 실행하는 역할이다. 특정 파일 묶음을 읽고 요약하거나, 한 모듈의 테스트 케이스를 작성하거나, 문서에서 필요한 근거를 찾아오는 식의 작업이 여기에 해당한다. Worker에게는 시스템 전체의 맥락을 모두 전달하기보다, 해당 작업을 수행하는 데 꼭 필요한 최소한의 정보만 넘겨주는 편이 좋다.

Worker가 지나치게 넓은 권한과 모호한 목표를 동시에 받으면 예상과 다른 방향으로 작업을 진행할 가능성이 커진다. 반대로 입력, 출력 형식, 하지 말아야 할 행동, 시간 제한이 분명하게 주어지면 Orchestrator가 여러 Worker의 결과를 비교하고 하나로 합치기가 훨씬 쉬워진다.

결과를 취합하는 과정이 설계의 핵심

멀티 에이전트 시스템에서 자주 놓치는 부분이 바로 결과를 어떻게 합칠지에 대한 설계다. Worker들이 각자 그럴듯한 답을 내놓더라도, 이를 하나의 최종 답변이나 코드 변경으로 묶는 기준이 없으면 전체 품질이 흔들린다. Orchestrator는 Worker의 결과를 그대로 이어 붙이기보다, 서로 충돌하는 주장이나 빠진 조건, 검증되지 않은 가정을 다시 한번 점검하는 역할까지 함께 맡아야 한다.

실제로 적용해볼 수 있는 방법

작업 단위를 잘게 나누기

Worker에게 전체 기능을 구현해달라는 식으로 큰 덩어리를 맡기기보다 현재 인증 흐름을 요약해달라거나 특정 테스트 파일에 필요한 케이스를 제안해달라는 식으로 작은 단위로 나눠 맡기는 편이 안정적이다. 작업이 작을수록 성공 여부를 판단하기 쉽고, 실패했을 때 다시 시도하는 비용도 낮아진다.

출력 형식을 고정해두기

Worker의 결과가 매번 다른 형태로 돌아오면 Orchestrator가 이를 취합하기 어려워진다. 조사를 맡은 Worker라면 발견한 사실, 근거가 된 파일, 확실하지 않은 부분처럼 항목을 미리 정해두고, 구현을 맡은 Worker라면 변경한 파일, 변경 의도, 검증 결과를 요구하는 식이 좋다. 출력 형식은 사실상 에이전트 사이의 인터페이스 역할을 한다.

권한을 단계별로 나눠 부여하기

모든 Worker에게 파일 수정 권한을 줄 필요는 없다. 조사를 맡은 Worker는 읽기 전용으로 두고, 구현을 맡은 Worker만 제한된 범위에서 수정할 수 있게 하며, 검토를 맡은 Worker는 수정 없이 문제만 지적하도록 나눠두면 예기치 않은 변경을 줄일 수 있다.

중간 결정을 기록해두기

Orchestrator가 왜 특정 작업을 만들었는지, 여러 Worker의 결과 중 어떤 것을 채택했는지를 기록해두면 나중에 실패 원인을 분석하기 쉬워진다. 이런 기록이 없으면 멀티 에이전트 시스템은 겉으로는 정교해 보여도 내부 의사결정 과정을 다시 재현하기 어렵다.

주의할 점

에이전트 수를 늘리는 것 자체가 결과의 품질을 끌어올리지는 않는다. 작업이 단순한데도 Worker를 지나치게 많이 두면 조율에 드는 비용이 오히려 커지고, 비슷한 결론을 여러 번 검토하는 데 시간이 낭비된다. 병렬로 처리하기에 유리한 작업인지, 순서대로 처리해야 하는 작업인지를 먼저 구분해야 한다.

또 하나 흔히 생기는 문제는 Worker들이 서로의 작업 내용을 모른 채 같은 파일이나 같은 결정을 동시에 건드리는 경우다. 코드를 수정하는 작업에서는 특히 이런 충돌이 자주 발생한다. Orchestrator가 파일 범위와 책임을 미리 나눠주고, 최종적으로 결과를 합치기 전에 한 번 더 검토하는 과정을 반드시 거치도록 설계해야 한다.

정리

멀티 에이전트 시스템은 여러 모델을 단순히 연결하는 기술보다, 역할과 경계를 어떻게 설계하느냐가 더 중요한 문제다. Orchestrator는 목표 해석과 작업 분해, 결과 취합을 맡고 Worker는 작고 명확한 실행을 담당하는 구조가 기본 골격이 된다. 출력 형식과 권한 범위를 고정해두면 시스템의 동작을 예측하기 쉬워지고, 문제가 생겼을 때도 어느 지점을 고쳐야 하는지 훨씬 빠르게 찾을 수 있다.