들어가며
안녕하세요, 수누다입니다.
쿠버네티스를 운영하다 보면 가장 많이 받는 요청이 무엇인가요? 아마 "새로운 네임스페이스 만들어주세요", "DB 인스턴스 하나 띄워주세요" 같은 반복적인 작업일 겁니다. 13년 차인 저도 한때는 YAML 파일 복사해서 붙여넣느라 밤을 새우곤 했죠.
하지만 2026년의 k8s 운영은 달라야 합니다. 개발자가 인프라를 직접, 하지만 안전하게 제어할 수 있는 IDP(Internal Developer Platform)로 진화해야 합니다. 오늘 그 핵심 아키텍처를 짚어봅니다.
준비물 / 핵심 스펙 분석
IDP를 구축하기 위해 우리가 주목해야 할 '삼대장' 스택입니다.
- Portal (Backstage): Spotify에서 공개한 IDP 프레임워크입니다. 개발자가 사용하는 단일 창구 역할을 합니다.
- Control Plane (Crossplane): 쿠버네티스 커스텀 리소스(CRD)를 통해 AWS, Azure 같은 외부 클라우드 자원을 k8s 오브젝트처럼 관리하게 해줍니다.
- GitOps (ArgoCD): 선언적인 인프라 관리를 위한 마지막 퍼즐 조각입니다.
단계별 가이드: 플랫폼 엔지니어로 거듭나기
1단계: Infrastructure as Code에서 Control Plane으로
Terraform도 훌륭하지만, 이제는 Crossplane을 고려해야 할 때입니다. Terraform은 실행 시점에만 상태를 확인하지만, Crossplane은 k8s의 Reconciliation Loop를 활용해 인프라 상태를 실시간으로 감시하고 보정합니다.
2단계: Backstage를 통한 셀프 서비스화
개발자에게 kubectl 권한을 주는 대신, Backstage 포털에서 버튼 클릭 한 번으로 "표준화된 개발 환경"이 배포되도록 템플릿을 제공하세요. 이는 엔지니어의 반복 업무를 줄이고 보안 사고를 방지하는 최선의 방법입니다.
3단계: 가상 클러스터(vCluster) 활용
하나의 물리 클러스터에서 네임스페이스만 나누는 건 한계가 있습니다. 최근에는 vCluster를 통해 하나의 k8s 위에 여러 개의 가상 k8s를 띄워 개발자에게 완전한 클러스터 관리 권한을 부여하는 방식이 대세입니다.
⚠️ 엔지니어의 '삽질 방지' Tip
"Resource Quota와 LimitRange는 선택이 아닌 필수입니다."
셀프 서비스 플랫폼을 구축할 때 가장 무서운 게 무엇일까요? 바로 개발자의 실수로 인한 '클라우드 비용 폭탄'과 '노드 자원 고갈'입니다.
IDP 템플릿을 설계할 때 반드시 ResourceQuota를 빡빡하게 설정하세요. 특히 CPU/Memory Limit을 설정하지 않은 파드가 배포되지 않도록 Admission Controller나 Kyverno 같은 정책 엔진을 미리 심어두는 것이 여러분의 연봉과 수면 시간을 지키는 길입니다.
요약
- 플랫폼 엔지니어링: 이제는 k8s 운영자를 넘어 인프라 플랫폼 제작자가 되어야 합니다.
- Crossplane + Backstage: 인프라 프로비저닝을 자동화하고 개발자 경험(DX)을 극대화하는 최강 조합입니다.
- 거버넌스 우선: 자동화보다 중요한 건 정책(Policy)입니다. 배포 전 제약 사항을 반드시 선언하세요.
