낯선 흐름에 압도될까 싶을 때는 익숙한 것으로 새것을 배우는 것도 방법이다

이것이 멀티 에이전트다 - 싱글 에이전트부터 멀티 에이전트까지, MCP와 A2A로 구현하는 에이전트 시스템 개발 | Cursor 최신 버전 반영, 9가지 실습 프로젝트 수록
서지영 지음 / 한빛미디어 / 2026년 6월

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

『이것이 멀티 에이전트다』를 읽고 실습하면서 가장 크게 든 생각은 “익숙한 것으로 새것을 배운다”는 감각이었다. 책은 LLM에서 출발해 RAG, 에이전트, 멀티 에이전트로 사고를 확장하게 만든다. 단순히 프롬프트를 잘 쓰는 수준을 넘어, 검색과 평가, 도구 호출, 상태 전달, 에이전트 간 협업, 오케스트레이션까지 하나의 시스템으로 바라보게 한다는 점이 인상적이었다.

최근에는 CLI 기반 AI 도구를 사용하면서 hooks, sub agents, 자동화된 명령 실행 같은 기능적 접근에 관심이 많이 쏠려 있었다. 그런데 이 책을 보면서 그보다 한 단계 아래에 있는 구조를 다시 보게 되었다. MCP, A2A, RAG, Vector DB, AgentContext, 오케스트레이터 같은 요소들은 “에이전트가 똑똑하게 처리한다”는 막연한 설명을 구체적인 시스템 설계의 언어로 바꿔준다. 누가 상태를 들고 있고, 누가 검색을 담당하며, 누가 평가하고, 누가 최종 응답을 만들고, 이 전체 흐름을 누가 조율하는지 생각하게 된 것이다.

특히 오케스트레이터 개념이 마음에 들었다. 멀티 에이전트라고 하면 여러 에이전트가 각자 알아서 대화하며 문제를 해결하는 장면을 떠올리기 쉽지만, 실제 서비스를 만든다고 생각하면 자유도보다 제어 가능성이 중요하다. 검색 에이전트, 평가 에이전트, 답변 생성 에이전트, 보고서 생성 에이전트처럼 역할을 나누고, 그 사이의 흐름을 조율하는 구조가 있어야 한다. 책의 실습들은 이런 역할 분리와 워크플로우 설계를 반복적으로 보여준다. 약관 기반 질의응답, 음성 Q&A, 병렬 검색, 반복 평가, 뉴스 기반 종목 영향 평가, 이상 거래 탐지, 여행 플래너까지 사례는 다양하지만 결국 핵심은 비슷하다. 하나의 거대한 프롬프트가 아니라, 책임이 분리된 작은 단위들이 연결되어 하나의 시스템을 이룬다는 점이다.

이 흐름을 따라가다 보니 실제 서비스 아키텍처에 대한 생각도 자연스럽게 이어졌다. 멀티 에이전트 시스템을 로컬 실습이나 데모 수준으로만 볼 것이 아니라, MSA나 컨테이너 기반 구조와 연결해 보면 더 깔끔한 접근이 가능할 것 같다. 각 에이전트를 독립된 서비스처럼 두고, MCP나 A2A를 통해 도구 호출과 에이전트 간 통신을 구성한다면 유지보수성과 확장성도 좋아질 수 있다. 물론 구현하다 보면 시행착오도 생기겠지만, 서비스로 만들려면 결국 이런 구조적 사고가 필요하다고 느꼈다.

실습 자체는 주제를 따라가기 좋게 구성되어 있었다. 영업 데이터 분석과 시각화, 개인정보 탐지와 마스킹, 약관 기반 질의응답, Whisper 기반 음성 Q&A, 병렬 검색, 반복 평가, 뉴스 기반 종목 영향 평가, 이상 거래 탐지, 여행 플래너로 이어지는 예제들은 에이전트를 단순한 답변 생성기가 아니라 작업 수행 단위로 바라보게 한다. 뒤로 갈수록 검색, 평가, 개선, 보고서 생성, 알림 같은 책임이 세분화되는데, 이 흐름을 따라가다 보면 “멀티 에이전트”가 단순히 에이전트 수를 늘리는 일이 아니라 워크플로우를 설계하는 일이라는 점이 분명해진다.

다만 실습을 따라가면서 아쉬운 점도 있었다. 전체적으로 OpenAI 의존성이 강하다는 느낌을 받았다. 물론 입문자나 실습 안정성을 고려하면 가장 무난한 선택일 수 있다. 하지만 요즘은 Groq, NIM, Gemini, Gemma 같은 대안도 있고, 로컬 모델이나 오픈 모델을 섞어 쓰는 경우도 많다. 벡터 DB 역시 전용 벡터 데이터베이스뿐 아니라 PostgreSQL 기반 pgvector 같은 선택지도 충분히 현실적이다. 책이 모든 조합을 다룰 수는 없겠지만, 모델과 인프라 선택지를 조금 더 열어두었다면 실무 확장성을 고민하는 독자 입장에서는 더 좋았을 것 같다.

또 하나의 아쉬움은 구현 스택을 내 방식으로 조금 더 모던하게 가져가 보고 싶다는 점이었다. 예를 들어 패키지 관리는 uv로 정리하고, 시각화는 Plotly 기반으로 더 인터랙티브하게 구성해보고 싶다. 에이전트 워크플로우도 LangChain이나 LangGraph로 다시 구현해보면 책에서 배운 구조를 다른 방식으로 검증할 수 있을 것 같다. 특히 LangGraph의 상태 기반 그래프 구조는 오케스트레이터, 반복 평가, 조건 분기, 에이전트 간 상태 전달을 표현하기에 잘 맞아 보인다. Spring AI로도 같은 접근을 시도해보면 Java/Spring 기반의 엔터프라이즈 서비스 안에서 RAG와 멀티 에이전트 구조를 어떻게 녹일 수 있을지 확인할 수 있을 것이다.

소스 코드 제공 방식에 대해서도 약간의 생각이 남았다. 압축 소스 파일에 거의 모든 파일이 포함되어 있는 방식은 따라 하기에는 편하지만, 한편으로는 독자가 구조를 직접 만들어가며 이해할 여지를 줄이기도 한다. 처음에는 내 방식대로 변환하면서 실습을 진행했지만, 뒤로 갈수록 귀찮아져서 제공된 구조에 맞춰 따라가게 되었다. 그래도 이 과정 자체가 나름의 코드 에이전트 활용 연습처럼 느껴졌다. 주어진 코드를 해석하고, 내 환경에 맞게 바꾸고, 일부는 내가 선호하는 방식으로 정리해 보는 과정이 책의 본문만큼이나 학습이 되었다.

결국 이 책에서 얻은 가장 큰 수확은 특정 라이브러리 사용법보다 사고의 확장이었다. LLM을 호출하는 코드에서 출발해, RAG로 지식을 연결하고, 에이전트로 작업을 위임하고, 멀티 에이전트와 오케스트레이터로 시스템을 설계하는 방향으로 생각이 넓어졌다. 이전에는 AI 도구의 편의 기능이나 CLI 자동화에 매몰되어 있었다면, 이제는 그 아래에 있는 구조와 프로토콜, 데이터 흐름을 함께 보게 되었다.

『이것이 멀티 에이전트다』는 멀티 에이전트를 마법처럼 포장하기보다는, 여러 실습을 통해 하나씩 분해해 보여주는 책이다. 익숙한 개념들에서 출발하지만, 읽고 나면 그것들을 내 방식으로 다시 조합해보고 싶어진다. 그래서 이 책은 “새로운 것을 알려준 책”이라기보다, 이미 알고 있던 것들과 막연히 흩어져 있던 관심사를 하나의 구조로 다시 보게 만든 책에 가깝다. 그리고 그 점이 가장 좋았다.

#멀티에이전트 #AI에이전트 #생성형AI #LLM #RAG #MCP #A2A #벡터DB #임베딩 #오케스트레이터 #LangChain #LangGraph #SpringAI #OpenAI #ClaudeAI #Gemini #pgvector #파이썬 #개발자 #한빛미디어 #이것이멀티에이전트다

구현 중심 개발에서 구조 중심 개발로 : 클린 아키텍처 with 파이썬

클린 아키텍처 with 파이썬 : 유지보수 쉽고, 테스트 가능하며, 확장 가능한 구조로 전환하는 실전 설계 전략
샘 킨 지음, 송영숙 옮김 / 한빛아카데미(교재) / 2026년 4월

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

AI 시대에도 여전히 중요한 아키텍처

개발에서 생산성과 견고하면서도 유연한 체계는 언제나 trade-off의 대상이다. 빠르게 기능을 만들려면 구조적 엄격함을 어느 정도 포기하게 되고, 장기적으로 변경에 강한 시스템을 만들려면 초기 설계와 추상화에 더 많은 비용을 들여야 한다.

AI가 개발 과정에 들어왔다고 해서 이 문제가 크게 달라진 것 같지는 않다. 오히려 AI는 기존 구조의 장점과 단점을 더 빠르게 증폭한다.

구조가 잘 잡힌 프로젝트에서는 생산성을 높이지만, 책임과 경계가 흐린 코드베이스에서는 혼란 역시 빠르게 키운다. 그래서 AI 시대일수록 아키텍처 공부는 선택적 교양이 아니라, 개발자가 속도와 복잡도 사이의 균형을 잡기 위해 갖춰야 할 기본 감각에 가깝다.

현업의 현실과 클린 아키텍처의 위치

현업에서는 사실 레이어드 아키텍처와 MVC 패턴 정도만으로도 상당수의 애플리케이션을 충분히 만들 수 있다. Controller, Service, Repository로 나뉜 익숙한 구조는 여전히 실용적이고, 스프링 같은 프레임워크는 깊은 설계 철학을 완전히 이해하지 못해도 어떻게든 동작하는 애플리케이션을 만들 수 있게 해준다.

그래서 클린 아키텍처, 헥사고날 아키텍처, DDD, TDD 같은 개념은 때로는 배부른 소리처럼 들리기도 한다. 당장 기능을 만들어야 하는 상황에서는 “이 정도까지 해야 하나?”라는 의문이 자연스럽게 생긴다.

하지만 『클린 아키텍처 with 파이썬』은 클린 아키텍처를 절대적 정답으로 제시하지 않는다. 이 책에서의 클린 아키텍처는 “깨끗한 구조만이 옳다”는 선언이 아니라, 객체지향 설계와 테스트, 도메인 중심 사고를 더 일관되게 받아들이기 위한 체계에 가깝다.

SOLID를 통해 다시 보는 설계 원칙

책은 먼저 객체지향 설계의 대표 원칙인 SOLID에서 출발한다. 처음에는 단일 책임 원칙, 개방-폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존성 역전 원칙 같은 개념이 다소 고루하게 느껴질 수 있다.

그러나 책은 이 원칙들을 암기용 구호가 아니라, 구현에만 급급했던 코드가 왜 시간이 지날수록 변경하기 어려워지는지를 설명하는 도구로 사용한다. 특히 단일 책임 원칙은 “클래스 하나는 일 하나만 해야 한다”가 아니라 “변경 이유가 하나여야 한다”는 기준으로 읽힌다.

의존성 역전 원칙은 고수준 정책이 저수준 구현에 끌려가지 않게 만드는 핵심 원리로 이어진다. 이 지점에서 Service 클래스 안에 비즈니스 로직, DB 접근, 외부 API 호출, 예외 처리, DTO 변환이 뒤섞인 코드가 왜 테스트와 확장을 방해하는지 명확해진다.

양파 아키텍처와 의존성의 방향

중반부터 양파 아키텍처 설명은 이 책에서 가장 인상적인 부분이었다. 양파 아키텍처는 시스템을 여러 겹의 원으로 바라보며, 가장 안쪽에는 핵심 비즈니스 규칙과 도메인 모델을 둔다. 그 바깥에는 유스케이스와 애플리케이션 서비스가 위치하고, 더 바깥에는 데이터베이스, 웹 프레임워크, 외부 API, UI 같은 기술적 세부사항이 위치한다.

핵심은 의존성의 방향이다. 바깥쪽 계층은 안쪽 계층을 알 수 있지만, 안쪽 계층은 바깥쪽 계층을 몰라야 한다. 즉, 데이터베이스나 프레임워크가 바뀌더라도 핵심 비즈니스 규칙은 흔들리지 않아야 한다. 이 원칙은 계층 분리가 단순히 코드를 예쁘게 나누는 일이 아니라, 변경 가능성이 높은 세부사항을 핵심 정책으로부터 분리하는 실무적 장치라는 점을 설득력 있게 보여준다.

파이썬을 넘어 다른 기술 스택으로 확장되는 사고

제목은 『클린 아키텍처 with 파이썬』이지만, 읽고 나면 “파이썬은 거들뿐”이라는 생각이 든다. 파이썬의 타입 힌트, 프로토콜, 테스트 도구, 의존성 주입 방식에 대한 설명도 유익하지만, 이 책의 더 큰 가치는 특정 언어 문법보다 아키텍처적 사고방식에 있다.

같은 구조는 스프링 프로젝트에서도 적용할 수 있다. Controller를 어댑터로, Use Case를 애플리케이션 계층으로, Entity와 Value Object를 도메인 계층으로 분리하는 방식이다. 노드 기반 프로젝트에서도 Express나 NestJS의 라우터와 컨트롤러는 바깥쪽 어댑터로 두고, 핵심 비즈니스 규칙은 프레임워크 바깥에 독립적으로 둘 수 있다. 결국 이 책은 클린 아키텍처를 그대로 따르라고 말하는 책이 아니라, 구현 중심의 사고에서 구조 중심의 사고로 넘어가게 만드는 책이다.

AI와 프레임워크가 생산성을 높여주는 시대일수록 개발자가 직접 이해하고 통제해야 할 것은 더 선명해진다. 중요한 것은 유행하는 구조를 외우는 것이 아니다. 각 계층의 책임을 명확히 하고, 변경 가능성이 높은 세부사항을 핵심 정책으로부터 분리하며, 비즈니스 규칙을 기술 선택보다 오래 살아남게 만드는 것이다.

#클린아키텍처 #소프트웨어아키텍처 #객체지향설계 #SOLID #의존성역전 #양파아키텍처 #헥사고날아키텍처 #도메인주도설계 #테스트주도개발 #레이어드아키텍처 #MVC패턴 #파이썬개발 #백엔드개발 #AI시대개발 #소프트웨어설계

OpenClaw를 시작하는 가장 안전하고 현명한 방법

오픈클로 with GPT, 제미나이, 클로드 - 내 컴퓨터에서 일하는 AI 집사 ㅣ 누구나 프로처럼 실전 AI
강민혁 지음 / 한빛미디어 / 2026년 3월

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

LLM이 바꾼 프로그래밍의 두 가지 풍경

대규모 언어 모델(LLM)의 등장이 프로그래밍에 미친 영향은 크게 두 가지로 요약할 수 있다.

첫째, 입력의 유연성이다. 매개변수나 인자처럼 정형화된 형태로 값을 넣지 않더라도, 모델이 여러 추론 과정을 거쳐 의도와 맥락을 파악해 그럴듯한 결과를 내놓는다.

둘째, 출력의 불확실성이다. 입력 처리의 유동성을 확보하기 위해 선택한 확률적 구조가 출력에도 그대로 영향을 미친다. 같은 입력이라도 결과가 달라질 수 있고, 이런 모델을 여러 번 연쇄적으로 호출해 만든 결과물은 자칫 통제를 벗어날 수 있다.

LLM(Large Language Model): 방대한 텍스트로 학습한 대규모 언어 모델

왜 하필 OpenClaw인가

OpenClaw는 이런 LLM 기반 프로덕트의 특성을 가장 잘 보여주는 프로젝트다. 이제는 NanoClaw, Hermes처럼 AI Agent를 만들기 위한 프로덕트가 흔해졌고, OpenAI나 Claude처럼 모델 자체를 서빙하는 업체들도 관련 제품을 내놓고 있다. 이 흐름 속에서 초기 프로젝트인 OpenClaw는 다소 레거시처럼 느껴질 수도 있다. 하지만 그렇기에 오히려, AI 대격변의 시대에 우리가 놓치면 안 될 원형(Prototype)을 확인할 수 있는 프로젝트이기도 하다.

장황하게 써놨지만 결국 OpenClaw는, 약간은 투박하고 어렵게 느껴지는 형태로나마 미래를 보여주는 프로덕트다. LLM의 힘을 빌려 '스스로를 개선'한다. SOUL.md, IDENTITY.md, USER.md와 여러 skill 문서들을 통해 자신의 메모리를 쌓아가고, 능력을 확장한다. 동시에 여러 보안적·사회적 문제를 일으킬 가능성도 갖고 있다. 브라우저나 메신저 같은 도구들을 연결할 수 있는데, 여기서 LLM 특유의 '통제 불가능성'이 발동하면 금전적·비금전적 손해를 볼 수 있다.

AI Agent: 사용자를 대신해 도구를 쓰며 작업을 수행하는 AI

Skill: 에이전트가 호출해 쓰는 능력 단위 문서/모듈

운전을 배우듯, 잘 배우는 것이 중요한 OpenClaw

OpenClaw는 처음 운전을 배우는 것처럼 '잘 배우는 것'이 중요한 소프트웨어다. 그런데 OpenClaw는 초심자에게 세팅과 활용 모두 진입 장벽이 꽤 높다. 『오픈클로 with GPT 제미나이 클로드』는 바로 그 벽을 낮춰주는 책이다.

개발자가 아니어도 처음부터 끝까지 따라가기만 하면 나만의 AI 비서를 만들 수 있고, 개발자라면 여기서 익힌 지식을 뼈대 삼아 자기 입맛대로 확장해 나갈 수 있다.

개인적으로는 처음에 개발자라는 객기로 Docker 안에서 격리 환경을 세팅해보겠다고 덤볐다가 결국 통으로 날려먹고, 결국 일반적인 방식으로 설치하는 길을 택했다. 그런데 그 일반적인 설치 과정조차도 이 책이 없었다면 공식 문서를 붙들고 낑낑댔거나, 반대로 Antigravity나 Claude Code 같은 툴에 모조리 위임해버린 채 뭐가 뭔지 모르는 상태가 되었을지도..

특히 이런 도구에 진입할 때 가장 큰 걸림돌이 되는 CLI 사용법과 API Key 발급 같은 부분이 잘 정리되어 있어서, 꼭 OpenClaw가 아니더라도 비슷한 류의 프로그램들에 적응하는 데도 도움이 될 것 같다.

Docker: 앱을 격리된 컨테이너 환경에서 실행하는 도구

CLI(Command Line Interface): 명령어를 입력해 컴퓨터를 다루는 방식

API Key: 외부 서비스를 호출할 때 쓰는 인증 키

아쉬운 점

다만, 관심과 지식욕이 많아 이것저것 들쑤시는 타입이라면 책 한 권으로는 호기심을 다 채우기 어렵다. 나는 책을 읽으며 다음 같은 방향들이 떠올랐다.

• Ollama를 통한 Local LLM 연결 (Qwen3.6-27b)

• Docker 안에서 격리 구동

• OpenRouter, Z.ai, Groq, Nvidia NIM 등 Free Tier를 활용한 비용 최적화

이런 주제들은 책의 설명만으로는 해결되지 않는 부분이 많아서, 따로 몇 시간씩 다른 방향으로 파고들어야 했다. 물론 대부분은 뇌에 과부하가 와서 도중에 때려쳤지만 말이다.

Ollama: PC에서 로컬 LLM을 손쉽게 구동하는 도구

Free Tier: 일정량까지 무료로 쓸 수 있는 사용 등급

『오픈클로 with GPT 제미나이 클로드』는 '무작정 따라 하기' 스타일로 일단 구동까지 끌고 가는, 가장 안전하면서도 확실한 길을 제시해주는 책이다. 이제 실제로 굴려보고 공식 문서와도 씨름하며, 더 잘 활용할 방법들을 찾아보려 한다.

스프링 생태계 기반으로 쫀쫀하게 만드는 AI 에이전트 : 이것이 Spring AI다

이것이 Spring AI다 - LLM을 활용한 AI 에이전트 개발|RAG 특별 동영상 강의 제공, 개정판 ㅣ 이것이 시리즈
신용권 지음 / 한빛미디어 / 2026년 3월

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

AI라고 하면 일반적 사용자들은 ChatGPT, Claude, Gemini 같은 챗봇 형태의 서비스를 생각할텐데, 개발자 입장에서는 좀 더 다양한 층위를 보게 된다. 그런 서비스들은 가장 최신의 모델(훈련된 AI 버전)을 쓰는데 이런 걸 프론티어 모델 혹은 SOTA (State-of-the-Art)라고 한다. SOTA는 말 그대로 '현재 기술 수준에서 가장 앞서있는 모델'을 의미하고, 프론티어 모델은 그 중에서도 성능의 최전선에 있는 것들을 지칭한다. 일반적으로 이것들은 좀 더 호출 당 단가가 비싸서 실제 서비스에 부차적으로 붙이기엔 부담스럽다. 찾아보면 이런 모델들의 열화 버전(mini, nano…) 등이 있는데 이 친구들은 경량화되어 있기에 속도도 빠르고 호출 당 비용도 적지만 자원을 덜 쓰는 만큼 내가 원하는 대로 작동을 안할 확률이 높다.

이런 저렴이 모델을 쓸 경우 대표적인 문제가 환각(Hallucination), Knowledge Cutoff, GIGO 같은 것들이다. 환각은 LLM이 실제로 존재하지 않는 정보를 마치 사실인 것처럼 생성하는 현상이다. 없는 논문을 만들어내거나, 존재하지 않는 API 메서드를 자신있게 알려주는 식이다. Knowledge Cutoff는 모델이 학습된 시점까지의 데이터만 알고 있기 때문에 그 이후의 정보에 대해서는 답변할 수 없는 한계를 말한다. GIGO는 'Garbage In, Garbage Out'의 약자로 입력이 부실하면 출력도 부실하다는 컴퓨팅/데이터 기반 솔루션에 있어 오래된 원칙인데 LLM에서도 그대로 적용된다. 프롬프트를 대충 넣으면 결과도 대충 나온다는 뜻이다.

이런 것들을 최소화하기 위해 LLM에 이것저것 프로그래밍적 술수(?)를 쓰게 되는데 이런 걸 AI 에이전트 코딩이라고 한다. 에이전트 코딩이란 LLM이 단순히 텍스트를 생성하는 것을 넘어서, 외부 도구를 호출하고, 검색을 수행하고, 코드를 실행하는 등 자율적으로 작업을 수행하도록 프로그래밍하는 것을 말한다. 가장 유명하면서 여러 플랫폼/언어에서 쓰이고 있는 LangChain 프레임워크다. 그런데 이게 명목상으로는 JS/Java/Python을 지원하지만 실질적으로는 Python 중심이다 보니 이제 자바/스프링 공화국인 한국에서는 외부 모듈이나 api 서버로 구현하지 않는 한 조금 뭔가 머시기 했던게 사실이다. 그러다 작년(2025년) 즈음해서 Spring AI가 릴리즈 되었고, ChatModel/ChatClient 등을 활용해서 기존에 스프링 컨테이너를 활용한 의존성 주입 및 스프링 부트의 스타터를 통한 편한 패키지/의존성 관리가 가능해졌다.

시중에 LangChain 관련 책들은 많이 존재하는데 Spring AI를 전문적으로 다루는 교재가 없었던게 사실이다. 그러다가 만나게 된게 이 '이것이 Spring AI다 (개정판)'이다. 이게 2025년에 나오고 바로 2026년에 개정판으로 한 번 더 나온 버전이다.

책의 구성

책의 구성은 상당히 튼실하다. 기본적인 Spring AI의 설정과 주요 인터페이스/클래스들부터 프롬프트 엔지니어링을 지나 멀티 모달(이미지, 음성)을 다루며 최종적으로 RAG, Tool Calling/MCP, 에이전트 오케스트레이션까지 나아간다.

• 프롬프트 엔지니어링(Prompt Engineering) : LLM에게 원하는 결과를 얻기 위해 입력(프롬프트)을 설계하고 최적화하는 기술이다. 단순히 질문을 잘 하는 것을 넘어서, 시스템 프롬프트 설정, few-shot 예시 제공, 출력 형식 지정 등 LLM의 응답 품질을 제어하기 위한 체계적인 접근법 전체를 포괄한다.

• 멀티 모달(Multimodal) : 텍스트뿐만 아니라 이미지, 음성, 영상 등 여러 형태의 데이터를 동시에 처리할 수 있는 AI의 능력을 말한다. 예를 들어 이미지를 보고 설명하거나, 음성을 텍스트로 변환하거나, 텍스트로부터 이미지를 생성하는 것이 모두 멀티 모달의 영역이다.

• RAG(Retrieval-Augmented Generation) : LLM의 가장 큰 약점인 환각과 Knowledge Cutoff를 보완하기 위한 기법이다. 사용자의 질문이 들어오면 먼저 외부 데이터소스(문서, DB 등)에서 관련 정보를 검색(Retrieval)한 후, 그 정보를 LLM의 컨텍스트에 함께 넣어 응답을 생성(Generation)하는 방식이다. 이를 위해 문서를 수치 벡터로 변환하는 임베딩(Embedding) 과정과, 그 벡터들을 저장하고 유사도 기반으로 검색할 수 있는 벡터 스토어(Vector Store)가 필요하다. 가르치다보면 이미지 생성이나 음성 인식 같은 것은 곧잘 하지만 RAG, 임베딩, 벡터 파트에서 많이 막히는 편인데 이 책에서 그쪽에 대한 설명이 상세하게 되어 있어서 좋았다.

• Tool Calling : LLM이 직접 수행할 수 없는 작업(실시간 데이터 조회, 계산, 외부 API 호출 등)을 외부 함수/도구를 호출해서 처리하는 메커니즘이다. LLM이 "이 작업은 이 도구로 처리해야겠다"고 판단하면 함수 호출 형태로 요청하고, 그 결과를 받아서 최종 응답에 반영하는 구조다.

• MCP(Model Context Protocol) : LLM이 외부 도구나 데이터소스에 접근할 때의 표준화된 인터페이스를 정의한다. Tool Calling이 개별 함수 호출이라면, MCP는 그것을 표준화된 규격으로 묶어서 다양한 도구 제공자와 LLM 사이의 상호운용성을 확보하려는 시도다.

• 에이전트 오케스트레이션(Agent Orchestration) : 여러 AI 에이전트를 조합하여 복잡한 작업을 수행하도록 관리하는 것이다. 하나의 에이전트가 계획을 세우고, 다른 에이전트가 실행하고, 또 다른 에이전트가 결과를 검증하는 식으로 역할을 분담시키는 패턴이다. LangChain에서는 이런 구조를 LangGraph 등으로 구현하는데, Spring AI에서도 이제 자체적으로 이런 오케스트레이션이 가능해진 것이다.

챗봇의 기본부터 심화까지의 내용을 상세히 실습해볼 수 있다.

실습과 코드

작년(2025년) 초만 하더라도 이정도를 구현하기 위해선 어쩔 수 없이 LangChain4J를 쓰거나 별도의 파이썬 모듈로 LangChain을 구현해야했는데 이제는 Spring 생태계의 통합된 모듈들을 활용해서 프로바이더를 지정하고, 설정 파일을 활용해 문서화하며 관리할 수 있다는게 상당히 놀라웠다.

내용 자체가 LangChain에서 볼 수 있던 접근법과 상당히 유사하긴 하였으나 어쨌든 자바는 자바고, 스프링은 스프링이라서 그 특색을 따라가는 것이 있는데 거기까지 하나하나 설명하기엔 너무나 방대하고 전문적 영역인지라 과감히 예제 코드 중심으로 '작동 원리'를 위주로 설명한 것이 좋았다.

이미 구현된 구조를 타임리프로 구현해놓은 화면에서 주로 실습하게 되는데 굳이 따지자면 최신의 Spring 문법을 따라가고 있진 않아서 약간 고치고 싶은 (@Autowired라든가…) 부분이 있긴한데 오히려 레거시를 관리중에 Spring AI를 통해 챗봇이나 지식 기반 시스템을 만들어야하는 상황이라면 더 유리한 부분이 있겠다 싶었다. 실습 환경이 일단은 VSCode인 것도 보면 확실히 어느정도 만들던 사람들을 타겟팅한다는게 느껴졌다. (자바 환경변수, OpenJDK 등의 문제들을 가능한 피하기 위해서 요새는 초심자 대상이라면 IntelliJ를 선택하는 교재도 많은지라…)

또한 OpenAI의 GPT 계열의 모델을 사용하는 것 뿐만 아니라 부록으로 Gemini, 로컬 모델(Llama, DeepSeek) 등의 사용방법을 소개하고 있어 벤더 의존성을 줄인 것이 좋았다. 책에는 없는 부분이지만 개인적으로는 Groq, NIM, OpenRouter 같은 여러 모델을 사용해볼 수 있는 프리티어 플랫폼을 연동하는 파트를 따로 연습해볼 생각이다.

예제코드가 잘 제공되어 있고 꼭 VSCode로 할 필요는 없다. (본인이 편한 IDE를 쓰면 된다.)

추천 독자

자바에서 LangChain을 써보고 싶었으나 대안을 찾기 어려웠던 사람

기존에는 LangChain4J라는 자바 포팅 프로젝트가 있었지만, 스프링 생태계와의 통합이 매끄럽지 않았고 커뮤니티 규모도 파이썬 쪽에 비해 현저히 작았다. Spring AI는 스프링 프레임워크의 철학(DI, 자동 설정, 스타터)을 그대로 따르기 때문에 기존 스프링 개발자라면 러닝 커브가 훨씬 낮다.

자프링(자바+스프링) 환경에서 AI 에이전트 플랫폼을 개발해보고 싶은 사람

이미 운영 중인 스프링 부트 애플리케이션에 AI 기능을 추가해야 하는 상황이라면, 별도의 파이썬 서버를 띄우는 것보다 같은 생태계 안에서 해결할 수 있다는 것은 운영 복잡도 측면에서 상당한 이점이다.

프롬프트 엔지니어링, 멀티모달, MCP/Tool Calling 등 여러 AI 에이

전트 요소에 대한 전반적 이해가 필요한 사람.

각 개념이 코드 레벨에서 어떻게 구현되는지를 보면서 이해할 수 있기 때문에, 이론만으로는 와닿지 않던 개념들이 구체적으로 다가온다.

#한빛미디어 #나는리뷰어다 #이것이SpringAI다 #SpringAI #스프링AI

#Java #Spring #SpringBoot #자바 #스프링부트 #백엔드개발

#LLM #생성형AI #AI에이전트 #프롬프트엔지니어링 #RAG #MCP #ToolCalling

#에이전트오케스트레이션 #멀티모달 #벡터스토어 #임베딩 #LangChain

#기술서리뷰 #개발서적 #개발자추천도서

생성형 AI 시대 개발자의 사고 전환: 『AI 에이전트 마스터 클래스』

AI 에이전트 마스터 클래스 - 기획, 구현, 운영, 배포까지 현업에서 바로 적용하는 에이전트 개발 가이드
김구현 지음 / 한빛미디어 / 2026년 1월

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

레거시 스택과 생성형 AI 사이의 간극

작년 초부터 생성형 AI와 자바 스프링 백엔드를 접목한 강의를 맡아왔다. 그러나 현실의 커리큘럼은 여전히 JSP(Java Server Pages), MyBatis(퍼시스턴스 프레임워크) 같은 전통 기술을 포함한다.

분기마다 DeepSeek(LLM), o1(추론 특화 모델), nano banana(경량 모델), Claude Code(코드 특화 LLM), OpenClaw(오픈소스 모델) 등 새로운 기술이 쏟아지는 상황에서, 이를 충분히 소화하지 못한 채 기존 스택을 다루는 과정은 구조적 간극처럼 느껴졌다. 특히 에이전트 구현 영역은 가장 난해했다.

LangChain으로 재정렬된 에이전트 개념

강의 특성상 Java 중심, 보조적으로 JavaScript 정도만 다루다 보니 Python 기반 LangChain(LLM 오케스트레이션 프레임워크)을 깊이 있게 접하기 어려웠다. 모델 호출 후 Stream(스트리밍 처리)이나 고차함수로 연결하는 수준에서 멈출 수밖에 없었다. 부트캠프 환경에서는 일정 깊이 이상을 다루면 오히려 이해도를 해칠 수 있다는 제약도 존재했다.

이 책은 그 단절된 개념들을 정리해준다. 기존 프로그래밍 패턴으로 설명하던 호출 체계, 상태 관리, 체이닝 구조가 LangChain을 통해 하나의 추상화 계층으로 묶인다. 그러나 핵심은 프레임워크 자체가 아니다. 프롬프트 품질 관리, 다중 모델 통합, 출력 스키마 제어 같은 문제를 어떻게 구조적으로 해결하는지가 중심이다. 에이전틱 사고(목표 기반 문제 해결 구조)를 체계화하는 데 의의가 있다.

RAG·MCP를 통한 구조 확장

책은 GPT-5-nano(경량 모델), LangChain, Colab(클라우드 노트북), Streamlit(파이썬 웹 UI) 중심으로 구성되어 학습 부담을 낮춘다. 환경 설정과 모델 선택에서의 복잡도를 최소화한 점은 분명 장점이다. 동시에 다양한 벤더나 배포 환경을 폭넓게 다루지는 않는다.

RAG(검색 증강 생성)와 MCP(Model Context Protocol, 모델-도구 연결 규약) 같은 개념은 단순한 텍스트 생성 단계를 넘어, 외부 데이터와 도구 호출을 결합한 구조로 확장하는 방향을 제시한다. 생성형 모델을 “출력기”가 아닌 “구성 요소”로 다루는 시각을 제공한다는 점에서 의미가 있다.

프레임워크를 넘어 설계 철학으로

이 책은 종착점이 아니라 정리된 출발점에 가깝다. LangChain4j(Java용 LangChain), Spring AI(스프링 기반 AI 통합), Ollama(로컬 LLM 서빙), OpenRouter·Groq·Gemini·NVIDIA NIM(다중 모델 API) 같은 환경에서도 동일한 문제 정의와 구조를 재현할 수 있다. 구현체는 달라도 설계 관점은 유지된다.

결국 중요한 것은 특정 라이브러리의 API 숙련도가 아니라, 모델 호출을 어떻게 추상화하고, 상태를 어떻게 통제하며, 출력을 어떻게 계약화(contract)할 것인가에 대한 사고 체계다. 이 책은 그 관점을 비교적 안정적으로 제공한다.

추천 독자

이 책은 다음과 같은 독자에게 적합하다.

• 생성형 AI를 실무 백엔드와 연결하려는 개발자
• LangChain의 개념 구조를 한 번에 정리하고 싶은 독자
• RAG나 도구 호출 기반 에이전트 구조를 처음 접하는 사람
• Python 중심 실습으로 빠르게 전체 그림을 파악하고 싶은 개발자

반면, 멀티 벤더 운영 전략이나 대규모 프로덕션 아키텍처 설계를 기대한다면 보완 학습이 필요하다. 기본 개념을 정리하고 구조적 사고를 다지는 용도로 적절한 기술서다.