플랫폼 엔지니어링DevOpsIDPBackstage골든 패스

플랫폼 엔지니어링 완전 가이드: DevOps 다음은 무엇인가

Gartner가 2026년까지 대형 SW 조직의 80%가 도입할 것으로 예측한 플랫폼 엔지니어링. 실제로는 90%가 이미 도입해 예측을 1년 앞질렀다. DevOps의 다음 단계인 플랫폼 엔지니어링이 왜 필요하고, 어떻게 시작하는지.

코어닷투데이2025-12-2212분

들어가며: DevOps가 만든 새로운 문제

DevOps는 혁명이었다. 개발(Dev)과 운영(Ops) 사이의 벽을 무너뜨리고, 배포를 자동화하고, 피드백 루프를 단축했다.

그런데 2026년, DevOps 자체가 새로운 문제를 만들었다.

"You build it, you run it"이 "You build it, you configure it, you deploy it, you monitor it, you're on call for it"가 되었다. 개발자는 코드를 쓰는 것 외에 Kubernetes, Terraform, Helm, ArgoCD, Prometheus, Grafana, OPA... 수십 가지 도구를 직접 관리해야 한다.

이것이 인지 과부하(cognitive overload)다. 개발자가 인프라 관리에 쏟는 시간이 실제 코드 작성 시간을 잡아먹는다.

플랫폼 엔지니어링은 이 문제의 답이다.

제1장: 플랫폼 엔지니어링이란

정의

개발자를 위한 셀프서비스 내부 플랫폼(Internal Developer Platform, IDP)을 구축하고 운영하는 분야. 개발 인프라를 제품처럼 취급하며, 개발자를 고객으로 본다.

DevOps와의 차이

DevOps vs 플랫폼 엔지니어링

DevOps 문화 운동 개발-운영 협업. "벽을 허물자."

플랫폼 엔지니어링 제품 분야 개발자 인프라를 제품으로. "개발자가 알아서 쓸 수 있게."

플랫폼 엔지니어링은 DevOps를 대체하지 않는다.** DevOps 문화 위에서, 그 문화를 **확장(scale)하는 것이다.

제2장: 왜 지금 필요한가 — 숫자로 보는 채택률

Gartner 2022년 예측: 2026년까지 대형 SW 조직의 80%가 도입
실제 2025년 결과 (DORA 보고서)**: **거의 90%가 이미 내부 플랫폼 보유 → Gartner 예측을 1년 앞질러 달성
기업의 55.9%가 2개 이상의 플랫폼을 운영
임원의 88%가 플랫폼 엔지니어링을 고성과의 핵심 동력으로 평가
시장 규모: $58억(2023) →$ 402억(2032) — 연평균 24% 성장

하지만 경고도 있다: 플랫폼 엔지니어링 이니셔티브의 70%가 18개월 내 실패한다. 도구 문제가 아니라 제품 관리 문제로 접근하지 않았기 때문이다.

제3장: IDP의 핵심 구성 요소

내부 개발자 플랫폼(IDP) 핵심 구성

개발자 포털 서비스 검색, 문서 접근, 리소스 프로비저닝, 모니터링을 하나의 인터페이스에서

골든 패스 사전 승인된 템플릿. 보안·CI/CD·인프라가 미리 구성됨.

서비스 카탈로그 모든 서비스, API, 라이브러리의 중앙 레지스트리. 소유권 추적.

셀프서비스 인프라 Terraform/Pulumi 모듈. 티켓 없이 리소스 프로비저닝.

자동화 CI/CD 템플릿화된 파이프라인. 자동 테스트, 보안 스캔.

관측성 모니터링, 로깅, 트레이싱, 비용 가시성 내장.

골든 패스 — 가장 중요한 개념

골든 패스(Golden Path)는 "새 프로젝트를 시작할 때 따르는 사전 검증된 경로"다.

예: Python FastAPI 골든 패스가 있으면:

Docker 설정 → 미리 구성됨
CI/CD 파이프라인 → 미리 구성됨
인프라(Terraform) → 미리 구성됨
보안 스캔 → 미리 구성됨
모니터링 → 미리 구성됨

개발자는 비즈니스 로직만 작성하면 된다. 나머지는 플랫폼이 처리한다. 티켓을 제출하고 기다릴 필요 없다.

제4장: 주요 도구

도구	유형	핵심 특징
Backstage (Spotify)	오픈소스 개발자 포털	CNCF 프로젝트. 서비스 카탈로그, 플러그인 생태계. 6~12개월 구축 필요.
Port	SaaS 개발자 포털	셀프서비스 액션, 자동화. Backstage보다 빠른 구축.
Humanitec	SaaS 플랫폼 오케스트레이터	그래프 기반 백엔드. 보안, 거버넌스, 비용 관리. 엔터프라이즈 규모.
Kratix	오픈소스 오케스트레이터	Kubernetes 네이티브. "Promise" 기반 계약 모델.

조합 가능: Backstage(포털) + Humanitec(오케스트레이터) 또는 Backstage + Kratix를 레이어링할 수 있다.

제5장: DevOps · SRE · FinOps와의 관계

분야	핵심 관심사
DevOps	배포 흐름 (빌드→테스트→배포), 협업, 자동화
SRE	신뢰성, SLO, 인시던트 대응
플랫폼 엔지니어링	셀프서비스, 골든 패스, 개발자 경험
FinOps	클라우드 비용 가시성, 최적화, 책임

2026년 수렴: FinOps 조직의 78%가 CTO/CIO 산하로 보고(전년 대비 18%↑). 비용이 지연시간, 에러율과 동급의 성능 메트릭으로 취급된다. 플랫폼 엔지니어링이 이 모든 것을 개발자가 결정하는 시점에 통합 제공한다.

제6장: 성공과 실패

성공 지표 (DORA 메트릭)

메트릭	엘리트 수준
배포 빈도	하루 여러 번
변경 리드 타임	1일 미만
변경 실패율	5% 미만
MTTR (복구 시간)	1시간 미만

Spotify의 사례: AI 에이전트가 2026년에 1,500건 이상의 머지된 PR을 생성, 대규모 마이그레이션에서 60~90% 시간 절감.

70% 실패율의 교훈

실패하는 이유:

도구 문제로 접근: 플랫폼은 도구가 아니라 제품이다. 제품 관리(로드맵, 피드백 루프, 사용자 리서치)가 필수.
개발자 피드백 부재: 플랫폼을 만들고 "쓰세요"라고 한다. 개발자가 실제로 필요로 하는 것을 묻지 않는다.
경영진 후원 부족: 플랫폼 팀은 장기 투자다. 단기 ROI를 요구하면 팀이 무너진다.

맺으며: 시작하는 법

플랫폼 엔지니어링은 "Backstage를 설치하는 것"이 아니다. 세 가지를 기억하라:

개발자와 대화하라. 어디서 시간을 낭비하는지, 무엇이 반복적인지 물어라.
작게 시작하라. 골든 패스 하나, 셀프서비스 인프라 하나부터 시작해 점진적으로 확장.
제품처럼 운영하라. 로드맵, 사용자 피드백, 반복 개선. 도구를 만드는 게 아니라 개발자 경험을 만드는 것이다.