이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 스팸 분류 모델을 실 서비스에 연결해보면서 ML 서비스 배포의 복잡도를 처음 체감했습니다. 모델 정확도가 95%였어도 서비스에 붙인 뒤 실제 사용자 데이터에서 오분류 패턴이 다르게 나오는 문제가 생겼고, 오프라인과 온라인 지표를 별도로 추적하는 중요성을 배웠습니다. 비즈니스 성과를 측정하려고 스팸 신고율과 오탐으로 인한 정상 차단 건수를 지표로 정의했는데, 이 두 지표가 서로 트레이드오프 관계임을 분석 과정에서 알게 됐습니다.
ML 서비스는 모델 배포가 끝이 아니라 지표 모니터링 체계를 함께 설계해야 지속적으로 개선할 수 있다는 걸 이 경험에서 배웠습니다. 지금도 ML 기능을 추가할 때 어떤 비즈니스 지표를 개선하는가를 먼저 정의하는 방향을 따릅니다.
ML 서비스를 배포한 후 오탐과 정탐 사이의 트레이드오프를 어떤 기준으로 조정해야 하는지 판단이 어려웠습니다. 임계값을 높이면 오탐이 줄지만 실제 스팸을 놓치고, 낮추면 반대가 됩니다.
지도 교수님께 이 상황을 설명했더니 임계값은 기술적 판단이 아니라 서비스가 감수할 수 있는 오류 유형을 먼저 정의해야 한다는 것을 알려줬습니다. 스팸을 놓치는 것과 정상 메시지를 차단하는 것 중 어느 쪽이 사용자에게 더 나쁜 경험인지가 결정 기준이었습니다.
이 관점을 갖고 나서 서비스 특성상 정상 메시지 차단이 더 큰 불편이라는 결론을 내리고 임계값을 높이는 방향으로 조정했습니다. ML 서비스의 파라미터 조정은 기술 문제가 아니라 서비스 정책 문제이기도 하다는 것을 이 대화에서 처음 명확하게 이해했습니다.
ML 서비스를 배포하면서 가장 아쉬웠던 것은 배포 전 체크리스트가 없었다는 점입니다. 모델 정확도는 확인했지만 배포 환경에서 실제로 동작하는지, 비즈니스 지표와 어떻게 연결되는지는 사후에 확인하게 됐습니다.
이후 ML 서비스 배포 전에 확인할 것들을 목록으로 만들었습니다. 오프라인 평가 지표 확인, 배포 환경에서의 추론 지연 시간 측정, 비즈니스 지표 모니터링 설정 여부를 기본으로 포함했습니다. 배포 후 문제가 생겼을 때 롤백 방법도 미리 정해두는 항목을 추가했습니다.
이 체크리스트를 만든 이후 배포 후 예상치 못한 문제를 겪는 빈도가 줄었고, 문제가 생겼을 때 원인을 찾는 시간도 줄었습니다. ML 서비스는 코드 배포보다 데이터와 모델 동작을 함께 관리해야 해서 일반 서비스 배포보다 확인할 것이 많습니다. 배포 전 절차를 명시해두는 것이 이 복잡성을 다루는 가장 실용적인 방법이라는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.