ㅁ 배포 전략 특징 및 고려사항

1. Model-in-service vs Model-as-service

ㅇ 정의:
– Model-in-service: 모델이 애플리케이션 서비스 내부에 포함되어 함께 배포되는 방식
– Model-as-service: 모델이 독립된 서비스로 배포되어 API 형태로 호출되는 방식

ㅇ 특징:
– Model-in-service: 배포 단순, 네트워크 지연 적음, 서비스와 모델 버전 동기화 필요
– Model-as-service: 모델 독립 배포 가능, 확장성 용이, 네트워크 호출 지연 발생 가능

ㅇ 적합한 경우:
– Model-in-service: 모델 변경이 적고 서비스와 강하게 결합된 경우
– Model-as-service: 모델 업데이트가 잦고 여러 서비스에서 동일 모델을 활용하는 경우

ㅇ 시험 함정:
– Model-in-service가 항상 빠르다고 단정하면 오답 (네트워크 지연은 적지만 서비스 재배포 부담 있음)
– Model-as-service가 항상 느리다고 단정하면 오답 (캐싱, 로드밸런싱으로 지연 최소화 가능)

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “모델을 독립적으로 배포하여 여러 서비스가 공용으로 사용할 경우 Model-as-service가 적합하다.”
– X: “Model-in-service는 모델 업데이트 시 서비스 재배포가 필요 없다.”

2. 리소스 사용

ㅇ 정의:
– 모델 배포 시 CPU, GPU, 메모리, 스토리지 등 시스템 자원의 사용량과 효율을 관리하는 것

ㅇ 특징:
– 모델 크기, 추론 빈도, 동시 요청 수에 따라 자원 사용량 변동
– GPU 사용 시 비용 증가, 메모리 최적화 필요

ㅇ 적합한 경우:
– 제한된 환경에서는 경량화 모델 사용
– 대규모 실시간 추론 시 GPU 클러스터 활용

ㅇ 시험 함정:
– GPU 사용이 항상 성능 최적이라는 단정은 오답 (작은 모델은 CPU가 더 효율적일 수 있음)

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “대규모 동시 추론 처리에는 GPU 자원 활용이 효과적이다.”
– X: “모든 모델은 GPU에서만 최적 성능을 낸다.”

3. 확장성 관리

ㅇ 정의:
– 서비스 요청 증가에 따라 시스템을 수평 또는 수직으로 확장하는 전략과 관리 방법

ㅇ 특징:
– 수평 확장: 인스턴스 수를 늘려 부하 분산
– 수직 확장: 단일 인스턴스의 성능 향상
– 오토스케일링, 로드밸런싱, 컨테이너 오케스트레이션 기술 활용

ㅇ 적합한 경우:
– 예측 불가능한 트래픽 변동 → 오토스케일링
– 고성능 단일 작업 필요 → 수직 확장

ㅇ 시험 함정:
– 수평 확장이 항상 비용 효율적이라는 단정은 오답 (인스턴스 관리 비용 증가 가능)
– 수직 확장이 항상 성능 향상 보장하는 것은 아님 (하드웨어 한계 존재)

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “트래픽 증가에 대비해 컨테이너 기반 오토스케일링을 적용할 수 있다.”
– X: “수직 확장은 무한정 성능을 향상시킬 수 있다.”

ㅁ 추가 학습 내용

Model-in-service와 Model-as-service 비교 시 다음 내용을 학습하는 것이 중요하다.
보안 측면에서는 데이터 접근 제어, 인증과 인가 절차를 이해해야 하며, 네트워크 병목 현상이 발생할 가능성과 그 해결 방안을 고려해야 한다.
모델 버전 관리 전략으로는 블루-그린 배포와 카나리 배포 방식의 특징과 장단점을 숙지해야 한다.

리소스 사용 최적화를 위해 모델 경량화 기법인 양자화와 프루닝의 원리와 효과를 이해하고, 배치 추론과 스트리밍 추론의 차이점을 파악해야 한다. 또한 비용 절감을 위해 스팟 인스턴스 활용 방법을 알아두는 것이 좋다.

확장성 관리에서는 Kubernetes와 Docker Swarm 같은 컨테이너 오케스트레이션 도구의 자동 확장 정책을 이해하고, 무중단 배포를 위한 롤링 업데이트와 롤백 전략을 학습해야 한다. 멀티 리전 배포 시에는 지연 시간 관리 방법을 숙지하는 것이 필요하다.