PyTorch 리드·아키텍트 배포·운영 기술면접

먼저 모델 학습 완료 후 자동으로 트리거되는 검증 파이프라인을 구성합니다. 첫 단계는 모델 메트릭 검증(정확도, F1 등)과 추론 성능 벤치마크(latency, throughput)를 자동으로 수행하고, 기준치 미달 시 배포를 중단합니다. 두 번째로 스테이징 환경에서 shadow mode 테스트를 진행하여 실제 트래픽으로 추론 결과를 생성하되 응답에는 사용하지 않고 기존 모델과 비교 분석합니다. 세 번째로 카나리 배포를 통해 5-10% 트래픽에 먼저 적용하고, 에러율과 latency를 실시간 모니터링하며 임계치 초과 시 자동 롤백합니다. 네 번째로 점진적 롤아웃(25%, 50%, 100%)을 진행하며 각 단계마다 비즈니스 메트릭(CTR, conversion 등)을 추적합니다. 마지막으로 모든 배포 단계에서 모델 아티팩트의 버전 관리와 재현 가능성을 위해 DVC나 MLflow를 활용하고, 롤백 시 즉시 이전 버전으로 복원 가능하도록 구성합니다.

먼저 베이스 이미지를 ubuntu 대신 python:3.x-slim이나 distroless를 사용하여 기본 크기를 줄입니다. 멀티 스테이지 빌드에서 빌드 단계와 런타임 단계를 분리하고, 런타임에는 컴파일된 wheel 파일만 복사하여 gcc, build-essential 등 빌드 도구를 제거합니다. PyTorch의 경우 CPU 전용이면 torch-cpu 패키지를 사용하고, GPU 버전도 필요한 CUDA 버전만 포함된 이미지를 선택합니다. 모델 파일은 TorchScript나 ONNX로 변환하여 크기를 줄이고, 양자화(INT8)를 적용하면 모델 크기를 4배 가량 축소할 수 있으나 정확도 손실을 검증해야 합니다. 레이어 캐싱 최적화를 위해 자주 변경되지 않는 종속성 설치를 먼저 수행하고 애플리케이션 코드를 나중에 복사하며, .dockerignore를 활용해 불필요한 파일을 제외합니다. 추가로 모델 파일을 이미지에 포함하지 않고 S3나 모델 레지스트리에서 런타임에 다운로드하는 방식도 고려할 수 있으나, 컨테이너 시작 시간이 증가하는 트레이드오프가 있습니다.

먼저 Readiness Probe를 /health/ready 엔드포인트로 구성하여 모델 로딩이 완료되고 추론 준비가 된 시점에만 트래픽을 받도록 합니다. initialDelaySeconds를 모델 로딩 시간보다 충분히 길게(예: 180초) 설정하고 periodSeconds는 5초로 설정합니다. Liveness Probe는 /health/live로 분리하여 프로세스 자체의 생존만 확인하고, 모델 로딩 실패로 인한 재시작 루프를 방지합니다. PreStop Hook에서 SIGTERM 수신 시 즉시 종료하지 않고, 먼저 Readiness를 false로 변경하여 새 요청 수신을 중단하고, 현재 처리 중인 요청이 완료될 때까지 대기(예: 30초)한 후 graceful shutdown을 수행합니다. terminationGracePeriodSeconds를 충분히 길게(예: 60초) 설정하여 PreStop Hook 실행 시간을 보장합니다. Rolling Update 전략에서 maxSurge를 1-2로 설정하여 새 Pod가 완전히 준비된 후 기존 Pod를 종료하고, maxUnavailable을 0으로 설정하여 최소 용량을 유지합니다. 추가로 PodDisruptionBudget을 설정하여 동시에 종료되는 Pod 수를 제한하고, 로드밸런서(Ingress/Service)의 connection draining timeout을 적절히 설정합니다.

인프라 레벨에서는 Prometheus와 Grafana로 GPU/CPU 사용률, 메모리 사용량, 추론 latency(p50, p95, p99), throughput(RPS), 에러율을 추적하고, latency p99가 SLA 임계치의 80%를 초과하거나 에러율이 1%를 넘으면 즉시 알림을 발송합니다. 모델 레벨에서는 추론 결과의 confidence score 분포를 모니터링하여 평균 confidence가 급격히 하락하면 모델 성능 저하 신호로 간주하고, 주기적으로 validation set에 대한 정확도를 재평가합니다. Data Drift 감지를 위해 입력 feature의 통계적 분포(평균, 분산, 분위수)를 학습 시점 데이터와 비교하고, KL divergence나 Kolmogorov-Smirnov test를 활용해 분포 변화를 정량화합니다. Model Drift는 실제 레이블이 있는 경우 온라인 메트릭을 계산하고, 없는 경우 비즈니스 메트릭(CTR, conversion rate)의 변화를 추적합니다. 비즈니스 메트릭은 일별/주별 트렌드 분석과 이상치 탐지 알고리즘을 적용하여 통계적으로 유의미한 하락을 감지합니다. 모든 메트릭은 시간대별, 사용자 세그먼트별로 분해하여 특정 조건에서만 발생하는 문제를 식별할 수 있도록 하고, 알림은 심각도에 따라 Critical(즉시 대응), Warning(24시간 내 검토), Info(주간 리뷰)로 분류합니다.

먼저 영향 범위와 심각도를 정량화합니다. 해당 세그먼트의 트래픽 비중, 비즈니스 임팩트(매출 손실 등), 품질 저하 정도를 측정하고, 전체 사용자의 10% 미만이고 critical한 기능이 아니라면 부분 롤백을 고려합니다. 부분 롤백은 Istio나 트래픽 라우팅 규칙으로 특정 세그먼트만 이전 모델로 라우팅하고, 나머지는 새 모델을 유지하여 배포 이점을 보존합니다. 영향이 크거나 원인이 불명확하면 안전을 위해 전체 롤백을 수행하되, 롤백 후에도 문제가 지속되는지 확인하여 배포와 무관한 이슈일 가능성을 검증합니다. 빠른 롤백을 위해 평소 모든 모델 버전을 레지스트리에 보관하고, Blue-Green 배포 환경을 유지하여 트래픽 스위칭만으로 즉시 롤백 가능하도록 합니다. Kubernetes에서는 Deployment의 rollout history를 유지하고 kubectl rollout undo로 즉시 이전 버전으로 복원할 수 있도록 설정합니다. 자동 롤백을 위해 핵심 메트릭(에러율, latency, 비즈니스 메트릭)에 임계치를 설정하고, Flagger나 Argo Rollouts 같은 Progressive Delivery 도구로 자동으로 롤백되도록 구성합니다. 롤백 후에는 반드시 post-mortem을 수행하여 근본 원인을 분석하고, 재발 방지를 위한 테스트 케이스를 추가합니다.