[개념] docker이해하기(2) - 이미지를 가져오고 컨테이너를 실행하기까지

 

 

 

지난 글에서는 Docker를 처음 공부할 때 가장 먼저 알아야 하는 이미지(Image)와 컨테이너(Container) 개념을 정리해봤다.

간단히 다시 정리하면 이렇다.

• 이미지는 실행을 위한 템플릿
• 컨테이너는 그 이미지를 실제로 실행한 결과

아직 안보고 오신 분들은 보고 오길 추천한다.

 

//이전 게시글 링크가져오기

 

 

이번에는 실제 Docker 명령어와 어떻게 연결되는지 정리해보려고 한다.

특히 Docker를 처음 공부하면 아래에서 많이 헷갈린다.

• docker pull은 뭘 하는 걸까?
• docker run은 정확히 뭘 실행하는 걸까?
• Dockerfile은 이미지랑 뭐가 다를까?
• 이미지는 어디에 저장되고, 컨테이너는 왜 지우면 내용이 사라질까?

이번 글에서는 이 부분을 최대한 헷갈리지 않게 정리해보겠다.

 

docker pull은 뭘 하는 명령어일까?

 

docker pull은 이미지를 내려받는 명령어다.

예를 들어 아래 명령어를 보자.

 

docker pull nginx

 

이 명령어는 nginx 이미지를 레지스트리에서 내 로컬 환경으로 가져온다.

여기서 중요한 점은 pull은 어디까지나 이미지를 받는 것이라는 점이다.
즉, 아직 실행한 것은 아니다.

처음 사용하는 입장에서는 여기서 한 번 헷갈리기 쉽다.

“이미지를 받았으니까 뭔가 실행된 거 아닌가?”

아니다.
이미지는 실행을 위한 준비물이고, pull은 그 준비물을 다운로드하는 단계다.

쉽게 말하면:

• docker pull = 실행 파일을 내려받는 것
• 아직 프로그램을 실행한 상태는 아님

 

docker run은 뭘 하는 명령어일까?

 

docker run은 이미지를 바탕으로 컨테이너를 생성하고 실행하는 명령어다.

예를 들어:

 

docker run -d -p 8080:80 nginx

 

이 명령어는 nginx 이미지를 기반으로 컨테이너를 하나 만들고 실행한다.

즉 흐름은 이렇게 이해하면 된다.

1. 이미지가 없으면 먼저 가져오고
2. 그 이미지를 기반으로 컨테이너를 만들고
3. 그 컨테이너를 실행한다

여기서 중요한 포인트가 하나 더 있다.

docker run은 단순히 “켜기”만 하는 명령어가 아니라,
컨테이너 생성 + 실행까지 같이 하는 명령어라는 점이다.

그래서 초보자들이 이런 실수를 자주 한다.

“왜 docker run을 여러 번 했더니 컨테이너가 여러 개 생기지?”

그 이유는 run이 기존 컨테이너를 다시 켜는 명령어가 아니라,
새 컨테이너를 만드는 명령어에 가깝기 때문이다.

 

 

docker pull vs docker run vs docker start

 

이 부분은 표로 보면 더 이해가 쉽다.

명령어의미대상결과

docker pull	이미지를 내려받음	이미지	로컬에 이미지가 저장됨
docker run	이미지를 기반으로 컨테이너를 생성하고 실행함	이미지	새 컨테이너가 생성되고 실행됨
docker start	이미 만들어진 컨테이너를 다시 시작함	기존 컨테이너	정지된 컨테이너가 다시 실행됨

즉 초보자 기준으로 가장 중요한 차이는 이렇다.

• pull은 이미지를 받는 것
• run은 새 컨테이너를 만드는 것
• start는 기존 컨테이너를 다시 켜는 것

이 차이를 알아두면 Docker 명령어가 훨씬 덜 헷갈린다.

 

 

Dockerfile은 정확히 어떤 역할을 할까?

 

이미지를 이야기하다 보면 자연스럽게 Dockerfile이 나온다.

Dockerfile은 이미지를 만들기 위한 설명서다.
쉽게 말하면 이미지의 설계도를 적어놓은 텍스트 파일이라고 생각하면 된다.

예를 들어 이런 식이다.

 

FROM python:3.12
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

 

 

이 파일이 의미하는 바를 풀어보면 대략 이렇다.

• python:3.12를 기반으로 시작하고
• 작업 폴더를 /app으로 설정하고
• 현재 파일을 복사하고
• 필요한 패키지를 설치한 다음
• app.py를 실행하라

즉, Dockerfile은 이미지를 만드는 방법을 적어둔 문서다.

그리고 그 문서를 바탕으로 실제 이미지를 만드는 명령어가 바로 docker build다.

 

docker build -t my-app .

 

이 명령어는 현재 위치의 Dockerfile을 읽어서 my-app이라는 이미지를 만든다.

 

 

Dockerfile, Image, Container는 어떻게 다를까?

 

이 세 개는 가장 많이 섞이는 개념이다.

항목의미비유

 

Dockerfile	이미지를 만드는 설명서	레시피 문서
Image	실행에 필요한 환경을 담은 결과물	완성된 밀키트
Container	이미지를 실제로 실행한 상태	밀키트를 조리해서 먹는 실제 음식

한 줄로 정리하면 이렇다.

Dockerfile -> Image -> Container

조금 더 자연스럽게 쓰면:

• Dockerfile로 이미지를 만들고
• 이미지로 컨테이너를 실행한다

이 흐름이 보이면 Docker의 큰 그림이 훨씬 잘 잡힌다.

 

 

docker build와 docker run은 뭐가 다를까?

 

이것도 자주 헷갈리는 부분이다.

둘 다 많이 쓰이지만 역할은 완전히 다르다.

명령어하는 일결과

 

docker build	Dockerfile을 읽어서 이미지를 만든다	이미지 생성
docker run	이미지를 기반으로 컨테이너를 만든 후 실행한다	컨테이너 생성 및 실행

즉,

• build는 만드는 단계
• run은 실행하는 단계

라고 이해하면 된다.

build와 run을 한 문장으로 묶어서 외워두면 편하다.

build는 이미지를 만들고, run은 컨테이너를 실행한다.

 

 

이미지는 어디에 저장될까? 레지스트리(Registry)

 

이미지를 저장하는 공간을 레지스트리(Registry)라고 한다.

가장 대표적인 예시는 Docker Hub다.

쉽게 비유하면 레지스트리는 이미지 창고 같은 곳이다.

• 내가 만든 이미지를 올릴 수도 있고
• 남이 올려둔 이미지를 내려받을 수도 있다

여기서 같이 알아두면 좋은 개념이 태그(Tag)다.

예를 들어 아래처럼 쓸 수 있다.

 

docker pull nginx:latest
docker pull python:3.12

 

 

여기서 latest, 3.12 같은 값이 태그다.
즉, 같은 이미지라도 버전이나 변형을 구분하기 위해 태그를 붙인다.

그래서 실무에서는 latest만 막연히 쓰기보다는
명확한 버전을 지정하는 경우가 많다.

예를 들면:

• python:3.12
• mysql:8.0
• node:20

이렇게 써야 어떤 버전으로 실행되는지 더 명확해진다.

 

 

 

알아두면 좋은 점

 

1. 컨테이너는 “서버 한 대”가 아니라 “프로세스 하나”에 더 가깝다

처음에는 컨테이너를 작은 컴퓨터처럼 생각하기 쉽다.
그런데 실제로는 애플리케이션 하나를 격리해서 실행하는 프로세스에 더 가깝다.

예를 들어:

• 백엔드 서버 컨테이너 1개
• DB 컨테이너 1개
• Redis 컨테이너 1개

이런 식으로 역할별로 나눠서 실행하는 경우가 많다.

즉, 컨테이너 하나에 모든 것을 다 넣는 방식보다는
역할별로 나눠서 실행한다는 감각을 초반에 잡아두면 좋다.

 

2. 컨테이너 안에서 직접 수정하는 습관은 길게 보면 좋지 않다

실행 중인 컨테이너에 들어가서 파일을 고치고 싶어질 수 있다.

물론 테스트용으로는 가능하지만,
실제로는 Dockerfile을 수정하고 이미지를 다시 빌드하는 방식이 더 중요하다.

왜냐하면 그래야:

• 같은 환경을 다시 만들 수 있고
• 다른 사람도 똑같이 실행할 수 있고
• 배포 환경도 일관되게 유지할 수 있기 때문이다

즉, Docker의 핵심은
“실행 중인 것을 손으로 고치는 것”보다
“같은 환경을 다시 만들어낼 수 있게 하는 것”에 있다.

 

3. 로그를 보는 습관이 중요하다

Docker를 처음 쓸 때 컨테이너가 안 뜨면 당황하기 쉽다.
그럴 때 가장 먼저 봐야 하는 것이 로그다.

예를 들어 보통 이런 명령어를 자주 쓰게 된다.

 

docker ps
docker ps -a
docker logs <컨테이너명 또는 ID>

 

초보자 입장에서는 컨테이너가 “왜 죽었는지”를 감으로 맞추기보다,
로그를 먼저 확인하는 습관을 들이는 게 훨씬 중요하다.

 

4. 포트 매핑 개념은 꼭 익혀두는 게 좋다

처음 Docker를 쓰면 “분명 실행됐는데 왜 접속이 안 되지?”라는 상황을 자주 겪는다.

이때 자주 관련되는 개념이 포트 매핑이다.

 

docker run -p 8080:80 nginx

 

이건 보통 이렇게 이해하면 된다.

• 내 컴퓨터의 8080 포트로 들어온 요청을
• 컨테이너 내부의 80 포트로 연결한다

즉, 호스트 포트와 컨테이너 포트는 다를 수 있다는 점을 초반에 익혀두면 좋다.

 

5. 데이터는 컨테이너 밖에 따로 보관해야 할 수 있다

애플리케이션 코드는 이미지로 관리할 수 있지만,
DB 데이터나 업로드 파일처럼 계속 남아 있어야 하는 데이터는 별도로 관리해야 한다.

그래서 Docker를 공부하다 보면 자연스럽게 Volume이라는 개념이 나온다.

아주 간단히만 기억하면 된다.

• 컨테이너 = 실행
• 볼륨 = 저장

이 정도 감각만 있어도 초반에는 충분하다.

 

많이 헷갈리는 포인트

이번 편에서는 이 부분을 꼭 짚고 넘어가는 게 좋다.

 

1. docker pull을 했는데 왜 실행이 안 되지?

pull은 실행이 아니라 다운로드다.
이미지만 가져온 상태이기 때문에 컨테이너는 아직 없다.

실행하려면 docker run이 필요하다.

 

2. docker run을 여러 번 했더니 왜 컨테이너가 계속 생기지?

run은 새 컨테이너를 만드는 명령어다.
기존 컨테이너를 다시 켜는 게 아니라 새로 생성하는 것이기 때문에 여러 개가 생길 수 있다.

 

3. Dockerfile이 이미지 그 자체인가?

아니다.

• Dockerfile은 설명서
• Image는 그 설명서로 만든 결과물

이 둘은 다르다.

 

4. 컨테이너 안에서 수정한 내용은 계속 남는가?

 

항상 그렇지는 않다.
컨테이너는 실행 단위이기 때문에 삭제되면 내부 변경사항도 사라질 수 있다.

그래서 데이터베이스 파일이나 업로드 파일처럼 유지해야 하는 데이터는
Volume 같은 별도 저장 공간을 사용하는 경우가 많다.

 

컨테이너 안의 데이터는 왜 사라질까?

Docker를 처음 쓰면 이런 궁금증이 생긴다.

“컨테이너 안에서 뭔가 설치하고 수정했는데, 컨테이너를 지우면 왜 없어지지?”

이유는 컨테이너가 기본적으로 실행 단위이기 때문이다.
컨테이너는 애플리케이션을 실행하기 위한 환경이지, 영구 저장소 자체가 아니다.

그래서 중요한 데이터는 컨테이너 내부에만 두지 않고 따로 분리해야 한다.
이때 많이 사용하는 개념이 Volume이다.

아주 간단하게만 정리하면:

• 컨테이너 = 실행 환경
• 볼륨 = 유지해야 하는 데이터를 저장하는 별도 공간