Backstage로 구축하는 IDP: 셀프서비스 배포 환경을 직접 도입해본 이야기

"왜 또 인프라 팀 기다려야 해요?" — 개발하다 보면 한 번쯤은 속으로 삼킨 말일 겁니다. 코드는 다 짰는데, 환경 세팅이나 배포 승인 때문에 며칠을 허비한 경험, 다들 있을 거예요. 저도 그랬고요. 그 답답함을 구조적으로 해결하려는 시도가 바로 Platform Engineering이고, 그 핵심 산출물이 IDP(Internal Developer Platform, 내부 개발자 플랫폼)입니다.

이 글을 읽고 나면 소프트웨어 카탈로그부터 골든 패스, 스코어카드까지 IDP의 핵심 구성 요소를 직접 판단할 수 있게 됩니다. 어떤 도구를 언제 도입하면 좋을지, 그리고 어디서 가장 자주 무너지는지까지요. 백엔드든 프론트든, 자신의 팀이 이 방향으로 가고 있다면 — 혹은 가야 한다고 느낀다면 — 도움이 될 거예요.

한 가지 미리 말씀드리면, 도구보다 철학이 먼저입니다. 실제로 IDP를 잘 구축해놓고도 아무도 안 쓰는 팀을 여럿 봤는데, 공통점이 있더라고요. 그 이야기는 마지막에 풀겠습니다.

핵심 개념

IDP란 무엇인가: "개발자를 위한 원스톱 셀프서비스"

IDP는 개발자가 인프라, 배포, 시크릿 관리, 모니터링을 한 곳에서 직접 처리할 수 있도록 추상화된 플랫폼입니다. Platform Engineering은 DevOps의 "개발팀-운영팀 협업"보다 한 발 더 나아가, 플랫폼 자체를 하나의 제품으로 만드는 분야예요. Team Topologies에서 말하는 Platform Team의 핵심 역할이 바로 이겁니다 — 개발자의 인지 부하(cognitive load)를 줄여서, 팀이 비즈니스 로직에만 집중할 수 있도록 환경을 제공하는 것이죠.

핵심 구성 요소를 도식화하면 이렇습니다:

구성 요소	역할	예시
소프트웨어 카탈로그	전체 서비스·컴포넌트·오너십을 단일 뷰로 관리	Backstage Catalog
셀프서비스 액션	환경 생성, DB 프로비저닝, 배포를 클릭/API로 처리	Port Actions, Backstage Scaffolder
골든 패스	조직 베스트 프랙티스가 내장된 표준 템플릿·워크플로	cookiecutter, Backstage Templates
개발자 포털	위 기능을 통합하는 UI/UX 레이어	Backstage, Port, Cortex

Platform as a Product: IDP는 "플랫폼 팀이 내부 고객(개발자)을 위한 제품을 만든다"는 철학에 기반합니다. 외부 사용자 대신 동료 개발자가 고객인 것만 다를 뿐, 제품 사고방식 그대로입니다.

핵심 도구 생태계와 BACK Stack

이 부분이 처음엔 좀 압도적으로 느껴질 수 있는데, 실제로 이 도구들을 처음 연결해봤을 때 "어, 이게 진짜 되네?"라는 느낌이 들었거든요. 2025~2026년 기준으로 가장 많이 쓰이는 스택입니다:

레이어	도구	특징
개발자 포털	Backstage	CNCF(클라우드 네이티브 컴퓨팅 재단)의 공식 채택 프로젝트, 풍부한 플러그인 생태계
	Port	SaaS, 빠른 셋업, GitHub Actions·ArgoCD 통합
	Roadie	Managed Backstage (운영 부담 없음)
GitOps/CD	ArgoCD	K8s 네이티브 GitOps. 71% 이상 조직 채택
인프라 프로비저닝	Crossplane	K8s 컨트롤러 방식으로 클라우드 리소스 관리
	Terraform / OpenTofu	선언적 CLI 방식의 IaC 업계 표준. 71% 조직 사용
정책·보안	Kyverno / OPA Gatekeeper	K8s 정책 엔진
	Vault / Infisical	시크릿 관리

잠깐, Crossplane과 Terraform이 둘 다 "인프라 프로비저닝"으로 묶여 있는데 실제로는 운영 방식이 꽤 다릅니다. Crossplane은 Kubernetes 컨트롤러로 동작해서 K8s 매니페스트로 AWS·GCP 리소스를 선언하는 방식이고, Terraform은 CLI로 실행하는 독립적인 선언형 도구예요. K8s 환경이 이미 있다면 Crossplane이 자연스럽게 녹아들고, 그렇지 않다면 Terraform이 더 범용적인 선택입니다.

GitOps는 처음 나오는 개념이니 짧게 짚고 넘어가면 — Git이 단일 진실 소스(Single Source of Truth)가 되어 배포를 자동 동기화하는 방식입니다. 코드뿐 아니라 인프라 상태까지 Git으로 관리하는 거예요.

실무에서 자주 보이는 조합이 바로 BACK Stack입니다:

Backstage (포털)
  + ArgoCD (GitOps 배포)
  + Crossplane (인프라 프로비저닝)
  + Kyverno (정책 관리)

이 네 개가 맞물리면 "개발자가 포털에서 버튼 클릭 → 인프라 자동 생성 → 코드 push → 자동 배포 → 정책 자동 검사"까지 하나의 흐름이 완성됩니다.

실전 적용

예시 1: 소프트웨어 카탈로그 — 서비스 오너십 가시화

IDP 구축의 첫 번째 단계는 보통 "지금 우리 회사에 뭐가 있는지 파악하기"입니다. 솔직히 이게 제일 놀라운 단계예요. 100명짜리 조직도 "이 서비스 누가 만들었지?"를 모르는 경우가 허다하거든요. 처음 카탈로그를 채워넣을 때 "이런 서비스가 있었어?" 하는 순간이 꼭 나옵니다.

Backstage 카탈로그는 각 서비스 리포지토리에 catalog-info.yaml 파일 하나만 추가하면 등록됩니다:

yaml

# catalog-info.yaml (서비스 루트에 배치)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: 결제 처리 마이크로서비스
  tags:
    - java
    - payments
  annotations:
    github.com/project-slug: my-org/payment-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: P12345
spec:
  type: service
  lifecycle: production
  owner: payments-team
  dependsOn:
    - component:user-service
    - resource:payments-database
  providesApis:
    - payment-api

필드	역할
`owner`	서비스 오너 팀 지정 → 장애 시 빠른 에스컬레이션
`dependsOn`	의존 관계 시각화 → 배포 순서, 영향도 파악
`lifecycle`	production/experimental 구분 → 기술 부채 관리
`annotations`	PagerDuty, GitHub 등 외부 도구 연결

예시 2: 골든 패스 — 선택을 줄여주는 설계

저도 처음엔 "왜 굳이 표준 경로를 강제해?"라고 생각했는데, 실무에서 직접 겪어보니 이게 핵심이더라고요. 신규 개발자가 온보딩할 때, "어떤 프레임워크 써야 하지?", "CI/CD는 어떻게 연결하지?", "모니터링은?"을 매번 고민하게 두면 인지 부하가 폭발합니다.

골든 패스는 이 의사결정을 미리 해놓은 겁니다. Backstage의 Software Template 예시를 볼게요:

yaml

# template.yaml (Backstage Software Template 예시)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service-template
  title: Node.js 백엔드 서비스
  description: 팀 표준 Node.js 서비스 스캐폴딩 템플릿
spec:
  owner: platform-team
  type: service
 
  parameters:
    - title: 서비스 기본 정보
      properties:
        name:
          title: 서비스명
          type: string
        owner:
          title: 담당 팀
          type: string
          ui:field: OwnerPicker
 
  steps:
    - id: fetch-template
      name: 템플릿 코드 가져오기
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
 
    - id: publish
      name: GitHub 리포지토리 생성
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=my-org
 
    - id: register
      name: 카탈로그에 등록
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

steps의 순서가 fetch → publish → register인 게 포인트입니다. 이게 Backstage Scaffolder의 실제 실행 순서와 정확히 일치해요. 이 템플릿 하나로 신규 서비스 생성 → GitHub 리포 만들기 → 카탈로그 등록까지 자동화됩니다. Spotify는 이 방식으로 서비스 온보딩 속도를 60% 향상시켰습니다.

예시 3: ArgoCD + Crossplane으로 셀프서비스 환경 구성

개발자가 "스테이징 환경 하나 더 필요해요"라고 요청할 때, 기존엔 인프라 팀 티켓 → 며칠 대기였다면, Crossplane을 쓰면 Git에 파일 하나 push하는 것으로 끝납니다.

아래 파일은 Crossplane의 Composite Resource라는 개념인데, K8s를 확장한 커스텀 리소스입니다. apiVersion과 kind 필드가 낯설게 느껴질 수 있는데, 이건 K8s의 확장 리소스 형식으로 회사 플랫폼 팀이 미리 정의해둔 추상화 레이어라고 보시면 됩니다:

yaml

# staging-env.yaml (Crossplane Composite Resource 예시)
apiVersion: platform.mycompany.com/v1alpha1
kind: DeveloperEnvironment
metadata:
  name: feature-payment-v2-env
  namespace: team-payments
spec:
  parameters:
    region: ap-northeast-2
    dbSize: db.t3.medium
    clusterSize: small
  compositeDeletePolicy: Foreground  # 리소스 삭제 시 하위 리소스가 모두 정리된 후 완료 처리
  writeConnectionSecretsToNamespace: team-payments

compositeDeletePolicy: Foreground는 삭제 정책이라 한 줄 설명이 필요합니다 — 이 환경을 삭제할 때 AWS RDS, 네트워크 리소스 등 하위에 생성된 모든 것이 완전히 정리된 후에야 삭제가 완료됩니다. 실수로 환경을 지웠는데 실제 클라우드 리소스가 남아있는 상황을 방지하기 위한 설정이에요.

yaml

# ArgoCD Application — Git 변경 감지 → 자동 배포
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: feature-payment-v2
  namespace: argocd
spec:
  project: payments-team
  source:
    repoURL: https://github.com/my-org/environments
    targetRevision: HEAD
    path: teams/payments/feature-payment-v2
  destination:
    server: https://kubernetes.default.svc
    namespace: feature-payment-v2
  syncPolicy:
    automated:
      prune: true      # Git에서 삭제된 리소스를 클러스터에서도 자동 제거
      selfHeal: true   # 클러스터 상태가 Git과 달라지면 자동으로 복원

prune과 selfHeal은 실무에서 놓치기 쉬운 설정인데, 이 두 개가 없으면 "Git에선 삭제했는데 실제 환경엔 아직 남아있는" 상황이 생깁니다. 이 구성이 완성되면 개발자가 Git에 staging-env.yaml을 올리는 순간, Crossplane이 AWS 리소스를 생성하고 ArgoCD가 K8s 배포까지 자동으로 처리합니다.

Netflix는 이 방식으로 수십 개의 내부 도구를 단일 콘솔로 통합한 뒤, 중앙 DevOps 팀에 대한 배포 의존 티켓 수를 65% 줄였습니다. 엔지니어 입장에서 이게 어떤 경험인지 생각해보면 — 매번 누군가에게 부탁하지 않고 내가 직접 환경을 만들고 지울 수 있다는 게 얼마나 큰 자율감인지, 써보기 전엔 잘 모르거든요.

예시 4: 스코어카드로 운영 성숙도 측정

IDP 도입 후 "잘 운영되고 있나?"를 측정하는 방법으로 스코어카드가 많이 쓰입니다. Port나 Cortex 같은 SaaS 도구에선 YAML 정의 하나로 바로 쓸 수 있어요. Port 기준 예시입니다:

yaml

# Port 스코어카드 정의 예시 (Port 포털에서 직접 등록)
identifier: service-maturity
title: 서비스 운영 성숙도
levels:
  - color: red
    title: Basic
  - color: gold
    title: Silver
  - color: silver
    title: Gold
rules:
  - identifier: has-catalog-info
    title: 카탈로그 등록 여부
    level: Basic
    query:
      combinator: and
      rules:
        - property: $identifier
          operator: isNotEmpty
  - identifier: has-owner
    title: 오너십 지정
    level: Basic
    query:
      combinator: and
      rules:
        - property: $team
          operator: isNotEmpty
  - identifier: has-runbook
    title: 런북 문서화
    level: Silver
    query:
      combinator: and
      rules:
        - property: runbook_url
          operator: isNotEmpty
  - identifier: has-alerting
    title: PagerDuty 알람 연동
    level: Gold
    query:
      combinator: and
      rules:
        - property: pagerduty_service_id
          operator: isNotEmpty

서비스마다 점수가 매겨지면, 플랫폼 팀은 "어느 팀이 런북 없이 운영하는지"를 대화 없이도 파악할 수 있습니다. Gartner 2026 예측에 따르면 대형 엔지니어링 조직의 80%가 전담 플랫폼 팀을 보유하게 될 거라고 하는데, 그 팀들이 가장 먼저 활용하는 게 이런 스코어카드 기반의 가시성이에요.

장단점 분석

장점

항목	내용
배포 속도	배포 빈도 30~50% 개선 (셀프서비스 환경 덕분)
개발자 생산성	인프라 결정·도구 선택 고민 제거로 최대 40% 향상
온보딩 단축	첫 배포까지 걸리는 시간 대폭 감소 (Spotify 60% 향상)
인지 부하 감소	골든 패스로 "어떻게 해야 하지?" 고민 제거
장애 감소	표준화로 Critical incident 약 20% 감소
ROI	185~220% ROI (피처 개발 단독 대비)*

*ROI 수치는 State of Platform Engineering Report Vol.4 (platformengineering.org) 기준입니다.

단점 및 주의사항

항목	내용	대응 방안
초기 투자	Backstage 자체 구축 시 6~~12개월, 유지에 3~~15명 필요	소규모 팀은 Port·Roadie 등 SaaS 검토
채택 문제	UX가 불편하면 개발자가 그냥 안 씀	얼리어답터 팀과 함께 피드백 루프 구성
유연성 딜레마	골든 패스가 너무 경직되면 특수 요구 억제	Escape Hatch 경로 별도 마련
지속 유지보수	기술 스택 변화에 따라 지속 업데이트 필요	분기별 플랫폼 로드맵 수립
조직 합의	다수 이해관계자 조율 필요	초기부터 각 팀 대표를 설계에 참여시키기

DIY vs SaaS: Backstage를 직접 구축·운영하려면 최대 15명의 엔지니어가 필요하다는 연구 결과가 나오면서, Port·Cortex·Roadie 같은 SaaS로 전환하는 조직이 빠르게 늘고 있습니다. "처음부터 직접 만들어야 한다"는 부담은 내려놓으셔도 됩니다.

실무에서 가장 흔한 실수

"만들면 알아서 쓰겠지" 착각: 실제로 제가 겪은 케이스 중에, 6개월을 투자해 훌륭한 포털을 만들었는데 3개월 후 접속자가 한 자리수인 팀이 있었습니다. IDP는 출시 후 개발자가 실제로 쓰기 시작하는 순간부터 시작입니다. 얼리어답터 팀을 잡아 직접 피드백을 받으면서 개선하는 루프가 없으면, 열심히 만든 포털이 아무도 안 쓰는 내부 도구가 됩니다.
조직 문제를 도구로 해결하려는 시도: IDP는 "서비스 오너십이 불명확하다", "배포 프로세스가 복잡하다"는 이미 인지된 문제를 자동화해주는 도구입니다. 팀 간 신뢰 부족이나 책임 불명확 같은 문화 문제는 플랫폼이 해결해주지 않습니다. 실제로 "우리는 도구를 도입했으니 이제 DevOps 됐다"고 생각했다가 혼란이 더 커진 사례를 봤어요. Crossplane이 환경을 자동으로 만들어줘도, 그 환경을 누가 책임지는지 합의가 없으면 아무 소용이 없거든요.
골든 패스를 처음부터 완벽하게 만들려는 욕심: 처음부터 모든 케이스를 커버하려다가 누구도 쓰기 불편한 템플릿이 됩니다. 가장 흔한 80% 케이스만 골든 패스로 만들고, 나머지는 유연하게 열어두는 것이 현실적입니다.

마치며

Platform Engineering과 IDP의 핵심은 개발자를 기다리게 만드는 마찰을 구조적으로 제거하는 것입니다. 그런데 이걸 가능하게 하려면, 도구보다 먼저 "우리 팀에서 가장 반복적이고 불필요한 대기가 무엇인가"를 명확히 아는 게 선행되어야 해요. 도구는 그 다음입니다. 거창하게 시작할 필요도 없고요. 소프트웨어 카탈로그 하나만 도입해도 "이 서비스 누가 관리하지?"에서 오는 시간 낭비를 바로 줄일 수 있습니다.

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

팀 내 페인포인트를 먼저 리스트업해보시면 좋습니다. "배포할 때 뭐가 제일 힘드세요?"를 동료 5명에게 물어보면 IDP에서 가장 먼저 해결해야 할 것이 보입니다. 도구보다 문제 정의가 먼저입니다.
소프트웨어 카탈로그부터 시작해볼 수 있습니다. Backstage를 직접 띄우기 부담스럽다면, Port 무료 티어로 팀 서비스 목록을 등록해보는 것도 좋은 출발점입니다. catalog-info.yaml 파일 하나만 리포에 추가하면 시작됩니다.
골든 패스 템플릿을 하나만 만들어보시는 것도 효과적입니다. 팀에서 가장 자주 만드는 서비스 유형(예: Node.js API 서버)의 표준 스캐폴딩을 Backstage Template 또는 cookiecutter 형태로 정리해두면, 다음 신규 서비스 생성부터 바로 체감이 됩니다.

다음 글: Backstage 플러그인 직접 개발하기 — 우리 팀만의 커스텀 셀프서비스 액션을 TypeScript로 구현하는 방법

참고 자료

Backstage로 구축하는 IDP: 셀프서비스 배포 환경을 직접 도입해본 이야기 | DEV BAK - 기술블로그

DevOps

Backstage로 구축하는 IDP: 셀프서비스 배포 환경을 직접 도입해본 이야기

핵심 개념

IDP란 무엇인가: "개발자를 위한 원스톱 셀프서비스"

핵심 구성 요소를 도식화하면 이렇습니다:

구성 요소	역할	예시
소프트웨어 카탈로그	전체 서비스·컴포넌트·오너십을 단일 뷰로 관리	Backstage Catalog
셀프서비스 액션	환경 생성, DB 프로비저닝, 배포를 클릭/API로 처리	Port Actions, Backstage Scaffolder
골든 패스	조직 베스트 프랙티스가 내장된 표준 템플릿·워크플로	cookiecutter, Backstage Templates
개발자 포털	위 기능을 통합하는 UI/UX 레이어	Backstage, Port, Cortex

Platform as a Product: IDP는 "플랫폼 팀이 내부 고객(개발자)을 위한 제품을 만든다"는 철학에 기반합니다. 외부 사용자 대신 동료 개발자가 고객인 것만 다를 뿐, 제품 사고방식 그대로입니다.

핵심 도구 생태계와 BACK Stack

레이어	도구	특징
개발자 포털	Backstage	CNCF(클라우드 네이티브 컴퓨팅 재단)의 공식 채택 프로젝트, 풍부한 플러그인 생태계
	Port	SaaS, 빠른 셋업, GitHub Actions·ArgoCD 통합
	Roadie	Managed Backstage (운영 부담 없음)
GitOps/CD	ArgoCD	K8s 네이티브 GitOps. 71% 이상 조직 채택
인프라 프로비저닝	Crossplane	K8s 컨트롤러 방식으로 클라우드 리소스 관리
	Terraform / OpenTofu	선언적 CLI 방식의 IaC 업계 표준. 71% 조직 사용
정책·보안	Kyverno / OPA Gatekeeper	K8s 정책 엔진
	Vault / Infisical	시크릿 관리

실무에서 자주 보이는 조합이 바로 BACK Stack입니다:

Backstage (포털)
  + ArgoCD (GitOps 배포)
  + Crossplane (인프라 프로비저닝)
  + Kyverno (정책 관리)

이 네 개가 맞물리면 "개발자가 포털에서 버튼 클릭 → 인프라 자동 생성 → 코드 push → 자동 배포 → 정책 자동 검사"까지 하나의 흐름이 완성됩니다.

실전 적용

예시 1: 소프트웨어 카탈로그 — 서비스 오너십 가시화

Backstage 카탈로그는 각 서비스 리포지토리에 catalog-info.yaml 파일 하나만 추가하면 등록됩니다:

yaml

# catalog-info.yaml (서비스 루트에 배치)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: 결제 처리 마이크로서비스
  tags:
    - java
    - payments
  annotations:
    github.com/project-slug: my-org/payment-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: P12345
spec:
  type: service
  lifecycle: production
  owner: payments-team
  dependsOn:
    - component:user-service
    - resource:payments-database
  providesApis:
    - payment-api

필드	역할
`owner`	서비스 오너 팀 지정 → 장애 시 빠른 에스컬레이션
`dependsOn`	의존 관계 시각화 → 배포 순서, 영향도 파악
`lifecycle`	production/experimental 구분 → 기술 부채 관리
`annotations`	PagerDuty, GitHub 등 외부 도구 연결

예시 2: 골든 패스 — 선택을 줄여주는 설계

골든 패스는 이 의사결정을 미리 해놓은 겁니다. Backstage의 Software Template 예시를 볼게요:

yaml

# template.yaml (Backstage Software Template 예시)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service-template
  title: Node.js 백엔드 서비스
  description: 팀 표준 Node.js 서비스 스캐폴딩 템플릿
spec:
  owner: platform-team
  type: service
 
  parameters:
    - title: 서비스 기본 정보
      properties:
        name:
          title: 서비스명
          type: string
        owner:
          title: 담당 팀
          type: string
          ui:field: OwnerPicker
 
  steps:
    - id: fetch-template
      name: 템플릿 코드 가져오기
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
 
    - id: publish
      name: GitHub 리포지토리 생성
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=my-org
 
    - id: register
      name: 카탈로그에 등록
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

예시 3: ArgoCD + Crossplane으로 셀프서비스 환경 구성

yaml

# staging-env.yaml (Crossplane Composite Resource 예시)
apiVersion: platform.mycompany.com/v1alpha1
kind: DeveloperEnvironment
metadata:
  name: feature-payment-v2-env
  namespace: team-payments
spec:
  parameters:
    region: ap-northeast-2
    dbSize: db.t3.medium
    clusterSize: small
  compositeDeletePolicy: Foreground  # 리소스 삭제 시 하위 리소스가 모두 정리된 후 완료 처리
  writeConnectionSecretsToNamespace: team-payments

yaml

# ArgoCD Application — Git 변경 감지 → 자동 배포
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: feature-payment-v2
  namespace: argocd
spec:
  project: payments-team
  source:
    repoURL: https://github.com/my-org/environments
    targetRevision: HEAD
    path: teams/payments/feature-payment-v2
  destination:
    server: https://kubernetes.default.svc
    namespace: feature-payment-v2
  syncPolicy:
    automated:
      prune: true      # Git에서 삭제된 리소스를 클러스터에서도 자동 제거
      selfHeal: true   # 클러스터 상태가 Git과 달라지면 자동으로 복원

예시 4: 스코어카드로 운영 성숙도 측정

yaml

# Port 스코어카드 정의 예시 (Port 포털에서 직접 등록)
identifier: service-maturity
title: 서비스 운영 성숙도
levels:
  - color: red
    title: Basic
  - color: gold
    title: Silver
  - color: silver
    title: Gold
rules:
  - identifier: has-catalog-info
    title: 카탈로그 등록 여부
    level: Basic
    query:
      combinator: and
      rules:
        - property: $identifier
          operator: isNotEmpty
  - identifier: has-owner
    title: 오너십 지정
    level: Basic
    query:
      combinator: and
      rules:
        - property: $team
          operator: isNotEmpty
  - identifier: has-runbook
    title: 런북 문서화
    level: Silver
    query:
      combinator: and
      rules:
        - property: runbook_url
          operator: isNotEmpty
  - identifier: has-alerting
    title: PagerDuty 알람 연동
    level: Gold
    query:
      combinator: and
      rules:
        - property: pagerduty_service_id
          operator: isNotEmpty

장단점 분석

장점

항목	내용
배포 속도	배포 빈도 30~50% 개선 (셀프서비스 환경 덕분)
개발자 생산성	인프라 결정·도구 선택 고민 제거로 최대 40% 향상
온보딩 단축	첫 배포까지 걸리는 시간 대폭 감소 (Spotify 60% 향상)
인지 부하 감소	골든 패스로 "어떻게 해야 하지?" 고민 제거
장애 감소	표준화로 Critical incident 약 20% 감소
ROI	185~220% ROI (피처 개발 단독 대비)*

*ROI 수치는 State of Platform Engineering Report Vol.4 (platformengineering.org) 기준입니다.

단점 및 주의사항

항목	내용	대응 방안
초기 투자	Backstage 자체 구축 시 6~~12개월, 유지에 3~~15명 필요	소규모 팀은 Port·Roadie 등 SaaS 검토
채택 문제	UX가 불편하면 개발자가 그냥 안 씀	얼리어답터 팀과 함께 피드백 루프 구성
유연성 딜레마	골든 패스가 너무 경직되면 특수 요구 억제	Escape Hatch 경로 별도 마련
지속 유지보수	기술 스택 변화에 따라 지속 업데이트 필요	분기별 플랫폼 로드맵 수립
조직 합의	다수 이해관계자 조율 필요	초기부터 각 팀 대표를 설계에 참여시키기

DIY vs SaaS: Backstage를 직접 구축·운영하려면 최대 15명의 엔지니어가 필요하다는 연구 결과가 나오면서, Port·Cortex·Roadie 같은 SaaS로 전환하는 조직이 빠르게 늘고 있습니다. "처음부터 직접 만들어야 한다"는 부담은 내려놓으셔도 됩니다.

실무에서 가장 흔한 실수

"만들면 알아서 쓰겠지" 착각: 실제로 제가 겪은 케이스 중에, 6개월을 투자해 훌륭한 포털을 만들었는데 3개월 후 접속자가 한 자리수인 팀이 있었습니다. IDP는 출시 후 개발자가 실제로 쓰기 시작하는 순간부터 시작입니다. 얼리어답터 팀을 잡아 직접 피드백을 받으면서 개선하는 루프가 없으면, 열심히 만든 포털이 아무도 안 쓰는 내부 도구가 됩니다.
조직 문제를 도구로 해결하려는 시도: IDP는 "서비스 오너십이 불명확하다", "배포 프로세스가 복잡하다"는 이미 인지된 문제를 자동화해주는 도구입니다. 팀 간 신뢰 부족이나 책임 불명확 같은 문화 문제는 플랫폼이 해결해주지 않습니다. 실제로 "우리는 도구를 도입했으니 이제 DevOps 됐다"고 생각했다가 혼란이 더 커진 사례를 봤어요. Crossplane이 환경을 자동으로 만들어줘도, 그 환경을 누가 책임지는지 합의가 없으면 아무 소용이 없거든요.
골든 패스를 처음부터 완벽하게 만들려는 욕심: 처음부터 모든 케이스를 커버하려다가 누구도 쓰기 불편한 템플릿이 됩니다. 가장 흔한 80% 케이스만 골든 패스로 만들고, 나머지는 유연하게 열어두는 것이 현실적입니다.

마치며

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

팀 내 페인포인트를 먼저 리스트업해보시면 좋습니다. "배포할 때 뭐가 제일 힘드세요?"를 동료 5명에게 물어보면 IDP에서 가장 먼저 해결해야 할 것이 보입니다. 도구보다 문제 정의가 먼저입니다.
소프트웨어 카탈로그부터 시작해볼 수 있습니다. Backstage를 직접 띄우기 부담스럽다면, Port 무료 티어로 팀 서비스 목록을 등록해보는 것도 좋은 출발점입니다. catalog-info.yaml 파일 하나만 리포에 추가하면 시작됩니다.
골든 패스 템플릿을 하나만 만들어보시는 것도 효과적입니다. 팀에서 가장 자주 만드는 서비스 유형(예: Node.js API 서버)의 표준 스캐폴딩을 Backstage Template 또는 cookiecutter 형태로 정리해두면, 다음 신규 서비스 생성부터 바로 체감이 됩니다.

다음 글: Backstage 플러그인 직접 개발하기 — 우리 팀만의 커스텀 셀프서비스 액션을 TypeScript로 구현하는 방법

핵심 개념

IDP란 무엇인가: "개발자를 위한 원스톱 셀프서비스"

핵심 도구 생태계와 BACK Stack

실전 적용

예시 1: 소프트웨어 카탈로그 — 서비스 오너십 가시화

예시 2: 골든 패스 — 선택을 줄여주는 설계

예시 3: ArgoCD + Crossplane으로 셀프서비스 환경 구성

예시 4: 스코어카드로 운영 성숙도 측정

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

IDP란 무엇인가: "개발자를 위한 원스톱 셀프서비스"

핵심 도구 생태계와 BACK Stack

실전 적용

예시 1: 소프트웨어 카탈로그 — 서비스 오너십 가시화

예시 2: 골든 패스 — 선택을 줄여주는 설계

예시 3: ArgoCD + Crossplane으로 셀프서비스 환경 구성

예시 4: 스코어카드로 운영 성숙도 측정

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

AI 기반 프론트엔드 CI/CD: 예측·자가 치유·자율 테스트로 배포 파이프라인 바꾸기

GitOps로 인프라를 선언적으로 자동화하기 — Argo CD로 배포부터 자동 복구까지

eBPF로 코드 한 줄 안 바꾸고 커널까지 들여다보기 — Kubernetes 관측가능성(Observability) 실전 가이드

OTel spanmetrics 커넥터: 코드 수정 없이 트레이스에서 RED 메트릭을 자동 생성하고 Grafana에 연결하는 방법

Tail Sampling + KEDA: 트래픽 급증에도 트레이스를 놓치지 않는 2계층 OTel 아키텍처

OpenTelemetry Tail Sampling 심화: 복합 정책 설계와 decision_wait로 메모리 최적화하기