이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 팀에서 매번 수동으로 스크립트를 실행하여 모델을 학습시키고 있었습니다. 실험 재현이 안 되는 문제가 반복되어, Kubeflow Pipelines로 전처리 → 학습 → 평가 단계를 컴포넌트로 분리하는 작업을 맡았습니다.
처음에는 컴포넌트 간 아티팩트 전달 방식을 잘못 이해하여, 학습된 모델 파일이 다음 단계에 넘어가지 않는 문제가 발생했습니다. output_path를 마운트된 볼륨 경로로 설정해야 하는데 로컬 경로로 잘못 설정한 것이 원인이었습니다.
수정을 한 후 파이프라인이 정상적으로 동작하였고, 실험 10개를 병렬로 실행할 수 있게 되었습니다. 실험 재현율도 향상되었으며, 팀에서는 이제 어떤 실험이 어떤 데이터로 진행되었는지를 추적할 수 있다는 긍정적인 피드백을 받았습니다.
졸업 프로젝트에서 작은 LLM 모델을 API로 서빙하다가, 더 나은 모델로 교체하려 했는데 그냥 컨테이너를 내리고 올리는 방식으로 했더니 30초 넘게 서비스가 끊겼어요.
이후 Kubernetes의 rolling update 전략을 쓰도록 바꿨는데, 문제는 모델 파일 크기가 3GB라 로딩에 20초가 걸렸고, 새 파드가 올라오기 전에 헬스체크가 실패해서 배포가 롤백되는 현상이 반복됐어요.
initialDelaySeconds를 늘리고, 모델 파일을 미리 캐시에 올려두는 init 컨테이너를 추가해서 해결했습니다. 모델 서빙은 일반 API와 다르게 시작 시간이 길어서 헬스체크 튜닝이 중요하다는 걸 이때 배웠어요.
Kubeflow를 직접 써본 경험은 없지만, 개인 프로젝트에서 BERT 기반 감성 분류 모델을 FastAPI로 서빙하고 Docker로 배포한 경험이 있어요.
그때 가장 힘들었던 건 모델 파일을 이미지에 넣으면 빌드 시간이 너무 길어지는 문제였어요. 결국 모델은 S3에 올리고 컨테이너 시작 시 내려받는 방식으로 바꿨는데, 환경별로 모델 버전을 다르게 가져가야 할 때 관리가 복잡해졌습니다.
Kubeflow의 모델 레지스트리나 KFServing 같은 도구가 이런 버전 관리를 편하게 해준다는 걸 이후 문서를 보고 알게 됐어요. **팀 규모가 커지면 이런 도구 없이는 실험과 배포가 뒤섞여 혼란이 생기겠다**고 느껴서, 기회가 되면 직접 써보고 싶어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.