[도커 & 쿠버네티스] 도커 동작 원리

목차 (OPEN)

• 🐋 도커의 동작 원리 요약
• 🏗️ 도커의 구조
• 📦 컨테이너 내부
• 🧩 운영체제의 두 가지 요소
• 📦 컨테이너의 구조
• 🏃🏻‍♀️ 컨테이너가 빠른 이유
• 🌐 컨테이너 안에 윈도우 프로그램을 못 넣는 이유
• 📚 결론

 

 

 

 

🐋 도커의 동작 원리 요약

오늘 알아볼 핵심 내용부터 짚고 넘어가보자.

 

도커 컨테이너는 단순히 프로세스의 집합이 아니라,

프로세스를 격리된 실행환경 안에서 동작하게 하는 기술이다.

 

여기서 핵심은 커널을 호스트 운영체제가 공유한다는 점이다.

컨테이너 내부에는 주로 유저랜드(쉘, 라이브러리 등)만 들어 있으며,

가상머신처럼 OS 전체를 새로 올리는 것이 아니기 때문에 훨씬 가볍고 빠르다.

 

다만, 도커는 리눅스 커널 기능에 의존하기 때문에

Windows나 macOS에서는 내부적으로 작은 리눅스 VM을 하나 실행한 뒤,

그 위에서 컨테이너를 돌리는 방식을 사용한다.

 

---

🏗️ 도커의 구조

도커의 구조를 이해하려면, 먼저 서버의 기본 모습부터 출발해야 한다.

 

우선 하나의 물리 서버(하드웨어)가 있고, 그 위에 리눅스 운영체제(호스트 OS)가 동작한다.

이 단계까지는 일반적인 서버와 전혀 다르지 않다.

 

그런데 일반적인 서버라면, 이 위에 곧바로 프로그램을 설치하고 실행하게 된다.

 

하지만, 도커 환경에서는 여기서 한 단계를 더 거친다.

호스트 OS 위에 도커 엔진이 올라가며, 이 도커 엔진이 컨테이너를 생성하고 관리하는 역할을 담당한다.

 

우리가 docker run ... 명령을 실행하면,

바로 이 도커 엔진이 프로그램 실행에 필요한 컨테이너를 준비하고 띄우는 것이다.

 

 

 

 

조금 더 쉬운 비유를 위해 주방 한가운데에 도커 엔진이라는 관리자가 서 있다고 생각해보자.

이 관리자는 요리사(프로그램)들이 한 주방을 뒤엉키지 않고 사용할 수 있도록

칸막이를 세워서 독립된 조리공간(컨테이너)을 마련해준다.

덕분에 여러 요리가 동시에 진행되더라도 서로 간섭하지 않고,

깔끔하게 분리된 상태에서 진행될 수 있을 것이다.

 

추가로, 물리 서버(하드웨어)는 주방이 들어있는 건물 자체라고 생각하면 되고,

서버 운영체제(리눅스 OS)는 주방의 기본 규칙과 설비라고 생각하면 된다.

대략 전기나 수도, 가스 같은 인프라를 제공하고, 주방에서 어떤 방식으로 요리를 할 수 있는지 정해주는 정도의 역할이다.

 

---

📦 컨테이너 내부

보통은 도커 컨테이너를 작은 리눅스라고 생각하지만,

실제로는 운영체제 전체(OS)를 통째로 담는 것은 아니다라는게 핵심이다.

 

컨테이너는 보통 호스트 리눅스 커널을 공유하고, 그 위에서 돌아가는 유저랜드만을 얹는다.

 

이 한 줄을 이해하는 게 쉽지 않으니 아래에서 단계별로 알아가보도록 하자.

 

---

🧩 운영체제의 두 가지 요소

'운영체제 = 커널 + 유저랜드'라고 보면 된다.

• 커널
  • 프로세스, 메모리, 파일, 네트워크, 디바이스를 관리하는 핵심 두뇌이다.
  • 하드웨어와 직접 대화한다.
• 유저랜드
  • 우리가 쓰는 쉘, 기본 명령들, 패키지 관리기, 표준 라이브러리 등 일반 프로그램이 기대하는 도구 상자이다.

 

---

 

📦 컨테이너의 구조

도커 컨테이너의 가장 중요한 특징 중 하나는 자체 커널이 없다는 점이다.

즉, 컨테이너는 호스트(물리 서버의 리눅스 운영체제) 커널을 그대로 공유한다.

 

그렇다면 컨테이너의 안은 텅 비어있을까?

정답은 ❌이다.

 

컨테이너 내부에는 보통 유저랜드라고 불리는 부분이 들어있다.

쉽게 말해서 술집에 가면 기본 안주를 주듯이, 컨테이너에도 기본 도구 세트가 깔려 나온다고 보면 된다.

여기에는 우리가 알고 있는 쉘(ex. bash, sh), 기본 유틸리티 명령어(ls, cp 등), 런타임 라이브러리(libc 같은 C 표준 라이브러리)가 포함되어 있다.

 

이러한 유저랜드가 하는 역할은

컨테이너 속에서 실행되는 프로그램이 내리는 명령(ex. "파일을 읽어라")을 호스트 리눅스 커널에 시스템콜 형태로 전달하는 것이다.

 

즉, 컨테이너 안의 프로그램은 "나만의 작은 리눅스" 위에서 동작하는 것처럼 보이지만,

실제로는 유저랜드를 통해 호스트 커널을 빌려 쓰는 구조라고 할 수 있다.

 

---

🏃🏻‍♀️ 컨테이너가 빠른 이유

가상머신(VM)은 운영체제를 통째로 올려야 하기 때문에 수 GB 단위의 디스크와 메모리가 필요하다.

 

반면, 컨테이너는 커널을 공유하기 때문에 운영체제 전체를 올릴 필요가 없고,

필요한 유저랜드 파일만 있으면 바로 실행할 수 있다.

따라서 컨테이너는 수 초 만에 시작할 수 있고, 수십 MB 정도의 가벼운 용량으로도 충분히 돌아간다.

 

즉, 컨테이너가 빠른 이유는 커널을 공유하기 때문이다.

 

---

🌐 컨테이너 안에 윈도우 프로그램을 못 넣는 이유

이 이유를 살펴보기 위해 중요한 점은 컨테이너는 호스트의 커널을 그대로 공유한다는 사실이다.

 

즉, 호스트가 리눅스라면, 컨테이너도 리눅스 커널을 써야 한다.

따라서 리눅스에서만 동작하는 프로그램은 잘 실행되지만,

윈도우 커널에 의존하는 프로그램(ex. .exe 파일)은 실행할 수 없는 것이다.

 

이처럼 컨테이너는 호스트 커널에 종속적이기 때문에

윈도우 커널이 없는 리눅스 컨테이너에서는 윈도우 전용 프로그램을 돌릴 수 없는 것이다.

 

---

📚 결론

컨테이너의 구조를 공부하면서 가장 크게 느낀 점은 컨테이너는 완전히 독립된 운영체제를 가진 가상머신이 아니라,

호스트 커널을 공유하면서도 자신만의 독립된 실행 환경을 제공한다는 점이었다.

 

처음에는 단순히 "컨테이너 = 작은 가상머신"이라고만 생각했는데,

실제로는 커널을 공유하고 필요한 유저랜드만 얹힌 얇고 효율적인 구조라는 점이 인상깊었다.

이를 통해서 컨테이너가 왜 빠르고 가벼운지, 어떻게 시스템 자원을 최소한으로 활용할 수 있는지를 명확히 이해할 수 있었다.

 

특히, 컨테이너 내부 프로그램이 마치 자신만의 운영체제 위에서 실행되는 것처럼 보이지만,

실제로는 시스템콜을 통해 호스트 커널을 빌려 쓰는 구조라는 점은 매우 흥미로웠다.

 

이 차이를 이해하고 나니, 앞으로 단순히 "도커는 가볍다"는 말이 아니라,

그 가벼움의 원리와 기술적 배경까지 설명할 수 있는 시각을 가지게 된 것 같다.