플랫폼 엔지니어링과 Internal Developer Platform: Backstage와 골든 패스가 개발자 셀프서비스를 만드는 원리

솔직히 말하면, 저도 처음에 플랫폼 엔지니어링을 들었을 때 "결국 DevOps 이름 바꾼 거 아니야?"라고 생각했습니다. Kubernetes YAML 100줄을 외워가며 배포하고, Terraform(클라우드 인프라를 코드로 선언해 프로비저닝하는 도구) 스크립트 실수로 프로덕션을 날릴 뻔했던 경험을 했던 사람으로서—그게 "개발자가 인프라도 책임진다"는 DevOps 모델의 현실적인 모습이었으니까요. 플랫폼 엔지니어링은 거기서 한 걸음 더 나아갑니다. "그 고통을 전문 팀이 흡수하고, 개발자는 코드에만 집중하게 하자"는 발상이죠.

플랫폼 엔지니어링의 핵심은 내부 인프라와 개발 도구를 하나의 '제품'으로 다루고, 조직 내 개발자를 고객으로 취급하는 것입니다. 그 결과물이 바로 IDP(Internal Developer Platform, 내부 개발자 플랫폼)입니다. State of Platform Engineering Report Vol.4(518명 글로벌 엔지니어 대상)에 따르면 이미 55% 이상의 조직이 플랫폼 엔지니어링을 채택했고, Gartner는 2026년까지 대형 조직의 80%가 플랫폼 팀을 운영할 것으로 예측합니다. 일시적인 유행이 아닌 셈이죠.

이 글은 인프라 경험이 제한된 풀스택·백엔드 개발자를 주요 독자로 상정합니다. IDP의 세 계층이 실제로 어떻게 맞물리는지, 그리고 팀에서 당장 써볼 수 있는 코드까지 함께 살펴봅니다.

핵심 개념

DevOps와 플랫폼 엔지니어링, 뭐가 다를까?

실무에서 자주 맞닥뜨리는 혼란인데, 두 방법론은 목표는 같지만 접근 방식이 다릅니다.

구분	DevOps	플랫폼 엔지니어링
철학	개발자가 인프라까지 직접 소유	플랫폼 팀이 인지 부하를 흡수
개발자 역할	배포·운영까지 전담	코드와 비즈니스 로직에 집중
인프라 접근	직접 조작 (kubectl, AWS Console)	셀프서비스 포털을 통한 추상화
주요 리스크	인지 부하 과다, 보안 실수	플랫폼 팀 병목, 초기 투자 비용

핵심은 추상화 계층입니다. 개발자가 매번 Kubernetes YAML을 직접 작성하거나 보안 그룹 규칙을 설정하는 대신, 플랫폼이 검증된 설정을 제공하는 구조입니다.

IDP의 세 가지 계층

IDP는 단일 도구가 아니라 세 계층이 맞물린 시스템입니다.

mermaid

graph TD
    A["셀프서비스 포털 (개발자 접점) — Backstage / Port / Cortex*"]
    B["오케스트레이션 계층 — Humanitec / Crossplane"]
    C["인프라 자동화 계층 — Terraform / Pulumi / ArgoCD"]
 
    A --> B
    B --> C

*Cortex는 소프트웨어 카탈로그와 서비스 품질 점수 관리에 특화된 도구입니다. Backstage나 Port처럼 풀스택 셀프서비스 포털이라기보다는 카탈로그 중심 플랫폼으로 이해하는 것이 더 정확합니다.

개발자는 포털에서 "스테이징 환경 하나 주세요"라고 요청하면, 오케스트레이션 레이어가 IaC를 실행하고 실제 클라우드 리소스를 프로비저닝합니다. 개발자는 내부 구현을 알 필요가 없습니다.

골든 패스(Golden Path): IDP의 핵심 철학

골든 패스(Golden Path) 란 보안·거버넌스·운영 모범 사례를 코드화한 템플릿 경로입니다. 개발자가 매번 처음부터 설정하지 않고 검증된 경로를 선택함으로써 일관성과 속도를 동시에 얻는 개념입니다.

예를 들어 새 마이크로서비스를 시작할 때, 골든 패스가 없으면 누군가는 보안 그룹을 너무 열어놓고, 누군가는 리소스 limit 설정을 빠뜨립니다. 골든 패스가 있으면 조직이 정한 모범 사례가 자동으로 적용된 스캐폴딩으로 시작할 수 있습니다.

실전 적용

예시 1: Backstage로 소프트웨어 카탈로그와 골든 패스 구성하기

→ IDP 3계층 중 셀프서비스 포털 계층에 해당합니다.

신규 개발자가 입사했을 때 "우리 회사에 어떤 서비스가 있고, 누가 담당하고, API 문서는 어디 있지?"를 파악하는 데 몇 주가 걸리는 상황—많이 익숙하실 겁니다. 저도 입사 첫 달에 서비스 의존 관계를 이해하려고 슬랙 채널을 샅샅이 뒤진 기억이 납니다. Backstage의 소프트웨어 카탈로그가 이 문제를 해결합니다.

yaml

# 각 서비스 리포지토리에 추가하는 catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: B2B 결제 처리 서비스
  tags:
    - payment
    - critical
  annotations:
    github.com/project-slug: my-org/payment-service
    grafana/dashboard-selector: "payment-service"
    pagerduty.com/service-id: "P1234ABC"
spec:
  type: service
  lifecycle: production
  owner: payments-team
  dependsOn:
    - component:user-service
    - resource:payments-database
  providesApis:
    - payment-api

항목	설명
`annotations`	외부 시스템(GitHub, Grafana, PagerDuty)과 자동 연결
`dependsOn`	서비스 의존성 그래프 자동 생성
`providesApis`	API 문서와 카탈로그 항목 자동 연결
`owner`	서비스 소유권 명확화 및 온콜 라우팅

카탈로그 파일만으로는 부족합니다. 새 서비스 생성 자체도 자동화할 수 있는데, 이게 바로 Backstage 스캐폴더의 역할입니다.

yaml

# Backstage 스캐폴더 템플릿 (골든 패스 진입점)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service-template
  title: Node.js 마이크로서비스 (골든 패스)
  description: 보안·모니터링·CI/CD 설정이 포함된 표준 템플릿
spec:
  owner: platform-team
  type: service
  parameters:
    - title: 서비스 기본 정보
      required:
        - name
        - owner
      properties:
        name:
          title: 서비스 이름
          type: string
        owner:
          title: 팀 이름
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch
      name: 템플릿 가져오기
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: GitHub에 푸시
      action: publish:github
      input:
        allowedHosts:
          - github.com
        repoUrl: github.com?owner=my-org&repo=${{ parameters.name }}-service
        defaultBranch: main
    - id: register
      name: Backstage 카탈로그에 등록
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

이 템플릿 하나로 새 서비스를 시작할 때마다 GitHub 리포지토리 생성, CI/CD 파이프라인 연결, 모니터링 설정, Backstage 카탈로그 등록이 자동으로 처리됩니다. 실무 사례를 보면 수 주 걸리던 온보딩이 수 시간으로 단축되는 경우도 있습니다.

예시 2: Policy-as-Code로 거버넌스 자동화하기

→ IDP 3계층 중 오케스트레이션 / 인프라 자동화 계층의 보안 레이어에 해당합니다.

보안팀이 배포 전 체크리스트를 수동으로 확인하는 조직이라면, OPA(Open Policy Agent, 정책을 코드로 선언해 자동 검증하는 도구)를 활용해 정책을 자동화할 수 있습니다.

여기서 잠깐—OPA를 CI/CD 파이프라인에 붙이는 것과 Kubernetes admission controller에 붙이는 것은 역할이 다릅니다. CI/CD 단계에서는 배포 전에 정책을 미리 검사해서 빌드를 실패시키고(사전 예방), admission controller 단계에서는 실제 클러스터에 리소스가 생성되는 순간 실시간으로 차단합니다(실시간 방어). 두 곳 모두에 적용하면 이중 안전망이 생깁니다.

rego

# OPA Rego 정책 예시: 프로덕션 환경 배포 규칙
# Rego는 Prolog 계열 문법입니다. 'deny[msg] { ... }' 블록 안의 조건이
# 모두 참이면 해당 요청을 거부한다는 식으로 읽으시면 됩니다.
package kubernetes.admission
 
# 프로덕션 네임스페이스에는 리소스 limit 필수
deny[msg] {
  input.request.kind.kind == "Pod"
  input.request.namespace == "production"
  container := input.request.object.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("컨테이너 '%v'에 메모리 limit이 없습니다. 프로덕션 배포를 위해 설정이 필요합니다.", [container.name])
}
 
# latest 태그 사용 금지
deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  endswith(container.image, ":latest")
  msg := sprintf("컨테이너 '%v'가 ':latest' 태그를 사용하고 있습니다. 버전을 고정해 주세요.", [container.name])
}
 
# 루트 컨테이너 차단
deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  container.securityContext.runAsUser == 0
  msg := sprintf("컨테이너 '%v'가 root로 실행되고 있습니다. 비권한 사용자로 변경해 주세요.", [container.name])
}

세 정책 모두 실제로 가장 빈번하게 위반되는 규칙들입니다. Convera(글로벌 B2B 결제 기업)는 Humanitec 기반 IDP에 이런 정책 자동화를 결합해 변경 실패율 5% 미만, 출시 기간 30% 단축이라는 성과를 달성했습니다.

예시 3: Crossplane으로 인프라를 Kubernetes 리소스처럼 선언하기

→ IDP 3계층 중 오케스트레이션 계층에 해당합니다.

개발자가 "PostgreSQL DB 하나 필요해요"를 말하면 Ops 팀을 며칠씩 기다리던 시절과 달리, Crossplane을 사용하면 Kubernetes에서 쓰던 선언적 방식 그대로 인프라를 요청할 수 있습니다. 처음 이걸 봤을 때 저도 Composition이 뭔지 몰라서 공식 문서를 세 번 읽었는데, 개발자 시각과 플랫폼 팀 시각으로 나눠서 보니까 훨씬 이해가 빨랐습니다.

yaml

# 개발자가 작성하는 DB 요청 (Crossplane Claim)
# 비즈니스 관점 파라미터만 지정하면 됩니다
apiVersion: database.example.com/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: my-app-db
  namespace: my-team
spec:
  parameters:
    storageGB: 20
    version: "14"
    environment: staging
  writeConnectionSecretToRef:
    name: my-app-db-credentials

yaml

# 플랫폼 팀이 정의하는 Composition (단순화)
# 개발자의 Claim이 들어오면 실제로 어떤 AWS 리소스를 만들지 여기서 결정합니다
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgresql-aws
spec:
  compositeTypeRef:
    apiVersion: database.example.com/v1alpha1
    kind: PostgreSQLInstance
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: ap-northeast-2
            instanceClass: db.t3.micro
            engine: postgres
      patches:
        - fromFieldPath: spec.parameters.storageGB
          toFieldPath: spec.forProvider.allocatedStorage
        - fromFieldPath: spec.parameters.version
          toFieldPath: spec.forProvider.engineVersion

Crossplane Composition 이란 플랫폼 팀이 "PostgreSQL 요청이 들어오면 어떤 AWS 리소스들을 어떻게 조합해서 만들지"를 미리 정의한 템플릿입니다. 개발자는 이 구현 세부사항을 몰라도 됩니다.

개발자는 VPC, 서브넷, 파라미터 그룹 등 AWS RDS의 복잡한 설정을 알 필요 없이 비즈니스 관점의 파라미터(용량, 버전, 환경)만 지정하면 됩니다. 플랫폼 팀은 Composition으로 모범 사례를 한 번만 정의해두면, 이후 모든 요청에 자동으로 적용됩니다.

장단점 분석

장점

항목	내용
인지 부하 감소	개발자가 인프라 세부 지식 없이 셀프서비스로 작업 가능, 핵심 개발에 집중
배포 속도 향상	주 단위 릴리스에서 일일 다중 배포로 전환하는 사례 다수 (State of Platform Engineering Vol.4)
보안 자동화	Policy-as-Code로 수동 보안 체크리스트의 상당 부분 자동화 가능
표준화	골든 패스로 팀 전체에 모범 사례 일관 적용
온보딩 가속	수 주 걸리던 신규 개발자 온보딩을 수 시간으로 단축한 사례 보고

단점 및 주의사항

항목	내용	대응 방안
높은 초기 투자	약 47%의 플랫폼 이니셔티브가 연간 예산 $100만 이하로 운영	작게 시작해 점진적 확장 (골든 패스 1~2개로 시작)
전담 팀 필요	플랫폼 자체가 제품이므로 지속적 유지보수 인력 필요	최소 2~3명의 전담 엔지니어 확보 후 착수
문화적 저항	개발자들의 새 워크플로에 대한 거부감	개발자를 설계 단계부터 참여시키는 변화 관리
성과 측정 어려움	플랫폼 팀의 약 30%가 성과를 전혀 측정하지 않음 (State of Platform Engineering Vol.4)	DORA 지표 기반 측정 체계 수립
벤더 종속	특정 도구에 과도하게 의존 시 전환 비용 증가	플러그인 아키텍처와 표준 인터페이스 활용

DORA 지표(DORA Metrics) 란 Google DevOps Research and Assessment팀이 정의한 소프트웨어 딜리버리 성과 측정 기준입니다. 배포 빈도(Deployment Frequency), 변경 리드 타임(Lead Time for Changes), 변경 실패율(Change Failure Rate), 서비스 복구 시간(Time to Restore)의 네 가지로 구성됩니다.

실무에서 가장 흔한 실수

"도구부터 선택한다" — Backstage를 설치하는 게 플랫폼 엔지니어링의 시작이라고 착각하는 경우가 많습니다. 실제로는 "Platform as a Product" 마인드셋, 즉 개발자를 고객으로 보는 사고방식이 먼저입니다. 도구는 그다음입니다.
너무 크게 시작한다 — 첫날부터 완벽한 IDP를 만들려다 팀 전체가 지쳐버리는 사례를 자주 봤습니다. 가장 고통스러운 워크플로 하나를 골든 패스로 만들고, 개발자 피드백을 받으며 점진적으로 확장하는 방식이 현실적으로 잘 작동합니다.
ROI를 측정하지 않는다 — State of Platform Engineering Vol.4에 따르면 플랫폼 팀의 약 30%가 성과를 아예 측정하지 않아 예산 확보에 실패합니다. 배포 빈도, 온보딩 시간, 인시던트 건수의 기준선을 플랫폼 도입 전에 먼저 측정해두는 것을 권장합니다.

마치며

플랫폼 엔지니어링은 도구의 집합이 아니라, 개발자를 고객으로 취급하고 내부 인프라를 제품으로 다루는 사고방식의 전환입니다. Backstage로 카탈로그를 구성하고, OPA로 정책을 자동화하고, Crossplane으로 인프라를 선언적으로 다루면—처음에는 설정이 많아 보여도 골든 패스 하나가 자리 잡히고 나면 팀 전체의 흐름이 달라집니다. 저는 이걸 경험하고 나서야 "DevOps 이름만 바꾼 거"라는 첫인상이 틀렸다는 걸 인정하게 됐습니다.

지금 바로 시작해볼 수 있는 3단계:

팀에서 가장 많은 시간을 잡아먹는 워크플로 하나를 찾는 것이 출발점입니다. 새 서비스 온보딩인지, Kubernetes 배포인지, 환경 프로비저닝인지—그 작업이 첫 번째 골든 패스 후보입니다. npx @backstage/create-app@latest 명령어로 로컬 Backstage를 30분 안에 실행해볼 수 있습니다.
개발자 5명에게 "인프라 관련 작업 중 가장 불편한 게 뭔가요?"를 물어보시면 좋습니다. 플랫폼 팀이 추측으로 만든 기능보다 실제 고통을 해결한 기능이 훨씬 빠르게 채택됩니다. 저는 이 인터뷰 결과를 기반으로 첫 골든 패스 범위를 정했더니 채택률이 눈에 띄게 달라졌습니다.
DORA 지표 기준선을 지금 측정해두는 것을 권장합니다. 배포 빈도, 리드 타임, 변경 실패율을 스프레드시트에라도 기록해두면 플랫폼 도입 후 효과를 수치로 보여줄 수 있습니다. 이 데이터가 6개월 뒤 추가 예산을 요청할 때 가장 강한 근거가 됩니다.

참고 자료

Platform Engineering and Internal Developer Platforms: How Backstage and Golden Paths Enable Developer Self-Service | DEV BAK - 기술블로그

Architecture

플랫폼 엔지니어링과 Internal Developer Platform: Backstage와 골든 패스가 개발자 셀프서비스를 만드는 원리

핵심 개념

DevOps와 플랫폼 엔지니어링, 뭐가 다를까?

실무에서 자주 맞닥뜨리는 혼란인데, 두 방법론은 목표는 같지만 접근 방식이 다릅니다.

구분	DevOps	플랫폼 엔지니어링
철학	개발자가 인프라까지 직접 소유	플랫폼 팀이 인지 부하를 흡수
개발자 역할	배포·운영까지 전담	코드와 비즈니스 로직에 집중
인프라 접근	직접 조작 (kubectl, AWS Console)	셀프서비스 포털을 통한 추상화
주요 리스크	인지 부하 과다, 보안 실수	플랫폼 팀 병목, 초기 투자 비용

IDP의 세 가지 계층

IDP는 단일 도구가 아니라 세 계층이 맞물린 시스템입니다.

mermaid

graph TD
    A["셀프서비스 포털 (개발자 접점) — Backstage / Port / Cortex*"]
    B["오케스트레이션 계층 — Humanitec / Crossplane"]
    C["인프라 자동화 계층 — Terraform / Pulumi / ArgoCD"]
 
    A --> B
    B --> C

*Cortex는 소프트웨어 카탈로그와 서비스 품질 점수 관리에 특화된 도구입니다. Backstage나 Port처럼 풀스택 셀프서비스 포털이라기보다는 카탈로그 중심 플랫폼으로 이해하는 것이 더 정확합니다.

골든 패스(Golden Path): IDP의 핵심 철학

골든 패스(Golden Path) 란 보안·거버넌스·운영 모범 사례를 코드화한 템플릿 경로입니다. 개발자가 매번 처음부터 설정하지 않고 검증된 경로를 선택함으로써 일관성과 속도를 동시에 얻는 개념입니다.

실전 적용

예시 1: Backstage로 소프트웨어 카탈로그와 골든 패스 구성하기

→ IDP 3계층 중 셀프서비스 포털 계층에 해당합니다.

yaml

# 각 서비스 리포지토리에 추가하는 catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: B2B 결제 처리 서비스
  tags:
    - payment
    - critical
  annotations:
    github.com/project-slug: my-org/payment-service
    grafana/dashboard-selector: "payment-service"
    pagerduty.com/service-id: "P1234ABC"
spec:
  type: service
  lifecycle: production
  owner: payments-team
  dependsOn:
    - component:user-service
    - resource:payments-database
  providesApis:
    - payment-api

항목	설명
`annotations`	외부 시스템(GitHub, Grafana, PagerDuty)과 자동 연결
`dependsOn`	서비스 의존성 그래프 자동 생성
`providesApis`	API 문서와 카탈로그 항목 자동 연결
`owner`	서비스 소유권 명확화 및 온콜 라우팅

카탈로그 파일만으로는 부족합니다. 새 서비스 생성 자체도 자동화할 수 있는데, 이게 바로 Backstage 스캐폴더의 역할입니다.

yaml

# Backstage 스캐폴더 템플릿 (골든 패스 진입점)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service-template
  title: Node.js 마이크로서비스 (골든 패스)
  description: 보안·모니터링·CI/CD 설정이 포함된 표준 템플릿
spec:
  owner: platform-team
  type: service
  parameters:
    - title: 서비스 기본 정보
      required:
        - name
        - owner
      properties:
        name:
          title: 서비스 이름
          type: string
        owner:
          title: 팀 이름
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch
      name: 템플릿 가져오기
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: GitHub에 푸시
      action: publish:github
      input:
        allowedHosts:
          - github.com
        repoUrl: github.com?owner=my-org&repo=${{ parameters.name }}-service
        defaultBranch: main
    - id: register
      name: Backstage 카탈로그에 등록
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

예시 2: Policy-as-Code로 거버넌스 자동화하기

→ IDP 3계층 중 오케스트레이션 / 인프라 자동화 계층의 보안 레이어에 해당합니다.

rego

# OPA Rego 정책 예시: 프로덕션 환경 배포 규칙
# Rego는 Prolog 계열 문법입니다. 'deny[msg] { ... }' 블록 안의 조건이
# 모두 참이면 해당 요청을 거부한다는 식으로 읽으시면 됩니다.
package kubernetes.admission
 
# 프로덕션 네임스페이스에는 리소스 limit 필수
deny[msg] {
  input.request.kind.kind == "Pod"
  input.request.namespace == "production"
  container := input.request.object.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("컨테이너 '%v'에 메모리 limit이 없습니다. 프로덕션 배포를 위해 설정이 필요합니다.", [container.name])
}
 
# latest 태그 사용 금지
deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  endswith(container.image, ":latest")
  msg := sprintf("컨테이너 '%v'가 ':latest' 태그를 사용하고 있습니다. 버전을 고정해 주세요.", [container.name])
}
 
# 루트 컨테이너 차단
deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  container.securityContext.runAsUser == 0
  msg := sprintf("컨테이너 '%v'가 root로 실행되고 있습니다. 비권한 사용자로 변경해 주세요.", [container.name])
}

예시 3: Crossplane으로 인프라를 Kubernetes 리소스처럼 선언하기

→ IDP 3계층 중 오케스트레이션 계층에 해당합니다.

yaml

# 개발자가 작성하는 DB 요청 (Crossplane Claim)
# 비즈니스 관점 파라미터만 지정하면 됩니다
apiVersion: database.example.com/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: my-app-db
  namespace: my-team
spec:
  parameters:
    storageGB: 20
    version: "14"
    environment: staging
  writeConnectionSecretToRef:
    name: my-app-db-credentials

yaml

# 플랫폼 팀이 정의하는 Composition (단순화)
# 개발자의 Claim이 들어오면 실제로 어떤 AWS 리소스를 만들지 여기서 결정합니다
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgresql-aws
spec:
  compositeTypeRef:
    apiVersion: database.example.com/v1alpha1
    kind: PostgreSQLInstance
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: ap-northeast-2
            instanceClass: db.t3.micro
            engine: postgres
      patches:
        - fromFieldPath: spec.parameters.storageGB
          toFieldPath: spec.forProvider.allocatedStorage
        - fromFieldPath: spec.parameters.version
          toFieldPath: spec.forProvider.engineVersion

Crossplane Composition 이란 플랫폼 팀이 "PostgreSQL 요청이 들어오면 어떤 AWS 리소스들을 어떻게 조합해서 만들지"를 미리 정의한 템플릿입니다. 개발자는 이 구현 세부사항을 몰라도 됩니다.

장단점 분석

장점

항목	내용
인지 부하 감소	개발자가 인프라 세부 지식 없이 셀프서비스로 작업 가능, 핵심 개발에 집중
배포 속도 향상	주 단위 릴리스에서 일일 다중 배포로 전환하는 사례 다수 (State of Platform Engineering Vol.4)
보안 자동화	Policy-as-Code로 수동 보안 체크리스트의 상당 부분 자동화 가능
표준화	골든 패스로 팀 전체에 모범 사례 일관 적용
온보딩 가속	수 주 걸리던 신규 개발자 온보딩을 수 시간으로 단축한 사례 보고

단점 및 주의사항

항목	내용	대응 방안
높은 초기 투자	약 47%의 플랫폼 이니셔티브가 연간 예산 $100만 이하로 운영	작게 시작해 점진적 확장 (골든 패스 1~2개로 시작)
전담 팀 필요	플랫폼 자체가 제품이므로 지속적 유지보수 인력 필요	최소 2~3명의 전담 엔지니어 확보 후 착수
문화적 저항	개발자들의 새 워크플로에 대한 거부감	개발자를 설계 단계부터 참여시키는 변화 관리
성과 측정 어려움	플랫폼 팀의 약 30%가 성과를 전혀 측정하지 않음 (State of Platform Engineering Vol.4)	DORA 지표 기반 측정 체계 수립
벤더 종속	특정 도구에 과도하게 의존 시 전환 비용 증가	플러그인 아키텍처와 표준 인터페이스 활용

DORA 지표(DORA Metrics) 란 Google DevOps Research and Assessment팀이 정의한 소프트웨어 딜리버리 성과 측정 기준입니다. 배포 빈도(Deployment Frequency), 변경 리드 타임(Lead Time for Changes), 변경 실패율(Change Failure Rate), 서비스 복구 시간(Time to Restore)의 네 가지로 구성됩니다.

실무에서 가장 흔한 실수

"도구부터 선택한다" — Backstage를 설치하는 게 플랫폼 엔지니어링의 시작이라고 착각하는 경우가 많습니다. 실제로는 "Platform as a Product" 마인드셋, 즉 개발자를 고객으로 보는 사고방식이 먼저입니다. 도구는 그다음입니다.
너무 크게 시작한다 — 첫날부터 완벽한 IDP를 만들려다 팀 전체가 지쳐버리는 사례를 자주 봤습니다. 가장 고통스러운 워크플로 하나를 골든 패스로 만들고, 개발자 피드백을 받으며 점진적으로 확장하는 방식이 현실적으로 잘 작동합니다.
ROI를 측정하지 않는다 — State of Platform Engineering Vol.4에 따르면 플랫폼 팀의 약 30%가 성과를 아예 측정하지 않아 예산 확보에 실패합니다. 배포 빈도, 온보딩 시간, 인시던트 건수의 기준선을 플랫폼 도입 전에 먼저 측정해두는 것을 권장합니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

팀에서 가장 많은 시간을 잡아먹는 워크플로 하나를 찾는 것이 출발점입니다. 새 서비스 온보딩인지, Kubernetes 배포인지, 환경 프로비저닝인지—그 작업이 첫 번째 골든 패스 후보입니다. npx @backstage/create-app@latest 명령어로 로컬 Backstage를 30분 안에 실행해볼 수 있습니다.
개발자 5명에게 "인프라 관련 작업 중 가장 불편한 게 뭔가요?"를 물어보시면 좋습니다. 플랫폼 팀이 추측으로 만든 기능보다 실제 고통을 해결한 기능이 훨씬 빠르게 채택됩니다. 저는 이 인터뷰 결과를 기반으로 첫 골든 패스 범위를 정했더니 채택률이 눈에 띄게 달라졌습니다.
DORA 지표 기준선을 지금 측정해두는 것을 권장합니다. 배포 빈도, 리드 타임, 변경 실패율을 스프레드시트에라도 기록해두면 플랫폼 도입 후 효과를 수치로 보여줄 수 있습니다. 이 데이터가 6개월 뒤 추가 예산을 요청할 때 가장 강한 근거가 됩니다.

핵심 개념

DevOps와 플랫폼 엔지니어링, 뭐가 다를까?

IDP의 세 가지 계층

골든 패스(Golden Path): IDP의 핵심 철학

실전 적용

예시 1: Backstage로 소프트웨어 카탈로그와 골든 패스 구성하기

예시 2: Policy-as-Code로 거버넌스 자동화하기

예시 3: Crossplane으로 인프라를 Kubernetes 리소스처럼 선언하기

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

DevOps와 플랫폼 엔지니어링, 뭐가 다를까?

IDP의 세 가지 계층

골든 패스(Golden Path): IDP의 핵심 철학

실전 적용

예시 1: Backstage로 소프트웨어 카탈로그와 골든 패스 구성하기

예시 2: Policy-as-Code로 거버넌스 자동화하기

예시 3: Crossplane으로 인프라를 Kubernetes 리소스처럼 선언하기

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

사이드카리스 서비스 메시의 현실: eBPF가 Istio 사이드카를 어떻게 대체하는가

마이크로서비스를 버린 42%가 선택한 것 — 모놀리스 vs 마이크로서비스, 아키텍처 선택의 현실

서버리스 + 엣지 컴퓨팅: Cloudflare Workers로 전 세계 300개 노드에서 5ms 응답 구현하기

EDA가 분산된 모놀리스로 끝나지 않으려면 — Outbox·Saga·CQRS 핵심 패턴과 프로덕션 함정 3가지