처음 만드는 AI 에이전트 서비스 - 매일 쓰던 LLM을 직접 조립해서 배포까지

“길벗 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

처음 만드는 AI 에이전트 서비스 도서

왜 이 책을 선택했나 - 호출하고 답받으면 에이전트 서비스인가

ChatGPT와 Claude는 매일 쓴다. 코드를 짜다가도 쓰고, 글을 다듬을 때도 쓰고, 막히면 일단 물어본다. 그런데 제대로 된 에이전트 서비스를 직접 만들려면 어떻게 해야 하나.

만들어보고 싶다는 생각은 오래 했다. 랭체인으로 하면 된다는 말을 듣고 몇 개 대충 만들어보기도 했다. LLM 호출해서 답을 받아 뿌리면, 이 정도면 에이전트 서비스 아닌가 싶었다.

아니었다. 기능을 하나 붙이면 프롬프트가 길어지고, 요청에 따라 다른 처리를 해야 할 때 그걸 if문으로 갈라야 하는지 모델에 맡겨야 하는지도 몰랐다. 무엇보다 그게 어떻게 서비스가 되는지 — API로 감싸고 화면을 붙이고 배포하기까지 — 이어진 그림으로 본 적이 없었다.

처음 만드는 AI 에이전트 서비스를 고른 이유가 그거였다. 목차가 LLM 호출에서 시작해 배포에서 끝난다. 조각이 아니라 하나의 프로젝트가 끝까지 가는 구성이라 손이 갔다.

만드는 결과물도 명확하다. 글을 넣으면 요약하고, 감성을 분석하고, 다시 써주는 AI 글 분석 서비스다. 실습 대상이 처음부터 정해져 있으니 각 장이 무엇을 위한 단계인지 헷갈리지 않는다.

12장 한눈에 보기 - 이 책이 실제로 다루는 범위

파트	장	다루는 것
Part 1 기초 다지기	1~4장	개발 환경 / LangChain 설치와 API 키 관리 / 프롬프트 템플릿 / LCEL과 출력 구조화
Part 2 에이전트 만들기	5~7장	Tool 정의와 입력 구조 / 요약·감성 분석·재작성 Tool 구현 / 에이전트 구현과 디버깅
Part 3 서비스 완성	8~12장	FastAPI 백엔드 / 에이전트를 API로 연결 / React + Tailwind 화면 / 클라우드 배포

파트가 그대로 학습 단계다. 개념 → 기능 조립 → 서비스화로 올라간다. 앞 파트에서 만든 것이 다음 파트의 재료가 되기 때문에, 이 책은 필요한 장만 뽑아 읽는 방식이 잘 안 맞는다. 순서대로 따라가야 한다.

개인적으로는 4장을 넘기지 말라고 하고 싶다. Runnable과 LCEL이 뒤에 나오는 모든 조립의 문법이라서, 여기를 대충 보면 5장부터 코드가 왜 이렇게 생겼는지 계속 되짚어야 한다.

Part 2 Tool과 에이전트 - 기능을 쪼개고 에이전트에 연결한다

하나의 프롬프트에 다 밀어 넣고 있었다

그동안 나는 프롬프트 하나에 전부 담았다. 요약도 해주고, 톤도 봐주고, 필요하면 다시 써달라고. 되는 것처럼 보이지만 결과가 매번 달랐고, 어디를 고쳐야 결과가 어떻게 바뀌는지 예측할 수 없었다.

이 책은 그걸 세 개의 Tool로 쪼갠다. 글 요약, 감성 분석, 재작성. 각각 따로 만들고 따로 검증한다(6.5 Tool 통합 검증).

쪼개고 나서야 이해된 게 있다. 하나의 프롬프트는 고칠 지점이 하나뿐이지만, 세 개의 Tool은 문제가 생긴 Tool만 고치면 된다. 프롬프트 엔지니어링이 아니라 함수를 나누는 이야기였다.

Tool 정의가 곧 에이전트의 판단 근거다

5장에서 가장 중요한 절은 Tool 입력 구조를 정의하는 부분(5.3)이었다.

처음에는 왜 입력 스키마까지 굳이 정의하나 싶었다. 그런데 7장에서 에이전트를 만들면서 이유가 붙었다. 에이전트는 사람이 짠 if문으로 Tool을 고르는 게 아니라, Tool의 이름·설명·입력 정의를 읽고 스스로 고른다. 그러니까 Tool을 어떻게 설명해 뒀느냐가 그대로 에이전트의 판단 품질이 된다.

Tool을 흩어놓지 않고 목록으로 관리하는 절(5.5)도 뒤에서 도움이 됐다. Tool이 세 개일 때는 티가 안 나지만, 늘어날 때 어디를 건드려야 하는지가 여기서 정해진다.

ReAct - 생각하고, 도구를 쓰고, 다시 생각한다

ReAct 패턴 실행 흐름

7장의 동작 원리(7.1)에서 막혀 있던 게 풀렸다. 에이전트가 ReAct 방식으로 움직인다는 부분이다. Reasoning과 Acting, 생각과 행동을 번갈아 반복한다는 뜻이다.

한 번 호출해서 한 번 답하는 구조가 아니다.

요청을 받고 지금 무엇이 필요한지 판단한다 (생각)
필요한 Tool을 고르고 호출한다 (행동)
그 결과를 다시 입력으로 받는다 (관찰)
충분한지 판단해서, 부족하면 1번으로 돌아간다

여기서 핵심은 반복 자체가 아니다. 그 호출 순서를 내가 코드로 작성하지 않는다는 점이다.

평소대로 짠다면 “요약 함수를 부르고, 그다음 감성 분석을 부르고, 결과를 합친다”를 내가 정해서 적어야 한다. ReAct에서는 그 순서를 매 단계마다 모델이 정한다. 요약만 필요한 요청이면 Tool 하나로 끝나고, “요약하고 톤도 봐줘”면 루프가 두 바퀴 돈다. 내가 작성하는 건 Tool 목록과 각 Tool의 설명까지다.

“모델이 알아서 판단한다”는 말은 그동안 여러 번 들었는데, 정확히 무엇을 판단하는지가 늘 흐릿했다. 판단하는 대상은 어떤 Tool을 언제 부르고 언제 멈출지였다. 도입에서 if문으로 갈라야 하나 싶었던 게 여기서 걷혔다.

이런 분께 추천합니다

첫째, LLM을 매일 쓰지만 만들어본 적은 없는 개발자

API를 호출해본 적은 있어도 Tool이 뭔지, 에이전트가 뭘 근거로 움직이는지는 설명하기 어려웠던 경우. 이 책은 그 사이를 한 프로젝트로 이어서 보여준다. 개념을 따로 공부하고 조립을 알아서 하라고 미루지 않는다.

둘째, AI 기능을 서비스까지 올려본 적 없는 사람

파이썬으로 스크립트는 돌리는데 API·화면·배포 중 하나라도 막막했다면, Part 3만으로도 쓸모가 있다. 백엔드와 프런트엔드를 한 권에서 같은 프로젝트로 다루는 책이 흔하지 않다.

다만 개발자 입장에서는 조금 더 깊었으면 하는 지점이 있었다. 왜 이 방식을 골랐고 다른 선택지와 무엇을 맞바꾸는지, 비용과 지연은 어떻게 다루는지 같은 이야기다. 이 책은 그쪽 대신 전체를 빠르게 한 바퀴 돌리는 쪽에 확실히 무게를 뒀고, 처음 접근하는 사람에게는 그 선택이 맞다고 생각한다. 한 바퀴를 돌고 나서 더 필요하면 그때 더 깊은 책으로 넘어가면 된다.

정리 - 남은 건 조립 순서였다

처음 만드는 AI 에이전트 서비스를 한 문장으로 정리하면 이렇다.

“LLM 호출에서 배포까지, 한 프로젝트로 한 바퀴 돌게 해주는 책.”

308쪽을 덮고 남은 건 랭체인 API 지식이라기보다 순서였다.

프롬프트로 형태를 잡고 → 기능을 Tool로 쪼개고 → 에이전트가 고르게 하고 → API로 감싸고 → 화면을 붙이고 → 배포한다.

이 순서를 한 번 통과해 두면, 다음에 만들 게 글 분석이 아니어도 각 단계에서 뭘 결정해야 하는지는 안다. 지금 만들고 있는 웹 서비스에도 붙일 만한 자리가 몇 군데 보인다.

피드백은 언제나 환영입니다.