Docker 컨테이너의 데이터 유지 여부는 중지·재시작인지 삭제·재생성인지, 파일이 컨테이너 내부에 저장됐는지 볼륨에 저장됐는지에 따라 달라진다.
WSL Ubuntu에서 텍스트 파일로 세 가지 동작을 확인했다. 컨테이너 내부 파일은 중지·재시작 후 유지됐지만 삭제·재생성 후에는 소실됐다. 같은 볼륨을 마운트한 새 컨테이너에서는 기존 파일을 조회할 수 있었다.
1. Docker Desktop 실행 상태와 WSL 연동 확인#
Windows의 Docker Desktop과 WSL Ubuntu를 연동한 환경에서 진행했다. Docker Desktop은 4.94.0, Docker Engine은 29.8.2이며, 컨테이너 이미지는 alpine:3.22를 사용했다. 설치가 필요하다면 Docker Desktop 설치와 WSL 연동부터 진행한다.
이후 명령은 모두 WSL Ubuntu 터미널에서 실행한다. Compose 파일이나 별도 스크립트는 필요 없다.
처음 docker version을 실행했을 때는 다음 오류가 표시됐다.
The command 'docker' could not be found in this WSL 2 distro.Windows에서 Docker Desktop이 실행 중인지 먼저 확인한다. Docker Desktop이 실행되지 않았거나 해당 Ubuntu 배포판의 WSL 연동이 비활성화되어 있으면, WSL에서 Docker 명령을 찾지 못하거나 엔진 연결 오류가 발생할 수 있다. 위 메시지만으로 어느 설정이 원인인지 확정할 수는 없다.
Docker Desktop을 열고 하단에 Engine running이 표시되는지 확인한다. 계속 오류가 나면 Settings → Resources → WSL integration에서 사용할 Ubuntu를 활성화하고 설정을 적용한다. Docker의 WSL 연동 안내
오류가 계속된다면 WSL 2에서 docker 명령을 찾지 못할 때의 점검 순서를 참고한다.
WSL에서 다시 실행한다.
docker version
Client와 Server 정보가 모두 출력되면 실습을 진행한다. Client만 출력되고 Server 연결이 실패한다면 아직 엔진에 연결되지 않은 상태다.
기존 실습과 충돌하지 않도록 아래 컨테이너·볼륨 이름을 사용한다. 같은 이름의 리소스가 이미 있다면 용도를 확인하고 다른 이름으로 바꾼다.
docker ps -a --filter name=jinosoft-storage-
docker volume ls --filter name=jinosoft-storage-data2. 컨테이너 중지·재시작 시 데이터 유지 여부#
먼저 볼륨을 마운트하지 않은 컨테이너를 실행하고 /data/note.txt를 생성한다.
docker run -d --name jinosoft-storage-layer alpine:3.22 sleep infinity
docker exec jinosoft-storage-layer sh -c 'mkdir -p /data; printf "container-only\n" > /data/note.txt'
docker exec jinosoft-storage-layer cat /data/note.txt-d는 백그라운드 실행, sleep infinity는 실습용 컨테이너가 바로 종료되지 않도록 대기하는 명령이다. docker exec는 실행 중인 컨테이너 안에서 명령을 수행한다. 처음 실행하면 Alpine 이미지 다운로드가 먼저 진행될 수 있다.
파일 내용으로 container-only가 출력되는지 확인한 뒤, 같은 컨테이너를 중지했다가 다시 시작한다.
docker stop jinosoft-storage-layer
docker start jinosoft-storage-layer
docker exec jinosoft-storage-layer cat /data/note.txt
재시작한 뒤에도 container-only가 출력됐다. docker stop은 컨테이너를 삭제하지 않으므로, 이 예제의 컨테이너 내부 파일은 그대로 남는다.
볼륨 미사용과 중지 시 데이터 소실은 같은 의미가 아니다. 이번 파일은 메모리 기반 tmpfs가 아니라 컨테이너의 디스크 기반 쓰기 계층에 저장됐다.
3. 컨테이너 삭제·재생성 시 데이터 소실 확인#
이번에는 컨테이너를 삭제하고, 동일한 이미지와 컨테이너 이름으로 재생성한다.
아래
docker rm -f는 지정한 실습용 컨테이너를 강제 종료하고 삭제한다. 실제 서비스 컨테이너에 그대로 적용하지 않는다. 운영 환경에서는 정상 종료와 필요한 데이터의 백업을 먼저 확인한다.
docker rm -f jinosoft-storage-layer
docker run -d --name jinosoft-storage-layer alpine:3.22 sleep infinity
docker exec jinosoft-storage-layer cat /data/note.txt
이번에는 다음 오류가 출력됐다.
cat: can't open '/data/note.txt': No such file or directory컨테이너 안에 새로 만든 파일은 기본적으로 해당 컨테이너의 **쓰기 계층(writable layer)**에 저장된다. 컨테이너를 삭제하면 이 계층도 삭제된다. 같은 이름을 다시 사용해도 새 컨테이너가 이전 파일을 이어받지는 않는다. Docker 저장 구조
실행 중 생성한 note.txt는 원본 alpine:3.22 이미지에 반영되지 않는다. 같은 이미지로 컨테이너를 재생성해도 이전 쓰기 계층은 복원되지 않는다.
4. 네임드 볼륨 마운트로 데이터 유지#
컨테이너 삭제·재생성 후에도 유지할 데이터는 쓰기 계층과 분리해 저장해야 한다. 여기서는 이름을 지정해 생성하는 **네임드 볼륨(named volume)**을 사용한다. 볼륨을 컨테이너의 특정 경로에서 사용할 수 있도록 연결하는 작업을 **마운트(mount)**라고 한다.
볼륨을 생성하고 컨테이너의 /data에 마운트한다.
docker volume create jinosoft-storage-data
docker run -d --name jinosoft-storage-volume \
--mount type=volume,source=jinosoft-storage-data,target=/data \
alpine:3.22 sleep infinitysource는 볼륨 이름, target은 컨테이너 내부의 마운트 경로다. 이제 /data에 기록하는 파일은 jinosoft-storage-data 볼륨에 저장된다.
docker exec jinosoft-storage-volume sh -c 'printf "saved-in-volume\n" > /data/note.txt'
docker exec jinosoft-storage-volume cat /data/note.txtsaved-in-volume이 출력되면 컨테이너를 삭제한다. 이후 동일한 볼륨을 마운트해 컨테이너를 재생성한다.
docker rm -f jinosoft-storage-volume
docker run -d --name jinosoft-storage-volume \
--mount type=volume,source=jinosoft-storage-data,target=/data \
alpine:3.22 sleep infinity
docker exec jinosoft-storage-volume cat /data/note.txt
새 컨테이너에서도 saved-in-volume이 출력됐다. 파일 생성 명령을 다시 실행하지 않았는데도 기존 데이터를 조회할 수 있었다. 컨테이너와 별도로 관리되는 네임드 볼륨은 컨테이너 삭제 후에도 유지됐기 때문이다. Docker 볼륨의 수명
컨테이너 이름은 달라도 된다. 데이터 재사용 조건은 동일한 Docker 엔진에서 동일한 볼륨을 마운트하는 것이다. 이 예제에서는 /data만 마운트했으므로, /tmp 등 마운트 경로 밖에 생성한 파일까지 유지되는 것은 아니다.
5. 네임드 볼륨과 바인드 마운트 비교#
호스트의 파일·디렉터리를 직접 지정해 마운트하려면 **바인드 마운트(bind mount)**를 사용한다.
| 구분 | 네임드 볼륨 | 바인드 마운트 |
|---|---|---|
| 마운트 대상 | Docker가 관리하는 볼륨 | 직접 지정한 호스트 파일·디렉터리 |
| 지정 예 | source=jinosoft-storage-data | source=/home/user/project |
| 주로 쓰는 경우 | DB 데이터 등 컨테이너와 분리해 보관할 데이터 | 호스트에서 편집하는 소스 코드·설정 파일 공유 |
| 컨테이너 삭제 후 | 볼륨을 별도로 삭제하지 않으면 유지 | 원본 호스트 파일을 삭제하지 않으면 유지 |
둘 다 컨테이너 밖의 저장소를 연결하지만, 볼륨은 Docker가 저장 위치를 관리하고 바인드 마운트는 사용자가 경로를 지정한다. 바인드 마운트를 기본 쓰기 가능 상태로 연결하면 컨테이너에서 호스트 파일을 수정하거나 삭제할 수도 있다. 설정 파일을 읽기만 해야 한다면 readonly 옵션을 검토한다. 바인드 마운트 공식 문서
이번 실습의 검증 대상은 네임드 볼륨이다. 바인드 마운트는 저장 경로 관리 방식과 사용 목적을 비교하기 위해 함께 정리했다.
6. 실습 리소스 삭제와 볼륨 관리 주의사항#
캡처와 확인이 끝나면 이번 실습용 컨테이너만 삭제한다. 아래는 정리가 필요할 때 실행하는 명령이며, 앞의 캡처에서 실행한 결과는 아니다.
docker rm -f jinosoft-storage-layer jinosoft-storage-volume컨테이너 삭제만으로는 jinosoft-storage-data 네임드 볼륨이 삭제되지 않는다. 테스트 파일도 더 이상 필요 없을 때만 아래 명령을 실행한다.
docker volume rm jinosoft-storage-data볼륨을 삭제하면 그 안의 파일도 삭제된다. 다른 프로젝트의 데이터까지 정리하지 않도록 전체 볼륨 삭제·정리 명령 대신 이름을 명시했다.
볼륨 삭제 옵션은 명령에 따라 적용 범위가 다르다. docker rm -v는 컨테이너에 연결된 익명 볼륨을 삭제하며 네임드 볼륨은 유지한다. 익명 볼륨은 사용자가 이름을 지정하지 않아 Docker가 임의의 이름을 부여한 볼륨이다. 반면 docker compose down -v는 Compose 파일에 선언된 네임드 볼륨도 삭제 대상으로 포함한다. Compose에서 external로 선언한 볼륨은 제외된다. 컨테이너 삭제 옵션, Compose down 옵션
볼륨은 컨테이너 재생성에 대비한 저장 방식이지 백업은 아니다. 볼륨 안에서 파일을 지우면 삭제가 반영되고, 저장 장치 장애나 Docker Desktop 데이터 초기화에도 대비해야 한다. 중요한 데이터는 별도 백업과 복구 확인이 필요하다.
마무리#
이번 실습에서는 중지·재시작 시 쓰기 계층 유지, 삭제·재생성 시 쓰기 계층 소실, 동일한 볼륨 마운트 시 기존 데이터 조회를 확인했다.
컨테이너를 교체할 때는 이름 재사용 여부가 아니라, 유지할 데이터 경로에 볼륨 또는 바인드 마운트가 설정되어 있는지 먼저 확인해야 한다.