TT Lab
요금제

한국어

시작하기
블로그

블로그

플랫폼 엔지니어링과 Developer Experience — Backstage·IDP·GitOps·Operator·Score·Dagger·Nix·Remote Dev Env·DORA·SPACE 심층 가이드 (2025)

2026-04-15 · 21 분 읽기 · #platform-engineering#backstage#idp#gitops#kubernetes#dagger#nix#dora#space#dx

왜 2025년의 조직은 "플랫폼 팀"을 당연히 둘까

10년 전 DevOps의 구호는 "You build it, you run it"이었다. 팀이 개발과 운영을 모두 하자는 것. 이상은 훌륭했지만 현실은 달랐다 — 한 팀이 Kubernetes·Terraform·CI/CD·관측가능성·보안 전부를 다루는 건 불가능이다. 대부분 팀의 절반 이상 시간이 인프라 보일러플레이트에 빠졌다. 이 딜레마의 해답이 Platform Engineering이다. "전담 플랫폼 팀이 내부 제품을 만들어, 프로덕트 팀에게 셀프 서비스로 제공한다"는 조직 모델.

2022년 Gartner Hype Cycle에서 Platform Engineering이 빠르게 올라갔고, 2024~2025년 "Peak of Inflated Expectations"을 지나 실용 단계로 진입했다. Puppet 2024 State of DevOps Report는 조직의 72%가 플랫폼 팀을 보유한다고 응답. Team Topologies 책(Matthew Skelton/Manuel Pais)이 이 흐름의 이론적 기반이 되었고, CNCF의 platforms.cncf.io 백서가 용어를 통일했다.

이 글은 그 2025년 플랫폼의 구성 요소·툴·지표·안티패턴을 전부 훑는다.

이 글은 앞선 관측가능성 가이드의 연속이다. 관측을 쉽게 붙이고, 인프라를 쉽게 프로비저닝하고, 반복을 플랫폼이 해주는 것 — 그것이 플랫폼 엔지니어링.

1부. DevOps → Platform Engineering — 조직론의 대전환

1.1 Team Topologies의 4가지 팀 유형

핵심 인사이트: Cognitive Load(인지 부담). 스트림 팀이 다룰 수 있는 복잡도에는 한계가 있고, 그걸 넘는 건 플랫폼·Enabling 팀이 흡수해야 팀이 질식 안 함.

1.2 Platform as a Product

플랫폼은 내부 고객(다른 엔지니어)을 가진 제품이다. 그래서 PM, UX 리서처, 로드맵, NPS(내부 고객 만족도) 조사가 필요하다. "인프라 팀이 티켓 받아 처리"가 아니라 "내부 제품팀이 self-service API를 빌드"하는 것.

1.3 Spotify·Netflix·Uber의 원형

이들이 "플랫폼 엔지니어링"을 구체화했고, 2024~2025년 중견 기업까지 확산됐다.

2부. Internal Developer Platform (IDP) — 한 포털로 다 해결

2.1 IDP의 구성 요소

CNCF 백서의 5개 평면 모델.

  1. Developer Control Plane — 포털 UI, CLI, API
  2. Integration and Delivery Plane — CI/CD, IaC
  3. Monitoring and Logging Plane — 관측가능성(앞 글)
  4. Security Plane — Secrets, RBAC, Policy
  5. Resource Plane — Kubernetes, DB, 메시지 큐, CDN

2.2 Backstage — 포털 표준

Spotify가 기부, CNCF 인큐베이팅. 핵심 개념 3가지.

2024~2025 추가된 것: Backstage RBAC(Permission Framework), Search/Discovery GA, TechInsights (Scorecards), AI-assisted Catalog Curation.

2.3 Golden Path와 Paved Road

"가장 쉬운 길 = 가장 올바른 길"로 만드는 원칙. 새 서비스를 만들 때 Backstage 템플릿을 선택하면 자동으로:

→ 개발자는 비즈니스 로직만 쓰면 된다. 표준을 강제하는 대신 쉽게.

2.4 Scorecards — 서비스의 건강 지표

각 팀이 자기 서비스의 스코어를 한눈에 본다. Backstage TechInsights, Cortex, OpsLevel, Atlassian Compass가 이 카테고리.

3부. GitOps — Git이 진실의 유일한 원천

3.1 원리

3.2 ArgoCD vs Flux

3.3 Crossplane — 인프라도 Kubernetes API로

AWS S3, GCP Cloud SQL, Azure Storage 같은 클라우드 리소스를 CRD로 표현. 즉 "YAML로 RDS 만들기". Terraform을 보완·대체하는 흐름.

apiVersion: database.example.com/v1alpha1
kind: PostgresInstance
metadata: { name: user-db }
spec:
  region: us-east-1
  size: db.t4g.medium
  version: "16"

3.4 Progressive Delivery — Argo Rollouts / Flagger

3.5 Helm vs Kustomize vs Timoni vs KCL

2024~2025 트렌드: "Helm + Kustomize 혼용 지친 팀들이 Timoni/KCL 탐색".

4부. Kubernetes Operator — 도메인 지식을 자동화

4.1 CRD + Controller = Operator

4.2 유명 Operator

4.3 Operator SDK vs Kubebuilder

4.4 Operator 작성 팁

5부. Platform Abstraction의 새 물결 — Score, Humanitec, Kratix

5.1 문제

Kubernetes YAML은 개발자가 쓰기에 너무 저수준. "내 서비스에 Postgres DB 붙여줘"라는 의도만 표현하고 싶다.

5.2 Score (score.dev)

Humanitec+CNCF. 플랫폼 중립 워크로드 스펙.

apiVersion: score.dev/v1b1
metadata: { name: my-app }
containers:
  main:
    image: myorg/app:latest
    variables:
      DB_URL: $${resources.db.url}
resources:
  db:
    type: postgres

CI에서 score-compose·score-k8s로 목적 환경별 매니페스트로 컴파일.

5.3 Humanitec

Score를 포함한 상용 Internal Developer Platform 빌더. Platform Orchestrator가 환경별 resource(Postgres, Redis 등)를 동적으로 그래프 만들어 생성.

5.4 Kratix

영국 Syntasso 제작. "Promises"라는 추상화로 플랫폼 팀이 서비스형 API를 게시.

5.5 Port, Mia-Platform, Cortex

상용 IDP 빌더들. Port는 Backstage와 다르게 "스키마 중심" 접근. Mia는 유럽계, 금융권 강세. Cortex는 Scorecard 특화.

6부. 재현 가능한 빌드 — Dagger, Nix, Bazel, Buildpacks

6.1 왜 재현성인가

6.2 Dagger — 코드로 CI

6.3 Nix / NixOS

6.4 Bazel / Buck2 / Pants

6.5 Buildpacks (CNB)

6.6 SBOM + SLSA

7부. Remote Dev Environment — 노트북에서 벗어나기

7.1 문제

7.2 GitHub Codespaces

7.3 Gitpod (Cloud → Self-hosted)

2024년 SaaS 중단·OSS(Flex) 집중. 기업 자체 호스팅으로 선회. 보안 민감 조직(금융·의료)에서 인기.

7.4 Coder

7.5 JetBrains Space / Fleet, Replit, Cursor, GitHub Copilot Workspace

각자 다른 각도로 접근. Cursor는 2024 $9B 평가로 IDE + AI 통합의 대세가 됨. GitHub은 Copilot Workspace로 "이슈 → PR까지 AI가" 시도.

7.6 선택 기준

8부. 시크릿·폴리시·보안

8.1 Secret Management

8.2 Policy as Code

8.3 RBAC과 Zero-Trust

8.4 Supply Chain

9부. AI + Platform Engineering

9.1 Copilot Workspace·Cursor Agent·Claude Code

9.2 AI 기반 Incident Response

9.3 AI Platform의 표준화

9.4 Platform Engineering과 MLOps 통합

10부. DX 지표 — DORA, SPACE, DX Core 4

10.1 DORA 4 metrics (2019~)

Nicole Forsgren의 "Accelerate" 기반.

Elite팀은 하루 수십번 배포, 분 단위 회복. 측정 단순하고 설득력 강함.

10.2 SPACE Framework (Microsoft, 2021)

DORA가 놓친 "사람" 측면.

Developer Experience를 다차원으로 본다.

10.3 DX Core 4 (2024, Abi Noda)

GetDX 팀이 제안한 최신 합의. DORA+SPACE를 간결히 융합.

10.4 측정 도구

주의: 지표를 개인 KPI로 쓰면 Goodhart's Law 발동. 팀·조직 수준 트렌드로만 써야 함.

11부. FinOps — 누구나 신경 안 쓰는 플랫폼의 비용

11.1 클라우드 비용이 문제가 되는 시점

11.2 도구들

11.3 비용 절감 패턴

11.4 플랫폼 팀이 해야 할 일

12부. 플랫폼 조직 설계 — 실전

12.1 팀 크기

12.2 플랫폼 팀 RACI

12.3 Platform Product Manager

필수 포지션. 기능 요청 큐 관리, 로드맵, 내부 사용자 인터뷰, NPS. 없는 팀은 "엔지니어가 좋아하는 기능"만 만들고 실제 필요에 어긋나기 쉬움.

12.4 Enabling Team

플랫폼이 아직 없거나, 새 기술(예: AI/ML 도입)에 한시적으로 투입되어 스트림 팀을 학습시키고 패턴을 만든 뒤 해산·재배치.

13부. 실패 패턴 — 플랫폼 팀이 망하는 10가지

  1. 플랫폼을 기술 프로젝트로 취급 — 제품이 아님
  2. 내부 고객 인터뷰 없이 만든 기능
  3. 강제(mandate) 일변도 — Golden Path가 실제로 더 편해야 채택됨
  4. 문서가 없음 — DX 망함
  5. 플랫폼 팀이 처리팀(티켓 대응)화
  6. 실력 있는 시니어만 플랫폼 팀에 몰림 → 스트림 팀 속도 저하
  7. K8s everything — 단순 앱도 K8s에 올려 복잡도 폭발
  8. 추상화 과다 — 디버깅이 3겹 깊어짐
  9. 지표가 활동 중심(커밋 수, 티켓 수) — 성과 중심 아님
  10. 비용 가시성 부재 — 경영진 신뢰 잃음

14부. 체크리스트 12 · 안티패턴 10

✅ 체크리스트 12

  1. Backstage(또는 유사 포털) 서비스 카탈로그가 최신인가?
  2. Golden Path 템플릿이 있고, 신규 서비스의 70% 이상이 이걸로 시작하는가?
  3. Scorecard로 서비스 건강도가 가시화되는가?
  4. GitOps로 프로덕션 변경이 Git에 기록되는가?
  5. Progressive Delivery(Canary/Blue-Green)가 기본인가?
  6. 인프라 resource(DB, Redis 등)가 self-service로 프로비저닝되는가?
  7. 시크릿 관리 표준(Vault/External Secrets)이 강제되는가?
  8. SBOM + 서명이 모든 artifact에 붙는가?
  9. Remote Dev Environment가 있어 5분 안에 온보딩 가능한가?
  10. DORA 4 + DX Core 4가 분기별 측정되는가?
  11. FinOps 대시보드로 팀·서비스별 비용이 보이는가?
  12. Platform Product Manager가 로드맵/NPS를 관리하는가?

⚠️ 안티패턴 10

  1. "You build it, you run it"을 플랫폼 지원 없이 교조적으로 밀어붙임
  2. Backstage만 깔고 실제 통합은 안 함
  3. Terraform 레포가 전 직원에게 open, 무질서한 drift
  4. 한 팀이 Kubernetes·Vault·Terraform을 모두 직접 운용
  5. CI가 평균 30분 넘음 — 플랫폼 개선 순위 밀림
  6. Dev/Stage/Prod 환경이 설정 drift
  7. Paved Road가 실제로 더 불편 — 팀들이 우회
  8. 시크릿을 환경변수·Git에 평문
  9. 플랫폼 리포지토리에 프로덕트 팀 PR 금지 → 플랫폼이 병목
  10. DORA/DX 지표를 개인 평가에 연결

다음 글 예고 — "데이터 플랫폼의 현대" — Lakehouse·Iceberg·dbt·Airflow/Dagster·Spark·Flink·DuckDB·ClickHouse·Snowflake·Databricks·BigQuery·AI 시대의 데이터 계약

플랫폼 엔지니어링 옆자리에는 언제나 데이터 플랫폼이 있다. 다음 글은 2025년 데이터 스택의 지형을 그린다.

플랫폼이 애플리케이션을 굴린다면, 데이터 플랫폼은 의사결정의 기반을 굴린다. 다음 편에서 만난다.

로그인하면 좋아요를 누를 수 있습니다

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다