✍️ 필사 모드: 플랫폼 엔지니어링 완전 가이드 — IDP·GitOps·Backstage·Cost·DX (Season 2 Ep 11, 2025)

들어가며 — 왜 "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가 경험을 담당. 큰 조직은 둘 다 존재.

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

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 도구 생태계

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 선택

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까지 포함한 분산의 진짜 얼굴, 다음 글에서.