EKS로 Kubernetes를 숨기는 법: 내부 개발자 플랫폼 설계 원칙

기업의 80%가 Kubernetes를 프로덕션에서 사용하는 2026년, 정작 개발자들은 Kubernetes를 직접 다루지 않으려 한다. etcd 상태 관리, 컨트롤 플레인 업그레이드, CNI 플러그인 선택, CSI 드라이버 구성 같은 것들은 애플리케이션 비즈니스 로직과는 별개의 전문성을 요구하기 때문이다. AWS는 EKS Auto Mode와 Amazon EKS Capabilities로 이 복잡도를 추상화하는 방향으로 움직이고 있고, 플랫폼 엔지니어링 팀은 내부 개발자 플랫폼(Internal Developer Platform, IDP)으로 Kubernetes 자체를 개발자 시야에서 지워버리는 셀프서비스 인프라를 구축하고 있다.

개발자가 Kubernetes를 피하는 이유

CNCF의 2026년 보고서(12,500명 대상)를 보면 개발자 대다수가 Kubernetes에 직접 접근하지 않고 내부 플랫폼을 거쳐 간접적으로 접근하는 추세가 뚜렷하다. 노드 프로비저닝·패치·스케일링·업그레이드를 플랫폼 팀이 수동으로 관리하는 비용이 높다 보니, 플랫폼 팀이 티켓 처리에 매몰되는 악순환이 생긴다. 개발자 입장에서는 YAML 매니페스트·IAM 정책·네트워크 플러그인 설정 자체가 생산성을 갉아먹는 인지 부하다.

Gartner는 소프트웨어 엔지니어링 조직의 80% 이상이 전담 플랫폼 팀을 보유하고, 75%는 개발자 셀프서비스 포털을 운영할 것으로 전망한다. 플랫폼 팀의 역할도 따라서 바뀌었다 — Kubernetes 전문성 없이도 배포할 수 있는 "황금 경로(Golden Path)"를 개발자에게 제공하는 쪽으로. AWS는 EKS Capabilities를 통해 ArgoCD·ACK·KRO 같은 오픈소스 도구를 EKS에 직접 통합해, 설치·패치·스케일링 부담을 애초에 없애는 방향으로 대응하고 있다.

Kubernetes 복잡도는 어느 레이어에 몰려 있나

Kubernetes의 복잡도는 한 곳에 뭉쳐 있지 않고 여러 레이어에 흩어져 있으며, 레이어마다 요구하는 전문성과 운영 부담이 다르다.

레이어	주요 구성요소	복잡도 원인
컨트롤 플레인	API Server, etcd, Scheduler, Controller Manager	업그레이드 시 하위 호환성·데이터 마이그레이션
네트워크	CNI(VPC CNI, Cilium, Calico)	서브넷 설계·SecurityGroup·NetworkPolicy 충돌
스토리지	CSI(EBS, EFS, S3 CSI)	PV/PVC 생명주기·StorageClass 선택·성능 특성
노드 관리	Node Groups, Managed Node Groups	스팟 가격·인스턴스 다양성·예약 용량 최적화
관측성	Prometheus, Grafana, OpenTelemetry	메트릭·로그·트레이스 파이프라인 통합
보안	RBAC, Pod Security Admission, OPA Gatekeeper	정책 일관성·시크릿 관리·취약점 스캐닝

EKS는 컨트롤 플레인을 완전 관리형으로 제공해 첫 번째 레이어는 이미 추상화했다. 하지만 네트워크·스토리지·노드 관리·보안 레이어의 복잡도는 여전히 사용자 몫으로 남아 있다.

EKS Auto Mode: 노드 관리를 통째로 자동화하기

2024년 re:Invent에서 발표된 EKS Auto Mode는 Karpenter를 기반으로 노드 생명주기 전체를 자동화한다. Pod의 리소스 요구·노드 셀렉터·테인트·톨러레이션·토폴로지 제약을 분석해 EC2 인스턴스를 실시간으로 생성하고, 미사용 노드는 자동 종료해 유휴 비용을 없앤다. OS 패치와 Kubernetes 버전 업그레이드도 자동 적용돼 플랫폼 팀의 유지보수 부담이 줄고, 스팟·온디맨드·Savings Plans를 섞어 비용까지 최적화한다. VPC CNI·EBS CSI·ALB 컨트롤러도 Auto Mode가 내장 관리하기 때문에 별도 설치·설정이 필요 없다.

⤢✕

기존 Cluster Autoscaler가 정적으로 정의된 노드 그룹 안에서 스케일링하는 것과 달리, EKS Auto Mode는 노드 그룹을 미리 정의할 필요 없이 Pod 요구에 맞는 인스턴스를 JIT 방식으로 만들어낸다는 점이 근본적으로 다르다.

Karpenter가 Cluster Autoscaler와 다른 지점

Karpenter는 Cluster Autoscaler의 한계를 넘어서기 위해 AWS가 만든 오픈소스 노드 프로비저너다. 미리 정의된 노드 그룹 없이 Pod 요구에 맞는 최적 인스턴스를 즉시 생성하는 JIT 프로비저닝이 핵심이고, 수백 종의 EC2 인스턴스 유형 중 가격·성능·가용성을 따져 자동으로 고른다. 워크로드를 더 적은 노드에 통합해 빈 노드를 자동 종료하는 컨솔리데이션 기능도 비용 절감에 직결된다. NodePool·EC2NodeClass 같은 선언적 CRD를 쓰면 플랫폼 팀은 제약 조건만 선언하고, 개발자는 Pod 스펙만 작성하면 된다.

항목	Cluster Autoscaler	Karpenter
스케일링 단위	사전 정의 노드 그룹	개별 노드 (JIT)
인스턴스 유형	노드 그룹 설정 범위	수백 종 자동 선택
컨솔리데이션	제한적	고도화된 자동 통합
스케일 속도	분 단위	초~분 단위
설정 복잡도	노드 그룹 수 비례	NodePool CRD 중심

내부 개발자 플랫폼이 지켜야 할 원칙

IDP는 Kubernetes의 복잡도를 개발자로부터 완전히 가리는 셀프서비스 인터페이스이고, 플랫폼 팀이 짓고 운영한다. 원칙은 다섯 가지로 정리된다.

플랫폼 팀이 검증한 배포 템플릿·CI/CD 파이프라인·보안 정책을 기본값으로 제공하는 황금 경로(Golden Path)가 첫 번째다. 개발자가 최선의 방법에서 벗어나기 어렵게 설계하는 것이 목표다. 두 번째는 추상화 우선 — 개발자는 YAML·Terraform·IAM을 몰라도 CPU, 메모리, 스토리지, 환경변수 같은 애플리케이션 요구사항만 선언하면 인프라가 알아서 구성된다. 세 번째는 셀프서비스 자율성으로, 플랫폼 팀 티켓 없이 개발자가 직접 환경을 만들고 배포하고 스케일링해 병목을 없앤다. 네 번째는 가드레일이다. 자율성을 주되 보안·컴플라이언스 정책은 OPA Gatekeeper나 Kyverno로 자동 강제해 "안전한 자율성"을 만든다. 마지막은 관측성 내장 — 로그·메트릭·트레이스가 플랫폼에 기본 제공돼 개발자가 따로 구성할 필요가 없다.

EKS 기반 IDP는 어떻게 조립되는가

⤢✕

각 구성 요소의 역할을 뜯어보면, Backstage는 Spotify가 오픈소스로 공개한 IDP 프레임워크로 서비스 카탈로그·기술 문서·CI/CD 통합을 단일 포털에 모은다. Argo CD는 GitOps 기반 지속 배포를 맡아 Git 저장소를 클러스터 상태의 단일 진실 공급원으로 삼는다. Crossplane은 Kubernetes CRD로 RDS·S3·VPC·ElastiCache 같은 AWS 리소스를 선언적으로 프로비저닝해, 개발자가 Terraform 없이도 데이터베이스를 만들 수 있게 한다. Amazon EKS Capabilities는 ArgoCD·ACK(AWS Controllers for Kubernetes)·KRO를 EKS 안에 직접 통합해 별도 설치·패치·스케일링이 필요 없게 만든다.

개발자가 티켓 없이 인프라를 받는 패턴

플랫폼 팀 개입 없이 개발자가 인프라를 프로비저닝하는 패턴은 크게 세 가지다. 첫째는 추상 인프라(Abstract Infrastructure)로, Backstage의 소프트웨어 템플릿에서 "PostgreSQL 데이터베이스 필요"를 선언하면 Crossplane이 RDS를 자동 생성하고 시크릿을 Secrets Manager에 저장한다. 둘째는 Environment-as-Code로, dev/staging/prod 같은 환경 정의를 Git 저장소에 저장하고 PR 기반으로 생성·삭제하기 때문에 인프라 변경이 코드 리뷰를 반드시 거친다. 셋째는 Namespace-as-a-Service로, 팀별 Kubernetes 네임스페이스를 플랫폼이 자동 생성하면서 RBAC·NetworkPolicy·ResourceQuota·LimitRange까지 함께 적용해 테넌트 격리를 보장한다. 세 패턴 모두 플랫폼 팀이 사전에 정의한 황금 경로 안에서만 셀프서비스를 허용해, 자율성과 거버넌스를 동시에 잡는다.

플랫폼 팀과 애플리케이션 팀, 경계는 어디까지인가

IDP가 오래 살아남는지는 역할 경계가 얼마나 명확한지에 달려 있다.

책임 영역	플랫폼 팀	애플리케이션 팀
클러스터 생성·업그레이드	담당	무관
노드 프로비저닝 (EKS Auto Mode)	정책(NodePool) 정의	무관
네트워크·보안 정책	설계·OPA/Kyverno 강제	준수
앱 배포 파이프라인	황금 경로 템플릿 제공	GitOps PR 실행
모니터링 대시보드	플랫폼 기본 대시보드 제공	애플리케이션 메트릭 추가
데이터베이스·캐시 프로비저닝	Crossplane 컴포지션 정의	Backstage 셀프서비스 선택
시크릿 관리	External Secrets 설정	시크릿 참조만 사용

이 경계 덕분에 플랫폼 팀은 티켓 처리 대신 플랫폼 품질과 개발자 경험 향상에 집중할 수 있고, 애플리케이션 팀은 인프라 지식 없이도 안전하게 배포할 수 있다. EKS Auto Mode와 Karpenter가 인프라 운영의 자동화를 맡고, Backstage·Argo CD·Crossplane이 그 위에서 셀프서비스 인터페이스를 제공하는 구조는 이미 플랫폼 엔지니어링의 표준 패턴으로 자리 잡고 있다.