TT Lab
요금제

한국어 English 日本語

시작하기
블로그

블로그

플랫폼 엔지니어링 & IDP 2026 완벽 가이드 - Backstage · Port · Cortex · Humanitec · Crossplane · ArgoCD · Pulumi · Terraform · OpenTofu 심층 분석

2026-05-16 · 38 분 읽기 · #platform-engineering#idp#backstage#port#cortex#opslevel#humanitec#crossplane#argocd#pulumi#terraform#opentofu#devex#gitops#devops

대화로 듣기 · 9분두 사람이 이 글을 풀어 줍니다

프롤로그 — 2026년, "플랫폼 팀"은 더 이상 농담이 아니다

2018년까지 "플랫폼 엔지니어링"은 모호한 단어였다. Kubernetes 운영자, SRE, DevOps, 인프라팀 — 누가 어디까지 책임지는지 아무도 몰랐다.

2026년에는 답이 거의 정해졌다.

이 글은 2026년의 플랫폼 엔지니어링 스택을 처음부터 끝까지 정리한다. IDP·GitOps·IaC·CI/CD·Dev Environment·Service Mesh·Secrets·Policy까지 — 그리고 그 사이에서 "어떤 도구를 어떤 단계에서 쓸지" 결정하는 매트릭스까지.

1장 · Platform Engineering vs DevOps — 무엇이 달라졌나

"플랫폼 엔지니어링은 그냥 DevOps 아니냐"는 질문에 대한 2026년의 답은 명확하다.

이 차이가 만든 가장 큰 변화는 인지 부하(cognitive load)의 재분배다. 2010년대의 "You Build It, You Run It"은 좋은 슬로건이었지만, 마이크로서비스가 늘어나면서 모든 팀이 Kubernetes·Terraform·Vault·OPA·ArgoCD를 다 알아야 하는 부담이 됐다. 2026년의 플랫폼 팀은 그 인지 부하를 흡수해서, 스트림 팀에게는 "버튼 한 번"으로 보이게 만든다.

기억할 한 줄: "Platform Engineering은 Platform-as-a-Product다. 내부 개발자가 고객이고, NPS·DevEx 점수가 KPI다."

2장 · Team Topologies — 4가지 팀과 3가지 상호작용

Matthew Skelton과 Manuel Pais가 2019년에 쓴 "Team Topologies"는 2026년에 사실상 표준 어휘가 됐다. 4가지 팀 유형:

  1. Stream-aligned team — 가치 흐름(value stream)에 정렬된 팀. 제품·기능 단위로 책임을 진다.
  2. Platform team — 다른 팀의 인지 부하를 줄여주는 내부 서비스 제공자. IDP를 만든다.
  3. Enabling team — 일정 기간 다른 팀에 합류해서 역량을 키워주는 컨설팅성 팀. (예: SRE Enabling)
  4. Complicated-subsystem team — 깊은 전문성이 필요한 서브시스템(예: 결제 도메인, ML 추론) 전담 팀.

그리고 3가지 상호작용 모드:

플랫폼 팀의 일상은 X-as-a-Service의 품질을 높이는 것이다. 셀프 서비스가 막히면 Collaboration으로 잠깐 돌아가고, 역량 격차가 보이면 Enabling으로 옮긴다.

3장 · Golden Path & Paved Road — 개발자 경험의 핵심 은유

Spotify가 2020년 R&D 블로그에 정리한 "Golden Path"는 2026년 플랫폼 팀의 표준 약속이 됐다.

Netflix·Stripe가 쓰는 비슷한 표현이 "Paved Road"다. 콘크리트로 포장된 길 = 황금 길. 흙길로 가도 되지만, 비 오면 진흙탕에 빠진다.

플랫폼 팀의 첫 번째 산출물은 거의 항상 "Golden Path 정의서"다. 어떤 언어·런타임·DB·CI·배포 방식이 1급 시민인가? 그 정의가 IDP의 템플릿이 되고, OPA 정책이 되고, Backstage Software Template이 된다.

4장 · IDP 4분할 — Backstage · Port · Cortex · OpsLevel · Humanitec

2026년 IDP 시장은 크게 4사분면으로 나뉜다.

IDP모델호스팅강점약점
Backstage (Spotify, CNCF)오픈소스 프레임워크셀프호스팅무료, 플러그인, TechDocs, Software Templates셀프호스팅 운영 부담, 초기 셋업 길다
PortSaaS, Blueprint 모델SaaS빠른 시작, 셀프서비스 액션, GitOps락인 위험, 가격
CortexSaaS, Service Catalog 중심SaaS서비스 점수(Scorecards), 온콜 통합UI 학습 곡선
OpsLevelSaaS, Service MaturitySaaS서비스 성숙도 측정, 통합 다양한국 진출 약함
HumanitecSaaS, Score 워크로드 추상화SaaSDynamic Config Management, Score 표준카탈로그보다 워크로드 중심

선택 기준은 단순하다.

5장 · Backstage — Spotify가 CNCF에 기증한 오픈소스 IDP

Spotify는 2016년에 Backstage를 사내에 만들었고, 2020년에 오픈소스화했고, 2022년에 CNCF에 기증했다. 2026년 5월 기준 1.40대가 안정 버전이고, 다음 핵심 개념을 제공한다.

가장 작은 catalog-info.yaml 예시.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-service
  description: Handles checkout flow for storefront
  annotations:
    github.com/project-slug: acme/checkout-service
    backstage.io/techdocs-ref: dir:.
    argocd/app-name: checkout-service-prod
  tags:
    - golang
    - payments
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: storefront
  providesApis:
    - checkout-api
  dependsOn:
    - resource:postgres-checkout
    - component:kafka-orders

Software Template 예시 (스캐폴딩).

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: golang-grpc-service
  title: Golang gRPC Microservice
spec:
  owner: team-platform
  type: service
  parameters:
    - title: Basics
      required: [name, owner]
      properties:
        name:
          type: string
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch
      name: Fetch skeleton
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: $|parameters.name|
          owner: $|parameters.owner|
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=acme&repo=$|parameters.name|
    - id: register
      name: Register in catalog
      action: catalog:register
      input:
        repoContentsUrl: $|steps.publish.output.repoContentsUrl|
        catalogInfoPath: /catalog-info.yaml

Backstage의 진가는 플러그인 생태계다. ArgoCD 플러그인은 카탈로그 페이지에서 배포 상태를 보여주고, Cost Insights는 AWS/GCP 비용을 서비스별로 쪼개고, Kubernetes 플러그인은 Pod·Deployment 상태를 실시간으로 보여준다.

6장 · Port — Blueprint 모델과 셀프서비스 액션

Port(getport.io)는 2022년에 등장해서 2024~2026년에 빠르게 성장한 SaaS IDP다. Backstage가 "프레임워크"라면, Port는 "완성품"에 가깝다.

핵심 개념은 Blueprint다. 엔터티의 스키마를 JSON Schema로 정의하고, 그 인스턴스를 자동으로 채운다. 예를 들어 "Service" Blueprint를 정의하면 GitHub·ArgoCD·Datadog·PagerDuty에서 데이터를 끌어와 자동으로 채워준다.

두 번째 강점은 Self-Service Actions다. "새 마이크로서비스 만들기", "DB 백업 복원", "스테이징 환경 띄우기" — 이런 작업을 버튼 한 번으로 실행 가능하게 만든다. 백엔드는 GitHub Actions, Jenkins, ArgoCD Workflow 등 무엇이든 연결할 수 있다.

Backstage와 Port의 비교가 자주 묻는 질문이다.

7장 · Cortex & OpsLevel — Service Scorecards와 성숙도

Cortex(cortex.io)와 OpsLevel(opslevel.com)은 서비스 카탈로그를 넘어 서비스 성숙도를 점수화하는 데 강점이 있다.

스코어카드의 가치는 거버넌스다. 보안팀이 "모든 서비스는 SAST·SCA·SBOM·런타임 보안이 통과해야 한다"는 규칙을 카드로 만들면, 각 서비스 오너가 자기 점수를 자기 화면에서 본다. 강제하지는 않지만 가시화한다.

한국 시장에서는 Backstage·Port가 강하고, Cortex·OpsLevel은 외국계 핀테크·스타트업에서 주로 쓰인다.

8장 · Humanitec & Score — 워크로드 추상화의 새 표준

Humanitec(humanitec.com)은 다른 IDP와 결이 좀 다르다. 카탈로그보다 워크로드 추상화와 동적 환경 구성에 집중한다.

핵심은 Score(score.dev)라는 워크로드 명세 표준이다. 개발자가 작성하는 score.yaml은 환경에 중립적이다 — Kubernetes·ECS·Nomad 어디서든 같은 스펙을 쓰고, 플랫폼 팀이 정의한 매니페스트 생성기가 환경별로 변환한다.

Score 명세 예시.

apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  orders:
    image: ghcr.io/acme/orders:1.2.3
    variables:
      DATABASE_URL: ${resources.db.connection}
      REDIS_URL: ${resources.cache.connection}
    resources:
      requests:
        memory: 256Mi
        cpu: 200m
service:
  ports:
    http:
      port: 80
      targetPort: 8080
resources:
  db:
    type: postgres
  cache:
    type: redis
  dns:
    type: dns

이 한 파일이 Humanitec의 Dynamic Config Management를 통해 환경별로 다른 Kubernetes·Terraform 매니페스트가 된다. 개발 환경에서는 SQLite로 떨어지고, 프로덕션에서는 Aurora로 풀린다.

Score는 CNCF Sandbox 프로젝트로 들어가서 표준화되고 있고, Backstage·Port와도 통합된다.

9장 · Crossplane — Kubernetes를 IaC 컨트롤 플레인으로

Crossplane(crossplane.io)은 2018년에 Upbound가 시작해서 2020년에 CNCF에 기증한, Kubernetes를 클라우드 리소스의 컨트롤 플레인으로 만드는 프로젝트다.

핵심 아이디어는 단순하다. AWS RDS, GCP Cloud SQL, Azure Database — 이런 클라우드 리소스를 Kubernetes CRD(Custom Resource Definition)로 표현하고, kubectl로 관리한다. Terraform 대신 Kubernetes 그 자체가 IaC 도구가 된다.

가장 강력한 기능은 Composition이다. 여러 리소스를 묶어서 XRD(Composite Resource Definition)로 추상화한다. 예를 들어 "MySQLCluster" XRD를 정의하면, 내부적으로 RDS 인스턴스 + 서브넷 그룹 + 보안 그룹 + IAM 역할을 묶어서 한 번에 만든다.

XRD 예시.

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresclusters.platform.acme.io
spec:
  group: platform.acme.io
  names:
    kind: XPostgresCluster
    plural: xpostgresclusters
  claimNames:
    kind: PostgresCluster
    plural: postgresclusters
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    storageGB:
                      type: integer
                    instanceClass:
                      type: string
                  required: [storageGB, instanceClass]

개발자는 이렇게 청구한다.

apiVersion: platform.acme.io/v1alpha1
kind: PostgresCluster
metadata:
  name: orders-db
spec:
  parameters:
    storageGB: 100
    instanceClass: db.t4g.medium

Crossplane의 약점은 학습 곡선이 가파르다는 것이다. XRD·Composition·Function·Pipeline까지 — Terraform 한 줄로 끝낼 일을 여러 레이어로 만든다. 그러나 플랫폼 팀이 Composition을 한 번 잘 정의하면, 개발자는 5줄짜리 YAML로 RDS·VPC·IAM을 동시에 청구할 수 있다.

10장 · ArgoCD — GitOps 표준의 대표주자

ArgoCD(argo-cd.readthedocs.io)는 2018년 Intuit가 만들어 2020년에 CNCF에 기증했고, 2026년 기준 v3.x가 안정 버전이며 사실상의 GitOps 표준이다.

핵심 모델은 단순하다.

Application 매니페스트.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout-prod
  namespace: argocd
spec:
  project: storefront
  source:
    repoURL: https://github.com/acme/manifests
    targetRevision: HEAD
    path: apps/checkout/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: checkout-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 10s
        factor: 2
        maxDuration: 3m

수십~수백 개의 마이크로서비스를 다룰 때는 ApplicationSet이 유용하다. 한 템플릿으로 여러 Application을 자동 생성한다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: services-prod
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/acme/manifests
        revision: HEAD
        directories:
          - path: apps/*/overlays/prod
  template:
    metadata:
      name: '{{path.basename}}-prod'
    spec:
      project: storefront
      source:
        repoURL: https://github.com/acme/manifests
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}-prod'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ArgoCD의 동료 도구로는 Argo Rollouts(Blue/Green, Canary), Argo Workflows(워크플로우 엔진), Argo Events(이벤트 트리거)가 있다. 합쳐서 "Argo 패밀리"라고 부른다.

11장 · Flux — GitOps의 또 다른 표준

Flux(fluxcd.io)는 Weaveworks가 2016년에 만들어 CNCF에 기증한, ArgoCD의 가장 큰 경쟁자다. 2026년 v2.x가 안정 버전이다.

ArgoCD와 Flux의 차이.

대규모 멀티 클러스터 환경에서는 Flux가 더 가볍게 도는 경향이 있고, UI/UX와 RBAC을 중시하면 ArgoCD가 유리하다. 한국에서는 ArgoCD가 압도적으로 많이 쓰이고, 글로벌 인프라 회사(Weaveworks 영향권)에서는 Flux도 종종 보인다.

12장 · Pulumi · Terraform · OpenTofu — IaC 트로이카

IaC 시장은 2026년에 3강 구도로 정리됐다.

IaC언어라이선스강점약점
Terraform (HashiCorp)HCLBSL 1.1 (비오픈)가장 성숙, 모듈 생태계라이선스 변경 후 OSS 진영 이탈
OpenTofu (Linux Foundation)HCL (Terraform 호환)MPL 2.0 (오픈)진짜 오픈소스, Terraform 마이그레이션 쉬움후발, 일부 신기능은 늦음
PulumiTS/Python/Go/C#/JavaApache 2.0진짜 프로그래밍 언어, IDE 지원코드 표준 차이, 추상화 비용

2023년 HashiCorp가 Terraform 라이선스를 BSL로 바꾼 이후 OpenTofu가 갈라져 나왔다. 2026년에는 OpenTofu가 v1.10대에 들어서면서 Terraform과의 호환성이 거의 100%에 가깝다. 새 프로젝트에서는 OpenTofu를 쓰고, 기존 Terraform 워크스페이스를 그대로 옮기는 회사가 늘었다.

Pulumi의 강점은 진짜 프로그래밍 언어로 인프라를 쓴다는 것이다. 반복문·조건문·테스트가 자연스럽다. 단점은 팀 표준을 잡기가 어렵다는 것 — HCL은 "이렇게 쓰는 게 맞다"가 있지만, TypeScript로 쓰면 100가지 방식이 나온다.

OpenTofu 샘플 — RDS + 서브넷 그룹 + 보안 그룹.

terraform {
  required_version = ">= 1.10"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
  backend "s3" {
    bucket = "acme-tfstate"
    key    = "rds/prod.tfstate"
    region = "ap-northeast-2"
  }
}

resource "aws_db_subnet_group" "this" {
  name       = "orders-prod"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "db" {
  name   = "orders-prod-db"
  vpc_id = var.vpc_id
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = var.app_sg_ids
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "orders" {
  identifier             = "orders-prod"
  engine                 = "postgres"
  engine_version         = "16.4"
  instance_class         = "db.r6g.large"
  allocated_storage      = 100
  storage_encrypted      = true
  username               = "ordersadmin"
  manage_master_user_password = true
  db_subnet_group_name   = aws_db_subnet_group.this.name
  vpc_security_group_ids = [aws_security_group.db.id]
  multi_az               = true
  backup_retention_period = 14
  deletion_protection    = true
}

같은 일을 Pulumi TypeScript로 쓰면 이렇다.

import * as aws from '@pulumi/aws'

const subnetGroup = new aws.rds.SubnetGroup('orders-prod', {
  subnetIds: privateSubnetIds,
})

const dbSg = new aws.ec2.SecurityGroup('orders-prod-db', {
  vpcId: vpcId,
  ingress: [
    {
      fromPort: 5432,
      toPort: 5432,
      protocol: 'tcp',
      securityGroups: appSgIds,
    },
  ],
  egress: [{ fromPort: 0, toPort: 0, protocol: '-1', cidrBlocks: ['0.0.0.0/0'] }],
})

const orders = new aws.rds.Instance('orders', {
  identifier: 'orders-prod',
  engine: 'postgres',
  engineVersion: '16.4',
  instanceClass: 'db.r6g.large',
  allocatedStorage: 100,
  storageEncrypted: true,
  username: 'ordersadmin',
  manageMasterUserPassword: true,
  dbSubnetGroupName: subnetGroup.name,
  vpcSecurityGroupIds: [dbSg.id],
  multiAz: true,
  backupRetentionPeriod: 14,
  deletionProtection: true,
})

13장 · Atlantis · Spacelift · env0 · Terraform Cloud — IaC 협업 자동화

IaC 코드를 PR에서 자동으로 plan/apply하는 협업 도구도 시장이 분명해졌다.

2026년 트렌드는 Atlantis(무료) + 자체 OPA + 자체 드리프트 또는 Spacelift/env0(SaaS) 둘 중 하나로 양분됐다. Terraform Cloud는 라이선스 이슈 이후 점유율이 다소 빠졌다.

14장 · CI/CD — GitHub Actions · GitLab CI/CD · Buildkite · CircleCI · Harness

CI/CD 시장도 2026년에 정리가 됐다.

한국에서는 Toss·Naver·카카오 등이 자체 빌드 시스템 위에 GitHub Actions를 결합하는 패턴이 보편적이다. Coupang은 자체 Buildkite 변형을 쓴다는 보고가 있다.

15장 · Earthly · Bazel · Nx · Turborepo — 빌드 시스템과 모노레포

CI의 위/아래에 있는 빌드 도구도 진화했다.

2026년에는 Bazel은 거대 모노레포(Google, Uber, Spotify), Nx/Turborepo는 JS/TS 모노레포, Earthly는 Polyglot CI 통일이라는 그림으로 갈렸다.

16장 · Devbox · Devpod · Coder · Gitpod · Codespaces · Daytona — 개발 환경

"맥북에서만 빌드되는 코드"의 문제는 2026년에 거의 해결됐다. 개발 환경을 그 자체로 코드로 만든다.

기업에서 가장 자주 쓰이는 조합은 Codespaces(소형 팀) / Coder(중대형 팀, 셀프호스팅) / Devbox 또는 Nix(로컬 결정론) 셋이다.

17장 · Nix · NixOS · Devenv — 결정론적 환경의 끝판

Nix는 2003년부터 있었지만 2026년에 와서야 진짜로 대중화되기 시작했다. 핵심 약속은 "같은 입력에는 같은 출력" — 빌드와 환경이 완전히 결정론적이다.

학습 곡선은 여전히 가파르지만, 한 번 익히면 "이 프로젝트는 macOS·Linux 어디서든 똑같이 빌드된다"는 보장이 따라온다. Determinate Systems가 도입한 Nix Installer가 이 진입 장벽을 크게 낮췄다.

18장 · Container-Native — Docker Build Cloud · BuildKit · Podman · Nerdctl

컨테이너 도구도 2026년에 분화됐다.

기업 정책 측면에서는 Docker Desktop의 라이선스 정책 변경 → Podman/Finch/Rancher Desktop으로 이주가 2024~2026년에 광범위하게 일어났다.

19장 · Service Mesh — Istio · Linkerd · Cilium · Consul Connect

Service Mesh 시장도 정리가 됐다.

Mesh데이터 플레인강점약점
IstioEnvoy기능 풍부, 표준 (Ambient Mode 안정화)복잡성, 운영 부담
LinkerdLinkerd2-proxy (Rust)단순, 빠름, 메모리 가벼움기능 폭 좁음
Cilium Service MesheBPF + Envoy사이드카 없음, CNI와 통합eBPF 의존, 커널 요구
Consul ConnectEnvoyMulti-cloud, VM도 지원Kubernetes-native 약함

2024년 Istio Ambient Mode가 GA 되면서, 사이드카 없는 메시가 본격화됐다. 2026년에는 Istio Ambient + Cilium의 조합이 늘었다. Linkerd는 단순함이 매력이라 중소 클러스터에서 여전히 인기다.

20장 · Secrets — Vault · Doppler · Infisical · External Secrets Operator

비밀 관리도 2026년에 정리됐다.

핵심 패턴은 "Vault/AWS SM/GCP SM 등의 외부 스토어 + ESO + 워크로드는 K8s Secret 또는 환경변수로 받음"이다. 2026년에는 SOPS + Age 조합도 GitOps 친화로 인기다.

21장 · Policy-as-Code — OPA Gatekeeper · Kyverno · Conftest · Checkov · tfsec

정책을 코드로 표현하는 도구도 분야별로 정리됐다.

2026년 표준 조합은 Kyverno(런타임 정책) + Checkov 또는 tfsec(IaC 정적 분석) + Conftest(임의 파일)다. OPA Gatekeeper는 표준이지만 Rego의 진입장벽 때문에 신규 도입은 Kyverno로 많이 옮겨갔다.

22장 · DORA · SPACE · DevEx — 개발자 생산성 측정의 3대 프레임워크

Nicole Forsgren의 "Accelerate"(2018)에서 출발한 DORA Metrics는 2026년에 사실상 표준이다.

플랫폼 팀의 KPI는 점점 이 셋의 조합으로 정의된다. Backstage Cost Insights가 DORA 메트릭을 자동 수집하는 플러그인을 제공하고, GetDX(getdx.com)는 SPACE/DevEx 설문을 자동화하는 SaaS다.

기억할 한 줄: "DORA는 시스템을 보고, SPACE는 사람을 보고, DevEx는 일상을 본다."

23장 · 한국 사례 — Toss · Coupang · Naver의 플랫폼 팀

한국 빅테크의 플랫폼 팀은 2024~2026년에 본격적으로 모양을 갖췄다.

공통점은 "한국형 플랫폼 팀의 첫 1년 목표는 카탈로그·온콜·CI 표준화"라는 패턴이다. Backstage 또는 Port를 카탈로그로 도입하고, ArgoCD/Flux로 GitOps를 표준화하고, OPA/Kyverno로 정책 표준화 — 이 세 트랙이 동시에 돌아간다.

24장 · 일본 사례 — Mercari · ZOZO · CyberAgent

일본도 플랫폼 엔지니어링에 적극적이다.

Mercari의 발표는 영어 자료도 풍부해서 한국 플랫폼 팀이 자주 인용한다. "We solved [X] with this pattern" 발표 시리즈가 GitHub Issues보다 자세하다.

25장 · 미국·유럽 사례 — Spotify · Netflix · Airbnb · ING

이들의 공통점은 "IDP는 만드는 게 아니라 운영하는 것"이라는 인식이다. 첫 6개월 만드는 건 쉽지만, 5년차에 1000개의 컴포넌트가 들어간 카탈로그를 유지하는 게 진짜 일이다.

26장 · 의사결정 트리 — 우리 회사는 무엇을 골라야 하나

회사 규모와 단계에 따라 추천 스택이 다르다.

스타트업 (10~50명, 마이크로서비스 5~20개)

중견 (50~500명, 마이크로서비스 20~100개)

대규모 (500명 이상, 마이크로서비스 100+)

27장 · 마이그레이션 가이드 — 셀프 빌드 PaaS에서 IDP로

많은 회사에 이미 "자체 PaaS"가 있다. Jenkins·GitOps 스크립트·Slack 봇 같은 것들이 누적된 것. 이걸 IDP로 옮기는 길.

  1. 카탈로그 먼저 — Backstage 또는 Port를 띄우고, 모든 서비스를 등록한다. (catalog-info.yaml 또는 Blueprint)
  2. 온콜·문서 통합 — TechDocs로 문서를 한곳에, PagerDuty 플러그인으로 온콜을 한곳에.
  3. GitOps 표준화 — Jenkins 배포를 ArgoCD/Flux로. 첫 한 달은 병행, 다음 달은 신규 서비스만 GitOps.
  4. Self-Service Actions — Port나 Backstage Software Templates으로 "신규 서비스 만들기"를 버튼 한 번.
  5. DORA 측정 시작 — 그 다음 부터 KPI를 본다. 측정하지 않는 건 못 고친다.
  6. Score / Crossplane 도입 — 마지막에 워크로드 추상화. 너무 일찍 도입하면 추상화 비용이 가치보다 크다.

28장 · 마무리 — 플랫폼 엔지니어링은 2026년의 SRE다

2010년대의 SRE처럼, 2020년대 후반의 플랫폼 엔지니어링은 "좋은 회사라면 다 가지고 있어야 하는" 분야가 됐다. 차이가 있다면, SRE가 "운영의 자동화"였다면 플랫폼 엔지니어링은 "개발자 경험의 제품화"다.

기억해야 할 한 줄: "IDP는 만드는 게 아니라 운영하는 것이고, 운영의 비결은 측정·반복·고객 인터뷰다."

플랫폼 팀의 첫 6개월은 도구 선택에 쓰지 말고, 누가 우리 고객인지 정의하는 데 써야 한다. Stream-aligned team이 고객이다. 그들의 NPS를 분기마다 묻고, DORA를 측정하고, Backstage·Port·ArgoCD·Terraform — 어떤 도구든 그 NPS를 올리는 방향으로 다듬는다. 그게 2026년 플랫폼 엔지니어링의 진짜 코드다.

References

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

댓글

아직 댓글이 없습니다.

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