Spring AI: Java의 AI 모멘트에 대한 시니어 개발자의 솔직한 견해

요약 (TL;DR)

Spring AI는 자동 설정(auto-configuration), 의존성 주입(dependency injection), 벤더 이식 가능한 추상화(vendor-portable abstractions)와 같은 익숙한 패턴을 사용하여 AI 모델을 Java에 통합하는 공식 Spring 프로젝트입니다.
2025년 5월에 1.0 GA에 도달했으며, 2025년 11월에 1.1 버전을 출시하며 전체 MCP (Model Context Protocol) 통합을 포함하여 850개 이상의 개선 사항을 제공했습니다.
단일하고 일관된 API를 통해 20개 이상의 AI 모델 제공업체 (OpenAI, Anthropic, Google, Ollama 등) 및 **12개 이상의 벡터 스토어 (vector stores)**를 지원합니다.
만약 당신의 팀이 Spring Boot를 사용하고 있다면, 더 이상 LLM에 직접 생(raw) HTTP 호출을 작성해야 할 타당한 이유가 없습니다.

Java 개발자들이 예상치 못했던 문제
Spring AI의 실체
프레임워크의 핵심
언급할 가치가 있는 공정한 비판
Spring AI vs LangChain4j: 솔직한 비교
이것이 당신에게 의미하는 바
개발자들이 Spring AI에 대해 실제로 묻고 있는 질문들
이 모든 것이 10년 뒤에 도달할 지점
참고 문헌
저자 소개

프로그래밍 언어의 역사는 대부분 기존 강자들이 누구도 예측하지 못한 만큼 더 오래 살아남은 역사입니다. COBOL은 여전히 매일 약 3조 달러 규모의 금융 거래를 처리하고 있습니다. Fortran은 여전히 기후 모델과 항공우주 시뮬레이션에 등장합니다. 1995년에 도입된 Java는 엔터프라이즈 세계의 기질(substrate)이 되었고 결코 떠나지 않았습니다.

그러다 AI 모델이 등장했고, 잠시 동안 이러한 패턴이 깨지는 듯 보였습니다. 언어 모델을 다루기 위한 기본 언어는 Python이었습니다. Python이 아키텍처적으로 더 우월하기 때문이 아닙니다. LangChain, HuggingFace 통합, 그리고 노트북 우선(notebook-first) 워크플로우를 만든 연구자들과 도구 제작자들이 먼저 자신들을 위해 구축한 Python 개발자들이었기 때문입니다.

은행, 물류 플랫폼, 또는 병원 기록 관리 시스템을 실제로 운영하는 시스템을 유지 관리하는 Java 엔지니어들은, 조직에서 이미 도입을 요구받고 있는 기술을 위한 Python SDK를 바라보고 있는 자신들을 발견했습니다. 2023년에 형성된 기본 가정은 AI 통합을 위해 완전히 다른 스택이 필요하다는 것이었습니다. 그 가정은 틀린 것으로 드러났습니다. Spring AI가 그 증거입니다.

Java 개발자들이 예상치 못했던 문제

2023-2024년 AI 파도의 불편한 현실은 Java가 초기 논의 단계에 포함되지 않았다는 점이었습니다.

빠르게 움직이는 AI 도구 생태계는 거의 전적으로 Python 중심(Python-native)이었습니다. 한동안 올바르게 형성되었던 사고 모델은, AI 애플리케이션을 구축하려면 단순히 기술을 추가하는 것이 아니라 스택 자체를 전환해야 한다는 것이었습니다. 커리어를 통해 프로덕션급 분산 시스템(distributed systems)을 구축해 온 Java 개발자들은, 자신들이 일상적으로 사용하지 않는 언어를 중심으로 도구 카테고리 전체가 등장하는 것을 지켜봐야만 했습니다.

2024 BellSoft Java Survey에 따르면, 약 74%의 Java 개발자가 이미 일상 업무에서 AI 도구를 사용하고 있지만, AI 기반 애플리케이션을 구축하기 위해 AI 프레임워크를 사용하는 비율은 34%에 불과했습니다. AI를 사용하는 것과 AI로 구축하는 것 사이의 이 격차가 바로 Spring AI가 작동하는 지점입니다.

대부분의 팀이 직면한 질문은 철학적인 문제가 아니었습니다. 그것은 아키텍처(architectural)에 관한 문제였습니다: 기존의 Spring Boot 마이크로서비스(microservices)를 유지할 것인가, 아니면 모든 LLM 호출을 처리하기 위해 Python 사이드카(sidecar) 서비스를 도입할 것인가? 두 개의 프로세스로 구성된 아키텍처는 프로토타입 단계에서는 관리 가능한 것처럼 느껴지지만, 프로덕션 환경에서는 유지 관리의 부담(maintenance liability)이 됩니다.

Spring AI는 그 격차를 메웁니다. Spring AI는 여러분의 팀이 이미 알고 있는 동일한 패턴을 사용하여 AI 모델 통합을 Spring 컨테이너(container) 자체로 가져옵니다.

Spring AI의 실체

Spring AI는 이식 가능한 추상화 (portable abstractions), Spring Boot 자동 설정 (auto-configuration), 그리고 익숙한 의존성 주입 (dependency injection) 패턴을 사용하여 엔터프라이즈 Java 애플리케이션을 AI 모델에 연결하는 애플리케이션 프레임워크입니다. 이 프레임워크는 단일하고 일관된 API를 통해 20개 이상의 모델 제공업체(model providers)와 12개 이상의 벡터 저장소(vector stores)를 지원하며, RAG, 도구 호출 (tool calling), 채팅 메모리 (chat memory), 그리고 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP) 지원을 내장하고 있습니다. 이 프로젝트는 2025년 5월에 1.0 GA(General Availability)에 도달했으며, 현재 프로덕션 환경에서 사용할 준비가 되어 있습니다.

Spring 팀의 공식 설명은 정확합니다: Spring AI는 핵심 Spring 설계 원칙, 특히 이식성 (portability)과 모듈형 설계 (modular design)를 AI 도메인에 적용하며, 일반 Java 객체 (plain Java objects)를 AI 애플리케이션의 빌딩 블록으로 사용하는 것을 권장합니다.

데이터베이스 대신 AI 모델을 위한 Spring Data라고 생각하면 됩니다. 동일한 철학이 적용됩니다. 특정 벤더에 코드를 고정하지 않고 모델로부터 원하는 것이 무엇인지 기술하기만 하면 됩니다. 만약 수년간 JpaRepository 추상화를 작성해 왔다면, 그 사고 모델 (mental model)이 그대로 전이됩니다.

Broadcom의 Spring 개발자 어드보케이트 (Developer Advocate)인 Josh Long은 2025년 DevOps UK에서 이를 명확하게 말했습니다: AI 애플리케이션을 구축하는 것은 대부분 HTTP API를 가진 모델을 호출하는 것뿐입니다. Spring Boot 서비스를 구축할 수 있다면, 당신은 이미 AI 개발자입니다. 기술은 그대로 전이됩니다. 도구가 따라잡을 필요가 있었을 뿐입니다.

Spring AI는 현재 다음을 지원합니다:

20개 이상의 AI 모델 제공업체: OpenAI, Anthropic, Google Gemini, Amazon Bedrock, Azure OpenAI, Ollama, DeepSeek, Groq, Mistral AI, NVIDIA, Hugging Face 등
12개 이상의 벡터 저장소 (vector stores): PostgreSQL/PGVector, Chroma, Pinecone, Weaviate, Milvus, Redis, MongoDB Atlas, Neo4j, Oracle, Qdrant, Apache Cassandra, Azure Vector Search
모든 주요 모델 유형: 채팅 완성 (chat completion), 임베딩 (embeddings), 텍스트-이미지 변환 (text-to-image), 오디오 전사 (audio transcription), 텍스트-음성 변환 (text-to-speech), 그리고 모더레이션 (moderation)
도구 호출 (tool calling), RAG 파이프라인, MCP 클라이언트 및 서버 지원, 채팅 메모리 (chat memory), 그리고 구조화된 출력 (structured outputs)을 포함한 에이전트 기능 (Agentic capabilities)

Spring AI 2.0은 2026년 중반 기준으로 Spring Boot 4.0, Spring Framework 7.0, 그리고 Jakarta EE 11 베이스라인을 기반으로 활발한 마일스톤 개발 단계에 있으며, Java 21을 최소 런타임 (runtime)으로 요구합니다.

프레임워크의 핵심 (The Core of the Framework)

ChatClient: 주요 진입점 (Main Entry Point)

Spring 컨테이너는 이미 당신의 비즈니스 로직을 알고 있습니다. 당신이 @Service 빈 (beans)을 작성한 날부터 그것들을 관리해 왔습니다. 이제 Spring은 소개를 시작하며, 당신의 기존 코드를 해당 분기에 배포 중인 어떤 언어 모델 (language model)과도 같은 공간에 배치합니다.

주요 API는 ChatClient로, WebClient나 RestClient의 형제처럼 느껴지도록 설계된 유연한 빌더 인터페이스 (fluent builder interface)입니다. 다음은 Spring AI 1.1을 사용한 작동 가능한 RAG 지원 채팅 엔드포인트 (endpoint) 예시입니다:

@RestController
public class DocumentChatController {

...

여기서는 1년 전만 해도 상당한 상용구 코드 (boilerplate)가 필요했던 네 가지 작업이 일어나고 있습니다. QuestionAnswerAdvisor는 벡터 스토어 (vector store)에서 관련 문서를 검색하여 프롬프트 (prompt)에 자동으로 주입합니다. VectorStore 추상화 (abstraction) 덕분에 이 컨트롤러를 수정하지 않고도 PostgreSQL/PGVector를 Pinecone으로 교체할 수 있습니다. 모델 자체는 application.yml에서 설정됩니다. 이 모든 것이 표준 @RestController입니다.

이것은 단순한 예시용 코드가 아닙니다. 실제 운영 환경에서의 문서 Q&A 엔드포인트가 어떤 모습인지에 매우 근접한 형태입니다.

제공자 전환은 코드 결정이 아닌 설정 결정입니다

Spring AI가 제공하는 즉각적으로 유용한 기능 중 하나는 제공자 (provider) 선택을 배포 관련 사항 (deployment concern)으로 취급한다는 점입니다. OpenAI에서 Anthropic으로 전환하려면 application.yml만 업데이트하면 됩니다:

# OpenAI 설정
spring:
  ai:
...

당신의 컨트롤러, 서비스, 그리고 비즈니스 로직은 변경되지 않습니다. 이러한 이식성 (portability)은 프레임워크의 핵심 설계 약속이며, 실제로도 이를 충실히 이행합니다.

함수 호출 (Function Calling) 및 MCP: 에이전트 이야기가 흥미로워지는 지점

Spring AI 1.1은 일급 시민(first-class) 수준의 Model Context Protocol (MCP) 통합을 도입했으며, 이는 에이전트 시스템 (agentic systems)을 구축하는 팀들에게 프레임워크 측면에서 가장 전략적으로 중요한 부분입니다. MCP는 AI 에이전트와 에이전트가 호출해야 하는 외부 도구 간의 상호 운용성 (interoperability)을 위한 신흥 표준입니다.

Spring AI를 사용하면 최소한의 코드로 기존 비즈니스 로직을 AI가 호출 가능한 함수로 등록할 수 있습니다:

@Configuration
public class BankingTools {

...

프레임워크는 이 빈 (bean)을 자동으로 감지하여 함수 호출 (function calling)을 통해 모델이 사용할 수 있도록 합니다. 이제 AI는 기존 서비스 구현을 변경하지 않고도 완전한 타입 안정성 (type safety)을 갖춘 상태로 비즈니스 로직을 직접 호출할 수 있습니다.

Jonathan Schneider는 2025년에 비교를 한 적이 있으며, 이는 이후 Spring 커뮤니티에서 계속 반복되어 온 내용입니다. 즉, 함수 호출 (function calling)은 Java 개발에서 제어의 역전 (Inversion of Control, IoC)이 수행했던 역할과 RAG의 관계와 같습니다. IoC는 단순히 의존성 관리 (dependency management)를 깔끔하게 만든 것이 아닙니다. 그것은 팀들이 컴포넌트 설계에 대해 생각하는 방식 자체를 완전히 바꾸어 놓았습니다. MCP를 통한 함수 호출은 비즈니스 로직과 AI 오케스트레이션 (orchestration) 사이의 관계에 대해 이와 유사한 역할을 수행합니다.

850개의 개선 사항이 인간의 관점에서 의미하는 실제 내용

Spring AI 1.1은 5개의 마일스톤 빌드에 걸쳐 850개 이상의 개선 사항을 포함하여 출시되었습니다. 만약 각 개선 사항이 1초의 연속적인 작업이라면, 이는 단 한 번의 릴리스 사이클 동안 14분 이상의 수정, 강화 및 문서 업데이트가 쏟아져 나왔음을 의미합니다. 구체적으로는 354개의 기능 강화 (enhancements), 241개의 버그 수정 (bug fixes), 그리고 100개의 문서 개선 (documentation improvements)이 이루어졌습니다. 이는 스스로를 따라잡으려 노력하는 연구용 프로토타입이 아니라, 빠르게 생산 단계로 성숙해 가고 있는 프레임워크임을 보여줍니다.

언급할 가치가 있는 정당한 비판

여기서 제기할 수 있는 정당한 비판은 명확합니다. Spring AI는 여러분이 이미 Spring 생태계에 있을 때만 적합한 도구라는 점입니다. 이식성 추상화 (portability abstractions)는 진정으로 유용하지만, 이는 Spring Boot의 자동 설정 (auto-configuration) 위에 구축되어 있습니다. 만약 여러분의 팀이 Quarkus, Micronaut 또는 순수 Vert.x를 사용한다면, 이 일급 시민 수준의 통합 스토리는 여러분에게 적용되지 않습니다.

주요 Java 대안인 LangChain4j는 Red Hat에서 유지 관리하는 네이티브 Quarkus 확장(extensions)을 제공하며, Spring AI(20개 이상)보다 더 많은 수의 LLM 제공업체(30개 이상)를 기본적으로 지원하고, 기반 기술로 Spring Boot를 요구하지 않습니다.

실제 운영 환경 평가 중에 마주친 한 가지 실질적인 한계점을 언급하고 싶습니다. Advisors API 문서가 일부 구간에서 정말 부실합니다. RAG(Retrieval-Augmented Generation) 검색을 대화 메모리(conversation memory)와 결합할 때 체이닝된 어드바이저(chained advisors)가 어떻게 구성되는지 이해하기 위해, 저는 참조 가이드보다 Spring AI 통합 테스트 코드를 더 많이 읽어야 했습니다. 팀에서 이 부분을 개선하고 있지만, 만약 오늘 당장 새로운 엔지니어를 Spring AI RAG 파이프라인에 투입해야 한다면, 이러한 공백을 고려하여 추가 시간을 할당하십시오.

성능 문제에 대해서는: LLM 네트워크 지연 시간(latency)은 Java 프레임워크의 오버헤드보다 2~3자릿수(orders of magnitude)나 더 큽니다. 2026년 초의 상세한 Java 생태계 분석 결과는 이를 직접적으로 확인해 주었습니다. 병목 현상은 항상 모델의 라운드 트립(round trip)이지, 추상화 계층(abstraction layer)이 아닙니다. Spring AI는 이미 수백 밀리초(ms) 이상이 소요되는 작업에 의미 있는 지연 시간을 추가하지 않습니다.

솔직하게 하나 더 말씀드리자면, API 표면(API surface)이 여전히 변하고 있습니다. Spring AI 1.0 버전에 고정했던 팀들은 1.1 버전에서 일부 어댑터 인터페이스(adapter interfaces)가 변경된 것을 발견했습니다. Jakarta EE 11 베이스라인과 Spring Boot 4 기반으로의 전환을 고려할 때, 1.x에서 2.0으로의 업그레이드 경로는 세심한 주의가 필요할 것입니다. 이것이 Spring AI를 피해야 할 이유는 아닙니다. 다만 Spring Data나 Spring Security보다 마이너 버전을 더 적극적으로 추적해야 할 이유입니다.

Spring AI vs LangChain4j: 솔직한 비교

차원 (Dimension)	Spring AI 1.1	LangChain4j 1.x
주요 타겟 (Primary target)	Spring Boot 팀	모든 JVM 스택
...

여기서 도출되는 결정 규칙은 명확합니다. 기존의 관측성 (Observability) 및 Spring Security 설정이 갖춰진 Spring Boot 팀인가요? 그렇다면 Spring AI가 마찰이 가장 적고 장기적인 유지보수 비용이 가장 낮은 경로입니다. Spring이 아닌 스택을 사용하거나, 더 넓은 제공자 카탈로그 (Provider catalog)가 필요한가요? 그렇다면 LangChain4j가 합리적인 대안입니다. 둘 다 프로덕션 환경에 적용 가능합니다 (Production-ready). 프로젝트 시작 6개월 후에 스택을 전환하는 비용은 실질적인 문제이므로, 이를 구현 세부 사항이 아닌 아키텍처 결정 사항으로 취급하십시오.

이것이 당신에게 의미하는 바

만약 당신이 Spring Boot 팀의 백엔드 엔지니어라면, 질문은 Spring AI를 사용할 것인가가 아닙니다. 어떤 기능부터 시작할 것인가입니다.

ChatClient와 단일 제공자 (Provider)로 시작하십시오. 하나의 엔드포인트가 엔드 투 엔드 (End-to-end)로 작동하게 만드십시오. 진정한 문서 검색 (Document retrieval) 유스케이스가 생겼을 때 VectorStore를 추가하십시오. 첫 번째 스프린트에서 RAG, MCP, 도구 호출 (Tool calling), 그리고 관측성 (Observability)을 동시에 시도하지 마십시오. 추상화는 설계 단계부터 조합 가능하도록 (Composable) 만들어졌으며, 실제로 필요할 때 각 레이어를 추가할 수 있습니다.

만약 당신이 플랫폼의 기존 지식 베이스를 기반으로 내부 도구 또는 코파일럿 (Copilot) 스타일의 기능을 구축하고 있다면 (제가 OHB의 Digital Application Platforms 팀을 위해 적극적으로 평가하고 있는 카테고리입니다), Advisors API와 채팅 메모리 (Chat memory) 지원이 가장 즉각적으로 유용한 요소입니다. 이를 통해 Python 사이드카 (Sidecar) 서비스와 그에 따른 모든 운영 오버헤드를 구축하지 않고도 문맥 인식 어시스턴트 (Context-aware assistants)를 구축할 수 있습니다.