60일차 회고｜평가·실패 복구·AWS CI/CD·프로젝트 설계｜AI 오케스트레이션 개발자 국비지원

 

오늘은 멀티 에이전트 시스템을 어떻게 평가하고, 실패했을 때 복구하며, 실제 서비스 형태로 배포할 것인지를 집중적으로 배웠다.

특히 이전까지 배웠던 Supervisor, Worker, Output Contract, MCP 등의 개념이 단순히 에이전트를 연결하는 데서 끝나는 것이 아니라 평가 → 실패 감지 → 재시도 → 재계획 → 사용자 개입 → 최종 실행까지 이어져야 한다는 점이 인상적이었다.

오전에는 AWS EC2 환경에서 Frontend, Backend, MCP Server의 CI/CD 배포 환경을 구성했고, 오후에는 본격적인 프로젝트 주제와 설계 방향을 논의했다.

---

오늘 배운 내용

오늘 학습은 크게 네 가지 흐름으로 정리할 수 있다.

1. 멀티 에이전트 결과 평가(Evaluation)
2. 실패 처리와 복구 전략
3. AWS EC2 + GitHub Actions 기반 CI/CD
4. 프로젝트 주제 및 멀티 에이전트 설계

특히 오늘은 이전 수업에서 배웠던 기능들이 실제 프로젝트에서는 어떻게 연결되어야 하는지를 생각해보는 날에 가까웠다.

---

1. 에이전트가 만든 결과를 평가하는 이유

멀티 에이전트 시스템에서는 한 Agent가 만든 결과를 다음 Agent가 그대로 사용하는 경우가 많다.

예를 들어 여행 서비스를 만든다고 하면,

사용자
 ↓
날씨 Agent
 ↓
지역 추천 Agent
 ↓
호텔 Agent
 ↓
여행 가이드 Agent
 ↓
예약

과 같은 흐름이 만들어질 수 있다.

그런데 여기서 각 Agent가 결과를 만들었다고 해서 그 결과가 항상 제대로 만들어졌다고 보기는 어렵다.

그래서 오늘은 Evaluation이라는 개념을 배웠다.

Evaluation은 쉽게 말하면 Agent가 만든 결과가 우리가 정해놓은 기준을 만족하는지 검사하는 과정이다.

예를 들어 여행 계획이라면 다음과 같은 평가 기준을 만들 수 있다.

• 사용자가 요청한 지역이 포함되어 있는가?
• 여행 일정이 빠져 있지 않은가?
• 필요한 정보가 모두 포함되어 있는가?
• 사용자의 요구사항과 맞는가?

이런 기준을 가지고 결과를 평가하고 일정 점수 이상이면 다음 단계로 넘어가도록 구성할 수 있다.

---

2. Writer → Evaluator → Reviser 구조

오늘 특히 중요하게 배운 구조는 다음과 같다.

Writer
  ↓
Evaluator
  ↓
Pass?
 ├─ Yes → 다음 단계
 │
 └─ No
      ↓
   Feedback
      ↓
   Reviser
      ↓
   Evaluator

Evaluator는 단순히 통과 / 실패만 반환하는 것보다 점수와 피드백을 함께 제공하는 방식이 더 유용하다.

예를 들어 100점 만점에 80점 이상을 통과 기준으로 정했다면,

Score: 72
Feedback:
- 여행 일정의 마지막 날이 누락됨
- 사용자가 요청한 예산 정보가 부족함

처럼 구체적인 피드백을 전달할 수 있다.

그러면 Reviser가 기존 결과와 피드백을 받아 다시 수정하고, 수정된 결과를 다시 Evaluator가 평가한다.

이 과정은 무한히 반복할 수 없기 때문에 최대 재시도 횟수도 정해야 한다. 강의에서는 최대 5회까지 반복하는 예시를 확인했다.

---

3. 평가 기준도 하드코딩하지 않을 수 있다

처음에는 평가 기준을 코드에 직접 작성할 수 있다고 생각했지만, 오늘은 평가 기준 자체를 외부에서 관리하는 방법도 배웠다.

예를 들어 평가 기준을

• DB
• Redis
• JSON
• YAML

등에 저장해두고 필요할 때 가져와서 사용할 수 있다.

이렇게 하면 평가 기준을 변경하기 위해 Agent의 코드를 직접 수정할 필요가 줄어든다.

결국 중요한 것은 LLM에게 무조건 판단을 맡기는 것이 아니라 어떤 기준으로 판단할 것인지 명확하게 정의하는 것이라는 점이었다.

---

4. 실패는 예외가 아니라 설계 대상이었다

오늘 가장 크게 느낀 부분 중 하나는 멀티 에이전트 시스템에서 실패를 어떻게 처리할 것인가였다.

이전까지는 Agent가 정상적으로 실행되는 흐름을 중심으로 생각했다면, 이제는 반대로 생각해야 했다.

정상적으로 실행되는 경우
+
중간에 실패하는 경우
+
실패한 뒤 복구되는 경우
+
복구되지 않는 경우

까지 설계해야 실제 서비스에 가까워진다.

대표적으로 다음과 같은 복구 전략을 배웠다.

Retry

일시적인 오류라면 같은 작업을 다시 실행한다.

예를 들어 외부 API가 잠깐 응답하지 않는 경우라면 일정 횟수만큼 재시도할 수 있다.

Fallback

계속 실패하면 다른 방법을 사용한다.

예를 들어 날씨 API가 실패했다면 다른 데이터 소스나 Redis에 저장된 캐시 데이터를 사용할 수 있다.

Replan

필수 Agent가 실패해서 기존 실행 경로를 그대로 진행할 수 없다면 상위 단계에서 실행 계획 자체를 다시 세우는 방법이다.

Block

위험하거나 비정상적인 상태라면 무조건 진행하지 않고 실행을 중단한다.

Human

AI가 스스로 판단하기 어려운 상황에서는 사용자에게 상황을 알려주고 선택을 요청한다.

---

5. 병렬 실행에서는 실패한 Agent만 다시 실행할 수 있다

오늘 배운 내용 중 실제 멀티 에이전트 구조에서 특히 중요하다고 느낀 부분이다.

예를 들어 다음 세 Agent를 동시에 실행한다고 생각해보자.

Weather Agent
Place Agent
Budget Agent

그런데 Place Agent만 실패했다면 전체를 처음부터 다시 실행할 필요가 없다.

이미 성공한

Weather 결과
Budget 결과

는 그대로 보존하고 실패한 Place Agent만 다시 실행할 수 있다.

이를 위해 실행 상태를 저장하고, 실패한 Agent를 구분해서 처리하는 구조가 필요하다.

결국 실패했다고 해서 성공한 작업까지 버리지 않는 것이 중요하다.

---

6. 예약 시스템에서 생각해본 실패 처리

강의에서는 여행 예약 시나리오를 이용해 실패 처리를 설명했다.

정상적인 흐름은 대략 다음과 같다.

날씨 확인
 ↓
지역 추천
 ↓
사용자 지역 선택
 ↓
호텔 검색
 ↓
사용자 호텔 선택
 ↓
날짜 / 인원 입력
 ↓
사용자 최종 승인
 ↓
예약 실행
 ↓
DB 저장
 ↓
여행 가이드 / 일정 생성

여기서 마지막 예약 단계에서 외부 예약 시스템이 실패할 수도 있다.

그렇다고 앞에서 이미 완료한

• 날씨 정보
• 지역 추천
• 호텔 정보
• 사용자 선택

등을 전부 버리고 처음부터 다시 시작할 필요는 없다.

이미 완료된 상태를 보존하고 예약 단계만 재시도하는 것이 더 적절하다.

재시도에도 계속 실패한다면 사용자에게

다시 시도할 것인지, 취소할 것인지, 다른 방식으로 처리할 것인지

선택하게 할 수도 있다.

이런 구조를 통해 단순한 AI 챗봇과 실제 업무를 처리하는 Agent 시스템의 차이를 조금 더 이해할 수 있었다.

---

7. MCP는 데이터를 가져오는 것에서 끝나지 않는다

오늘 MCP에 대해서도 중요한 관점을 다시 확인했다.

MCP를 처음 접했을 때는 외부 데이터를 가져오기 위한 도구 정도로 생각하기 쉬운데, 실제로는 외부 시스템의 기능을 실행하는 데에도 사용할 수 있다.

예를 들어 여행 서비스라면

날씨 조회
호텔 조회
예약 실행

처럼 단순 조회뿐 아니라 실제 예약과 같은 Action까지 연결할 수 있다.

다만 예약처럼 실제 행동이 발생하는 작업은 AI가 임의로 실행하기보다는 명확한 입력값과 사용자 승인을 거친 후 실행하는 것이 중요하다는 점도 함께 배웠다.

---

8. AWS EC2 배포 구조를 단순화했다

오전에는 프로젝트 배포 환경도 계속 구성했다.

기존에는 Frontend, Backend, MCP Server를 각각 별도의 서버에 배포하는 구조를 생각했지만, 이번 프로젝트에서는 하나의 EC2 서버에 세 서비스를 함께 배포하는 방식으로 단순화했다.

구조는 다음과 같다.

AWS EC2
├── frontend/
├── backend/
└── mcp-server/

      ↕
 Redis / DB

서비스 자체는 하나의 EC2에서 실행하지만 CI/CD는 각각 분리한다.

.github/workflows/
├── frontend.yml
├── backend.yml
└── mcp.yml

이렇게 하면 Backend 코드가 변경되었을 때 Backend CI/CD만 실행하고, Frontend나 MCP까지 불필요하게 다시 배포하지 않을 수 있다.

---

9. .env와 .env.docker

배포 과정에서 환경변수 관리도 다시 확인했다.

로컬 개발 환경에서는 .env를 사용하고, Docker 기반 배포 환경에서는 .env.docker를 별도로 사용한다.

특히 .env.docker에는 API Key 같은 민감한 정보가 들어갈 수 있기 때문에 GitHub 저장소에 그대로 올리면 안 된다.

따라서 GitHub Actions가 코드를 AWS로 가져오더라도 .env.docker는 별도로 AWS 서버에 준비해야 한다.

AWS 서버에서는 다음과 같이 서비스별 디렉터리에 환경설정을 두는 구조를 사용했다.

backend/
 └── .env.docker

frontend/
 └── .env.docker

mcp-server/
 └── .env.docker

그리고 각 서비스의 GitHub Actions가 해당 디렉터리를 기준으로 Docker Compose를 실행하는 방식이다.

---

10. GitHub Actions로 실제 배포 흐름 확인

CI/CD에서는 GitHub Actions의 Workflow를 이용한다.

각 서비스마다 별도의 Workflow를 만들고 AWS EC2의 해당 디렉터리에 코드를 배포한 다음 Docker Compose를 실행하는 구조다.

오늘은 특히 Workflow를 직접 실행해서 배포가 제대로 이루어지는지 확인하는 과정을 진행했다.

또한 YAML이나 Docker Compose에서 오류가 발생했을 때 단순히 도구에게 수정을 맡기는 것이 아니라, 왜 문제가 발생했는지 확인하고 수정 결과를 직접 검증하는 것이 중요하다는 점도 강조됐다.

---

11. 오후에는 프로젝트 주제와 설계 방향을 고민했다

오후부터는 본격적으로 프로젝트 주제에 대한 논의가 시작됐다.

오늘 논의에서 인상적이었던 부분은 단순히 사용자가 질문하면 AI가 답변하는 서비스로 끝내지 않는 것이었다.

예를 들어

사용자 질문
 ↓
AI 답변

만으로 끝나는 것보다,

사용자 요청
 ↓
정보 수집
 ↓
추가 질문
 ↓
분석
 ↓
문서 생성
 ↓
사용자 승인
 ↓
실제 처리
 ↓
결과 확인

처럼 실제 업무의 다음 단계까지 연결되는 형태가 더 적합하다는 방향이었다.

민원 처리 서비스 같은 예시도 논의됐다.

사용자가 민원을 입력하면 AI가 필요한 정보를 추가로 확인하고, 관련 데이터를 수집하고, 내용을 분석한 뒤 적절한 문서나 처리 내용을 만들고, 이후 제출이나 담당자 전달 등의 후속 작업까지 연결하는 방식이다.

다만 이것이 최종 프로젝트 주제로 확정된 것은 아니며, 실제 데이터 확보와 구현 가능성 등을 추가로 검토해야 하는 단계였다.

---

12. Agent를 많이 만드는 것이 중요한 게 아니었다

프로젝트 설계에서 또 하나 중요했던 부분은 Agent를 단순히 많이 만드는 것이 목적이 아니라는 것이었다.

각 Agent가 실제로 명확한 역할을 가져야 한다.

예를 들어 Supervisor가 다음 Agent를 선택한다면,

Supervisor
 ├── 정보 수집 Agent
 ├── 분석 Agent
 ├── 문서 작성 Agent
 └── 처리 Agent

각 Agent 사이에 어떤 데이터를 주고받을 것인지도 미리 정의해야 한다.

이 부분은 이전에 배웠던 Pydantic Output Contract와도 연결된다.

앞 단계 Agent가 어떤 형식으로 결과를 만들어야 다음 Agent가 안정적으로 사용할 수 있는지를 미리 약속하는 것이다.

프로젝트가 커질수록 Agent의 역할과 데이터 계약을 명확하게 정하는 것이 중요하다는 점을 다시 이해했다.

---

오늘 새롭게 이해한 점

오늘 학습을 통해 멀티 에이전트에 대한 생각이 조금 달라졌다.

처음에는 멀티 에이전트 시스템을

여러 Agent를 연결해서 원하는 결과를 만들어내는 구조

정도로 생각했다.

하지만 이제는 그것만으로는 부족하다는 생각이 든다.

실제 서비스에서는

실행
 ↓
평가
 ↓
실패 감지
 ↓
Retry / Fallback / Replan
 ↓
필요하면 사용자 개입
 ↓
최종 실행

이라는 흐름까지 고려해야 한다.

특히 성공하는 경우보다 실패했을 때 시스템이 어떻게 행동하는지를 설계하는 것이 중요하다는 점이 오늘 가장 큰 배움이었다.

---

현재 내가 부족하다고 느낀 부분

아직 Evaluation과 Failure Recovery를 직접 하나의 완성된 프로젝트 구조로 구현해서 자유롭게 설계할 수 있는 수준까지는 아니다.

특히 다음 부분은 앞으로 더 복습해야 할 것 같다.

• Evaluator와 Reviser의 실제 구현 구조
• 평가 기준을 외부 데이터로 관리하는 방법
• Retry와 Fallback의 구체적인 구현
• 실패한 Agent의 상태를 Redis 등에 저장하고 복구하는 방법
• Replan이 필요한 상황과 단순 Retry를 해야 하는 상황의 구분
• 여러 Agent 사이의 Output Contract 설계
• GitHub Actions YAML과 Docker Compose의 관계
• AWS 환경에서 서비스별 CI/CD가 실제로 어떻게 연결되는지

오늘 배운 개념들이 각각 따로 있는 것이 아니라 하나의 프로젝트 안에서 연결되어야 하기 때문에, 앞으로 프로젝트를 진행하면서 직접 적용해보는 과정이 중요할 것 같다.

---

오늘의 회고

60일차는 지금까지 배운 내용을 실제 서비스의 관점에서 다시 바라본 날이었다.

Evaluation을 통해 Agent의 결과를 검증하고, 실패하면 Retry나 Fallback, Replan, Human Intervention 등의 방법으로 복구할 수 있다. 여기에 MCP를 통해 외부 시스템과 연결하고, 사용자 승인 이후 실제 작업까지 실행할 수 있다.

또한 AWS EC2와 GitHub Actions를 이용한 CI/CD 환경을 구성하면서 개발한 Agent 시스템을 실제 서버에서 운영하기 위한 기반도 준비했다.

무엇보다 프로젝트 주제 논의를 통해 "AI가 답변하는 서비스"와 "AI가 실제 업무를 처리하는 서비스"의 차이를 생각해볼 수 있었다.

이제부터는 단순히 Agent를 만드는 것보다,

이 Agent가 무엇을 담당하고, 어떤 결과를 만들어내며, 다음 Agent와 어떤 데이터를 주고받고, 실패하면 어떻게 복구할 것인가?

를 먼저 생각하면서 프로젝트를 설계해야 할 것 같다.

60일차까지 오면서 학습의 중심이 개별 기술을 배우는 단계에서 실제 멀티 에이전트 시스템을 설계하는 단계로 넘어가고 있다는 느낌이 들었다.

---

해시태그

#AI오케스트레이션 #멀티에이전트 #AI에이전트 #Evaluation #FailureRecovery #MCP #AWS #EC2 #GitHubActions #CI_CD