빠른 비교

# bind mount — 호스트 경로를 그대로 마운트
docker run -v "$(pwd)/src":/app/src node:22-alpine

# named volume — Docker가 관리하는 전용 저장소
docker run -v pgdata:/var/lib/postgresql/data postgres:16

# tmpfs — 메모리 기반 임시 저장소
docker run --tmpfs /tmp:rw,size=64m my-app

갈리는 기준

어떤 저장소 방식을 먼저 떠올리면 되나

Volume — Docker가 관리하는 전용 스토리지를 써야 호스트 경로에 독립적이다

Volume은 Docker 엔진이 직접 생성하고 관리하는 저장소입니다. 호스트 파일시스템의 특정 경로(/home/user/data 같은)에 의존하지 않으므로, 같은 compose.yaml로 팀원 누구의 머신에서 실행해도 경로 충돌이 없습니다. docker volume ls로 목록을 보고, docker volume rm으로 삭제할 수 있습니다.

docker volume create pgdata
docker run -v pgdata:/var/lib/postgresql/data postgres:16

# 볼륨은 컨테이너를 삭제해도 남아 있음
docker rm -f db
docker volume ls  # pgdata 여전히 존재

Bind Mount — 호스트 파일시스템을 그대로 마운트해 소스 코드 핫리로드에 쓴다

Bind mount는 호스트의 특정 디렉터리를 컨테이너 안에 직접 연결합니다. 호스트에서 파일을 수정하면 컨테이너 안에 즉시 반영되므로, 개발 중 소스 코드 변경이 서버에 바로 적용되길 원할 때 적합합니다. 단, 경로가 머신마다 달라질 수 있어 이식성이 떨어집니다.

# 소스 코드를 컨테이너에 실시간 반영
docker run \
  -v "$(pwd)":/app \
  -w /app \
  node:22-alpine \
  npm run dev

tmpfs — 민감 데이터를 디스크에 남기지 않을 때는 메모리 기반 마운트를 쓴다

tmpfs는 컨테이너 메모리에만 존재하는 임시 마운트입니다. 컨테이너가 종료되면 내용이 사라지며, 디스크에 기록되지 않아 비밀 파일이나 캐시처럼 영속이 필요 없는 데이터에 적합합니다.

docker run --tmpfs /run/secrets:rw,noexec,nosuid,size=1m my-app

bind mount와 volume은 "누가 저장소를 관리하는가"가 다르다

bind mount는 호스트 경로를 그대로 연결하므로 개발 중 편하지만, 경로 의존성과 권한 문제가 바로 따라옵니다. volume은 Docker가 저장소 수명주기를 관리하므로 운영 데이터에 더 안정적입니다. 실시간 코드 반영이 목적이면 bind mount, 데이터 보존과 이식성이 목적이면 volume으로 먼저 생각하면 실수가 줄어듭니다.

선택 기준

주의할 점

docker run -v "$(pwd)/data":/var/lib/postgresql/data postgres:16

# 팀원마다 $(pwd)가 다르면 같은 compose/run 명령이라도
# 실제 데이터 위치와 권한 문제가 달라질 수 있음