이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 머신러닝 모델 설계 경험은 졸업 프로젝트에서 있었습니다. '대규모'라는 표현이 상대적이지만 수백만 행 데이터를 다루는 추천 모델을 설계하고 배포하는 과정이었습니다. 데이터 전처리 파이프라인, 피처 엔지니어링, 모델 학습, 서빙까지 엔드투엔드로 구현하면서 각 단계의 의존성을 관리하는 것이 가장 어려웠습니다. 특히 학습 데이터와 서빙 환경의 피처 분포 차이(training-serving skew) 문제를 처음 만났고, 피처 스토어 개념을 도입해 양쪽을 동일 소스로 통일하는 방식으로 해결했습니다. 앞으로도 ML 시스템을 설계할 때 모델 성능보다 파이프라인 안정성과 재현성을 먼저 고려하는 방식을 유지하겠습니다.
ML 시스템은 모델보다 파이프라인이 더 오래 살아있습니다. 앞으로도 ML 시스템을 설계할 때 모델 정확도보다 파이프라인의 재현성과 유지보수 가능성을 먼저 따지는 방식을 유지하겠습니다. ML 엔지니어링의 80%는 데이터와 파이프라인입니다.
텍스트 분류 프로젝트에서 사전학습 언어 모델을 파인튜닝하는 경험을 했습니다. 감성 분석 과제였는데, 처음에는 TF-IDF 기반 모델로 시작했다가 성능 한계를 느끼고 BERT 계열 모델로 전환하면서 파이프라인을 다시 설계했습니다. 가장 어려웠던 부분은 학습 데이터의 라벨 노이즈였습니다. 크롤링한 리뷰 데이터 중 긍정·부정이 섞인 문장이 많았는데, 그대로 학습시키면 모델이 경계 케이스에서 일관성을 잃었습니다.
불확실한 샘플을 제거하는 대신 soft label을 부여하는 방식을 택했고, 검증셋 F1이 약 4포인트 올랐습니다. 역할 분담은 제가 전처리 파이프라인과 파인튜닝 코드를 맡고, 팀원이 데이터 수집과 라벨링을 담당했습니다. 배포 단계에서는 추론 속도를 줄이기 위해 ONNX 변환 작업까지 직접 해봤습니다. 그 경험 이후 모델 선택보다 데이터 품질과 라벨 일관성이 성능에 더 큰 영향을 준다는 감각이 생겼습니다.
졸업 프로젝트에서 이미지 분류 모델을 만들었을 때, 학습까지는 빠르게 끝났지만 실제 서빙 환경에 올리는 과정에서 예상치 못한 문제들을 만났습니다. GPU 서버 없이 CPU만으로 응답해야 했는데, 기본 PyTorch 모델의 추론 지연이 요구 사양의 두 배 가까이 나왔습니다.
TorchScript 컴파일과 배치 사이즈 조정을 적용했고 지연을 절반 수준으로 줄였습니다. 그다음은 메모리 사용량이 점진적으로 늘어나는 문제였습니다. 프로파일링 도구로 추적한 결과, 텐서를 매 요청마다 새로 생성하면서 GC가 제때 처리하지 못하는 패턴을 발견했습니다.
텐서를 재사용하는 구조로 리팩토링하자 메모리 누수가 잡혔습니다. 이 경험에서 얻은 것은 ML 모델은 학습 성능과 서빙 성능이 별개라는 인식이었습니다. 모델을 만드는 시점부터 배포 환경의 제약을 함께 고려해야 한다는 것, 그리고 운영 중 발생하는 문제는 학습 코드보다 인프라 레이어에서 더 많이 나온다는 것을 직접 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.