2024년 5월 첫 마일스톤이 나왔을 때 Spring AI는 "Spring Boot 생태계에 AI를 끼얹어 보자"는 실험 프로젝트에 가까웠다. 그로부터 약 1년 뒤인 2025년 5월 1.0 GA, 다시 6개월 뒤 1.1 GA, 그리고 한 달 뒤 2.0 첫 마일스톤. "AI 시대의 Spring Data"가 될 수 있는가라는 질문이 "이제 어떤 속도로 성숙하는가"로 바뀐 2년이었다.
이 글은 두 가지를 한꺼번에 본다. 시점(타임라인) — 버전별로 무엇이 언제 들어왔는가. 그리고 성능 — 실제 숫자로 본 1.0 대비 2.0의 체감 차이와 마이그레이션 비용.
1. 타임라인 총정리
| 2024년 5월 | 첫 마일스톤 | ChatClient·Prompt·RAG의 골격 |
| 2025년 4월 | 1.0.0-M7 | Docker Model Runner, MCP 0.9.0 통합 |
| 2025년 5월 초 | 1.0.0-M8 | Chat memory, Template rendering 개선 |
| 2025년 5월 13일 | 1.0.0-RC1 | API freeze, DeepSeek 전용 지원, Breaking change 마무리 |
| 2025년 5월 20일 | 1.0 GA | ChatClient·RAG·Memory·Tools·MCP·Advisors 일체화 |
| 2025년 8월 | 1.0.1 | 안정화 150+ 변경 |
| 2025년 10월 | 1.0.3 | GemFire 필터, GraalVM 네이티브 이미지 개선 |
| 2025년 11월 3일 | 1.1.0-M4 | 340개 개선, MCP 0.15.0 |
| 2025년 11월 12일 | 1.1 GA | Prompt caching(비용 90% 절감), Spring AI Agents |
| 2025년 12월 11일 | 2.0.0-M1 | Spring Boot 4.0 + Framework 7.0 + Jakarta EE 11 베이스 |
| 2026년 3월 17일 | 2.0.0-M3 | MCP 패키지 rename, Jackson 2→3 마이그레이션 |
| 2026년 3월 26일 | 2.0.0-M4 | Vertex AI / ZhiPu / OCI GenAI 단계적 Deprecation |
| 미정 | 2.0 GA | "Null safety + Jackson 3 + Boot 4" 3대 테마 |
주목할 점은 속도다. 1.0 GA에서 2.0 첫 마일스톤까지 정확히 7개월. 그 사이에 1.1 GA까지 끼워넣으며 "LTS성 안정 트랙"과 "차세대 플랫폼 트랙"을 병행 운영했다. Spring Boot 본가가 3.x 안정화와 4.0 준비를 동시에 돌린 것과 같은 이중 트랙이다.
2. Spring AI 1.0 — "골격"이 완성된 시점
2.1 1.0 GA가 담은 것
2025년 5월 20일 1.0 GA가 발표됐을 때 핵심 메시지는 "프로덕션에 가져다 쓸 수 있는 기본기 완성" 이었다. 구성은 다음 6개 축이다.
- ChatClient: 프로바이더 중립 API. OpenAI, Anthropic, Google Gemini, Ollama, Azure, Bedrock 등을 동일 인터페이스로.
- Advisors: Spring MVC의 HandlerInterceptor 같은 느낌. 프롬프트 전후 처리 체인을 모듈화.
- RAG: DocumentLoader → Splitter → EmbeddingModel → VectorStore → Retriever 파이프라인.
- ChatMemory: JDBC, Cassandra, Neo4j 등 스토리지 백엔드 선택.
- Tool Calling: @Tool 어노테이션 기반 선언형 + @Bean 동적 등록 + 프로그래매틱 생성 3가지 방식.
- MCP (Model Context Protocol): Anthropic 스펙 공개 직후 Spring AI 팀이 먼저 Java SDK를 만들어 Anthropic에 기증. 그 기반 위에 Spring Boot starter 제공.
여기서 중요한 역사적 사실 하나. MCP Java SDK는 Spring AI 팀에서 시작해서 Anthropic으로 갔다. 지금 표준이 된 MCP의 Java 진영 발판을 Spring 팀이 먼저 깔았다는 뜻이다. 한국 Java 개발자 입장에서는 생각보다 자부심 가져도 되는 지점이다.
2.2 1.0이 남긴 한계
하지만 1.0 GA는 완성이 아니라 "production에 쓸 수 있는 최소한"이었다. 실무에서 체감된 한계는 세 가지였다.
- 비용 제어 수단 부재: Prompt caching이 없어서 시스템 프롬프트를 매 요청마다 풀로 보내는 구조. 장문 프롬프트가 많은 에이전트 워크로드에서 그대로 토큰 비용이 나왔다.
- 에이전틱 패턴 추상화 미흡: ReAct, Plan-and-Execute, Multi-agent 같은 패턴을 쓰려면 Advisors를 직접 조립해야 했다.
- 모델 버전 종속: 예를 들어 OpenAI starter 하나 바꾸려면 공식 SDK가 아닌 Spring AI 자체 구현을 통해야 해서 신규 API(Responses API 등) 반영 속도가 느렸다.
2.3 1.1 GA가 메운 구멍 — 성능 관점의 변곡점
2025년 11월 12일의 1.1 GA는 이 세 가지 중 두 가지를 정면 타격했다.
첫째, Prompt Caching 정식 지원. Anthropic Claude, AWS Bedrock Converse API 양쪽에 5분/1시간 TTL 캐시가 붙었다. 공식 블로그가 제시한 수치는 비용 최대 90% 절감, 응답 시간 개선. 긴 시스템 프롬프트 + 반복 질의 구조를 가진 RAG 에이전트라면 이 하나로 운영 경제학이 바뀐다.
둘째, Spring AI Agents 프레임워크. 에이전틱 코딩 도구와 AI 에이전트를 만들기 위한 별도 프레임워크가 Spring AI Community GitHub Organization 산하로 분리 신설됐다. Claude Code 같은 자율 CLI 에이전트를 Spring AI 위에서 돌리기 위한 AgentClient 실험이 여기서 나왔다.
셋째, MCP Java SDK v0.10 → v0.15. 약 6개월 만에 5개 마이너 버전이 진행됐다. OAuth2-secured MCP server, 다중 프로토콜 버전 협상(2024-11-05 + 2025-03-26), HTTP+SSE 전송 등이 누적됐다.
1.1 GA 지점에서 Spring AI는 비로소 "production RAG + MCP 에이전트"를 표준 패턴으로 태울 수 있는 스택이 됐다고 본다. 1.0은 "만들 수 있다", 1.1은 "운영할 수 있다"의 차이.
3. Spring AI 2.0 — 골격이 아니라 토대의 교체
2.0이 흥미로운 이유는 AI 기능 추가가 아니라 플랫폼 교체이기 때문이다. 2025년 12월 11일 나온 M1의 변경 요점은 "2.0은 Spring Boot 4.0 + Framework 7.0 + Jakarta EE 11 베이스로 통째 재정렬됐다"였다.
3.1 세 가지 핵심 테마
Spring AI 팀이 공식 로드맵에서 2.0 GA의 핵심 테마로 잡은 것은 다음과 같다.
- Spring Boot 4.0 baseline
- Null Safety (JSpecify 어노테이션 기반, NullAway 같은 정적 분석 친화)
- Jackson 3 baseline
이 세 가지가 겉보기에는 배경 작업 같지만, 실제 코드에 얼마나 큰 파장을 만드는지는 다음 섹션에서 성능과 함께 짚는다.
3.2 M1 → M3 → M4에서 쌓인 실질 변화
이후 마일스톤에서 누적된 중요한 변화 몇 가지.
M1 (2025-12-11)
- Official OpenAI Java SDK 네이티브 통합 — Spring AI가 자체 래퍼 대신 공식 SDK를 직접 사용. 신규 API 반영 속도의 고질병을 구조적으로 해결.
- Default temperature 설정 제거 (Breaking change) — 암시적 기본값에 의존하던 애플리케이션은 명시적 설정 필수.
- Default chat model: gpt-5-mini로 변경.
- Anthropic Citations API 지원 — Claude가 제공 문서의 특정 부분을 참조하며 답변 생성 가능. Claude 3.7 Sonnet 및 Claude 4 모델 계열.
- Claude Skills + Files API 통합 — Claude가 직접 다운로드 가능한 파일을 생성하는 워크플로우를 Spring AI 내부에서 오케스트레이션.
- Tool Choice 지원 — Auto / Any / Tool / None 4가지 모드로 툴 호출 강제 여부 제어.
- Azure Cosmos DB Chat Memory starter 추가.
M3 (2026-03-17)
- MCP annotation 패키지 rename (Breaking change)
- MCP transport artifact 재배치 (Breaking change)
- Jackson 2 → Jackson 3 마이그레이션 (Breaking change). 이게 조용한 시한폭탄이다(아래 성능 섹션 참조).
- ToolContext에서 대화 이력 제거 (Breaking change)
- CVE-2026-22729, CVE-2026-22730 보안 패치 동반.
M4 (2026-03-26)
- Vertex AI / ZhiPu AI / OCI GenAI 모델 통합 클래스를 Deprecated 처리. 향후 버전에서 제거 예정. 이들 프로바이더를 쓰던 팀은 마이그레이션 계획 필수.
- OpenAI SDK 4.28.0, Anthropic SDK 2.17.0 반영.
- Google Generative AI SDK 1.44.0 반영.
3.3 2.0 GA는 언제쯤?
공식 마일스톤 페이지에는 "New features: TBD" 라고만 되어 있다. 일정도 명시적 공개가 없다. 다만 지금까지의 패턴(M1에서 M3까지 3개월)과 업계 관측(Spring Boot 4.0이 2025년 11월 GA된 점, Spring I/O 2026 4월 발표가 2.0 중심이었던 점)을 종합하면 2026년 2분기 말 ~ 3분기 GA가 현실적 추정선이다. 다만 아직 M4에서 deprecation 정리가 진행 중이라는 걸 보면 RC 단계가 더 길어질 가능성도 있다.
4. 성능 관점의 실제 숫자
"2.0이 1.0보다 얼마나 빠른가"라는 질문에 직접 답하는 공식 벤치마크는 아직 없다. 하지만 2.0이 깔고 있는 플랫폼(Boot 4, Java 21+, Jackson 3) 각각이 만드는 성능 레버가 명확하니, 그것들을 하나씩 본다.
4.1 Prompt Caching (1.1 시점, 2.0 계승)
가장 큰 숫자는 여기다. 비용 최대 90% 절감.
긴 시스템 프롬프트가 있는 Anthropic Claude 기반 RAG 에이전트에서 반복 질의 구조라면, 시스템 프롬프트 + 대화 이력 + RAG 컨텍스트를 캐시에 태워 입력 토큰 청구를 1/10 수준까지 줄일 수 있다. 실무 입장에서 이게 왜 중요한가:
- 8K 토큰 시스템 프롬프트 + 회당 500 토큰 질의 구조를 가정.
- 캐시 전: 회당 청구 = 8,500 토큰 × 입력 단가.
- 캐시 후: 캐시 히트 시 약 10% 비용만 청구 → 회당 실효 토큰 ≈ 1,350.
- 하루 10만 회 호출 기준으로 월 토큰 비용이 분기 예산 단위로 달라진다.
2.0에서도 이 기능은 그대로 계승되고 AWS Bedrock Converse API 측 개선이 추가됐다.
4.2 Virtual Threads — Spring Boot 3.2부터 가능, Boot 4에서 본격 자리 잡음
Spring AI 자체가 virtual threads를 쓰는 건 아니지만, Spring AI 애플리케이션이 올라가는 Spring Boot 런타임의 병목이 여기서 풀린다.
LLM 호출은 본질적으로 블로킹 I/O다. 수 초씩 걸리는 외부 API 호출이 동시에 수백 건 들어올 때 기존 플랫폼 스레드 모델은 스레드풀 고갈이 즉시 온다. 커뮤니티 벤치마크에 따르면, 블로킹 인터서비스 HTTP 호출 시나리오에서 virtual threads가 3배 이상의 처리량 개선을 보인다. 데이터베이스 블로킹 호출에서는 체감이 거의 없다는 보고도 있으니 워크로드별로 측정 필요.
Spring AI 관점에서 함의: LLM 호출이 주 블로킹 지점인 AI 에이전트 서버는 virtual threads 활성화만으로 동시 처리량이 유의미하게 개선된다. spring.threads.virtual.enabled=true 한 줄이다.
4.3 Jackson 3 — 기본값 변경의 조용한 파장
2.0 M3에서 들어온 Jackson 2 → 3 마이그레이션은 라이브러리 버전업 이상의 의미를 갖는다. 기본값 몇 개가 바뀌었는데, 그 중 하나가 WRITE_DATES_AS_TIMESTAMPS다. 기본 동작이 Unix timestamp에서 ISO-8601 문자열로 바뀌었다.
성능 관점에서는 직렬화/역직렬화 경로가 크게 달라진다는 뜻이고, 실무 관점에서는 클라이언트 코드 · 스냅샷 테스트 · 프론트엔드의 날짜 파싱 로직이 조용히 깨질 수 있다는 뜻이다. 업그레이드 전 date 필드를 전수 감사하는 것이 표준 절차가 됐다.
4.4 AOT 캐시와 Leyden — 시작 시간 41%
Java 26에서 들어온 AOT 캐시 확장(JEP 516)은 ZGC에서도 사용 가능해졌다. Spring PetClinic 벤치마크 기준 AOT 캐시 적용 시 시작 시간 41% 개선 보고가 나왔다. 이게 어떤 영향인가:
- 쿠버네티스 환경에서 파드 복구·스케일 아웃 지연 단축.
- 서버리스/FaaS 환경에서 Cold Start 개선.
- Spring AI 2.0이 Boot 4 위에서 동작하므로, Java 26 런타임과 조합 시 이 이득을 그대로 흡수.
4.5 공식 SDK 네이티브 통합
1.0 시대에는 OpenAI의 새 API(예: Responses API)가 나오면 Spring AI가 자체 래퍼를 업데이트할 때까지 기다려야 했다. 2.0에서는 공식 OpenAI Java SDK를 직접 쓴다. 이는 성능 숫자로 치환하긴 어렵지만, 신규 기능 반영 지연이라는 운영 리스크를 없앤다는 점에서 실질 레버다.
5. 1.0 → 2.0 마이그레이션 체크리스트
1.0에서 2.0으로 직접 점프하는 대신 1.0 → 1.1 → 2.0의 2단 마이그레이션을 권장한다. 그 이유와 체크리스트.
Phase 1: 1.0 → 1.1
- Prompt caching 적용 가능한 지점 식별(긴 시스템 프롬프트, 반복 질의)
- MCP 클라이언트/서버 의존성 버전 업그레이드
- Chat memory repository 네이밍 변경 반영 (spring.ai.chat.memory.<storage> → spring.ai.chat.memory.repository.<storage>)
- ToolCallAdvisor의 새 hook 사용처 검토
Phase 2: 1.1 → 2.0
- Spring Boot 3.x → 4.0 업그레이드. 이게 전제 조건. 별도 프로젝트로 관리.
- Java 17이 baseline이지만 Java 21+ 강력 권장 (virtual threads, Leyden 이득).
- default temperature 의존 코드 감사 — 암시적으로 기본값을 받던 모든 호출을 명시적 설정으로 전환.
- Jackson 3 date 포맷 감사 — 모든 API 응답의 timestamp 필드 클라이언트 영향 확인.
- MCP 패키지 import 경로 일괄 변경 (M3 breaking change 반영).
- ToolContext에서 대화 이력 끄집어 쓰던 코드 리팩터링.
- Vertex AI / ZhiPu AI / OCI GenAI 사용 중이면 대체 프로바이더 확정.
- JSpecify 어노테이션 기반 null-safety에 맞춰 IDE 경고 처리.
Phase 3 (선택): Java 26 + AOT 캐시 도입
- Spring PetClinic 벤치마크 기준 41% 시작시간 개선 — 하지만 조직 차원의 Java 버전 정책이 전제.
- 컨테이너 이미지에 AOT 캐시 생성 단계 추가.
6. 한국 개발자·팀 관점의 판단 포인트
6.1 스파르타클럽·KOSA 등 교육 트랙에서 배우는 입장
Spring AI 교육 과정이 대부분 1.0 또는 1.1 기준이다. 2026년 2분기 현재 "배우는 것은 1.1, 실험하는 것은 2.0 M4" 가 현실적이다. 교육에서 배운 API 중 ChatClient, Advisors, RAG, Tool Calling 코어는 2.0에서도 거의 호환되므로 학습 자산이 사라지지 않는다. 다만 설정 프로퍼티 몇 개와 Jackson 관련 직렬화는 2.0 전환 시 재학습 포인트다.
6.2 실제 회사 프로덕션에 쓰는 입장
정산·결제 같은 미션 크리티컬 도메인이라면 2.0 GA가 나온 뒤 최소 2–3개월 대기 후 도입이 안전선이다. M1–M4 사이 breaking change가 이미 여러 개 쌓였고, 실제 GA 시점에 추가 변경이 있을 가능성이 있다. 반면 내부 관리 도구, 사내 챗봇 수준이라면 지금 2.0 M4로 POC를 돌리는 게 2.0 GA 시점에 한 발 먼저 프로덕션에 태우는 가장 빠른 경로다.
7. 마무리 — 플랫폼의 성숙과 선택의 시점
2024년 5월 첫 마일스톤에서 2026년 4월 2.0 M4까지, 약 23개월. Spring AI가 "Spring 생태계의 AI 어댑터 계층"에서 "AI-Native Java 애플리케이션의 기본 플랫폼"으로 포지션을 옮기는 데 걸린 시간이다.
1.0 GA가 던진 질문은 "Python 없이 프로덕션 AI 애플리케이션을 만들 수 있는가" 였고, 답은 "기본기는 됐다"였다. 1.1 GA는 "운영 경제학이 성립하는가" 를 물었고, Prompt caching 90% 절감으로 답했다. 2.0이 묻는 것은 다른 층위의 질문이다 — "Spring Boot 4, Jakarta EE 11, Jackson 3, Java 21+ 위에 AI가 1급 시민(first-class citizen)으로 올라섰을 때, Java 진영의 AI 개발 경험은 어디까지 갈 수 있는가."
이 질문의 답은 2.0 GA가 나오고 6개월 정도 실제 프로덕션 사례가 쌓인 뒤에야 나올 것이다. 그 답을 기다리는 동안 우리가 할 일은 단순하다. 1.1에서 쓸 수 있는 것을 충분히 써서 운영 비용을 먼저 내려놓고, 2.0이 요구하는 플랫폼 업그레이드(Boot 4, Jackson 3, Java 21+)를 개별 트랙으로 준비해두는 것. 두 트랙이 만나는 지점이 바로 2026년 하반기의 기술 투자 포인트다.
참고 자료
- Spring AI 1.0 GA Released (Spring 공식 블로그)
- Spring AI 1.1 GA Released (Spring 공식 블로그)
- Spring AI 2.0.0-M1 Available Now (Spring 공식 블로그)
- Spring AI 2.0.0-M3 Release Notes
- Spring AI 2.0.0-M4 Release Notes
- Spring Projects Milestones — Spring AI 2.0 Roadmap
- Chris van Breeden — Spring Boot 4 and Spring AI 2.0: The New Java AI Stack (Medium)
- TechLife — Java in April 2026: Leyden Grows Up, Spring Gets Smarter
- Salaboy — Spring I/O 2026 참관기
- Alibaba Cloud — Spring AI Alibaba 1.0 GA 발표
'Software > Maker(Spring & Python & node)' 카테고리의 다른 글
| 한국 솔루션의 진짜 해자 — 기술이 아닌 제도·관계·도메인의 구조 분석 (0) | 2026.04.23 |
|---|---|
| Claude Code로 OZ Report 같은 리포트 툴을 만들 수 있을까 — 픽셀 퍼펙트와 법적 유효성 사이 (1) | 2026.04.23 |
| 분산 시스템 기반 대규모 트래픽 처리(wil. 7week) (0) | 2026.04.23 |
| Claude Mythos는 언제 우리 손에 오는가 — 공개 시점과 오픈소스 생태계에 미칠 영향에 대한 고찰 (6) | 2026.04.23 |
| Claude Opus 4.7, 4.6과 무엇이 달라졌나 — 실사용자 관점 마이그레이션 노트 (0) | 2026.04.23 |