플랫폼 엔지니어링 성숙도 모델 (Platform Engineering Maturity Model)

다음 글은 CNCF의 플랫폼 백서를 gemini로 번역한 글입니다. 
원본: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/

 

Cloud Native Computing Foundation (CNCF) 플랫폼 워킹 그룹 발표

버전 1.0.0 | 2023년 10월 31일 출시

1. 서론 (Introduction)

CNCF의 초기 '플랫폼 정의 백서'는 클라우드 컴퓨팅을 위한 내부 플랫폼이 무엇인지, 그리고 기업에 약속하는 가치가 무엇인지 설명합니다. 하지만 이러한 가치를 달성하기 위해 조직은 자신들에게 영향력 있는 결과와 관행을 성찰하고 의도적으로 추구해야 합니다. 모든 조직은 설령 그것이 제3자 서비스를 사용하는 방법에 대한 문서에 불과할지라도, 자신의 조직을 위해 정교하게 만들어진 내부 플랫폼에 의존하고 있다는 점을 명심해야 합니다. 이 성숙도 모델은 그러한 성찰을 위한 프레임워크를 제공하고, 모든 조직에서 개선의 기회를 식별할 수 있게 돕습니다.

2. 플랫폼 엔지니어링이란 무엇인가? (What is platform engineering?)

DevOps가 약속했던 교차 기능적 협력에 영감을 받아, 플랫폼과 플랫폼 엔지니어링은 그 협력의 명시적인 형태로서 기업 내에 등장했습니다. 플랫폼은 공통의 역량, 프레임워크 및 경험을 선별하고 제시합니다. 본 워킹 그룹과 관련 간행물의 초점은 제품 및 애플리케이션 팀과 같은 내부 사용자의 업무를 촉진하고 가속화하는 플랫폼에 있습니다.

플랫폼 엔지니어링은 이러한 컴퓨팅 플랫폼을 개발자와 사용자에게 계획하고 제공하는 관행이며, 플랫폼의 모든 부분과 역량(사람, 프로세스, 정책, 기술 및 이를 추진하는 비즈니스 결과)을 포괄합니다. 완전한 맥락 파악을 위해 CNCF 플랫폼 정의 백서를 먼저 읽어보시기 바랍니다.

3. 이 모델을 사용하는 방법 (How to use this model)

지난 몇 년간 플랫폼 엔지니어링이 부상하면서 몇 가지 패턴이 분명해졌습니다. 이러한 패턴과 관찰 내용을 진보적인 성숙도 모델로 정리함으로써, 플랫폼 팀이 직면할 수 있는 과제와 지향해야 할 기회를 안내하고자 합니다.

각 측면(Aspect)은 각 레벨 내에서 서로 다른 팀과 조직의 특성을 보여주는 연속체로 설명됩니다. 독자들은 이 모델에서 자신의 위치를 찾고 인접한 레벨에서 기회를 식별할 수 있을 것입니다.

주의 사항:

• 성숙도 레벨이 높아질수록 더 많은 자금과 인력의 시간이 요구됩니다. 따라서 최고 레벨에 도달하는 것 자체가 목표가 되어서는 안 됩니다.
• 독자들은 필요한 투자 대비 자신의 조직과 현재 맥락이 해당 레벨의 특성으로부터 이득을 얻을 수 있는지 고려해야 합니다.
• 각 측면은 독립적으로 평가하고 발전시켜야 합니다. 하지만 이들은 복잡하게 상호 연관되어 있어, 한 측면을 개선하기 위해 다른 측면에서도 최소한의 레벨에 도달해야 할 수도 있습니다.
• 조직의 현재 클라우드 네이티브 전환 상태를 평가하십시오. 이를 위해 'Cloud Native Maturity Model'을 활용하는 것이 좋습니다.

마틴 파울러는 다음과 같이 말했습니다: "성숙도 모델 평가의 진정한 결과는 당신이 어느 레벨에 있느냐가 아니라, 개선을 위해 작업해야 할 목록입니다. 현재 레벨은 다음에 습득할 기술 목록을 결정하기 위한 중간 작업일 뿐입니다."

4. 이 작업의 배경 (Context behind this work)

대상 독자 (Intended audiences)

• CTO, VP, 기술 이사: 디지털 전환 및 개발자 생산성 향상을 위한 경로를 계획하는 리더.
• 엔지니어링 매니저: 엔지니어가 적은 오버헤드와 높은 효율성으로 가치를 제공하도록 역량을 부여하려는 그룹.
• 엔터프라이즈 아키텍트: 기술 문제에 대해 가치 및 솔루션 중심의 관점을 찾는 개인.
• 플랫폼 엔지니어 및 플랫폼 제품 매니저: 플랫폼 구축자와 사용자를 위해 최고의 경험을 만들고자 하는 팀.
• 제품 벤더 및 프로젝트 메인테이너: 사용자가 플랫폼을 통해 성공할 수 있도록 도구와 메시지를 설계하려는 조직.
• 애플리케이션 및 제품 개발자: 내부 플랫폼에서 무엇을 기대할 수 있는지 상세히 이해하고자 하는 사용자.

레벨의 이해 (Understanding the levels)

이 모델은 조직을 완전히 "레벨 1" 또는 "레벨 4"로 분류하기 위한 것이 아닙니다. 각 측면은 독립적으로 고려되어야 합니다. 낮은 번호의 레벨은 더 전술적인(Tactical) 솔루션으로 구성되며, 높은 번호의 레벨은 더 전략적(Strategic)입니다. 이는 일반적인 디지털 제품 개발 프로세스와 유사합니다: 문제 인식 → MVP 개발 → 반복 및 적합성 확인 → 확장 및 최적화.

5. 모델 요약표 (Model table)

측면 (Aspect)	레벨 1: 임시 (Provisional)	레벨 2: 운영 (Operational)	레벨 3: 확장 (Scalable)	레벨 4: 최적화 (Optimizing)
투자 (Investment)	자발적 또는 일시적	전담 팀	제품으로서 관리	활성화된 생태계
도입 (Adoption)	불규칙함	외부적 압박 (Push)	내부적 끌림 (Pull)	참여형
인터페이스 (Interfaces)	맞춤형 프로세스	표준 도구화	셀프 서비스 솔루션	통합 서비스
운영 및 측정 (Operations & Measurement)	요청에 의한 처리 / 임시 방편	중앙 집중식 추적 / 일관된 수집	중앙 집중식 활성화 / 인사이트 도출	관리형 서비스 / 정량적 및 정성적 측정

6. 모델 상세 (Model Detail)

6.1 투자 (Investment)

직원과 자금을 플랫폼 역량에 어떻게 배분하는가?

• 레벨 1, 임시 - 자발적 또는 일시적: 역량이 계획되거나 의도적인 자금 지원 없이 필요에 따라 구축됩니다. 일시적으로 배정된 인원이나 자원봉사자에 의해 유지되며, 사용자의 즉각적인 전술적 요구에 의존합니다.
• 특징: 긴급 요구사항 처리를 위한 "타이거 팀" 운영, 개선 작업이 "있으면 좋은 것"으로 치부됨. 직원들은 본업 외 업무량으로 인해 번아웃을 호소합니다.
• 레벨 2, 운영 - 전담 팀: 지속적인 지원을 위해 예산과 인력이 배정됩니다. 소프트웨어 제고 속도를 높이기 위해 공통 역량을 제공하는 임무를 맡습니다. 주로 반응적인 기술 요구사항에 집중하며, 비용 센터(Cost center)로 취급되어 가치 흐름에 미치는 영향은 측정되지 않습니다.
• 특징: 기술 범용 전문가로 구성, 팀 예산에 인프라 비용이 포함되어 예산 논의의 중심이 됨. 사용자 조사를 수행할 시간이나 경험이 부족합니다.
• 레벨 3, 확장 - 제품으로서: 외부 판매용 제품처럼 플랫폼에 투자합니다. 제품 관리(PM) 및 사용자 경험(UX)에 명시적으로 투자하며, 데이터 기반 지표와 피드백 루프를 사용하여 자원을 배분합니다.
• 특징: PM, UX 등 전통적 기술 팀에 없던 역할 배치, 내부 로드맵 공개. 기능 제거(Feature removal)도 중요한 논의 주제가 됩니다.
• 레벨 4, 최적화 - 활성화된 생태계: 플랫폼 팀은 기본적인 역량을 넘어 조직 전체의 효율성을 극대화할 방법을 찾습니다. 핵심 유지관리자는 보안, 성능 전문가들이 플랫폼 프레임워크에 직접 기여하여 기능을 확장할 수 있도록 돕는 데 집중합니다.

6.2 도입 (Adoption)

왜, 그리고 어떻게 사용자들이 내부 플랫폼을 발견하고 사용하는가?

• 레벨 1, 임시 - 불규칙함: 공유 플랫폼 채택이 산발적이고 일관성이 없습니다. 조직 차원의 전략이 없으며, 팀들은 내부 도구보다 외부 도구가 더 효과적이라고 생각합니다.
• 특징: 일회성 도구 난무, 클라우드 서비스가 표준 정책 없이 제각각 사용됨, 소문에 의존한 도구 발견.
• 레벨 2, 운영 - 외부적 압박(Push): 조직이 공유 플랫폼의 가치를 인식하고 도입을 독려합니다. 인사고과나 펀딩 조건과 같은 외부 지침이 사용을 강제하거나 인센티브를 제공합니다.
• 특징: 역량 활용이 단편적임, 사용자는 플랫폼 학습 의욕이 낮고 헬프 데스크에 크게 의존함.
• 레벨 3, 확장 - 내부적 끌림(Pull): 사용자들이 인지 부하 감소와 높은 품질이라는 명확한 가치 때문에 스스로 플랫폼을 선택합니다.
• 특징: 도입이 자생적으로 일어남, 하나의 역량에 만족한 사용자가 다른 역량을 찾아봄. 골든 패스 템플릿과 셀프 서비스 포털이 신속한 사용을 가능하게 합니다.
• 레벨 4, 최적화 - 참여형: 사용자들이 플랫폼 생태계에 합류하여 직접 기여(Contribution)합니다. 기존 기능을 수정하거나 새로운 사례를 위한 기능을 직접 추가합니다.
• 특징: 이슈 보드나 PR을 통해 비동기적으로 기능 강화, 개발자 에반젤리스트가 내부 커뮤니티 지원.

6.3 인터페이스 (Interface)

사용자가 플랫폼 역량과 어떻게 상호작용하고 소비하는가?

• 레벨 1, 임시 - 맞춤형 프로세스: 일관성 없는 다양한 프로세스가 존재하며 수동 개입에 의존합니다. 지식은 개인 간에 구두로 공유되며 표준화가 부족합니다.
• 레벨 2, 운영 - 표준 도구화: 광범위한 요구를 충족하는 일관된 표준 인터페이스가 존재합니다. 문서와 템플릿 형태의 "포장된 도로(Paved roads)" 또는 "골든 패스"가 제공됩니다.
• 레벨 3, 확장 - 셀프 서비스 솔루션: 유지관리자의 지원 없이도 사용자가 자율적으로 사용할 수 있습니다. 가이드된 내부 언어 등을 통해 복잡성을 추상화한 "원클릭" 구현을 제공합니다.
• 레벨 4, 최적화 - 관리형 서비스: 플랫폼 역량이 팀이 이미 사용하는 도구와 프로세스에 투명하게 통합됩니다. 관측성이나 ID 관리가 배포 시 자동으로 프로비저닝됩니다. 필요에 따라 깊은 커스터마이징이 가능한 빌드 블록 형태로 제공됩니다.

6.4 운영 (Operation)

플랫폼 역량을 어떻게 계획, 우선순위 지정, 개발 및 유지관리하는가?

• 레벨 1, 임시 - 요청에 의한 처리: 제품 팀의 산발적인 요청에 따라 반응적으로 개발됩니다. 초기 인도에만 집중하며 지속적인 유지관리나 보안 패치 계획이 부재합니다.
• 레벨 2, 운영 - 중앙 집중식 추적: 역량이 중앙에서 문서화되고 발견 가능합니다. 서비스별 소유권이 명시되며, 중앙 팀이 백로그를 관리하여 유지관리 상태를 추적합니다.
• 레벨 3, 확장 - 중앙 집중식 활성화: 플랫폼 팀이 조직의 폭넓은 니즈를 이해하고 우선순위를 정합니다. 누구나 솔루션을 기여할 수 있는 표준 프로세스가 존재하며, 지속적 인도(CD)를 통해 업데이트가 배포됩니다.
• 레벨 4, 최적화 - 관리형 서비스: 모든 역량의 라이프사이클이 표준화되고 자동화된 방식으로 관리됩니다. 업데이트가 사용자 영향 없이 지속적으로 전달되며, 명확한 '책임 공유 모델'이 존재합니다.

6.5 측정 (Measurement)

피드백과 학습을 수집하고 반영하는 프로세스는 무엇인가?

• 레벨 1, 임시 - 임시 방편(Ad hoc): 사용량이나 만족도 지표가 거의 수집되지 않으며, 결정은 일화적인 요구사항과 불완전한 데이터에 근거합니다.
• 레벨 2, 운영 - 일관된 수집: 사용자 피드백을 구조적으로 수집하는 것을 중요하게 여깁니다. 설문 조사나 포럼이 표준화되며, 사용자 경험이 데이터로 계측됩니다.
• 레벨 3, 확장 - 인사이트 도출: 특정 전략적 인사이트를 얻기 위해 정교한 방식으로 데이터를 수집합니다. 업계 프레임워크(DORA 등)를 활용하여 성과를 측정하고 로드맵에 반영합니다.
• 레벨 4, 최적화 - 정량적 및 정성적 측정: 피드백과 측정이 조직 문화에 깊이 통합됩니다. 데이터가 민주화되어 모든 이해관계자가 가설 수립과 검증에 참여하며, 정성적 변화가 정량적 지표 개선과 어떻게 연결되는지 파악합니다.

7. 결론 (Conclusion)

플랫폼과 그 유지관리자들은 민첩한 디지털 제품 개발을 위한 토대를 제공합니다. 이들은 효율적인 소프트웨어 개발 및 제고를 가능하게 하는 일관된 역량의 집합을 제공합니다. 이 성숙도 모델은 여러분의 플랫폼 엔지니어링 여정을 위한 지도가 되어줄 것입니다.