"Docker가 필요한 이유"

## "내 컴퓨터에서는 됩니다"

개발자라면 누구나 겪는 상황:

```
개발자 A: "배포했는데 왜 에러나요?"
서버 담당: "로컬에선 잘 됐는데..."
개발자 A: "제 컴퓨터에서는 되는데요?"
```

원인은 대부분 **환경 불일치**:
- 로컬: Python 3.11, 서버: Python 3.8
- 로컬: macOS ARM, 서버: Linux x86
- 로컬에만 설치된 시스템 라이브러리

Docker는 이 문제를 **"환경 자체를 코드로 패키징"** 해서 해결한다.

---

## 컨테이너 철학: 불변 인프라

### 기존 방식 (Mutable)
```
서버 A ─── 설치 → 설정 → 패치 → 업그레이드 → ...
              ↑ 시간이 지날수록 "눈송이 서버" 발생
```

### 컨테이너 방식 (Immutable)
```
Dockerfile (코드) → 이미지 빌드 → 컨테이너 실행
                                   ↓ 문제 발생
                                 컨테이너 교체 (같은 이미지로)
```

한 번 빌드한 이미지는 **어디서 실행해도 동일**하게 동작한다.

---

## Docker가 해결하는 3가지

### 1. 환경 재현성
```dockerfile
FROM python:3.11.9-slim    # 버전까지 정확히 고정
```
"Python 3.11이 필요해" 수준이 아니라, OS 패키지까지 포함한 환경을 정확히 재현.

### 2. 격리
각 컨테이너는 독립된 파일시스템, 네트워크, 프로세스를 가진다. 여러 앱이 같은 서버에서 **충돌 없이** 공존.

```
서버 한 대
├── 컨테이너 A: Python 3.11, FastAPI
├── 컨테이너 B: Python 3.8, Django
└── 컨테이너 C: Node 20, Next.js
```

### 3. 이식성
```
로컬 맥북 → 팀원 윈도우 PC → CI 서버(Ubuntu) → 프로덕션(AWS EC2)
                    모두 동일한 이미지로 실행
```

---

## 이미지 ↔ 컨테이너 관계

```
클래스(이미지)  →  인스턴스(컨테이너)
    Dog         →     myCat = new Dog()
```

이미지 하나로 여러 컨테이너를 실행할 수 있다.

```bash
docker run -d -p 8001:8000 --name app1 myapp
docker run -d -p 8002:8000 --name app2 myapp
docker run -d -p 8003:8000 --name app3 myapp
# 같은 이미지, 3개 컨테이너
```

---

## 레이어 시스템

Docker 이미지는 **읽기 전용 레이어의 스택**이다.

```
레이어 4: COPY ./app /app         ← 자주 변경
레이어 3: RUN pip install ...     ← 가끔 변경
레이어 2: COPY requirements.txt . ← 가끔 변경
레이어 1: FROM python:3.11-slim   ← 거의 불변
```

하위 레이어가 변경되지 않으면 **캐시**를 재사용 → 빌드 시간 단축.

---

## 다음 단계

개념을 이해했다면, 실제 Dockerfile을 최적화하는 방법으로 넘어간다. 멀티 스테이지 빌드로 이미지 크기를 90% 줄이는 것도 가능하다.

"Docker가 필요한 이유"

// COMMENTS

ON THIS PAGE