[Platform Engineering] Day 4: 플랫폼 관측성 - 플랫폼 팀의 SLO와 개발자 경험 지표

서론: 플랫폼도 제품이므로 측정해야 한다

플랫폼 팀이 측정 없이 운영하면 두 가지 문제가 생긴다. 첫째, 플랫폼이 실제로 개발자 생산성을 높이는지 알 수 없다. 둘째, 경영진에게 플랫폼 투자의 가치를 설명하기 어렵다.

플랫폼을 제품으로 운영한다면 제품처럼 지표를 정의하고 SLO를 달성해야 한다.

1. 플랫폼 SLO 정의

플랫폼의 고객은 내부 개발자다. SLO는 개발자가 경험하는 품질을 반영해야 한다.

서비스	SLI	SLO
CI/CD 파이프라인	빌드 성공률	≥ 99%
셀프서비스 프로비저닝	요청 처리 완료 시간	p95 < 10분
스캐폴딩 서비스	템플릿 생성 성공률	≥ 99.5%
Service Catalog	조회 응답 시간	p99 < 2초
시크릿 주입	실패율	< 0.1%

SLO 위반 시 개발자에게 영향이 가는 항목부터 우선 정의한다.

2. DORA 지표

DevOps Research and Assessment(DORA)에서 정의한 4가지 지표는 소프트웨어 전달 성능의 산업 표준이다.

지표	설명	측정 방법
Deployment Frequency	배포 빈도	CI/CD 파이프라인 이벤트 수집
Lead Time for Changes	커밋 → 프로덕션 소요 시간	Git 커밋 시간 vs 배포 시간
Change Failure Rate	배포 후 장애 유발 비율	롤백/핫픽스 빈도
Time to Restore	장애 복구 시간	인시던트 시작 → 해결 시간

플랫폼 개선이 DORA 지표에 어떤 영향을 미쳤는지를 추적하면 플랫폼 가치를 정량화할 수 있다.

3. SPACE 프레임워크

DORA가 배포 프로세스 효율을 측정한다면, SPACE는 개발자 경험 전반을 측정한다.

차원	의미	예시 지표
Satisfaction	개발자 만족도와 웰빙	분기별 설문 점수
Performance	결과물의 품질	버그 탈출률, 코드 리뷰 통과율
Activity	수행한 행동의 양	PR 수, 배포 수
Communication	협업 효율	코드 리뷰 응답 시간
Efficiency	방해 없이 작업 완료	컨텍스트 스위칭 빈도, 블로킹 시간

Activity만 측정하는 함정을 피하기 위해 Satisfaction과 Efficiency를 반드시 포함한다.

4. 개발자 경험(DevEx) 설문

정량 지표가 포착하지 못하는 마찰을 정성적으로 수집한다.

대표 질문:

• “오늘 개발 환경 설정에 얼마나 시간을 썼나요?”
• “지난주 가장 불편했던 플랫폼 경험은 무엇인가요?”
• “새 서비스를 배포할 때 가장 큰 장벽은?”

분기 1회 전사 설문 + 월 1회 소규모 팀 인터뷰 조합이 효과적이다.

5. 플랫폼 대시보드 구성

플랫폼 팀 대시보드
  ├─ SLO 현황 (서비스별 SLO 달성률)
  ├─ DORA 지표 (배포 빈도, 리드 타임, 실패율, 복구 시간)
  ├─ 채택률 (Golden Path, 표준 파이프라인, 셀프서비스 사용률)
  ├─ 지원 부하 (플랫폼 관련 티켓 수, 해결 시간)
  └─ DevEx 설문 점수 추이

이 대시보드는 경영진 보고와 팀 내 우선순위 결정에 모두 활용된다.

6. Day 4 체크리스트

1. 주요 플랫폼 서비스별 SLI/SLO를 정의하고 측정 방법을 구현했다.
2. DORA 4개 지표를 CI/CD 파이프라인 이벤트에서 자동 수집한다.
3. 분기별 개발자 경험 설문을 계획하고 결과를 개선 백로그에 반영한다.
4. 플랫폼 채택률을 SLO와 함께 추적해 개선 우선순위에 반영한다.

다음 글 예고

Day 5에서는 플랫폼 성숙도 로드맵을 다룬다. 조직이 Platform Engineering을 단계적으로 도입하는 방법과 팀 구조, 예산 근거를 만드는 방법을 정리한다.