다음 글은 CNCF의 플랫폼 백서를 gemini로 번역한 글입니다. 원본: https://tag-app-delivery.cncf.io/whitepapers/platforms/
서론
DevOps가 약속했던 교차 기능적 협력(cross-functional cooperation)에 영감을 받아, 기업 내에서 그 협력의 명시적인 형태로서 '플랫폼 엔지니어링'이 등장하기 시작했습니다. 플랫폼은 애플리케이션 개발자, 데이터 과학자, 정보 근로자와 같은 내부 고객의 업무를 촉진하고 가속화하기 위해 기초적인 역량, 프레임워크 및 경험을 선별하여 제공합니다. 특히 클라우드 컴퓨팅 분야에서 플랫폼은 제품의 빠른 출시, 인프라 간의 이식성, 더 안전하고 탄력적인 제품, 그리고 더 높은 개발자 생산성 등 클라우드가 오랫동안 약속해 온 가치들을 기업이 실현할 수 있도록 돕고 있습니다.
본 백서는 기업 리더, 엔터프라이즈 아키텍트 및 플랫폼 팀 리더가 클라우드 컴퓨팅을 위한 내부 플랫폼을 옹호하고 조사하며 계획하는 것을 지원하기 위해 작성되었습니다. 우리는 플랫폼이 기업의 실제 가치 흐름(Value Streams)에 큰 영향을 미치지만, 이는 간접적인 방식이라고 믿습니다. 따라서 플랫폼 팀의 장기적인 지속 가능성과 성공을 위해서는 경영진의 합의와 지원이 필수적입니다. 이 문서에서는 플랫폼의 가치가 무엇인지, 그 가치를 어떻게 측정하는지, 그리고 가치를 극대화하는 플랫폼 팀을 어떻게 구현하는지 논의함으로써 그러한 지원을 가능하게 할 것입니다.
목차
왜 플랫폼인가?
플랫폼이란 무엇인가?
성공적인 플랫폼의 속성
성공적인 플랫폼 팀의 속성
플랫폼 구현 시의 과제
플랫폼의 성공을 측정하는 방법
플랫폼의 역량
왜 플랫폼인가?
오늘날 클라우드 컴퓨팅 세계에서 플랫폼과 플랫폼 엔지니어링은 대중적인 주제입니다. 플랫폼 구축을 위한 정의, 기술 및 측정 방법을 살펴보기 전에, 먼저 이러한 관심을 불러일으키는 플랫폼의 가치가 무엇인지 탐구하는 것이 중요합니다.
지난 2~30년 동안의 프로세스 개선은 소프트웨어 애플리케이션 및 제품 팀의 민첩성을 크게 향상시켰습니다. 이들에게 컴퓨팅, 네트워크, 스토리지와 같은 인프라 서비스뿐만 아니라 빌드, 테스트, 배포 및 관측성과 같은 개발자 서비스를 유연하게 제공했습니다. 그러나 이러한 자율성과 프로세스 개선은 역설적으로 지원 서비스에 대한 책임을 제품 팀으로 점차 전가하는 결과를 낳았습니다. 결과적으로 제품 팀은 인프라 문제에 점점 더 많은 시간과 인지적 에너지를 소비하게 되었고, 조직에 실질적인 가치를 생산하는 시간은 줄어들었습니다.
제고(delivery) 팀이 본연의 업무에 집중하게 하고 조직 전체의 중복 노력을 줄이려는 열망은 기업들이 클라우드 네이티브 컴퓨팅을 위한 플랫폼을 구현하게 된 동기가 되었습니다. 플랫폼에 투자함으로써 기업은 다음과 같은 이점을 얻을 수 있습니다.
제품 팀의 인지 부하(Cognitive load)를 감소시켜 제품 개발 및 배포를 가속화합니다.
전문가가 플랫폼 역량을 구성하고 관리하게 함으로써, 해당 역량에 의존하는 제품의 신뢰성과 탄력성을 향상시킵니다.
기업 내 여러 팀이 플랫폼 도구와 지식을 재사용하고 공유함으로써 제품 개발 및 배포를 가속화합니다.
플랫폼 역량과 그 주변의 사용자, 도구 및 프로세스를 거버넌스 하에 두어 제품 및 서비스의 보안, 규제 및 기능적 문제의 위험을 감소시킵니다.
사용자 경험에 대한 통제권을 유지하면서 구현은 퍼블릭 클라우드 및 관리형 서비스 제공업체에 위임함으로써, 비용 효율적이고 생산적인 서비스 사용을 가능하게 합니다.
이러한 이점은 부분적으로는 소수의 플랫폼 팀이 다수의 제품 팀에 서비스를 제공하여 영향력을 배가하기 때문이며, 부분적으로는 플랫폼 팀이 공통 기능 관리를 통합하여 거버넌스를 용이하게 하기 때문이고, 마지막으로 플랫폼 팀이 무엇보다 사용자 인터페이스와 경험을 강조하기 때문에 발생합니다.
플랫폼 전문가 팀은 제품 팀에 요구되는 공통 업무를 줄일 뿐만 아니라 해당 제품에서 사용되는 플랫폼 역량을 최적화합니다. 또한 플랫폼 팀은 기업 전체에서 널리 사용되는 관행적 패턴, 지식 및 도구 세트를 유지하여 개발자가 동일한 기반 위에 구축된 다른 팀이나 제품에 빠르게 기여할 수 있도록 합니다. 공유된 플랫폼 패턴은 템플릿, 패턴 및 역량 내에 거버넌스와 통제 기능을 내장할 수 있게 합니다. 마지막으로, 플랫폼 팀은 제공업체들을 관리하고 일관된 경험을 제공하므로, 데이터베이스, ID 액세스, 인프라 운영 및 앱 라이프사이클과 같은 기초적이지만 차별화되지 않은 기능을 위해 퍼블릭 클라우드와 서비스 제공업체를 효율적으로 사용할 수 있게 합니다.
플랫폼이란 무엇인가?
클라우드 네이티브 컴퓨팅을 위한 플랫폼은 플랫폼 사용자의 요구에 따라 정의되고 제시되는 역량들의 통합된 집합입니다. 이는 다양한 애플리케이션 및 사용 사례에 대해 일반적인 역량과 서비스를 획득하고 통합할 때 일관된 경험을 보장하는 횡단 계층(cross-cutting layer)입니다. 좋은 플랫폼은 웹 포털, 프로젝트 템플릿, 셀프 서비스 API와 같이 역량과 서비스를 사용하고 관리하기 위한 일관된 사용자 경험을 제공합니다.
Atlassian[1]에 따르면, "플랫폼 팀은 적은 오버헤드로 수많은 스트림 정렬(stream-aligned)[제품] 팀이 사용할 수 있는 역량을 만듭니다. 플랫폼 팀은 제품 팀의 리소스와 인지 부하를 최소화하며, 서로 다른 사용자 경험이나 제품을 아우르는 응집력 있는 경험을 창출할 수 있습니다."
Martin Fowler와 Evan Bottcher[2]에 따르면, "디지털 플랫폼은 셀프 서비스 API, 도구, 서비스, 지식 및 지원의 기반이며, 이는 매력적인 내부 제품으로 배치됩니다. 자율적인 제고 팀은 조율 작업을 줄이면서 더 빠른 속도로 제품 기능을 제공하기 위해 이 플랫폼을 사용할 수 있습니다."
플랫폼이 지원하는 구체적인 역량 및 시나리오 세트는 이해관계자와 사용자의 요구에 의해 결정되어야 합니다. 플랫폼이 이러한 필수 역량을 제공하지만, 플랫폼 팀이 항상 이를 직접 구현해야 하는 것은 아니라는 점이 중요합니다. 관리형 서비스 제공업체나 전담 내부 팀이 백엔드 구현을 유지할 수 있으며, 플랫폼은 제공된 구현 전반에 걸쳐 일관성을 제공하고 조직의 요구사항을 충족하는 '가장 얇고 합리적인 계층(thinnest reasonable layer)' 역할을 합니다. 예를 들어, 아주 단순한 "플랫폼"은 제공업체로부터 역량을 프로비저닝하기 위한 표준 운영 절차 링크가 포함된 위키 페이지일 수도 있습니다[3].
이러한 플랫폼은 기업의 내부 사용자만을 대상으로 하기 때문에 우리는 종종 이를 **내부 플랫폼(Internal Platforms)**이라고 부릅니다.
플랫폼은 클라우드 네이티브 아키텍처에서 특히 중요합니다. 그 이유는 이전의 패러다임보다 애플리케이션 특정 로직에서 지원 역량을 더 명확하게 분리하기 때문입니다. 클라우드와 같은 환경에서 리소스와 역량은 종종 독립적으로 관리되며 맞춤형 비즈니스 구성 요소와 통합됩니다. 이러한 리소스에는 데이터베이스, 객체 저장소, 메시지 큐, 관측성 수집기 및 대시보드, 사용자 디렉토리 및 인증 시스템 등이 포함될 수 있습니다. 내부 플랫폼은 기업 팀이 이러한 리소스를 자신의 애플리케이션과 시스템에 쉽게 통합할 수 있는 방식으로 제공합니다.
플랫폼 성숙도 (Platform maturity)
가장 기본적인 단계에서 내부 플랫폼은 파이프라인 러너, 데이터베이스 시스템 또는 비밀 저장소와 같은 개별 서비스를 획득하고 사용하기 위한 일관된 경험을 제공합니다. 성숙해짐에 따라 내부 플랫폼은 웹 애플리케이션 개발이나 데이터 분석(MLOps)과 같은 주요 시나리오를 위한 셀프 서비스 템플릿으로서 이러한 서비스들의 **조합(compositions)**을 제공합니다.
기업이 플랫폼을 통해 달성할 수 있는 사용 사례는 다음과 같이 발전할 수 있습니다.
제품 개발자가 컴퓨팅, 스토리지, 데이터베이스 또는 ID와 같은 역량을 필요에 따라 프로비저닝하고 즉시 사용하여 시스템을 실행할 수 있습니다.
제품 개발자가 서비스 공간을 필요에 따라 프로비저닝하고 이를 사용하여 파이프라인과 작업을 실행하고, 산출물과 구성을 저장하며, 텔레메트리를 수집할 수 있습니다.
타사 소프트웨어 관리자가 데이터베이스와 같은 필수 종속성을 필요에 따라 프로비저닝하고 해당 소프트웨어를 쉽게 설치 및 실행할 수 있습니다.
제품 개발자가 웹 개발 또는 MLOps와 같은 특정 시나리오에 필요한 런타임 및 개발 타임 서비스가 결합된 템플릿으로부터 완전한 환경을 프로비저닝할 수 있습니다.
제품 개발자와 관리자가 자동화된 인스트루멘테이션과 표준 대시보드를 통해 배포된 서비스의 기능, 성능 및 비용을 관찰할 수 있습니다.
개별 역량 또는 그 집합에 대해 일관되고 규정을 준수하는 경험을 제공함으로써, 내부 플랫폼은 궁극적으로 사용자가 가치 있는 제품을 더 쉽고 효율적으로 제공할 수 있게 합니다.
플랫폼의 속성
플랫폼이 무엇인지, 왜 구축해야 하는지 정의한 후, 성공에 영향을 미치는 몇 가지 핵심 속성을 확인해 보겠습니다.
제품으로서의 플랫폼 (Platform as a product): 플랫폼은 사용자의 요구사항을 충족하기 위해 존재하며, 다른 소프트웨어 제품과 마찬가지로 해당 요구사항을 기반으로 설계되고 발전해야 합니다. 플랫폼은 제품 팀 전체에서 가장 일반적인 사용 사례를 지원하는 데 필요한 역량을 제공해야 하며, 전달되는 가치를 극대화하기 위해 단일 팀만 사용하는 구체적인 역량보다 공통 역량을 우선시해야 합니다.
사용자 경험 (User experience): 플랫폼은 일관된 인터페이스를 통해 역량을 제공하고 사용자 경험에 집중해야 합니다. 플랫폼은 사용자가 있는 곳(GUI, API, CLI, IDE, 포털 등)에서 그들을 만나기 위해 노력해야 합니다. 예를 들어 제품 소유자는 웹 포털을 사용하고, 개발자는 IDE를, 테스터는 CLI를 통해 동일한 배포 역량을 소비할 수 있습니다.
문서화 및 온보딩 (Documentation and onboarding): 문서화는 성공적인 소프트웨어 제품의 핵심입니다. 플랫폼은 사용자의 요구를 충족하는 적절한 문서와 예제와 함께 제공되어야 합니다. 또한 사용자가 플랫폼 서비스를 빠르고 간단하게 소비할 수 있도록 돕는 새로운 프로젝트 온보딩 도구를 제공해야 합니다. 이러한 번들을 종종 **골든 패스(Golden Path)**라고 부릅니다.
셀프 서비스 (Self-service): 플랫폼은 셀프 서비스가 가능해야 합니다. 사용자는 자율적이고 자동적으로 역량을 요청하고 받을 수 있어야 합니다. 이는 플랫폼 팀이 여러 제품 팀을 지원하고 확장하는 데 핵심적인 특성입니다.
사용자의 인지 부하 감소 (Reduced cognitive load for users): 플랫폼의 필수 목표는 제품 팀의 인지 부하를 줄이는 것입니다. 플랫폼은 구현 세부 사항을 캡슐화하고 아키텍처에서 발생할 수 있는 복잡성을 숨겨야 합니다. 사용자는 플랫폼이 제공하는 서비스를 운영할 책임이 없어야 합니다(예: 데이터베이스 서버 자체를 관리할 필요가 없어야 함).
선택 가능 및 조합 가능 (Optional and composable): 플랫폼은 효율성을 높이기 위한 것이지 방해물이 되어서는 안 됩니다. 플랫폼은 조합 가능해야 하며 제품 팀이 제공되는 기능의 일부만 사용할 수 있도록 해야 합니다. 또한 필요한 경우 제품 팀이 플랫폼 외부에서 자체 역량을 관리할 수 있어야 합니다.
기본 보안 (Secure by default): 플랫폼은 기본적으로 안전해야 하며, 조직에서 정의한 규칙과 표준에 따라 규정 준수 및 검증을 보장하는 역량을 제공해야 합니다.
플랫폼 팀의 속성
플랫폼 팀은 웹 포털, 맞춤형 API, 골든 패스 템플릿과 같은 플랫폼 역량의 인터페이스와 경험을 책임집니다. 한편으로는 인프라를 구현하는 팀과 협력하여 일관된 경험을 정의하고, 다른 한편으로는 제품 팀과 협력하여 피드백을 수집하고 요구사항 충족 여부를 확인합니다.
플랫폼 팀의 주요 업무는 다음과 같습니다.
플랫폼 사용자 요구사항 조사 및 기능 로드맵 계획
플랫폼의 제안 가치 마케팅, 전파 및 옹호
포털, API, 문서, 템플릿, CLI 도구를 포함한 역량 및 서비스 사용/관찰 인터페이스 관리 및 개발
가장 중요한 것은 플랫폼 팀이 사용자의 요구사항을 지속적으로 학습하여 제공하는 인터페이스를 개선하는 것입니다. 학습 방법으로는 인터뷰, 해커톤, 이슈 트래커, 설문 조사 및 관측 도구를 통한 직접 관찰이 있습니다.
인바운드 피드백과 사려 깊은 설계가 제품 제고의 한 면이라면, 다른 한 면은 아웃바운드 마케팅과 옹호입니다. 플랫폼이 사용자의 요구사항에 맞게 구축되었다면 사용자들은 이를 기꺼이 사용할 것입니다. 플랫폼 팀은 공지, 데모, 정기 피드백 세션 등 내부 마케팅 활동을 통해 사용자 도입을 촉진해야 합니다.
플랫폼 팀이 반드시 컴퓨팅, 네트워크 등의 서비스를 직접 운영할 필요는 없습니다. 사실 내부 플랫폼은 가능한 한 외부에서 제공되는 서비스와 역량에 의존해야 합니다. 플랫폼 팀은 주로 이러한 서비스들이 제공되는 인터페이스(GUI, CLI, API)와 사용자 경험에 책임을 집니다.
플랫폼 구현 시의 과제
플랫폼은 많은 가치를 약속하지만, 다음과 같은 도전 과제도 수반합니다.
플랫폼 팀은 플랫폼을 제품처럼 다루고 사용자와 함께 개발해야 합니다.
플랫폼 팀은 우선순위와 초기 파트너 애플리케이션 팀을 신중하게 선택해야 합니다.
플랫폼 팀은 기업 리더십의 지원을 구하고 가치 흐름에 미치는 영향을 보여주어야 합니다.
가장 중요한 것은 플랫폼을 고객 대면 제품으로 취급하고, 그 성공이 사용자와 제품의 성공에 달려 있음을 인식하는 것입니다. 피드백 없이 기능을 출시하거나 하향식 명령(top-down mandates)에 의존하여 도입을 강요하는 플랫폼 팀은 사용자의 저항에 직면할 가능성이 큽니다.
플랫폼 팀 활성화
플랫폼 팀 역시 다양한 책임으로 인해 인지 부하에 직면합니다. 팀의 에너지를 비즈니스에 고유한 경험과 역량에 집중하는 것이 중요합니다. 플랫폼 팀의 부하를 줄이는 방법은 다음과 같습니다.
관리형 제공업체의 구현 위에 **가장 얇은 실행 가능한 플랫폼 계층(thinnest viable platform layer)**을 구축합니다.
문서, 템플릿, 조합을 만들기 위해 오픈 소스 프레임워크와 툴킷을 활용합니다.
플랫폼 팀이 도메인과 고객 수에 맞게 적절한 인력을 확보하도록 합니다.
플랫폼의 성공을 측정하는 방법
플랫폼 팀은 사용자 피드백을 지속적으로 수집하고 활동을 측정해야 합니다. 측정 항목은 다음과 같습니다.
사용자 만족도 및 생산성: 활성 사용자 및 유지율, 순추천지수(NPS), SPACE 프레임워크[4]와 같은 개발자 생산성 지표.
조직 효율성: 서비스 요청부터 이행까지의 대기 시간(latency), 새로운 서비스의 빌드 및 배포 시간, 신규 사용자의 첫 코드 변경 제출 시간.
제품 및 기능 제고: DORA 메트릭(배포 빈도, 변경 리드 타임, 실패 시 복구 시간, 변경 실패율) 추적.
궁극적으로 조직의 제품과 애플리케이션의 성공이 플랫폼 성공의 진정한 척도입니다.
플랫폼의 역량
클라우드 네이티브 컴퓨팅 플랫폼은 다양한 지원 제공업체의 역량을 결합합니다. 플랫폼은 역량 제공자와 애플리케이션 개발자 사이의 가교 역할을 수행하며 보안, 성능, 비용 거버넌스를 시행합니다.
고려해야 할 역량 도메인:
웹 포털: 제품 및 역량 관찰/프로비저닝용
API 및 CLI: 자동 프로비저닝용
"골든 패스" 템플릿 및 문서: 최적의 사용 지원
빌드/테스트/배포 자동화
개발 환경: 호스팅된 IDE 등
관측성: 기능, 성능, 비용 대시보드
인프라 서비스: 런타임, 네트워크, 스토리지
데이터 서비스: DB, 캐시, 객체 저장소
메시징 및 이벤트 서비스
ID 및 비밀 관리
보안 서비스: 정적/런타임 분석, 정책 시행
아티팩트 저장소: 이미지 및 패키지 저장
(이후 표 부분은 각 역량별 CNCF/CDF 프로젝트 예시를 나열한 것이며, Backstage, Kubernetes, Argo, Crossplane, Prometheus 등 익숙하신 프로젝트들이 포함되어 있습니다.)
