플랫폼 성숙도와 IDP 의 구성 요소

한 줄 요약

내부 개발자 플랫폼(IDP)은 포털 하나가 아니라 다섯 개의 평면(plane) 이 모인 것입니다. 그리고 성숙도는 도구 개수가 아니라 "누가 어떻게 결정하고 무엇으로 측정하는가"로 올라갑니다.

왜 이게 필요했나

"IDP 를 도입하자"는 말이 나오면 대개 포털 제품을 고르는 회의부터 시작합니다. 그런데 포털은 IDP 의 표면 일 뿐입니다. 그 아래에 실제로 무언가를 만들고 굴리는 층이 없으면 포털은 링크 모음집이 됩니다. 어떤 조각이 필요한지를 먼저 그려야 무엇이 없는지 보입니다.

어떻게 동작하나

IDP 의 다섯 평면

CNCF 플랫폼 백서가 정리한 구분을 실무 언어로 옮기면 이렇습니다.

| 평면 | 하는 일 | 흔한 구현 |
| --- | --- | --- |
| Developer Control Plane | 개발자가 만지는 표면 | 포털(Backstage), CLI, 저장소 템플릿, 매니페스트 추상화 |
| Integration & Delivery | 빌드하고 배포한다 | CI, 이미지 레지스트리, GitOps 에이전트, 시크릿 오퍼레이터 |
| Monitoring & Logging | 무슨 일이 벌어지는지 본다 | 메트릭, 로그, 트레이스, 대시보드, 알림 |
| Security | 신원과 정책 | 인증·인가, 정책 엔진, 이미지 서명·스캔 |
| Resource Plane | 실제 자원 | 클러스터, 노드, 네트워크, 스토리지, 데이터베이스 |

여기에 두 개의 축이 가로지릅니다. API 와 인터페이스(각 평면을 어떻게 부를 것인가)와 역량 제공(capabilities) 입니다. 시험에서는 "포털은 IDP 그 자체인가?" 를 물으면 답은 아니오이고, 포털은 Developer Control Plane 의 한 구현일 뿐입니다.

성숙도 단계

숫자보다 각 단계의 증상 을 외우는 편이 문제 풀이에 유리합니다.

1. 임시(Provisional) — 팀마다 각자 스크립트. 새 서비스 하나 띄우는 데 며칠. 지식은 사람 머릿속에.
2. 운영(Operational) — 공통 스크립트와 문서가 생김. 여전히 플랫폼 팀이 티켓을 받아 대신 해 줌. 병목이 사람.
3. 확장 가능(Scalable) — 셀프서비스가 됨. 개발자가 티켓 없이 스스로 프로비저닝. 플랫폼 팀은 요청 처리가 아니라 기능 개발을 함.
4. 최적화(Optimizing) — 사용 데이터와 사용자 피드백으로 플랫폼 자체를 개선. 폐기와 마이그레이션이 계획적으로 일어남.

단계를 가르는 진짜 기준은 "티켓이 필요한가" 입니다. 2 단계와 3 단계 사이에 절벽이 있고, 대부분의 조직이 여기서 멈춥니다. 자동화는 했는데 실행 버튼을 플랫폼 팀만 누를 수 있으면 여전히 2 단계입니다.

셀프서비스가 성립하려면

셀프서비스는 "권한을 준다"가 전부가 아닙니다. 세 가지가 동시에 필요합니다.

• 안전한 기본값 — 아무것도 지정하지 않아도 리소스 제한, 보안 컨텍스트, 관측이 붙는다.
• 경계 — 남의 네임스페이스를 건드릴 수 없고, 클러스터 전체를 망가뜨릴 수 없다.
• 빠른 피드백 — 잘못 쓰면 즉시, 사람이 읽을 수 있는 말로 거절당한다. 30 분 뒤에 파이프라인 로그 900 줄로 알려주면 셀프서비스가 아니다.

세 번째가 특히 중요합니다. 쿠버네티스에서 이건 곧 스키마 검증 입니다. CRD 의 OpenAPI 스키마에 maximum: 10 을 넣어 두면 API 서버가 즉시 거절합니다. 정책 엔진의 웹훅도 같은 역할을 합니다.

현장에서 만나는 모습

저자가 홈랩 위에 만들고 있는 것이 정확히 3 단계로 가는 시도입니다 — "수강생이 버튼을 누르면 실습 파드가 뜨고, 채점받고, 끝나면 사라지는 시스템". 여기서 플랫폼 관점의 요구가 그대로 드러납니다. 실습 파드는 남의 파드를 볼 수 없어야 하고(경계), 자원을 무한정 쓸 수 없어야 하고(가드레일), 아무 설정 없이도 필요한 도구가 들어 있어야 하며(안전한 기본값), 끝나면 스스로 사라져야 합니다(생명주기).

그리고 그 아래 클러스터에는 이런 제약이 이미 존재합니다. 컨트롤 플레인 3 대로 etcd 쿼럼은 갖췄지만 controlPlaneEndpoint 가 첫 노드의 물리 IP 에 고정돼 있어 그 노드가 죽으면 API 접근이 끊깁니다. GPU 는 24GB·32GB·8GB 두 장으로 체급이 제각각이라 nvidia.com/gpu: 1 만 요청하면 엉뚱한 카드에 얹힙니다. 그래서 gpu.homelab/tier 같은 의미 기반 라벨을 사람이 정의해 얹어야 했습니다.

이것이 플랫폼 API 설계의 출발점입니다. 물리적 사실(GPU 카드 모델)을 그대로 노출하지 않고, 개발자가 이해할 수 있는 어휘(tier=xlarge)로 번역해 주는 것 — 그게 추상화이고, 다음 모듈의 주제입니다.

다음 퀴즈에서 확인할 것

다음 모듈에서 CRD 로 WebService 라는 플랫폼 API 를 직접 만듭니다. 스키마로 잘못된 값을 즉시 거절하고, 기본값을 서버가 채워 주고, 네임스페이스·ResourceQuota·LimitRange 로 테넌트 경계를 긋고, RBAC 으로 셀프서비스 권한을 주는 한 세트를 실제 클러스터에서 완성합니다.