목록으로
개발

Spring AI 2.0, 왜 지금 다시 볼 만한가

·11분 읽기
#Spring AI#Spring Boot#LLM#RAG#MCP
Spring AI 2.0, 왜 지금 다시 볼 만한가

title: "Spring AI 2.0, 왜 지금 다시 볼 만한가" slug: "spring-ai-2-overview" status: "draft" series: "Spring AI 2.0 읽는 순서" order: 1 description: "Spring AI 2.0이 단순한 모델 SDK 래퍼가 아니라 Chat, Tools, Advisors, RAG, MCP를 Spring 방식으로 묶는 프레임워크라는 점을 큰 그림으로 설명하는 입문 글." tags: ["Spring AI", "Spring Boot", "LLM", "RAG", "MCP"] source_docs:

  • "downloads/spring-ai-reference-2.0-ko/index.html"
  • "downloads/spring-ai-reference-2.0-ko/concepts.html"
  • "downloads/spring-ai-reference-2.0-ko/api/index.html"

Spring AI 2.0을 처음 보면 범위가 생각보다 넓다.

보통은 “Spring Boot에서 OpenAI 같은 모델을 한 번 호출해 보는 라이브러리” 정도로 예상하지만, 실제 문서 구조를 보면 훨씬 다르다. ChatClient, Prompt, Embeddings, Tools, Advisors, RAG, Vector Store, MCP, Evaluation, Observability까지 한 흐름 안에 들어 있다.

즉 Spring AI는 모델 API를 감싸는 얇은 어댑터라기보다, AI 기능을 Spring 애플리케이션 안에서 구조적으로 다루기 위한 프레임워크에 가깝다.

이 글은 그 큰 그림을 먼저 정리해 보려는 목적이다. 공급자별 세부 옵션보다 먼저, Spring AI가 무엇을 공통 추상화로 묶고 있는지부터 감을 잡아 두면 이후 문서가 훨씬 빨리 읽힌다.

왜 Spring AI가 따로 필요한가

LLM 앱을 만드는 가장 단순한 방법은 모델 공급자의 SDK를 직접 붙이는 것이다. 작은 실험이라면 그것만으로도 충분하다.

하지만 애플리케이션이 조금만 커져도 금방 문제가 생긴다.

  • 모델 공급자를 바꾸고 싶다.
  • 프롬프트를 코드에서 덜 지저분하게 관리하고 싶다.
  • 벡터 검색과 RAG를 붙이고 싶다.
  • 모델이 외부 도구를 호출하게 하고 싶다.
  • 대화 메모리, 평가, 관찰 가능성을 함께 넣고 싶다.

이때부터는 단일 SDK보다 일관된 애플리케이션 구조가 중요해진다. Spring AI는 바로 이 지점을 노린다.

Spring AI의 핵심 가치는 대략 네 가지로 요약할 수 있다.

  1. 모델 종류와 공급자 차이를 공통 인터페이스로 다룬다.
    텍스트, 이미지, 오디오, 임베딩 모델을 Spring 스타일로 접근하게 만든다.
  2. 프롬프트와 메시지를 애플리케이션 코드 안에서 조립하기 쉽게 만든다.
    단순 문자열이 아니라 시스템 메시지, 사용자 메시지, 옵션, 템플릿을 조합한다.
  3. RAG, Tool Calling, Memory, Advisors 같은 실무형 패턴을 프레임워크 수준에서 연결한다.
  4. Spring Boot 자동 설정과 궁합이 좋다.
    결국 많은 팀이 원하는 것은 “작동하는 첫 버전”을 빠르게 만드는 일인데, Spring AI는 그 출발선을 낮춘다.

먼저 잡아야 하는 핵심 개념

Spring AI가 추상화하는 모델 유형 개요
Spring AI는 텍스트·이미지·오디오·임베딩 모델을 공통적인 애플리케이션 구조 안에서 다룬다.

Spring AI 문서에서 가장 먼저 읽을 만한 페이지가 concepts.html인 이유도 여기에 있다. API보다 먼저 개념을 잡아야 나중에 나오는 클래스 이름이 자연스럽게 읽힌다.

1) 프롬프트는 문자열이 아니라 메시지 묶음이다

Spring AI는 현대 LLM API의 감각을 그대로 가져간다. 즉 프롬프트는 단순한 텍스트 한 줄이 아니라, 역할이 나뉜 메시지들의 집합이다.

  • system: 모델의 태도, 규칙, 역할 설정
  • user: 실제 사용자 요청
  • 경우에 따라 추가 문맥이나 메모리, 검색 결과

이 구조를 먼저 받아들이면 “왜 ChatClient가 fluent API를 제공하는가”도 바로 이해된다.

2) 임베딩은 검색 가능한 의미 표현이다

Spring AI 임베딩 개념도
임베딩은 문서를 의미 벡터로 바꿔 유사도 검색을 가능하게 만드는 출발점이다.

RAG를 이해하려면 임베딩을 알아야 한다. 임베딩은 문서나 문장을 숫자 벡터로 바꿔서, 의미적으로 비슷한 것끼리 가깝게 찾을 수 있게 만든다.

실무에서는 임베딩의 수학보다 다음 감각이 더 중요하다.

  • 데이터 원문을 그대로 뒤지는 게 아니라
  • 의미가 비슷한 문서를 검색 가능한 형태로 변환한다

이게 있어야 벡터 스토어와 RAG가 성립한다.

3) 토큰은 성능 문제가 아니라 설계 문제다

문서에서 강조하는 포인트 중 하나는 토큰이다. 토큰은 비용이기도 하고, 컨텍스트 윈도우 한계이기도 하다.

그래서 실제 앱에서는 “문서를 통째로 넣는다”보다 다음 설계가 중요해진다.

  • 어떻게 문서를 자를 것인가
  • 무엇을 먼저 검색할 것인가
  • 어떤 문맥만 모델에 넣을 것인가
  • 언제 메모리를 남기고 언제 버릴 것인가

Spring AI의 RAG, ETL, Advisor 계층은 결국 이 문제를 다루기 쉽게 하려는 장치다.

4) Tool Calling은 모델 능력이 아니라 앱 설계다

Spring AI Tool Calling 흐름도
모델은 도구 사용을 제안하고, 실제 실행과 결과 반영은 애플리케이션이 통제한다.

이건 꽤 중요한 포인트다. 모델이 도구를 “직접 실행하는 것”이 아니다. 모델은 어떤 도구를 써야 할지 요청할 뿐이고, 실제 실행은 애플리케이션이 담당한다.

즉 Tool Calling의 핵심은 멋진 데모가 아니라 다음과 같은 경계 설정이다.

  • 어떤 도구를 공개할 것인가
  • 어떤 입력만 허용할 것인가
  • 읽기 전용 도구와 액션형 도구를 어떻게 구분할 것인가
  • 실행 결과를 모델에 어떤 방식으로 다시 넘길 것인가

Spring AI는 이 과정을 프레임워크 차원에서 정리해 둔다.

Spring AI 2.0에서 특히 눈에 들어오는 축

문서를 기준으로 보면, Spring AI 2.0을 읽는 데 중요한 축은 대략 이렇다.

ChatClient

가장 먼저 손에 익히게 되는 API다. 보통 첫 번째 실전 코드는 ChatClient에서 시작한다. 사용자 입력을 넣고, 시스템 프롬프트를 추가하고, 동기 호출 또는 스트리밍 응답을 받는 흐름이 여기서 시작된다.

Advisors

Spring AI의 설계가 “단발 호출”에서 끝나지 않는다는 걸 보여 주는 계층이다. 요청 전후에 개입해서 메모리, RAG, 관찰 가능성, 평가 같은 흐름을 조립하는 포인트라고 이해하면 된다.

RAG + Vector Store + ETL

대부분의 실무 앱이 언젠가 만나게 되는 영역이다. 최신 데이터, 사내 문서, 정책 문서, 제품 문서 같은 외부 지식을 모델에 연결하려면 결국 이 축으로 들어오게 된다.

Tool Calling

검색, 데이터 조회, 외부 시스템 액션을 모델 응답 흐름 안에 넣는 방법이다. 데모성 기능이 아니라, 실제 비즈니스 로직과 보안 경계를 설계하는 주제에 가깝다.

MCP

최근 AI 생태계에서 점점 중요해지는 표준화 계층이다. Spring 개발자 입장에서는 “내 애플리케이션이 MCP 서버를 소비할 수도 있고, 반대로 Spring 기반 서비스를 MCP 서버로 노출할 수도 있다”는 점이 중요하다.

처음 읽는 사람에게 추천하는 순서

Spring AI 문서는 공급자별 페이지까지 포함하면 범위가 넓다. 그래서 처음부터 OpenAI, Anthropic, Ollama 세부 옵션으로 들어가면 오히려 길을 잃기 쉽다.

개인적으로는 아래 순서를 추천한다.

  1. concepts.html
    전체 용어와 감각 잡기
  2. getting-started.html
    프로젝트 시작, BOM, 저장소, 의존성 구조 이해
  3. api/chatclient.html
    첫 호출과 프롬프트 구성 익히기
  4. api/advisors.html
    Spring AI가 왜 단순 호출 래퍼가 아닌지 이해
  5. api/tools.html
    외부 도구 연동의 경계 이해
  6. api/retrieval-augmented-generation.html
    RAG의 빠른 진입점 이해
  7. api/mcp/mcp-overview.html
    최근 표준화 흐름 파악

이 순서의 장점은 공급자 세부 설정 전에 먼저 프레임워크의 사고방식을 익힌다는 데 있다.

그래서 2.0을 왜 다시 볼 만한가

Spring AI가 흥미로운 이유는 “새로운 모델을 더 많이 지원한다”가 아니다. 더 중요한 건 AI 기능을 Spring 애플리케이션의 일부로 다룰 수 있게 구조를 제공한다는 점이다.

즉 개발자는 다음 질문을 더 자연스럽게 던질 수 있다.

  • 이 모델 호출을 서비스 코드에서 어떻게 감쌀까?
  • 검색 결과를 어디서 주입할까?
  • 도구 호출 권한을 어떻게 나눌까?
  • 메모리와 평가를 어떤 계층에 둘까?
  • 나중에 공급자를 바꾸면 어느 정도까지 코드가 살아남을까?

이건 결국 “LLM 데모”와 “운영 가능한 애플리케이션”의 차이다.

마무리

Spring AI 2.0은 한 줄 호출 예제를 더 쉽게 만드는 도구라기보다, AI 기능을 Spring 방식으로 구성하는 설계판에 가깝다.

그래서 문서를 읽을 때도 공급자 페이지를 먼저 보는 것보다,

  • 개념
  • 시작하기
  • ChatClient
  • Advisors
  • Tools
  • RAG
  • MCP

순으로 읽는 편이 훨씬 낫다.

다음 글에서는 이 큰 그림 다음 단계로, 실제 프로젝트를 시작할 때 가장 먼저 부딪히는 문제인 BOM, 저장소, 의존성 설정을 정리해 보겠다.

#Spring AI#Spring Boot#LLM#RAG#MCP