Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
필사 모드
Authors

들어가며 — 왜 "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와의 차이

SREPlatform Engineer
신뢰성 중심생산성 중심
SLO·Error BudgetDORA·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

ArgoCDFlux
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표준, 모든 클라우드
PulumiTS/Go/Python, 실제 코드
AWS CDKTS/Python, AWS 전용
CrossplaneK8s 네이티브 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 선택

클라우드제품특징
AWSEKS가장 성숙, 복잡
GCPGKE (+ Autopilot)자동화 최고
AzureAKSMS 통합
로컬/하이브리드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까지 포함한 분산의 진짜 얼굴, 다음 글에서.

Discuss on Twitter • View on GitHub