Dependency Hell — "내 컴퓨터에선 되는데"

모든 엔지니어가 듣기 싫어하는 다섯 글자

"내 컴퓨터에선 되는데" — environment 가 깨졌다는 자백이지. 그리고 코드랑 상관없는 버그 잡느라 몇 시간 태워먹었다는 신호.

이게 학술적으론 dependency hell 이야. 앱은 Python 3.12 가 필요한데 staging 은 3.10. node_modules 는 macOS 랑 Linux 에서 다르게 깔려. libssl, libpq 버전이 호스트마다 떠다녀. 새로 들어온 사람은 환경 맞추는 데 이틀 써.

왜 비싸냐

엔지니어 시간 — 가장 비싼 자원 — 이 setup 재현에 새. feature 빌드에 안 가고.
온보딩 이 시간 단위에서 일 단위로 늘어. canonical environment 가 없으니까.
배포 실패 가 일상이 돼. CI 통과한 코드가 prod 에서 깨져 — 호스트 libc 가 다르거든.
롤백 이 무서워. 이전 환경을 정확히 재현 못 하니까.

Container 가 뭘 고치냐

Container 는 process, filesystem 가정, OS-level 의존성 을 artifact 하나 로 묶어. 같은 artifact 가 노트북에서 돌고, CI 에서 돌고, staging 에서 돌고, production 에서 돌아. 호스트 kernel 다른 거? 같은 artifact. 클라우드 다른 거? 같은 artifact. image 가 계약서 야.

편의 그 이상이야 — 이건 전달물 자체가 뭔지가 바뀐 거야. 이제 전달물은 "소스 코드 + 돌리는 법 wiki" 가 아니야. image 그 자체 야.

Code

전형적인 환경 분기·bash

# Your laptop
python --version
# Python 3.12.2

# Staging server (set up 14 months ago)
ssh staging 'python --version'
# Python 3.10.7

# CI runner (default image)
echo 'python --version' | docker run --rm -i python:3.11-slim sh
# Python 3.11.10

# Three machines, three Pythons. The bug that 'only happens in staging'
# is almost always the gap between these lines.

같은 artifact, 세 호스트·bash

# Build once
docker build -t myapp:1.0 .

# Run on your laptop
docker run --rm myapp:1.0

# Run on staging (same image, pulled from registry)
ssh staging 'docker run --rm registry.example.com/myapp:1.0'

# Run in CI
# (CI just pulls and runs the same tag)

# All three executions use byte-identical layers.
# 'Works on my machine' becomes a nonsensical complaint.

Exercise

본인 머신의 진짜 프로젝트 하나 골라. 팀원이 새로 들어와서 돌리려면 깔아야 할 것들 다 적어봐: Python/Node 버전, OS 라이브러리, env var, 서비스 (Postgres, Redis), 도구 (ffmpeg, curl). 빈 노트북에서 온보딩 얼마나 걸려? 그리고 — 두 문장으로 — Dockerfile 이 그 리스트를 어떻게 대체할지 적어봐.