IDP 아키텍처의 핵심 구성 요소, 사용자 리서치 기반 설계, Build vs Buy 의사결정, 그리고 MVP부터 점진적 확장까지의 전략을 다룹니다.
1장에서 IDP의 세 계층을 간략히 살펴보았습니다. 이번 장에서는 각 계층을 더 구체적으로 분석하고, 실제 설계에 필요한 의사결정 포인트를 다룹니다.
업계에서 검증된 IDP 참조 아키텍처는 다음 다섯 가지 핵심 영역으로 구성됩니다.
각 영역의 설계 원칙을 하나씩 살펴보겠습니다.
IDP 설계의 출발점은 기술이 아니라 사용자입니다. Platform Engineering에서 사용자는 조직 내 개발자입니다.
조직 내 개발자를 페르소나로 분류하면 각 그룹의 요구사항을 명확히 파악할 수 있습니다.
personas:
- name: "주니어 백엔드 개발자"
experience: "1-3년"
pain_points:
- "Kubernetes 매니페스트 작성이 어렵다"
- "배포 파이프라인 설정에 시간이 많이 걸린다"
- "어떤 서비스가 어디에 배포되어 있는지 모르겠다"
needs:
- "원클릭 배포"
- "서비스 디스커버리"
- "문서화된 온보딩 가이드"
- name: "시니어 풀스택 개발자"
experience: "5-8년"
pain_points:
- "반복적인 인프라 작업에 시간을 뺏긴다"
- "팀마다 다른 도구와 프로세스"
- "비용 가시성 부족"
needs:
- "셀프서비스 인프라 프로비저닝"
- "표준화된 템플릿"
- "비용 대시보드"
- name: "테크 리드 / 아키텍트"
experience: "8년 이상"
pain_points:
- "조직 전체의 기술 스택 파악이 어렵다"
- "보안 정책 일관성 유지가 힘들다"
- "기술 부채 추적이 안 된다"
needs:
- "서비스 의존성 맵"
- "정책 기반 가드레일"
- "성숙도 스코어카드"효과적인 사용자 리서치를 위해 다음 방법을 병행합니다.
1. 개발자 설문조사
정량적 데이터를 수집하기 위한 설문입니다. 주요 질문 항목은 다음과 같습니다.
2. 개발자 인터뷰
설문으로 파악하기 어려운 맥락을 이해하기 위한 심층 인터뷰입니다. "마지막으로 배포할 때 어떤 단계를 거쳤나요?"와 같은 개방형 질문을 통해 실제 워크플로우를 파악합니다.
3. 워크플로우 섀도잉
개발자가 실제로 작업하는 과정을 관찰합니다. 어디서 막히는지, 어떤 문서를 찾는지, 누구에게 질문하는지를 기록합니다.
사용자 리서치는 IDP 구축 초기에만 하는 것이 아닙니다. 분기마다 정기적으로 개발자 만족도를 측정하고, 피드백을 수집하여 플랫폼을 지속적으로 개선해야 합니다.
사용자 리서치 결과를 바탕으로 IDP가 제공해야 할 핵심 역량을 정의합니다.
┌─────────────────────────────────────────────────────┐
│ IDP 역량 매트릭스 │
├──────────────┬──────────────┬───────────────────────┤
│ 카테고리 │ 역량 │ 우선순위 │
├──────────────┼──────────────┼───────────────────────┤
│ 서비스 생성 │ 프로젝트 템플릿 │ P0 (필수) │
│ │ CI/CD 자동 설정 │ P0 (필수) │
│ │ Git 저장소 생성 │ P0 (필수) │
├──────────────┼──────────────┼───────────────────────┤
│ 인프라 관리 │ 환경 프로비저닝 │ P0 (필수) │
│ │ DB 생성 │ P1 (중요) │
│ │ 도메인/TLS 설정 │ P1 (중요) │
├──────────────┼──────────────┼───────────────────────┤
│ 가시성 │ 서비스 카탈로그 │ P0 (필수) │
│ │ 의존성 맵 │ P1 (중요) │
│ │ 비용 대시보드 │ P2 (개선) │
├──────────────┼──────────────┼───────────────────────┤
│ 거버넌스 │ 보안 스캔 자동화 │ P1 (중요) │
│ │ 정책 적용 │ P1 (중요) │
│ │ 성숙도 스코어 │ P2 (개선) │
└──────────────┴──────────────┴───────────────────────┘우선순위를 정할 때는 **임팩트(Impact)**와 **노력(Effort)**의 두 축으로 평가합니다. 많은 개발자에게 영향을 미치면서 구현이 상대적으로 쉬운 역량부터 시작하는 것이 효과적입니다.
IDP를 구축할 때 가장 중요한 의사결정 중 하나는 직접 구축할 것인지, 상용 솔루션을 도입할 것인지를 결정하는 것입니다.
업계 데이터에 따르면, 완전히 자체 구축한(DIY) IDP의 평균 조직 내 도입률은 **약 10%**에 그칩니다. 반면, 잘 설계된 상용 솔루션이나 오픈소스 프레임워크 기반의 IDP는 **60-80%**의 도입률을 달성합니다.
이 격차는 왜 발생할까요?
다음 질문들을 통해 Build vs Buy를 결정합니다.
| 질문 | Build 유리 | Buy 유리 |
|---|---|---|
| 플랫폼 팀 규모 | 5명 이상 전담 | 2-3명 |
| 특수 요구사항 | 높은 커스터마이징 필요 | 표준적인 요구사항 |
| 예산 | 인건비 여유 | 라이선스 비용 여유 |
| 시간 압박 | 여유로움 | 3-6개월 내 결과 필요 |
| 기존 도구 | 교체 대상이 많음 | 기존 도구 통합이 중요 |
"우리 조직은 특별하다"는 생각으로 모든 것을 자체 구축하려는 유혹에 빠지기 쉽습니다. 실제로 IDP의 핵심 기능 중 80%는 조직에 관계없이 동일합니다. 차별화가 필요한 20%에만 커스터마이징을 집중하는 것이 현명합니다.
대부분의 조직에 권장하는 접근법은 Backstage 같은 오픈소스 프레임워크를 기반으로 하되, 조직 특화 기능은 플러그인으로 개발하는 것입니다.
// 조직 특화 플러그인의 예: 내부 비용 대시보드
import { createPlugin, createRoutableExtension } from '@backstage/core-plugin-api';
export const costDashboardPlugin = createPlugin({
id: 'cost-dashboard',
routes: {
root: rootRouteRef,
},
});
export const CostDashboardPage = costDashboardPlugin.provide(
createRoutableExtension({
name: 'CostDashboardPage',
component: () =>
import('./components/CostDashboard').then(m => m.CostDashboard),
mountPoint: rootRouteRef,
}),
);IDP를 처음부터 완벽하게 구축하려는 것은 실패의 지름길입니다. **MVP(Minimum Viable Platform)**부터 시작하여 점진적으로 확장해야 합니다.
MVP에 포함할 핵심 기능은 다음과 같습니다.
mvp:
phase: 1
timeline: "8-12주"
target_users: "2-3개 파일럿 팀"
must_have:
- feature: "서비스 카탈로그"
description: "기존 서비스를 등록하고 조회"
tool: "Backstage Software Catalog"
- feature: "프로젝트 템플릿"
description: "표준 마이크로서비스 생성"
tool: "Backstage Scaffolder"
- feature: "CI/CD 자동 설정"
description: "템플릿에 CI/CD 파이프라인 포함"
tool: "GitHub Actions / ArgoCD"
nice_to_have:
- feature: "기술 문서"
description: "마크다운 기반 자동 문서 생성"
- feature: "비용 가시성"
description: "서비스별 클라우드 비용 표시"
explicitly_excluded:
- "셀프서비스 데이터베이스 프로비저닝"
- "멀티 클라우드 지원"
- "커스텀 대시보드"MVP의 성공 여부를 판단할 명확한 기준을 사전에 정의합니다.
| 지표 | 목표 | 측정 방법 |
|---|---|---|
| 서비스 등록률 | 파일럿 팀 서비스 100% | 카탈로그 등록 서비스 수 |
| 템플릿 사용률 | 신규 서비스의 80%가 템플릿 사용 | Scaffolder 실행 로그 |
| 배포 시간 단축 | 첫 배포까지 4시간 이내 (기존 2일) | 파이프라인 메트릭 |
| 개발자 만족도 | NPS 30 이상 | 분기별 설문 |
MVP 이후의 확장은 단계적으로 이루어져야 합니다.
각 단계의 전환 기준은 다음과 같습니다.
Phase 1 --> Phase 2 전환 조건:
Phase 2 --> Phase 3 전환 조건:
Phase 3 --> Phase 4 전환 조건:
점진적 확장에서 가장 중요한 것은 각 단계에서 피드백을 수집하고 반영하는 것입니다. 기능을 추가하는 속도보다 기존 기능의 품질을 높이는 것이 도입률 향상에 더 효과적입니다.
IDP 설계 과정에서 자주 발생하는 실수와 그 대안을 정리합니다.
플랫폼 팀이 사용자 리서치 없이 기술적으로 "멋진" 기능부터 구현하는 경우입니다. Crossplane으로 멀티 클라우드 추상화를 먼저 구축했지만, 정작 개발자들이 원한 것은 단순한 프로젝트 생성 템플릿이었다는 사례가 대표적입니다.
인프라를 지나치게 추상화하면 개발자가 문제 발생 시 디버깅할 수 없게 됩니다. 추상화 수준은 "개발자가 직접 다루지 않아도 되지만, 필요할 때 내부를 볼 수 있는" 정도가 적절합니다.
플랫폼을 강제로 사용하게 만드는 것은 역효과를 냅니다. 잘 설계된 Golden Path는 강제하지 않아도 80% 이상의 자발적 채택률을 달성합니다. 플랫폼이 매력적이지 않다면 강제가 아니라 개선이 답입니다.
모든 기능을 한꺼번에 출시하는 것은 위험합니다. 파일럿 팀부터 시작하여 검증하고, 점진적으로 확장하는 것이 안전합니다.
이번 장에서는 IDP를 설계하기 위한 체계적인 접근법을 살펴보았습니다.
다음 장에서는 가장 널리 사용되는 개발자 포털인 Backstage를 깊이 있게 다룹니다. Spotify가 만들고 CNCF가 졸업시킨 이 오픈소스 프로젝트의 아키텍처, 설치, 그리고 핵심 기능을 실습합니다.
이 글이 도움이 되셨나요?
Spotify 오픈소스이자 CNCF 졸업 프로젝트인 Backstage의 아키텍처, 설치, 소프트웨어 카탈로그, TechDocs, 플러그인 시스템을 실습합니다.
DevOps의 한계에서 출발한 Platform Engineering의 등장 배경, 인지 부하 감소를 위한 내부 개발자 플랫폼(IDP)의 정의, 그리고 2026년 현황과 트렌드를 살펴봅니다.
Backstage 소프트웨어 카탈로그의 엔티티 모델, catalog-info.yaml 스키마, 메타데이터 표준화, 그리고 Scaffolder를 활용한 프로젝트 자동 생성을 다룹니다.