[26년 독후감 12] 에이전트 시대의 AI 시스템 설계 : 생성형 AI를 ‘사용’하는 시대에서 ‘설계’하는 시대로

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

📖 책 정보

• 책 제목: 에이전트 시대의 AI 시스템 설계
  • 부제: RAG, 최적화, 가드레일로 완성하는 32가지 프로덕션 패턴
• 저자: 발리아파 락슈마난, 하네스 하프케
• 출판 연도: 2026년
• 장르: 컴퓨터/IT, 인공지능, 기계학습, AI 시스템 설계

 

---

❓ 책을 고른 이유 (물음표)

이번 5월 서평 신청 도서는 한빛미디어의 《에이전트 시대의 AI 시스템 설계》이다. 최근에는 자기계발서를 읽었기 때문에 이번에는 전공과 조금 더 직접적으로 연결되는 기술 도서를 진득하게 읽어보고 싶었다. 그러던 중 최근 출간된 한빛미디어-O’Reilly 번역서인 이 책을 보게 되었고, 지금 내가 관심을 가지고 있는 생성형 AI와 서비스 개발 방향에 잘 맞는 책이라고 생각해 선택하게 되었다.
요즘은 생성형 AI를 활용하면 누구나 빠르게 코드를 작성하고 간단한 서비스를 만들어볼 수 있는 시대가 되었다. 하지만 실제로 AI 기능을 서비스에 안정적으로 적용하려면 단순히 프롬프트를 잘 쓰는 것만으로는 부족하다고 느꼈다. 생성형 AI에는 환각, 비결정적인 응답, 지식 공백, 비용, 지연시간, 안전성 같은 문제가 있고, 이런 한계를 어떻게 설계로 보완할 수 있는지가 중요하다고 생각했다.
이 책은 LLM 애플리케이션과 AI 에이전트를 구축할 때 필요한 32가지 설계 패턴을 다룬다고 해서 특히 흥미가 갔다. RAG, 최적화, 가드레일, 에이전트 구축 등 실제 서비스 개발에서 마주칠 수 있는 문제들을 패턴 중심으로 설명한다는 점이 마음에 들었다. 단순히 생성형 AI를 사용하는 방법을 배우는 것이 아니라 전공자답게 AI 시스템을 어떻게 설계하고 안정적으로 운영할 수 있는지 배울 수 있을 것 같았다.
특히 복학 전에 나만의 서비스를 하나 출시해보고 싶다는 생각을 하고 있는데 이 책이 그 과정에서 많은 도움이 될 것 같다. 생성형 AI를 활용한 서비스를 만들 때 어떤 구조로 설계해야 하는지, 어떤 문제를 미리 고려해야 하는지 배울 수 있을 것 같아서 이번 책은 조금 더 진지하게 집중해서 읽어보고 싶다.

---

📚 독서 과정

• 읽은 기간: 26.05.07 ~ 26.05.19

---

✍️ 책 내용 & 정리

이 책은 생성형 AI를 단순히 “잘 사용하는 방법”이 아니라 실제 서비스에 넣을 수 있는 “AI 시스템으로 설계하는 방법”을 다룬다. 처음에는 책 두께가 꽤 부담스러웠다. 전체를 처음부터 끝까지 완독하기보다는 내가 지금 관심 있는 AI 서비스 개발과 직접 연결될 만한 패턴을 먼저 골라 읽는 방식으로 접근했다. 그래서 RAG, 에이전트, 도구 호출, 코드 실행, 비용 최적화, 장기 기억, 가드레일처럼 실제 서비스를 만들 때 필요할 것 같은 부분을 중심으로 공부했다.
이 책에서 가장 크게 느낀 점은 생성형 AI 시스템이 단순히 LLM API 하나를 호출한다고 완성되는 것이 아니라는 점이다. 요즘은 프롬프트만 잘 작성해도 그럴듯한 결과가 나오기 때문에 “AI 서비스 개발이 쉬워졌다”고 느낄 수 있다. 하지만 책을 읽으면서 프로토타입과 프로덕션 시스템 사이에는 꽤 큰 차이가 있다는 것을 알게 되었다. 실제 서비스에서는 환각, 최신 정보 부족, 비공개 데이터 접근, 응답 일관성, 비용, 지연시간, 보안, 개인정보, 악의적인 입력 등 고려해야 할 문제가 많다. 결국 중요한 것은 모델 자체의 성능만이 아니라 모델을 둘러싼 전체 시스템 구조를 어떻게 설계하느냐였다.
이 책은 이런 문제들을 32가지 설계 패턴으로 정리한다. 소프트웨어 공학에서 디자인 패턴이 반복되는 문제에 대한 검증된 해법을 제공하듯이 생성형 AI 애플리케이션에도 반복적으로 등장하는 문제와 해결 방식이 존재한다. 이 책은 그 패턴들을 콘텐츠 제어, RAG, 추론 강화, 신뢰성 향상, 에이전트, 배포 최적화, 안전장치라는 흐름으로 설명한다. 그래서 읽으면서 단편적으로 알고 있던 AI 개념들이 조금씩 하나의 구조로 연결되는 느낌이 들었다.

내가 먼저 읽은 주요 패턴 한눈에 정리

• 콘텐츠 최적화: 좋은 콘텐츠 스타일을 감으로 정하는 것이 아니라 선호도 데이터로 모델이 더 나은 결과를 만들도록 조정하는 패턴
• 기본 RAG: LLM이 모르는 최신 정보, 내부 문서, 개인화 데이터를 외부 지식 베이스에서 검색해 답변에 반영하는 구조
• 색인 인식 검색: 기본 RAG의 검색 실패를 줄이기 위해 가상 답변, 쿼리 확장, 하이브리드 검색, Graph RAG 등을 활용하는 고급 검색 패턴
• 신뢰할 수 있는 생성: 출처 표시, 도메인 이탈 탐지, 인간 피드백, CRAG 등을 통해 RAG 답변의 신뢰도를 높이는 패턴
• 지시사항 진화: 적은 수의 초기 지시사항을 확장해 도메인 특화 작업을 학습시킬 데이터셋을 만드는 패턴
• 프롬프트 최적화: 프롬프트를 감으로 수정하는 것이 아니라 데이터셋과 평가기를 기반으로 체계적으로 개선하는 패턴
• 도구 호출: LLM이 외부 API나 함수를 호출할 수 있게 하여 실제 행동을 수행하도록 만드는 에이전트 핵심 패턴
• 코드 실행: LLM이 코드를 생성하고 안전한 환경에서 실행하게 하여 계산, 분석, 시각화 작업을 수행하는 패턴
• 다중 에이전트 협업: 여러 전문 에이전트가 역할을 나누어 복잡한 문제를 해결하는 구조
• 소규모 언어 모델: 증류, 양자화, 추측 디코딩 등을 통해 비용과 지연시간을 줄이는 배포 최적화 패턴
• 프롬프트 캐싱: 반복되거나 유사한 요청을 다시 계산하지 않고 재사용해 비용과 응답 시간을 줄이는 패턴
• 장기 기억: 사용자의 과거 대화, 선호도, 핵심 사실을 저장하고 검색해 개인화된 응답을 만드는 패턴
• 자체점검: 토큰 확률이나 불확실성 정보를 활용해 환각 가능성을 감지하는 패턴
• 가드레일: 입력, 출력, 컨텍스트, 도구 호출 전후에 안전장치를 적용해 AI 애플리케이션을 보호하는 패턴

먼저 전체 패턴의 흐름을 잡았다

책의 패턴을 크게 보면 앞부분은 “LLM이 어떤 형식과 스타일로 답하게 할 것인가”에 가깝고 중간 부분은 “LLM이 모르는 정보를 어떻게 외부에서 가져올 것인가” 후반부는 “LLM이 실제 행동을 하게 만들고 안전하고 효율적으로 운영하려면 어떻게 해야 하는가”에 가깝다.
2장에서는 로짓 마스킹, 문법, 스타일 전이, 역중립화, 콘텐츠 최적화처럼 모델의 출력 형식과 스타일을 제어하는 패턴을 다룬다. 이 부분은 AI가 아무 말이나 자유롭게 생성하게 두는 것이 아니라 원하는 형식과 목적에 맞게 결과를 제한하고 다듬는 데 초점이 있다.
3장과 4장은 RAG를 중심으로 한다. LLM은 훈련된 시점 이후의 정보나 기업 내부 데이터, 개인화된 정보에는 기본적으로 접근할 수 없다. 그래서 외부 지식 베이스를 검색하고, 검색한 정보를 프롬프트에 넣어 답변을 생성하게 하는 구조가 필요하다. 기본 RAG에서 시작해서 의미 기반 색인화, 대규모 색인화, 색인 인식 검색, 신뢰할 수 있는 생성 같은 패턴으로 점점 고도화된다.
5장은 모델의 추론 능력과 도메인 적응을 다룬다. 사고 연쇄, 사고 트리, 어댑터 조정, 지시사항 진화 같은 패턴이 등장한다. 여기서 인상 깊었던 점은 LLM이 모든 문제를 알아서 잘 푸는 것이 아니라 복잡한 작업은 단계적으로 생각하게 하거나 특정 업무에 맞는 데이터셋을 만들어 조정해야 한다는 점이었다.
6장은 신뢰성 있는 AI 시스템을 만드는 방법을 다룬다. 심판형 LLM, 성찰, 의존성 주입, 프롬프트 최적화가 나온다. 이 장은 “AI가 답을 잘했는지 어떻게 평가할 것인가”와 “모델이나 프롬프트가 바뀌어도 시스템 품질을 어떻게 유지할 것인가”에 대한 내용으로 이해했다.
7장은 이 책의 제목과 가장 직접적으로 연결되는 에이전트 부분이다. 도구 호출, 코드 실행, 다중 에이전트 협업을 통해 LLM이 단순히 텍스트를 생성하는 것을 넘어 외부 API를 호출하거나, 코드를 실행하거나, 여러 에이전트가 역할을 나누어 문제를 해결하는 구조를 설명한다.
8장은 실제 운영 관점에서 중요했다. 아무리 좋은 AI 시스템이라도 비용이 너무 많이 들거나 응답이 너무 느리면 서비스로 쓰기 어렵다. 그래서 소규모 언어 모델, 프롬프트 캐싱, 인퍼런스 최적화, 성능 저하 테스트, 장기 기억 같은 패턴을 통해 비용과 지연시간, 개인화 문제를 다룬다.
9장은 안전장치에 관한 내용이다. 자체점검과 가드레일이 특히 인상 깊었다. 생성형 AI 애플리케이션은 본질적으로 비결정적이고, 환각이나 악의적 입력에 취약할 수 있다. 그래서 입력과 출력, 컨텍스트, 도구 사용 전후에 안전장치를 두는 것이 중요하다는 점을 배웠다.

콘텐츠 최적화: 좋은 답변 스타일을 감으로 고르는 것이 아니라 학습시키는 방식

내가 먼저 읽은 패턴 중 하나는 콘텐츠 최적화였다. 이 패턴은 생성된 콘텐츠 중 어떤 것이 더 좋은지 비교하고 선택된 결과에 가까운 답변을 모델이 더 자주 만들도록 조정하는 방식이다. 쉽게 말하면 “좋은 콘텐츠의 기준을 말로 완벽하게 설명하기 어렵다면, 좋은 예시와 나쁜 예시를 비교하게 해서 모델이 더 나은 쪽을 따라가게 만들자”는 접근으로 이해했다.
예를 들어 교육 콘텐츠를 만든다고 할 때 어떤 문체가 학습자에게 더 좋은지 처음부터 명확히 알기 어렵다. 문단 길이, 말투, 예시의 양, 설명 방식 등 여러 요소가 결과에 영향을 줄 수 있다. 전통적인 A/B 테스트는 특정 가설이 있을 때는 유용하지만 무엇이 중요한지 모를 때는 한계가 있다. 이 책에서 설명하는 콘텐츠 최적화는 승자와 패자 콘텐츠 쌍을 만들어 선호도 조정을 수행하는 방식으로 이 문제를 풀어간다.
이 부분을 읽고 느낀 점은 AI 콘텐츠 품질을 단순히 “프롬프트를 잘 쓰면 된다”로 끝내면 안 된다는 것이다. 실제 서비스에서는 사용자가 좋아하는 결과, 학습 효과가 좋은 결과, 클릭률이나 전환율이 높은 결과처럼 목적에 따라 좋은 콘텐츠의 기준이 달라진다. 그래서 콘텐츠 생성 시스템을 만들 때는 프롬프트만 수정하는 것이 아니라 어떤 결과가 좋은지 평가하고 그 데이터를 다시 시스템 개선에 활용하는 구조가 필요하다고 느꼈다.
내가 나중에 AI 기반 블로그 요약 서비스나 학습 콘텐츠 생성 서비스를 만든다면 이 패턴을 적용해볼 수 있을 것 같다. 처음에는 여러 스타일의 결과를 생성하고 사용자의 선택이나 피드백을 모아서 어떤 설명 방식이 더 좋은지 학습시킬 수 있다. 단순히 “친절하게 설명해줘”라고 프롬프트에 쓰는 것보다 실제 사용자가 선호한 결과를 기준으로 시스템을 개선하는 쪽이 더 실무적이라고 느꼈다.

기본 RAG: 닫힌 모델을 열린 시스템으로 바꾸는 방법

RAG는 이 책에서 가장 중요하게 느껴진 부분 중 하나였다. LLM은 아무리 똑똑해 보여도 기본적으로 훈련 데이터에 갇혀 있다. 훈련 이후의 최신 정보, 기업 내부 문서, 개인 데이터, 특정 서비스의 실시간 정보는 기본 모델이 알 수 없다. 그런데 사용자는 이런 정보에 대해 질문한다. 이때 모델이 모르는 것을 모른다고 하지 않고 그럴듯하게 답하면 환각이 발생한다.
RAG는 이 문제를 해결하기 위해 모델이 답변하기 전에 외부 지식 베이스에서 관련 정보를 검색하고 그 정보를 근거로 답변하게 하는 방식이다. 책에서는 RAG를 색인화, 검색, 생성이라는 세 단계로 설명한다. 먼저 문서를 적절한 크기의 청크로 나누고 색인화한다. 사용자가 질문하면 그 질문과 관련 있는 청크를 검색한다. 마지막으로 검색된 정보를 프롬프트에 넣어 LLM이 답변을 생성하게 한다.
이 구조를 보면서 RAG는 단순한 “검색 + AI 답변”이 아니라 LLM의 한계를 시스템적으로 보완하는 핵심 구조라는 생각이 들었다. 모델 자체를 다시 훈련하지 않아도 실행 시점에 최신 정보와 내부 정보를 넣어줄 수 있기 때문이다. 특히 기업 서비스나 개인화 서비스에서는 RAG가 거의 필수에 가깝다고 느꼈다.
다만 RAG가 환각을 완전히 없애주는 것은 아니다. 검색된 문서가 부정확하거나 관련 없는 청크가 들어오거나 모델이 검색 결과를 잘못 해석하면 여전히 문제가 생긴다. 그래서 RAG를 적용했다는 것만으로 “이제 신뢰할 수 있다”고 말할 수는 없다. 검색 품질, 청크 분할, 메타데이터, 출처 표시, 후처리까지 함께 설계해야 한다.
이 부분은 내가 나만의 서비스를 만들 때 가장 먼저 적용해보고 싶은 부분이다. 예를 들어 전공 공부 자료, 블로그 글, 프로젝트 문서, 강의 PDF를 기반으로 질문에 답하는 개인 학습 도우미를 만든다면 기본 구조는 RAG가 될 것이다. 내가 업로드한 자료를 색인화하고, 질문과 관련 있는 부분을 찾아 답변하게 만들면 단순 챗봇보다 훨씬 실용적인 서비스가 될 수 있을 것 같다.

색인 인식 검색: RAG의 검색 실패를 줄이는 고급 방법

기본 RAG를 이해한 뒤에는 색인 인식 검색이 중요하게 느껴졌다. RAG는 사용자의 질문과 비슷한 문서 청크를 검색할 수 있다는 가정 위에 작동한다. 그런데 실제로는 이 가정이 깨질 때가 많다. 사용자가 쓰는 표현과 문서에 쓰인 표현이 다를 수 있고 답변이 여러 청크에 나뉘어 있을 수도 있다. 또는 질문 자체가 너무 추상적이어서 단순 벡터 검색만으로는 좋은 결과를 찾기 어려울 수도 있다.
색인 인식 검색은 이런 문제를 해결하기 위한 여러 방법을 묶은 패턴으로 이해했다. 대표적으로 가상 답변, 쿼리 확장, 혼합 검색, 그래프 RAG가 있다.
가상 답변은 질문 자체로 검색하는 대신 먼저 LLM이 답변처럼 생긴 문장을 만들어보고 그 가상의 답변과 비슷한 문서를 찾는 방식이다. 질문이 문서 표현과 직접 맞지 않을 때 유용할 수 있다. 쿼리 확장은 사용자의 질문을 문서에서 쓰일 법한 용어나 맥락으로 확장해서 검색 품질을 높이는 방법이다. 혼합 검색은 키워드 기반 검색과 임베딩 기반 검색을 함께 사용한다. 의미 기반 검색은 전체 의미를 잘 잡지만 세부 키워드를 놓칠 수 있고 키워드 검색은 정확한 단어 매칭에 강하므로 둘을 섞으면 더 안정적인 검색이 가능하다. 그래프 RAG는 문서나 청크 사이의 관계를 그래프로 구성하고 하나의 청크만 보는 것이 아니라 관련된 노드까지 함께 탐색하는 방식이다.
이 부분을 읽으면서 RAG 시스템의 성능은 LLM 성능보다 검색 설계에 더 크게 좌우될 수도 있겠다는 생각이 들었다. AI 서비스가 틀린 답을 하는 이유가 모델이 나빠서가 아니라 애초에 잘못된 문서를 검색해서일 수도 있기 때문이다. 그래서 RAG를 공부할 때는 단순히 벡터 DB를 붙이는 수준을 넘어서 검색 전략 자체를 깊게 봐야 한다고 느꼈다.
앞으로 더 공부해야 할 부분도 여기서 생겼다. 임베딩, BM25, 하이브리드 검색, 재순위화, Graph RAG 같은 개념은 실제 구현 경험이 있어야 제대로 이해할 수 있을 것 같다. 나중에 개인 학습 자료 기반 Q&A 서비스를 만든다면,단순 벡터 검색부터 시작해서 검색 품질이 부족할 때 쿼리 확장이나 하이브리드 검색을 추가하는 식으로 실험해보고 싶다.

신뢰할 수 있는 생성: 답변을 잘 만드는 것만큼 신뢰를 표현하는 것도 중요하다

신뢰할 수 있는 생성 패턴은 RAG 시스템이 만든 답변을 사용자가 믿을 수 있게 만드는 방법에 관한 내용이었다. RAG를 사용하면 외부 문서를 근거로 답변할 수 있지만 검색 실패나 오래된 문서, 편향된 문서, 추론 오류, 환각 위험은 여전히 존재한다. 그래서 책에서는 답변 자체의 품질뿐 아니라 답변의 신뢰도를 어떻게 표현하고 관리할지도 중요하게 다룬다.
가장 기본적인 방법은 도메인 이탈을 탐지하는 것이다. 시스템이 답변할 수 없는 질문에는 억지로 답하지 않는 것이 더 신뢰를 준다. 예를 들어 의료 문서 기반 RAG 시스템에 길찾기 질문이 들어오면 그 질문에 답하는 것이 아니라 해당 시스템의 범위를 벗어났다고 알려주는 편이 낫다.
출처 표시도 중요하다. 사용자는 AI의 답변만 보는 것보다 그 답변이 어떤 문서나 자료를 기반으로 나왔는지 확인할 수 있을 때 더 신뢰하게 된다. 이 책에서는 소스 수준 추적, 분류 기반 출처 표시, 토큰 수준 귀속 같은 방식을 다룬다. 특히 실제 서비스에서는 모든 문장에 출처를 달 필요는 없더라도 사실 주장이나 중요한 의사결정에 영향을 주는 답변에는 출처가 필요하다고 느꼈다.
또한 인간 피드백과 CRAG도 인상 깊었다. CRAG는 검색된 문서가 정말 질문과 관련 있는지 평가한 뒤 부족하면 추가 검색이나 재구성을 수행하는 방식이다. 여기서 중요한 것은 AI 시스템을 한 번의 호출로 끝내는 것이 아니라 검색 결과를 평가하고 보정하는 파이프라인으로 보는 관점이었다.
이 내용을 읽으면서 내가 만들고 싶은 AI 서비스에도 “답변 생성”만 넣으면 부족하겠다는 생각이 들었다. 사용자가 답변을 신뢰할 수 있도록 출처, 근거, 불확실성, 답변 가능 범위를 함께 설계해야 한다. 특히 공부 도우미나 문서 기반 질의응답 서비스라면 “이 답변은 어떤 자료의 어느 부분을 근거로 했는지”를 보여주는 기능이 꼭 필요할 것 같다.

지시사항 진화: 기업 업무나 전문 작업을 모델에게 가르치는 방법

지시사항 진화 패턴은 꽤 어려웠지만 흥미로웠다. 기초 모델은 많은 작업을 할 수 있지만 기업 내부 업무나 특정 조직의 특수한 작업은 잘 모를 수 있다. 예를 들어 특정 회사의 보고서 작성 방식, 내부 의사결정 기준, 고객 응대 정책, 도메인 특화 분석 방식은 공개 데이터에 충분히 포함되어 있지 않을 가능성이 높다. 이런 작업을 모델에게 가르치려면 지시사항 조정을 위한 데이터셋이 필요하다.
문제는 좋은 데이터셋을 만드는 데 비용이 많이 든다는 것이다. 지시사항 진화는 적은 수의 초기 지시사항을 더 다양하고 복잡한 지시사항으로 확장하고, 그에 대한 답변을 생성하고 품질을 평가해 필터링한 뒤 이를 지시사항 조정 데이터셋으로 사용하는 방식이다. 즉 사람이 모든 예시를 직접 만드는 대신 모델과 평가 과정을 활용해 훈련 데이터를 효율적으로 늘리는 방법이다.
책에서 나온 비즈니스 전략 예제가 특히 기억에 남았다. S&P 500 기업의 SEC 제출 서류를 기반으로 비즈니스 전략 질문과 답변을 만들고 모델이 전략 컨설턴트처럼 답할 수 있도록 조정하는 흐름이었다. 내가 경제나 비즈니스에도 관심이 있어서 그런지 이 예제는 단순 기술 예제보다 더 현실적으로 와닿았다. 공개된 기업 자료를 바탕으로 전략 질문을 만들고 그에 대한 분석 답변을 학습시킨다는 발상이 흥미로웠다.
하지만 지시사항 진화는 아무 때나 쓰는 패턴은 아니라고 이해했다. 데이터셋 생성에도 비용이 들고 모델 조정에도 GPU 비용과 시간이 든다. 또 모델을 특정 작업에 맞게 조정하면 기존 능력 일부를 잊어버리는 파국적 망각도 생길 수 있다. 그래서 단순한 작업은 퓨샷 프롬프팅이나 RAG, 어댑터 조정으로 충분할 수 있고 지시사항 진화는 정말 복잡한 도메인 작업을 작은 모델이나 특정 환경에서 수행해야 할 때 고려하는 방식이라고 정리했다.

프롬프트 최적화: 프롬프트도 수작업이 아니라 평가 기반으로 관리해야 한다

프롬프트 최적화 패턴은 내가 기존에 프롬프트를 바라보던 방식을 바꿔준 부분이었다. 보통 AI 서비스를 만들 때 프롬프트는 개발자가 직접 이것저것 바꿔가며 개선한다. 더 자세히 써보거나, 예시를 넣어보거나, 지시사항 순서를 바꿔보는 식이다. 그런데 문제는 모델이 바뀌거나 도구가 바뀌면 이전에 잘 작동하던 프롬프트가 다시 흔들릴 수 있다는 점이다.
이 책에서는 프롬프트를 감으로 고치는 것이 아니라 데이터셋과 평가기를 기반으로 최적화하는 구조를 설명한다. 프롬프트 최적화를 하려면 먼저 애플리케이션의 단계별 파이프라인이 있어야 한다. 그리고 그 파이프라인을 평가할 예시 데이터셋이 필요하다. 다음으로 결과를 평가하는 평가기가 필요하고 마지막으로 여러 프롬프트 후보를 생성하고 비교해 최적의 프롬프트를 찾는 최적화기가 필요하다.
이 부분을 읽으면서 프롬프트도 일종의 소프트웨어 자산처럼 관리해야 한다는 생각이 들었다. 그냥 메모장에 적어두는 문장이 아니라 모델 버전과 데이터셋, 평가 결과에 따라 지속적으로 관리되는 구성 요소에 가깝다. 특히 프로덕션 환경에서는 “내가 보기엔 답변이 좋아 보인다”가 아니라, 정해진 평가 기준에서 이전보다 나아졌는지 확인해야 한다.
앞으로 서비스를 만들 때도 프롬프트를 단순히 작성하는 것에 그치지 않고 테스트 케이스를 만들어야겠다고 생각했다. 예를 들어 학습 도우미라면 대표 질문 30개 정도를 정해두고 프롬프트를 바꿀 때마다 답변 품질이 어떻게 바뀌는지 비교할 수 있어야 한다. 이 과정이 있어야 모델 변경이나 프롬프트 수정에도 서비스 품질을 유지할 수 있을 것 같다.

도구 호출: LLM이 실제 행동을 하게 만드는 핵심 구조

도구 호출은 이 책에서 에이전트 시스템을 이해하는 데 가장 중요한 패턴처럼 느껴졌다. LLM은 기본적으로 텍스트를 생성하는 모델이다. “환불이 처리되었습니다”라는 문장은 만들 수 있지만 실제로 환불 API를 호출해 돈이 입금되게 만들 수는 없다. 항공권 예약 문구를 작성할 수는 있지만 실제 항공권을 예약하려면 외부 API와 연결되어야 한다.
도구 호출 패턴은 이 문제를 해결한다. 사용자의 요청을 수행하기 위해 어떤 함수나 API가 필요한지 LLM이 판단하고 필요한 함수 이름과 인수를 구조화된 형태로 출력한다. 그러면 클라이언트 프로그램이 실제 함수를 호출하고 그 결과를 다시 LLM에게 전달한다. 마지막으로 LLM은 도구 호출 결과를 바탕으로 사용자에게 최종 응답을 생성한다.
중요한 점은 LLM이 외부 함수를 직접 실행하는 것이 아니라는 점이다. 보안상 모델이 임의로 함수를 직접 실행하게 두면 위험하다. 그래서 실제 호출은 클라이언트 쪽에서 수행하고 모델은 어떤 도구를 어떤 인수로 호출해야 하는지 제안하는 역할을 한다. 이 구조를 이해해야 도구 호출이 단순한 마법이 아니라 모델과 애플리케이션 사이의 명확한 인터페이스라는 것을 알 수 있다.
도구 호출은 RAG와도 다르게 이해할 필요가 있다. RAG는 비교적 정적이고 미리 색인화할 수 있는 지식에 강하다. 반면 도구 호출은 날씨, 주가, 캘린더, 이메일, 결제, 기업 API처럼 동적이고 실시간성이 필요한 데이터나 행동에 강하다. 내가 나중에 서비스를 만든다면 문서 기반 지식은 RAG로 처리하고, 실시간 데이터 조회나 외부 시스템 작업은 도구 호출로 처리하는 식으로 나눠볼 수 있을 것 같다.

코드 실행: 말로 답하는 AI에서 계산하고 실행하는 AI로

코드 실행 패턴은 LLM이 코드를 작성하고 그 코드를 안전한 환경에서 실행하게 하는 방식이다. 도구 호출이 미리 정의된 함수를 호출하는 구조라면, 코드 실행은 LLM이 문제 해결에 필요한 코드를 직접 생성한다는 점이 다르다. 예를 들어 그래프를 그리거나, SQL 질의를 만들거나, 데이터 분석을 수행하거나, 시각화를 생성하는 작업에 잘 맞는다.
이 패턴을 읽으면서 LLM이 단순히 답변을 생성하는 것보다 코드를 통해 실제 계산을 수행할 때 훨씬 강력해진다는 점을 느꼈다. 수학 계산이나 데이터 분석을 텍스트로만 처리하면 오류가 생기기 쉽다. 하지만 코드를 생성하고 실행 결과를 바탕으로 답하게 하면 더 정확하고 실용적인 시스템을 만들 수 있다.
다만 보안 문제가 매우 중요하다. LLM이 생성한 코드를 아무 환경에서나 실행하면 위험하다. 악의적인 사용자가 위험한 코드를 생성하도록 유도할 수도 있고 무한 루프나 자원 고갈, 데이터 유출 같은 문제가 생길 수 있다. 그래서 책에서는 모래상자 환경, 실행 시간 제한, 네트워크 접근 제한, 정적 분석, 실행 전 검증 같은 안전장치를 강조한다.
내가 서비스에 코드 실행을 적용한다면 처음부터 범용 Python 실행 환경을 열어두기보다는 제한된 DSL이나 특정 라이브러리만 허용하는 방식이 현실적일 것 같다. 예를 들어 차트 생성, SQL 조회, 간단한 통계 계산처럼 범위가 명확한 작업부터 적용하는 것이 안전하다.

다중 에이전트 협업: 하나의 거대한 모델보다 역할을 나누는 구조

다중 에이전트 협업은 여러 개의 전문화된 에이전트를 조직해서 복잡한 문제를 해결하는 패턴이다. 단일 LLM 호출만으로는 긴 맥락, 여러 단계의 작업, 다양한 도구 사용, 전문 영역별 판단을 모두 안정적으로 처리하기 어렵다. 그래서 하나의 거대한 에이전트에게 모든 일을 맡기기보다 역할을 나눈 여러 에이전트가 협업하도록 설계하는 방식이 필요하다.
이 부분에서 인상 깊었던 것은 다중 에이전트 시스템을 인간 조직과 비슷하게 설명한다는 점이었다. 실제 회사에서도 한 사람이 기획, 개발, 테스트, 배포, 보안, 고객 응대를 모두 완벽하게 처리하기는 어렵다. 각자 역할을 나누고, 서로의 결과물을 검토하고, 필요한 경우 다시 수정한다. AI 에이전트도 마찬가지로 기획 에이전트, 검색 에이전트, 코딩 에이전트, 테스트 에이전트, 리뷰 에이전트처럼 나누어 설계할 수 있다.
다중 에이전트의 장점은 확장성과 견고성이다. 새로운 기능이 필요하면 전체 모델을 다시 만드는 것이 아니라 해당 역할의 에이전트를 추가하거나 교체할 수 있다. 또한 한 에이전트가 만든 결과를 다른 에이전트가 검증할 수 있기 때문에 단일 에이전트가 놓치는 오류를 줄일 수 있다.
하지만 무조건 에이전트를 많이 만든다고 좋은 시스템이 되는 것은 아닐 것 같다. 에이전트가 많아질수록 통신 비용, 지연시간, 상태 관리, 실패 처리, 책임 분리 문제가 복잡해진다. 그래서 실제 적용할 때는 “어떤 작업을 분리할 가치가 있는가”를 먼저 판단해야 한다. 개인 프로젝트에서는 처음부터 복잡한 다중 에이전트 구조를 만들기보다 하나의 에이전트에 도구 호출과 코드 실행을 붙이고, 이후 역할 분리가 필요해질 때 확장하는 방식이 더 현실적이라고 느꼈다.

소규모 언어 모델: 좋은 서비스는 큰 모델만으로 만들어지지 않는다

8장에서는 프로덕션 환경에서 비용과 지연시간을 줄이는 패턴들이 나온다. 그중 소규모 언어 모델 패턴은 특히 현실적인 내용이었다. 프런티어 모델은 성능이 좋지만 비용이 비싸고 지연시간이 길 수 있으며 대규모 서비스에서는 호출 비용이 빠르게 증가한다. 그래서 모든 작업을 가장 큰 모델에 맡기는 것은 비효율적일 수 있다.
소규모 언어 모델을 활용하는 방법으로는 증류, 양자화, 추측 디코딩이 있다. 증류는 큰 모델의 행동을 작은 모델이 따라 하도록 학습시키는 방식이다. 모든 세계 지식을 다 유지하기보다 특정 서비스에 필요한 작업만 잘 수행하도록 작은 모델을 특화하는 개념이다. 양자화는 모델 매개변수의 정밀도를 낮춰 메모리 사용량을 줄이는 방법이다. 추측 디코딩은 작은 모델이 빠르게 토큰을 제안하고 큰 모델이 이를 검증하는 방식으로 속도와 품질의 균형을 맞춘다.
이 부분을 읽으면서 AI 서비스 개발에서 중요한 것은 “가장 똑똑한 모델을 쓰는 것”이 아니라 “작업에 맞는 모델을 적절히 배치하는 것”이라는 생각이 들었다. 간단한 분류, 요약, 형식 변환, 라우팅 같은 작업은 작은 모델로 처리하고 복잡한 추론이나 고난도 생성 작업만 큰 모델에 맡기는 구조가 더 효율적일 수 있다.
내가 실제 서비스를 만든다면 처음에는 프런티어 모델로 빠르게 프로토타입을 만들고 사용 패턴이 안정되면 일부 작업을 작은 모델이나 캐싱 구조로 대체하는 방식으로 최적화할 수 있을 것 같다. 이 부분은 백엔드 개발자의 관점에서도 중요했다. AI 기능도 결국 서버 비용과 응답 시간의 문제를 피할 수 없기 때문이다.

프롬프트 캐싱: 반복 요청을 다시 계산하지 않는 설계

프롬프트 캐싱은 이전에 처리한 프롬프트나 유사한 프롬프트에 대해 결과나 모델 내부 상태를 재사용하는 패턴이다. 서비스에서는 생각보다 같은 질문이나 비슷한 요청이 반복된다. 영업시간, 로그인 문제, 정전 신고, 자주 묻는 정책처럼 사용자의 질문은 완전히 새롭기보다 반복되는 경우가 많다. 이런 요청을 매번 LLM에 새로 계산하게 하는 것은 비용과 시간 측면에서 낭비다.
프롬프트 캐싱에는 클라이언트 쪽 캐싱과 서버 쪽 캐싱이 있다. 클라이언트 쪽 캐싱은 요청과 응답을 키-값 형태로 저장해두고, 같은 요청이 들어오면 모델을 호출하지 않고 저장된 응답을 반환하는 방식이다. 의미 캐싱은 완전히 같은 문장이 아니더라도 의미가 비슷하면 캐시를 활용하는 방식이다. 서버 쪽 캐싱은 주로 프롬프트 앞부분처럼 여러 요청에서 반복되는 부분의 모델 내부 상태를 재사용하는 방식으로 이해했다.
이 패턴은 AI 서비스의 백엔드 설계와 직접 연결된다. 일반 웹 서비스에서도 캐싱은 성능 최적화의 핵심인데, LLM 기반 서비스에서는 캐싱의 효과가 더 클 수 있다. 모델 호출은 일반 API 호출보다 비싸고 느리기 때문이다. 특히 시스템 프롬프트가 길거나, 같은 문서 컨텍스트를 반복해서 사용하는 서비스라면 캐싱 전략이 매우 중요할 것 같다.
내가 만들 서비스에서도 FAQ성 질문, 반복되는 문서 요약, 고정된 시스템 프롬프트, 동일한 자료 기반 질의응답에는 캐싱을 적용할 수 있을 것 같다. 다만 캐싱된 응답이 오래되거나 부정확해질 수 있으므로 캐시 만료 정책과 최신성 관리도 함께 고려해야 한다.

장기 기억: 챗봇이 사용자를 기억하게 만드는 방법

장기 기억 패턴은 사용자의 이전 상호작용을 저장하고 검색해서 세션이 바뀌어도 맥락을 유지하는 방법이다. 기본적으로 LLM은 상태가 없다. 매 호출은 독립적이고 이전 대화를 기억하지 못한다. 챗봇이 이전 대화를 기억하는 것처럼 보이는 이유는 애플리케이션이 이전 메시지를 다시 프롬프트에 넣어주기 때문이다.
하지만 모든 대화 기록을 매번 프롬프트에 넣으면 비용이 커지고 컨텍스트 창도 한계에 부딪힌다. 그래서 장기 기억은 필요한 정보를 저장하고 현재 요청과 관련 있는 기억만 검색해서 사용하는 방식으로 설계해야 한다.
책에서는 기억을 작업 기억, 일화 기억, 절차 기억, 의미 기억으로 나누어 설명한다. 작업 기억은 현재 세션의 대화 흐름을 유지하는 것이다. 예를 들어 사용자가 “그거 큰 걸로 바꿔줘”라고 말했을 때 여기서 “그거”가 무엇인지 알려면 바로 이전 대화가 필요하다. 일화 기억은 과거 세션에서 있었던 특정 경험이나 대화를 저장하고 필요할 때 가져오는 것이다. 예전에 사용자가 어떤 제안을 거절했다면 다음에 같은 제안을 반복하지 않도록 할 수 있다. 절차 기억은 사용자의 선호도나 시스템 지시사항처럼 응답 방식에 영향을 주는 정보를 저장하는 것이다. 의미 기억은 과거 대화에서 추출한 핵심 사실을 의미 중심으로 저장하고 검색하는 방식이다.
이 부분을 읽으면서 개인화 AI 서비스를 만들려면 기억 설계가 정말 중요하다는 것을 느꼈다. 사용자가 매번 자기 상황을 다시 설명해야 한다면 AI 서비스의 가치가 떨어진다. 반대로 적절한 기억을 유지하면 사용자는 “이 서비스가 나를 이해하고 있다”고 느낄 수 있다.
다만 기억은 개인정보와도 연결된다. 무엇을 저장할지, 얼마나 오래 저장할지, 사용자가 삭제할 수 있는지, 민감한 정보는 어떻게 다룰지까지 설계해야 한다. 그래서 장기 기억은 단순히 기능이 아니라 신뢰와 보안의 문제이기도 하다.

자체점검: 모델의 불확실성을 이용해 환각을 감지하기

자체점검 패턴은 토큰 확률을 활용해 환각 가능성을 탐지하는 방식이다. LLM은 답변을 생성할 때 각 토큰에 대한 확률 정보를 가지고 있다. 어떤 토큰을 매우 확신하고 생성했다면 확률이 높고 여러 후보 사이에서 애매하게 선택했다면 확률이 낮을 수 있다. 이 낮은 확률을 환각 가능성의 신호로 활용할 수 있다는 점이 흥미로웠다.
물론 확률이 낮다고 무조건 틀린 것은 아니다. 사람 이름, 고유명사, 드문 숫자처럼 정답이어도 확률이 낮을 수 있다. 그래서 단순히 모든 토큰의 확률을 보는 것이 아니라, 관심 있는 핵심 토큰만 확인하거나 여러 시퀀스를 생성해 비교하거나, 전체 시퀀스의 혼란도를 정규화해서 보는 방식이 필요하다.
이 패턴은 특히 숫자 추출, 문서 이미지 인식, 사실 기반 응답처럼 오류가 치명적인 작업에 유용할 것 같다. 예를 들어 영수증에서 금액을 추출하거나 계약서에서 날짜를 추출하는 시스템이라면 모델이 확신하지 못하는 토큰을 표시하고 그 부분은 사용자 검토를 요구할 수 있다.
이 부분을 읽으면서 “AI가 틀리지 않게 만들기”보다 “틀릴 가능성이 있는 부분을 감지하고 처리하기”가 더 현실적인 접근이라는 생각이 들었다. 완벽한 모델을 기다리는 것보다 불확실성을 측정하고 안전하게 다루는 시스템을 만드는 것이 프로덕션에 더 적합하다.

가드레일: AI 시스템을 서비스로 만들기 위한 마지막 안전장치

가드레일은 LLM의 입력, 출력, 컨텍스트, 도구 매개변수에 안전장치를 적용하는 패턴이다. AI 애플리케이션은 사용자의 자연어 입력을 받기 때문에 예측하기 어려운 상황이 많다. 사용자가 악의적인 프롬프트를 넣을 수도 있고 모델이 허용되지 않은 내용을 생성할 수도 있으며 도구 호출 과정에서 위험한 행동이 발생할 수도 있다. 그래서 모델 앞뒤에 보호 계층을 두어야 한다.
가드레일은 입력 단계에서 부적절한 요청을 차단할 수도 있고 출력 단계에서 개인정보나 위험한 내용을 제거할 수도 있다. RAG 시스템에서는 검색된 컨텍스트가 안전한지 확인할 수도 있고 도구 호출에서는 매개변수가 허용된 범위 안에 있는지 검증할 수도 있다.
이 패턴을 읽으면서 가드레일은 단순히 “나쁜 말 필터링”이 아니라 훨씬 넓은 개념이라는 것을 알게 되었다. 보안, 개인정보, 콘텐츠 정책, 법적 기준, 기능적 제한, 도구 사용 권한까지 모두 포함하는 시스템 보호 장치에 가깝다.
하지만 가드레일에도 트레이드오프가 있다. 너무 엄격하면 사용성이 떨어지고 너무 느리면 서비스 경험이 나빠진다. 또 어떤 가드레일도 완벽하게 모든 공격을 막을 수는 없다. 그래서 가드레일은 한 번 만들어 끝나는 기능이 아니라 계속 평가하고 업데이트해야 하는 보호 계층으로 이해해야 한다.
내가 실제 AI 서비스를 만든다면 최소한 입력 검증, 출력 검증, 개인정보 마스킹, 도구 호출 권한 검사, 로그 기반 모니터링은 기본으로 설계해야겠다고 느꼈다. 특히 도구 호출이나 코드 실행처럼 외부 세계에 영향을 주는 기능을 넣을수록 가드레일은 선택이 아니라 필수라고 생각했다.

이 책을 읽고 정리한 나만의 AI 시스템 설계 흐름

이 책을 읽으면서 내가 머릿속에 정리한 AI 시스템 설계 흐름은 다음과 같다.
먼저 사용자의 요청을 받으면 이 요청이 시스템이 처리할 수 있는 범위 안에 있는지 확인해야 한다. 이 단계에서 입력 가드레일이나 도메인 이탈 탐지가 필요하다. 그다음 요청이 단순 답변인지, 외부 지식이 필요한지, 실시간 데이터나 행동이 필요한지 판단해야 한다.
외부 지식이 필요하면 RAG를 사용해 관련 문서를 검색하고, 검색 품질이 부족하면 쿼리 확장, 하이브리드 검색, 그래프 RAG 같은 고급 검색 전략을 적용할 수 있다. 실시간 데이터나 실제 행동이 필요하면 도구 호출을 사용한다. 계산, 시각화, SQL, 데이터 분석처럼 코드가 더 적합한 작업은 코드 실행을 활용한다.
답변을 생성한 뒤에는 출처 표시, 자체점검, 심판형 LLM, 성찰, 출력 가드레일 등을 통해 결과의 신뢰성을 높여야 한다. 그리고 사용자의 선호도나 과거 대화가 중요한 서비스라면 장기 기억을 활용해 개인화한다. 마지막으로 서비스가 커지면 프롬프트 캐싱, 소규모 언어 모델, 인퍼런스 최적화 같은 방법으로 비용과 지연시간을 줄여야 한다.
결국 좋은 AI 서비스는 “LLM을 붙인 서비스”가 아니라 LLM을 중심으로 검색, 도구, 메모리, 평가, 최적화, 안전장치가 함께 설계된 시스템이라는 생각이 들었다.

앞으로 더 공부하고 싶은 부분

이번에 책을 읽으면서 개념적으로는 많은 것을 배웠지만 실제 구현 경험이 부족한 부분도 보였다. 특히 RAG는 단순히 벡터 DB를 연결하는 수준을 넘어서 청크 분할, 임베딩 모델 선택, 하이브리드 검색, 재순위화, 출처 표시까지 직접 실험해봐야 제대로 이해할 수 있을 것 같다.
도구 호출과 코드 실행도 더 공부하고 싶다. 에이전트형 서비스의 핵심은 결국 LLM이 외부 시스템과 어떻게 안전하게 상호작용하느냐에 있다고 느꼈다. API 설계, 함수 스키마 작성, MCP, LangGraph 같은 프레임워크를 실제로 사용해보면서 구조를 익혀야 할 것 같다.
또한 가드레일과 자체점검은 AI 서비스를 운영하려면 꼭 필요한 부분이라고 느꼈다. 지금까지는 AI가 답을 잘하게 만드는 것에 관심이 많았다면 이제는 AI가 잘못 답했을 때 어떻게 감지하고 막을 것인지도 함께 고민해야겠다고 생각했다.
마지막으로 비용 최적화도 놓치면 안 될 것 같다. 개인 프로젝트에서는 처음에는 큰 모델을 써도 되지만 실제 사용자가 늘어나면 캐싱, 작은 모델, 모델 라우팅, 토큰 절약 전략이 중요해진다. AI 서비스도 결국 백엔드 시스템이기 때문에 성능과 비용을 함께 보는 습관이 필요하다고 느꼈다.
전체적으로 이 책은 생성형 AI를 단순히 편리한 도구로 보는 관점에서 벗어나 하나의 소프트웨어 시스템으로 바라보게 해준 책이었다. 특히 복학 전에 나만의 서비스를 만들어보고 싶다는 목표가 있는 나에게는, 어떤 기능을 어떤 구조로 설계해야 할지 큰 방향을 잡아주는 책이었다. 아직 모든 패턴을 완벽하게 이해한 것은 아니지만, 적어도 “AI 서비스를 만들 때 무엇을 고민해야 하는가”에 대한 기준은 훨씬 선명해졌다.

---

❗ 책을 덮으며 느낀 변화 (느낌표)

이 책을 덮고 나서 가장 크게 남은 생각은 이제 생성형 AI를 단순히 “잘 쓰는 사람”에서 멈추면 안 되겠다는 것이었다. 지금까지는 ChatGPT, Claude, Gemini 같은 모델을 활용해서 코드를 작성하거나 글을 정리하고 간단한 기능을 빠르게 구현하는 데 관심이 많았다. 그런데 이 책을 읽으면서 생성형 AI의 진짜 실력은 모델 하나에서 나오는 것이 아니라 그 모델을 둘러싼 시스템 설계에서 나온다는 것을 느꼈다.
특히 프로토타입과 프로덕션의 차이를 분명하게 보게 되었다. 생성형 AI를 활용하면 그럴듯한 데모는 정말 빠르게 만들 수 있다. 하지만 실제 서비스로 배포하려면 환각, 비결정적인 응답, 지식 단절, 비용, 지연시간, 개인정보, 보안, 가드레일 같은 문제를 반드시 고려해야 한다. 단순히 “AI가 답을 잘한다”가 아니라 “AI가 언제 틀릴 수 있고, 그때 시스템이 어떻게 대응할 것인가”까지 설계해야 한다는 점이 인상 깊었다.
이 책을 통해 RAG, 도구 호출, 코드 실행, 다중 에이전트, 장기 기억, 프롬프트 캐싱, 자체점검, 가드레일 같은 개념들이 따로 떨어진 기술이 아니라 하나의 AI 시스템을 구성하는 부품처럼 연결된다는 것을 알게 되었다. 예전에는 RAG는 문서 검색, Tool Calling은 API 호출, Agent는 요즘 유행하는 기능 정도로만 생각했다. 하지만 이제는 사용자의 요청을 어떻게 이해하고 어떤 지식을 검색하며 어떤 도구를 호출하고 결과를 어떻게 검증하고 위험한 응답을 어떻게 막을 것인지까지 하나의 흐름으로 바라보게 되었다.
또 하나 배운 점은 AI 서비스에서도 결국 소프트웨어 공학적 사고가 중요하다는 것이다. 프롬프트를 잘 쓰는 것도 중요하지만 프롬프트만으로는 안정적인 서비스를 만들 수 없다. 입력과 출력의 형식, 검색 파이프라인, 평가 데이터셋, 캐싱 전략, 비용 최적화, 안전장치, 모니터링까지 함께 설계해야 한다. 결국 AI 시스템도 하나의 백엔드 시스템이고, 개발자는 모델을 호출하는 사람이 아니라 모델이 안정적으로 일할 수 있는 구조를 만드는 사람이어야 한다는 생각이 들었다.
개인적으로 가장 많이 자극받은 부분은 “복학 전에 나만의 AI 서비스를 하나 제대로 만들어보고 싶다”는 목표와 연결되는 지점이었다. 지금까지는 아이디어가 생기면 기능 중심으로 먼저 생각했다. “이런 챗봇을 만들면 좋겠다”, “이런 요약 기능을 넣으면 좋겠다” 정도였다. 하지만 이제는 기능보다 먼저 구조를 고민해야겠다고 느꼈다. 이 기능은 RAG가 필요한지, 도구 호출이 필요한지, 장기 기억을 넣어야 하는지, 사용자 데이터를 어디까지 저장해야 하는지, 답변의 출처를 어떻게 보여줄지, 가드레일은 어디에 둘지 먼저 생각해야 한다.
앞으로는 AI 서비스를 만들 때 처음부터 거창한 에이전트 시스템을 만들기보다, 작은 구조부터 차근차근 실험해보고 싶다. 먼저 내가 가진 PDF, 블로그 글, 강의 자료를 기반으로 답변하는 RAG 기반 학습 도우미를 만들어보고 싶다. 그다음에는 검색 품질을 높이기 위해 하이브리드 검색이나 재순위화, 출처 표시를 붙여보고 이후에는 일정 조회나 문서 생성 같은 기능을 도구 호출로 연결해보고 싶다. 마지막으로 사용자의 학습 기록이나 선호도를 기억하는 장기 기억 구조까지 확장해보면 단순 챗봇이 아니라 진짜 개인화된 AI 서비스에 가까워질 것 같다.
물론 이 책을 읽었다고 해서 모든 패턴을 완벽하게 이해한 것은 아니다. 오히려 내가 앞으로 더 공부해야 할 부분이 더 선명해졌다. RAG의 청크 분할과 임베딩, Graph RAG, LangGraph, MCP, 프롬프트 평가 데이터셋, 가드레일 설계, 비용 최적화 같은 부분은 직접 구현해봐야 내 것이 될 것 같다. 그래도 막연하게 “AI 서비스를 만들어보고 싶다”고 생각하던 단계에서 이제는 “어떤 구조로 만들어야 하는지”를 고민하는 단계로 넘어온 것만으로도 큰 변화라고 느낀다.
결국 이 책은 나에게 생성형 AI를 사용하는 관점에서 설계하는 관점으로 넘어가게 해준 책이었다. AI가 코드를 대신 써주는 시대일수록 개발자는 더 높은 수준의 문제 정의와 시스템 설계 능력을 가져야 한다. 이 책을 읽고 나니 앞으로 내가 만들어야 할 것은 단순히 AI를 붙인 서비스가 아니라 신뢰할 수 있고 유지보수 가능하며 실제 사용자에게 도움이 되는 AI 시스템이어야 한다는 기준이 생겼다.

---

🌟 총평 및 추천 여부

• 별점: ★★★★☆ (5점 만점)
• 이 책을 추천하는 대상:
  • 생성형 AI 시대에 소프트웨어 엔지니어가 어떤 사고방식을 가져야 하는지 고민하는 전공자 및 현업 개발자
• 한줄평: 생성형 AI를 “잘 사용하는 방법”이 아니라,실제로 신뢰 가능한 AI 시스템으로 설계하는 방법을 알려주는 실전 설계 패턴 가이드.