DevOps 메트릭 접근 방식

DevOps 메트릭은 소프트웨어 개발 및 IT 운영과 관련된 DevOps 사례의 효율성을 트래킹합니다. DevOps는 더욱 빠르고 신뢰할 수 있으며 안정적으로 소프트웨어를 제공하는 것을 목표로 합니다. 셀프 서비스 툴, 자동화, 커뮤니케이션을 우선시하는 동시에 개발자의 생산성과 만족도를 강조합니다.

DevOps에 투자했다면 그 성과를 모니터링하는 일관된 메트릭 세트가 필요할 것입니다. 선호하는 접근 방식은 조직에서 중요하게 여기는 것에 따라 달라집니다. 소프트웨어 결과물이나 팀의 상태를 측정하고 싶으신가요? 이 문서에서는 가장 많이 사용되는 두 가지 프레임워크, 즉 DORA(소프트웨어 중심)와 SPACE(팀 중심)를 살펴봅니다.

DevOps는 지속적으로 개선하는 문화를 중심으로 운영됩니다. 개선하려는 사항과 이를 측정하는 방법을 결정하는 것은 중요한 전략 단계입니다. DevOps 메트릭에서 영향력 있는 두 가지 프레임워크는 DORA와 SPACE입니다. 

DevOps의 기본 목표는 제대로 작동하는 소프트웨어의 릴리스 속도를 높이는 것이므로, 이 목표와 관련된 측정을 최우선으로 둘 수 있습니다. 이런 경우에 맞는 메트릭은 DORA(연구 및 평가를 의미하는 DevOps research and assessment의 약자)입니다.

그러나 제대로 작동하는 소프트웨어를 얼마나 많이 제공하는지가 DevOps의 전부는 아닙니다. 팀의 만족도 및 협업과 같은 특성에 중점을 둘 수도 있습니다. SPACE(만족, 성과, 작업 활동, 커뮤니케이션, 협업, 효율성을 의미하는 satisfaction, performance, activity, communication and collaboration, efficiency의 약자)는 팀 관련 메트릭을 강조합니다.

이렇듯 서로 다른 DevOps 측정 접근 방식은 무엇을 측정해야 하는지에 관한 서로 다른 철학을 반영합니다. 하지만 둘 중 하나만 선택할 필요는 없습니다. 두 프레임워크는 보완되며 DevOps 목표의 서로 다른 부분을 측정할 수 있습니다. 

DORA

DORA 메트릭은 Google Cloud가 지원하는 DORA 리서치 프로그램에서 나왔습니다. 2020년, DORA 프로그램은 소프트웨어 개발 팀의 성과를 측정하는 '4대 주요 메트릭'을 제시했습니다.

• 배포 빈도: 조직이 소프트웨어를 프로덕션으로 성공적으로 릴리스하는 빈도입니다. 이 요소를 측정하려면 먼저, 팀이 성공적인 배포가 무엇인지를 정의해야 합니다. 이 정의가 결정되면 예를 들어 한 건 이상을 성공적으로 배포한 주당 일 수의 중앙값 등을 계산할 수 있습니다.
• 변경 리드 타임: 커밋이 프로덕션에 반영될 때까지 걸리는 시간입니다. 이 요소를 측정하려면 커밋 발생 시점과 배포 발생 시점을 트래킹해야 합니다.
• 변경 실패율: 프로덕션에서 장애를 일으킨 배포의 비율입니다. 이 값을 계산하려면 배포한 건수와 문제 관리 시스템 등에 보고된 버그 또는 인시던트 수를 알아야 합니다.
• 서비스 복원 시간: 프로덕션의 장애 복구에 걸리는 시간입니다. 각 인시던트가 발생한 날짜와 해결된 날짜를 트래킹해야 하며, 이는 인시던트 관리 시스템에서 풀링할 수 있습니다.

이듬해, 5번째 주요 메트릭을 추가했습니다.

• 신뢰성: 가용성, 대기 시간, 성능, 확장성을 포괄합니다. DORA 프레임워크는 조직이 신뢰성 목표 이상을 달성하는 능력을 측정합니다.

이 리서치 및 메트릭 세트가 중점을 두는 것은 비즈니스 성과를 향상시키는 것입니다. 팀은 소프트웨어 파이프라인의 데이터를 대시보드로 풀링하여 시간 경과에 따른 전개 상황을 모니터링하는 방법으로 소프트웨어 성능을 트래킹할 수 있습니다. DORA 프레임워크는 또한 각 메트릭의 수준을 바탕으로 성능 등급을 부여합니다(엘리트, 높음, 중간, 낮음).

DORA 프레임워크의 주요 장점은 소프트웨어 팀이 기존에 사용하고 있는 GitHub, GitLab 및 인시던트 관리 시스템과 같은 툴에서 바로 얻을 수 있는 측정값에 기반한다는 것입니다. 메트릭을 대시보드로 풀링하는 단계를 거쳐야 하지만, 데이터는 바로 구할 수 있습니다.

SPACE

DevOps 메트릭용 SPACE 프레임워크는 생산성을 다양한 차원에서 포착합니다. 리서치 팀은 SPACE를 2021년 문서에서 소개했습니다. 문서에서는 엔지니어링 작업이 매우 복잡해서 단일 차원 또는 메트릭으로 포착할 수 없다고 주장합니다. 소프트웨어 개발에는 절충점이 요구되며, 팀에 필요한 것은 더 많은 작업 요소를 아우르는 종합적인 접근 방식입니다.

SPACE 프레임워크는 5가지 측면에서 측정합니다.

• 만족도 및 건강: 개발자들이 자신의 일에 대해 어떻게 느끼는지, 신체적, 정신적 건강은 어떤지 등을 측정합니다. 직원 만족도 관련 설문조사를 통해 개발자가 필요한 툴 및 리소스에 액세스할 수 있는지, 직장 스트레스로 인한 번아웃은 어느 정도인지와 같은 데이터를 수집해야 할 수 있습니다.
• 성과: 시스템 또는 프로세스의 성과(결과물과 구별됨)입니다. 여기에는 단순히 코드의 양이나 코드가 비즈니스에 미치는 영향 이상의 의미가 있습니다. 코드의 신뢰성 또는 지속적인 서비스 상태와 같은 품질 측면뿐만 아니라 고객 만족도 또는 고객 채택 및 유지와 같은 영향 측면에서도 성과를 측정합니다.
• 작업 활동: 작업 수행 과정에서 완료한 작업 또는 결과물을 트래킹합니다. 개발자 활동 수준을 커밋의 양이나 릴리스 건수와 같은 다양한 방식으로 포착할 수 있지만, SPACE 프레임워크는 이러한 방식을 별개로 사용하지 말 것을 강조합니다.
• 커뮤니케이션 및 협업: 작업자 및 팀이 정보를 공유하고 협력하는 방식을 포착합니다. 커뮤니케이션, 협업, 공동 작업을 측정하는 데 도움이 되는 메트릭에는 도큐멘테이션 및 전문성 검색, 작업 통합 속도, 작업 리뷰 품질, 누가 연결되어 있는지 보여주는 네트워크 메트릭, 신규 팀원 온보딩 시간이 포함됩니다.
• 효율성 및 흐름: 중단 또는 지연이 거의 없이 작업을 완료하거나 진척시킬 수 있는 능력을 측정합니다. SPACE는 프로세스 내의 인수인계 횟수, 작업 흐름을 유지하고 작업을 완료할 수 있다는 작업자 스스로의 느낌, 중단, 시스템을 통한 시간 측정과 같은 메트릭을 통해 효율성 및 흐름을 측정할 것을 제안합니다.

각 SPACE 메트릭을 개인, 팀 또는 시스템 수준에서 측정 및 트래킹할 수 있습니다.

SPACE 프레임워크는 DevOps에 대한 팀의 사고방식을 확장하려고 합니다. 다시 말해서 원시 결과값을 측정하는 데서 벗어나 종합적인 시각에서 생산성을 측정하는 것입니다. 그러려면 설문조사를 통해 개발자 만족도 수준과 같이 기존이 없던 메트릭을 수집하는 등의 새로운 프로세스를 만들어야 할 수도 있습니다.

DevOps 메트릭은 고유한 우선순위를 반영하고 실제 측정 가능한 데이터에 기반한 것으로 선택해야 합니다. DevOps 성공을 측정하는 메트릭 중 일부는 DORA 프레임워크의 경우처럼, 제공되는 소프트웨어의 속도 및 품질을 비롯한 결과물에 중점을 둘 수 있습니다. 또는 SPACE 프레임워크의 경우처럼, 소프트웨어 개발자가 더 높은 생산성을 위해 취해야 하는 복잡한 절충점에 초점을 둘 수도 있습니다.

무엇을 측정할지 선택할 때 다음 사항을 자문해 보면 도움이 됩니다.

• 조직의 목표는 무엇인가요? 목표는 속도에 중점을 둘 수도 있고 신뢰성 및 복원력에 중점을 둘 수도 있습니다. 아니면 개발자 만족도, 협업 용이성, 효율성을 포함한 종합적인 개발자 경험에 더 주목할 수도 있습니다.
• 어떤 데이터를 수집할 수 있나요? 지속적 통합 및 지속적 배포(CI/CD) 파이프라인은 소프트웨어 변경 사항이 어떻게 전달되는지에 관한 데이터를 얻을 수 있는 최상의 소스일 수 있습니다. 하지만 정성적 데이터를 수집하기 위해 설문조사 방식을 채택해야 할 수도 있습니다.
• 자동화 및 커뮤니케이션 시스템이 효과적으로 작동하고 있나요? DevOps 메트릭을 포착하려면 장애물, 팀 간의 커뮤니케이션, 의사 결정이 이루어지는 방법을 확인할 수 있어야 합니다. DevOps 시스템이 의도대로 작동하는 것이 우선되어야만 측정할 요소에 관한 신뢰할 수 있는 데이터를 얻을 수 있습니다.

DevOps는 플랫폼 엔지니어링과 관련이 있으며, 플랫폼 엔지니어링은 DevOps 워크플로우를 지원하는 내부 플랫폼 및 툴을 다룹니다. DevOps 성과를 평가하는 메트릭 중 일부는 플랫폼 엔지니어링 툴에서 가져옵니다. 개발자 경험, 즉 DevEx라는 분야 또한 DevOps 메트릭에 반영됩니다. 

플랫폼 엔지니어링은 개발 팀에게 주어지는 부담을 완화하여 개발자 경험을 향상하고자 합니다. 그 일환으로, 개발자를 위한 재사용 가능한 일반적인 툴과 기능을 설정하는 내부 개발자 플랫폼(IDP)을 제공합니다. 플랫폼 엔지니어는 조직 표준에 따라 소프트웨어를 구축 및 배포할 수 있도록 잘 문서화된 지원 방식인 골든 경로를 설계 및 유지 관리합니다.

IDP, 골든 경로 및 다른 관련 아티팩트를 정의하는 선택들은 DevOps 메트릭과 관련이 매우 높습니다. 효율적인 DevOps를 위한 프로세스를 수립하는 과정에서 중요한 요소 및 현실적으로 측정할 수 있는 요소를 설정합니다. 예를 들어 CI/CD 파이프라인은 소프트웨어 커밋과 릴리스를 확인할 수 있는 소스입니다.

Red Hat은 DevOps 생산성을 측정하는 데 도움을 줄 수 있는 플랫폼, 툴, 컨설팅 서비스를 제공합니다.

Red Hat OpenShift

애플리케이션을 실행하는 플랫폼은 DevOps 메트릭 전략의 성공에 영향을 미칩니다. Red Hat® OpenShift®는 클라우드, 온프레미스 및 엣지 환경에서 일관된 플랫폼을 제공합니다. Red Hat OpenShift GitOps 및 Red Hat OpenShift Pipelines 오퍼레이터를 통해 CI/CD 워크플로우를 지원합니다. 또한 Red Hat OpenShift 관측성을 통해 애플리케이션의 성능 및 상태를 확인할 수 있습니다.

Red Hat Advanced Developer Suite

Red Hat Advanced Developer Suite는 생산성 향상에 중점을 두는 DevOps의 목적에 맞춰 개발자 생산성 가속화, 소프트웨어 공급망 보안 강화, AI 기반 개발 지원 등을 위한 핵심 구성 요소를 제공함으로써 Red Hat OpenShift 기능을 확장합니다.

Red Hat Developer Hub

Red Hat Advanced Developer Suite에 포함된 Red Hat Developer Hub는 내부 개발자 포털입니다. 서비스 카탈로그와 도큐멘테이션부터 CI/CD 파이프라인에 이르는 개발자 툴링 및 서비스를 탐색 가능한 단일 허브에 통합해 한곳에서 시각적으로 확인할 수 있도록 제공함으로써 개발 경험과 조직 생산성을 크게 개선합니다.

Red Hat Consulting

Red Hat Consulting의 기술 전문가는 핸즈온 협업을 통해 DevOps 프로그램을 지원할 수 있습니다. 컨설턴트는 서비스 청사진 및 메트릭 기반 프로세스 매핑(MBPM)과 같은 기술을 활용해 워크플로우를 더 잘 이해하고 측정하도록 지원할 수 있습니다.