이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
ML 시스템을 운영할 때 모델 성능이 배포 후 조용히 떨어지는 상황이 가장 위험하다고 생각합니다. 코드 오류처럼 눈에 보이지 않기 때문입니다. 저는 먼저 예측 분포를 실시간으로 추적하는 지표를 대시보드에 연결하는 것을 기본으로 두겠습니다. 입력 데이터의 분포가 훈련 때와 벌어지는 데이터 드리프트를 조기에 잡는 게 핵심이라고 보기 때문입니다.
KL divergence나 PSI 같은 지표를 임계값과 함께 걸어두면, 일정 수준 넘을 때 알림이 오게 할 수 있습니다. 그다음에는 재학습 트리거 조건을 문서화해두는 게 중요합니다. 어떤 상황에서 모델을 다시 돌릴지 기준이 없으면 판단이 사람마다 달라집니다. 저는 팀 내 기준이 없을 때 드리프트 임계값·재학습 주기·롤백 조건을 한 장짜리 문서로 정리한 적이 있고, 그게 팀 공통 기준이 됐습니다. 안정성은 도구보다 합의된 절차에서 나온다고 생각합니다.
ML 시스템의 운영 안정성을 위해 제가 가장 먼저 설계하는 것은 안전한 배포 파이프라인입니다. 새 모델이 프로덕션에 올라갈 때 무중단으로, 이전 버전으로 빠르게 롤백할 수 있는 구조가 없으면 장애가 생겼을 때 대응이 너무 느립니다. 운영 안정성 준비로는 CI/CD 파이프라인에 자동화된 모델 검증 단계를 포함시켜서, 지표가 기준 이하면 배포가 차단되도록 했습니다. 베스트 프랙티스 정의 과정으로는 Canary 배포나 Shadow 모드로 새 모델을 일부 트래픽에만 먼저 적용하고, 성능을 확인한 뒤 전체로 확대하는 방식을 표준화했습니다. 리스크 관리 방안으로는 모델 드리프트가 감지됐을 때 자동 재학습이 트리거되도록 파이프라인을 구성하되, 재학습 결과도 검증 통과 후에만 배포되도록 했습니다. 지속적인 모니터링으로는 MLflow로 모델 버전과 지표를 추적하고, Prometheus+Grafana로 예측 지연 시간과 에러율을 실시간 확인했습니다.
운영 안정성은 좋은 모델이 아니라, 좋은 배포 구조에서 나옵니다.
ML 시스템이 예상치 못하게 성능이 떨어지는 가장 흔한 원인은 모델이 아니라 입력 데이터의 변화입니다. 배포 이후 데이터 분포가 바뀌면, 학습 때와 다른 패턴에 대응하지 못해 성능이 낮아집니다. 운영 안정성 준비로는 입력 데이터의 통계적 특성(분포, 결측률, 이상값)을 지속적으로 모니터링하는 파이프라인을 설계했습니다. 베스트 프랙티스 정의 과정으로는 데이터 드리프트와 개념 드리프트를 구분해서, 각각 다른 대응 전략을 적용했습니다. 데이터 분포 변화가 감지되면 피처 중요도를 다시 확인하고, 개념 드리프트는 예측 오류율 추세로 감지했습니다. 리스크 관리 방안으로는 드리프트가 임계값을 초과하면 알림이 가고, 자동 재학습 여부를 판단하는 워크플로를 구성했습니다. 지속적인 모니터링으로는 예측 결과의 신뢰도 분포 추세를 관찰해서, 신뢰도가 낮은 예측 비율이 늘어나는 것도 경고 신호로 활용했습니다.
ML 시스템의 안정성은 출시가 아니라 운영 중에 계속 지켜야 하는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.