한빛미디어



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



우선 책에 있는 코드를 실행하기 위해서는 환경설정을 해야 한다.

openai, langchain, langgraph, langchain-openai, tavily-python 패키지가 설치되어 있어야 하며, .env 파일 등에 OPENAI_API_KEY와 TAVILY_API_KEY가 설정되어 있어야 한다. 이 과정을 유튜브와 책의 시작 도입부분을 통해 해결하고 시작해야 한다.

gongwon-nayeon/hanbit-aiagent

또는 유튜브 영상을 참고하면서 초기 설정을 할 수 있다.
 



단순히 묻고 답하는 챗봇의 시대는 끝났다고 한다. 스스로 사고하고 도구를 사용하며 문제를 해결하는 'AI 에이전트'의 시대다. 이 책은 복잡한 이론에 매몰되지 않고, 랭체인(LangChain)과 랭그래프(LangGraph)를 통해 실질적인 결과물을 만들어내는 최적의 경로를 제시한다.

"최신 주가를 검색해서 보고서 양식으로 정리해 줘"라는 복잡한 명령을 내리면, 일반적인 LLM은 정보를 누락하거나 엉뚱한 답변을 내놓기 일쑤다. 나 또한 프롬프트 지옥에 빠져 허우적댔다.

책은 단순히 '코드를 따라 하는 법'이 아니라, 'AI 에이전트의 사고방식을 설계하는 법'을 가르쳐 주었다. 이 책을 통해 얻은 인사이트를 공유해 본다.

에이전트 개발이 어렵게 느껴진다면 우선 다음의 비유를 통해 핵심을 이해할 수 있다. 책에 있는 이미지와 도표를 보면서 개념 정리를 할 수 있었다.



1.먼저 20일이라는 시간을 가지고 이 책을 살펴볼 계획을 수립했다. (20일 로드맵

1주차: 에이전트의 뇌 구조 이해 (기초)

D01~D02 (2.5h): LLM 의사결정 원리와 ReAct 패턴 학습. AI가 생각(Thought)하고 행동(Action)하는 루프를 직접 손으로 그려보며 이해한다 (p.1-90)

D03~D04 (2.5h): 도구 호출 메커니즘과 메모리 시스템. AI에게 손과 발(API)을 달아주는 법과 과거를 기억하게 하는 법을 배운다 (p.91-190)

D05 (3h): 1주차 복습 및 아키텍처 설계 기준 정립

2주차: LangGraph 싱글 에이전트 구현 (심화)

D06~D07 (3h): 개발 환경 구축 및 랭그래프의 노드(Node), 엣지(Edge) 개념 파악. 간단한 제어 흐름을 코드로 구현한다 (p.231-320)

D08~D09 (3h): 웹 검색 에이전트 완성. 타빌리(Tavily) API를 연동해 최신 정보를 수집하는 실전 코드를 작성한다 (p.321-400)

D10~D11 (3h): 코딩 에이전트 & RAG 에이전트. 파이썬 코드를 실행하고 문서를 검색해 답변하는 고성능 에이전트를 빌드한다 (p.401-510)

3주차: 멀티 에이전트 협업 & 메모리 (실전)

D12~D13 (3h): 멀티 에이전트 패턴(슈퍼바이저, 네트워크) 학습. 여러 AI가 대화하며 문제를 푸는 구조를 설계한다 (p.511-575)

D14~D15 (3h): 에이전트 간 핸드오프와 장기 메모리(SQLite) 연동. 대화의 맥락이 끊기지 않는 영속적인 시스템을 만든다 (p.576-625)

D16 (3h): 3주차 복습 및 개인화 메커니즘 최적화

4주차: 프로토콜 확장 & 통합 프로젝트 (완성)

D17~D18 (3h): MCP와 A2A 프로토콜 실습. 외부 파일 시스템과 연동하고 에이전트 간 업무 위임 구조를 완성한다 (Part 04)

D19~D20 (4h): 통합 실전 프로젝트. 웹 검색, RAG, 파일 관리가 결합된 오케스트레이터 시스템을 구축하고 GitHub에 포트폴리오를 정리하며 마무리한다 (Part 05)

2. LLM vs 에이전트: '지식인'과 '해결사'의 차이

LLM이 방대한 지식을 머릿속에 담고 있는 '도서관'이라면, 에이전트는 그 지식을 바탕으로 직접 검색하고, 계산기를 두드리고, 코드를 실행하는 '현장 해결사'다.

책에서는 이를 추론(Reasoning), 도구 호출(Tool Use), 메모리(Memory)의 3요소로 정의한다 (Part 01, p.40-190)

3. '방 안의 박사님'에게 손과 발을 달아주는 ReAct 패턴 (Chapter 02, p.60)

많은 이들이 LLM(대규모 언어 모델)을 모든 답을 알고 있는 '전지전능한 신'으로 오해한다. 하지만 실제 LLM은 방대한 지식은 있지만 외부 세계와 소통할 손발이 없는 '방 안의 박사님'과 같다.

. 방 밖에 있는 최신 정보를 가져오거나 복잡한 계산을 하려면 박사님에게 검색창이나 계산기 같은 '도구'를 쥐여주어야 한다.

만약 "현재 서울 기온에 10을 곱해줘"라고 명령하면, AI는 Thought를 통해 웹 검색이 필요하다고 판단하고, Action으로 검색 도구를 호출한다. 검색 결과인 20도라는 값을 Observation으로 확인한 뒤, 다시 Thought를 통해 수학 계산 도구를 선택하는 식이다. 이 책의 Chapter 02 (p.60~75 부근)에서는 이 흐름을 순수 파이썬 코드로 제어하는 실습을 진행한다.



에이전트가 문제를 해결하는 과정은 '요리사가 레시피를 보며 요리하는 과정'과 똑같다. 이를 AI 세계에서는 ReAct(Reasoning + Acting) 패턴이라고 부른다.

Thought(생각): "지금은 파를 썰어야 할 차례군." (추론)

Action(행동): 도마 위에서 칼을 집어 들고 파를 썬다. (도구 실행)

Observation(관찰): "파가 다 썰렸으니 이제 냄비에 넣고 끓여야겠다." (결과 확인 후 다음 단계 결정)

이 책의 Chapter 03 에서는 이 흐름을 순수 파이썬 코드로 제어하는 실습을 진행한다.

이 실습을 통해 에이전트가 "오늘 날씨를 검색하고 그에 맞는 옷차림을 추천해 줘"라는 명령을 받았을 때, 내부적으로 어떻게 검색 도구를 선택하고 그 결과를 다시 분석하는지 그 '블랙박스'를 투명하게 들여다볼 수 있었다.



4.엇나가는 AI 비서에게 '업무 매뉴얼'을 쥐여주는 LangGraph (Part 02, p.231)

에이전트에게 자유만 주면 엉뚱한 길로 빠지기 쉽다. 랭그래프는 에이전트가 어떤 상황에서 어떤 도구를 써야 하는지, 결과가 잘못되면 어떻게 되돌아가야 하는지 그려놓은 '업무 순서도'와 같다.

야구를 좋아하는 사람에게는 '구원투수' 비유도 이해에 도움이 될 것이다.

이를 통해 우리는 AI의 불확실성을 제어 가능한 소프트웨어 아키텍처로 전환할 수 있다 (Part 02, p.231)

랭그래프는 에이전트가 움직이는 궤도를 그려주는 '업무 순서도(Workflow)'다. 아무리 똑똑한 직원이라도 매뉴얼이 없으면 실수하기 마련이다.

책의 Chapter 04~05 에서는 기존 랭체인 코드를 구조화된 랭그래프의 상태 기반 시스템(Stateful System)으로 마이그레이션하는 법을 아주 친절하게 다룬다.



4-1. 데이터의 흐름을 추적하는 '상태 변환(State Update)'의 원리

랭그래프의 핵심은 모든 노드가 '하나의 공유된 State'를 바라보며 일한다는 점이다. 책의 실습을 따라가다 보면 이 노트에 데이터가 쌓이는 과정을 실시간으로 추적할 수 있다.

[초기 상태]: 사용자가 "서울 날씨 검색해줘"라는 메시지를 노트(messages)에 적는다.

[agent 노드 실행]: LLM이 노트를 읽고 "검색 도구를 써야겠다"고 판단하여 도구 호출 명령(tool_calls)을 노트에 추가한다.

[tools 노드 실행]: 도구 노드가 배턴을 이어받아 실제 검색을 수행하고, 그 결과값(tool_outputs)을 다시 노트의 맨 뒤에 이어 붙인다(add_messages).

이처럼 데이터가 누적되는 상태 기반 시스템(Stateful System) 덕분에 AI가 이전 단계에서 무엇을 했는지 까먹지 않고 정교한 연쇄 작업이 가능해진다.



단순히 프롬프트에 "제발 단계별로 천천히 생각해 줘"라며 애원하던 과거의 방식은 실무에서 무조건 실패했다. 반면 랭그래프로 에이전트의 상태(AgentState)를 명확히 쥐고 통제하는 법을 배우, 소프트웨어처럼 예측 가능하고 제어할 수 있는 안전한 에이전트를 만들 수 있다.

4-2. TypedDict와 Pydantic BaseModel이해



책에 나오는 어려운 개념들에 대해서는 "꼭! 이해하고 넘어가기"를 통해 도움을 받을 수 있었다.

TypedDict: "이 메모지에는 반드시 이름, 나이 항목만 적어서 넘겨주세요." (느슨한 가이드라인, 딕셔너리 기반)

Pydantic BaseModel: "입력된 데이터가 진짜 숫자가 맞는지, 빈칸은 없는지 철저히 검사하고 통과되면 정식 문서를 발급합니다." (엄격한 데이터 검증 및 객체화)

1) TypedDict

파이썬에서 흔히 쓰는 딕셔너리({ "key": "value" })는 자유롭지만, 어떤 키(Key)가 들어있는지 컴파일 시점에 알기 어렵다는 단점이 있다. TypedDict는 파이썬의 표준 typing 라이브러리에서 제공하는 기능으로, 딕셔너리에 어떤 키와 어떤 타입의 값이 들어가야 하는지 정의하는 명세서 역할을 한다.

- 왜 랭그래프(LangGraph) 상태(State) 정의에 쓸까?

LangGraph에서는 에이전트들이 공유하는 노트인 State를 정의할 때 주로 TypedDict를 사용한다.

2)Pydantic BaseModel

Pydantic은 파이썬에서 데이터 검증(Validation)을 할 때 전 세계적으로 가장 많이 쓰이는 라이브러리다. BaseModel을 상속받아 클래스를 만들면, 데이터가 들어오는 순간 타입이 맞는지 검사하고 필요하면 자동으로 변환(강제 변환)까지 수행한다.

- 왜 LLM 도구(Tool) 정의나 구조화된 출력에 쓸까?

LLM에게 "결과를 JSON 형태로 반환해 줘"라고 하거나 에이전트가 사용할 도구의 입력 형식을 지정할 때 Pydantic을 사용한다. LLM이 엉뚱한 형식의 데이터를 보내는 것을 원천 차단하기 위함이다.

5.MCP와 A2A: 에이전트들의 '공용어'와 '팀워크'

MCP(Model Context Protocol)는 서로 다른 도구들을 연결하는 '유니버설 어댑터'이며, A2A(Agent-to-Agent)는 서로 다른 전문 에이전트들이 협업하는 '팀 빌딩' 프로토콜이다 (Part 04).

6.학습 후 얻은 인사이트와 향후 방향

제어 가능한 AI 설계: 인공지능 개발이 단순히 '운'이나 '프롬프트'에 의존하는 것이 아니라, 명확한 상태 관리와 그래프 설계로 제어할 수 있는 영역임을 깨달았다.

특히 Chapter 05에서 랭그래프의 '조건부 엣지'를 활용해 에이전트의 탈선을 막는 코드를 성공시켰을 때의 쾌감은 대단했다. 이제는 단순한 챗봇을 넘어, 복잡한 워크플로우를 대신 수행하는 '진짜 에이전트'를 만들 준비가 되었다.

확장성 있는 아키텍처: MCP나 A2A 같은 최신 프로토콜을 접하며, 앞으로 에이전트가 어떻게 거대한 생태계를 이룰지 시야가 넓어졌다.

MCP(Model Context Protocol)와 A2A(Agent-to-Agent) 개념을 바탕으로, 서로 다른 전문 에이전트들이 협업하는 거대한 'AI 오케스트라' 시스템을 직접 구축해 볼 계획이다. AI 에이전트 개발의 긴 여정에서 이 책은 가장 완벽한 첫 단추가 되어 주었다.