이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
ML 모델을 양산에 올릴 때 Concept Drift가 가장 흔한 문제입니다. 학습 때와 운영 환경의 데이터 분포가 달라지면 모델 성능이 조용히 떨어지기 시작합니다. 대응 방법으로는 입력 데이터의 통계 분포를 주기적으로 비교하고, 모니터링 지표에 이상 신호가 생기면 재학습 파이프라인을 트리거하는 구조를 씁니다. 수업 프로젝트에서 간단한 Drift 감지 모듈을 직접 구현했는데, 기준 분포와 현재 분포의 KL divergence를 주기적으로 계산해서 경고를 내보내는 방식으로 만들었습니다. 배포가 끝이 아니라 운영 모니터링이 시작이라는 걸 그때 실감했습니다.
배포가 끝이 아니라 운영 모니터링이 시작입니다. Drift 감지와 재학습 파이프라인을 처음부터 설계에 포함하는 것이 ML 시스템의 신뢰성을 만든다고 생각합니다.
ML 모델을 양산에 올릴 때 Latency 문제는 Concept Drift와 다르게 배포 시점부터 바로 나타납니다. 추론 시간이 SLA를 넘으면 실시간 처리가 필요한 시스템에서는 모델 자체를 쓸 수 없게 됩니다. 대응 방향은 크게 두 가지입니다. 모델 구조를 경량화하는 것(양자화, pruning)과 서빙 인프라를 최적화하는 것입니다. 수업에서 같은 모델을 배치 크기와 하드웨어 조건을 바꿔가며 추론 속도를 측정하는 실험을 했는데, 배치 크기 하나가 처리량(throughput)과 지연(latency) 사이의 trade-off를 결정한다는 것을 수치로 확인했습니다. 신뢰성은 모델이 예측 불가능한 입력에서 안전하게 실패하는 구조를 갖추는 것이 핵심입니다.
모델이 틀리는 것보다 틀리는 방식을 예측할 수 없는 것이 더 큰 문제입니다.
수업 프로젝트에서 간단한 Drift 감지 모듈을 구현하면서 어떤 통계량을 기준으로 Drift를 정의하느냐에 따라 민감도가 크게 달라진다는 것을 경험했습니다. KL divergence를 쓰면 분포 차이를 수치로 잡을 수 있지만, 임계값을 어떻게 설정하느냐에 따라 오경보가 많거나 실제 Drift를 놓치는 경우가 생겼습니다.
임계값 설정 자체가 도메인 지식을 요구한다는 것이 가장 어려운 부분이었습니다. 해결 방향으로는 초기에 기준 분포를 여러 시점으로 나눠 저장하고, 그것을 기반으로 임계값을 시뮬레이션하는 방법이 실용적이라는 것을 찾았습니다. 배포가 끝이 아니라 운영 중 모니터링이 시작이라는 것을 그 프로젝트에서 처음 실감했고, 그 이후로 모델 개발 단계에서 모니터링 설계를 함께 고려하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.