이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대학원 연구실에서 모델 학습·배포 과정이 수동이라 재현이 어렵다는 문제를 해결하려고 간단한 파이프라인을 만들어보기로 했습니다. 처음엔 스크립트 몇 개로 연결하면 될 것 같았는데, 환경이 달라지면 같은 코드인데 결과가 다르게 나오는 문제가 생겼습니다. 의존성 버전 충돌이 원인이었습니다. 그래서 컨테이너로 환경을 고정하는 방식을 도입했습니다. 학습 단계를 컨테이너 이미지로 묶고, 로컬과 서버에서 같은 이미지로 실행하도록 구성했습니다. 처음엔 이미지 크기가 너무 커서 빌드 시간이 10분 이상 걸렸습니다. 레이어 구조를 정리하고 불필요한 패키지를 제거했더니 3분대로 줄었습니다. 완전한 MLOps 구축은 아니었지만, 재현 가능성의 첫 단계로 컨테이너 환경이 얼마나 중요한지 이 경험으로 알게 됐습니다.
졸업 프로젝트에서 모델을 새로 학습할 때마다 이전 버전이 어디 있는지 찾기 어렵다는 문제가 팀에서 반복됐습니다. 제가 이 부분을 정리해보기로 했습니다. 처음엔 모델 파일 이름에 날짜를 붙이는 방식으로 시작했는데, 어떤 데이터로 학습했는지 나중에 파악이 안 되는 한계가 생겼습니다. 이후 학습 시마다 파라미터와 성능 지표, 데이터 버전을 함께 기록하는 간단한 로그 파일을 만들었습니다. 파일 하나에 텍스트로 쌓는 방식이었지만, 덕분에 3개월 전 모델이 왜 그 성능이었는지를 나중에 추적할 수 있었습니다. 팀원이 로그 형식이 일관되지 않다고 지적해서 템플릿을 정해두는 방식으로 바꿨습니다. 작은 구조부터 잡아가는 경험이었고, 실무에서 MLOps 도구를 쓸 때 이 구조의 이유를 이해하는 데 도움이 됐습니다.
개인 사이드 프로젝트에서 학습한 모델을 API로 서빙하는 구조를 처음 만들어봤습니다. 처음엔 그냥 서버에 올리면 되겠다고 생각했는데, 요청이 동시에 여러 개 오면 응답 시간이 크게 늘어나는 문제가 생겼습니다. 모델 추론이 단일 스레드로만 동작하고 있었습니다. 워커를 여러 개 띄우는 방식으로 바꿨더니 처리량이 올라갔지만, 메모리 사용량도 그만큼 늘어서 서버가 버티지 못하는 상황이 생겼습니다. 워커 수를 줄이고 모델 가중치를 공유해 메모리 사용을 줄이는 구조로 바꿨습니다. 작은 서버에서 실험하며 자원 제약 안에서 성능과 안정성을 저울질하는 과정을 직접 경험했습니다. 쿠버네티스 같은 오케스트레이션 도구가 왜 필요한지 이 경험에서 처음으로 이해하게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 MLOps 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.