Docker 컨테이너를 삭제해도 데이터를 보관하려면? 볼륨과 바인드 마운트

프로그램을 Docker로 실행한 뒤 파일을 업로드했다고 가정해 보겠습니다. 다음 배포에서 컨테이너를 새로 만들었더니 업로드 목록이 비어 있다면, 먼저 확인할 것은 이미지 버전보다 파일이 저장되던 위치입니다.

컨테이너의 실행 환경과 업무 데이터를 분리하면 컨테이너 교체 뒤에도 같은 데이터를 다시 연결할 수 있습니다. 이 글에서는 이름 있는 볼륨과 바인드 마운트의 차이, 간단한 재연결 예제, 데이터를 옮기기 전에 확인할 사항을 설명합니다.

1. 재시작과 삭제·재생성은 다릅니다

컨테이너 내부에서 생성한 파일은 별도 마운트가 없다면 해당 컨테이너의 쓰기 가능한 계층에 저장됩니다. 그 컨테이너를 삭제하면 이 계층도 함께 사라집니다. Docker의 저장소 안내는 컨테이너 계층과 외부 저장소를 구분해 설명합니다.

같은 컨테이너를 정지했다가 다시 시작하는 것과, 기존 컨테이너를 지우고 새 컨테이너를 만드는 것은 다른 작업입니다. “재시작해도 파일이 있었다”는 확인만으로 재배포 후 데이터 유지까지 검증했다고 보기는 어렵습니다.

직접 구성한 저장 구조 개념도. 컨테이너 안에서 보이는 경로와 실제 데이터를 보관하는 위치를 구분했습니다.

2. 두 방식 모두 컨테이너 밖의 저장소를 연결합니다

기준	이름 있는 볼륨	바인드 마운트
지정하는 대상	Docker가 관리하는 볼륨 이름	호스트의 특정 파일·폴더 경로
선택 예	애플리케이션이 지속적으로 쓰는 데이터	호스트에서 준비한 설정 파일이나 직접 관리하는 폴더
교체 후 확인	같은 볼륨 이름을 다시 연결했는지	같은 호스트 경로를 다시 연결했는지

볼륨은 Docker가 저장 위치를 관리하며 컨테이너 수명과 별개로 유지됩니다. 볼륨 내부 파일은 볼륨을 연결한 컨테이너를 통해 다루는 방식으로 계획하는 것이 좋습니다. Docker 볼륨 안내에서 생성과 연결, 수명주기를 확인할 수 있습니다.

바인드 마운트는 호스트의 경로를 직접 지정합니다. 설정 파일을 컨테이너에 제공하거나 호스트에서도 같은 파일을 관리할 때 유용합니다. 대신 다른 서버로 옮길 때 그 경로와 접근 권한도 준비해야 합니다. 바인드 마운트 공식 안내는 호스트 경로 의존성과 읽기 전용 옵션을 설명합니다.

3. 이름 있는 볼륨을 다시 연결하는 예제

아래는 Docker Engine 또는 Docker Desktop이 실행 중인 로컬 학습 환경을 위한 명령 예제입니다. macOS·Linux의 셸을 기준으로 작성했습니다. 실행 환경에서 직접 측정한 결과를 제시하는 것은 아니며, 동작을 확인하는 순서와 예상 결과를 설명합니다. 운영 데이터와 구분되는 새 볼륨 이름을 사용하세요.

먼저 학습용 볼륨을 만듭니다.

docker volume create tistory-volume-demo

첫 번째 임시 컨테이너에서 /data에 파일을 씁니다. alpine:3 이미지가 없다면 내려받기 때문에 인터넷 연결이 필요할 수 있습니다.

docker run --rm   --mount type=volume,source=tistory-volume-demo,target=/data   alpine:3 sh -c 'printf "%s\n" "volume-demo" > /data/hello.txt'

이 명령이 정상 종료되면 임시 컨테이너는 제거됩니다. 이어서 새로운 컨테이너에 같은 이름의 볼륨을 읽기 전용으로 연결해 파일을 확인합니다.

docker run --rm   --mount type=volume,source=tistory-volume-demo,target=/data,readonly   alpine:3 cat /data/hello.txt

앞 단계가 정상 수행되었다면 예상 출력은 volume-demo입니다. 확인하려는 것은 첫 컨테이너가 계속 살아 있는지가 아니라, 새 컨테이너가 같은 외부 저장소의 파일을 읽는지입니다. 여기서 --rm은 임시 컨테이너를 정리하며, 명시적으로 이름을 지정한 이 볼륨은 별도로 남습니다.

4. 바인드 마운트는 어떤 모습일까?

예를 들어 호스트에서 편집하는 설정 파일을 컨테이너의 설정 경로에 연결할 수 있습니다. 아래 표는 문법을 이해하기 위한 구조 예시이며 특정 프로그램의 완성된 실행 설정은 아닙니다.

호스트에서 준비한 대상	컨테이너가 보는 대상
설정 파일 한 개	프로그램이 읽는 설정 파일 경로, 읽기 전용 연결 검토
업로드 보관 폴더	프로그램의 업로드 저장 경로, 쓰기 권한 필요

컨테이너 경로만 보고 호스트 저장 위치를 추측하지 말고 실제 마운트 설정을 확인하세요. 특히 원격 Docker를 사용하면 기준은 명령을 입력하는 노트북이 아니라 Docker 데몬이 실행되는 호스트입니다. Docker Desktop은 가상머신과 호스트 경로 공유를 중간에서 처리하므로 일반 Linux 서버와 보이는 저장 위치가 다를 수 있습니다. 공식 문서의 호스트·Desktop 설명을 참고하세요.

5. Compose에서 데이터가 비어 보일 때

Compose에서 볼륨을 선언하는 것과 각 서비스에 연결하는 것은 각각 확인해야 합니다. 상위 volumes 항목에 이름만 적고 정작 데이터를 쓰는 서비스에 마운트하지 않았다면 의도한 보관 구조가 되지 않습니다. Compose 볼륨 문서는 선언과 서비스 연결을 구분합니다.

재배포 후 내용이 비어 보이면 다음 순서로 확인해 보세요.

1. 프로그램이 실제로 쓰는 디렉터리와 마운트 대상 경로가 일치하는지 확인합니다.
2. 기존 볼륨이나 호스트 폴더가 남아 있는지 확인합니다.
3. 새 컨테이너가 그 저장소를 연결했는지 확인합니다. Compose 프로젝트 이름이 바뀌면 다른 이름의 볼륨을 사용할 수 있습니다.
4. 파일 소유자·권한 때문에 읽거나 쓰지 못하는지 확인합니다.

빈 폴더를 기존 파일이 있던 경로 위에 마운트하면 원래 파일이 가려질 수도 있습니다. 따라서 “보이지 않는다”와 “삭제되었다”는 구분해서 확인해야 합니다. 이 동작은 기존 데이터 위에 바인드 마운트하는 경우에도 설명되어 있습니다.

6. 데이터 보관과 백업은 별도로 준비합니다

일반적인 docker compose down은 컨테이너와 네트워크를 정리하지만, -v 옵션을 붙이면 Compose에서 관리하는 이름 있는 볼륨과 연결된 익명 볼륨의 삭제까지 포함합니다. 외부 볼륨은 별도 규칙을 따릅니다. 실행하려는 명령의 범위는 Compose down 공식 안내와 사용 중인 버전의 도움말로 확인하세요.

볼륨이 남는 구조라도 파일을 잘못 덮어쓰거나 디스크가 고장 나면 데이터를 잃을 수 있습니다. 데이터베이스는 해당 제품이 지원하는 백업 방식을 사용하고, 파일은 복사 대상·주기·복구 위치를 정해 두세요. 업무에 쓰기 전에는 별도 위치에서 복구해 실제로 읽을 수 있는지도 확인하는 편이 좋습니다.

배포 전에 한 문장으로 답할 수 있으면 좋습니다. “이 컨테이너를 새로 만들면, 어느 저장소를 어떤 경로에 다시 연결할 것인가?” 답이 명확해야 컨테이너 교체와 데이터 보관을 함께 계획할 수 있습니다.

스트리밍 프로그램에서 설정과 업로드 파일을 나누어 보관하는 예는 MediaMTX 스트리밍 제어 서버 소개에서도 확인할 수 있습니다.

자료 확인일: 2026년 9월 6일. 명령은 학습용 예제이며 운영 서버의 저장 경로나 실제 데이터에 맞춘 배포 절차는 아닙니다.