📋 밋업 한눈에 보기

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의 변경 사항을 감지해 클러스터에 반영한다.

왜 필요한가 — 모든 변경 이력을 Git으로 감사·리뷰 가능하게 만들고, 클러스터 실제 상태가 선언된 상태에서 벗어나는 drift를 자동으로 복구하기 위해 사용한다.

발표에서는 — 관리 클러스터에서 애플리케이션 클러스터들의 상태를 지속적으로 리컨사일하는 핵심 컴포넌트로 소개됐으며, 다른 컴포넌트보다 더 높은 권한이 부여된다고 설명했다.

Crossplane

Kubernetes의 CRD와 컨트롤러 패턴을 이용해 클라우드 인프라(클러스터, 네트워크, DB 등)를 코드로 정의하고 프로비저닝하는 오픈소스 도구다. 발표자는 이를 ‘Kubernetes 네이티브 Terraform’에 비유했다.

왜 필요한가 — 인프라 프로비저닝 로직을 Composition이라는 재사용 가능한 API로 캡슐화해, 팀이 인프라 세부 사항을 몰라도 표준화된 방식으로 요청할 수 있게 하기 위해서다.

발표에서는 — composition/composite resource로 클러스터 스펙(마스터 노드 수, 방화벽 규칙 등)을 정의하고 provider를 통해 실제 클라우드 리소스를 생성하는 예시로 소개됐다.

Kyverno

Kubernetes 클러스터에 배포되는 리소스를 검사해 정책을 위반하면 거부하거나 수정하는 정책 엔진이다. YAML 기반으로 규칙을 정의할 수 있다.

왜 필요한가 — 모든 네임스페이스가 동일한 최소 보안 기준을 갖추도록 강제하고, 잘못 설정된 워크로드가 클러스터에 배포되기 전에 자동으로 차단하기 위해 사용한다.

발표에서는 — 특정 리소스(예: Crossplane provider) 삭제를 막는 세밀한 정책 예시를 들며, 필요하면 특정 리소스 단위로 예외를 둘 수 있다고 설명했다.

Cilium

eBPF 기반의 Kubernetes CNI(컨테이너 네트워크 인터페이스)로, 파드 간 네트워크 트래픽을 커널 레벨에서 관측하고 제어한다.

왜 필요한가 — 클러스터 내부에서 어떤 파드가 어떤 파드와 통신할 수 있는지 L3/L4 수준에서 세밀하게 제어하는 zero-trust 네트워크를 구현하기 위해 사용한다.

발표에서는 — zero-trust 네트워크의 기반으로 소개됐고, 최근 Cilium이 transparent mTLS 기능을 추가했다는 점도 언급됐다.

Istio

마이크로서비스 간 통신을 관리하는 서비스 메시로, 사이드카를 통해 트래픽 암호화와 인증을 애플리케이션 코드 변경 없이 적용한다.

왜 필요한가 — 서비스 간 mTLS 통신을 자동으로 적용하고, L7 레벨에서 클러스터로 들어오는 외부 트래픽을 게이트웨이로 제어하기 위해 사용한다.

발표에서는 — 서비스 메시 레이어로 소개됐으며, 애플리케이션 코드 수정 없이 mTLS를 적용하고 게이트웨이로 외부 트래픽을 L7에서 제어하는 용도로 언급됐다.

kagent

Kubernetes 클러스터 위에서 동작하는 AI 에이전트 프레임워크로, CNCF 관련 프로젝트로 소개됐다. 자연어로 클러스터 상태를 질의하면 로그·메트릭 등 신호를 분석해 문제를 진단해준다.

왜 필요한가 — 파드 크래시 같은 문제를 사람이 직접 로그를 뒤지지 않고도 자연어 대화로 빠르게 진단하기 위해서다.

발표에서는 — 현재는 관리 클러스터에만 배치해 SRE가 애플리케이션 클러스터를 원격 진단하는 데 쓰고 있으며, 향후 애플리케이션 클러스터에도 직접 배치하는 방안을 검토 중이라고 답했다. 사용자가 자체 MCP 도구를 연결해 확장할 수도 있다고 설명했다.

🧭 추구 방향과 흐름

  • Platform as a Product — 발표자는 내부 개발자를 ‘고객’으로 보고, 문서화와 피드백 루프, 채택률을 플랫폼 성공 지표로 삼는 제품 마인드셋을 강조했다. DORA 리포트를 인용하며 플랫폼 도입이 실제로 소프트웨어 딜리버리 성과를 끌어올린다는 근거를 제시했다.
  • GitOps 기반 선언적 인프라 관리 — 클러스터의 원하는 상태를 모두 Git에 두고 Argo CD가 지속적으로 리컨사일하도록 해, 감사 가능한 변경 이력과 자동 drift 복구를 확보하는 방향을 제시했다. Crossplane으로 인프라 프로비저닝까지 같은 GitOps 흐름에 편입시킨 것이 특징이다.
  • Zero Trust와 Shift-Left 보안 — 기본적으로 모든 권한을 최소화하고, 더 많은 권한이 필요하면 감사 가능한 승격 절차를 거치도록 설계했다. Kyverno로 배포 시점에 정책을 강제하고 Cilium·Istio로 네트워크 계층에서 세그멘테이션과 mTLS를 적용해, 사고 이후 감사하는 대신 애초에 문제가 발생하지 않도록 하는 shift-left 접근을 취했다.
  • 플랫폼 버전 번들링과 점진적 업그레이드 — 플랫폼 컴포넌트 전체를 하나의 버전으로 묶어 배포하고, 업그레이드·롤백을 git commit 단위로 다루는 방향을 취하고 있다. 다만 Kubernetes 버전과 애드온 버전을 지나치게 결합하는 것에 대한 고민을 청중과 나누며 향후 분리 가능성을 검토 중이라고 밝혔다.

💬 Q&A 하이라이트

Q. 플랫폼 버전이 바뀔 때마다 별도의 관리 클러스터가 필요한가?

선택할 수 있다. 기존 클러스터를 그대로 업그레이드하거나(단, 이전 버전과의 호환 계약이 깨질 수 있음), 새 버전을 위해 별도 클러스터를 새로 띄우는 방식 모두 가능하다고 답했다.

Q. 플랫폼 애드온 컴포넌트들을 Kubernetes 버전과 함께 묶어서 배포하는 게 중요한가?

현재는 함께 번들링하고 있지만 결합도가 너무 높다는 문제를 인식하고 있으며, Kubernetes 버전을 애드온 버전과 분리하는 방안을 검토 중이라고 답했다.

Q. 아키텍처 다이어그램을 보면 kagent가 관리(host) 클러스터에만 있는데 맞는가?

맞다. 현재는 SRE가 원격으로 애플리케이션 클러스터를 진단하는 용도로만 쓰고 있으며, 향후 애플리케이션 클러스터에도 직접 배치해 팀들이 자체적으로 쓸 수 있게 하는 것을 고려 중이라고 답했다.

Q. 새 플랫폼 버전에 대한 개발자 피드백은 어떻게 수집하나?

카나리(green) 환경처럼 자동으로 새 버전을 먼저 태워보고 테스트를 통과하면 자동 적용, 실패하면 고쳐서 다시 시도하는 방식을 선호한다고 답했다.

Q. 관리 클러스터 자체는 어떻게 프로비저닝하고 관리하나?

GitHub Actions 같은 자동화로 프로비저닝하며, SRE가 직접 실행해 새 관리 클러스터를 띄운다고 답했다.

Q. kagent로 사용자가 자체 MCP 서버나 커스텀 도구를 연결해 쓸 수 있나?

가능하다. kagent는 자체 도구와 MCP 서비스를 연결해 플랫폼에 기본 제공되지 않는 기능도 확장할 수 있다고 답했다.

Q. 팀들이 golden path를 벗어나 임의의 Helm chart 등을 설치하는 것을 막을 수 있나?

app chart 패턴을 따르면 무엇이든 배포할 수 있어 완전히 막기는 어렵다. 베스트 프랙티스를 문서화할 수는 있지만, 최종적으로 클러스터 보안에 대한 책임은 해당 팀에 있는 shared responsibility 모델이라고 답했다.

🚀 바로 활용하기

  1. Argo CD 공식 문서를 참고해 로컬 환경에서 GitOps 방식으로 샘플 애플리케이션을 배포·동기화해본다.
  2. Crossplane으로 간단한 Composition을 작성해 클라우드 리소스를 CRD 형태로 프로비저닝해본다.
  3. Kyverno로 ‘특정 라벨 없는 파드 배포 금지’ 같은 정책을 작성해 테스트 클러스터에 적용해본다.
  4. DORA 리포트를 읽고 자신이 속한 조직의 플랫폼 엔지니어링 도입 수준과 소프트웨어 딜리버리 성과를 비교해본다.

🔗 참고 자료

  • Kubernetes — 발표 전반의 기반이 된 CRD/컨트롤러 패턴과 클러스터 아키텍처 논의의 근거.
  • Argo CD — 관리 클러스터에서 애플리케이션 클러스터를 리컨사일하는 GitOps 도구.
  • Crossplane — 인프라를 Composition/CRD로 정의해 프로비저닝하는 도구.
  • Kyverno — 클러스터 정책 강제 및 misconfiguration 차단에 사용된 정책 엔진.
  • Cilium — eBPF 기반 CNI로 zero-trust 네트워크 정책을 구현하는 데 사용.
  • Istio — 서비스 메시로 mTLS와 L7 트래픽 제어를 담당.
  • DORA — 발표에서 인용된 플랫폼 엔지니어링 도입 효과 관련 리포트 출처.
  • kagent — 클러스터 진단에 사용된 AI 에이전트 프레임워크.