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

 

9월은 지금까지 배운 AI Agent 기술을 하나의 서비스로 연결하고, 실제 실행 환경에 배포한 뒤, 멀티 에이전트의 실행 흐름까지 설계해보는 과정이었다.

월초에는 AI Agent를 어떻게 설계하고 검증할 것인지 고민했다. 이후 법률 AI Agent 프로젝트인 LawPath를 완성하면서 Frontend, Backend, MCP, Database가 연결되는 실제 서비스 구조를 경험했고, Docker와 AWS EC2를 통해 배포 환경까지 확장했다. 월말에는 관심의 중심이 멀티 에이전트 오케스트레이션으로 이동하면서 Router, Supervisor, Handoff, Output Contract, Validation, Guard, State 등의 개념을 실제 실행 흐름으로 연결해봤다. (랩보다 AI 더 잘해지기)

한 달의 흐름을 정리하면,

AI Agent 설계 → 서비스 통합 → Docker/AWS 배포 → CI/CD → 멀티 에이전트 → 실행 검증

이라고 할 수 있다.

---

1. 한 달 학습 흐름

9월 초에는 AI Agent의 구조를 다시 바라보는 것부터 시작했다.

그동안에는 LLM에 Prompt를 넣고 Tool을 연결해서 원하는 결과를 만드는 것에 집중했다면, 이번 달에는 실제 서비스에서 Agent가 어떻게 동작해야 하는가를 생각하기 시작했다.

특히 다음 개념들을 하나의 구조로 연결해봤다.

• RAG
• Memory
• State
• Tool
• MCP
• Database
• Redis
• SSE
• Human-in-the-Loop
• Testing
• Evaluation

RAG는 서비스에 필요한 지식이나 문서를 검색하는 역할이고, Memory는 사용자와 관련된 상태나 이전 정보를 기억하는 역할이라는 차이도 조금 더 명확해졌다. 또한 Agent의 실행 상태를 나타내는 State, 실제 실행 과정을 추적하는 Trace, 사람의 승인을 거치는 Human-in-the-Loop가 왜 필요한지도 이해하게 됐다. (랩보다 AI 더 잘해지기)

그리고 9월 2주차에는 이 개념들을 실제 프로젝트에 적용했다.

법률 사례 검색 서비스인 LawPath를 구현하면서 Frontend → Backend → Agent → MCP → Database가 하나의 서비스로 연결되는 과정을 경험했다. 단순히 AI가 답변을 생성하는 것이 아니라 검색 결과와 근거자료를 사용자에게 전달하고, 질의 이력과 결과를 저장하는 것까지 고려해야 했다. (랩보다 AI 더 잘해지기)

프로젝트가 끝난 뒤에는 Docker를 이용해 여러 서비스를 컨테이너로 분리하고, Docker Hub와 AWS EC2를 이용해 실제 배포 환경까지 확장했다. 이후 GitHub Actions를 이용한 CI/CD를 구성하면서 코드를 작성하는 것과 서비스를 배포하고 관리하는 것은 또 다른 문제라는 것도 경험했다. (랩보다 AI 더 잘해지기)

9월 후반에는 다시 AI 자체의 실행 구조로 돌아왔다.

여러 Agent를 어떤 방식으로 연결할지에 따라 Sequential, Parallel, Router, Supervisor, Evaluator-Optimizer, Handoff 등의 패턴을 구분했고, 월말에는 Output Contract와 Validation, Guard, State, 실패 정책 등을 포함한 멀티 에이전트 실행 구조를 직접 설계하고 실습했다. (랩보다 AI 더 잘해지기)

---

2. 이번 달 가장 크게 달라진 생각

"AI Agent를 만드는 것"과 "AI Agent 시스템을 설계하는 것"은 달랐다

9월을 시작할 때만 해도 AI Agent를 어느 정도 단순하게 생각했던 것 같다.

LLM
+
Prompt
+
Tool
=
AI Agent

하지만 실제 프로젝트를 진행하면서 이 정도만으로는 서비스가 만들어지지 않는다는 것을 알게 됐다.

실제로는

Frontend
   ↓
Backend
   ↓
AI Agent
   ↓
MCP
   ↓
Tool
   ↓
Database
   ↓
검색 / 처리
   ↓
결과 검증
   ↓
Frontend

처럼 여러 구성요소가 연결되어야 한다.

LawPath를 만들면서 특히 이 부분을 직접 경험했다.

화면에 결과를 보여주는 기능 하나를 추가하더라도 Backend API, 인증 Token, run_id, conversation_id, Database 등이 함께 연결되어야 했다. 각자 맡은 기능이 정상적으로 동작하는 것과 전체 서비스가 정상적으로 동작하는 것은 전혀 다른 문제였다. (랩보다 AI 더 잘해지기)

이 경험을 통해 개발을 바라보는 범위가 조금 넓어졌다.

예전에는

"내 코드가 정상적으로 실행되는가?"

를 먼저 생각했다면,

지금은

"이 코드가 전체 시스템에서 어떤 역할을 하고, 앞뒤의 구성요소와 어떻게 연결되는가?"

를 같이 생각하게 됐다.

---

3. LawPath 프로젝트를 통해 배운 것

9월 중 가장 큰 실습 경험은 법률 AI Agent 프로젝트인 LawPath였다.

처음에는 법률 사례를 검색하고 결과를 보여주는 기능 자체가 중요하다고 생각했다.

하지만 실제 구현 과정에서는 기능보다 데이터 흐름이 더 어려웠다.

사용자 질문
   ↓
정보 충분성 판단
   ↓
필요하면 추가 질문
   ↓
AI Agent
   ↓
MCP Tool
   ↓
법령 / 상담사례 / 판례 검색
   ↓
Database
   ↓
분석 결과
   ↓
Frontend
   ↓
결과 저장
   ↓
질의 이력

어떤 오류가 발생했을 때도 단순히 내가 작성한 코드만 보면 해결되지 않았다.

이 값은 누가 만들었는가?
어디로 전달되는가?
최종적으로 어디에서 사용하는가?

를 따라가야 했다.

팀원들의 코드가 합쳐지면서 API 요청과 응답 구조, Agent 상태, MCP Tool, 검색 결과, Mock 데이터와 실제 API, Git branch와 merge 등을 함께 확인해야 했던 것도 중요한 경험이었다. (랩보다 AI 더 잘해지기)

결국 이번 프로젝트에서 배운 것은 단순한 법률 AI 구현 방법보다 여러 구성요소를 하나의 서비스로 연결하는 방법에 가까웠다.

---

4. Docker와 AWS를 배우며 개발의 범위가 넓어졌다

LawPath 프로젝트 이후에는 Docker와 AWS를 학습했다.

Docker를 처음 배울 때는 단순히

"프로그램을 컨테이너에서 실행하는 기술"

정도로 생각했다.

하지만 Docker Compose로 Frontend, Backend, MCP Server, PostgreSQL, Redis 등을 연결해보면서 실행 환경 자체를 구성하고 관리하는 기술이라는 관점이 생겼다.

특히 로컬 환경에서는 자연스럽게 사용했던 localhost가 Docker에서는 컨테이너 자신을 의미한다는 것을 직접 경험하면서 네트워크에 대한 이해도 조금 달라졌다. 컨테이너 간 통신에서는 서비스 이름을 사용해야 한다는 것도 실제 구성 과정에서 이해할 수 있었다. (랩보다 AI 더 잘해지기)

그 다음에는 AWS EC2에 직접 배포했다.

로컬 개발
   ↓
Docker Image
   ↓
Docker Hub
   ↓
AWS EC2
   ↓
Docker Compose
   ↓
외부 서비스 접속

이 과정에서는 SSH 개인키 권한 문제도 경험했고, 이후에는 Security Group, Port, Public IP와 Private IP 등의 개념도 직접 확인했다. (랩보다 AI 더 잘해지기)

특히 AWS에서 어려웠던 것은 네트워크였다.

로컬에서는 Docker Compose가 서비스들을 연결해주기 때문에 상대적으로 단순했지만, 서버가 분리되면서부터는

컨테이너
→ 이미지
→ 환경변수
→ IP / Port
→ Security Group
→ 실제 실행 상태

를 순서대로 확인해야 했다.

이 경험을 통해 오류가 발생했을 때 무작정 코드를 수정하기보다 어디에서 → 어디로 → 어떤 방식으로 접근하고 있는지를 먼저 확인해야 한다는 것을 배웠다. (랩보다 AI 더 잘해지기)

---

5. CI/CD를 경험하면서 "배포"의 의미도 달라졌다

GitHub Actions를 이용해 CI/CD도 구성했다.

CI는 코드가 변경됐을 때 테스트와 빌드 등을 자동으로 수행해서 문제를 검증하는 과정이고, CD는 검증된 결과를 실제 배포 환경에 반영하는 과정이다.

이번 실습에서는

코드 수정
   ↓
Commit / Push
   ↓
GitHub Actions
   ↓
Test
   ↓
Docker Build
   ↓
CI
   ↓
AWS EC2
   ↓
Deploy

와 같은 흐름을 경험했다. (랩보다 AI 더 잘해지기)

특히 CI는 정상적으로 통과했는데 CD 단계에서 AWS SSH 접속이 실패하는 문제도 있었다.

이때 단순히 YAML 설정만 확인하는 것이 아니라 GitHub Actions가 실행되는 환경에서 AWS EC2에 접근할 수 있는가를 확인해야 했다. Security Group 설정을 확인하면서 문제의 원인을 좁혀갔다. (랩보다 AI 더 잘해지기)

이 과정에서 CI/CD 역시 단순한 도구 사용법이 아니라 각 구성요소가 어디에서 실행되고 어디에 접근하는지를 이해하는 문제라는 것을 알게 됐다.

---

6. 멀티 에이전트에 대한 생각도 달라졌다

9월 후반부터는 멀티 에이전트 오케스트레이션을 본격적으로 학습했다.

처음에는 멀티 에이전트를

Agent 1
   ↓
Agent 2
   ↓
Agent 3

처럼 여러 Agent를 연결하는 것이라고 생각했다.

하지만 지금은 Agent의 개수보다 역할과 책임, 데이터 전달 방식, 실행 흐름이 더 중요하다고 생각하게 됐다.

이번 달에 배운 대표적인 패턴을 정리하면 다음과 같다.

패턴역할

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

처음에는 비슷하게 느껴졌지만 각각을 "누가 무엇을 결정하는가"라는 관점에서 바라보니 차이가 조금씩 명확해졌다. (랩보다 AI 더 잘해지기)

특히 Router와 Supervisor의 차이를 이해한 것이 의미 있었다.

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

반면 Supervisor는

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

에 가깝다. (랩보다 AI 더 잘해지기)

이 차이를 직접 실행 흐름으로 확인하면서 멀티 에이전트를 단순한 "Agent 여러 개"가 아니라 실행을 조정하는 시스템으로 바라보게 됐다.

---

7. Output Contract와 Validation을 통해 "검증"의 중요성을 배웠다

9월 마지막 주에는 Agent 간 결과를 어떻게 안전하게 전달할 것인지에 대한 고민도 깊어졌다.

Agent가 생성한 결과를 다음 Agent에게 그대로 전달하는 것이 아니라 Output Contract를 통해 정해진 형태로 전달하는 구조를 학습했다.

여기서 중요한 것은 단순한 형식 검증만으로 충분하지 않다는 점이었다.

예를 들어

{
  "total": 100000
}

이라는 값이 있다고 해도 JSON 구조와 숫자 타입이 정상이라고 해서 실제 계산 결과까지 올바르다고 보장할 수는 없다.

그래서

구조 검증
   ↓
의미 검증
   ↓
Guard
   ↓
다음 단계

와 같은 여러 단계의 검증이 필요하다는 것을 이해했다. (랩보다 AI 더 잘해지기)

이 부분은 앞으로 멀티 에이전트 시스템을 만들면서 계속 중요하게 사용하게 될 개념이라고 생각한다.

---

8. Supervisor를 직접 실행하면서 오케스트레이션을 이해하다

이번 달 후반의 학습에서 가장 인상적이었던 부분 중 하나는 Supervisor였다.

단순한 Sequence에서는

Analyst
  ↓
Developer
  ↓
Reviewer
  ↓
Finish

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

하지만 Supervisor에서는 결과에 따라 다시 작업할 수 있다.

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

즉 Supervisor는 단순히 "다음 Agent를 선택하는 역할"이 아니라 현재 결과를 확인하고 다음 행동을 결정하는 역할이라는 것을 실습을 통해 이해했다. (랩보다 AI 더 잘해지기)

그리고 이 구조를 사용하려면 반드시 함께 설계해야 하는 것들이 있었다.

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

이런 조건이 없다면 Supervisor가 같은 작업을 계속 반복할 수도 있기 때문이다.

결국 오케스트레이션은 Agent를 연결하는 것에서 끝나는 것이 아니라 실행을 제어할 수 있어야 한다는 것을 배웠다.

---

9. 이사 준비 멀티 에이전트 실습으로 직접 설계해보다

월말에는 지금까지 배운 내용을 바탕으로 이사 준비 시나리오를 멀티 에이전트 구조로 설계해봤다.

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

이 과정에서 처음에는 기능을 많이 넣는 것이 좋은 멀티 에이전트 시스템이라고 생각하기 쉬웠지만, 실제로 설계해보면서 오히려 필요한 역할만 명확하게 분리하는 것이 중요하다는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

그리고 자연스럽게 다음과 같은 설계 순서가 생겼다.

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

이전에는 각각 따로 배웠던 개념들이었는데, 이제는 하나의 시스템을 설계할 때 함께 고려해야 하는 요소로 보이기 시작했다.

---

10. 한 달 동안 가장 어려웠던 부분

9월의 어려움을 하나로 정리한다면 "각 기술을 사용하는 것"보다 "각 기술의 책임 범위를 구분하고 연결하는 것"이었다.

LawPath에서는 Frontend, Backend, Agent, MCP, Database 사이의 데이터 흐름을 따라가는 것이 어려웠다.

Docker와 AWS에서는 컨테이너와 서버, IP, Port, Security Group, 환경변수 사이의 관계를 이해해야 했다.

멀티 에이전트에서는 Router, Supervisor, Handoff가 비슷하게 느껴져 각각의 책임을 구분하는 데 시간이 필요했다.

그리고 Validation에서는 형식적으로 정상인 데이터와 실제 업무적으로 올바른 데이터가 다를 수 있다는 것을 이해해야 했다. (랩보다 AI 더 잘해지기)

결국 공통점이 있었다.

문제가 발생했을 때 한 부분만 보는 것이 아니라 전체 흐름을 따라가야 했다.

이것이 9월 학습에서 가장 많이 연습한 부분인 것 같다.

---

11. 한 달 동안 달라진 점

9월 초에는 AI Agent를 주로 기능 단위로 바라봤다.

LLM을 호출하고, Tool을 연결하고, RAG를 붙이고, Memory를 저장하는 식이었다.

하지만 한 달 동안 프로젝트와 배포, 멀티 에이전트 실습을 거치면서 지금은 조금 다르게 생각하게 됐다.

기능
 ↓
구조
 ↓
데이터 흐름
 ↓
실행 상태
 ↓
검증
 ↓
실패 처리
 ↓
배포

각각의 기술을 알고 있는 것도 중요하지만 실제 개발에서는 각 기술이 시스템 안에서 어떤 역할을 맡고 서로 어떻게 연결되는지 이해하는 것이 더 중요하다는 생각이 들었다.

특히

"Agent를 몇 개 만들 것인가?"

보다

"각 Agent의 책임은 어디까지이며, 어떤 데이터를 주고받고, 결과가 잘못되었을 때 어떻게 처리할 것인가?"

라는 질문이 더 중요해졌다.

이것이 9월 동안 가장 크게 달라진 시선이다.

---

12. 현재 나의 상태

9월을 마친 현재는 AI Agent와 멀티 에이전트 시스템의 주요 구성요소를 단순히 개별 기술로 보는 단계에서는 조금 벗어난 것 같다.

현재 이해하고 있는 범위를 정리하면 다음과 같다.

이해할 수 있게 된 것

• RAG와 Memory의 역할 차이
• Agent와 Workflow의 차이
• State와 Trace의 필요성
• MCP와 Tool의 연결 구조
• Docker와 Docker Compose
• Docker Hub
• AWS EC2 배포
• 기본적인 CI/CD 흐름
• Sequential / Parallel
• Router / Supervisor
• Handoff
• Evaluator-Optimizer
• Output Contract
• 구조 검증과 의미 검증
• Guard와 실패 처리의 필요성

또한 LawPath 프로젝트와 여러 실습을 통해 전체 서비스의 데이터 흐름을 따라가면서 문제를 확인하는 경험도 했다. (랩보다 AI 더 잘해지기)

다만 아직 Python, Backend, Database 같은 기초 개발 역량은 더 보완해야 한다.

특히 내가 처음부터 Backend나 Database 구조를 설계하고 구현하는 능력은 아직 부족하다. 프로젝트를 진행하면서 오히려 이런 부족한 부분이 더 명확하게 보였다. (랩보다 AI 더 잘해지기)

그래서 지금은 "AI 기술을 많이 알고 있다"기보다는 AI 시스템이 어떤 구조로 만들어지고 서로 어떻게 연결되는지에 대한 큰 그림이 생긴 상태라고 생각한다.

---

13. KPT 회고

Keep

전체 흐름을 먼저 이해하려고 하는 습관

문제가 생겼을 때 특정 코드만 수정하기보다 데이터가 어디에서 만들어지고 어디로 전달되는지를 따라가는 방식은 앞으로도 유지하고 싶다.

특히 멀티 에이전트에서는 Agent 하나의 코드보다 전체 실행 흐름을 이해하는 것이 중요하기 때문에 계속 연습할 필요가 있다.

Problem

기초 개발 역량의 부족

AI Agent 구조와 오케스트레이션 개념은 점점 익숙해지고 있지만 Python, Backend, Database에 대한 기본기가 아직 충분하지 않다.

또 여러 멀티 에이전트 패턴을 배우면서 각각의 차이를 이해하는 것과 실제 상황에서 어떤 패턴을 선택해야 하는 것은 또 다른 문제라는 것도 느꼈다.

Try

작은 멀티 에이전트 시스템을 직접 설계하고 반복해서 수정해보기

앞으로는 단순히 강의 코드를 따라가는 것보다 하나의 작은 시나리오를 정하고,

시나리오
→ Agent 역할
→ Contract
→ Validation
→ Orchestration
→ State
→ 실패 처리
→ 테스트

까지 직접 설계해보는 연습을 해보고 싶다.

그리고 Python과 Backend, Database 기초도 병행해서 보완해야겠다.

---

14. 다음 달에는 무엇을 보완할 것인가

9월에는 AI Agent를 서비스와 배포 환경, 멀티 에이전트 구조까지 확장해서 바라보는 것을 경험했다면, 앞으로는 이 구조를 더 안정적으로 만드는 방향으로 학습하고 싶다.

특히 다음 부분을 집중해서 보완할 계획이다.

① 멀티 에이전트 설계

Agent를 무조건 많이 만드는 것이 아니라,

• 어떤 역할을 분리해야 하는지
• 어떤 경우에 Sequential을 사용하는지
• 언제 Parallel이 필요한지
• Router와 Supervisor를 어떻게 구분하는지
• Handoff가 필요한 상황은 무엇인지

를 실제 문제에 적용해보는 연습이 필요하다.

② Contract와 Validation

LLM이 생성한 결과를 그대로 믿지 않고,

Output Contract
→ 구조 검증
→ 의미 검증
→ Guard
→ 다음 단계

로 연결하는 방법을 더 익히고 싶다.

③ State와 실패 처리

Agent가 실패했을 때 전체를 처음부터 다시 실행하는 것이 아니라 어느 단계에서 실패했는지 확인하고 필요한 부분부터 다시 실행할 수 있는 구조를 더 공부하고 싶다.

④ Python / Backend / Database

AI 오케스트레이션을 제대로 이해하기 위해서는 결국 기반 기술도 필요하다.

지금까지는 Agent 구조를 중심으로 학습했다면 앞으로는 Python과 Backend, Database에 대한 부족한 부분을 조금씩 채워야겠다.

---

마무리

9월을 한 문장으로 정리하면,

"AI Agent의 기능을 만드는 단계에서 벗어나, 여러 구성요소가 협력하는 시스템을 설계하는 단계로 넘어간 한 달"

이었다.

월초에는 RAG, Memory, State, Tool, MCP, Testing 같은 개별 개념을 연결했고, LawPath 프로젝트를 통해 실제 서비스 구조를 경험했다.

그다음 Docker와 AWS를 이용해 로컬에서 만든 서비스를 배포 환경으로 가져가면서 개발 → 실행 → 배포의 흐름을 경험했다.

그리고 월말에는 멀티 에이전트 오케스트레이션을 배우면서 다시 한 단계 더 들어갔다.

이제는 단순히

"Agent가 잘 실행되는가?"

만 보는 것이 아니라,

"어떤 Agent가 어떤 책임을 가지고 있는가?"
"어떤 데이터를 주고받는가?"
"결과를 어떻게 검증하는가?"
"실패하면 어떻게 처리하는가?"
"전체 실행 상태를 어떻게 관리하는가?"

를 함께 생각하게 됐다.

아직 모든 내용을 능숙하게 구현할 수 있는 단계는 아니다.

하지만 9월을 지나면서 적어도 AI 오케스트레이션이라는 것이 단순히 LLM과 여러 Agent를 연결하는 기술이 아니라, 각각의 구성요소가 정해진 책임과 계약을 가지고 협력하도록 전체 실행 흐름을 설계하는 과정이라는 것은 조금씩 이해하기 시작한 것 같다.

10월에는 이 구조를 더 많이 직접 구현해보면서, 머릿속에서 이해한 오케스트레이션과 실제 코드로 구현한 오케스트레이션 사이의 차이를 줄여나가야겠다.