667. 컨테이너 런타임 (runc) HW 네임스페이스

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

본질: runc는 여러 리눅스 네임스페이스를 조합해 각 컨테이너에 /dev, 네트워크 인터페이스, 프로세스 번호, 호스트명 같은 HW (Hardware) 인접 자원의 "보이는 세계"를 따로 만들어 주는 런타임이다.

가치: 별도 커널이나 가상 하드웨어를 부팅하지 않고도 격리된 실행 환경을 빠르게 만들 수 있어, 높은 배치 밀도와 빠른 배포 속도를 동시에 얻는다.

판단 포인트: 네임스페이스는 가시성과 식별자를 분리하는 기술이지 물리 자원을 새로 만드는 기술이 아니므로, 자원 한도는 cgroups (Control Groups), 강한 보안 경계는 마이크로 가상 머신과 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

먼저 용어를 분명히 할 필요가 있다. "HW 네임스페이스"는 리눅스 커널의 공식 서브시스템 이름이라기보다, runc가 네임스페이스를 이용해 하드웨어와 맞닿아 있는 시스템 자원의 가시성을 분리하는 방식을 설명하는 관점이다. 즉 실제 중앙 처리 장치 (Central Processing Unit, CPU)나 메모리를 새로 만드는 것이 아니라, 컨테이너마다 "어떤 장치와 식별자가 보이는가"를 다르게 만드는 것이다.

runc는 Open Container Initiative (OCI) 표준의 대표 런타임 구현으로, 컨테이너 생성 시 여러 네임스페이스를 한꺼번에 설정한다. 이 과정을 통해 컨테이너는 자신만의 프로세스 트리, 네트워크 인터페이스, 마운트 트리, 호스트명, 사용자 매핑을 갖게 된다. 같은 호스트 커널을 공유하지만, 프로세스 입장에서는 마치 자신만의 작은 운영체제 안에서 실행되는 것처럼 보인다.

이런 분리가 필요한 이유는 컨테이너가 공유 커널 위에서 돌아가기 때문이다. 네임스페이스가 없다면 한 프로세스는 호스트의 모든 네트워크 인터페이스와 프로세스 목록, 장치 파일을 그대로 볼 수 있고, 이는 충돌과 보안 문제를 바로 일으킨다. runc의 HW 네임스페이스 관점은 바로 이 "보이는 표면"을 잘라 내는 데 초점이 있다.

📢 섹션 요약 비유: runc 네임스페이스는 같은 대형 창고 안에 칸막이를 세우는 일과 같다. 건물은 하나지만, 각 팀은 자기 구역만 보이니 서로의 물건에 쉽게 손대지 못한다.

Ⅱ. 아키텍처 및 핵심 원리

runc가 만드는 격리는 하나의 마법 스위치가 아니라 여러 네임스페이스의 조합이다. 특히 하드웨어 관점에서 중요한 것은 mount namespace, network namespace, PID (Process Identifier) namespace, IPC (Inter-Process Communication) namespace, user namespace다. 컨테이너 네트워크는 보통 가상 이더넷 (virtual Ethernet, veth) 쌍으로 호스트와 연결된다. 이 각각이 /dev, 네트워크 카드, 프로세스 번호, 공유 메모리, 권한 해석 방식을 다르게 만든다.

네임스페이스	분리 대상	HW 관점에서 의미
Mount namespace	루트 파일 시스템과 마운트 트리	`/dev`, `/proc`, `/sys` 노출 범위를 다르게 만듦
Network namespace	네트워크 인터페이스, 라우팅, 포트	컨테이너마다 독립된 `lo`, `eth0`, 방화벽 규칙 제공
PID namespace	프로세스 번호 공간	컨테이너 내부에서는 자기 프로세스만 보이게 함
IPC namespace	공유 메모리와 세마포어	다른 컨테이너의 메모리 채널과 충돌 방지
User namespace	UID (User Identifier) / GID (Group Identifier) 매핑	컨테이너의 root를 호스트의 비특권 사용자로 변환 가능

아래 그림은 runc가 만드는 "가시성 격리"를 단순화한 것이다.

┌──────────────────────── Host kernel ────────────────────────┐
│ physical NICs, device nodes, global PID space, host mounts │
└───────────────────────────┬─────────────────────────────────┘
                            │ runc creates namespaces
                            ▼
┌────────────────────── Container view ───────────────────────┐
│ net ns   : lo + veth as eth0                               │
│ mount ns : own rootfs + selected /dev nodes                │
│ pid ns   : process 1 starts inside container               │
│ ipc ns   : isolated shm/sem                                │
│ user ns  : remapped ids                                    │
└─────────────────────────────────────────────────────────────┘

핵심은 "보이는 장치"와 "실제 물리 장치"가 같지 않다는 점이다. 예를 들어 network namespace 안의 eth0는 보통 가상 이더넷 (virtual Ethernet, veth) 쌍의 한쪽 끝이고, 다른 끝은 브리지나 가상 스위치에 붙는다. 또한 mount namespace는 전체 /dev를 보여 주는 대신, 필요한 장치 노드만 bind mount 하거나 새로 만들어 노출한다. 즉 컨테이너는 하드웨어를 직접 소유하는 것이 아니라, 하드웨어 접근 창구를 재구성한 뷰를 받는다.

runc가 빠른 이유도 여기서 나온다. 하이퍼바이저처럼 새 커널을 부팅하는 대신 기존 커널 안에서 clone, unshare, setns 계열 시스템 호출로 실행 문맥을 갈라내기 때문에, 격리는 충분히 강하면서도 시작 비용이 낮다. 하지만 공유 커널이라는 사실은 여전히 남아 있으므로, 네임스페이스만으로는 커널 취약점이나 자원 고갈 문제까지 모두 해결하지 못한다.

📢 섹션 요약 비유: 네임스페이스는 놀이공원 지도에 색깔별 구역을 칠하는 것과 같다. 사람마다 보는 지도는 다르지만, 실제 놀이공원 땅 자체가 여러 개로 쪼개지는 것은 아니다.

Ⅲ. 비교 및 연결

runc의 HW 네임스페이스를 정확히 이해하려면 cgroups와 마이크로 가상 머신을 함께 비교해야 한다. 네임스페이스는 "무엇이 보이는가"를 바꾸고, cgroups는 "얼마나 쓸 수 있는가"를 제한하며, 마이크로 가상 머신은 아예 커널 경계를 따로 만든다. 이 셋을 같은 격리 기술로 뭉뚱그리면 설계 판단이 흐려진다.

관점	`runc` 네임스페이스	cgroups	마이크로 가상 머신
핵심 역할	이름공간과 가시성 분리	사용량과 우선순위 제한	커널·가상 하드웨어 경계 분리
커널 공유 여부	공유	공유	비공유
시작 비용	매우 낮음	매우 낮음	더 높음
HW 관점 장점	장치/인터페이스 뷰 분리	CPU·메모리·입출력 (Input/Output, I/O) 통제	가장 강한 격리
HW 관점 한계	실제 HW 독립성은 약함	가시성 분리는 못 함	오버헤드와 운영 복잡도 증가

여기서 중요한 기술적 사실 하나는, 리눅스에 "device namespace"라는 단일 기능이 따로 있는 것은 아니라는 점이다. 우리가 컨테이너에서 장치가 분리된다고 느끼는 이유는 mount namespace, network namespace, user namespace, capability drop, device cgroup이 함께 작동하기 때문이다. 즉 runc의 HW 네임스페이스는 하나의 커널 스위치가 아니라 여러 격리 수단의 합성 결과다.

그래서 runc는 빠르고 실용적이지만, 적대적인 멀티테넌트 보안 경계를 제공하는 데는 한계가 있다. 신뢰할 수 있는 내부 서비스는 네임스페이스와 cgroups 조합만으로도 충분한 경우가 많지만, 서로 다른 고객의 불신 워크로드를 한 노드에 섞는다면 마이크로 가상 머신이나 confidential container 계열까지 검토해야 한다.

📢 섹션 요약 비유: 네임스페이스는 커튼으로 시야를 가르는 기술이고, cgroups는 식판 배식량을 정하는 기술이며, 마이크로 가상 머신은 아예 방을 따로 짓는 기술이다.

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

실무에서 runc HW 네임스페이스는 주로 쿠버네티스 노드의 기본 격리층으로 사용된다. 예를 들어 컨테이너 네트워크 인터페이스 플러그인이 각 Pod에 veth를 연결하면, Pod 내부 프로세스는 그것을 자기 전용 eth0로 본다. 저장소 쪽에서는 root file system과 필요한 장치 노드만 노출해, 애플리케이션이 호스트 전체 파일 시스템을 직접 보지 못하게 한다.

보안 강화를 원한다면 user namespace와 seccomp (secure computing mode)를 함께 보는 것이 좋다. user namespace를 쓰면 컨테이너 내부 root가 호스트에서는 비특권 사용자로 매핑되고, seccomp는 허용된 시스템 호출만 통과시켜 커널 공격 표면을 줄인다. 반대로 --privileged, hostNetwork, hostPID 같은 옵션은 네임스페이스 격리의 상당 부분을 스스로 해제하는 선택이므로, 성능이나 운영 편의를 위해 쓸 때도 위험을 명확히 인지해야 한다.

실무 체크리스트

컨테이너에 전체 /dev를 bind mount 하지 않고 필요한 장치만 노출했는가?
hostNetwork, hostPID 사용이 정말 필요한가, 아니면 단순 편의인가?
rootless 또는 user namespace 매핑으로 호스트 권한 상승 경로를 줄였는가?
자원 제한은 다음 단계인 cgroups에서 별도로 설정했는가?

대표 안티패턴

네임스페이스만 믿고 CPU, 메모리, I/O 고갈 방어를 하지 않는 경우
문제 해결이 쉬워 보인다는 이유로 --privileged를 습관적으로 사용하는 경우
호스트의 /var/run/docker.sock 같은 민감한 제어 소켓을 그대로 노출하는 경우
📢 섹션 요약 비유: 네임스페이스 운영은 전시장 진열장 배치와 같다. 관람객이 볼 유리창과 출입문을 잘 설계해야 안전하지, 문을 전부 열어 둔 채 칸막이만 세워서는 의미가 없다.

Ⅴ. 기대효과 및 결론

runc 기반 HW 네임스페이스의 가장 큰 효과는 빠른 시작과 높은 밀도다. 같은 커널 위에서 수많은 컨테이너가 각자 다른 네트워크 인터페이스와 파일 시스템 뷰를 가진 것처럼 동작하므로, 서비스 배포 속도와 자원 활용도가 높다. 또한 운영자는 가상 머신을 매번 부팅하지 않고도 애플리케이션 단위 격리를 손쉽게 자동화할 수 있다.

하지만 이 격리는 어디까지나 공유 커널 위의 가시성 분리라는 전제를 가진다. 따라서 자원 통제는 cgroups가, 강한 보안 경계는 마이크로 가상 머신이나 추가 보안 계층이 담당해야 한다. 즉 runc 네임스페이스를 하드웨어 가상화 자체로 착각하면 과신이 된다.

기억해야 할 핵심은 간단하다. runc의 HW 네임스페이스는 "하드웨어 접근 표면을 잘라 내는 빠른 소프트웨어 격리층"이다. 무엇을 보게 할지 정리하는 데 뛰어나지만, 무엇을 얼마나 쓰게 할지와 얼마나 깊이 믿을 수 있는지까지는 다른 기술과 함께 설계해야 한다.

📢 섹션 요약 비유: runc 네임스페이스는 같은 운동장을 선으로 나눠 각 팀 경기장을 만드는 것과 같다. 경계선 덕분에 게임은 빨리 시작되지만, 공 사용량 규칙과 안전펜스는 따로 세워야 한다.

📌 관련 개념 맵

개념	연결 포인트
Mount namespace	`/dev`, `/proc`, `/sys` 등 장치 인접 파일 시스템 뷰를 분리
Network namespace	컨테이너마다 독립된 인터페이스와 라우팅 테이블을 제공
User namespace	컨테이너 내부 권한과 호스트 권한을 다르게 해석하게 만듦
Device cgroup	네임스페이스가 만든 장치 뷰에 실제 접근 제약을 더함
Seccomp	커널 공격 표면을 줄여 네임스페이스 격리를 보강

📈 관련 키워드 및 발전 흐름도

chroot / jail
    │
    ▼
Linux namespace
    │
    ▼
OCI + runc
    │
    ▼
rootless container + seccomp hardening
    │
    ▼
microVM / confidential container

이 흐름은 "파일 시스템 격리 → 이름공간 분리 → 표준 런타임화 → 권한 축소 → 더 강한 경계 추가"로 컨테이너 격리가 진화하는 방향을 나타낸다.

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

runc는 큰 운동장을 선으로 나눠 각 팀이 자기 구역만 보게 해 주는 도구예요.
그래서 우리 팀은 자기 골대와 공만 보면서 바로 경기를 시작할 수 있어요.
하지만 운동장 자체는 하나라서, 규칙과 안전요원은 따로 필요하답니다.