52일차 회고｜멀티에이전트 오케스트레이션 패턴과 Handoff｜AI 오케스트레이션 개발자 국비지원

 

52일차에는 지금까지 배운 멀티에이전트 구조를 실제 서비스 관점에서 다시 정리하고, 여러 에이전트를 어떤 방식으로 연결하고 운영할 것인지를 집중적으로 학습했다.

특히 Anthropic에서 소개한 에이전트 워크플로우 패턴을 기반으로 Prompt Chaining, Parallelization, Routing, Supervisor-Worker, Evaluator-Optimizer를 살펴봤고, 여기에 Contract, Handoff, Trace, Failover까지 연결하면서 멀티에이전트 시스템을 설계할 때 고려해야 할 요소가 생각보다 많다는 것을 알게 됐다.

---

오늘 배운 내용

이번 수업의 시작은 미니 프로젝트를 준비하면서 기존에 배운 내용을 다시 정리하는 것이었다.

지금까지는 하나의 AI Agent가 여러 Tool이나 MCP 서버를 사용하는 구조를 주로 다뤘다면, 이제는 하나의 Agent가 모든 일을 처리하는 대신 역할별로 Agent를 나누고 이들을 Orchestrator가 연결하는 구조를 만들어야 했다.

여기서 중요한 것은 단순히 Agent의 개수를 늘리는 것이 아니었다.

예를 들어 여행 서비스를 만든다고 하면,

• Weather Agent
• Place Agent
• Budget Agent

처럼 역할을 나눌 수 있다.

하지만 이 세 개를 만들어 놓고 각각 같은 질문을 던진 뒤 결과를 모으는 것만으로는 충분하지 않다.

어떤 Agent가 어떤 데이터를 볼 수 있는지, 어떤 Tool을 사용할 수 있는지, 결과를 어떤 형식으로 넘겨줄 것인지, 어떤 순서로 실행할 것인지까지 설계해야 한다.

결국 멀티에이전트에서 중요한 것은 역할 분리와 에이전트 간 연결 방식이라는 점을 다시 확인했다.

---

1. Prompt Chaining

가장 먼저 살펴본 것은 Prompt Chaining이었다.

Prompt Chaining은 여러 Agent를 순서대로 연결하는 방식이다.

예를 들어 부산 여행 안내문을 만든다면 다음과 같은 구조가 될 수 있다.

사용자 요청
   ↓
Research Agent
   ↓
Writer Agent
   ↓
Reviewer Agent
   ↓
최종 결과

Research Agent가 조사한 결과를 Writer Agent에게 전달하고, Writer Agent가 작성한 결과를 Reviewer Agent에게 전달하는 방식이다.

여기서 중요한 개념이 Contract였다.

Contract는 법적인 계약이 아니라 Agent와 Agent 사이에서 어떤 데이터를 주고받을 것인지 정해놓은 규칙이다.

예를 들어 Writer Agent가 Research Agent의 결과를 받는다면 어떤 형식의 데이터를 받을 것인지 미리 정의해야 한다.

Research Agent
Input  → 사용자 요청
Output → 조사 결과

Writer Agent
Input  → 사용자 요청 + 조사 결과
Output → 작성된 문서

이런 규칙이 명확해야 여러 Agent를 연결했을 때 예상하지 못한 데이터가 전달되는 문제를 줄일 수 있다.

---

2. Trace와 실행 상태 관리

멀티에이전트 구조를 배우면서 생각보다 중요하게 느껴졌던 부분은 Trace였다.

Agent가 하나라면 문제가 발생했을 때 어디서 문제가 생겼는지 비교적 찾기 쉽다.

하지만 여러 Agent가 순서대로 실행된다면 상황이 달라진다.

Research 시작
Research 완료
Writer 시작
Writer 완료
Reviewer 시작
Reviewer 실패

이런 실행 과정을 기록해두어야 문제가 발생한 위치를 알 수 있다.

수업에서는 단순히 배열에 Trace를 기록하는 예제를 살펴봤지만, 실제 서비스에서는 Redis나 데이터베이스 등에 저장하는 방식으로 확장할 수 있다고 배웠다.

특히 이 Trace를 사용자 화면과 연결하면 활용도가 더 커진다.

Redis에 실행 상태를 저장하고 이를 SSE(Server-Sent Events)를 이용해 프론트엔드에 전달하면 사용자는 단순히 로딩 화면만 보는 것이 아니라,

Research Agent 실행 중
Research 완료
Writer Agent 실행 중
Reviewer 실행 중

처럼 현재 시스템이 무엇을 하고 있는지 확인할 수 있다.

멀티에이전트 서비스에서는 사용자 입장에서 "아무것도 안 하고 기다리는 것처럼 보이는 문제"를 줄이는 것도 중요하다는 점을 알게 됐다.

---

3. Parallelization과 Joining

다음으로는 여러 Agent를 동시에 실행하는 Parallelization을 살펴봤다.

예를 들어 어떤 기업의 경제 상황을 분석한다고 하면 여러 경제지표를 각각 독립적으로 조회할 수 있다.

              ┌─ 경제지표 A ─┐
사용자 요청 → ├─ 경제지표 B ─┤ → Aggregator
              └─ 경제지표 C ─┘

각 Agent가 독립적으로 실행된 뒤 결과를 하나로 합치는 과정을 Join 또는 Aggregation이라고 한다.

다만 여기서 중요한 점이 있었다.

병렬 실행이 항상 좋은 것은 아니다.

여행 계획을 예로 들면 날씨를 확인한 다음 그 날씨에 맞는 장소를 선택하고, 선택된 장소를 바탕으로 여행 일정을 구성하는 것이 더 자연스러울 수 있다.

날씨 → 장소 → 여행 일정

이 경우에는 Prompt Chaining이 적합하다.

반대로 서로 독립적인 경제지표를 수집하는 작업이라면 Parallelization이 더 자연스러울 수 있다.

결국 중요한 것은 특정 패턴을 무조건 사용하는 것이 아니라 작업의 의존관계를 보고 적절한 패턴을 선택하는 것이었다.

---

4. Routing과 패턴의 조합

Routing은 사용자의 요청을 먼저 분류한 뒤 적절한 Agent나 워크플로우로 보내는 방식이다.

예를 들어 고객지원 시스템이라면,

사용자 요청
    ↓
Router
 ┌──┼──────────┐
 ↓  ↓          ↓
배송 환불    기술문의
 ↓  ↓          ↓
Delivery Refund Technical

처럼 구성할 수 있다.

그런데 여기서 끝나는 것이 아니라 Routing 이후에 다른 패턴을 연결할 수도 있다.

예를 들어 부산 여행을 요청하면 Prompt Chaining을 실행하고, 주식 분석을 요청하면 여러 경제지표를 Parallel하게 수집한 뒤 Aggregation할 수 있다.

즉,

사용자 요청
     ↓
   Router
   ↙   ↘
여행     주식
 ↓        ↓
Chaining Parallel
          ↓
       Aggregation

처럼 하나의 시스템 안에서도 여러 패턴이 조합될 수 있다.

이번 수업에서 가장 중요했던 부분 중 하나가 바로 이것이었다.

5가지 패턴 중 하나가 정답인 것이 아니라, 실제 서비스의 요구사항에 따라 여러 패턴을 조합해서 하나의 오케스트레이션을 만드는 것이다.

---

5. Supervisor-Worker

기존의 Orchestrator는 실행 순서를 미리 정해놓을 수 있었다.

예를 들어 항상

Research → Writer → Reviewer

순서로 실행하도록 만드는 것이다.

반면 Supervisor-Worker 구조에서는 Supervisor가 사용자의 요청과 각 Agent의 결과를 보고 어떤 Worker를 실행할지 결정할 수 있다.

예를 들어 코드 관련 요청이라면,

사용자 요청
   ↓
Supervisor
   ↓
Analysis → Developer → Reviewer

가 될 수 있지만, 단순히 코드 리뷰만 요청했다면,

사용자 요청
   ↓
Supervisor
   ↓
Reviewer

만 실행할 수도 있다.

즉, 실행 흐름을 미리 하나로 고정해놓는 것이 아니라 요청에 따라 필요한 Agent를 선택하고 실행 흐름을 만들어가는 방식이다.

이 구조를 배우면서 평소 AI 코딩 도구를 사용할 때 보이는 분석 → 코드 작성 → 리뷰 같은 과정도 Agent 관점에서 생각해볼 수 있었다.

---

6. Evaluator-Optimizer

8교시에는 Evaluator-Optimizer 패턴을 학습했다.

기본적인 구조는 다음과 같다.

Generator
   ↓
Evaluator
   ↓
Feedback
   ↓
Generator 수정
   ↓
Evaluator 재평가
   ↺

한 번 생성하고 끝내는 것이 아니라 결과를 평가하고, 평가 결과를 다시 생성 과정에 반영하는 방식이다.

예를 들어 여행 안내문이나 회사의 제안서 같은 문서를 작성한다고 해보자.

Evaluator에게 다음과 같은 평가 기준을 줄 수 있다.

• 일정한 글자 수 이상인가?
• 반드시 포함되어야 할 정보가 있는가?
• 금지된 표현이 포함되어 있지는 않은가?
• 요구사항을 모두 충족했는가?

그리고 점수 기준을 추가할 수도 있다.

예를 들어 80점 이상이면 통과하고, 80점 미만이면 Feedback을 Generator에게 전달해서 다시 작성하도록 만드는 식이다.

그런데 여기서 어려운 부분은 평가 기준을 어떻게 정의하느냐였다.

사람에게 "좋은 부산 여행 안내문인지 평가해줘"라고 하면 어느 정도 판단할 수 있지만, Agent에게 평가를 맡기려면 "좋다"라는 기준을 구체적인 규칙으로 바꿔야 한다.

또 하나 주의할 점은 무한 반복이었다.

평가 기준을 통과할 때까지 계속 수정하도록 만들어 놓으면 10번, 20번 이상 반복될 수도 있다.

따라서 최대 반복 횟수를 설정해야 하고, 최대 횟수에 도달했을 때 어떻게 처리할지도 정해야 한다.

실습 예제에서는 최대 반복 횟수를 5회로 설정했지만 실제 실행에서는 3번의 반복만으로 최종 결과가 만들어지는 것을 확인했다.

즉, 조건을 만족하면 불필요한 반복을 하지 않고 종료하도록 만드는 것도 중요한 설계였다.

---

7. Failover

멀티에이전트 서비스를 실제로 운영하려면 LLM 자체의 장애도 고려해야 한다는 점을 배웠다.

수업에서는 Gemma를 먼저 사용하다가 연결에 문제가 발생하면 OpenAI로 전환하는 예제를 실행했다.

Agent
 ↓
Gemma 실행
 ↓
Connection Error
 ↓
OpenAI로 전환
 ↓
결과 반환

실제로 Gemma가 정상적으로 동작할 때와 컨테이너를 중지한 뒤 다시 실행했을 때의 결과가 달라지는 것을 확인하면서 Failover 흐름을 살펴봤다.

Failover는 쉽게 말해 주로 사용하던 시스템에 문제가 발생했을 때 다른 시스템으로 전환해서 서비스를 계속 유지하는 방식이다.

멀티에이전트에서는 여러 Agent가 서로 다른 LLM을 사용할 수도 있기 때문에 이런 장애 대응 구조가 더욱 중요해질 수 있다.

특히 특정 Agent 하나의 LLM 문제가 전체 서비스 중단으로 이어지지 않도록 백업 경로를 고려해야 한다는 점을 배웠다.

---

8. Handoff

이번 학습에서 또 하나 중요했던 개념은 Handoff였다.

Handoff는 현재 작업을 수행하던 Agent가 자신의 책임을 마치고 다른 Agent에게 작업을 넘기는 것이다.

예를 들어 고객지원 Agent가 배송 지연 문제를 처리하다가 고객이 환불을 요청했다고 해보자.

Support Agent
     ↓
환불 요청 확인
     ↓
Refund Agent
     ↓
환불 처리

Support Agent가 Refund Agent에게 단순히 "환불해주세요"라고 전달하는 것이 아니라,

• 사용자 ID
• 주문 ID
• 환불 대상
• 수량
• 환불 사유

등 Refund Agent가 처리하는 데 필요한 데이터를 전달해야 한다.

여기에서도 Contract가 연결된다.

Contract는 어떤 데이터를 주고받을지에 대한 규칙이고, Handoff는 실제로 작업과 데이터를 다음 Agent에게 넘기는 과정이라고 이해했다.

---

9. 미니 프로젝트 준비

수업 후반에는 앞으로 진행할 미니 프로젝트 환경을 준비했다.

이번 프로젝트는 기존에 만들어진 예제를 단순히 실행하는 것보다 멀티에이전트와 여러 오케스트레이션 패턴을 Frontend, Backend, MCP Server로 나누어 구성하는 것을 목표로 한다.

특히 이번에는 Mock 데이터만 사용하는 방식에서 벗어나 데이터베이스 연동까지 고려해야 한다.

또한 수업에서 계속 사용했던 구조를 그대로 따라 만드는 것이 아니라,

• Backend
• Frontend
• MCP Server

를 각각 독립적인 서비스로 구성하고 Docker 이미지로 만들며, CI/CD와 실제 배포까지 고려해야 한다.

그래서 이번에는 단순히 코드를 작성하는 것보다 어떤 서비스를 독립시키고 어떻게 배포할 것인지에 대한 전략적인 설계가 중요하다는 설명을 들었다.

---

새롭게 이해한 점

처음 멀티에이전트를 배울 때는 단순하게 생각했다.

"하나의 Agent가 하던 일을 여러 Agent로 나누면 멀티에이전트다."

하지만 이번 학습을 거치면서 이것만으로는 부족하다는 것을 알게 됐다.

실제로 중요한 것은 Agent의 개수보다 역할과 책임의 경계였다.

각 Agent가 어떤 목적을 가지고 있는지, 어떤 Context를 볼 수 있는지, 어떤 Tool을 사용할 수 있는지, 어떤 형식으로 결과를 반환하는지, 다음 Agent에게 어떻게 전달할 것인지까지 정의해야 한다.

그리고 그 위에 Orchestrator나 Supervisor가 Agent들을 연결해야 한다.

결국 멀티에이전트 시스템은 단순히 AI를 여러 개 붙이는 작업이 아니라 하나의 복잡한 업무를 여러 책임 단위로 나누고, 그 사이의 흐름을 설계하는 작업에 가깝다는 생각이 들었다.

---

현재 나의 상태

52일차까지 학습하면서 이제 멀티에이전트의 여러 기본 패턴을 구분해서 볼 수 있게 됐다.

• 순차적인 작업 → Prompt Chaining
• 독립적인 작업 → Parallelization
• 요청에 따른 분기 → Routing
• 동적으로 Worker를 선택 → Supervisor-Worker
• 생성 결과를 반복적으로 개선 → Evaluator-Optimizer
• Agent 사이의 책임 전달 → Handoff
• Agent 간 데이터 규칙 → Contract
• 실행 과정 기록 → Trace
• 장애 발생 시 다른 Provider로 전환 → Failover

이제 각각의 개념이 무엇인지는 어느 정도 정리됐지만, 아직은 여러 패턴을 실제 프로젝트에서 어떻게 조합할 것인지가 더 중요한 과제로 남아 있다.

특히 실제 서비스에서는 LLM 호출 비용, 응답 속도, 장애 가능성, 데이터 격리, Tool 권한, 상태 관리까지 함께 고려해야 하기 때문에 단순한 예제보다 훨씬 복잡해질 것 같다.

---

앞으로 보완할 부분

앞으로 진행할 미니 프로젝트에서는 지금까지 배운 패턴을 실제 구조로 옮겨보는 것이 중요할 것 같다.

특히 다음 부분을 직접 경험해보고 싶다.

1. Agent별 역할과 Contract를 명확하게 설계하기
2. 여러 패턴을 실제 하나의 workflow로 조합하기
3. Redis와 Trace를 이용한 실행 상태 관리
4. SSE를 이용한 프론트엔드 상태 전달
5. LLM Failover 구현
6. Backend / Frontend / MCP Server의 독립적인 Docker 구성
7. CI/CD를 통한 실제 배포
8. DB와 MCP Server까지 포함한 전체 서비스 구조 이해하기

지금까지는 각각의 기술과 패턴을 하나씩 학습했다면, 이제부터는 이 기술들을 하나의 서비스 안에서 어떻게 연결할 것인지가 핵심이 될 것 같다.

---

오늘의 회고

52일차는 새로운 기술 하나를 깊게 파고든 날이라기보다, 지금까지 배운 멀티에이전트 개념을 하나의 시스템 설계 관점에서 연결해본 날에 가까웠다.

특히 기억에 남은 것은 "멀티에이전트 = Agent를 많이 만드는 것"이 아니라는 점이다.

Agent마다 명확한 역할을 부여하고, 필요한 Context와 Tool 권한을 분리하고, Contract를 통해 데이터를 주고받고, Orchestrator나 Supervisor가 실행 흐름을 관리해야 한다.

여기에 실제 서비스가 되면 Trace, Redis, SSE, Failover, Docker, CI/CD 같은 운영 요소까지 추가된다.

결국 앞으로의 미니 프로젝트에서는 단순히 "AI가 결과를 잘 만들어냈다"는 것보다 여러 Agent가 어떤 구조로 협업하고, 문제가 발생했을 때 어떻게 추적하고 복구할 수 있는지까지 보여주는 것이 중요할 것 같다.

이제 개념을 배우는 단계에서 조금씩 벗어나서, 배운 패턴을 실제 서비스 구조로 조합하는 단계로 넘어가고 있다.