들어가며 — 왜 "Platform Engineering"이 뜨는가
2023~2025년 가장 빠르게 성장하는 엔지니어링 역할: **Platform Engineer**.
**배경:**
- Kubernetes·클라우드 네이티브가 복잡해짐 → 모든 팀이 다 배우기 어려움
- "You build it, you run it" (DevOps)이 모두에게 번아웃 유발
- 내부 공통 플랫폼이 없으면 팀마다 바퀴를 재발명
- Cognitive Load (Team Topologies, 2019) 이론의 확산
**Platform Engineering의 정의 (Thoughtworks, 2023):**
> "내부 개발자 플랫폼(IDP)을 **제품으로** 제공하여, 애플리케이션 개발자의 인지 부하를 줄이고 생산성을 높이는 엔지니어링 분야."
키워드: **"제품으로"** — 내부 사용자도 고객으로 취급.
1부 — Platform Engineering vs SRE vs DevOps
1.1 개념 정리
- **DevOps**: 문화·철학 (Dev + Ops 협업)
- **SRE**: 신뢰성 엔지니어링 (SLO, Error Budget)
- **Platform Engineering**: 내부 플랫폼을 제품으로 만드는 팀
1.2 어떻게 공존하는가 (Team Topologies 관점)
Stream-aligned Team (제품 팀)
↓ 사용
Platform Team (내부 플랫폼)
↓ 지원
Enabling Team (교육·컨설팅)
↓ 특수 영역
Complicated Subsystem Team (DB, 보안 등)
1.3 SRE와의 차이
| SRE | Platform Engineer |
|-----|------------------|
| 신뢰성 중심 | 생산성 중심 |
| SLO·Error Budget | DORA·DX |
| 사고 대응 | 온보딩·Golden Path |
| Toil 감소 | Cognitive Load 감소 |
**공존 가능**: SRE가 품질을, Platform Engineer가 경험을 담당. 큰 조직은 둘 다 존재.
1.4 2025년 역할의 현실
- 100명 미만 스타트업: DevOps 엔지니어가 혼자 다 함
- 100~500명: SRE + DevOps
- 500+명: SRE + Platform Engineering (분리)
- 대기업: 여러 Platform 팀 (Compute, Data, Security, Frontend)
2부 — Internal Developer Platform (IDP)
2.1 IDP가 제공해야 할 것
개발자가 **"어떻게"를 고민하지 않도록**:
1. **앱 scaffolding**: `platform create service my-api`
2. **로컬 개발 환경**: Devbox, Nix, mise
3. **CI/CD 파이프라인**: 기본 제공
4. **배포**: GitOps 또는 PaaS 인터페이스
5. **모니터링·로그·알림**: 자동 연결
6. **Secret·Config 관리**: Vault·Parameter Store 추상화
7. **DB·Queue provisioning**: Self-service
8. **권한·Role 관리**: IAM 추상화
9. **Cost 가시성**: 팀별·서비스별 비용
10. **Service Catalog**: Backstage
2.2 Platform as a Product 원칙
- **Internal Developer = Customer**
- User Research 수행 (개발자 인터뷰)
- Roadmap·Release Note 공개
- Feedback Loop (Slack, 사용 지표)
- MVP → Iterate
2.3 Minimum Viable Platform (MVP)
처음부터 모든 것을 할 필요 없음:
**우선순위 (Humanitec 통계):**
1. **배포 파이프라인 표준화** (가장 큰 병목)
2. **로컬 개발 환경**
3. **관측성 기본 연결**
4. **권한·Secret 관리**
5. **Service Catalog**
3부 — Backstage: Spotify의 선물
3.1 Backstage란
Spotify가 오픈소스화한 **개발자 포털**. 2024~2025 플랫폼 엔지니어링의 사실상 표준.
**구성:**
- **Software Catalog**: 모든 서비스·라이브러리·팀 목록
- **Software Templates**: 새 서비스 scaffolding
- **TechDocs**: docs-as-code
- **Plugins**: ArgoCD, GitHub, Jira, PagerDuty 등 수백 개
3.2 Catalog 예시
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: "결제 처리 서비스"
tags: [java, critical]
annotations:
github.com/project-slug: mycompany/payment-service
pagerduty.com/service-id: PXXXXXX
spec:
type: service
lifecycle: production
owner: team-payments
system: commerce
dependsOn:
- component:default/auth-service
- resource:default/payment-db
**메타데이터가 한 곳**: 서비스 소유자·문서·알림·의존성 전부 찾을 수 있음.
3.3 Software Template
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: nodejs-service
title: Node.js Microservice
parameters:
- title: Service Info
properties:
name: {type: string}
owner: {type: string, ui:field: OwnerPicker}
steps:
- id: fetch
action: fetch:template
input:
url: ./skeleton
values: {name: {{parameters.name}}}
- id: publish
action: publish:github
input:
repoUrl: github.com?owner=mycompany&repo={{parameters.name}}
- id: register
action: catalog:register
새 서비스 5분 만에 뼈대 + Git + Catalog 등록.
3.4 Backstage의 함정
- **유지보수 부담**: 플러그인 업데이트 빈번
- **React 전문성 필요**: 커스텀 플러그인
- **초기 가치 증명 어려움**: 팀 수 50+ 되기 전엔 ROI 낮음
- **대안**: Port, Cortex, OpsLevel (상용 SaaS)
4부 — GitOps: 배포의 진실은 Git에
4.1 GitOps 4원칙 (OpenGitOps, 2022)
1. **선언적 (Declarative)**: 원하는 상태를 기술
2. **버전 관리 (Versioned)**: Git이 진실의 원천
3. **자동 동기화 (Pulled)**: 에이전트가 Git 감시 + 반영
4. **연속 조정 (Continuously Reconciled)**: 드리프트 자동 교정
4.2 Push vs Pull
**Push (전통 CD)**: CI가 kubectl apply → 보안 위험 (CI에 cluster 권한)
**Pull (GitOps)**: Cluster 내 에이전트가 Git에서 가져옴 → 안전
4.3 ArgoCD vs Flux
| ArgoCD | Flux |
|--------|------|
| UI 강함 | CLI·운영 자동화 강함 |
| 복잡한 의존성 관리 | GitOps 원칙에 충실 |
| 대기업 선호 | Weaveworks 생태계 |
| Helm·Kustomize 지원 | 동일 |
**2025 추천**: 대부분 **ArgoCD**, 극단적 GitOps 순수주의는 **Flux**.
4.4 ArgoCD Application 예시
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app-prod
spec:
project: default
source:
repoURL: https://github.com/mycompany/k8s-manifests
targetRevision: main
path: apps/my-app/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: my-app
syncPolicy:
automated:
prune: true
selfHeal: true
4.5 환경 관리: Kustomize vs Helm
- **Kustomize**: Base + Overlay (patch). 단순, K8s 네이티브
- **Helm**: Templating + 패키징. 강력, 복잡
- **Holos / Timoni**: 2024~ 새 대안 (CUE 기반)
**2025 현실**: Helm이 압도적, 내부 앱은 Kustomize로 전환 추세.
4.6 Progressive Delivery
GitOps + Canary/Blue-Green:
- **Argo Rollouts**: ArgoCD + 트래픽 스플릿
- **Flagger**: Flux + Istio/Linkerd 통합
- **자동 롤백**: 메트릭 악화 감지
5부 — Infrastructure as Code 2025
5.1 IaC 도구 생태계
| 도구 | 특징 |
|-----|-----|
| **Terraform** / **OpenTofu** | 표준, 모든 클라우드 |
| **Pulumi** | TS/Go/Python, 실제 코드 |
| **AWS CDK** | TS/Python, AWS 전용 |
| **Crossplane** | K8s 네이티브 IaC |
| **Kubernetes Operators** | 도메인 특화 |
5.2 Terraform 2024 충격: OpenTofu
HashiCorp BSL 라이선스 변경 → Linux Foundation이 OpenTofu 포크. 2024~ 오픈소스 진영 표준은 OpenTofu로 이동.
5.3 Terraform·OpenTofu 실전 패턴
module "rds" {
source = "terraform-aws-modules/rds/aws"
identifier = "myapp-prod"
engine = "postgres"
engine_version = "16.3"
instance_class = "db.r6g.large"
allocated_storage = 100
db_name = "myapp"
backup_retention_period = 30
tags = {
Environment = "prod"
Owner = "team-payments"
CostCenter = "commerce"
}
}
**모범 사례:**
- 모듈화 (재사용)
- Remote State (S3 + DynamoDB lock)
- Environment separation (dir 또는 workspace)
- Plan → Review → Apply (자동화하되 gate 있게)
- Policy-as-Code (Sentinel, OPA)
5.4 Crossplane — K8s 네이티브 IaC
apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
name: myapp-db
spec:
forProvider:
region: us-west-2
instanceClass: db.r6g.large
engine: postgres
allocatedStorage: 100
**장점**: K8s API로 모든 인프라 관리. GitOps와 완벽 통합.
**단점**: Provider 성숙도는 Terraform보다 떨어짐.
6부 — FinOps: 클라우드 비용 관리
6.1 FinOps Framework 6단계
1. **Inform**: 비용 가시화 (대시보드, 태그)
2. **Allocate**: 팀·프로젝트·서비스별 할당
3. **Optimize**: Right-sizing, Spot, Reserved
4. **Forecast**: 예측 + 예산
5. **Operate**: 일상화 (이상 징후 알림)
6. **Culture**: 엔지니어가 비용을 의식
6.2 2025 FinOps 도구
- **AWS Cost Explorer + CUR**: 네이티브
- **Kubecost**: K8s 비용 가시화
- **OpenCost**: 오픈소스 Kubecost 기반
- **Vantage**: 멀티클라우드 통합
- **CloudZero**: Allocation 강력
- **Harness CCM**: 자동 최적화
6.3 K8s Pod 비용 할당
Pod 비용 = (CPU·메모리 요청 × 노드 단가 × 시간) / 노드 용량
**Kubecost**가 자동 계산. 네임스페이스·Label·어노테이션으로 팀 할당.
6.4 비용 최적화 15가지 (AWS)
1. **Right-sizing**: 과잉 프로비저닝 제거
2. **Spot Instances**: 60~70% 할인
3. **Reserved / Savings Plan**: 1~3년 약정 할인
4. **Graviton (ARM)**: 동일 성능에 20% 저렴
5. **S3 Intelligent-Tiering**: 자동 계층화
6. **S3 Glacier**: 장기 보관
7. **CloudFront 캐싱**: Origin 부하·비용 ↓
8. **RDS Reserved**: 장기 DB 비용 절감
9. **Lambda vs Fargate**: 사용량 패턴별 선택
10. **NAT Gateway 대체**: VPC Endpoint (S3, DynamoDB는 무료)
11. **Log 보존**: 짧게 + S3 아카이브
12. **Unused EIP·EBS·Snapshot 삭제**
13. **Data Transfer 최적화**: 같은 AZ 내 통신 선호
14. **Dev/Staging 야간 종료**: 70% 시간 = 70% 절감
15. **Anomaly Detection**: 비용 급증 즉시 알림
6.5 Showback vs Chargeback
- **Showback**: 팀별 비용 **보여주기만** (영향력 ↓)
- **Chargeback**: 팀 예산에서 **실제 차감** (영향력 ↑, 정치 ↑)
**2025 추천**: Showback부터 시작, 성숙해지면 Chargeback.
7부 — Developer Experience (DX) 측정
7.1 DORA 4 Metrics (Google DevOps Research)
2014년부터 연구된 **고성과 팀의 4가지 지표**:
1. **Deployment Frequency**: 얼마나 자주 배포
2. **Lead Time for Changes**: 커밋에서 프로덕션까지
3. **Change Failure Rate**: 배포 중 장애 비율
4. **Time to Restore**: 장애 복구 시간
**Elite 팀 (2024):** 매일 여러 번 배포, LT < 1시간, CFR < 15%, MTTR < 1시간.
7.2 SPACE Framework (2021)
- **Satisfaction**: 만족도
- **Performance**: 성과
- **Activity**: 활동량
- **Communication**: 협업
- **Efficiency**: 효율
DORA는 Activity·Performance만 → SPACE가 보완.
7.3 DevEx Framework (2023, GitHub + MS)
- **Feedback Loop**: 변경 → 검증 시간
- **Cognitive Load**: 이해해야 할 양
- **Flow State**: 몰입 시간
**설문 + 시스템 지표 결합**이 핵심.
7.4 측정 실전 원칙
- **여러 지표 조합**: 한 지표는 해킹됨
- **팀 단위**: 개인 추적 금지 (감시 vs 개선)
- **설문 + 시스템**: 둘 다
- **결과 공개**: 팀이 직접 개선
7.5 Anti-metric: 절대 추적하면 안 되는 것
- 라인 수
- 커밋 수
- PR 수
- 일한 시간
- "활동량"
→ 모두 조작 가능, Goodhart's Law 적용.
8부 — Golden Path 설계
8.1 Golden Path란
"**가장 쉬운 길이 가장 올바른 길**"이 되게 하는 것.
예: 팀이 새 서비스 만들 때 "Golden Path" 템플릿을 쓰면 자동으로:
- Git 리포 + CI/CD 설정
- 로깅·메트릭·트레이스 자동 연결
- Dockerfile·Helm 차트 포함
- 보안 스캔 파이프라인
- 문서 템플릿
8.2 Path 설계 원칙
1. **No Special Case**: 예외 최소화
2. **Opinionated**: 선택지 적게
3. **Escape Hatch**: 필요하면 벗어날 수 있게
4. **Continuous Improvement**: 월별 개선
8.3 2024~2025 Path 도구
- **Backstage Templates**: 가장 인기
- **Cookiecutter**: Python 생태계
- **Yeoman**: JS 생태계
- **Plop**: 가벼운 ts 생태계
- **Cruft**: Cookiecutter + 업데이트 자동 푸시
9부 — Kubernetes 플랫폼 2025
9.1 관리형 K8s 선택
| 클라우드 | 제품 | 특징 |
|---------|-----|-----|
| AWS | EKS | 가장 성숙, 복잡 |
| GCP | GKE (+ Autopilot) | 자동화 최고 |
| Azure | AKS | MS 통합 |
| 로컬/하이브리드 | kind, k3s, k0s | 소규모 |
9.2 2025 필수 K8s 생태계
- **Helm**: 패키지 매니저
- **Kustomize**: 설정 조합
- **ArgoCD / Flux**: GitOps
- **Cert-Manager**: TLS 자동
- **External-DNS**: DNS 자동
- **External-Secrets**: Vault·KMS 통합
- **Crossplane**: IaC
- **Karpenter**: 노드 오토스케일링
- **KEDA**: 이벤트 기반 오토스케일
- **Istio / Linkerd / Cilium**: Service Mesh
- **OPA Gatekeeper / Kyverno**: 정책
- **Falco / Tetragon**: 런타임 보안
- **Prometheus + Grafana + Loki + Tempo**: 관측성
- **Velero**: 백업
9.3 멀티테넌시 전략
- **Namespace별**: 가장 단순
- **vCluster**: Virtual Cluster
- **Capsule**: 네임스페이스 그룹핑
- **Cluster별**: 완전 격리, 비용 ↑
9.4 K8s가 과하다면
모든 서비스가 K8s에 있을 필요 없음:
- **Fargate / Cloud Run**: Serverless 컨테이너
- **AWS Lambda / Cloudflare Workers**: FaaS
- **Fly.io / Railway**: PaaS (작은 팀)
- **Heroku**: 여전히 유효 (2024 가격 인상으로 매력 ↓)
10부 — Platform Engineer 로드맵 6개월
Month 1: 기초
- Team Topologies 책 읽기
- K8s 심화 (Operator, CRD)
- Helm·Kustomize 숙달
Month 2: GitOps + IaC
- ArgoCD 또는 Flux 실전
- Terraform·OpenTofu 모듈 설계
- Crossplane 체험
Month 3: IDP 설계
- Backstage 설치·커스터마이즈
- Software Template 작성
- 서비스 카탈로그 이전
Month 4: 관측성·보안 통합
- OTEL + Grafana Stack
- Vault + External Secrets
- OPA Gatekeeper 정책
Month 5: FinOps
- Kubecost 또는 OpenCost 도입
- 비용 대시보드
- 월간 FinOps 리뷰
Month 6: DX + 조직
- DORA 지표 수집·공개
- DevEx 설문
- Golden Path 문서화
11부 — Platform Engineering 체크리스트 12
1. **Platform vs SRE vs DevOps** 역할 구분을 안다
2. **Team Topologies 4 팀 유형**을 안다
3. **Platform as a Product** 원칙을 설명할 수 있다
4. **Backstage Catalog·Template** 구조를 안다
5. **GitOps 4원칙**을 말할 수 있다
6. **ArgoCD vs Flux** 선택 기준을 안다
7. **Terraform OpenTofu 전환** 배경을 안다
8. **Crossplane의 의미**를 안다
9. **FinOps 6단계**를 안다
10. **DORA 4 Metrics**를 측정 방법까지 안다
11. **Golden Path 설계 원칙**을 안다
12. **Showback vs Chargeback** 차이를 안다
12부 — Platform 안티패턴 10
1. **Platform을 "내부 인프라 팀" 취급**: 제품 마인드셋 없음
2. **개발자 설문 없이 기능 결정**: 추측으로 빌드
3. **너무 많은 선택지 제공**: Golden Path 실종
4. **탈출 불가 플랫폼**: 벗어날 수 없으면 반발
5. **지나친 추상화**: Kubernetes를 숨기려다 오히려 복잡
6. **Backstage를 허드슨 대체로만**: Catalog·Template 없이 쓰면 ROI 낮음
7. **CI/CD만 표준화**: 로컬 개발·관측·보안 표준 없음
8. **DORA만 측정**: 개발자 만족도·Cognitive Load 무시
9. **비용 가시성 없음**: 엔지니어가 비용 감각 0
10. **"한 번 구축하면 끝"**: 지속 개선 문화 없음
마치며 — 플랫폼은 "지렛대"다
하나의 Golden Path가 잘 만들어지면 200명의 엔지니어가 그 위에서 뛴다. 그것이 **레버리지의 핵심**.
하지만 플랫폼은:
- **제품 마인드셋 없이는** 방치되는 내부 도구로 전락
- **개발자 공감 없이는** 관료주의로 전락
- **지속 개선 없이는** 기술 부채로 전락
2025년의 플랫폼 엔지니어는 **"인프라 엔지니어 + 제품 매니저 + 교육자"** 3역.
다음 글 예고 — "분산 시스템 완전 가이드: 시계·Consensus·이벤트 소싱·사가·CRDT·장애 패턴"
Season 2 Ep 12는 분산의 본질, **분산 시스템 심화**. 다음 글은:
- Lamport Clock, Vector Clock, HLC
- Raft, Paxos, PBFT 실전
- Event Sourcing + CQRS
- Saga 패턴 (Choreography vs Orchestration)
- CRDT (Conflict-free Replicated Data Type)
- 8 Fallacies of Distributed Computing
Byzantine Fault까지 포함한 분산의 진짜 얼굴, 다음 글에서.
현재 단락 (1/339)
2023~2025년 가장 빠르게 성장하는 엔지니어링 역할: **Platform Engineer**.