Spotify 오픈소스이자 CNCF 졸업 프로젝트인 Backstage의 아키텍처, 설치, 소프트웨어 카탈로그, TechDocs, 플러그인 시스템을 실습합니다.
Backstage는 Spotify가 내부에서 사용하던 개발자 포털을 2020년에 오픈소스로 공개한 프로젝트입니다. 2022년 CNCF Incubating 프로젝트로 승격되었고, 2024년에 Graduated 프로젝트가 되었습니다. 2026년 현재 3,400개 이상의 조직이 Backstage를 채택하고 있습니다.
Backstage가 해결하는 핵심 문제는 개발자 경험의 단편화입니다. 대규모 조직에서 개발자가 매일 사용하는 도구는 수십 가지에 달합니다. CI/CD는 Jenkins에서, 모니터링은 Grafana에서, 문서는 Confluence에서, 인프라 요청은 Jira에서. Backstage는 이 모든 것을 하나의 통합 포털로 모읍니다.
Spotify는 내부적으로 Backstage를 통해 2,000개 이상의 마이크로서비스, 4,000명 이상의 엔지니어를 관리하고 있습니다. 신규 엔지니어의 온보딩 시간이 평균 60% 단축되었다고 보고합니다.
Backstage는 세 가지 핵심 컴포넌트로 구성됩니다.
React 기반의 **SPA(Single Page Application)**입니다. Material UI를 기반으로 하며, 조직의 브랜드에 맞게 테마를 커스터마이징할 수 있습니다. 모든 기능은 플러그인 형태로 제공되며, 프론트엔드 플러그인은 독립적인 React 컴포넌트로 동작합니다.
Node.js 기반의 백엔드 서버입니다. 카탈로그 엔진, 인증 모듈, 검색 엔진 등의 핵심 기능과 백엔드 플러그인이 동작합니다. 각 플러그인은 독립적인 Express 라우터로 구현됩니다.
PostgreSQL을 기본 데이터베이스로 사용합니다. 카탈로그 엔티티, 사용자 정보, 플러그인 데이터 등이 저장됩니다.
Backstage를 설치하기 위해 다음이 필요합니다.
# Node.js 20 이상
node --version
# v20.x.x
# Yarn (Backstage는 Yarn을 기본 패키지 관리자로 사용)
yarn --version
# 4.x.x
# Docker (선택사항, PostgreSQL 실행용)
docker --version# Backstage CLI로 새 앱 생성
npx @backstage/create-app@latest
# 앱 이름 입력
# ? Enter a name for the app: my-company-portal
# 생성된 디렉토리로 이동
cd my-company-portal
# 개발 서버 실행
yarn devyarn dev를 실행하면 프론트엔드(포트 3000)와 백엔드(포트 7007)가 동시에 시작됩니다.
Backstage의 설정은 app-config.yaml에서 관리합니다.
app:
title: "My Company Developer Portal"
baseUrl: http://localhost:3000
organization:
name: "My Company"
backend:
baseUrl: http://localhost:7007
listen:
port: 7007
database:
client: pg
connection:
host: localhost
port: 5432
user: backstage
password: ${POSTGRES_PASSWORD}
integrations:
github:
- host: github.com
token: ${GITHUB_TOKEN}
auth:
environment: development
providers:
github:
development:
clientId: ${GITHUB_CLIENT_ID}
clientSecret: ${GITHUB_CLIENT_SECRET}
catalog:
import:
entityFilename: catalog-info.yaml
pullRequestBranchName: backstage-integration
rules:
- allow: [Component, System, API, Resource, Location, Domain, Group, User]
locations:
- type: file
target: ../../examples/entities.yaml
- type: file
target: ../../examples/template/template.yaml
rules:
- allow: [Template]app-config.yaml에 민감한 정보(토큰, 비밀번호)를 직접 넣지 마세요. 환경 변수 치환 문법(${ENV_VAR})을 사용하거나, app-config.local.yaml(gitignore에 포함)에 로컬 설정을 분리하세요.
프로덕션 환경에서는 추가 설정이 필요합니다.
app:
baseUrl: https://backstage.mycompany.com
backend:
baseUrl: https://backstage-api.mycompany.com
database:
client: pg
connection:
host: ${POSTGRES_HOST}
port: 5432
user: ${POSTGRES_USER}
password: ${POSTGRES_PASSWORD}
plugin:
catalog:
connection:
database: backstage_plugin_catalog
auth:
connection:
database: backstage_plugin_auth
auth:
environment: production
providers:
github:
production:
clientId: ${GITHUB_CLIENT_ID}
clientSecret: ${GITHUB_CLIENT_SECRET}**Software Catalog(소프트웨어 카탈로그)**는 Backstage의 핵심 기능입니다. 조직 내 모든 소프트웨어 자산(서비스, API, 라이브러리, 문서 등)을 중앙에서 관리합니다.
카탈로그에 엔티티를 등록하려면 프로젝트 루트에 catalog-info.yaml 파일을 작성합니다.
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: user-service
description: "사용자 인증 및 프로필 관리 서비스"
annotations:
github.com/project-slug: mycompany/user-service
backstage.io/techdocs-ref: dir:.
tags:
- java
- spring-boot
- grpc
links:
- url: https://grafana.mycompany.com/d/user-service
title: Grafana Dashboard
icon: dashboard
spec:
type: service
lifecycle: production
owner: team-auth
system: user-management
dependsOn:
- resource:default/user-database
- component:default/notification-service
providesApis:
- user-apiBackstage의 카탈로그는 다양한 종류의 엔티티를 지원합니다. 주요 엔티티 종류는 4장에서 자세히 다루지만, 여기서 간략히 소개합니다.
| Kind | 설명 | 예시 |
|---|---|---|
| Component | 소프트웨어 컴포넌트 | 마이크로서비스, 라이브러리, 웹사이트 |
| API | API 정의 | REST API, gRPC, GraphQL |
| Resource | 인프라 리소스 | 데이터베이스, S3 버킷, 메시지큐 |
| System | 관련 컴포넌트의 집합 | 사용자 관리 시스템 |
| Domain | 비즈니스 도메인 | 결제, 배송, 회원 |
| Group | 팀/조직 | backend-team, platform-team |
| User | 개발자 개인 | 조직 구성원 |
TechDocs는 Backstage에 내장된 기술 문서 시스템입니다. "docs-like-code" 접근법을 따르며, 마크다운으로 작성한 문서를 자동으로 빌드하여 Backstage 포털 내에서 제공합니다.
프로젝트에 TechDocs를 추가하려면 두 가지가 필요합니다.
1. mkdocs.yml 설정 파일
site_name: User Service
site_description: "사용자 인증 및 프로필 관리 서비스 문서"
nav:
- Home: index.md
- Architecture: architecture.md
- API Reference: api-reference.md
- Runbook: runbook.md
- ADR:
- "ADR-001: 인증 방식 선택": adr/001-auth-method.md
- "ADR-002: 데이터베이스 선택": adr/002-database-choice.md
plugins:
- techdocs-core2. docs 디렉토리에 마크다운 파일 작성
user-service/
catalog-info.yaml
mkdocs.yml
docs/
index.md
architecture.md
api-reference.md
runbook.md
adr/
001-auth-method.md
002-database-choice.mdTechDocs는 두 가지 빌드 방식을 지원합니다.
| 방식 | 장점 | 단점 | 적합한 환경 |
|---|---|---|---|
| 로컬 빌드 | 설정 간단 | Backstage 서버에 부하 | 소규모, 개발 환경 |
| 외부 빌드 | 서버 부하 없음 | CI/CD 설정 필요 | 프로덕션 |
프로덕션에서는 CI/CD 파이프라인에서 문서를 빌드하고 S3 같은 외부 스토리지에 저장하는 외부 빌드 방식을 권장합니다.
techdocs:
builder: external
generator:
runIn: local
publisher:
type: awsS3
awsS3:
bucketName: mycompany-techdocs
region: ap-northeast-2
credentials:
roleArn: arn:aws:iam::123456789012:role/techdocs-publisherBackstage의 강력함은 플러그인 아키텍처에서 나옵니다. 모든 기능이 플러그인으로 구현되어 있으며, 커뮤니티에서 100개 이상의 플러그인을 제공합니다.
| 플러그인 | 기능 | 카테고리 |
|---|---|---|
@backstage/plugin-kubernetes | Kubernetes 리소스 조회 | 인프라 |
@backstage/plugin-github-actions | GitHub Actions 상태 | CI/CD |
@backstage/plugin-pagerduty | PagerDuty 인시던트 | 운영 |
@backstage/plugin-cost-insights | 비용 인사이트 | FinOps |
@backstage/plugin-lighthouse | Lighthouse 성능 점수 | 품질 |
@backstage/plugin-sonarqube | SonarQube 코드 품질 | 품질 |
@backstage/plugin-grafana | Grafana 대시보드 | 모니터링 |
조직 특화 기능은 커스텀 플러그인으로 개발합니다.
# 프론트엔드 플러그인 생성
yarn new --select plugin
# 백엔드 플러그인 생성
yarn new --select backend-plugin프론트엔드 플러그인의 기본 구조는 다음과 같습니다.
import {
createPlugin,
createRoutableExtension,
} from '@backstage/core-plugin-api';
import { rootRouteRef } from './routes';
export const myPlugin = createPlugin({
id: 'my-plugin',
routes: {
root: rootRouteRef,
},
});
export const MyPluginPage = myPlugin.provide(
createRoutableExtension({
name: 'MyPluginPage',
component: () =>
import('./components/MyPluginPage').then(m => m.MyPluginPage),
mountPoint: rootRouteRef,
}),
);import React from 'react';
import { Typography, Grid } from '@material-ui/core';
import {
Header,
Page,
Content,
ContentHeader,
SupportButton,
} from '@backstage/core-components';
export function MyPluginPage() {
return (
<Page themeId="tool">
<Header title="My Custom Plugin" subtitle="조직 특화 기능" />
<Content>
<ContentHeader title="Overview">
<SupportButton>플랫폼 팀에 문의</SupportButton>
</ContentHeader>
<Grid container spacing={3}>
<Grid item xs={12}>
<Typography variant="body1">
커스텀 플러그인 콘텐츠가 여기에 표시됩니다.
</Typography>
</Grid>
</Grid>
</Content>
</Page>
);
}커스텀 플러그인 개발 시, Backstage의 디자인 시스템(@backstage/core-components)을 활용하면 일관된 UI를 유지할 수 있습니다. 독자적인 UI 컴포넌트를 만들기보다 기존 컴포넌트를 재사용하는 것을 권장합니다.
Backstage를 프로덕션에서 운영할 때 주의해야 할 사항들입니다.
Backstage는 지속적인 투자가 필요한 프로젝트입니다. 업스트림 업데이트를 정기적으로 반영해야 하며, 플러그인 호환성도 관리해야 합니다. 전담 인력 1-2명이 필수적입니다.
카탈로그에 등록된 엔티티가 수천 개를 넘어가면 검색 성능이 저하될 수 있습니다. PostgreSQL 인덱스 최적화와 검색 엔진(Elasticsearch/OpenSearch) 도입을 고려해야 합니다.
프로덕션 환경에서는 적절한 인증 프로바이더(GitHub, Google, Okta 등)와 RBAC(Role-Based Access Control) 설정이 필수입니다.
permission:
enabled: true
rbac:
admin:
superUsers:
- name: user:default/platform-admin
policies:
- permission: catalog.entity.read
effect: allow
conditions:
allOf:
- resourceType: catalog-entity
- permission: catalog.entity.delete
effect: deny
conditions:
not:
allOf:
- claim: groups
value: platform-team이번 장에서는 Backstage의 전반적인 아키텍처와 설치, 핵심 기능을 살펴보았습니다.
다음 장에서는 소프트웨어 카탈로그를 깊이 있게 다룹니다. catalog-info.yaml의 상세 스키마, 엔티티 모델, 메타데이터 표준화, 그리고 소프트웨어 템플릿(Scaffolder)을 통한 프로젝트 자동 생성까지 살펴보겠습니다.
이 글이 도움이 되셨나요?
Backstage 소프트웨어 카탈로그의 엔티티 모델, catalog-info.yaml 스키마, 메타데이터 표준화, 그리고 Scaffolder를 활용한 프로젝트 자동 생성을 다룹니다.
IDP 아키텍처의 핵심 구성 요소, 사용자 리서치 기반 설계, Build vs Buy 의사결정, 그리고 MVP부터 점진적 확장까지의 전략을 다룹니다.
Golden Path의 정의와 철학, 옵셔널하되 매력적인 경로 설계, Terraform/Pulumi 기반 자동 인프라 프로비저닝, 그리고 80% 이상 자발적 채택률의 비결을 다룹니다.