쿠버네티스 v1.35의 cgroup v1 퇴출과 노드 스왑 GA: 인프라 마비 막는 서버 전환 규칙

리눅스 커널 구형 규격 퇴출과 인공지능 메모리 병목의 정면충돌

기업의 클라우드 인프라 운영 방식이 거대한 분기점을 맞이했다. 리눅스 기반 컨테이너 자동 순서 제어의 표준인 쿠버네티스가 v1.35 버전부터 구형 리소스 관리 체계인 cgroup v1 노드에서의 노드 에이전트(kubelet) 구동을 완전히 거부하기 시작했기 때문이다. 과거 10년 넘게 관행적으로 유지되던 레거시 리눅스 커널 설정을 방치해 둔 기업은 최신 클러스터로 업그레이드하는 순간 인프라 전체가 멈춰 서는 하드 블로커(Hard Blocker)를 마주하게 된다.

이번 조치는 단순한 버전 정리가 아니다. 최근 급격히 확산된 자율형 AI(Agentic AI)와 대규모 추론 모델이 인프라 밑바닥의 메모리 구조를 뿌리째 뒤흔들고 있는 현실과 맞닿아 있다. 에이전트 기반 인공지능 워크로드는 작업 요청이 들어오는 순간 메모리를 기형적으로 폭식하듯 끌어다 쓰고, 작업이 끝나면 대량의 메모리를 빈 채로 방치하는 불규칙한 특성을 보인다. 중앙처리장치(CPU) 여유가 충분해도 메모리 용량이 먼저 바닥나 서버 전체가 다운되는 현상이 반복되자, 쿠버네티스 진영은 오랜 시간 금기시해 오던 디스크 스왑(Swap) 카드를 꺼내 들었다.

쿠버네티스는 v1.34에서 노드 스왑(Node Swap) 기능을 정식 상용화(GA) 단계로 전환했다. 메모리 부족 시 컨테이너를 강제 종료(OOM Kill)하던 과거의 가혹한 정책 대신, 초고속 NVMe 솔리드 스테이트 드라이브(SSD)를 완충재 삼아 급격한 메모리 스파이크를 흡수하도록 뼈대를 고친 것이다. 하지만 이 완충 장치가 정상 작동하려면 반드시 단일 계층 구조를 갖춘 cgroup v2 환경이 전제되어야 한다. 구형 운영체제와 레거시 가상화 환경에 갇혀 있던 엔지니어링 조직들이 더 이상 인프라 현대화를 미룰 수 없게 된 배경이다.

cgroup 규격 및 메모리 관리 방식 팩트 대조 분석

리눅스 커널의 자원 격리 제어기인 cgroup v1과 v2는 설계 철학부터 완전히 다르다. v1은 CPU, 메모리, 블록 입출력(I/O)이 각기 다른 디렉터리 트리로 분리되어 있어, 특정 컨테이너가 메모리를 초과 사용할 때 블록 쓰기 속도와의 연동 제어가 불가능했다. 반면 cgroup v2는 프로세스를 단일 계층 트리 구조로 통합 관리하여 메모리 부족(OOM) 상황을 프로세스 단위가 아닌 컨테이너 단위로 매끄럽게 제어한다.

아래 표는 cgroup 규격 차이와 함께, 쿠버네티스 v1.34에 정식 탑재된 노드 스왑 기능이 실제 인프라 지표에 미치는 영향을 비교한 데이터다.

실제 성능 측정 데이터에 따르면, 초고속 NVMe 스토리지를 백본으로 연결한 상태에서 노드 스왑을 활성화할 경우 동일 하드웨어 대비 노드 집약도를 최대 3배까지 끌어올릴 수 있는 것으로 나타났다. 물리 메모리 가격이 치솟는 상황에서 비싼 서버를 무작정 증설하지 않고도 간헐적인 AI 워크로드를 안정적으로 소화할 수 있는 수치적 근거다.

서버 인프라 현장에 닥친 3대 운영 파급력

커널 인터페이스의 퇴출과 스왑 메커니즘의 등장은 플랫폼 엔지니어링 팀에 세 가지 뚜렷한 실무적 압박과 기회를 동시에 던져주고 있다.

1. 운영 비용(OPEX)의 재설계와 유휴 메모리 낭비 차단

인공지능 모델을 돌리는 서버 환경에서 가장 뼈아픈 낭비는 대기 중인 유휴 메모리(Idle RAM)다. 에이전트형 AI는 복잡한 추론이나 툴 체인 호출이 발생할 때 일시적으로 수십 기가바이트의 메모리를 요구하지만, 작업이 끝난 뒤에는 기본 상태로 복귀한다. 종전에는 이 돌발 피크치를 기준으로 파드의 메모리 리밋(Limit)을 넉넉히 설정해야 했기에 막대한 클라우드 인스턴스 비용을 지불하면서도 실제 가동률은 30% 밑도는 일이 흔했다.

노드 스왑을 도입하면 값비싼 물리 메모리를 피크치에 맞춰 구매하는 대신, 저렴한 고속 NVMe 스토리지로 여유 버퍼를 확보할 수 있다. 실무 시뮬레이션 추정에 따르면, 64GB 메모리를 탑재한 범용 클라우드 인스턴스 10대를 운영하던 조직이 스왑 최적화를 적용할 경우 인스턴스 4–5대 분량의 워크로드를 흡수할 수 있어 연간 인프라 지출을 35–45%가량 줄이는 계산이 나온다.

2. 메모리 병목으로 인한 파드 축출 및 지연 시간 통제

과거 쿠버네티스 관리자들이 노드 스왑을 극도로 꺼렸던 이유는 스왑 디스크로 메모리 데이터가 내려앉는 순간 지연 시간(Latency)이 기하급수적으로 늘어나 전체 서비스 응답이 마비되었기 때문이다. 하드디스크 시절의 경험이 만들어낸 불신이었다.

그러나 초당 수 기가바이트의 대역폭을 뿜어내는 최신 PCIe 4.0/5.0 NVMe 환경에서는 이야기가 완전히 달라진다. 백그라운드 데이터의 페이징 속도가 비약적으로 개선되었으며, cgroup v2의 세밀한 I/O 컨트롤러 덕분에 실시간 처리가 필요한 핵심 프로세스를 스왑 대상에서 제외하고 유휴 상태의 비활성 페이지만 골라 스왑 공간으로 밀어낼 수 있다. 결과적으로 메모리 부족으로 파드가 강제 종료되거나 다른 노드로 축출(Eviction)되면서 발생하던 2–5분의 콜드 스타트 지연을 0초대로 방어할 수 있게 되었다.

3. 클라우드 엣지 분산 환경의 규제 및 배포 안정성 확보

중앙 데이터센터를 벗어나 공장, 병원, 지사 현장으로 인공지능 추론을 분산 배치하는 엣지 컴퓨팅 현장에서는 이번 변화가 더욱 직접적으로 작용한다. 엣지 환경은 하드웨어 증설이 물리적으로 어렵고 통신 비용(Data Egress Fees)과 프라이버시 규제 때문에 데이터를 외부로 내보내기 어렵다.

제한된 사양의 엣지 서버에서 KubeEdge 같은 경량 오케스트레이터를 돌릴 때, cgroup v2 기반의 노드 스왑은 하드웨어 증설 없이도 거대 온디바이스 모델을 얹을 수 있는 유일한 탈출구가 된다. 하드웨어, 운영체제, 애플리케이션 계층이 톱니바퀴처럼 맞물려야만 장애 없이 구동되므로, 인프라 팀이 사전에 운영체제 이미지를 최신 커널로 표준화해 두지 않으면 현장 서버의 대규모 먹통 사태를 초래하게 된다.

스왑 완충벽과 하이브리드 인프라 전환 실증

선도적인 클라우드 네이티브 엔지니어링 기업들은 이미 cgroup v2와 고속 스왑의 결합을 통해 비용 절감과 안정성을 동시에 확보하고 있다.

대표적으로 휴렛팩커드 엔터프라이즈(HPE)는 엣지 AI 환경에 특화된 ProLiant 서버 제품군을 중심으로 하드웨어와 운영체제 계층을 결합한 통합 설계를 제시하고 있다. 메모리가 제약된 현장 엣지 노드에서 보안 규정을 만족하면서 인공지능 모델을 구동하려면, 단순한 소프트웨어 패치 수준을 넘어 NVMe I/O 처리량이 보장된 맞춤형 컴퓨팅 환경이 필수적이기 때문이다.

동시에 오픈소스 진영에서는 다오클라우드(DaoCloud)와 같은 인프라 전문 기술팀이 cgroup v2 전환을 주도하며 컨테이너별 메모리 서비스 품질(QoS) 보장 규칙을 정교화하고 있다. 상용 모니터링 환경에서는 노드 레벨의 리소스 고갈 징후를 사전에 포착하기 위해 Datadog 같은 관측 도구를 연동하여, 물리 메모리 사용률뿐만 아니라 스왑 진입 빈도(Major Page Fault)를 종합 대시보드로 추적하는 운영 표준이 자리 잡고 있다.

아래는 구형 cgroup v1 환경과 차세대 cgroup v2 및 노드 스왑 결합 체계의 실제 운영 지표 차이를 보여주는 대조표다.

자체 데이터센터나 고객사 사내망(온프레미스)에 프라이빗 AI 플랫폼을 직접 구축해 제공하는 벤더들의 작업 방식도 바뀌고 있다. 클라우드 관리 전문 기업 페어윈즈(Fairwinds)는 설치 마법사(Installer)만 믿고 배포를 진행했다가 실패하는 대다수 프로젝트의 원인으로 ‘기저 인프라 사전 점검 부재’를 꼽는다. 고객사의 사내 쿠버네티스 노드가 여전히 cgroup v1을 쓰고 있거나 스왑 파티션 권한 설정이 막혀 있는 경우, 아무리 최신 AI 플랫폼을 얹어도 며칠 못 가 전체 노드가 패닉 상태에 빠지기 때문이다.

단계별 마일스톤 실행 로드맵: 무중단 클러스터 전환 지침

쿠버네티스 v1.35 환경으로 안전하게 넘어가면서 노드 스왑을 성공적으로 안착시키기 위해 시스템 엔지니어링 팀이 밟아야 할 단계별 실행 과제를 정리했다.

단기 준비 과제 (파일럿 검증 및 데이터 정비)

• 노드 커널 및 cgroup 규격 전수 조사: 클러스터를 구성하는 모든 워커 노드에서 커널 명령행 매개변수를 확인한다. 파일 시스템이 /sys/fs/cgroup/unified 또는 단일 cgroup2로 마운트되어 있는지 점검하고, 리눅스 커널 버전이 5.8 이상(권장 6.x 이상)인지 확인해야 한다.
• 컨테이너 런타임(containerd / CRI-O) 드라이버 정렬: containerd의 config.toml 파일에서 SystemdCgroup = true로 설정되어 있는지 점검한다. kubelet의 cgroup 드라이버와 런타임 드라이버가 불일치할 경우 노드 재부팅 시 클러스터에 조인하지 못하는 장애가 발생한다.
• NVMe 기반 전용 스왑 공간 프로비저닝: 노드 스왑을 일반 SATA 디스크나 네트워크 스토리지(NFS) 위에 올리는 것은 절대 금물이다. 반드시 초고속 NVMe SSD 파티션에 스왑 공간을 잡고, 운영체제 레벨에서 스왑 우선순위를 설정해야 한다.
• 쿠버네티스 피처 게이트(Feature Gate) 검증: 쿠버네티스 v1.34 이상 버전에서 NodeSwap 플래그가 정상 활성화되어 있는지 확인하고, 테스트 네임스페이스의 비핵심 파드를 대상으로 메모리 급증 시나리오를 강제 유발하여 OOM 킬러 대신 스왑이 매끄럽게 동작하는지 파일럿 검증을 수행한다.

중장기 확대 과제 (전사 확산 및 지속 운영 체계)

• 롤링 노드 교체(Canary Node Rollout): 기존 운영 클러스터의 워커 노드를 한 번에 바꾸지 않고, cgroup v2와 노드 스왑이 적용된 신규 노드 풀을 생성한 뒤 kubectl drain을 통해 파드를 점진적으로 이전한다.
• 워크로드별 스왑 동작 정책(QoS) 차등화: 실시간 응답이 필수적인 API 게이트웨이나 금융 트랜잭션 파드는 스왑을 타지 않도록 requests와 limits를 동일하게 맞춘 Guaranteed 클래스로 보호한다. 반면 일시적 스파이크가 잦은 비동기 AI 에이전트 워커는 Burstable 클래스로 두어 스왑 버퍼의 혜택을 극대화한다.
• 스왑 I/O 병목 관측 지표 구축: 단순 메모리 사용량 알림을 넘어, 노드 디스크 쓰기 대역폭과 페이지 결함(Page Fault) 빈도를 감시 지표로 추가한다. 스왑 파티션의 I/O 대기율이 임계치를 넘어서면 즉시 오토스케일러(KARPENTER 등)를 가동해 노드를 자동 증설하는 방어선 체계를 갖춘다.
• 인프라 패키징 표준화: 온프레미스나 고객사 프라이빗 클라우드에 배포되는 플랫폼 도구의 경우, 설치 스크립트 전면에 커널 점검 루틴을 내장하여 cgroup v1 노드 감지 시 설치를 사전에 차단하고 안내 메시지를 출력하도록 자동화 파이프라인을 정비한다.