Docker 볼륨과 데이터 관리 완벽 가이드

Docker 컨테이너의 데이터를 영구적으로 저장하고 관리하는 방법을 알아봅니다. 볼륨, 바인드 마운트, tmpfs의 차이점부터 백업과 복원, 컨테이너 간 데이터 공유까지 실무에 필요한 모든 내용을 다룹니다.

---

목차

1. 볼륨_vs_바인드_마운트
2. Named_Volume_생성과_관리
3. 바인드_마운트_활용
4. tmpfs_마운트
5. 볼륨_백업과_복원
6. 컨테이너_간_데이터_공유

---

1. 볼륨 vs 바인드 마운트

김개발 씨는 Docker를 처음 배우면서 한 가지 의문이 생겼습니다. 컨테이너를 삭제하면 그 안에 있던 데이터는 전부 사라진다고 하는데, 그러면 데이터베이스는 어떻게 운영하는 걸까요?

선배에게 물어보니 "볼륨을 써야지"라는 답이 돌아왔습니다.

Docker에서 데이터를 영구적으로 저장하는 방법은 크게 볼륨과 바인드 마운트 두 가지입니다. 볼륨은 Docker가 직접 관리하는 저장소이고, 바인드 마운트는 호스트의 특정 경로를 컨테이너에 연결하는 방식입니다.

마치 회사 창고와 개인 사물함의 차이라고 생각하면 됩니다.

다음 코드를 살펴봅시다.

# 볼륨 방식: Docker가 관리하는 저장소 사용
docker run -d --name db-container \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# 바인드 마운트 방식: 호스트의 특정 경로 연결
docker run -d --name web-container \
  -v /home/user/project:/app \
  node:18

# 볼륨 목록 확인
docker volume ls

# 볼륨 상세 정보 확인
docker volume inspect mysql-data

김개발 씨는 입사 2주 차에 첫 번째 Docker 프로젝트를 맡게 되었습니다. MySQL 컨테이너를 띄우고 테스트 데이터를 열심히 입력했는데, 다음 날 출근해보니 컨테이너가 재시작되면서 모든 데이터가 사라져 있었습니다.

"어제 입력한 데이터가 다 날아갔어요!" 김개발 씨가 당황해서 외치자, 선배 박시니어 씨가 웃으며 다가왔습니다. "컨테이너는 기본적으로 일회용이거든요.

데이터를 보존하려면 볼륨을 써야 해요." 그렇다면 볼륨이란 정확히 무엇일까요? 쉽게 비유하자면, 컨테이너는 호텔 객실과 같습니다.

체크아웃하면 방은 깨끗이 정리되고, 손님이 두고 간 물건은 모두 처분됩니다. 하지만 호텔 금고에 맡긴 귀중품은 안전하게 보관되어 있습니다.

바로 이 금고가 볼륨입니다. Docker 볼륨은 컨테이너의 생명주기와 독립적으로 존재합니다.

컨테이너를 삭제해도 볼륨의 데이터는 그대로 남아있고, 새 컨테이너를 만들 때 같은 볼륨을 연결하면 이전 데이터를 그대로 사용할 수 있습니다. 반면 바인드 마운트는 조금 다른 개념입니다.

호텔 비유를 계속하자면, 바인드 마운트는 자기 집에서 가져온 짐가방을 객실에 그대로 두는 것과 같습니다. 호스트 컴퓨터의 특정 폴더를 컨테이너 내부의 경로에 직접 연결하는 방식입니다.

두 방식의 가장 큰 차이는 관리 주체에 있습니다. 볼륨은 Docker가 알아서 관리합니다.

어디에 저장되는지, 어떻게 최적화되는지 개발자가 신경 쓸 필요가 없습니다. 반면 바인드 마운트는 호스트의 파일 시스템을 직접 다루기 때문에 개발자가 경로와 권한을 직접 관리해야 합니다.

위 코드를 살펴보면, 볼륨 방식에서는 mysql-data라는 이름만 지정하면 됩니다. Docker가 알아서 적절한 위치에 저장소를 만들어줍니다.

반면 바인드 마운트에서는 /home/user/project처럼 호스트의 정확한 경로를 지정해야 합니다. 그렇다면 언제 어떤 방식을 써야 할까요?

볼륨은 프로덕션 환경에서 데이터베이스나 영구 데이터를 저장할 때 적합합니다. 이식성이 좋아서 다른 서버로 옮기기도 쉽고, Docker가 최적화해주므로 성능도 우수합니다.

바인드 마운트는 개발 환경에서 빛을 발합니다. 로컬에서 코드를 수정하면 컨테이너 안에서도 바로 반영되기 때문에, 매번 이미지를 다시 빌드할 필요가 없습니다.

다시 김개발 씨 이야기로 돌아가봅시다. 박시니어 씨의 설명을 듣고 MySQL 컨테이너에 볼륨을 연결했더니, 이제 컨테이너를 재시작해도 데이터가 안전하게 보존되었습니다.

"볼륨 하나로 이렇게 편해지다니!" 김개발 씨는 감탄했습니다.

실전 팁

💡 - 프로덕션 데이터베이스에는 반드시 Named Volume을 사용하세요

• 개발 중 소스 코드 동기화에는 바인드 마운트가 편리합니다
• docker volume ls 명령으로 사용하지 않는 볼륨을 정기적으로 정리하세요

---

2. Named Volume 생성과 관리

김개발 씨가 볼륨의 개념을 이해하고 나니, 이번에는 새로운 의문이 생겼습니다. "볼륨을 미리 만들어두고 여러 컨테이너에서 쓸 수 있나요?" 박시니어 씨는 고개를 끄덕이며 Named Volume에 대해 설명하기 시작했습니다.

Named Volume은 이름을 붙여서 생성하는 볼륨입니다. docker volume create 명령으로 미리 만들어두거나, 컨테이너 실행 시 자동으로 생성할 수 있습니다.

이름이 있기 때문에 관리하기 쉽고, 여러 컨테이너에서 같은 볼륨을 공유할 수도 있습니다.

다음 코드를 살펴봅시다.

# Named Volume 생성
docker volume create my-app-data

# 생성된 볼륨 확인
docker volume ls

# 볼륨 상세 정보 (저장 위치 확인)
docker volume inspect my-app-data

# 볼륨을 컨테이너에 연결
docker run -d --name app1 \
  -v my-app-data:/data \
  alpine tail -f /dev/null

# 사용하지 않는 볼륨 일괄 삭제
docker volume prune

# 특정 볼륨 삭제
docker volume rm my-app-data

박시니어 씨는 화이트보드에 그림을 그리며 설명을 시작했습니다. "볼륨에는 두 종류가 있어요.

이름 없이 자동 생성되는 익명 볼륨과, 이름을 붙여서 만드는 Named Volume이죠." 익명 볼륨은 컨테이너를 실행할 때 자동으로 만들어지고, 긴 해시값이 이름 대신 붙습니다. 관리하기가 불편하고, 나중에 어떤 볼륨이 어떤 용도였는지 알기 어렵습니다.

반면 Named Volume은 사람이 읽기 쉬운 이름을 붙일 수 있습니다. 마치 파일에 의미 있는 이름을 붙이는 것과 같습니다.

mysql-production-data, redis-cache, nginx-logs 처럼 용도를 한눈에 알 수 있는 이름을 붙이면 관리가 훨씬 편해집니다. Named Volume을 만드는 방법은 간단합니다.

docker volume create 명령 뒤에 원하는 이름을 적으면 됩니다. 물론 컨테이너 실행 시 -v 옵션에 이름을 지정하면 자동으로 생성되기도 합니다.

볼륨이 실제로 어디에 저장되는지 궁금하다면 docker volume inspect 명령을 사용하면 됩니다. 출력 결과의 Mountpoint 항목을 보면 호스트 시스템의 실제 경로를 확인할 수 있습니다.

보통 /var/lib/docker/volumes/ 아래에 저장됩니다. "그런데 선배, 볼륨이 계속 쌓이면 디스크가 가득 차지 않을까요?" 김개발 씨가 걱정스럽게 물었습니다.

박시니어 씨는 docker volume prune 명령을 알려주었습니다. 이 명령은 어떤 컨테이너에도 연결되지 않은 볼륨을 한 번에 삭제합니다.

정기적으로 실행하면 디스크 공간을 효율적으로 관리할 수 있습니다. 주의할 점도 있습니다.

prune 명령은 연결되지 않은 모든 볼륨을 삭제하므로, 임시로 컨테이너를 내린 상태에서 실행하면 중요한 데이터가 날아갈 수 있습니다. 운영 서버에서는 특히 조심해야 합니다.

특정 볼륨만 삭제하고 싶다면 docker volume rm 뒤에 볼륨 이름을 지정하면 됩니다. 단, 해당 볼륨이 컨테이너에 연결되어 있으면 삭제되지 않습니다.

먼저 컨테이너를 중지하고 삭제한 후에 볼륨을 지워야 합니다. 김개발 씨는 자신이 만든 모든 볼륨에 의미 있는 이름을 붙이기로 결심했습니다.

나중에 자기가 봐도, 다른 팀원이 봐도 한눈에 용도를 알 수 있도록 말입니다.

실전 팁

💡 - 볼륨 이름은 용도를 알 수 있게 명확하게 지으세요 (예: postgres-prod-data)

• docker volume prune은 운영 서버에서 신중하게 사용하세요
• docker system df 명령으로 볼륨이 차지하는 디스크 용량을 확인할 수 있습니다

---

3. 바인드 마운트 활용

개발 중인 웹 애플리케이션을 Docker로 실행하려던 김개발 씨는 난감한 상황에 빠졌습니다. 코드를 수정할 때마다 이미지를 다시 빌드하고 컨테이너를 재시작해야 했기 때문입니다.

한 글자 고치는데 5분씩 걸리다니, 이건 아닌 것 같았습니다.

바인드 마운트는 호스트의 디렉토리나 파일을 컨테이너 내부에 직접 연결하는 방식입니다. 호스트에서 파일을 수정하면 컨테이너 안에서도 즉시 반영되므로, 개발 환경에서 매우 유용합니다.

볼륨과 달리 호스트의 절대 경로를 지정해야 합니다.

다음 코드를 살펴봅시다.

# 현재 디렉토리를 컨테이너에 마운트 (개발용)
docker run -d --name dev-server \
  -v $(pwd):/app \
  -w /app \
  -p 3000:3000 \
  node:18 npm run dev

# 특정 파일만 마운트 (설정 파일)
docker run -d --name nginx-custom \
  -v /home/user/nginx.conf:/etc/nginx/nginx.conf:ro \
  -p 80:80 \
  nginx:latest

# 읽기 전용 마운트 (:ro 옵션)
docker run -d --name app \
  -v /home/user/config:/app/config:ro \
  my-app:latest

박시니어 씨는 김개발 씨의 고민을 듣고 바로 해결책을 제시했습니다. "바인드 마운트를 쓰면 코드 수정이 바로 반영돼요.

이미지를 다시 빌드할 필요가 없어요." 바인드 마운트의 원리는 간단합니다. 호스트 컴퓨터의 폴더를 컨테이너 내부의 폴더와 동기화하는 것입니다.

마치 클라우드 동기화 폴더처럼, 한쪽에서 파일을 수정하면 다른 쪽에서도 즉시 변경 사항이 보입니다. 사용 방법도 볼륨과 비슷합니다.

-v 옵션 뒤에 호스트경로:컨테이너경로 형식으로 지정하면 됩니다. 차이점은 호스트 경로가 절대 경로여야 한다는 것입니다.

상대 경로를 사용하면 Docker가 볼륨으로 인식합니다. 위 코드의 첫 번째 예제를 보면 **$(pwd)**라는 표현이 있습니다.

이것은 현재 작업 디렉토리의 절대 경로로 치환됩니다. 개발할 때 프로젝트 폴더에서 이 명령을 실행하면, 해당 폴더 전체가 컨테이너의 /app 디렉토리에 연결됩니다.

바인드 마운트의 진가는 핫 리로드와 함께 사용할 때 발휘됩니다. Node.js의 nodemon이나 React의 개발 서버처럼 파일 변경을 감지하는 도구와 조합하면, 코드를 저장하는 순간 브라우저에 변경 사항이 반영됩니다.

두 번째 예제는 설정 파일 하나만 마운트하는 경우입니다. 전체 폴더가 아니라 특정 파일만 연결할 수도 있습니다.

nginx 설정을 커스터마이징할 때 자주 사용하는 패턴입니다. 주목할 점은 :ro 옵션입니다.

이것은 read-only의 약자로, 컨테이너 안에서 해당 파일이나 폴더를 수정할 수 없게 만듭니다. 설정 파일처럼 읽기만 해야 하는 경우에 사용하면 실수로 파일을 수정하는 것을 방지할 수 있습니다.

하지만 바인드 마운트에도 단점이 있습니다. 호스트의 파일 시스템에 의존하기 때문에 이식성이 떨어집니다.

개발 컴퓨터에서는 /home/user/project에 프로젝트가 있지만, 동료의 컴퓨터에서는 경로가 다를 수 있습니다. 또한 권한 문제가 발생할 수 있습니다.

컨테이너 내부의 프로세스가 호스트 파일에 접근하려면 적절한 권한이 필요합니다. Linux에서는 특히 UID/GID 관련 문제가 자주 발생합니다.

김개발 씨는 개발 환경에서는 바인드 마운트를, 프로덕션 환경에서는 볼륨을 사용하기로 결정했습니다. 각각의 장단점을 이해하고 상황에 맞게 선택하는 것이 중요합니다.

실전 팁

💡 - 개발 환경에서는 바인드 마운트로 빠른 피드백 루프를 만드세요

• 설정 파일은 :ro 옵션으로 읽기 전용 마운트하는 것이 안전합니다
• Windows에서는 경로 형식이 다르므로 /c/Users/... 형태로 작성해야 합니다

---

4. tmpfs 마운트

보안 관련 프로젝트를 진행하던 김개발 씨에게 선배가 물었습니다. "비밀번호나 API 키 같은 민감한 데이터를 파일로 저장해야 하는데, 컨테이너가 종료되면 흔적도 없이 사라지게 할 수 있을까요?" 이럴 때 사용하는 것이 바로 tmpfs 마운트입니다.

tmpfs 마운트는 데이터를 디스크가 아닌 메모리에 저장하는 방식입니다. 컨테이너가 종료되면 데이터가 완전히 사라지므로, 민감한 정보나 임시 데이터를 다룰 때 유용합니다.

디스크 I/O가 없어서 속도도 매우 빠릅니다.

다음 코드를 살펴봅시다.

# tmpfs 마운트 기본 사용법
docker run -d --name secure-app \
  --tmpfs /app/secrets \
  my-app:latest

# 크기와 권한 지정
docker run -d --name cache-app \
  --tmpfs /app/cache:size=100m,mode=1777 \
  my-app:latest

# --mount 문법으로 상세 옵션 지정
docker run -d --name temp-processor \
  --mount type=tmpfs,destination=/tmp/work,tmpfs-size=256m \
  data-processor:latest

# 여러 tmpfs 마운트 동시 사용
docker run -d --name multi-tmpfs \
  --tmpfs /app/temp \
  --tmpfs /app/cache \
  my-app:latest

박시니어 씨는 tmpfs를 설명하기 위해 재미있는 비유를 들었습니다. "볼륨이 금고라면, tmpfs는 칠판이에요.

내용을 쓰고 지울 수 있지만, 건물 문을 닫으면 다음 날 칠판은 깨끗이 지워져 있죠." tmpfs는 temporary file system의 약자입니다. 이름처럼 임시 파일 시스템이며, 데이터가 디스크가 아닌 **메모리(RAM)**에 저장됩니다.

메모리는 전원이 꺼지면 내용이 사라지는 휘발성 저장소이므로, 컨테이너가 종료되면 tmpfs에 저장된 모든 데이터도 함께 사라집니다. 이런 특성 때문에 tmpfs는 보안이 중요한 데이터를 다룰 때 유용합니다.

예를 들어 JWT 서명 키, 데이터베이스 비밀번호, API 키 같은 민감한 정보를 tmpfs에 저장하면, 컨테이너가 해킹당하더라도 컨테이너를 종료하는 순간 흔적이 남지 않습니다. 또 다른 장점은 속도입니다.

디스크에서 파일을 읽고 쓰는 것보다 메모리에서 작업하는 것이 훨씬 빠릅니다. 빈번하게 읽고 쓰는 캐시 데이터나 임시 파일을 tmpfs에 저장하면 성능이 크게 향상됩니다.

위 코드를 보면 --tmpfs 옵션으로 간단하게 사용할 수 있습니다. 컨테이너 내부의 경로만 지정하면 됩니다.

볼륨이나 바인드 마운트와 달리 호스트 경로는 필요 없습니다. 메모리에 저장되기 때문입니다.

두 번째 예제에서는 size와 mode 옵션을 볼 수 있습니다. size는 tmpfs의 최대 크기를 제한합니다.

무한정 메모리를 사용하면 시스템이 불안정해질 수 있으므로, 적절한 크기를 지정하는 것이 좋습니다. mode는 디렉토리의 권한을 설정합니다.

세 번째 예제는 --mount 문법을 사용한 것입니다. -v나 --tmpfs보다 길지만, 옵션을 더 명확하게 지정할 수 있습니다.

특히 복잡한 설정이 필요할 때 유용합니다. 주의할 점도 있습니다.

tmpfs는 메모리를 사용하므로, 너무 많은 데이터를 저장하면 시스템 메모리가 부족해질 수 있습니다. 또한 Linux에서만 지원되며, Windows나 macOS Docker Desktop에서는 일부 제한이 있을 수 있습니다.

김개발 씨는 프로젝트의 인증 토큰을 tmpfs에 저장하기로 했습니다. 보안 감사에서도 좋은 평가를 받을 수 있을 것입니다.

실전 팁

💡 - 민감한 정보(비밀번호, 키)는 tmpfs에 저장하여 보안을 강화하세요

• tmpfs 크기를 적절히 제한하여 메모리 부족을 방지하세요
• 캐시 데이터를 tmpfs에 저장하면 I/O 성능이 크게 향상됩니다

---

5. 볼륨 백업과 복원

어느 날 팀장님이 급하게 김개발 씨를 불렀습니다. "프로덕션 데이터베이스 볼륨을 백업해둬야 할 것 같아.

혹시 서버에 문제가 생기면 복원할 수 있도록." 김개발 씨는 볼륨 데이터를 어떻게 백업하고 복원하는지 알아보기로 했습니다.

Docker 볼륨의 데이터를 백업하려면 임시 컨테이너를 활용하는 방법이 일반적입니다. 볼륨을 마운트한 컨테이너에서 tar 명령으로 압축하고, 그 결과를 호스트로 복사하면 됩니다.

복원은 반대 과정을 거칩니다.

다음 코드를 살펴봅시다.

# 볼륨 백업: tar로 압축하여 호스트에 저장
docker run --rm \
  -v mysql-data:/source:ro \
  -v $(pwd):/backup \
  alpine tar czf /backup/mysql-backup.tar.gz -C /source .

# 볼륨 복원: 백업 파일을 새 볼륨에 풀기
docker run --rm \
  -v mysql-data-restored:/target \
  -v $(pwd):/backup:ro \
  alpine tar xzf /backup/mysql-backup.tar.gz -C /target

# 볼륨 간 데이터 복사
docker run --rm \
  -v source-volume:/from:ro \
  -v target-volume:/to \
  alpine sh -c "cp -av /from/. /to/"

# 백업 자동화 스크립트 예시
BACKUP_NAME="db-$(date +%Y%m%d-%H%M%S).tar.gz"
docker run --rm \
  -v postgres-data:/data:ro \
  -v /backups:/backup \
  alpine tar czf /backup/$BACKUP_NAME -C /data .

박시니어 씨는 볼륨 백업의 중요성을 강조했습니다. "볼륨은 Docker가 관리하니까 안전하다고 생각하기 쉬운데, 서버 하드웨어가 고장나면 볼륨 데이터도 날아가요.

정기적인 백업은 필수입니다." Docker 볼륨을 백업하는 가장 일반적인 방법은 임시 컨테이너를 활용하는 것입니다. 아이디어는 간단합니다.

볼륨을 마운트한 컨테이너 안에서 파일들을 압축하고, 그 결과물을 호스트로 가져오는 것입니다. 위 코드의 첫 번째 예제를 자세히 살펴봅시다.

--rm 옵션은 컨테이너가 종료되면 자동으로 삭제하라는 의미입니다. 백업은 일회성 작업이므로 컨테이너를 남겨둘 필요가 없습니다.

-v mysql-data:/source:ro는 백업할 볼륨을 컨테이너의 /source 경로에 읽기 전용으로 마운트합니다. 백업 중에 데이터가 변경되는 것을 방지하기 위해 ro 옵션을 사용합니다.

-v $(pwd):/backup은 현재 디렉토리를 컨테이너의 /backup 경로에 마운트합니다. 이렇게 하면 컨테이너 안에서 만든 백업 파일이 호스트의 현재 디렉토리에 저장됩니다.

alpine은 가벼운 Linux 이미지입니다. tar 명령을 실행하기 위해 사용합니다.

마지막으로 tar czf 명령으로 /source 디렉토리의 내용을 압축하여 /backup/mysql-backup.tar.gz 파일로 만듭니다. 복원 과정은 정확히 반대입니다.

새 볼륨을 만들고, 백업 파일을 그 볼륨 안에 풀어주면 됩니다. 두 번째 예제에서 tar xzf 명령이 압축을 해제하는 부분입니다.

세 번째 예제는 볼륨 간 데이터를 직접 복사하는 방법입니다. 백업 파일을 만들지 않고 한 볼륨의 내용을 다른 볼륨으로 바로 옮길 때 유용합니다.

네 번째 예제는 백업 자동화의 기본입니다. 날짜와 시간을 파일 이름에 포함시켜 백업을 구분합니다.

이 명령을 cron에 등록하면 정기적인 백업이 가능합니다. "백업은 했는데 복원을 안 해봤으면 백업을 안 한 거나 마찬가지예요." 박시니어 씨의 말에 김개발 씨는 복원 테스트의 중요성을 깨달았습니다.

실전 팁

💡 - 프로덕션 데이터는 정기적으로 백업하고, 복원 테스트도 반드시 해보세요

• 백업 시 :ro 옵션으로 원본 데이터 변경을 방지하세요
• 백업 파일에 날짜를 포함시켜 버전 관리하세요

---

6. 컨테이너 간 데이터 공유

마이크로서비스 아키텍처로 프로젝트를 진행하던 김개발 씨는 새로운 문제에 직면했습니다. 웹 서버 컨테이너가 생성한 로그 파일을 로그 수집 컨테이너가 읽어야 하는데, 서로 다른 컨테이너끼리 파일을 공유하려면 어떻게 해야 할까요?

여러 컨테이너가 같은 볼륨을 마운트하면 데이터를 공유할 수 있습니다. 한 컨테이너가 파일을 쓰면 다른 컨테이너에서 즉시 읽을 수 있습니다.

다만 동시에 같은 파일을 쓰면 충돌이 발생할 수 있으므로 주의가 필요합니다.

다음 코드를 살펴봅시다.

# 공유 볼륨 생성
docker volume create shared-logs

# 웹 서버: 로그를 공유 볼륨에 기록
docker run -d --name web-server \
  -v shared-logs:/var/log/app \
  nginx:latest

# 로그 수집기: 같은 볼륨을 읽기 전용으로 마운트
docker run -d --name log-collector \
  -v shared-logs:/logs:ro \
  fluentd:latest

# docker-compose로 데이터 공유 (권장)
# docker-compose.yml 예시:
# services:
#   web:
#     image: nginx
#     volumes:
#       - shared-data:/app/data
#   worker:
#     image: my-worker
#     volumes:
#       - shared-data:/data:ro
# volumes:
#   shared-data:

박시니어 씨는 화이트보드에 여러 개의 상자를 그리며 설명했습니다. "컨테이너들이 각자 독립된 공간에서 실행되지만, 같은 볼륨을 바라보게 하면 데이터를 주고받을 수 있어요.

마치 여러 사람이 같은 공유 폴더를 쓰는 것처럼요." 컨테이너 간 데이터 공유의 핵심은 같은 볼륨을 여러 컨테이너에 마운트하는 것입니다. 볼륨은 컨테이너와 독립적으로 존재하므로, 여러 컨테이너가 동시에 접근할 수 있습니다.

위 코드에서 shared-logs라는 볼륨을 먼저 생성합니다. 그리고 web-server 컨테이너는 이 볼륨을 /var/log/app 경로에, log-collector 컨테이너는 같은 볼륨을 /logs 경로에 마운트합니다.

경로는 달라도 같은 볼륨이므로 데이터가 공유됩니다. 중요한 것은 권한 분리입니다.

데이터를 생성하는 컨테이너는 읽기/쓰기 권한이 필요하지만, 데이터를 읽기만 하는 컨테이너는 :ro 옵션으로 읽기 전용 마운트하는 것이 안전합니다. 실수로 데이터를 변경하거나 삭제하는 것을 방지할 수 있습니다.

데이터 공유 시 주의할 점이 있습니다. 여러 컨테이너가 동시에 같은 파일을 쓰려고 하면 데이터가 깨질 수 있습니다.

파일 시스템은 기본적으로 동시 쓰기에 대한 보호 기능이 없기 때문입니다. 이 문제를 해결하는 방법은 여러 가지입니다.

첫째, 쓰기 담당 컨테이너를 하나로 제한합니다. 나머지는 읽기만 합니다.

둘째, 파일 이름을 다르게 해서 충돌을 피합니다. 셋째, 데이터베이스처럼 동시성 제어가 되는 시스템을 사용합니다.

실무에서는 Docker Compose를 사용하면 볼륨 공유가 더 편리합니다. docker-compose.yml 파일에 볼륨을 정의하고, 여러 서비스에서 같은 볼륨 이름을 참조하면 됩니다.

네트워크와 볼륨이 한 파일에 정의되어 있어 관리하기 쉽습니다. 김개발 씨는 웹 서버가 로그를 쓰고, 로그 수집기가 읽어가는 구조를 성공적으로 구현했습니다.

마이크로서비스 간 데이터 공유의 기초를 익힌 것입니다. "이제 컨테이너들이 서로 대화할 수 있게 됐네요!" 김개발 씨가 뿌듯해하자, 박시니어 씨가 덧붙였습니다.

"볼륨 공유는 같은 호스트 내에서만 작동해요. 여러 서버에 걸친 데이터 공유는 또 다른 방법이 필요하답니다."

실전 팁

💡 - 데이터를 쓰는 컨테이너는 하나로 제한하여 충돌을 방지하세요

• 읽기 전용 컨테이너는 반드시 :ro 옵션을 사용하세요
• 복잡한 구성은 Docker Compose로 관리하면 편리합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!