## 소개글 > [!abstract] Introduction > 소프트웨어 프로젝트에서 "측정할 수 없으면 개선할 수 없다"는 말은 단순한 격언이 아니라 프로세스 개선의 출발점입니다. 측정과 분석*Measurement and Analysis*은 [[Capability Maturity Model Integration|CMMI]]의 지원 프로세스 영역 중 하나로, 프로젝트의 현재 상태를 정량적으로 파악하고 근거 있는 의사결정을 내릴 수 있도록 돕는 역할을 합니다. 이 글에서는 측정지표의 개념과 GQM 기법, 제품·프로세스 메트릭, DORA 메트릭, 그리고 CMMI MA 프로세스 영역의 여덟 가지 실천사항을 살펴봅니다. # Metric 측정지표*Metric*란, 시스템 컴포넌트, 프로세스가 특정 속성을 보유한 정도를 나타내는 정량적인 측정변수다. > [!info] Definition > Quantitive measure of the degree to which a system, component, or process possesses a given attribute (ISO/IEC/IEEE 24765:2017) 예를 들어, 자동차를 구입하고자 한다면 엔진의 성능이 좋은지, 경제성이 좋은지를 따져볼 텐데, 이를 정량적인 지표로 평가하기 위해 필요한 것이 바로 제로백이나 연비와 같은 측정지표다. 이러한 메트릭을 만들기 위해서는 주행 거리, 주행 시간, 소모한 연료 등의 데이터를 수집해야 한다. ## Goal-Question-Metric 그런데 사용자가 어떤 제품이 좋은지 안좋은지 파악할 수 있는 측정지표를 만들기 위해서는 어떻게 해야 할까? 이러한 고민 속에서 탄생한 것이 바로 목적*Goal*-질문*Question*-측정지표*Metric* 기법, 줄여서 GQM 기법이라 불리는 측정지표 도출 방법이다. 목적을 정하고 그 목적에 맞는 질문을 던진 뒤 질문에 대답할 수 있는 측정지표를 만들어가는 과정이 아래 그래프에 나와 있다. ![[GqmGoalQuestionMetric.png]] # 측정 그렇다면 측정은 왜 하는 것일까? 측정할 수 없으면 통제할 수 없고, 측정할 수 없으면 개선할 수 없다. 측정의 역할은 이해*Understand*, 평가*Evaluate*, 통제*Control*, 예측*Predict*으로 정리할 수 있다. - 이해: 정보를 수집하여 필요한 시간, 비용, 자원 할당, 오류, 생산성에 대해 이해할 수 있다. - 평가: 의사결정 절차에서 측정 결과를 사용할 수 있으며, 기준점을 세우고 후에 설정된 표준, 목표, 인수 기준에 만족하는지 판단할 수 있다. - 통제: 자원, 프로세스, 제품, 서비스에 대한 관리를 할 때 사용한다. - 예측: 예산, 일정 계획, 인력 배치, 자원, 위험, 품질, 신뢰성 등 미래의 속성에 대한 가치를 예측하는데 사용될 수 있다. ## 품질 측정 앞서 측정을 위해서 측정지표를 만드는 과정을 확인했다. 그렇다면 제품의 품질이라는 정성적인 것처럼 보이는 개념도 측정할 수 있을 것이다. 제품의 품질은 프로세스의 품질로부터 나오며, 제품과 프로세스 모두 각자의 측정지표가 있다. 전체적인 관계는 아래와 같다. ![[ProductAndProcessQuality.png]] ### 제품 메트릭 제품 메트릭은 개발 중인 또는 완성된 제품의 특징을 측정한 측정지표다. 크게 내적/정적 속성과 외적/행위 속성으로 나눌 수 있는데, 내적/정적 속성으로는 규모, 유지보수성, 정적분석이나 리뷰를 통해 발견한 결함 등이 있고 외적/행위 속성으로는 유지보수성, 테스트 결함, 성능, 신뢰성, 가용성, 사용성 등이 있다. #### 규모 규모*Size*는 소스코드 라인 수, 기능 점수, 클래스의 수, 요구사항의 수, 테스트 케이스의 수, Story Point 등 여러가지 데이터로 측정할 수 있다. ##### Lines of Code 소스코드 라인 수는 통상 실행가능한 코드를 측정하여 산정하며 목적에 따라 주석을 포함하기도 한다. 워낙 큰 스케일을 다루어야 하기 때문에 1000 LOC는 1 KLOC라고 부른다. 가장 일반적으로 사용되는 규모 추정 메트릭이며 개발 대가 산정, 제품 특징 정의, 결함 밀도[^1] 등에 활용된다. 이때 어떤 프로그래밍 언어를 사용하는지에 따라 차이가 큰 것을 고려해야 한다. 여러 프로그래밍 언어를 사용하는 시스템의 경우 규모 산정이 어려우며, 개발 생명주기 초기에는 예측이 어렵다. ##### Function Point 기능 점수는 사용자 관점에서 시스템이 제공하는 논리적 기능의 규모를 측정하는 측정지표다. 트랜잭션 기능과 데이터 기능으로 구분하여 측정하며 프로젝트 초반에 요구사항을 기반으로 추정할 수 있다, 다만 측정을 위해 구체적인 요구사항 자료가 필요하며, 복잡도 계산이 주관적이라는 한계를 가지고 있어서 정보 시스템에는 적합하나 임베디드 소프트웨어나 서버 프로그램 등에는 적용하기 어렵다. #### 유지보수성 유지보수성*Maintainability* 안에는 모듈성*Modularity*라는 특성이 있는데, 그 안에는 코드 복잡도*Cyclomatic Complexity*, 컴포넌트 내 응집도*Cohesion*, 컴포넌트 간 결합도*Coupling*이 있다. 특히 결합도에는 전역변수, 현재 있는 곳에서 호출하는 모듈의 수*fan-out*, 현재 있는 모듈을 호출하는 모듈의 수*fan-in* 등의 변수가 고려된다. ##### 코드 복잡도 사이클로매틱 복잡도는 모듈의 시작과 끝을 잇는 직선적인 독립 경로를 측정한다. 완벽한 커버리지를 위해 꼭 실행되어야 하는 최소의 경로 시험을 결정하기 위한 구조기반 테스트에 이용되며, 설계 단계에서 정량적으로 수치화가 가능하다는 장점이 있지만 데이터 복잡성을 표현하지 못하는 단점이 존재한다. 그래프로 구성되기 때문에 계산은 그래프 이론을 활용하여 이루어진다. #### 결함 결함은 분포와 밀도가 있는데, 결함 분포의 경우 결함 유형, 심각도, 비즈니스 중요도라는 메트릭을 가지고 있으며, 결함 밀도에는 결함 수 / KLOC, 결함 수 / FP, 요구사항 결함 수 / 요구사항 수라는 메트릭이 있다. ##### 시장 결함 시장 결함*Post-release Defect*은 소프트웨어가 사용자에게 전달되었을 때 이미 존재하거나 앞으로 발생할 가능성이 있는 결함을 일컫는 말이다. 사용 3개월 이내에 발견되는 비율은 약 20%~40% 수준이며 군용 소프트웨어, 임베디드 소프트웨어, 정보 소프트웨어 순으로 발견될 확률이 높다. ## 프로세스 메트릭 프로세스 메트릭은 프로세스의 효율성/효과성을 측정하고 개선하기 위하여 활용되며, 데이터 축적 및 분석을 통하여 프로세스 성과 및 제품 품질을 예측할 수 있다. - 프로젝트 관리 활동 측면 - 견적 정확성 (규모, 비용, 일정, 자원 등의 추정 대비 실제의 차이) - 프로젝트 진척율 - 납기 준수율 - 개발 활동 측면 - Bad fix Rate - 개발자 대비 테스트팀 결함 발견 비중 - 결함 제거 활동 측면 - 조기 결함 발견율 - 결함 해결율 - 결함 해결 사이클 타임 - 테스트 자동화율 ## DORA Metrics 프로세스 메트릭 중에서도 소프트웨어 전달 성과를 측정하는 대표적인 프레임워크가 바로 DORA*DevOps Research and Assessment* 메트릭이다. DORA 메트릭은 Forsgren, Humble, Kim이 2014년부터 수행한 대규모 연구에서 도출된 네 가지 핵심 성과 지표로, 처리량*Throughput*과 안정성*Stability*이라는 두 축으로 구성된다. ![[TheDORAMetrics.png]] 처리량 측면에서는 배포 빈도*Deployment Frequency*와 변경 리드 타임*Lead Time for Changes*을, 안정성 측면에서는 평균 복구 시간*Mean Time to Recover*과 변경 실패율*Change Failure Rate*을 측정한다. 이 네 가지 메트릭이 핵심적인 이유는 속도와 안정성이 상충 관계가 아니라는 것을 실증적으로 보여주기 때문이다. 엘리트 수준의 조직은 높은 배포 빈도와 낮은 변경 실패율을 동시에 달성한다. ### 배포 빈도 배포 빈도*Deployment Frequency*는 완성된 코드가 프로덕션 환경에 배포되는 평균 횟수를 의미한다. $\text{Deployment Frequency} = \frac{\text{배포 횟수}}{\text{기간(일)}}$ ![[DeploymentFrequency.png]] 위 그림에서 볼 수 있듯이, 코드가 백로그에서 개발, 프리프로덕션, 프로덕션으로 이동하는 과정에서 프리프로덕션에서 프로덕션으로의 전환 빈도가 곧 배포 빈도다. 이상적인 상태는 코드 커밋 빈도와 배포 빈도가 일치하는 것이다. ![[DeploymentFrequencyMatchingCodeCommitFrequency.png]] 코드 커밋 빈도와 배포 빈도가 일치한다는 것은 개발 단계에서 프리프로덕션으로 넘어가는 속도(일 15회)가 그대로 프로덕션 배포 속도(일 15회)로 이어진다는 뜻이다. 이를 가능하게 하는 것이 자동화된 CI/CD 파이프라인과 작은 배치 크기다. 작은 단위로 자주 배포하면 각 배포의 위험도가 낮아지고, 문제가 발생했을 때 원인을 빠르게 특정할 수 있다. ### 변경 리드 타임 변경 리드 타임*Lead Time for Changes*은 코드 변경이 버전 관리 시스템에 커밋된 시점부터 프로덕션 환경에 성공적으로 배포되기까지 걸리는 시간이다. $\text{Lead Time for Changes} = \text{배포 시각} - \text{커밋 시각}$ ![[TheLeadTimeForChanges.png]] 변경 리드 타임은 파이프라인의 효율성을 직접적으로 반영한다. 자동화된 테스트, 코드 리뷰, 배포 프로세스가 잘 갖추어진 조직은 리드 타임이 수 시간 이내인 반면, 수동 테스트와 승인 절차에 의존하는 조직은 수 일에서 수 주가 걸리기도 한다. ### 평균 복구 시간 평균 복구 시간*Mean Time to Recover, MTTR*은 프로덕션 환경에서 장애가 발생한 시점부터 서비스가 정상으로 복구되기까지 걸리는 평균 시간이다. $\text{MTTR} = \frac{\sum \text{각 장애의 복구 시간}}{\text{장애 횟수}}$ ![[TheMeanTimeToRecoverWithCodeChangesRequired.png]] 위 그림은 코드 변경이 필요한 장애 복구 과정을 보여준다. 장애가 감지*Issue detected*되면 수정 방안을 식별*Fix identified*하고, 수정 코드를 개발*Fix developed*한 뒤 프로덕션에 적용*Fix applied in production*한다. 여기서 핵심적인 사실은 수정 코드를 프로덕션에 배포하는 과정이 곧 변경 리드 타임이라는 점이다. ![[TheMeanTimeToRecoverIncludingLeadTimeForChanges.png]] 즉, MTTR은 장애 감지 및 진단 시간에 변경 리드 타임을 더한 것이다. 변경 리드 타임이 짧은 조직은 수정 코드를 빠르게 프로덕션에 반영할 수 있으므로 MTTR도 자연스럽게 짧아진다. 반대로 리드 타임이 긴 조직은 수정 코드를 빠르게 작성하더라도 배포까지의 지연으로 인해 MTTR이 길어질 수밖에 없다. ### 변경 실패율 변경 실패율*Change Failure Rate*은 프로덕션 배포 중에서 즉각적인 조치(핫픽스, 롤백 등)가 필요한 배포의 비율이다. $\text{Change Failure Rate} = \frac{\text{실패한 배포 횟수}}{\text{전체 배포 횟수}} \times 100\%$ ![[TheChangeFailureRate.png]] 위 그림에서 볼 수 있듯이, 개발 단계를 거쳐 프리프로덕션과 프로덕션으로 이동하는 과정에서 일부 배포는 성공(✔)하고 일부는 실패(✘)한다. 변경 실패율은 프로덕션에 도달한 배포 중 실패한 비율을 측정한다. ![[TheChangeFailureRateBeforeAndAfterContinuousDeployment.png]] 배치 크기가 변경 실패율에 미치는 영향은 극적이다. 왼쪽의 배치 배포 방식에서는 10개의 커밋을 3번의 대규모 배포로 묶어 배포하는데, 이 경우 변경 실패율이 66%에 달한다. 반면 오른쪽의 지속적 배포 방식에서는 각 커밋을 개별적으로 배포하여 변경 실패율이 33%로 낮아진다. 작은 단위의 배포는 변경 범위가 좁아 실패 확률이 낮고, 실패하더라도 원인 파악과 복구가 빠르다. ### Shift-Left 원칙 DORA 메트릭의 네 가지 지표를 동시에 개선하는 핵심 전략이 Shift-Left 원칙이다. 품질 검증 활동을 개발 생명주기의 왼쪽(초기 단계)으로 당기는 것을 의미한다. ![[TheShiftLeftPrincipleFromDifferentPerspectives.png]] 위 그림은 Shift-Left를 두 가지 관점에서 보여준다. 팀 워크플로우 관점에서는 QA와 Sign-off 단계를 Doing 단계 쪽으로 당기는 것이고, 프로덕션 경로 관점에서는 테스트와 검증 활동을 개발자의 로컬 환경과 빌드 단계에서 수행하는 것이다. 개발 초기에 결함을 발견하면 수정 비용이 10~100배 저렴하며[^2], 빠른 피드백 루프가 개발자의 학습 속도를 높인다. 결과적으로 변경 리드 타임이 단축되고 배포 빈도가 높아지며, 작은 배치 크기로 인해 변경 실패율이 낮아지고 MTTR도 짧아지는 선순환 구조가 만들어진다. # Measurement and Analysis 지금까지 살펴본 측정지표, GQM 기법, 측정의 역할, 제품 메트릭, 프로세스 메트릭, 그리고 DORA 메트릭은 모두 측정과 분석이라는 큰 틀 안에서 동작한다. [[Capability Maturity Model Integration|CMMI]]에서는 측정과 분석*Measurement and Analysis, MA*을 독립적인 지원 프로세스 영역으로 정의하고 있으며, 이 프로세스 영역의 목적은 관리 정보 요구를 뒷받침하는 측정 역량을 개발하고 유지하는 것이다. MA는 두 가지 구체적 목표*Specific Goal*와 여덟 가지 구체적 실천사항*Specific Practice*으로 구성된다. ![[MeasurementAndAnalysisDiagram.png]] 위 다이어그램에서 보이듯이, 왼쪽의 이해관계자로부터 정보 요구*Information Needs*가 들어오면 SG1의 네 가지 실천사항(SP 1.1~SP 1.4)이 측정 목표*Measurement Objectives*를 수립하고 측정 저장소*Measurement Repository*와 연결한다. 이어서 SG2의 네 가지 실천사항(SP 2.1~SP 2.4)이 데이터를 수집·분석하여 측정 결과*Measurement Results*를 도출하고 오른쪽의 이해관계자에게 전달한다. ## SG1: Align Measurement and Analysis Activities 첫 번째 구체적 목표는 측정 활동을 정보 요구 및 목표와 정렬하는 것이다. 무엇을 왜 측정하는지, 어떻게 수집하고 어떻게 분석할지를 사전에 정의하는 단계로, 측정의 기반을 다지는 과정이다. ### SP 1.1: Establish Measurement Objectives 측정 목표 수립*Establish Measurement Objectives*은 식별된 정보 요구로부터 측정 목표를 도출하고 유지하는 활동이다. 이해관계자(경영층, 프로젝트 팀, 고객)의 정보 요구를 파악한 뒤, 이를 구체적이고 달성 가능한 측정 목표로 변환한다. 예를 들어, 경영층이 "제품의 품질 수준을 파악하고 싶다"는 정보 요구를 제시했다면, 이를 "출시 후 3개월 이내 결함 밀도를 0.5 defects/KLOC 이하로 유지한다"와 같은 정량적 목표로 구체화하는 것이 이 단계의 핵심이다. 앞서 다룬 [[Measurement and Analysis#Goal-Question-Metric|GQM 기법]]이 바로 이 단계에서 활용될 수 있다. 목적에서 출발하여 질문을 던지고, 질문에 답할 수 있는 측정지표를 도출하는 체계적인 접근을 제공하기 때문이다. ### SP 1.2: Specify Measures 측정지표 명세*Specify Measures*는 측정 목표를 달성하기 위한 구체적인 측정지표를 정의하는 활동이다. 각 측정지표의 단위, 데이터 유형, 수집 시점을 결정하고, 조작적 정의[^3]를 문서화한다. "결함 밀도 0.5 defects/KLOC 이하"라는 목표가 수립되었다면, 이 단계에서는 결함의 수를 어떻게 셀 것인지(결함 유형별 포함 범위), KLOC를 어떻게 산정할 것인지(주석 포함 여부, 프로그래밍 언어별 보정), 결함의 심각도 분류 기준은 무엇인지 등을 명확하게 정의한다. 앞서 살펴본 [[Measurement and Analysis#제품 메트릭|제품 메트릭]]과 [[Measurement and Analysis#프로세스 메트릭|프로세스 메트릭]]이 이 단계에서 구체적으로 명세되는 것이다. ### SP 1.3: Specify Data Collection and Storage Procedures 데이터 수집 및 저장 절차 명세*Specify Data Collection and Storage Procedures*는 데이터를 체계적으로 수집하고 무결성을 유지하며 저장하는 방법을 정의하는 활동이다. 데이터 출처(자동화 도구, 수동 입력, 외부 시스템), 수집 빈도, 검증 규칙, 저장 메커니즘, 접근 제어, 보존 정책 등을 결정한다. 예를 들어, 결함 데이터는 이슈 트래킹 시스템(Jira 등)에서 자동으로 수집하고, 코드 규모 데이터는 `Git` 훅을 통해 커밋 시점에 자동 집계하며, 수집된 데이터는 중앙 측정 저장소에 월별 스냅샷으로 보관하는 식이다. 데이터의 정확성과 일관성을 검증하기 위해 교차 검증 절차도 함께 정의한다. ### SP 1.4: Specify Analysis Procedures 분석 절차 명세*Specify Analysis Procedures*는 수집된 데이터를 어떻게 분석하고 해석할지, 그리고 그 결과를 어떻게 의사결정에 활용할지를 정의하는 활동이다. 분석 방법(통계 분석, 추세 분석, 비교 분석), 분석 일정, 이상치 처리 방법, 의사결정 임계값 등을 사전에 결정한다. 결함 밀도 데이터를 예로 들면, 관리도*control chart*를 활용한 월별 추세 분석을 수행하고, 상한 관리 한계를 초과하면 근본 원인 분석을 시작하며, 분기별로 기준선 대비 성과를 비교 평가한다는 식으로 분석 절차를 구체화한다. ## SG2: Provide Measurement Results 두 번째 구체적 목표는 식별된 정보 요구와 목표를 달성하기 위한 측정 결과를 제공하는 것이다. SG1에서 정의한 계획에 따라 실제로 데이터를 수집하고, 분석하고, 저장하고, 전달하는 실행 단계다. ### SP 2.1: Obtain Measurement Data 측정 데이터 획득*Obtain Measurement Data*은 정의된 절차에 따라 데이터를 실제로 수집하고, 완전성과 무결성을 검증하는 활동이다. 모든 예상 데이터 포인트가 수집되었는지 확인하고, 누락되거나 의심스러운 데이터를 식별하여 문서화한다. 주간 데이터 수집 체크리스트를 운영하여 코드 저장소 메트릭의 최신 여부를 확인하고, 빌드 및 배포 로그의 완전성을 검증하며, 결함 추적 시스템의 항목을 교차 참조하는 식으로 데이터 품질을 보장한다. 시스템 다운타임이나 프로세스 변경 등 데이터 이상의 원인이 될 수 있는 사건도 함께 기록한다. ### SP 2.2: Analyze Measurement Data 측정 데이터 분석*Analyze Measurement Data*은 계획된 대로 데이터를 분석하고, 필요에 따라 추가 분석을 수행하며, 관련 이해관계자와 결과를 검토하는 활동이다. 원시 데이터를 의사결정에 활용할 수 있는 통찰로 변환하는 핵심 단계다. 측정지표를 계산하고, 통계 분석(추세, 분산, 상관관계)을 수행하며, 기준선 및 목표 대비 비교 분석을 진행한다. 패턴과 이상치를 식별하고 근본 원인을 파악하여 개선 권고 사항을 도출한다. 예를 들어, "배포 빈도가 지난 분기 대비 40% 증가했으며, 이는 CI/CD 파이프라인 도입의 효과로 분석된다"와 같은 형태의 인사이트를 만들어낸다. ### SP 2.3: Store Data and Results 데이터 및 결과 저장*Store Data and Results*은 측정 데이터와 분석 결과를 안전하고 접근 가능한 형태로 보존하여 장기적인 추세 분석, 준거 준수, 미래 분석에 활용할 수 있도록 하는 활동이다. 적절한 접근 제어를 갖춘 중앙 저장소에 데이터를 보관하고, 타임스탬프와 버전 정보를 포함한 이력을 유지한다. 데이터 보존 정책을 수립하고, 백업 및 재해 복구 절차를 마련한다. 특히 측정 데이터가 개인의 성과 평가에 오용되지 않도록 집계 수준에서 관리하는 것이 중요하다. [[Capability Maturity Model Integration#측정의 목적|측정의 목적]]은 통제가 아니라 개선이기 때문이다. ### SP 2.4: Communicate Results 결과 전달*Communicate Results*은 측정 결과를 적시에 이해하기 쉬운 형태로 모든 관련 이해관계자에게 전달하는 활동이다. 이해관계자별로 정보 요구가 다르므로 전달 방식도 차별화해야 한다. 자동 갱신되는 대시보드, 주간 팀 메트릭 리뷰, 월간 경영 요약 보고, 임계값 초과 시 실시간 알림 등 다양한 전달 메커니즘을 활용한다. 예를 들어, 개발팀에게는 일별 결함 추세와 배포 현황을 대시보드로 제공하고, 경영층에게는 월별 전략 목표 달성도를 요약 보고서로 전달하며, 배포 실패율이 임계값을 초과하면 관련 담당자에게 즉시 알림을 보내는 식이다. 단순히 데이터를 전달하는 것이 아니라, 해석과 맥락을 함께 제공하여 의사결정을 지원하는 것이 핵심이다. [^1]: 결함 밀도는 결함수/KLOC로 계산한다. [^2]: Boehm, B.W.와 Basili, V.R. (2001)의 연구에 따르면, 요구사항 단계에서 발견된 결함의 수정 비용을 1로 놓았을 때, 유지보수 단계에서 발견된 결함의 수정 비용은 최대 100배에 달한다. [^3]: 조작적 정의*Operational Definition*란 측정 대상의 개념을 관찰 가능하고 반복 가능한 절차로 구체화한 정의를 말한다. 예를 들어, "결함"이라는 개념을 "코드 리뷰, 테스트, 필드에서 발견된 소프트웨어 동작의 명세 위반"으로 정의하는 것이 조작적 정의다. --- ## 출처 - Chrissis, M.B., Konrad, M. and Shrum, S. (2011) _CMMI for development: guidelines for process integration and product improvement_. 3rd edn. Upper Saddle River, NJ: Addison-Wesley (The SEI series in software engineering). - Forsgren, N., Humble, J. and Kim, G. (2018) _Accelerate: the science of lean software and DevOps: building and scaling high performing technology organizations_. Portland, Oregon: IT Revolution Press. - Boehm, B.W. and Basili, V.R. (2001) 'Software Defect Reduction Top 10 List', _Computer_, 34(1), pp. 135–137. - ISO/IEC/IEEE (2017) _ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabulary_. International Organization for Standardization. - Basili, V.R., Caldiera, G. and Rombach, H.D. (1994) 'The Goal Question Metric Approach', in Marciniak, J.J. (ed.) _Encyclopedia of Software Engineering_. New York: Wiley, pp. 528–532.