Skip to content
Published on

CNPE(Certified Cloud Native Platform Engineer) 완벽 가이드 - 시험 범위부터 실전 기술 스택까지

Authors
  • Name
    Twitter

1. CNPE란?

**CNPE(Certified Cloud Native Platform Engineer)**는 CNCF에서 2025년 11월에 공식 발표한 최고급 수준의 자격증이다. 엔터프라이즈 규모의 **내부 개발자 플랫폼(IDP)**을 설계하고 운영하는 고급 실무 역량을 검증한다.

CNCF CTO Chris Aniszczyk가 밝힌 바에 따르면, 이 자격증은 "플랫폼 아키텍처, GitOps, Observability, 보안, 개발자 경험을 아우르는 프로덕션 수준의 클라우드 네이티브 시스템 역량"을 인증한다.

1.1 시험 형식

항목내용
시간120분
형식100% 실습형(Performance-based), 온라인 감독
환경Linux 기반 원격 데스크톱 (터미널 + 웹 인터페이스)
오픈북kubernetes.io/docs 및 과제별 Quick Reference 문서 참조 가능
응시료$445 USD
재응시1회 무료 포함
유효기간2년
시뮬레이터Killer.sh 2회 포함

1.2 선행 요건

공식적인 필수 선행 요건은 없으나, CNPA(Certified Cloud Native Platform Associate) 또는 CKA 수준의 Kubernetes 관리 경험이 강력히 권장된다.

1.3 대상

  • 숙련된 Platform Engineer
  • Senior DevOps / SRE
  • Platform Architect
  • Infrastructure Engineer

2. 시험 도메인 개요

CNPE 시험은 5개 핵심 도메인으로 구성된다.

도메인비중
GitOps 및 지속적 배포 (GitOps and Continuous Delivery)25%
플랫폼 API 및 셀프 서비스 (Platform APIs and Self-Service Capabilities)25%
관측성 및 운영 (Observability and Operations)20%
플랫폼 아키텍처 및 인프라 (Platform Architecture and Infrastructure)15%
보안 및 정책 적용 (Security and Policy Enforcement)15%

업계에서 자주 언급되는 레퍼런스 아키텍처는 BACK 스택: Backstage + Argo CD + Crossplane + Kyverno이다. 단, 시험은 벤더 중립적이므로 Argo CD 대신 Flux, Kyverno 대신 OPA/Gatekeeper 등으로 대체 가능하다.


3. Domain 1: GitOps 및 지속적 배포 (25%)

3.1 GitOps 핵심 원칙

OpenGitOps(opengitops.dev)에서 정의한 4가지 핵심 원칙이다.

원칙설명
Declarative시스템의 원하는 상태를 선언적으로 표현한다
Versioned and Immutable원하는 상태를 Git에 저장하여 변경 이력을 추적한다
Pulled Automatically에이전트가 소스에서 원하는 상태를 자동으로 가져온다 (Push가 아닌 Pull)
Continuously Reconciled실제 상태와 원하는 상태의 차이를 지속적으로 감지하고 자동 복원한다

3.2 Argo CD 아키텍처

Argo CD는 Kubernetes를 위한 선언적 GitOps CD 도구로, 3개의 핵심 컴포넌트로 구성된다.

  • API Server (argocd-server): gRPC/REST 서버로 Web UI와 CLI API를 제공한다. 애플리케이션 관리, RBAC 적용, Git webhook 수신을 담당한다.
  • Repository Server (argocd-repo-server): Git 저장소의 로컬 캐시를 유지하고, 리비전과 경로에 따른 Kubernetes 매니페스트를 생성한다.
  • Application Controller (argocd-application-controller): 실행 중인 애플리케이션을 지속 감시하며, 현재 상태와 Git의 목표 상태를 비교하여 OutOfSync를 탐지한다.

Application CRD 예시:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true # Git에서 제거된 리소스 삭제
      selfHeal: true # 수동 변경 자동 복원

3.3 Argo CD Sync 정책

정책기본값설명
automateddisabledOutOfSync 감지 시 자동 동기화
prunefalseGit에서 삭제된 리소스를 클러스터에서도 제거
selfHealfalse클러스터의 수동 변경(drift)을 Git 상태로 자동 복원
allowEmptyfalse매니페스트가 0개일 때 동기화 허용 여부

3.4 ApplicationSet으로 멀티 클러스터 배포

ApplicationSet은 단일 템플릿에서 여러 Application 리소스를 생성하는 CRD다. Generator를 통해 파라미터를 동적으로 생성한다.

주요 Generator:

Generator설명
ClusterArgo CD에 등록된 클러스터 자동 탐지
Git Directory리포지토리의 디렉토리 구조에서 앱 생성
Matrix두 Generator의 파라미터를 조합 (Cartesian Product)
Pull Request열린 PR마다 프리뷰 환경 생성
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-apps
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: '{{.name}}-my-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/apps.git
        targetRevision: HEAD
        path: deploy/production
      destination:
        server: '{{.server}}'
        namespace: my-app

3.5 Flux CD

Flux는 CNCF GitOps Toolkit 기반의 CD 도구로, 5개의 전문화된 컨트롤러로 구성된다.

컨트롤러CRD역할
Source ControllerGitRepository, HelmRepository, OCIRepositoryGit/Helm/OCI에서 아티팩트 가져오기
Kustomize ControllerKustomizationKustomize 오버레이 또는 Plain YAML 적용
Helm ControllerHelmReleaseHelm 차트 라이프사이클 관리
Notification ControllerProvider, Alert, Receiver알림 발송 및 인바운드 웹훅 처리
Image AutomationImageRepository, ImagePolicy컨테이너 레지스트리 스캔 및 자동 업데이트

Flux Kustomization 예시:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: my-app
  path: ./deploy/production
  prune: true
  wait: true
  dependsOn:
    - name: cert-manager
    - name: ingress-nginx
  postBuild:
    substitute:
      CLUSTER_NAME: production
      DOMAIN: example.com

3.6 Progressive Delivery: Argo Rollouts

Argo Rollouts는 Canary, Blue-Green 등의 점진적 배포 전략을 자동화한다.

Canary 배포 예시:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: my-app-canary
      stableService: my-app-stable
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
        - setWeight: 100
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: myapp:v2

Blue-Green 배포 핵심 설정:

설정설명
autoPromotionEnabled프리뷰 후 자동 프로모션 여부 (기본: true)
autoPromotionSeconds자동 프로모션까지 대기 시간
scaleDownDelaySeconds이전 버전 Pod 종료까지 대기 시간 (기본: 30초)
prePromotionAnalysis트래픽 전환 전 메트릭 검증
postPromotionAnalysis전환 후 검증, 실패 시 롤백

4. Domain 2: 플랫폼 API 및 셀프 서비스 (25%)

4.1 Crossplane으로 셀프 서비스 인프라 구축

Crossplane은 Kubernetes를 범용 Control Plane으로 확장하여 클라우드 인프라를 Kubernetes API로 프로비저닝할 수 있게 한다.

아키텍처: Provider → Managed Resources → Compositions → Composite Resources (XRDs)

Composite Resource Definition (XRD):

apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
  name: mydatabases.example.org
spec:
  scope: Namespaced
  group: example.org
  names:
    kind: XMyDatabase
    plural: mydatabases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                region:
                  type: string
                size:
                  type: string
              required:
                - region
                - size

Composition (구현 템플릿):

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example-database
spec:
  compositeTypeRef:
    apiVersion: example.org/v1alpha1
    kind: XMyDatabase
  mode: Pipeline
  pipeline:
    - step: patch-and-transform
      functionRef:
        name: function-patch-and-transform
      input:
        apiVersion: pt.fn.crossplane.io/v1beta1
        kind: Resources
        resources:
          - name: rds-instance
            base:
              apiVersion: rds.aws.m.upbound.io/v1beta1
              kind: Instance
              spec:
                forProvider:
                  region: us-east-2
                  engine: postgres
                  instanceClass: db.t3.micro
            patches:
              - type: FromCompositeFieldPath
                fromFieldPath: spec.region
                toFieldPath: spec.forProvider.region

셀프 서비스 패턴은 다음과 같다:

  1. 플랫폼 팀이 XRD(API 스키마)와 Composition(구현)을 정의한다.
  2. 개발자는 자신의 네임스페이스에서 XRD 인스턴스를 생성한다.
  3. Crossplane이 자동으로 클라우드 리소스를 프로비저닝하고 관리한다.
  4. 개발자는 클라우드 Provider API를 직접 다루지 않는다.

4.2 Backstage: Internal Developer Portal

Backstage(CNCF Incubating)는 Spotify가 개발한 오픈소스 IDP 프레임워크다.

핵심 기능:

기능설명
Software Catalog모든 소프트웨어 자산의 중앙 레지스트리
Software Templates표준화된 프로젝트 생성 자동화
TechDocsDocs-like-code 방식의 기술 문서
Plugin 아키텍처확장 가능한 플러그인 시스템

Software Catalog 엔티티 정의:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Payment processing microservice
  tags:
    - java
    - spring-boot
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: payment-platform
  dependsOn:
    - resource:default/payments-db
  providesApis:
    - payment-api

Software Template 예시:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: Create New Microservice
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Details
      required:
        - name
        - owner
      properties:
        name:
          title: Service Name
          type: string
        owner:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetchBase
      name: Fetch Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{parameters.name}}
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=${{parameters.name}}
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{steps.publish.output.repoContentsUrl}}
        catalogInfoPath: /catalog-info.yaml

4.3 CRD와 Operator 패턴

플랫폼 API의 기반은 Kubernetes **Custom Resource Definitions(CRD)**와 Operator 패턴이다.

Operator는 도메인별 운영 지식을 Kubernetes 컨트롤러에 인코딩한다.

Control Loop:
  1. Observe: Custom Resource 변경 감시
  2. Analyze: 현재 상태와 목표 상태 비교
  3. Act: 종속 리소스 생성/업데이트/삭제로 상태 조정

주요 Operator 프레임워크:

프레임워크언어
KubebuilderGo
Operator SDKGo, Ansible, Helm
KopfPython
kube-rsRust
Metacontroller모든 언어 (웹훅 방식)

5. Domain 3: 관측성 및 운영 (20%)

5.1 OpenTelemetry

OpenTelemetry(OTel)는 CNCF Observability 프레임워크로, 3가지 핵심 신호를 통합 수집한다.

신호설명용도
Traces분산 시스템에서의 요청 경로 추적마이크로서비스 간 요청 흐름 이해
Metrics런타임 측정값 (Counter, Gauge, Histogram)성능 추세 및 리소스 사용률 모니터링
Logs타임스탬프가 있는 이벤트 기록특정 시점의 디버깅 컨텍스트

OTel Collector 설정:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 2000
  batch:
    timeout: 10s

exporters:
  otlp/jaeger:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]

Kubernetes Auto-Instrumentation:

OTel Operator를 사용하면 코드 수정 없이 자동 계측이 가능하다.

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  exporter:
    endpoint: http://otel-collector:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: '1'

Deployment에 어노테이션 추가로 자동 계측 활성화:

metadata:
  annotations:
    instrumentation.opentelemetry.io/inject-java: 'true' # Java
    instrumentation.opentelemetry.io/inject-python: 'true' # Python
    instrumentation.opentelemetry.io/inject-nodejs: 'true' # Node.js

5.2 Prometheus와 Grafana 스택

Prometheus 아키텍처:

컴포넌트역할
Prometheus Server시계열 데이터 수집 및 저장 (Pull 기반)
Alertmanager알림 라우팅, 중복 제거, 발송
Exporters서드파티 시스템 메트릭 어댑터
Service DiscoveryKubernetes, Consul, DNS 등 자동 타겟 탐지

ServiceMonitor CRD (Prometheus Operator):

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

PromQL 핵심 쿼리:

# 초당 요청률 (5분 윈도우)
rate(http_requests_total[5m])

# Job별 합산
sum by (job) (rate(http_requests_total[5m]))

# P99 지연시간
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 에러율
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Grafana 관측성 스택:

                  +-----------+
                  |  Grafana  |  (대시보드, 알림)
                  +-----+-----+
                        |
           +------------+------------+
           |            |            |
      +----+----+  +---+---+  +-----+-----+
      |  Mimir  |  |  Loki |  |   Tempo   |
      | Metrics |  |  Logs |  |  Traces   |
      +----+----+  +---+---+  +-----+-----+
           |            |            |
           +------------+------------+
                        |
               +--------+--------+
               | OTel Collector  |
               +-----------------+
                        |
                [Applications]
  • Mimir: 수평 확장 가능한 장기 메트릭 저장소
  • Loki: 라벨 기반 인덱싱의 경량 로그 집계 시스템
  • Tempo: 대규모 분산 트레이싱 백엔드

5.3 SLI/SLO와 Error Budget

개념정의예시
SLI서비스 성능의 정량적 측정값요청 성공률, P99 지연시간
SLOSLI의 목표 범위"99.9%의 요청이 200ms 이내 완료"
SLASLO 미달 시 책임이 있는 계약"가용성 99.95% 미만 시 서비스 크레딧 제공"

Error Budget 계산:

Error Budget = 1 - SLO

SLO 99.9%Error Budget 0.1% → 월간 약 43.2분 다운타임 허용
SLO 99.99%Error Budget 0.01% → 월간 약 4.32분 다운타임 허용

Error Budget 정책:

소진률조치
0-50% (Green)정상 기능 개발 진행
50-80% (Yellow)안정성 중심 작업 강화, 코드 리뷰 강화
80-100% (Red)기능 동결, 안정성 작업에 전력 집중

5.4 DORA 메트릭

플랫폼 효율성을 측정하는 핵심 메트릭이다.

메트릭설명
Deployment Frequency배포 빈도
Lead Time for Changes코드 커밋에서 프로덕션 배포까지의 시간
Change Failure Rate배포 후 장애가 발생한 비율
Mean Time to Recovery장애 발생부터 복구까지의 평균 시간

6. Domain 4: 플랫폼 아키텍처 및 인프라 (15%)

6.1 멀티 테넌시 패턴

패턴격리 수준적합한 상황
Namespace 기반논리적 격리신뢰할 수 있는 내부 팀
Cluster 기반물리적 격리강력한 보안 요구, 규제 환경
하이브리드혼합환경별 차등 격리 필요 시

Namespace 기반 격리 도구:

# ResourceQuota로 리소스 제한
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: '10'
    requests.memory: 20Gi
    limits.cpu: '20'
    limits.memory: 40Gi
    pods: '50'
---
# NetworkPolicy로 네트워크 격리
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

6.2 비용 관리: OpenCost

OpenCost(CNCF Sandbox)는 Kubernetes 비용 가시성과 할당을 제공하는 오픈소스 도구다. 네임스페이스, 팀, 서비스별 비용을 추적하고 리소스 Right-Sizing을 지원한다.

6.3 오토스케일링 전략

스케일러대상기준
HPAPod 수평 확장CPU/메모리/커스텀 메트릭
VPAPod 리소스 요청 조정실제 사용량 분석
Cluster Autoscaler노드 수평 확장Pending Pod 감지
KEDA이벤트 기반 확장큐 길이, HTTP 요청 등

7. Domain 5: 보안 및 정책 적용 (15%)

7.1 OPA/Gatekeeper

OPA Gatekeeper는 ConstraintTemplate(Rego로 정책 로직 정의)과 Constraint(정책 적용 대상 지정) 두 리소스로 운영된다.

ConstraintTemplate 예시 (필수 라벨 검증):

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

Constraint 적용:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
spec:
  match:
    kinds:
      - apiGroups: ['']
        kinds: ['Namespace']
  parameters:
    labels: ['team', 'environment']

7.2 Kyverno

Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML + CEL 기반이라 별도 언어 학습이 필요 없다. validate, mutate, generate 세 가지 유형의 룰을 지원한다.

ClusterPolicy 예시 (리소스 제한 필수):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: 'CPU and memory resource limits are required.'
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: '?*'
                    memory: '?*'

7.3 OPA/Gatekeeper vs Kyverno 비교

항목OPA/GatekeeperKyverno
정책 언어Rego (전용 언어)YAML + CEL
학습 곡선높음낮음
Validate지원지원
Mutate제한적완전 지원
Generate제한적완전 지원 (네임스페이스 간 동기화)
범용성멀티 플랫폼 (K8s 외 사용 가능)Kubernetes 전용
CNCF 상태Graduated (OPA)Incubating

7.4 Supply Chain 보안

  • SBOM(Software Bill of Materials): 소프트웨어 구성 요소 목록 생성 및 관리
  • 컨테이너 이미지 스캔: CI/CD 파이프라인에 Shift Left 보안 통합
  • Falco: 런타임 보안 위협 탐지 (CNCF Graduated)

8. 추천 학습 계획 (12주)

주차내용
1-3주Kubernetes 기초 복습 + GitOps 원칙 + ArgoCD/Flux 실습
4-5주Crossplane XRD/Composition 설계 + CRD/Operator 개발
6-7주Backstage 셋업 + Software Template 작성
8-9주OpenTelemetry + Prometheus + Grafana 스택 구성
10주OPA/Kyverno 정책 적용 + 보안 파이프라인 구축
11-12주통합 플랫폼 실습 + CNCF 공식 리소스 복습 + Killer.sh 모의시험

9. 필수 학습 리소스

리소스URL
CNPE 공식 페이지training.linuxfoundation.org/certification/cnpe
CNCF 커리큘럼 (오픈소스)github.com/cncf/curriculum
CNCF Platforms White Papertag-app-delivery.cncf.io/whitepapers/platforms
Platform Engineering Maturity Modeltag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model
Killer.sh 시뮬레이터시험 등록 시 2회 포함

관련 보조 자격증: CKA, CNPA, CGOA(Certified GitOps Associate), OTCA(OpenTelemetry Certified Associate), CBA(Certified Backstage Associate)


References