컨테이너 격리 및 런타임 기술(Container Isolation & Runtime)

1. 개요

가. 정의

컨테이너 격리 및 런타임 기술이란 리눅스 커널의 네임스페이스(namespace)·컨트롤 그룹(cgroups)·권한 축소(capabilities)·시스템 호출 필터링(seccomp) 등 OS 수준 격리 기능을 조합해 하나의 커널 위에서 다수의 프로세스를 서로 독립된 실행 환경처럼 보이게 하고, 이를 OCI(Open Container Initiative) 표준에 따라 생성·실행·종료하는 소프트웨어 계층(런타임)을 말한다.

하이퍼바이저 기반 가상머신이 하드웨어를 가상화해 게스트 OS마다 별도의 커널을 올리는 것과 달리, 컨테이너는 호스트 커널을 공유하면서 프로세스 수준에서만 격리한다. 따라서 부팅 과정이 없고 수백 MB의 게스트 OS 이미지도 필요 없어, 수십 밀리초 단위로 기동하며 하나의 노드에서 수백~수천 개를 밀집 배치할 수 있다. 그러나 커널을 공유한다는 사실은 곧 "격리의 강도가 커널 기능의 정확성과 설정 품질에 의존한다"는 뜻이며, 이것이 컨테이너 보안과 런타임 설계의 출발점이다.

나. 등장 배경과 필요성

첫째, 가상머신은 애플리케이션 하나를 격리하기 위해 OS 전체를 복제하는 방식이라 자원 효율과 배포 속도가 낮았다. 마이크로서비스처럼 작은 서비스를 수십~수백 개로 쪼개 배포하는 흐름에서는, 서비스마다 수 GB짜리 VM을 띄우는 비용이 감당하기 어려웠다. 컨테이너는 "애플리케이션과 그 의존성만 패키징"하는 경량 단위를 제공해 이 문제를 해결했다.

둘째, "내 노트북에서는 되는데 운영에서는 안 된다"는 환경 불일치 문제가 심각했다. 컨테이너 이미지는 라이브러리·런타임·설정을 하나의 불변(immutable) 아티팩트로 고정하므로, 개발·테스트·운영 환경 간 재현성을 보장한다. 이 재현성은 CI/CD 자동화, 즉 [[ci-cd-pipeline]]·[[gitops]]의 전제 조건이 되었다.

셋째, 2013년 Docker가 리눅스 커널 기능을 쉬운 CLI와 이미지 포맷으로 묶어 대중화했고, 2015년 OCI가 출범해 이미지 포맷·런타임·배포 규격을 표준화하면서 특정 벤더에 종속되지 않는 생태계가 형성되었다. 이로써 Docker, containerd, CRI-O, Podman 등 여러 구현이 상호 호환되고, [[kubernetes]]가 CRI(Container Runtime Interface)를 통해 런타임을 교체 가능하게 다룰 수 있게 되었다.

다. 특징

컨테이너 격리는 (1) 공유 커널 — 성능·밀도의 원천이자 보안 경계의 약점, (2) 선언적 불변 이미지 — 재현성과 공급망 추적성의 기반, (3) 표준 기반 교체 가능성 — OCI/CRI를 통한 벤더 중립성이라는 세 특징을 동시에 가진다. 이 세 특징의 균형점이 어디냐에 따라 순수 컨테이너부터 샌드박스 런타임, 경량 VM까지 다양한 격리 수준이 선택된다.

2. 컨테이너 격리의 핵심 구성요소

컨테이너는 단일 기술이 아니라 여러 커널 기능의 조합이다. 전체 구조를 먼저 조망한 뒤 각 요소의 원리를 설명한다.

graph TD
    subgraph Host["호스트 (단일 공유 커널)"]
        K["리눅스 커널"]
        subgraph C1["컨테이너 A"]
            P1["애플리케이션 프로세스"]
        end
        subgraph C2["컨테이너 B"]
            P2["애플리케이션 프로세스"]
        end
    end
    K -->|"네임스페이스 (무엇을 볼 수 있나)"| C1
    K -->|"네임스페이스 (무엇을 볼 수 있나)"| C2
    K -->|"cgroups (얼마나 쓸 수 있나)"| C1
    K -->|"cgroups (얼마나 쓸 수 있나)"| C2
    K -->|"capabilities·seccomp·LSM (무엇을 할 수 있나)"| C1
    K -->|"capabilities·seccomp·LSM (무엇을 할 수 있나)"| C2

가. 네임스페이스(Namespace) — 가시성의 격리

네임스페이스는 "프로세스가 무엇을 볼 수 있는가"를 분할하는 기능이다. PID 네임스페이스는 컨테이너 내부 프로세스가 자신을 PID 1로 인식하게 만들어, 호스트의 다른 프로세스를 보지 못하게 한다. NET 네임스페이스는 독립된 네트워크 스택(인터페이스·라우팅 테이블·방화벽 규칙)을 제공하므로, 컨테이너마다 자체 IP와 포트 공간을 가질 수 있다. 이 밖에 MNT(파일시스템 마운트), IPC(공유 메모리·세마포어), UTS(호스트명), USER(사용자·그룹 ID 매핑), CGROUP, TIME 네임스페이스가 있어 총 8종이 2024년 기준 커널에 존재한다.

특히 USER 네임스페이스는 보안상 핵심이다. 컨테이너 내부의 root(UID 0)를 호스트의 비권한 사용자(예: UID 100000)로 매핑하면, 컨테이너 탈출이 발생해도 호스트에서는 일반 사용자 권한만 얻게 되어 피해를 크게 줄인다. 이것이 뒤에서 설명할 루트리스(rootless) 컨테이너의 기반이다.

나. 컨트롤 그룹(cgroups) — 자원의 격리

cgroups는 "프로세스 그룹이 자원을 얼마나 쓸 수 있는가"를 제한·측정한다. CPU 쿼터(예: 0.5 vCPU), 메모리 상한(예: 512MiB), 블록 I/O 대역폭, PID 개수 등을 제어하여 한 컨테이너의 폭주가 노드 전체를 마비시키는 노이지 네이버(noisy neighbor) 문제를 막는다. 가령 메모리 상한을 초과하면 OOM Killer가 해당 컨테이너의 프로세스를 종료하여 다른 워크로드를 보호한다.

현재는 계층 구조가 단순화되고 자원 유형을 통합 관리하는 cgroups v2가 표준이다. systemd와 결합해 단일 통합 계층으로 동작하며, 쿠버네티스 1.25부터 v2가 정식(GA) 지원되어 메모리 압박 신호(PSI, Pressure Stall Information) 기반의 정밀한 부하 제어가 가능해졌다.

다. 권한 축소·시스템 호출 필터링 — 행위의 격리

capabilities는 전통적으로 "전부 아니면 전무"였던 root 권한을 약 40여 개의 세분화된 권한으로 쪼갠다. 컨테이너 런타임은 기본적으로 CAP_NET_RAW, CAP_SYS_ADMIN 등 위험한 권한을 제거한 최소 집합만 부여한다. seccomp(secure computing)는 BPF 필터로 프로세스가 호출할 수 있는 시스템 콜을 화이트리스트로 제한하여, 커널 공격 표면을 줄인다 — Docker 기본 프로파일은 약 300여 개 중 44개 위험 시스템 콜을 차단한다. 여기에 SELinux·AppArmor 같은 LSM(Linux Security Module)으로 파일·네트워크 접근을 강제 접근제어 수준에서 통제하면, 네임스페이스가 뚫려도 2차 방어선이 작동한다.

구분	통제 질문	주요 기능	격리 실패 시 영향
네임스페이스	무엇을 보는가	PID·NET·MNT·USER 등 8종	다른 컨테이너·호스트 자원 노출
cgroups	얼마나 쓰는가	CPU·메모리·I/O·PID 상한	자원 고갈·서비스 거부
capabilities	무엇을 하는가	root 권한 세분화	권한 상승·호스트 장악
seccomp/LSM	커널을 어떻게 호출	시스템 콜·MAC 제한	커널 취약점 악용·탈출

표에서 보듯 세 범주는 서로 다른 질문에 답하며 다층 방어(defense in depth) 로 함께 작동해야 한다. 어느 하나만으로는 완전한 격리가 성립하지 않는다는 점이 컨테이너 보안 설계의 핵심 함의다.

3. 컨테이너 런타임 아키텍처와 실행 절차

런타임은 역할에 따라 고수준 런타임(이미지 관리·네트워크·스토리지 오케스트레이션)과 저수준 런타임(네임스페이스·cgroups를 실제로 설정해 프로세스를 띄우는 OCI 런타임)으로 나뉜다. 쿠버네티스가 Pod를 띄울 때의 호출 흐름을 통해 이 계층을 설명한다.

sequenceDiagram
    participant K as kubelet
    participant HL as containerd / CRI-O (고수준)
    participant S as containerd-shim
    participant LL as runc / crun (저수준 OCI)
    participant KN as 리눅스 커널
    K->>HL: CRI gRPC 호출 (RunPodSandbox/CreateContainer)
    HL->>HL: OCI 이미지 Pull·압축해제·롤 구성
    HL->>S: shim 프로세스 생성 (컨테이너 수명 분리)
    S->>LL: OCI 번들(config.json + rootfs) 전달
    LL->>KN: clone() + 네임스페이스·cgroups·capabilities 설정
    KN-->>LL: 격리된 PID 1 프로세스 기동
    LL-->>S: 실행 결과 반환 후 종료
    S-->>HL: 컨테이너 상태 보고 (shim이 상주)

가. 고수준 런타임과 CRI

kubelet은 특정 런타임에 종속되지 않도록 CRI(Container Runtime Interface) 라는 gRPC 표준으로 통신한다. 2020년 쿠버네티스가 Docker 전용 연결 계층(dockershim)을 폐기(1.24에서 제거)하면서, 현재는 containerd와 CRI-O가 사실상 표준 고수준 런타임이다. 고수준 런타임은 이미지 레지스트리에서 OCI 이미지를 내려받아 계층(layer)을 합치고, 네트워크(CNI)·스토리지(CSI)를 연결한 뒤 OCI 번들(rootfs + config.json)을 만든다.

나. shim과 저수준 OCI 런타임

containerd-shim은 컨테이너 프로세스의 부모 역할을 상주하며 떠맡아, containerd 데몬을 재시작해도 실행 중 컨테이너가 죽지 않도록 수명주기를 분리한다. 실제 격리 설정은 저수준 런타임인 runc(Go)가 수행한다. runc는 clone()/unshare() 시스템 콜로 네임스페이스를 만들고 cgroups·capabilities·seccomp를 적용한 뒤 사용자 프로세스를 exec 한다. 최근에는 C로 작성해 메모리 사용과 기동 지연을 줄인 crun, Rust로 작성한 youki 등 OCI 호환 대체 런타임이 등장해 고밀도·저지연 환경에서 채택이 늘고 있다.

다. 이미지와 공급망

실행 절차의 재현성은 OCI 이미지 스펙(콘텐츠 주소 지정 계층 + 매니페스트)에 기반한다. 동일 다이제스트(SHA-256)의 이미지는 어디서든 동일하므로, 이미지 서명·[[sbom]]·취약점 스캔을 결합하면 소프트웨어 공급망 무결성을 검증할 수 있다. 즉 런타임은 "격리된 실행"뿐 아니라 "검증된 아티팩트의 실행"까지 책임지는 방향으로 확장되고 있다.

4. 격리 강화·샌드박스 런타임 비교

공유 커널의 한계를 보완하기 위해 격리 강도를 높인 런타임들이 등장했다. 단순 나열이 아니라 왜 그런 선택을 했는지를 중심으로 비교한다.

방식	격리 경계	커널 공유	기동 속도	밀도·효율	대표 적용
표준 컨테이너(runc)	네임스페이스/cgroups	호스트 커널 직접 공유	매우 빠름(수십 ms)	최고	일반 마이크로서비스
gVisor(runsc)	사용자공간 게스트 커널	시스템 콜 가로채기	빠름	높음	멀티테넌트 PaaS
Kata Containers	경량 VM(하드웨어)	게스트 커널 분리	중간(수백 ms)	중간	신뢰 경계가 다른 테넌트
Firecracker microVM	microVM(하드웨어)	게스트 커널 분리	빠름(~125ms)	높음	서버리스(FaaS)

gVisor는 Google이 공개한 방식으로, 컨테이너의 시스템 콜을 사용자공간에서 동작하는 자체 게스트 커널(Sentry)이 가로채 처리한다. 호스트 커널에 직접 닿는 시스템 콜 표면을 극적으로 줄여, 커널 취약점을 통한 탈출 위험을 낮춘다. 다만 시스템 콜을 중계하므로 I/O 집약 워크로드에서는 성능 저하가 발생하는 트레이드오프가 있다 — 이 때문에 신뢰 낮은 코드를 격리 실행하는 멀티테넌트 환경에 적합하다.

Kata Containers는 각 Pod를 QEMU·Cloud Hypervisor 같은 하이퍼바이저 위의 경량 VM으로 감싸 하드웨어 수준의 커널 분리를 제공한다. 표준 컨테이너 인터페이스(OCI/CRI)를 그대로 유지하므로 애플리케이션 수정 없이 runtimeClassName만 바꿔 더 강한 격리를 선택할 수 있다. [[confidential-containers]]는 여기에 TEE 메모리 암호화를 결합한 확장이며, 이는 Kata 기반 경량 VM 격리가 기밀 컴퓨팅의 토대가 됨을 보여준다.

Firecracker는 AWS가 Lambda·Fargate를 위해 만든 microVM으로, 부팅을 약 125ms 이내로 끝내고 VM당 메모리 오버헤드를 약 5MiB 수준으로 낮춰, 단일 호스트에서 수천 개의 격리된 함수 인스턴스를 밀집 실행한다. VM의 강한 격리와 컨테이너의 빠른 기동을 결합한 사례로, "격리 강도와 성능은 반드시 상충한다"는 통념을 공격 표면 최소화 설계로 완화한 실무 예시다.

5. 심화: 최신 동향과 실무 적용

가. 루트리스(Rootless) 컨테이너의 확산

전통적으로 컨테이너 데몬은 root로 동작해, 데몬이 탈취되면 호스트가 통째로 위험했다. USER 네임스페이스를 활용한 루트리스 방식은 데몬·런타임을 비권한 사용자로 실행하고 컨테이너 내부 root를 호스트 일반 사용자로 매핑한다. Podman은 데몬 없는(daemonless) 루트리스 구조를 기본으로 채택했고, 쿠버네티스도 루트리스 kubelet을 실험적으로 지원하면서 "최소 권한" 원칙이 런타임 기본값으로 이동하고 있다.

나. Wasm 런타임과의 결합

WebAssembly([[webassembly]])를 컨테이너 생태계에 편입하려는 흐름도 뚜렷하다. containerd의 runwasi shim을 쓰면 Wasm 모듈을 OCI 이미지로 포장해 Pod처럼 배포할 수 있다. Wasm은 기동이 밀리초 미만으로 매우 빠르고 메모리 격리가 언어 수준에서 보장되어, 서버리스·엣지([[edge-computing]])의 극저지연 워크로드에서 경량 컨테이너의 보완재로 주목받는다.

다. 커널 수준 가시성·보안 — eBPF

[[ebpf]] 기반 도구(Cilium, Falco, Tetragon)는 컨테이너의 시스템 콜·네트워크 흐름을 커널에서 직접 관측·강제하여, 런타임 위협 탐지와 네트워크 정책 적용을 수행한다. 예컨대 금융권에서는 컨테이너 런타임에 대한 이상행위(예상치 못한 셸 실행, 권한 상승 시도)를 eBPF로 탐지해 런타임 보안([[rasp]]와 유사한 워크로드 자가보호)을 구현하는 사례가 늘고 있다. 이는 격리가 "정적 설정"에서 "동적 탐지·대응"으로 확장되고 있음을 보여준다.

6. 고려사항 및 시사점

기술사 관점에서 컨테이너 격리·런타임의 도입은 다음을 종합적으로 판단해야 한다.

• 격리 수준과 성능의 트레이드오프 설계: 모든 워크로드에 VM급 격리를 적용하면 비용·성능이 악화된다. 신뢰 경계(동일 조직 내부 vs 외부 테넌트 코드)를 기준으로, 저신뢰 워크로드에만 gVisor·Kata를 선택적으로 적용하는 runtimeClassName 기반 계층적 격리 전략이 현실적이다.
• 최소 권한의 기본값화: capabilities 제거, seccomp·AppArmor 프로파일 강제, 루트리스·읽기전용 루트 파일시스템, USER 네임스페이스 매핑을 기본 정책으로 삼아야 한다. [[kubernetes-pod-security-standards]]의 Restricted 프로파일을 어드미션 단계에서 강제해 설정 누락을 방지한다.
• 공급망 신뢰까지 포함한 통제: 격리된 실행만으로는 악성·취약 이미지를 막지 못한다. 이미지 서명 검증, [[sbom]] 생성, 취약점 스캔, 레지스트리 접근통제를 CI/CD와 [[policy-as-code]]로 연결해 "검증된 아티팩트만 실행"을 강제해야 한다.
• 관측성과 런타임 위협 대응 연계: 정적 격리 설정과 함께 eBPF 기반 런타임 탐지([[edr]]·Falco), 중앙 로그·[[observability]]를 결합해 격리가 뚫리는 순간을 조기에 탐지·대응하는 체계를 갖춰야 한다.
• 표준·벤더 중립성 확보: OCI/CRI 표준을 준수하는 런타임을 선택해 특정 벤더 종속을 피하고, dockershim 제거 사례처럼 생태계 변화에 대비한 교체 가능한 아키텍처를 유지한다.

종합하면 컨테이너 격리는 단일 기능이 아니라 커널 격리 요소·런타임 계층·공급망·관측성이 결합된 신뢰 실행 체계이며, 기술사는 보안·성능·운영 효율의 균형점을 조직의 신뢰 모델에 맞게 설계하는 역량을 요구받는다.

참고자료

• Open Container Initiative, "Runtime/Image/Distribution Specifications", https://opencontainers.org/
• Kubernetes Documentation, "Container Runtime Interface (CRI)", https://kubernetes.io/docs/concepts/architecture/cri/
• Linux man-pages, "namespaces(7) / cgroups(7) / capabilities(7) / seccomp(2)", https://man7.org/linux/man-pages/man7/namespaces.7.html
• AWS, "Firecracker: Lightweight Virtualization for Serverless Applications", https://firecracker-microvm.github.io/
• gVisor Documentation, "What is gVisor?", https://gvisor.dev/docs/

---

한 줄 요약: 컨테이너 격리·런타임은 리눅스 네임스페이스(가시성)·cgroups(자원)·capabilities/seccomp(행위)로 공유 커널 위에서 프로세스를 격리하고 OCI/CRI 표준 런타임(containerd→runc)으로 실행하는 기술로, 공유 커널의 보안 한계를 gVisor·Kata·Firecracker 같은 샌드박스·경량 VM과 루트리스·eBPF 관측으로 보완해 격리 강도와 성능의 균형을 설계하는 신뢰 실행 체계다.