How DS and MLE Work Together

When the roles and responsibilities of DS (Data Scientist) and MLE (ML Engineer) are unclear in the process of deploying ML models to services, repeated time is spent aligning model code with the execution environment. Toss Bank solved this problem by improving the collaboration method three times over one year.

In Phase 0, when a DS handed over a model built in a Jupyter notebook to an MLE, the MLE would rewrite the serving code from scratch. As the process of exchanging libraries and configuration files needed for the model repeated, collaboration costs grew larger as the number of models increased.

In Phase 1, the boundary of collaboration was moved from between people to files. DS separated the core inference logic into a separate .py file, which had to pass MLE review and CI. Communication costs decreased, but since detailed rules such as file structure and global configuration changes were not defined, there remained a possibility of affecting other models in the serving environment.

In Phase 2, the standard for role division was defined as an interface. An abstraction class for models was created in the shared package commons-ml-model, and the preprocessing, inference, and postprocessing methods were established as the contract for model implementation.

DS builds a model implementing the interface into a single package, and MLE installs it via pip install to deploy it to the service. Instead of directly moving code, deployment happens through the package, and a common wrapper is configured to automatically leave logs, metrics, and traces, clearly defining the boundary between model development and serving.