올해 초, 저는 제가 관리하는 Spring Boot 애플리케이션에 AI 어시스턴트를 추가해야 했습니다. 특별한 것은 아니었습니다. 그저 시스템 문서에 관한 질문에 답할 수 있는 채팅 인터페이스가 필요했을 뿐입니다. 저에게는 두 가지 명확한 선택지가 있었습니다. 바로 Spring AI 또는 LangChain4j였습니다.

저는 결정이 금방 끝날 것이라고 생각했습니다. 두 프레임워크 모두 성숙해 있었고, 주요 LLM (Large Language Model) 제공업체를 모두 지원하며, Spring Boot 통합 기능도 갖추고 있었습니다. 이 둘이 얼마나 다를 수 있겠습니까?

6주간의 시간과 두 개의 프로토타입을 거친 후, 저는 그 차이가 기능 매트릭스가 시사하는 것보다 훨씬 더 중요하다는 것을 깨달았습니다.

저는 다카(Dhaka)에 위치한 BS23의 Senior Software Engineer II입니다. 저는 매일 Spring Boot로 작업합니다. 또한 개인적인 AI 인프라로 Hermes Agent를 운영하고 있습니다. 따라서 저는 엔터프라이즈 Java 세계와 AI 에이전트(Agent) 세계 양쪽에 발을 걸치고 있습니다. 다음은 이 두 프레임워크를 정면으로 비교하며 제가 발견한 내용입니다.

두 명의 경쟁자

Spring AI는 Broadcom(이전 VMware)의 Spring 팀에서 제공하는 공식 AI 통합 프레임워크입니다. 2026년에 Spring Boot 4와 함께 버전 2.0.0에 도달했습니다. 이 프레임워크는 채팅, 임베딩 (Embeddings), 이미지 생성, 오디오 전사 (Audio Transcription), 텍스트 음성 변환 (Text-to-Speech), 모더레이션 (Moderation), 그리고 2.0의 핵심 기능인 일급 시민 수준의 MCP (Model Context Protocol) 지원까지 전체 범위를 다룹니다. start.spring.io에서 다른 모든 Spring starter와 함께 찾아볼 수 있습니다.

LangChain4j는 Python이 지배하는 AI 환경에 대한 대응으로 2023년 초에 시작되었습니다. 이름에도 불구하고, 이것은 LangChain의 Java 포팅 버전이 아닙니다. 유지 관리자들은 이 점을 강조합니다. 즉, Java로 포팅된 것이 아니라 Java를 위해 구축되었다는 것입니다. LangChain4j는 20개 이상의 LLM 제공업체와 30개 이상의 벡터 스토어 (Vector Stores)를 지원하며, Spring Boot, Quarkus, Helidon, Micronaut과 통합됩니다.

두 프레임워크 모두 LLM을 호출하고, RAG (Retrieval-Augmented Generation) 파이프라인을 구축하며, 도구 (Tools)를 호출하고, 에이전트 (Agents)를 생성할 수 있게 해줍니다. 하지만 이들은 근본적으로 다른 각도에서 이러한 작업에 접근합니다.

아키텍처 철학

이것이 두 프레임워크 사이의 단 하나의 가장 큰 차이점이며, 다른 모든 결정을 주도하는 요소입니다.

Spring AI는 Spring 생태계를 위해 구축되었습니다. 이미 Spring Boot를 사용하고 있다면, Spring AI는 다른 Spring starter와 마찬가지로 자연스럽게 스며듭니다. 자동 설정 (auto-configuration), 속성 기반 설정 (property-driven setup), 익숙한 의존성 주입 (dependency injection) 모델, 그리고 Spring의 관찰 가능성 스택 (observability stack; Micrometer, Actuator)과의 긴밀한 통합을 누릴 수 있습니다. API는 마치 RestTemplate과 WebClient를 만든 사람들과 동일한 사람들이 설계한 것처럼 느껴지는데, 실제로 그렇기 때문입니다.

Spring Boot 4 프로젝트에 Spring AI를 추가하는 방법은 다음과 같습니다:

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
...

그 다음 application.yaml에서:

spring:
  ai:
    openai:
...

그리고 코드에서:

@RestController
class ChatController {
    private final ChatClient chatClient;
...

이것으로 끝입니다. 하나의 의존성, 설정 속성, 생성자 주입만 있으면 LLM을 호출할 수 있습니다.

LangChain4j는 프레임워크에 구애받지 않습니다 (framework-agnostic). Spring Boot, Quarkus, Helidon, Micronaut 또는 일반 Java와 함께 사용할 수 있습니다. 이 프레임워크는 사용자가 Spring 컨텍스트 내에 있다고 가정하지 않습니다. 이는 더 높은 이식성 (portability)을 제공하지만, Spring Boot와 함께 사용할 때 더 많은 와이어링 (wiring) 작업을 직접 처리해야 함을 의미하기도 합니다.

Spring Boot에서 LangChain4j를 사용한 동일한 채팅 엔드포인트는 다음과 같습니다:

@Configuration
class LangChain4jConfig {
    @Bean
...

코드가 눈에 띄게 길어지지는 않지만, 더 명시적입니다. 자동 설정에 의존하는 대신 모델 인스턴스를 직접 구축합니다.

LLM 제공업체 지원

두 프레임워크 모두 주요 제공업체들을 지원합니다. 실질적인 차이는 흔치 않은 제공업체들을 지원하는 방식에서 나타납니다.

Spring AI 2.0은 다음을 지원합니다: OpenAI, Anthropic, Google Gemini, Amazon Bedrock, DeepSeek, Mistral AI, Ollama, Groq, Perplexity AI, NVIDIA, MiniMax, OCI Generative AI, Azure OpenAI, 그리고 Docker Model Runner. 전체 목록은 Spring AI 레퍼런스 문서에서 확인할 수 있습니다.

LangChain4j는 OpenAI, Anthropic, Google Gemini, Azure OpenAI, Amazon Bedrock, Ollama, Mistral AI, DeepSeek, Groq, Perplexity AI, HuggingFace, LocalAI 및 약 10개 이상의 서비스를 지원합니다. 전체 목록은 통합 페이지 (integrations page)에서 확인할 수 있습니다.

차이점은 유명한 모델들(big names)에 있지 않습니다. 두 프레임워크 모두 이를 지원하기 때문입니다. 차이는 롱테일(long tail) 영역에 있습니다. LangChain4j는 플러그인과 같은 아키텍처 덕분에 새로운 제공업체를 추가하기가 더 쉬워, 커뮤니티가 기여한 통합(integrations)이 더 많습니다. Spring AI는 그 수는 더 적지만, 각각의 통합이 Spring 팀에 의해 유지 관리되며 일관된 API 패턴을 따릅니다.

승자: 메인스트림 제공업체는 무승부. 비주류(esoteric) 제공업체는 LangChain4j의 승리.

ChatClient vs AI Services의 차이점

Spring AI 2.0은 WebClient 및 RestClient를 의도적으로 반영한 유연한(fluent) ChatClient API를 도입했습니다. .prompt(), .user(), .system(), .call(), .entity() 호출을 체이닝(chaining)하여 사용합니다. 이는 장황(verbose)할 수 있지만 표현력이 풍부하여, 요청의 모든 부분을 한눈에 확인할 수 있습니다.

반면 LangChain4j는 AI Services라고 불리는 선언적(declarative) 패턴을 지향합니다. 인터페이스를 정의하고 어노테이션(annotation)을 붙이면, LangChain4j가 런타임(runtime)에 구현체를 생성합니다:

interface Assistant {
    String chat(@UserMessage String message);
}
...

이는 Spring Data JPA의 레포지토리 패턴(repository pattern)과 더 유사합니다. 원하는 바를 기술하면 프레임워크가 구현체를 생성하는 방식입니다.

두 접근 방식 모두 작동합니다. 저는 흐름이 명시적이기 때문에 ChatClient API가 디버깅하기 더 쉽다고 느낍니다. AI Services 패턴은 단순한 사용 사례에서는 더 깔끔하지만, 문제가 발생했을 때 추적(trace)하기가 더 어려울 수 있습니다.

RAG: 검색 증강 생성 (Retrieval-Augmented Generation)

두 프레임워크 모두 RAG를 지원하지만, 접근 방식은 다릅니다.

Spring AI는 문서 수집을 위한 ETL 프레임워크를 번들로 제공합니다. 파이프라인(pipeline)을 사용하여 문서를 읽고, 분할(split)하고, 임베딩(embed)한 뒤 벡터 데이터베이스(vector database)에 저장할 수 있습니다:

var pipeline = DocumentReadConfig
    .from("classpath:docs/")
    .toVectorStore(pgvectorStore)
...

그 후 쿼리 시점에 Advisors API를 사용하여 관련 컨텍스트를 주입합니다:

chatClient.prompt()
    .user(question)
    .advisors(assistant.createContextRetrievalAdvisor(pgvectorStore))
...

LangChain4j는 ContentRetriever 추상화를 사용합니다. 임베딩 저장소(embedding store)와 리트리버(retriever)를 구성한 다음, 이를 AI 서비스(AI Service)에 연결합니다:

var embeddingStore = new PgVectorEmbeddingStore(...);
var contentRetriever = new EmbeddingStoreContentRetriever(embeddingStore);

...

두 프레임워크 모두 주요 벡터 저장소(vector stores)를 지원합니다: PostgreSQL (pgvector 포함), Pinecone, Qdrant, Milvus, Chroma, Redis, Weaviate, MongoDB Atlas, Cassandra, Elasticsearch 등이 있습니다.

차이점은 ETL 파이프라인에 있습니다. Spring AI의 DocumentReadConfig 파이프라인은 더 정형화되어 있고 구조적(opinionated)입니다. LangChain4j는 각 단계에 대해 더 많은 제어권을 제공하지만, 더 많은 수동 설정이 필요합니다.

MCP: Model Context Protocol

이 지점이 2026년에 두 프레임워크가 크게 갈라지는 부분입니다.

Spring AI 2.0은 전용 Boot Starter를 통해 일급 시민(first-class) 수준의 MCP 지원을 제공합니다. STDIO, SSE 또는 Streamable-HTTP 전송 방식을 사용하여 MCP 서버와 클라이언트를 실행할 수 있습니다. 심지어 Spring Bean을 MCP 도구(tools)로 노출하기 위한 MCP 어노테이션(annotations) 시스템도 존재합니다:

@McpServer
@Component
public class MathTools {
...

Spring AI 2.0은 MCP를 사후 고려 사항이 아닌, 일급 통합 포인트(first-class integration point)로 취급합니다. application.yaml에서 MCP 서버를 구성하면 자동으로 로드됩니다.

LangChain4j 또한 도구 호출(tool-calling) 및 함수 호출(function-calling) 메커니즘을 통해 MCP를 지원합니다. 하지만 Spring AI와 같은 수준의 자동 구성(auto-configuration)이나 어노테이션 기반의 서버 모델은 갖추고 있지 않습니다. MCP 서버에 연결할 수는 있지만, 수동으로 연결(wire up)해야 합니다.

만약 MCP가 아키텍처의 핵심이라면, 현재로서는 Spring AI 2.0이 확실한 우위에 있습니다.

Spring AI를 선택해야 하는 경우

다음과 같은 경우 Spring AI를 선택하세요:

• 이미 Spring Boot 4를 사용 중인 경우. 자동 설정 (auto-configuration), 속성 기반 설정 (property-driven setup), 그리고 나머지 Spring 생태계와의 일관성은 실제 개발 시간을 절약해 줍니다.
• 관측 가능성 (observability)이 필요한 경우. Spring AI는 Micrometer 및 Spring Boot Actuator와 즉시 통합됩니다. 추가적인 계측 (instrumentation) 없이도 토큰 사용량, 지연 시간 (latency), 에러율에 대한 메트릭을 얻을 수 있습니다.
• MCP가 주요 통합 패턴인 경우. MCP 어노테이션 (annotations)과 자동 설정은 현재 Java 생태계의 그 어떤 것보다 앞서 있습니다.
• Spring 팀의 지원을 원하는 경우. Broadcom은 Spring AI에 장기적인 리소스를 투입하기로 약속했습니다. 릴리스 사이클 (release cycle) 또한 Spring Boot와 연동됩니다.

Spring AI 문서는 매우 훌륭합니다. 참조 가이드 (reference guide)는 실행 가능한 예제와 함께 모든 기능을 다룹니다.

LangChain4j를 선택해야 하는 경우

다음과 같은 경우 LangChain4j를 선택하세요:

• Spring Boot를 사용하지 않는 경우. Quarkus, Helidon, Micronaut 또는 순수 Java를 사용한다면 LangChain4j가 자연스러운 선택입니다.
• 더 넓은 제공자 (providers) 및 벡터 저장소 (vector stores) 생태계가 필요한 경우. 커뮤니티에서 더 많은 통합 기능을 유지 관리하며, 릴리스 사이클이 특정 프레임워크에 종속되지 않습니다.
• AI 서비스 선언적 패턴 (declarative pattern)을 선호하는 경우. 레포지토리 스타일의 프록시 (proxy) 방식이 자연스럽게 느껴진다면, LangChain4j가 Spring AI보다 이를 더 깔끔하게 제공합니다.
• 프레임워크 독립성을 원하는 경우. Spring Boot에서 Quarkus로 (또는 그 반대로) 전환할 가능성이 있다면, LangChain4j는 마이그레이션 비용을 줄여줍니다.

LangChain4j의 시작 가이드는 docs.langchain4j.dev에서 확인할 수 있습니다.

내가 실제로 한 선택

두 개의 프로토타입을 구축한 후, 나는 문서 어시스턴트를 위해 Spring AI를 선택했습니다. 이유는 지루할 정도로 실용적이었습니다. 내 프로젝트는 이미 Spring Boot 4를 사용 중이었고, 자동 설정 (auto-configuration)을 통한 개발 속도 향상이 눈에 띄었기 때문입니다. Advisors API 덕분에 RAG를 구현하는 것이 매우 간단했습니다. 또한 MCP 어노테이션을 통해 어댑터 (adapter)를 작성하지 않고도 기존의 Spring Bean을 도구 (tools)로 노출할 수 있었습니다.

하지만 만약 제가 Quarkus에서 그린필드 프로젝트 (greenfield project)를 시작하거나, 여러 Java 프레임워크에 걸쳐 작동해야 하는 라이브러리를 구축한다면, 저는 주저 없이 LangChain4j를 선택할 것입니다.

두 프레임워크 모두 훌륭한 애플리케이션을 만들어냅니다. 잘못된 선택은 두 프레임워크 중 하나를 고르지 못하는 것이 아니라, 동일한 프로젝트에서 두 가지를 모두 사용하려고 시도하며 추상화 (abstractions)를 중복시키는 것입니다.

빠른 결정 매트릭스 (Quick Decision Matrix)

사용 중인 프레임워크 -- Spring Boot 4인가요? 그렇다면 Spring AI를 선택하세요. 그 외의 다른 JVM 프레임워크인가요? 그렇다면 LangChain4j를 선택하세요.

제공자 커버리지 (Provider coverage) -- 주류 제공자들은 두 프레임워크 모두에서 잘 지원됩니다. 비주류이거나 커뮤니티에서 유지 관리되는 제공자들은 LangChain4j 쪽으로 기울어 있습니다.

MCP 통합 (MCP integration) -- Spring AI 2.0은 자동 설정 (auto-configuration)을 포함한 일급 시민 (first-class) 수준의 어노테이션 기반 MCP 지원을 제공합니다. LangChain4j는 수동 와이어링 (manual wiring)이 필요합니다.

관측 가능성 (Observability) -- Spring AI는 Micrometer 및 Actuator 통합이 내장되어 있습니다. LangChain4j는 사용자가 직접 모니터링을 와이어링할 것을 요구합니다.

학습 곡선 (Learning curve) -- Spring Boot를 알고 있다면 Spring AI가 자연스럽게 느껴질 것입니다. Spring 없이 Java를 알고 있다면 LangChain4j가 시작하기에 더 간단합니다.

프로젝트 이식성 (Project portability) -- LangChain4j는 프레임워크에 구애받지 않습니다 (Quarkus, Helidon, Micronaut, 순수 Java에서 작동). Spring AI는 당신을 Spring 생태계에 종속시킵니다.

RAG를 위한 ETL -- Spring AI는 구조화된 문서 파이프라인 (document pipeline)을 제공합니다. LangChain4j는 각 단계에 대해 더 유연하고 수동적인 제어권을 제공합니다.

Spring AI나 LangChain4j를 프로덕션 환경에서 사용해 보셨나요? 어떤 점이 선택의 근거가 되었나요? 댓글로 여러분의 경험을 들려주세요.

결론: 기능 목록을 비교하여 프레임워크를 선택하지 마세요. 여러분의 프로젝트 철학과 일치하는 것을 선택하세요. Spring AI는 Spring Boot 팀에게 속도와 일관성이라는 보상을 제공합니다. LangChain4j는 모든 JVM 팀에게 유연성과 이식성이라는 보상을 제공합니다. 둘 다 프로덕션 환경에 사용할 준비가 되어 있습니다. 결정은 여러분의 컨텍스트 (context)에 달려 있습니다.