이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 프로젝트에서 감정 분류 모델을 Flask API로 배포하면서 학습 환경과 서빙 환경 간의 불일치 문제를 처음 겪었습니다.
로컬에서는 잘 작동하던 모델이 서버에 올렸을 때 라이브러리 버전 차이로 예측값이 달라지는 문제가 생겼습니다. 원인 파악에 시간이 오래 걸렸고, `requirements.txt`로 버전을 고정하는 것만으로는 부족해서 `Docker`로 학습 환경 전체를 컨테이너화하는 방향으로 해결했습니다.
두 번째 어려움은 응답 속도였습니다. 추론 시간이 길어서 API 타임아웃이 발생했고, 모델 파일 로딩을 요청마다 하는 구조가 문제였습니다. 서버 시작 시 모델을 한 번만 메모리에 올려두는 방식으로 수정하니 응답 속도가 크게 줄었습니다. 모델을 만드는 것과 실제로 서빙되는 것이 전혀 다른 문제라는 것을 이 경험에서 배웠습니다.
졸업 프로젝트에서 감성 분류 모델을 배포한 뒤, 배포 초기에는 정확도가 괜찮았는데 두 달 후 같은 방식으로 평가했을 때 성능이 눈에 띄게 떨어져 있었습니다. 처음에는 코드 수정 중 버그가 생긴 줄 알았는데, 원인을 추적해 보니 입력 데이터의 분포 자체가 달라진 것이었습니다.
리뷰 텍스트의 길이 분포와 특정 단어 사용 빈도가 초기 학습 데이터와 달라졌고, 모델이 학습 당시의 패턴을 기준으로 판단하니 새로운 입력에 맞지 않는 결과가 나왔습니다. 이후 입력 데이터의 주요 통계값을 정기적으로 기록하고, 분포 변화가 임계값을 넘으면 알림을 받는 간단한 모니터링을 추가했습니다.
모델을 만들고 배포하는 것이 끝이 아니라 서비스가 동작하는 동안 데이터가 어떻게 바뀌는지를 지속적으로 보는 것이 배포 이후 단계에서 더 중요하다는 것을 이 경험에서 배웠습니다. 모델이 틀리기 시작하는 이유를 빠르게 찾을 수 있는 구조를 처음부터 갖춰두는 것이 나중에 대응 비용을 크게 줄입니다.
인턴 기간에 이미지 분류 모델을 REST API로 서빙하는 작업을 담당했는데, 처음 배포했을 때 요청 한 건 처리에 2~3초가 걸려서 실사용이 어려운 수준이었습니다. 로컬 테스트에서는 허용 범위라 생각했는데, 실제로 동시 요청이 들어오면 처리 대기가 쌓이는 문제가 생겼습니다.
원인을 분석해 보니 두 가지가 주된 병목이었습니다. 하나는 모델을 `float32`로 그대로 사용해 추론 연산량이 불필요하게 많았던 것이었고, 다른 하나는 단일 이미지 요청마다 독립적으로 처리하다 보니 GPU 활용률이 낮았습니다. `int8` 양자화로 모델 크기를 줄이고, 요청을 묶어 처리하는 배치 추론 방식으로 바꾸니 응답 속도가 절반 이하로 줄었습니다.
모델 성능 지표와 실제 서빙 환경에서의 속도는 완전히 다른 문제라는 것을 이 경험에서 배웠습니다. 정확도가 높아도 응답이 느리면 서비스에서 쓸 수 없고, 그 간격을 좁히는 것이 배포 이후의 핵심 과제라는 것을 처음 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.