이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모델 성능 평가 프로젝트에서 단순 정확도만 보면 현장 요구와 다르다는 것을 초반에 겪었습니다. 정밀도, 재현율, F1 스코어를 함께 보는 방향으로 바꿨고, 어떤 오류가 더 비싼지를 기준으로 가중치를 달리 설정하였습니다. 벤치마크는 실제 서비스 데이터 분포를 반영한 테스트셋을 별도로 구성하였습니다.
훈련 데이터와 비슷한 테스트셋으로는 편향된 평가가 나온다는 것을 직접 확인하였고, 그 이후로는 항상 분포를 먼저 점검하게 되었습니다. 결과 해석에서도 수치보다 어떤 경우에 틀리는지를 분석하는 것이 더 유용하였습니다. 오류 패턴 분석이 다음 개선 방향을 결정하더라고요. 성능 평가는 숫자를 내는 것이 아니라 방향을 정하는 도구라고 생각하게 되었습니다.
졸업 프로젝트에서 텍스트 분류 모델을 만들었는데, 테스트 정확도는 높았지만 실제 데이터에서 성능이 뚝 떨어졌어요. 원인을 찾다 보니 훈련/테스트 분할이 동일 소스에서 나와서 분포가 동일했고, 실제 입력은 다른 스타일이었습니다. 도메인 시프트라는 개념을 그때 처음 실감했어요. 이후 외부 데이터로 별도 검증 세트를 구성하고, 서로 다른 도메인에서 얼마나 잘 버티는지를 평가 항목에 넣었습니다. 수치가 낮아졌지만 실제 성능을 더 정확하게 반영하게 됐어요.
벤치마크는 실제 환경을 얼마나 잘 모사하는가가 핵심이라는 걸 배웠고, 그 이후로 평가 설계가 모델 설계만큼 중요하다고 생각하게 됐습니다. 좋은 평가가 좋은 모델을 만들어요.
인턴에서 이상 탐지 모델 성능을 평가할 때 정확도만 보면 이상 케이스가 거의 없어서 정상으로 예측해도 높게 나온다는 걸 알았어요. AUC-ROC와 Precision-Recall 곡선을 주요 지표로 바꾸니 실제 탐지 성능이 눈에 보이기 시작했습니다. 어떤 임계값에서 정밀도와 재현율이 교환되는지 분석하면서 운영 기준을 정했어요. 탐지 실패가 어느 쪽 오류인지에 따라 임계값 설정이 달라진다는 것도 배웠습니다.
지표 선택은 비즈니스 요구를 반영해야 한다는 걸 그때 처음 이해했어요. 단순히 숫자가 높은 모델이 아니라, 문제 맥락에 맞는 지표로 평가해야 실제로 쓸 수 있는 모델이 나온다는 걸 체감했습니다. 성능 평가는 모델이 아니라 문제에서 출발해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.