도커 컴포즈 볼륨 설정과 재배포 데이터 보존 확인법

Docker Compose로 서비스를 다시 올릴 때, 설정 파일보다 먼저 확인할 것은 데이터가 저장된 위치입니다. docker compose down과 볼륨 삭제 옵션의 차이, 이름 있는 볼륨과 호스트 폴더의 차이를 구분하면 재배포 전에 점검할 대상을 찾을 수 있습니다. 공식 문서를 바탕으로 데이터 보존 조건과 확인 순서를 정리합니다.

핵심 요약

일반 docker compose down은 이름 있는 볼륨을 기본적으로 삭제하지 않습니다.
--volumes 옵션을 붙이면 삭제 범위가 달라집니다. 재배포 명령과 데이터 초기화 명령을 구분하세요.
데이터가 남아 있는지와 새 컨테이너가 같은 데이터를 연결했는지는 별도 확인이 필요합니다.
재배포 전에는 저장 방식, 실제 볼륨 이름, 컨테이너 내부 경로, 백업을 함께 점검하세요.

저장 위치부터 구분하기

컨테이너의 쓰기 가능한 계층에만 저장한 파일은 그 컨테이너를 제거하면 사라집니다. Canonical의 Ubuntu 문서는 데이터를 유지할 방법으로 Docker가 관리하는 볼륨과 호스트 경로를 연결하는 바인드 마운트를 설명합니다. 앱이 만드는 데이터를 관리할지, 호스트에서 파일을 직접 다룰지에 따라 선택 기준을 잡을 수 있습니다.

저장 방식	무엇을 연결하나	재배포 전 확인할 것
이름 있는 볼륨	Docker가 이름으로 관리하는 저장소	실제 볼륨 이름과 연결 대상
바인드 마운트	호스트의 파일 또는 디렉터리	호스트 경로와 접근 권한
익명 볼륨	명시적인 이름을 지정하지 않은 볼륨	이후 실행에서 다시 연결되는지
컨테이너 쓰기 계층	해당 컨테이너 안의 변경 내용	보존할 데이터가 이곳에만 있는지

down과 볼륨 삭제 옵션은 구분하기

Docker의 명령 참조에서 일반 down의 기본 제거 대상은 서비스 컨테이너와 해당 네트워크입니다. 이름 있는 볼륨은 기본 삭제 대상이 아닙니다. 반면 -v 또는 --volumes를 지정하면 Compose 파일에 선언한 이름 있는 볼륨과 컨테이너에 연결된 익명 볼륨도 제거 대상에 포함됩니다.

익명 볼륨은 일반 down에서 남아 있어도, 다음 up이 자동으로 같은 볼륨을 다시 연결하지 않습니다. 따라서 “볼륨은 지우지 않았는데 앱이 처음 실행한 것처럼 보인다”면 삭제 여부와 연결 여부를 분리해 살펴봐야 합니다. 위 명령 참조도 업데이트 사이에 보존할 데이터에는 이름 있는 볼륨이나 명시적인 바인드 경로를 사용하도록 안내합니다.

볼륨 이름이 달라지는 경우 확인하기

Compose는 기본적으로 구성 파일이 있는 디렉터리의 이름에서 프로젝트 이름을 정합니다. 명령행의 -p, 환경 변수 COMPOSE_PROJECT_NAME, 구성 파일의 최상위 name 등으로 바꿀 수도 있습니다. 폴더를 옮기거나 실행 옵션을 바꿨다면 프로젝트 이름부터 비교하세요.

일반적인 Compose 볼륨에는 프로젝트 이름이 붙습니다. 볼륨의 name을 명시하면 지정한 이름을 그대로 사용합니다. 이 규칙을 고려하면, 재배포 후 빈 앱이 보일 때 기존 볼륨이 삭제됐다고 바로 판단하기보다 다른 이름의 볼륨을 연결했는지 먼저 확인하는 순서가 합리적입니다.

external: true는 이미 존재하는 볼륨을 Compose 앱 바깥에서 관리한다는 선언입니다. Compose는 그 볼륨을 새로 만들지 않으며, 없으면 오류를 반환합니다. down에서도 외부 볼륨은 제거하지 않습니다. 다만 이 설정을 데이터 백업이나 모든 삭제로부터의 보호 기능으로 해석해서는 안 됩니다.

재배포 전에 따라 할 점검 순서

아래는 공식 명령과 저장소 설명을 묶어 구성한 점검 절차입니다. 사용 중인 앱의 설치 문서와 함께 적용하세요.

보존할 항목을 적습니다. 데이터베이스, 업로드 파일, 설정 파일을 구분하고 각각의 컨테이너 내부 저장 경로를 찾습니다.
최종 구성을 확인합니다. docker compose config는 여러 구성 파일을 합치고 변수를 해석한 실제 적용 모델을 출력합니다. 편집 중인 파일뿐 아니라 적용될 마운트와 이름을 확인하세요. 출력에 환경 값이 포함될 수 있으므로 공유 전 비밀값을 점검합니다.
저장소 목록을 대조합니다. docker volume ls로 볼륨을 확인하고 필요한 항목은 docker volume inspect로 살펴봅니다. 바인드 마운트라면 구성에 적힌 호스트 경로와 실제 디렉터리를 대조합니다.
변경 전후를 기록합니다. 프로젝트 이름, 볼륨 이름, 호스트 경로, 컨테이너 경로를 한 줄씩 적어 바뀌는 항목을 표시합니다.
백업과 복원을 별도로 준비합니다. 볼륨 유지 여부만으로 준비를 끝내지 말고, 사용할 앱의 백업 절차와 복원 확인 방법을 정한 뒤 재배포합니다.

호스트 경로와 권한도 함께 보기

바인드 마운트는 호스트 디렉터리 구조에 의존하며 기본적으로 쓰기가 가능합니다. 컨테이너에서 호스트 파일을 바꿀 수 있으므로 필요한 경로만 연결하고, 읽기만 필요한 파일에는 읽기 전용 설정을 검토하세요.

운영체제에 따른 권한 차이도 있습니다. Microsoft의 Windows 컨테이너 문서는 격리 방식에 따라 바인드 마운트 접근에 사용하는 계정과 권한 모델이 달라진다고 설명합니다. Linux 예제의 경로와 권한 설정을 Windows 컨테이너에 그대로 적용하지 말고 해당 환경 문서를 확인하세요.

NAS에서 관리 화면과 Compose의 관계가 헷갈린다면 기존 시놀로지 컨테이너 매니저 확인법을 함께 읽어 보세요. 여기서 설명한 CLI 명령의 범위를 관리 화면의 모든 삭제 버튼에 그대로 대응시키지는 마세요.

정리

재배포 전 점검의 기준은 데이터가 어디에 남는지, 다음 컨테이너가 무엇을 연결하는지입니다. 저장 방식과 이름·경로를 기록하고 실행 옵션을 대조한 뒤, 백업과 복원 준비까지 확인하세요. 앱이 빈 상태로 보이면 초기화부터 진행하지 말고 기존 저장소와 연결 설정을 먼저 살펴보는 것을 권합니다.

도커 컴포즈 볼륨, 재배포 전 데이터 보존 확인법