컨테이너는 기본적으로 휘발성이다. docker rm으로 컨테이너를 삭제하는 순간, 내부에 기록된 모든 데이터도 함께 사라진다. 데이터베이스나 업로드 파일처럼 영구적으로 보존해야 하는 데이터를 다룰 때는 별도의 스토리지 전략이 필요하다. Docker는 이 문제를 해결하기 위해 세 가지 마운트 방식을 제공한다.
Docker 컨테이너의 파일시스템은 Union File System 위에서 동작한다. 컨테이너 레이어는 이미지 레이어 위에 쌓이는 얇은 쓰기 가능 레이어이며, 컨테이너가 제거되면 이 레이어도 함께 삭제된다.
[ Container Layer ] ← 쓰기 발생 (삭제 시 소멸)
[ Image Layer 3 ]
[ Image Layer 2 ] ← 읽기 전용
[ Image Layer 1 ]
| 방식 | 저장 위치 | 관리 주체 | 주요 용도 |
|---|---|---|---|
| Named Volume | Docker 관리 영역 | Docker | DB, 앱 데이터 영속화 |
| Bind Mount | 호스트 경로 직접 지정 | 사용자 | 개발 환경, 소스 코드 동기화 |
| tmpfs Mount | 호스트 메모리 | Docker | 민감 정보, 임시 캐시 |
Named Volume은 Docker가 직접 관리하는 스토리지다. 호스트 경로를 몰라도 되고, 컨테이너 간 공유도 간단하다.
# Volume 생성
docker volume create mydata
# Volume 목록 확인
docker volume ls
# 컨테이너에 마운트
docker run -d \
-v mydata:/var/lib/postgresql/data \
postgres:16
# Volume 상세 정보
docker volume inspect mydata
# 사용하지 않는 Volume 정리
docker volume rm mydata
docker volume prune
docker volume prune — 어떤 컨테이너에도 연결되지 않은 모든 Volume을 일괄 삭제한다.
컨테이너를 삭제(docker rm)해도 Volume은 남는다. 새 컨테이너를 같은 Volume에 연결하면 데이터가 그대로 복원된다.
Bind Mount는 호스트의 특정 디렉터리를 컨테이너 내부로 직접 연결한다. 개발 중 소스 코드를 컨테이너에 실시간 반영할 때 주로 사용한다.
docker run -d \
-v $(pwd)/app:/usr/src/app \
node:20
호스트 컨테이너
/home/user/app → /usr/src/app
↕ 실시간 양방향 동기화
호스트 경로가 존재하지 않으면 Docker가 자동으로 디렉터리를 생성한다. 운영 환경에서는 예측하지 못한 호스트 경로 의존성이 생기므로 Named Volume을 선호한다.
tmpfs Mount는 호스트 메모리에만 데이터를 기록하며, 컨테이너가 중지되면 즉시 삭제된다. 디스크에 남으면 안 되는 세션 토큰이나 임시 연산 결과에 적합하다.
docker run -d \
--tmpfs /run/secrets:rw,size=64m \
myapp
services:
db:
image: postgres:16
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
top-level volumes 블록 — Compose 파일 최상위에 선언된 Volume은 docker compose down으로 서비스를 내려도 삭제되지 않는다. docker compose down -v를 써야 함께 제거된다.
Named Volume은 데이터 영속성이 필요한 모든 상황의 기본 선택이다. Bind Mount는 개발 편의를 위한 도구이고, tmpfs는 보안이 필요한 일시 데이터에만 한정해 사용한다.