도커 데이터 보존의 두 축: 바인드 마운트(Bind Mount) vs 볼륨(Volume) 완벽 정리

도커(Docker) 컨테이너는 기본적으로 ‘일회성’이라는 특징을 가지고 있습니다. 컨테이너를 삭제하거나 업데이트하면 그 안에서 생성되었던 데이터(DB 로그, 사용자가 업로드한 파일 등)가 모두 사라지게 되죠. 이러한 데이터 유실을 막기 위해 도커는 데이터를 호스트 서버(Ubuntu 등)에 영구적으로 보존하는 데이터 스토리지 옵션을 제공합니다. 그중 가장 대중적으로 쓰이는 두 가지 방식, 바인드 마운트(Bind Mount)와 볼륨(Named Volume)의 차이점과 사용 이유를 명확하게 파헤쳐 보겠습니다.

1. 도커 컨테이너의 데이터는 왜 사라질까?

도커 컨테이너는 독립된 환경에서 실행되며, 컨테이너 내부의 레이어에 데이터를 저장합니다. 하지만 이 레이어는 컨테이너의 생명주기와 함께하기 때문에 docker rm이나 docker compose down으로 컨테이너를 삭제하는 순간 내부 데이터도 흔적 없이 사라집니다. 이를 방지하려면 호스트 OS의 물리적 저장 공간과 컨테이너 내부 공간을 연결해야 하는데, 이 과정을 마운트(Mount)라고 합니다.

2. 바인드 마운트 (Bind Mount)

“호스트의 특정 폴더를 컨테이너가 그대로 훔쳐보게 하는 방식”으로, 호스트 시스템의 절대 경로(예: /home/user/app/logs)를 컨테이너 내부의 경로와 직접 연결하는 방식입니다. docker-compose.yml 파일에 아래와 같이 정의합니다.

volumes:
  - /home/user/zabbix_export:/usr/lib/zabbix/alertscripts

1. 동작 방식
   • 호스트에 사용자가 미리 만들어 둔 특정 디렉터리가 주인공이 됩니다. 컨테이너는 그 폴더를 그대로 마운트해서 사용합니다.
2. 장점 및 특징
   • 실시간 공유와 수정: 호스트 파일 시스템의 파일이 변경되면 컨테이너 내부에도 즉시 반영됩니다.
   • 설정 파일 및 스크립트 관리에 최적: 개발자가 소스 코드를 실시간으로 수정하며 반영해야 하는 개발 환경이나, 사용자가 직접 수동으로 알람 스크립트나 환경 설정 파일을 주입해야 할 때 가장 유용합니다.
3. 주의할 점
   • 권한(Permission) 충돌: 호스트에서 일반 계정으로 만든 폴더를 컨테이너 내부의 특정 프로세스(예: root가 아닌 mysql이나 nginx 계정)가 쓰려고 할 때, 권한이 없어 시스템이 뻗는 Permission Denied 에러가 자주 발생합니다
   • 이식성 저하: 호스트의 특정 절대 경로에 의존하기 때문에, 서버를 다른 호스트로 옮길 때 해당 경로가 없다면 컨테이너가 정상적으로 실행되지 않습니다.

3. 볼륨 (Volume / Named Volume)

“도커 엔진이 안전하게 격리해서 관리하는 전용 저장소 방식”으로, 볼륨은 호스트의 특정 경로를 사용자가 지정하는 것이 아니라, 도커 엔진이 직접 관리하는 호스트 내부의 격리된 영역에 저장 공간을 생성하고 이름을 붙여 사용하는 방식입니다.

services:
  zabbix-db:
    volumes:
      - zabbix-db-data:/var/lib/mysql

# 하단에 볼륨 정의 필수
volumes:
  zabbix-db-data:

1. 동작 방식
   • 사용자가 경로를 지정하지 않아도 도커가 알아서 /var/lib/docker/volumes/볼륨명(zabbix-db-data)/_data 경로에 안전한 폴더를 생성하고 컨테이너와 연결합니다.
2. 장점 및 특징
   • 권한 충돌 방지: 도커 엔진이 컨테이너 내부 프로세스의 권한(UID/GID)에 맞춰 저장소 권한을 자동으로 세팅해 줍니다. 권한 문제로 머리 아플 일이 전혀 없습니다.
   • 데이터베이스(DB) 관리에 최적: 사용자가 직접 내부 파일을 수동으로 열어보거나 수정할 일이 없고, 오직 프로그램이 고속으로 대량의 데이터를 읽고 써야 하는 데이터베이스 영역(MySQL, PostgreSQL 등)에 최적화되어 있습니다.
   • 높은 이식성과 안전성: 호스트 시스템의 디렉터리 구조와 격리되어 있어 도커 명령어로만 관리(docker volume ls, docker volume rm 등)되므로 호스트 OS 오동작으로 인한 파일 훼손 가능성이 낮습니다.
3. 주의할 점
   • 디스크 고갈 주범: docker compose down을 하거나 docker rm -f로 컨테이너를 삭제하면 컨테이너는 사라지지만, Named Volume은 Ubuntu 서버의 /var/lib/docker/volumes/ 내부에 영구히 남아있습니다. 볼륨을 삭제하기 위해서는 docker volume rm 볼륨명을 실행해야 합니다.
   • 백업 솔루션 연동 제약: 도커 엔진의 블랙박스 안에 갇혀 있는 형태라 외부 백업 솔루션이 볼륨에 저장된 파일들을 직접 긁어가기 어렵습니다. 경로가 너무 길고 접근하려면 무조건 root 권한(sudo)이 필요해서 관리가 직관적이지 않습니다.