Day 23. LLM Ops & 마무리 — 운영 생태계 · 2.0 전환 · 전체 회고

전통 APM vs LLM Ops

Day 22에서 Micrometer + Prometheus + Grafana를 연결했어요. 전통적인 APM(Application Performance Monitoring)의 정석이죠. 이 조합으로 볼 수 있는 건 이런 것들이에요.

Day 22의 UsageTrackingMeterAdvisor가 마지막 줄까지 커버해줬어요. 그런데 LLM 앱은 여기서 끝이 아니에요.

LLM Ops가 추가로 보는 축:

Langfuse — 오픈소스 LLM Ops

Langfuse는 오픈소스 LLM Ops 플랫폼이에요. 셀프 호스팅(Docker)도 가능하고, 클라우드 서비스도 있어요.

핵심 개념 3가지:

1. Trace — 사용자 요청 한 건의 전체 흐름. 우리 ai-friends에서 "채팅 메시지 1건 보내기"가 Trace 하나예요.
2. Generation — Trace 안에서 실제 LLM 호출 1건. ChatClient가 ChatModel.call()을 부르는 순간이 Generation이에요. 모델명, 토큰 수, 지연시간, 비용이 자동으로 기록돼요.
3. Score — Generation이나 Trace에 붙이는 품질 점수. 사용자 👍/👎 피드백, 또는 Day 21의 AgentBench 같은 자동 평가 결과를 Score로 기록해요.

Langfuse가 해결하는 문제들:

• 프롬프트 버전 관리: Day 3에서 만든 SoulmateSystemPrompt.st 를 버전 v1, v2, v3으로 관리. 어느 버전이 더 나은 응답을 만드는지 A/B 비교.
• 비용 대시보드: 모델별, 기능별, 사용자별 비용 분석. "이미지 생성이 전체 비용의 70%를 쓴다"를 숫자로 확인.
• 평가 파이프라인: 자동 평가(환각률, 관련성, 독성) + 사람 평가(라벨링) 결합.

현재 서버 v3.175.0, Python/JS SDK는 v4로 전면 리라이트되었어요.

LangSmith — LangChain 진영의 관리형 서비스

LangSmith는 LangChain 팀이 만든 상용 LLM Ops 플랫폼이에요. LangChain에 최적화되어 있지만, REST API로 어떤 프레임워크에서든 사용할 수 있어요.

요금 구조 (2026년 5월 기준):

LangSmith의 강점:

• Hub: 프롬프트를 팀 단위로 공유하는 저장소. "이 프롬프트 잘 됐으니까 팀에 공유"가 클릭 한 번.
• Datasets: 평가용 입력/기대 출력 데이터셋을 버전 관리. CI/CD에 평가 자동 실행.
• Annotation Queue: 사람이 라벨링할 응답을 큐로 관리.

Langfuse vs LangSmith — 어떤 걸 선택할까

💡 결론: 사내 인프라에 데이터를 보관해야 하는 조직이라면 Langfuse 셀프 호스팅이 적합해요. 빠른 시작과 관리형 서비스를 선호한다면 LangSmith Developer(무료)부터 시작하세요.

어느 쪽이든 Day 22에서 만든 Prometheus 메트릭 인프라와 병행해서 쓰는 거예요.

Day 22에서 만든 것 복습

Day 22에서 3종의 Advisor를 만들었어요.

Prometheus + Grafana에서 8개 패널 대시보드까지 만들었어요. 인프라 메트릭 관점은 완성된 상태예요.

LLM Ops 플랫폼이 추가하는 계층

여기에 Langfuse 같은 LLM Ops 플랫폼을 연결하면 두 번째 관측 경로가 생겨요.

사용자 요청
  → ChatClient
    → Advisor Chain
      ├── PiiMaskingAdvisor
      ├── AuditLoggingAdvisor ──→ AuditLog DB
      └── UsageTrackingMeterAdvisor ──→ Micrometer
    → ChatModel.call()
      → LLM Provider (Gemini / Ollama)

관측 경로 1 (인프라): Micrometer → Prometheus → Grafana
관측 경로 2 (LLM 특화): OpenTelemetry → Langfuse

연결 포인트 — Spring AI Observation

Spring AI는 내부적으로 Micrometer Observation API를 사용해요. Day 22에서 spring-boot-starter-actuator를 추가했을 때 자동으로 활성화된 것이죠.

이 Observation 데이터를 OpenTelemetry 프로토콜(OTLP)로 내보내면, Langfuse가 받을 수 있어요.

연결에 필요한 설정은 이런 형태예요.

# application.yml — Langfuse 연결 (개념 예시)
spring:
  ai:
    chat:
      observations:
        include-input: true
        include-output: true

management:
  otlp:
    tracing:
      endpoint: http://localhost:3000/api/public/otel/v1/traces
    metrics:
      export:
        otlp:
          enabled: true

# .env
LANGFUSE_PUBLIC_KEY=pk-...
LANGFUSE_SECRET_KEY=sk-...

⚠️ 이 설정은 개념 안내예요. 오늘은 단방향 강의라 직접 연결하지 않아요. 핵심은 "Day 22 인프라 위에 OTLP exporter 하나 추가하면 LLM Ops 관측이 열린다"는 그림이에요.

Langfuse에서 보이는 것들

연결이 되면 Langfuse 대시보드에서 이런 정보를 볼 수 있어요.

Trace 워터폴: 사용자가 채팅 메시지를 보내면, Advisor chain의 각 단계가 타임라인으로 펼쳐져요. ChatMemory 조회에 12ms, LLM 호출에 850ms, PII 마스킹에 3ms — 병목이 어디인지 한눈에 보여요.

Generation 상세: LLM 호출 하나하나의 모델명, 토큰 수, 비용, 지연시간이 기록돼요. "이번 주 Gemini Flash 비용이 $12.30인데, 이미지 분석이 $8.70"처럼 기능별 비용을 바로 확인할 수 있어요.

프롬프트 버전 비교: SoulmateSystemPrompt.st v1과 v2를 같은 입력으로 돌려서, 어느 쪽 응답이 더 좋은지 Score로 비교해요.

💡 결론: Grafana는 숲(전체 시스템 건강)을 보고, Langfuse는 나무(개별 LLM 호출 품질)를 봐요. Day 22의 인프라 위에 OTLP 한 줄 추가하면 LLM 특화 관측이 열려요.

Spring AI Agent Utils

Day 14에서 @Tool로 날씨 검색, 캘린더 조회 같은 도구를 직접 만들었어요. 하나씩 구현하는 건 학습에 좋지만, 프로덕션 에이전트에 범용 도구를 매번 새로 짤 수는 없어요.

Spring AI Agent Utils는 spring-ai-community 프로젝트에서 개발 중인 재사용 가능한 도구 라이브러리예요. Claude Code의 도구 시스템에서 영감을 받았어요.

제공 도구 카테고리:

현재 0.7.0-SNAPSHOT 단계예요. 정식 릴리즈가 되면 build.gradle에 의존성 한 줄 추가로 에이전트에 범용 도구를 장착할 수 있어요.

// 정식 릴리즈 후 예상 형태
implementation 'org.springframework.ai:spring-ai-agent-utils:1.0.0'

Day 19 Harness 6구성요소를 떠올려보세요. 그 중 Tool Belt(에이전트가 사용하는 도구 집합)를 표준화한 것이 Agent Utils예요.

A2A 프로토콜 심화 — 에이전트가 팀으로 일하는 시대

Day 18에서 A2A(Agent-to-Agent) 프로토콜을 처음 만났어요. MCP가 도구 연결(Tool → AI)이라면, A2A는 에이전트 간 통신(AI ↔ AI)이라고 했죠.

팀 차원에서 A2A를 도입할 때 알아야 할 설계 포인트 3가지를 짚어볼게요.

1. Agent Card — 에이전트의 이력서

에이전트가 자신의 역량을 JSON으로 선언하는 것이 Agent Card예요.

{
  "name": "ai-friends-chat-agent",
  "description": "미연시 게임 캐릭터 대화 에이전트",
  "capabilities": [
    "text-chat",
    "image-analysis",
    "voice-synthesis"
  ],
  "endpoint": "https://ai-friends.example.com/a2a",
  "authentication": "oauth2"
}

다른 에이전트가 "이미지 분석을 해줄 수 있어?"라고 물으면, Agent Card의 capabilities를 보고 판단해요. 사람이 팀원의 역할을 파악하는 것과 같아요.

2. Secure Message Envelope — 에이전트 간 통신 보안

에이전트끼리 메시지를 주고받을 때, 세 가지 보안 계층이 필요해요.

3. 생태계 현황 (2026년 5월)

A2A는 빠르게 성장하고 있어요.

• 150+ 조직이 참여 (Google, Microsoft, Anthropic, Salesforce 등)
• Linux Foundation 산하 프로젝트로 거버넌스 확립
• Azure, AWS Bedrock에서 프로덕션 사례 공개
• MCP와 A2A는 경쟁이 아니라 상호보완: MCP는 도구 수준, A2A는 에이전트 수준

💡 결론: MCP가 개인 도구함이라면, A2A는 팀원 간 업무 위임 프로토콜이에요. 에이전트가 혼자 일하는 시대에서 팀으로 일하는 시대로 넘어가고 있어요.

ai-friends를 프로덕션에 배포한다고 가정해볼게요. Day 1부터 22까지 만든 부품들을 실제 서비스에 올릴 때 어떤 점을 챙겨야 하는지 정리해요.

프로바이더 폴백 전략

Day 2에서 application.yml 프로파일 한 줄로 프로바이더를 전환하는 법을 배웠어요. 프로덕션에서는 자동 폴백이 필요해요.

Primary: Gemini Flash (무료 티어)
  ↓ 장애 발생 (5xx / 타임아웃)
Fallback: Ollama 로컬 (또는 다른 프로바이더)

Day 20에서 만든 Resilience4j @CircuitBreaker가 이 역할을 해요. Primary 프로바이더가 3번 연속 실패하면 Circuit이 열리고, 자동으로 Fallback 프로바이더로 전환돼요.

⚠️ "프로바이더 하나에만 의존하면 장애 = 서비스 전체 다운이에요. 반드시 폴백을 준비하세요."

비용 관리

프로덕션에서는 일 예산과 월 ceiling을 따로 설정해요. 일 예산 초과는 경고, 월 ceiling 초과는 자동 throttling(응답 속도 제한)으로 비용 폭주를 방지해요.

API 키 관리

⚠️ .env 파일은 절대 git에 커밋하면 안 돼요. Day 1부터 .gitignore에 포함해둔 이유예요.

키 로테이션도 중요해요. 한 키를 영원히 쓰면 유출 시 피해가 커져요. 주기적으로 새 키를 발급하고, 이전 키를 폐기하는 zero-downtime 로테이션을 설정하세요.

프로덕션 배포 체크리스트

💡 결론: 이 체크리스트의 10개 항목은 Day 1부터 22까지 하나씩 쌓아온 부품이에요. 새로 만들 게 없어요 — 이미 가지고 있는 것을 프로덕션 수준으로 조이기만 하면 돼요.

릴리즈 일정

우리 강의는 Spring AI 1.1.x(Spring Boot 3.x 호환)로 진행했어요. Spring AI 2.0은 Spring Boot 4.0 기반의 메이저 업그레이드예요.

원래 5월 28일 GA로 예고되었지만, RC를 거쳐 6월 4일로 조정됐어요. RC1 이후로는 API가 동결되니까, RC1 기준으로 마이그레이션을 시작해도 안전해요.

기반 전환 — Big Picture

Jackson 3 패키지 변경이 가장 큰 영향이에요. com.fasterxml.jackson → tools.jackson으로 패키지가 바뀌었어요. 직접 Jackson 클래스를 import한 코드가 있다면 전부 수정해야 해요.

주요 변경 카테고리

1. ChatClient API 변경 (M7)

Tool calling이 자동 등록돼요. 이전에는 ToolCallAdvisor를 수동으로 추가했는데, 2.0에서는 tools를 설정하면 자동으로 등록돼요.

// 1.1.x — 수동 등록
chatClient.prompt("날씨 알려줘")
    .tools(weatherTool)
    .advisors(ToolCallAdvisor.builder().build())
    .call().content();

// 2.0 — 자동 등록
chatClient.prompt("날씨 알려줘")
    .tools(weatherTool)
    .call().content();

개별 tool 메서드도 통합됐어요.

// 1.1.x
chatClient.prompt()
    .toolCallbacks(myCallback)
    .toolContext(Map.of("tenantId", "acme"))
    .call().content();

// 2.0
chatClient.prompt()
    .tools(t -> t.callbacks(myCallback)
                  .context("tenantId", "acme"))
    .call().content();

2. ChatMemory 변경 (M6)

Conversation ID가 필수가 됐어요. DEFAULT_CONVERSATION_ID 상수가 삭제되었고, 매 호출마다 명시적으로 전달해야 해요.

// 1.1.x — 기본값 사용 가능
MessageChatMemoryAdvisor.builder(chatMemory)
    .conversationId("my-session")  // 선택적
    .build();

// 2.0 — 필수 전달
chatClient.prompt()
    .user("안녕!")
    .advisors(a -> a.param(
        ChatMemory.CONVERSATION_ID, "my-session"))
    .call().content();

PromptChatMemoryAdvisor도 삭제돼요. MessageChatMemoryAdvisor로 통합됐어요.

3. MCP 마이그레이션 (M3)

MCP 어노테이션이 Spring AI 본체로 흡수됐어요.

// 1.1.x (외부 라이브러리)
import org.springaicommunity.mcp.annotation.McpTool;

// 2.0 (Spring AI 내장)
import org.springframework.ai.mcp.annotation.McpTool;

MCP transport 모듈도 Spring AI로 이동했어요.

<!-- 1.1.x -->
<groupId>io.modelcontextprotocol.sdk</groupId>
<artifactId>mcp-spring-webflux</artifactId>

<!-- 2.0 -->
<groupId>org.springframework.ai</groupId>
<artifactId>mcp-spring-webflux</artifactId>

4. 설정 프로퍼티 변경 (M6)

.options. 세그먼트가 제거됐어요.

# 1.1.x
spring.ai.openai.chat.options.model: gpt-4
spring.ai.openai.chat.options.temperature: 0.7

# 2.0
spring.ai.openai.chat.model: gpt-4
spring.ai.openai.chat.temperature: 0.7

하위 호환을 위해 .options. 프로퍼티도 당분간 동작하지만, deprecated 경고가 뜰 거예요.

5. 모델 모듈 정리 (M3, M5)

• spring-ai-azure-openai 삭제 → spring-ai-openai로 통합 (Azure 배포 지원 내장)
• Anthropic: 자체 API 클래스 삭제 → 공식 Java SDK 사용
• OpenAI: 공식 openai-java SDK 전환

6. Observation 변경 (M6)

스팬 이름이 바뀌었어요.

1.1.x: tool_call <tool-name>
2.0:   execute_tool <tool-name>

Day 22에서 Grafana 대시보드를 만들었다면, 쿼리의 메트릭 이름을 업데이트해야 해요.

ai-friends 코드베이스 영향 분석 (요약)

코드베이스 365개 파일을 전수 분석한 결과예요.

이 중 일부는 RC1/GA에서 확정될 예정이에요. 다음 시간(Day 24)에서 이 변경점들을 직접 코드로 옮겨봐요.

OpenRewrite 자동 변환

Spring AI 팀이 OpenRewrite 레시피를 제공해요. MCP 패키지 이동 같은 반복적인 변환을 자동화할 수 있어요.

mvn org.openrewrite.maven:rewrite-maven-plugin:6.32.0:run \
  -Drewrite.activeRecipes=\
    org.springframework.ai.migration.MigrateToSpringAI200M3

자동 변환으로 커버되는 것(패키지 이동, import 정리)과 수동 보정이 필요한 것(ChatMemory ID 필수화, Tool API 통합)이 있어요. Day 24에서 둘 다 경험해봐요.

💡 결론: 1.1.x로 배운 원리는 2.0에서도 그대로 살아 있어요. API 이름이 바뀌고 패키지가 이동했을 뿐, ChatClient + Advisor + ChatMemory + RAG 구조는 동일해요.

다음 시간에 직접 코드를 옮기면서 확인해봐요.

23일 동안 ai-friends가 어떻게 변했는지, 큰 그림으로 돌아봐요.

Phase별 축 정리

Before / After — Day 0 vs Day 23

Day 0: 기존 ai-friends (RestClient 기반)

사용자 → AiChatController
           → GeminiService
             └── RestClient로 Gemini API 직접 호출
             └── String.formatted()로 프롬프트 조립
             └── 수동 JSON 파싱
           → ChatLog 엔티티
             └── 수동 DB 조회로 대화 기록

기능: 텍스트 대화만. Gemini에 묶여 있고, 대화 기록은 수동 관리.

Day 23: 완성된 ai-friends (Spring AI 기반)

사용자 → ChatClient
           → Advisor Chain
             ├── MessageChatMemoryAdvisor
             │     └── JdbcChatMemoryRepository
             ├── RetrievalAugmentationAdvisor
             │     └── PgVectorStore
             ├── ToolCallAdvisor
             │     └── @Tool 함수들
             ├── UsageTrackingMeterAdvisor
             │     └── Micrometer → Prometheus
             ├── AuditLoggingAdvisor
             │     └── AuditLog DB
             └── PiiMaskingAdvisor
           → ChatModel (프로바이더 독립)
             → Gemini / Ollama / OpenAI...
           → Cost Guardrail
             └── Bucket4j + Redis + Resilience4j
           → Observability
             └── Prometheus + Grafana

기능: 텍스트 + 이미지 + 음성 + 비디오. 프로바이더 독립. 영속 메모리. RAG 검색. 도구 사용. 에이전트 패턴. 비용 관리. 관측 인프라.

축별 Before / After 비교

학습 곡선에서 인상 깊었을 순간들

돌이켜보면, 몇 가지 순간이 기억에 남을 거예요.

Day 2 — application.yml 프로파일 한 줄 바꿔서 Gemini → Ollama로 프로바이더를 전환했을 때. "코드 한 줄 안 고치고 모델이 바뀐다"는 인터페이스 추상화의 위력을 체감한 순간이에요.

Day 5 — ChatMemory를 도입하고, 이전 대화가 자연스럽게 이어지는 걸 확인했을 때. "AI가 나를 기억한다"는 사용자 경험의 전환점이에요.

Day 11 — @Tool 하나 등록했더니 AI가 날씨를 검색하는 걸 봤을 때. "AI가 외부 세계와 상호작용한다"는 에이전트의 시작점이에요.

Day 14 — 가드레일 없는 에이전트가 폭주하는 걸 시연했을 때. "자율성에는 반드시 안전 장치가 필요하다"는 교훈이에요.

Day 15 — 첫 RAG에서 "AI가 내 문서를 읽고 답변한다"를 확인했을 때. 일반 대화를 넘어 도메인 특화 AI로 가는 첫걸음이에요.

Day 22 — Grafana 대시보드에 실시간 메트릭이 올라가는 걸 봤을 때. "코드를 짜는 것"에서 "운영하는 것"으로 시야가 넓어진 순간이에요.

💡 결론: 23일 동안 ai-friends는 "RestClient + 수동 파싱 덩어리"에서 "ChatClient + Advisors + ChatMemory + RAG + Tools + Harness + Observability의 레이어드 구조"로 진화했어요.

여러분이 만든 거예요.

Day 24 예고

다음 시간에 ai-friends를 Spring AI 2.0으로 실제 마이그레이션해요.

• build.gradle 버전 올리기 (Spring Boot 4.0 + Spring AI 2.0)
• OpenRewrite 자동 변환 실행
• 수동 보정 (ChatMemory ID 필수화, Tool API 통합 등)
• ./gradlew test 전체 Green 달성

Step 5에서 정리한 마이그레이션 포인트를 직접 코드로 옮기는 시간이에요. RC1(6/1) 또는 GA(6/4)가 나온 시점에 진행하면 가장 정확해요.

이 강의 이후 학습 방향

Spring AI의 기본기는 충분히 쌓았어요. 여기서 더 나아가고 싶다면 이런 방향이 있어요.

1. Spring AI 공식 리소스

• Spring AI Reference Documentation — 공식 문서
• Spring AI Examples — 공식 예제
• Spring AI Blog 시리즈 — Agentic Patterns, Best Practices

2. 커뮤니티 참여

• spring-ai-community — Agent Utils, MCP Annotations 등 커뮤니티 프로젝트
• GitHub Discussions — 질문과 아이디어 공유
• Spring One / AI Conference — 연간 컨퍼런스

3. 심화 학습

• Agentic Patterns 심화 — Alibaba Graph (LangGraph의 Java 구현) 참고
• LLM Ops 전문 과정 — Langfuse / LangSmith 깊이 있는 활용
• MLOps + LLMOps 통합 — 모델 파인튜닝 + 서빙 + 모니터링 파이프라인

4. AI 엔지니어 커리어

2026년 현재, "AI 엔지니어"라는 역할이 빠르게 자리잡고 있어요. 기존 백엔드 개발자와 다른 점은 이런 것들이에요.

여러분은 이미 Spring Boot 백엔드 위에 Spring AI를 올려 에이전트를 만들고, Harness로 감싸고, Observability를 구축하는 경험을 했어요. 이 경험이 AI 엔지니어의 출발점이에요.

마지막으로

Day 1에서 RestClient로 Gemini를 호출하고 "Hello, AI"를 받아본 그 순간부터 여기까지 왔어요. 23일 동안 쌓은 건 코드만이 아니에요. LLM 앱을 설계하고, 구현하고, 운영하는 감각이에요.

Spring AI의 원리를 이해하고 있으니, 프레임워크가 바뀌어도 적응할 수 있어요. 2.0이 나와도, 새로운 프레임워크가 나와도 밑바닥의 ChatModel + Memory + Tools + RAG + Harness 구조는 동일해요.

다음 시간에 2.0 마이그레이션을 함께 해봐요. 마지막까지 함께해 주셔서 고마워요.

오늘 Day 23에서 다룬 내용을 정리할게요.

Day 24로 이어지는 다리

오늘 Step 5에서 정리한 마이그레이션 포인트를 다음 시간에 직접 코드로 옮겨요. build.gradle 버전 올리기부터 OpenRewrite 자동 변환, 수동 보정, 전체 테스트 Green까지 함께 합니다.