[Docker] 컨테이너, CLI, Volume

본 글은 2026년 7월 29일 수강한 인프런 「비전공자도 이해할 수 있는 Docker 입문/실전」 강의와 제공된 수업자료를 바탕으로 정리한 학습 기록이다.

1. Docker를 사용하는 이유

Docker는 애플리케이션을 실행하는 데 필요한 환경을 컨테이너 단위로 묶어 실행할 수 있게 해주는 도구이다.

개발을 하다 보면 내 컴퓨터에서는 잘 동작하던 프로그램이 다른 사람의 컴퓨터나 서버에서는 제대로 실행되지 않는 경우가 있다. 운영체제, 라이브러리 버전, 실행 환경이 서로 다르기 때문이다.

Docker는 이런 문제를 줄여준다. 애플리케이션 실행에 필요한 환경을 이미지로 만들고, 그 이미지를 기반으로 컨테이너를 실행하면 어디서든 거의 동일한 환경을 재현할 수 있다.

즉 Docker를 사용하는 가장 큰 이유는 실행 환경을 일관되게 관리하기 위해서라고 볼 수 있다.

2. IP와 Port의 기본 개념

Docker 실습에서는 컨테이너로 실행한 서버에 접속하는 과정이 자주 등장한다. 이때 IP와 Port 개념을 이해해야 한다.

IP는 네트워크에서 특정 컴퓨터를 찾기 위한 주소이다. Port는 그 컴퓨터 안에서 어떤 프로그램으로 연결할지를 구분하는 번호이다.

예를 들어 웹 서버는 보통 80번 포트를 사용한다. 내 컴퓨터에서 Docker로 Nginx 컨테이너를 실행하고, 호스트의 8080번 포트를 컨테이너의 80번 포트와 연결하면 다음과 같이 접속할 수 있다.

docker run -p 8080:80 nginx

이 명령어를 실행한 뒤 브라우저에서 localhost:8080으로 접속하면 Nginx 화면을 확인할 수 있다.

여기서 8080:80은 다음 의미를 가진다.

호스트 포트:컨테이너 포트

즉 내 컴퓨터의 8080번 포트로 들어온 요청을 컨테이너 내부의 80번 포트로 전달한다는 뜻이다.

3. Docker, 이미지, 컨테이너의 관계

Docker를 이해할 때 가장 중요한 개념은 이미지와 컨테이너이다.

이미지는 컨테이너를 만들기 위한 실행 환경의 템플릿이다. 애플리케이션 코드, 실행 파일, 라이브러리, 설정 등이 포함될 수 있다.

컨테이너는 이미지를 기반으로 실제 실행되는 인스턴스이다. 쉽게 말하면 이미지는 설계도이고, 컨테이너는 그 설계도로 만들어 실행 중인 결과물이다.

예를 들어 nginx 이미지를 다운로드하면, 이 이미지를 바탕으로 여러 개의 Nginx 컨테이너를 실행할 수 있다.

docker pull nginx
docker run nginx

같은 이미지에서 여러 컨테이너를 만들 수 있고, 각 컨테이너는 서로 독립된 실행 환경을 가진다.

4. Docker CLI 기본 명령어

강의에서는 현업에서 자주 사용하는 Docker CLI 명령어들을 실습했다.

이미지를 다운로드할 때는 docker pull을 사용한다.

docker pull nginx

 

다운로드한 이미지 목록은 docker images로 확인한다.

docker images

 

 

필요 없는 이미지는 docker rmi로 삭제할 수 있다.

docker rmi nginx

 

 

컨테이너를 생성하고 실행할 때는 docker run을 사용한다.

docker run nginx

 

 

실행 중인 컨테이너 목록은 docker ps로 확인한다.

docker ps

 

 

중지된 컨테이너까지 모두 확인하려면 -a 옵션을 붙인다.

docker ps -a

 

 

컨테이너를 중지할 때는 docker stop, 삭제할 때는 docker rm을 사용한다.

docker stop 컨테이너_ID
docker rm 컨테이너_ID

 

 

컨테이너 로그는 docker logs로 확인할 수 있다.

docker logs 컨테이너_ID

 

 

실행 중인 컨테이너 내부에 접속할 때는 docker exec -it을 사용한다.

docker exec -it 컨테이너_ID bash

이 명령어를 사용하면 컨테이너 내부의 파일 구조나 실행 환경을 직접 확인할 수 있다.

5. Nginx와 Redis 컨테이너 실행 실습

강의에서는 Nginx와 Redis 이미지를 활용해 Docker의 전체 흐름을 실습했다.

Nginx는 웹 서버로, Docker의 포트 연결을 이해하기 좋은 예제이다.

docker run -d -p 8080:80 --name nginx-container nginx

이 명령어는 Nginx 컨테이너를 백그라운드에서 실행하고, 내 컴퓨터의 8080번 포트를 컨테이너의 80번 포트와 연결한다.

Redis는 메모리 기반 데이터 저장소이다. Redis 컨테이너도 Docker를 이용하면 간단히 실행할 수 있다.

docker run -d --name redis-container redis

 

 

컨테이너가 정상적으로 실행 중인지 확인하려면 다음 명령어를 사용한다.

docker ps

이러한 실습을 통해 이미지를 다운로드하고, 컨테이너를 실행하고, 상태를 확인하고, 필요하면 중지 및 삭제하는 기본 흐름을 익힐 수 있었다.

6. Docker Volume을 사용하는 이유

Docker 컨테이너 내부에 저장된 데이터는 컨테이너가 삭제되면 함께 사라진다.

예를 들어 MySQL 컨테이너 내부에 데이터베이스를 만들었는데 컨테이너를 삭제하면, 별도 설정이 없는 한 그 데이터도 함께 삭제된다. 컨테이너는 영구 저장 공간이라기보다는 실행 환경에 가깝기 때문이다.

따라서 데이터베이스처럼 데이터를 보존해야 하는 서비스는 컨테이너 내부가 아니라 외부 저장 공간에 데이터를 저장해야 한다.

Docker에서는 이를 위해 Volume을 사용한다.

7. Bind Mount와 Docker Volume

Docker에서 데이터를 외부에 저장하는 대표적인 방법은 Bind Mount와 Docker Volume이다.

Bind Mount는 호스트의 특정 폴더를 컨테이너 내부 경로와 직접 연결하는 방식이다. 사용자가 직접 경로를 지정하기 때문에 로컬 파일을 컨테이너와 공유할 때 유용하다.

Docker Volume은 Docker가 관리하는 저장 공간을 사용하는 방식이다. 호스트의 실제 저장 위치를 직접 신경 쓰지 않아도 되고, Docker 명령어로 관리할 수 있다.

MySQL처럼 데이터를 안정적으로 보존해야 하는 경우에는 Docker Volume을 사용하는 방식이 자주 활용된다.

8. MySQL 컨테이너와 Volume 실습

MySQL 데이터를 Volume에 저장하려면 먼저 볼륨을 생성한다.

docker volume create mysql-data

이후 MySQL 컨테이너를 실행하면서 해당 볼륨을 MySQL 데이터 저장 경로에 연결한다.

docker run -d \
  --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=1234 \
  -v mysql-data:/var/lib/mysql \
  mysql

 

 

여기서 중요한 부분은 다음 옵션이다.

-v mysql-data:/var/lib/mysql

mysql-data는 Docker Volume 이름이고, /var/lib/mysql은 컨테이너 내부에서 MySQL 데이터가 저장되는 경로이다.

이렇게 실행하면 컨테이너를 삭제해도 데이터는 mysql-data 볼륨에 남아 있다. 이후 같은 볼륨을 다시 연결해 MySQL 컨테이너를 생성하면 기존 데이터를 계속 사용할 수 있다.

9. 이미지로부터 컨테이너가 생성될 때 일어나는 일

Docker 이미지는 여러 개의 읽기 전용 레이어로 구성된다. 컨테이너가 생성될 때 이 이미지 레이어들이 컨테이너의 rootfs를 구성한다.

그리고 그 위에 변경 사항을 기록할 수 있는 writable layer가 추가된다.

이미지 자체는 읽기 전용이기 때문에 컨테이너 내부에서 파일을 생성하거나 수정하면 이미지가 바뀌는 것이 아니라 컨테이너의 writable layer에 변경 사항이 기록된다.

이 구조 덕분에 하나의 이미지를 기반으로 여러 컨테이너를 빠르게 생성할 수 있다.

10. VM과 Docker의 차이

VM과 Docker는 모두 격리된 실행 환경을 제공하지만 구조가 다르다.

VM은 하이퍼바이저 위에서 게스트 OS 전체를 실행한다. 따라서 VM마다 운영체제가 필요하고, 그만큼 자원 사용량도 크다.

반면 Docker 컨테이너는 호스트 OS의 커널을 공유한다. 별도의 게스트 OS를 실행하지 않기 때문에 VM보다 가볍고 빠르게 실행할 수 있다.

정리하면 VM은 OS 단위의 가상화에 가깝고, Docker는 프로세스 단위의 격리에 가깝다.

이 차이 때문에 Docker는 개발 환경 구성, 테스트 환경 구성, 배포 자동화 등에서 효율적으로 활용된다.

11. 실행 중인 컨테이너의 이미지를 갱신할 수 있을까?

실행 중인 컨테이너의 기반 이미지를 직접 교체하는 방식으로 업데이트하지는 않는다.

컨테이너는 생성될 당시의 이미지를 기반으로 만들어진 실행 객체이기 때문이다. 새 이미지가 필요하다면 이미지를 다시 다운로드하고, 기존 컨테이너를 중지 및 삭제한 뒤 새 이미지로 컨테이너를 다시 생성해야 한다.

예를 들어 Nginx 이미지를 최신 버전으로 갱신하려면 다음과 같은 흐름을 따른다.

docker pull nginx
docker stop nginx-container
docker rm nginx-container
docker run -d --name nginx-container -p 8080:80 nginx

Docker에서는 컨테이너를 직접 수정해서 오래 유지하기보다는, 필요한 설정과 데이터는 외부에 분리하고 컨테이너는 언제든 재생성할 수 있게 관리하는 방식이 중요하다.

12. Windows Git Bash에서 Docker 경로가 이상해지는 이유

Windows에서 Git Bash를 사용할 때 Docker 볼륨 마운트 경로가 이상하게 변환되는 문제가 발생할 수 있다.

예를 들어 Docker 명령어에서 컨테이너 내부 경로로 /var/lib/mysql을 입력했는데, Git Bash가 이를 Windows 경로로 자동 변환해 버리는 경우가 있다.

이는 Git Bash가 Unix 스타일 경로를 Windows 경로로 바꾸는 자동 경로 변환 기능을 가지고 있기 때문이다. 하지만 Docker 명령어에서는 컨테이너 내부 경로가 그대로 전달되어야 하므로, 이 변환이 오히려 문제를 만들 수 있다.

이 문제를 피하려면 PowerShell이나 CMD를 사용하거나, Git Bash에서 경로 변환을 비활성화하는 방법을 사용할 수 있다.

 

---

Docker 추가 학습 정리

Docker 기본 실습을 하면서 이미지, 컨테이너, Volume 개념을 배웠다. 추가로 헷갈릴 수 있는 부분들을 정리해보았다.

1. 이미지로부터 컨테이너가 생성될 때

Docker 이미지는 여러 개의 읽기 전용 레이어로 구성된다. 컨테이너를 실행하면 이 이미지 레이어들이 컨테이너의 파일 시스템인 rootfs를 구성한다.

그리고 그 위에 컨테이너별로 변경 사항을 기록하는 writable layer가 추가된다.

즉 컨테이너 내부에서 파일을 생성하거나 수정해도 원본 이미지가 바뀌는 것은 아니다. 변경 사항은 해당 컨테이너의 writable layer에만 저장된다.

이 구조 덕분에 하나의 이미지로 여러 컨테이너를 빠르게 만들 수 있다.

2. VM과 Docker의 차이

VM과 Docker는 모두 격리된 실행 환경을 제공하지만 구조가 다르다.

VM은 게스트 OS 전체를 실행한다. 그래서 독립성은 높지만 무겁고 실행 속도가 비교적 느리다.

반면 Docker 컨테이너는 호스트 OS의 커널을 공유한다. 별도의 OS를 통째로 실행하지 않기 때문에 VM보다 가볍고 빠르다.

정리하면 VM은 OS 단위 가상화에 가깝고, Docker는 애플리케이션 실행 환경을 컨테이너 단위로 격리하는 방식이다.

3. 실행 중인 컨테이너의 이미지를 갱신할 수 있을까?

실행 중인 컨테이너의 기반 이미지는 직접 교체할 수 없다.

컨테이너는 생성될 때 사용한 이미지를 기준으로 만들어진다. 이후 새 이미지를 받아도 기존 컨테이너가 자동으로 바뀌지는 않는다.

이미지를 갱신하려면 새 이미지를 받은 뒤 기존 컨테이너를 삭제하고 다시 생성해야 한다.

docker pull nginx
docker stop nginx-container
docker rm nginx-container
docker run -d --name nginx-container -p 8080:80 nginx

그래서 Docker에서는 컨테이너를 직접 수정해서 오래 유지하기보다, 필요하면 새로 만들 수 있도록 관리하는 방식이 중요하다.

4. Windows Git Bash에서 Docker 경로가 이상해지는 이유

Windows Git Bash에서는 Docker 명령어의 경로가 이상하게 바뀌는 경우가 있다.

예를 들어 /var/lib/mysql은 컨테이너 내부 경로인데, Git Bash가 이를 Windows 경로로 자동 변환할 수 있다.

/var/lib/mysql
→ C:/Program Files/Git/var/lib/mysql

이렇게 되면 Docker Volume 마운트가 의도대로 동작하지 않을 수 있다.

이 문제를 피하려면 PowerShell이나 CMD를 사용하거나, Git Bash에서 경로 변환을 비활성화하면 된다.

MSYS_NO_PATHCONV=1 docker run -v mysql-data:/var/lib/mysql mysql