Platform-Engineering

DevOps 다음은 왜 플랫폼 엔지니어링인가 DevOps는 애플리케이션 팀에게 인프라를 직접 다룰 자유를 줬지만, 그 대가로 모든 팀이 YAML과 IAM, 네트워크 정책을 각자 재발명하는 ‘인지 부하 폭증’을 낳았다. 이 문제를 해결하기 위해 등장한 것이 플랫폼 엔지니어링이다. CNCF는 이를 “플랫폼 팀이 제공하는 능력의 계층으로, 제품 팀이 하부 인프라에 대한 깊은 전문성 없이도 서비스를 빌드·배포·운영할 수 있게 하는 것"이라 정의하며, 골든 패스(Golden Path)를 “가드레일이지 게이트가 아니다"라고 못박는다 (CNCF Platforms White Paper). 실제로 DORA의 2025 State of AI-assisted Software Development 보고서에 따르면 조직의 90%가 내부 개발자 플랫폼(IDP)을 이미 운영 중이고 76%는 전담 플랫폼 팀을 두고 있다. 더 중요한 발견은, AI 도입률이 90%에 달하는 지금 AI는 그 조직의 기존 엔지니어링 시스템을 ‘증폭’할 뿐이라는 점이다. 플랫폼이 부실하면 AI도 그 부실함을 그대로 증폭시킨다. ...

📋 밋업 한눈에 보기 Akamai의 플랫폼 엔지니어가 500개 이상의 클러스터와 8000개 이상의 애플리케이션을 운영하는 사내 Internal Developer Platform 아키텍처를 소개한 발표다. DevOps 셀프서비스 피로에서 platform engineering이 어떻게 태동했는지, 관리 클러스터(SRE 소유)와 애플리케이션 클러스터(서비스 팀 소유)를 Argo CD와 Crossplane으로 GitOps하게 관리하는 구조, Kyverno·Cilium·Istio로 구현한 zero-trust 보안, 그리고 kagent를 활용한 AI 트러블슈팅 실험까지 다뤘다. 발표 후에는 플랫폼 버전 관리, 업그레이드 전략, 책임 분담 모델에 대한 활발한 질의응답이 이어졌다. 🔑 핵심 요점 Platform engineering은 각 팀이 개별적으로 YAML, IAM, 티켓 프로세스를 배워야 했던 DevOps 셀프서비스의 피로에서 출발했다. 플랫폼을 ‘제품’으로, 내부 개발자를 ‘고객’으로 취급하고 문서화와 피드백 루프, 채택률을 성공 지표로 삼는 것이 핵심 원칙이다. 관리 클러스터와 애플리케이션 클러스터를 분리하고, Argo CD와 Crossplane으로 전체 인프라와 애플리케이션을 GitOps 방식으로 관리한다. Kyverno로 정책을 강제하고 Cilium과 Istio로 네트워크 계층의 zero-trust(세그멘테이션, mTLS)를 구현하며, RBAC은 OIDC/SSO와 연동된다. 플랫폼 컴포넌트 전체를 하나의 버전으로 번들링해 배포하며, 업그레이드와 롤백도 git commit 단위로 이루어진다. kagent 같은 AI 에이전트를 도입해 자연어로 클러스터 상태를 질의하고 진단하는 실험을 진행 중이다. DORA 리포트를 인용하며 플랫폼 엔지니어링 도입이 소프트웨어 딜리버리 성과와 개발자 생산성 향상에 실제로 기여한다고 설명했다. 🛠 핵심 기술 쉽게 이해하기 Argo CD Git 저장소에 선언된 상태를 기준으로 Kubernetes 클러스터를 자동으로 동기화해주는 GitOps 배포 도구다. 사람이 직접 kubectl apply를 실행하는 대신, 컨트롤러가 Git의 변경 사항을 감지해 클러스터에 반영한다. ...