동블

그래프 뷰

12. Production Readiness와 인프라 협업

6 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • Spring AI 기능 출시 전 production readiness checklist는 무엇인가?
  • 인프라팀은 AI 기능에서 어떤 운영 부담을 걱정하는가?
  • 개인 프로젝트와 기업 운영의 최소 기준은 어떻게 다른가?
  • prompt, model, index, tool, MCP 변경을 배포 자산으로 관리해야 하는 이유는 무엇인가?

개요

Spring AI 기능은 애플리케이션 코드만으로 끝나지 않는다. 외부 provider, secret, outbound network, vector DB, log volume, tracing, 비용, 개인정보, MCP server가 함께 생긴다.

인프라팀과의 협업은 “나중에 배포만 부탁”이 아니다. 설계 단계에서 egress, proxy, secret, backup, alert, rollback 기준을 맞춰야 한다.

원리

production readiness는 다음 축으로 본다.

  • Dependency: Spring Boot, Spring AI, provider starter 버전
  • Secret: API key 저장과 rotation
  • Network: provider endpoint, proxy, DNS, TLS, egress allowlist
  • Runtime: timeout, retry, rate limit, circuit breaker
  • Data: 개인정보, prompt log, retention, masking
  • RAG: vector DB backup, index rebuild, ACL sync
  • Tool/MCP: 인증, 인가, 감사 로그, 노출 범위
  • Deploy: prompt/model/index/tool schema rollback
  • Observability: metrics, logs, traces, alert

이 항목이 비어 있으면 기능은 동작해도 운영 준비가 부족하다.

실습

출시 전 체크리스트를 문서로 둔다.

record AiProductionChecklist(
        boolean secretManaged,
        boolean timeoutConfigured,
        boolean quotaConfigured,
        boolean promptVersionLogged,
        boolean modelProfileLogged,
        boolean piiMaskingEnabled,
        boolean evalGatePassed,
        boolean rollbackDocumented,
        boolean incidentRunbookReady
) {
    boolean ready() {
        return secretManaged
                && timeoutConfigured
                && quotaConfigured
                && promptVersionLogged
                && modelProfileLogged
                && piiMaskingEnabled
                && evalGatePassed
                && rollbackDocumented
                && incidentRunbookReady;
    }
}

배포 메타데이터도 기록한다.

record AiRelease(
        String applicationVersion,
        String promptVersion,
        String modelProfile,
        String indexVersion,
        String toolSchemaVersion,
        String mcpServerVersion
) {
}

성공 경로는 장애가 났을 때 어떤 release 조합이 문제였는지 바로 찾을 수 있는 것이다.

자주 나는 오류는 prompt만 바꿨으니 배포가 아니라고 생각하는 것이다. prompt 변경도 품질과 비용과 보안 결과를 바꾼다.

운영에서는 code release와 prompt/model/index release를 연결해 release note를 남긴다.

실전 판단

개인 프로젝트 최소 기준은 다음이다.

  • timeout
  • 하루 호출 제한
  • API key 환경 변수
  • structured output validation
  • 작은 eval set
  • prompt version 기록
  • 로그 원문 저장 금지 또는 local 한정
  • RAG index 재생성 절차

기업 운영 기준은 다음이 추가된다.

  • tenant별 quota와 비용 예산
  • 개인정보 처리 경계와 보존 정책
  • provider 장애 fallback
  • vector DB backup과 restore
  • MCP 노출 범위와 인증
  • audit log와 incident runbook
  • eval regression gate
  • 인프라 capacity와 log/trace 비용 관리

실전 팁

  • 인프라팀에게 “AI API 하나”가 아니라 “새 외부 의존성, 새 저장소, 새 로그 차원”이라고 설명한다.
  • vector DB는 애플리케이션 부속품이 아니라 운영 저장소로 다룬다.
  • prompt/model/index rollback 방법을 출시 전에 적는다.
  • MCP server는 네트워크 다이어그램에 포함한다.
  • quota와 비용 alert는 기능 출시 전부터 켠다.

위험 신호!

  • API key rotation 절차가 없다.
  • provider 장애 시 전체 API thread가 timeout까지 묶인다.
  • vector DB backup과 restore를 테스트하지 않았다.
  • prompt 원문 로그 보존 기간이 정해져 있지 않다.
  • 인프라팀이 MCP server의 존재를 모른다.
  • eval 없이 model profile을 바꾼다.

확인 질문

확인 질문

  • production readiness에서 code 외에 관리해야 할 배포 자산은 무엇인가?
    • prompt, model profile, index version, tool schema, MCP server version이다.
  • 인프라팀이 AI 기능에서 걱정하는 것은 무엇인가?
    • egress, secret, provider 장애, vector DB 운영, 로그 비용, tracing cardinality, backup, rollback이다.
  • 개인 프로젝트에서도 꼭 챙길 최소 기준은 무엇인가?
    • timeout, quota, secret 관리, validation, 작은 eval, prompt version, 로그 마스킹이다.
  • prompt 변경을 배포로 봐야 하는 이유는 무엇인가?
    • 품질, 비용, latency, 보안, fallback 결과가 바뀔 수 있기 때문이다.

학습 연결

참고 문서

관련 문서

백링크