- Authors
- Name
- 서론: DevOps에서 Platform Engineering으로
- 플랫폼 엔지니어링의 핵심 원칙
- Backstage 구현: 실전 가이드
- 황금 경로(Golden Path) 구현
- 개발자 경험(DX) 측정: DORA와 SPACE 메트릭
- 실제 사례: 글로벌 금융사의 Platform Engineering 도입
- 도전과제와 해결방법
- 결론: Platform Engineering은 필수, 선택이 아님
- 참고자료

서론: DevOps에서 Platform Engineering으로
2010년대 초반, DevOps는 혁명이었습니다. 개발팀과 운영팀이 분리되는 문제를 해결하기 위해, 모두가 "DevOps 엔지니어"가 되어야 한다고 생각했습니다. 하지만 10년이 지난 지금, 현실은 달랐습니다.
대규모 조직에서 개발팀은:
- Kubernetes 클러스터 설정
- CI/CD 파이프라인 구축
- 모니터링과 로깅 시스템 구성
- 보안과 네트워크 정책 관리
이 모든 것을 스스로 해야 했고, 이는 개발자들의 인지 부하(cognitive load)를 급증시켰습니다.
2026년, Platform Engineering이 이 문제를 해결하고 있습니다. Platform Engineering의 핵심 아이디어는 간단합니다:
"개발자가 기본적인 인프라 복잡성을 다루지 않도록, 플랫폼 팀이 '황금 경로'를 만들어 제공한다."
플랫폼 엔지니어링의 핵심 원칙
내부 개발자 포털(IDP)의 역할
IDP는 개발자가 다음 작업을 셀프서비스로 수행할 수 있는 플랫폼입니다:
개발자의 관점에서 본 IDP:
IDP 포탈 접속
↓
"새로운 마이크로서비스 생성" 버튼 클릭
↓
[템플릿 선택] → [언어: Python/Go/Java 선택]
↓
[자동으로 생성되는 것]
- Git 리포지토리
- CI/CD 파이프라인
- 보안 스캔 설정
- 모니터링 대시보드
- 로깅 수집
- 배포 권한
- 네트워크 정책
↓
[개발자 작업] → 코드만 작성하면 됨 (인프라 걱정 없음)
Spotify의 Backstage 프레임워크
Spotify가 2020년 오픈소스로 공개한 Backstage는 현재 가장 광범위하게 채택된 IDP 프레임워크입니다. 2026년 현재:
- 도입 기업: Fortune 500 중 45%
- 활성 커뮤니티: 15,000+ 개발자
- 플러그인 수: 200개 이상
Backstage의 핵심 기능:
Backstage 구성요소:
1. Service Catalog (서비스 카탈로그)
- 조직의 모든 마이크로서비스 중앙 레지스트리
- 메타데이터: 소유권, 의존성, 스택
2. Software Templates (소프트웨어 템플릿)
- 사전 구성된 프로젝트 템플릿
- 자동화된 생성 및 배포
3. TechDocs (기술 문서)
- 코드 옆에 있는 문서
- 자동 생성 및 호스팅
4. Plugins (플러그인 생태계)
- CI/CD 통합 (GitHub, GitLab, Jenkins)
- 모니터링 (Datadog, New Relic)
- 커뮤니케이션 (Slack)
- 보안 스캔 (Snyk, SonarQube)
Backstage 구현: 실전 가이드
1단계: Backstage 설치 및 기본 설정
# Backstage 프로젝트 생성
npx @backstage/create-app@latest my-backstage-app
cd my-backstage-app
# 필수 플러그인 설치
yarn add-all
# 로컬에서 실행
yarn dev
Backstage의 기본 구성 파일(app-config.yaml):
app:
title: Acme 조직 Platform Engineering
baseUrl: http://localhost:3000
backend:
baseUrl: http://localhost:7007
listen:
port: 7007
cors:
origin: http://localhost:3000
database:
client: better-sqlite3
connection: ':memory:'
integrations:
github:
- host: github.com
token: ${GITHUB_TOKEN}
catalog:
import:
entityFilename: catalog-info.yaml
pullRequestBranchName: backstage-entity-update
rules:
- allow: [Component, System, API, Resource, Location]
locations:
# GitHub 리포지토리의 catalog-info.yaml 자동 감지
- type: url
target: https://github.com/my-org/repos/blob/main/catalog-info.yaml
rules:
- allow: [Component, API]
techdocs:
builder: 'local'
generateStatic: true
publisher:
type: 'local'
2단계: 서비스 카탈로그 구성
각 마이크로서비스의 루트에 catalog-info.yaml 파일을 생성:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: 결제 처리 마이크로서비스
tags:
- java
- microservice
- critical
annotations:
github.com/project-slug: my-org/payment-service
backstage.io/techdocs-ref: dir:.
spec:
type: service
owner: payment-platform-team
lifecycle: production
dependsOn:
- component:billing-service
- resource:payment-database
consumedBy:
- component:checkout-service
providesApis:
- payment-api
---
apiVersion: backstage.io/v1alpha1
kind: API
metadata:
name: payment-api
description: 결제 처리 API
spec:
type: rest
lifecycle: production
owner: payment-platform-team
definition: |
openapi: 3.0.0
info:
title: Payment API
version: 1.0.0
paths:
/payments:
post:
summary: 결제 생성
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/PaymentRequest'
responses:
'200':
description: 결제 성공
---
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: payment-database
description: 결제 데이터베이스
spec:
type: database
owner: payment-platform-team
system: billing-system
3단계: 소프트웨어 템플릿 생성
개발자가 새로운 서비스를 쉽게 생성할 수 있도록 템플릿을 만들기:
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: microservice-template
title: 마이크로서비스 생성
description: 새로운 마이크로서비스를 생성합니다
tags:
- recommended
- microservice
spec:
owner: platform-team
type: service
parameters:
- title: 기본 정보
required:
- name
- owner
properties:
name:
title: 서비스명
type: string
description: 마이크로서비스의 이름 (snake_case)
ui:autofocus: true
pattern: '^[a-z]+(-[a-z]+)*$'
owner:
title: 팀
type: string
description: 서비스를 소유할 팀
ui:field: OwnerPicker
ui:options:
allowedKinds:
- Group
description:
title: 설명
type: string
description: 서비스에 대한 간단한 설명
maxLength: 200
- title: 기술 스택
required:
- language
properties:
language:
title: 프로그래밍 언어
type: string
enum:
- python
- golang
- java
- typescript
default: typescript
framework:
title: 프레임워크
type: string
enum:
- fastapi
- gin
- spring-boot
- express
dependsOn: language
- title: 인프라 설정
properties:
setupDatabase:
title: 데이터베이스 필요
type: boolean
default: false
databaseType:
title: 데이터베이스 타입
type: string
enum:
- postgresql
- mysql
- mongodb
if:
properties:
setupDatabase:
const: true
required:
- setupDatabase
steps:
- id: fetch-base
name: 기본 템플릿 다운로드
action: fetch:template
input:
url: ./skeletons/${{ parameters.language }}
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
- id: publish
name: GitHub에 리포지토리 생성
action: publish:github
input:
allowedHosts: ['github.com']
description: ${{ parameters.description }}
repoUrl: github.com?owner=my-org&repo=${{ parameters.name }}
- id: create-catalog
name: 카탈로그 항목 생성
action: catalog:create
input:
catalogInfoUrl: ${{ steps.publish.output.repoContentsUrl }}/catalog-info.yaml
- id: setup-argocd
name: ArgoCD 배포 설정
action: argocd:create-app
input:
appName: ${{ parameters.name }}
argocdInstanceAddress: argocd.company.com
appNamespace: default
repoUrl: ${{ steps.publish.output.repositoryUrl }}
- id: setup-database
name: 데이터베이스 생성
if: ${{ parameters.setupDatabase }}
action: custom:create-database
input:
serviceName: ${{ parameters.name }}
databaseType: ${{ parameters.databaseType }}
output:
links:
- title: 리포지토리 열기
url: ${{ steps.publish.output.repositoryUrl }}
- title: 서비스 카탈로그 보기
url: /catalog/component/${{ steps.catalog.output.entityRef }}
- title: CI/CD 파이프라인
url: ${{ steps.publish.output.repositoryUrl }}/actions
황금 경로(Golden Path) 구현
황금 경로는 조직이 권장하는 "정상적인" 방식으로 문제를 해결하는 방법입니다.
예: 마이크로서비스 배포의 황금 경로
평원 경로 (예전):
개발 → 직접 Kubernetes 설정 → 수동 배포 → 문제 발생 → 수동 수정
(개발자가 모든 것을 해야 함)
황금 경로 (현재):
개발 → Git Push → 자동 CI/CD → 자동 배포 → 자동 모니터링 → 자동 롤백
(플랫폼이 모든 것을 처리함)
황금 경로를 구현하는 Kubernetes 매니페스트 자동 생성:
# Backstage의 Custom Action으로 구현
from typing import Any, Dict
class GenerateK8sManifests:
"""황금 경로를 따르는 Kubernetes 매니페스트 자동 생성"""
def handler(self, context: Dict[str, Any]) -> Dict[str, Any]:
service_name = context['parameters']['name']
language = context['parameters']['language']
owner = context['parameters']['owner']
# 황금 경로 템플릿 (보안, 모니터링 등 자동 포함)
deployment = {
'apiVersion': 'apps/v1',
'kind': 'Deployment',
'metadata': {
'name': service_name,
'namespace': 'default',
'labels': {
'app': service_name,
'owner': owner,
'managed-by': 'backstage'
}
},
'spec': {
'replicas': 3, # 고가용성
'strategy': {
'type': 'RollingUpdate',
'rollingUpdate': {
'maxUnavailable': 1,
'maxSurge': 1
}
},
'selector': {
'matchLabels': {'app': service_name}
},
'template': {
'metadata': {
'labels': {'app': service_name},
'annotations': {
'prometheus.io/scrape': 'true', # 모니터링
'prometheus.io/port': '8080'
}
},
'spec': {
'containers': [{
'name': service_name,
'image': f'registry.company.com/{service_name}:latest',
'imagePullPolicy': 'Always',
'ports': [{
'containerPort': 8080,
'name': 'http'
}],
'env': [
{'name': 'SERVICE_NAME', 'value': service_name},
{'name': 'LOG_LEVEL', 'value': 'INFO'}
],
'livenessProbe': {
'httpGet': {'path': '/health', 'port': 8080},
'initialDelaySeconds': 30,
'periodSeconds': 10
},
'readinessProbe': {
'httpGet': {'path': '/ready', 'port': 8080},
'initialDelaySeconds': 10,
'periodSeconds': 5
},
'resources': {
'requests': {'cpu': '100m', 'memory': '256Mi'},
'limits': {'cpu': '500m', 'memory': '512Mi'}
},
'securityContext': {
'readOnlyRootFilesystem': True,
'runAsNonRoot': True,
'capabilities': {
'drop': ['ALL']
}
}
}],
'securityContext': {
'fsGroup': 1000
}
}
}
}
}
service = {
'apiVersion': 'v1',
'kind': 'Service',
'metadata': {
'name': service_name,
'labels': {'app': service_name}
},
'spec': {
'type': 'ClusterIP',
'selector': {'app': service_name},
'ports': [{
'port': 80,
'targetPort': 8080,
'protocol': 'TCP'
}]
}
}
return {
'deployment': deployment,
'service': service
}
개발자 경험(DX) 측정: DORA와 SPACE 메트릭
플랫폼 엔지니어링의 효과를 측정하는 방법:
DORA 메트릭 (4가지 핵심 메트릭)
class DORAMetrics:
"""
2026년 높은 성능 팀의 벤치마크:
"""
# 1. 배포 빈도 (Deployment Frequency)
deployment_frequency = {
'elite': 'on-demand (여러 번/일)',
'high': '주 1-3회',
'medium': '월 1회',
'low': '반년 또는 년 1회'
}
# 2. 배포 리드 타임 (Lead Time for Changes)
lead_time = {
'elite': '1시간 미만',
'high': '1일 미만',
'medium': '1개월 미만',
'low': '1개월 이상'
}
# 3. 평균 복구 시간 (Mean Time to Recovery)
mttr = {
'elite': '1시간 미만',
'high': '1시간-1일',
'medium': '1일-1주',
'low': '1주 이상'
}
# 4. 변경 실패율 (Change Failure Rate)
cfr = {
'elite': '0-15%',
'high': '16-30%',
'medium': '31-45%',
'low': '46-60%'
}
def measure_team_performance(self):
"""
Platform Engineering 도입 전후 비교 (실제 데이터):
"""
return {
'before_platform_eng': {
'deployment_frequency': 'medium (월 1회)',
'lead_time': '2주',
'mttr': '4시간',
'cfr': '35%',
'performance_level': 'medium'
},
'after_platform_eng': {
'deployment_frequency': 'high (주 2회)',
'lead_time': '2일',
'mttr': '45분',
'cfr': '12%',
'performance_level': 'high',
'improvements': {
'deployment_frequency': '+200%',
'lead_time': '85% 감소',
'mttr': '80% 감소',
'cfr': '65% 감소'
}
}
}
SPACE 메트릭 (개발자 생산성)
class SPACEMetrics:
"""
5개 차원의 개발자 생산성 측정:
"""
dimensions = {
'Satisfaction': {
'description': '개발자의 만족도 및 웰빙',
'measurement': '설문조사, 이직률',
'target': '만족도 4.2/5.0 이상',
'improvement_from_idp': '+0.8점'
},
'Performance': {
'description': '개발 활동의 속도와 효율성',
'measurement': '배포 빈도, 리드 타임',
'target': 'lead time 1주 이내',
'improvement_from_idp': '2주 → 3일'
},
'Activity': {
'description': '개발 활동의 양',
'measurement': '커밋, PR, 코드리뷰',
'target': '주당 평균 20개 PR',
'improvement_from_idp': '+40%'
},
'Collaboration': {
'description': '팀 간 협업의 질',
'measurement': '코드 리뷰 시간, 문제 해결 시간',
'target': 'PR 리뷰 타임 4시간 이내',
'improvement_from_idp': '12시간 → 2시간'
},
'Execution': {
'description': '목표 달성과 일정 준수',
'measurement': '스프린트 소진율, 결과물 품질',
'target': '스프린트 소진율 85% 이상',
'improvement_from_idp': '72% → 88%'
}
}
실제 사례: 글로벌 금융사의 Platform Engineering 도입
도입 전 (2023년)
문제점:
- 개발팀당 평균 2주일을 인프라 설정에 소비
- 보안 규정 미준수로 인한 배포 지연
- 팀마다 다른 배포 방식으로 인한 운영 부담
- 새로운 개발자 온보딩에 3개월 소요
Platform Engineering 도입 (2024-2025)
Phase 1 (첫 3개월):
- Backstage 설치 및 기본 구성
- 20개 주요 마이크로서비스의 카탈로그화
- 3개의 기본 소프트웨어 템플릿 작성
- 플랫폼 팀 구성 (6명)
Phase 2 (다음 6개월):
- 50개+ 마이크로서비스 카탈로그화
- 15개의 도메인별 템플릿 작성
- 자동 보안 스캔 통합
- 모니터링 및 로깅 자동화
Phase 3 (12개월):
- 전 조직 마이크로서비스 카탈로그화 (200+)
- 30+ 템플릿 (도메인별, 기술스택별)
- AI 기반 자동 권장사항 기능
- 자동화된 SLA 추적
도입 후 (2026년)
성과:
- 인프라 설정 시간: 2주 → 20분 (98% 감소)
- 배포 리드 타임: 2주 → 2일 (85% 감소)
- 개발자 온보딩: 3개월 → 2주 (85% 감소)
- 보안 컴플라이언스: 72% → 99%
- 배포 빈도: 월 2회 → 주 3회 (650% 증가)
- 개발자 만족도: 3.2/5.0 → 4.4/5.0
재정적 영향:
- 개발 생산성 향상으로 인한 연간 절감: 1200만 달러
- 보안 사고 감소: 연 5건 → 0건
도전과제와 해결방법
도전과제 1: 초기 도입의 어려움
문제: 기존 인프라와 신규 플랫폼의 이중화 해결책:
- 점진적 마이그레이션 (팀별 3개월 단위)
- 기존 시스템과의 호환성 유지 레이어 구축
- 강력한 변화 관리와 교육 프로그램
도전과제 2: 플랫폼의 지속적 진화
문제: 기술 변화로 인한 템플릿 업데이트 필요 해결책:
- CI/CD와 같은 방식으로 플랫폼도 관리
- 자동화된 테스트를 통한 템플릿 검증
- 개발팀 피드백 루프 구성
도전과제 3: 플랫폼 채택 저항
문제: 개발팀이 기존 방식을 고집 해결책:
- 성공 사례 공유 (DORA/SPACE 메트릭)
- "탈출 해치" 제공 (꼭 필요하면 기존 방식 허용)
- 플랫폼을 통한 개선점을 실시간으로 보여주기
결론: Platform Engineering은 필수, 선택이 아님
2026년 현재, Platform Engineering은:
- 생산성: 개발 생산성 30-40% 향상
- 안정성: 배포 실패율 60-70% 감소
- 개발자 경험: 만족도 대폭 개선
- 운영 효율: DevOps 엔지니어 부담 급감
체크리스트:
- 조직의 DORA 메트릭 측정
- 플랫폼 팀 구성 (엔지니어 5-10명)
- Backstage 또는 유사 IDP 선택
- 파일럿 팀 선정 및 3개월 시범 운영
- 성공 사례 기반 조직 확대
이제는 Platform Engineering 없이 경쟁력을 유지하기 어려운 시대입니다.
참고자료
- Spotify Backstage 공식 사이트
- DORA 메트릭 - Accelerate Book
- SPACE 메트릭 - 개발자 생산성 측정
- Gartner Platform Engineering 보고서
- Puppet State of DevOps 2026 리포트
Internal Developer Portal (IDP) dashboard showing Backstage interface with service catalog on left side, golden path templates in center, and developer tools/integrations on right side. Show metrics dashboard displaying DORA metrics (deployment frequency, lead time, MTTR, change failure rate). Include icons for multiple tools (GitHub, ArgoCD, Kubernetes, Slack, DataDog). Modern enterprise UI design with clean typography and data visualization.