IT의 IT 블로그

Docker 기본 개념 정리 본문

Dev Tools

Docker 기본 개념 정리

IT의 IT 블로그 2026. 4. 13. 13:56

안녕하세요.

 

이번 글에서는 Docker의 기본 개념을 정리해보겠습니다.

Docker를 공부하다 보면
이미지(Image), 컨테이너(Container), Dockerfile, Registry, Compose 같은 용어가 계속 등장합니다.

 

이 개념들은 각각 따로 보이지만,
실제로는 서로 연결되어 있기 때문에 흐름으로 이해하는 것이 중요합니다.

 

이번 글에서는 Docker를 왜 사용하는지부터 시작해서,
Docker Desktop과 CLI, 이미지와 컨테이너의 관계, Dockerfile의 역할,
그리고 Compose와 Registry까지 전체 구조를 한 번에 정리해보겠습니다.

 

단순히 명령어만 보는 것이 아니라,
Docker가 어떤 문제를 해결하고 어떤 방식으로 동작하는지를 중심으로 살펴보겠습니다.

0. Docker Desktop과 CLI

Docker를 사용하는 방법은 크게 두 가지가 있습니다.

 

하나는 터미널에서 직접 명령어를 입력하는 CLI 방식이고,
다른 하나는 화면에서 컨테이너와 이미지를 확인하고 관리할 수 있는 Docker Desktop 방식입니다.

 

윈도우 환경에서는 보통 Docker Desktop을 먼저 설치해서 사용하게 되는데,
실제로 Docker를 다룰 때는 CLI와 Docker Desktop을 함께 사용하는 경우가 많습니다.

 

즉, Docker Desktop은 Docker를 좀 더 쉽게 관리하고 상태를 확인하게 해주는 도구이고,
CLI는 Docker를 실제로 실행하고 제어하는 기본 방식이라고 볼 수 있습니다.

0.1 CLI (Command Line Interface)

CLI는 터미널에서 직접 명령어를 입력하는 방식입니다.

 

예를 들어 아래와 같은 명령어들이 있습니다.

docker build
docker run
docker ps
docker images
 

이 방식은 처음에는 다소 낯설 수 있지만,
Docker를 실제로 다룰 때 가장 기본이 되는 방식입니다.

 

CLI 방식의 장점은 다음과 같습니다.

  • 명령어로 세밀하게 제어할 수 있음
  • 반복 작업을 자동화하기 쉬움
  • CI/CD나 서버 환경에서 그대로 사용 가능
  • Docker의 동작 원리를 익히기에 좋음

즉, CLI는
Docker를 실제로 다루는 가장 표준적인 방식이라고 볼 수 있습니다.

0.2 Docker Desktop

 

반면 윈도우나 Mac 환경에서는 Docker Desktop이라는 GUI 프로그램을 함께 사용할 수 있습니다.

 

Docker Desktop은
Docker Engine을 조금 더 쉽게 사용할 수 있도록 도와주는 관리 도구입니다.

 

예를 들어 Docker Desktop에서는 다음과 같은 작업을
UI 화면에서 비교적 직관적으로 할 수 있습니다.

  • 현재 실행 중인 컨테이너 확인
  • 이미지 목록 확인
  • 컨테이너 시작 / 중지 / 삭제
  • 로그 확인
  • 볼륨 / 네트워크 상태 확인

즉, 명령어를 모두 외우지 않아도
현재 Docker 상태를 눈으로 확인하고 관리하기가 쉽습니다.

 

특히 Docker를 처음 공부할 때는
컨테이너가 실제로 생성되고 실행되는 모습을
GUI 화면으로 보는 것이 이해에 도움이 됩니다.

0.3 Windows에서는 왜 Docker Desktop을 많이 쓰는가

리눅스에서는 Docker를 비교적 직접 설치해서 사용하는 경우가 많지만,
윈도우에서는 Docker Desktop을 통해 Docker 환경을 구성하는 경우가 많습니다.

 

그 이유는 윈도우가 리눅스 커널을 직접 사용하는 환경이 아니기 때문에,
Docker Desktop이 내부적으로 필요한 실행 환경을 함께 관리해주기 때문입니다.

 

사용자 입장에서는 복잡한 내부 구조를 모두 신경 쓰기보다
Docker Desktop을 설치하고 실행한 뒤,
CLI와 GUI를 함께 사용하는 방식으로 시작하는 경우가 일반적입니다.

 

즉, 윈도우 기준으로는 보통 다음처럼 이해하면 됩니다.

  • Docker Desktop = Docker를 쉽게 실행하고 관리할 수 있게 해주는 프로그램
  • CLI = Docker를 실제로 조작하는 핵심 명령 방식

0.4 Docker Desktop과 CLI의 관계

이 둘은 서로 대체 관계라기보다는
함께 사용하는 관계에 가깝습니다.

 

예를 들어

  • 이미지는 CLI로 docker build
  • 컨테이너 상태는 Docker Desktop에서 확인
  • 실행과 삭제는 CLI 또는 GUI 둘 다 가능

이런 식으로 함께 사용할 수 있습니다.

정리하면 다음과 같습니다.

  • CLI는 Docker를 직접 다루는 핵심 방식
  • Docker Desktop은 Docker를 더 쉽게 관리하고 시각적으로 확인하게 해주는 도구

처음에는 Docker Desktop으로 전체 구조를 이해하고,
점점 CLI 중심으로 익숙해지는 방식이 가장 자연스럽습니다.

1. 왜 Docker를 사용하는가

개발을 하다 보면
같은 프로젝트라도 실행 환경에 따라 정상적으로 동작하지 않는 경우를 자주 마주하게 됩니다.

 

예를 들어, 로컬에서는 잘 동작하던 코드가
서버에서는 오류가 발생하거나 실행되지 않는 상황이 생길 수 있습니다.

 

같은 프로젝트라도 실행 환경이 다르면 문제가 생길 수 있가 때문입니다.

  • 운영체제가 다를 수 있고
  • Node.js 버전이 다를 수 있고
  • 설치된 라이브러리가 다를 수 있고
  • 배포 서버와 로컬 환경이 다를 수 있습니다

이런 차이 때문에
로컬에서는 잘 되지만 서버에서는 동작하지 않거나,
협업 중에 같은 코드를 받아도 실행이 안 되는 경우가 생깁니다.

 

Docker는 이런 문제를 해결하기 위해 사용합니다.

 

애플리케이션을 단순히 코드만 옮기는 것이 아니라,
실행에 필요한 환경까지 함께 묶어서
어디서든 동일하게 실행할 수 있도록 만들어줍니다.

 

즉, Docker의 가장 큰 목적은
환경 차이를 줄이고 실행 환경을 표준화하는 것입니다.

2. Docker란?

Docker는 컨테이너 기반 가상화 기술을 활용해
애플리케이션을 더 쉽게 실행하고 관리할 수 있도록 도와주는 플랫폼입니다.

 

조금 더 쉽게 말하면,
프로그램을 실행하는 데 필요한 환경을 하나로 묶어서
격리된 상태로 실행할 수 있게 해주는 도구입니다.

 

예를 들어 어떤 애플리케이션을 실행하려면 다음과 같은 요소가 필요할 수 있습니다.

  • 운영체제 기반 환경
  • 언어 런타임(Node.js, Python 등)
  • 라이브러리
  • 애플리케이션 코드
  • 실행 명령어

Docker는 이런 요소들을 하나의 실행 단위로 정리해
어디서든 같은 방식으로 실행할 수 있게 만들어줍니다.

 

핵심은 다음과 같습니다.

  • 실행 환경을 함께 묶을 수 있음
  • 격리된 환경에서 실행 가능
  • 다른 컴퓨터에서도 동일하게 실행 가능
  • 배포와 실행이 단순해짐

즉, Docker는
**“프로그램을 실행하기 위한 환경까지 함께 포장해서 배포하는 방식”**이라고 이해하면 가장 쉽습니다.

3. Virtual Machine과 Docker Container의 차이

Docker를 이해할 때 가장 많이 비교되는 대상이 바로 Virtual Machine입니다.

 

둘 다 격리된 환경을 만든다는 공통점은 있지만,
동작 방식은 꽤 다릅니다.

3.1 Virtual Machine(가상머신)

기존 가상화 방식은 하이퍼바이저(Hypervisor)를 이용해
하나의 호스트 위에 여러 개의 운영체제를 올려서 사용하는 방식입니다.

 

각 가상머신은 독립된 Guest OS를 가지고,
그 안에서 필요한 프로그램을 설치하고 실행합니다.

 

즉, 애플리케이션 하나를 실행하기 위해
운영체제 전체를 하나 더 올리는 구조라고 볼 수 있습니다.

 

이 방식의 장점은
운영체제 단위로 완전히 분리된 환경을 만들 수 있다는 점입니다.

 

하지만 단점도 있습니다.

  • Guest OS가 각각 필요함
  • 커널과 라이브러리까지 모두 포함해야 함
  • 이미지 크기가 큼
  • 실행 속도가 상대적으로 느림
  • 하이퍼바이저를 거치므로 성능 오버헤드가 발생할 수 있음

즉, VM은 강력한 격리를 제공하지만 무겁습니다.

 

VM → OS 포함

3.2 Docker Container(도커 컨테이너)

Docker 컨테이너는 가상머신처럼 운영체제를 통째로 새로 만들지 않습니다.

 

호스트 OS의 커널을 공유하면서
프로세스 단위로 애플리케이션을 격리해서 실행합니다.

 

즉, 필요한 것은 분리하되
운영체제 전체를 복제하지는 않는 방식입니다.

 

이 방식 덕분에 다음과 같은 장점이 생깁니다.

  • 훨씬 가볍다
  • 실행 속도가 빠르다
  • 이미지 크기가 작다
  • 성능 손실이 적다

컨테이너 안에는
애플리케이션 실행에 필요한 라이브러리와 파일만 포함되고,
커널은 호스트와 공유합니다.

 

그래서 Docker는
가상머신보다 더 빠르고 효율적으로 실행 환경을 제공할 수 있습니다.

4. Docker가 가볍고 빠른 이유

Docker가 빠르다고 많이 이야기하지만,
중요한 것은 왜 빠른가를 이해하는 것입니다.

 

Docker가 가볍고 빠른 이유는 크게 세 가지로 볼 수 있습니다.

4.1 운영체제를 통째로 포함하지 않는다

OS 전체 포함 vs 필요한 실행 환경만 포함

 

컨테이너는 Guest OS를 따로 가지지 않습니다.
호스트의 커널을 공유하기 때문에
운영체제 전체를 매번 포함할 필요가 없습니다.

4.2 필요한 것만 포함한다

필요한 것만 포함

 

컨테이너에는 애플리케이션 실행에 필요한 파일과 라이브러리만 들어갑니다.

 

예를 들어 Node.js 애플리케이션이라면
Node 런타임, 패키지, 소스 코드 정도만 포함하면 됩니다.

4.3 프로세스 단위로 격리한다

가상머신은 OS 단위 가상화에 가깝지만,
Docker는 프로세스 단위 격리이기 때문에 훨씬 효율적입니다.

 

결국 Docker는
무겁게 전체 시스템을 가상화하는 대신, 필요한 실행 환경만 분리해서 사용하기 때문에 빠르고 가볍습니다.

프로세스 단위 비교 인포그래픽

5. Docker의 핵심 구성요소

Docker를 사용할 때 자주 등장하는 구성요소는 다음과 같습니다.

도커 흐름도

5.1 Docker Client

우리가 터미널에서 사용하는 docker 명령어가 바로 Docker Client입니다.

 

예를 들어

docker build
docker pull
docker run
 

이런 명령어를 입력하면
Docker Client가 그 요청을 Docker Engine에 전달합니다.

 

즉, 사용자의 입력을 받아 실제 엔진에 명령을 전달하는 역할입니다.

5.2 Docker Engine(Docker Daemon)

 

 

Docker의 실제 동작 주체입니다.

 

Docker Engine은 다음과 같은 작업을 수행합니다.

  • 이미지 빌드
  • 이미지 다운로드 및 저장
  • 컨테이너 생성 및 실행
  • 네트워크 / 볼륨 관리

즉, Docker의 핵심은 결국 Docker Engine이라고 볼 수 있습니다.

5.3 Docker Host

Docker Engine이 실행되는 환경입니다.
이미지와 컨테이너가 실제로 존재하고 관리되는 서버 또는 PC라고 보면 됩니다.

5.4 Registry

이미지를 저장하는 원격 저장소입니다.

 

대표적으로 다음이 있습니다.

  • Docker Hub
  • AWS ECR
  • GitHub Container Registry

이미지를 Registry에 올려두면
다른 환경에서 pull 받아서 그대로 실행할 수 있습니다.

6. Docker Image와 Docker Container

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

 

이 둘은 서로 연결되어 있지만 역할이 다릅니다.

6.1 Docker Image란?

Docker Image는 컨테이너를 생성하기 위한 실행 패키지입니다.

 

쉽게 말하면
애플리케이션을 실행하는 데 필요한 환경을 담아둔 묶음입니다.

 

여기에는 보통 다음이 포함됩니다.

  • 베이스 이미지 정보
  • 런타임
  • 라이브러리
  • 소스 코드
  • 실행 명령

즉, 이미지는 실행 환경이 미리 구성된 결과물입니다.

 

비유하면 다음과 같습니다.

  • 클래스와 인스턴스 관계에서의 클래스
  • 프로그램과 프로세스 관계에서의 프로그램 파일
  • 건축으로 보면 설계도

즉, 이미지는
실행되기 전의 정적인 패키지입니다.

6.2 Docker Container란?

컨테이너는 이미지를 실제로 실행한 상태입니다.

 

이미지가 정적인 실행 패키지라면,
컨테이너는 그 패키지가 메모리 위에서 실제로 동작하고 있는 실행 인스턴스입니다.

 

같은 이미지 하나로 여러 개의 컨테이너를 만들 수 있기 때문에
이미지와 컨테이너는 1:N 관계입니다.

 

예를 들어 하나의 웹 서버 이미지로부터
여러 개의 웹 서버 컨테이너를 띄울 수 있습니다.

 

즉, 이미지는 재사용 가능한 원본이고,
컨테이너는 그 원본으로부터 만들어진 실행 결과입니다.

6.3 이미지와 컨테이너의 차이

이미지는 읽기 전용입니다.
한 번 만들어진 이미지는 직접 수정하는 개념보다
새로 빌드해서 교체하는 방식에 가깝습니다.

 

반면 컨테이너는 실행 중 상태가 바뀔 수 있습니다.

 

예를 들어 컨테이너 안에서 파일을 수정하거나 프로그램을 설치할 수 있지만,
그 변경은 원본 이미지에 직접 반영되는 것이 아니라
컨테이너의 쓰기 계층에 따로 저장됩니다.

 

즉,

  • 이미지는 원본
  • 컨테이너는 실행본
  • 컨테이너의 변경 사항은 해당 컨테이너에만 적용

됩니다.

 

같은 이미지로 만든 A 컨테이너를 수정해도
B 컨테이너에는 영향을 주지 않는 이유가 바로 이것입니다.

7. 이미지의 핵심 특징: 불변성과 레이어 구조

Docker 이미지가 어떻게 관리되는지를 이해하려면
불변성(Immutable) 과 레이어(Layer) 개념을 꼭 알아야 합니다.

7.1 이미지는 변경할 수 없다

Docker 이미지는 기본적으로 불변입니다.

 

즉, 한 번 생성된 이미지를 직접 수정해서 덮어쓰는 방식이 아니라
변경이 필요하면 새로운 이미지를 다시 빌드합니다.

 

예를 들어 코드가 수정되었거나 패키지가 추가되었다면
기존 이미지를 고치는 것이 아니라
그 상태를 반영한 새로운 이미지를 다시 만들어야 합니다.

 

이 방식은 번거로워 보일 수 있지만 장점이 분명합니다.

  • 실행 환경이 항상 예측 가능함
  • 같은 이미지라면 어디서 실행해도 동일한 결과 보장
  • 버전 관리가 쉬움
  • 배포 이력이 명확해짐

즉, Docker는
“실행 중인 환경을 직접 고쳐 쓰는 방식”보다
“새로운 버전을 다시 만들어 교체하는 방식”에 더 가깝습니다.

7.2 이미지는 여러 레이어로 구성된다

Docker 이미지는 하나의 덩어리 파일처럼 보이지만,
내부적으로는 여러 레이어가 쌓여서 구성됩니다.

 

예를 들어 아래와 같은 Dockerfile이 있다고 해보겠습니다.

FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "dev"]
 

이 Dockerfile은 한 번에 전체가 만들어지는 것이 아니라,
각 명령어 단위로 레이어가 쌓이는 구조입니다.

 

대략적인 흐름은 다음과 같습니다.

  • FROM node:22-alpine
    → Node.js 22 기반의 베이스 이미지 레이어
  • WORKDIR /app
    → 작업 디렉토리 설정 레이어
  • COPY package.json package-lock.json ./
    → 의존성 파일 복사 레이어
  • RUN npm install
    → 패키지 설치 레이어
  • COPY . .
    → 실제 소스 코드 복사 레이어
  • CMD ["npm", "run", "dev"]
    → 컨테이너 실행 기본 명령 설정

즉, 이미지는 여러 단계의 파일 시스템 변경이 차곡차곡 쌓인 결과입니다.

7.3 레이어 구조가 중요한 이유

레이어 구조는 Docker의 성능과 효율성에 매우 중요합니다.

1) 캐시를 활용할 수 있다

이전에 빌드한 레이어와 동일하면 다시 만들지 않고 재사용할 수 있습니다.

 

예를 들어 package.json이 바뀌지 않았다면
RUN npm install 레이어를 다시 만들지 않고 캐시를 사용할 수 있습니다.

 

그래서 보통 Dockerfile 작성 시에는

COPY package.json package-lock.json ./
RUN npm install
COPY . .
 

처럼 의존성 파일을 먼저 복사하고 설치한 뒤, 나중에 소스 코드를 복사하는 패턴을 많이 사용합니다.

 

이렇게 하면 코드만 수정됐을 때 매번 npm install을 다시 하지 않아도 되기 때문입니다.

2) 이미지 확장이 쉽다

기존 베이스 이미지 위에 필요한 레이어만 추가하면 되기 때문에
Node 이미지, Python 이미지 같은 공식 이미지를 기반으로 손쉽게 확장할 수 있습니다.

3) 저장과 전송이 효율적이다

변경된 레이어만 전송하거나 재사용할 수 있기 때문에
빌드와 배포 과정이 더 효율적입니다.

 

즉, 레이어 구조는 단순한 내부 구현이 아니라
Docker가 빠르고 효율적으로 동작하는 핵심 이유 중 하나입니다.

8. Dockerfile이란?

 

Dockerfile은 이미지를 만들기 위한 명령어들을 작성하는 파일입니다.

 

즉,
**“이 애플리케이션을 어떤 환경에서, 어떤 순서로 이미지화할 것인가”**를 정의한 빌드 스크립트입니다.

 

Dockerfile은 단순히 명령어를 적는 파일이 아니라,
이미지 생성 과정을 문서처럼 선언적으로 표현하는 파일입니다.

 

즉, Dockerfile만 보면

  • 어떤 베이스 이미지를 사용할지
  • 어떤 파일을 복사할지
  • 어떤 패키지를 설치할지
  • 어떤 명령으로 실행할지

를 한눈에 파악할 수 있습니다.

8.1 Dockerfile의 역할

Dockerfile의 역할은 크게 네 가지로 볼 수 있습니다.

1) 실행 환경 정의

어떤 런타임과 어떤 OS 기반에서 시작할지를 정합니다.

예를 들어

 
FROM node:22-alpine
 

는
Node.js 22가 설치된 Alpine Linux 기반 환경에서 시작하겠다는 의미입니다.

2) 애플리케이션 파일 복사

내 로컬에 있는 프로젝트 파일을 이미지 안으로 복사합니다.

예를 들어

 
COPY . .
 

는 현재 폴더의 파일을 이미지 내부로 복사하겠다는 뜻입니다.

3) 필요한 의존성 설치

애플리케이션 실행에 필요한 패키지를 이미지 안에 설치합니다.

예를 들어

 
RUN npm install
 

는 컨테이너 내부 환경에서 npm install을 실행해
필요한 패키지를 설치하겠다는 의미입니다.

4) 컨테이너 시작 명령 정의

이미지를 실행했을 때 어떤 명령어를 기본으로 실행할지를 정합니다.

예를 들어

 
CMD ["npm", "run", "dev"]
 

는 컨테이너가 시작될 때 npm run dev를 실행하겠다는 의미입니다.

8.2 자주 쓰는 Dockerfile 명령어

FROM

베이스 이미지 지정

FROM node:22-alpine
 

WORKDIR

작업 디렉토리 지정

WORKDIR /app
 

이후 명령어들은 /app 기준으로 실행됩니다.

COPY

파일 복사

COPY . .
 

현재 프로젝트 파일을 이미지 내부로 복사합니다.

RUN

이미지 빌드 과정에서 실행할 명령어

RUN npm install
 

빌드 시점에 패키지를 설치합니다.

CMD

컨테이너 실행 시 기본으로 실행할 명령어

CMD ["npm", "run", "dev"]
 

컨테이너가 시작될 때 실행됩니다.

8.3 Dockerfile은 왜 중요한가

Dockerfile이 중요한 이유는
이미지를 사람 손으로 직접 만드는 것이 아니라
코드처럼 재현 가능하게 만들 수 있기 때문입니다.

 

즉, Dockerfile이 있으면

  • 누구나 동일한 이미지 생성 가능
  • 배포 환경 재현 가능
  • 버전 관리 가능
  • 빌드 과정을 문서화할 수 있음

결국 Dockerfile은
이미지 빌드 과정을 코드로 관리하는 파일이라고 볼 수 있습니다.

9. 이미지는 어떻게 만들어지는가

Docker 이미지는 보통 다음 흐름으로 생성됩니다.

9.1 Dockerfile 작성

프로젝트 루트에 Dockerfile을 작성합니다.

9.2 이미지 빌드

docker build -t my-app .
 

이 명령어를 실행하면 Dockerfile을 기반으로 이미지가 생성됩니다.

9.3 컨테이너 실행

docker run -p 5173:5173 my-app
 

생성된 이미지를 실행하면 컨테이너가 됩니다.

즉, 전체 흐름은 다음과 같습니다.

Dockerfile
↓
docker build
↓
Docker Image
↓
docker run
↓
Docker Container
 
 

10. 이미지 이름은 어떻게 구성되는가

Docker 이미지 이름은 보통 아래 형태를 따릅니다.

 

[저장소 이름]/[이미지 이름]:[태그]
 

예를 들면 다음과 같습니다.

myrepo/my-app:1.0
 

각 부분의 의미는 다음과 같습니다.

  • 저장소 이름: 이미지가 저장되는 위치
  • 이미지 이름: 이미지의 역할
  • 태그: 버전 정보

태그를 생략하면 일반적으로 latest로 인식합니다.

 

즉, 이미지 이름은 단순한 문자열이 아니라
어디 저장되어 있고, 어떤 역할을 하며, 어떤 버전인지까지 포함하는 식별자입니다.

11. Registry와 Repository

이 둘은 이름이 비슷해서 많이 헷갈립니다.

11.1 Registry

Registry는 이미지를 저장하는 중앙 저장소입니다.

 

예를 들어 Docker Hub는 대표적인 Registry입니다.

 

즉, 이미지를 push 하고 pull 받는 서버입니다.

11.2 Repository

Repository는 Registry 안에서 관련 이미지들을 묶어두는 단위입니다.

 

하나의 프로젝트 폴더처럼 생각하면 이해하기 쉽습니다.

 

예를 들어 Docker Hub라는 Registry 안에
my-app이라는 Repository가 있고,
그 안에 1.0, 1.1, latest 같은 태그가 존재할 수 있습니다.

즉,

  • Registry = 전체 이미지 저장소
  • Repository = 특정 프로젝트 이미지 모음

입니다.

12. 왜 이미지를 만들어두면 편한가

 

이미지를 한 번 잘 만들어두면
다른 컴퓨터에서도 동일한 방식으로 쉽게 실행할 수 있습니다.

 

즉, 내 컴퓨터에서 동작하던 환경을
그대로 다른 환경으로 옮길 수 있습니다.

 

이 방식은 특히 다음 상황에서 강력합니다.

  • 협업 환경 통일
  • 배포 자동화
  • 서버 이전
  • 테스트 환경 재현

이미지를 Registry에 올려두면
다른 사람은 복잡한 설정 없이 pull 받아 실행만 하면 됩니다.

 

그래서 Docker는 개발 환경뿐 아니라
운영 환경과 CI/CD에서도 많이 사용됩니다.

13. 컨테이너는 하나의 역할만 맡는 것이 좋다

컨테이너를 사용할 때 자주 언급되는 원칙이 있습니다.

 

하나의 컨테이너는 하나의 역할에 집중하는 것이 좋다는 점입니다.

 

예를 들면 다음처럼 나누는 방식입니다.

  • 프론트엔드 컨테이너
  • 백엔드 컨테이너
  • 데이터베이스 컨테이너
  • 캐시 서버 컨테이너

이렇게 역할을 나누면 다음 장점이 있습니다.

  • 관리가 쉬움
  • 장애 범위 분리 가능
  • 확장 용이
  • 배포 단위 명확

즉, 컨테이너는 작고 분리된 단위로 설계할수록 관리가 쉬워집니다.

14. Docker Compose란?

실제 애플리케이션은 하나의 컨테이너만으로 끝나지 않는 경우가 많습니다.

예를 들면

  • 프론트엔드
  • 백엔드
  • 데이터베이스
  • Redis

처럼 여러 서비스가 함께 동작해야 할 수 있습니다.

 

이때 각각을 docker run으로 하나씩 띄우면
설정도 길어지고 관리도 어려워집니다.

 

Docker Compose는 이런 문제를 해결하기 위해 사용합니다.

여러 컨테이너와 그 설정을
하나의 YAML 파일에 정의하고,
한 번의 명령으로 함께 실행할 수 있게 해주는 도구입니다.

14.1 Compose 예시

 
version: "3"

services:
app:
build: .
ports:
- "5173:5173"

db:
image: postgres
 

이렇게 작성하면

docker compose up
 

명령어 한 번으로 여러 서비스를 함께 실행할 수 있습니다.

14.2 Compose의 핵심

핵심은 다음과 같습니다.

  • Dockerfile은 이미지를 만드는 파일
  • Compose는 실행할 서비스들을 정의하는 파일

즉, Dockerfile은 빌드 중심이고
Compose는 실행 구성 중심입니다.

15. Dockerfile과 Compose는 무엇이 다른가

둘은 비슷해 보이지만 역할이 다릅니다.

Dockerfile

  • 이미지 생성 방법 정의
  • 빌드 과정 담당

Compose 파일

  • 실행할 컨테이너 정의
  • 서비스 간 연결 담당

즉,

  • Dockerfile → 이미지를 어떻게 만들지
  • Compose → 컨테이너를 어떻게 실행할지

를 담당합니다.

Dockerfile vs Compose 비교

항목 Dockerfile Docker Compose
목적 이미지를 만드는 방법 정의 여러 컨테이너를 실행하고 관리
대상 단일 이미지 빌드 여러 서비스(컨테이너) 실행
중심 개념 build run
작성 파일 Dockerfile compose.yml 또는 docker-compose.yml
주요 내용 베이스 이미지, 파일 복사, 패키지 설치, 실행 명령 정의 서비스 정의, 포트, 볼륨, 네트워크, 환경변수 설정
사용 시점 이미지를 생성할 때 컨테이너를 실행할 때
대표 명령어 docker build docker compose up
결과 Docker Image 생성 여러 Container 생성 및 실행
비유 설계도 실행 계획표

16. 전체 흐름으로 다시 정리

지금까지의 내용을 한 번에 정리하면 Docker의 전체 흐름은 다음과 같습니다.

  1. Dockerfile 작성
  2. docker build로 이미지 생성
  3. 이미지를 Registry에 push
  4. 다른 환경에서 pull
  5. docker run 또는 docker compose up으로 컨테이너 실행

즉, Docker는
실행 환경을 코드처럼 정의하고,
그 결과물을 이미지로 만들고,
그 이미지를 어디서든 동일하게 실행할 수 있도록 해주는 구조입니다.

17. 정리

지금까지 Docker의 기본 개념과 구조를 정리해봤습니다.

 

Docker는 단순히 컨테이너를 띄우는 도구가 아니라,
애플리케이션 실행 환경을 함께 묶어서
어디서든 동일하게 실행할 수 있도록 해주는 플랫폼입니다.

 

핵심 개념을 다시 정리하면 다음과 같습니다.

  • Docker는 실행 환경을 통째로 패키징한다
  • Image는 실행 환경을 담은 패키지다
  • Container는 이미지를 실행한 상태다
  • Dockerfile은 이미지를 만드는 설계서다
  • Compose는 여러 컨테이너를 관리하는 실행 설정 파일이다
  • 이미지는 불변이며 여러 레이어로 구성된다

결국 Docker의 가장 큰 장점은
환경 차이를 줄이고, 실행과 배포를 단순하게 만든다는 점입니다.

🔗 다음 글

이 글에서는 Docker의 개념과 구조를 정리했습니다.

 

다음 글에서는
실제 프로젝트(self-interior-guide)에 Docker를 적용한 과정을 통해
이 개념들이 어떻게 활용되는지 살펴보겠습니다.

'Dev Tools' 카테고리의 다른 글

사이드 프로젝트에 Docker 적용해보기 (self-interior-guide)  (0) 2026.04.20
'Dev Tools' Related Articles more