소프트웨어 메트릭스로 프로젝트와 품질을 측정하는 방법

숫자로 드러나는 개발 현장의 상태

소프트웨어는 눈으로 완성도를 바로 판단하기 어렵다. 개발 공정, 산출물, 프로젝트 운영의 상태를 수치로 바꾸는 소프트웨어 메트릭스(SW Metrics)는 이 보이지 않는 상태를 의사결정에 사용할 수 있는 지표로 만든다.

메트릭스는 코드만 재는 도구가 아니다. 소프트웨어의 특성·성능·품질을 측정해 가치를 평가하고, 개발 프로세스와 프로젝트 운영의 성숙도까지 진단하는 기준이다. 이를 통해 진행 상황을 가시화하고, 품질을 제어하며, 자원·비용·기간을 예측하고 리스크의 우선순위를 조정할 수 있다.

프로젝트·제품·프로세스를 함께 본다

측정 대상에 따라 메트릭스는 프로젝트, 제품, 프로세스 관점으로 나뉜다. 어느 한 관점만으로는 개발 상태를 충분히 설명하기 어렵다.

프로젝트 메트릭스는 관리자가 일정과 자원 소모를 판단할 때 쓰는 지표다. 투입 인력(Man-Month), 개발 기간, 예산 집행률, 진척도(Velocity), 리스크 발생 빈도 등을 측정한다. 계획과 실제 투입 인력의 편차를 분석하면 프로젝트의 상태를 진단할 수 있고, 지연이 예상되는 구간에서는 인력 충원이나 범위 조정의 근거가 된다.

제품 메트릭스는 최종 산출물의 품질과 기술적 특성을 대상으로 한다. 코드 라인 수(LOC), 기능 점수(Function Point), 순환 복잡도(Cyclic Complexity), 응집도(Cohesion), 결합도(Coupling), 주석률 등이 여기에 속한다. 소스 코드의 복잡도를 통해 유지보수 비용을 예측할 수 있으며, 결합도가 낮고 응집도가 높은 모듈은 변경에 유연하고 재사용성이 높다는 점을 보여준다.

프로세스 메트릭스는 소프트웨어를 만드는 절차와 방법론의 성과를 측정한다. 결함 제거율(DRE), 프로세스 준수율, 단위 시간당 생산성, 평균 복구 시간(MTTR)이 대표 항목이다. 출시 후 결함이 많이 발견된다면 테스트 설계나 코드 리뷰 절차를 개선해야 한다는 신호가 될 수 있다.

측정값이 개선으로 이어지는 흐름

지표 수집 자체는 목적이 아니다. 프로젝트 성격에 맞는 지표를 고르고, 데이터를 수집한 뒤 기준값(Baseline) 또는 과거 데이터와 비교해 편차를 분석해야 한다. 분석 결과는 이해관계자와 공유하고, 개선이 필요한 부분에는 구체적인 액션 플랜으로 연결한다.

⤢✕

제어 흐름에서 읽는 순환 복잡도

맥케이브(McCabe)의 순환 복잡도(Cyclomatic Complexity)는 널리 활용되는 제품 메트릭스다. 제어 흐름 그래프(Control Flow Graph)를 기준으로 프로그램의 논리적 복잡도를 측정한다.

순환 복잡도 V(G)는 다음 공식으로 구한다.

V(G) = e - n + 2
e (Edges): 그래프 내의 화살표(제어 흐름) 수
n (Nodes): 그래프 내의 노드(명령문 또는 블록) 수

닫힌 영역의 수에 1을 더하거나, 조건문 수에 1을 더하는 방식으로도 계산할 수 있다.

코드 리뷰에서는 수치 구간을 진단 기준으로 사용할 수 있다.

5 이하 (매우 간단): 논리 구조가 명확하며 개별 유닛 테스트만으로 충분히 검증 가능한 상태다.
5 ~ 10 (구조적 안정): 일반적인 상용 소프트웨어 모듈이 지향해야 할 수준이다. 가독성이 유지되고 유지보수가 용이하다.
20 이하 (매우 복잡): 하나의 함수나 모듈에 너무 많은 조건문이 집중된 상태다. 로직 오류 발생 가능성이 비약적으로 상승하며 서브 모듈로의 분할이 권장된다.
50 이하 (비구조적 불안정): 흔히 말하는 '스파게티 코드'가 될 확률이 높다. 테스트 케이스를 모두 작성하는 것이 거의 불가능에 가까우며 전면적인 리팩토링이 필수적이다.

출시 전 결함을 포착하는 DRE

결함 제거 효율(Defect Removal Efficiency, DRE)은 전체 결함 가운데 개발 단계에서 제거한 결함의 비중을 나타내는 프로세스 메트릭스다.

DRE = E / (E + D)

E: 개발 단계(출시 전)에서 발견된 결함 수
D: 사용자 인도(출시 후) 단계에서 발견된 결함 수

DRE가 1에 가까울수록 개발 프로세스가 견고하다는 뜻이며, 사후 유지보수 비용을 획기적으로 줄이는 지표가 된다. 고품질 소프트웨어를 지향하는 조직은 95% 이상의 DRE를 목표로 관리하는 경우가 많다.

숫자가 목표를 대체하지 않게 하려면

현장에서는 수집 데이터의 신뢰성부터 확인해야 한다. 수동 수집은 데이터 왜곡 위험이 있으므로, 가능한 한 자동화된 툴링으로 객관적인 데이터를 확보할 필요가 있다.

수치를 높이는 일이 목적이 되어서도 안 된다. LOC를 늘리려고 불필요한 코드를 넣는 방식처럼 지표를 위한 편법이 생길 수 있다. 메트릭스는 평가보다 개선을 위한 도구로 다뤄야 한다.

생산성과 품질 지표가 충돌하는 상황도 있다. 빠른 개발을 위해 복잡도를 희생할 수 있기 때문이다. 단일 지표를 맹신하지 않고 여러 지표를 함께 해석해야 하며, 측정 과정이 개발자에게 과도한 업무 부담이 되지 않도록 자동화 도구를 활용해야 한다. 측정하기 쉬운 항목이 아니라 프로젝트의 성공 목표와 직접 연결된 지표를 선택하는 기준도 필요하다.

초기 단계부터 결함 지표를 관리하면 사후 수정 비용을 줄일 수 있다. 데이터는 팀원과 이해관계자 사이의 객관적인 소통 기반이 되며, 축적된 지표의 분석은 조직의 개발 역량을 점진적으로 강화한다.

Sources

소프트웨어 공학 센터(Software Engineering Center) 품질 관리 가이드
IEEE Std 1061, Standard for a Software Quality Metrics Methodology
McCabe, T. J. (1976). A Complexity Measure. IEEE Transactions on Software Engineering.