플랫폼 엔지니어링이란? (Platform Engineering vs DevOps vs SRE)

2023년의 전략 기술 트렌드로 가트너는 확장 영역에서 플랫폼 엔지니어링을 언급했습니다. 본문에서는 플랫폼 엔지니어링이 무엇이고 DevOps 및 SRE와는 어떤 유사점과 차이점을 갖고 있는지 알아봤습니다.

1. 개념

플랫폼 엔지니어링은 소프트웨어를 제공하고 수명주기를 관리하기 위해 셀프서비스 기능을 설계하고 구축하는 분야로 내부 사용자 (일반적으로 소프트웨어 개발자 및 엔지니어)에게 공유 인프라 플랫폼을 제공합니다.

2. 배경

플랫폼 엔지니어링은 디지털 트랜스포메이션을 위해 엔터프라이즈 소프트웨어 제공을 현대화하기 위한 새로운 트렌드로 등장했습니다. 개발자들은 애플리케이션을 빠르고 효율적으로 배포하기를 원합니다. 그런데 우리가 사용하는 소프트웨어는 다양하고 그 복잡성은 더욱 증가하고 있는 추세입니다. 결국, 최종사용자를 돕고 수행 작업 과정에서의 마찰을 줄이기 위해서 최종사용자와 지원 서비스 사이의 운영 플랫폼을 구축하기 시작한 것입니다.

3. 목표

플랫폼 엔지니어링의 가장 중요한 목표는 개발자 생산성을 높이는 것입니다. 개발자와 다른 사람들이 가능한 한 적은 오버헤드로 가치 있는 소프트웨어를 생산할 수 있도록 적절한 기능을 제공하는, 마찰 없는 셀프 서비스 개발자 경험을 제공하는 것입니다. 따라서 플랫폼은 인지 부하를 줄이는 동시에 개발자 생산성을 높여야 합니다. 플랫폼에는 개발 팀이 필요로 하는 모든 것들이 포함되어야 하고 팀이 선호하는 워크플로에 적합한 방식으로 제공돼야 합니다.

4. DevOps vs SRE vs Platform Engineering

플랫폼 엔지니어링이 급속도로 관심을 받으면서 이것이 무엇인지, 그리고 사이트 안정성 엔지니어링(SRE) 및 DevOps와 같은 분야와 어떤 점이 다른지에 대한 많은 혼란이 생겼습니다. 실제로 많은 SRE 및 DevOps 전문가가 플랫폼 엔지니어링으로 전환하면서 세 개의 분야가 동일한 것으로 착각하기 쉬워졌습니다.

플랫폼 엔지니어링 그리고 DevOps, SRE의 차이는 미묘하지만 플랫폼 엔지니어링의 역할이 매우 중요해지는 요인이기도 합니다.

1) DevOps (데브옵스)

2006년, Amazon의 CTO Werner Vogels는 소프트웨어 엔지니어링에 대한 회사의 접근 방식에 대해 “You build it, you run it.”이라고 설명했습니다. 그렇게 Amazon 개발자들을 중심으로 DevOps가 탄생했고, DevOps 접근 방식의 도입의 성공을 측정할 수 있는 다양한 지표들이 제시되었습니다. Accelerate는 리드타임, 배포 빈도, 평균 복구 시간(MTTR)을 표준 메트릭으로 설정했습니다. Puppet에서 발행한 DevOps 상태 및 Humanitec의 DevOps 벤치마킹 연구 보고서에서는 이러한 메트릭을 사용해 최고 성과를 내는 조직과 낮은 성과를 내는 조직을 비교하고 성공 수준에 가장 크게 기여하는 방식을 추론했습니다.

DevOps는 일부 소프트웨어 엔지니어링 팀에 새로운 수준의 생산성과 효율성을 제공했지만 많은 조직에서 DevOps의 채택은 높은 기대치에 미치지 못했습니다. Manuel Pais와 Matthew Skelton은 저서 『DevOps Topology』에서 이러한 안티 패턴을 문서화했습니다. 한 시나리오에서 조직은 별도의 운영 팀을 유지하기를 원치 않아 개발팀이 인프라, 환경 관리, 모니터링 등을 담당하도록 합니다. 이에 따라 선임 개발자들은 스스로 작업을 수행하거나 후임 개발자를 보조하면서 조직 변화로 인한 가장 큰 영향을 받게 됩니다.

이러한 “shadow operations” 안티 패턴은 조직에서 가장 유능한 리소스를 비효율적으로 할당하는 결과를 맞이합니다. 이는 DevOps 설정에 어려움을 겪는 조직들 사이에서 만연한 문제입니다. Humanitec의 DevOps 벤치마킹 연구에 따르면 상위 성과를 내는 조직의 100%가 개발자가 모든 DevOps 작업을 스스로 수행할 수 있다고 응답했지만, 하위 성과를 내는 조직의 44%가 섀도 작업을 수행하고 있는 것으로 나타났습니다. 섀도 작업 즉, shadow operations은 잘못된 DevOps의 운영에서 파생된 더 큰 문제입니다. 개발자에게 너무 많은 인지 부하를 주게 되는 것입니다.

DevOps 채택으로 인해 개발자가 상호 작용해야 하는 도구 및 워크플로의 양과 복잡성이 증가했습니다. 이 모든 것이 인지 부하를 만들어내고 개발자가 가장 중요한 작업을 완료하는 데에 방해가 됩니다. DevOps 문화는 개발자 셀프 서비스가 생산성과 효율성을 높일 수 있음을 보여주는 동시에 많은 조직에서 발생하는 개발자의 인지 부하로 인해 일부 구조, 표준화 및 적절한 수준의 추상화를 제공하기 위한 설정의 필요성이 강조되었습니다.

2. SRE (사이트 안정성 엔지니어링)

SRE는 Google에서 만들고 대중화했습니다. DevOps와 마찬가지로 많은 주목을 받은 문화적 변화였습니다. SRE의 도움으로 엔지니어는 목표로 하는 서비스 수준을 정할 수 있습니다. 정의된 목표를 기반으로 시스템이 개발되며 이러한 시스템은 장애 완화, 단일 장애 지점 제거와 같은 영역을 처리하는 플랫폼으로 확장됩니다. SRE의 접근 방식 중 매우 중요한 측면은 모든 장애를 장애로 간주하고 상세한 근본 원인 분석을 수행해 장애 원인을 찾는 것입니다. 또한 신뢰성 측면에서 지속적인 발전을 위해 시정 조치를 도입합니다.

이론적으로 SRE에는 큰 문제가 없습니다. 하지만 다른 방법론과 같이 잘못 채택된 사이트 안정성 엔지니어링은 많은 문제를 일으킬 수 있고 특히 Google과 달리 리소스나 인재가 부족한 조직일 경우 더욱 문제가 두드러지게 나타납니다. SRE를 고용하는 것은 어렵고 많은 비용을 투자해야 합니다. 이런 문제로 대부분의 조직은 요구 사항을 충족하기에 충분한 경험이 있는 SRE를 고용하지 못합니다. 결과적으로 일부의 담당자가 대신하여 책임을 맡게 됩니다. 이러한 조직의 SRE는 개발자 경험을 개선하는 일 보다 생존에 더 집중할 수밖에 없습니다. 그들은 개발자 셀프 서비스를 활성화하거나 아키텍처 또는 도구를 개선할 시간이 없습니다.

“가짜” SRE는 소프트웨어 엔지니어링에 대한 DevOps 이전의 접근 방식을 연상시킬 정도로 매우 제한적인 역할이 됩니다. 개발자들은 자신이 구축한 소프트웨어를 실제로 실행하는 데에 어려움을 겪고, SRE는 문제가 발생했을 때 개발자와 협력해 문제를 해결할 시간이 없기 때문에 여전히 문제가 되고 있습니다.

3) Platform Engineering (플랫폼 엔지니어링)

플랫폼 엔지니어링은 소프트웨어 엔지니어링 조직이 일관성을 유지하고 작업의 속도를 높일 수 있도록 워크플로 및 도구를 설계, 구축 및 유지 관리 하는 프로세스입니다. 많은 플랫폼 엔지니어는 내부 개발자 포털이라는 통합 소프트웨어 제품을 유지 관리합니다. 이 포털은 클라우드, 도구 및 팀에 분산된 데이터와 지식을 통합해 엔지니어링 조직의 모든 사람이 애플리케이션, 서비스 및 인프라에 대한 필수 정보를 한 곳에서 검색할 수 있도록 합니다.

Luca Galante는 플랫폼 엔지니어링을 “클라우드 네이티브 시대의 소프트웨어 엔지니어링 조직을 위한 셀프서비스 기능을 지원하는 도구 체인 및 워크플로를 설계하고 구축하는 분야”라고 정의했습니다. 플랫폼 엔지니어는 애플리케이션의 전체 수명 주기의 운영 필요성을 포괄하는 ‘내부 개발자 플랫폼’으로 자주 언급되는 통합 제품을 제공합니다. 내부 개발자 플랫폼 및 이를 구축하는 팀은 조직의 성과를 향상시키는 데에 큰 역할을 합니다. 내부 개발자 플랫폼 사용 그리고 DevOps의 성숙도에 대한 관계에 대한 요약 내용을 원한다면 여기를 클릭하세요

Humanitec CTO인 Chris Stephenson은 IDP(Internal Developer Platforms)를 “개발자가 작업에 방해받지 않고 작업을 수행할 수 있도록 개발자와 플랫폼 팀을 연결하는 다리”라고 설명했습니다. 좋은 플랫폼은 잘못 채택된 DevOps 및 SRE에서 발생하는 문제를 완화합니다. DevOps가 개발자에게 너무 많은 인지 부하를 생성하는 경우 플랫폼 엔지니어링은 적절한 수준으로 핵심적인 개념과 기능을 간추리고 골든 패스를 활용해 이를 완화하려고 합니다. 가짜 SRE가 개발자에게 병목현상을 일으키는 경향이 있는 경우 플랫폼 엔지니어링은 개발자 셀프서비스와 자율성을 우선시하며 문제를 해결합니다.

5. 결론

1) DevOps vs Platform Engineering

플랫폼 엔지니어링은 여러 응용 프로그램 및 서비스를 지원하는 기본 인프라 및 플랫폼을 구축하고 유지하는 데에 중점을 둡니다. DevOps는 전체 소프트웨어 제공 프로세스 개선을 목표로 하는 일련의 사례 및 도구를 포함하는 광범위한 영역으로 쉽게 말해 플랫폼 엔지니어링이 조금 더 세분화되고 전문적인 영역이라고 볼 수 있습니다. 또한, 플랫폼 엔지니어링은 플랫폼 설계 및 개발의 기술적 측면 즉, 세부 구현에 중점을 두고 있는 반면에 DevOps는 개발팀과 운영팀 간의 협업 및 커뮤니케이션 문화 및 프로세스에 중점을 두고 있습니다.

조직이 새로운 애플리케이션과 서비스를 빠르고 쉽게 개발, 배포 확장할 수 있도록 하여 혁신과 성장의 기반을 제공하는 것을 목표로 두고 있는 것이 플랫폼 엔지니어링이라면, DevOps는 프로세스를 자동화하고 팀 간의 사일로를 허물어 소프트웨어 제공의 속도와 안정성 그리고 효율성을 개선하는 것을 목표로 하고 있습니다. 플랫폼 엔지니어링과 DevOps는 지향하는 바가 동일하지만 DevOps에 비해 플랫폼 엔지니어링은 조금 더 전문적인 내용을 다룬다는 차이가 있습니다.

2) SRE vs Platform Engineering

플랫폼 엔지니어링 팀은 소프트웨어 엔지니어링 원칙을 적용해 소프트웨어 제공을 가속화합니다. 플랫폼 엔지니어는 애플리케이션 개발 팀이 소프트웨어 제공 수명 주기의 모든 측면에서 생산성을 발휘하도록 합니다. 반면에 사이트 안정성 엔지니어링 팀은 소프트웨어 엔지니어링의 원칙을 적용해 안정성을 향상시키며 클라우드 애플리케이션의 전반적인 안정성에 영향을 줄 수 있는 오류의 빈도와 영향을 최소화합니다.

이 두 팀은 자주 혼동되기도 하고 용어의 경우 때로는 같은 의미로 사용됩니다. 실제로 일부 조직은 SRE팀과 플랫폼 엔지니어링 팀을 통합합니다. 두 팀 모두 공통의 원칙을 적용하기 때문입니다.

미래를 예측하는 것은 결코 쉽지 않지만, 이를 가능하게 하는 몇 가지의 요인은 존재합니다. 플랫폼 엔지니어링의 발전에 가장 큰 역할을 하는 것은 바로 클라우드 컴퓨팅의 성장입니다. 또 AI와 ML의 부상 역시 플랫폼 엔지니어링을 발전시키는 또 하나의 축이며, 이러한 기술적인 요소 외에도 보안 및 규정준수 역시 플랫폼 엔지니어링의 미래를 형성할 수 있습니다. DevOps의 성숙으로 세분화 및 전문화에 따라 플랫폼 엔지니어 역시 점점 더 중요한 역할을 하게 될 것입니다.