플랫폼 엔지니어링·내부 개발자 플랫폼(IDP) 실전 - Backstage·Port·Humanitec로 셀프서비스 포털 구축하기

들어가며

지난 #139 DevSecOps 파이프라인 통합까지로 보안·프라이버시·CI/CD가 한 줄의 PR에서 자동 작동하는 모습을 그렸습니다. 그런데 한 단계 더 올라가면 같은 질문이 다시 옵니다. "이 모든 것을 신규 서비스가 첫날부터 갖추게 하려면 어떻게 하는가?"

2026년 Gartner는 "대형 조직의 80%가 2027년까지 플랫폼 엔지니어링 팀을 운영할 것"이라고 예측했고, State of Platform Engineering 2025 보고서는 IDP를 도입한 조직이 리드타임을 평균 41% 단축했다고 보고했습니다. "어디 어디 보안팀", "어디 어디 SRE팀"이 따로 노는 시대에서, 제품팀이 셀프서비스로 모든 인프라·보안·관측을 받는 시대로 옮겨가는 중입니다.

오늘은 그 핵심 도구인 플랫폼 엔지니어링과 내부 개발자 플랫폼(IDP)을 실전 관점에서 정리합니다.

• 1부 - DevOps와 Platform Engineering의 차이
• 2부 - IDP의 4대 구성요소
• 3부 - Backstage 깊이 보기 - 카탈로그·템플릿·플러그인
• 4부 - Port·Humanitec·CNOE 비교
• 5부 - Golden Path - 신규 서비스가 30분 만에 프로덕션에 도달하는 법
• 6부 - 보안·관측·배포·시크릿을 IDP에 녹이기
• 7부 - DORA·SPACE·DX-30 메트릭으로 효과 입증
• 8부 - 도입 로드맵과 흔한 실패

1. DevOps와 Platform Engineering의 차이

혼용되지만 발상이 다릅니다.

축	DevOps (2010~)	Platform Engineering (2022~)
핵심 가정	"You build it, you run it" - 모든 팀이 자체 운영	"인프라·운영을 제품으로 - 사용자는 개발팀"
운영 주체	제품팀 자체	전담 플랫폼팀 + 제품팀 셀프서비스
인지 부하	높음 (모두가 K8s·CI·관측 알아야 함)	낮음 (Golden Path로 추상화)
표준화	팀별 다양	중앙 표준 + 예외 합의
보안 통합	각 팀이 책임	플랫폼이 "기본값"으로 강제
주요 산출물	러너·파이프라인	개발자 포털·Golden Path·SDK
측정	배포 빈도·MTTR	+ 개발자 만족도(DX), 인지 부하

DevOps의 한계는 인지 부하의 폭발이었습니다. K8s·Terraform·Vault·Prometheus·OpenTelemetry·Cosign·OPA를 모든 백엔드 개발자가 다 알아야 하는 시점이 오면, 그건 더 이상 지속 가능한 모델이 아닙니다. 플랫폼 엔지니어링은 그 부하를 플랫폼팀이 한 번만 풀어두는 구조로 옮기는 답입니다.

1-1. "Team Topologies" 모델

매튜 스켈튼·마누엘 페이스의 Team Topologies가 2026년 플랫폼 엔지니어링의 정신적 토대입니다. 4가지 팀 유형:

• Stream-aligned team - 제품 가치 흐름에 정렬된 팀(앱·서비스 개발팀)
• Platform team - 셀프서비스 가능한 내부 플랫폼 제공
• Enabling team - 일시적 코칭·전수(보안·SRE 컨설팅)
• Complicated-subsystem team - 깊은 전문성 필요 영역(검색·결제·ML)

가장 중요한 원칙은 "Platform team은 내부 고객이 있는 제품팀"이라는 것입니다. NPS·만족도·사용량으로 측정되고, 안 쓰이면 폐기됩니다. "중앙에서 강제로 깐다"는 발상은 거의 항상 실패합니다.

2. IDP의 4대 구성요소

모든 IDP는 4가지 층으로 분해됩니다.

층	역할	대표 도구
Developer Portal (UI)	개발자가 보는 단일 진입점	Backstage, Port, Cortex
Service Catalog	모든 서비스·소유자·의존성 메타데이터	Backstage Catalog, Port Blueprint
Platform Orchestrator	리소스 프로비저닝 자동화	Humanitec, Crossplane, Kratix
Golden Path	표준 템플릿 + 정책 + 가이드	Backstage Software Templates

흔한 오해는 "Backstage = IDP"입니다. Backstage는 Portal + Catalog + Templates는 잘 하지만 Orchestrator(실제 클라우드 리소스 생성)는 약합니다. 그래서 2026년 표준 조합은 Backstage(개발자 UI) + Crossplane/Humanitec(오케스트레이터)입니다.

2-1. CNCF의 IDP 표준화 - Score 사양

2024년 등장한 Score는 "개발자가 작성하는 워크로드 사양 표준"입니다. K8s 매니페스트가 너무 복잡해서 개발자가 직접 쓰면 안 된다는 인식의 결과물입니다.

# score.yaml - 개발자가 작성
apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  app:
    image: ghcr.io/myorg/orders-api:1.4.2
    variables:
      DB_URL: ${resources.db.uri}
resources:
  db:
    type: postgres
  cache:
    type: redis

플랫폼이 이 80줄짜리 의도를 받아 800줄짜리 K8s 매니페스트 + Helm + Terraform으로 변환합니다. 개발자는 "무엇이 필요한가"만 적고, 플랫폼이 "어떻게 만드는가"를 책임집니다.

3. Backstage 깊이 보기

Spotify가 2020년 오픈소스화한 Backstage는 2026년 기준 가장 표준적인 IDP 프레임워크입니다. CNCF Incubating 프로젝트이고, GitHub 별 30,000+, 350개 이상 기업이 도입.

3-1. 핵심 개념

개념	설명
Component	실행되는 서비스·라이브러리·웹사이트
API	Component가 제공/소비하는 인터페이스
System	여러 Component의 묶음(논리적 도메인)
Domain	여러 System의 묶음(예: "Payments")
Resource	인프라 리소스(DB, S3 버킷, Kafka 토픽)
Group/User	소유자·팀

3-2. catalog-info.yaml - 서비스 등록

# 각 레포의 catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: orders-api
  description: 주문 도메인 API
  annotations:
    github.com/project-slug: myorg/orders-api
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/integration-key: PXXX
    grafana/dashboard-selector: "service=orders-api"
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: payments
  providesApis:
    - orders-rest-v1
  dependsOn:
    - resource:postgres-orders
    - component:auth-svc

이 한 파일이 모든 메타데이터의 진실의 원천이 됩니다. PagerDuty 연동·Grafana 대시보드·소유 팀·의존성이 한 곳에서 관리됩니다.

3-3. Software Templates - Golden Path의 시작

# template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: spring-boot-microservice
  title: Spring Boot 마이크로서비스
  description: |
    표준 Spring Boot 서비스 - DevSecOps 파이프라인·관측·배포 포함
spec:
  parameters:
    - title: 기본 정보
      properties:
        name:
          type: string
          pattern: '^[a-z][a-z0-9-]+$'
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch-skeleton
      name: 스켈레톤 가져오기
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish-github
      name: GitHub 레포 생성
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
        repoVisibility: internal
    - id: register-catalog
      name: 카탈로그 등록
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['publish-github'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

이 템플릿이 만들어내는 결과물은 다음을 모두 포함합니다.

• 표준 디렉터리 구조 + Spring Boot 4 + Java 21
• DevSecOps GitHub Actions 워크플로우(#139)
• OpenTelemetry 자동 계측(#110)
• Vault 동적 시크릿 어노테이션(#133)
• Helm 차트 + ArgoCD 배포 매니페스트
• Grafana 대시보드 자동 생성
• PagerDuty 서비스 등록
• Backstage 카탈로그 자동 등록

30분 안에 신규 서비스가 프로덕션 가능한 상태가 됩니다. 이게 "Golden Path"의 실제 모습입니다.

3-4. TechDocs - 코드 옆에 사는 문서

각 레포의 docs/에 마크다운을 두면 Backstage UI에서 자동 렌더링됩니다. MkDocs 기반이라 다이어그램·코드 하이라이팅·검색이 기본 제공됩니다. "문서가 코드에서 멀어질수록 죽는다"는 원칙의 도구적 답입니다.

3-5. 플러그인 생태계

카테고리	대표 플러그인
CI/CD	GitHub Actions, GitLab, Argo CD, Jenkins
관측	Grafana, Prometheus, Datadog, New Relic
온콜	PagerDuty, Opsgenie
보안	Snyk, SonarQube, Dependabot
클라우드	AWS·Azure·GCP, Crossplane
AI	Spotify Lighthouse, Backstage AI Assistant

2026년 등장한 Backstage AI Assistant는 카탈로그·문서·로그를 컨텍스트로 한 LLM 어시스턴트입니다. "MCP로 사내 시스템을 AI에 연결"의 실제 구현체이기도 합니다.

4. Port·Humanitec·CNOE 비교

Backstage가 "open framework"라면, 시간을 사고 싶은 조직에는 다른 선택지도 있습니다.

항목	Backstage	Port	Humanitec	CNOE
방식	오픈소스 프레임워크	SaaS Low-code	SaaS Orchestrator	오픈소스 레퍼런스 아키
러닝커브	가파름 (TypeScript 코드 작성)	완만 (UI 빌더)	완만	가파름
강점	완전 커스텀, 거대 생태계	빠른 도입, 대시보드	리소스 프로비저닝	오픈 + 통합 청사진
약점	유지보수 인력 필요	벤더 종속	UI는 별도 필요	구축 직접
적합	50명+ 플랫폼팀	중소·중견	K8s 중심 멀티클라우드	오픈 표준 우선

실무 패턴은 Backstage(UI) + Crossplane(Orchestrator) + Argo CD(GitOps) 조합이 가장 빈번합니다. CNCF가 후원하는 CNOE(Cloud Native Operational Excellence)는 이 조합의 "레퍼런스 청사진"이고, AWS·Adobe·Bloomberg·Twilio가 공동으로 표준화 중입니다.

4-1. Crossplane - K8s가 클라우드 컨트롤 플레인이 되는 일

# DB 한 줄 요청 - Crossplane Composite Resource
apiVersion: platform.example.com/v1
kind: PostgresCluster
metadata:
  name: orders-db
spec:
  size: small
  region: ap-northeast-2
  highAvailability: true

플랫폼팀이 정의한 Composition이 이 한 장을 받아 RDS Instance·Subnet Group·Security Group·KMS Key·IAM Role·Parameter Store 항목을 모두 생성합니다. 개발자는 80줄을 안 쓰고, 플랫폼이 알아서 합니다.

5. Golden Path

"Paved road"라고도 불립니다. "보안·관측·배포·시크릿이 기본값으로 갖춰진 표준 경로"입니다. 벗어날 수는 있지만 벗어날 이유가 없게 만드는 게 목표입니다.

5-1. Spring Boot Golden Path 예시

$ backstage create spring-boot-svc orders-api
  ↓ (30초)
[1/8] GitHub 레포 생성
[2/8] Spring Boot 4 + Java 21 스켈레톤
[3/8] DevSecOps 워크플로우 (#139)
[4/8] Helm 차트 + ArgoCD ApplicationSet
[5/8] OpenTelemetry 계측 + Grafana 대시보드
[6/8] Vault 동적 시크릿 어노테이션
[7/8] PagerDuty 서비스 + 온콜 로테이션
[8/8] Backstage 카탈로그 등록

✓ https://github.com/myorg/orders-api
✓ https://backstage.example.com/catalog/default/component/orders-api
✓ 첫 PR 머지 시 자동 배포 (dev → staging)

30분 만에 신규 서비스가 프로덕션 직전까지 도달합니다. 같은 일을 사람이 수동으로 하면 평균 3~5일입니다. ROI가 압도적입니다.

5-2. Golden Path 설계의 5원칙

• 완전성보다 신선도 - 5개 시나리오만 완벽하게. 50개 시나리오 미흡 < 5개 시나리오 완벽.
• 벗어날 자유 - "꼭 써야 함"이 아니라 "기본값". 다른 길을 갈 수는 있다.
• 업데이트 주기 - 분기마다 템플릿 자체가 PR로 갱신된다.
• 단일 진실 원천 - 같은 정보가 두 곳에 있으면 결국 어긋난다.
• 측정 가능 - "몇 % 서비스가 Golden Path를 따르는가"가 메트릭.

6. 보안·관측·배포·시크릿을 IDP에 녹이기

플랫폼 엔지니어링의 진짜 가치는 "지난 글에서 다룬 모든 통제가 자동으로 들어가는 일"입니다.

6-1. 통합 매트릭스

영역	도구	IDP 통합 방식
SAST·SCA·SBOM	Semgrep·Trivy·Syft (#132·#139)	Software Template에 워크플로우 포함
이미지 서명·검증	Cosign·Kyverno (#132)	표준 빌드·배포 단계에 박힘
시크릿	Vault·KMS (#133)	Pod 어노테이션 자동 주입
네트워크 정책	Istio·SPIFFE (#134)	NetworkPolicy 템플릿 자동 생성
관측	OpenTelemetry·Prometheus (#110·#93)	Auto-instrumentation 의존성 추가
탐지·대응	Falco·SIEM (#135·#137)	SIEM 경보가 PR에 자동 코멘트
프라이버시	KMS·CMP (#138)	PII 라벨 어노테이션 + 정책 검증
배포	Argo CD·Flux	ApplicationSet 자동 생성

플랫폼팀이 한 번 정의해두면, 모든 신규 서비스가 첫날부터 위 9개 통제를 모두 갖춥니다. 사람이 "잊지 않고 추가"하기를 기대하는 구조와 비교 불가의 신뢰도입니다.

6-2. "Default Secure"의 의미

플랫폼 엔지니어링의 핵심 슬로건은 "Make the right thing the easy thing"입니다. 보안은 "잊지 말고 해야 하는 것"에서 "하지 않으려면 노력이 드는 것"으로 바뀝니다.

7. DORA·SPACE·DX-30 메트릭

IDP 도입의 효과는 측정 가능해야 합니다. 2026년 기준 표준 메트릭은 셋입니다.

7-1. DORA 4지표 (Google)

지표	Elite	High	Medium	Low
배포 빈도	온디맨드	주~일	주~월	월 미만
리드타임	< 1시간	일~주	주~월	월 이상
변경 실패율	0~15%	16~30%	16~30%	16~30%
복구 시간(MTTR)	< 1시간	일 미만	일~주	주 이상

7-2. SPACE - 5차원 개발자 경험

• Satisfaction - 만족도·번아웃
• Performance - 결과물·품질
• Activity - PR·커밋·리뷰 수
• Communication - 협업·지식공유
• Efficiency - 흐름·인지부하

7-3. DX-30 (DX.com / 2024)

DORA·SPACE보다 플랫폼 효과를 직접 측정하는 30개 질문 묶음입니다. "코드 리뷰 대기 시간", "배포 신뢰도", "문서 발견성", "개발 환경 안정성" 등 IDP가 직접 영향을 주는 지표가 모입니다.

현실적 운영 패턴은 DORA(객관) + DX-30(주관) 분기 측정입니다. DORA만 보면 "숫자는 좋은데 개발자가 지친" 상태를 못 봅니다. DX-30이 그 공백을 메웁니다.

7-4. 인지 부하(Cognitive Load) 직접 측정

"이번 분기에 기억해야 했던 도구·언어·시스템의 수"를 분기마다 설문으로 잰 뒤, 평균이 줄어드는 추세인지 확인합니다. 늘어나면 플랫폼이 추상화에 실패하고 있다는 신호입니다.

8. 도입 로드맵

8-1. 분기별 단계

분기	목표	성공 지표
Q1	Backstage 설치 + 카탈로그 시드 (수기 30개 등록)	전 서비스의 80% 카탈로그 등재
Q2	첫 Golden Path 1개 (대표 언어/스택)	신규 서비스 100% 템플릿 사용
Q3	관측·시크릿·DevSecOps 통합	9대 통제 자동 주입
Q4	Crossplane 인프라 셀프서비스	DB·Kafka·S3 셀프 프로비저닝
다음 해	2~3개 Golden Path + AI 어시스턴트	DORA Elite, DX-30 +20점

8-2. 플랫폼팀의 첫 5명

• Tech Lead - 아키텍처·로드맵
• Backstage 풀스택 - 포털 빌드 (TypeScript)
• 인프라/SRE - Crossplane·K8s
• DevSecOps - CI/CD·보안 통합
• DX/PM - 내부 고객 인터뷰·우선순위·문서

마지막 DX 역할이 가장 흔히 빠지고, 가장 흔한 실패 원인입니다. 플랫폼이 "제품"이 되려면 PM이 있어야 합니다.

9. 흔한 실패 패턴

• 중앙에서 강제로 깐다 - "이거 안 쓰면 안 됨". 강제는 단기엔 효과적이지만 장기적으로 불만이 누적되어 사보타주가 일어남. "Paved road"는 강제가 아니라 "가장 쉬운 길".
• 완벽한 첫 릴리스를 노림 - 1년 동안 만들고 쓸모없는 게 나옴. 4주 내 첫 베타·5명 사용자가 정석.
• 플랫폼팀이 내부 고객 인터뷰를 안 함 - "이게 좋아 보이는데 쓰는 사람이 없네"가 1순위 실패 원인. 분기 NPS·월간 사용자 수가 KPI.
• Golden Path가 너무 많음 - 5개 언어·5개 스택 모두 지원하려다 어느 것도 완성도 못 갖춤. 우선 1개에 100% 투자.
• Backstage를 위키처럼 사용 - 카탈로그·플러그인 활용 없이 그냥 문서 사이트. TechDocs·CI 통합·ServiceNow 통합 등 진짜 가치 영역을 미사용.
• 오케스트레이터 없이 UI만 만듦 - 클릭하면 티켓이 생성되어 사람이 처리. 셀프서비스가 아님. Crossplane·Humanitec 등 실제 프로비저닝 레이어 필수.
• 측정하지 않음 - DORA·DX-30이 없으면 ROI 입증 불가, 다음 해 예산 삭감. 첫날부터 베이스라인 측정.
• 플랫폼팀이 SRE팀과 같은 사람들로 구성 - 운영 사고가 터지면 플랫폼 일이 멈춤. 책임 분리가 핵심.
• 레거시 마이그레이션을 첫 목표로 - 기존 100개 서비스를 모두 IDP에 등록하려다 6개월 소진. 신규 서비스부터 100% 적용 → 자연스러운 흐름이 정석.
• AI 어시스턴트를 너무 일찍 도입 - 카탈로그 데이터가 부실한 상태에서 LLM 답변은 환각 천국. 카탈로그·문서 품질이 선행 조건.

10. 체크리스트

• [ ] 모든 서비스가 Backstage 카탈로그에 등재되어 있다
• [ ] 각 서비스는 catalog-info.yaml로 소유자·의존성·관측 링크를 선언한다
• [ ] 최소 1개 Golden Path가 운영 중이고 신규 서비스 80% 이상이 따른다
• [ ] Software Template에 DevSecOps·관측·시크릿이 기본 포함된다
• [ ] Crossplane 또는 Humanitec으로 인프라 셀프 프로비저닝이 가능하다
• [ ] TechDocs로 코드 옆 문서가 자동 렌더링된다
• [ ] PagerDuty·Grafana·SonarQube 등 핵심 도구가 플러그인으로 통합돼 있다
• [ ] 분기마다 DORA + DX-30 측정이 이루어진다
• [ ] 플랫폼팀에 DX/PM 역할이 존재한다
• [ ] 내부 고객 NPS·월간 사용자 수가 KPI에 포함돼 있다

11. 보안·플랫폼·운영의 위치

축	관점	대표 도구	본 글
OWASP·SBOM·서명	코드와 아티팩트의 무결성	Trivy·Cosign	#131·#132
Secrets·Zero Trust	자격증명·네트워크	Vault·Istio	#133·#134
Runtime·SIEM/SOAR	탐지·대응	Falco·Elastic·Tines	#135·#137
Privacy	사람의 데이터	KMS·CMP·삭제권	#138
DevSecOps Pipeline	한 줄 PR에 통합	GitHub Actions + 9대 통제	#139
Platform Engineering	제품팀의 셀프서비스	Backstage·Crossplane	오늘

지금까지의 모든 통제·도구가 제품팀이 아무 노력 없이 받는 기본값이 되는 자리가 IDP입니다. 보안 7층이 "강제"에서 "선물"로 바뀌는 지점입니다.

마치며

플랫폼 엔지니어링·IDP의 핵심을 정리합니다.

• 플랫폼은 제품이고, 내부 고객이 있습니다. "중앙에서 강제로 깐다"는 발상은 거의 항상 실패합니다. NPS·만족도·사용량으로 측정되고, 안 쓰이면 폐기되는 진짜 제품의 룰을 따라야 합니다.
• Backstage = IDP가 아닙니다. Backstage는 Portal·Catalog·Templates를 잘 하지만 실제 클라우드 리소스 생성은 약합니다. 2026년 표준은 Backstage(UI) + Crossplane/Humanitec(Orchestrator) + Argo CD(GitOps)의 조합입니다.
• Golden Path는 강제가 아니라 "가장 쉬운 길"입니다. 벗어날 수 있지만 벗어날 이유가 없게 만드는 게 목표입니다. 5개 시나리오 미흡보다 1개 시나리오 완벽이 훨씬 큰 가치를 줍니다.
• Score 같은 추상화가 K8s 매니페스트의 미래입니다. 80줄짜리 의도를 800줄짜리 매니페스트로 변환하는 일은 플랫폼이 책임지고, 개발자는 "무엇이 필요한가"만 적습니다. 이 분리가 인지 부하를 낮추는 핵심입니다.
• DevSecOps의 모든 통제가 IDP에서 "기본값"이 됩니다. SAST·SBOM·Cosign·Vault·Istio·OTel·Falco·SIEM·KMS의 9대 통제가 신규 서비스의 첫날부터 자동 주입됩니다. "잊지 않고 추가"하기에 의존하는 구조와 비교 불가의 신뢰도입니다.
• 측정하지 않는 플랫폼은 다음 해 예산을 잃습니다. DORA(객관) + DX-30(주관)을 첫날부터 베이스라인으로 잡고 분기마다 추적해야 ROI를 입증할 수 있습니다. 인지 부하 추세도 같은 분기 설문에 포함해야 추상화 실패를 조기에 감지합니다.
• 레거시 마이그레이션을 첫 목표로 잡지 않습니다. 신규 서비스부터 100% 적용해 1년 뒤 자연스러운 다수가 되도록 만드는 흐름이 정석입니다. 기존 100개를 한 번에 옮기려는 시도는 6개월 안에 동력을 잃습니다.

이로써 보안 7층 + DevSecOps 통합 + 플랫폼 엔지니어링까지 현대 백엔드 엔지니어링의 운영 시스템이 한 줄로 이어졌습니다. 다음 편에서는 시점을 또 한 번 바꿔, 모든 코드와 인프라가 자동화된 자리에서 마지막으로 남는 인간의 역할 - SRE·온콜·인시던트 매니지먼트 실전 - 무엇을 자동화하고 무엇은 사람이 결정하는가를 다룰 예정입니다. 기술이 더 발전할수록, "사람이 정확히 무엇을 결정해야 하는가"의 경계는 더 또렷해져야 합니다.