EKS Auto Mode란? Karpenter 전환 전 운영 체크리스트

EKS 운영은 컨트롤 플레인 버전만 올린다고 끝나지 않는다. VPC CNI, kube-proxy, CoreDNS, EBS CSI, 데이터 플레인 노드, Karpenter까지 같이 움직이기 시작하면 작은 인프라 팀 입장에서는 업그레이드가 거의 이사 수준의 이벤트가 된다.

2026년 5월 13일 AWS 기술 블로그에 올라온 딜라이트룸 사례가 흥미로운 이유도 여기에 있다. 딜라이트룸은 2025년 11월 기존 5개 EKS 클러스터를 EKS Auto Mode로 전환했고, 현재는 10개 이상의 클러스터를 Auto Mode로 운영한다고 밝혔다. 숫자만 보면 “오, 편해졌네”인데, 실제로 봐야 할 부분은 무엇을 AWS에 넘겼고 무엇은 여전히 팀이 책임져야 하는가다.

한 줄로 잡으면 이렇다. EKS Auto Mode는 Karpenter를 없애는 기능이라기보다, Karpenter와 노드 운영을 AWS 관리 영역으로 옮겨서 플랫폼팀이 업그레이드, 패치, 로그, 레이블 마이그레이션을 다시 설계하게 만드는 선택지다.

이 글은 EKS Auto Mode 출시 소개가 아니다. 이미 self-managed Karpenter를 쓰고 있거나, 멀티 클러스터 EKS 운영에서 업그레이드와 노드 패치가 부담인 팀이 전환 전 무엇을 확인해야 하는지 보는 체크리스트다. 버튼 하나 누르면 운영이 사라진다고 믿으면 안 된다. 운영은 사라지는 게 아니라 모양이 바뀐다.

지금 결론

판단 축	Self-managed Karpenter	EKS Auto Mode
Karpenter 운영	Helm release, CRD, controller, SQS/EventBridge 등을 팀이 관리	AWS 관리형 컴퓨트 기능 안에서 Karpenter 기반으로 동작
노드 OS/패치	AMI, 노드 교체, 보안 패치 전략을 팀이 설계	AWS가 관리형 인스턴스와 Bottlerocket 기반 AMI를 패치/교체
접근 방식	SSH/SSM, `kubectl logs` 등 기존 노드/컨트롤러 관측 흐름 가능	SSH/SSM 직접 접근 제한, 관리형 컴포넌트 로그는 별도 수집 필요
커스터마이징	자유도 높음, 대신 운영 책임도 큼	NodePool/NodeClass로 제한적 조정, 기본 리소스 직접 수정은 피해야 함
마이그레이션 리스크	이미 운영 중이면 익숙함	레이블, EBS CSI, 로드밸런서, PDB, 로그 체계 확인 필요

딜라이트룸 사례에서 가장 강한 지표는 업그레이드 시간이다. 기존에는 7개 컴포넌트를 개별 관리하면서 클러스터당 약 4~6시간이 걸렸고, Auto Mode 전환 뒤에는 Control Plane 업그레이드 한 번으로 관리형 컴포넌트가 함께 업데이트되어 약 30분 이내로 줄었다. 신규 클러스터 구성도 약 3~4시간에서 약 30분 이내로 단축됐다고 정리했다.

다만 이 숫자는 “우리 팀도 무조건 30분”이라는 약속이 아니다. 워크로드 구조, IaC 성숙도, PDB, 로드밸런서 구성, EBS 볼륨 사용 방식에 따라 난이도가 달라진다. 그래서 이 글의 핵심은 도입 찬반이 아니라 전환 전 체크 순서다.

EKS Auto Mode가 실제로 넘겨받는 것

AWS 공식 문서 기준으로 EKS Auto Mode는 클러스터 인프라 운영 범위를 컨트롤 플레인 바깥까지 넓힌다. compute autoscaling, pod/service networking, application load balancing, cluster DNS, block storage, GPU support 같은 기능이 애드온이 아니라 core component처럼 관리된다.

오토스케일링은 Karpenter 기반이다. Pod가 기존 노드에 올라갈 수 없으면 Auto Mode가 새 EC2 관리형 인스턴스를 만들고, 워크로드가 줄면 노드를 정리한다. 그래서 “Karpenter가 사라진다”보다 “Karpenter 운영 주체가 바뀐다”라고 보는 편이 더 정확하다.

노드도 일반 EC2처럼 다루면 안 된다. AWS 문서는 EKS Auto Mode 관리형 인스턴스는 EKS가 생성, 삭제, 패치를 담당하고, 사용자는 그 위에 배포되는 container와 pod 책임을 가진다고 설명한다. SSH 접근이나 직접 소프트웨어 설치가 제한되므로 노드에 뭔가 깔아야 하는 운영 습관이 있다면 먼저 DaemonSet이나 별도 관측 흐름으로 바꿔야 한다.

보안 기본값은 꽤 강하다. AWS 문서는 Auto Mode 노드가 SELinux enforcing mode, read-only root file system을 포함한 locked-down AMI를 쓰며, 노드 최대 수명은 21일이고 그 이후 새 노드로 교체된다고 설명한다. 이건 CVE 패치와 노드 순환을 팀의 수동 루틴에서 AWS 관리 흐름으로 옮기는 효과가 있다.

전환 전에 제일 먼저 볼 레이블 문제

딜라이트룸 사례에서 제일 실전적인 함정은 레이블이다. self-managed Karpenter에서 쓰던 karpenter.k8s.aws/* 접두사 레이블이 Auto Mode 노드에서는 eks.amazonaws.com/* 접두사로 바뀌면서, 일부 워크로드가 개발 환경에서 스케줄링되지 않았다.

예를 들어 기존 nodeSelector가 karpenter.k8s.aws/instance-category를 보고 있었다면 Auto Mode 노드의 eks.amazonaws.com/instance-category와 맞지 않아 Pod가 Pending 상태로 빠질 수 있다. 이건 글로 보면 단순해 보이지만, 실제 운영에서는 배포 직후 “왜 특정 워크로드만 안 뜨지?”로 나타난다. 이때 사람 정신도 같이 Pending 된다.

전환 전에는 전체 워크로드에서 nodeSelector, nodeAffinity, tolerations, topologySpreadConstraints, PDB를 먼저 긁어봐야 한다. 레이블 문자열 검색만 해도 1차 위험은 잡힌다. Helm values, Kustomize overlay, Terraform/Pulumi 템플릿에 박힌 레이블까지 같이 봐야 한다.

운영 순서는 개발 클러스터에서 먼저 실패를 보게 만드는 쪽이 낫다. 딜라이트룸도 개발 환경 전환에서 레이블 불일치를 찾고 운영 환경 전환 전 워크로드를 수정했다. Auto Mode 전환은 멋진 스위치가 아니라, 기존 워크로드가 어떤 노드 가정을 하고 있었는지 까발리는 행사에 가깝다.

로그와 진단은 따로 다시 설계해야 한다

EKS Auto Mode에서 Karpenter, VPC CNI, Load Balancer Controller, EBS CSI 같은 핵심 컴포넌트는 고객 클러스터 안의 Pod로 보이지 않을 수 있다. AWS best practices 문서도 Auto Mode에서는 Karpenter나 AWS Load Balancer Controller 같은 구성 요소가 클러스터 외부에서 관리되므로 self-managed 때와 같은 로그 가시성을 기대하면 안 된다고 설명한다.

딜라이트룸은 이 제약을 CloudWatch Vended Logs와 NodeDiagnostic CRD로 보완했다. 상시 모니터링은 AUTO_MODE_COMPUTE_LOGS, AUTO_MODE_IPAM_LOGS, AUTO_MODE_BLOCK_STORAGE_LOGS, AUTO_MODE_LOAD_BALANCING_LOGS 중 필요한 로그를 CloudWatch Logs로 보내는 방식이다. 사례에서는 Karpenter 동작과 IPAM 동작을 먼저 보기 위해 compute와 IPAM 로그를 우선 켰고, 보존 기간은 30일로 설정했다.

사후 진단은 NodeDiagnostic CRD를 썼다. 특정 노드의 시스템 로그를 S3 pre-signed URL로 업로드하게 만들고, 이 과정을 스크립트로 자동화한 것이다. 특히 수집 중 대상 노드가 Karpenter consolidation으로 조기 종료되지 않도록 karpenter.sh/do-not-disrupt 어노테이션을 붙였다가 제거한 부분이 실전적이다.

즉, Auto Mode 전환은 “로그를 AWS가 알아서 보관해주겠지”가 아니다. 기존 kubectl logs, SSH, SSM 중심의 진단 루틴을 CloudWatch Logs, Support ticket, NodeDiagnostic, S3 보관 정책 중심으로 바꿔야 한다. 이 작업을 안 해두면 장애 때 운영 부담은 줄지 않고 관측성만 줄어드는 묘한 상태가 된다.

EBS와 로드밸런서는 자동 이전을 기대하면 안 된다

공식 마이그레이션 문서에서 특히 조심할 부분은 EBS CSI와 로드밸런서다. AWS는 기존 EBS CSI 컨트롤러에서 EKS Auto Mode EBS CSI 컨트롤러로 볼륨을 직접 마이그레이션하는 것을 지원하지 않는다고 설명한다. 프로비저너가 ebs.csi.aws.com에서 ebs.csi.eks.amazonaws.com로 달라지기 때문이다.

PersistentVolume을 쓰는 워크로드가 있으면 전환 전에 스토리지 클래스와 PVC/PV 관계를 따로 봐야 한다. 공식 문서는 retain policy, 기존 PV 제거, 동일 EBS 볼륨을 참조하는 새 PV 생성, 새 PVC 바인딩 같은 절차를 안내하지만, 이건 운영 중 데이터가 걸린 작업이다. 비프로덕션에서 검증하고 백업을 준비하라는 말을 가볍게 넘기면 안 된다.

로드밸런서도 비슷하다. AWS 문서는 self-managed AWS Load Balancer Controller에서 EKS Auto Mode로 기존 로드밸런서를 직접 이전할 수 없고, 블루/그린 배포와 DNS 기반 트래픽 이동을 권장한다. Service의 loadBalancerClass, IngressClass의 controller 값도 Auto Mode용 값으로 달라진다.

그래서 전환 체크리스트는 컴퓨트만 보면 반쪽이다. stateless workload만 있는 개발 클러스터에서는 쉽게 성공해도, 프로덕션에서는 EBS, Ingress, NLB, ALB, DNS, 인증서, 헬스체크가 같이 움직인다. Auto Mode가 편해지는 지점은 분명하지만, 마이그레이션 순간에는 오히려 체크할 표가 늘어난다.

언제 EKS Auto Mode가 잘 맞나

EKS Auto Mode는 클러스터 수가 늘어나는데 인프라 팀이 작고, Karpenter/노드/애드온 업그레이드가 반복 업무로 굳은 팀에 잘 맞는다. 딜라이트룸처럼 앱 인수나 서비스 확장으로 클러스터가 5개에서 10개 이상으로 늘어나는 상황에서는 “각 클러스터마다 같은 일을 반복하는 비용”이 눈에 보이기 시작한다.

또 하나는 표준화가 가능한 팀이다. Pulumi, Terraform, eksctl 같은 IaC로 클러스터 생성과 온보딩을 관리하고, 개발-스테이징-운영 순서로 검증할 수 있어야 Auto Mode 전환의 이점이 커진다. 수동 콘솔 작업과 구전 운영 지식이 많으면 Auto Mode가 문제가 아니라 기존 운영 습관이 먼저 발목을 잡는다.

반대로 노드에 직접 접근해 호스트 레벨 도구를 설치해야 하거나, 특정 OS 기능에 강하게 의존하거나, 로드밸런서와 EBS 마이그레이션을 당장 쪼갤 수 없는 팀은 천천히 가야 한다. AWS 문서도 Auto Mode 관리형 인스턴스에는 직접 접근하거나 소프트웨어를 설치할 수 없다고 설명한다. 이런 워크로드는 DaemonSet으로 대체 가능한지부터 따져야 한다.

비용도 확인해야 한다. AWS best practices 문서는 Auto Mode가 표준 EC2 요금은 유지하면서 Auto Mode 관리형 노드에 대해서만 관리 요금을 추가한다고 설명한다. 운영 시간을 줄이는 비용과 관리 요금, CloudWatch Logs 비용, 마이그레이션 작업 시간을 같이 놓고 봐야 한다.

전환 전 10분 체크리스트

체크 항목	봐야 할 것	위험 신호
Karpenter 레이블	`karpenter.k8s.aws/`, `karpenter.sh/` 참조	Pod Pending, 특정 워크로드만 미스케줄
PDB/NDB	업그레이드와 노드 교체를 막는 정책	21일 노드 교체나 패치가 지연될 수 있음
EBS CSI	StorageClass, PVC, PV, provisioner	기존 볼륨 직접 이전 기대
로드밸런서	IngressClass, Service `loadBalancerClass`	기존 ALB/NLB를 자동 이전한다고 가정
관측성	CloudWatch Vended Logs, NodeDiagnostic, S3 보관	`kubectl logs`와 SSH만 믿고 있음
IaC	NodePool/NodeClass, 로그 설정, 태그, 권한	콘솔 수동 전환 후 재현 불가
비용	관리 요금, 로그 비용, 전환 작업 시간	EC2 비용만 비교

내가 운영팀이라면 첫 전환은 프로덕션이 아니라 “실제로 비슷한 워크로드가 있는 개발 클러스터”에서 한다. 빈 샘플 클러스터에서 성공하는 건 당연하다. 중요한 건 기존 서비스가 갖고 있던 nodeSelector, EBS, Ingress, 헬스체크, 배포 순서가 Auto Mode에서 어디서 삐걱이는지 먼저 보는 것이다.

그리고 전환 후에는 성공 여부를 “Pod가 떴다”로 끝내지 않는다. 업그레이드 시간, 신규 클러스터 생성 시간, Pending 이벤트, 노드 교체 이벤트, CloudWatch 로그 수집 누락, 장애 시 진단 로그 확보 시간을 같이 기록해야 한다. 그래야 Auto Mode가 진짜 운영 부담을 줄였는지, 단순히 부담의 위치만 바꿨는지 판단할 수 있다.

TECHTAEK식 판단

EKS Auto Mode는 좋은 기능이다. 하지만 좋은 기능일수록 도입 문서가 얇으면 나중에 팀이 고생한다. 특히 Karpenter를 이미 잘 쓰고 있는 팀이라면 “관리형이니까 편하겠지”보다 “내가 직접 만지던 부분이 어디로 숨는가”를 먼저 봐야 한다.

이번 딜라이트룸 사례의 좋은 점은 성공 숫자만 보여준 게 아니라 레이블 불일치, 로그 가시성, NodeDiagnostic 자동화 같은 운영 지점을 같이 보여줬다는 점이다. 이런 글은 복붙할 답안지가 아니라 체크리스트 재료로 써야 한다.

내 기준에서 EKS Auto Mode는 클러스터가 1개일 때보다 5개, 10개로 늘어날수록 설득력이 커진다. 반복되는 업그레이드와 노드 패치가 플랫폼팀의 시간을 계속 먹고 있다면 검토 가치가 높다. 대신 PVC와 로드밸런서가 복잡하고, 노드 접근에 기대는 운영이 많고, 관측성 자동화가 약하면 먼저 정리부터 해야 한다.

그래서 오늘의 결론은 단순하다. EKS Auto Mode를 켜기 전에 karpenter.k8s.aws/* 검색, PDB 점검, EBS/로드밸런서 마이그레이션 표, CloudWatch/NodeDiagnostic 로그 루틴부터 만든다. 이 네 가지가 준비되면 Auto Mode는 꽤 매력적인 운영 축소 카드가 된다. 준비 없이 누르면 그냥 클라우드가 대신 화내는 것처럼 보일 수 있다.

FAQ

EKS Auto Mode는 Karpenter를 완전히 대체하나?

운영 관점에서는 self-managed Karpenter의 배포, 확장, 업그레이드 부담을 AWS 관리 영역으로 넘긴다고 보는 편이 맞다. AWS 문서도 EKS Auto Mode가 Karpenter 기반 시스템을 사용한다고 설명한다. 다만 NodePool과 NodeClass 개념은 계속 중요하다.

기존 Karpenter와 EKS Auto Mode를 같이 둘 수 있나?

AWS 문서는 마이그레이션이나 고급 구성 중 둘을 같이 설치할 수 있지만, 워크로드가 Karpenter 또는 Auto Mode 중 어느 쪽 NodePool을 사용할지 명확히 구성해야 한다고 설명한다. 둘을 섞는다면 임시 전환 전략인지 장기 운영 구조인지부터 정해야 한다.

Auto Mode를 켜면 EBS 볼륨도 자동으로 이전되나?

아니다. 공식 마이그레이션 문서는 기존 EBS CSI 컨트롤러와 EKS Auto Mode EBS CSI 컨트롤러 사이의 볼륨 직접 마이그레이션을 지원하지 않는다고 설명한다. 프로덕션 PVC가 있다면 비프로덕션 검증과 백업을 먼저 해야 한다.

로드밸런서는 기존 ALB/NLB를 그대로 가져가나?

그렇게 기대하면 위험하다. AWS 문서는 self-managed AWS Load Balancer Controller에서 EKS Auto Mode로 기존 로드밸런서를 직접 이전할 수 없고, 블루/그린과 DNS 기반 트래픽 이동을 권장한다.

EKS Auto Mode가 맞지 않는 팀은 어떤 팀인가?

호스트 OS에 직접 접근해야 하거나, 특정 AMI 커스터마이징에 의존하거나, EBS/로드밸런서 마이그레이션을 분리할 수 없거나, 관측성 체계가 아직 kubectl logs와 SSH에만 기대는 팀은 천천히 가는 편이 낫다. 먼저 운영 가정을 줄인 뒤 Auto Mode를 검토해야 한다.

도입 성과는 무엇으로 봐야 하나?

업그레이드 시간, 신규 클러스터 온보딩 시간, 수동 관리 컴포넌트 수, 보안 패치 반영 속도, 장애 시 진단 로그 확보 시간을 같이 봐야 한다. 딜라이트룸 사례처럼 전환 전후 수치를 기록해야 기능 도입이 아니라 운영 개선인지 판단할 수 있다.