DS와 MLE가 함께 일하는 법

토스뱅크 ML 팀이 DS와 MLE 간 협업 방식을 1년 동안 세 단계에 걸쳐 개선한 과정을 다룬다. Jupyter 노트북 전달 방식에서 추상화 인터페이스 기반 패키지 계약으로 전환해 "첫 커밋 당일 배포"를 달성했다.

핵심 포인트

Phase 0: DS가 노트북을 통째로 MLE에게 전달하면 MLE가 서빙 코드를 처음부터 재작성했다. "노트북에서는 되는데 서빙에서 안 된다"가 반복됐다.
Phase 1: 추론 로직을 .py 파일로 분리했지만 인터페이스 표준이 없어 옮길 때마다 수정이 필요했다.
Phase 2: commons-ml-model 추상화 클래스로 DS는 pre_process/inference/post_process 구현에만 집중하고 MLE는 로그·메트릭·추적을 자동 처리한다. pip install 한 줄로 모델 배포가 가능해졌다.
모노레포(uv workspace)로 추상화 클래스와 모델 패키지를 함께 관리해 공통 라이브러리 수정이 전체 모델에 한 번에 반영된다.
AI 코드 작성 시대에는 역할 인터페이스 통일에 더해 코드 스타일 통일(pfmls-stylepack)이 새로운 협업 과제가 됐다.

상세 정리

Phase 0 문제: DS가 노트북을 통째로 MLE에게 넘기면 라이브러리·설정 파일이 흩어져 있어 "이 파일도 필요해요"를 며칠 동안 주고받았다. 모델이 5~6개로 늘자 감당이 안 됐다.
Phase 1 시도: 추론 로직을 .py 파일로 분리하고 MLE 리뷰·CI를 의무화했다. 소통 비용은 줄었지만 인터페이스가 predict/run/inference 등 제각각이라 옮길 때마다 수정이 남았다.
Phase 1 실패 사례: 한 모델이 공용 추론 라이브러리의 전역 설정을 변경하는 한 줄을 포함했다. 노트북에선 문제없었지만 여러 모델이 한 프로세스에서 실행되는 서빙에서는 다른 모델까지 영향을 받을 수 있었다.
Phase 2 설계: BaseInference 추상화 클래스의 run() 메서드가 trace_id 생성·타이머·로그를 자동 처리하고, DS가 구현하는 pre_process/inference/post_process를 호출한다.
역할 계약: DS는 3개 메서드만 구현해 패키지로 만들고, MLE는 pip install로 설치해 서비스에 올린다. 손으로 코드를 옮기는 과정이 사라졌다.
성과: 새 서비스 하나는 첫 커밋 당일 배포까지 마쳤다. 예전엔 "전달받아 맞추기"에만 며칠이 걸렸다.
모노레포(uv workspace): 추상화 클래스와 모델 패키지를 한 레포에서 관리해 공통 패키지 수정이 모든 모델에 한 번에 반영된다. poetry에서 uv로 전환해 빌드 속도 3~5배 개선했다.
pfmls-stylepack: AI 코드 작성이 늘면서 팀 컨벤션(네이밍, 예외 처리, enum 사용 기준)을 AI가 코드 생성 시 Hook으로 자동 준수하게 했다. 규칙 적용 위치에 이유를 명시해 리뷰어가 맥락을 바로 파악할 수 있다.
교훈: 구조가 너무 엄격하면 DS 커스터마이징이 어렵고 너무 느슨하면 다시 제각각이 된다. 공통 라이브러리는 하나만 고쳐도 전체 반영되는 양날의 검이다. AI와 협업하는 시대에는 구조 통일과 스타일 통일을 별개 과제로 다뤄야 한다.