본문 바로가기
카테고리 없음

[AI 캠프 10주차 회고] Agent Engineering 핵심 정리: MCP, LangGraph, Multi-Agent, PydanticAI

by proprocess-manager 2026. 11. 14.
반응형

[AI 캠프 10주차 회고] Agent Engineering 핵심 정리: MCP, LangGraph, Multi-Agent, PydanticAI

이번 주는 단순히 AI를 사용하는 수준을 넘어, Agent가 어떻게 협업하고 기억하며 외부 시스템과 연결되는지를 구조적으로 이해하는 시간이었다.

특히 LangGraph, MCP, FastMCP, PydanticAI를 중심으로 에이전트 아키텍처를 학습하면서 "잘 답변하는 AI"보다 "잘 설계된 AI 시스템"의 중요성을 체감할 수 있었다.

기존에는 LLM에게 질문을 입력하고 답변을 얻는 방식에 집중했다면, 이번 주에는 AI가 외부 도구를 사용하고, 여러 에이전트가 역할을 나누며, 상태와 기억을 유지하는 시스템을 어떻게 설계하는지 살펴보았다.


1. 이번 주 Agent Engineering 전체 흐름

이번 주에 학습한 핵심 기술을 하나의 구조로 연결하면 다음과 같다.

LLM (대규모 언어 모델)
↓
MCP (외부 시스템 연결 표준)
↓
FastMCP (MCP 서버 구현)
↓
LangGraph (Agent Workflow 설계)
↓
Multi-Agent (역할별 협업)
↓
PydanticAI (구조화된 데이터 검증)
↓
Checkpointing (상태 저장 및 복원)
↓
실제 서비스 수준의 AI Agent 시스템

각 기술은 서로 다른 역할을 담당한다. MCP는 외부 시스템과의 연결을 표준화하고, LangGraph는 에이전트의 작업 흐름을 설계한다. PydanticAI는 데이터의 구조와 유효성을 관리하며, Checkpointing은 실행 상태를 저장하고 복원하는 데 활용된다.


2. MCP(Model Context Protocol)란?

2-1. MCP의 개념

MCP는 Model Context Protocol의 약자로, LLM과 외부 시스템을 연결하기 위한 표준 프로토콜이다.

이번 수업에서는 MCP를 "AI 시대의 USB-C"라는 관점으로 이해했다.

USB-C가 다양한 기기를 하나의 연결 규격으로 연결하듯, MCP는 AI 모델이 여러 외부 도구와 데이터에 표준화된 방식으로 접근할 수 있도록 지원한다.

2-2. MCP의 주요 구성 요소

구성 요소 역할
Tool AI가 실행할 수 있는 기능이나 작업 제공
Resource AI가 접근할 수 있는 데이터 및 정보 제공
Prompt 재사용 가능한 프롬프트 템플릿 제공

Tool, Resource, Prompt를 표준화된 방식으로 제공하면 서로 다른 시스템 간의 상호운용성을 높일 수 있다.

2-3. MCP Host / Client / Server

MCP는 Host, Client, Server의 역할을 구분하는 구조를 가지고 있다.

MCP Host

AI 애플리케이션 및 전체 연결 관리

↓
MCP Client

MCP Server와 통신하는 연결 담당

↓
MCP Server

Tool, Resource, Prompt 제공

↓
외부 API / 데이터베이스 / 파일 시스템
  • Host: MCP 연결을 관리하는 AI 애플리케이션
  • Client: 서버와 프로토콜을 통해 통신하는 구성 요소
  • Server: AI가 사용할 수 있는 도구와 데이터를 제공하는 구성 요소

2-4. JSON-RPC

MCP 통신에서는 JSON-RPC 기반의 메시지 교환 방식을 사용한다.

JSON-RPC는 JSON 형식으로 요청과 응답을 주고받는 원격 프로시저 호출(Remote Procedure Call) 방식이다. 이를 통해 Client와 Server가 정해진 규격에 따라 통신할 수 있다.

핵심 정리

MCP의 핵심은 개별 도구를 직접 연결하는 방식에서 벗어나, AI와 외부 시스템 사이의 연결 규격을 표준화하는 것이다.


3. FastMCP를 활용한 MCP 서버 구현

3-1. FastMCP란?

FastMCP는 Python 환경에서 MCP 서버와 클라이언트를 구현할 수 있도록 지원하는 도구다. 복잡한 프로토콜 구현을 직접 처리하는 대신, 간결한 코드로 Tool 등을 등록하고 관리할 수 있다.

3-2. 이번 주 구현 및 학습 내용

  • FastMCP를 이용한 Tool 등록
  • Pydantic 기반 입력 스키마 정의
  • JSON 기반 데이터 교환
  • 예외 처리
  • Client-Server 통신

3-3. Pydantic 기반 데이터 계약(Data Contract)

이번 실습에서 중요하게 느낀 부분은 Pydantic을 활용한 데이터 계약(Data Contract) 개념이었다.

단순히 함수를 호출하는 것만으로는 안정적인 시스템을 만들기 어렵다. 실제 Agent 환경에서는 다음 사항을 명확하게 정의해야 한다.

  • 어떤 데이터를 입력받을 것인가?
  • 입력 데이터의 자료형은 무엇인가?
  • 필수 입력값은 무엇인가?
  • 어떤 형식으로 결과를 반환할 것인가?
  • 잘못된 입력이 들어왔을 때 어떻게 처리할 것인가?

즉, Agent 시스템에서도 데이터의 입력과 출력 규격을 명확하게 정의하는 것이 안정성을 결정하는 중요한 요소라는 점을 이해했다.


4. LangGraph의 상태(State) 중심 설계

4-1. LangGraph란?

LangGraph는 여러 Agent와 작업 단계를 그래프 형태로 연결하고 실행 흐름을 관리하는 프레임워크다.

이번 주 학습에서 가장 중요했던 개념은 State를 중심으로 모든 Agent가 협업한다는 점이었다.

4-2. AgentState의 역할

LangGraph에서는 AgentState에 작업 과정에서 필요한 정보를 저장하고, 각 노드가 해당 상태를 읽거나 수정하면서 작업을 수행한다.

이번 수업에서 다룬 상태 정보의 예시는 다음과 같다.

AgentState = {
    "messages": [],
    "context": "",
    "rephrased_query": "",
    "next": ""
}
상태 항목 역할
messages 대화 메시지 관리
context 작업에 필요한 문맥 정보
rephrased_query 재구성된 사용자 질문
next 다음에 실행할 노드 결정 정보

각 노드는 State에 저장된 정보를 활용해 작업을 수행하고, 필요한 결과를 다시 State에 반영한다.

Agent는 상태(State)를 읽고 상태를 수정하는 존재다.

이 관점은 기존의 함수 호출 중심 사고에서 벗어나 전체 시스템의 데이터 흐름을 설계하는 데 중요한 기준이 되었다.


5. Multi-Agent System과 역할 분담

5-1. 싱글 에이전트와 멀티 에이전트 비교

싱글 에이전트는 하나의 Agent가 질문 이해, 문서 검색, 답변 생성 등의 작업을 수행한다.

반면 멀티 에이전트는 작업을 여러 역할로 분리하여 각각의 Agent가 담당하도록 구성한다.

구분 싱글 에이전트 멀티 에이전트
작업 구조 하나의 Agent가 수행 역할별 Agent가 분담
책임 분리 상대적으로 어려움 역할별 분리 가능
확장성 구조에 따라 제한적 기능별 확장에 유리
관리 단일 흐름 중심 Agent 간 협업 흐름 관리 필요

5-2. 역할별 Agent 구성

이번 수업에서는 다음과 같이 역할을 분리하는 구조를 학습했다.

사용자 질문
↓
Rephrase Agent
질문 재구성
↓
Retriever Agent
관련 문서 검색
↓
Answer Agent
검색 결과 기반 답변 생성
↓
최종 답변

5-3. 멀티 에이전트의 장점

  • 책임 분리: 각 Agent가 명확한 역할을 담당한다.
  • 유지보수성: 기능별로 수정하고 관리하기 쉽다.
  • 확장성: 새로운 역할의 Agent를 추가할 수 있다.
  • 성능 최적화: 각 작업에 적합한 모델과 처리 방식을 적용할 수 있다.

다만 멀티 에이전트는 Agent 간 통신과 상태 관리가 추가되므로, 모든 작업을 무조건 여러 Agent로 분리하는 것이 좋은 것은 아니다. 작업의 복잡도와 분리 필요성을 고려해야 한다.


6. 조건부 라우팅(Conditional Routing)과 Workflow

6-1. 조건부 라우팅이란?

LangGraph의 핵심은 노드를 단순하게 연결하는 것뿐만 아니라, 현재 상태에 따라 다음에 실행할 노드를 동적으로 결정할 수 있다는 점이다.

이번 수업에서는 state["next"] 값을 이용해 다음 작업을 결정하는 구조를 학습했다.

6-2. 조건부 라우팅의 기본 흐름

현재 Node 실행
      ↓
State 업데이트
      ↓
state["next"] 확인
      ↓
Router 실행
      ↓
조건에 맞는 다음 Node 선택
      ↓
다음 작업 수행

예를 들어 현재 상태에 따라 검색 노드로 이동하거나 답변 생성 노드로 이동하는 식으로 작업 흐름을 구성할 수 있다.

6-3. StateGraph

StateGraph는 LangGraph에서 상태를 중심으로 노드와 엣지를 구성하는 그래프 구조다.

  • Node: 실제 작업을 수행하는 함수
  • Edge: 노드 간 연결 관계
  • Conditional Edge: 조건에 따라 다음 노드를 결정하는 연결
  • State: 작업 과정에서 공유하는 데이터

이를 통해 단순한 순차 실행을 넘어 조건에 따라 달라지는 Agent Workflow를 설계할 수 있다.


7. PydanticAI와 구조화 출력(Structured Output)

7-1. 구조화 출력이 중요한 이유

LLM은 기본적으로 자연어 형태의 비정형 데이터를 생성한다. 하지만 실제 서비스에서는 다음과 같이 정해진 데이터 형식이 필요하다.

  • 문자열(String)
  • 정수(Integer)
  • 리스트(List)
  • 딕셔너리(Dictionary)

다음 Agent나 프로그램이 결과를 사용하려면 출력 데이터의 구조와 자료형이 명확해야 한다.

7-2. PydanticAI의 역할

PydanticAI는 Agent의 입력과 출력에 구조화된 데이터 타입을 적용할 수 있도록 지원한다.

  • 스키마 정의: 데이터 구조와 필드 지정
  • 런타임 검증: 결과 데이터의 형식 및 유효성 확인
  • 검증 오류 처리: 잘못된 결과에 대한 처리 지원

특히 멀티 에이전트 환경에서는 앞 단계의 출력이 다음 단계의 입력이 되는 경우가 많다. 따라서 구조화 출력은 Agent 간 데이터 전달의 신뢰성을 확보하는 데 중요하다.

핵심 정리

Agent가 생성한 결과를 다음 Agent가 안정적으로 사용하려면 데이터 계약과 구조화 출력이 필요하다.


8. 비동기 프로그래밍(Async / Await)

8-1. 이번 주 학습 키워드

  • async
  • await
  • Coroutine
  • ainvoke()

8-2. 비동기 처리가 필요한 이유

Agent 시스템에서는 외부 API 호출, 데이터베이스 조회, 파일 입출력처럼 응답을 기다려야 하는 작업이 자주 발생한다.

이러한 작업을 동기 방식으로만 처리하면 작업이 완료될 때까지 다음 작업을 진행하지 못할 수 있다.

비동기 프로그래밍은 I/O 작업이 진행되는 동안 다른 작업을 수행할 수 있도록 하여 대기 시간을 효율적으로 활용하는 방식이다.

8-3. 라면 물 끓이기 비유

동기 방식

라면 물을 끓인다 → 물이 끓을 때까지 기다린다 → 다음 작업을 한다.


비동기 방식

라면 물을 끓인다 → 물이 끓는 동안 다른 준비를 한다 → 물이 끓으면 다음 작업을 진행한다.

이번 비유를 통해 비동기 처리의 핵심을 이해할 수 있었다.

8-4. 주요 문법 키워드

async def my_function():
    result = await some_async_task()
    return result
  • async def: 비동기 함수 정의
  • await: 비동기 작업의 완료를 기다리는 표현
  • Coroutine: 실행이 중단되고 재개될 수 있는 비동기 실행 단위
  • ainvoke(): 일부 LangChain 및 LangGraph 실행 인터페이스에서 사용하는 비동기 호출 메서드

비동기 처리는 단순히 코드를 빠르게 만드는 기능이 아니라, I/O 대기 시간을 효율적으로 관리하기 위한 프로그래밍 방식이라는 점을 이해했다.


9. Checkpointing과 기억 지속성(Persistence)

9-1. Agent에게 기억이 필요한 이유

Agent가 실제 서비스로 발전하려면 단순히 한 번의 질문에 답변하는 것뿐만 아니라 이전 작업의 상태를 저장하고 다시 이어서 처리할 수 있어야 한다.

이를 위해 이번 주에는 Checkpointing과 Persistence 개념을 학습했다.

9-2. 핵심 개념

개념 설명
Checkpoint 특정 시점의 실행 상태를 저장한 정보
Checkpointing 실행 상태를 저장하는 과정
Checkpointer 상태 저장 및 복원을 담당하는 구성 요소
Persistence 실행이 종료되어도 상태를 지속적으로 보존하는 개념
AsyncSqliteSaver SQLite를 활용하는 비동기 체크포인트 저장 방식

9-3. Thread ID 기반 상태 관리

이번 실습에서 특히 인상적이었던 부분은 Thread ID를 이용한 상태 관리였다.

Thread ID
↓
상태 저장
↓
Checkpoint 관리
↓
상태 복원
↓
대화 및 작업 이어서 진행

Thread ID를 기준으로 실행 상태를 구분하고 저장하면 동일한 대화나 작업 흐름을 다시 불러와 이어서 진행할 수 있다.

이번 학습을 통해 Agent의 기억 기능은 단순히 대화 내용을 프롬프트에 추가하는 것만이 아니라, DB 기반으로 실행 상태를 관리하는 체계적인 접근이 필요하다는 점을 이해했다.


10. RAG와 NL2SQL 관련 학습 키워드

이번 주 학습 키워드에는 RAG와 NL2SQL도 포함되었다. 두 기술은 Agent가 외부 데이터와 연결되어 실제 정보를 활용하는 시스템을 설계하는 데 중요한 개념이다.

10-1. RAG(Retrieval-Augmented Generation)

RAG는 검색 증강 생성 방식으로, 외부 문서나 데이터에서 관련 정보를 검색한 후 해당 정보를 바탕으로 답변을 생성하는 구조다.

이번 주 학습에서 다룬 주요 노드는 다음과 같다.

  • Rephrase Node: 사용자의 질문을 검색하기 적합한 형태로 재구성
  • Retriever Node: 관련 문서 및 정보를 검색
  • Answer Node: 검색된 정보를 바탕으로 답변 생성
사용자 질문
↓ Rephrase Node
↓ Retriever Node
↓ Answer Node
↓ 최종 답변

10-2. NL2SQL

NL2SQL은 자연어(Natural Language)를 SQL 쿼리로 변환하는 기술이다.

사용자가 자연어로 질문하면 시스템이 이를 데이터베이스에서 실행할 수 있는 SQL 형태로 변환하는 방식이다.

사용자 질문:
"이번 달 매출 합계를 알려줘."

        ↓

SQL 변환

        ↓

SELECT SUM(sales)
FROM orders
WHERE order_date >= ...;

        ↓

SQLite 데이터 조회

        ↓

조회 결과 반환

이번 주 키워드에는 SQLite도 포함되었다. 데이터베이스와 Agent를 연결하면 자연어를 기반으로 데이터 조회 작업을 수행하는 시스템으로 확장할 수 있다.

실제 서비스에서는 생성된 SQL을 실행하기 전에 권한, 허용된 테이블, 쿼리 유형 등을 검증하는 안전장치가 중요하다.


11. Agent Engineering과 소프트웨어 아키텍처

이번 주 학습을 통해 Agent 개발 역시 기존 소프트웨어 공학의 설계 원칙과 깊이 연결되어 있다는 점을 알게 되었다.

11-1. Workflow Orchestration

Workflow Orchestration은 여러 작업과 구성 요소의 실행 순서 및 흐름을 관리하는 개념이다.

LangGraph의 StateGraph와 Conditional Routing을 이용하면 Agent가 수행해야 할 작업을 단계별로 구성하고, 상태에 따라 실행 흐름을 변경할 수 있다.

11-2. Microservices Architecture

마이크로서비스 아키텍처는 시스템을 독립적인 기능 단위로 분리하여 설계하는 방식이다.

멀티 에이전트 시스템에서도 각 Agent의 역할을 분리하고 명확한 입력과 출력 규격을 정의한다는 점에서 유사한 설계 관점을 적용할 수 있다.

다만 멀티 에이전트와 마이크로서비스는 동일한 개념은 아니다. Agent는 추론과 작업 수행을 담당하는 구성 요소이고, 마이크로서비스는 독립적으로 배포·운영되는 소프트웨어 아키텍처 방식이다.


12. 이번 주 핵심 키워드 정리

MCP 및 외부 시스템 연결

  • MCP (Model Context Protocol)
  • FastMCP
  • MCP Host / Client / Server
  • JSON-RPC
  • MultiServerMCPClient
  • Tool / Resource / Prompt

LangGraph 및 Agent 설계

  • LangGraph
  • AgentState
  • StateGraph
  • Conditional Routing
  • Multi-Agent System
  • Workflow Orchestration
  • Multi-Agent Collaboration

PydanticAI 및 데이터 관리

  • PydanticAI Agent
  • Structured Output
  • Data Contract
  • Schema Validation

비동기 프로그래밍

  • Async / Await
  • Coroutine
  • ainvoke()
  • I/O Bound

상태 저장 및 기억

  • Checkpoint
  • Checkpointing
  • Checkpointer
  • AsyncSqliteSaver
  • Persistence
  • Thread ID

데이터 활용 및 서비스 구조

  • RAG
  • Rephrase Node
  • Retriever Node
  • Answer Node
  • NL2SQL
  • SQLite
  • Microservices Architecture

13. 한 주를 마무리하며

이번 주는 단순한 프롬프트 엔지니어링을 넘어 Agent Engineering의 핵심 구조를 이해한 주간이었다.

특히 다음 네 가지 기술의 역할이 하나의 시스템으로 연결되기 시작했다.

① MCP
외부 세계와 연결한다.


② LangGraph
Agent의 상태와 작업 흐름을 설계한다.


③ PydanticAI
데이터의 구조와 신뢰성을 확보한다.


④ Checkpointing
실행 상태를 저장하고 복원한다.

아직 구현 과정에서 비동기 처리, 상태 설계, 라우팅 로직이 어렵게 느껴진다. 특히 각 노드가 어떤 데이터를 입력받고 어떤 상태를 반환해야 하는지 설계하는 과정은 반복적인 실습이 필요하다고 생각한다.

하지만 이번 주를 통해 "에이전트는 결국 상태(State)를 중심으로 협업하는 소프트웨어 시스템"이라는 관점을 얻었다는 점이 가장 큰 성과였다.

앞으로는 단순히 AI 모델을 호출하는 데 그치지 않고, 외부 도구와 데이터베이스를 연결하고, 역할별 Agent가 협업하며, 실행 상태까지 유지할 수 있는 실제 서비스 구조를 직접 구현하는 것을 목표로 하고자 한다.

14. 다음 학습 방향

  • MCP Host / Client / Server 통신 구조 복습
  • FastMCP Tool 등록 및 입력 스키마 실습
  • LangGraph AgentState와 StateGraph 구현
  • Conditional Routing 분기 로직 복습
  • Multi-Agent 역할 분담 구조 구현
  • PydanticAI Structured Output 실습
  • async / await 및 ainvoke() 복습
  • AsyncSqliteSaver를 활용한 Checkpointing 실습
  • RAG 및 NL2SQL 워크플로우 정리

오늘의 한 줄 요약

MCP로 외부 시스템과 연결하고, LangGraph로 Agent의 상태와 작업 흐름을 설계하며, PydanticAI로 데이터 신뢰성을 확보하고, Checkpointing으로 기억을 유지한다.


관련 학습 키워드

#AI캠프 #AgentEngineering #AI에이전트 #MCP #ModelContextProtocol #FastMCP #LangGraph #MultiAgent #PydanticAI #StructuredOutput #AsyncAwait #Checkpointing #RAG #NL2SQL #SQLite #WorkflowOrchestration #Python #LLM

```

반응형