[Linux] Linux Namespace 격리 기술, 실제 적용과 검증 방법

목차

• 1. 왜 Linux Namespace를 이해해야 하나요
• 2. Linux Namespace 핵심 개념 정리
• 3. 실제 적용 사례: 컨테이너 기술에서 어떻게 쓰이나요
• 4. 실전 구현: unshare로 Namespace 직접 만들기
• 4-1. 네트워크 Namespace 실습
• 4-2. 간단한 프로세스 격리 확인용 C 코드
• 5. 주의사항과 트러블슈팅: 여기서 많이 막힙니다
• 6. 검증과 결과 확인: 분리됐는지 어떻게 보나
• 7. 실제 운영에서 어디에 써먹나
• 8. 정리와 다음 단계
• 9. 자주 묻는 질문
• Q1. Namespace만 쓰면 컨테이너를 직접 만든 셈인가요?
• Q2. Docker를 쓰는데도 Namespace를 따로 알아야 하나요?
• Q3. User Namespace는 꼭 써야 하나요?

Linux Namespace 격리 기술, 실제 적용과 검증 방법

Linux Namespace는 요즘 컨테이너 기술 이야기할 때 거의 빠지지 않는 핵심 요소입니다. Docker를 쓰든, containerd를 쓰든, Kubernetes 위에서 파드를 띄우든 결국 밑바닥에는 이런 격리 기술이 깔려 있거든요. 근데 운영하다 보면 막연히 "컨테이너는 분리돼 있다" 정도로만 이해해서는 한계가 옵니다. 장애가 났을 때 왜 프로세스는 안 보이는지, 왜 네트워크가 따로 노는지, 왜 마운트가 호스트랑 다르게 보이는지 알아야 하더라고요.

저도 처음엔 이게 뭔가 싶었습니다. 컨테이너는 많이 올려봤는데, 정작 Linux Namespace를 직접 까보지 않으면 문제 원인을 제대로 못 잡겠더라고요. 특히 홈랩에서 테스트할 때 네트워크 네임스페이스를 잘못 건드려서 통신이 안 붙고, 마운트 네임스페이스 때문에 파일이 보였다 안 보였다 해서 삽질 좀 했습니다 ㅎㅎ 이번 글에서는 이론만 나열하지 않고, Linux Namespace를 실제로 어떻게 적용하고 검증하는지, 그리고 현업이나 홈랩에서 어디에 유용한지 경험 기준으로 풀어보겠습니다.

프로세스, 네트워크, 마운트가 각각 분리되는 구조를 한눈에 보여주는 개요 이미지입니다.

1. 왜 Linux Namespace를 이해해야 하나요

쉽게 말해 Linux Namespace는 커널(Kernel)이 프로세스에게 보여주는 세상을 따로 나누는 기능이거든요. 같은 서버 위에서 돌아가더라도 A 프로세스는 자기 PID 목록만 보고, B 프로세스는 자기 네트워크 인터페이스만 보게 만들 수 있습니다. 이게 컨테이너 기술의 출발점입니다.

여기서 중요한 포인트! 가상머신(Virtual Machine)은 커널까지 통째로 분리하는 방식이고, Namespace는 같은 커널을 공유하면서 보이는 범위만 나누는 방식입니다. 그래서 더 가볍고 빠릅니다. 대신 보안 경계(Security Boundary)로 과신하면 안 됩니다. 저도 처음엔 "분리됐으니 완전히 안전하겠지"라고 생각했는데, 실제로 써보니 Namespace는 격리의 한 축일 뿐이고 cgroups, capabilities, seccomp 같은 요소랑 같이 봐야 하더라고요.

2. Linux Namespace 핵심 개념 정리

대표적인 Namespace는 아래처럼 이해하시면 됩니다.

종류	영문	무엇을 격리하나	현실적인 사용 예
PID	Process ID Namespace	프로세스 번호와 프로세스 트리	컨테이너 내부에서 1번 프로세스만 보이게 구성
NET	Network Namespace	네트워크 인터페이스, 라우팅, 포트	컨테이너별 가상 NIC와 독립 라우팅
MNT	Mount Namespace	마운트 지점과 파일시스템 뷰	호스트와 다른 루트 파일시스템 제공
UTS	UNIX Timesharing System Namespace	호스트명, 도메인명	컨테이너별 hostname 분리
IPC	Inter-Process Communication Namespace	공유 메모리, 세마포어, 메시지 큐	프로세스 간 IPC 격리
USER	User Namespace	UID/GID 매핑	컨테이너 root를 호스트 비특권 사용자로 매핑

한 줄로 줄이면 이렇습니다. Linux Namespace는 프로세스가 보는 시스템 자원을 논리적으로 쪼개는 장치거든요. 컨테이너 런타임은 이걸 조합해서 "내 것처럼 보이지만 사실은 제한된 환경"을 만들어냅니다.

3. 실제 적용 사례: 컨테이너 기술에서 어떻게 쓰이나요

가장 흔한 사례는 역시 Docker나 containerd 같은 런타임입니다. 예를 들어 웹 애플리케이션 컨테이너 하나를 띄운다고 해보죠. 그 안의 애플리케이션은 자기 PID 공간만 보고, 자기 네트워크 인터페이스만 보고, 자기 루트 파일시스템만 봅니다. 사용자는 그냥 컨테이너가 하나 올라간 걸로 보지만, 내부적으로는 여러 Namespace가 같이 엮여 있죠.

제가 홈랩에서 많이 해보는 패턴은 이렇습니다.

1. 리버스 프록시(Reverse Proxy) 컨테이너는 외부와 붙게 둡니다.
2. 백엔드 애플리케이션 컨테이너는 별도 네트워크 네임스페이스에 둡니다.
3. 로그 수집기나 모니터링 에이전트는 필요한 마운트만 노출합니다.
4. 가능하면 User Namespace까지 고려해서 호스트 권한을 줄입니다.

이 방식이 왜 좋냐면, 장애 범위가 줄어듭니다. 어떤 애플리케이션이 오작동해서 내부 프로세스를 마구 생성하더라도, 적어도 다른 워크로드의 프로세스 공간까지 바로 오염시키지는 않거든요. 물론 이것만으로 충분하진 않지만, 운영 안정성에서 체감 차이가 꽤 큽니다.

4. 실전 구현: unshare로 Namespace 직접 만들기

이제 이론 말고 직접 보겠습니다. 저는 Namespace를 설명할 때 항상 <code>unshare부터 보여드립니다. 이걸 한 번 손으로 쳐보면 감이 확 옵니다. 아래 예시는 PID, UTS, Mount Namespace를 분리해서 새 쉘을 띄우는 방식입니다.

sudo unshare --fork --pid --mount --uts /bin/bash

이 상태에서 호스트명도 바꿔보겠습니다.

hostname ns-lab
hostname
ps -ef

여기서 ps -ef를 보면 호스트 전체 프로세스가 아니라 새 Namespace 기준의 프로세스만 보여집니다. 처음 보면 "어? 왜 이렇게 적지?" 싶거든요. 그게 정상입니다.

마운트도 분리해보죠.

mount -t proc proc /proc
mount | grep proc

Mount Namespace를 분리한 뒤 /proc를 다시 마운트하지 않으면 프로세스 정보가 기대와 다르게 보일 수 있습니다. 이 부분에서 많이 헷갈립니다. 저도 예전에 "PID Namespace가 안 먹었나?" 하고 한참 봤었는데, 알고 보니 /proc를 새로 안 붙였던 거였습니다.

실습 중간에 확인해야 하는 핵심 명령과 분리된 PID 공간이 보이는 터미널 예시입니다.

4-1. 네트워크 Namespace 실습

네트워크는 조금 더 재미있습니다. 별도 네임스페이스를 만들고 veth pair(가상 이더넷 쌍)로 연결하면 거의 미니 컨테이너 네트워크처럼 테스트할 수 있죠.

sudo ip netns add ns1
sudo ip link add veth-host type veth peer name veth-ns
sudo ip link set veth-ns netns ns1
sudo ip addr add 10.10.10.1/24 dev veth-host
sudo ip link set veth-host up
sudo ip netns exec ns1 ip addr add 10.10.10.2/24 dev veth-ns
sudo ip netns exec ns1 ip link set lo up
sudo ip netns exec ns1 ip link set veth-ns up
sudo ip netns exec ns1 ping -c 3 10.10.10.1

이 실습이 좋은 이유는 컨테이너 기술의 네트워크 격리 원리를 거의 그대로 보여주기 때문입니다. 브리지(Bridge), NAT, 포트 포워딩까지 붙이면 Docker 네트워크 구조를 훨씬 잘 이해하게 됩니다.

4-2. 간단한 프로세스 격리 확인용 C 코드

시스템 프로그래밍 관점에서 보면 clone() 계열 시스템 콜로 Namespace를 만드는 흐름을 이해하는 것도 중요합니다. 아래 코드는 개념 확인용으로 아주 단순화한 예시입니다.

#define _GNU_SOURCE
#include <sched.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

#define STACK_SIZE 1024 * 1024

static int child_func(void *arg) {
    sethostname("ns-child", 8);
    system("hostname; ps -ef");
    return 0;
}

int main() {
    char *stack = malloc(STACK_SIZE);
    if (!stack) return 1;

    pid_t pid = clone(child_func, stack + STACK_SIZE, CLONE_NEWUTS | CLONE_NEWPID | SIGCHLD, NULL);
    if (pid == -1) return 1;

    waitpid(pid, NULL, 0);
    free(stack);
    return 0;
}

실무에서 직접 이런 코드를 매번 짜진 않지만, 런타임이 내부적으로 어떤 일을 하는지 이해하는 데는 꽤 도움이 됩니다.

5. 주의사항과 트러블슈팅: 여기서 많이 막힙니다

실제로 써보니 Linux Namespace는 개념보다 디버깅이 더 중요하더라고요. 아래는 제가 자주 겪었던 문제들입니다.

• ⚠️ /proc 재마운트 누락: PID Namespace를 만들었는데 프로세스가 이상하게 보이면 먼저 확인하세요.
• ⚠️ loopback 미활성화: Network Namespace 안에서 lo를 올리지 않으면 localhost 통신이 어색하게 깨집니다.
• ⚠️ 권한 문제: User Namespace를 섞으면 UID/GID 매핑 때문에 파일 접근이 예상과 다를 수 있습니다.
• ⚠️ 네트워크 라우팅 누락: veth만 연결해놓고 라우팅이나 NAT를 안 잡으면 외부 통신이 안 됩니다.

특히 네트워크 부분은 진짜 많이 삽질합니다. 저는 예전에 "분명 인터페이스는 올라왔는데 왜 패킷이 안 나가지?" 하고 tcpdump만 한참 봤거든요. 알고 보니 호스트 쪽 IP 포워딩(IP Forwarding)이 빠져 있었습니다. 그래서 아래처럼 확인하는 습관을 들였습니다.

sysctl net.ipv4.ip_forward
ip netns exec ns1 ip route
ip addr show veth-host

보안 측면에서도 한 가지 강조하고 싶습니다. Namespace는 강력하지만 만능은 아니거든요. 격리 기술이라고 해서 무조건 안전한 게 아니고, 커널 취약점이나 잘못된 capability 설정이 있으면 경계가 흐려질 수 있습니다. 그래서 현업에서는 보통 cgroups, seccomp, AppArmor 또는 SELinux 같은 보안 메커니즘과 함께 갑니다.

호스트와 네임스페이스가 veth로 연결되고 패킷이 흐르는 경로를 이해하기 위한 구성도입니다.

6. 검증과 결과 확인: 분리됐는지 어떻게 보나

설정만 해놓고 끝내면 안 됩니다. 반드시 검증해야 합니다. 저는 보통 아래 순서로 봅니다.

1. 프로세스가 분리됐는지 ps, /proc로 확인합니다.
2. 호스트명이 분리됐는지 hostname으로 확인합니다.
3. 네트워크 인터페이스가 분리됐는지 ip addr로 확인합니다.
4. 마운트 뷰가 다른지 mount 출력으로 비교합니다.
5. 필요하면 네임스페이스 핸들을 lsns로 확인합니다.

lsns
sudo ip netns exec ns1 ip addr
sudo ip netns exec ns1 hostname
sudo ip netns exec ns1 ps -ef

이렇게 보면 각 격리가 실제로 먹었는지 금방 드러납니다. lsns는 운영 중 문제 파악할 때 꽤 유용하더라고요. 어떤 프로세스가 어떤 Namespace에 속했는지 감을 잡는 데 도움이 되거든요.

실무 관점의 결과를 정리하면 이렇습니다.

검증 항목	성공 시 기대 결과	실패 시 의심 포인트
PID 분리	내부 프로세스만 보임	/proc 재마운트 누락
hostname 분리	Namespace 내부 이름만 변경됨	UTS 미분리
네트워크 분리	별도 인터페이스/라우팅 표시	veth 연결, lo 활성화 누락
마운트 분리	호스트와 다른 마운트 목록	Mount Namespace 미적용

분리된 Namespace가 실제로 적용됐는지 확인하는 검증 결과 예시 이미지입니다.

7. 실제 운영에서 어디에 써먹나

혹시 이런 경험 있으신가요? 개발팀은 "컨테이너니까 독립적이다"라고 생각하는데, 운영팀은 "그래도 결국 같은 커널인데?"라는 불안이 남습니다. 둘 다 맞는 말이거든요. 그래서 Namespace를 이해하면 커뮤니케이션이 훨씬 쉬워집니다.

제가 현장에서 보거나 직접 적용해본 패턴은 대체로 이렇습니다.

• 멀티테넌트(Multi-tenant) 환경에서 워크로드 간 기본 격리
• CI 러너나 빌드 작업의 프로세스/파일시스템 분리
• 네트워크 실험 환경 구성과 장애 재현
• 보안 테스트용 최소 권한 실행 환경 만들기

특히 홈랩에서는 이게 정말 좋습니다. VM 여러 대 띄우기 부담스러울 때 Namespace 기반으로 작은 실험 환경을 빠르게 만들 수 있거든요. 물론 커널 공유라는 특성 때문에 VM을 완전히 대체하진 못하지만, 문제 재현과 구조 학습에는 진짜 편하더라고요.

8. 정리와 다음 단계

Linux Namespace를 이해하면 컨테이너가 갑자기 훨씬 덜 추상적으로 보입니다. 그냥 "신기한 배포 단위"가 아니라, PID Namespace, Network Namespace, Mount Namespace 같은 커널 기능의 조합으로 보이기 시작하거든요. 저도 처음엔 Docker 명령만 외웠는데, 바닥 기술을 알고 나니 장애 대응 속도가 확실히 빨라졌습니다. 드디어 됐다! 싶은 순간이 오더라고요.

오늘 정리한 핵심만 다시 적어보면 이렇습니다.

• Linux Namespace는 프로세스가 보는 시스템 자원을 분리합니다.
• 컨테이너 기술은 여러 Namespace를 조합해 가벼운 실행 환경을 만듭니다.
• 실전에서는 네트워크, 마운트, 권한 매핑에서 가장 많이 막힙니다.
• 검증 명령을 반드시 함께 익혀야 운영에서 써먹을 수 있습니다.

다음 단계로는 cgroups와 함께 보면 좋습니다. Namespace가 "보이는 범위"를 나눈다면, cgroups는 CPU와 메모리 같은 자원 사용량을 통제하거든요. 다음 글에서 다룰 예정입니다. 그리고 이전 글에서 컨테이너 런타임 구조를 정리했다면 같이 보시면 연결이 더 잘 됩니다.

PID, NET, MNT 등 주요 Namespace와 운영 포인트를 빠르게 복습할 수 있는 요약 이미지입니다.

9. 자주 묻는 질문

Q1. Namespace만 쓰면 컨테이너를 직접 만든 셈인가요?

완전히 그렇진 않습니다. Namespace는 핵심 구성요소지만, 실제 컨테이너 환경에는 cgroups, 루트 파일시스템, capability 제어, 보안 정책 등이 함께 필요하죠.

Q2. Docker를 쓰는데도 Namespace를 따로 알아야 하나요?

네, 운영이나 장애 대응을 생각하면 알아두는 게 좋습니다. 특히 네트워크 안 붙음, 파일 안 보임, 프로세스 이상 동작 같은 문제는 바닥 기술을 이해해야 빨리 풀린다고 봅니다.

Q3. User Namespace는 꼭 써야 하나요?

상황에 따라 다릅니다. 보안상 이점은 분명하지만, 권한 매핑과 파일 접근에서 복잡도가 올라갑니다. 운영 환경에서는 호환성과 보안 요구사항을 함께 봐야 합니다.

📚 함께 읽으면 좋은 글

• cgroup vs namespace: 컨테이너 격리의 핵심 비교 분석
• systemd timer vs Cron: 리눅스 작업 스케줄러 성능 및 자원 비교
• Ubuntu Server vs Debian Stable: 홈서버 OS 선택 가이드