[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_9월 5주차 회고

 

9월 마지막 주는 멀티 에이전트의 구조를 설계하는 단계에서 실제 실행과 검증, 그리고 배포 환경까지 연결해 보는 과정이었다.

특히 이번 주에는 Agent를 여러 개 만드는 것 자체보다 각 Agent의 책임을 어떻게 나누고, 결과를 어떤 계약으로 전달하며, 문제가 생겼을 때 어떻게 제어할 것인가에 대한 이해가 깊어졌다. 여기에 Supervisor, Router, Handoff, State, Validation, Guard 등의 개념이 하나의 실행 흐름으로 연결되기 시작했고, 마지막에는 Docker와 AWS, GitHub Actions를 이용한 CI/CD까지 범위가 확장됐다. (랩보다 AI 더 잘해지기)

---

1. 이번 주 학습 요약

이번 주 학습의 흐름을 한 문장으로 정리하면 다음과 같다.

Agent의 역할을 정의하는 것에서 시작해 → Agent 간 데이터를 계약으로 연결하고 → 실행 결과를 검증하고 → Supervisor가 다음 행동을 판단하고 → State와 Trace로 실행 상태를 관리하고 → 실제 배포 환경까지 연결했다.

주 초반에는 멀티 에이전트의 기본적인 설계 원칙을 다시 정리했다.

Agent마다 역할과 책임을 분리하고, 결과는 Pydantic 기반의 Output Contract를 통해 일정한 형태로 전달하도록 설계했다. 단순히 데이터의 타입이나 필드만 확인하는 구조 검증과 실제 사용자 입력이나 업무 규칙에 맞는지를 확인하는 의미 검증도 구분해서 이해했다. (랩보다 AI 더 잘해지기)

이후에는 Router와 Supervisor의 차이를 살펴봤다.

Router가 사용자의 요청을 보고 적절한 Agent나 흐름으로 연결하는 역할이라면, Supervisor는 이미 실행된 Worker의 결과를 확인하고 다음 행동을 결정한다. 결과가 부족하면 같은 Worker를 다시 실행할 수도 있기 때문에 단순한 순차 실행보다 훨씬 동적인 구조가 된다. (랩보다 AI 더 잘해지기)

후반에는 Handoff와 Context 전달, Validation과 Guard, Sequential과 Parallel 실행, 실패 정책 등을 실제 실행 흐름 안에서 연결해 봤다. 마지막에는 Handoff와 State의 차이를 이해하고, Docker·AWS·GitHub Actions를 이용해 개발한 시스템을 실제 운영 환경으로 가져가는 과정까지 학습했다. (랩보다 AI 더 잘해지기)

---

2. 가장 인상 깊었던 학습

Agent를 많이 만드는 것보다 중요한 것

이번 주에 가장 크게 생각이 바뀐 부분이다.

처음에는 멀티 에이전트라고 하면 자연스럽게

Agent 1
 ↓
Agent 2
 ↓
Agent 3

처럼 여러 Agent를 연결하는 것을 먼저 떠올렸다.

하지만 이번 주 수업과 실습을 거치면서 중요한 것은 Agent의 숫자가 아니라 Agent 사이의 경계와 실행 흐름이라는 것을 이해하게 됐다.

각 Agent가

• 무엇을 담당하는지
• 어떤 입력을 받는지
• 어떤 결과를 만들어내는지
• 다음 Agent에 어떤 정보를 전달하는지
• 결과가 정상인지 어떻게 판단하는지

를 먼저 정의해야 한다.

그래서 이번 주에 배운 내용을 단순화하면 다음과 같은 구조로 정리할 수 있었다.

User Input
   ↓
Router / Supervisor
   ↓
Agent
   ↓
Output Contract
   ↓
Validation / Guard
   ↓
Handoff
   ↓
Next Agent
   ↓
결과 통합
   ↓
Final Output

이 흐름이 머릿속에 잡히기 시작하면서 이전에 각각 따로 배웠던 개념들이 하나의 시스템으로 연결되기 시작했다. (랩보다 AI 더 잘해지기)

---

Supervisor를 직접 실행해 보면서 이해한 것

특히 Supervisor에 대한 이해가 많이 달라졌다.

단순한 Sequence라면

Analyst → Developer → Reviewer → Finish

처럼 정해진 순서대로 실행하면 된다.

하지만 Supervisor 구조에서는 Reviewer의 결과를 확인한 뒤 결과가 부족하면 다시 Reviewer를 호출할 수도 있다.

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

즉 Supervisor는 단순히 "다음 Agent를 골라주는 역할"이 아니라 현재 결과를 평가하고 다음 행동을 결정하는 관리자 역할에 가깝다는 것을 실습을 통해 이해했다. (랩보다 AI 더 잘해지기)

그리고 이 구조를 사용하려면 평가 기준과 종료 조건도 반드시 필요했다.

그렇지 않으면 Supervisor가 결과가 부족하다고 판단해서 같은 Worker를 계속 실행할 수도 있기 때문이다.

따라서

• 결과 평가 기준
• 재작업 조건
• 다음 단계로 넘어가는 조건
• 완료 조건
• 최대 실행 횟수

같은 조건을 함께 설계해야 한다는 점도 알게 됐다. (랩보다 AI 더 잘해지기)

---

3. 가장 어려웠던 점과 해결 과정

이번 주에 가장 어려웠던 부분은 특정 코드 하나를 이해하는 것보다는 각 개념의 책임 범위를 구분하는 것이었다.

예를 들어 Router와 Supervisor가 모두 Agent를 선택할 수 있기 때문에 처음에는 둘의 차이가 모호하게 느껴졌다.

하지만 실제 흐름을 비교하면서 차이를 정리할 수 있었다.

Router

사용자 요청
   ↓
어디로 보낼 것인가?
   ↓
Agent / Workflow 선택

Supervisor

현재 상태
   ↓
이전 Agent 결과 확인
   ↓
충분한가?
 ├─ Yes → 다음 단계
 └─ No  → 재작업

즉 Router는 외부 요청을 어디로 연결할지가 중심이고, Supervisor는 이미 진행 중인 작업을 어떻게 계속 진행할지가 중심이라고 정리했다. (랩보다 AI 더 잘해지기)

---

LLM의 결과를 그대로 믿으면 안 된다는 문제

또 하나 어려웠던 부분은 Validation의 범위였다.

Pydantic 같은 도구를 이용하면 데이터의 타입이나 구조를 확인할 수 있다.

하지만 구조가 정상이라고 해서 결과가 반드시 올바른 것은 아니다.

예를 들어 예산 결과가

{
  "total": 100000
}

처럼 정상적인 숫자를 가지고 있다고 해도 실제 항목별 금액을 더한 결과와 맞지 않을 수 있다.

즉,

형식적으로 정상인 결과와 실제 업무적으로 올바른 결과는 다를 수 있다.

이번 주에는 이런 사례를 통해 구조 검증 → 의미 검증 → Guard로 이어지는 검증의 필요성을 조금 더 구체적으로 이해했다. (랩보다 AI 더 잘해지기)

---

4. 이사 준비 멀티에이전트 실습에서 배운 것

이번 주에는 앞에서 배운 개념을 내가 정한 이사 준비 시나리오에 적용했다.

사용자가 이사 정보를 입력하면 여러 Agent가 각각 역할을 수행하고, 결과를 다음 단계로 전달하는 구조였다.

초기에는 기능을 많이 넣는 것이 멀티 에이전트 시스템을 잘 만드는 것처럼 느껴졌지만, 실제로 설계하면서는 오히려 필요한 역할만 명확하게 분리하는 것이 중요하다는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

특히 Worker끼리 직접 데이터를 주고받도록 하기보다는 Supervisor가 검증된 Contract를 기준으로 다음 Worker에게 전달하는 구조를 생각해 볼 수 있었다.

이 과정에서 자연스럽게

시나리오
 ↓
Agent 역할
 ↓
Output Contract
 ↓
Validation
 ↓
Orchestration
 ↓
실패 / 재작업 정책

순서로 설계하는 습관이 조금씩 생기기 시작했다.

---

5. Handoff와 State의 차이를 이해하다

이번 주 후반에는 Handoff와 State의 차이도 명확하게 정리할 수 있었다.

Handoff는 말 그대로 Agent 사이에서 작업과 필요한 데이터를 전달하는 것이다.

Agent A
   ↓
Handoff
   ↓
Agent B

반면 State는 전체 시스템에서 현재 어디까지 진행됐는지를 관리한다.

예를 들어

Weather Agent 성공
       ↓
Itinerary Agent 실행
       ↓
Itinerary Agent 실패

라는 상황에서 Handoff만 생각하면 앞 단계의 결과를 다음 Agent에게 전달하는 것까지만 생각할 수 있다.

하지만 실제 서비스에서는

• 어느 Agent에서 실패했는지
• 앞 단계는 성공했는지
• 처음부터 다시 실행해야 하는지
• 실패한 단계부터 재실행할 수 있는지

같은 정보가 필요하다.

이런 실행 상태를 관리하기 위해 State가 필요하다는 것을 이해했다. Redis나 DB 등에 Trace를 남기면 프로그램이 종료된 이후에도 실행 기록을 확인할 수 있다는 점까지 연결해서 생각할 수 있었다. (랩보다 AI 더 잘해지기)

---

6. 멀티 에이전트에서 실제 서비스 운영까지

주 마지막에는 관심 범위가 Agent 내부에서 실제 서비스 운영 환경으로 확장됐다.

AWS 인스턴스의 보안 그룹과 포트 설정을 확인하면서 단순히 서버를 실행하는 것과 외부에서 접근할 수 있도록 네트워크를 구성하는 것이 별개의 문제라는 것도 확인했다.

또 Docker를 이용한 실행 환경 구성과 GitHub Actions를 이용한 CI/CD도 함께 살펴봤다. (랩보다 AI 더 잘해지기)

특히 기억에 남았던 것은 AWS 인스턴스의 IP 변경으로 CI/CD가 실패하는 상황을 직접 경험한 것이다.

코드 자체에 문제가 없어도

서버
환경 변수
인증 정보
네트워크
IP
배포 설정

중 하나만 달라져도 자동 배포가 정상적으로 동작하지 않을 수 있었다.

이 경험을 통해 개발에서 "코드를 작성한다"는 것과 "작성한 코드를 실제 환경에서 안정적으로 실행하고 배포한다"는 것은 다른 문제라는 것을 체감했다. (랩보다 AI 더 잘해지기)

---

7. 이번 주에 새롭게 이해한 점

이번 주 전과 후의 가장 큰 차이는 멀티 에이전트를 바라보는 관점이었다.

처음에는

여러 Agent를 연결하면 멀티 에이전트 시스템이 된다.

정도로 생각했다.

지금은 조금 다르게 생각한다.

멀티 에이전트 시스템은 Agent를 연결하는 것보다 Agent 사이의 데이터, 책임, 검증, 상태, 실패 처리를 설계하는 것이 중요하다.

특히 다음 관계가 조금씩 정리됐다.

Agent
→ 무엇을 하는가

Output Contract
→ 어떤 형태로 결과를 전달하는가

Validation
→ 결과의 형식과 내용이 정상인가

Guard
→ 업무 규칙이나 안전 조건에 문제가 없는가

Handoff
→ 다음 Agent에게 무엇을 전달하는가

Supervisor
→ 결과를 보고 다음에 무엇을 할 것인가

State
→ 전체 실행이 현재 어디까지 진행됐는가

Trace
→ 실행 과정을 어떻게 추적할 것인가

여기에 Docker, CI/CD, AWS까지 연결하면서 멀티 에이전트 개발은 Agent 코드만 작성하는 작업이 아니라 하나의 서비스를 구성하는 전체 개발 과정과 연결된다는 것도 이해하게 됐다. (랩보다 AI 더 잘해지기)

---

8. 현재 나의 상태

현재는 이전보다 멀티 에이전트 프로젝트의 코드를 볼 때 전체적인 구조를 파악하기 쉬워졌다.

특히

• Agent 역할 분리
• Output Contract
• Validation
• Router
• Supervisor
• Handoff
• State
• Sequential / Parallel 실행

이 각각 어떤 문제를 해결하기 위한 요소인지 구분할 수 있게 됐다.

또한 내가 정한 이사 준비 시나리오에 이런 개념을 적용해 보면서 설계 → 구현 → 실행 결과 확인의 과정을 직접 경험했다.

다만 아직 부족한 부분도 분명하다.

특히 CI/CD 전체 구조를 처음부터 혼자 설계하거나 Supervisor의 평가 기준과 재작업 조건을 안정적으로 설계하는 수준까지는 더 연습이 필요하다. GitHub Actions YAML, Environment와 Secrets, SSH 배포, Docker Compose와 AWS 서버의 관계도 계속 복습해야 할 부분이다. (랩보다 AI 더 잘해지기)

---

9. 다음 주 계획

다음 주에는 이번 주에 배운 개념을 단순히 다시 읽는 것보다 실제 프로젝트 구조에 적용하면서 익히는 것을 우선하고 싶다.

① 멀티 에이전트 구조 복습

Router
Supervisor
Agent
Contract
Validation
Guard
Handoff
State

각 요소의 역할을 다시 정리하고 실제 코드에서 어디에 위치하는지 확인할 예정이다.

② Supervisor의 평가 기준 구체화

단순히 "결과가 좋은가?"가 아니라

• 무엇을 만족해야 하는가
• 어떤 경우 재작업하는가
• 언제 다음 단계로 넘어가는가
• 언제 종료하는가
• 최대 몇 번까지 실행할 것인가

를 명확하게 정의하는 연습을 해보고 싶다.

③ CI/CD 구조 직접 확인

Frontend / Backend / MCP Server처럼 서비스 영역을 분리하고, 특정 디렉터리가 변경됐을 때 해당 영역의 CI만 실행되는 구조가 어떻게 만들어지는지 더 익혀볼 예정이다. (랩보다 AI 더 잘해지기)

---

10. KPT 회고

Keep

개념을 단순히 외우기보다 실제 시나리오에 적용해 보는 것.

이사 준비라는 하나의 주제를 정해두니 Agent, Contract, Supervisor, Handoff 같은 개념을 각각 따로 배우는 것보다 서로 어떤 관계를 가지고 있는지 이해하기 쉬웠다.

Problem

각 요소의 책임 범위를 처음부터 명확하게 나누는 것이 아직 어렵다.

특히 Supervisor가 판단해야 하는 것과 Worker가 처리해야 하는 것, Router가 결정해야 하는 것을 설계 단계에서 명확하게 나누는 연습이 더 필요하다.

또 CI/CD와 AWS 환경에서는 코드 외적인 설정까지 함께 확인해야 해서 아직 전체적인 문제 해결 흐름이 익숙하지 않다.

Try

다음 주에는 기능을 먼저 추가하기보다

시나리오 → 역할 → Contract → 검증 → 실행 흐름 → 실패 정책

순서로 먼저 설계해 보는 습관을 만들어볼 생각이다.

그리고 실제 프로젝트에서 문제가 발생했을 때 단순히 에러 메시지만 수정하기보다 어느 단계에서 상태가 잘못됐고, 어떤 데이터가 다음 단계로 전달됐는지부터 추적해 보려고 한다.

---

마무리

9월 5주차는 지금까지 배운 AI 오케스트레이션 개념들이 하나의 그림으로 연결되기 시작한 주였다.

초반에는 Agent의 역할과 Output Contract를 중심으로 설계를 배웠고, 이후 Router와 Supervisor를 통해 실행 흐름을 제어하는 방법을 익혔다.

그리고 Handoff, Validation, Guard, State, Trace를 연결하면서 에이전트가 결과를 생성하는 것보다 그 결과를 검증하고 전달하고 추적하는 과정이 중요하다는 것을 알게 됐다.

마지막에는 Docker, AWS, GitHub Actions를 통해 이 구조가 실제 서비스 개발과 배포 환경으로 이어지는 과정까지 살펴봤다. (랩보다 AI 더 잘해지기)

아직 모든 내용을 혼자 처음부터 설계할 수 있는 단계는 아니지만, 적어도 이제 멀티 에이전트 시스템을 볼 때 "Agent가 몇 개지?"보다 "각 Agent의 책임은 무엇이고, 결과는 어떻게 검증되며, 실패하면 어떻게 처리되는가?"를 먼저 생각하게 됐다.

이번 주는 그 관점의 변화가 가장 큰 수확이었다.