DevOps란?
DevOps는 툴과 프로세스를 사용하여 개발과 운영이라는 두 영역을 결합함으로써 기존에는 조직 내에서 서로 격리되어 있던 팀을 통합합니다. DevOps는 애자일 원칙을 사용합니다. 이는 자체 관리형 팀과 빠른 반복에 의존하는 개발 방법론입니다. DevOps를 구현하려면 팀 간 협업, 다양한 부서의 참여, 그리고 신뢰와 화합이 필요합니다. 따라서 일반적으로 단순한 프로세스 변경이 아닌 조직적 차원의 변경이 필요합니다. DevOps가 제대로 기능하려면 조직의 문화를 바꾸어야 합니다.
DevOps 및 애자일 방법론은 기존의 워터폴(waterfall) 소프트웨어 개발에 대한 비판에 맞서 등장했습니다. 비판의 주 내용은 혁신 속도를 늦추고 조직 내에 장벽과 병목을 만든다는 것이었습니다. 워터폴 시스템에서는 코드 요구 사항을 먼저 기능, 효율성, 표준화, 도큐멘테이션 측면에 대해 테스트한 다음 애플리케이션에 통합합니다. 이러한 사전 테스트 때문에 프로세스 대기열이 길어져서 프로젝트를 범위 내에서 기한과 예산에 맞춰 실행하기 어려운데, 불확실하거나 유동적인 프로젝트의 경우 더욱 어렵습니다.
한편 DevOps는 자동화와 주기적 프로세스를 사용하기 때문에, 개발 팀은 소프트웨어를 개발 단계에서 프로덕션 단계로 빠르게 이동하고 프로덕션 단계에서도 소프트웨어를 지속적으로 개선할 수 있습니다. DevOps는 전문 지식을 공유하도록 장려하는 관행을 통한 팀 간의 밀접한 소통과 협업을 필요로 합니다. 이러한 관행은 제품을 미리 개선하여 출시 속도를 늦추는 대신 반복 작업 내에 통합하여 개발하는 것을 의미합니다. DevOps를 구현하는 조직은 시간 흐름에 따라 소프트웨어를 체계적으로 개선할 수 있으므로 팀이 변화에 적응하고 새로운 방법을 시도할 수 있습니다. 기존 개발 모델에서는 그렇게 하기가 어렵습니다.
AI 시대의 플랫폼 엔지니어링 현황
플랫폼 엔지니어링이란?
플랫폼 엔지니어링은 DevOps 관행을 확장한 것으로, 표준화된 툴, 서비스, 워크플로우를 제공하여 개발 팀이 소프트웨어 솔루션을 더욱 효율적으로 빌드할 수 있도록 합니다. 플랫폼 엔지니어링은 내부 서비스와 리소스를 체계화하여 개발 팀이 그러한 기반 요소를 직접 관리할 필요 없이 솔루션을 빌드할 수 있도록 하는 관행을 의미하는 최신 용어입니다. 플랫폼 엔지니어는 개발 팀이 필요로 하는 다양한 툴, 서비스 및 도큐멘테이션을 선별하고 유지 관리함으로써 IT 조직의 모든 멤버가 최적의 경로인 자동화된 프로세스를 사용하여 모든 것을 직접 준비할 필요 없이 더욱 효율적으로 작업할 수 있도록 돕습니다. 플랫폼 엔지니어링은 DevOps가 더욱 널리 채택됨에 따라 성장했습니다. 플랫폼 엔지니어링은 DevOps 워크플로우를 지원하고 엔터프라이즈 조직에서 DevOps가 확장할 수 있도록 돕는 기반 구성 요소를 제공하기 때문입니다.
셀프 서비스 모델에서는 개발 팀이 일상적인 태스크를 처리하기 위해 수많은 기술을 직접 다뤄야 합니다. 적합한 툴셋을 찾아 헤매는 것은 번거롭고 효율성이 떨어지며 팀의 인지적 부담을 늘릴 수 있습니다. 새로운 멤버가 효율적으로 팀에 적응하기가 더 어려워지는 온보딩 문제도 발생합니다. 신규 채용자는 수많은 툴과 시스템 속에서 어려움을 겪고, 그들을 도와야 할 기존 팀원은 본연의 업무에 집중하지 못하게 되어 생산성이 떨어집니다. 플랫폼 엔지니어링은 이러한 부담을 완화하여 DevOps 워크플로우를 지원합니다. 즉, 플랫폼 엔지니어가 IT 조직을 위해 모범 사례와 셀프 서비스 경험을 중앙화하여 IT 조직이 혁신에 집중할 수 있도록 합니다.
플랫폼 엔지니어링의 무대 뒤 재생 시간: 2:31
플랫폼 엔지니어링과 DevOps의 장점
플랫폼 엔지니어링은 DevOps 팀이 모든 작업을 직접 수행할 필요를 없애서 DevOps의 확장을 돕습니다. 플랫폼 엔지니어링을 통해 조직 내 여러 개발 팀이 사용할 수 있는 일련의 표준화된 툴, 지식, 서비스 및 프로세스를 구축할 수 있습니다. 개발 팀은 엄선된 플랫폼을 사용하여 구성 요소를 빌드, 배포, 운영 및 지원하고, 플랫폼 팀은 플랫폼 구성 요소를 빌드, 배포, 운영 및 지원할 수 있습니다. 이 방식으로 두 팀이 본연의 업무에 집중하고 제공 속도를 높일 수 있습니다. 플랫폼 팀은 모든 것을 서비스로(X-as-a-service) 제공하므로 DevOps 팀은 모든 것을 즉석에서 빌드할 필요가 없습니다.
플랫폼 팀이 개발 팀을 위한 구성 요소를 제공하는 경우, 플랫폼 엔지니어링이 동일한 문제를 야기하고 DevOps에서 처음에 완화하려 한 내부 종속성이 발생할 것처럼 보일지도 모릅니다. 애플리케이션 팀이 플랫폼 팀으로부터 필요한 것을 제공받을 떄까지 기다리면 프로세스에 병목이 발생할까 걱정스럽죠.
이는 이론상으로는 가능하지만, 플랫폼 팀은 중복성과 이중의 수고를 줄여서 조직 전체에서 시간을 절감하는 데 도움을 줄 수 있습니다. 여러 개발 팀이 각자 동일한 기능을 하는 플랫폼을 자체적으로 빌드하는 대신, 하나의 셀프 서비스 플랫폼을 사용하는 것입니다. 이렇게 하면 시간이 흐름에 따라 일관성이 갖춰집니다. 기존 개발 팀이 현재 프로젝트에서 떠나는 경우에도 이러한 일관성을 유지할 수 있습니다. 또한 이러한 플랫폼 팀에 있어 개발 팀은 고객입니다. 플랫폼 팀이 타겟 사용자의 요구 사항을 충족하지 못하는 경우 해당 내부 고객은 다른 종류의 인프라나 배포 메커니즘을 사용할 것이기 때문에 빨리 제공하는 것이 좋습니다. 모범 사례와 검증된 솔루션으로 플랫폼에 기여할 수 있으며, 팀은 더 효과적으로 지식을 공유할 수 있습니다.
사이트 신뢰성 엔지니어링의 목적은?
사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)에 대해 알고 있다면 플랫폼 엔지니어링이 낯설지 않을 것입니다. SRE는 Google이 이전에는 시스템 관리자가 실행하던 수작업 대신 자동화로 제품을 실행하는 시스템을 설명하기 위해 새롭게 만든 용어입니다. SRE는 기본 인프라를 관리하며, SRE 팀은 인프라 무결성을 보장하고 가동 시간을 유지하기 위한 프로세스와 자동화를 개발합니다. SRE 실무자 및 플랫폼 엔지니어는 공통된 목표를 갖고 있지만, SRE는 소프트웨어의 성능, 신뢰성, 확장에 초점을 두는 반면 플랫폼 엔지니어링은 개발자 경험 향상을 목표로 하는 시스템에 초점을 맞춥니다.
플랫폼 엔지니어링 및 DevOps 활용 사례
팀은 일반적으로 플랫폼 엔지니어링을 사용하여 셀프 서비스 포털에서 자체 내부 개발 플랫폼(Internal Development Platform, IDP), 툴, 서비스 및 도큐멘테이션을 개발합니다. 플랫폼 엔지니어는 사용자 요구 사항과 모범 사례를 기반으로 IDP를 설계하고 제공할 수 있으며, 사용자 조사와 테스트를 통해 이를 반복해서 개선할 수 있습니다. 플랫폼 엔지니어는 개발 팀을 타겟 사용자로 하여 개발자 셀프 서비스를 지원하고 개발 팀의 인지적 부담을 줄이는 데 도움이 되는 IDP를 제공할 수 있습니다.
소프트웨어 개발 라이프사이클에서 지속적 통합 및 지속적 제공(Continuous Integration and Continuous Delivery, CI/CD)을 확립하려는 조직은 DevOps 관행을 채택해야 합니다. CI/CD는 코드 테스트 및 빌드를 자동화하여 소프트웨어 개발 및 업데이트 주기를 지속적으로 통합하므로 버그와 코드 오류의 영향을 최소화합니다. 조직은 소프트웨어 개발 라이프사이클 전반에서 CI/CD 파이프라인을 통합하고 자동화하여 고품질의 플랫폼을 빌드하고 애플리케이션을 더 빠르게 제공하는 데 필요한 가시성을 확보할 수 있습니다.
플랫폼 엔지니어링과 DevOps 역할의 차이
DevOps와 플랫폼 엔지니어링은 소프트웨어 개발과 배포를 최적화하기 위한 서로 다른 접근 방식이지만 상호 보완적입니다. 두 방식 모두 릴리스 속도를 높이고 시스템 안정성을 유지하는 것을 목표로 하지만 실행 방식에는 큰 차이가 있습니다. DevOps는 협업 문화이자 방법론입니다. 반면 플랫폼 엔지니어링은 이러한 문화를 조직 전체로 확장할 수 있도록 기반 툴을 구축하는 제품 중심의 전문 분야입니다.
이러한 에코시스템에서 DevOps 엔지니어는 개발 팀과 IT 운영 팀 사이에 존재해 온 전통적인 간극을 좁히는 데 주력합니다. 주요 업무는 CI/CD 파이프라인을 설계하고 유지 관리하여 빌드, 테스트, 배포 프로세스를 자동화하는 것입니다. 또한 환경 전반의 일관성을 유지하기 위해 서버를 수동으로 구성하는 대신 코드형 인프라(Infrastructure as Code)를 적극 활용하여 인프라와 플랫폼을 자동으로 프로비저닝합니다. 이 역할에서는 지속적인 개선을 중시하며, 배포 파이프라인의 장애물을 꾸준히 분석합니다. 또한 DevOps 엔지니어는 기능을 빠르게 릴리스하면서도 엄격한 시스템 가동 시간과 신뢰성 목표를 충족하기 위해 사이트 신뢰성 엔지니어와 긴밀하게 협업하는 경우가 많습니다.
플랫폼 엔지니어는 인프라를 하나의 제품이라는 관점에서 접근하며, 클라우드 환경이 갈수록 복잡해지는 가운데 소프트웨어 개발자의 인지 부하를 줄이는 것을 목표로 합니다. 플랫폼 엔지니어의 주요 업무는 개발자가 환경, 데이터베이스, 파이프라인을 독립적으로 프로비저닝할 수 있는 셀프 서비스 포털 역할의 내부 개발자 플랫폼(IDP)을 구축하고 유지 관리하는 것입니다. 이 과정에서 시스템 액세스 제어와 보안 컴플라이언스를 표준화하여 플랫폼 템플릿에 적용합니다. 플랫폼 엔지니어는 상위 수준의 청사진을 재사용 가능한 최적의 경로로 구현하여 클라우드 네트워킹과 컨테이너 오케스트레이션의 복잡성을 추상화합니다. 이를 통해 개발자는 애플리케이션 코드 작성에만 집중할 수 있습니다.
보안, 컴플라이언스 및 리스크 관리
엔터프라이즈 환경에서는 보안과 컴플라이언스를 일상적인 배포 방식에 직접 통합해야 합니다. 기존 DevOps 모델은 개발 단계에서 자동화된 테스트와 지속적 통합을 통해 보안 문제를 해결하는 '시프트 레프트'(shift left) 철학을 강조하지만, 이로 인해 개발자의 인지 부하가 크게 늘어날 수 있습니다. 이러한 부담을 완화하기 위해 플랫폼 엔지니어링에서는 처음부터 규정을 준수하고 안전한 플랫폼을 설계할 수 있습니다.
플랫폼 엔지니어링은 보안 및 컴플라이언스 정책을 자동화 툴과 표준화된 CI/CD 방식에 통합하여 규제 복잡성을 추상화합니다. 이러한 접근 방식을 통해 개발자는 컴플라이언스 전문가가 아니어도 안전하고 확장 가능한 인프라를 기반으로 빌드할 수 있습니다.
또한 클라우드 플랫폼 전반에서 강력한 리스크 관리를 통합하려면 코드형 인프라와 컨테이너화에 대한 일관된 접근 방식이 필요합니다. DevOps 팀은 이러한 방법론을 활용해 소프트웨어 제공 속도를 높이고, 플랫폼 엔지니어는 거버넌스가 적용된 기본 시스템을 유지 관리합니다. 이러한 협업을 통해 조직의 요구 사항에서 벗어나는 드리프트를 즉시 감지할 수 있습니다. 조직은 확장 가능하고 안전한 시스템을 구축하는 책임을 중앙화된 플랫폼 전략으로 전환함으로써, 규제 및 운영 리스크에 대한 대응 수준을 유지하면서 릴리스 속도를 높일 수 있습니다.
Red Hat의 지원
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®를 함께 사용하여 온프레미스, 클라우드, 엣지 등 배포 위치에 상관없이 클라우드 네이티브, 레거시 및 현대화된 애플리케이션 등 다양한 애플리케이션을 작업할 때 원하는 툴을 사용할 수 있습니다.
