1What — 'Works on My Machine' 신드롬이란?
2- 데이터 사이언티스트가 Jupyter 노트북에서 완벽히 동작하는 모델을 서버에 배포하면 실패하는 현상
3- 원인은 환경 불일치: 로컬과 프로덕션 서버의 소프트웨어 스택이 다름
4- 비유: 집에서 완벽하게 만든 요리 레시피가, 다른 주방에 가면 오븐 온도 단위가 다르고(°F vs °C), 재료 브랜드가 다르고, 칼 종류가 달라서 맛이 완전히 달라지는 것과 같음
5ML 프로덕션에서 실제 실패하는 3가지 패턴
6- ① CUDA 버전 불일치: 로컬에서 CUDA 11.8 + PyTorch 2.0으로 학습했는데, 서버에는 CUDA 12.1이 설치 → GPU 연산 시 런타임 에러 또는 조용한 수치 오차 발생
7- ② 패키지 버전 충돌: 로컬 numpy 1.24에서 만든 .npy 파일을 서버의 numpy 1.21이 역직렬화 실패 → 모델 가중치 로드 불가. scikit-learn 버전이 다르면 pickle 모델 자체가 로드 안 됨
8- ③ 경로·환경변수 문제: 로컬에서 \texttt{/home/user/models/v2.pt}로 하드코딩한 경로가 서버에 없음. \texttt{PYTHONPATH}, \texttt{LD\_LIBRARY\_PATH} 등 환경변수 차이로 import 실패
9Why — 왜 이 문제가 ML에서 특히 치명적인가?
10- 전통 웹 앱은 언어 런타임 + 프레임워크 정도만 맞추면 되지만, ML은 OS → GPU 드라이버 → CUDA → cuDNN → Python → 프레임워크 → 모델 코드까지 7개 레이어가 정확히 맞아야 함
11- 버전 하나만 어긋나도 "조용한 실패"(silent failure)가 발생: 에러 없이 추론 정확도만 떨어져서 발견이 늦음 (Sculley et al., 2015)
12- ML 모델은 재현성이 핵심 — 학습 결과가 배포 환경에서 동일하게 나오지 않으면 모델 자체를 신뢰할 수 없음
13How — 컨테이너화가 해결하는 방법
14- 핵심 한 문장: Docker는 코드 + 런타임 + 라이브러리 + 시스템 설정을 하나의 이미지로 패키징하여, 어디서 실행하든 동일한 환경을 보장한다
15- 컨테이너 = "앱이 필요로 하는 모든 것을 담은 휴대용 주방". 오븐, 칼, 재료, 레시피가 전부 들어있어서 어떤 건물에 가져가도 동일한 요리가 나옴
16- VM과의 차이: VM은 건물 전체(OS 포함)를 복제하지만, 컨테이너는 주방만 복제 → 가볍고 빠름
17비즈니스 사례 — 대규모 전환의 이유
18- Netflix: 2015년 모놀리식 아키텍처에서 700+ 마이크로서비스 컨테이너로 전환. 배포 시간 수 시간 → 수 분으로 단축, 장애 격리로 전체 서비스 다운 방지 (Mauro, 2018)
19- Spotify: 수백 개의 ML 모델(추천, 검색, 광고)을 각각 독립 컨테이너로 배포. 팀마다 독립적으로 모델 업데이트 가능 → 배포 속도 10배 향상
20- 공통 패턴: 두 기업 모두 "개발 속도"와 "장애 격리"가 전환의 핵심 동기. 하나의 모델 업데이트가 다른 서비스에 영향을 주지 않는 구조
21핵심 정리
22- 환경 재현성 문제는 ML에서 단순 불편이 아니라 모델 신뢰성의 근본 위협
23- Docker 컨테이너화 = 환경을 코드로 정의(Infrastructure as Code)하여 "내 컴퓨터에서는 됩니다"를 "어디서든 됩니다"로 바꾸는 기술
24- Google 내부에서도 모든 워크로드를 컨테이너로 실행(Borg 시스템)하며, 이것이 Kubernetes의 기원 (Verma et al., 2015)