[Platform Engineering] Day 5: 플랫폼 성숙도 로드맵 - 단계적 도입과 팀 구조

서론: 처음부터 완성된 플랫폼을 만들 필요는 없다

Platform Engineering을 도입하려는 조직이 흔히 저지르는 실수는 처음부터 모든 것을 구축하려 한다는 것이다. Service Catalog, 스캐폴딩, 셀프서비스 인프라, 표준 파이프라인을 동시에 시작하면 어느 것도 완성되지 않는다.

성공한 조직들은 가장 아픈 문제 하나를 먼저 해결하고, 그 성과로 다음 단계를 정당화한다.

1. 성숙도 단계 모델

Level 0: 임시방편

• 인프라 요청은 모두 티켓
• 서비스마다 다른 파이프라인
• “플랫폼 팀”이 존재하지 않거나 인프라 운영팀이 겸임

Level 1: 표준화 시작

• 표준 CI/CD 파이프라인 1~2개 도입
• 공통 모니터링 스택 통일
• 비공식 플랫폼 챔피언 그룹 형성

Level 2: Self-Service 기초

• 스캐폴딩으로 신규 서비스 생성 표준화
• 핵심 인프라 컴포넌트 IaC 모듈화
• Service Catalog 초기 도입
• 전담 플랫폼 팀 구성

Level 3: 내부 제품으로 운영

• 전체 Golden Path 완성
• 셀프서비스 프로비저닝 80% 이상 자동화
• SLO 정의 및 DORA 지표 측정
• 개발자 설문 기반 개선 루프

Level 4: 지속적 최적화

• 플랫폼 채택률 90% 이상
• 표준 경로 대비 커스텀 비율 최소화
• 플랫폼 변경이 DORA 지표에 미치는 영향 추적
• 플랫폼 컴포넌트 오픈소스 기여 또는 외부 공유

2. 팀 구조: Team Topologies 관점

Team Topologies는 Platform Team을 조직 설계의 핵심 패턴으로 정의한다.

Stream-aligned Teams (제품 팀)
  └─ 비즈니스 기능 단위로 구성
  └─ 플랫폼에 의존해 인프라 운영 부담 최소화

Platform Team
  └─ 내부 제품(IDP)을 제공
  └─ Stream-aligned Team의 인지 부하 감소가 목표

Enabling Team (선택적)
  └─ 일시적으로 특정 역량을 팀에 전달
  └─ 플랫폼 도입 초기 코칭 역할

Complicated Subsystem Team (선택적)
  └─ ML 파이프라인, 검색 엔진 등 고난도 기술 전담

플랫폼 팀의 성공 지표는 팀 규모가 아니라 자신들이 없어도 개발자가 스스로 할 수 있는 일의 범위다.

3. 플랫폼 팀 규모와 비율

경험적 기준:

• 초기: 2~3명으로 시작해 가장 아픈 문제 하나 해결
• 성장기: 개발자 15~20명당 플랫폼 엔지니어 1명
• 성숙기: 셀프서비스 성숙도가 높아지면 비율이 낮아짐

플랫폼 팀 규모를 “개발자 수의 N%”로 고정하지 않는다. 자동화 성숙도에 따라 달라진다.

4. 도입 순서 권고

단계	집중 영역	예상 기간
1	표준 CI/CD 파이프라인 + 공통 모니터링	1~2개월
2	서비스 스캐폴딩 + Service Catalog	2~3개월
3	핵심 인프라 IaC 모듈 + 셀프서비스 포털	3~6개월
4	SLO 측정 + 개발자 경험 피드백 루프	지속

각 단계는 이전 단계가 개발자에게 채택된 뒤에 시작한다.

5. 예산 근거 만들기

경영진 설득에 필요한 수치:

• 현재 인프라 티켓 처리 시간 × 엔지니어 시급 = 연간 비용
• 신규 서비스 온보딩 소요 시간 × 연간 신규 서비스 수 = 비용
• 표준화 부재로 인한 보안 사고 대응 비용 (있다면)

IDP 도입 후 이 비용이 얼마나 줄었는지를 측정해 ROI를 산출한다.

6. 시리즈 종합 체크리스트

1. 가장 아픈 개발자 경험 문제를 하나 선정해 플랫폼 도입을 시작했다.
2. Golden Path를 강제가 아닌 “가장 쉬운 길”로 설계했다.
3. IaC 모듈에 보안·컴플라이언스 정책을 기본값으로 내장했다.
4. SLO와 DORA 지표로 플랫폼 가치를 정량화했다.
5. 플랫폼 팀을 내부 제품 팀으로 운영하고 개발자 피드백을 정기 수집한다.

시리즈 마무리

Platform Engineering의 본질은 기술이 아니라 조직의 문제다.

가장 좋은 플랫폼은 개발자가 “플랫폼을 쓰고 있다”는 것을 인식하지 못할 만큼 자연스럽게 동작하는 플랫폼이다. 그 수준에 도달하려면 기술 구현보다 개발자 경험에 집착하고, 지표로 검증하고, 점진적으로 개선하는 제품 사고방식이 필요하다.