우리는 DX와 플랫폼 엔지니어링이 효율적인 소프트웨어 개발의 핵심이라고 생각한다. 최근 개발자들을 대상으로 설문을 실시하여, 취합된 의견을 바탕으로 종합적인 서비스 및 도구의 카탈로그를 만들고, 간소화된 프로세스를 정하여 업무 흐름을 효율적으로 재정비했다.
오픈 무선 액세스 네트워크(O-RAN, Open Radio Access Network) 얼라이언스와 서비스 관리 및 오케스트레이션(SMO, service management and orchestration) 플랫폼은 CSP가 DX와 플랫폼 엔지니어링을 활용하여 rApp(비실시간 RAN 인텔리전트 컨트롤러 애플리케이션)을 개발할 수 있도록 지원하며, 이는 통신 분야의 네트워크 자동화를 앞당길 것이다.
- DX란 소프트웨어 개발과 관련 절차와 툴, 업무 환경에 관한 상호작용을 포함한 개발자의 전반적인 경험을 나타낸다.
- 열악한DX은 실적에 영향을 미친다. 높은 수준의 개발자 경험 인덱스를 보이는 기업은 매출 성장률이 4-5배 더 높은 것으로 나타났다.[6]
- 플랫폼 엔지니어링은 DevOps를 기반으로 개발자의 업무를 간소화하고, 불필요한 업무를 최소화하는 셀프 서비스 툴과 서비스, 프로세스를 제공하여 DX를 향상시키는 것을 목표로 한다.
소프트웨어 개발 방식의 진화
소프트웨어 개발과 운영은 20년 전, 개발팀이 코딩에만 집중하고 시스템 관리자가 구축 및 유지보수를 담당했던 시절과 비교할 때 상당히 변화해왔다. 오래 전부터 이 같은 단절된 업무 방식은 개발자와 시스템 관리자 모두에게 부정적인 영향을 미쳤으며, 이로 인해 개발과 운영을 통합하는 DevOps 방법론이 부상하게 되었다. 더 통합된 DevOps 접근법은 개발팀이 소프트웨어 개발과 구축 모두에 필요한 역량을 갖추도록 하여 개발자 경험(DX)을 개선시켰으며, 이에 따라 DevOps는 빠르게 업계 표준으로 자리잡았다.
동일한 시기에 등장한 클라우드 네이티브 개념은 확장성, 가용성, 운영성 측면에서 큰 진전을 이루었으나, 동시에 설정 과정은 훨씬 복잡해졌다. 그 결과, 단순한 스크립트를 통해 데이터베이스와 연동되는 싱글 티어 애플리케이션을 손쉽게 구축하던 방식은 더 이상 통하지 않게 되었다.
클라우드 네이티브의 등장은 다음과 같은 요소로 이미 복잡한 개발자 환경에 부담을 가중시켰다.
- 다양한 프로그래밍 언어 (예: Java, Python, Rust, Go, C++)
- 다양한 통합개발환경 (integrated development environments, IDEs) (IntelliJ, Visual Studio Code, Eclipse)
- 버전 콘트롤 시스템 (Gerrit, GitHub)
- CI/CD(continuous integration/deployment) 툴 (Jenkins, Spinnaker and ArgoCD)
- 옵저버빌리티(observability) 툴 (Prometheus, Grafana , Jaeger)
- 보안 툴 (FOSSA, Trivy, Xray)
그 결과 개발자의 역할은 과도하게 복잡해졌고, 기능 구현과 관련이 없는 업무를 처리해야하는 부담으로 소프트웨어 개발의 효율성도 저하되었다.
이 같은 문제를 해결하기 위해 DevOps의 긍정적인 요소를 기반으로 하는 한편 클라우드 네이티브 환경의 복잡성을 해결하는 것을 목표로 하는 플랫폼 엔지니어링이 유망한 솔루션으로 부상했다. 플랫폼 엔지니어링은 엔드투엔드(end-to-end) 툴체인의 모든 것을 각 개발자가 직접 이해하고 운영해야 하는 부담을 줄이고, 개발자에게 직접적인 관련이 없는 업무를 분리시켜 개발자 경험(DX)을 간소화하는 데 초점을 둔다.
개발자 페르소나
소프트웨어 개발 방식이 다양해지면서 개발자의 유형과 그들이 가진 지식과 역량의 범위도 확대되었다. 그림1의 표는 개발자 페르소나를 크게 3가지 유형으로 나눠 설명한다. 기술 중심적인(프로코드/pro-code개발자) 유형부터 소프트웨어를 도구로 활용하나 최상의 소프트웨어 방식을 다룸에 있어 시간과 지식이 제한적인 조금 더 솔루션 중심적인 (로코드/low-code, 노코드/no-code 개발자)유형을 중심으로 살펴본다. 동일한 솔루션을 제공하는 개발팀 간에도 솔루션 종류에 따라 이 같은 여러 페르소나가 혼합되어 존재하는 경우도 있다. 가령, 백엔드(backend) 개발자는 코드 중심(pro-code)의 개발에 집중하나, 프론트엔드(frontend) 개발은 시간 및/또는 경험 부족으로 로코드 또는 노코드 개발자로 이루어져있을 수도 있다. 이런 관점에서 볼 때 플랫폼 엔지니어링 솔루션은 다양한 니즈에 대응하고 여러 개발자 페르소나 범주의 역량을 수용할 수 있어야 한다.
[우측]
| <----Technology focused -------------------------------------------------------------------Solution focused----> | |||
| Pro-code developer | Low-code developer | No-code developer | |
| Task/approach | Front/Backend development that follows best software engineering practices | Relies on scripting languages and business process tools | No-code drag/drop and business-process tools |
| Motto | "I love building software" | "Software is means to an end" | "Software is to be avoided" |
| Software lifespan | Many years, which means that quality, reliability and long-term maintainability are important | Months to years, which means that long-term maintainability is not as important and there is a willingness to trade quality for lower initial cost | Weeks to months, which means quality is not as important and there is heavy reliance on tools that provide a reasonable level for a short period of time |
| Motivation | To develop professional-grade software using the latest tools and techniques | To develop solutions that solve business-specific problems | To develop solutions that increase automation of day-to-day work and tasks |
Figure 1: Developer personas
[/우측]
사용자 경험에서 개발자 경험
20여년 전부터 소프트웨어 기업은 UX(user experience, 사용자 경험)를 가장 우선시했다. UX가 제품에 대한 소비자의 선호도와 추천도에 큰 영향을 미쳤기 때문이다. 사용자 중심의 사고(design thinking, 디자인 씽킹)는 효과적인 솔루션을 개발하고자 사용자 경험과 니즈, 문제점을 이해하고자 활용되는 UX 기반의 방법론이다. 그림2는 사용자에 대한 공감, 문제점 정의, 아이디어 브레인스토밍과 솔루션 프로토타입 제작부터 사용자와 해당 솔루션 사전 테스트 등 일련의 모든 절차를 포함하는 디자인 씽킹 프로세스를 나타낸다. 이 같은 반복적인 방식을 통해 창의성과 협업을 증진시켜 사용자 중심의 혁신적인 결과물을 내도록 한다.
[좌측]
Figure 2: Design-thinking process super loop
[/좌측]
에릭슨은 플랫폼 엔지니어링으로 전환하는 과정의 일환으로 디자인 씽킹을 통해 자사 개발자들의 경험을 향상시키고 있다. 이 같은 사람 중심의 접근법은 개발자가 소프트웨어를 개발하고 제공하는 과정에서 기능개발과 직접적으로 관련되지 않은 업무를 자동화하는 솔루션을 설계할 때도 항상 개발자를 중심에 두도록 한다.
사용성 테스트(usability testing)이나 A/B 테스트, 필드 연구처럼 전통적인 사용자 중심의 연구 방식과 달리 개발자를 중심에 둔 방식은 다른 접근법을 필요로 한다. 개발자의 업무는 기간이 오래 걸리고 여러 팀과의 협업뿐만 아니라 다양한 툴을 활용하기 때문에 전통적인 방법론은 효율성이 떨어질 수 있다. 그에 따라 우리는 포커스 그룹과 인터뷰, 설문조사를 포함한 정성적, 정량적 기술을 모두 활용해 사용자의 태도와 관련된 데이터를 수집했다. 이러한 전략은 편견을 최소화하고 개발자의 행동방식이나 인식에 영향을 주지 않기 위해 일반적인 주제에서 구체적인 주제로 나아가는 방식으로 설계된다.
리서치 결과와 개발자들이 공통으로 직면한 과제
DX를 개선시킬 유일한 방법은 개발자의 목소리에 적극적으로 귀를 기울이는 것이다. 그들의 니즈와 고충이 무엇인지 듣고 개발자의 피드백을 반영해야 한다. 디자인 씽킹의 방법론과 UX 원칙을 활용하면 직관적이고 효율적인 솔루션을 제공하고 동시에 마찰을 줄여 전반적인 생산성을 개선시킬 수 있다. 이러한 협업 기반의 접근법을 통해 개발자의 역량은 강화시키고 만족도와 나아가 지속적인 개선과 혁신의 문화도 향상될 수 있다. 플랫폼과 rApp 개발자로부터 취합한 데이터에 따르면 각각의 팀은 고유한 특성과 강점을 갖으나 공통적으로 유사한 고충을 겪는 것으로 나타났다. 팀마다 기능 개발과 제공까지 필요한 지원은 다르나, 그들이 토로하는 고충은 크게 세 가지 부류로 나눠진다.
- 문서 현행화 이슈 및 검색의 용이성 부족
- 잘못된 환경 설정과 불안정한 딜리버리 파이프라인
- 셀프서비스 방식의 부재
1. 문서 현행화 이슈 및 검색의 용이성 부족
외부 시스템이나 라이브러리를 연동 또는 사용하는 경우, 개발자 가이드와 APIs, 아키텍처 정보, 나아가 오너십에 관련 정보 등에 대한 액세스가 필요하고, 해결되어야 할 CVE(common vulnerabilities and exposures, 취약성 노출상황)가 있는지 확인해야 한다. 그러나 이는 대부분의 팀 기능 중심이 아니라 팀 구조에 따라 내부 소프트웨어 정보를 저장하기 때문에, 형식, 세부 정보의 수준, 품질이 제각각이 되는 경우가 많아 문제가 되고 있다.
2. 잘못된 환경 설정과 불안정한 딜리버리 파이프라인
효율적인 소프트웨어 개발을 위해선 정확한 설계와 런타임 개발 환경이 중요하지만, IDE 와 의존성, 사용자 권한 구성 절차는 매우 복잡할 수 있다. 정확한 데이터로 적절히 구성된 시험 환경을 갖추는 것 역시 녹록치 않다. 또한 테스트 실패가 테스트 중인 대상 자체의 문제인지, 아니면 인프라나 테스트 오류 때문인지 정확히 판단할 수 있도록 개발자는 딜리버리 파이프라인을 신뢰할 수 있어야 한다.
3. 셀프 서비스 방식의 부재
직접적인 개입이나 회의, 승인 등을 필요로 하는 절차가 복잡한 작업은 개발자에게 큰 부담이 된다. 모든 사람이 모든 영역에서 전문가일 수는 없다는 점을 기억해야 한다. 샘플코드와 레퍼런스 아키텍처, 코드 생성기, 가이드 도구가 제공되면 체계적인 트레이닝없이도 빠르게 업무 진척을 이룰 수 있다. 정확한 지시와 명확한 학습 경로를 제공하면 개발자 온보딩이 훨씬 수월해지고, 개발자가 빠르게 업무에 독립할 수 있도록 지원할 수 있다.
플랫폼 엔지니어링 방식의 소프트웨어 개발
개발자와의 관계 형성에 있어 공감적 경청 기법을 활용하였고 이를 통해 개발 과정의 일부 어려움은 단순히 기술적 것이 아니라 조직적인 문제와 맞물려 있다는 것을 발견하였다.
개발자의 고충을 해결하려면 조직은 열린 자세를 변화에 임해야 하며, 그렇지 않으면 걸림돌은 계속해서 나타나 수밖에 없다. 플랫폼 엔지니어링은 팀 간 마찰을 최소화하는 통합적이고 효율적인 환경을 만들어 이러한 조직적 어려움을 극복하는 데 도움을 줄 수 있다. 그림 3은 플랫폼 엔지니어링 기반의 솔루션 제안을 나타낸다.
[우측]
Figure 3: Platform-engineering solution
[/우측]
내부 개발자 포탈
그림 3의 우측 노란색 부분은 플랫폼 엔지니어링 솔루션의 핵심 요소인 내부 개발자 포털(internal developer portal, IDP)을 나타낸다. IDP는 개발 조직의 인프라와 개발 도구 체인 위에 위치한 셀프 서비스 계층으로, 복잡한 내부 구조를 단순화하여 쉽게 사용할 수 있도록 한다. 개발자가 코드 변경 사항을 저장하는 소프트웨어 저장소와 함께 IDP는, 개발자와 솔루션 아키텍처, 프로그램 매니저 모두가 조직 내 모든 소프트웨어 저장소와 연동하여 소프트웨어 라이프사이클 전체를 관리하고 이해할 수 있는 통합 인터페이스를 제공한다. IDP는 코딩에서 구축까지 일련의 모든 과정을 아우르며 여러가지 반복 작업을 자동화하고 모범 사례를 적용하며, 서비스 작동 방식을 학습하고, 조직 전체에 걸쳐 일관된 사용자 경험이 제공되도록 한다. 이 모든 기능은 Spotify의 Backstage [3]와 같은 업계 제공 솔루션의 레퍼런스 플러그인 기반 아키텍처를 통해 구현되며, Backstage는 2023년에 Cloud Native Computing Foundation [4]에서 Kubernetes와 OpenTelemetry에 이어 세 번째로 많이 채택되었다.
플러그인
프론트엔드 플러그인은 그림 3의 개발자 포탈 내 노란 상자로 표기된 바와 같이 상호 연결되고 맥락을 인식하는 다양한 활용 사례를 개발자에게 제공하는 데 사용될 수 있다. 예를 들어, 조직 내의 모든 소프트웨어(APIs, 라이브러리, 서비스, 시스템 등)를 소프트웨어 오너십 정보와 함께 소프트웨어 카탈로그에서 쉽게 검색할 수 있도록 할 수 있다. 또한, 코드 생성기 플러그인은 사용자 인터페이스(UI)를 포함한 플러그인으로, 로코드& 노코드 개발자가 손쉽게 코드를 생성할 수 있도록 지원하며, 이를 통해 빠르게 비즈니스 가치를 창출할 수 있다.
또한 코드 저장소를 생성해 코딩을 시작하거나 Kubernates 클러스터에 Helm 구축 등과 같은 셀프 서비스 활용 사례를 실행하는 셀프 서비스 방식의 마법사 기반 UI를 제공하는데도 플러그인은 사용될 수 있다.
백엔드 플러그인은 고객의 딜리버리 파이프라인이 개발자의 니즈를 충족할 수 있도록 주로 Jira, GitHub, Jenkins, Spinnaker, Kubernetes 같은 외부 시스템 또는 기타 서비스형 (as a service)인프라 시스템과의 연결해주는 역할을 한다.
개발자 포탈 외 고려사항
개발자 포털이 개발자 경험(DX)의 중요한 부분이긴 하나, 그 외에도 고려해야 할 사항이 많다. DX 개선 작업은 개발자 포털의 범위를 넘어, 개발자가 활동하는 생태계 전체를 아우른다. 온보딩과 협업 도구 최적화, 커뮤니케이션 채널 간소화, 파이프라인 복원력 확보, 새로운 코드 저장소 관리, 테스트 환경 예약 등이 그에 포함된다. 이러한 측면들은 각각 독립적으로 해결될 수 있고 또 그렇게 되어야 하지만, 개발자 포털을 통해 하나의 통합된 솔루션 오퍼링으로 어우러져야 한다. 이러한 모든 측면이 개발자 포탈에 통합되어 한 화면으로 제공될 때 개발자와 그들이 개발 중인 소프트웨어의 맥락을 인식하는 것이 매우 중요하다.
이 같은 아키텍처 솔루션은 다양한 개체가 모델링되도록 하며, 개발자가 소유한 소프트웨어 산출물을 나타내는 메타 데이터 스키마의 정의에 따라 조직 고유의 정보를 저장할 수 있도록 확장 가능하다. 이러한 메타 데이터는 문서와 API 등의 기타 메타 데이터와 함께 서비스의 저장소에 문서 코드화 방식(doc-as-code)으로 저장되며, 개발자가 직접 이 과정을 관리하게 된다. 프론트엔드와 백엔드 플러그인 모두 저장된 메타데이터를 활용하여 개발자 맞춤형 맥락 기반 뷰를 제공합니다. 개발자가 작업중인 오류 유형에 따라 다양한 활용 사례와 개발자 요구에 적합한 플러그인이 생성될 수 있으며, 이를 통해 다양한 개발자 페르소나를 지원하는 유연성과 맞춤형 문제 해결이 가능하다.
불필요한 작업 지양
플랫폼 엔지니어링, 특히 개발자 포털에서는 대상 개발자가 필요로 하는 기능을 통합할 때, 새로운 플러그인을 생성할 지와 외부 도구에 이미 존재하는 기능을 활용할 지 그 사이에서 적절한 균형을 찾아야 한다. 개발자의 관점에서 상황에 맞는 (context-aware) 통합 작업이 이루어져야 하나, 불필요하게 새로운 플러그인을 만들 필요는 없다. 예를 들어, 풀스택 개발자가 rApp을 개발하면서 특정 API와의 상호작용을 테스트하고자 할 때, 이를 새로 구축하기보다는 OpenAPI Generator와 같은 업계 표준 도구를 활용하는 것이 합리적인 선택일 수 있다. 포털은 해당 API에 대한 OpenAPI 명세 파일을 제공하여, 이를 통해 어떤 테스트 프레임워크에서도 실행 가능한 스텁(stub) 서버를 생성할 수 있도록 지원할 수 있다. 이 기능을 사용할 개발자와의 긴밀한 협력이 해당 개발자들로 하여금 이러한 기능을 잘 활용할 수 있도록 하는 유일한 방법이다.
서비스 관리&오케스트레이션 DX 적용
O-RAN 얼라이언스의 회원사인[5]에릭슨은 rApp과 SMO 생태계를 통해 CSP가 네트워크 활용 사례를 자동화하는 소프트웨어를 구축할 수 있도록 지원할 수 있다. 이러한 역량으로 CSP와의 관계에 있어 큰 변화를 이끌 것으로 기대한다. 기존에는 최종 사용자를 위한 활용 사례를 실행하는 애플리케이션을 주로 제공해왔다면, 이제는 다양한 역량과 관심사를 가진 개발자들이 직접 활용 사례를 구현할 수 있도록 기능과 지원을 제공할 수 있다. 예를 들어, 현재 여러 CSP에 자체 자동화 스크립트를 구축하는 로코드 개발자는 조만간 더욱 제품화되고 체계적으로 관리되는 rApps를 활용해 다양한 네트워크 활용 사례를 자동화할 수 있게 될 것으로 예상된다. 보안과 같은 영역처럼 특정 표준을 준수해야 하는 경우 rApps는 필수이며, 그에 따라 개발 관련 업무도 증가할 수 있다. 클라우드 네이티브로 전환되는 과정에서 프로 코드 개발자를 위한 DX를 개선하는 것이 중요했던 것처럼 로드(low-code), 노코드(no-code) 개발자가 솔루션 개발에 집중하는 동안 rApps를 수월하게 채택, 개발할 수 있도록 지원하는 것 역시 중요하다.
연구 결과 적용을 통한 고객 니즈 해결
SMO상에서 구동되는 rApp 을 통해 가치를 창출하든 SMO를 기반으로 플랫폼 기능을 노출하는 서비스를 개발하는 사람이든 모두 개발자다. 어느 쪽이든 자사의 개발자와 마찬가지로 테스트와 파이프라인 이행, 문서 작업 등과 같은 유사한 고충 외에도 추가적인 어려움에도 처한다. 소프트웨어 개발 키트 문서작업, 앱 이식성(portability), 앱 이식성을 지원하는 O-RAN 표준의 성숙도, 해당 개발자의 개발 역량 등이 포함된다. 로코드와 노코드 개발자는 그 이상의 지원을 필요로 하며, SMO 벤더와 rApp 벤더간 통합도 필요하다. 고객사는 또한 rApps을 포함한 자사의 소프트웨어와 외부 벤더의 rApps, SMO 소프트웨어, 나아가 다양한 엔지니어링과 CI 방식까지 통합해야 한다.
우리는 내부 및 CSP 개발자 커뮤니티 모두를 지원할 수 있도록, '한 번에 제대로 문서화해 둘 것(write it once and write it well')이라는 원칙 하에 서비스용 문서(API, 개발자 가이드, 릴리즈 노트 등)를 누구나 쉽게 접근하고 이해할 수 있는 형태로 작성하는 체계를 개선시켜 왔다.
그러나 “환경 셋업”과 “셀프 서비스” 와 관련해 CSP rApp 개발자가 겪는 고충에는 중요한 차이점이 있다. 이들의 고충은 우리와 비슷하나, CSP 자체적인 상용 및 오픈소스 서비스(aaS) 제공 방식을 기반으로 하기 때문에, 솔루션을 설계시, 이를 모두 고려해야 한다. 그럼에도 불구하고, 동일한 셀프서비스 측면(빠른 온보딩, 간소화된 워크플로우, 향상된 생산성)을 반드시 지원해야 한다. 솔루션은 노코드부터 프로코드까지 다양한 개발자 페르소나가 적합한 보안과 구축 기준에 맞춰 rApp을 신속하게 개발하여 비즈니스 가치를 제공할 수 있도록 맥락 기반의 맞춤형 기능을 갖춰야 한다.
사례 분석: 로코드 (low-code) 개발자가 rApp을 개발하는 경우
파이썬과 통신에 대한 탄탄한 지식을 갖춘 CSP 소속 로코드 개발자가 머신러닝을 활용해 자사의 네트워크 퍼포먼스에 인사이트를 제공할 수 있는 rApp를 개발해야하는 상황을 상상해보자. 해당 rApp은 여러 인사이트를 보고하기 위한 GUI(graphic user interface)를 포함해야 하나, 해당 개발자는 GUI 개발 경험이 충분치 않을 수 있다.
이 개발자는 실제 코딩 작업을 하기 전과 그 이후까지 여러 가지가 필요하다. 우선, 필요한 SMO 플랫폼 API에 대한 정보가 있어야 하며, CSP가 사용하는 내부 라이브러리가 있다면 그것이 어떤 기능을 하고 어떻게 동작하는지도 알아야 한다. 또한, 이 rApp 개발에 사용할 기술(JavaScript, Python 등)을 지원하는 노트북이 마련되어야 한다. rApp을 테스트할 시점이 되면, 필요한 데이터와 서비스가 갖춰진 환경이 마련되야 한다. 도입 작업이 시작되면, 새로운 기능 제공이나 버그 수정 등의 소프트웨어 릴리스를 자동화할 수 있는 CI/CD 프레임워크가 필요하다. 또한 해당 rApp이 실제 운영 환경에 구축되기 전 보안 및 품질 기준을 충족한다는 승인을 받아야 한다.
어떤 개발자에게도 이는 상당한 업무량이지만, 적합한 플러그인을 갖춘 개발자 포탈을 활용하면 여러 측면에서 업무를 간소화할 수 있다. 예를 들어, API 문서를 조회하거나 특정 CSP 전용 라이브러리를 찾을 수 있도록 API 카탈로그가 제공된다면 매우 유용할 수 있다. 또한, 개발 아이디어를 실험해볼 수 있도록 사전 구성된 개발 환경의 플레이그라운드나 샌드박스를 제공하는 개발자용 컨테이너가 있다면, 로컬에 별도로 소프트웨어를 설치할 필요 없이 빠르게 작업을 시작할 수 있다. 접근성 등 UX 규정을 준수하는 간단한 GUI를 자동으로 생성해주는 코드 생성기 역시 큰 도움이 될 수 있다.
개발자 포털은 개발자가 맡아야 하는 방대한 양의 직접적인 조율 작업을 간소화시킬 수 있다. 예를 들어, 보안과 품질 기준을 충족하는지 확인하기 위한 일부 자동화된 검증 절차가 있긴 하지만, 대부분의 경우 특정 단계마다 여러 사람의 승인이 필요하다. 셀프서비스 절차를 통해 적절한 정보를 수집하고, 승인이 필요한 담당자에게 자동으로 알림을 보내는 방식으로 이 과정을 훨씬 빠르게 진행할 수 있다.
결론
더 높은 수준의 네트워크 자동화를 구현하려면 뛰어난 품질 소프트웨어를 효율적으로 개발하는 것이 핵심이다. rApp 개발 과정에서 개발자 경험(DX)을 우선시함으로써, CSP는 자사의 개발자들이 사용하는 도구와 플랫폼이 효율성과 효과에 최적화되도록 할 수 있으며, 이는 곧 생산성 향상과 빠른 시장 출시(time to market)로 이어진다.
플랫폼 엔지니어링은 기술 역량을 강화하고 운영을 간소화하려는 모든 조직에 필수적이며, CSP도 예외는 아니다. 플랫폼 엔지니어링 방식을 채택함으로써 기업은 다양한 애플리케이션과 서비스를 지원하는 강력하고 확장 가능하며 효율적인 플랫폼을 구축할 수 있다. 이러한 접근법은 개발 사이클을 단축시킬 뿐만 아니라 기술 스택 전반에 걸쳐 일관성, 신뢰성, 보안성을 보장한다. 플랫폼 엔지니어링에 대한 투자는 운영 효율성을 개선시키고, 비즈니스 성장을 지원하며, 빠르게 디지털화 되어가는 환경에서 CSP가 지속적으로 발전할 수 있도록 하는 전략적인 행보라고 할 수 있다.
Further reading
References
Authors
Anne Marie Dignam
Damien O’Toole
Joseph Grogan
