Platform Engineering: Internal Developer Platform 구축 방법

spinny:~/writing $ less platform-engineering-internal-developer-platform.md

1 
2소프트웨어 시스템이 점점 더 복잡해지면서  -  마이크로서비스, Kubernetes, 멀티클라우드, CI/CD 파이프라인, 관측성 스택  -  개발자들은 인프라에 더 많은 시간을 쓰고 제품 구축에는 더 적은 시간을 쓰고 있습니다. **Platform Engineering**은 복잡성을 추상화하고 개발자에게 더 빠른 배포를 위한 셀프서비스 도구를 제공하는 내부 플랫폼을 만들어 이 문제를 해결합니다.
3 
4Gartner는 2027년까지 **소프트웨어 엔지니어링 조직의 80%**가 플랫폼 팀을 설립할 것으로 예측합니다. 이 가이드에서는 Platform Engineering이 무엇인지, 왜 중요한지, 그리고 Internal Developer Platform을 처음부터 구축하는 방법을 살펴보겠습니다.
5 
6## Platform Engineering이란?
7 
8Platform Engineering은 소프트웨어 엔지니어링 조직을 위한 셀프서비스 기능을 가능하게 하는 도구 체인과 워크플로를 설계하고 구축하는 분야입니다. 그 결과물은 **Internal Developer Platform (IDP)**  -  개발자와 인프라 사이에 위치하는 계층입니다.
9 
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17 
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24 
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31 
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43 
44### Platform Engineering vs DevOps
45 
46Platform Engineering은 DevOps의 대체가 아닙니다  -  다음 단계의 진화입니다. DevOps는 "네가 만들면, 네가 운영해"라고 했습니다. Platform Engineering은 "우리가 만들기와 운영을 쉽게 만들어 줄게"라고 말합니다.
47 
48| 측면 | DevOps | Platform Engineering |
49|------|--------|---------------------|
50| **초점** | 문화와 실천 | 제품과 셀프서비스 |
51| **접근방식** | 각 팀이 인프라 관리 | 플랫폼 팀이 인프라 추상화 |
52| **인지 부하** | 높음 (각 팀이 모든 것을 학습) | 낮음 (골든 패스 제공) |
53| **결과물** | CI/CD 파이프라인, IaC 스크립트 | Internal Developer Platform |
54| **사용자** | 모든 엔지니어링 | 플랫폼 팀이 엔지니어링 서비스 |
55 
56## Platform Engineering이 중요한 이유
57 
58### 인지 부하 문제
59 
60일반적인 현대 조직에서 개발자는 다음을 이해해야 합니다:
61 
62- Git 워크플로와 브랜치 전략
63- CI/CD 파이프라인 설정
64- 컨테이너 빌드와 레지스트리 관리
65- Kubernetes 매니페스트와 Helm Charts
66- 클라우드 제공업체 서비스 (AWS/GCP/Azure)
67- 네트워킹, DNS, TLS 인증서
68- 모니터링, 로깅, 알림 설정
69- 데이터베이스 프로비저닝과 마이그레이션
70- 보안 정책과 규정 준수
71 
72이것은 실제 제품에서 집중력을 빼앗는 엄청난 인지 부담입니다.
73 
74### 골든 패스
75 
76Platform Engineering은 **골든 패스** 개념을 도입합니다  -  일반적인 작업을 위한 의견이 담긴, 잘 지원되고 문서화된 경로입니다. 골든 패스는 강제가 아닙니다; 개발자는 *벗어날 수 있지만*, 플랫폼은 올바른 것을 쉬운 것으로 만듭니다.
77 
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88 
89**새 마이크로서비스 생성을 위한 골든 패스 예시:**
901. 개발자가 포털에서 "새 백엔드 서비스"를 선택
912. 언어/프레임워크 선택 (Node.js, Go, Python)
923. 플랫폼이 자동 생성: Git 리포지토리, CI/CD 파이프라인, Kubernetes 네임스페이스, 모니터링 대시보드, 알림 규칙
934. 개발자가 리포지토리를 클론하고 즉시 코딩 시작
94 
95## Internal Developer Platform 구축
96 
97### 레이어 1: Developer Portal
98 
99포털은 개발자를 위한 단일 진입점입니다. 가장 인기 있는 오픈소스 옵션은 **Backstage** (Spotify가 만들었으며, 현재 CNCF 프로젝트)입니다.
100 
101핵심 기능:
102- **서비스 카탈로그**: 모든 서비스, 소유자, 문서, 의존성
103- **소프트웨어 템플릿**: 모범 사례가 내장된 새 서비스 스캐폴딩
104- **기술 문서**: 코드로서의 문서, 렌더링 및 검색 가능
105- **플러그인 생태계**: 커스텀 기능으로 확장 가능
106 
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127 
128### 레이어 2: 인프라 추상화
129 
130개발자는 Terraform이나 Kubernetes YAML을 직접 작성해서는 안 됩니다. 플랫폼이 추상화를 제공해야 합니다.
131 
132**도구:**
133- **Crossplane**: Kubernetes 네이티브 인프라 프로비저닝
134- **Terraform 모듈**: 사전 구축되고 테스트된 인프라 모듈
135- **Pulumi**: 실제 코드로서의 인프라 (TypeScript, Python, Go)
136 
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149 
150RDS 파라미터, VPC 서브넷, 보안 그룹, 백업 정책을 구성하는 대신, 개발자는 `size: small`과 `backup: daily`만 지정합니다. 플랫폼이 나머지를 처리합니다.
151 
152### 레이어 3: CI/CD 표준화
153 
154팀마다 각자의 파이프라인을 만들지 않도록 CI/CD를 표준화합니다.
155 
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163 
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172 
173**핵심 실천사항:**
174- 팀이 포함(복사가 아닌)하는 공유 CI/CD 템플릿
175- 자동 보안 스캐닝 (SAST, 의존성 감사)
176- 표준화된 배포 전략 (카나리, 블루/그린)
177- 헬스 체크 실패 시 자동 롤백
178 
179### 레이어 4: 관측성
180 
181사전 구성된 모니터링으로 개발자가 즉시 대시보드와 알림을 받습니다.
182 
183- **메트릭**: Prometheus + Grafana, 서비스별 표준 대시보드
184- **로깅**: 중앙 집중 수집이 포함된 구조화된 로깅 (Loki, ELK)
185- **트레이싱**: OpenTelemetry를 활용한 분산 트레이싱
186- **알림**: 합리적인 기본값이 적용된 PagerDuty/Opsgenie 연동
187 
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199 
200## 성공 측정
201 
202플랫폼이 잘 작동하는지 어떻게 알 수 있을까요? 다음 메트릭을 추적하세요:
203 
204### DORA 메트릭
205- **배포 빈도**: 코드가 프로덕션에 도달하는 빈도
206- **변경 리드 타임**: 커밋에서 프로덕션까지의 시간
207- **변경 실패율**: 장애를 유발하는 배포의 비율
208- **평균 복구 시간**: 인시던트 후 서비스를 복원하는 시간
209 
210### 플랫폼 특화 메트릭
211- **첫 배포까지의 시간**: "새 서비스"에서 첫 프로덕션 배포까지 소요 시간
212- **개발자 만족도 (NPS)**: 사용자를 정기적으로 설문 조사
213- **셀프서비스 비율**: 티켓 없이 처리되는 인프라 요청의 %
214- **골든 패스 채택률**: 권장 경로를 따르는 서비스의 %
215 
216## 흔한 실수
217 
218### 1. 너무 일찍 너무 많이 만들기
219거창한 비전이 아닌 가장 큰 고통점부터 시작하세요. 배포가 고통스럽다면 거기서 시작하세요. 프로비저닝에 몇 주가 걸린다면 거기서 시작하세요.
220 
221### 2. 플랫폼을 제품으로 다루지 않기
222플랫폼 팀에는 프로덕트 매니저, 사용자 리서치, 피드백 루프가 필요합니다. 개발자가 여러분의 고객입니다  -  그들의 니즈를 이해하세요.
223 
224### 3. 끌어들이는 대신 강제하기
225최고의 플랫폼은 개발자의 삶을 더 쉽게 만들기 때문에 자발적으로 채택됩니다. 사용을 강제해야 한다면, 플랫폼이 충분히 좋지 않다는 뜻입니다.
226 
227### 4. 개발자 경험 무시하기
228끔찍한 UX의 플랫폼은 사용되지 않습니다. 명확한 문서, 도움되는 에러 메시지, 빠른 피드백 루프에 투자하세요.
229 
230## 시작하기
231 
232첫 번째 IDP를 구축하기 위한 실용적인 로드맵:
233 
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239 
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243 
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247 
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251 
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256 
257### 최소 실행 가능 플랫폼
258 
2591. **서비스 카탈로그** (Backstage)  -  무엇이 존재하고 누가 소유하는지 파악
2602. **하나의 서비스 템플릿**  -  가장 일반적인 서비스 유형을 위한 골든 패스
2613. **표준화된 CI/CD**  -  팀이 포함하는 공유 파이프라인
2624. **기본 문서**  -  플랫폼 사용법, 도움을 받을 수 있는 곳
263 
264이 MVP는 2-3명의 엔지니어 팀으로 2-3개월 내에 구축할 수 있습니다.
265 
266## 결론
267 
268Platform Engineering은 첫날부터 완벽한 플랫폼을 만드는 것이 아닙니다. 개발자의 인지 부하를 점진적으로 줄여 제품 구축에 집중할 수 있게 하는 것입니다. 작게 시작하고, 영향을 측정하고, 개발자 피드백을 기반으로 반복하세요.
269 
270Platform Engineering에 투자하는 조직은 상당한 경쟁 우위를 갖게 됩니다: 더 빠른 딜리버리, 더 행복한 개발자, 그리고 더 안정적인 시스템.
271 
272**리소스:**
273- [Team Topologies](https://teamtopologies.com/)  -  플랫폼 팀을 대중화한 책
274- [Backstage](https://backstage.io/)  -  Spotify의 오픈소스 개발자 포털
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  커뮤니티 정의와 모범 사례
276- [platformengineering.org](https://platformengineering.org/)  -  커뮤니티, 이벤트, 리소스
277

:Platform Engineering: Internal Developer Platform 구축 방법lines 1-277 (END) — press q to close

2소프트웨어 시스템이 점점 더 복잡해지면서 - 마이크로서비스, Kubernetes, 멀티클라우드, CI/CD 파이프라인, 관측성 스택 - 개발자들은 인프라에 더 많은 시간을 쓰고 제품 구축에는 더 적은 시간을 쓰고 있습니다. **Platform Engineering**은 복잡성을 추상화하고 개발자에게 더 빠른 배포를 위한 셀프서비스 도구를 제공하는 내부 플랫폼을 만들어 이 문제를 해결합니다.

4Gartner는 2027년까지 **소프트웨어 엔지니어링 조직의 80%**가 플랫폼 팀을 설립할 것으로 예측합니다. 이 가이드에서는 Platform Engineering이 무엇인지, 왜 중요한지, 그리고 Internal Developer Platform을 처음부터 구축하는 방법을 살펴보겠습니다.

6## Platform Engineering이란?

8Platform Engineering은 소프트웨어 엔지니어링 조직을 위한 셀프서비스 기능을 가능하게 하는 도구 체인과 워크플로를 설계하고 구축하는 분야입니다. 그 결과물은 **Internal Developer Platform (IDP)** - 개발자와 인프라 사이에 위치하는 계층입니다.

10```mermaid

11graph TD

12 subgraph "Developers"

13 D1[Frontend Team]

14 D2[Backend Team]

15 D3[Data Team]

16 end

18 subgraph "Internal Developer Platform"

19 Portal[Developer Portal]

20 Templates[Service Templates]

21 CICD[CI/CD Pipelines]

22 Infra[Infrastructure Abstraction]

23 end

25 subgraph "Infrastructure"

26 K8s[Kubernetes]

27 Cloud[Cloud Services]

28 DB[Databases]

29 Monitor[Monitoring]

30 end

32 D1 --> Portal

33 D2 --> Portal

34 D3 --> Portal

35 Portal --> Templates

36 Portal --> CICD

37 Portal --> Infra

38 Infra --> K8s

39 Infra --> Cloud

40 Infra --> DB

41 CICD --> Monitor

42```

44### Platform Engineering vs DevOps

46Platform Engineering은 DevOps의 대체가 아닙니다 - 다음 단계의 진화입니다. DevOps는 "네가 만들면, 네가 운영해"라고 했습니다. Platform Engineering은 "우리가 만들기와 운영을 쉽게 만들어 줄게"라고 말합니다.

48| 측면 | DevOps | Platform Engineering |

49|------|--------|---------------------|

50| **초점** | 문화와 실천 | 제품과 셀프서비스 |

51| **접근방식** | 각 팀이 인프라 관리 | 플랫폼 팀이 인프라 추상화 |

52| **인지 부하** | 높음 (각 팀이 모든 것을 학습) | 낮음 (골든 패스 제공) |

53| **결과물** | CI/CD 파이프라인, IaC 스크립트 | Internal Developer Platform |

54| **사용자** | 모든 엔지니어링 | 플랫폼 팀이 엔지니어링 서비스 |

56## Platform Engineering이 중요한 이유

58### 인지 부하 문제

60일반적인 현대 조직에서 개발자는 다음을 이해해야 합니다:

62- Git 워크플로와 브랜치 전략

63- CI/CD 파이프라인 설정

64- 컨테이너 빌드와 레지스트리 관리

65- Kubernetes 매니페스트와 Helm Charts

66- 클라우드 제공업체 서비스 (AWS/GCP/Azure)

67- 네트워킹, DNS, TLS 인증서

68- 모니터링, 로깅, 알림 설정

69- 데이터베이스 프로비저닝과 마이그레이션

70- 보안 정책과 규정 준수

72이것은 실제 제품에서 집중력을 빼앗는 엄청난 인지 부담입니다.

74### 골든 패스

76Platform Engineering은 **골든 패스** 개념을 도입합니다 - 일반적인 작업을 위한 의견이 담긴, 잘 지원되고 문서화된 경로입니다. 골든 패스는 강제가 아닙니다; 개발자는 *벗어날 수 있지만*, 플랫폼은 올바른 것을 쉬운 것으로 만듭니다.

78```mermaid

79flowchart LR

80 Dev[Developer] -- "Create new service" --> Portal[Portal]

81 Portal -- "Select template" --> Template[Service Template]

82 Template -- "Auto-provision" --> Repo[Git Repository]

83 Template --> Pipeline[CI/CD Pipeline]

84 Template --> Infra[Kubernetes Namespace]

85 Template --> Monitor[Dashboards + Alerts]

86 Repo --> Ready[Ready to Code!]

87```

89**새 마이크로서비스 생성을 위한 골든 패스 예시:**

901. 개발자가 포털에서 "새 백엔드 서비스"를 선택

912. 언어/프레임워크 선택 (Node.js, Go, Python)

923. 플랫폼이 자동 생성: Git 리포지토리, CI/CD 파이프라인, Kubernetes 네임스페이스, 모니터링 대시보드, 알림 규칙

934. 개발자가 리포지토리를 클론하고 즉시 코딩 시작

95## Internal Developer Platform 구축

97### 레이어 1: Developer Portal

99포털은 개발자를 위한 단일 진입점입니다. 가장 인기 있는 오픈소스 옵션은 **Backstage** (Spotify가 만들었으며, 현재 CNCF 프로젝트)입니다.

100

101핵심 기능:

102- **서비스 카탈로그**: 모든 서비스, 소유자, 문서, 의존성

103- **소프트웨어 템플릿**: 모범 사례가 내장된 새 서비스 스캐폴딩

104- **기술 문서**: 코드로서의 문서, 렌더링 및 검색 가능

105- **플러그인 생태계**: 커스텀 기능으로 확장 가능

106

107```yaml

108# backstage/catalog-info.yaml

109apiVersion: backstage.io/v1alpha1

110kind: Component

111metadata:

112 name: user-service

113 description: Manages user accounts and authentication

114 annotations:

115 github.com/project-slug: myorg/user-service

116 backstage.io/techdocs-ref: dir:.

117spec:

118 type: service

119 lifecycle: production

120 owner: team-auth

121 system: identity-platform

122 dependsOn:

123 - resource:postgresql-main

124 providesApis:

125 - user-api

126```

127

128### 레이어 2: 인프라 추상화

129

130개발자는 Terraform이나 Kubernetes YAML을 직접 작성해서는 안 됩니다. 플랫폼이 추상화를 제공해야 합니다.

131

132**도구:**

133- **Crossplane**: Kubernetes 네이티브 인프라 프로비저닝

134- **Terraform 모듈**: 사전 구축되고 테스트된 인프라 모듈

135- **Pulumi**: 실제 코드로서의 인프라 (TypeScript, Python, Go)

136

137```yaml

138# Example: Crossplane composition for a database

139apiVersion: database.example.com/v1

140kind: PostgreSQLInstance

141metadata:

142 name: user-db

143spec:

144 size: small # Abstraction: small = 2 vCPU, 4GB RAM

145 version: "16"

146 backup: daily

147 team: auth-team

148```

149

150RDS 파라미터, VPC 서브넷, 보안 그룹, 백업 정책을 구성하는 대신, 개발자는 `size: small`과 `backup: daily`만 지정합니다. 플랫폼이 나머지를 처리합니다.

151

152### 레이어 3: CI/CD 표준화

153

154팀마다 각자의 파이프라인을 만들지 않도록 CI/CD를 표준화합니다.

155

156```yaml

157# .github/workflows/platform-ci.yml

158# Teams just include the shared workflow

159name: Build and Deploy

160on:

161 push:

162 branches: [main]

163

164jobs:

165 pipeline:

166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2

167 with:

168 language: node

169 deploy-target: production

170 secrets: inherit

171```

172

173**핵심 실천사항:**

174- 팀이 포함(복사가 아닌)하는 공유 CI/CD 템플릿

175- 자동 보안 스캐닝 (SAST, 의존성 감사)

176- 표준화된 배포 전략 (카나리, 블루/그린)

177- 헬스 체크 실패 시 자동 롤백

178

179### 레이어 4: 관측성

180

181사전 구성된 모니터링으로 개발자가 즉시 대시보드와 알림을 받습니다.

182

183- **메트릭**: Prometheus + Grafana, 서비스별 표준 대시보드

184- **로깅**: 중앙 집중 수집이 포함된 구조화된 로깅 (Loki, ELK)

185- **트레이싱**: OpenTelemetry를 활용한 분산 트레이싱

186- **알림**: 합리적인 기본값이 적용된 PagerDuty/Opsgenie 연동

187

188```mermaid

189graph LR

190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]

191 Collector --> Prometheus[Prometheus]

192 Collector --> Loki[Loki]

193 Collector --> Tempo[Tempo]

194 Prometheus --> Grafana[Grafana Dashboards]

195 Loki --> Grafana

196 Tempo --> Grafana

197 Grafana --> PagerDuty[PagerDuty Alerts]

198```

199

200## 성공 측정

201

202플랫폼이 잘 작동하는지 어떻게 알 수 있을까요? 다음 메트릭을 추적하세요:

203

204### DORA 메트릭

205- **배포 빈도**: 코드가 프로덕션에 도달하는 빈도

206- **변경 리드 타임**: 커밋에서 프로덕션까지의 시간

207- **변경 실패율**: 장애를 유발하는 배포의 비율

208- **평균 복구 시간**: 인시던트 후 서비스를 복원하는 시간

209

210### 플랫폼 특화 메트릭

211- **첫 배포까지의 시간**: "새 서비스"에서 첫 프로덕션 배포까지 소요 시간

212- **개발자 만족도 (NPS)**: 사용자를 정기적으로 설문 조사

213- **셀프서비스 비율**: 티켓 없이 처리되는 인프라 요청의 %

214- **골든 패스 채택률**: 권장 경로를 따르는 서비스의 %

215

216## 흔한 실수

217

218### 1. 너무 일찍 너무 많이 만들기

219거창한 비전이 아닌 가장 큰 고통점부터 시작하세요. 배포가 고통스럽다면 거기서 시작하세요. 프로비저닝에 몇 주가 걸린다면 거기서 시작하세요.

220

221### 2. 플랫폼을 제품으로 다루지 않기

222플랫폼 팀에는 프로덕트 매니저, 사용자 리서치, 피드백 루프가 필요합니다. 개발자가 여러분의 고객입니다 - 그들의 니즈를 이해하세요.

223

224### 3. 끌어들이는 대신 강제하기

225최고의 플랫폼은 개발자의 삶을 더 쉽게 만들기 때문에 자발적으로 채택됩니다. 사용을 강제해야 한다면, 플랫폼이 충분히 좋지 않다는 뜻입니다.

226

227### 4. 개발자 경험 무시하기

228끔찍한 UX의 플랫폼은 사용되지 않습니다. 명확한 문서, 도움되는 에러 메시지, 빠른 피드백 루프에 투자하세요.

229

230## 시작하기

231

232첫 번째 IDP를 구축하기 위한 실용적인 로드맵:

233

234```mermaid

235flowchart TD

236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]

237 B --> C[Month 5-6: Iterate]

238 C --> D[Month 7+: Scale]

239

240 A --> A1[Interview developers]

241 A --> A2[Map pain points]

242 A --> A3[Choose first golden path]

243

244 B --> B1[Deploy Backstage]

245 B --> B2[First service template]

246 B --> B3[Standardized CI/CD]

247

248 C --> C1[Gather feedback]

249 C --> C2[Add infrastructure abstraction]

250 C --> C3[Improve docs and onboarding]

251

252 D --> D1[More templates and golden paths]

253 D --> D2[Self-service infrastructure]

254 D --> D3[Advanced observability]

255```

256

257### 최소 실행 가능 플랫폼

258

2591. **서비스 카탈로그** (Backstage) - 무엇이 존재하고 누가 소유하는지 파악

2602. **하나의 서비스 템플릿** - 가장 일반적인 서비스 유형을 위한 골든 패스

2613. **표준화된 CI/CD** - 팀이 포함하는 공유 파이프라인

2624. **기본 문서** - 플랫폼 사용법, 도움을 받을 수 있는 곳

263

264이 MVP는 2-3명의 엔지니어 팀으로 2-3개월 내에 구축할 수 있습니다.

265

266## 결론

267

268Platform Engineering은 첫날부터 완벽한 플랫폼을 만드는 것이 아닙니다. 개발자의 인지 부하를 점진적으로 줄여 제품 구축에 집중할 수 있게 하는 것입니다. 작게 시작하고, 영향을 측정하고, 개발자 피드백을 기반으로 반복하세요.

269

270Platform Engineering에 투자하는 조직은 상당한 경쟁 우위를 갖게 됩니다: 더 빠른 딜리버리, 더 행복한 개발자, 그리고 더 안정적인 시스템.

271

272**리소스:**

273- [Team Topologies](https://teamtopologies.com/) - 플랫폼 팀을 대중화한 책

274- [Backstage](https://backstage.io/) - Spotify의 오픈소스 개발자 포털

275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - 커뮤니티 정의와 모범 사례

276- [platformengineering.org](https://platformengineering.org/) - 커뮤니티, 이벤트, 리소스

277