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

  • cloud provider API와 self-hosted LLM은 어떤 기준으로 선택하는가?
  • hybrid 전략은 언제 유용한가?
  • self-hosted를 선택하면 인프라팀과 무엇을 준비해야 하는가?

개요

AI 모델 사용 방식은 크게 cloud provider API와 self-hosted serving으로 나눌 수 있다. 둘 다 장단점이 있다. 선택 기준은 유행이 아니라 요구사항이다.

Cloud Provider API

장점:

  • 빠른 도입
  • 최신 모델 접근
  • 운영 부담 감소
  • scaling 위임
  • 다양한 API 기능

주의점:

  • 외부 데이터 전송
  • provider 장애와 rate limit
  • 가격 변경
  • vendor lock-in
  • 데이터 정책 확인 필요

Self-hosted LLM

장점:

  • 데이터 통제
  • 모델과 serving 제어
  • 특정 비용 구조에서 유리할 수 있음
  • 내부망 배포 가능

주의점:

  • GPU 비용
  • model serving 운영
  • capacity planning
  • monitoring
  • rollback
  • 모델 업데이트 책임

Hybrid 전략

예시:

  • 일반 QA는 cloud API
  • 민감 문서 요약은 self-hosted
  • 개발자 로컬 실험은 Ollama
  • 대량 batch는 self-hosted
  • 고성능 reasoning은 cloud

hybrid는 유연하지만 routing과 observability가 복잡해진다.

코드로 이해하기

model_routing:
  public_summary:
    provider: cloud
    profile: fast-cheap
  sensitive_summary:
    provider: self_hosted
    profile: internal-llm
  high_risk_reasoning:
    provider: cloud
    profile: quality-reasoning

정책을 코드에 흩뿌리지 말고 routing config로 관리한다.

인프라 협업 포인트

self-hosted 준비 항목:

  • GPU 종류와 수량
  • model artifact 저장소
  • serving framework
  • autoscaling 여부
  • batching 설정
  • monitoring
  • model rollback
  • security patching

개인 프로젝트 최소 기준

로컬 모델은 실험에 좋다. 그러나 공개 서비스에 쓰려면 동시성, timeout, 리소스 제한, 보안을 검증해야 한다.

기업 운영 수준 기준

cloud와 self-hosted 모두 vendor/security review를 거친다. 특히 self-hosted는 인프라 운영 역량과 GPU 비용을 현실적으로 계산한다.

실전 팁

  • self-hosted가 항상 싸다고 가정하지 않는다.
  • cloud가 항상 위험하다고 가정하지 않는다.
  • hybrid는 routing trace를 잘 남긴다.
  • 민감 데이터 기준을 보안팀과 먼저 정한다.

위험 신호!

  • GPU 비용과 idle capacity를 계산하지 않는다.
  • local dev 성능으로 production 성능을 추정한다.
  • cloud provider 데이터 정책을 확인하지 않는다.
  • routing 이유가 문서화되어 있지 않다.

확인 질문

확인 질문

  • self-hosted LLM 선택의 핵심 조건은 무엇인가?
    • 데이터 통제 필요성, GPU 운영 역량, 비용 구조, latency, 규제 요구다.
  • hybrid 전략이 복잡해지는 이유는 무엇인가?
    • provider별 품질, 비용, latency, 관측성, 보안 정책을 모두 관리해야 하기 때문이다.

Spring AI 적용 연결

참고 문서