56일차 회고｜Supervisor·Worker·Output Contract｜AI 오케스트레이션 개발자 국비지원

 

오늘은 멀티에이전트 오케스트레이션에서 Supervisor가 어떤 역할을 하는지 직접 실행 결과를 확인하고, 이를 이사 준비 체크리스트 서비스에 적용하는 실습을 진행했다.

단순히 여러 Agent를 순서대로 실행하는 것과 Supervisor가 각 결과를 판단하면서 다음 작업을 결정하는 것은 생각보다 차이가 컸다. 특히 실제 결과가 기준에 맞지 않으면 같은 Worker를 다시 실행할 수 있다는 점이 Supervisor의 핵심적인 특징이라는 것을 확인했다.

---

오늘 배운 내용

오늘 수업에서는 크게 Router와 Supervisor의 차이, Supervisor의 평가와 재작업, YAML 기반 Agent 구성, Output Contract 검증, 그리고 Handoff를 활용한 서비스 확장을 다뤘다.

Router는 사용자의 요청을 보고 적절한 Agent나 오케스트레이션으로 분기하는 역할에 가깝다.

반면 Supervisor는 이미 실행된 Worker의 결과까지 확인한 뒤,

"이 결과가 충분한가?"

를 판단하고 다음에 무엇을 할지 결정한다.

따라서 Supervisor에서는 단순한 순차 실행보다 평가 기준과 종료 조건을 어떻게 설계하느냐가 중요했다.

---

Supervisor는 단순한 순차 실행과 달랐다

실습에서 Reviewer가 한 번 실행된 뒤 작업이 끝나는 것이 아니라, Reviewer의 결과를 Supervisor가 다시 확인하고 Reviewer를 한 번 더 호출하는 상황을 확인했다.

일반적인 Sequence라면 다음과 같이 진행된다.

Analyst → Developer → Reviewer → Finish

하지만 Supervisor 구조에서는 결과에 따라 흐름이 달라질 수 있다.

Supervisor
    ↓
Analyst
    ↓
Supervisor
    ↓
Reviewer
    ↓
Supervisor
    ↓
Reviewer 재실행
    ↓
Supervisor
    ↓
Finish

예산 가이드와 실제 계산 결과가 맞지 않는 상황처럼 검토 결과가 기준을 만족하지 못하면 다시 작업시키는 것이다.

이 부분에서 Supervisor가 단순히 여러 Agent를 연결하는 역할이 아니라는 것을 확실히 이해할 수 있었다.

---

Output Contract가 왜 중요한지도 다시 확인했다

앞선 수업에서 Output Contract를 배웠지만, 오늘은 Supervisor와 연결하면서 그 의미가 더 명확해졌다.

Output Contract는 쉽게 말하면 Agent가 어떤 형식과 내용을 갖춘 결과를 반환해야 하는지 정의한 약속이다.

예를 들어 Worker가 결과를 만들었다고 해서 무조건 다음 Worker에게 전달하는 것이 아니라,

Worker 실행
   ↓
Output Contract 검증
   ↓
정상인가?
 ├─ Yes → Supervisor 평가
 └─ No → 오류 처리 / 재작업

과정을 거쳐야 한다.

특히 단순히 필드가 존재하는지만 확인하는 형식 검증과 함께 누락, 중복, 잘못된 ID, 원문 근거 등의 의미적인 문제까지 확인하는 것이 중요했다.

---

직접 진행한 이사 준비 멀티에이전트 실습

오늘 실제로는 이사 준비 체크리스트를 생성하는 멀티에이전트 서비스를 만들어보면서 수업 내용을 적용했다.

목표는 사용자가 이사 정보를 입력하면 이사 전·당일·후에 필요한 체크리스트를 만들어주는 것이다.

중요한 점은 실제 예약이나 견적, 신고를 대신 처리하는 서비스가 아니라 Supervisor–Worker, Output Contract, Mock MCP Tool, API와 화면 연결을 학습하기 위한 과제라는 점이다.

기본 시나리오는 다음과 같이 구성했다.

• 출발지: 관악푸르지오 2차 아파트
• 도착지: 수유동 벽산아파트
• 이사일: 2026년 10월 9일
• 이사 종류: 일반이사
• 가져갈 물품과 판매·폐기 물품
• 가스·에어컨·인터넷 관련 사항
• 엘리베이터와 주차 공간 등 아직 확인하지 못한 정보

현재 구현된 구조에서는 YAML로 선언한 Agent를 Loader와 Registry를 통해 실제 LLM Runtime과 연결하고, Mock MCP Tool을 이용해 준비 항목을 제공하도록 구성했다.

또한 참고사항을 별도의 Agent가 구조화된 결과로 정리하고, Pydantic 기반 계약 검증을 거치도록 했다.

---

실제 오류를 통해 Supervisor 구조를 확인했다

이번 실습에서 가장 기억에 남는 부분은 실제 오류가 발생했던 과정이다.

일정 Agent가 사용자 정보에서 "자녀·반려동물 없음"이라는 내용을 보고 관련 항목을 삭제했는데, 이 때문에 계약 검증에서 문제가 발생했다.

이후 Supervisor가 일정 결과 없이 종료를 선택하면서 invalid_transition까지 발생했다.

이 문제를 해결하면서 다음과 같이 보완했다.

• 해당 없음으로 판단한 항목도 내부 계약에는 유지
• 검증 오류에 누락·중복·잘못된 ID를 구체적으로 전달
• 식별자는 영문 원래 값을 유지하고 설명만 한글화
• 필수 Worker의 재시도 횟수를 제한
• 불필요한 추가 호출을 줄이고 종료 이유를 화면에 한글로 표시

다만 개발 속도를 우선했기 때문에 최근 변경 사항 전체에 대한 실제 LLM 정상 실행까지 최종 검증한 상태는 아니다.

이 부분은 회고에서 반드시 구분해둘 필요가 있다. 구현한 것과 실제 전체 흐름을 검증한 것은 다른 문제이기 때문이다.

---

Supervisor 구조를 어떻게 개선할 것인가

현재 구현은 단계별 Worker 중심으로 구성되어 있지만, 이후에는 업무 분야별 Worker로 재구성할 계획을 세웠다.

Supervisor
 ├─ 참고사항 정리
 ├─ 물품·포장
 ├─ 판매·폐기
 ├─ 생활 서비스
 └─ 주거·당일

예를 들어 생활 서비스 Worker가

가스 연결 분리 후 판매

라는 선행 작업을 발견하면 판매·폐기 Worker가 이를 체크리스트에 반영할 수 있도록 Supervisor가 결과를 전달한다.

여기서 중요한 것은 Worker끼리 직접 대화하는 것이 아니라 Supervisor가 검증된 계약을 기준으로 다음 Worker에게 전달하는 구조라는 점이다.

---

Supervisor에는 평가 기준과 최대 실행 횟수가 필요하다

오늘 실습을 통해 Supervisor의 또 다른 문제도 알게 됐다.

평가 기준이 명확하지 않으면 Supervisor가 계속 같은 Worker를 호출할 수 있다.

따라서 다음과 같은 요소가 필요하다.

• 결과 평가 기준
• 재작업 조건
• 다음 Worker로 넘어가는 조건
• 완료 조건
• 최대 호출 또는 Step 제한

즉,

결과 생성
   ↓
Supervisor 평가
   ↓
충분함 ─────────→ 완료
   │
   └─ 부족함 → 재작업
                 ↓
              재평가

라는 루프를 만들되, 무한 반복되지 않도록 제한을 두어야 한다.

---

Handoff를 실제 서비스와 연결해서 생각해봤다

오늘은 Handoff의 의미도 다시 연결해서 생각해볼 수 있었다.

예를 들어 여행 일정을 만드는 오케스트레이션이 끝났다면 그 결과를 다음 서비스로 넘겨

여행 일정 생성
      ↓
Handoff
      ↓
Google Calendar 등록

하는 식으로 확장할 수 있다.

메일이나 Slack, Discord 같은 외부 서비스에 결과를 전달하는 것도 같은 방식으로 생각할 수 있다.

이때 캘린더 등록이나 메시지 전송 자체가 반드시 새로운 오케스트레이션일 필요는 없고, Tool이나 별도의 Agent가 담당할 수 있는 작업이라는 점도 이해했다.

결국 AI가 답변만 생성하는 것이 아니라,

생성 → 사용자 확인 → 외부 시스템에서 실제 행동

까지 이어지는 구조로 확장할 수 있다는 것이다.

---

오늘 새롭게 이해한 점

처음에는 멀티에이전트라고 하면 Agent를 여러 개 만들고 순서대로 실행하면 된다고 생각하기 쉬웠다.

하지만 오늘 실습을 하면서 중요한 것은 Agent의 개수보다 각 Agent의 책임과 결과를 어떻게 검증하고 연결하는가라는 것을 알게 됐다.

특히 Supervisor는 단순히 "다음 Agent를 골라주는 역할"이 아니라,

현재 결과를 평가하고, 부족하면 다시 작업시키며, 충분하면 다음 단계로 넘기거나 종료하는 관리자

에 가깝다는 점이 명확해졌다.

또 하나 중요했던 점은 시나리오를 먼저 정하고 그다음 Agent와 오케스트레이션 패턴을 설계해야 한다는 것이다.

처음부터 Supervisor를 사용하기 위해 억지로 복잡한 시나리오를 만드는 것보다, 실제 문제를 정의한 뒤 Sequence, Parallel, Router, Supervisor 중 어떤 구조가 적합한지를 판단하는 것이 더 자연스러운 설계라는 것도 배웠다.

---

현재 나의 상태

현재는 YAML 기반 Agent를 등록하고 Runtime에 연결하는 과정부터 Output Contract 검증, Supervisor 기반 오케스트레이션, API와 화면 연결까지 전체적인 구조를 직접 다뤄볼 수 있는 상태가 되었다.

특히 이번에는 단순한 예제만 따라간 것이 아니라 내가 정한 이사 준비라는 주제를 실제 서비스 형태로 구성하면서 오류도 직접 경험했다.

다만 아직 모든 변경 사항에 대한 최종 LLM 실행 검증을 끝낸 것은 아니기 때문에, 구현 구조를 이해한 것과 안정적으로 동작하는 서비스를 만든 것은 구분해야 한다.

앞으로는 Supervisor의 평가 기준을 더 명확하게 만들고, 실제 재작업과 종료 조건이 의도대로 동작하는지 테스트하는 것이 필요하다.

---

오늘의 회고

오늘 가장 크게 배운 것은 Supervisor의 핵심은 "선택"보다 "평가"에 있다는 것이다.

Worker를 여러 개 실행하는 것 자체는 어렵지 않지만, Worker가 만든 결과를 보고 무엇이 부족한지 판단하고 다시 작업시킬 수 있도록 만드는 것은 별도의 설계가 필요했다.

특히 실제 이사 체크리스트를 만들면서 계약 검증 오류가 발생하고, 그 오류가 Supervisor의 종료 판단까지 영향을 주는 과정을 경험하면서 Agent → Contract → Supervisor → 재작업이 서로 분리된 개념이 아니라 하나의 흐름으로 연결되어 있다는 것을 이해하게 됐다.

아직 완성된 서비스라고 할 수는 없지만, 오늘은 멀티에이전트 시스템을 단순히 "Agent 여러 개를 연결하는 것"으로 보는 단계에서 벗어나 결과를 검증하고 필요하면 다시 실행하는 오케스트레이션 구조를 직접 설계해본 날이었다.

복습할 부분

• Router와 Supervisor의 역할 차이
• Supervisor 평가 기준 작성
• Output Contract의 형식 검증과 의미 검증
• Supervisor 재작업 조건
• 최대 Step/호출 제한
• Handoff와 Tool의 차이
• YAML Agent 정의 → Loader → Registry → Runtime 흐름