Spring AI는 AI 모델을 만드는 도구일까?

Spring AI 시리즈 1/9

Spring AI로 챗봇을 넘어 일하는 AI 만들기 — Java·Spring 개발자가 LLM, RAG, Tool Calling, MCP를 공부하며 이해한 것들

식당 주인이 이미 뛰어난 요리사를 고용했다고 생각해 보겠습니다. 요리사는 맛있는 음식을 만들 수 있지만 손님의 주문, 알레르기, 오늘 남은 재료와 식당의 결제 규칙을 저절로 알지는 못합니다.

주문을 받고 규칙을 확인한 뒤 주방에 전달하고, 완성된 음식을 손님에게 돌려주는 시스템이 필요합니다. Spring AI는 새 요리사를 훈련하는 학교보다 기존 요리사와 식당 업무를 연결하는 주문 시스템에 가깝습니다.

따라서 제목의 답은 “아니요”입니다. Spring AI는 AI 모델을 새로 학습시키는 도구가 아니라, 이미 학습된 모델을 Java·Spring 애플리케이션의 데이터, API와 업무 흐름에 연결하는 프레임워크입니다.

식당 비유	실제 기술
손님의 주문	User Message 또는 Prompt
주문받는 창구	ChatClient
알레르기·식당 규칙 확인	Advisor
주방과 연결되는 공통 주문 규격	ChatModel 인터페이스
이미 훈련된 요리사	사전 학습된 AI 모델
완성된 음식	모델 응답

이 글은 대용량 트래픽 시리즈 다음 단계의 학습 흐름을 기록하기 위해 2026년 3월 기준으로 배치했습니다. 이후 달라진 API와 버전 정보는 2026년 8월 공식 문서를 기준으로 다시 확인해 표시했습니다. 실제 프로덕션 운영 성과를 소개하는 글은 아닙니다.

3월 5일의 안정 버전 흐름은 Spring AI 1.1.2였습니다. 3월 17일에 1.1.3과 2.0.0-M3가 발표됐으므로 당시 2.0은 안정 버전이 아니었습니다. 현재 검증일인 8월 14일의 공식 안정 버전은 2.0.0이며, 아래 실행 예제는 이 버전만 기준으로 합니다.

모델을 만든다는 말부터 나눠 보자

LLM(Large Language Model, 대규모 언어 모델)은 많은 글에서 언어의 패턴을 배운 모델입니다. 하지만 “AI를 만든다”는 말에는 서로 다른 작업이 섞여 있습니다.

Training(학습)은 많은 데이터로 모델의 기본 능력을 만드는 과정입니다.
Fine-tuning(미세 조정)은 이미 학습된 모델을 특정 목적에 맞게 추가로 조정하는 과정입니다.
Inference(추론)는 학습이 끝난 모델에 질문을 보내 답을 얻는 과정입니다.

Spring AI의 중심 역할은 학습이나 미세 조정이 아닙니다. 애플리케이션에서 기존 모델의 추론 기능을 호출하고, 그 앞뒤에 대화 기억·외부 지식·도구·관측 같은 기능을 연결합니다.

식당 비유로 돌아가면 Training은 요리사를 교육하는 일입니다. Spring AI가 주로 맡는 일은 이미 일할 수 있는 요리사에게 정확한 주문서를 전달하고 결과를 식당 시스템으로 돌려받는 일입니다.

AI API를 직접 호출하면 안 될까?

직접 호출도 유효한 선택입니다. 모델 하나에 간단한 질문 한두 개만 보내는 실험이라면 Spring의 RestClient, WebClient 또는 제공자 공식 SDK가 더 짧고 분명할 수 있습니다.

특정 제공자의 최신 기능을 깊게 써야 할 때도 공식 SDK가 자연스럽습니다. 공통 추상화가 오히려 제공자 고유 옵션을 이해하는 데 한 단계를 더 만들 수 있기 때문입니다.

하지만 요구사항이 늘어나면 반복되는 일이 생깁니다. 제공자별 요청과 응답을 바꾸고, Prompt를 구성하고, 동기 호출과 Streaming을 나누고, 응답을 자바 객체로 변환해야 합니다. 여기에 대화 기억, RAG, Tool Calling, 관측성과 공통 정책까지 붙으면 연결 코드가 커집니다.

Spring AI는 이런 반복 지점을 Spring 방식의 공통 API와 자동 설정으로 묶습니다. 항상 더 좋은 선택이라는 뜻은 아닙니다. 여러 기능을 일관되게 연결할 필요가 생겼을 때 비용을 지불하고 선택하는 프레임워크입니다.

주문을 전달하는 세 가지 구성요소

ChatModel은 모델이 아니라 공통 연결 규격이다

ChatModel은 여러 채팅 모델을 공통 방식으로 호출하기 위한 인터페이스입니다. Prompt를 받아 ChatResponse를 돌려주는 규격이며, 그 자체가 GPT나 다른 AI 모델은 아닙니다.

OpenAiChatModel 같은 제공자별 구현체가 실제 모델 API와 연결됩니다. 공통 인터페이스가 있어도 제공자마다 지원 기능과 옵션은 다르므로 설정만 바꾼 완벽한 무수정 교체가 보장되지는 않습니다.

ChatClient는 주문서를 단계적으로 만드는 창구다

ChatClient는 ChatModel 위에서 쓰는 상위 수준의 Fluent API입니다. Fluent API는 prompt().user().call()처럼 앞 단계의 설정에 다음 설정을 이어 붙여 읽기 쉽게 만드는 방식입니다.

System Message, User Message와 모델 옵션을 단계적으로 구성할 수 있고 동기 호출과 Streaming을 지원합니다. 이번 글은 한 번에 답을 받는 동기 호출만 다룹니다. 응답이 조금씩 도착하는 Streaming은 2편에서 살펴봅니다.

Advisor는 Agent가 아니라 앞뒤를 확인하는 체인이다

Advisor는 스스로 목표를 정해 행동하는 AI Agent와 다른 개념입니다. 요청과 응답을 가로채 확인·수정·보강하는 순서 있는 체인입니다.

대화 기억이나 RAG처럼 반복되는 생성형 AI 패턴을 공통 기능으로 분리할 수 있습니다. 요청은 낮은 order 값의 Advisor부터 지나가고, 응답은 반대 순서로 돌아옵니다. Advisor가 여러 개라면 순서와 실패 처리도 애플리케이션이 관리해야 합니다.

Spring AI는 ChatClient, Advisor, ChatModel을 이용해 애플리케이션과 이미 학습된 모델을 연결합니다. 모델을 새로 학습시키는 과정은 이 흐름에 포함되지 않습니다.

질문 하나는 어디를 지나갈까?

사용자가 “오늘 재고가 있는 메뉴를 추천해 줘”라고 묻는 흐름을 따라가 보겠습니다.

Controller가 사용자의 질문을 받습니다.
ChatClient가 질문과 System Message를 Prompt로 구성합니다.
Advisor들이 요청을 차례로 확인하거나 기억과 외부 정보를 보강합니다.
ChatModel의 제공자별 구현체가 선택한 모델 제공자에게 요청을 전달합니다.
이미 학습된 AI 모델이 Inference를 수행합니다.
모델 응답이 Advisor 체인을 반대 방향으로 통과합니다.
ChatClient가 애플리케이션이 쓰기 쉬운 결과를 돌려줍니다.

모델이 반드시 Spring 애플리케이션 안에서 실행되는 것은 아닙니다. 인터넷을 통해 원격 모델 API를 호출할 수도 있고, Ollama를 통해 내 컴퓨터의 로컬 모델과 연결할 수도 있습니다. Ollama와 로컬 LLM은 2편에서 자세히 다룹니다.

2026년 8월 업데이트 예제

현재 Spring AI 2.0.0 공식 문서의 가장 작은 동기 호출 형태는 다음과 같습니다.

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
class AiController {
    private final ChatClient chatClient;

    AiController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping("/ai")
    String ask(@RequestParam String question) {
        return this.chatClient.prompt()
            .user(question)
            .call()
            .content();
    }
}

prompt()는 새 요청 구성을 시작합니다. user()는 사용자의 질문을 넣고, call()은 동기 방식으로 모델 호출을 실행합니다. content()는 응답 본문을 문자열로 꺼냅니다.

Spring Boot Auto-configuration(자동 설정)이 선택한 모델의 ChatModel과 ChatClient.Builder를 준비할 수 있습니다. API Key는 환경 변수나 안전한 비밀 저장소로 주입해야 하며 코드에 직접 넣지 않습니다.

이 예제는 흐름만 보여주기 때문에 timeout, 예외 처리, 입력 검증, 보안과 관측성을 생략했습니다. Spring AI 2.0.x는 Spring Boot 4.0.x·4.1.x 계열을 지원합니다. 1.1.x를 유지한다면 Spring Boot 3.4.x·3.5.x 계열의 공식 호환성과 해당 버전 API를 따로 확인해야 합니다.

세 가지 선택지는 목적이 다르다

선택지	적합한 상황	비용과 한계
직접 HTTP 호출	작은 실험과 단순 요청	반복 코드와 제공자 종속
제공자 공식 SDK	특정 제공자 기능을 깊게 사용	다른 제공자로 전환하기 어려움
Spring AI	Spring에서 여러 AI 기능을 일관되게 연결	프레임워크 추상화와 버전 학습 비용

초기 실험에는 직접 호출이 가장 투명할 수 있습니다. 기능과 운영 정책이 늘어날 때 Spring AI의 공통 구조가 주는 이점과 새로 생기는 복잡도를 함께 비교해야 합니다.

Spring AI가 대신 해결하지 않는 것

Spring AI는 좋은 Prompt를 자동으로 만들어 주지 않고 모델의 환각도 자동으로 제거하지 않습니다. 외부 API 장애와 지연, timeout, rate limit(호출 제한), 모델 호출 비용도 사라지지 않습니다.

개인정보 보호와 권한 통제 역시 직접 설계해야 합니다. API Key와 Prompt 로그에는 비밀정보가 남지 않게 해야 하며, 누가 어떤 데이터와 도구에 접근할 수 있는지 제한해야 합니다.

프레임워크를 쓰면 Advisor 순서와 설정 오류라는 새 실패 지점도 생깁니다. 추상화 뒤에서 실제로 어떤 요청이 전송됐는지 추적하기 어려울 수 있고, Spring AI와 제공자 API의 버전 변화도 따라가야 합니다.

제공자별 기능 차이도 완전히 없어지지 않습니다. Spring AI를 추가했다는 사실만으로 안전한 프로덕션 서비스가 완성되는 것은 아닙니다.

한 단계 더 깊게: Spring 안에서 오가는 것

Prompt는 모델에 전달할 여러 Message와 호출 옵션을 묶은 요청입니다.

Message는 system, user, assistant처럼 대화에서 맡은 역할과 내용을 표현합니다.

ChatResponse는 모델의 생성 결과와 관련 메타데이터를 담는 응답입니다.

Spring Boot Auto-configuration은 의존성과 설정을 보고 필요한 Bean을 준비합니다.

Provider-specific implementation(제공자별 구현체)은 ChatModel 규격과 실제 모델 API 사이를 연결합니다.

POJO(Plain Old Java Object, 평범한 자바 객체)는 특별한 프레임워크 상속 없이 데이터를 표현하는 일반 자바 객체이며, Spring AI는 모델 출력을 이런 객체로 변환하는 기능도 제공합니다.

모델보다 연결할 업무를 먼저 본다

Spring AI는 모델 학습 도구가 아닙니다.
기존 AI 모델과 Spring 애플리케이션의 데이터·API·업무 흐름을 연결합니다.
직접 API 호출보다 항상 좋은 것이 아니므로 요구사항에 맞춰 선택해야 합니다.

그렇다면 외부 AI API 없이 내 컴퓨터에서 모델을 실행해 Spring Boot와 연결할 수도 있을까요? 다음 편에서는 Ollama와 로컬 LLM의 실제 구조와 한계를 살펴봅니다.

다음 글 — 인터넷 없이도 AI 챗봇을 만들 수 있을까?