컨테이너 네임스페이스 격리 (Container Namespace Isolation)

핵심 인사이트 (3줄 요약)

본질: 네임스페이스 (Namespace)는 하나의 리눅스 커널(OS)을 공유하면서도, 각 프로세스 그룹이 시스템 자원(PID, 네트워크, 마운트 등)을 자기 혼자만 독점하고 있는 것처럼 착각하게 만드는 논리적 격리(Isolation) 메커니즘이다.

가치: 무겁고 부팅이 느린 하이퍼바이저 기반의 가상 머신(VM)을 대체하여, 단 몇 초 만에 켜지고 수십 MB밖에 차지하지 않는 초경량 컨테이너(Docker, Kubernetes) 생태계를 폭발시킨 핵심 커널 기술이다.

융합: 네임스페이스가 컨테이너의 "시야(무엇을 볼 수 있는가)"를 제한하는 보이지 않는 벽이라면, Cgroups (Control Groups)는 컨테이너의 "체력(얼마나 쓸 수 있는가)"을 제한하는 족쇄 역할을 하며 이 둘의 결합이 현대 컨테이너 아키텍처의 완성이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 운영체제 수준의 가상화 기술. 커널의 전역(Global) 시스템 리소스를 프로세스별로 추상화하여 제공한다. 네임스페이스 안의 프로세스는 자기만의 독립된 인스턴스에서 돌아가는 것처럼 보이지만, 실제로는 밑단의 단일 호스트 커널 위에서 동작한다.
필요성(문제의식):
- 과거 chroot(체인지 루트)를 통해 파일 시스템의 뿌리를 가짜 폴더로 가두는 감옥(Jail) 기술이 있었지만, 이는 파일 경로만 속일 뿐 네트워크 포트 번호나 프로세스 ID(PID)는 호스트와 섞여 충돌을 일으켰다.
- 웹 서버 컨테이너와 DB 컨테이너가 둘 다 80포트를 열고 싶거나, 내 컨테이너에서 남의 컨테이너 프로세스를 kill 명령어로 죽여버리는 심각한 보안/충돌 문제가 발생했다.
- 해결책: "파일뿐만 아니라 프로세스 ID, 네트워크 인터페이스, 사용자 권한까지 모든 자원의 이름을 구역별로 완전히 분리해 버리자!"
💡 비유:
- 100명이 일하는 큰 사무실(호스트 OS)이 있다. 여기서 A부서와 B부서는 서로 완전히 독립된 회사처럼 일하고 싶어 한다.
- 네임스페이스는 이 큰 사무실 안에 '마법의 파티션(벽)'을 치는 것이다. A부서 파티션 안에 있는 직원은 자기 부서 사람들(PID)만 보이고, 자기 부서 전용 전화선(Network)과 서랍장(Mount)만 쓸 수 있어서 파티션 밖의 세상이 아예 존재하지 않는다고 느낀다.
등장 배경:
- 2002년 Linux 커널 2.4.19에 Mount 네임스페이스가 최초 도입 (전통적 chroot의 한계 극복).
- 이후 PID, NET, IPC 등 6대 네임스페이스가 리눅스 커널에 순차적으로 통합 (LXC 프로젝트).
- 2013년 Docker가 이 네임스페이스와 Cgroups라는 어려운 커널 기술을 누구나 쓰기 쉬운 랩퍼(Wrapper) 툴로 포장해 출시하면서 클라우드 네이티브 혁명이 시작됨.

  ┌─────────────────────────────────────────────────────────────┐
  │                 네임스페이스 적용 전후의 프로세스 시야 차이           │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [적용 전: Global 전역 공간]                                    │
  │  호스트 OS: PID 1(init), PID 2, PID 100(App), PID 200(DB)   │
  │   - App이 `ps` 명령어를 치면 1~200번까지 모든 프로세스가 다 보임.    │
  │   - App이 실수로 PID 200을 죽일 수 있음. (상호 간섭 심각)          │
  │                                                             │
  │  [적용 후: Namespace 로 격리된 공간]                             │
  │   ┌───────── 호스트 커널 (실제 PID 관리) ──────────┐             │
  │   │   실제 PID: 1000        실제 PID: 2000     │             │
  │   │  ┌────────────────┐ ┌────────────────┐ │             │
  │   │  │ Namespace A    │ │ Namespace B    │ │             │
  │   │  │ 가상 PID: 1 (App)│ │ 가상 PID: 1 (DB) │ │             │
  │   │  └────────────────┘ └────────────────┘ │             │
  │   └────────────────────────────────────────┘             │
  │                                                             │
  │   결과: A공간의 App은 자기가 시스템의 첫 번째 프로세스(PID 1)인 줄 앎. │
  │        밖의 호스트 프로세스나 B공간의 DB는 아예 존재 자체를 인식 못 함. │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 그림은 PID 네임스페이스의 환상(Illusion)을 보여준다. 호스트 운영체제(커널) 입장에서는 컨테이너 A의 프로세스가 PID 1000번, 컨테이너 B의 프로세스가 PID 2000번인 평범한 프로세스일 뿐이다. 그러나 네임스페이스라는 가상 안경을 씌워놓았기 때문에, 각 컨테이너 내부에서 ps를 치면 자신을 PID 1번(전지전능한 init 프로세스)으로 보게 된다. 이 격리성 덕분에 개발자는 다른 컨테이너의 존재를 전혀 신경 쓰지 않고 무결점의 독립 환경에서 앱을 짤 수 있게 되었다.

📢 섹션 요약 비유: 가상현실(VR) 고글을 쓴 사람 10명이 같은 거실(커널)에 서 있지만, 고글(네임스페이스) 화면에는 각자 자기 혼자 무인도나 우주선에 있는 것처럼 완벽한 환상을 보여주어 서로 절대 부딪히거나 싸우지 않게 격리하는 기술입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

리눅스의 6대 핵심 네임스페이스 (The 6 Namespaces)

컨테이너라는 마법을 완성하기 위해 리눅스 커널은 시스템의 구성 요소를 6개의 독립된 영역으로 쪼갰다. 최근 Cgroup과 Time 네임스페이스가 추가되어 8개로 늘었지만, 근간은 아래 6가지다.

네임스페이스 종류	영문 플래그	격리하는 대상 (무엇을 나누는가?)	내부 효과 및 실무 의미
Mount (마운트)	`CLONE_NEWNS`	파일 시스템 마운트 포인트	컨테이너마다 별도의 `/`, `/etc`, `/var` 디렉터리 트리를 가짐. `chroot`의 강력한 진화형.
PID (프로세스)	`CLONE_NEWPID`	프로세스 ID 번호 공간	컨테이너 내부의 최초 프로세스가 PID 1을 부여받음. 서로 다른 컨테이너의 프로세스를 볼 수 없음.
Network (네트워크)	`CLONE_NEWNET`	네트워크 인터페이스, IP, 포트, 라우팅 테이블	컨테이너마다 고유의 eth0 인터페이스와 IP를 가짐. 80포트를 열 개 컨테이너가 동시에 바인딩 가능.
IPC (프로세스 통신)	`CLONE_NEWIPC`	공유 메모리, 메시지 큐 (System V IPC)	A 컨테이너가 메모리에 올린 데이터를 B 컨테이너가 훔쳐보거나 덮어쓰는 것을 물리적으로 차단함.
UTS (호스트명)	`CLONE_NEWUTS`	호스트네임 (Hostname) 및 도메인 네임	한 대의 물리 서버 위에서도 100개의 컨테이너가 각각 `web-01`, `db-01` 등 서로 다른 컴퓨터 이름을 가짐.
User (사용자)	`CLONE_NEWUSER`	UID (User ID), GID (Group ID) 권한	컨테이너 내부에서는 자기가 막강한 `root(UID 0)`지만, 호스트 밖으로 나오면 권한 없는 `일반 유저(UID 1000)`로 매핑되어 보안 극대화.

컨테이너 생성과 커널 시스템 콜 (clone API)

도커(Docker)에서 docker run 명령어를 치면, 마법이 일어나는 것이 아니라 리눅스 커널의 특정 시스템 콜 API가 호출될 뿐이다. 핵심은 C언어의 clone() 함수다. 프로세스를 생성할 때 특별한 깃발(Flags)을 꽂아주는 것이다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 네임스페이스 격리를 통한 컨테이너 생성 매커니즘             │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [일반적인 프로세스 생성]                                             │
  │   fork() 호출 -> 호스트의 부모 프로세스와 환경(네트워크, 파일) 100% 공유    │
  │                                                                   │
  │   [컨테이너 프로세스 생성 (Docker 동작 원리)]                            │
  │   clone(child_func, stack,                                        │
  │         CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS |               │
  │         CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER, arg);        │
  │             ▲                                                     │
  │             │ 6개의 "격리 파티션 쳐라!" 라는 커널 플래그 전달               │
  │                                                                   │
  │   [커널의 내부 처리]                                                  │
  │    1. VFS 마운트 테이블 새로 생성 (Mount NS)                          │
  │    2. 가상 네트워크 인터페이스(veth) 쌍 생성 후 할당 (Net NS)              │
  │    3. PID 맵핑 테이블 생성 (PID NS)                                   │
  │    4. 새로운 격리 환경 안에서 child_func (/bin/sh 또는 앱) 실행!           │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 도커 엔진은 겉포장지일 뿐, 컨테이너 격리의 실제 일꾼은 리눅스 커널의 clone() 시스템 콜이다. CLONE_NEW... 플래그들을 인자로 넘기면, 커널은 이 프로세스 전용으로 완전히 빈 백지상태의 자원 관리 테이블(네트워크 포트, 마운트 트리 등)을 램 메모리 상에 새로 찍어낸다. 이것이 하이퍼바이저 방식과 결정적으로 다른 점이다. 거대한 OS 커널 전체를 통째로 로딩할 필요 없이, 커널 내부에 자원 관리 꼬리표(Table)만 하나 추가하기 때문에 0.1초 만에 컨테이너가 켜지는 초경량성을 확보하게 된다.

📢 섹션 요약 비유: 회사에 신입 사원이 들어왔을 때 건물(OS)을 새로 하나 지어주는 게 아니라, "새로운 사원증, 독립된 내선 전화번호, 파티션"만 묶어서(Clone 플래그) 빠르고 효율적으로 업무 환경을 세팅해주는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

격리 기술의 3단계 발전사 (Chroot vs Namespace vs Hypervisor)

비교 항목	1세대: Chroot (감옥)	2세대: Container (네임스페이스)	3세대: VM (하이퍼바이저)
격리 대상	파일 디렉터리 구조	프로세스 관련 OS 자원 (6대 NS)	하드웨어 칩 (CPU, 메모리)
운영체제 공유	Host OS 커널 공유	Host OS 커널 100% 공유	별도의 Guest OS 부팅 (공유 X)
보안 약점	`../../` 트릭 등으로 감옥(Jail) 탈출이 매우 쉬움	커널 취약점(Privilege Escalation) 발생 시 모든 컨테이너 동시 해킹 위험	하드웨어 링 격리로 가장 안전함 (탈출 불가능에 가까움)
초기화 속도	즉각적	매우 빠름 (밀리초 단위)	느림 (몇 분 소요, OS 부팅 과정 거침)
실무 비유	방에 가두고 밖을 못 보게 창문만 막음	방음벽을 치고 개인용 전화, 주소지까지 따로 줌	아예 땅을 사서 완전히 다른 독립 건물을 지어줌

네임스페이스와 Cgroups의 상호보완성 (과목 융합)

컨테이너를 완벽한 '가상 머신'처럼 착각하게 만들려면, 네임스페이스 하나로는 부족하다. 리눅스의 **Cgroups (Control Groups)**라는 기능이 짝궁으로 붙어야 비로소 컨테이너가 완성된다.

  ┌─────────────────────────────────────────────────────────┐
  │         현대 컨테이너 아키텍처의 양대 기둥: Namespace + Cgroups │
  ├─────────────────────────────────────────────────────────┤
  │                                                         │
  │     [ Namespace (격리) ]        [ Cgroups (통제) ]      │
  │     "무엇을 볼 수 있는가?"         "얼마나 쓸 수 있는가?"      │
  │            │                          │                 │
  │            ▼                          ▼                 │
  │     - 파일, 네트워크 분리         - CPU 사용량 30% 제한    │
  │     - PID, 사용자 분리           - RAM 최대 1GB 제한      │
  │     - IPC 메모리 차단            - 디스크 I/O 속도 통제     │
  │            │                          │                 │
  │            └─────────┬────────────────┘                 │
  │                      ▼                                  │
  │             🚀 안전하고 통제된 [컨테이너] 완성                 │
  │                                                         │
  │ ※ Namespace만 있고 Cgroups가 없다면?                       │
  │    -> 컨테이너 안의 앱이 무한루프 버그에 빠지면, 호스트 CPU의    │
  │       100%를 독식해버려 옆 컨테이너와 시스템 전체가 죽어버림!     │
  └─────────────────────────────────────────────────────────┘

[다이어그램 해설] 네임스페이스는 논리적인 눈가리개일 뿐, 물리적인 자원(CPU 클럭, 램 용량)의 한도를 정해주지는 못한다. 만약 네임스페이스만으로 컨테이너를 만들면, 어느 한 컨테이너 안에서 메모리 누수(OOM)나 디도스(DDoS) 공격이 발생할 때 호스트 시스템 전체의 체력이 고갈되는 '시끄러운 이웃(Noisy Neighbor)' 사태가 벌어진다. Cgroups는 커널 스케줄러와 메모리 관리자 레벨에서 특정 프로세스 트리의 자원 상한선을 칼같이 잘라버리는 역할을 한다. Docker나 Kubernetes는 이 두 가지 커널 기술의 톱니바퀴를 정교하게 엮어놓은 오케스트레이션 도구다.

📢 섹션 요약 비유: 네임스페이스가 감방의 '두꺼운 콘크리트 벽과 블라인드'라면, Cgroups는 수감자에게 매일 배급되는 '정량의 식사와 물'입니다. 벽만 쳐놓고 식량을 무제한으로 열어두면 식량 창고 전체가 거덜 나기 때문에 두 가지 통제가 동시에 필요합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오 및 운영 안티패턴

시나리오 — Docker 컨테이너 탈출 (Container Breakout) 보안 사고: 앱 개발팀이 디버깅의 편의성과 네트워크 설정을 마음대로 바꾸기 위해 도커 컨테이너를 실행할 때 --privileged 옵션을 주고 호스트의 / 경로를 컨테이너 내부에 볼륨 마운트했다.
- 원인 분석: --privileged 옵션을 켜면 커널은 네임스페이스가 제공하던 강력한 제약(Capabilities)을 모두 풀어버려, 컨테이너 안의 루트(UID 0)가 호스트의 실제 루트(UID 0)와 동일한 막강한 권한을 쥐게 된다. 해커가 웹 앱 취약점으로 컨테이너에 들어오면 네임스페이스 벽을 허물고 호스트 서버 전체를 장악한다.
- 아키텍트 판단: 상용 서비스 환경에서는 절대 Privileged 컨테이너 실행을 허용해서는 안 되며, 쿠버네티스의 **Pod Security Admission (PSA)**을 통해 원천적으로 생성을 차단(Enforce)해야 한다. 최선의 방어책은 User 네임스페이스를 활성화하여, 컨테이너 내부의 Root 계정이 호스트 밖에서는 권한 없는 nobody(UID 100000)로 매핑되게끔 권한을 완전히 분리(Remapping)하는 것이다.
시나리오 — 마이크로서비스 간의 초고속 네트워크(IPC) 통신 필요: 동일한 머신 위에 떠 있는 프론트엔드 컨테이너와 인메모리 DB 컨테이너가 TCP 소켓으로 통신하다 보니 커널 네트워크 스택을 타느라 레이턴시 오버헤드가 크다.
- 아키텍트 판단 (Namespace 공유 기법): 격리가 원칙이지만, 예외적으로 효율을 위해 벽을 허물 수 있다. 쿠버네티스의 Pod(파드) 개념이 바로 이것이다. Pod 내부에 배치된 컨테이너들은 **Network 네임스페이스와 IPC 네임스페이스를 서로 공유(Share)**하도록 커널 설정이 조정된다. 따라서 밖으로 나갈 필요 없이 localhost(127.0.0.1) 루프백 주소와 공유 메모리(Shared Memory)를 통해 초고속으로 통신할 수 있는 유연한 아키텍처가 실현된다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 Kubernetes Pod 내부의 네임스페이스 공유 구조              │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [ Kubernetes Pod 단위 격리 벽 ]                                     │
  │   ┌───────────────────────────────────────────────────────────┐   │
  │   │  Network NS (공유): 192.168.1.10, localhost               │   │
  │   │  IPC NS (공유): System V Shared Memory 영역               │   │
  │   │                                                           │   │
  │   │     [컨테이너 A (Web)]            [컨테이너 B (DB)]             │   │
  │   │   - PID NS: 분리됨                - PID NS: 분리됨             │   │
  │   │   - Mount NS: 분리됨              - Mount NS: 분리됨           │   │
  │   │     (내부에서 포트 8080 엶)        (내부에서 포트 3306 엶)        │   │
  │   │           │                          │                    │   │
  │   │           └────── localhost 통신 ─────┘                    │   │
  │   │                 (네트워크 스택 공유)                         │   │
  │   └───────────────────────────────────────────────────────────┘   │
  │                                                                   │
  │   결과: 파일이나 프로세스 트리(Mount/PID)는 안전하게 격리하면서도,           │
  │        효율적인 통신을 위해 네트워크(NET/IPC) 장벽만 선택적으로 허물어냄.     │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 도커는 1컨테이너 = 1앱 철학으로 모든 네임스페이스를 완벽히 격리하지만, 쿠버네티스는 Pod라는 더 큰 봉투를 도입했다. 위 그림처럼 Pod 안에 있는 두 컨테이너는 동일한 IP 주소를 가지며 localhost로 통신한다. 이는 리눅스 커널의 네임스페이스가 6개로 쪼개져 있는 모듈형 구조이기 때문에 가능한 마법이다. "PID와 Mount는 찢고, Net과 IPC는 합쳐라"라는 식의 선택적 레고 블록 조립이 현대 마이크로서비스 설계의 극한의 유연성을 제공한다.

도입 체크리스트

보안 격리: 호스트의 특정 폴더를 마운트할 때, 악성코드 전파를 막기 위해 반드시 Read-Only(RO) 옵션을 켜서 파일 시스템 네임스페이스를 보호하고 있는가?
Zombie 프로세스 사냥: 컨테이너 안의 PID 1번 프로세스(예: Node.js)는 UNIX의 init 프로세스처럼 자식 프로세스가 죽었을 때 찌꺼기를 치워주는(Reaping) 역할을 기본적으로 하지 못한다. 이로 인해 좀비 프로세스가 쌓여 컨테이너가 죽는 걸 방지하기 위해 tini나 dumb-init 같은 초경량 PID 1 프록시를 래핑하여 사용하고 있는가?
📢 섹션 요약 비유: 각 부서를 파티션으로 완벽히 가르더라도, 필요하다면 천장 위 빈 공간으로 두 부서 간 직통 파이프(네트워크 공유) 하나 정도는 뚫어주어 문서 전달(데이터 통신)을 극도로 빠르게 만드는 유연한 사무실 인테리어 기법입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	VM (하이퍼바이저 기반)	Container (네임스페이스 기반)	개선 효과
정량 (부팅/스케일링 시간)	수 분(OS 전체 부팅 필요)	밀리초(ms) ~ 수 초 이내	트래픽 폭증 시 Auto-scaling 즉각 대응 가능
정량 (서버 집적도 Density)	물리 서버당 수십 개의 VM	물리 서버당 수백~수천 개의 컨테이너	인프라 운용 비용(TCO) 획기적 절감
정성 (환경 일관성)	개발자 PC와 운영 서버의 OS 환경 불일치	'Build Once, Run Anywhere' 달성	"제 PC에선 되는데요?"라는 개발/운영 마찰 완전 종식

미래 전망

MicroVM 과의 결합 (Kata Containers, Firecracker): 네임스페이스 기반의 컨테이너는 가벼운 대신, 단일 호스트 커널을 공유하기 때문에 커널 제로데이 취약점이 터지면 모든 컨테이너가 해킹당하는 결정적 보안 약점(Kernel Exploit)을 지닌다. 이를 해결하기 위해 최근에는 부팅 시간이 10ms에 불과한 초경량 하이퍼바이저(MicroVM) 안에 컨테이너를 가두어, 속도와 하드웨어 레벨의 보안 격리성을 동시에 잡는 융합 기술이 표준으로 자리 잡고 있다.
eBPF를 통한 네임스페이스 모니터링: 촘촘한 네임스페이스 벽 때문에 기존 보안 도구들이 컨테이너 내부의 네트워크나 파일 이벤트를 들여다보지 못하는 '가시성(Visibility) 사각지대'가 생겼다. 이를 커널 레벨에서 우회하여 초고속으로 추적하는 eBPF 기술이 클라우드 네이티브 보안(Cilium 등)의 판도를 바꾸고 있다.

참고 표준

OCI (Open Container Initiative): Docker의 기술 독점을 막고, 런타임(runc)과 이미지 포맷을 어떤 도구에서도 호환되게 만든 리눅스 파운데이션 산하의 개방형 컨테이너 표준 스펙.
Linux Capabilities: 루트(Root) 권한을 잘게 쪼개어, 컨테이너 안의 프로세스에 꼭 필요한 시스템 권한(예: 포트 오픈)만 부여하고 위험한 권한(시스템 시계 변경 등)은 드랍(Drop)시키는 OS 커널 보안 표준.

네임스페이스는 거대한 덩어리였던 운영체제를 레고 블록처럼 분해하여, 프로세스 하나하나에 맞춤형 환상을 제공하는 마스터피스다. 이 작고 정교한 커널 기능 하나가 전 세계의 소프트웨어 배포 패러다임을 통째로 바꾸었으며, 클라우드 컴퓨팅의 역사를 가상머신(IaaS)에서 컨테이너 오케스트레이션(PaaS/CaaS) 시대로 견인했다.

📢 섹션 요약 비유: 수백 명의 여행객(앱)에게 각자 무거운 개인용 캠핑카(VM)를 끌고 다니게 하는 대신, 거대한 KTX(커널) 안에 개인용 커튼과 모니터(네임스페이스)를 달아주어 빠르고 가볍게 목적지까지 이동시키는 현대 IT 물류의 대혁명입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Cgroups (Control Groups)	네임스페이스가 자원의 격리(벽)를 담당한다면, Cgroups는 CPU/메모리 할당량(배급량)을 통제하여 컨테이너 아키텍처의 양대 기둥을 이룬다.
Chroot (Change Root)	마운트 네임스페이스의 조상 격인 기술로, 파일 시스템의 최상위 폴더를 가짜로 지정해 앱을 가두는 고전적인 감옥(Jail) 방식이다.
OCI 런타임 (runc)	도커와 쿠버네티스의 밑단에서 실제로 리눅스 커널의 clone() 시스템 콜을 날려 네임스페이스 격리를 수행하는 오픈소스 저수준 엔진이다.
하이퍼바이저 (Hypervisor)	하드웨어 칩 레벨에서 Guest OS 전체를 분리해내는 방식으로, OS 레벨 격리인 네임스페이스보다 무겁지만 보안성은 훨씬 강력하다.
컨테이너 탈출 (Container Breakout)	해커가 커널 취약점이나 잘못된 설정(Privileged 모드)을 뚫고 네임스페이스 벽을 허물어 호스트 OS의 권한을 탈취하는 치명적 해킹 기법이다.

👶 어린이를 위한 3줄 비유 설명

커다란 사무실(컴퓨터) 안에 100명의 직원이 섞여서 일하면 서로 말소리도 섞이고 실수로 남의 서류를 버리는 일이 생겨요.
그래서 '네임스페이스'라는 투명한 마법의 유리방을 사람마다 씌워줬어요! 이 방에 들어가면 밖의 사람은 투명 인간처럼 아예 안 보이고, 나 혼자 회사에 있는 것처럼 느껴져요.
덕분에 100명이 각자 자기만의 완벽한 사무실(컨테이너)을 가진 것처럼 맘 편하게 일할 수 있어서, 똑똑한 도커(Docker) 고래가 이 마법을 이용해 컴퓨터 세상을 엄청나게 발전시켰답니다!