철학적인 논쟁은 건너뜁시다. 이것은 AI를 위해 Java가 Python보다 나은지에 대한 문제가 아닙니다. 모델 연구는 Python이 주도하고 있으며 이는 변하지 않을 것입니다. 이것은 모델 엔드포인트(model endpoint)를 확보한 후, 그 주변에 신뢰할 수 있는 시스템을 구축해야 할 때 발생하는 문제에 관한 것입니다: 검색(retrieval), 도구 호출(tool calling), 멀티 에이전트 오케스트레이션(multi-agent orchestration), 관측성(observability), 그리고 출시 당일에 무너지지 않을 만큼의 충분한 처리량(throughput)에 관한 것입니다.

이 가이드는 Java 21, Spring Boot 3.x, Spring AI, 가상 스레드(virtual threads), 그리고 구조화된 동시성(structured concurrency)을 사용하여 프로덕션 등급의 RAG + 에이전트 서비스를 구축하는 과정을 다룹니다. 실제 코드, 실제 트레이드오프(tradeoffs), 그리고 여러분이 제 말만 믿는 것이 아니라 직접 확인할 수 있도록 몇 가지 다이어그램을 포함합니다.

백엔드 엔지니어들이 AI 팀에 합류하게 되는 이유

2026년의 AI 제품은 단순한 모델 호출이 아닙니다. 그것들은 분산 시스템(distributed systems)입니다: 검색 파이프라인(retrieval pipelines), 도구 호출 에이전트(tool-calling agents), 비용과 신뢰성을 위한 멀티 모델 라우팅(multi-model routing), 시맨틱 캐싱(semantic caching), 그리고 5개의 서로 다른 서비스를 가로질러 요청을 추적해야 하는 관측성 스택(observability stacks) 등이 포함됩니다. 그것은 그래프의 한 노드에 LLM이 결합된 백엔드 엔지니어링입니다.

flowchart LR
    U[User Request] --> GW[AI Gateway]
    GW --> RT[Model Router]
...

AI 요청 처리(AI request handling)는 거의 전적으로 I/O 대기(I/O wait) 상태입니다. 모델을 호출하고, 벡터 스토어(vector store)를 호출하고, 도구(tool)를 호출하고, 다시 모델을 호출하는 과정의 연속입니다. 플랫폼 스레드(Platform threads)는 이 과정을 비용이 많이 들게 만들었습니다. 각 차단된(blocked) 스레드가 OS 스레드를 점유했기 때문에, 스레드 풀(thread pool)을 튜닝하며 요행을 바랄 수밖에 없었습니다. 가상 스레드(Virtual threads)는 이 둘을 분리합니다. 여러분은 일반적이고 차단 방식(blocking)이며 가독성 좋은 코드를 작성하면 되고, JVM은 이를 소수의 캐리어 스레드(carrier threads) 위에 수천 개의 스레드로 스케줄링합니다.

@RestController
@RequestMapping("/api/chat")
public class ChatController {
...

수동적인 스레드 풀 튜닝이 필요 없습니다. 높은 동시성(high concurrency)을 확보하기 위해 리액티브 보일러플레이트(reactive boilerplate)를 작성할 필요도 없습니다. 다만, 단순히 높은 스레드 수가 아니라 스트리밍 파이프라인에 대한 진정한 백프레셔(backpressure) 제어가 필요한 경우에는 WebFlux가 여전히 유효한 선택지입니다. 가상 스레드와 리액티브 스트림(reactive streams)은 서로 겹치면서도 별개의 문제를 해결합니다. 가상 스레드는 명령형 코드(imperative code)로 저렴한 동시성을 제공하며, WebFlux는 백프레셔와 논블로킹 합성(non-blocking composition)을 제공합니다. 흐름 제어(flow control) 요구 사항이 있는 대용량 스트리밍을 처리할 때는 리액티브를 선택하고, 대규모 환경에서 차단 방식의 단순함을 원할 때는 가상 스레드를 선택하십시오. 많은 프로덕션 시스템이 이 두 가지를 모두 사용합니다.

멀티 도구 에이전트 호출을 위한 구조화된 동시성 (Structured Concurrency)

에이전트는 빈번하게 여러 도구나 검색 소스로 병렬적으로 팬아웃(fan out)하고 결과를 결합해야 합니다. Java의 구조화된 동시성(structured concurrency, JDK 21+ 프리뷰에서 확정되어 이후 릴리스에서 안정화됨)은 부분적인 실패 시에도 스레드를 누수(leak)시키지 않고 이를 수행할 수 있는 깔끔한 방법을 제공합니다.

public AgentResult gatherContext(String query) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        var vectorResults = scope.fork(() -> vectorStore.similaritySearch(query));
...

만약 하위 작업(subtask) 중 하나라도 실패하면, 스코프(scope)가 다른 작업들을 자동으로 취소합니다. 고아 스레드(orphaned threads)도, 수동적인 CompletableFuture 정리도, 조용한 누수(silent leaks)도 발생하지 않습니다. 이는 잊혀진 Future가 결국 아무도 설명하고 싶지 않은 메모리 프로필(memory profile) 문제로 나타나는 장기 실행 에이전트 서비스에서 실제로 발생하는 문제입니다.

RAG 아키텍처: pgvector vs. Qdrant vs. Milvus

Java 기반의 RAG 파이프라인을 위한 벡터 스토어(vector store)를 선택하려는 팀을 위한 빠르고 솔직한 비교입니다:

대부분의 중간 규모 프로덕션 시스템에서는 pgvector가 단순성 측면에서 승리합니다. 운영해야 할 데이터베이스가 하나 줄어들고, 장애 도메인 (failure domain)도 하나 줄어듭니다. 또한 Spring AI의 PgVectorStore는 Spring의 트랜잭션 관리 (transaction management)와 직접 통합되는데, 이는 벡터 쓰기 작업이 나머지 데이터 모델과 일관성을 유지해야 할 때 매우 중요합니다.

@Bean
public VectorStore vectorStore(JdbcTemplate jdbcTemplate, EmbeddingModel embeddingModel) {
    return PgVectorStore.builder(jdbcTemplate, embeddingModel)
...

멀티 모델 라우팅 (Multi-Model Routing) 및 비용 제어

프로덕션 시스템에서는 모든 요청에 대해 단일 모델만을 호출하는 경우가 드뭅니다. 저렴하고 빠른 모델은 단순한 쿼리를 처리하고, 더 큰 모델은 복잡한 추론 (reasoning)을 처리하며, Ollama 또는 vLLM을 통한 로컬 모델은 제3자 인프라에 두기에 민감한 모든 작업을 처리합니다. LiteLLM 또는 커스텀 Spring AI ChatModel 라우터가 이 모든 모델의 앞단에 위치할 수 있습니다:

@Component
public class ModelRouter {

...

이 지점에서

실제로 이는 트래픽은 높지만 변동성이 낮은 쿼리 패턴(고객 지원 봇, FAQ 스타일의 어시스턴트, 내부 도구 등)에서 동일한 질문이 수십 가지의 다른 표현으로 나타날 때 모델 비용을 유의미하게 절감해 줍니다.

에이전트 오케스트레이션 (Agent Orchestration) 및 MCP

Model Context Protocol (MCP)는 모든 팀이 각자 맞춤형 함수 호출 (function-calling) 스키마를 직접 만드는 대신, 에이전트가 도구를 발견하고 호출하는 방식을 표준화합니다. Spring AI의 MCP 지원을 사용하면 Java 서비스를 MCP 서버로 등록할 수 있으며, 이를 통해 어떤 언어나 프레임워크로 구축되었는지와 관계없이 규약을 준수하는 모든 에이전트가 호출할 수 있습니다:

@McpServer(name = "invoice-tools")
public class InvoiceToolServer {

...

분기 로직이 포함된 다단계 에이전트 워크플로우의 경우, 팀들은 종음적으로 LangGraph와 유사한 그래프 기반 오케스트레이션 (orchestration) 패턴을 Spring AI의 도구 호출 (tool-calling) 프리미티브와 결합하여 사용하는 경우가 많습니다. 이는 에이전트를 암시적인 체인 (chain)이 아닌 명시적인 상태 머신 (state machine)으로 모델링하게 하여, 실패한 실행에 대한 디버깅을 극적으로 쉽게 만들어 줍니다:

stateDiagram-v2
    [*] --> Retrieve
    Retrieve --> Decide
...

구조화된 출력 (Structured Outputs)

다운스트림 (downstream) 시스템에는 산문이 아닌 구조화된 데이터가 필요합니다. Spring AI의 구조화된 출력 컨버터 (structured output converters)는 모델의 응답을 스키마 검증 (schema validation) 기능이 내장된 Java 레코드 (record)로 직접 매핑합니다:

public record InvoiceSummary(
    String customerId,
    double totalAmount,
...

이를 통해 초기 단계의 AI 통합 과정에서 빈번하게 발생하는 문제인, 모델의 자유 형식 텍스트 출력으로부터 JSON을 수동으로 파싱할 때 발생하는 버그 카테고리 전체를 제거할 수 있습니다.

관측 가능성 (Observability): 보이지 않는 것은 고칠 수 없다

AI 시스템은 일반적이지 않은 방식으로 실패합니다. 조용한 환각 (hallucination), 부하 상황에서의 느린 성능 저하, 아무도 검토하지 않은 프롬프트 템플릿 변경으로 인한 비용 급증 등이 그 예입니다. 표준 관측 가능성 (observability) 도구들이 여전히 유효하며, 이 분야에서 Java의 생태계는 매우 성숙해 있습니다:

@Bean
public ObservationRegistry observationRegistry(MeterRegistry meterRegistry) {
    return ObservationRegistry.create()
...

Spring AI는 Micrometer를 통해 채팅 호출 (chat calls), 임베딩 호출 (embedding calls), 벡터 스토어 작업 (vector store operations)을 자동으로 계측 (auto-instruments)하며, 이는 추가적인 연결 코드 (glue code) 없이 Prometheus 및 OpenTelemetry로 흐릅니다. 프로덕션 환경에서는 최소한 다음 항목들을 추적해야 합니다: 요청당 토큰 사용량 (token usage per request), 모델별 지연 시간 백분위수 (latency percentiles per model), 캐시 히트율 (cache hit rate), 그리고 도구 호출 실패율 (tool-call failure rate). 마지막 항목은 사용자가 문제를 인지하기 몇 주 전에 문제를 포착해 줍니다.

배포: 컨테이너 및 시작 시간

지연 시간에 민감하거나 서버리스 (serverless)에 인접한 AI 배포 환경에서 Java에 대해 흔히 제기되는 반론은 JVM 시작 시간입니다. 알아둘 가치가 있는 두 가지 완화 방법은 다음과 같습니다:

• CDS (Class Data Sharing) / AppCDS — 클래스 메타데이터를 캐싱하여 컨테이너화된 배포 환경의 콜드 스타트 (cold start)를 유의미하게 줄여줍니다.
• GraalVM native image — 콜드 스타트가 정말로 중요한 서비스 (scale-to-zero Kubernetes 배포 등)의 경우, 네이티브 바이너리로 컴파일하면 시작 시간을 초 단위에서 밀리초 (milliseconds) 단위로 단축할 수 있습니다. 다만, 빌드 시간이 길어지고 리플렉션 (reflection) 의존도가 높은 라이브러리와의 호환성 문제가 발생할 수 있습니다 (결정하기 전에 사용 중인 특정 스타터에 대한 Spring AI의 네이티브 지원 상태를 확인하십시오).

FROM eclipse-temurin:21-jre-alpine
COPY target/ai-service.jar app.jar
ENTRYPOINT ["java", "-XX:+UseZGC", "-jar", "app.jar"]

특히 AI 서비스의 경우 ZGC (Z Garbage Collector)를 기본값으로 사용하는 것이 가치가 있습니다. SSE를 통해 토큰을 스트리밍할 때 GC 일시 중단 (GC pause)이 응답에서 눈에 보이는 끊김으로 나타날 수 있으므로, 서브 밀리초 (sub-millisecond) 단위의 일시 중단 시간이 중요하기 때문입니다.

이것이 의미하는 바

이 모든 것이 모델 개발, 평가 또는 연구를 위한 Python을 대체하는 것은 아니며, 그것이 목표도 아닙니다. 이것이 제공하는 것은 모델 '주변'에서 필요한 모든 것, 즉 검색 (retrieval), 도구 오케스트레이션 (tool orchestration), 멀티 모델 라우팅 (multi-model routing), 캐싱 (caching), 구조화된 출력 (structured outputs), 그리고 관측성 (observability)을 위한 프로덕션 등급의 레이어입니다. 이는 고동시성 (high-concurrency), 장기 실행 (long-running), I/O 바운드 (I/O-bound) 서비스와 같이 중단 없이 운영되어야 하는 문제들을 위해 수십 년간 튜닝되어 온 런타임(runtime) 위에서 구축되었습니다.

만약 현재 AI 오케스트레이션 레이어 (AI orchestration layer)를 우연히 서비스로 커져 버린 Python 스크립트로 운영하고 있다면, 여기서 제시하는 마이그레이션 경로 (migration path)는 그 어떤 것도 버릴 필요가 없습니다. 모델 레이어 (model layer)는 Python으로 유지하십시오. 그 앞에 라우팅 (routing), 캐싱 (caching), 그리고 오케스트레이션 (orchestration)을 담당할 Java 서비스를 배치하십시오. 한 달 뒤, 여러분의 p99 지연 시간 (p99 latency)과 온콜 (on-call) 부하가 어떻게 달라졌는지 측정해 보십시오.