diff --git a/website/content/ko/wgs/platforms/maturity-model/README.md b/website/content/ko/wgs/platforms/maturity-model/README.md new file mode 100644 index 00000000..90fd8500 --- /dev/null +++ b/website/content/ko/wgs/platforms/maturity-model/README.md @@ -0,0 +1,10 @@ +# Platform Engineering Maturity Model + +CNCF TAG App Delivery maintains and publishes this paper describing how +organizations can review and grow their platform engineering maturity. + +v1 was completed in October 2023; improvements and iterations continue in the +[`latest`](./latest/) directory. + +Currently, the edition in the `v1` directory is published to TAG App Delivery's website at +. diff --git a/website/content/ko/wgs/platforms/maturity-model/v1/index.md b/website/content/ko/wgs/platforms/maturity-model/v1/index.md new file mode 100644 index 00000000..332f8070 --- /dev/null +++ b/website/content/ko/wgs/platforms/maturity-model/v1/index.md @@ -0,0 +1,502 @@ +--- +title: "플랫폼 엔지니어링 성숙도 모델" +pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-maturity-model/v1/assets/platform-eng-maturity-model-v1.0.pdf +version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-maturity-model/README.md +description: "이 성숙도 모델은 플랫폼 정의 백서에서 논의된 패턴을 채택하려는 사용자에게 전술적 지침을 제공하기 위한 것이다. 해당 백서는 왜 그리고 무엇을 구축해야 하는지를 제안하며; 이 문서는 어떻게 구축을 계획하는지를 설명하기 시작할 것이다. 대상 청중은 현재 상태와 환경을 평가하고 개선 기회를 파악하고자 하는 CTO, 엔지니어링 책임자, 수석 엔지니어와 아키텍트이다.

+이 문서는 다음 관련 문서를 참조하고 개선하며 유사한 표준을 따른다:
+[클라우드 성숙도 모델](https://maturitymodel.cncf.io/)
+[플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)" +type: whitepapers +--- + + + + +## 도입 + +CNCF의 초기 [플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)에서는 클라우드 컴퓨팅을 위한 내부 플랫폼이 무엇인지, 그리고 이들이 기업에 제공하겠다고 약속하는 가치에 대해 설명한다. 그러나 이러한 가치를 달성하려면 모든 조직은 자체 조직을 위해 제작된 내부 플랫폼에 의존한다는 점을 명심해두고 조직은 자신에게 영향을 미치는 결과와 관행을 반영하고 의도적으로 추구해야 한다. - 해당 플랫폼이 단지 제3자 서비스를 사용하는 방법에 대한 문서일지라도 말이다. 이 성숙도 모델은 모든 조직에서 이러한 성찰과 개선 기회 식별을 위한 프레임워크를 제공한다. + +## 플랫폼 엔지니어링이란 무엇인가요 ? + +DevOps가 약속한 부서 간 협력에서 영감을 받아 플랫폼과 플랫폼 엔지니어링은 이러한 협력의 명시적인 형태로 기업에 등장했다. 플랫폼은 공통 기능, 프레임워크 및 경험을 선별하고 제시한다. 해당 작업 그룹 및 관련 출판물에서는 프로덕트 및 애플리케이션 팀의 [내부 사용자]({{< ref "/wgs/platforms/glossary#platform-users" >}})의 작업을 촉진하고 가속화하는 플랫폼에 중점을 두고 있다. + +[**플랫폼 엔지니어링**]({{< ref "/wgs/platforms/glossary#platform-engineering" >}})은 이러한 컴퓨팅 플랫폼을 개발자와 사용자에게 계획하고 제공하는 관행으로 플랫폼의 모든 부분과 그들의 역량을 포괄한다 - 그들의 인력, 프로세스, 정책 및 기술과 같은 역량을 말이다; 뿐만 아니라 그들이 추구하는 원하는 비즈니스 결과도 있다. + +전체 내용을 보려면 먼저 [CNCF 플랫폼 정의 백서](https://tag-app-delivery.cncf.io/whitepapers/platforms/)를 읽어보세요. + +## 해당 모델 사용 방법 + +지난 몇 년 동안 플랫폼 엔지니어링이 두각을 나타내면서 몇 가지 패턴이 분명해졌다. 이러한 패턴과 관찰을 점진적인 성숙도 모델로 구성함으로써 우리는 [플랫폼 팀]({{< ref "/wgs/platforms/glossary#platform-teams" >}})이 직면할 수 있는 과제와 목표로 삼을 수 있는 기회에 방향을 맞추는 것을 목표로 한다. 각 측면은 해당 측면 내의 각 수준에서 서로 다른 팀과 조직의 특성의 연속체로 설명된다. 우리는 독자들이 모델에서 자신을 찾고 인접한 수준에서 기회를 식별하기를 기대한다. + +주목할 만한 점은 각각의 성숙도 수준이 높아질수록 자금과 인력(사람들의 시간)에 대한 더 큰 요구사항이 뒤따른다는 점이다. 그러므로 최고 수준에 도달하는 것 자체가 목표가 되어서는 안 된다. 각 수준은 해당 단계에서 나타나야 하는 특성을 설명한다. 독자들은 필요한 투자를 고려할 때 그들의 조직과 현재 상황이 이러한 특성으로부터 이익을 얻을 수 있는지 고려해야 한다. + +각각의 측면은 독립적으로 평가되고 발전된다는 점을 명심해야 한다. 그러나 모든 사회 기술적 시스템과 마찬가지로 이 측면들은 복잡하고 상호 연관되어 있다. 따라서 한 측면에서 개선하려면 다른 측면에서도 최소 수준에 도달해야 한다는 것을 알 수 있다. + +플랫폼의 구현은 조직마다 다르다는 점을 인지하는 것도 또한 중요하다. 여러분의 그룹의 전반적인 클라우드 네이티브 전환의 현황을 반드시 평가해야 한다. 이러한 평가에 활용할 수 있는 경이로운 리소스는 [클라우드 네이티브 성숙도 모델](https://maturitymodel.cncf.io/)이다. + +마지막으로, 이 모델은 조직이 의도적인 계획을 통해 플랫폼 엔지니어링 규율과 그에 따른 플랫폼을 성숙시키도록 장려한다. 이러한 계획과 규율 그 자체는 성숙한 플랫폼 개발과 지속적인 발전을 위한 요구 사항이다. + +일반적으로, 조직을 모델에 매핑하면 점진적인 반복과 개선이 가능한 현재 상태가 포착된다는 사실을 명심해야 한다. [마틴 파울러](https://martinfowler.com/bliki/MaturityModel.html)는 다음과 같이 말했다: "성숙도 모델 평가의 진정한 결과는 당신이 어떤 수준에 있는지가 아니라 개선하기 위해 노력해야 할 것들의 목록이다. 당신의 현재 수준은 다음에 습득해야 할 기술 목록을 결정하기 위한 중간 작업에 불과하다." 그러한 맥락에서 모델에서 자신을 찾고 인접한 수준에서 기회를 식별하세요. + +## 해당 작업의 배경 + +문서가 작성된 맥락을 이해하는 것은 가치가 있는 일이다. 다음 절에서는 모델 뒤에 있는 몇 가지 맥락과 독자 여러분이 기대하는 바를 설명한다. + +### 대상 독자들 + +각 독자는 이 모델을 통해 독특한 학습을 하게 되고 다른 맥락을 갖게 된다. 우리가 염두에 두고 있는 몇 가지 인물들과 이 모델에 참여하기 위한 가능한 동기는 다음과 같다: + +* **CTO, VP 및 기술 담당 이사**: 디지털 전환 및 개발자 생산성 향상을 위한 길을 모색하는 리더 +* **엔지니어링 관리자**: 엔지니어가 더 적은 오버헤드와 더 높은 효율성으로 가치를 제공할 수 있도록 지원하고자 하는 그룹과 개인 +* **엔터프라이즈 아키텍트**: 기술 문제에 대한 가치와 솔루션 중심의 관점을 추구하는 현대 기술 환경을 탐색하는 개인 +* **플랫폼 엔지니어 및 플랫폼 프로덕트 관리자**: 플랫폼 빌더와 플랫폼 사용자를 위해 가능한 최고의 경험을 구축하고자 하는 팀과 사람들 +* **프로덕트 벤더 및 프로젝트 메인테이너**: 사용자가 플랫폼과 기능으로 성공할 수 있도록 도구를 설계하고 메시지를 전달하고자 하는 조직 및 엔지니어 +* **애플리케이션 및 프로덕트 개발자**: 내부 플랫폼에 대해 무엇을 기대할 수 있는지 더 자세히 이해하고자 하는 플랫폼 사용자 + +### 수준 이해하기 + +이 모델은 조직이나 플랫폼 팀을 전적으로 "레벨 1" 또는 "레벨 4"로 분류하는 것을 의미하지 않는다. 각 측면은 다른 측면과 독립적으로 고려되어야 한다; 각 수준의 특성은 그 측면 내의 연속체를 나타내지만 반드시 동일한 수준의 다른 측면과 결합되지는 않는다. 더욱이, 많은 조직들은 하나 이상의 수준의 특성이 팀과 업무 전반에 걸쳐 적용 가능하다고 볼 것이다. 어떤 수준도 본질적으로 좋거나 나쁘거나하지 않고 팀의 목표에 맥락적일 뿐이기 때문이다. + +각 수준의 레이블은 조직에서 플랫폼 엔지니어링의 영향을 반영하기 위한 것이다. 주어진 수준에서 귀하의 조직을 인식하면 다음 수준에서 뒤따르는 기회에 대한 통찰력을 얻게 될 것이다. 숫자가 낮은 수준은 더 많은 전술적 솔루션을 구성하고 숫자가 높은 수준은 더 전략적 솔루션을 구성한다. + +이는 다른 디지털 프로덕트 개발과 유사한 플랫폼 개발 및 성숙도를 위한 잠재적 프로세스를 생성한다: 먼저 문제와 새로운 솔루션에 대한 필요성을 인식하고, 다음으로 최소 실행 가능한 프로덕트를 가설화된 솔루션으로 개발하고, 세 번째로 문제를 더 잘 해결하고 고객에게 적합하도록 반복하고 마지막으로 많은 팀과 사용자의 문제를 해결하기 위해 프로덕트를 확장하고 최적화한다. + +[CNCF 클라우드 네이티브 성숙도 모델](https://maturitymodel.cncf.io/)과 유사하게, 이 모델은 기술과 함께 사람, 프로세스, 정책의 균형을 통해서만 성공적인 비즈니스 성과를 달성할 수 있다는 점을 강조한다. 특히, 이 모델은 단일 내부 팀의 소관이 아닌 경우가 많으며 오히려 엔지니어링 부서와 광범위한 조직 간의 협력이 필요한 측면을 소개한다. + +### 그런데 안 맞는 것 같아요 + +정말 괜찮다! 모든 조직과 그룹에는 해당 조직과 관련된 동적 요소와 매개변수가 있다. + +이 백서의 목표는 엄격한 공식을 규정하는 것이 아니라, 상황에 맞게 적용할 수 있는 프레임워크를 규정하는 것이다. 모든 단어가 귀하와 관련이 없을 수도 있지만, 우리는 그 내용이 여러분이 스스로의 플랫폼 여정을 성찰하고, 의미가 있는 것을 선택하고 나머지는 버리도록 영감을 주기를 바란다. + +이 모델의 목적은 플랫폼 엔지니어링 실무자, 이해관계자 및 기타 이해관계자의 여정을 안내하는 데 도움이 되는 도구를 제공하는 것이다. 플랫폼 디자인과 구현은 정확한 과학이 아니라, 오히려 개별 프로젝트, 조직 및 특정 시간과 장소의 요구에 달려 있다. + + +## 모델 테이블 + +|
측면
| | 제공(Provisional) | 운영(Operational) | 확장성(Scalable) | 최적화(Optimizing) | +|:---------------------------------------|:-------------------------------------------------------------------------------------------|:-----------------------|:----------------------|:-----------------------|:-----------------------------| +| [투자(Investment)](#Investment) | _플랫폼 기능에 대한 인력 및 자금 배분은 어떻게 이루어지나요?_ | 자발적 혹은 일시적 | 전담 팀 | 프로덕트 | 활성화된 에코시스템 | +| [채택(Adoption)](#Adoption) | _사용자가 내부 플랫폼 및 플랫폼 기능을 발견하고 사용하는 이유와 방법은 무엇인가요?_ | 불규칙 | 외부 푸시 | 내부 풀 | 참여형 | +| [인터페이스(Interfaces)](#Interfaces) | _사용자는 어떻게 플랫폼 기능과 상호 작용하고 소비하나요?_ | 사용자 정의 프로세스 | 표준 도구 | 셀프 서비스 솔루션 | 통합 서비스 | +| [운영(Operations)](#Operations) | _플랫폼과 그 기능은 어떻게 계획되고, 우선순위가 정해지고, 개발되고, 유지관리되나요?_ | 요청 시 | 중앙 추적 | 중앙 활성화 | 관리형 서비스 | +| [측정(Measurement)](#Measurement) | _피드백과 학습을 수집하고 반영하는 과정은 어떻게 되나요?_ | 즉흥적(Ad hoc) | 일관된 수집 | 인사이트(Insights) | 정량적, 정성적 | + +## 모델 상세 + +
+{{< tabs tabTotal="6">}} +{{< tab tabName="Investment" >}} + +

인력과 자금은 플랫폼 기능에 어떻게 할당되나요?

+ +플랫폼 및 플랫폼 엔지니어링에 대한 투자는 공통 기능을 구축하고 유지하기 위해 예산과 인력을 할당하는 과정이다. 이니셔티브는 상향식으로 유기적으로 구축되거나 하향식 이니셔티브를 통해 추진되는 것으로 설명되는 것이 일반적이다. 어느 경우든 영향력이 큰 작업을 추진하는 것은 지속적인 노력을 투자하는 능력이다. 이러한 측면은 투자의 규모와 폭이 플랫폼 성공에 어떤 영향을 미칠 수 있는지를 포착한다. + +### 레벨 1, 제공(Provisional) — 자발적 혹은 일시적 + +개별 기능은 공통 또는 중요한 기능에 대한 공통 기반을 제공하기 위해 존재할 수 있다. 이러한 기능은 계획하고 의도적으로 자금을 지원하기보다는 필요에 따라 구축되고 유지된다. + +이러한 기능은 일시적으로 또는 자발적으로 배정된 사람들에 의해 구축되고 유지된다; 중앙 자금이나 인력이 의도적으로 할당되지 않는다. 그들은 사용자의 현재 전술적 요구 사항에 의존한다. + +#### 특징: + +* "Hit" 또는 "tiger" 팀은 긴급한 요구 사항을 처리하기 위해 구성되었다. 이러한 팀은 수명이 짧으며 장기적인 계획과 지원을 제공할 시간이 할당되거나 부여되지 않는다. +* 마이그레이션, 개선 또는 향상은 종종 "있으면 좋은" 작업 항목으로 간주되며 "리서치" 또는 "핵 데이(hack day)" 노력에 의존한다. +* 긴급 보안 패치와 같은 새로운 요구 사항을 처리하는 동안 프로세스 개선이나 자동화가 도입될 수 있지만, 재사용 가능하거나 지속 가능한 방식으로 솔루션을 구축하기 위한 지원은 없다. +* 직원들은 자신의 핵심 역할 이외의 업무량으로 인해 피로감과 좌절감을 호소한다. + +#### 예시 시나리오: + +* 테스트 환경 전문가로 평가되는 특정 직원이 있다. 이 직원의 의도는 좋지만, 제한된 투자에도 불구하고 더 나은 테스트 환경을 가능하게 하려는 그들의 시도는 솔루션의 유지 보수가 없고 고장 난 테스트 환경을 분류하는 방법에 대한 공유된 이해가 없기 때문에 위험을 증가시켰다. +* 엔지니어들은 수익 창출 기능에 대한 경영진의 압력이 없을 때 기능 개선에 투자할 것을 권장받는다. 이는 CI/CD 파이프라인의 일부를 자동화하고 개선하는 데 우선순위를 두는 일부 스프린트의 마지막 며칠로 해석된다. 이러한 측면에서 시간을 허용하지 않는 지나치게 꽉 찬 스프린트가 수개월 동안 있을 수 있기 때문에 이러한 개선이 갑자기 발생하는 것은 드문 일이 아니다. + +### Level 2, 운영(Operationalized) — 전담 팀 + +예산과 인력은 지속적인 인력과 자원 지원을 위해 할당된다. 할당된 인력은 소프트웨어 제공 속도를 높이기 위해 일반적으로 필요한 기능을 제공하는 임무를 맡는다. 종종 이러한 팀은 반응형 기술 요구 사항을 충족하는 데 중점을 둔다. 이러한 팀은 DevOps, Engineering Enablement, Developer Experience (DevEx 또는 DevX), Shared Tools, Centre-Of Excellence 또는 심지어 플랫폼이라고도 불린다. 이러한 팀은 중앙 집중식으로 자금을 받고 비용 센터로 취급된다; 직접적인 가치 스트림과 애플리케이션 팀에 미치는 영향은 측정되지 않는다. 이러한 수준의 플랫폼 팀이 조직과 가치 스트림에 미치는 영향을 매핑하는 것이 어려울 수 있으며, 이는 이러한 팀에 자금을 계속 지원하고 유지하는 것을 어렵게 만들 수 있다. + +#### 특징: + +* 팀은 거의 모든 기술 저널리스트들로 구성되어 있다. +* 팀 예산은 종종 예산 논의의 핵심 사항으로 이어지는 업무와 관련된 인프라 비용을 포함할 수 있다. +* 백로그 항목들은 다양한 기술들을 포함하고 있어 빈번하고 큰 컨텍스트 스위치들로 이어진다. +* 이 팀은 선언된 팀의 범위가 아니더라도 아직 해결되지 않은 공백을 가장 먼저 채우는 경우가 많다. 이 팀은 소유자가 없는 리소스의 소유권을 갖는다. +* 할당된 사람들은 그들의 디자인이나 구현을 검증하기 위한 고객 조사에 대한 시간이나 경험이 거의 없다. + +#### 예시 시나리오: + +* 애플리케이션 개발자들은 자신들의 애플리케이션 빌드 시간이 길다는 문제를 제기한다. 중앙 집중식 팀은 빌드 시간을 50% 단축하는 임무를 맡고 있다. 그들은 개별적으로 애플리케이션 빌드를 개선할 만큼 소프트웨어와 가깝지 않다는 점을 고려하여 CI 러너의 크기와 양을 두 배로 늘려서 이 문제를 해결한다. 증가된 인프라 비용에 비해 생산성 향상을 직접 측정할 수 없기 때문에 이로 인해 중앙 집중식 팀에 예산 문제가 발생한다. + +### 레벨 3, 확장성(Scalable) — 프로덕트 + +내부 플랫폼과 그 기능에 대한 투자는 기업의 아웃바운드 프로덕트와 가치 흐름(value streams)에 대한 투자와 유사하다: 이는 그들이 고객에게 제공할 것으로 기대되는 가치에 기반으로 한다. 프로덕트 관리 및 사용자 경험은 명시적으로 고려되고 투자된다. 플랫폼이 고객 자신의 직접적인 가치 흐름 및 프로덕트에 미치는 영향을 반영하기 위해 지불 거절(chargeback) 시스템이 사용될 수 있다. 기업은 데이터 기반 성과 지표와 피드백 루프를 사용하여 적절한 이니셔티브에 자금과 직원을 할당한다. 플랫폼 팀은 궁극적으로 비즈니스 자체를 최적화하고 수익성 향상에 기여할 수 있다. + +#### 특징: + +* 플랫폼 팀의 직원 역할은 전통적으로 내부 서빙 또는 기술 팀에서 찾아볼 수 없는 역할, 예를 들어 프로덕트 관리와 사용자 경험이다. +* 팀은 전달된 가치와 높은 수준의 기능 목표를 나타내는 로드맵을 조직 내부에 공개한다. +* 기능은 디자인, 제공 및 배포 후에 구현 품질과 사용자 경험 모두에 대해 테스트된다. +* 기능 제거는 대화의 핵심 부분이며, 유지 관리가 되지 않을 수 있는 방대한 기능 대신 잘 지원되고 잘 사용되는 기능 제품군을 보유하는 것이 목표이다. + +#### 예시 시나리오: + +* 플랫폼 사용 지표에서 도출된 데이터는 가장 영향력 있는 이니셔티브에 자금과 인력을 할당하는 결정을 내리는 데 도움이 된다. + +### 레벨 4, 최적화(Optimizing) — 활성화된 에코시스템 + +플랫폼 팀은 기본적인 기능을 넘어 조직 전반의 효율성과 효과를 높일 수 있는 방법을 모색한다. 핵심 플랫폼 메인테이너는 새로운 프로덕트 출시 기간 최적화, 전사적 비용 절감, 새로운 서비스에 대한 효율적인 거버넌스와 규정 준수, 빠르고 쉬운 워크로드 확장과 기타 여러 요구 사항을 충족하기 위해 노력한다. 이러한 핵심 메인테이너는 기능 전문가가 요구 사항과 제안을 플랫폼의 기존 및 새로운 부분에 원활하게 통합할 수 있도록 지원하는 데 중점을 둔다. 또한, 조직은 보안, 성능, 품질과 같은 전문 영역의 인력과 리소스를 제공된 플랫폼 프레임워크에 집중하여 프로덕트 팀이 중앙 집중식 팀 백로그에 의존하지 않고 회사 목표를 빠르게 달성할 수 있는 고급 기능을 도입할 수 있도록 집중한다. + +#### 특징: + +* 전문가가 플랫폼 기능을 확장하고 새로운 기능을 도입할 수 있도록 하는 것이 우선 순위가 된다. +* 조직은 전문가를 중앙 집중화하여 그들의 지식과 지원이 플랫폼 기능을 통해 확산될 수 있도록 할 수 있다. + +#### 예시 시나리오: + +* 마케팅은 플랫폼 빌더와 협력하여 일관된 사용자 추적 기능을 도입하여 마케팅 노력을 프로덕트 성과에 기여한다. +* 자동화 이니셔티브를 통해 데이터베이스 프로비저닝에 소요되는 인력 시간을 인스턴스당 30분 단축하여 연간 1,000만 달러를 절약한다. + +{{< /tab >}} +{{< tab tabName="Adoption" >}} + +

사용자가 내부 플랫폼과 플랫폼 기능을 발견하고 사용하는 이유와 방법은 무엇인가요?

+ +채택(Adoption)은 조직이 플랫폼 기능을 어떻게 얼마나 사용하는지 뿐만 아니라, 그렇게 하도록 동기를 부여하는 요소도 설명한다. 초기 단계에서는 많은 대상 사용자가 플랫폼을 사용하고 있다는 사실을 전혀 인식하지 못할 수 있으며, 오히려 도구를 다양한 내부 소스의 기능을 임시로(ad hoc) 모아놓은 것으로 간주한다. 이는 일관되게 관리되고 사용자에게 제공되는 기능 그룹으로 발전할 수 있다 - 즉, 하나 이상의 플랫폼으로 말이다. 기능이 더욱 세분화되고 발견이 가능해짐에 따라, 플랫폼 사용의 동기는 의무나 인센티브와 같은 더 외부적인 동기에서 벗어나는 것이 일반적이다. 이는 사용자가 스스로 플랫폼 기능을 선택하고 더 넓은 플랫폼 에코시스템에 이상적으로 그들의 노력을 투자하도록 만든다. + +
+ +
+
+플랫폼 채택의 일반적인 성장 패턴을 나타내는 다이어그램이다. 이는 주로 플랫폼 빌더에 의해 주도하는 느린 시작을 보여준다. 일단 플랫폼이 사용자에게 충분한 가치를 제공하게 되면, 사용자에 의해 성장세가 더욱 빨라져 채택 곡선이 가파르게 된다. +
+
+
+
+ +### 레벨 1, 제공(Provisional) — 불규칙 + +공유 플랫폼과 기능의 채택은 산발적이고 일관성이 없다. 필요한 지원 서비스 및 기술을 선택하고 통합하기 위한 조직 차원의 전략이나 지침이 존재하지 않는다. 개별 팀은 자체 프로세스를 개선하기 위해 플랫폼 관행을 활용할 수 있지만, 조직 전체에 걸쳐 조율된 노력이나 표준화는 없다. 이러한 수준의 채택은 일관된 접근 방식이 없고 외부 도구가 내부에서 제공하는 도구보다 더 효과적이라는 생각이 특징이다. + +#### 특징: + +* 일회성 도구, 서비스와 기능은 조직의 다양한 팀과 부서에서 관리하고 사용한다. +* 공급자 관리(일명 "클라우드") 서비스는 내부 구성을 찾거나 사용하기 어렵기 때문에 표준 관행과 정책 없이 일관성 없이 채택되고 사용된다. +* 앱 및 서비스 팀이 중앙 집중식 프로세스가 아닌 소문이나 우연한 대화를 통해 도구와 기능을 우연히 발견한다. +* 구성 요소와 기능의 조정과 재사용은 최종 사용자(애플리케이션 팀)에 의해서만 이루어진다. +* 프로덕트 팀은 각각 애플리케이션 배포를 위한 자체 스크립트 또는 도구 세트를 유지 관리한다. + +#### 예시 시나리오: + +* 은행 서비스에는 데이터베이스가 필요하다. 한 개발자가 다른 팀의 친구로부터 AWS 계정을 요청하고 RDS 데이터베이스를 설정할 수 있다는 사실을 알게 되었다. 다른 팀에서 해당 데이터베이스를 프로비저닝하기 위한 Terraform 스크립트를 찾는다. 모니터링을 위해 임시로 CloudWatch를 사용한다; Terraform 스크립트를 실행하기 전에 AWS 콘솔에서 해시코프 볼트 인스턴스로 시크릿을 수동으로 복사한다. + +### 레벨 2, 운영(Operationalized) — 외부 푸시 + +조직은 공유 플랫폼과 기능의 가치를 인정하고 이를 장려하고 육성하기 위해 노력한다. 내부 지침에 따라 일부 사용 사례에 대해서는 공유 플랫폼 서비스 사용을 장려하거나 요구하기도 한다. 일부 프로덕트 팀은 다른 프로덕트 팀보다 플랫폼 기능을 더 많이 사용한다; 기능은 조직의 일반적인 사용 사례는 포함하지만 특이한 사용 사례는 포함하지 않는다; 그리고 이러한 이상치를 공통 플랫폼에 추가하기는 어렵다. + +사용자가 기능을 발견하고 사용하는 방법은 일관되지 않는다; 프로덕트 팀의 사용자가 플랫폼 팀의 지시가 없다면 지원되는 기능을 발견하지 못할 수도 있다. + +#### 특징: + +* 어느 정도의 외부 자극은 플랫폼 기능의 사용으로 이어진다. 예를 들면 다음과 같다. + * 개인 리뷰와 같은 인센티브 + * 프로덕션 릴리스에 사용을 요구하거나 자금을 지원받는 것과 같은 의무 사항 +* 플랫폼 기능의 활용은 단편적이다 - 사용자는 한 가지 기능을 활용할 수 있지만 사용 가능한 다른 기능을 인식하지 못하거나 채택하는 데 관심이 없을 수도 있다. +* 사용자는 플랫폼 기능 사용법을 배우려는 동기가 낮고 업무 시간이나 헬프 데스크와 같은 포럼을 통해 공급자와의 협업에 크게 의존한다. +* 플랫폼 사용자는 비공식적인 실무 커뮤니티에 참여하여 문제와 해결책을 공유하도록 권장되지만 참석이 제한될 수 있다. + +#### 예시 시나리오: + +* 엔지니어링 조직에서 표준 배포 도구를 결정하고 모든 팀에게 이를 사용하도록 지시한다. 새로운 프로세스(릴리스 노트 커뮤니케이션 등)는 해당 표준을 중심으로 구축된다. 팀들은 다른 종류의 배포 스크립트 사용을 중단하고 대신 공통 도구를 사용하라는 지시를 받는다. 새로운 프로세스를 이해하지 못하거나 확장할 수 없는 일부 팀에게는 이 과정이 어려울 수 있다. + +### 레벨 3, 확장(Scalable) — 내부 풀 + +프로덕트와 서비스 팀의 사용자들은 더 높은 품질의 지원 서비스를 제공하면서 프로덕트 팀의 인지 부하를 줄이는 데 제공되는 명확한 가치 때문에 플랫폼과 그 기능을 사용하기로 선택한다. 문서화와 인체공학적 인터페이스를 통해 프로덕트 팀 사용자는 플랫폼 기능을 신속하게 프로비저닝하고 사용할 수 있다. 사용자들은 직접 기능을 개발하거나 공급자를 고용하는 등의 대안 대신 내부 플랫폼 구현을 선택한다. + +#### 특징: + +* 플랫폼 채택은 자립적이다 - 핵심 채택의 주요 동인은 사용자가 플랫폼 제품을 사용하도록 하는 외부의 자극이나 인센티브가 아니다 - 오히려 사용자를 끌어들이는 플랫폼 제품 자체의 가치이다. +* 사용자는 한 가지 또는 일부 플랫폼 기능을 사용하고 만족한 후, 다른 기능을 찾게 되고 여러 기능에서 비슷한 경험을 하게 된다. 개별 기능이 분리된 것이 아니라, 오히려 더 큰 플랫폼 기능 세트 중 하나의 기능일 것이라는 기대가 있다. +* 플랫폼 팀은 사용자 피드백을 수집하고 로드맵을 공유하며 사용자와의 대화를 위한 공개 포럼을 유지함으로써 플랫폼의 자연스러운 채택을 장려한다. +* 애플리케이션 및 프로덕트 팀은 지불 거절(chargeback) 시스템 등을 통해 플랫폼 기능에 대한 비용을 지불할 만큼 플랫폼 기능을 중요하게 생각한다. +* 사용자는 공개 포럼과 공유 로드맵을 통해 피드백을 공유하고 향후 출시될 기능에 대해 배울 수 있다. +* 셀프 서비스 포털, 골든패스 템플릿과 기타 문서를 통해 빠르게 사용할 수 있다. + +#### 예시 시나리오: + +* 한 애플리케이션 팀이 이전에 새 데이터베이스를 성공적으로 요청한 적이 있다. 프로세스는 이해하기 쉬웠고 대기 시간도 거의 필요하지 않았다. 게다가, 백업과 모니터링 같은 핵심 기능이 포함되어 있어 문제 없이 프로덕션까지 사용할 수 있었다. 이러한 경험은 팀이 나중에 큐가 필요할 때, 가장 먼저 본능적으로 내부 플랫폼 옵션을 확인하는 것임을 의미했다. 원래는 특정 큐 기술을 사용하려고 했지만, 결국 내부에서 제공하는 솔루션이 조직에 얼마나 잘 통합되는지 알았기 때문에 내부에서 제공하는 기술을 사용하기로 결정했다. + +### 레벨 4, 최적화(Optimizing) — 참여형 + +프로덕트 팀의 사용자는 에코시스템에 참여하여 다시 기여함으로써 플랫폼 기능에 더욱 투자한다. 일부 기여는 기존 기능을 개선하고 수정한다; 다른 기여는 새로운 사용 사례를 해결하기 위해 새로운 기능과 특징을 도입한다. 프로세스와 서비스가 정의되어 사용자가 요구사항을 파악하고 여러 제품과 플랫폼 팀 간의 기여를 조정할 수 있다. 새로운 기능은 일관된 인터페이스와 포털을 통해 완전한 문서화 와 표준 버전 관리와 함께 게시된다. + +#### 특징: + +* 앱/서비스 팀의 사용자는 플랫폼 기능에 대한 수정 사항, 기능 및 피드백을 제공할 수 있다. +* 외부 프로젝트와 표준을 전략적으로 활용하여 유지관리 비용을 절감하고, 새로운 기능 제공을 가속화하고, 조직 인력을 가장 효과적으로 활용한다. +* 새로운 기능과 개선 사항은 이슈 보드와 풀 리퀘스트를 통해 비동기적으로 조정된다. 문서와 체크리스트를 통해 기여자가 자기 주도적으로 개발할 수 있다. +* 개발자 옹호자와 내부 홍보대사가 플랫폼 소유권을 앱과 서비스 팀 기여자에게까지 확장하여 내부 사용자 커뮤니티를 구축하고 지원한다. +* 플랫폼 기능의 사용은 리더(leadership)와 개인 기여자 모두 조직에서 일하는 가장 좋은 방법으로 간주된다. +* 플랫폼 엔지니어는 프로덕트 팀 계획에 참여하여 요구 사항을 파악하고 관련 기존 기능을 제안한다. + +#### 예시 시나리오: + +* 한 팀에서 대체 백업 계획을 원한다. 이를 일반 제안(offering)으로 제안한 후, 재사용이 최소화되어 우선순위가 낮은 것으로 간주된다. 제안 팀은 솔루션을 플랫폼 프레임워크에 통합하여 조직에서 사용할 수 있도록 하기로 선택한다. 원래는 알파 제안(offering)이지만 모든 운영 요구 사항을 충족하면 핵심 플랫폼 기능으로 승격될 수 있다. + +{{< /tab >}} +{{< tab tabName="Interfaces">}} + +

사용자는 어떻게 플랫폼 기능과 상호 작용하고 소비하나요?

+ +플랫폼에서 제공하는 인터페이스는 사용자가 기능을 프로비저닝, 관리, 관찰하기 위해 이러한 플랫폼 제품과 상호작용하는 방식에 영향을 미친다. 인터페이스에는 자동화 가능한 API 및 명령줄(CLI) 도구뿐만 아니라 티켓팅 시스템, 프로젝트 템플릿, 그래픽 포털들이 포함될 수 있다. + +인터페이스의 주요 특징에는 초기 요청, 유지 관리 또는 사고 분류와 같은 주요 사용자 여정에서 얼마나 검색 가능하고 사용자 친화적인지가 포함된다. 여기서 성숙도가 높을수록 더 통합되고, 일관되며, 자동화되고, 지원되는 인터페이스가 반영된다. + +### 레벨 1, 제공(Provisional) — 사용자 정의 프로세스 + +다양한 기능과 서비스를 제공하기 위해 다양한 프로세스의 집합이 존재하지만, 인터페이스의 일관성은 고려되지 않는다. 사용자 맞춤형 프로세스는 개인이나 팀의 즉각적인 요구 사항을 해결하며 공급자가 일부 자동화된 구현 스크립트를 사용하더라도 수동 개입에 의존한다. + +이러한 솔루션을 요청하는 방법에 대한 지식은 개인 간에 공유된다. 서비스 요청 프로세스는 표준화 및 일관성이 부족하다. 플랫폼 서비스를 프로비저닝하고 사용하려면 기능 공급자의 심층적인 지원이 필요할 수 있다. + +중앙 요구사항과 표준이 부족하여 회사가 아직 기대치를 파악하고 문서화하지 않은 경우에 이 수준이 적합하다. 특히 초기 단계의 회사나 플랫폼 작업을 하는 팀에 효과적일 수 있다. 이러한 환경에서는 팀이 필요에 따라 프로세스와 기능을 자유롭게 발전시킬 수 있으므로, 나중에 필요할 때만 표준화에 대한 대가를 지불하고 더 빠르게 제공할 수 있다. + +#### 특징: + +* 사용자 상호작용은 주요 논의 주제가 아니며 새로운 기능을 다자인하고 제공하는 과정에서 상호작용을 테스트하는 경우는 거의 없다. +* 기능은 주로 수동 요청을 통해 제공되지만 공급자는 사용자 요청을 프로비저닝하는 데 필요한 활동의 일부 또는 전부를 자동화할 수 있다. +* 겉보기에는 “단순”해 보이는 요청이 따라야 할 올바른 프로세스를 찾느라 복잡해지기도 한다. +* 때때로 프로세스가 승인된 것처럼 보이지만, 다른 부서나 팀이 관여할 때 사용자에게 문제가 발생하는 경우도 있다. + +#### 예시 시나리오: + +* 애플리케이션 팀이 새로운 변경 사항을 성능 테스트하려고 한다. 이를 위해, 정확한 성능을 파악할 수 있는 충분한 테스트 데이터가 포함된 격리된 환경을 원한다. 마지막으로 이 요청을 받았을 때 이전 팀원이 환경에 액세스할 수 있었지만, 그 후 이직하여 아무도 환경을 다시 만드는 방법을 모른다. 결국, 며칠 내에 환경을 프로비저닝할 수 있는 인프라 팀의 엔지니어와 연결되어졌다. +* 프로덕트 개발의 탐색 단계에 있는 팀은 맞춤형 프로세스를 사용하여 솔루션이 추가 투자를 보장하는지 검증할 필요 없이 새로운 클라우드 서비스를 프로비저닝할 수 있다. + +### 레벨 2, 운영(Operationalized) — 표준 도구 + +플랫폼과 기능을 프로비저닝하고 관찰하기 위한 일관된 표준 인터페이스가 존재하며 광범위한 요구사항을 충족한다. 사용자는 사용 가능한 기능을 파악할 수 있으며 필요한 기능을 요청할 수도 있다. + +문서와 템플릿의 형태로 "포장된 길(Paved roads)" 또는 "황금 경로(golden paths)"가 제공된다. 이러한 리소스는 규정을 준수하고 테스트를 거친 패턴을 사용하여 일반적인 기능을 프로비저닝하고 관리하는 방법을 정의한다. 일부 사용자는 이러한 솔루션을 스스로 사용할 수 있지만, 이러한 솔루션에는 여전히 심층적인 도메인 전문 지식이 필요한 경우가 많으므로 유지 관리자의 지원이 여전히 필수적이다. + +#### 특징: + +* 기술 솔루션은 문제 영역에 특정한 기본 제공 도구이며, 항상 사용자에게 친숙한 도구는 아니다. +* 공통 경로에 대한 투자가 있다; 그러나, 단일 옵션을 구축하는 데 중점을 두었기 때문에 해당 경로에서 벗어나는 것은 적은 사용자 정의 옵션을 빠르게 발견하게 된다. +* 표준화를 통해, 비공식 내부 그룹이 형성되고 모여 모범 사례를 공유하고 공유된 문제를 극복할 수 있다. +* 팀이 템플릿을 가져와 사용자 정의한 다음 중앙 집중식 팀의 변경 사항을 병합할 수 없기 때문에 기능 구현에 드리프트가 있을 수 있다. + +#### 예시 시나리오: + +* 중앙 집중식 팀이 다양한 유형의 인프라를 프로비저닝하기 위해 Terraform 모듈, Kubernetes 컨트롤러 및 CRD를 큐레이션한다. +* 공유 위치에는 조직 전반의 솔루션에 대한 종합적인 문서가 포함되어 있다. + +### 레벨 3, 확장(Scalable) — 셀프 서비스 솔루션 + +솔루션은 사용자에게 자율성을 제공하고 메인테이너의 지원이 거의 필요하지 않은 방식으로 제공된다. 조직은 솔루션이 한 기능에서 다른 기능으로 사용자 경험을 검색하고 이동시킬 수 있는 일관된 인터페이스를 제공하도록 장려하고 이를 가능하게 한다. 셀프 서비스이지만, 이러한 솔루션은 팀의 인식과 구현이 필요하다. 이러한 경험을 개선하기 위해 사용자가 플랫폼 기능을 보다 빠르게 채택하고 통합할 수 있도록 안내하고 간소화한 내부 언어가 있을 수 있다. 이렇게 하면 사용자 중심의 셀프 서비스가 가능하고 일관된 기능 모음이 생성된다. + +#### 특징: + +* 솔루션은 "원클릭" 구현으로 제공되므로, 프로비저닝 방법을 이해할 필요 없이 팀에서 기능을 활용할 수 있다. +* 솔루션은 쉽게 만들 수 있지만, 2일 차와 솔루션 관리 이후에는 유용성이 그다지 높지 않을 수 있다. +* 사용 가능한 솔루션의 경로가 계속 좁아지고 있어, 고유한 요구 사항을 가진 사용자가 어떻게 진행해야 할지 모를 수 있다. + +#### 예시 시나리오: + +* 데이터베이스의 생성과 유지 관리를 추상화하고 연결 문자열, 시크릿 데이터의 위치, 관찰 가능성(Observability) 데이터가 있는 대시보드와 같은 해당 플랫폼 기능을 활용하는 데 필요한 모든 정보를 사용자에게 제공하는 API가 제공된다. + +### 레벨 4, 최적화(Optimizing) — 관리형 서비스 + +플랫폼 기능은 팀이 이미 업무에 사용하고 있는 도구와 프로세스에 투명하게 통합된다. 배포된 서비스에 대한 관찰 가능성(Observability) 또는 신원 관리와 같은 일부 기능은 자동으로 프로비저닝된다. 사용자가 제공된 서비스의 가장자리에 도달하면, 플랫폼 기능은 빌딩 블록으로 간주되기 때문에 내부 제품을 떠나지 않고도 자동화된 솔루션을 넘어 필요에 맞게 사용자 정의할 수 있는 기회가 있다. 이러한 빌딩 블록은 투명하고 자동화된 구성을 구축하여 상위 수준의 사용 사례를 충족하는 동시에 필요한 경우 더 심층적인 사용자 지정이 가능하도록 하는 데 사용된다. + +#### 특징: + +* 조직을 차별화하는 기능과 그렇지 않은 기능이 명확하므로, 내부 팀은 업계 표준을 활용할 수 없는 경우에만 맞춤형 솔루션에 투자할 수 있다. +* 기능은 일관된 방식으로 표면화되지만, 기능을 사용하기 위한 방법은 제한이 없다. 일부는 스크립트에 사용하기 위한 CLI 도구로 가장 적합한 반면 다른 일부는 사용자가 편집기 및 IDE에서 코드를 작성하는 위치에 통합되어 이점을 얻는다. +* 개별 기능의 가치는 소프트웨어 개발 및 릴리스의 흐름에 초점을 맞춰 확장되어, 기능을 더 높은 수준의 제품으로 결합하는 방법에 중점을 둔다. +* 기능은 패키지 형태로 제공되는 경우가 많지만, 슈퍼 유저는 필요한 시기와 장소를 최적화하기 위해 이러한 더 높은 수준의 서비스를 분해할 수 있다. + +#### 예시 시나리오: + +* 모든 워크로드에 관찰 가능성(Observability) 에이전트가 주입되고 모든 애플리케이션 앞에 OIDC 프록시가 배치된다. +* 기본적으로 모든 새 프로젝트는 태스크 러너 (파이프라인) 와 런타임 환경(K8s 네임스페이스)의 공간을 제공받지만, 프로젝트는 서버리스 런타임과 같은 다른 옵션을 선택할 수 있다. +* 서비스 나우 포털의 카탈로그에서 사용자가 “데이터베이스 프로비저닝”을 선택하면 자동화가 RDS 데이터베이스를 프로비저닝하고 사용자에게 자격 증명을 가져올 수 있는 URL과 위치를 보낸다. + +{{< /tab >}} +{{< tab tabName="Operations">}} + +

플랫폼과 그 기능은 어떻게 계획되고, 우선순위가 정해지고, 개발되고, 유지관리되나요?

+ +플랫폼 운영이란 새로운 요청의 수락, 초기 릴리스, 업그레이드와 확장, 지속적인 유지관리와 운영, 사용자 지원, 심지어 사용 중단과 종료까지 포함하여 전체 수명 기간 동안 플랫폼의 기능과 특징들을 실행하고 지원하는 것을 의미한다. 조직과 플랫폼 팀은 플랫폼과 기능을 선택하여 만들고 유지 관리하며 가장 가치 있고 영향력 있는 이니셔티브의 우선순위를 정할 수 있다. + +특히, 기능을 제공하기 위한 대부분의 작업은 초기 출시 이후 - 원활한 업그레이드, 새롭고 향상된 기능, 운영 지원, 최종 사용자 지원 과 교육 제공으로 확장된다. 따라서 영향력 있고 가치 있는 플랫폼은 장기적으로 지속 가능한 운영과 안정성을 위해 미리 계획을 세우고 플랫폼을 관리한다. + +### 레벨 1, 제공(Provisional) — 요청마다 + +플랫폼과 기능은 임시(ad hoc) 프로덕트 팀의 요청과 요구 사항에 따라 즉각적으로 개발되고, 게시되고 업데이트된다. 심지어 프로덕트 팀이 스스로 필요한 기능을 계획하고 구축해야 할 수도 있다. + +전담 중앙 집중식 팀이든 자체 요구 사항을 충족하는 애플리케이션 팀이든 새로운 기능을 구축하는 팀은 그 기능을 사용하는 다른 사람들을 지원하는 비공식적인 책임만 진다. 그들은 적극적으로 유지 관리하지 않을 것으로 예상되며 제공된 기능의 품질을 검증하는 프로세스도 거의 존재하지 않는다. 이러한 수준에서, 보안 취약점이 발견되거나 버그로 인해 사용이 불가능하거나 새로운 요구 사항이 발생할 때까지 구현이 종종 무시되며, 이 시점에서 다른 대응 계획이 신속하게 구현될 수 있다. + +#### 특징: + +* 개별 애플리케이션 팀의 긴급한 요구 사항을 충족하기 위해 기능이 만들어진다. +* 핵심 기능의 초기 제공에 중점을 두며; 지속적인 유지 관리와 지속 가능성에 대한 계획은 수립되지 않는다. +* 기능 구현이 일반적으로 오래되어 업데이트를 기다리고 있다. +* 취약점 발견과 같이 영향력이 큰 기능 변경을 위해 갑작스럽게 업무가 급증한다. +* 변경으로 인해 계획된 다운타임과 계획되지 않은 다운타임이 모두 발생할 수 있다. +* 각 업그레이드는 맞춤형 방식으로 이루어지므로 각, 업그레이드에 대한 프로세스를 고안하는 데 많은 시간과 연구가 필요하다. + +#### 예시 시나리오: + +* Log4Shell 보안 취약점이 발표되고 조직은 전문 팀을 구성하여 조직이 취약할 수 있는 부분을 조사하고 패치를 유도한다. 팀에서 영향을 파악한 후, 각 팀마다 서버와 업그레이드 프로세스를 다르게 관리하기 때문에 여러 팀과 협력하여 작업해야 한다. 이 작업이 완료된 것으로 간주되더라도, 더 많은 사례가 발견되지 않을 것이라는 신뢰 수준은 상당히 낮다. + +### Level 2, 운영(Operationalized) — 중앙 추적 + +플랫폼과 기능은 중앙에서 문서화되고 검색이 가능하며, 기능의 수명주기를 계획하고 관리하는 프로세스는 최소한 간략하게 정의되어 있다. 각 서비스와 기능에 대한 책임과 소유권이 문서화되어 있다. 수명 주기 관리 프로세스는 소유자와 우선순위에 따라 기능마다 다양하다. 중앙 집중식 팀은 현재 기능에 대한 유지 관리 상태를 제공하기 위해 백로그 기능의 인벤토리를 유지 관리하거나 필요에 따라 생성할 수 있다. 이를 통해 조직은 기능 제공에 대한 진행 상황을 추적하고 업그레이드 요구 사항을 준수할 수 있다. + +#### 특징: + +* 애플리케이션 팀은 긴급한 요구 사항을 충족하기 위해 필요에 따라 새로운 기능을 만든다. +* 중앙 팀에서 조직 전체에 사용 가능한 공유 서비스 목록을 제공한다. +* 자동화 가능한 API와 사용 설명서 요구와 같은 느슨한 표준이 기능에 적용된다. +* 배포된 서비스를 더 쉽게 추적할 수 있도록 코드형 인프라(IaC)를 사용한다. +* 서비스 인벤토리를 통해 PCI DSS 또는 HIPPA와 같은 규정 준수 규정에 대한 감사가 활성화된다. +* 마이그레이션과 업그레이드 작업을 번다운 차트에 따라 추적되므로 규정 준수율과 완료까지 걸리는 시간을 추적할 수 있다. +* 추적은 지원의 수준을 나타내지 않으며; 이 단계의 업그레이드는 여전히 수동과 맞춤형으로 이루어지는 경우가 많다. + +#### 예시 시나리오: + +* PostgreSQL 11은 연말에 지원 종료된다. 조직은 업그레이드가 필요한 데이터베이스를 파악하고 있으며 각 팀의 백로그 작업을 완료하기 위해 일정을 잡고 있다. + +### Level 3, 확장(Scalable) — 중앙 활성화 + +플랫폼과 기능은 중앙에서 등록될 뿐만 아니라 중앙에서 조율된다. 플랫폼 팀은 조직의 광범위한 요구 사항을 파악하고 그에 따라 플랫폼 팀과 인프라 팀의 업무 우선순위를 정할 책임을 가진다. 기능을 담당하는 사람들은 해당 기능을 기술적으로 유지 관리할 뿐만 아니라, 조직 내 다른 관련 서비스와 기능을 통합하기 위한 표준 사용자 경험을 제공하고, 안전하고 안정적인 사용을 보장하며, 관찰 가능성까지 제공할 것으로 기대된다. + +새로운 기능을 만들고 발전시키기 위한 표준 프로세스가 존재하므로, 조직 내 누구나 기대에 부합하는 솔루션을 제공할 수 있다. 플랫폼 기능과 특징에 대한 지속적인 제공 프로세스를 통해 정기적인 롤아웃과 롤백이 가능하다. 대규모 변경은 고객 대면 프로덕트 변경과 마찬가지로 계획되고 조정된다. + +#### 특징: + +* 애플리케이션 팀은 서비스를 만들기 전에 먼저 플랫폼 팀에 서비스를 요청한다. +* 새로운 서비스는 표준 인터페이스, 문서화와 거버넌스 같은 표준 관행을 준수해야 한다. +* 업그레이드 프로세스는 버전과 서비스 전반에 걸쳐 문서화되고 일관성을 유지한다. +* 기능 공급자가 업그레이드를 관리하지 않는 경우, 영향을 최소화하기 위해 사용자에게 도구와 지원을 제공한다. + +#### 예시 시나리오: + +* 조직은 RHEL 9로 업그레이드할 예정이다. 이 과정에서, 각 애플리케이션 팀은 소프트웨어가 계속 작동하는지 확인해야 한다. 이 테스트 단계를 활성화하기 위해 중앙 집중식 컴퓨팅 팀은 각 팀에 올바른 소프트웨어 및 OS 버전으로 테스트 환경을 설정하고 있다. + +### Level 4, 최적화(Optimizing) — 관리형 서비스 + +각 기능의 수명 주기는 표준화되고 자동화된 방식으로 관리된다. 기능, 특징과 업데이트는 사용자에게 영향을 주지 않고 지속적으로 제공된다. 플랫폼 공급자가 주도하는 모든 대규모 변경에는 책임과 일정이 정의된 기존 사용자를 위한 마이그레이션 계획이 포함된다. + +플랫폼 기능 공급자는 유지 관리에 대한 책임을 지지만, 사용자의 책임을 설명하는 명확한 계약 - "공유 책임 모델" - 을 통해, 양측이 대부분 자율적으로 운영할 수 있도록 한다. + +#### 특징: + +* 공유 소유권 모델은 플랫폼과 그 기능에 대한 책임이 누구에게 있는지 사용자에게 기대되는 것이 무엇인지 명확하게 정의한다. +* 팀은 업그레이드 실행과 롤백 전략을 모두 스크립화하여 위험과 영향을 낮게 유지한다. +* Teams script both the execution of the upgrade and any rollback strategies to keep risk and impact low. + +#### 예시 시나리오: + +* 가상 머신 사용자는 버전 업그레이드와 관련된 어떤 것도 관리할 필요가 없다. 그들의 유일한 요구 사항은 배포 파이프라인에 대표적인 스모크 테스트가 포함된 단계를 갖는 것이다. 그런 다음 얼리 어답터가 되기 위해 완전히 굳어진 업그레이드 또는 더 높은 위험 허용 범위를 기다릴 수 있도록 애플리케이션을 위험 허용 범위가 낮은 것으로 선언하도록 요청받는다. 그런 다음 가상 머신 기능은 스모크 테스트 또는 카나리아 릴리스 실패 후 롤백을 포함한 업그레이드의 자동 릴리스를 관리한다. + +{{< /tab >}} +{{< tab tabName="Measurement">}} + +

피드백과 학습을 수집하고 반영하는 과정은 어떻게 되나요?

+ +사용자의 명시적 및 암묵적 피드백에 반응함으로써, 조직은 사용자 만족도를 높이고 장기적인 플랫폼 지속 가능성을 보장할 수 있다. 조직은 플랫폼의 관련성을 유지하기 위해 혁신과 사용자 요구 충족의 균형을 유지해야 한다. 기술과 사용자 선호도가 변화함에 따라, 이러한 변화에 민첩하게 대응하는 플랫폼이 돋보이게 될 것이다. 피드백 메커니즘을 정기적으로 재검토하고 개선하면 플랫폼 개발을 더욱 최적화하고 사용자 참여를 향상시킬 수 있다. + +### Level 1, 제공(Provisional) — 즉흥적 + +사용량과 만족도 지표는 각 플랫폼과 기능별로 사용자 지정 방식으로 수집된다. 결과와 성공의 척도가 여러 기능에 걸쳐 일관되게 조정되지 않으므로, 그에 상응하는 인사이트가 수집되진 않는다. 플랫폼 사용에 대한 사용자 피드백과 계측이 수집되지 않거나, 수집되더라도 비공식적으로 이루어진다. 일화적인 요구 사항과 불완전한 데이터를 기반으로 의사 결정이 이루어지게 된다. + +#### 특징: + +* 플랫폼의 성공을 측정하는 방법에 대한 경험이나 의견이 없다 +* 익숙한 도구를 사용하여 제한된 의도와 예측을 통해 일반적인 지표를 수집 +* 소량의 데이터에 의존 +* 사용자 참여를 확보하기 어렵다 - 사용자는 자신의 피드백이 고려되지 않는다고 생각한다 +* 설문조사를 사용하는 경우, 설문조사가 실행 간에 질문이 변경되어 진행 상황을 추적할 수 없다 + +#### 예시 시나리오: + +* 플랫폼 기술 책임자가 다음 분기 계획에 주요 주제를 추가하여 사용자와의 협업을 개선하고자 한다. 사용자들이 보고 싶어 하는 것에 대한 설문조사를 실시하기로 결정한다. 응답이 압도적으로 많아 흥미롭지만, 모든 아이디어를 정리하고 응답하는 데 어려움을 겪게 된다. 일부 아이디어는 분기별 계획에 영향을 미치지만, 사용자들은 자신의 아이디어가 받아들여졌다고 생각하지 않고 다음 설문조사에 응답하는 경향이 줄어든다. +* 팀은 더 많은 데이터를 자동으로 수집하기를 원하기 때문에, CI에서 테스트 실패와 같이 쉽게 수집할 수 있는 기회를 찾는다. 그러나, 모든 팀이 동일한 CI 자동화를 사용하는 것은 아니기 때문에 일부 팀은 Scala로 서비스를 작성하는 단계로 넘어갔지만 데이터는 Java 애플리케이션에서만 사용할 수 있다. + +### Level 2, 운영(Operationalized) — 일관된 수집 + +이 단계의 조직은 플랫폼 프로덕트가 내부 사용자 시장의 요구 사항을 충족하는지 검증하려는 의도적인 목표를 가지고 있다. 실행 가능하고 구조화된 사용자 피드백 수집이 중요하다. 피드백 수집을 위해 전담 팀이나 개인을 지정하여, 보다 일관된 접근 방식을 보장할 수 있다. 설문조사나 사용자 포럼과 같은 피드백 채널은 표준화되어 있으며, 피드백은 분류되고 우선순위가 정해진다. 사용자 피드백 외에도, 사용자 경험을 계측하여 시간이 지남에 따라 사용 데이터를 생성하는 것도 기대할 수 있다. + +피드백을 실행 가능한 작업으로 전환하는 데는 여전히 과제가 남아 있다. 사용자 데이터의 저장소가 늘어나고 있지만, 조직은 이러한 피드백을 효과적으로 이해하고 플랫폼 로드맵에 통합하는 데 도움이 필요할 수 있다. 사용자가 피드백을 통해 가시적인 변화를 체감할 수 있도록 보장하는 것이 어려울 수 있다. + +#### 특징: + +* 데이터 수집은 대부분의 주요 계획 세션 또는 기능 구현의 일부로 논의된다. +* 성공을 확인하기 위해 무엇을 측정해야 하는지 정확히 일치하지 않을 수 있다. +* 플랫폼 기능은 사용자 채택 또는 사용자 시간 절약을 측정하여 성공 여부를 측정할 수 있다. + +#### 예시 시나리오: + +* 플랫폼 팀은 설문조사와 기타 인터뷰 기법을 통해 파악한 사용자 정의 기능에 업무 시간의 20%를 할당한다. 조사 결과는 추가 투표와 댓글을 통해 우선순위를 더욱 구체화할 수 있는 도구로 수집된다. 구현 과정에서 요청하는 사용자에게 접근하여 초기 디자인과 구현에 대한 협업을 요청한다. 구현이 완료되면, 공지를 통해 요청 사용자가 새로운 기능을 인지하고 이를 채택할 수 있도록 지원한다. +* 소프트웨어 제공 기능에 중점을 둔 팀은 커밋부터 프로덕션까지 빌드 도구를 통해 자동화하는 사이클 타임을 포함하여 더 많은 데이터를 자동으로 캡쳐하기를 원한다. 사이클 타임에는 PR 검토와 같은 다른 활동도 포함될 수 있다는 것을 알고 있지만, 현재로서는 포함되지 않는다. + +### Level 3, 확장(Scalable) — 인사이트(Insights) + +강력한 표준 피드백 메커니즘이 이미 존재하지만, 이 단계에서는 구체적인 전략적 인사이트와 조치를 도출하기 위해 정교한 방식으로 데이터를 수집한다. 원하는 결과와 성과가 식별되고 이어서 해당 결과에 대한 진행 상황을 나타내기 위해 선택된 표준 측정 기준이 따른다. 특정 행동의 영향에 대한 업계 리서치로부터 이익을 얻기 위해 업계 프레임워크와 표준이 활용될 수 있다. + +피드백을 수집하고 검토하며 실행 가능한 인사이트를 요약하는 데 전담 팀 또는 도구가 사용된다. 플랫폼 프로덕트와 사용자 간의 공생 관계가 구축된다. 피드백은 플랫폼 운영과 로드맵을 안내하는 전략적 자산으로 간주된다. 정기적인 피드백 검토 세션을 마련하여, 여러 부서 팀이 모여 사용자 인사이트를 기반으로 토론하고 전략을 수립할 수 있다. + +#### 특징: + +* 새로운 플랫폼 기능을 제공하기 전에, 팀은 작업 결과를 평가하는 방법에 대해 논의한다. +* 조직은 플랫폼 이니셔티브의 성공을 나타내는 지표에 대해 폭넓게 조율한다. +* [프로덕트 관리자]({{< ref "/wgs/platforms/glossary#platform-product-managers" >}}) 또는 전담 팀원이 지속적이고 일관된 피드백 수집과 분석 프로세스를 주도한다. +* 조직이 성공을 나타내기 위해 관찰하고 목표로 삼을 지표와 목표를 설정했다. + +#### 예시 시나리오: + +* 조직은 빌드 시간과 리드 시간을 지속적으로 추적해 왔다. 그러나 이제는 수집하기는 쉽지만, 이것만으로는 소프트웨어 제공에 대한 완전한 그림을 보여주지 못한다는 것을 깨닫게 되었다. 이를 염두에 두고, 팀은 서비스 신뢰성 및 안정성에 대한 측정을 구현한다. + +### Level 4, 최적화(Optimizing) — 정량적, 정성적 + +피드백과 측정은 조직의 문화에 깊이 통합되어 있다. 최고 경영진부터 엔지니어에 이르기까지 조직 전체가 데이터 수집과 프로덕트 발전에 대한 피드백의 가치를 인식하고 있다. 플랫폼 사용자와 비즈니스 리더를 비롯한 다양한 이해관계자가 플랫폼 개선을 위한 가설을 세우고, 디자인 과정에서 피드백을 제공하고, 출시 후 영향을 측정하는 데 적극적으로 참여하는 데이터의 민주화가 이루어지고 있다. 이러한 모든 측정은 플랫폼 이니셔티브를 계획할 때 고려된다. + +표준 프레임워크가 활용될 뿐만 아니라, 다양한 각도에서 측정해야 보다 전체적인 그림을 그릴 수 있다는 인식이 확산되고 있다. 정량적 측정이 개선됨에 따라 정성적 측정이 어떻게 변화하는지 이해하는 데 투자하고 있다. 사용자의 요구를 지원하고, 문제를 완화하며, 업계 트렌드와 비즈니스 요구사항에 앞서 나갈 수 있는 기능을 예측할 수 있는 선도적인 측정을 파악하는 데 초점을 맞추고 있다. + +#### 특징: + +* 플랫폼 팀은 지속적으로 모니터링하는 지표와 데이터 수집 방식을 개선하기 위한 방법을 모색한다. +* 조직은 [굿하트의 법칙(Goodhart's Law)](https://en.wikipedia.org/wiki/Goodhart%27s_law)에 익숙하며 이에 민감하다: "측정값이 목표가 되면, 더 이상 좋은 측정값이 아니다." +* 수집된 메트릭과 원격 측정은 진정한 인사이트와 가치를 위해 지속적으로 평가된다. +* 데이터 레이크 관리와 인사이트 도출을 위한 표준 플랫폼 기능과 같이 메트릭 데이터 관리가 잘 지원된다. +* 부서 간 협업을 장려하여 데이터 사일로를 방지하고 효과적인 피드백 사이클을 가능하게 한다. + +#### 예시 시나리오: + +* 시간이 지남에 따라 조직에서 수집한 데이터에 따르면 빌드 시간이 15% 이상 증가했다. 이는 부정적인 개발자 경험을 유발하며, 일단 트리거가 발생하면 빌드 시간이 원래 시간보다 단축되더라도 개발자는 더 오랫동안 좌절감을 느끼게 된다. 이러한 인사이트를 통해 빌드 팀은 서비스 수준 목표(SLO)를 설정하고 준수하여, 사용자에게 부정적인 사이클이 시작되기 전에 조기에 식별하고 개선할 수 있다. + +{{< /tab >}} +{{< /tabs >}} +
+ +
+ +--- +## 결론 + +플랫폼과 해당 메인테이너는 애자일한 디지털 프로덕트 개발을 위한 기반을 제공한다. 플랫폼은 효율적인 소프트웨어 개발과 제공을 가능하게 하는 일관된 기능 모음을 제공한다. 이 성숙도 모델은 플랫폼 엔지니어링 여정을 위한 지도를 제공한다. diff --git a/website/content/ko/wgs/platforms/whitepaper/index.md b/website/content/ko/wgs/platforms/whitepaper/index.md index 3d31020d..0cba38d5 100644 --- a/website/content/ko/wgs/platforms/whitepaper/index.md +++ b/website/content/ko/wgs/platforms/whitepaper/index.md @@ -2,14 +2,14 @@ title: "CNCF 플랫폼 백서(White Paper)" pdf: https://github.com/cncf/tag-app-delivery/raw/main/platforms-whitepaper/v1/assets/platforms-def-v1.0.pdf version_info: https://github.com/cncf/tag-app-delivery/tree/main/platforms-whitepaper/README.md -description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 내부 플랫폼을 옹호하고, 조사하고, 계획할 수 있도록 지원하고자 합니다. 플랫폼은 기업의 실제 가치 흐름에 큰 영향을 미치지만 간접적으로만 영향을 미치므로 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적입니다. 이 백서에서는 플랫폼의 가치가 무엇인지, 이를 측정하는 방법, 그리고 이를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 이러한 지원을 가능하게 할 것입니다." +description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 내부 플랫폼을 옹호하고, 조사하고, 계획할 수 있도록 지원하고자 한다. 플랫폼은 기업의 실제 가치 흐름에 큰 영향을 미치지만 간접적으로만 영향을 미치므로 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적이다. 이 백서에서는 플랫폼의 가치가 무엇인지, 이를 측정하는 방법, 그리고 이를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 이러한 지원을 가능하게 할 것이다." --- ## 소개 -데브옵스가 추구하는 부서 간 협력에서 영감을 받은 플랫폼 엔지니어링(Platform Engineering)은 이러한 확실한 협력을 기반으로한 형태로 기업에 도입되기 시작했습니다. 플랫폼은 애플리케이션 개발자, 데이터 과학자, 정보를 다루는 엔지니어(Information worker) 등 내부 고객의 작업을 촉진하고 가속화하기 위해 기본 기능, 프레임워크 및 경험을 선별하고 제공합니다. 특히 클라우드 컴퓨팅에서 플랫폼은 빠른 제품 출시, 인프라 간 이동성, 더 안전하고 탄력적인 제품, 개발자 생산성 향상 등 클라우드가 오랫동안 약속한 가치를 실현하는데 도움이 되었습니다. +데브옵스가 추구하는 부서 간 협력에서 영감을 받은 플랫폼 엔지니어링(Platform Engineering)은 이러한 확실한 협력을 기반으로한 형태로 기업에 도입되기 시작했다. 플랫폼은 애플리케이션 개발자, 데이터 과학자, 정보를 다루는 엔지니어(Information worker) 등 내부 고객의 작업을 촉진하고 가속화하기 위해 기본 기능, 프레임워크 및 경험을 선별하고 제공한다. 특히 클라우드 컴퓨팅에서 플랫폼은 빠른 제품 출시, 인프라 간 이동성, 더 안전하고 탄력적인 제품, 개발자 생산성 향상 등 클라우드가 오랫동안 약속한 가치를 실현하는데 도움이 되었다. -이 백서는 기업의 리더, 아키텍트 및 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 기업 내부 플랫폼을 지지하고, 조사하고, 계획할 수 있도록 지원하고자 합니다. 플랫폼은 실제로 기업의 실제 가치 흐름에 큰 영향을 미치지만, 표면적으로는 간접적으로만 영향을 받는 것으로 보이기 때문에 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적입니다. 이 백서에서는 플랫폼의 가치가 무엇인지, 그 가치를 측정하는 방법, 가치를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 경영진 및 플랫폼 사용자 등 관계자들의 지원이 가능하게 할 것입니다. +이 백서는 기업의 리더, 아키텍트 및 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 기업 내부 플랫폼을 지지하고, 조사하고, 계획할 수 있도록 지원하고자 한다. 플랫폼은 실제로 기업의 실제 가치 흐름에 큰 영향을 미치지만, 표면적으로는 간접적으로만 영향을 받는 것으로 보이기 때문에 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적이다. 이 백서에서는 플랫폼의 가치가 무엇인지, 그 가치를 측정하는 방법, 가치를 극대화하는 플랫폼 팀을 구현하는 방법에 대해 논의함으로써 경영진 및 플랫폼 사용자 등 관계자들의 지원이 가능하게 할 것이다. @@ -27,129 +27,129 @@ description: "이 백서는 기업 리더, 엔터프라이즈 아키텍트, 플 ## 왜 플랫폼인가요? -플랫폼과 플랫폼 엔지니어링은 오늘날 클라우드 컴퓨팅 세계에서 인기 있는 주제입니다. 플랫폼 구축에 대한 정의, 기술 및 측정에 대해 알아보기 전에 먼저 플랫폼이 제공하는 가치에 대해 살펴보는 것이 중요합니다. +플랫폼과 플랫폼 엔지니어링은 오늘날 클라우드 컴퓨팅 세계에서 인기 있는 주제이다. 플랫폼 구축에 대한 정의, 기술 및 측정에 대해 알아보기 전에 먼저 플랫폼이 제공하는 가치에 대해 살펴보는 것이 중요하다. -지난 2\~3년 동안의 프로세스 개선으로 소프트웨어 애플리케이션 및 제품(Product) 팀의 민첩성이 크게 향상되어 컴퓨팅, 네트워크, 스토리지와 같은 인프라는 물론 빌드, 테스트, 배포, 관찰 가능성(Observability)과 같은 개발자를 위한 유연한 서비스 제공을 할 수 있게 되었습니다. 이러한 자율성과 프로세스 개선은 서비스 지원에 대한 책임을 점차 제품 팀으로 이전하는 효과도 가져왔으며, 제품 팀은 인프라 문제에 점점 더 많은 시간과 에너지를 소비하고 조직과 관련된 가치를 창출하는 데 더 많은 시간을 할애할 수 밖에 없게 되었습니다. +지난 2\~3년 동안의 프로세스 개선으로 소프트웨어 애플리케이션 및 제품(Product) 팀의 민첩성이 크게 향상되어 컴퓨팅, 네트워크, 스토리지와 같은 인프라는 물론 빌드, 테스트, 배포, 관찰 가능성(Observability)과 같은 개발자를 위한 유연한 서비스 제공을 할 수 있게 되었다. 이러한 자율성과 프로세스 개선은 서비스 지원에 대한 책임을 점차 제품 팀으로 이전하는 효과도 가져왔으며, 제품 팀은 인프라 문제에 점점 더 많은 시간과 에너지를 소비하고 조직과 관련된 가치를 창출하는 데 더 많은 시간을 할애할 수 밖에 없게 되었다. -제공(Delivery, `역자: 일반적으로 한국에서는 현재 기준으로 DevOps 팀에서 주로 담당`) 팀이 핵심 업무에 다시 집중하고 조직 전반에서 중복되는 노력을 줄이려는 열망으로 인해 기업들은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구현하게 되었습니다. 플랫폼에 투자함으로써 기업은 다음과 같은 이점을 얻을 수 있습니다: +제공(Delivery, `역자: 일반적으로 한국에서는 현재 기준으로 DevOps 팀에서 주로 담당`) 팀이 핵심 업무에 다시 집중하고 조직 전반에서 중복되는 노력을 줄이려는 열망으로 인해 기업들은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구현하게 되었다. 플랫폼에 투자함으로써 기업은 다음과 같은 이점을 얻을 수 있다: -1. 제품 팀의 업무 부하를 줄여 제품 개발 및 배포를 보다 빠르게 합니다. -2. 플랫폼 기능을 구성하고 관리할 전문가를 전담 배치하여 플랫폼 기능에 의존하는 제품의 안정성과 복원력 향상 시킵니다. -3. 기업 내 여러 팀에서 플랫폼 도구와 지식을 재사용하고 공유하여 제품 개발 및 제공을 가속화합니다. -4. 플랫폼 기능과 이를 둘러싼 사용자, 도구 및 프로세스를 관리하여 제품 및 서비스의 보안, 규제 및 기능 문제 위험을 줄입니다. -5. 사용자 경험에 대한 제어를 유지하면서 퍼블릭 클라우드 및 기타 관리형 제공업체에 구현을 위임하여 비용 효율적이고 생산적으로 서비스를 사용할 수 있도록 지원합니다. +1. 제품 팀의 업무 부하를 줄여 제품 개발 및 배포를 보다 빠르게 한다. +2. 플랫폼 기능을 구성하고 관리할 전문가를 전담 배치하여 플랫폼 기능에 의존하는 제품의 안정성과 복원력을 향상시킨다. +3. 기업 내 여러 팀에서 플랫폼 도구와 지식을 재사용하고 공유하여 제품 개발 및 제공을 가속화한다. +4. 플랫폼 기능과 이를 둘러싼 사용자, 도구 및 프로세스를 관리하여 제품 및 서비스의 보안, 규제 및 기능 문제 위험을 줄인다. +5. 사용자 경험에 대한 제어를 유지하면서 퍼블릭 클라우드 및 기타 관리형 제공업체에 구현을 위임하여 비용 효율적이고 생산적으로 서비스를 사용할 수 있도록 지원한다. -이러한 이점들은 부분적으로는 소수의 플랫폼 팀이 많은 제품 팀에 서비스를 제공하여 그 영향력을 확대하기 때문에 발생합니다. 플랫폼 팀이 공통적으로 기능 관리를 통합하여 거버넌스를 쉽게 이용할 수 있게 하고 또한 무엇보다도 사용자 인터페이스와 경험을 중요하게 생각하는 조직이기 때문입니다. +이러한 이점들은 부분적으로는 소수의 플랫폼 팀이 많은 제품 팀에 서비스를 제공하여 그 영향력을 확대하기 때문에 발생한다. 플랫폼 팀이 공통적으로 기능 관리를 통합하여 거버넌스를 쉽게 이용할 수 있게 하고 또한 무엇보다도 사용자 인터페이스와 경험을 중요하게 생각하는 조직이기 때문이다. -플랫폼 전문가로 구성된 팀은 제품 팀에 요구되는 공통 업무를 줄여줄 뿐만 아니라 해당 제품에 사용되는 플랫폼 기능을 최적화합니다. 또한 플랫폼 팀은 전사적으로 광범위하게 사용되는 일련의 기존 패턴, 지식 및 도구를 유지 관리하여 개발자가 동일한 기반 위에 구축된 다른 팀과 제품에 신속하게 기여할 수 있도록 지원합니다. 또한 공유 플랫폼 패턴을 통해 템플릿, 패턴 및 기능에 거버넌스 및 제어 기능을 포함할 수 있습니다. 마지막으로, 플랫폼 팀은 제공업체를 통합하고 제공 서비스에 일관된 경험을 제공하기 때문에 데이터베이스, ID 액세스, 인프라 운영 및 앱 수명주기와 같이 기본적이며 CSP(Cloud Service Provider) 별로 특화되지 않은 기능들을 사용하기 위해서(`역자 생각: Lock in에 대해서 우려`) 퍼블릭 클라우드 및 서비스 제공업체를 이용할 수 있습니다. +플랫폼 전문가로 구성된 팀은 제품 팀에 요구되는 공통 업무를 줄여줄 뿐만 아니라 해당 제품에 사용되는 플랫폼 기능을 최적화한다. 또한 플랫폼 팀은 전사적으로 광범위하게 사용되는 일련의 기존 패턴, 지식 및 도구를 유지 관리하여 개발자가 동일한 기반 위에 구축된 다른 팀과 제품에 신속하게 기여할 수 있도록 지원한다. 또한 공유 플랫폼 패턴을 통해 템플릿, 패턴 및 기능에 거버넌스 및 제어 기능을 포함할 수 있다. 마지막으로, 플랫폼 팀은 제공업체를 통합하고 제공 서비스에 일관된 경험을 제공하기 때문에 데이터베이스, ID 액세스, 인프라 운영 및 앱 수명주기와 같이 기본적이며 CSP(Cloud Service Provider) 별로 특화되지 않은 기능들을 사용하기 위해서(`역자 생각: Lock in에 대해서 우려`) 퍼블릭 클라우드 및 서비스 제공업체를 이용할 수 있다. -## 플랫폼이란 어떤걸까요?? +## 플랫폼이란 어떤 걸까요?? -클라우드 네이티브 컴퓨팅을 위한 플랫폼은 플랫폼 사용자의 필요에 따라 정의되고 제공되는 기능의 통합 모음입니다. 플랫폼은 광범위한 애플리케이션 및 사용 사례에 대한 일반적인 기능과 서비스를 획득하고 통합하기 위한 일관된 경험을 보장하는 횡단 계층(cross-cutting layer, `역자: 계층간에 서로 영향을 주고 받을 수 있음 / 의존성에 가깝지만 여기서는`` `**`단일 사용자 채널`**`에 가까운 용어로 사용함` / [자세히 링크](https://zetawiki.com/wiki/%ED%9A%A1%EB%8B%A8\_%EA%B4%80%EC%8B%AC%EC%82%AC)) 입니다. 좋은 플랫폼은 웹 포털, 프로젝트 템플릿 및 셀프 서비스 API와 같은 기능 및 서비스를 사용하고 관리하기 위한 일관된 사용자 경험을 제공합니다. +클라우드 네이티브 컴퓨팅을 위한 플랫폼은 플랫폼 사용자의 필요에 따라 정의되고 제공되는 기능의 통합 모음이다. 플랫폼은 광범위한 애플리케이션 및 사용 사례에 대한 일반적인 기능과 서비스를 획득하고 통합하기 위한 일관된 경험을 보장하는 횡단 계층(cross-cutting layer, `역자: 계층간에 서로 영향을 주고 받을 수 있음 / 의존성에 가깝지만 여기서는`` `**`단일 사용자 채널`**`에 가까운 용어로 사용함` / [자세히 링크](https://zetawiki.com/wiki/%ED%9A%A1%EB%8B%A8\_%EA%B4%80%EC%8B%AC%EC%82%AC)) 이다. 좋은 플랫폼은 웹 포털, 프로젝트 템플릿 및 셀프 서비스 API와 같은 기능 및 서비스를 사용하고 관리하기 위한 일관된 사용자 경험을 제공한다. -Atlassian\[[1](https://www.atlassian.com/devops/frameworks/team-topologies)]에 따르면, "플랫폼 팀은 오버헤드가 거의 없이 수많은 스트림 정렬 \[제품] 팀에서 사용할 수 있는 기능을 만듭니다.... 플랫폼 팀은 스트림 정렬 \[제품] 팀의 리소스 및 작업 부하를 최소화합니다... 플랫폼 팀은 다양한 사용자 경험 또는 제품에 걸쳐 일관된 경험을 만들 수 있습니다."라고 설명합니다. +Atlassian\[[1](https://www.atlassian.com/devops/frameworks/team-topologies)]에 따르면, "플랫폼 팀은 오버헤드가 거의 없이 수많은 스트림 정렬 \[제품] 팀에서 사용할 수 있는 기능을 만든다.... 플랫폼 팀은 스트림 정렬 \[제품] 팀의 리소스 및 작업 부하를 최소화한다... 플랫폼 팀은 다양한 사용자 경험 또는 제품에 걸쳐 일관된 경험을 만들 수 있다."라고 설명한다. -마틴 파울러와 에반 보처\[[2](https://martinfowler.com/articles/talk-about-platforms.html)]에 따르면, "디지털 플랫폼은 하나의 매력적인 내부 제품으로 셀프 서비스 API, 도구, 서비스, 지식 및 지원을 잘 정리해서 제공합니다. 자율(Autonomous, `역자: 일종의 셀프 서비스 들로 인해서 제공 팀이 직접 서비스들을 제공하지 않아도 되는 형태`) 제공 팀은 플랫폼을 활용하여 조정을 줄이면서 더 빠른 속도로 제품 기능을 제공할 수 있습니다."라고 설명합니다. +마틴 파울러와 에반 보처\[[2](https://martinfowler.com/articles/talk-about-platforms.html)]에 따르면, "디지털 플랫폼은 하나의 매력적인 내부 제품으로 셀프 서비스 API, 도구, 서비스, 지식 및 지원을 잘 정리해서 제공한다. 자율(Autonomous, `역자: 일종의 셀프 서비스 들로 인해서 제공 팀이 직접 서비스들을 제공하지 않아도 되는 형태`) 제공 팀은 플랫폼을 활용하여 조정을 줄이면서 더 빠른 속도로 제품 기능을 제공할 수 있다."라고 설명한다. -플랫폼에서 지원하는 특정 기능 및 시나리오는 이해관계자와 사용자의 요구에 따라 결정되어야 합니다. 플랫폼이 이러한 필수 기능을 제공하지만, 플랫폼 팀이 항상 직접 구현해서는 안 된다는 점에 유의해야 합니다. 관리형 서비스 제공 업체나 전담 내부 팀은 지원 구현을 유지 관리할 수 있지만, 플랫폼을 통해 제공되는 구현 전반에 일관성을 제공하고 조직의 요구 사항을 충족하는 가장 합리적인 팀은 플랫폼 팀이어야 합니다. 예를 들어, 매우 간단한 '플랫폼'은 \[[3](https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp)]에 설명된 대로 제공업체의 기능을 프로비저닝하기 위한 표준 운영 절차에 대한 링크가 있는 위키 페이지일 수 있습니다. +플랫폼에서 지원하는 특정 기능 및 시나리오는 이해관계자와 사용자의 요구에 따라 결정되어야 한다. 플랫폼이 이러한 필수 기능을 제공하지만, 플랫폼 팀이 항상 직접 구현해서는 안 된다는 점에 유의해야 한다. 관리형 서비스 제공 업체나 전담 내부 팀은 지원 구현을 유지 관리할 수 있지만, 플랫폼을 통해 제공되는 구현 전반에 일관성을 제공하고 조직의 요구 사항을 충족하는 가장 합리적인 팀은 플랫폼 팀이어야 한다. 예를 들어, 매우 간단한 '플랫폼'은 \[[3](https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp)]에 설명된 대로 제공업체의 기능을 프로비저닝하기 위한 표준 운영 절차에 대한 링크가 있는 위키 페이지일 수 있다. -이러한 플랫폼은 기업의 내부 사용자만을 대상으로 하기 때문에 내부 플랫폼이라고 부르는 경우가 많습니다. +이러한 플랫폼은 기업의 내부 사용자만을 대상으로 하기 때문에 내부 플랫폼이라고 부르는 경우가 많다. -플랫폼은 이전 패러다임(`역자 생각: DevOps 그리고 SRE 의 트렌드를 의미`, [설명](https://osckorea.tistory.com/173))보다 애플리케이션별 로직에서 지원 기능을 분리하기 때문에 클라우드 네이티브 아키텍처와 특히 밀접하게 연관되어 있습니다. 클라우드와 같은 환경에서는 리소스와 기능이 독립적으로 관리되고 사용자 지정 비즈니스 구성 요소와 통합되는 경우가 많으며, 이러한 리소스에는 데이터베이스 및 개체 저장소, 메시지 큐 및 브로커, 관찰 가능성 수집기(collectors, `역자: 익스포터들을 의미`) 및 대시보드, 사용자 디렉터리 및 인증 시스템, 작업 실행자 및 조정자(reconcilers) 등이 포함될 수 있습니다. 내부 플랫폼은 이러한 리소스를 애플리케이션과 시스템에 쉽게 통합할 수 있는 방식으로 엔터프라이즈 팀에 제공합니다. +플랫폼은 이전 패러다임(`역자 생각: DevOps 그리고 SRE 의 트렌드를 의미`, [설명](https://osckorea.tistory.com/173))보다 애플리케이션별 로직에서 지원 기능을 분리하기 때문에 클라우드 네이티브 아키텍처와 특히 밀접하게 연관되어 있다. 클라우드와 같은 환경에서는 리소스와 기능이 독립적으로 관리되고 사용자 지정 비즈니스 구성 요소와 통합되는 경우가 많으며, 이러한 리소스에는 데이터베이스 및 개체 저장소, 메시지 큐 및 브로커, 관찰 가능성 수집기(collectors, `역자: 익스포터들을 의미`) 및 대시보드, 사용자 디렉터리 및 인증 시스템, 작업 실행자 및 조정자(reconcilers) 등이 포함될 수 있다. 내부 플랫폼은 이러한 리소스를 애플리케이션과 시스템에 쉽게 통합할 수 있는 방식으로 엔터프라이즈 팀에 제공한다. ## 플랫폼 성숙도 -가장 기본적인 내부 플랫폼은 파이프라인 러너, 데이터베이스 시스템 또는 시크릿(Secret) 저장소와 같은 개별 서비스를 사용하기 위한 일관된 환경을 제공합니다. 내부 플랫폼이 성숙해짐에 따라 웹 애플리케이션 개발이나 데이터 분석과 같은 주요 시나리오를 위한 셀프 서비스 가능한 템플릿(일반적으로 MLOps)과 같은 서비스 구성도 제공합니다. +가장 기본적인 내부 플랫폼은 파이프라인 러너, 데이터베이스 시스템 또는 시크릿(Secret) 저장소와 같은 개별 서비스를 사용하기 위한 일관된 환경을 제공한다. 내부 플랫폼이 성숙해짐에 따라 웹 애플리케이션 개발이나 데이터 분석과 같은 주요 시나리오를 위한 셀프 서비스 가능한 템플릿(일반적으로 MLOps)과 같은 서비스 구성도 제공한다. -기업이 플랫폼을 통해 만날 수 있는 사용 사례는 다음과 같이 진행될 수 있습니다. +기업이 플랫폼을 통해 만날 수 있는 사용 사례는 다음과 같이 진행될 수 있다. -1. 제품 개발자는 필요에 따라 기능을 프로비저닝하여 컴퓨팅, 스토리지, 데이터베이스 또는 신원 확인(ID)과 같은 시스템을 즉시 사용할 수 있습니다. -2. 제품 개발자는 필요에 따라 서비스 공간을 프로비저닝하여 파이프라인 및 작업을 실행하고, 아티팩트 및 구성을 저장하고, 원격 측정을 수집하는 데 사용할 수 있습니다. -3. 타사 소프트웨어의 관리자는 필요에 따라 데이터베이스와 같은 필수 의존 요소를 프로비저닝하고 해당 소프트웨어를 쉽게 설치하고 실행할 수 있습니다. -4. 제품 개발자는 웹 개발이나 MLOps와 같은 특정 시나리오에 필요한 런타임 및 개발 시간 서비스를 결합한 템플릿이 갖춰진 완전한 환경에서 프로비저닝할 수 있습니다. -5. 제품 개발자와 관리자는 자동 계측 및 표준 대시보드를 통해 배포된 서비스의 기능, 성능, 비용을 모니터링할 수 있습니다. +1. 제품 개발자는 필요에 따라 기능을 프로비저닝하여 컴퓨팅, 스토리지, 데이터베이스 또는 신원 확인(ID)과 같은 시스템을 즉시 사용할 수 있다. +2. 제품 개발자는 필요에 따라 서비스 공간을 프로비저닝하여 파이프라인 및 작업을 실행하고, 아티팩트 및 구성을 저장하고, 원격 측정을 수집하는 데 사용할 수 있다. +3. 타사 소프트웨어의 관리자는 필요에 따라 데이터베이스와 같은 필수 의존 요소를 프로비저닝하고 해당 소프트웨어를 쉽게 설치하고 실행할 수 있다. +4. 제품 개발자는 웹 개발이나 MLOps와 같은 특정 시나리오에 필요한 런타임 및 개발 시간 서비스를 결합한 템플릿이 갖춰진 완전한 환경에서 프로비저닝할 수 있다. +5. 제품 개발자와 관리자는 자동 계측 및 표준 대시보드를 통해 배포된 서비스의 기능, 성능, 비용을 모니터링할 수 있다. -내부 플랫폼은 개별 기능 또는 기능 세트에 대해 규정을 준수할 뿐만 아니라 일관된 경험을 제공함으로써 궁극적으로 사용자에게 가치 있는 제품을 보다 쉽고 효율적으로 제공할 수 있도록 지원합니다. +내부 플랫폼은 개별 기능 또는 기능 세트에 대해 규정을 준수할 뿐만 아니라 일관된 경험을 제공함으로써 궁극적으로 사용자에게 가치 있는 제품을 보다 쉽고 효율적으로 제공할 수 있도록 지원한다. {{% pageinfo color="info" %}} -Please refer to the [Platform Engineering Maturity Model](https://tag-app-delivery.cncf.io/ko/whitepapers/platform-eng-maturity-model/) created after this paper was originally published. +해당 백서가 출판된 이후에 만들어진 [플랫폼 엔지니어링 성숙도 모델](https://tag-app-delivery.cncf.io/ko/whitepapers/platform-eng-maturity-model/)을 참고해주세요. {{% /pageinfo %}} ## 플랫폼의 속성 -플랫폼이 무엇이며 조직이 플랫폼을 구축하려는 이유를 충분히 알아봤으니 다음으로는 플랫폼이 성공에 영향을 미치는 몇 가지 주요 속성을 파악해 보겠습니다. +플랫폼이 무엇이며 조직이 플랫폼을 구축하려는 이유를 충분히 알아봤으니 다음으로는 플랫폼이 성공에 영향을 미치는 몇 가지 주요 속성을 파악해 보겠다. -1. **제품으로서의 플랫폼.** 플랫폼은 사용자의 요구 사항을 충족하기 위해 존재하며, 다른 소프트웨어 제품과 마찬가지로 이러한 요구 사항을 기반으로 설계되고 발전되어야 합니다. 플랫폼은 제품 팀 전반에서 가장 일반적인 사용 사례를 지원하는 데 필요한 기능을 제공해야 하며, 단일 팀에서만 사용하는 특정 기능보다 이러한 기능에 우선 순위를 두어 제공되는 가치를 극대화해야 합니다. -2. **사용자 경험.** 플랫폼은 일관된 인터페이스를 통해 기능을 제공하고 사용자 경험에 집중해야 합니다. 플랫폼은 사용자가 있는 곳에서 사용자를 만나기 위해 노력해야 하며, 이는 GUI, API, 커맨드 라인(command-line) 도구, IDE 및 포털의 통합을 의미할 수 있습니다. 예를 들어, 플랫폼은 일반적으로 애플리케이션 배포 기능을 제공합니다. 개발자는 IDE를 통해 이러한 기능을 사용할 수 있고, 테스터는 커맨드 라인 도구를 사용할 수 있으며, 제품 소유자는 GUI 기반 웹 포털을 사용할 수 있습니다. -3. **문서화 및 온보딩.** 성공적인 소프트웨어 제품의 핵심 요소는 문서화입니다. 사용자가 플랫폼의 제품을 사용하려면 문서와 예제가 필요합니다. 플랫폼은 사용자의 요구 사항을 충족하는 적절한 문서와 함께 제공되어야 합니다. 또한 사용자가 필요한 플랫폼 서비스를 빠르고 간단하게 사용할 수 있도록 새로운 프로젝트의 온보딩을 가속화할 수 있는 도구를 제공해야 합니다. 예를 들어, 플랫폼은 쿠버네티스에서 웹 애플리케이션을 빌드, 스캔, 테스트, 배포 및 모니터링 하기 위해 재사용 가능한 형태의 서비스 공급망(supply chain) 워크플로우를 제공할 수 있습니다. 이러한 워크플로우는 초기 프로젝트 템플릿 및 문서와 함께 제공될 수 있으며, 종종 가장 빠르게 도입(Golden path)할 수 있는 번들 형태로 제공되기도 합니다. -4. **셀프 서비스.** 플랫폼은 셀프서비스가 가능해야 합니다. 사용자가 자율적으로 자동으로 기능을 요청하고 받을 수 있어야 합니다. 이 속성은 플랫폼 팀이 여러 제품 팀을 지원하고 필요에 따라 확장할 수 있도록 하는 핵심 요소입니다. 플랫폼 기능은 위에서 설명한 인터페이스를 통해 최소한의 수동 개입으로 필요에 따라 사용할 수 있어야 합니다. 예를 들어, 사용자가 커맨드 라인 도구를 실행하거나 웹 포털에서 양식을 작성하여 데이터베이스를 요청하고 해당 위치 및 자격 증명(credentials)을 받을 수 있어야 합니다. -5. **사용자의 작업 부하 감소.** 플랫폼의 필수 목표는 제품 팀의 작업 부하를 줄이는 것입니다. 플랫폼은 구현 세부 사항을 요약하고 아키텍처에서 발생할 수 있는 모든 복잡성을 숨겨야 합니다. 예를 들어, 플랫폼은 특정 서비스를 클라우드 제공업체에 위임할 수 있지만 사용자는 이러한 세부 사항에 노출되어서는 안 됩니다. 동시에 플랫폼은 사용자가 필요에 따라 특정 서비스를 구성하고 관찰할 수 있도록 허용해야 합니다. 사용자는 플랫폼에서 제공하는 서비스 운영에 대한 책임을 져서는 안 됩니다. 예를 들어, 사용자는 종종 데이터베이스가 필요할 수 있지만 데이터베이스 서버를 관리할 필요가 없어야 합니다. -6. **선택 사항 및 구성 가능.** 플랫폼은 제품 개발의 효율성을 높이기 위한 것이므로 장애물이 되어서는 안 됩니다. 플랫폼은 구성이 가능해야 하며 제품 팀이 플랫폼의 일부만 사용할 수 있어야 합니다. 또한 필요한 경우 제품 팀이 플랫폼 외부에서 자체 기능을 제공하고 관리할 수 있어야 합니다. 예를 들어, 플랫폼에서 그래프 데이터베이스(`역자: 예를 들자면 Neo4j`)를 제공하지 않지만 제품에 필요한 경우, 제품 팀이 직접 그래프 데이터베이스를 프로비저닝하고 운영할 수 있어야 합니다. -7. **보안은 기본.** 플랫폼은 기본적으로 안전해야 하며 조직에서 정의한 규칙과 표준에 따라 규정 준수 및 유효성 검사를 보장하는 기능을 제공해야 합니다. +1. **제품으로서의 플랫폼.** 플랫폼은 사용자의 요구 사항을 충족하기 위해 존재하며, 다른 소프트웨어 제품과 마찬가지로 이러한 요구 사항을 기반으로 설계되고 발전되어야 한다. 플랫폼은 제품 팀 전반에서 가장 일반적인 사용 사례를 지원하는 데 필요한 기능을 제공해야 하며, 단일 팀에서만 사용하는 특정 기능보다 이러한 기능에 우선 순위를 두어 제공되는 가치를 극대화해야 한다. +2. **사용자 경험.** 플랫폼은 일관된 인터페이스를 통해 기능을 제공하고 사용자 경험에 집중해야 한다. 플랫폼은 사용자가 있는 곳에서 사용자를 만나기 위해 노력해야 하며, 이는 GUI, API, 커맨드 라인(command-line) 도구, IDE 및 포털의 통합을 의미할 수 있다. 예를 들어, 플랫폼은 일반적으로 애플리케이션 배포 기능을 제공한다. 개발자는 IDE를 통해 이러한 기능을 사용할 수 있고, 테스터는 커맨드 라인 도구를 사용할 수 있으며, 제품 소유자는 GUI 기반 웹 포털을 사용할 수 있다. +3. **문서화 및 온보딩.** 성공적인 소프트웨어 제품의 핵심 요소는 문서화이다. 사용자가 플랫폼의 제품을 사용하려면 문서와 예제가 필요하다. 플랫폼은 사용자의 요구 사항을 충족하는 적절한 문서와 함께 제공되어야 한다. 또한 사용자가 필요한 플랫폼 서비스를 빠르고 간단하게 사용할 수 있도록 새로운 프로젝트의 온보딩을 가속화할 수 있는 도구를 제공해야 한다. 예를 들어, 플랫폼은 쿠버네티스에서 웹 애플리케이션을 빌드, 스캔, 테스트, 배포 및 모니터링 하기 위해 재사용 가능한 형태의 서비스 공급망(supply chain) 워크플로우를 제공할 수 있다. 이러한 워크플로우는 초기 프로젝트 템플릿 및 문서와 함께 제공될 수 있으며, 종종 가장 빠르게 도입(Golden path)할 수 있는 번들 형태로 제공되기도 한다. +4. **셀프 서비스.** 플랫폼은 셀프서비스가 가능해야 한다. 사용자가 자율적으로 자동으로 기능을 요청하고 받을 수 있어야 한다. 이 속성은 플랫폼 팀이 여러 제품 팀을 지원하고 필요에 따라 확장할 수 있도록 하는 핵심 요소이다. 플랫폼 기능은 위에서 설명한 인터페이스를 통해 최소한의 수동 개입으로 필요에 따라 사용할 수 있어야 한다. 예를 들어, 사용자가 커맨드 라인 도구를 실행하거나 웹 포털에서 양식을 작성하여 데이터베이스를 요청하고 해당 위치 및 자격 증명(credentials)을 받을 수 있어야 한다. +5. **사용자의 작업 부하 감소.** 플랫폼의 필수 목표는 제품 팀의 작업 부하를 줄이는 것이다. 플랫폼은 구현 세부 사항을 요약하고 아키텍처에서 발생할 수 있는 모든 복잡성을 숨겨야 한다. 예를 들어, 플랫폼은 특정 서비스를 클라우드 제공업체에 위임할 수 있지만 사용자는 이러한 세부 사항에 노출되어서는 안 된다. 동시에 플랫폼은 사용자가 필요에 따라 특정 서비스를 구성하고 관찰할 수 있도록 허용해야 한다. 사용자는 플랫폼에서 제공하는 서비스 운영에 대한 책임을 져서는 안 된다. 예를 들어, 사용자는 종종 데이터베이스가 필요할 수 있지만 데이터베이스 서버를 관리할 필요가 없어야 한다. +6. **선택 사항 및 구성 가능.** 플랫폼은 제품 개발의 효율성을 높이기 위한 것이므로 장애물이 되어서는 안 된다. 플랫폼은 구성이 가능해야 하며 제품 팀이 플랫폼의 일부만 사용할 수 있어야 한다. 또한 필요한 경우 제품 팀이 플랫폼 외부에서 자체 기능을 제공하고 관리할 수 있어야 한다. 예를 들어, 플랫폼에서 그래프 데이터베이스(`역자: 예를 들자면 Neo4j`)를 제공하지 않지만 제품에 필요한 경우, 제품 팀이 직접 그래프 데이터베이스를 프로비저닝하고 운영할 수 있어야 한다. +7. **보안은 기본.** 플랫폼은 기본적으로 안전해야 하며 조직에서 정의한 규칙과 표준에 따라 규정 준수 및 유효성 검사를 보장하는 기능을 제공해야 한다. ## 플랫폼 팀의 속성 -플랫폼 팀은 웹 포털, 사용자 지정(custom) API, 빠른 도입을 위한 템플릿과 같은 플랫폼 기능에 대한 인터페이스와 사용자 경험을 담당합니다. 플랫폼 팀은 인프라를 구현하고 서비스를 지원하는 팀과 협력하여 일관된 경험을 규정하고, 다른 한편으로는 제품 및 사용자 팀과 협력하여 피드백을 수집하는 한편 이러한 경험이 실제로 사용자의 요구 사항을 충족하는지 확인합니다. +플랫폼 팀은 웹 포털, 사용자 지정(custom) API, 빠른 도입을 위한 템플릿과 같은 플랫폼 기능에 대한 인터페이스와 사용자 경험을 담당한다. 플랫폼 팀은 인프라를 구현하고 서비스를 지원하는 팀과 협력하여 일관된 경험을 규정하고, 다른 한편으로는 제품 및 사용자 팀과 협력하여 피드백을 수집하는 한편 이러한 경험이 실제로 사용자의 요구 사항을 충족하는지 확인한다. -다음은 플랫폼 팀이 담당해야 하는 업무입니다. +다음은 플랫폼 팀이 담당해야 하는 업무이다. 1. 플랫폼 사용자 요구 사항 조사 및 기능 로드맵 수립 2. 플랫폼이 제안하는 가치를 마케팅, 홍보 지원 3. 포털, API, 문서 및 템플릿, 커맨드 라인(CLI) 도구 등 기능 및 서비스를 사용하고 관찰하기 위한 인터페이스를 관리 및 개발 -가장 중요한 것은 플랫폼 팀이 플랫폼에서 제공하는 기능과 인터페이스를 알리고 지속적으로 개선하기 위해 플랫폼 사용자의 요구사항을 파악해야 한다는 것입니다. 사용자 요구 사항을 파악하는 방법에는 사용자 인터뷰, 양방향 해커톤, 이슈 트래커 및 설문조사, 관찰 가능성 도구를 통한 사용 현황 직접 관찰 등이 있습니다. 예를 들어, 플랫폼 팀은 사용자가 기능 요청을 제출할 수 있는 양식을 게시하고, 로드맵 회의를 주도하여 예정된 기능을 공유하고, 사용자의 사용 패턴을 검토하여 우선 순위를 설정할 수 있습니다. +가장 중요한 것은 플랫폼 팀이 플랫폼에서 제공하는 기능과 인터페이스를 알리고 지속적으로 개선하기 위해 플랫폼 사용자의 요구사항을 파악해야 한다는 것이다. 사용자 요구 사항을 파악하는 방법에는 사용자 인터뷰, 양방향 해커톤, 이슈 트래커 및 설문조사, 관찰 가능성 도구를 통한 사용 현황 직접 관찰 등이 있다. 예를 들어, 플랫폼 팀은 사용자가 기능 요청을 제출할 수 있는 양식을 게시하고, 로드맵 회의를 주도하여 예정된 기능을 공유하고, 사용자의 사용 패턴을 검토하여 우선 순위를 설정할 수 있다. -플랫폼은 내부로부터(Inbound)의 피드백과 면밀한 설계를 가지고 있어야 하고, 다른 측면으로는 적극적으로 외부(Outbound)에 마케팅적으로 알려야 하고 지원 받아야 합니다. 플랫폼이 진정으로 사용자 요구사항에 맞게 구축되었다면 사용자들은 플랫폼에서 제공하는 기능등을 기꺼이 사용할 것입니다. 플랫폼 팀이 사용자의 사용을 유도하는 몇 가지 방법으로는 광범위한 공지, 매력적인 데모, 정기적인 피드백 및 커뮤니케이션 세션 등의 내부 마케팅 활동을 들 수 있습니다. 여기서 핵심은 사용자가 있는 곳에서 사용자를 만나고 플랫폼에 참여하고 혜택을 누릴 수 있는 과정을 안내하는 것입니다. +플랫폼은 내부로부터(Inbound)의 피드백과 면밀한 설계를 가지고 있어야 하고, 다른 측면으로는 적극적으로 외부(Outbound)에 마케팅적으로 알려야 하고 지원 받아야 한다. 플랫폼이 진정으로 사용자 요구사항에 맞게 구축되었다면 사용자들은 플랫폼에서 제공하는 기능등을 기꺼이 사용할 것이다. 플랫폼 팀이 사용자의 사용을 유도하는 몇 가지 방법으로는 광범위한 공지, 매력적인 데모, 정기적인 피드백 및 커뮤니케이션 세션 등의 내부 마케팅 활동을 들 수 있다. 여기서 핵심은 사용자가 있는 곳에서 사용자를 만나고 플랫폼에 참여하고 혜택을 누릴 수 있는 과정을 안내하는 것이다. -플랫폼 팀이 반드시 컴퓨팅, 네트워크, 스토리지 또는 기타 서비스를 운영할 필요는 없습니다. 사실 내부 플랫폼은 가능한 한 외부에서 제공하는 서비스와 기능에 의존해야 하며, 플랫폼 팀은 관리 공급업체나 내부 인프라 팀에서 사용할 수 없는 경우에만 자체 기능을 구축하고 유지 관리해야 합니다. 대신 플랫폼 팀은 플랫폼에서 제공하는 서비스 및 기능에 대한 인터페이스(예: GUI, CLI, API) 및 사용자 경험에 대해서 확실히 책임을 지고 유지 관리해야 합니다. +플랫폼 팀이 반드시 컴퓨팅, 네트워크, 스토리지 또는 기타 서비스를 운영할 필요는 없다. 사실 내부 플랫폼은 가능한 한 외부에서 제공하는 서비스와 기능에 의존해야 하며, 플랫폼 팀은 관리 공급업체나 내부 인프라 팀에서 사용할 수 없는 경우에만 자체 기능을 구축하고 유지 관리해야 한다. 대신 플랫폼 팀은 플랫폼에서 제공하는 서비스 및 기능에 대한 인터페이스(예: GUI, CLI, API) 및 사용자 경험에 대해서 확실히 책임을 지고 유지 관리해야 한다. -예를 들어, 플랫폼의 웹 페이지에서 앱의 신원 인증(ID)을 제공하는 버튼에 대해 설명하고 제공할 수 있으며, 실제로해당 기능에 대한 구현은 클라우드에서 호스팅되는 ID 서비스(`역자: 예를 들자면 IAM관련 서비스`)를 통해 이루어질 수 있습니다. 내부 플랫폼 팀이 웹 페이지와 API를 관리할 수 있지만 실제 서비스 구현은 관리하지 않을 수 있습니다. 플랫폼 팀은 일반적으로 필요한 기능을 다른 곳에서 사용할 수 없는 경우에만 자체 기능을 만들고 유지 관리하는 것을 고려해야 합니다. +예를 들어, 플랫폼의 웹 페이지에서 앱의 신원 인증(ID)을 제공하는 버튼에 대해 설명하고 제공할 수 있으며, 실제로해당 기능에 대한 구현은 클라우드에서 호스팅되는 ID 서비스(`역자: 예를 들자면 IAM관련 서비스`)를 통해 이루어질 수 있다. 내부 플랫폼 팀이 웹 페이지와 API를 관리할 수 있지만 실제 서비스 구현은 관리하지 않을 수 있다. 플랫폼 팀은 일반적으로 필요한 기능을 다른 곳에서 사용할 수 없는 경우에만 자체 기능을 만들고 유지 관리하는 것을 고려해야 한다. ## 플랫폼의 당면 과제 -플랫폼은 많은 가치를 약속하지만, 구현자가 염두에 두어야 할 다음과 같은 과제도 있습니다. +플랫폼은 많은 가치를 약속하지만, 구현자가 염두에 두어야 할 다음과 같은 과제도 있다. -1. 플랫폼 팀은 플랫폼을 제품처럼 취급하고, 사용자와 함께 개발해야 합니다. -2. 플랫폼 팀은 우선 순위와 초기 파트너 애플리케이션 팀을 신중하게 선택해야 합니다. -3. 플랫폼 팀은 기업 경영진의 지원을 얻고, 비지니스 가치 흐름에 미치는 영향을 보여줘야 합니다. +1. 플랫폼 팀은 플랫폼을 제품처럼 취급하고, 사용자와 함께 개발해야 한다. +2. 플랫폼 팀은 우선 순위와 초기 파트너 애플리케이션 팀을 신중하게 선택해야 한다. +3. 플랫폼 팀은 기업 경영진의 지원을 얻고, 비지니스 가치 흐름에 미치는 영향을 보여줘야 한다. -가장 중요한 것은 플랫폼을 고객 대상 제품으로 취급하고, 플랫폼의 성공이 사용자와 제품의 성공에 직접적으로 좌우된다는 점을 인식하는 것입니다. 따라서 플랫폼 팀은 애플리케이션 팀 및 다른 사용자와 협력하여 플랫폼의 기능과 사용자 경험의 우선 순위를 정하고, 계획하고, 구현하고, 반복하는 것이 중요합니다. 피드백 없이 기능과 경험을 공개하거나 탑다운 방식에 의존하여 도입을 추진하는 플랫폼 팀은 사용자의 저항과 반발을 불러일으키고 결국 약속한 가치를 상당 부분 놓칠 가능성이 높습니다. 이를 방지하기 위해 플랫폼 팀은 처음부터 제품 관리자를 포함시켜 로드맵을 공유하고, 피드백을 수집하며, 플랫폼 사용자의 요구 사항을 전반적으로 이해하고 반영해야 합니다. +가장 중요한 것은 플랫폼을 고객 대상 제품으로 취급하고, 플랫폼의 성공이 사용자와 제품의 성공에 직접적으로 좌우된다는 점을 인식하는 것이다. 따라서 플랫폼 팀은 애플리케이션 팀 및 다른 사용자와 협력하여 플랫폼의 기능과 사용자 경험의 우선 순위를 정하고, 계획하고, 구현하고, 반복하는 것이 중요하다. 피드백 없이 기능과 경험을 공개하거나 탑다운 방식에 의존하여 도입을 추진하는 플랫폼 팀은 사용자의 저항과 반발을 불러일으키고 결국 약속한 가치를 상당 부분 놓칠 가능성이 높다. 이를 방지하기 위해 플랫폼 팀은 처음부터 제품 관리자를 포함시켜 로드맵을 공유하고, 피드백을 수집하며, 플랫폼 사용자의 요구 사항을 전반적으로 이해하고 반영해야 한다. -플랫폼을 도입할 때는 우선적으로 지원해야 할 기능과 경험을 선택하는 것이 중요합니다. 파이프라인, 데이터베이스 및 관찰 가능성과 같이 자주 필요하지만 차별화되지 않은 기능을 먼저 시작하는 것이 좋습니다. 플랫폼 팀은 참여도가 높고 숙련된 소수의 애플리케이션 팀에 우선적으로 주력할 수도 있습니다. 이러한 팀의 상세한 피드백은 첫 번째 플랫폼 경험을 개선하고, 이러한 팀의 사람들은 나중에 플랫폼을 채택하는 사람들에게 플랫폼을 홍보하고 전파하는 데 도움을 줍니다. +플랫폼을 도입할 때는 우선적으로 지원해야 할 기능과 경험을 선택하는 것이 중요하다. 파이프라인, 데이터베이스 및 관찰 가능성과 같이 자주 필요하지만 차별화되지 않은 기능을 먼저 시작하는 것이 좋다. 플랫폼 팀은 참여도가 높고 숙련된 소수의 애플리케이션 팀에 우선적으로 주력할 수도 있다. 이러한 팀의 상세한 피드백은 첫 번째 플랫폼 경험을 개선하고, 이러한 팀의 사람들은 나중에 플랫폼을 채택하는 사람들에게 플랫폼을 홍보하고 전파하는 데 도움을 준다. -마지막으로, 플랫폼팀은 기업의 경영진으로부터 지원을 신속하게 확보하는 것이 매우 중요합니다. 많은 기업 경영진은 IT 인프라를 주요 비지니스 가치 흐름과 동떨어진 비용으로 인식하고 IT 플랫폼에 할당되는 비용과 리소스를 제한하려고 하기 때문에 구현이 제대로 이루어지지 않아 플랫폼 엔지니어팀의 의욕을 꺽을 수 있고 또한 플랫폼 사용자들을 떠나게 만들 수 있습니다. 이를 방지하기 위해 플랫폼 팀은 최종 제품 및 비지니스 가치 흐름에 직접적인 영향을 미친다는 것을 입증하고, 이를 통해서 제품 팀과 전략적인 협력 관계임을 보여주어야 합니다. +마지막으로, 플랫폼팀은 기업의 경영진으로부터 지원을 신속하게 확보하는 것이 매우 중요하다. 많은 기업 경영진은 IT 인프라를 주요 비지니스 가치 흐름과 동떨어진 비용으로 인식하고 IT 플랫폼에 할당되는 비용과 리소스를 제한하려고 하기 때문에 구현이 제대로 이루어지지 않아 플랫폼 엔지니어팀의 의욕을 꺽을 수 있고 또한 플랫폼 사용자들을 떠나게 만들 수 있다. 이를 방지하기 위해 플랫폼 팀은 최종 제품 및 비지니스 가치 흐름에 직접적인 영향을 미친다는 것을 입증하고, 이를 통해서 제품 팀과 전략적인 협력 관계임을 보여주어야 한다. -## 플랫폼팀을 어떻게 도와줄 것인가? +## 플랫폼 팀을 어떻게 도와줄 것인가? -이러한 당면 과제들을 통해 볼 때 플랫폼 팀은 다양한 책임에 가지고 있으며, 이는 과중한 업무량으로 이어진다는 것을 알 수 있습니다. 애플리케이션 팀과 마찬가지로 플랫폼 팀도 지원해야 하는 사용자와 팀의 수와 다양성이 증가함에 따라 이러한 당면 과제들은 더욱 커집니다. +이러한 당면 과제들을 통해 볼 때 플랫폼 팀은 다양한 책임에 가지고 있으며, 이는 과중한 업무량으로 이어진다는 것을 알 수 있다. 애플리케이션 팀과 마찬가지로 플랫폼 팀도 지원해야 하는 사용자와 팀의 수와 다양성이 증가함에 따라 이러한 당면 과제들은 더욱 커진다. -플랫폼 팀의 에너지를 특정 비즈니스 역량에 집중하는 것은 매우 중요합니다. 플랫폼 팀의 업무 부담을 줄이는 방법에는 다음이 포함됩니다. +플랫폼 팀의 에너지를 특정 비즈니스 역량에 집중하는 것은 매우 중요하다. 플랫폼 팀의 업무 부담을 줄이는 방법에는 다음이 포함된다. -1. 관리형 제공업체에서 이미 구현된 기능을 쓰기 보다 가장 가벼운 형태([TVP](platform\_whitepaper.md#glossary), thinnest viable platform)로 구동할 수 있는 플랫폼 계층을 구축하기 위해 노력해야 합니다. -2. 오픈 소스 프레임워크 및 툴킷(toolkits)을 이용해서 애플리케이션 팀이 사용할 문서, 템플릿 및 구조(compositions)를 만듭니다. -3. 플랫폼 팀이 도메인(Domain)과 고객 수에 맞게 적절한 인력을 확보하도록 합니다. +1. 관리형 제공업체에서 이미 구현된 기능을 쓰기 보다 가장 가벼운 형태([TVP](platform\_whitepaper.md#glossary), thinnest viable platform)로 구동할 수 있는 플랫폼 계층을 구축하기 위해 노력해야 한다. +2. 오픈 소스 프레임워크 및 툴킷(toolkits)을 이용해서 애플리케이션 팀이 사용할 문서, 템플릿 및 구조(compositions)를 만든다. +3. 플랫폼 팀이 도메인(Domain)과 고객 수에 맞게 적절한 인력을 확보하도록 한다. ## 어떻게 플랫폼의 성공을 측정할 수 있나요? -기업은 플랫폼 형태로의 도입 또는 전환이 위에서 설명한 가치와 속성을 제공하고 있는지 측정하고자 할 것입니다. 또한 이 백서 전체에서 내부 플랫폼을 제품으로 취급하는 것이 중요하며, 우수한 제품 관리는 제품 성능의 정량적, 정성적 측정에 달려 있다고 강조했습니다. 이러한 요구 사항을 충족하기 위해 내부 플랫폼 팀은 지속적으로 사용자 피드백을 수집하고 사용자 활동을 측정해야 합니다. +기업은 플랫폼 형태로의 도입 또는 전환이 위에서 설명한 가치와 속성을 제공하고 있는지 측정하고자 할 것이다. 또한 이 백서 전체에서 내부 플랫폼을 제품으로 취급하는 것이 중요하며, 우수한 제품 관리는 제품 성능의 정량적, 정성적 측정에 달려 있다고 강조했다. 이러한 요구 사항을 충족하기 위해 내부 플랫폼 팀은 지속적으로 사용자 피드백을 수집하고 사용자 활동을 측정해야 한다. -하지만 내부 플랫폼의 다른 측면과 마찬가지로 플랫폼 팀은 필요한 피드백을 수집하기 위해 가능한 최소한의 노력을 기울여야 합니다. 여기서는 몇 가지 지표를 제안하지만, 초기에는 사용자 행동에 대한 간단한 설문조사와 분석이 가장 유용할 수 있습니다. +하지만 내부 플랫폼의 다른 측면과 마찬가지로 플랫폼 팀은 필요한 피드백을 수집하기 위해 가능한 최소한의 노력을 기울여야 한다. 여기서는 몇 가지 지표를 제안하지만, 초기에는 사용자 행동에 대한 간단한 설문 조사와 분석이 가장 유용할 수 있다. -기업과 플랫폼 팀이 플랫폼의 영향을 이해하는 데 도움이 되는 지표의 범주는 다음과 같습니다: +기업과 플랫폼 팀이 플랫폼의 영향을 이해하는 데 도움이 되는 지표의 범주는 다음과 같다: ### 사용자 만족도 및 생산성 -많은 플랫폼이 추구하는 첫 번째 품질은 생산성을 높이기 위해 사용자 경험을 개선하는 것입니다. 사용자 만족도와 생산성을 반영하는 지표에는 다음이 포함됩니다 +많은 플랫폼이 추구하는 첫 번째 품질은 생산성을 높이기 위해 사용자 경험을 개선하는 것이다. 사용자 만족도와 생산성을 반영하는 지표에는 다음이 포함된다: * 활성 사용자 및 유지율(Retention): 프로비저닝된 기능 수 및 사용자 증가/이탈 포함 * "제품에 대한 사용자 만족도를 측정하는 "순추천지수(NPS, Net Promoter Score)" 또는 기타 설문조사 @@ -157,7 +157,7 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive ### 조직 효율성 -많은 플랫폼에서 이루고자하는 또 다른 효과는 대규모 사용자 기반에 공통의 요구 사항을 효율적으로 제공하는 것입니다. 이는 사용자 셀프 서비스를 활성화하고 일일이 수작업으로 진행해야 하는 단계와 사람의 개입을 줄임과 동시에 안전과 규정 준수를 보장하는 정책을 구현함으로써 달성되는 경우가 많습니다. 공통 작업을 줄이는 데 있어 플랫폼의 효율성을 측정하려면 다음과 같은 측정 항목을 고려할 수 있습니다. +많은 플랫폼에서 이루고자하는 또 다른 효과는 대규모 사용자 기반에 공통의 요구 사항을 효율적으로 제공하는 것이다. 이는 사용자 셀프 서비스를 활성화하고 일일이 수작업으로 진행해야 하는 단계와 사람의 개입을 줄임과 동시에 안전과 규정 준수를 보장하는 정책을 구현함으로써 달성되는 경우가 많다. 공통 작업을 줄이는 데 있어 플랫폼의 효율성을 측정하려면 다음과 같은 측정 항목을 고려할 수 있다. * 데이터베이스 또는 테스트 환경과 같은 서비스 또는 기능 요청부터 이행까지의 지연 시간 * 새로운 서비스를 빌드하고 프로덕션 환경에 배포하는 데 걸리는 지연 시간 @@ -165,26 +165,26 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive ### 제품 및 기능 제공 -내부 플랫폼의 궁극적인 목표는 고객에게 비즈니스 가치를 더 빠르게 제공하는 것이므로, 비즈니스 자체의 제품 및 기능 릴리스에 대한 영향을 측정하면 플랫폼의 목표가 달성되고 있음을 알 수 있습니다. Google의 DevOps 연구 및 평가(DORA) 연구소는 \[[5](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling?hl=en)] 다음 메트릭을 추적할 것을 제안합니다. +내부 플랫폼의 궁극적인 목표는 고객에게 비즈니스 가치를 더 빠르게 제공하는 것이므로, 비즈니스 자체의 제품 및 기능 릴리스에 대한 영향을 측정하면 플랫폼의 목표가 달성되고 있음을 알 수 있다. Google의 DevOps 연구 및 평가(DORA) 연구소는 \[[5](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling?hl=en)] 다음 메트릭을 추적할 것을 제안한다. * 배포 빈도 * 변경에 소요되는 시간(Lead time) * 장애 후 서비스 복원 시간 * 변경 실패율 -일반적으로 플랫폼 팀의 핵심 목표는 인프라 및 기타 IT 기능을 기업의 가치 흐름, 즉 제품에 맞춰 조정하는 것입니다. 따라서 궁극적으로 기업의 제품과 애플리케이션의 성공이 플랫폼의 성공을 가늠하는 진정한 척도입니다. +일반적으로 플랫폼 팀의 핵심 목표는 인프라 및 기타 IT 기능을 기업의 가치 흐름, 즉 제품에 맞춰 조정하는 것이다. 따라서 궁극적으로 기업의 제품과 애플리케이션의 성공이 플랫폼의 성공을 가늠하는 진정한 척도이다. ## 플랫폼의 기능들 -앞서 설명한 것처럼 클라우드 네이티브 컴퓨팅을 위한 플랫폼은 여러 지원 제공업체의 기능과 서비스를 함께 혼합하여 제공합니다. 이러한 제공업체는 같은 기업 내의 다른 팀일 수도 있고 클라우드 서비스 제공업체와 같은 타사일 수도 있습니다. 간단히 말해, 플랫폼은 기본 기능 제공업체와 애플리케이션 개발자와 같은 플랫폼 사용자를 연결하고, 그 과정에서 보안, 성능, 비용 거버넌스, 일관된 경험에 대해 원하는 모범 사례를 구현하고 시행합니다. 다음 그래픽은 제품, 플랫폼, 기능 제공업체 간의 관계를 보여줍니다. +앞서 설명한 것처럼 클라우드 네이티브 컴퓨팅을 위한 플랫폼은 여러 지원 제공업체의 기능과 서비스를 함께 혼합하여 제공한다. 이러한 제공업체는 같은 기업 내의 다른 팀일 수도 있고 클라우드 서비스 제공업체와 같은 타사일 수도 있다. 간단히 말해, 플랫폼은 기본 기능 제공업체와 애플리케이션 개발자와 같은 플랫폼 사용자를 연결하고, 그 과정에서 보안, 성능, 비용 거버넌스, 일관된 경험에 대해 원하는 모범 사례를 구현하고 시행한다. 다음 그래픽은 제품, 플랫폼, 기능 제공업체 간의 관계를 보여준다. -

제품과 플랫폼 그리고 기능 제공업체 간의 관계 그래프

+ -이 백서에서는 우수한 플랫폼과 플랫폼 팀을 구성하는 방법에 중점을 두었으며, 이제 마지막 섹션에서는 플랫폼이 실제로 제공할 수 있는 기능에 대해 설명하고자 합니다. 이 목록은 플랫폼 구축 담당자를 안내하기 위한 것으로, 일반적으로 클라우드 네이티브 애플리케이션에 필요한 기능을 포함하고 있습니다. 하지만 앞서 언급했듯이 좋은 플랫폼은 사용자의 요구 사항을 반영하므로 궁극적으로 플랫폼 팀은 사용자와 함께 플랫폼이 제공하는 기능을 선택하고 우선 순위를 정해야 합니다. +이 백서에서는 우수한 플랫폼과 플랫폼 팀을 구성하는 방법에 중점을 두었으며, 이제 마지막 섹션에서는 플랫폼이 실제로 제공할 수 있는 기능에 대해 설명하고자 한다. 이 목록은 플랫폼 구축 담당자를 안내하기 위한 것으로, 일반적으로 클라우드 네이티브 애플리케이션에 필요한 기능을 포함하고 있다. 하지만 앞서 언급했듯이 좋은 플랫폼은 사용자의 요구 사항을 반영하므로 궁극적으로 플랫폼 팀은 사용자와 함께 플랫폼이 제공하는 기능을 선택하고 우선 순위를 정해야 한다. -기능들은 도메인의 특성에 따라 여러가지로 특성 및 속성이 나누어질 수 있습니다. 예를 들어, 관찰 가능성에는 메트릭, 추적 및 로그를 수집 및 게시하고 비용 및 리소스 사용량을 모니터링하기 위한 기능이 포함될 수 있습니다. 이 때 조직에서는 각 기능 또는 요소의 필요성과 우선순위를 고려해서 적용해야 합니다. 추후 CNCF 발행물은 각 도메인에 대해 더 확장해서 배포할 수 있습니다. +기능들은 도메인의 특성에 따라 여러가지로 특성 및 속성이 나누어질 수 있다. 예를 들어, 관찰 가능성에는 메트릭, 추적 및 로그를 수집 및 게시하고 비용 및 리소스 사용량을 모니터링하기 위한 기능이 포함될 수 있다. 이 때 조직에서는 각 기능 또는 요소의 필요성과 우선 순위를 고려해서 적용해야 한다. 추후 CNCF 발행물은 각 도메인에 대해 더 확장해서 배포할 수 있다. -다음은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구축할 때 고려해야 할 기능 영역입니다. +다음은 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구축할 때 고려해야 할 기능 영역이다. 1. **웹 포털**: 제품 및 기능을 관찰하고 할당 및 배포 관리(provisioning)함 2. **API(및 CLI)**: 제품 및 기능을 자동으로 할당 및 배포 관리(provisioning)함 @@ -194,16 +194,17 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive 6. **개발 환경**: 사용할 수 있도록 설치 구성된(hosted) IDE와 원격 연결 도구 제공 7. **관찰 가능성**: 계측 및 대시보드를 사용하여 서비스 및 제품을 모니터링(기능, 성능 및 비용 관찰 포함) 8. **인프라(Infrastructure) 서비스**: 런타임이 동작가능한 컴퓨터, 프로그래밍에 사용할 네트워크, 블록 및 볼륨 스토리지를 제공 -9. **데이터 서비스**: 데이터베이스, 캐시, 객체 저장소, 메시징 및 이벤트 서비스(서비스 브로커, 큐, 이벤트 패브릭을 포함) 제공 -10. **사용자 인증 및 시크릿(Secret) 관리 서비스**: 서비스 및 사용자 ID 및 권한 부여, 인증서 및 키 발급, 정적 시크릿 저장소 제공 -11. **보안 서비스**: 코드 및 아티팩트의 정적 분석, 런타임 분석, 정책 적용을 제공 -12. **아티팩트(Artifact ) 저장소**: 컨테이너 이미지 및 언어별 패키지, 사용자 지정 바이너리 및 라이브러리, 소스 코드의 저장 제공 +9. **데이터 서비스**: 데이터베이스, 캐시, 객체 저장소 제공 +10. **메시징 및 이벤트 서비스**: 브로커, 큐, 이벤트 패브릭 제공 +11. **사용자 인증 및 시크릿(Secret) 관리 서비스**: 서비스 및 사용자 ID 및 권한 부여, 인증서 및 키 발급, 정적 시크릿 저장소 제공 +12. **보안 서비스**: 코드 및 아티팩트의 정적 분석, 런타임 분석, 정책 적용을 제공 +13. **아티팩트(Artifact ) 저장소**: 컨테이너 이미지 및 언어별 패키지, 사용자 지정 바이너리 및 라이브러리, 소스 코드의 저장 제공 -다음 표는 독자들이 각 기능을 기존 CNCF 또는 CDF 프로젝트와 느슨하게 연관시켜 파악하는 데 도움을 주기 위한 것입니다. +다음 표는 독자들이 각 기능을 기존 CNCF 또는 CDF 프로젝트와 느슨하게 연관시켜 파악하는 데 도움을 주기 위한 것이다. | 기능 | 설명 | CNCF/CDF 프로젝트 예시 | | ---------------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -| 프로비저닝 및 관찰 기능을 위한 웹 포털 | 문서, 서비스 카탈로그 및 프로젝트 템플릿을 게시합니다. 시스템 및 기능에 대한 원격 분석을 게시 | Backstage, Skooner, Ortelius | +| 프로비저닝 및 관찰 기능을 위한 웹 포털 | 문서, 서비스 카탈로그 및 프로젝트 템플릿을 게시한다. 시스템 및 기능에 대한 원격 분석을 게시 | Backstage, Skooner, Ortelius | | 자동 프로비저닝 기능을 위한 API | 자동으로 생성, 업데이트, 삭제 및 관찰 기능을 위한 구조화된 형식 | Kubernetes, Crossplane, Operator Framework, Helm, KubeVela | | 최적(Golden) 경로 템플릿 및 문서 | 신속한 프로젝트 개발을 위해 잘 통합된 코드와 기능으로 구성된 템플릿을 제공 | ArtifactHub | | 제품 구축 및 테스트를 위 한 자동화 | 디지털 제품 및 서비스의 빌드 및 테스트를 자동화 | Tekton, Jenkins, Buildpacks, ko, Carvel | @@ -213,6 +214,7 @@ Please refer to the [Platform Engineering Maturity Model](https://tag-app-delive | 인프라 서비스 | 애플리케이션 코드 실행, 애플리케이 션 구성 요소 연결 및 애플리케이션의 데이터 유지 | Kubernetes, Kubevirt, Knative, WasmEdge CNI, Istio, Cilium, Envoy, Linkerd, CoreDNS Rook, Longhorn, Etcd | | 데이터 서비스 | 애플리케이션을 위한 구조화된 데이터 유지 | TiKV, Vitess, SchemaHero | | 메시징 및 이벤트 서비스 | 애플리케이션이 서로 비동기적으로 통신할 수 있도록 지원 | Strimzi, NATS, gRPC, Knative, Dapr | -| 신원인증 및 시크릿(Secret) 서비스 | 워크로드에 리소스와 기능을 사용할 수 있는 로케이터와 암호가 있는지 확인합니다. 서비스가 다른 서비스에 자신을 식별할 수 있도록 지원 | Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager | -| 보안 서비스 | 런타임 동작을 관찰하고 이상 징후 를 보고/수정합니다. 빌드 및 아티팩트에 취약점이 없는지 확인합니다. 엔터프라이즈 요구 사항에 따라 플랫폼에서 활동을 제한하고 이상 징후를 알리거나 수정 | Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian | -| 아티팩트 스토리지 | 프로덕션에서 사용할 수 있도록 빌드된 아티팩트를 저장, 게시 및 보호합니다. 타사 아티팩트를 캐시하고 분석합니다. 그리고 소스 코드를 저장하는 기능도 제공 | ArtifactHub, Harbor, Distribution, Porter | +| 신원인증 및 시크릿(Secret) 서비스 | 워크로드에 리소스와 기능을 사용할 수 있는 로케이터와 암호가 있는지 확인한다. 서비스가 다른 서비스에 자신을 식별할 수 있도록 지원 | Dex, External Secrets, SPIFFE/SPIRE, Teller, cert-manager | +| 보안 서비스 | 런타임 동작을 관찰하고 이상 징후 를 보고/수정한다. 빌드 및 아티팩트에 취약점이 없는지 확인한다. 엔터프라이즈 요구 사항에 따라 플랫폼에서 활동을 제한하고 이상 징후를 알리거나 수정 | Falco, In-toto, KubeArmor, OPA, Kyverno, Cloud Custodian | +| 아티팩트 스토리지 | 프로덕션에서 사용할 수 있도록 빌드된 아티팩트를 저장, 게시 및 보호한다. 타사 아티팩트를 캐시하고 분석한다. 그리고 소스 코드를 저장하는 기능도 제공 | ArtifactHub, Harbor, Distribution, Porter | +