[{"content":"DevOps 다음은 왜 플랫폼 엔지니어링인가 DevOps는 애플리케이션 팀에게 인프라를 직접 다룰 자유를 줬지만, 그 대가로 모든 팀이 YAML과 IAM, 네트워크 정책을 각자 재발명하는 \u0026lsquo;인지 부하 폭증\u0026rsquo;을 낳았다. 이 문제를 해결하기 위해 등장한 것이 플랫폼 엔지니어링이다. CNCF는 이를 \u0026ldquo;플랫폼 팀이 제공하는 능력의 계층으로, 제품 팀이 하부 인프라에 대한 깊은 전문성 없이도 서비스를 빌드·배포·운영할 수 있게 하는 것\u0026quot;이라 정의하며, 골든 패스(Golden Path)를 \u0026ldquo;가드레일이지 게이트가 아니다\u0026quot;라고 못박는다 (CNCF Platforms White Paper). 실제로 DORA의 2025 State of AI-assisted Software Development 보고서에 따르면 조직의 90%가 내부 개발자 플랫폼(IDP)을 이미 운영 중이고 76%는 전담 플랫폼 팀을 두고 있다. 더 중요한 발견은, AI 도입률이 90%에 달하는 지금 AI는 그 조직의 기존 엔지니어링 시스템을 \u0026lsquo;증폭\u0026rsquo;할 뿐이라는 점이다. 플랫폼이 부실하면 AI도 그 부실함을 그대로 증폭시킨다.\nGit을 단일 진실 공급원으로: GitOps 플랫폼을 안전하게 운영하려면 \u0026lsquo;무엇이 배포되어 있는가\u0026rsquo;에 대한 감사 가능한 기록이 필요하다. CNCF 산하 OpenGitOps 이니셔티브는 GitOps의 네 가지 원칙으로 선언적 정의, 버전 관리와 불변성, Git을 통한 자동 배포(Pull), 지속적 조정(Reconciliation)을 제시한다. Argo CD는 이 모델을 구현한 CNCF Graduated 프로젝트로, 클러스터 내부에서 컨트롤러로 동작하며 Git의 선언 상태와 실제 클러스터 상태를 지속적으로 비교해 드리프트를 감지하고 되돌린다 (Argo CD GitHub). 즉 인프라 변경도 코드 리뷰와 동일한 PR 승인 절차를 거치게 되어, \u0026lsquo;누가 무엇을 언제 바꿨는지\u0026rsquo; 자체가 감사 로그가 된다.\nKubernetes를 클라우드 전체의 제어 평면으로: Crossplane 애플리케이션 배포에는 GitOps가 표준이 됐지만, 클라우드 인프라(RDS, VPC, IAM 등) 프로비저닝은 여전히 별도 도구가 필요한 경우가 많았다. Crossplane은 Kubernetes의 CRD와 컨트롤러 패턴을 확장해 RDS 인스턴스부터 IAM 역할까지 임의의 클라우드 리소스를 Kubernetes API로 선언·관리하게 해주는 CNCF 프로젝트다 (crossplane.io). 플랫폼 팀은 여러 개별 리소스를 하나의 \u0026lsquo;Composition\u0026rsquo;으로 묶어 애플리케이션 팀에게는 \u0026ldquo;클러스터 하나 주세요\u0026rdquo; 같은 단순한 API만 노출할 수 있다. Terraform과 달리 Crossplane은 클러스터 내부에서 지속적으로 상태를 조정(reconcile)하므로 GitOps와 자연스럽게 맞물린다.\n제로 트러스트와 정책의 자동 강제 플랫폼이 셀프서비스를 제공하는 만큼 보안은 사람이 아니라 정책 엔진이 담당해야 한다. eBPF 기반 CNI인 Cilium은 2023년 CNCF Graduated 등급을 받았으며, IP·포트 기반이 아니라 워크로드의 신원(서비스 어카운트, 레이블)에 기반해 통신을 인가하는 방식으로 제로 트러스트 네트워킹을 구현한다 (Cilium Zero Trust). 여기에 Kyverno 같은 정책 엔진을 더하면, 정책에 어긋나는 워크로드는 클러스터에 진입하기도 전에 거부된다 — 즉 보안 검토가 배포 이후가 아니라 배포 이전 단계로 \u0026lsquo;시프트 레프트\u0026rsquo;된다.\nAI 에이전트, 플랫폼의 새로운 인터페이스 최근 흐름은 이 모든 플랫폼 구성 요소를 자연어로 다루게 만드는 것이다. Solo.io가 만들고 현재 CNCF Sandbox 프로젝트인 kagent는 Kubernetes 클러스터 안에서 직접 AI 에이전트를 배포·운영하는 프레임워크로, MCP(Model Context Protocol)와 Agent-to-Agent 통신을 지원해 로그·메트릭을 조회하고 장애를 진단하는 작업을 자연어 채팅으로 처리할 수 있게 한다 (CNCF: Kagent 소개). 다만 DORA 보고서가 지적하듯 AI 에이전트 역시 플랫폼이라는 기반이 견고할 때만 신뢰할 수 있는 결과를 낸다.\n실무 도입 조언 플랫폼을 도입할 때는 (1) 골든 패스를 먼저 문서화하고 CLI/API로 노출하는 것부터 시작하고, (2) GitOps로 애플리케이션과 인프라 변경 이력을 모두 Git에 남기며, (3) 정책 엔진으로 보안 가드레일을 코드화한 뒤, (4) AI 에이전트는 가장 마지막에 \u0026lsquo;이미 신뢰할 수 있는 플랫폼 위의 인터페이스\u0026rsquo;로 얹는 순서를 권한다. 순서를 거꾸로 하면, 즉 기반 없이 AI부터 얹으면 조직의 기존 무질서만 자동화되어 확대될 위험이 크다.\n🔗 참고 자료 (작성 중 열람한 자료) DORA | State of AI-assisted Software Development 2025 — IDP 도입률 90%, 플랫폼 팀 보유율 76%, AI가 기존 엔지니어링 시스템 품질을 증폭한다는 근거 CNCF Platforms White Paper — 내부 개발자 플랫폼과 골든 패스의 공식 정의, \u0026lsquo;가드레일이지 게이트가 아니다\u0026rsquo;라는 원칙의 출처 What is platform engineering? | CNCF — 플랫폼 엔지니어링을 사람·프로세스·정책·기술을 포괄하는 실천으로 규정하는 CNCF 공식 설명 Argo CD GitHub (argoproj/argo-cd) — Argo CD가 CNCF Graduated 프로젝트이며 Git과 클러스터 상태를 지속 비교/조정한다는 근거 Crossplane 공식 사이트 — Crossplane이 Kubernetes CRD/컨트롤러로 클라우드 인프라 전체를 제어 평면화한다는 근거 Cilium Zero Trust Networking — Cilium이 eBPF와 워크로드 신원 기반 정책으로 제로 트러스트를 구현한다는 근거 CNCF: Kagent, Bringing Agentic AI to Cloud Native — kagent가 Solo.io 기원의 CNCF Sandbox 프로젝트이며 MCP/A2A를 지원한다는 근거 GitHub cncf/sandbox Issue #360 (kagent) — kagent의 CNCF Sandbox 편입 심사 및 프로젝트 개요 ","permalink":"https://meetup.metacog.co.kr/blog/2026-07-19-gitops-crossplane-ai/","summary":"\u003ch2 id=\"devops-다음은-왜-플랫폼-엔지니어링인가\"\u003eDevOps 다음은 왜 플랫폼 엔지니어링인가\u003c/h2\u003e\n\u003cp\u003eDevOps는 애플리케이션 팀에게 인프라를 직접 다룰 자유를 줬지만, 그 대가로 모든 팀이 YAML과 IAM, 네트워크 정책을 각자 재발명하는 \u0026lsquo;인지 부하 폭증\u0026rsquo;을 낳았다. 이 문제를 해결하기 위해 등장한 것이 플랫폼 엔지니어링이다. CNCF는 이를 \u0026ldquo;플랫폼 팀이 제공하는 능력의 계층으로, 제품 팀이 하부 인프라에 대한 깊은 전문성 없이도 서비스를 빌드·배포·운영할 수 있게 하는 것\u0026quot;이라 정의하며, 골든 패스(Golden Path)를 \u0026ldquo;가드레일이지 게이트가 아니다\u0026quot;라고 못박는다 (\u003ca href=\"https://tag-app-delivery.cncf.io/whitepapers/platforms/\"\u003eCNCF Platforms White Paper\u003c/a\u003e). 실제로 \u003ca href=\"https://dora.dev/dora-report-2025/\"\u003eDORA의 2025 State of AI-assisted Software Development 보고서\u003c/a\u003e에 따르면 조직의 90%가 내부 개발자 플랫폼(IDP)을 이미 운영 중이고 76%는 전담 플랫폼 팀을 두고 있다. 더 중요한 발견은, AI 도입률이 90%에 달하는 지금 AI는 그 조직의 기존 엔지니어링 시스템을 \u0026lsquo;증폭\u0026rsquo;할 뿐이라는 점이다. 플랫폼이 부실하면 AI도 그 부실함을 그대로 증폭시킨다.\u003c/p\u003e","title":"2026-07-19 플랫폼 엔지니어링의 다음 단계: GitOps, Crossplane, 그리고 AI 에이전트가 만드는 셀프서비스 플랫폼"},{"content":"📋 밋업 한눈에 보기 Akamai의 플랫폼 엔지니어가 500개 이상의 클러스터와 8000개 이상의 애플리케이션을 운영하는 사내 Internal Developer Platform 아키텍처를 소개한 발표다. DevOps 셀프서비스 피로에서 platform engineering이 어떻게 태동했는지, 관리 클러스터(SRE 소유)와 애플리케이션 클러스터(서비스 팀 소유)를 Argo CD와 Crossplane으로 GitOps하게 관리하는 구조, Kyverno·Cilium·Istio로 구현한 zero-trust 보안, 그리고 kagent를 활용한 AI 트러블슈팅 실험까지 다뤘다. 발표 후에는 플랫폼 버전 관리, 업그레이드 전략, 책임 분담 모델에 대한 활발한 질의응답이 이어졌다.\n🔑 핵심 요점 Platform engineering은 각 팀이 개별적으로 YAML, IAM, 티켓 프로세스를 배워야 했던 DevOps 셀프서비스의 피로에서 출발했다. 플랫폼을 \u0026lsquo;제품\u0026rsquo;으로, 내부 개발자를 \u0026lsquo;고객\u0026rsquo;으로 취급하고 문서화와 피드백 루프, 채택률을 성공 지표로 삼는 것이 핵심 원칙이다. 관리 클러스터와 애플리케이션 클러스터를 분리하고, 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의 변경 사항을 감지해 클러스터에 반영한다.\n왜 필요한가 — 모든 변경 이력을 Git으로 감사·리뷰 가능하게 만들고, 클러스터 실제 상태가 선언된 상태에서 벗어나는 drift를 자동으로 복구하기 위해 사용한다.\n발표에서는 — 관리 클러스터에서 애플리케이션 클러스터들의 상태를 지속적으로 리컨사일하는 핵심 컴포넌트로 소개됐으며, 다른 컴포넌트보다 더 높은 권한이 부여된다고 설명했다.\nCrossplane Kubernetes의 CRD와 컨트롤러 패턴을 이용해 클라우드 인프라(클러스터, 네트워크, DB 등)를 코드로 정의하고 프로비저닝하는 오픈소스 도구다. 발표자는 이를 \u0026lsquo;Kubernetes 네이티브 Terraform\u0026rsquo;에 비유했다.\n왜 필요한가 — 인프라 프로비저닝 로직을 Composition이라는 재사용 가능한 API로 캡슐화해, 팀이 인프라 세부 사항을 몰라도 표준화된 방식으로 요청할 수 있게 하기 위해서다.\n발표에서는 — composition/composite resource로 클러스터 스펙(마스터 노드 수, 방화벽 규칙 등)을 정의하고 provider를 통해 실제 클라우드 리소스를 생성하는 예시로 소개됐다.\nKyverno Kubernetes 클러스터에 배포되는 리소스를 검사해 정책을 위반하면 거부하거나 수정하는 정책 엔진이다. YAML 기반으로 규칙을 정의할 수 있다.\n왜 필요한가 — 모든 네임스페이스가 동일한 최소 보안 기준을 갖추도록 강제하고, 잘못 설정된 워크로드가 클러스터에 배포되기 전에 자동으로 차단하기 위해 사용한다.\n발표에서는 — 특정 리소스(예: Crossplane provider) 삭제를 막는 세밀한 정책 예시를 들며, 필요하면 특정 리소스 단위로 예외를 둘 수 있다고 설명했다.\nCilium eBPF 기반의 Kubernetes CNI(컨테이너 네트워크 인터페이스)로, 파드 간 네트워크 트래픽을 커널 레벨에서 관측하고 제어한다.\n왜 필요한가 — 클러스터 내부에서 어떤 파드가 어떤 파드와 통신할 수 있는지 L3/L4 수준에서 세밀하게 제어하는 zero-trust 네트워크를 구현하기 위해 사용한다.\n발표에서는 — zero-trust 네트워크의 기반으로 소개됐고, 최근 Cilium이 transparent mTLS 기능을 추가했다는 점도 언급됐다.\nIstio 마이크로서비스 간 통신을 관리하는 서비스 메시로, 사이드카를 통해 트래픽 암호화와 인증을 애플리케이션 코드 변경 없이 적용한다.\n왜 필요한가 — 서비스 간 mTLS 통신을 자동으로 적용하고, L7 레벨에서 클러스터로 들어오는 외부 트래픽을 게이트웨이로 제어하기 위해 사용한다.\n발표에서는 — 서비스 메시 레이어로 소개됐으며, 애플리케이션 코드 수정 없이 mTLS를 적용하고 게이트웨이로 외부 트래픽을 L7에서 제어하는 용도로 언급됐다.\nkagent Kubernetes 클러스터 위에서 동작하는 AI 에이전트 프레임워크로, CNCF 관련 프로젝트로 소개됐다. 자연어로 클러스터 상태를 질의하면 로그·메트릭 등 신호를 분석해 문제를 진단해준다.\n왜 필요한가 — 파드 크래시 같은 문제를 사람이 직접 로그를 뒤지지 않고도 자연어 대화로 빠르게 진단하기 위해서다.\n발표에서는 — 현재는 관리 클러스터에만 배치해 SRE가 애플리케이션 클러스터를 원격 진단하는 데 쓰고 있으며, 향후 애플리케이션 클러스터에도 직접 배치하는 방안을 검토 중이라고 답했다. 사용자가 자체 MCP 도구를 연결해 확장할 수도 있다고 설명했다.\n🧭 추구 방향과 흐름 Platform as a Product — 발표자는 내부 개발자를 \u0026lsquo;고객\u0026rsquo;으로 보고, 문서화와 피드백 루프, 채택률을 플랫폼 성공 지표로 삼는 제품 마인드셋을 강조했다. DORA 리포트를 인용하며 플랫폼 도입이 실제로 소프트웨어 딜리버리 성과를 끌어올린다는 근거를 제시했다. GitOps 기반 선언적 인프라 관리 — 클러스터의 원하는 상태를 모두 Git에 두고 Argo CD가 지속적으로 리컨사일하도록 해, 감사 가능한 변경 이력과 자동 drift 복구를 확보하는 방향을 제시했다. Crossplane으로 인프라 프로비저닝까지 같은 GitOps 흐름에 편입시킨 것이 특징이다. Zero Trust와 Shift-Left 보안 — 기본적으로 모든 권한을 최소화하고, 더 많은 권한이 필요하면 감사 가능한 승격 절차를 거치도록 설계했다. Kyverno로 배포 시점에 정책을 강제하고 Cilium·Istio로 네트워크 계층에서 세그멘테이션과 mTLS를 적용해, 사고 이후 감사하는 대신 애초에 문제가 발생하지 않도록 하는 shift-left 접근을 취했다. 플랫폼 버전 번들링과 점진적 업그레이드 — 플랫폼 컴포넌트 전체를 하나의 버전으로 묶어 배포하고, 업그레이드·롤백을 git commit 단위로 다루는 방향을 취하고 있다. 다만 Kubernetes 버전과 애드온 버전을 지나치게 결합하는 것에 대한 고민을 청중과 나누며 향후 분리 가능성을 검토 중이라고 밝혔다. 💬 Q\u0026amp;A 하이라이트 Q. 플랫폼 버전이 바뀔 때마다 별도의 관리 클러스터가 필요한가?선택할 수 있다. 기존 클러스터를 그대로 업그레이드하거나(단, 이전 버전과의 호환 계약이 깨질 수 있음), 새 버전을 위해 별도 클러스터를 새로 띄우는 방식 모두 가능하다고 답했다.\nQ. 플랫폼 애드온 컴포넌트들을 Kubernetes 버전과 함께 묶어서 배포하는 게 중요한가?현재는 함께 번들링하고 있지만 결합도가 너무 높다는 문제를 인식하고 있으며, Kubernetes 버전을 애드온 버전과 분리하는 방안을 검토 중이라고 답했다.\nQ. 아키텍처 다이어그램을 보면 kagent가 관리(host) 클러스터에만 있는데 맞는가?맞다. 현재는 SRE가 원격으로 애플리케이션 클러스터를 진단하는 용도로만 쓰고 있으며, 향후 애플리케이션 클러스터에도 직접 배치해 팀들이 자체적으로 쓸 수 있게 하는 것을 고려 중이라고 답했다.\nQ. 새 플랫폼 버전에 대한 개발자 피드백은 어떻게 수집하나?카나리(green) 환경처럼 자동으로 새 버전을 먼저 태워보고 테스트를 통과하면 자동 적용, 실패하면 고쳐서 다시 시도하는 방식을 선호한다고 답했다.\nQ. 관리 클러스터 자체는 어떻게 프로비저닝하고 관리하나?GitHub Actions 같은 자동화로 프로비저닝하며, SRE가 직접 실행해 새 관리 클러스터를 띄운다고 답했다.\nQ. kagent로 사용자가 자체 MCP 서버나 커스텀 도구를 연결해 쓸 수 있나?가능하다. kagent는 자체 도구와 MCP 서비스를 연결해 플랫폼에 기본 제공되지 않는 기능도 확장할 수 있다고 답했다.\nQ. 팀들이 golden path를 벗어나 임의의 Helm chart 등을 설치하는 것을 막을 수 있나?app chart 패턴을 따르면 무엇이든 배포할 수 있어 완전히 막기는 어렵다. 베스트 프랙티스를 문서화할 수는 있지만, 최종적으로 클러스터 보안에 대한 책임은 해당 팀에 있는 shared responsibility 모델이라고 답했다.\n🚀 바로 활용하기 Argo CD 공식 문서를 참고해 로컬 환경에서 GitOps 방식으로 샘플 애플리케이션을 배포·동기화해본다. Crossplane으로 간단한 Composition을 작성해 클라우드 리소스를 CRD 형태로 프로비저닝해본다. Kyverno로 \u0026lsquo;특정 라벨 없는 파드 배포 금지\u0026rsquo; 같은 정책을 작성해 테스트 클러스터에 적용해본다. DORA 리포트를 읽고 자신이 속한 조직의 플랫폼 엔지니어링 도입 수준과 소프트웨어 딜리버리 성과를 비교해본다. 🔗 참고 자료 Kubernetes — 발표 전반의 기반이 된 CRD/컨트롤러 패턴과 클러스터 아키텍처 논의의 근거. Argo CD — 관리 클러스터에서 애플리케이션 클러스터를 리컨사일하는 GitOps 도구. Crossplane — 인프라를 Composition/CRD로 정의해 프로비저닝하는 도구. Kyverno — 클러스터 정책 강제 및 misconfiguration 차단에 사용된 정책 엔진. Cilium — eBPF 기반 CNI로 zero-trust 네트워크 정책을 구현하는 데 사용. Istio — 서비스 메시로 mTLS와 L7 트래픽 제어를 담당. DORA — 발표에서 인용된 플랫폼 엔지니어링 도입 효과 관련 리포트 출처. kagent — 클러스터 진단에 사용된 AI 에이전트 프레임워크. ","permalink":"https://meetup.metacog.co.kr/posts/2026-07-19-platform-engineering-golden-path-argo-cd-crossplane-kyverno/","summary":"\u003ch2 id=\"-밋업-한눈에-보기\"\u003e📋 밋업 한눈에 보기\u003c/h2\u003e\n\u003cp\u003eAkamai의 플랫폼 엔지니어가 500개 이상의 클러스터와 8000개 이상의 애플리케이션을 운영하는 사내 Internal Developer Platform 아키텍처를 소개한 발표다. DevOps 셀프서비스 피로에서 platform engineering이 어떻게 태동했는지, 관리 클러스터(SRE 소유)와 애플리케이션 클러스터(서비스 팀 소유)를 Argo CD와 Crossplane으로 GitOps하게 관리하는 구조, Kyverno·Cilium·Istio로 구현한 zero-trust 보안, 그리고 kagent를 활용한 AI 트러블슈팅 실험까지 다뤘다. 발표 후에는 플랫폼 버전 관리, 업그레이드 전략, 책임 분담 모델에 대한 활발한 질의응답이 이어졌다.\u003c/p\u003e\n\u003ch2 id=\"-핵심-요점\"\u003e🔑 핵심 요점\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePlatform engineering은 각 팀이 개별적으로 YAML, IAM, 티켓 프로세스를 배워야 했던 DevOps 셀프서비스의 피로에서 출발했다.\u003c/li\u003e\n\u003cli\u003e플랫폼을 \u0026lsquo;제품\u0026rsquo;으로, 내부 개발자를 \u0026lsquo;고객\u0026rsquo;으로 취급하고 문서화와 피드백 루프, 채택률을 성공 지표로 삼는 것이 핵심 원칙이다.\u003c/li\u003e\n\u003cli\u003e관리 클러스터와 애플리케이션 클러스터를 분리하고, Argo CD와 Crossplane으로 전체 인프라와 애플리케이션을 GitOps 방식으로 관리한다.\u003c/li\u003e\n\u003cli\u003eKyverno로 정책을 강제하고 Cilium과 Istio로 네트워크 계층의 zero-trust(세그멘테이션, mTLS)를 구현하며, RBAC은 OIDC/SSO와 연동된다.\u003c/li\u003e\n\u003cli\u003e플랫폼 컴포넌트 전체를 하나의 버전으로 번들링해 배포하며, 업그레이드와 롤백도 git commit 단위로 이루어진다.\u003c/li\u003e\n\u003cli\u003ekagent 같은 AI 에이전트를 도입해 자연어로 클러스터 상태를 질의하고 진단하는 실험을 진행 중이다.\u003c/li\u003e\n\u003cli\u003eDORA 리포트를 인용하며 플랫폼 엔지니어링 도입이 소프트웨어 딜리버리 성과와 개발자 생산성 향상에 실제로 기여한다고 설명했다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"-핵심-기술-쉽게-이해하기\"\u003e🛠 핵심 기술 쉽게 이해하기\u003c/h2\u003e\n\u003ch3 id=\"argo-cd\"\u003eArgo CD\u003c/h3\u003e\n\u003cp\u003eGit 저장소에 선언된 상태를 기준으로 Kubernetes 클러스터를 자동으로 동기화해주는 GitOps 배포 도구다. 사람이 직접 kubectl apply를 실행하는 대신, 컨트롤러가 Git의 변경 사항을 감지해 클러스터에 반영한다.\u003c/p\u003e","title":"2026-07-19 Platform Engineering으로 만드는 Golden Path: Argo CD, Crossplane, Kyverno로 설계한 사내 플랫폼"}]