이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
머신러닝 모델 서빙 환경을 구성할 때 가장 먼저 선택한 것은 추론 API 방식이었습니다. REST API로 감싸면 호출 클라이언트가 모델 구현에 독립적으로 동작할 수 있어, 모델이 교체되거나 업데이트돼도 클라이언트 코드 변경이 최소화됐습니다.
모델 버저닝도 중요한 운영 과제였습니다. 새 모델이 기존 모델보다 항상 낫다는 보장이 없기 때문에, 이전 버전으로 롤백할 수 있는 구조를 유지했습니다. 모델 파일을 버전 태그와 함께 레지스트리에 저장하고 배포 시 버전을 명시하는 방식을 사용했습니다.
추론 지연 최적화도 담당했습니다. 배치 추론과 단건 추론을 분리해 대기 시간에 민감한 요청은 단건으로, 지연이 허용되는 경우는 배치로 처리했습니다. 모델 양자화와 ONNX 변환을 적용해 응답 속도를 줄이면서도 정확도 손실을 최소화했습니다.
ML 서빙 경험에서 아직 충분히 다뤄보지 못한 영역이 있습니다. 직접 구성한 환경은 단일 서버 기반 REST API 수준이었는데, 대규모 트래픽에서 GPU 클러스터를 운영하거나 동적 배치를 튜닝하는 경험은 없습니다. Triton Inference Server나 vLLM처럼 고처리량 서빙 프레임워크를 실제 서비스 레벨에서 운영해본 적이 없어서, P99 레이턴시나 GPU 활용률을 어떻게 관측하고 조정하는지는 공부 중입니다.
Prometheus/Grafana로 추론 메트릭을 수집하는 구조는 이론으로 알고 있고, 사이드 프로젝트에서 적용해보는 중입니다. 내가 경험한 것의 범위를 정직하게 알고, 모르는 부분을 빠르게 파악하고 채우는 것이 더 중요하다고 생각합니다.
ML 모델 서빙에서 새 모델로 전환할 때 가장 어려운 부분은 기존 서비스를 멈추지 않으면서 교체하는 것이었습니다. 단순히 모델 파일을 교체하면 추론 결과가 갑자기 달라져 사용자에게 영향이 즉각 퍼집니다. 이를 막기 위해 카나리 방식으로 트래픽 5%를 새 모델로 먼저 라우팅하고, 기존 모델과 새 모델의 예측 분포를 비교했습니다.
MLflow로 두 버전의 메트릭을 나란히 저장하니, 새 모델의 정확도 분포가 특정 입력 범위에서 기존 모델보다 오히려 낮아지는 케이스를 배포 전에 잡을 수 있었습니다. 롤백도 버전 태그를 바꾸는 것으로 30초 안에 가능했습니다. 모델 서빙에서 배포 속도보다 안전한 전환이 먼저라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.