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

 

이번 주는 Docker와 AWS를 이용한 배포 환경을 직접 구성하는 단계에서 멀티에이전트 오케스트레이션의 구조를 설계하는 단계로 넘어간 한 주였다.

51일차에는 Docker Compose, GitHub Actions, AWS EC2를 연결하면서 CI/CD 파이프라인을 직접 구성했고, 이후 52~53일차에는 여러 AI Agent를 어떤 기준으로 나누고 연결해야 하는지 본격적으로 학습했다. (랩보다 AI 더 잘해지기)

돌이켜보면 이번 주의 핵심은 새로운 기술을 하나씩 추가로 배운 것보다 지금까지 배운 기술들을 하나의 서비스 구조 안에서 바라보기 시작했다는 것에 있었다.

---

1. 이번 주 학습 요약

이번 주 초에는 기존에 학습했던 Docker와 AWS 배포를 한 단계 더 확장했다.

단순히 EC2에 접속해서 Docker 명령어를 직접 실행하는 것이 아니라,

프로젝트
 ↓
Docker Compose
 ↓
테스트
 ↓
GitHub Actions
 ↓
CI
 ↓
AWS EC2
 ↓
Docker Compose
 ↓
배포

와 같은 흐름으로 CI/CD(지속적 통합/지속적 배포)를 구성했다.

Docker Compose는 여러 컨테이너를 하나의 애플리케이션처럼 실행할 수 있게 해주고, GitHub Actions는 테스트와 빌드, 배포 과정을 자동화하는 역할을 한다. 실제 실습에서는 Backend API 테스트를 진행하고 Docker 이미지를 빌드한 뒤 AWS EC2까지 배포하는 흐름을 확인했다. (랩보다 AI 더 잘해지기)

그리고 주 후반에는 관심의 중심이 인프라에서 멀티에이전트 오케스트레이션으로 이동했다.

Sequential, Parallel, Router, Supervisor-Worker, Evaluator-Optimizer, Handoff 등의 패턴을 배우면서 단순히 Agent를 여러 개 만드는 것이 아니라 각 Agent의 역할과 책임, Context, Tool, 데이터 전달 방식을 설계하는 것이 중요하다는 것을 이해하게 됐다. (랩보다 AI 더 잘해지기)

---

2. 이번 주 가장 인상 깊었던 학습

"멀티에이전트 = Agent를 여러 개 만드는 것"이 아니었다

이번 주 가장 크게 이해가 달라진 부분이다.

처음 멀티에이전트를 접했을 때는 하나의 Agent가 하던 일을 여러 Agent로 나누면 멀티에이전트가 되는 것이라고 생각했다.

하지만 실제로는 훨씬 더 많은 설계가 필요했다.

예를 들어 고객지원 서비스를 만든다고 하면,

사용자 요청
     ↓
   Router
  ↙   ↓    ↘
배송  환불  기술지원

처럼 요청에 따라 담당 Agent를 나눌 수 있다.

여기서 끝나는 것이 아니라 각 Agent가 무엇을 할 수 있는지, 어떤 Tool을 사용할 수 있는지, 어떤 데이터를 입력받고 어떤 형식으로 결과를 반환하는지까지 정의해야 한다.

특히 53일차에 살펴본 Handoff 코드에서는 단순히 다음 Agent에게 작업을 넘기는 것이 아니라,

from_agent
to_agent
responsibility
context

를 함께 전달하는 구조를 확인했다.

즉,

"다음 Agent에게 일을 넘긴다."

가 아니라

"누가 → 누구에게 → 왜 넘기며 → 지금까지 어떤 정보를 가지고 있는가"

까지 전달해야 하는 것이다. (랩보다 AI 더 잘해지기)

이 부분을 이해하면서 Agent 간의 협업도 결국 명확한 인터페이스와 데이터 구조가 필요하다는 점을 조금씩 이해하게 됐다.

---

3. 여러 오케스트레이션 패턴을 비교하면서 알게 된 것

이번 주에는 여러 패턴을 한꺼번에 접하면서 처음에는 개념들이 상당히 비슷하게 느껴졌다.

정리해보면 다음과 같다.

패턴역할

Sequential	정해진 순서대로 Agent 실행
Parallel	독립적인 작업을 동시에 실행
Router	요청을 적절한 Agent로 분기
Supervisor	결과를 확인하면서 다음 작업 결정
Evaluator-Optimizer	결과를 평가하고 수정하는 과정을 반복
Handoff	현재 Agent가 다른 Agent에게 책임과 Context 전달

예를 들어 서로 독립적인 정보를 조사한다면 Parallel이 적합할 수 있지만, 앞 단계의 결과가 다음 단계의 입력으로 필요한 경우에는 Sequential이 더 적합하다.

또한 Router가 단순히 "어디로 보낼지" 결정한다면 Supervisor는 각 Agent의 결과를 다시 확인하면서 다음 작업을 결정할 수 있다. (랩보다 AI 더 잘해지기)

처음에는 각각을 별개의 기술처럼 외우려고 했지만, 이제는 조금 다르게 보이기 시작했다.

Router
  ↓
Supervisor
  ↓
Sequential
  ↓
Parallel
  ↓
Join
  ↓
Evaluator
  ↓
Optimizer
  ↓
Handoff

처럼 하나의 시스템 안에서 여러 패턴을 조합할 수 있는 블록으로 생각할 수 있게 됐다. (랩보다 AI 더 잘해지기)

---

4. 어려웠던 점과 해결 과정

이번 주에는 크게 두 가지가 어려웠다.

① CI/CD에서 "어디에서 실행되는가"를 이해하는 것

Docker와 GitHub Actions를 연결하면서 단순히 YAML 문법을 맞추는 것만으로는 해결되지 않는 문제가 있었다.

실제 배포 과정에서 CI는 정상적으로 통과했지만 CD 단계에서 AWS SSH 접속이 실패하는 문제가 발생했다.

처음에는 단순한 설정 오류처럼 보였지만, 직접 접속할 때와 GitHub Actions가 접속할 때 접속 주체가 다르다는 것을 확인하면서 원인을 좁혀갔다.

결국 GitHub Actions 실행 환경에서 AWS EC2의 SSH 포트에 접근할 수 있도록 Security Group 설정을 확인해야 했다. (랩보다 AI 더 잘해지기)

이 경험을 통해 오류가 발생했을 때 무조건 설정값부터 바꾸기보다는,

어디에서 → 어디로 → 어떤 방식으로 → 무엇에 접근하고 있는가?

를 먼저 확인해야 한다는 것을 배웠다.

---

② Router, Supervisor, Handoff의 차이

멀티에이전트 패턴을 처음 배울 때는 Router와 Supervisor, Handoff가 비슷하게 느껴졌다.

하지만 역할을 기준으로 다시 정리하면서 조금씩 구분할 수 있었다.

Router
→ 어디로 보낼지 결정

Sequential
→ 정해진 순서대로 실행

Parallel
→ 여러 작업을 동시에 실행

Supervisor
→ 결과를 보고 다음 작업을 결정

Handoff
→ 현재 Agent가 다음 Agent에게 책임을 넘김

Evaluator-Optimizer
→ 결과를 평가하고 다시 개선

이렇게 단순한 문장으로 정리하고 나니 각각의 차이가 훨씬 명확해졌다. (랩보다 AI 더 잘해지기)

---

5. Evaluator-Optimizer에서 배운 것

이번 주에 특히 흥미로웠던 또 하나의 패턴은 Evaluator-Optimizer였다.

단순히 AI에게 결과물을 생성하게 하고 끝내는 것이 아니라,

Writer
 ↓
Evaluator
 ↓
통과?
 ├─ YES → 종료
 └─ NO
      ↓
   Optimizer
      ↓
   수정
      ↓
   Evaluator

처럼 결과를 평가하고 부족한 부분을 다시 수정한다.

그런데 여기서 중요한 문제가 있었다.

"좋은 결과"를 어떻게 정의할 것인가?

사람에게는 자연스럽게 판단할 수 있는 기준도 Agent에게는 명확한 규칙으로 만들어줘야 한다.

예를 들어 필수 정보가 모두 들어갔는지, 특정 조건을 만족하는지, 일정 점수 이상인지 등을 구체적으로 정의해야 한다.

또 하나는 무한 반복이다.

평가에 통과할 때까지 계속 수정하도록 만들면 반복이 끝나지 않을 수 있기 때문에 최대 반복 횟수와 종료 조건이 필요하다. (랩보다 AI 더 잘해지기)

이 부분을 보면서 AI 시스템에서는 단순히 "더 좋은 결과를 만들어줘"라고 요청하는 것보다 평가 기준과 종료 조건을 시스템적으로 정의하는 것이 중요하다는 것을 알게 됐다.

---

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

이번 주 전반부와 후반부를 연결해서 생각해보니 재미있는 부분이 있었다.

51일차에는 Docker, GitHub Actions, AWS를 연결했다.

Docker
→ 실행 환경

Docker Compose
→ 여러 서비스 실행

pytest
→ 테스트

GitHub Actions
→ 자동화

AWS EC2
→ 배포 환경

그리고 52~53일차에는 Agent들을 연결했다.

Agent
→ 역할 수행

Contract
→ 데이터 전달 규칙

Context
→ 작업에 필요한 정보

Orchestrator / Supervisor
→ 실행 흐름 관리

Handoff
→ 책임 전달

Trace
→ 실행 과정 기록

Failover
→ 장애 발생 시 대체 경로

결국 두 학습 모두 비슷한 방향으로 연결된다는 생각이 들었다.

각각의 구성요소를 만드는 것보다 구성요소 사이의 관계와 흐름을 설계하는 것이 중요하다.

Docker Compose에서는 여러 서비스를 어떻게 연결할지 고민했고, 멀티에이전트에서는 여러 Agent가 어떤 방식으로 협력할지를 고민했다.

이제는 단순히 "어떤 기술을 배웠는가"보다 "이 기술이 전체 시스템에서 어떤 역할을 하는가"를 생각하면서 수업을 보게 되는 것 같다.

---

7. 현재 나의 상태

이번 주까지 학습하면서 이전보다 멀티에이전트 시스템을 바라보는 관점은 조금 달라졌다.

이전에는 LLM을 호출하고 결과를 받아오는 것 자체에 집중했다면, 이제는

• Agent의 역할은 무엇인지
• 어떤 Tool을 사용할 수 있는지
• 어떤 Context를 전달받는지
• 어떤 조건에서 다음 Agent로 넘어가는지
• 어떤 Output Contract를 사용하는지
• 언제 실행을 종료하는지
• 오류가 발생하면 어떻게 복구하는지

를 생각하면서 코드를 볼 수 있게 됐다. (랩보다 AI 더 잘해지기)

다만 아직 처음부터 멀티에이전트 구조를 설계하고 코드를 작성할 수 있는 수준은 아니다.

각 패턴의 개념은 어느 정도 구분할 수 있게 되었지만, 실제 프로젝트에서 여러 패턴을 어떻게 조합해야 하는지는 앞으로 직접 구현하면서 더 익혀야 할 부분이다.

특히 미니 프로젝트에서는 Backend, Frontend, MCP Server를 분리하고 Docker와 CI/CD까지 연결해야 하기 때문에 지금까지 배운 내용이 실제로 어떻게 하나의 서비스로 연결되는지 확인하는 과정이 중요할 것 같다. (랩보다 AI 더 잘해지기)

---

8. 다음 주 계획

다음 주부터는 지금까지 배운 개념을 실제 프로젝트 구조로 연결하는 데 집중하려고 한다.

우선 다음 부분을 중점적으로 확인할 예정이다.

1. Agent별 역할과 책임 명확하게 정의하기
2. Agent Contract 설계하기
3. 여러 오케스트레이션 패턴 조합하기
4. Context 전달 구조 이해하기
5. Handoff 구현 방식 익히기
6. Trace와 실행 상태 관리 이해하기
7. LLM Failover 구조 확인하기
8. Backend / Frontend / MCP Server의 역할 분리하기
9. Docker와 CI/CD를 실제 프로젝트에 연결하기

특히 코드를 볼 때 단순히 "이 함수는 이렇게 사용한다"에서 끝내지 않고,

왜 이 Agent가 여기서 실행되는가?

왜 이 Context가 필요한가?

왜 이 시점에 Handoff가 발생하는가?

를 계속 질문하면서 코드를 읽어보려고 한다.

---

9. KPT 회고

Keep

지금까지 배운 기술을 단순히 개별적으로 외우기보다 전체 흐름으로 연결해서 이해하려는 방식은 계속 유지하고 싶다.

특히 오류가 발생했을 때 바로 해결 방법을 찾기보다 실행 흐름과 구성요소 간 관계를 먼저 확인하는 습관을 계속 가져가려고 한다.

Problem

멀티에이전트 패턴이 많아지면서 각각의 차이와 실제 적용 상황을 한 번에 구분하는 것이 아직 어렵다.

또한 개념을 이해하는 것과 실제 코드로 처음부터 설계하는 것 사이에는 아직 차이가 있다.

Try

다음 주에는 지금까지 배운 패턴을 실제 프로젝트에 적용하면서 단순히 예제 코드를 따라가는 것이 아니라 직접 구조를 설명할 수 있도록 연습해볼 예정이다.

특히 Agent → Context → Contract → Orchestration → Handoff → 결과가 어떤 흐름으로 연결되는지 직접 확인해보는 것을 목표로 한다.

---

마무리

이번 주는 배포 환경을 자동화하는 방법에서 AI Agent들의 협업 구조를 설계하는 방법으로 학습의 중심이 이동한 주간이었다.

51일차에는 Docker Compose와 GitHub Actions, AWS EC2를 연결하면서 애플리케이션을 실제 환경에 배포하는 흐름을 경험했다. 이후 52~53일차에는 Sequential, Parallel, Router, Supervisor, Evaluator-Optimizer, Handoff 등을 배우면서 AI Agent 역시 역할과 책임을 나누고 그 사이의 흐름을 설계해야 한다는 것을 이해했다. (랩보다 AI 더 잘해지기)

무엇보다 이번 주를 지나면서 "AI를 잘 사용하는 것"에서 "AI 시스템의 구조를 설계하는 것"으로 관심이 조금씩 이동하고 있다는 점이 가장 큰 변화였다.

아직 실제 프로젝트를 처음부터 설계할 수 있는 수준은 아니지만, 적어도 이제는 멀티에이전트 코드를 볼 때 단순히 Agent의 개수만 보는 것이 아니라 각 Agent의 역할, Context, Tool, Contract, 실행 흐름과 책임 전달 구조를 함께 살펴볼 수 있게 됐다.

이제부터는 배운 개념을 실제 프로젝트 안에서 연결해보면서, 개념을 아는 단계에서 직접 설계할 수 있는 단계로 넘어가는 것이 다음 과제가 될 것 같다.

---

해시태그

#SK네트웍스 #엔코아AI캠퍼스 #AI오케스트레이션 #멀티에이전트 #AI에이전트 #Handoff #Docker #GitHubActions #AWS #CI_CD