[이것이 Spring AI다] Spring, 백엔드 프레임워크 아니었어?

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

이것이 Spring AI다 / 신용권 저

---

배경

나는 2025년도부터 개발자들 사이에서 Spring AI에 대한 관심도가 부쩍 높아진 것을 체감했다. 아무것도 모르는 상태에서 처음 든 생각은 '파이썬이 AI 생태계를 주도하는 상황에서 Spring이 여기까지 넘본다고?' 였다. 찾아보니 대부분 개발된 모델/에이전트를 서비스 내로 포팅하는 느낌의 기능들을 가지고 있었고, 그제서야 그들의 선택을 이해할 수 있었다. 그렇게 다소 막연하게만 알고 있던 상황이었는데, 이번에 책을 받아 읽을 기회가 생겨 잠깐 훑어보니 생각보다 더 많은 기능을 지원하고 있었다.

 

들어가기 앞서, 내가 이해한 Spring AI의 역할을 Python을 활용한 모델 개선과 구분지어 비유를 통해 설명해보고자 한다. AI를 활용하는 단계를 크게 세 단계로 나누어 비유하면 ①수능 N등급의 학생에게 ②실무를 가르치고 ③성과를 내도록 만드는 과정이라고 생각한다. Python에서의 모델링은 더 높은 수능 등급을 가진 학생 ─ 기초 역량이 더 높은 주체로 만드는 것이다. 그러나 그래봤자 수능이고, 고졸로 취직하든 대학에서 전공을 가지든 필요한 지식을 주입해야 실무자가 될 수 있다. 또 필요한 지식을 가지고 있어도, 업무의 목표나 고객의 요구사항이 분명하지 않으면 원하는 결과물을 얻지 못한다. 이러한 맥락에서 Python은 1번과 2번, Spring은 2번과 3번 과정에 집중한다. hugging face, llama 등 오픈 소스로 모델을 활용할 수 있는 길이 열려있는 상황이 앞으로도 지속된다면, Spring AI를 잘 활용하는 것만으로도 충분히 좋은 결과를 만들어낼 수 있으리라 생각한다.

전체 아키텍처

AI 응용 서비스의 아키텍처

 

이 책에서는 AI를 사용하는 서비스의 개략적인 구조를 제시하는데, Web Application 계층을 포함한 중간 계층의 상호작용 양상이 복잡해지는 것을 볼 수 있다. 이러한 경향성은 여기서 내부/외부 도구라고 명명되었지만, 넓게 보면 많은 수의 마이크로서비스가 필수적인 환경으로 변화하고 있다는 느낌을 받았다. 일부 도구들은 필요에 따라 자체적으로 만들어 사용되지만, 대부분의 경우에는 벤더에서 제공하는 것을 가져다쓰고, 이런 저런 상황들을 고려하다보면 결국 웹 통신 계층에서 통합하는 것이 가장 깔끔하기 때문일지도 모른다. 더불어 소규모의 목적 지향적인 도구 또는 에이전트들을 조합하는 것이, 하나의 큰 에이전트를 학습시키는 것보다 더 효율적이라는 측면도 있을 것이다. 이러한 생각의 흐름에 따라 Spring AI에서는 이러한 흐름을 어떻게 통합하고 있을지 궁금해졌다.

Chapter 11. 도구 호출

Spring AI 도구 호출 흐름

 

특별한 기능이 있는 건 아니다. 프레임워크로서 쉽고 빠르게 시작할 수 있는 구조를 제공하는 것은 예외 없이 Spring AI에서도 이어진다. `@Tool` 어노테이션은 메서드를 도구로 정의하고, `@ToolParam` 어노테이션은 그 도구를 사용하기 위한 파라미터, ToolContext는 Map 타입의 객체로 민감한 데이터 등 추가 데이터를 실어보내기 위해 인자로 활용한다. 경우에 따라서는 5번 과정을 거치지 않고, 바로 6번으로 향하도록 호출 흐름을 수정할 수도 있다.

Chapter 12. MCP, 외부 도구

지금까지 다룬 내용은 내부 도구 - 우리가 코드 수준에서 직접 정의한 도구에 대한 것이었다. 따라서, 외부라고 하면 벤더 사에서 제공하거나 오픈소스로 공개된 MCP 서버를 의미하는 것이 일반적이다. 이것도 본질적으로는 내부 도구와 큰 차이가 없다. 기존의 아키텍처의 관점으로 보았을 때에는 특별한 업무를 담당하는 마이크로서비스 중 하나일 뿐이다. 물론 내부 도구와 비교하면 통신 방식과 규모에 있어 차이가 생긴다. 크게 표준 입출력(STDIO) 방식과 SSE 방식으로 나뉘는데, 현재 운영중인 서비스의 성숙도 또는 의존 MCP 서버의 규모에 따라 자연스럽게 전자에서 후자로 넘어가는 것을 고려해보면 좋을 것 같다.

새롭게 생겨난 개념에 대해 이미지를 활용하여 비유적으로 설명하는 내용들이 있다.

Chapter 13. 에이전트 개발

이 책의 내용에 의하면 에이전트를 크게 3가지 - 사용자의 지시(Prompt), 에이전트의 기억 및 맥락(Advisor), 그리고 활용 가능한 도구(Tool)로 분해하여 보고 있다. 앞서 개요에서도 명시했듯이, Spring AI는 주어진 모델을 잘 튜닝하는 것에 초점을 두고 있다. 따라서, 여기서의 `개발`은 각 에이전트에게 부여된 목표를 위해 사전에 지시를 내리고, 에이전트가 그 지시를 잘 기억하는지, 그리고 맥락에 따라 적절한 도구를 활용할 수 있는지가 성능 평가 지표가 될 것이다.

 

이러한 작업을 흔히 `프롬프트 엔지니어링`이라 부르는데, AI의 활용도가 점차 성숙해짐에 따라 성능을 얻기 위한 전형적인 방법들이 많이 연구되었으나, 하나의 에이전트로는 원하는 결과를 안정적으로 얻는 것이 어려운 것이 현실이다. 애초에 자연어가 규약만을 서술하기 위해 고안된 것도 아니고, 심지어 우리의 요구사항 자체도 자연어로 쓰여질 때 의미가 모호해지기 때문이다. 또한 아무리 엄밀하게 지시한다고 한들, 결국 에이전트가 기억해야 하는 맥락은 요구사항이 추가됨에 따라 지수적으로 상승할 것이며, 그에 따라 응답 속도나 컴퓨팅 자원에서 손해를 보게 될테니, 그냥 일찌감치 싱글 에이전트의 한계를 인지하는 편이 낫다.  

에이전트 개요

Chapter 14. 멀티 에이전트로 협업하기

개인적으로 AI를 활용한 서비스를 고안할 때 가장 재미있는 부분이 아닌가 싶다. 오케스트레이터를 활용해서 다양한 에이전트 간의 상호작용을 거치며 응답을 생성하는 과정이다. 개인적으로는 멀티 에이전트를 잘 사용하려면 응답은 잘 분해하고 출력은 적절히 제한시켜야 하며, 응답을 생성하는 것보다 잘 평가하다고 생각하는 입장이다. LLM은 태생적으로 할루시네이션을 발생시킬 수 밖에 없는데, UX의 관점에서 이런 무가치한 답변을 그대로 내보내는 순간 고객의 신뢰도가 급감할 것이기 때문이다. 물론 서비스의 성격에 따라 예능적인 요소를 갖는 경우에는 이러한 부담이 덜하겠지만, '이 답변 잘못된 거 아니야?'라는 의심이 커지다보면, 고객 입장에서는 서비스 이용의 피로도가 자연스레 높아질 수 밖에 없다.

 

예를 들어, 지도 앱에서 '이 근처에 맛집은 어디야?'라고 물어본다면 에이전트는 일차적으로 이 질문이 단순 장소 검색이 아니라는 것을 인지해야 한다. 다음에는 `근처`, `맛집`이라는 키워드에 착안하여 이를 '반경 1km 이내 맛집 위치'로 바꿀 수 있어야 한다. 다음에는 그 질문을 사용자의 현재 위치 파악, 지리적 정보 기반으로 설계된 데이터베이스에 음식점 질의, 맛집 별점 및 후기 정보 평가로 작업을 분해할 수 있어야 한다. 마지막 단계에서 `맛집`이라는 매우 주관적인 키워드를 어떻게 해석할 지가 관건이 되며, 보통 이러한 하나의 관심사가 하나의 MCP 서버로서 관리된다. 리뷰 신뢰도를 AI로 평가하여 필터링하고 맛집은 단순히 별점 순으로 정의한다든지, 또는 고객을 프로파일링하고 유사도 기반 추천 알고리즘을 활용하는 등의 다양한 방법이 가능하다.

 

하지만 앞서 `평가`를 강조한 것처럼, 피드백 루프가 없는 AI 앱은 실속없는 수다쟁이가 되버리기 쉽다. 가장 좋은 것은 짧은 피드백 루프 - 즉, 검색 즉시 고객에게 피드백을 받는 것이지만, 사용자를 피곤하게 만든다는 점에서 바람직하지만은 않다. 결국 그 사람이 실제로 방문하기 위해 길찾기를 했는지, 지리적 정보로 실제 이동했는지, 다음에 또 검색을 했는지 등의 정보를 토대로 이전 에이전트의 응답이 적절했는지에 대한 사후 평가도 필요하다는 생각이다. 그리고 평가가 되었더라도 출력이 장황하면, 이것을 다음의 개선된 응답을 위한 데이터로 활용하기가 어렵다. 따라서, 응답에 사용된 하위 에이전트들의 응답을 제한시켜 표준화된 파라미터 A, B, C로 정의하고, 그에 대한 평가 D를 기록해두는 식의 방향성을 갖고 다음에는 더 나은 응답이 나올 수 있는 루프를 설계할 필요가 있다고 생각한다.

책에서는 멀티 에이전트와 관련된 내용들을 간단히 소개한다

---

후기: 새로운 시대

Spring은 현재 정부 표준이라는 점에서 대한민국 웹 개발 시장에서 경쟁력이 있는 프레임워크이다. 23년도부터는 기존 7급만 뽑던 전산 데이터직이 9급 공무원까지 확장되었으며, 이러한 경향에 따라 향후 Spring AI가 국가 표준으로 자리잡을 수도 있다. 사용자 친화적이라는 관점에서 LLM은 앞으로 고객과 맞닿은 영역에서 필수 불가결한 존재가 될 것이며, 모든 B2C 사업에 고부가가치를 창출하기 위한 핵심 아이템으로 자리잡을 것이다. Spring AI는 앞으로 더 널리 활용될 것이라 생각하며, 이러한 관점에서 책이 제공해주는 소스 코드를 기반으로 컨셉과 실제 활용 사례를 빠르게 확인해볼 수 있어 새롭게 접하는 이들을 위한 좋은 시작점이 되겠다고 느꼈다.

전자정부 표준프레임워크

 

👉 책 보러 가기

https://www.hanbit.co.kr/store/books/look.php?p_code=B8856838821