딥러닝 미드레벨 배포·운영 기술면접

먼저 Alpine 또는 slim 계열의 경량 베이스 이미지를 사용하고, CUDA가 필요한 경우 nvidia/cuda의 runtime 태그를 사용합니다. Multi-stage build를 활용해 빌드 의존성과 런타임 의존성을 분리하고, 최종 이미지에는 필요한 파일만 복사합니다. pip 설치 시 --no-cache-dir 옵션을 사용하고, 불필요한 개발 패키지는 제외합니다. 모델 가중치는 별도 볼륨이나 S3에서 로드하도록 분리하고, .dockerignore를 활용해 불필요한 파일이 컨텍스트에 포함되지 않도록 합니다. 레이어 캐싱을 고려해 자주 변경되지 않는 명령어를 상단에 배치합니다.

파이프라인은 크게 5단계로 구성합니다. 첫째, 코드 커밋 시 린팅과 유닛 테스트를 수행하는 검증 단계입니다. 둘째, 데이터 검증 및 전처리 파이프라인을 실행하는 데이터 준비 단계입니다. 셋째, 모델 학습을 실행하고 MLflow나 Weights&Biases에 메트릭을 로깅하는 학습 단계입니다. 넷째, 학습된 모델의 정확도, 추론 속도, 메모리 사용량 등을 검증하고 이전 버전과 비교하는 모델 검증 단계입니다. 다섯째, 검증을 통과한 모델을 컨테이너 이미지로 빌드하고 스테이징 환경에 배포한 후 A/B 테스트를 거쳐 프로덕션에 배포하는 배포 단계입니다.

딥러닝 서비스에서는 Blue-Green 배포를 선호합니다. Blue-Green은 전체 인프라를 복제해 새 버전을 배포하고 트래픽을 한 번에 전환하는 방식으로, 롤백이 즉각적이고 두 버전 간 비교 테스트가 용이합니다. 단점은 2배의 리소스가 필요하다는 점이지만, GPU 인스턴스처럼 모델 로딩 시간이 긴 경우 Rolling 배포보다 안정적입니다. Rolling 배포는 점진적으로 인스턴스를 교체하므로 리소스 효율적이지만, 딥러닝 모델은 초기화 시간이 길어 일부 인스턴스가 준비되지 않은 상태에서 트래픽을 받을 위험이 있습니다. 또한 서로 다른 모델 버전이 동시에 실행되어 예측 결과가 일관되지 않을 수 있습니다. 따라서 충분한 warm-up 시간과 헬스체크가 보장된다면 Rolling을, 빠른 롤백과 일관성이 중요하다면 Blue-Green을 선택합니다.

모니터링 메트릭은 세 가지 레이어로 구분됩니다. 인프라 레이어에서는 GPU/CPU 사용률, 메모리 사용량, 추론 지연시간(latency), 처리량(throughput)을 모니터링해 리소스 병목을 감지합니다. 모델 성능 레이어에서는 예측 신뢰도 분포, 입력 데이터 분포(data drift), 예측 결과 분포(prediction drift)를 추적해 모델 품질 저하를 조기에 발견합니다. 비즈니스 레이어에서는 요청 성공률, 에러율, 타임아웃 비율을 모니터링해 서비스 가용성을 확인합니다. 특히 data drift는 재학습 시점을 결정하는 중요한 지표이며, 신뢰도가 낮은 예측이 증가하면 모델 성능 저하를 의심할 수 있습니다. Prometheus와 Grafana로 실시간 대시보드를 구성하고, 임계값 기반 알림을 설정합니다.

먼저 모니터링 대시보드에서 예측 신뢰도 분포, 에러율, 입력 데이터 분포를 확인해 정확도 저하가 실제인지 검증합니다. A/B 테스트 결과나 샘플 예측을 이전 버전과 비교 분석합니다. 문제가 확인되면 영향받는 사용자 범위와 비즈니스 임팩트를 평가합니다. 롤백 결정 시에는 이전 모델 버전의 가용성을 확인하고, 컨테이너 이미지 태그나 모델 레지스트리에서 안정 버전을 식별합니다. 롤백 후에는 헬스체크와 smoke test를 수행하고, 일부 트래픽으로 검증한 후 전체 트래픽을 전환합니다. 롤백 후에도 근본 원인 분석을 진행해 데이터 이슈인지, 모델 이슈인지, 전처리 파이프라인 문제인지 파악하고 재발을 방지합니다.

GPU 리소스 관리를 위해 먼저 nvidia-device-plugin을 설치하고, Pod에 resources.limits에 nvidia.com/gpu를 명시해 GPU를 할당합니다. GPU는 분할이 어려우므로 MIG(Multi-Instance GPU)나 time-slicing을 활용해 여러 Pod가 하나의 GPU를 공유하도록 설정할 수 있습니다. Node affinity와 taint/toleration을 사용해 GPU 노드에만 추론 Pod가 스케줄되도록 제한합니다. HPA(Horizontal Pod Autoscaler)는 GPU 메트릭 기반으로 설정하되, GPU 노드의 제한된 수량을 고려해 maxReplicas를 신중히 설정합니다. VPA는 GPU 리소스에는 적합하지 않으므로 사용하지 않습니다. PriorityClass를 설정해 추론 서비스가 배치 학습 작업보다 높은 우선순위를 갖도록 하고, preemption을 통해 리소스 경합 시 추론 서비스를 우선합니다.

모델 버전 관리는 MLflow Model Registry나 DVC를 사용해 각 모델에 버전 태그와 메타데이터를 부여합니다. 서빙 시에는 TorchServe나 TensorFlow Serving의 multi-model serving 기능을 활용하거나, 각 버전별로 별도 컨테이너를 배포합니다. API 레벨에서는 URL path(/v1/predict, /v2/predict) 또는 헤더 기반으로 버전을 구분하고, API Gateway나 Istio를 통해 트래픽을 라우팅합니다. 특정 사용자나 기능에 따라 다른 모델 버전을 제공해야 한다면 feature flag를 활용합니다. 각 모델 버전별로 성능 메트릭을 별도로 수집해 비교 분석하고, 구버전 deprecation 정책을 수립해 일정 기간 후 자동으로 제거되도록 합니다. 모델 메타데이터에는 학습 날짜, 데이터셋 버전, 성능 지표를 포함해 추적성을 확보합니다.

GitOps는 Git 저장소를 single source of truth로 사용해 인프라와 애플리케이션 상태를 선언적으로 관리하는 방식입니다. ArgoCD나 Flux를 사용해 Git의 Kubernetes manifest 변경을 감지하고 클러스터에 자동으로 동기화합니다. 딥러닝 배포 시에는 모델 가중치 파일은 Git에 저장하지 않고, manifest에는 모델 버전 참조(S3 경로, 레지스트리 태그)만 포함합니다. Helm chart나 Kustomize로 환경별 설정을 관리하고, 모델 학습 파이프라인이 완료되면 CI에서 새 모델 버전으로 manifest를 업데이트하는 PR을 자동 생성합니다. PR 리뷰와 머지를 통해 변경 이력과 승인 프로세스를 Git에 기록하고, 롤백 시에는 Git revert로 이전 상태로 복원합니다. 모니터링 도구와 연동해 배포 후 자동으로 헬스체크를 수행하고 실패 시 알림을 발송합니다.

인프라 레벨에서는 GPU 인스턴스 타입을 업그레이드하거나, 추론 전용 GPU(T4, A10)로 교체하고, dynamic batching을 활성화해 여러 요청을 묶어 처리합니다. 모델 레벨에서는 양자화(INT8, FP16)로 모델 크기와 연산량을 줄이고, TensorRT나 ONNX Runtime으로 최적화된 추론 엔진을 사용하며, pruning이나 knowledge distillation으로 경량 모델을 생성합니다. 코드 레벨에서는 전처리 파이프라인을 최적화하고, Redis나 Memcached로 반복적인 요청 결과를 캐싱하며, asyncio를 활용한 비동기 처리로 I/O 대기 시간을 줄입니다. 또한 multi-worker 설정으로 병렬 처리 성능을 높이고, warm-up 요청으로 cold start를 방지합니다. 프로파일링 도구(NVIDIA Nsight, PyTorch Profiler)로 병목 구간을 식별하고 집중적으로 최적화합니다.

먼저 Prometheus와 Grafana로 메모리 사용 패턴을 분석해 시간에 따른 증가 추세와 요청 수와의 상관관계를 확인합니다. Python memory_profiler나 py-spy로 메모리 프로파일링을 수행해 메모리를 많이 사용하는 객체와 함수를 식별합니다. 메모리 누수가 의심되면 캐시나 글로벌 변수에 데이터가 계속 쌓이는지, 텐서가 GPU 메모리에서 해제되지 않는지 확인합니다. Kubernetes의 resources.limits.memory를 적절히 설정하고, OOMKilled 발생 시 즉시 알림을 받도록 구성합니다. 해결책으로는 배치 크기를 줄이고, torch.cuda.empty_cache()로 명시적 메모리 해제를 수행하며, 요청 처리 후 불필요한 텐서를 del로 삭제합니다. 근본적으로는 메모리 효율적인 모델 아키텍처로 변경하거나, mixed precision 추론을 활용하고, 주기적으로 Pod를 재시작하는 임시 방편도 고려합니다. 해결 후에는 부하 테스트로 메모리 안정성을 검증합니다.