컨테이너가 VM과 근본적으로 무엇이 다른지부터, 이미지 레이어 구조, Dockerfile·멀티 스테이지 빌드, BuildKit/buildx 멀티 플랫폼 빌드, 네트워크, 볼륨, Docker Compose, Docker Swarm 오케스트레이션, 컨테이너 보안·취약점 스캔까지 — Kubernetes로 넘어가기 전 반드시 다져야 할 Docker 실무 지식을 정리합니다.
컨테이너가 VM과 근본적으로 무엇이 다른지부터, 이미지 레이어 구조, Dockerfile·멀티 스테이지 빌드, BuildKit/buildx 멀티 플랫폼 빌드, 네트워크, 볼륨, Docker Compose, Docker Swarm 오케스트레이션, 컨테이너 보안·취약점 스캔까지 — Kubernetes로 넘어가기 전 반드시 다져야 할 Docker 실무 지식을 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
설치 명령을 외우기보다 트래픽, 런타임, 관측, 장애 대응이 어떤 순서로 이어지는지 파악합니다.
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 Docker를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
Docker를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
| 비교 항목 | VM | Container |
|---|---|---|
| 격리 단위 | OS 전체 (게스트 OS 포함) | 프로세스 (커널 공유) |
| 시작 속도 | 수십 초 ~ 수 분 | 1초 안팎 |
| 이미지 크기 | 보통 GB 단위 | 보통 MB 단위 |
| 밀도 | 서버당 수~수십 개 | 서버당 수십~수백 개 |
여기서는 설치을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# Docker Desktop (macOS/Windows): https://docker.com/get-started
# Linux — Docker Engine 설치
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER # sudo 없이 docker 명령 실행 (재로그인 필요)
docker --version
docker info # 데몬 연결 상태, 스토리지 드라이버 등 확인여기서는 기본 명령어와 컨테이너 생명주기을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
docker pull nginx # 이미지 다운로드
docker run -d -p 80:80 --name web nginx # 백그라운드 실행 + 이름 지정
docker ps # 실행 중인 컨테이너 목록
docker ps -a # 종료된 컨테이너까지 전체 목록
docker logs -f web # 로그 실시간 확인
docker exec -it web bash # 실행 중인 컨테이너 내부 접속
docker stop web # 정상 종료 (SIGTERM)
docker rm web # 컨테이너 삭제 (정지 상태여야 함)
docker rmi nginx # 이미지 삭제| 명령어 | 역할 |
|---|---|
| docker pull | 레지스트리(Docker Hub 등)에서 이미지를 내려받음 |
| docker run | 이미지로부터 컨테이너를 생성하고 시작 |
| docker stop / start | 실행 중인 컨테이너를 정지 / 정지된 컨테이너를 재시작 |
| docker rm / rmi | 컨테이너 삭제 / 이미지 삭제 |
여기서는 이미지와 레이어 구조을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
여기서는 Dockerfile 작성 & 멀티 스테이지 빌드을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# Stage 1: 빌드 전용 — devDependencies와 소스 전체 포함
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Stage 2: 실행 전용 — 빌드 결과물과 production 의존성만 복사
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]| 명령어 | 역할 |
|---|---|
| FROM | 베이스 이미지 지정 (AS로 스테이지 이름 부여 가능) |
| COPY --from=builder | 이전 스테이지의 결과물만 선택적으로 복사 |
| RUN | 이미지 빌드 시점에 한 번 실행 (레이어 생성) |
| CMD vs ENTRYPOINT | CMD는 실행 시 통째로 덮어쓰기 쉬움, ENTRYPOINT는 고정 실행파일 + CMD로 기본 인자만 전달할 때 사용 |
여기서는 BuildKit & buildx — 멀티 플랫폼 빌드을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# syntax=docker/dockerfile:1
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
# npm 캐시를 레이어가 아니라 별도 캐시 마운트에 보관 — 이미지 레이어에는 남지 않으면서
# 빌드마다 재사용되어, package.json이 바뀌어도 이미 받은 패키지는 다시 안 받음
RUN --mount=type=cache,target=/root/.npm \
npm ci
COPY . .
CMD ["node", "server.js"]# buildx 빌더 생성 & 활성화 (최초 1회)
docker buildx create --name multiarch --use
# 여러 아키텍처를 동시에 빌드해 레지스트리에 바로 push
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t myrepo/myapp:1.0.0 \
--push .
# 원격 캐시를 레지스트리에 저장 — CI 러너가 매번 새로 뜨는 환경에서도 캐시 재사용
docker buildx build \
--cache-to type=registry,ref=myrepo/myapp:buildcache \
--cache-from type=registry,ref=myrepo/myapp:buildcache \
-t myrepo/myapp:1.0.0 --push .| 기능 | 레거시 빌더 | BuildKit/buildx |
|---|---|---|
| 빌드 실행 방식 | 레이어를 순차적으로 하나씩 빌드 | 의존성 그래프를 분석해 무관한 단계를 병렬 실행 |
| 캐시 단위 | 레이어 전체 단위로만 캐시 | RUN --mount=type=cache로 특정 디렉토리만 세밀하게 캐시 |
| 시크릿 전달 | ARG/ENV로 전달 시 이미지 레이어에 흔적이 남을 위험 | --secret으로 전달 시 최종 이미지에 전혀 남지 않음 |
| 멀티 플랫폼 | 아키텍처별로 각각 빌드 후 수동으로 매니페스트 관리 | buildx build --platform으로 한 번에 빌드 + push |
여기서는 Docker 네트워크을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
| 네트워크 드라이버 | 용도 |
|---|---|
| bridge (기본값) | 같은 호스트 안 컨테이너 간 통신 — 대부분의 로컬/단일 서버 환경 |
| host | 컨테이너가 호스트의 네트워크를 그대로 사용 (포트 매핑 불필요, 격리 약화) |
| none | 네트워크 완전 비활성화 — 배치 작업 등 통신이 필요 없는 경우 |
| overlay | 여러 호스트에 걸친 컨테이너 통신 — Docker Swarm/멀티 호스트 환경 |
여기서는 볼륨과 데이터 영속성을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
| 방식 | 설명 | 주로 쓰는 곳 |
|---|---|---|
| Named Volume | Docker가 관리하는 저장 공간 (-v pgdata:/data) | DB, 애플리케이션 상태 등 컨테이너가 소유하는 데이터 |
| Bind Mount | 호스트의 특정 경로를 그대로 연결 (-v ./src:/app/src) | 로컬 개발 중 소스 코드 실시간 반영 |
| tmpfs | 메모리에만 저장, 컨테이너 종료 시 소멸 | 민감한 임시 데이터, 캐시 |
여기서는 Docker Compose로 다중 컨테이너 구성을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
services:
api:
build: .
ports: ["3000:3000"]
environment:
- DATABASE_URL=postgresql://user:pass@db:5432/mydb
depends_on:
db:
condition: service_healthy
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
POSTGRES_DB: mydb
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-U", "user"]
interval: 5s
retries: 5
volumes:
pgdata:여기서는 Docker Swarm — 아키텍처을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# 첫 번째 매니저 노드에서 클러스터 초기화
docker swarm init --advertise-addr 192.168.1.10
# 출력된 토큰으로 워커 노드를 클러스터에 합류
docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377
# 매니저를 추가로 합류시킬 때 쓰는 토큰은 별도 발급
docker swarm join-token manager
# 클러스터 노드 목록 & 역할 확인
docker node ls| 항목 | Manager | Worker |
|---|---|---|
| 역할 | 클러스터 상태 저장, 스케줄링 결정, API 응답 | 할당받은 태스크(컨테이너)만 실행 |
| 장애 허용 | N개 매니저 중 과반수(quorum)가 살아있어야 클러스터 동작 | 워커 하나가 죽어도 매니저가 다른 노드에 태스크 재배치 |
| 권장 대수 | 3, 5, 7대처럼 홀수 — (N-1)/2대까지 장애 허용 | 워크로드 양에 맞춰 자유롭게 증설 |
여기서는 Swarm 서비스 배포 & 롤링 업데이트을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# 서비스 생성 — 3개 복제본, 80번 포트로 클러스터 전체에 노출(ingress mesh)
docker service create --name web --replicas 3 -p 80:80 nginx:1.27
# 부하에 맞춰 즉시 스케일 조정
docker service scale web=6
# 이미지 롤링 업데이트 — 한 번에 1개씩, 10초 간격으로 순차 교체
docker service update \
--image nginx:1.28 \
--update-parallelism 1 \
--update-delay 10s \
--update-failure-action rollback \
web
# 방금 배포에 문제가 있으면 이전 버전으로 즉시 롤백
docker service rollback web
# 서비스 상태 & 태스크별 배치 노드 확인
docker service ps web| 플래그 | 의미 |
|---|---|
| --replicas | 유지할 태스크(컨테이너) 개수 — Swarm이 항상 이 수를 맞춰 자동 복구 |
| --update-parallelism | 한 번에 몇 개의 태스크를 동시에 교체할지 |
| --update-delay | 각 배치 교체 사이에 대기할 시간 — 헬스체크가 안정화될 시간을 확보 |
| --update-failure-action | 업데이트 실패 시 동작 (pause 또는 rollback) |
여기서는 Docker Stack & Swarm vs Kubernetes을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
services:
api:
image: myrepo/api:1.0.0
ports: ["80:3000"]
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
secrets:
- db_password
db:
image: postgres:16-alpine
deploy:
placement:
constraints: ["node.role == manager"] # 데이터는 특정 노드에 고정
secrets:
- db_password
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
external: true# 시크릿을 클러스터에 먼저 등록 (Git에는 값을 커밋하지 않음)
echo "s3cr3t" | docker secret create db_password -
# Compose 파일 그대로 Stack으로 배포
docker stack deploy -c docker-compose.yml myapp
docker stack services myapp # 서비스별 replica 상태
docker stack ps myapp # 태스크가 어느 노드에 배치됐는지| 비교 항목 | Docker Swarm | Kubernetes |
|---|---|---|
| 설치·학습 곡선 | Docker Engine에 내장 — 명령어 몇 개로 즉시 시작 | 별도 설치 필요, 개념(Pod·Service·Ingress 등)이 훨씬 많음 |
| 적합한 규모 | 노드 수십 대, 단순한 서비스 구성 | 노드 수백~수천 대, 복잡한 멀티팀 운영 |
| 생태계 | Compose 파일 재사용 가능, 생태계는 상대적으로 작음 | Helm·Operator·서비스 메시 등 압도적으로 큰 생태계 |
| 선택 기준 | 빠르게 띄우고 운영 부담을 최소화하고 싶을 때 | 확장성·세밀한 제어·업계 표준 도구 연동이 필요할 때 |
여기서는 컨테이너 보안 & 취약점 스캔을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# Docker Scout — 이미지 취약점 요약 확인 (Docker Desktop에 내장)
docker scout quickview myrepo/myapp:1.0.0
# CVE 상세 목록 (심각도별)
docker scout cves myrepo/myapp:1.0.0
# 베이스 이미지를 더 안전한 버전으로 바꿀 수 있는지 추천
docker scout recommendations myrepo/myapp:1.0.0
# CI 파이프라인에서: Critical/High 취약점이 있으면 빌드 실패 처리
docker scout cves --exit-code --only-severity critical,high myrepo/myapp:1.0.0| 항목 | 하지 말아야 할 것 | 대신 이렇게 |
|---|---|---|
| 실행 계정 | root로 그대로 실행 | Dockerfile에 USER 지정 (예: USER node) |
| 베이스 이미지 | 불필요하게 큰 풀 OS 이미지 | alpine, distroless 등 최소 이미지 |
| 시크릿 관리 | ENV나 Dockerfile ARG에 비밀번호 하드코딩 | Secrets Manager/환경변수 주입, --secret 빌드 옵션 |
| 이미지 취약점 | 검증 없이 배포 | docker scout, trivy 등으로 CI에서 스캔 |
이 섹션은 베스트 프랙티스을 실무 관점에서 정리합니다. 개념을 외우기보다, 어떤 상황에서 이 기준을 꺼내 쓸지에 초점을 맞춰보세요.
이 섹션은 다음 단계을 실무 관점에서 정리합니다. 개념을 외우기보다, 어떤 상황에서 이 기준을 꺼내 쓸지에 초점을 맞춰보세요.
Docker 실무 설계은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 결정 지점 | 확인 질문 | 실무 기준 |
|---|---|---|
| 경계 | Docker 코드에서 바뀌기 쉬운 부분은 어디인가? | 입출력, 설정, 외부 연동, 핵심 규칙을 분리합니다. |
| 상태 | 상태가 어디서 생성되고 어디서 사라지는가? | 상태 소유자와 수명 주기를 코드로 드러냅니다. |
| 장애 | 실패했을 때 호출자는 무엇을 받는가? | timeout, fallback, error contract를 먼저 정합니다. |
이 섹션은 Docker 운영 기준을 실무 관점에서 정리합니다. 개념을 외우기보다, 어떤 상황에서 이 기준을 꺼내 쓸지에 초점을 맞춰보세요.
Docker 검증 전략은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 품질 축 | 검증 방법 | 완료 기준 |
|---|---|---|
| 정확성 | 정상/실패 케이스를 자동화합니다. | 핵심 시나리오가 재현 가능하게 통과합니다. |
| 회귀 방지 | 버그 수정 시 동일 케이스를 테스트로 남깁니다. | 같은 장애가 다시 배포되지 않습니다. |
| 운영성 | 로그, 메트릭, 알림을 확인합니다. | 문제가 생겼을 때 원인 추적 경로가 있습니다. |