이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 PyTorch 기반 모델 학습 파이프라인을 처음 구현해봤습니다. 데이터 로더부터 학습 루프·검증·체크포인트 저장까지 직접 작성하면서 각 단계가 어떻게 연결되는지를 깊이 이해할 수 있었습니다. TensorFlow는 이미 학습된 모델을 SavedModel 형식으로 저장하고 추론 서버에 올리는 방식을 실험해봤는데, 학습과 서빙 환경이 다를 때 발생하는 의존성 불일치를 직접 경험했습니다.
프레임워크 선택보다 데이터 전처리와 피처 일관성이 모델 품질에 더 큰 영향을 준다는 걸 배웠고, 학습 데이터와 서빙 데이터의 분포가 달라지지 않도록 하는 데 신경 쓰게 됐습니다. 지금도 모델 개발 시 학습 파이프라인과 서빙 파이프라인을 함께 설계하는 방향을 따릅니다.
PyTorch로 모델 학습 파이프라인을 구현하면서 이 도구가 모든 상황에 적합하지 않다는 것을 경험했습니다. 연구나 실험 단계에서는 PyTorch의 유연성이 강점이었는데, 모델을 서비스에 올리는 단계에서 학습 코드에 의존하지 않는 독립적인 서빙 환경이 필요했습니다. PyTorch로 학습한 모델을 그대로 서빙하면 학습용 의존성이 서버에도 필요했는데, 이것이 배포 크기와 관리 부담을 높였습니다. ONNX 형식으로 변환해서 서빙하는 방식을 시도했는데, 변환이 안 되는 연산이 있어서 모델 구조를 일부 수정해야 했습니다. 이 경험에서 PyTorch는 실험과 학습에 강점이 있지만, 서빙 환경을 고려하면 처음 설계 단계부터 변환 가능성을 확인하는 것이 중요하다는 것을 배웠습니다. 도구를 고를 때는 개발 편의성뿐 아니라 운영 환경의 제약도 함께 고려해야 한다는 것을 이 경험에서 배웠습니다.
대용량 데이터를 처리하는 과제에서 Spark ML을 처음 사용해봤습니다. 단일 머신에서 처리하기 어려운 크기의 데이터를 분산 처리할 수 있다는 점에서 Spark ML이 적합했습니다. 사용하면서 발견한 한계는 PyTorch나 scikit-learn에서 사용하던 일부 알고리즘이 Spark ML에서 지원되지 않거나, 동일한 알고리즘이라도 구현 방식의 차이로 결과가 달라지는 경우가 있다는 것이었습니다. 분산 환경에서 모든 데이터를 동일하게 처리하는 것이 단일 머신에서처럼 직관적이지 않았고, 파티션 분배 방식에 따라 결과가 달라질 수 있다는 것도 배웠습니다. Spark ML은 스케일 문제를 해결하는 데 강점이 있지만, 세밀한 알고리즘 제어나 특정 모델 유형에서는 제약이 있다는 것을 이 경험에서 배웠습니다. 어떤 도구를 쓸지 결정할 때 데이터 크기와 모델 복잡도, 운영 환경을 함께 고려해야 한다는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에이로봇 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.