무엇을 재야 플랫폼이 나아지는가

한 줄 요약

DORA 네 지표는 배포 파이프라인의 건강 을 재는 도구이지 플랫폼의 성공을 재는 도구가 아닙니다. 플랫폼은 채택률·리드타임·인지 부하로 따로 재야 하고, 플랫폼 자신도 SLO 를 가져야 합니다.

왜 이게 필요했나

플랫폼 팀이 성과를 보고할 때 가장 흔한 실수가 "우리가 만든 것"을 나열하는 것입니다. "CI 템플릿 12 종, 차트 30 개, 대시보드 40 개." 이건 산출물(output)이지 성과(outcome)가 아닙니다. 그 12 종을 아무도 안 쓰고 있을 수도 있습니다.

성과를 재려면 사용자 쪽에서 봐야 합니다. 그리고 사용자는 다른 개발팀입니다.

어떻게 동작하나

DORA 네 지표와 그 한계

| 지표 | 뜻 |
| --- | --- |
| 배포 빈도(Deployment Frequency) | 얼마나 자주 프로덕션에 내보내는가 |
| 변경 리드 타임(Lead Time for Changes) | 커밋이 프로덕션에 도달하기까지 |
| 변경 실패율(Change Failure Rate) | 배포 중 장애로 이어진 비율 |
| 서비스 복구 시간(MTTR / Failed Deployment Recovery Time) | 실패에서 회복하기까지 |

앞의 둘은 속도(throughput), 뒤의 둘은 안정성(stability)입니다. DORA 연구의 핵심 발견은 이 둘이 상충하지 않는다 는 것이었습니다 — 빠른 조직이 대체로 더 안정적입니다.

한계도 분명합니다.

• 게임하기 쉽습니다. 배포를 잘게 쪼개면 빈도가 올라갑니다. 실패의 정의를 좁히면 실패율이 내려갑니다.
• 팀별 맥락을 지웁니다. 규제 심사가 필요한 결제 서비스와 사내 대시보드를 같은 잣대로 비교하면 잘못된 결론이 나옵니다.
• 플랫폼의 기여를 직접 보여주지 못합니다. 리드 타임이 줄었을 때 그게 플랫폼 덕분인지 팀이 작아진 덕분인지 지표만으로는 모릅니다.
• 개발자가 실제로 겪는 고통과 어긋날 수 있습니다. 배포는 빠른데 로컬 개발 환경 세팅에 이틀이 걸리는 조직에서 DORA 는 전부 초록색입니다.

그래서 DORA 는 경보 장치 로 쓰고, 플랫폼의 성과는 따로 재야 합니다.

플랫폼 고유 지표

• 채택률(adoption) — 강제되지 않은 상태에서 얼마나 쓰는가. 활성 사용 팀 수, 골든 패스로 만들어진 서비스 비율.
• 첫 배포까지의 시간(time-to-first-deploy) — 새 팀·새 서비스가 아무것도 없는 상태에서 프로덕션 배포에 도달하기까지. 플랫폼의 핵심 약속을 가장 직접적으로 잰다.
• 지원 티켓 수와 유형 — 줄어들면 셀프서비스가 되고 있다는 뜻. 늘어나는 유형이 곧 다음 골든 패스 후보다.
• 인지 부하 설문 — 정성 지표지만 유일하게 목표를 직접 잰다. "필요한 것을 찾기 얼마나 쉬웠나", "이 작업에 며칠이 걸릴 것 같은가" 같은 문항을 분기마다 같은 형태로 물어 추세를 본다.

여기서 자주 나오는 함정: 설문을 한 번만 하면 아무 쓸모가 없습니다. 절대값은 해석이 불가능하고 추세만 의미가 있습니다.

플랫폼도 SLO 를 가져야 한다

플랫폼이 다른 팀의 의존 대상이 되는 순간, 플랫폼의 가용성은 곧 그들의 가용성입니다. 그런데 많은 플랫폼 팀이 SLO 없이 운영합니다.

플랫폼 SLO 의 예:

• 배포 파이프라인 성공률과 P95 소요 시간
• 셀프서비스 프로비저닝 요청의 완료 시간(예: 새 네임스페이스 95% 가 2 분 이내)
• 내부 API·포털의 가용성
• 골든 패스 스캐폴딩의 성공률

SLO 가 있으면 에러 버짓이 생기고, 에러 버짓이 있으면 "이번 분기에 새 기능을 낼지 안정화를 할지"를 감이 아니라 숫자로 결정할 수 있습니다. SRE 의 방법론을 플랫폼 팀이 자기 자신에게 적용하는 것입니다.

멀티테넌시 격리 수준

플랫폼은 여러 팀이 자원을 나눠 쓰게 만듭니다. 격리 수준의 선택지는 대략 이렇습니다.

| 수준 | 격리 | 비용 | 운영 부담 |
| --- | --- | --- | --- |
| 네임스페이스 | 논리적. RBAC·쿼터·NetworkPolicy 로 구분 | 가장 저렴 | 낮음 |
| 노드 풀 분리 | 테넌트별 노드. taint/toleration 으로 배치 | 중간(유휴 자원 발생) | 중간 |
| 클러스터 분리 | 컨트롤 플레인까지 분리 | 비쌈 | 높음(클러스터 수만큼 업그레이드) |
| 계정·구독 분리 | 클라우드 경계까지 분리 | 가장 비쌈 | 가장 높음 |

선택 기준은 "이 테넌트끼리 신뢰 관계가 어떤가"와 "규제 요구가 있는가" 입니다. 같은 회사의 팀들이라면 네임스페이스로 충분한 경우가 많고, 외부 고객이 코드를 실행한다면 최소한 노드 분리, 대개는 클러스터 분리가 필요합니다. 소프트 멀티테넌시(신뢰하는 테넌트)와 하드 멀티테넌시(신뢰하지 않는 테넌트)를 구분하는 어휘가 시험에 나옵니다.

FinOps — 비용도 개발자 경험이다

비용은 사후 청구서가 아니라 피드백 신호 여야 합니다. 핵심 실천은 셋입니다.

1. 귀속(showback/chargeback) — 라벨과 네임스페이스로 비용을 팀에 매핑한다. 누구 것인지 모르면 아무도 줄이지 않는다. showback 은 보여만 주고, chargeback 은 실제로 청구한다.
2. 요청과 실제 사용의 격차 — 쿠버네티스 비용의 가장 큰 낭비는 과도한 requests 입니다. 요청 대비 실사용률을 팀에 보여 주는 것만으로도 상당 부분이 줄어듭니다.
3. 적정 규모 조정을 골든 패스에 넣기 — 기본 템플릿의 요청값이 합리적이면 아무도 신경 쓰지 않아도 비용이 절약됩니다.

현장에서 만나는 모습

저자의 홈랩은 kube-prometheus-stack 과 Grafana(10.0.0.203)로 관측을 갖췄고, 남은 과제 목록에 "컨트롤 플레인 부하 관찰 — 4C/14GB 미니 PC 가 etcd + apiserver 를 얼마나 버티는지" 가 올라 있습니다. 이게 플랫폼 SLO 사고의 축소판입니다. 컨트롤 플레인이 느려지면 그 위의 모든 팀이 느려지므로, 플랫폼의 자원 여유는 플랫폼만의 문제가 아니라 사용자 전체의 문제입니다.

격리 이야기도 같은 클러스터에서 그대로 나옵니다. GPU 는 24GB·32GB·8GB 두 장으로 체급이 제각각이라 아무 조치가 없으면 큰 학습이 작은 카드에 얹힙니다. 이건 성능 문제이자 공정성 문제 입니다 — 한 테넌트가 큰 카드를 독점하면 다른 테넌트의 리드 타임이 늘어납니다. 그래서 gpu.homelab/tier 라벨과 nodeSelector 로 배치 규칙을 만들었습니다. 격리는 보안만의 주제가 아니라 예측 가능성 의 주제이기도 합니다.

그리고 "상태가 Ready 와 실제로 동작한다는 다른 명제"라는 이 클러스터의 반복된 교훈은 측정에도 그대로 적용됩니다. 컴포넌트 헬스 체크가 전부 초록이어도 사용자가 겪는 경험은 나쁠 수 있습니다. 플랫폼 지표는 컴포넌트 상태가 아니라 사용자 여정에서 재야 합니다.

다음 퀴즈에서 확인할 것

이 모듈은 퀴즈로 마무리합니다. 앞 모듈에서 만든 CRD 와 쿼터, 골든 패스 스캐폴드가 여기서 말한 지표들과 어떻게 연결되는지 — 예를 들어 쿼터와 LimitRange 의 기본값이 곧 비용 지표에 영향을 준다는 점 — 을 되짚어 보면 좋습니다.