📋 밋업 한눈에 보기

이 밋업은 Sam과 Pankaj가 최근 발표한 리포트를 바탕으로 platform engineering이 어떻게 진화하고 있는지 다뤘다. 기존 platform engineering 1.0이 애플리케이션 개발자의 인지 부하 감소에만 집중했던 것과 달리, AI 에이전트·데이터 과학자·보안팀 등 새로운 페르소나가 늘어나면서 플랫폼이 그에 맞춰 확장돼야 한다는 점을 강조했다. AI-native 플랫폼, 다중 페르소나 지원, 임베디드 FinOps, security shift-down, composable 설계라는 다섯 가지 기둥으로 platform engineering 2.0을 정의했고, Q&A에서는 DevOps 엔지니어의 역할 변화, 에이전트 페르소나의 필요성, FinOps 적용 범위 등이 논의됐다.

🔑 핵심 요점

  • Platform engineering은 이제 선택이 아니라 필수이며, 조직의 90%가 이미 도입했고 76%는 전담 플랫폼 팀을 운영하고 있다.
  • 기존 platform engineering 1.0은 애플리케이션 개발자의 인지 부하 감소에만 집중했지만 AI 에이전트, 데이터 과학자, 보안팀 등 새로운 페르소나를 아우르지 못하는 한계가 있다.
  • AI로 인한 코드량 폭증, 토큰 비용 급증, 클라우드 낭비(약 35%)가 겹치며 비용 관리를 플랫폼에 내재화해야 하는 압박이 커지고 있다.
  • Platform engineering 2.0은 AI-native 플랫폼, 페르소나 확장, 임베디드 FinOps, security shift-down, composable 설계라는 다섯 개의 기둥으로 구성된다.
  • Security shift-left만으로는 프로덕션 이후 발견되는 취약점을 잡지 못하기 때문에 shift-down으로 이를 보완해야 한다.
  • AI 에이전트는 사람과 동일한 수준의 통제를 줄 수 없는, 별도의 가드레일이 필요한 새로운 비인간(non-human) 페르소나로 다뤄야 한다.
  • 플랫폼을 제품처럼 다루는 근본 원칙은 그대로이며, 변화는 대상 페르소나와 요구사항이 확장되는 데서 온다.

🛠 핵심 기술 쉽게 이해하기

Internal Developer Platform (IDP) / Platform Engineering

조직이 개발자가 스스로 인프라를 신경 쓰지 않고도 표준화된 self-service 환경에서 애플리케이션을 배포할 수 있도록 구축하는 내부 플랫폼이다. 정해진 표준 배포 경로인 golden path를 제공해 반복 작업을 줄여준다.

왜 필요한가 — 개발자의 인지 부하를 줄이고 배포 속도를 높이며 보안 이슈를 초기에 걸러내기 위해 도입한다.

발표에서는 — 발표는 IDP가 이제 90% 조직에 도입되고 76%가 전담 팀을 운영할 정도로 보편화됐다는 통계를 제시하면서도, 개발자 중심·반응형 운영·golden path가 golden cage로 변질되는 등 1.0 모델의 한계를 지적하고 2.0으로의 진화 필요성을 설명했다.

MCP (Model Context Protocol)

AI 에이전트가 외부 도구, 데이터, 서비스에 표준화된 방식으로 연결할 수 있게 해주는 프로토콜이다. 에이전트가 API처럼 외부 리소스를 호출할 수 있는 통로 역할을 한다.

왜 필요한가 — 에이전트 수가 급증하면서 각 에이전트가 안전하고 일관된 방식으로 플랫폼 자원에 접근할 표준 인터페이스가 필요해졌다.

발표에서는 — 발표자는 지난 12개월 사이 MCP server와 MCP gateway가 실험 단계에서 조직의 필수 구성요소로 빠르게 자리잡았다고 언급하며, AI-native 플랫폼과 composable 아키텍처를 설명하는 핵심 예시로 들었다.

FinOps

클라우드 및 AI 비용을 조직 전체가 함께 가시화하고 관리하는 운영 문화이자 실무 프랙티스다. 비용 데이터를 실시간으로 추적해 각 팀이 스스로 지출을 통제하도록 돕는다.

왜 필요한가 — 클라우드 낭비(약 35%)와 AI 토큰 비용 급증으로 인해 격주 리포트 수준의 대응으로는 더 이상 충분하지 않기 때문이다.

발표에서는 — 발표는 FinOps를 플랫폼에 직접 임베드해 배포 시점에 예상 비용을 미리 보여주고 예산 초과 시 승인 절차를 거치게 하는 사전 통제 방식을 제안했으며, Q&A에서는 프로덕션과 비프로덕션 환경 중 어디에 우선 적용할지에 대한 질문도 다뤄졌다.

Cilium

리눅스 커널의 eBPF 기술을 기반으로 쿠버네티스 클러스터 내 네트워킹, 보안, 관측성을 제공하는 오픈소스 프로젝트다. 워크로드 간 mutual TLS(mTLS) 암호화와 세밀한 네트워크 세그멘테이션을 지원한다.

왜 필요한가 — 에이전트와 워크로드가 급증하는 환경에서 서비스 간 통신을 안전하게 격리하고 암호화할 필요가 있기 때문이다.

발표에서는 — security shift-down 파트에서 워크로드·에이전트·인프라 사이에 강력한 세그멘테이션과 mTLS를 적용하는 사례로 언급됐다.

CNCF 생태계 / Kubernetes

CNCF(Cloud Native Computing Foundation)는 쿠버네티스를 비롯한 클라우드 네이티브 오픈소스 프로젝트들을 관리하는 재단이며, 쿠버네티스는 컨테이너 오케스트레이션의 사실상 표준이다.

왜 필요한가 — composable 플랫폼을 구성하는 표준화된 빌딩블록들을 제공해 벤더 종속 없이 컴포넌트를 교체할 수 있게 해준다.

발표에서는 — 발표자는 2018년 50개였던 CNCF 프로젝트가 현재 200개 이상으로 늘어난 점, 그리고 쿠버네티스가 아직 GPU를 인식하지 못한다는 한계를 짚으며 composable 아키텍처와 AI-native 플랫폼 논의의 배경으로 제시했다.

🧭 추구 방향과 흐름

  • AI-native 플랫폼 — GPU/TPU 워크로드, 모델 레지스트리, AI 게이트웨이, MCP 서버 같은 AI 특화 요구사항을 플랫폼에 처음부터 내장하는 방향이다. 발표는 컨테이너·VM·AI 워크로드를 하나의 플랫폼에서 함께 지원해야 자원 활용률과 운영 일관성을 높일 수 있다고 설명했다.
  • Multi-persona 플랫폼으로의 확장 — 기존에 애플리케이션 개발자 한 명의 페르소나에만 집중했던 것에서 벗어나, 데이터 과학자·보안팀·SRE·비개발자 시민 개발자·AI 에이전트까지 포괄하는 방향이다. 각 페르소나가 고유한 추상화, 도구, 대시보드를 필요로 한다는 점을 강조했다.
  • 임베디드 FinOps와 Security Shift-down — 비용과 보안을 애플리케이션 배포 이후 별도 프로세스로 처리하던 방식에서, 플랫폼 자체에 내재화하는 방향이다. 배포 시점에 비용을 예측하고 정책을 코드로 강제하며, shift-left가 놓치는 프로덕션 단계 취약점을 shift-down으로 보완한다.
  • Composable 아키텍처로의 전환 — 플랫폼을 모듈화된 독립 교체 가능 빌딩블록으로 구성해 CI/CD 도구, CNI, GPU 시리즈 등을 빠르게 교체·재구성할 수 있도록 하는 방향이다. 발표자는 개발자의 도구 충성도가 낮아지는 추세를 근거로 build-and-buy가 아닌 compose 방식이 플랫폼의 미래가 될 것이라고 말했다.

💬 Q&A 하이라이트

Q. 많은 전통적 조직이 아직 platform engineering 1.0도 제대로 구축하지 못하고 있는데, 2.0에서 DevOps 엔지니어의 역할은 어떻게 바뀌며 일부 DevOps 역할이 대체될 위험이 있는가?

역할이 순수 DevOps에 머물러 있고 platform engineering적 사고(제품처럼 다루기, shift-down 등)를 받아들이지 않는다면 대체될 위험이 실제로 있다고 답했다. 다만 DevOps 철학 자체가 사라지는 것은 아니며, 플랫폼을 제품으로 다루는 근본 원칙을 지키는 한 우선순위가 흔들려도 괜찮다고 덧붙였다.

Q. VMware(발표사)는 실제로 agentic AI를 얼마나 사용하고 있는가?

엔지니어링, 마케팅, 세일즈 등 전 부서에 걸쳐 agentic AI 전용 프로젝트를 운영하고 있으며 AI 도구를 매우 적극적으로 받아들이고 있다고 답했다.

Q. 에이전트가 개발자, 테스트 엔지니어 등 기존 역할을 대신 수행하는 것뿐인데 왜 별도의 페르소나로 취급하는가?

인간은 자연스럽게 가드레일을 갖고 있지만 에이전트는 그렇지 않고, 에이전트 수는 인간보다 훨씬 큰 규모(예: 마이크로소프트 사내 2천만 에이전트 전망)로 늘어날 수 있어 신원 관리·권한·감사 방식이 인간과 근본적으로 다르게 설계돼야 한다고 답했다.

Q. FinOps를 platform engineering 2.0에 적용할 때 프로덕션과 비프로덕션 환경 중 어디에 우선순위를 둬야 하는가?

조직마다 다르지만, 대부분의 플랫폼 팀은 아직 격주 미팅 수준으로만 비용을 다루고 있어 우선 비용이 새는 지점을 파악하는 진단부터 시작해야 한다고 답했다. 특히 비프로덕션 환경이 방치돼 비용이 새는 경우가 매우 흔하고, 모델 학습처럼 비용이 큰 영역에서는 FinOps 역할이 특히 중요하다고 덧붙였다.

🚀 바로 활용하기

  1. 자사 플랫폼의 golden path가 golden cage로 변질되지 않았는지 점검하고, 데이터 과학자·보안팀 등 비개발자 페르소나를 위한 경험 계층을 설계해본다.
  2. 격주 비용 리포트 수준에 머물러 있다면, 비용이 새고 있는 영역(특히 비프로덕션 환경)부터 진단하는 FinOps 대시보드를 만들어본다.
  3. MCP 서버/게이트웨이를 활용해 에이전트가 플랫폼 리소스에 접근하는 표준 인터페이스를 실험적으로 구축해본다.
  4. Cilium 같은 도구로 워크로드·에이전트 간 mTLS와 세그멘테이션을 적용해 security shift-down을 시작해본다.

🔗 참고 자료

  • Kubernetes 공식 문서 — 발표에서 언급된 GPU 인식 한계, 컨테이너 오케스트레이션 표준으로서의 배경 지식
  • CNCF (Cloud Native Computing Foundation) — 2018년 50개에서 현재 200개 이상으로 늘어난 CNCF 프로젝트 생태계와 composable 아키텍처 논의의 배경
  • Cilium — security shift-down 파트에서 언급된 mTLS 및 워크로드 세그멘테이션 도구
  • Model Context Protocol (MCP) — AI-native 플랫폼과 composable 아키텍처의 핵심 빌딩블록으로 반복 언급된 MCP server/gateway
  • FinOps Foundation — 임베디드 FinOps 기둥과 Q&A에서 다뤄진 비용 관리 프랙티스의 배경 자료
  • DORA (DevOps Research and Assessment) — 발표에서 성과 측정 지표로 언급된 DORA metrics 관련 공식 자료