AI는 대답할 뿐이지만 에이전트는 일을 합니다

질문에 답하고 끝나는 AI 사용법이 아니라 AI에 일을 맡기고 하나의 흐름을 만드는 방법을 다루는 책. FAQ 봇에서 시작해 문서를 읽고 판단하는 AI, 여러 역할을 나눠 협업하는 멀티 에이전트 시스템까지 단계별로 직접 만들면서 왜 이런 구조가 필요한지 쉽게 이해할 수 있도록 구성했다. 프로젝트를 완성해가는 과정을 통해 흐름과 구조가 눈에 들어오고, 마지막 장을 덮을 때쯤이면 사람 대신 일을 맡길 수 있는 AI 에이전트 시스템이 완성되어 있을 것이다.

시작하며 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쪽)

아직도 AI에게 질문만 하나요?

AI는 이미 충분히 강력해졌습니다. 문서를 읽고, 코드를 만들고, 복잡한 질문에도 답할 수 있습니다. 그런데도 우리의 일은 크게 달라지지 않았습니다. 여전히 복사/붙여넣기와 수동 리포트 작성이 반복되고 있습니다. 2025년 가트너 발표에 따르면 에이전틱 AI를 실무에 적용한 조직은 1%에도 미치지 못합니다.

이 책은 그 간극을 줄이는 방법을 다룹니다. 단순히 AI를 사용하는 방법이 아니라 실제로 일을 맡길 수 있는 구조를 만드는 데 집중합니다. 신입 개발자 준호와 시니어 개발자 민지의 이야기를 통해 각 단계에서 무엇을 만들고 왜 필요한지를 자연스럽게 이해할 수 있도록 구성했습니다.

LLM의 기본 원리와 AI 에이전트의 개념부터 시작합니다. '대답'하는 AI와 실제로 일을 '처리'하는 AI의 차이를 이해하고, Planner, Executor, Tools, Memory로 이루어진 핵심 구조를 직접 구현하며 내부 동작 방식을 익힙니다. 이어 LangChain으로 FAQ 봇을 만들고, 문서를 기반으로 답하고 맥락을 이어가는 흐름을 구성합니다.

이후 CrewAI와 LangGraph를 활용해 여러 에이전트가 역할을 나누어 협업하는 멀티 에이전트 시스템으로 확장합니다. 마지막 단계에서는 MCP를 중심으로 AI와 외부 시스템을 연결합니다. 분산된 API를 하나의 방식으로 통합하고, FastAPI로 MCP 서버를 직접 구축한 뒤 LangGraph와 연동해 하나의 완성된 AI 시스템까지 확장합니다.

이 책을 끝까지 따라가면, 챗봇 수준에서 멈추지 않습니다. 실제로 일을 처리하는 AI 시스템을 직접 만듭니다. 이제는 AI에게 무엇을 물어볼지 고민하는 데서 벗어나 어떤 일을 맡기고 어떻게 흐름을 설계할지 스스로 결정할 수 있게 될 것입니다.

주요 내용

• LLM의 작동 원리와 프롬프트 설계 핵심 이해
• Planner, Executor, Tools, Memory로 완성하는 에이전트 구조
• 랭체인으로 만드는 FAQ 기반 질의응답 시스템
• CrewAI와 랭그래프로 설계하는 멀티 에이전트 협업
• MCP를 통한 에이전트와 외부 시스템 연결
• FastAPI 기반 MCP 서버 구현과 연동