플랫폼 팀의 구조와 Team Topologies 적용, 채택률 측정과 개선, 개발자 만족도(NPS), 이해관계자 관리, 그리고 플랫폼 성숙도 모델을 다룹니다.
Team Topologies는 Matthew Skelton과 Manuel Pais가 제안한 조직 설계 프레임워크입니다. 이 프레임워크에서 정의하는 네 가지 팀 유형 중, 플랫폼 팀은 고유한 위치를 차지합니다.
| 팀 유형 | 역할 | 플랫폼 관점 |
|---|---|---|
| Stream-aligned | 비즈니스 가치를 직접 전달하는 팀 | 플랫폼의 주요 사용자 |
| Enabling | 다른 팀의 역량을 높이는 팀 | 플랫폼 팀이 Enabling 역할 겸임 가능 |
| Complicated Subsystem | 전문 지식이 필요한 하위시스템 담당 | ML 플랫폼, 데이터 플랫폼 등 |
| Platform | 내부 서비스를 제공하는 팀 | IDP를 구축하고 운영 |
플랫폼 팀의 책임을 명확히 정의하는 것이 중요합니다. 범위가 모호하면 플랫폼 팀이 "무엇이든 해주는 팀"으로 전락합니다.
team:
name: "Platform Engineering Team"
mission: "개발자가 비즈니스 로직에 집중할 수 있도록 셀프서비스 인프라와 도구를 제공한다"
responsibilities:
core:
- "내부 개발자 플랫폼(IDP) 구축 및 운영"
- "Golden Path 설계 및 유지보수"
- "셀프서비스 인프라 프로비저닝"
- "개발자 포털(Backstage) 운영"
- "CI/CD 파이프라인 표준화"
supporting:
- "개발 팀 온보딩 지원"
- "플랫폼 교육 및 워크숍"
- "기술 컨설팅 (Enabling 역할)"
explicitly_excluded:
- "개별 서비스의 배포 및 운영"
- "비즈니스 로직 개발"
- "24/7 온콜 (개별 서비스)"
- "모든 인프라 티켓 처리"플랫폼 팀이 "모든 인프라 문제를 해결해주는 팀"이 되면 병목이 됩니다. 플랫폼 팀의 목표는 개발 팀이 스스로 문제를 해결할 수 있는 도구를 제공하는 것이지, 문제를 대신 해결해주는 것이 아닙니다.
조직의 규모에 따라 플랫폼 팀의 구성이 달라집니다.
소규모 (개발자 30-50명, 플랫폼 팀 2-3명)
Platform Team (2-3명)
- Platform Engineer (백엔드 + 인프라)
- Platform Engineer (프론트엔드 + DX)
- (선택) SRE / DevOps Engineer소규모 팀에서는 한 사람이 여러 역할을 겸합니다. MVP에 집중하고, 가장 임팩트가 큰 기능부터 구현합니다.
중규모 (개발자 100-300명, 플랫폼 팀 5-8명)
Platform Team (5-8명)
- Platform Product Manager (1명)
- Developer Experience Engineer (1-2명)
- Backstage 포털 개발
- CLI 도구 개발
- 문서화
- Infrastructure Engineer (2-3명)
- Kubernetes 플랫폼
- IaC 모듈 / Crossplane
- CI/CD 파이프라인
- Platform SRE (1명)
- 플랫폼 가용성
- 모니터링 / 알림대규모 (개발자 500명 이상, 플랫폼 팀 10명 이상)
Platform Engineering Division
|
+-- Developer Portal Team (3-4명)
| - Backstage 개발 및 운영
| - 플러그인 개발
|
+-- Infrastructure Platform Team (4-5명)
| - Kubernetes 플랫폼
| - 셀프서비스 인프라
| - Crossplane / Terraform
|
+-- Developer Experience Team (2-3명)
| - CLI 도구
| - SDK
| - 문서화 / 교육
|
+-- Platform SRE Team (2-3명)
| - 플랫폼 가용성
| - 성능 최적화
| - 인시던트 관리
|
+-- Platform Product Manager (1-2명)
- 로드맵 관리
- 사용자 리서치
- 이해관계자 관리Team Topologies에서 정의하는 세 가지 상호작용 모드를 플랫폼 팀에 적용합니다.
| 모드 | 설명 | 플랫폼 팀의 예 |
|---|---|---|
| X-as-a-Service | 서비스 제공자-소비자 관계 | 셀프서비스 인프라, Backstage 포털 |
| Collaboration | 밀접한 협력 | 신규 Golden Path 개발 시 파일럿 팀과 협업 |
| Facilitating | 역량 강화 지원 | 교육, 워크숍, 마이그레이션 지원 |
대부분의 상호작용은 X-as-a-Service 모드입니다. 개발 팀은 플랫폼의 셀프서비스 기능을 독립적으로 사용합니다. 새로운 기능을 개발할 때는 일시적으로 Collaboration 모드로 전환하여 파일럿 팀과 함께 만들어갑니다.
플랫폼의 성공을 측정하는 가장 중요한 지표는 채택률입니다.
kpis:
adoption:
- name: "템플릿 사용률"
formula: "Scaffolder로 생성한 신규 서비스 / 전체 신규 서비스"
target: "80%+"
frequency: monthly
- name: "카탈로그 등록률"
formula: "카탈로그에 등록된 서비스 / 전체 운영 서비스"
target: "95%+"
frequency: monthly
- name: "셀프서비스 비율"
formula: "셀프서비스로 처리된 인프라 요청 / 전체 인프라 요청"
target: "70%+"
frequency: monthly
efficiency:
- name: "첫 배포 소요 시간"
formula: "프로젝트 생성부터 첫 프로덕션 배포까지"
target: "4시간 이내"
frequency: per-event
- name: "배포 빈도"
formula: "팀당 일 평균 배포 횟수"
target: "3회 이상"
frequency: weekly
- name: "인프라 프로비저닝 시간"
formula: "인프라 요청부터 사용 가능까지"
target: "30분 이내 (자동 승인)"
frequency: per-event
satisfaction:
- name: "개발자 NPS"
target: "40 이상"
frequency: quarterly
- name: "플랫폼 지원 요청 건수"
formula: "월간 Slack 채널 + 티켓 문의 수"
target: "감소 추세"
frequency: monthly채택률이 목표에 미달할 때 적용할 수 있는 전략입니다.
1. 저항의 원인 파악
채택하지 않는 팀에 직접 물어봅니다. 흔한 이유는 다음과 같습니다.
| 저항 원인 | 대응 전략 |
|---|---|
| "우리 유스케이스에 안 맞아요" | 해당 유스케이스를 지원하는 템플릿 추가 |
| "기존 방식이 더 익숙해요" | 마이그레이션 가이드 + 핸즈온 워크숍 |
| "플랫폼이 너무 느려요" | 성능 최적화, 피드백 반영 |
| "장애 나면 디버깅이 어려워요" | 가시성(Observability) 개선, 로그 접근성 향상 |
| "플랫폼 팀에 의존하기 싫어요" | 셀프서비스 기능 강화, 문서 개선 |
2. 챔피언 프로그램
각 팀에서 플랫폼에 호의적인 개발자를 "Platform Champion"으로 지정합니다. 챔피언은 팀 내에서 플랫폼 사용을 전파하고, 피드백을 수집하는 역할을 합니다.
3. 성공 사례 공유
플랫폼 도입으로 실제 성과를 얻은 팀의 사례를 사내에 적극 공유합니다. 정량적 데이터(배포 시간 단축, 인시던트 감소)와 정성적 피드백을 함께 제시합니다.
채택률을 높이는 가장 효과적인 방법은 "강제"가 아니라 "매력"입니다. 플랫폼이 충분히 매력적이지 않다면, 강제로 사용하게 만드는 대신 플랫폼 자체를 개선하세요.
**NPS(Net Promoter Score)**는 고객 충성도를 측정하는 지표입니다. 이를 개발자 만족도에 적용합니다.
핵심 질문: "동료에게 이 플랫폼을 추천할 의향이 얼마나 됩니까? (0-10)"
Promoter (9-10): 추천하겠다
Passive (7-8): 보통이다
Detractor (0-6): 추천하지 않겠다
NPS = (Promoter 비율) - (Detractor 비율)
예시:
전체 응답자 100명
Promoter: 50명 (50%)
Passive: 30명 (30%)
Detractor: 20명 (20%)
NPS = 50% - 20% = 30NPS 점수만으로는 개선 방향을 알기 어렵습니다. 추가 질문으로 맥락을 파악합니다.
survey:
name: "Platform Developer Satisfaction Survey"
frequency: quarterly
questions:
- type: nps
text: "동료에게 이 플랫폼을 추천할 의향이 얼마나 됩니까? (0-10)"
- type: open-text
text: "위 점수를 준 이유를 알려주세요."
- type: rating
scale: 1-5
items:
- "새 프로젝트를 시작하기 쉽다"
- "인프라를 셀프서비스로 프로비저닝하기 쉽다"
- "문서가 충분하고 이해하기 쉽다"
- "문제 발생 시 원인을 빠르게 파악할 수 있다"
- "플랫폼 팀의 지원이 신속하다"
- "비용 정보가 유용하다"
- type: multiple-choice
text: "가장 개선이 필요한 영역은?"
options:
- "프로젝트 생성 / 온보딩"
- "CI/CD 파이프라인"
- "인프라 프로비저닝"
- "모니터링 / 로깅"
- "문서화"
- "비용 가시성"
- "보안"
- "기타"
- type: open-text
text: "플랫폼에 추가되었으면 하는 기능이 있나요?"| NPS 범위 | 평가 | 조치 |
|---|---|---|
| 50 이상 | 우수 | 현재 전략 유지, 세부 개선 |
| 30-50 | 양호 | Detractor 피드백 집중 분석 |
| 0-30 | 보통 | 핵심 불만 사항 긴급 개선 |
| 0 미만 | 위험 | 전면 재검토 필요 |
플랫폼 팀의 이해관계자는 개발자뿐만이 아닙니다.
각 이해관계자에게 맞는 보고 체계를 구성합니다.
| 이해관계자 | 보고 주기 | 핵심 지표 | 채널 |
|---|---|---|---|
| CTO | 분기별 | ROI, 채택률, 비용 절감 | 경영 보고서 |
| Engineering Manager | 월별 | 팀 생산성, 배포 빈도 | 월간 리포트 |
| 개발자 | 실시간 | 플랫폼 상태, 새 기능 | Slack, 포털 |
| 보안팀 | 월별 | 컴플라이언스 비율, 취약점 | 보안 대시보드 |
| 재무팀 | 월별 | 비용 트렌드, 예산 준수 | 비용 리포트 |
조직의 Platform Engineering 성숙도를 객관적으로 평가하고 발전 방향을 설정하기 위한 모델입니다.
maturity_levels:
- level: 1
name: "초기 (Initial)"
characteristics:
- "플랫폼 팀 미존재 또는 비공식"
- "팀별로 각자 인프라 관리"
- "문서화 부족"
- "수동 프로비저닝"
target_actions:
- "플랫폼 팀 공식 편성"
- "핵심 인프라 표준화 시작"
- level: 2
name: "반복 가능 (Repeatable)"
characteristics:
- "플랫폼 팀 존재 (2-3명)"
- "기본 CI/CD 파이프라인 표준화"
- "일부 IaC 모듈 존재"
- "수동 카탈로그 관리"
target_actions:
- "Backstage 도입"
- "프로젝트 템플릿 2-3개 제작"
- "사용자 리서치 시작"
- level: 3
name: "정의됨 (Defined)"
characteristics:
- "개발자 포털 운영"
- "Golden Path 3개 이상"
- "셀프서비스 인프라 (기본)"
- "카탈로그 70% 이상 등록"
- "개발자 NPS 측정 시작"
target_actions:
- "셀프서비스 범위 확대"
- "FinOps 통합"
- "보안 자동화"
- level: 4
name: "관리됨 (Managed)"
characteristics:
- "셀프서비스 인프라 70% 이상"
- "카탈로그 95% 이상 등록"
- "FinOps 통합 완료"
- "보안 정책 자동 적용"
- "NPS 30 이상"
- "플랫폼 팀 5명 이상"
target_actions:
- "AI 기반 최적화"
- "멀티 클러스터/클라우드"
- "고급 거버넌스"
- level: 5
name: "최적화됨 (Optimized)"
characteristics:
- "AI 기반 자동 최적화"
- "NPS 50 이상"
- "셀프서비스 90% 이상"
- "비용 최적화 자동화"
- "제로 트러스트 보안 내재화"
- "글로벌 멀티 리전 지원"
target_actions:
- "지속적 혁신"
- "업계 선도적 실험"성숙도 모델은 현재 위치를 진단하고 다음 단계를 계획하는 도구입니다. 한 번에 Level 5를 목표로 하는 것이 아니라, 현재 수준에서 한 단계씩 올라가는 것이 현실적입니다. 대부분의 조직은 Level 3에 도달하는 데 1-2년이 소요됩니다.
플랫폼이 성장하면 두 가지 차원의 스케일링이 필요합니다.
기능 확장: 새로운 기능(FinOps, 보안, AI 등)을 추가하는 것입니다. 이때 주의할 점은 기존 기능의 품질을 유지하면서 확장해야 한다는 것입니다.
팀 확장: 플랫폼 팀의 인원을 늘리는 것입니다. 대규모 조직에서는 하위 팀으로 분리하는 것이 효과적입니다.
| 위험 | 설명 | 대응 |
|---|---|---|
| 범위 확대 (Scope Creep) | 요청을 모두 수용하여 범위가 무한 확장 | 엄격한 로드맵 관리, "No" 할 줄 알기 |
| 플랫폼 팀 번아웃 | 운영 + 개발 + 지원의 과부하 | 자동화 우선, 온콜 로테이션 |
| 레거시 기술 부채 | 초기 구축 시 발생한 기술 부채 누적 | 정기적 리팩토링 시간 확보 (20%) |
| 사용자 기대치 관리 | 기능 추가 속도에 대한 과도한 기대 | 투명한 로드맵 공유, 분기별 계획 |
이번 장에서는 플랫폼 팀의 조직 구조와 운영 전략을 다루었습니다.
다음 장에서는 이 시리즈의 마지막으로 실전 프로젝트를 수행합니다. Backstage + ArgoCD + Crossplane으로 엔드투엔드 IDP를 구축하고, Golden Path 작성, 셀프서비스 워크플로우, 비용 가시성 통합까지 전 과정을 실습합니다.
이 글이 도움이 되셨나요?
Backstage, ArgoCD, Crossplane으로 엔드투엔드 IDP를 구축하는 실전 프로젝트. Golden Path 작성, 셀프서비스 워크플로우, 비용 가시성 통합까지 전 과정을 다룹니다.
FinOps 원칙과 플랫폼 통합, Backstage 비용 대시보드, 태그 기반 비용 할당, 리소스 생성 시점의 비용 예측, 그리고 AI 기반 비용 최적화를 다룹니다.
Platform as a Product 관점에서의 API 계층 설계, 추상화 수준 결정, 내부 API 버전닝, 인증과 인가, 감사 로깅, 그리고 CLI 도구 제공까지 다룹니다.