이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 작품으로 이미지 분류 모델을 서빙하는 API 서버를 만들었는데, 첫 요청이 항상 3초가 넘었습니다. 두 번째부터는 빠른데 첫 요청만 느렸습니다.
모델이 첫 요청 시 메모리에 로드되는 구조였습니다. 서버 시작 시 모델을 미리 로드해 두는 방식으로 바꾸니 첫 응답도 200ms 이내가 됐습니다. 메모리 사용이 늘었지만 서빙 응답성이 더 중요한 상황이었습니다.
실패도 있었습니다. 배치 크기를 1로 고정해 요청이 몰릴 때 처리량이 낮은 문제가 있었습니다. 동적 배칭을 도입해 짧은 시간 내 들어온 요청을 묶어 처리하는 방식으로 개선했습니다. AI 모델 서빙에서는 모델 로딩 전략과 배칭 설계가 응답성에 가장 큰 영향을 준다는 걸 그때 배웠습니다.
인턴 때 감성 분석 모델 서빙 서버에서 모델을 교체할 때 서버를 재시작해야 했고, 재시작 동안 API가 30초간 중단되는 문제가 있었습니다.
새 모델을 별도 경로에 로드한 뒤 준비되면 포인터만 교체하는 방식으로 바꿨습니다. 이전 모델은 진행 중인 요청이 끝날 때까지 유지하다가 자동으로 해제했습니다. 이후 모델 교체 시 서비스 중단 없이 전환됐습니다.
처음엔 두 모델이 동시에 메모리에 올라가는 것을 걱정했는데, 교체 시간이 짧아 실제 오버헤드는 미미했습니다. AI 모델 서빙에서 무중단 배포를 설계할 때는 모델을 코드가 아닌 데이터처럼 취급해야 한다는 것이 그때 배운 기준입니다.
팀 프로젝트에서 텍스트 생성 모델 API 서빙 중 특정 입력에서 모델이 무한 루프에 빠져 워커 전체가 멈추는 사고가 있었습니다.
추론 요청에 타임아웃을 설정하고, 타임아웃 초과 시 에러 응답을 반환하도록 했습니다. 워커 프로세스를 별도로 두어 추론 오류가 API 서버 프로세스에 영향을 주지 않도록 격리했습니다.
실패 경험은 타임아웃을 너무 짧게 설정해 정상 긴 입력에서도 타임아웃이 발생한 것입니다. 입력 길이에 따라 동적으로 타임아웃을 조정하는 방식으로 개선했습니다. AI 모델 서빙에서 안정성은 추론 오류를 격리하는 구조에서 나온다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.