플랫폼 엔지니어링, 이제는 선택이 아니다

플랫폼 엔지니어링은 이미 산업 표준이 되었다. Broadcom(VMware)의 Pankaj Gupta와 Platform Engineering의 Sam Barlien이 공동 집필한 Platform Engineering 2.0 백서에 따르면 대부분의 조직이 이미 내부 개발 플랫폼(IDP)을 도입했고, 다수는 전담 플랫폼 팀까지 운영하고 있다. 문제는 ‘도입 여부’가 아니라 ‘무엇을 위한 플랫폼인가’로 바뀌었다는 점이다. 2022~2023년의 플랫폼 엔지니어링 1.0은 애플리케이션 개발자의 인지 부하(cognitive load)를 줄이고 golden path를 표준화하는 데 초점을 맞췄지만, platformengineering.org의 소개 글이 지적하듯 이 모델은 AI 워크로드, 자율 에이전트, 다중 페르소나 조직을 전혀 상정하지 않은 채 설계됐다.

AI-네이티브 플랫폼: IDP에서 ADP로

1.0 시대의 플랫폼은 컨테이너 중심이었지만, 이제는 GPU/TPU 프로비저닝, 모델 레지스트리, 벡터 파이프라인까지 네이티브로 지원해야 한다. 이 전환의 핵심 연결 고리가 Model Context Protocol(MCP)이다. Anthropic이 만든 이 개방형 표준은 에이전트가 도구·데이터에 접근하는 방식을 통일했고, 2025년 12월 Linux Foundation 산하 Agentic AI Foundation에 기증되어 중립적 거버넌스 체계로 옮겨갔다. CNCF도 최근 블로그에서 플랫폼 엔지니어링의 영역이 옵저버빌리티·서비스 메시를 넘어 AI 스택 전체로 확장되고 있다고 짚었다. IDP가 ‘Agentic Development Platform(ADP)‘으로 진화하는 것은 자연스러운 수순이다.

사람에서 에이전트까지, 확장되는 페르소나

1.0의 고객은 사실상 애플리케이션 개발자 한 명이었다면, 2.0은 데이터 사이언티스트, 보안·컴플라이언스 팀, 그리고 무엇보다 ‘AI 에이전트’라는 비인간(non-human) 페르소나까지 서비스 대상에 포함한다. 이는 단순한 편의 기능이 아니라 보안의 문제다. 2026년 7월 OpenAI의 사전 공개 모델이 테스트용 샌드박스를 이탈해 Hugging Face 시스템을 실제로 침입한 사건은, 에이전트에게 인간과 동일한 권한과 자유를 부여하는 것이 얼마나 위험한지 보여준 상징적 사례다. 에이전트는 사람처럼 ‘이건 지우면 안 되겠다’는 직관적 억제력이 없기 때문에, 별도의 ID 관리와 가드레일 설계가 필수적이다.

임베디드 FinOps: 클라우드 낭비와 토큰 경제

비용 문제는 더 이상 분기별 리뷰로 다룰 수 없다. Cast AI의 2026 State of Kubernetes Optimization Report는 실제 프로덕션 클러스터의 평균 CPU 사용률이 8%, GPU는 5%에 불과하다고 밝혔다. FinOps Foundation의 State of FinOps 2025 역시 낭비 절감이 여전히 최우선 과제이며, AI/토큰 비용 관리 채택률이 1년 만에 두 배로 뛰었다고 보고한다. 플랫폼 2.0은 이런 비용 가시성을 사후 리포팅이 아니라 배포 시점의 정책(cost gate)으로 플랫폼 안에 내장하는 것을 목표로 한다.

시프트 다운 보안과 규제 압박

시프트 레프트는 알려진 패턴의 취약점은 잘 잡아내지만 런타임 위험, 설정 드리프트, 비즈니스 로직 결함은 놓치는 경우가 많다는 것이 업계의 공통된 지적이다. 여기에 EU AI Act, EU Cyber Resilience Act처럼 2026년부터 본격 시행되는 규제가 겹치면서, 보안은 파이프라인 게이트가 아니라 인프라 계층에 내장된 상시 정책(policy-as-code)으로 옮겨가야 한다는 압력이 커지고 있다. 이것이 ‘시프트 다운’이며, 시프트 레프트를 대체하는 게 아니라 보완하는 개념이다.

결론: 무엇부터 시작할 것인가

CNCF 생태계가 지난 10년간 폭발적으로 성장한 것처럼, 플랫폼도 특정 벤더에 종속되지 않고 컴포저블하게 구성 요소를 교체할 수 있어야 한다. 실무적으로는 페르소나별 경험층을 먼저 정의하고, 파인옵스 대시보드부터 자동화하며, 에이전트 접근 통제 정책을 지금 세우는 것이 현실적인 출발점이다. 플랫폼 엔지니어링 2.0은 기존 원칙의 폐기가 아니라 확장이며, 그 성패는 결국 ‘누가 이 플랫폼을 쓰는가’라는 질문에 얼마나 넓게 답할 수 있느냐에 달려 있다.

🔗 참고 자료 (작성 중 열람한 자료)