[목 차]
  

시작하며 ix

감사의 글 xi

이 책에 대하여 xii

 

CHAPTER 1 왜 지금 에이전트인가? 1

[STORY] 운명적인 만남 2

1.1 현재 AI 지형도: 폭발적 성장과 활용의 간극 3

1.2 구독형 AI의 근본적 한계: 구조적 문제 분석 5

1.3 에이전트 패러다임: 근본적 전환 10

1.4 왜 지금인가: 2025~2026년의 기술적 변곡점 13

1.5 요약 17

[STORY] 에이전트 시대의 시작 18

 

CHAPTER 2 기초 다지기: LLM의 원리와 실습 환경 구축 19

[STORY] LLM과의 첫 만남 20

2.1 LLM이란 무엇인가? 21

2.2 토큰화와 임베딩 23

2.3 LLM과 효과적으로 대화하는 기술: 프롬프트 엔지니어링 27

2.4 학습 기법: RLHF와 DPO로 LLM을 똑똑하게 만들기 29

2.5 실습 환경 구축: 로컬 LLM과 LLM API 34

2.6 요약 46

[STORY] LLM의 비밀을 풀다 48

 

CHAPTER 3 에이전트 기본 구조: 4개의 핵심 퍼즐 49

[STORY] 에이전트의 탄생 50

3.1 에이전트란 무엇인가? 51

3.2 AI 에이전트 핵심 구성 요소 52

3.3 통합 에이전트 시스템: 구성 요소의 조화로운 협업 81

3.4 요약 112

[STORY] 4개의 퍼즐이 완성되다 113

 

CHAPTER 4 단일 에이전트 구현: LangChain으로 만드는 실전 FAQ 봇 115

[STORY] 프로토타입에서 프로덕션으로 116

4.1 LangChain 0.2에서 1.0으로의 진화 117

4.2 1단계: LLM 브리지 만들기 122

4.3 2단계: FAQ 도구 만들기 134

4.4 3단계: ReAct 에이전트 만들기 142

4.5 4단계: 메모리 시스템 추가하기 148

4.6 5단계: 프로덕션을 위한 핵심 기능 추가하기 153

4.7 요약 167

[STORY] FAQ 시스템의 완성 168

 

CHAPTER 5 협업형 멀티 에이전트: 여러 전문가들의 시너지 169

[STORY] 단일 에이전트의 한계를 넘어서 170

5.1 멀티 에이전트 시스템의 이해 171

5.2 기본 협업 시스템 구현 174

5.3 프레임워크 활용 190

5.4 요약 212

[STORY] 멀티 에이전트의 미래 213

 

CHAPTER 6 MCP 완전 정복: 같은 말로 일하기 215

[STORY] MCP 이해하기 216

6.1 MCP 개념: 표준 통신 규약의 필요성 217

6.2 구조 설명: Host, Client, Server 관계도 226

6.3 JSON-RPC 2.0 메시지 흐름 이해 230

6.4 주요 LLM 애플리케이션의 MCP 지원 현황 246

6.5 Claude Desktop에서의 MCP 서버 설정 및 활용 268

6.6 MCP의 가능성과 한계, 그리고 앞으로의 길 273

6.7 요약 278

[STORY] MCP로 시작하는 AI 통합 280

 

CHAPTER 7 MCP 시스템 직접 구현: LangGraph 연동하기 281

[STORY] 실전 프로젝트의 시작 282

7.1 시스템 아키텍처란? 283

7.2 프로토콜 정의 계층 290

7.3 API 계층 구현 295

7.4 비즈니스 로직 계층 303

7.5 지원 계층 320

7.6 클라이언트 계층 327

7.7 워크플로 실행 338

7.8 요약 342

[STORY] 계층별 아키텍처로 완성한 MCP 시스템 343

 

찾아보기 345

[본 문]
  

Ollama 클라이언트 코드는 로컬 LLM과 통신하는 간단하면서도 효과적인 방법을 보여줍니다. base_url이 "http://localhost:11434"로 설정된 점에 주목하세요. 이는 Ollama가 로컬 컴퓨터의 11434 포트에서 실행되고 있다는 의미입니다. 클라우드 API와 달리 인터넷 연결이 필요 없고 모든 데이터가 로컬에서 처리됩니다. (36쪽)

 

Planner가 작동하는 방식을 더 깊이 이해해보겠습니다. 핵심은 구조화된 프롬프트 템플릿에 있습니다. 우리가 정의한 planning_prompt_template을 보면 LLM에게 단순히 '계획을 세워줘'라고 요청하는 것이 아니라 매우 구체적인 JSON 형식을 제시하고 있습니다. 이것이 중요한 이유는 자연어의 모호성 때문입니다. / 만약 구조화되지 않은 응답을 받는다면 '먼저 참석자를 확인하고, 그다음에 장소를 예약하세요'와 같은 문장형 답변을 받게 됩니다. 이런 응답은 인간이 읽기에는 자연스럽지만, 프로그램이 파싱하고 실행하기에는 매우 어렵습니다. 반면 JSON 형식으로 응답을 받으면 각 단계의 번호, 설명, 필요한 도구, 의존성 등이 명확히 구조화되어 Executor가 정확히 해석하고 실행할 수 있습니다. (55쪽)

 

LLM 브리지란 우리가 만든 LLM 인터페이스와 LangChain 생태계를 연결하는 어댑터입니다. 2장에서 만든 LLM 인터페이스는 독립적으로 작동하지만, LangChain의 에이전트, Tools, Memory 등과 함께 사용하려면 LangChain이 이해할 수 있는 형식으로 변환해주는 중간 계층이 필요합니다. 이것이 바로 브리지의 역할입니다. LLM을 상속받아 LangChain의 표준 인터페이스를 구현하면 우리 LLM을 LangChain 생태계의 모든 컴포넌트와 호환되도록 만들 수 있습니다. LangChain은 LLM 통합을 위해 두 가지 기반 클래스를 제공합니다. BaseLLM은 _generate() 메서드를 직접 구현해야 하는 저수준 추상 클래스이고, LLM은 BaseLLM을 상속하면서 _call() 메서드만 구현하면 되도록 간소화한 클래스입니다. 대부분의 경우 LLM 클래스를 상속받는 것으로 충분합니다. (122쪽)

 

실제 프로덕션에서는 단일 패턴만 사용하는 경우가 드뭅니다. 엔터프라이즈 시스템은 대체로 업무의 성격과 복잡도에 따라 서로 다른 처리 방식을 조합한 하이브리드 구조를 채택합니다. 예를 들어 단순한 조회성 업무는 순차적 처리(요청 → 처리 → 응답) 구조로 빠르고 안정적으로 처리되며, 재고 복구와 결제 취소처럼 서로 독립적인 작업이 포함된 업무는 병렬처리 방식이 효율적으로 활용됩니다. 반면 고객 분쟁이나 예외 처리가 필요한 복잡한 업무에는 상위 의사결정 주체가 하위 전문 역할을 조율하는 계층적 구조가 적합합니다. (174쪽)

 

LangGraph가 워크플로(어떤 순서로 작업하는가)에 초점을 둔다면 CrewAI는 역할(누가 무엇을 하는가)에 초점을 둡니다. CrewAI는 에이전트를 실제 팀원처럼 구성합니다. 각 에이전트는 역할(role), 목표(goal), 배경(backstory)을 지니고 서로 협력합니다. 이 차이는 단순한 스타일 차이라기보다 두 프레임워크가 강조하는 설계 관점의 차이를 보여줍니다. LangGraph를 사용할 때는 ‘먼저 분석하고, 조건을 확인하고, 그다음 이 작업과 저 작업을 한다’처럼 절차를 생각하지만, CrewAI를 사용할 때는 '분석가(analysis_task)가 문의를 분석하면 기술 전문가(technical_task)가 진단하고, 정책 전문가(policy_task)가 최종 판단을 내린다'처럼 역할과 책임을 생각합니다. (200쪽)

 

7단계 통신 흐름의 가장 큰 장점은 관심사의 분리입니다. Client는 파일이 디스크에 어떻게 저장되어 있는지, 어떤 운영 체제에서 실행되는지 알 필요가 없습니다. Server 역시 누가 요청을 했는지, 그 결과가 어떻게 사용될지 알 필요가 없습니다. 각 컴포넌트는 자신의 역할에만 집중하면 됩니다. / 여기서 Host의 역할에 주목할 필요가 있습니다. Host는 메시지를 중계하는 라우터가 아니라 Client를 생성하고 관리하는 상위 관리자입니다. 어떤 MCP 서버에 연결할지 결정하고, 보안 정책과 사용자 동의를 제어하며, Client의 결과를 수집하여 사용자에게 보여주는 것이 Host의 책임입니다. 실제 메시지 교환은 Client와 Server 사이에서 직접 이루어집니다. (230쪽)