2026년 7월 말, KubeCon + CloudNativeCon Japan이 요코하마에서 열렸다. 이번 행사의 공통된 주제는 AI 워크로드를 기존 클라우드 네이티브 생태계 위에 어떻게 통합하느냐였다. 아래는 현장에서 다룬 세션 여섯 개를 정리한 내용이다.

1. 키노트: CNCF 현황과 AI 시대의 클라우드 네이티브

CNCF 생태계 현황

Linux Foundation의 Jonathan Bryce(Executive Director)와 Chris Aniszczyk(CTO)가 키노트를 진행했다. KubeCon EU 기준 참석자 13,500명 이상, 100개국 3,500개 조직이 참여했다고 밝혔다. CNCF 프로젝트는 230개를 넘었고 전 세계 기여자는 30만 명, 개발자 수는 6개월 만에 1,500만 명에서 약 2,000만 명으로 늘었다.

이 시리즈의 마지막 편은 Domain 6: Measuring your Platform (8%) 를 정리한다. 핵심 메시지는 측정이 플랫폼을 비용 센터(cost center)에서 전략적 조력자(strategic enabler)로 전환한다는 것이다. 감이 아니라 데이터 기반(data-driven) 플랫폼 엔지니어링을 지향한다.

측정의 3대 기둥

측정은 세 축으로 이뤄진다.

• Business Impact: 속도, 품질, 혁신
• Developer Experience: 생산성, 만족도, 채택률
• Operational Efficiency: 비용 최적화, 인시던트 감소, 인프라 활용률

개발자 만족도 지표로는 NPS, 채택률, Time to First Success/Deploy, 지원 요청 빈도가 있다. 측정 원칙은 자동 수집 필수 이며, 수동 수집은 실패한다.

이번 편은 Domain 5: IDPs and Developer Experience (8%) 를 정리한다. 핵심 메시지는 플랫폼 성공의 최고 지표가 자발적 채택(voluntary adoption) 이라는 것이다. 개발자의 인지 부하(cognitive load)를 낮추는 단순·발견 가능·일관된 인터페이스가 IDP의 핵심이다.

단순화된 접근 (Simplified Access)

개발자는 하루 15개 이상의 도구를 전환하며, 플랫폼이 이 부담을 줄여야 한다. 복잡하면 개발자는 채택하지 않으므로, 채택이 곧 플랫폼의 생존 이다.

CLI 설계의 핵심 원칙은 Web UI, CLI, IDE 플러그인이 모두 동일한 기반 API를 호출 한다는 것이다. 이는 일관성과 확장성을 보장한다.

이번 편은 Domain 4: Platform APIs and Provisioning Infrastructure (12%) 를 정리한다. 핵심은 Kubernetes의 API + 조정 루프(reconciliation loop) 가 플랫폼 엔지니어링의 엔진이라는 것이다. CRD·Operator·프로비저닝 도구로 Kubernetes를 확장해 셀프서비스 API를 만든다.

Kubernetes API와 조정 루프

모든 도구(kubectl, 대시보드, 커스텀 훅)가 동일한 API와 상호작용한다. 오브젝트는 spec(원하는 상태) 과 status(Kubernetes가 채우는 관측 상태) 로 구성된다.

조정 루프의 4단계는 핵심이다.

Observe(관찰) → Compare(원하는 상태와 비교) → Act(차이가 있으면 조치) → Repeat(반복)

이 루프는 폴링이 아니라 이벤트 기반(event-driven) 이다. 컨트롤러는 변경 이벤트에 반응하며, Informer가 watch로 감시하고 캐싱한다.

이번 편은 Domain 3: Continuous Delivery & Platform Engineering (16%) 를 정리한다. 핵심은 플랫폼 엔지니어가 CI/CD를 직접 구현하는 것이 아니라 개발팀에게 CI/CD를 서비스로(as a Service) 제공한다는 것이다. 4대 요구사항은 속도와 안전의 균형, 내장 보안, 관측성, 일관성이다.

파이프라인 아키텍처

파이프라인은 Commit → Build → Test → Security Scan → Package → Deploy → Post-deployment Validation 순서로 진행된다. 각 단계는 품질 게이트(quality gate) 이며, 어느 단계든 실패하면 파이프라인을 중지하는 Fail Fast 원칙을 따른다.

이번 편은 Domain 2: Platform Observability, Security, and Conformance (20%) 를 정리한다. 핵심 메시지는 관측성과 보안이 사후 추가가 아니라 처음부터 내장(built-in, not an afterthought) 되어야 한다는 것이다. 반복 철학은 Zero Trust, Shift Left, Least Privilege(최소 권한) 다.

관측성 기초 (Observability Fundamentals)

전통적 Monitoring은 무엇이(what) 고장났는지 보여준다. Observability는 왜(why) 고장났는지 보여준다.

3대 기둥(Three Pillars)은 다음과 같이 구분한다.

시험은 “어떤 신호를 써야 하는가"를 자주 묻는다. 숫자 추세는 metrics, 상태 변화는 logs, end-to-end 흐름은 traces다.

선언적 vs 명령적 (Declarative vs Imperative)

Imperative(명령적) 는 레시피처럼 단계별로 How를 지시한다. Declarative(선언적) 는 메뉴 주문처럼 원하는 결과, 즉 desired state(원하는 상태) 만 선언한다.

플랫폼 엔지니어링은 선언적 접근을 선호(preferred) 한다. 선언된 상태는 control loop(제어 루프) 가 감시하며 실제 상태를 원하는 상태로 reconcile(조정) 한다.

Imperative가 여전히 유효한 경우는 디버깅, 긴급 핫픽스(emergency hotfix), 긴급 스케일링, 실험 정도다. 단, 이후 반드시 선언적 정의로 반영(backfill)해야 한다.