---
title: Spotify Backstage — Golden Path 기반 사내 scaffolding/template 플랫폼
source_type: company-tech-blog
url: https://backstage.io/docs/features/software-templates/
archive_url:
status: raw
confidence: medium
tags: [ca-tmpl, scaffolding, sample-removal, backstage, golden-path, spotify, idp]
related_branches: [feature-sample-removal-adoption-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Spotify Backstage — Software Templates / Golden Path

> Layer: `raw/company-tech-blogs/` — Spotify Backstage 의 Software Templates 공식 문서 + Golden Path 개념 (Spotify 엔지니어링 블로그).
> 본 raw 는 두 출처 결합: (a) backstage.io 공식 docs (CNCF incubating project) — 공식 vendor 문서 성격, (b) engineering.atspotify.com — 회사 엔지니어링 블로그.
> ca-tmpl 의 sample-removal / adoption 결정의 사례 reference. **"Golden Path = 업계 공식 best practice" 로 격상 금지** — Spotify 사례임.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-sample-removal-adoption-contract]] | dual-mode CI matrix + adoption checklist 를 IDP 플랫폼 (Backstage) 로 자동 강제하는 대안의 reference |
| [[raw/project-notes/ca-skeleton-operational-contract]] | Sample Removal / Project Adoption canonical section 의 IDP 사례 (대안 6) |

## 출처 / Source

- **원본 URL (Backstage Software Templates 공식 문서)**: https://backstage.io/docs/features/software-templates/
- **원본 URL (Golden Path 블로그)**: https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/
- 아카이브 URL: (미수집)
- 저자/조직: Spotify (Backstage 는 CNCF incubating project, Apache-2.0 라이선스)
- 발행일: Software Templates docs = rolling docs / Golden Paths 블로그 = 2020-08
- 라이선스: Apache-2.0
- 마지막 확인일: 2026-05-27

## 왜 저장했는지 / Why archived

ca-tmpl sample removal / adoption 결정에 대한 사례. Backstage 는 "사내 표준 scaffolding 을 internal developer platform (IDP) 에서 일원화" 하는 접근으로, ca-tmpl 이 향후 사내 표준 skeleton 으로 운영될 때 참조 가능한 모델. dual-mode CI matrix / adoption checklist 를 IDP UI/policy 로 강제 가능.

## 핵심 인용 / Key quotes (verbatim)

### Backstage 공식 docs (backstage.io)

> [§Overview] "The Software Templates part of Backstage is a tool that can help you create Components inside Backstage."

> [§Core Functionality] "By default, it has the ability to load skeletons of code, template in some variables, and then publish the template to some locations like GitHub or GitLab."

> [§Best Practices — Action ID Naming] "When creating custom scaffolder actions, use camelCase for action IDs instead of kebab-case."

> [§Getting Started — Access Point] "Software Templates you have imported into Backstage can be found under `/create`."

> [§Template Execution] "Each execution of a template is treated as a unique task, identifiable by its own unique ID."

### Spotify Golden Paths 블로그 (engineering.atspotify.com)

> [§Definition] "The Golden Path is the 'opinionated and supported' path to 'build something'"

> [§Discovery] "The blessed or recommended tooling should be easily discoverable"

> [§Support Boundary] "If you are an adventurer you can of course leave the Golden Path and do your own thing, but then you will not have the same support"

> [§Cognitive Load] "Teams don't have to reinvent the wheel, have fewer decisions to make"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| BACKSTAGE-TMPL-C1 | Backstage Software Templates 는 Backstage 내부에서 Components 를 생성하기 위한 도구 | [§Overview, docs] "The Software Templates part of Backstage is a tool that can help you create Components inside Backstage." | `official-vendor-doc` | Backstage 인스턴스를 운영하는 조직 | Backstage 없이 동일 효과를 얻을 수 없다는 뜻 아님 (cookiecutter, GitHub Template Repository 등 대안 존재) |
| BACKSTAGE-TMPL-C2 | Backstage Templates 는 코드 skeleton 로드 → 변수 templating → GitHub/GitLab 등에 publish 기능 제공 | [§Core Functionality, docs] "By default, it has the ability to load skeletons of code, template in some variables, and then publish the template to some locations like GitHub or GitLab." | `official-vendor-doc` | Backstage scaffolder 기능 사용 시 | GitHub/GitLab 외 다른 SCM (Bitbucket, internal Git) 도 동일하게 지원하는지 본 인용에 명시 없음 |
| BACKSTAGE-TMPL-C3 | 커스텀 scaffolder action ID 는 kebab-case 가 아닌 camelCase 사용 권장 (kebab-case 시 템플릿 표현 NaN 오류) | [§Best Practices, docs] "When creating custom scaffolder actions, use camelCase for action IDs instead of kebab-case." | `official-vendor-doc` | Backstage 커스텀 action 작성 시 | 이는 Backstage 내부 구현 제약 — 일반적인 scaffolder 도구 (cookiecutter 등) 에는 적용되지 않음 |
| BACKSTAGE-TMPL-C4 | Golden Path 는 Spotify 의 "opinionated and supported" 빌드 경로 정의 — 권장 도구 / 빌드 방식 | [§Golden Path Definition, Spotify blog] "The Golden Path is the 'opinionated and supported' path to 'build something'" | `company-case-study` | Spotify 내부 IDP 운영 모델 | Golden Path 가 업계 표준이라는 뜻 아님 — Spotify 사내 용어. **"공식 best practice" 로 격상 금지** |
| BACKSTAGE-TMPL-C5 | Golden Path 이탈 자유는 있으나, 이탈 시 사내 지원을 동일하게 받지 못함 (opt-out 비용 존재) | [§Support, Spotify blog] "If you are an adventurer you can of course leave the Golden Path and do your own thing, but then you will not have the same support" | `company-case-study` | IDP/Golden Path 모델의 거버넌스 trade-off | "강제" 가 아닌 "지원 차등" 모델 — 강제 표준화 모델과 구분 필요 |
| BACKSTAGE-TMPL-C6 | Golden Path 의 이점: 팀이 바퀴를 재발명할 필요 없음, 결정 부담 감소 | [§Cognitive Load, Spotify blog] "Teams don't have to reinvent the wheel, have fewer decisions to make" | `company-case-study` | 결정 피로 (decision fatigue) 가 큰 조직 | 이 이점이 정량 측정값 (개발 속도, 인시던트 감소 등) 으로 본 글에 입증되지는 않음 |

### Strength 주의

- `BACKSTAGE-TMPL-C1` ~ `C3`: backstage.io 공식 docs → `official-vendor-doc` (Backstage 자체에 대한 사양).
- `BACKSTAGE-TMPL-C4` ~ `C6`: Spotify engineering blog → `company-case-study` (Spotify 사내 운영 사례).
- **Golden Path 를 "업계 공식 best practice" 또는 "CNCF 공식 권고" 로 격상 금지**. Backstage 가 CNCF incubating 이지만 Golden Path 는 Spotify 용어이며 backstage.io docs 의 공식 정의가 아님.

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `BACKSTAGE-TMPL-C1` ~ `C3`: Backstage Software Templates 의 공식 사양 (Components 생성, skeleton + templating + publish, action ID camelCase 권장)
  - `BACKSTAGE-TMPL-C4` ~ `C6`: Spotify 의 Golden Path 운영 모델 (opinionated + supported, opt-out 지원 차등, 결정 부담 감소)
- **이 자료가 증명하지 않는 것**:
  - Backstage 가 ca-tmpl 같은 다른 scaffolding 도구보다 운영 성능에서 우월하다는 비교
  - Golden Path 모델이 모든 조직 규모에 적합하다는 일반화 (Spotify 규모 사례)
  - Backstage 인스턴스 운영 비용 / TCO numeric 데이터
  - sample-removal CI matrix 가 Backstage scaffolder action 으로 표현 가능한 구체적 방법
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl skeleton 을 Backstage Template 으로 등록 시 필요한 catalog-info.yaml 사양
  - sample-ticket 포함/제외 input parameter 의 Backstage scaffolder action 구현 방법
  - 1인 또는 소규모 팀에서 Backstage 인스턴스 운영 비용의 합리성 판단

## 메모 / Notes

- 동작 모델: YAML 로 정의된 Template (`backstage.io/v1beta3, kind: Template`) → input parameters → action steps (fetch:template, publish:github, register) → 새 component 생성.
- ca-tmpl 과의 차이: Backstage 자체는 generator 엔진. ca-tmpl skeleton repo 를 Backstage Template 으로 등록하면 사내 표준 진입점이 됨. sample-ticket 포함/제외를 input parameter 로 선택 가능 → ca-tmpl dual-mode CI matrix 결정과 잘 맞물림.
- 강점: scaffolding 뿐 아니라 catalog / ownership / docs 까지 같은 플랫폼에서 관리. ca-tmpl 7-step adoption checklist 일부를 Backstage policy / scaffolder action 으로 자동 강제 가능.
- 약점: Backstage 인스턴스 운영 비용. 1인 또는 소규모 팀 ca-tmpl 단계에서는 과도. 도입 시점은 조직 규모가 임계점에 도달했을 때.
- ca-tmpl 과의 합쳐쓰기 가능 경로: `GitHub Template Repository` 또는 `Cookiecutter` 위에 Backstage Scaffolder 를 entry point 로 얹는 layered 구성.
- 신뢰도: Backstage docs = `official-vendor-doc` (Backstage 사양에 한정). Golden Path 개념 = Spotify `company-case-study`. **Golden Path 를 "업계 공식 best practice" 로 격상 금지**.

## Related / 관련

- 같은 주제 다른 raw: (미작성)
- 인용하는 branch:
  - [[raw/branch-notes/feature-sample-removal-adoption-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]] (Sample Removal / Project Adoption)
- 대안 그룹: **Group H — Sample removal / adoption** — 본 자료는 대안 6 (Backstage Golden Path / IDP 사례)
- 인용한 wiki 요약: (미작성)