Kubernetes - 도커를 이해하기 위한 사전 지식과 핵심 개념
in DEV on DevOps, Kubernetes, Docker
도커는 개발-배포-운영의 경계를 허물며 효율적인 환경 일관성과 빠른 배포를 가능하게 해주는 컨테이너 기반 기술이다.
하지만 도커를 제대로 활용하려면 단순한 사용법이 아닌, 그 근간이 되는 운영체제 개념과 리눅스 커널 기술에 대한 이해가 꼭 필요하다.
이 포스트에서는 도커를 학습하기 전에 반드시 알고 있어야 할 사전 지식과 도커의 핵심 개념에 대해 알아본다.
목차
개발 환경
- Ubuntu 25.04
- Mac Apple M3 Max
- Memory 48 GB
1. 사전 기초 지식
도커를 이해하기 위해서는 운영체제, 프로그램, 스레드, 네임스페이스와 같은 개념을 먼저 이해해야 한다.
1.1. 운영체제(OS)
도커는 컨테이너 기술을 활용하여 경량화된 가상화 환경을 제공한다.
하지만 이 기술을 제대로 이해하고 사용하기 위해서는 먼저 컴퓨터의 가장 기본적인 구성요소인 운영체제에 대한 이해가 선행되어야 한다.
컴퓨터는 크게 두 가지 구성 요소르 나눌 수 있다.
- 하드웨어: CPU, RAM(주기억장치) 등 물리적 장치
- 소프트웨어: 하드웨어 위에서 동작하는 프로그램, 즉 운영체제와 애플리케이션
위 그림처럼 소프트웨어는 다시 운영체제와 애플리케이션으로 구분된다.
운영체제는 하드웨어와 애플리케이션 사이에서 다리 역할을 하며, 아래와 같은 기능을 수행한다.
- 하드웨어 자원(CPU, 메모리, 디스크 등) 관리
- 프로그램 실행 환경 제공(프로그램 스케쥴링)
- 사용자와 시스템 간 인터페이스 제공
운영체제는 내부적으로 여러 계층으로 구성된다.
- 커널
- 운영체제의 핵심
- 하드웨어 자원을 직접 제어 및 리소스 관리 담당
- 운영체제 라이브러리
- 시스템 콜 및 API 제공
- 예) glibc
- 운영체제 외 라이브러리
- 사용자가 설치한 공통 라이브러리
- 예) SSL, zlib 등
도커는 이 중에서 커널을 공유하면서 사용자 공간에서 독립적으로 실행되는 방식으로 동작한다.
셸(Shell)은 운영체제와 사용자 사이에서 명령어 기반으로 상호작용을 가능하게 해주는 프로그램이다.
- 셸은 운영체제의 껍질(Shell)이라는 의미에서 이름이 붙여짐
- 사용자가 터미널에 명령어를 입력하면 셸이 이를 해석하여 커널로 전달
- 대표적인 셸: bash, zsh, sh, fish
도커 명령어들도 결국 셸을 통해 실행되며, 컨테이너 내부에서의 기본 인터페이스 역시 셸이다.
운영체제와 애플리케이션 사이에는 셸이 존재하는데 말 그대로 운영체제를 껍질처럼 감싸고 있다. 셸은 운영체제와 사용자 사이에서 다리 역할을 하는 프로그램으로 사용자는 명령어를 입력함으로써 운영체제와 상호작용하며 다양한 작업을 수행한다. 현재 bash, zsh 등 다양한 종류의 셸이 있다.
1.2. 프로그램, 프로세스, 스레드
도커를 이해하려면 프로그램이 실행되는 방식, 그리고 실행 단위인 프로세스와 스레드의 개념을 확실히 이해해야 한다.
이 개념들은 컨테이너 내부에서 애플리케이션이 어떻게 실행되고, 어떤 방식으로 격리되고, 리소스를 공유하는지를 이해하는데 핵심적인 역할을 한다.
프로그램
프로그램은 실행 가능한 명령어들의 정적인 집합으로, 보통 디스크(HSS, SSD) 에 저장되어 있는 상태를 의미한다.
예를 들어 파워포인트 파일이나 myapp.jar 같은 애플리케이션 파일은 프로그램이다.
- 정적 상태
- 디스크에 저장되어 있음
- 실행 가능한 명령어들의 정적 모음
- 예) 파워포인트 실행 파일(.exe)
- 실행 전 상태
프로세스
프로세스는 실행 중인 프로그램을 의미하며, 동적인 상태의 프로그램이라고 볼 수 있다.
프로세스는 메모리(RAM) 에 적재되며, CPU 를 할당받아 실행된다.
- 동적 상태
- RAM 에 존재
- 실행 중인 프로그램 인스턴스
- 예) 파워포인트를 실행하여 열린 문서
- 운영체제가 스케쥴링하여 실행
디스크에 설치되어 있는 파워포인트는 프로그램에 해당하고, 파워포인트를 실행하여 나타나는 새 문서 파일은 프로세스에 해당한다.
멀티 프로세스(multitasking) 은 같은 프로그램을 여러 번 실행하여 서로 독립적인 프로세스를 여러 개 생성하는 구조이다.
스레드
스레드는 프로세스 내부에서 실제 작업을 수행하는 최소 실행 단위이다.
하나의 프로세스는 반드시 하나 이상의 스레드를 포함하며, 보통 처음 생성되는 스레드를 메인 스레드라고 한다.
- 프로세스 내부의 실행 흐름
- 프로세스 내에서 실제 작업을 수행하는 실행 흐름
- 예) 텍스트 렌더링, 사용자 입력 처리 등
- 메모리 공간(코드, 힙, 데이터 등)을 프로세스와 공유
- I/O 작업, 사용자 입력 처리 등을 병렬적으로 수행
예를 들어 파워포인트를 실행했을 때 스레드1은 텍스트 렌더링 처리, 스레드2는 사용자 입력처리를 한다면 하나의 프로세스에 2개의 스레드가 실행되고 있는 것이다. (= 하나의 프로세스 내부에서 동시에 실행되는 여러 흐름)
도커는 각 컨테이너 내부에서 하나 이상의 프로세스를 실행하며, 이 프로세스는 내부적으로 다수의 스레드를 포함할 수 있다.
이 구조를 이해하고 있어야 컨테이너의 상태 확인(docker top, ps aux), 프로세스 기반 리소스 모니터링, 멀티스레드 애플리케이션 실행 등을 정확히 분석할 수 있다.
1.3. 네임스페이스(Namespace)
도커의 핵심의 격리(Isolation)이다.
여러 개의 컨테이너가 하나의 호스트 운영체제 위에서 동시에 실행되면서도 서로 영향을 주지 않는 것이 가능하게 해주는 기술이 바로 리눅스의 네임스페이스이다.
네임스페이스는 리눅스 커널 기능 중 하나로, 프로세스가 사용할 수 있는 시스템 리소스를 분리하는 기술이다.(= 리눅스에서 리소스를 격리하는 커널 기능)
쉽게 말해 각각의 컨테이너가 마치 자신만의 독립된 환경에서 실행되는 것처럼 별도의 PID, 네트워크, 파일시스템 등을 갖도록 만들어주는 것이다.
<리눅스의 대표적인 네임스페이스 종류>
| 네임스페이스 | 이름 | 설명 |
|---|---|---|
| pid | Process ID | 프로세스 ID 공간을 분리하여, 각 컨테이너에서 PID 1부터 시작하도록 함 |
| net | Network | 컨테이너마다 독립적인 네트워크 인터페이스(IP, 포트 등) 을 할당 |
| ipc | IPC (Inter Process Communication) | 프로세스 간 통신(Shared Memory, Semaphore 등) 영역을 격리 |
| mnt | Mount | 파일시스템 마운트 포인트를 격리하며, 컨테이너마다 다른 파일 경로 구조 제공 |
| uts | UTS (Unix Timesharing System) | 호스트 이름, 도메인 이름 등의 시스템 식별자 분리 |
| user | User ID | 사용자와 그룹 ID 공간을 분리 (비권한 사용자 분리 가능) |
1.3.1. 도커에서 네임스페이스가 어떻게 사용되는가?
도커 컨테이너는 위의 네임스페이스 기능을 모두 활용한다.
컨테이너가 실행될 때 도커는 새로운 네임스페이스를 생성하고, 컨네이너 프로세스를 그 안에서 실행시켜 마치 독립된 컴퓨터처럼 동작하도록 만든다.
예를 들어:
- docker run 으로 컨테이너를 실행하면,
- 컨테이너 안의 프로세스는 자신만의 PID 1 을 가짐
- 외부 네트워크와 분리된 자체 IP 주소를 가짐
- 호스트의 파일시스템과 분리된 자체 디렉터리 구조를 가짐
즉,네임스페이스는 컨테이너별로 독립된 PID, 네트워크, 파일시스템 환경을 제공하여 충돌없는 병렬 실행, 가볍고 빠른 격리 환경 구현을 가능하게 해준다.
2. 도커 기초 지식
2.1. 도커란?
도커는 컨테이너라는 운영체제 수준의 가상화 기술을 기반으로 애플리케이션을 패키징하고 배포하는 플랫폼이다.(= 컨테이너 기반 가상화 플랫폼)
일반적으로 PaaS(Platform as a Service) 형태로 분류되며, 개발자가 인프라를 직접 관리하지 않고 애플리케이션과 데이터에만 집중할 수 있는 환경을 제공한다.
- 도커는 “애플리케이션 실행에 필요한 모든 구성요소(코드, 라이브러리, 환경 설정 등)”을 컨테이너라는 단위로 패키징하여,
- 어느 환경에서든 동일하게 실행되도록 만들어주는 가볍고 빠른 가상화 기술이다.
- 도커 엔진(Docker Engine)이 호스트 운영체제 위에 설치된다.
- 각 컨테이너는 해당 애플리케이션을 실행하는 독립된 환경을 가진다.
- 각 컨테이너는 격리되어 있으며, 자체 바이너리와 라이브러리를 포함하므로 의존성 충돌없이 독립적으로 실행된다.
이런 구조 덕분에 아래와 같은 이점이 있다.
- 로컬 개발 환경과 운영 환경이 동일 → 환경 일관성
- 컨테이너 단위의 배포 → 빠른 배포와 롤백
- 리소스 효율이 높음 → VM 보다 가볍고 빠름
<도커가 중요한 이유>
- 개발 환경의 표준화
- 팀원마다 다른 환경 설정없이 공통 컨테이너로 통일
- CI/CD 파이프라인 통합
- 테스트, 빌드, 배포를 컨테이너 기반으로 자동화
- 멀티 클라우드 지원
- AWS, GCP, Azure 어디서든 실행 가능
2.2. 컨테이너(Container)
소프트웨어를 개발하고 배포하는 과정에서 가장 큰 문제 중 하나는 환경 차이로 인한 실행 오류이다.
이를 해결하기 위해 등장한 것이 바로 컨테이너 기술이다.
컨테이너는 실생활에서의 화물 운송 시스템과 유사한 개념이다.
🛳️ 비유로 이해하기:
예전에는 배 위에 화물을 하나하나 직접 실었지만, 지금은 배 위에 화물을 실을 때 컨테이너 박스에 물건을 넣고 박스 단위로 운반한다.
이런 방식은 효율성과 표준화를 가져왔다.
소프트웨어에서도 마찬가지로, 코드, 라이브러리, 설정 파일 등을 하나의 “소프트웨어 컨테이너” 에 넣고 배포한다.
컨테이너는 게스트 OS 없이 경량 애플리케이션 환경을 제공하고,
도커는 컨테이너 기반 가상화 플랫폼으로 가볍고 빠르게 애플리케이션을 실행한다.
컨테이너 특징
- 코드 + 실행환경 + 라이브러리를 한데 묶은 패키지
- 운영체제 수준에서 격리된 독립 실행 환경
- 서로 다른 컨테이너끼리는 충돌 없이 동시에 실행 가능
컨테이너는 그 자체로 실행 가능한 패키지이며, 특정 애플리케이션을 실행하는데 필요한 모든 요소를 포함하고 있다.
컨테이너 장점
- 환경 일관성
- 빠른 배포
- 효율적인 리소스 사용
컨테이너와 MSA
컨테이너는 MSA 를 가능하게 만든 기반 기술이다.
- 각각의 기능을 독립적인 서비스(컨테이너)를 분리
- 서비스마다 개별 배포, 개별 스케일링 가능
- 서비스 간 통신은 네트워크를 통해 이루어짐
컨테이너 간 통신
컨테이너는 격리된 환경에서 실행되지만, 같은 호스트 운영체제 내에서 실행되기 때문에 네트워크를 통해 서로 통신할 수 있다.
도커에서는 기본적으로 브리지 네트워크를 통해 컨테이너 간 통신이 이루어진다.
필요에 따라 포트를 열거나, 사용자 정의 네트워크를 구성할 수 있다.
가상머신(VM)과의 비교
| 항목 | 컨테이너 | 가상머신 |
|---|---|---|
| 격리 수준 | 프로세스 수준 | 하드웨어 수준 |
| 성능 | 거의 네이티브 수준 | 상대적으로 무겁고 느림 |
| 부팅 시간 | 초 단위 | 분 단위 |
| 운영체제 | 호스트 OS 공유 | OS 별도 탑재 |
| 리소스 사용 | 효율적(공유) | 중복(낭비 발생) |
2.3. 가상화(Virtualization)
도커는 기존의 가상화 방식과는 완전히 다른 접근법으로 애플리케이션을 실행한다.
이 차이를 이해하려면 먼저 가상화의 기본 개념부터 알아야 한다.
가상화는 하나의 물리적 자원(서버, 디스크, 네트워크 등)을 논리적으로 분리하여 마치 여러 자원이 존재하는 것처럼 사용하는 기술이다.
- 하나의 컴퓨터에서 여러 운영체제를 실행
- 컴퓨팅 자원(CPU, 메모리 등)을 나누어 사용
- 효율적인 자원 활용 및 환경 격리 가능
이런 가상화를 실현하기 위해 여러 방식이 존재하며, 도커는 이 중 컨테이너 기반 가상화를 사용한다.
호스트 기반 가상화(Host Virtualization)
- 운영체제 위에 하이퍼바이저를 설치
- 하이퍼바이저를 통해 여러 개의 가상머신(VM) 생성
- 각 VM은 게스트 운영체제를 포함하여 완전한 독립 환경 제공
🛠️ 대표 도구: VirtualBox, VMware Workstation
💡 하이퍼바이저(Hypervisor)
- 가상 머신을 생성하고 관리하는 소프트웨어
- 예) VMware, VirtualBox, Hyper-V
- 하이퍼바이저는 보통 호스트 OS 위에 설치됨(Type 2), 또는 하드웨어 위에 직접 설치될 수도 있음(Type 1)
하이퍼바이저 기반 가상화(Bare-metal Hypervisor)
- 물리 서버 위에 직접 하이퍼바이저 설치
- 호스트 운영체제가 없음 (운영체제가 곧 하이퍼바이저)
- 따라서 부팅 시 가상머신을 선택하게 됨
- 성능은 뛰어나지만 관리가 복잡함
🛠️ 대표 도구: VMware ESXi, Microsoft Hyper-V, Xen
컨테이너 기반 가상화(Container Virtualization)
- 운영체제를 공유하면서 격리된 컨테이너를 실행
- 컨테이너 안에는 애플리케이션 + 필요한 바이너리/라이브러리만 포함
- 게스트 운영체제가 필요없음
🛠️ 대표 도구: Docker, Kubernetes
도커의 컨테이너 가상화과 다른 방식과 다른 이유
| 항목 | VM 기반 가상화 | 컨테이너 기반 가상화 |
|---|---|---|
| 운영체제 | 각 VM 에 개별 탑재 | 호스트 OS 공유 |
| 부팅 속도 | 느림 (분 단위) | 빠름 (초 단위) |
| 리소스 사용 | 무겁고 중복됨 | 경량, 공유 구조 |
| 실행 단위 | 운영체제 단위 | 애플리케이션 단위 |
| 이식성 | 제한적 | 매우 높음 (이미지화된 패키지로 이동 가능) |
📌 도커는 가상머신처럼 전체 운영체제를 포함하지 않고, 커널을 공유하면서 격리된 프로세스만 실행하기 때문에 훨씬 빠르고 가볍다.
2.3.1. 운영체제 vs 호스트 운영체제 vs 게스트 운영체제
운영체제
운영체제는 컴퓨터 하드웨어와 소프트웨어 자원을 관리하고, 사용자와 시스템 간의 인터페이스를 제공하는 기본적인 소프트웨어이다.
예) Windows, macOS, Linux, Android 등
<역할>
- CPU, 메모리, 디스크, 네트워크 자원 관리
- 파일 시스템 제공
- 프로세스와 스레드 관리
- 사용자 인터페이스 제공(CLI, GUI)
호스트 운영체제
가상화 환경에서 실제 물리적인 하드웨어 위에서 실행되고 있는 운영체제이다.
- 가상 머신을 실행하기 위한 기반 운영체제
- 예) Windows 위에서 VMware, VirtualBox 실행 → 이 Windows 가 호스트 OS
<역할>
- 하드웨어 자원을 직접 관리
- 가상화 소프트웨어(하이퍼바이저)를 통해 게스트 OS 에 자원 제공
게스트 운영체제
가상 머신 내부에서 실행되는 운영체제이다.
이 운영체제는 물리적 하드웨어가 아닌 가상화된 하드웨어 위에서 실행된다.
예) VirtualBox 위에서 Ubuntu 리눅스를 설치했다면, 이 Ubuntu 가 게스트 OS
<특징>
- 하드웨어 자원을 가상화된 형태로 인식
- 일반 OS 처럼 동작하지만, 실제 자원은 호스트 OS 를 통해 간접적으로 사용
| 구분 | 설명 | 예시 |
|---|---|---|
| 운영체제 | 하드웨어와 사용자/프로그램 사이를 중계하는 소프트웨어 | Windows, Linux, macOS |
| 호스트 운영체제 | 가상화 소프트웨어를 실행하는 실제 머신의 OS | Windows11(VMware 위에서 Ubuntu 실행 중) |
| 게스트 운영체제 | 가상 머신 내에 설치된 OS | Ubuntu 22.04 (VirtualBox 내 실행) |
2.4. 도커 구성 요소
도커는 겉으로 보면 간단한 docker run 명령어 하나로 컨테이너를 실행하는 툴처럼 보이지만, 사실 그 내부에서는 여러 컴포넌트들이 명확하게 역할을 분리하며 유기적으로 동작한다.
아래 그림은 컨테이너가 실행되기까지 필요한 도커 내부 구성 요소의 흐름을 나타낸 것이다.
Docker CLI(docker)
도커 클라이언트는 우리가 터미널에서 사용하는 docker build, docker run, docker ps 같은 명령어를 제공하는 도구이다.
- 사용자가 입력한 명령을 도커 데몬(dockerd) 에게 전달
- REST API 를 통해 도커 데몬과 통신
- CLI 와 데몬은 로컬 또는 원격에서도 통신 가능
📌 Ubuntu 나 macOS 터미널에서 사용하는 docker 명령어는 사실상 Docker CLI 이다.
Docker Daemon(dockerd)
dockerd 는 도커의 백그라운드 프로세스(데몬)로, 도커의 모든 주요 기능을 실제로 수행하는 엔진이다.
- 컨테이너, 이미지, 네트워크, 볼륨 등 전체 객체 관리
- Docker API 요청을 수신하고 처리
- 하위 런타임(containerd) 과 연결해 컨테이너 실행을 요청
쉽게 말해, Docker CLI 는 명령을 보내는 “사용자 인터페이스”이고,
dockerd 는 실제로 명령을 실행하는 “뇌” 역할이다.
containerd
containerd 는 도커 내부에서 컨테이너 실행을 관리하는 고수준 컨테이너 런타임이다.
- 컨테이너의 전체 생명주기를 관리
- 이미지 pull, 컨테이너 생성, 실행, 삭제, 네트워크, 스토리지
- OCI(Open Container Initiative) 사양을 따름
- 도커 뿐 아니라 Kubernetes, cri-o 등에서도 사용됨
containerd 는 단순히 실행만 담당하는 runc 보다 한 단계 상위의 런타임이다.
containerd-shim
containerd-shim 은 containerd 와 runc 사이에서 중간자 역할을 하는 경량 프로세스이다.
- containerd 가 컨테이너 실행 요청 시 runc 를 직접 실행하지 않고, shim 을 통해 실행
- 컨테이너 종료 이후에도 로그 수집이나 exit 코드 전달을 계속 처리
- containerd 가 죽더라도 컨테이너는 계속 동작 가능
shim 은 일종의 컨테이너 감시자 및 조정자 역할이라고 볼 수 있다.
runc
runc 는 실제 컨테이너 프로세스를 실행하는 저수준 런타임이다.
- 리눅스 네임스페이스, cgroups 를 설정
- 컨테이너를 실행 가능한 상태로 직접 시작
- 실행 이후에는 shim 에게 바톤을 넘기고 종료
runc 는 가볍고, 한 번 실행되면 종료되는 구조이다.
<각 컴포넌트의 역할 요약>
| 구성 요소 | 역할 요약 |
|---|---|
| Docker CLI | 명령어 입력 도구 |
| dockerd | 도커 데몬, API 처리 및 전체 관리 |
| containerd | 컨테이너 생명주기 전반 관리 |
| containerd-shim | 컨테이너 실행 후 후속 처리 담당 |
| runc | 실제 컨테이너 프로세스 실행 |
도커 실행 명령은 CLI → 데몬 → 런타임 계층으로 흘러간다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 장철원 저자의 한 권으로 배우는 도커&쿠버네티스를 기반으로 스터디하며 정리한 내용들입니다.
