1장: Platform Engineering의 등장과 핵심 개념

학습 목표

• DevOps에서 Platform Engineering으로 전환된 배경을 이해합니다.
• **Internal Developer Platform(IDP)**의 정의와 핵심 구성 요소를 파악합니다.
• 인지 부하(Cognitive Load) 감소가 왜 중요한지 설명할 수 있습니다.
• 2026년 기준 Platform Engineering의 시장 현황과 트렌드를 파악합니다.

DevOps, 그 다음은 무엇인가

**DevOps(데브옵스)**가 소프트웨어 업계에 도입된 지 15년이 넘었습니다. "You build it, you run it"이라는 철학 아래, 개발자는 코드 작성부터 배포, 운영까지 모든 책임을 지게 되었습니다. 이 접근법은 빠른 배포 사이클과 팀 자율성이라는 명확한 성과를 가져왔습니다.

그러나 시간이 지나면서 한 가지 근본적인 문제가 드러났습니다. 개발자가 알아야 할 것이 너무 많아졌다는 것입니다.

- 컨테이너: Docker, containerd
- 오케스트레이션: Kubernetes, Helm, Kustomize
- CI/CD: GitHub Actions, ArgoCD, Tekton
- 인프라: Terraform, Pulumi, CloudFormation
- 모니터링: Prometheus, Grafana, Datadog
- 로깅: ELK Stack, Loki
- 보안: OPA, Falco, Trivy
- 네트워킹: Istio, Cilium, Envoy
- 데이터베이스: PostgreSQL, Redis, MongoDB
- 메시지큐: Kafka, RabbitMQ, NATS

하나의 서비스를 배포하기 위해 알아야 하는 기술이 수십 가지에 달합니다. 이는 개발자의 **Cognitive Load(인지 부하)**를 극적으로 증가시켰고, 정작 비즈니스 로직에 집중해야 할 시간을 인프라 구성에 쏟게 만들었습니다.

인지 부하의 세 가지 유형

**Team Topologies(팀 토폴로지)**의 저자인 Matthew Skelton과 Manuel Pais는 인지 부하를 세 가지로 분류합니다.

Platform Engineering의 핵심 목표는 **Extraneous Load(외재적 인지 부하)**를 최소화하여, 개발자가 Intrinsic Load에 집중할 수 있도록 만드는 것입니다.

Platform Engineering이란

**Platform Engineering(플랫폼 엔지니어링)**은 소프트웨어 엔지니어링 조직 내에서 셀프서비스 기능을 설계하고 구축하는 분야입니다. 개발자가 인프라의 복잡성을 직접 다루지 않고도 소프트웨어를 빠르게 개발하고 배포할 수 있도록 **Internal Developer Platform(내부 개발자 플랫폼, IDP)**을 제공합니다.

DevOps vs Platform Engineering

DevOps와 Platform Engineering은 대립 관계가 아닙니다. Platform Engineering은 DevOps의 원칙 위에 세워진 진화된 접근법입니다.

핵심 차이점을 정리하면 다음과 같습니다.

IDP의 구성 요소

**Internal Developer Platform(내부 개발자 플랫폼)**은 단일 도구가 아닌, 여러 계층으로 구성된 플랫폼입니다.

각 계층의 역할을 살펴보겠습니다.

1. 개발자 경험 계층 (Developer Experience Layer)

개발자가 직접 상호작용하는 인터페이스입니다. Backstage(백스테이지) 같은 개발자 포털, CLI 도구, 그리고 플랫폼 API가 이 계층에 해당합니다. 핵심은 개발자가 인프라의 복잡성을 의식하지 않고도 필요한 모든 작업을 수행할 수 있어야 한다는 것입니다.

2. 오케스트레이션 계층 (Orchestration Layer)

개발자의 요청을 실제 인프라 작업으로 변환하는 계층입니다. GitOps 기반의 배포, Infrastructure as Code를 통한 리소스 프로비저닝, 그리고 템플릿 기반의 프로젝트 생성이 이루어집니다.

3. 인프라 계층 (Infrastructure Layer)

실제 컴퓨팅 리소스가 존재하는 계층입니다. Kubernetes 클러스터, 클라우드 서비스, 데이터베이스, 메시지큐 등이 포함됩니다.

왜 지금 Platform Engineering인가

Platform Engineering이 2024년부터 폭발적으로 성장한 데에는 몇 가지 배경이 있습니다.

Gartner의 예측

Gartner는 2026년까지 대규모 소프트웨어 엔지니어링 조직의 80% 이상이 전담 플랫폼 팀을 운영할 것으로 예측했습니다. 또한 **75%**의 조직이 셀프서비스 개발자 포털을 제공할 것이라고 전망했습니다. 이 예측은 현실이 되고 있습니다.

클라우드 네이티브 생태계의 성숙

**CNCF(Cloud Native Computing Foundation)**의 프로젝트 수는 2026년 기준 200개를 넘어섰습니다. Kubernetes를 중심으로 한 생태계가 성숙하면서, 이를 효과적으로 활용하기 위한 플랫폼의 필요성도 함께 커졌습니다.

AI의 부상

AI/ML 워크로드가 급증하면서 인프라 복잡성이 한 차원 높아졌습니다. GPU 스케줄링, 모델 서빙, 데이터 파이프라인 등 기존 웹 서비스와는 다른 인프라 요구사항이 생겼고, 이를 추상화할 플랫폼의 필요성이 더욱 절실해졌습니다.

2026년 현황과 트렌드

2026년 현재 Platform Engineering 분야의 주요 트렌드를 정리합니다.

시장 데이터

• **85%**의 Platform Engineering 팀이 IDP를 도입했거나 도입 중
• **94%**의 조직이 AI를 Platform Engineering의 핵심 요소로 인식
• Backstage는 CNCF 졸업 프로젝트로, 3,400개 이상의 조직이 채택

주요 트렌드

1. Platform as a Product(제품으로서의 플랫폼)

플랫폼을 내부 제품으로 취급하는 접근법이 표준이 되었습니다. 제품 관리자(Product Manager)가 플랫폼 팀에 합류하고, 사용자 리서치와 NPS 측정이 일상화되었습니다.

2. AI 기반 플랫폼 기능

AI가 Platform Engineering에 깊이 통합되고 있습니다. 코드 리뷰 자동화, 인프라 이상 탐지, 비용 최적화 추천 등이 AI를 통해 제공됩니다.

3. FinOps 통합

비용 가시성이 플랫폼의 핵심 기능으로 자리잡았습니다. 개발자가 리소스를 생성할 때 예상 비용을 확인하고, 팀별 비용 할당이 자동으로 이루어집니다.

4. 보안 시프트 레프트

보안 정책이 플랫폼에 내장되어 개발 초기부터 적용됩니다. Policy as Code(코드로서의 정책) 접근법을 통해 보안 가드레일이 Golden Path에 포함됩니다.

이 시리즈에서 다룰 내용

이 시리즈는 총 10장으로 구성되어 있으며, Platform Engineering의 개념부터 실전 구축까지 단계적으로 다룹니다.

정리

이번 장에서는 Platform Engineering이 왜 등장했는지, 그 핵심 개념은 무엇인지 살펴보았습니다.

• DevOps의 "모든 것을 직접 하라"는 접근법이 인지 부하를 증가시켰습니다.
• Platform Engineering은 IDP를 통해 외재적 인지 부하를 줄이고, 개발자가 비즈니스 로직에 집중할 수 있도록 합니다.
• IDP는 개발자 경험, 오케스트레이션, 인프라의 세 계층으로 구성됩니다.
• 2026년 현재, Gartner 예측대로 80% 이상의 조직이 전담 플랫폼 팀을 운영하고 있습니다.

다음 장에서는 IDP를 실제로 설계하는 방법을 다룹니다. 사용자 리서치부터 MVP 설계, Build vs Buy 의사결정까지 IDP 설계의 전 과정을 살펴보겠습니다.