[도서 리뷰] 만들면서 배우는 AI 에이전트 개발 입문+실전

알림

한빛미디어 서평단 <나는리뷰어다> 활동을 위해 도서를 협찬받아 작성된 서평입니다.

요즘은 AI 도움 없이 개발하는 흐름이 점점 낯설게 느껴질 정도로 개발하는 중에 AI가 자연스럽게 들어와 있습니다.

그래서 단순히 사용하는 것에 그치지 않고, AI 에이전트가 어떤 방식으로 동작하는지 개념부터 한 번 정리해보고 싶었습니다. 그런 이유로 이번에는 만들면서 배우는 AI 에이전트 개발 입문+실전 을 읽어보게 됐습니다.

개인적으로는 “모르는 것을 모르는 상태”보다, “내가 무엇을 모르는지 알고 있는 상태”가 더 중요하다고 생각합니다.

우선 전체적인 구조와 개념을 넓게 훑어본 뒤 이후 관심 있는 영역을 깊게 파고드는 방식이 학습에 더 적합하다고 느꼈습니다.

이 책은 그런 관점에서 AI 에이전트의 기본 개념부터 LangGraph 기반 실습까지 이어서 경험해볼 수 있는 입문서에 가까웠습니다.

아래에는 읽으면서 인상 깊었던 개념과 실습 포인트를 정리해보았습니다.

먼저 정리한 핵심 개념

OpenAI: GPT 같은 LLM을 제공하는 회사이자 모델 생태계
LangChain: LLM과 검색, API, DB 같은 외부 도구를 연결하는 프레임워크
LangGraph: 상태 기반 워크플로우로 여러 에이전트와 작업 흐름을 구성하는 프레임워크
Tavily Search: LLM 연동에 자주 활용되는 검색 API
Supabase: PostgreSQL 기반의 DB, Auth, Storage 등을 제공하는 백엔드 플랫폼
Google Drive API: 구글 드라이브 파일 조회와 업로드를 위한 API
RAG(Retrieval-Augmented Generation): 외부 문서를 먼저 검색한 뒤 그 내용을 바탕으로 답변을 생성하는 방식
LangGraph Studio: 에이전트 워크플로우를 시각화하고 디버깅할 수 있는 도구

Part 1. AI 에이전트의 개념과 원리

1장 LLM 기반 의사결정 구조와 에이전트 동작 방식

책 초반부에서는 LLM이 어떤 방식으로 입력을 해석하고 응답을 생성하는지 그리고 그 위에서 AI 에이전트가 어떤 역할을 수행하는지를 설명합니다.

읽으면서 가장 먼저 들었던 생각은 AI 에이전트가 결국 특정 모델의 결과를 더 목적에 맞게 활용하기 위한 실행 계층에 가깝다는 점이었습니다.

단순히 답변만 생성하는 것이 아니라 사용자의 의도를 해석하고 상황에 따라 필요한 행동을 선택한다는 점에서, 일반적인 챗봇보다 한 단계 더 구조적인 개념으로 느껴졌습니다.

특히 초반부터 어텐션 메커니즘을 설명해주는 구성이 인상 깊었습니다.
주변에서 자주 듣던 용어였는데 결국 문맥 안에서 어떤 정보에 더 집중해야 하는지를 판단하는 구조라고 이해하니 훨씬 쉽게 와닿았습니다.

“맥락을 이해해 더 적절한 응답을 선택하는 방식” 정도로 받아들이면 입문 단계에서는 충분하다고 느꼈습니다.

또한 외부 도구나 모델, 혹은 다른 에이전트로 작업을 분배하는 역할을 라우터(Router) 개념이라고 합니다.
전체적으로 1장은 LLM과 AI 에이전트의 동작 원리를 부담 없이 이해할 수 있도록 흐름을 잡아주는 역할에 가까웠습니다.

2장 AI 에이전트를 구성하는 3가지 핵심 요소

이 장에서는 에이전트 설계에서 자주 언급되는 추론 패턴인 ReAct와 Reflection을 소개합니다.

ReAct는 Reason + Act의 조합으로 추론과 행동을 반복하면서 문제를 해결하는 방식입니다.

즉 AI가 단순히 답을 한 번에 생성하는 것이 아니라, “생각 -> 행동 -> 관찰 -> 다시 생각"의 흐름으로 움직인다는 점이 핵심입니다.

Reflection은 한 번 만든 결과를 스스로 검토하고 수정하는 패턴입니다. 문제 해결 -> 결과 생성 -> 자기 검토 -> 보완 -> 최종 반환의 흐름으로 이어지기 때문에 한 번에 정답을 내기보다 점진적으로 결과 품질을 높이는 접근으로 이해할 수 있었습니다.

도구 사용에 대한 설명도 있었습니다. LLM은 학습된 지식만으로 답하는 것이 아니라 필요하면 웹 검색이나 외부 API를 활용해 문맥에 맞는 도구를 선택할 수 있습니다.

3장 목적에 따른 에이전트 아키텍처 설계 기준

싱글 에이전트와 멀티 에이전트 구조를 비교합니다.

싱글 에이전트는 하나의 이전트가 독립적으로 추론과 행동을 수행하는 구조입니다.

구조가 단순하고 빠르게 구현할 수 있어서, 문제 범위가 명확하고 판단 기준이 비교적 일관된 경우에는 좋은 선택지라고 느껴졌습니다.

반면 멀티 에이전트는 여러 에이전트가 역할을 나눠 협력하는 방식입니다.
더 복잡한 문제를 다루기에 적합하지만, 그만큼 설계와 테스트 난이도도 올라갑니다.

Part 2. 랭그래프로 구현하는 AI 에이전트

4장 에이전트 개발 환경 구축

이제부터는 실제 실습 파트입니다. VS Code 기반으로 에이전트 개발 환경을 구성하고, LangChain 및 LangGraph 실습을 진행할 수 있도록 준비합니다.

먼저 아나콘다를 설치해 실습용 파이썬 환경을 분리합니다. 아나콘다는 데이터 분석, 머신러닝, 인공지능 개발에서 많이 사용하는 배포판이라 패키지 관리와 가상 환경 구성이 비교적 편합니다.

아나콘다 설치 화면

가상 환경 설정

실습 환경 확인

conda를 이용해 LangGraph 실습 환경을 분리해두면, Docker와 완전히 동일한 방식은 아니지만 개발 환경을 독립적으로 관리할 수 있다는 점에서 유사한 형태로 사용할 수 있습니다.

이후 OpenAI 기반 실습을 진행하는 과정에서 아래와 같은 오류가 발생했습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
openai.RateLimitError: Error code: 429 -

{'error':
  {
    'message': 'You exceeded your current quota, please check your plan and billing details. For more information on this error, read the docs: https://platform.openai.com/docs/guides/error-codes/api-errors.',
    'type': 'insufficient_quota',
    'param': None,
    'code': 'insufficient_quota'
  }
}

해당 오류는 OpenAI API 사용량 또는 크레딧 한도를 초과했을 때 발생하는 오류입니다.

실제로 결제를 하여 실습을 하진 않았지만, 전체적인 실행 흐름과 구조를 이해하는 데에는 충분했기 때문에 이후 내용은 개념과 흐름 중심으로 학습을 이어갔습니다.

5장 랭그래프 기반 에이전트 설계

5장에서는 LangGraph의 핵심 개념인 State, Node, Edge를 중심으로 워크플로우를 구성하는 방법을 설명합니다.

입력 상태에 따라 다음 실행 흐름이 어떻게 달라지는지 직접 그래프로 구성해 보면서 LangGraph가 왜 단순 체이닝보다 복잡한 에이전트 흐름에 더 적합한지 조금 감을 잡을 수 있었습니다.

또한 Jupyter Notebook 환경에서 진행하다 보니 상태 변화와 실행 결과를 단계별로 확인하기가 편했습니다.
추상적인 개념으로만 보면 어렵게 느껴질 수 있는데 실제 흐름을 따라가며 보면 이해가 빨라지는 편이었습니다.

함께 소개되는 TypedDict와 Pydantic BaseModel도 유용했습니다. TypedDict는 상태 데이터 구조를 가볍게 정의하기 좋고, Pydantic BaseModel은 타입 검증까지 포함해 더 안정적으로 입력과 출력을 관리할 수 있습니다.

추가로 상태 병합 규칙을 다루는 Reducer 개념도 등장합니다. 여러 노드에서 갱신한 상태를 어떤 규칙으로 합칠지 정하는 방식인데, 메시지 누적이나 상태 업데이트 일관성을 유지하는 데 꽤 중요해 보였습니다.

6장 싱글 에이전트 구현

이 장에서는 Tavily Search를 활용해 웹 검색 도구를 호출하는 싱글 에이전트를 구현합니다.

LangChain에서는 도구 호출이 가능한 LLM에 도구를 바인딩해서, 사용자 질문에 따라 직접 답할지 아니면 외부 도구를 호출할지를 판단하도록 만들 수 있습니다. 도구 자체는 @tool 데코레이터로 정의할 수 있고, LLM은 bind_tools를 통해 어떤 도구를 사용할 수 있는지 전달받습니다.

이후 응답에 포함된 tool_calls를 기준으로 실제 도구 사용 여부를 판별하는 흐름이 이어지는데 전체적으로 “LLM이 언제 생각만 하고, 언제 외부 행동을 할 것인가"를 실습으로 확인해 보는 장이라고 볼 수 있었습니다.

Part 3. 멀티 에이전트 설계와 메모리 시스템 구현

해당 파트는 하나의 AI가 모든 작업을 처리하는 구조가 아니라, 여러 에이전트가 역할을 분리해 협업하는 구조를 다룹니다.

동시에 이전 대화나 사용자 정보를 기억하는 메모리 시스템도 함께 설명합니다.

예를 들어 검색 에이전트는 외부 정보를 수집하고, 분석 에이전트는 내용을 정리하며, 응답 에이전트는 최종 답변을 생성하는 식으로 역할을 분리할 수 있습니다.
이런 구조는 작업을 단계별로 쪼개기 때문에 복잡한 문제를 다루는 데 유리해 보였습니다.

또한 LangGraph에서는 장기 메모리 구현을 위해 InMemoryStore를 제공하며, 키-값 기반으로 대화 내용이나 상태 정보를 저장할 수 있습니다.
이를 활용하면 사용자별 설정이나 관심사 같은 정보를 유지하면서 더 개인화된 응답을 만들 수 있습니다.

사용자별 메모리 관리를 위해 RunnableConfig에 user_id 같은 값을 넣어 구분하는 방식도 소개됩니다.

preferences, interests, experiences, current_activities 같은 필드를 구조화해 저장하는 예시를 보면서, 결국 메모리도 막연한 개념이 아니라 꽤 명시적으로 설계해야 하는 영역이라는 생각이 들었습니다.

Part 4. 프로토콜 기반 에이전트 확장 전략

9장 MCP 기반 외부 도구 연동

이 장에서는 MCP(Model Context Protocol)를 다룹니다.

MCP는 LLM 기반 에이전트와 외부 도구, 시스템을 표준화된 방식으로 연결하기 위한 프로토콜입니다. 파일 시스템, 데이터베이스, 웹 검색, 외부 API 같은 기능을 일관된 인터페이스로 다룰 수 있다는 점에서 활용 범위가 넓어 보였습니다.

대표적인 전송 방식으로는 stdio와 streamable HTTP가 소개됩니다. stdio는 로컬 프로세스 간 표준 입출력으로 통신하는 방식이라 로컬 환경에서 단순하게 붙이기 좋고, streamable HTTP는 원격 서버와의 연동이나 확장성 있는 구조에 더 적합해 보였습니다.

최근에는 Cursor, Claude Desktop, 카카오 MCP 등 다양한 AI 도구에서 MCP 기반 연동을 지원하고 있어서, 실제 생태계 흐름과도 맞닿아 있는 주제라고 생각됩니다.

LangChain 및 LangGraph 환경에서는 LangChain-MCP-Adapters를 통해 MCP 서버와 연결합니다.
이 어댑터가 LangGraph의 요청을 MCP 프로토콜 형식으로 바꿔 주는 중간 브리지 역할을 한다고 이해하면 됩니다.

MCP 기본 구조

위 구조에서는 LangGraph가 MCP Host 역할을 하며, 중간의 어댑터가 요청을 변환해 MCP Server로 전달합니다.
MCP Server는 파일 저장이나 조회 같은 도구 기능을 제공하고, 에이전트는 필요한 순간에 이를 호출합니다.

또한 MCP 기반 멀티 에이전트 구조도 함께 살펴볼 수 있었습니다.

멀티 MCP 서버 구조

이 구조에서는 LangGraph 기반 멀티 에이전트가 여러 MCP Server와 연결되고, 각 서버가 서로 다른 역할의 도구를 제공합니다.
예를 들어 하나는 내부 문서 검색과 파일 저장을 담당하고, 다른 하나는 Tavily 기반 웹 검색과 크롤링을 담당하는 식입니다.

결국 하나의 에이전트가 여러 전문 기능 서버를 오케스트레이션하는 구조로 이해할 수 있었고, 실무 적용 관점에서도 꽤 현실적인 그림처럼 느껴졌습니다.

10장 A2A 기반 에이전트 상호 운용

A2A(Agent to Agent)는 에이전트 간 상호운용을 위한 개방형 프로토콜입니다.

A2A 기반 멀티 에이전트 구조

이 구조에서는 사용자 요청을 받은 Client Agent가 필요한 작업에 따라 여러 Remote Agent로 요청을 분산합니다. 각 Remote Agent는 다시 A2A Client를 통해 외부의 A2A Server와 통신하고, 실제 기능은 서버 내부의 LangGraph Agent나 OpenAI 기반 Agent가 수행합니다.

예를 들어 어떤 에이전트는 LangGraph 기반 워크플로우를 담당하고, 다른 에이전트는 웹 검색이나 질의응답을 수행할 수 있습니다. 여기에 MCP까지 결합되면, 각 에이전트가 외부 도구 서버와 연결된 상태로 협력하는 구조가 만들어집니다.

최근 AI 에이전트 생태계에서 MCP, A2A, 멀티 에이전트가 자주 함께 언급되는 이유를 조금은 체감할 수 있었습니다. 예전에 화제가 되었던 OpenClaw 같은 시스템도 큰 흐름에서는 비슷한 방향을 지향하는 것처럼 느껴졌습니다.

Part 5. 멀티 에이전트 실전 프로젝트

실전 프로젝트 구조

마지막 파트의 프로젝트 구조를 보면 여러 전문 에이전트가 각자의 역할을 수행하고 Client Agent가 이를 조합해 사용자 요청을 처리하는 형태입니다.

전체적으로는 하나의 AI가 모든 기능을 담당하는 구조라기보다는 역할별 에이전트를 나누고 중앙 오케스트레이터가 이를 조합하는 아키텍처에 가깝습니다.

사용자 요청을 분석한 뒤 검색, RAG, 파일 관리 같은 작업을 적절한 에이전트에 분산하고, 결과를 다시 통합하는 방식이어서 MSA나 API Gateway 구조와도 닮아 있다는 생각이 들었습니다.

특히 A2A는 에이전트 간 통신 역할을 하며, MCP는 에이전트와 외부 도구 연결 역할을 맡는다는 점이 인상적이었습니다.
최근 AI 시스템이 단일 LLM 중심에서 점점 오케스트레이션 중심 구조로 발전하고 있다는 느낌을 다시 한 번 받았습니다.

느낀 점

실습을 진행하면서 가장 먼저 느낀 점은, AI를 실제 서비스 형태로 활용하기 위해서는 생각보다 많은 준비 과정이 필요하다는 점이었습니다.

여러 서비스에서 API 키를 발급받아야 하고, 사용하는 도구마다 설정 방식도 달라 초반 환경 구성 과정에서 진입 장벽이 어느 정도 존재했습니다.

또한 서비스를 운영하는 관점에서는 비용 문제 역시 고려가 필요해 보였습니다.
특히 LLM API는 호출량에 따라 비용이 발생하며, 응답 속도 또한 실시간 서비스 환경에서는 제약 요소가 될 수 있겠다는 생각이 들었습니다.

실습 과정에서는 Tavily Search, Google Drive API, OpenAI API, Supabase 등 다양한 외부 도구를 함께 사용하게 되는데, 이 과정에서 단순히 LLM 하나만 사용하는 것이 아니라 여러 시스템을 연결하고 조합하는 구조라는 점도 확인할 수 있었습니다.

특히 이런 흐름을 따라가다 보니 MCP나 A2A 같은 프로토콜이 왜 등장하게 되었는지, 그리고 여러 에이전트를 조합해 복잡한 작업을 처리하는 구조가 왜 최근 주목받고 있는지도 이해할 수 있었습니다.

먼저 정리한 핵심 개념#

Part 1. AI 에이전트의 개념과 원리#

1장 LLM 기반 의사결정 구조와 에이전트 동작 방식#

2장 AI 에이전트를 구성하는 3가지 핵심 요소#

3장 목적에 따른 에이전트 아키텍처 설계 기준#

Part 2. 랭그래프로 구현하는 AI 에이전트#

4장 에이전트 개발 환경 구축#

5장 랭그래프 기반 에이전트 설계#

6장 싱글 에이전트 구현#

Part 3. 멀티 에이전트 설계와 메모리 시스템 구현#

Part 4. 프로토콜 기반 에이전트 확장 전략#

9장 MCP 기반 외부 도구 연동#

10장 A2A 기반 에이전트 상호 운용#

Part 5. 멀티 에이전트 실전 프로젝트#

느낀 점#