57일차 회고｜멀티 에이전트 실행 흐름과 검증｜AI 오케스트레이션 개발자 국비지원

 

57일차에는 지금까지 배운 Agent, Output Contract, Handoff, Supervisor, Router 개념을 실제 실행 흐름과 연결해서 살펴봤다. 특히 에이전트가 결과를 만들어내는 것만으로 끝나는 것이 아니라, 다음 단계로 넘길 수 있는 결과인지 검증하고 실패 상황까지 고려해야 한다는 점을 실습을 통해 확인했다.

오늘 배운 내용

오늘 수업에서는 멀티 에이전트 시스템을 구성할 때 필요한 여러 요소를 하나의 실행 흐름으로 연결해서 살펴봤다.

• Agent와 Output Contract
• Handoff와 Context 전달
• Validation과 Guard
• Supervisor와 Router
• Sequential / Parallel 실행
• YAML 기반 Agent 및 Workflow 설정
• 필수·선택 작업과 실패 정책
• Timeout
• API 및 실제 데이터 활용
• 데이터 수집 → 검증 → 통합 → 작성 → 리뷰 흐름

앞선 수업에서 각각의 개념을 따로 배웠다면, 오늘은 이 개념들이 실제 실행 과정에서 어떻게 연결되는지에 초점을 맞췄다.

---

Output Contract가 실제 실행에서 필요한 이유

실습에서는 사용자의 질문과 시스템 메시지, 그리고 미리 정의한 출력 스키마(Output Contract)를 LLM에 전달하고 그 결과를 다음 단계에서 사용하는 흐름을 확인했다.

Output Contract는 쉽게 말하면 에이전트가 어떤 형태의 결과를 반환해야 하는지 미리 약속해놓은 규칙이다.

예를 들어 Support Agent가 사용자의 질문을 보고 다음과 같이 판단할 수 있다.

• 환불 관련 → Refund Agent
• 배송 관련 → Delivery Agent
• 기술 지원 → Technical Support Agent

이때 단순히 "환불 에이전트로 보내세요"라는 문자열만 반환하는 것이 아니라, 다음 에이전트와 판단 이유, 전달해야 할 맥락 등을 정해진 구조로 반환하도록 만들 수 있다.

이 과정을 보면서 Output Contract가 단순히 문서에 적어놓는 설계 요소가 아니라, 실제로 에이전트 사이의 데이터를 연결하는 기준이라는 것을 이해할 수 있었다.

---

Handoff는 에이전트뿐 아니라 Context를 넘기는 과정

이어서 Handoff가 실제로 어떻게 이루어지는지도 확인했다.

Handoff는 한 에이전트가 처리하던 작업을 다른 에이전트에게 넘기는 과정이다. 중요한 것은 단순히 다음 에이전트의 이름만 전달하는 것이 아니라, 다음 에이전트가 작업을 이어가기 위해 필요한 정보까지 함께 전달하는 것이다.

환불 예제에서는 주문번호와 배송 지연 사유 같은 정보가 다음 에이전트에게 전달됐다.

즉,

이전 Agent의 결과 → 필요한 Context 구성 → 다음 Agent에게 Handoff → 다음 Agent가 처리

와 같은 흐름이다.

Handoff가 이루어진 이후에는 다음 에이전트가 해당 작업의 처리 주체가 된다.

이를 통해 멀티 에이전트 시스템에서 에이전트를 여러 개 만드는 것보다 각 에이전트가 어떤 정보를 받고 어떤 책임을 맡는지를 명확하게 정의하는 것이 중요하다는 점을 다시 확인했다.

---

예산 합계 오류를 통해 확인한 Validation의 필요성

오늘 가장 인상적으로 이해한 부분은 LLM의 결과를 그대로 믿고 다음 단계로 넘겨서는 안 된다는 것이었다.

예산을 작성하는 실습에서 총액과 항목별 금액의 합계가 일치하지 않는 오류가 발생했다.

LLM은 자연스러운 형태의 결과를 만들어냈지만, 실제 계산 결과가 맞는지는 별개의 문제였다.

예를 들어 항목별 금액이 다음과 같이 나왔다면,

교통비: 100,000원
식비: 200,000원
숙박비: 300,000원

각 항목의 합계가 실제로 총액과 일치하는지 별도로 확인해야 한다.

여기서 Validation과 Guard의 차이도 함께 이해할 수 있었다.

Validation

결과가 정해진 형식과 구조를 만족하는지 확인한다.

예를 들어:

• 필수 필드가 있는가?
• 숫자가 들어가야 하는 곳에 숫자가 들어갔는가?
• Output Schema에 맞는가?

Guard

형식뿐 아니라 실제 다음 단계로 진행해도 되는 상태인지 판단한다.

예를 들어:

• 총액과 항목별 금액이 일치하는가?
• 환불 처리를 위한 주문번호가 존재하는가?
• 필수 정보가 충분한가?
• 업무 규칙을 만족하는가?

결국 다음과 같은 흐름으로 생각할 수 있었다.

Agent 실행 → Output Validation → Business Guard → 다음 단계 실행

만약 검증에 실패하면 무조건 다음 Agent로 넘어가는 것이 아니라 재시도하거나 복구하거나 실행을 중단하는 등의 정책이 필요하다.

이 부분은 지금까지 배운 멀티 에이전트 구조를 단순한 "LLM 여러 개 연결하기"와 구분해주는 중요한 부분이라고 느꼈다.

---

병렬 실행에서는 실패 정책도 함께 설계해야 한다

오늘은 여러 Agent를 동시에 실행하는 Parallel 실행도 살펴봤다.

예를 들어 여행 정보를 수집한다고 하면,

        ┌─ 날씨 Agent ─┐
사용자 ─┼─ 장소 Agent ─┼→ 결과 통합
        └─ 예산 Agent ─┘

처럼 서로 독립적인 작업을 동시에 실행할 수 있다.

하지만 여기서 단순히 "병렬로 실행하면 빨라진다"라고 생각하면 부족했다.

실습에서는 날씨와 예산은 필수 작업, 장소 정보는 선택 작업으로 구분했다.

따라서:

• 날씨 실패 → 전체 작업 중단
• 예산 실패 → 전체 작업 중단
• 장소 실패 → 다른 결과로 계속 진행

과 같이 실패에 대한 정책을 다르게 설정할 수 있다.

또한 오래 걸리는 작업을 계속 기다리지 않도록 Timeout도 고려했다.

결국 병렬 실행을 설계할 때는 다음 질문까지 함께 생각해야 한다.

어떤 작업이 반드시 필요한가?
어떤 작업은 실패해도 괜찮은가?
어느 정도까지 기다릴 것인가?
일부 결과만 가지고도 최종 결과를 만들 수 있는가?

병렬화는 단순한 성능 개선이 아니라 실패 허용 범위와 결과 통합 방법까지 함께 설계하는 문제라는 것을 이해했다.

---

YAML 설정이 실제 실행 코드로 연결되는 구조

오늘은 Agent와 Workflow를 YAML 형태로 정의하는 방식도 확인했다.

설정 파일에 Agent의 정보와 실행 흐름을 정의하고, Loader와 Registry가 이 설정을 읽어 프로그램에서 사용할 수 있는 구조로 연결하는 방식이다.

처음에는 YAML에 Agent를 정의하는 것 자체가 설계 문서에 가까운 작업처럼 느껴질 수 있지만, 실제로는 이 설정이 실행 코드와 연결되어야 의미가 있다.

즉,

YAML 설정 → Loader → Registry → Agent/Workflow 실행

이라는 구조를 통해 설계와 실제 실행을 연결하는 방법을 확인했다.

---

실제 데이터 활용까지 확장하기

후반부에는 멀티 에이전트 시스템에서 실제 데이터를 사용하는 방법까지 살펴봤다.

공공데이터포털의 Open API와 기상청 데이터를 예로 들어 API 문서를 확인했고,

• 인증키
• 요청 URL
• 지역 코드
• 발표 시각
• 요청 파라미터
• 응답 형식

등을 확인하는 과정도 다뤘다.

또한 모든 데이터를 API로 가져오는 것은 아니다.

CSV나 PDF처럼 이미 존재하는 정적 데이터는 RAG나 데이터베이스 등에 활용할 수 있고, 실시간으로 변화하는 데이터는 API나 도구를 통해 가져오는 방식으로 구분할 수 있다.

결국 실제 AI 시스템에서는 에이전트의 구조뿐 아니라 어떤 데이터를 어디에서 가져오고, 어떤 방식으로 검증할 것인지까지 함께 설계해야 한다.

---

여기서 더 확장할 수 있는 에이전트 구조

오늘 배운 내용을 연결하면 단순한 Agent → Agent 구조를 넘어 다음과 같은 흐름도 만들 수 있다.

실제 데이터 수집
      ↓
여러 Research Agent 병렬 실행
      ↓
결과 검증 및 통합
      ↓
Writer Agent
      ↓
Reviewer Agent
      ↓
수정 및 재작성
      ↓
최종 결과

특히 중요한 부분은 Reviewer의 결과가 실제 수정으로 이어지는 것이다.

리뷰를 생성하는 것만으로 끝나는 것이 아니라,

작성 → 리뷰 → 리뷰 반영 → 재작성

이라는 순환 구조를 만들어야 최종 결과의 품질을 높이는 방향으로 연결할 수 있다.

앞으로 실제 데이터를 활용하는 실습을 진행한다면 이 구조를 직접 구현해보면서 오늘 배운 Output Contract, Handoff, Validation, Guard, Parallel 실행을 하나의 흐름으로 연결해보고 싶다.

---

오늘 새롭게 이해한 점

오늘은 멀티 에이전트 시스템을 바라보는 관점이 조금 더 구체적으로 정리됐다.

처음에는 여러 Agent를 연결하면 멀티 에이전트 시스템이 만들어진다고 생각하기 쉽다.

하지만 실제 실행 흐름을 살펴보니 중요한 것은 Agent의 개수가 아니었다.

각 Agent가 어떤 책임을 가지고, 어떤 형식으로 결과를 만들고, 어떤 Context를 다음 Agent에게 전달하며, 그 결과를 믿고 다음 단계로 넘어가도 되는지를 판단하는 구조가 더 중요했다.

특히 LLM은 계산이나 형식적인 결과를 항상 정확하게 보장해주는 프로그램이 아니기 때문에, LLM의 결과를 시스템이 검증하는 단계가 필요하다는 점을 예산 합계 오류 사례를 통해 구체적으로 이해할 수 있었다.

또한 병렬 실행도 단순히 여러 작업을 동시에 처리하는 것이 아니라, 필수 작업과 선택 작업을 구분하고 실패했을 때 어떻게 처리할지를 미리 설계해야 한다는 점을 알게 됐다.

---

현재 내가 이해한 상태

현재까지 학습한 내용을 연결하면 멀티 에이전트 실행 흐름을 다음과 같이 이해하고 있다.

User Input
   ↓
Supervisor / Router
   ↓
Agent 실행
   ↓
Output Contract
   ↓
Validation
   ↓
Guard
   ↓
Handoff / Next Agent
   ↓
Sequential 또는 Parallel 실행
   ↓
결과 통합
   ↓
Final Output

여기에 실패가 발생하면 Retry, Timeout, Fallback, Fail-fast, Best-effort 등의 정책을 상황에 맞게 적용할 수 있다.

아직 각각의 요소를 충분히 큰 규모의 시스템에서 직접 구현해본 단계는 아니기 때문에, 앞으로는 실제 데이터와 여러 Agent를 연결하면서 이 구조를 직접 구현하고 검증하는 과정이 필요하다.

---

앞으로 해보고 싶은 것

오늘 배운 내용을 실제 데이터 활용 실습으로 연결해보고 싶다.

특히 다음과 같은 흐름을 직접 구현해보는 것을 목표로 잡았다.

병렬 데이터 수집 → 결과 검증 → 통합 → 글 작성 → 리뷰 → 재작성

이 과정에서 단순히 Agent를 여러 개 실행하는 데 그치지 않고,

• Output Contract를 어떻게 정의할지
• Handoff에 어떤 Context가 필요한지
• Validation과 Guard를 어디에 둘지
• 어떤 Agent를 병렬 실행할지
• 필수·선택 작업을 어떻게 구분할지
• 실패했을 때 어디까지 복구할지
• 최종 리뷰 결과를 어떻게 재작성에 반영할지

까지 연결해서 이해해보고 싶다.

---

오늘의 회고

57일차에는 지금까지 따로 배웠던 Output Contract, Handoff, Supervisor, Router, Validation, Guard, Parallel 실행이 실제 멀티 에이전트 실행 흐름 안에서 어떻게 연결되는지 확인했다.

가장 기억에 남은 부분은 LLM이 결과를 만들어냈다는 것과 그 결과를 시스템이 신뢰할 수 있다는 것은 다른 문제라는 점이다.

예산 합계가 맞지 않았던 사례처럼 형식상 정상적인 응답도 실제 업무 규칙에는 맞지 않을 수 있다. 따라서 에이전트의 결과를 다음 단계로 전달하기 전에 필요한 정보를 검증하고, 문제가 있다면 재시도하거나 중단할 수 있는 구조가 필요하다.

또한 병렬 실행을 통해 성능을 높이는 것 역시 단순히 작업을 동시에 실행하는 것으로 끝나지 않았다. 필수 작업과 선택 작업을 구분하고, 실패를 어디까지 허용할 것인지 결정하는 것까지 오케스트레이션의 일부라는 점을 이해했다.

결국 오늘 학습을 통해 멀티 에이전트 개발에서 중요한 것은 Agent를 많이 만드는 것이 아니라, Agent 사이의 실행 흐름과 데이터 전달, 검증, 실패 처리를 안정적으로 설계하는 것이라는 방향을 조금 더 명확하게 잡을 수 있었다.