CNPA — 클라우드 네이티브 플랫폼 엔지니어링 어소시에이트 · 플랫폼 엔지니어링이란 · 이론

플랫폼을 제품으로 본다는 말의 뜻

한 줄 요약

플랫폼 엔지니어링의 목표는 도구를 많이 갖추는 것이 아니라 스트림 얼라인드 팀의 인지 부하(cognitive load)를 낮추는 것 입니다. 그래서 플랫폼은 프로젝트가 아니라 제품이고, 사용자는 다른 개발팀이며, 성공 지표는 배포 횟수가 아니라 자발적 채택률 입니다.

왜 이게 필요했나

"You build it, you run it" 이 유행하면서 많은 조직이 운영 책임을 개발팀으로 밀었습니다. 의도는 좋았는데 결과는 이랬습니다. 개발자 한 명이 알아야 할 것이 폭발했습니다 — 언어와 프레임워크, 도메인 로직, 그리고 그 위에 쿠버네티스, Helm, Terraform, CI 문법, 시크릿 관리, 관측 스택, 네트워크 정책, 비용 최적화까지.

이걸 팀 토폴로지에서는 인지 부하 초과라고 부릅니다. 인지 부하에는 세 종류가 있습니다.

| 종류 | 내용 | 대응 |
| --- | --- | --- |
| 내재적(intrinsic) | 언어·자료구조 같은 기본기 | 교육과 채용으로 |
| 외재적(extraneous) | YAML 여덟 개를 순서대로 쓰는 절차 | 플랫폼이 없애야 할 대상 |
| 본유적(germane) | 도메인 문제 자체 | 여기에 뇌를 쓰게 해야 한다 |

플랫폼 엔지니어링은 외재적 부하를 흡수해서 본유적 부하에 쓸 여유를 만드는 일입니다. 그래서 "우리 플랫폼이 잘하고 있나?"의 답은 도구 개수가 아니라 "개발자가 도메인 문제에 얼마나 시간을 쓰고 있나" 입니다.

어떻게 동작하나

제품으로서의 플랫폼

플랫폼을 프로젝트로 다루면 이렇게 흘러갑니다. 요구사항을 모아 6 개월 만들고, 배포하고, 팀을 해체합니다. 제품으로 다루면 다릅니다.

사용자가 있습니다. 그 사용자는 내부 개발자이고, 쓰기 싫으면 안 씁니다.
로드맵이 있습니다. 무엇을 안 할지도 정합니다.
온보딩 문서와 지원 채널이 있습니다.
버전과 폐기 정책이 있습니다. 어제 되던 게 오늘 깨지면 신뢰가 사라집니다.
성공 지표가 있습니다. 채택률, 첫 배포까지 걸린 시간, 지원 티켓 수.

가장 중요한 판별식이 하나 있습니다. 강제하지 않았는데도 사람들이 쓰고 있는가. 회사 규정으로 강제해서 100% 를 만든 플랫폼은 채택률이 아니라 순응률을 측정한 것입니다. 순응률이 높고 만족도가 낮으면 그 플랫폼은 실패하는 중인데 지표가 그걸 숨깁니다.

Team Topologies 의 네 팀 유형

CNPA 는 이 분류를 직접 묻습니다.

| 팀 유형 | 하는 일 |
| --- | --- |
| Stream-aligned | 하나의 가치 흐름(제품·기능·사용자 여정)을 끝까지 책임진다. 조직의 대다수를 차지해야 한다 |
| Platform | 스트림 얼라인드 팀이 셀프서비스로 쓸 내부 서비스를 제공한다 |
| Enabling | 다른 팀의 역량 격차를 한시적으로 메운다. 상주하지 않고 떠난다 |
| Complicated-subsystem | 전문 지식이 깊게 필요한 부분(비디오 코덱, 결제 정산, 수학 엔진)을 맡는다 |

그리고 상호작용 방식 세 가지 — Collaboration(한시적으로 밀착해 함께 발견), X-as-a-Service(경계가 명확한 소비 관계), Facilitating(가르치고 빠진다) — 이 있습니다. 플랫폼 팀의 정상 상태는 X-as-a-Service 입니다. 플랫폼 팀이 모든 스트림 팀과 상시 Collaboration 을 하고 있다면 그건 플랫폼이 아직 셀프서비스가 아니라는 신호입니다.

DevOps · SRE · 플랫폼 엔지니어링

셋은 경쟁하는 개념이 아니라 초점이 다릅니다.

DevOps 는 문화이자 원칙입니다 — 개발과 운영 사이의 벽을 없애자. 팀 이름이 아닙니다. "DevOps 팀"을 만들어 배포를 대신해 주기 시작하면 원래 없애려던 벽을 이름만 바꿔 다시 세운 것입니다.
SRE 는 신뢰성을 공학 문제로 다루는 구체적 실천입니다 — SLI/SLO, 에러 버짓, 토일(toil) 감축, 무비난 사후 분석. 대상은 서비스의 신뢰성 입니다.
플랫폼 엔지니어링 은 그 실천들을 셀프서비스 제품 으로 포장해 다수 팀에게 배포 가능하게 만드는 일입니다. 대상은 개발자 경험 입니다.

겹치는 부분이 큽니다. 플랫폼도 SLO 를 가져야 하고(SRE 의 방법), 플랫폼 팀도 자기 플랫폼을 스스로 운영해야 합니다(DevOps 의 원칙). 갈리는 지점은 "누구를 위해 최적화하는가" 입니다 — SRE 는 최종 사용자의 경험을, 플랫폼 엔지니어는 내부 개발자의 경험을 최적화합니다.

현장에서 만나는 모습

저자의 7 노드 홈랩이 이 이야기의 축소판입니다. Cilium 1.20 eBPF CNI, MetalLB L2(10.0.0.200-215), Harbor 레지스트리(10.0.0.202), Gitea(10.0.0.200), Argo CD(10.0.0.201), kube-prometheus-stack 과 Grafana(10.0.0.203), CloudNativePG, GPU Operator 로 GPU 4 장, KubeVirt, csi-driver-nfs — 스택만 나열하면 훌륭한 플랫폼처럼 보입니다.

그런데 각 컴포넌트를 올리는 과정에서 나온 사고 목록이 진짜 플랫폼의 가치를 보여줍니다. Gateway API 는 CRD v1.6.1 이 필요했고 v1.2 로는 컨트롤러가 기동을 거부했습니다. KubeVirt 는 컴포넌트 상태가 전부 AllComponentsReady 인데 VM 이 뜨지 않았고, 원인은 virt-launcher 파드의 볼륨 마운트 누락이었습니다. containerDisk 경로에 결함이 있어 DataVolume(PVC) 경로로 우회해야 했습니다.

이 지식들은 전부 외재적 인지 부하 입니다. 서비스를 만들려는 개발자가 알 이유가 없는 것들입니다. 플랫폼 팀의 일은 이 함정들을 한 번씩 밟고 나서, 그 결과를 "골든 패스 하나"로 포장해 다른 사람은 다시 밟지 않게 만드는 것입니다. 그리고 "상태가 Ready"와 "실제로 동작한다"는 다른 명제 라는 교훈을 같은 클러스터에서 세 번째 확인했다는 기록은, 플랫폼이 제공해야 할 것이 설치가 아니라 검증된 경로 라는 뜻이기도 합니다.

이어서 읽을 것

다음 리딩에서 플랫폼 성숙도 단계와 내부 개발자 플랫폼(IDP)의 구성 요소를 정리합니다. 그다음 모듈에서는 쿠버네티스 API 를 플랫폼 API 로 확장하는 방법을 실제 클러스터에서 CRD·CR·ResourceQuota·RBAC 으로 직접 만들어 봅니다.