플랫폼 엔지니어링과 DevOps 비교

URL 복사

 플랫폼 엔지니어링과 DevOps는 둘 다 애자일 소프트웨어 개발 방법론을 사용하여 출시 시간을 단축하고 개발 장벽을 낮추는 IT 관행이지만, 등장하는 단계와 다루는 문제가 서로 다릅니다. 둘의 차이를 이해한다면 목표에 부합하는 접근 방식을 선택하는 데 도움이 될 것입니다. DevOps는 조직이 개발과 IT 운영 기능을 반복적인 워크플로우로 통합하기 위해 사용하는 소프트웨어 개발 방식입니다. 반면 플랫폼 엔지니어링의 주 목적은 그러한 워크플로우를 지원하는 내부 플랫폼 및 툴을 개발하는 것입니다. 

DevOps는 툴과 프로세스를 사용하여 개발과 운영이라는 두 영역을 결합함으로써 기존에는 조직 내에서 서로 격리되어 있던 팀을 통합합니다. DevOps는 애자일 원칙을 사용합니다. 이는 자체 관리형 팀과 빠른 반복에 의존하는 개발 방법론입니다. DevOps를 구현하려면 팀 간 협업, 다양한 부서의 참여, 그리고 신뢰와 화합이 필요합니다. 따라서 일반적으로 단순한 프로세스 변경이 아닌 조직적 차원의 변경이 필요합니다. DevOps가 제대로 기능하려면 조직의 문화를 바꾸어야 합니다.

DevOps 및 애자일 방법론은 기존의 워터폴(waterfall) 소프트웨어 개발에 대한 비판에 맞서 등장했습니다. 비판의 주 내용은 혁신 속도를 늦추고 조직 내에 장벽과 병목을 만든다는 것이었습니다. 워터폴 시스템에서는 코드 요구 사항을 먼저 기능, 효율성, 표준화, 도큐멘테이션 측면에 대해 테스트한 다음 애플리케이션에 통합합니다. 이러한 사전 테스트 때문에 프로세스 대기열이 길어져서 프로젝트를 범위 내에서 기한과 예산에 맞춰 실행하기 어려운데, 불확실하거나 유동적인 프로젝트의 경우 더욱 어렵습니다.

한편 DevOps는 자동화와 주기적 프로세스를 사용하기 때문에, 개발 팀은 소프트웨어를 개발 단계에서 프로덕션 단계로 빠르게 이동하고 프로덕션 단계에서도 소프트웨어를 지속적으로 개선할 수 있습니다. DevOps는 전문 지식을 공유하도록 장려하는 관행을 통한 팀 간의 밀접한 소통과 협업을 필요로 합니다. 이러한 관행은 제품을 미리 개선하여 출시 속도를 늦추는 대신 반복 작업 내에 통합하여 개발하는 것을 의미합니다. DevOps를 구현하는 조직은 시간 흐름에 따라 소프트웨어를 체계적으로 개선할 수 있으므로 팀이 변화에 적응하고 새로운 방법을 시도할 수 있습니다. 기존 개발 모델에서는 그렇게 하기가 어렵습니다.

플랫폼 엔지니어링은 DevOps 관행을 확장한 것으로, 표준화된 툴, 서비스, 워크플로우를 제공하여 개발 팀이 소프트웨어 솔루션을 더욱 효율적으로 빌드할 수 있도록 합니다. 플랫폼 엔지니어링은 내부 서비스와 리소스를 체계화하여 개발 팀이 그러한 기반 요소를 직접 관리할 필요 없이 솔루션을 빌드할 수 있도록 하는 관행을 의미하는 최신 용어입니다. 플랫폼 엔지니어는 개발 팀이 필요로 하는 다양한 툴, 서비스 및 도큐멘테이션을 선별하고 유지 관리함으로써 IT 조직의 모든 멤버가 최적의 경로인 자동화된 프로세스를 사용하여 모든 것을 직접 준비할 필요 없이 더욱 효율적으로 작업할 수 있도록 돕습니다. 플랫폼 엔지니어링은 DevOps가 더욱 널리 채택됨에 따라 성장했습니다. 플랫폼 엔지니어링은 DevOps 워크플로우를 지원하고 엔터프라이즈 조직에서 DevOps가 확장할 수 있도록 돕는 기반 구성 요소를 제공하기 때문입니다.

 Abby Bangser는 DevOpsDays London 컨퍼런스 프레젠테이션에서 플랫폼 엔지니어링이 DevOps에서 하는 역할을 요리에 비유하여 설명했습니다. 여러분이 소프트웨어(메뉴)를 '요리'하고 있고 도구(팬) 또는 재료(파슬리)가 필요한 경우, 요청을 제출할 수는 있지만 필요한 것을 정확하게 손에 넣지 못할 수 있습니다. 프로비저닝 담당자가 여러분에게 필요한 재료를 올바르게 제공하지 못하거나, 요청한 재료에 접근하지 못하는 경우가 있어서죠. DevOps 모델에서는 요청을 제출하고 프로비저닝에 의존해야 하는 이런 상황을 방지합니다. 대신 필요한 재료나 도구를 직접 준비해야 합니다. Bangser의 요리 비유를 따르자면, 여러분이 직접 금속을 녹여 팬을 만들거나 파슬리 종자를 심고 길러야 합니다. 이는 어렵고 비효율적입니다.

이 셀프 서비스 모델에서는 개발 팀이 일상적인 작업을 처리하기 위해 수많은 기술을 직접 다뤄야 합니다. 적합한 툴셋을 찾아 헤매는 것은 번거롭고 효율성이 떨어지며 팀의 인지적 부담을 늘릴 수 있습니다. 새로운 멤버가 효율적으로 팀에 적응하기가 더 어려워지는 온보딩 문제도 발생합니다. 신규 채용자는 수많은 툴과 시스템 속에서 어려움을 겪고, 그들을 도와야 할 기존 팀원은 본연의 업무에 집중하지 못하게 되어 생산성이 떨어집니다. 플랫폼 엔지니어링은 이러한 부담을 완화하여 DevOps 워크플로우를 지원합니다. 즉, 플랫폼 엔지니어가 IT 조직을 위해 모범 사례와 셀프 서비스 경험을 중앙화하여 IT 조직이 혁신에 집중할 수 있도록 합니다.

플랫폼 엔지니어링에 대해 자세히 알아보기

플랫폼 엔지니어링은 DevOps 팀이 모든 작업을 직접 수행할 필요를 없애서 DevOps의 확장을 돕습니다. 플랫폼 엔지니어링을 통해 조직 내 여러 개발 팀이 사용할 수 있는 일련의 표준화된 툴, 지식, 서비스 및 프로세스를 구축할 수 있습니다. 개발 팀은 엄선된 플랫폼을 사용하여 구성 요소를 빌드, 배포, 운영 및 지원하고, 플랫폼 팀은 플랫폼 구성 요소를 빌드, 배포, 운영 및 지원할 수 있습니다. 이 방식으로 두 팀이 본연의 업무에 집중하고 제공 속도를 높일 수 있습니다. 플랫폼 팀은 모든 것을 서비스로(X-as-a-service) 제공하므로 DevOps 팀은 모든 것을 즉석에서 빌드할 필요가 없습니다.

플랫폼 팀이 개발 팀을 위한 구성 요소를 제공하는 경우, 플랫폼 엔지니어링이 동일한 문제를 야기하고 DevOps에서 처음에 완화하려 한 내부 종속성이 발생할 것처럼 보일지도 모릅니다. 애플리케이션 팀이 플랫폼 팀으로부터 필요한 것을 제공받을 떄까지 기다리면 프로세스에 병목이 발생할까 걱정스럽죠.

이는 이론상으로는 가능하지만, 플랫폼 팀은 중복성과 이중의 수고를 줄여서 조직 전체에서 시간을 절감하는 데 도움을 줄 수 있습니다. 여러 개발 팀이 각자 동일한 기능을 하는 플랫폼을 자체적으로 빌드하는 대신, 하나의 셀프 서비스 플랫폼을 사용하는 것입니다. 이렇게 하면 시간이 흐름에 따라 일관성이 갖춰집니다. 기존 개발 팀이 현재 프로젝트에서 떠나는 경우에도 이러한 일관성을 유지할 수 있습니다. 또한 이러한 플랫폼 팀에 있어 개발 팀은 고객입니다. 플랫폼 팀이 타겟 사용자의 요구 사항을 충족하지 못하는 경우 해당 내부 고객은 다른 종류의 인프라나 배포 메커니즘을 사용할 것이기 때문에 빨리 제공하는 것이 좋습니다. 모범 사례와 검증된 솔루션으로 플랫폼에 기여할 수 있으며, 팀은 더 효과적으로 지식을 공유할 수 있습니다.

사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)에 대해 알고 있다면 플랫폼 엔지니어링이 낯설지 않을 것입니다. SRE는 Google이 이전에는 시스템 관리자가 실행하던 수작업 대신 자동화로 제품을 실행하는 시스템을 설명하기 위해 새롭게 만든 용어입니다. SRE는 기본 인프라를 관리하며, SRE 팀은 인프라 무결성을 보장하고 가동 시간을 유지하기 위한 프로세스와 자동화를 개발합니다. SRE 실무자 및 플랫폼 엔지니어는 공통된 목표를 갖고 있지만, SRE는 소프트웨어의 성능, 신뢰성, 확장에 초점을 두는 반면 플랫폼 엔지니어링은 개발자 경험 향상을 목표로 하는 시스템에 초점을 맞춥니다.

SRE에 대한 Red Hat의 접근 방식 자세히 알아보기

팀은 일반적으로 플랫폼 엔지니어링을 사용하여 셀프 서비스 포털에서 자체 내부 개발 플랫폼(Internal Development Platform, IDP), 툴, 서비스 및 도큐멘테이션을 개발합니다. 플랫폼 엔지니어는 사용자 요구 사항과 모범 사례를 기반으로 IDP를 설계하고 제공할 수 있으며, 사용자 조사와 테스트를 통해 이를 반복해서 개선할 수 있습니다. 플랫폼 엔지니어는 개발 팀을 타겟 사용자로 하여 개발자 셀프 서비스를 지원하고 개발 팀의 인지적 부담을 줄이는 데 도움이 되는 IDP를 제공할 수 있습니다.

소프트웨어 개발 라이프사이클에서 지속적 통합 및 지속적 제공(Continuous Integration and Continuous Delivery, CI/CD)을 확립하려는 조직은 DevOps 관행을 채택해야 합니다. CI/CD는 코드 테스트 및 빌드를 자동화하여 소프트웨어 개발 및 업데이트 주기를 지속적으로 통합하므로 버그와 코드 오류의 영향을 최소화합니다. 조직은 소프트웨어 개발 라이프사이클 전반에서 CI/CD 파이프라인을 통합하고 자동화하여 고품질의 플랫폼을 빌드하고 애플리케이션을 더 빠르게 제공하는 데 필요한 가시성을 확보할 수 있습니다.

Red Hat® 제품 및 서비스는 유기적으로 작동하여 개발자 생산성을 지원하고 엔터프라이즈의 팀 생산성을 높이는 데 필요한 유연성을 제공합니다. 또한 셀프 서비스를 확장하고, 온보딩을 가속화하고, 모든 팀에서 반복적인 태스크를 줄입니다.

Red Hat Developer Hub는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF) 프로젝트인 Backstage 기반의 엔터프라이즈 내부 개발자 포털입니다. 조직은 Red Hat Developer Hub를 통해 사용하는 기술을 통합하고 셀프 서비스 및 온보딩을 확대하고 생산성을 높일 수 있습니다. 또한 Red Hat Developer Hub에서 내부 개발자 포털을 사용하여 개발 프로세스 요소를 통합하고 워크플로우를 간소화하고 내부 협업을 촉진할 수 있습니다.

개발자는 Red Hat Developer Hub와 Red Hat OpenShift®를 함께 사용하여 온프레미스, 클라우드, 엣지 등 배포 위치에 상관없이 클라우드 네이티브, 레거시 및 현대화된 애플리케이션 등 다양한 애플리케이션을 작업할 때 원하는 툴을 사용할 수 있습니다.

Red Hat 기술 연동을 통한 개발자 생산성 지원

Red Hat 기술 연동으로 개발자 생산성을 지원하는 방법을 알아보세요.

추가 자료

플랫폼 엔지니어를 위한 Red Hat OpenShift

Red Hat OpenShift는 플랫폼 엔지니어링 팀에 내부 개발자 플랫폼을 효과적으로 구축하고 관리하는 데 필요한 툴을 제공합니다.

엣지 인공지능(Edge AI)이란? 실시간 AI 분석 및 처리 기술

엣지 인공지능(Edge AI)은 데이터 분석과 처리를 클라우드가 아닌 디바이스에서 직접 수행하는 기술입니다. 실시간 응답 속도를 높이고, 보안과 개인정보 보호를 강화하는 Edge AI의 원리와 활용 사례를 확인하세요.

Linux(리눅스)란? 오픈소스 운영체제의 핵심 구성 요소와 장점

Linux(리눅스)는 커널, 툴, 애플리케이션, 서비스로 구성된 오픈소스 운영체제입니다. 서버와 클라우드 환경에서도 널리 사용되는 리눅스의 개념과 활용 사례를 알아보세요

Platform engineering 리소스

주요 제품

  • Red Hat OpenShift

    선택한 하이브리드 클라우드 인프라에 맞게 애플리케이션을 대규모로 구축, 현대화 및 배포할 수 있는 통합 애플리케이션 개발 플랫폼입니다.