도커 볼륨 개념, 데이터가 사라지지 않는 이유 5분 정리

공들여 넣은 데이터베이스 데이터가 컨테이너를 재시작했더니 감쪽같이 사라진 경험, 도커를 처음 쓰는 사람이라면 한 번쯤 겪는 일입니다.

도커 볼륨을 모르고 컨테이너를 쓰면 이런 사고가 반복될 수밖에 없습니다. 컨테이너는 기본적으로 “일회용”에 가까운 존재이기 때문입니다.

이 글은 왜 컨테이너 안 데이터가 사라지는지, 그리고 도커 볼륨이 어떻게 이 문제를 해결하는지 원리부터 실전 사용법까지 정리합니다.

이 시리즈의 컴포즈 편을 읽었다면 yml 파일 안에 등장하는 volumes 항목이 정확히 뭘 하는지도 이 글로 명확해질 겁니다.

도커 볼륨이 필요한 이유 – 컨테이너 데이터의 운명

도커 컨테이너는 이미지 위에 쓰기 가능한 레이어 하나를 얹어서 만들어집니다. 컨테이너 안에서 파일을 만들거나 수정하면 전부 이 쓰기 레이어에 기록됩니다.

문제는 컨테이너를 삭제하는 순간 이 쓰기 레이어도 함께 사라진다는 점입니다. 컨테이너는 언제든 지우고 새로 만들 수 있다는 게 도커의 장점이지만, 그 안의 데이터 입장에서는 위험 요소입니다.

예를 들어 데이터베이스 컨테이너를 그냥 실행만 하면, 저장한 회원 정보가 컨테이너를 재시작하거나 지우는 순간 통째로 날아갑니다. 실제 서비스라면 치명적인 사고입니다.

이 문제를 해결하는 방법이 바로 도커 볼륨입니다. 볼륨은 컨테이너의 쓰기 레이어가 아니라 도커가 별도로 관리하는 독립된 저장 공간에 데이터를 보관합니다.

컨테이너가 사라져도 볼륨은 그대로 남아있고, 새 컨테이너를 만들 때 같은 볼륨을 다시 연결하면 예전 데이터를 그대로 이어받을 수 있습니다.

도커 볼륨 vs 바인드 마운트, 뭐가 다를까

데이터를 유지하는 방법이 도커 볼륨 하나만 있는 건 아닙니다. 바인드 마운트(bind mount)라는 방식도 있어서 둘을 자주 헷갈립니다.

도커 볼륨은 도커가 위치와 관리를 전부 알아서 해줍니다. 사용자는 이름만 정하면 되고, 실제 저장 위치는 도커 내부 디렉토리에 도커가 알아서 잡습니다.

바인드 마운트는 반대로 사용자가 호스트 컴퓨터의 특정 경로를 직접 지정합니다. 예를 들어 내 컴퓨터의 코드 폴더를 컨테이너 안에 그대로 연결해서, 코드를 수정하면 컨테이너 안에도 즉시 반영되게 만들 때 씁니다.

정리하면 운영 환경에서 데이터를 안전하게 보관하려면 도커 볼륨을, 개발 중 코드 변경을 실시간으로 확인하려면 바인드 마운트를 쓰는 게 일반적입니다.

둘을 같은 컨테이너에서 동시에 쓰는 경우도 흔합니다. 코드는 바인드 마운트로, 데이터베이스 파일은 볼륨으로 나눠 연결하는 식입니다.

도커 볼륨 만들고 연결하는 법

도커 볼륨을 쓰는 방법은 크게 두 가지입니다. 미리 만들어두거나, 컨테이너 실행 시 자동으로 생성되게 하는 방법입니다.

먼저 만드는 방법은 docker volume create my-data처럼 이름을 정해서 생성합니다. 이후 docker run -v my-data:/var/lib/mysql mysql처럼 -v 옵션으로 볼륨 이름과 컨테이너 내부 경로를 콜론으로 연결해줍니다.

이렇게 하면 컨테이너 내부의 /var/lib/mysql 경로에 저장되는 모든 데이터가 실제로는 my-data 볼륨에 기록됩니다. 컨테이너를 지워도 my-data는 그대로 남아있습니다.

컴포즈 파일에서는 최상위 volumes 항목에 이름을 등록하고, services 안 해당 컨테이너의 volumes 목록에서 “볼륨이름:경로” 형식으로 연결합니다. 방식은 다르지만 원리는 -v 옵션과 동일합니다.

현재 만들어진 볼륨 목록은 docker volume ls로, 특정 볼륨의 세부 정보는 docker volume inspect 볼륨이름으로 확인할 수 있습니다.

도커 볼륨은 실제로 어디에 저장될까

도커 볼륨의 데이터가 눈에 안 보이는 곳에 저장되다 보니 “진짜 안전한 건가” 의문이 들 수 있습니다. 실제로는 호스트 컴퓨터 디스크의 특정 디렉토리에 물리적으로 저장됩니다.

리눅스 환경에서는 보통 /var/lib/docker/volumes 경로 아래에 볼륨 이름별로 폴더가 생성됩니다. 다만 도커가 직접 이 경로를 관리하므로, 사용자가 이 폴더를 직접 건드릴 필요는 거의 없습니다.

Docker Desktop을 쓰는 윈도우·맥 환경에서는 실제로는 도커가 내부적으로 띄운 리눅스 가상 환경 안에 저장됩니다. 그래서 탐색기나 파인더에서 바로 찾아지지 않는 게 정상입니다.

이렇게 도커가 물리적 위치를 추상화해주기 때문에, 사용자는 어떤 컴퓨터에서 실행하든 volume 이름만 기억하면 됩니다. 서버 환경이 바뀌어도 볼륨을 옮기는 방식만 알면 데이터를 그대로 이전할 수 있습니다.

백업이 필요하다면 이 디렉토리 전체를 복사하는 방법도 있지만, 실무에서는 볼륨을 마운트한 임시 컨테이너로 압축 파일을 만들어 별도 저장소에 옮기는 방식을 더 많이 씁니다.

도커 볼륨 관리 시 자주 하는 실수

가장 흔한 실수는 컨테이너를 지울 때 볼륨까지 함께 지우는 옵션을 무심코 쓰는 것입니다. docker rm -v 컨테이너명 명령은 연결된 익명 볼륨까지 삭제하므로, 데이터를 지키려면 이 옵션을 신중하게 써야 합니다.

두 번째는 이름 없는(익명) 볼륨을 계속 쌓아두는 습관입니다. 이름을 지정하지 않고 컨테이너를 여러 번 재생성하면 안 쓰는 볼륨이 계속 늘어나 디스크 공간을 차지합니다.

세 번째는 여러 컨테이너가 같은 볼륨을 동시에 쓰면서 데이터가 꼬이는 경우입니다. 특히 데이터베이스처럼 동시 쓰기에 민감한 서비스는 한 볼륨에 하나의 컨테이너만 연결하는 게 안전합니다.

도커 볼륨의 핵심은 “컨테이너는 사라져도 데이터는 남는다”는 원칙입니다. 이 원칙만 기억하고 볼륨 이름을 명확하게 관리하면 대부분의 사고를 예방할 수 있습니다.

FAQ

📖 핵심 용어 미니 사전

본문에 나온 용어가 낯설다면 아래에서 먼저 확인해보세요.

🔗 공식 자료

📖 출처

• Docker Docs, “Storage overview” – docs.docker.com/engine/storage/
• Docker Docs, “Volumes” – docs.docker.com/engine/storage/volumes/
• Docker Docs, “docker volume” CLI reference – docs.docker.com/reference/cli/docker/volume/
• Docker Docs, “Bind mounts”