측정·검토·품질 개선
지표를 질문과 분모, 환경, 표본과 함께 정의하고, 같은 비율도 표본의 크기에 따라 확실성이 다르다는 것을 계산해 봅니다. 워크스루, 인스펙션, 정적 분석의 차이를 정리하고, CMM과 CMMI 같은 프로세스 평가를 제품의 품질과 구별합니다.
"버그가 10개 줄었습니다"라는 보고만으로는 이전에 몇 개를 어떤 방법으로 찾았는지 알 수 없습니다. 어떤 질문에 답하려고 측정한 값을 정해진 방식으로 계산한 것을 지표(metric)라고 하는데, 질문과 분모를 빼고 숫자만 남기면 같은 숫자로 서로 다른 결론을 낼 수 있습니다. 이 글에서는 지표를 정의하는 방법과 실행하지 않고 산출물을 검토하는 방법, 그리고 조직의 프로세스를 평가하는 모델을 다룹니다.
지표는 질문에서 시작한다
지표를 정할 때는 먼저 목표를 세우고, 그 목표를 이루었는지 판단할 질문을 적은 뒤, 질문에 답할 지표를 고릅니다. 이 순서를 목표-질문-지표(goal-question-metric, GQM) 방식이라고 합니다. 예를 들어 "처음 쓰는 참가자가 신청을 혼자 끝낼 수 있게 한다"는 목표에는 "안내만 보고 신청을 끝내는가?"라는 질문이, 그 질문에는 "과업 완료율"이라는 지표가 이어집니다.
지표를 비교하려면 정의를 맞추어야 합니다. 결함 밀도를 비교하려면 무엇을 결함으로 세었는지, 어느 기간에 어떤 방법으로 찾았는지, 규모를 무엇으로 쟀는지가 같아야 합니다. 테스트 통과율은 어떤 사례를 실행했는지를, 과업 완료율은 어떤 참여자가 어떤 과업을 어떤 환경에서 했는지를 함께 밝혀야 하며, 코드 줄 수와 결함 수를 같은 품질의 잣대로 해석하지 않습니다.
같은 비율도 확실성이 다르다
과업 완료율은 완료한 수 / 시도한 수로 계산합니다. 다음 코드는 분모가 0 이하이거나 완료한 수가 불가능한 값이면 계산을 거절하고, 같은 0.8이라도 표본의 크기에 따라 불확실성이 얼마나 다른지 보여 줍니다. 두 표본은 계산을 위해 정한 가상의 값이며 실제 사용자를 관찰한 결과가 아닙니다.
function completionRate({ completed, attempted }) {
if (!Number.isInteger(attempted) || attempted <= 0 || !Number.isInteger(completed) || completed < 0 || completed > attempted) {
throw new RangeError("invalid observation counts");
}
return completed / attempted;
}
for (const sample of [{ completed: 8, attempted: 10 }, { completed: 80, attempted: 100 }]) {
const rate = completionRate(sample);
const standardError = Math.sqrt((rate * (1 - rate)) / sample.attempted);
console.log(`${sample.completed}/${sample.attempted}`, "비율", rate, "표준오차", standardError.toFixed(3));
}
try {
completionRate({ completed: 11, attempted: 10 });
} catch (error) {
console.log(error.name, error.message);
}8/10 비율 0.8 표준오차 0.126
80/100 비율 0.8 표준오차 0.040
RangeError invalid observation counts표준오차(standard error)는 표본으로 구한 비율이 표본을 다시 뽑을 때마다 얼마나 흔들릴지를 나타내는 대략적인 값으로, 여기서는 √(비율 × (1 - 비율) / 시도한 수)로 계산했습니다. 두 표본의 비율은 똑같이 0.8이지만, 10명에게서 얻은 비율은 100명에게서 얻은 비율보다 표준오차가 세 배 이상 큽니다. 게다가 참여자의 구성이나 과업의 난도, 측정 환경이 다르다면 두 0.8은 비교조차 할 수 없으며, 표본이 아주 작을 때는 이 근사식 자체도 잘 맞지 않습니다. 지표를 좋게 보이려고 측정 대상을 바꾸면, 숫자는 좋아져도 개선했다는 근거는 오히려 약해집니다.
실행하기 전의 검토
워크스루(walkthrough)는 작성자가 산출물을 설명하며 다른 사람의 질문과 의견을 받는 비교적 가벼운 검토입니다. 인스펙션(inspection)은 진행자, 기록자 같은 역할을 나누고, 참여자가 미리 준비하며, 찾은 결함을 정해진 형식으로 기록하는 더 체계적인 검토입니다. 정적 분석(static analysis)은 코드를 실행하지 않고 도구로 규칙 위반, 흐름의 문제, 타입의 오류 등을 찾습니다. 어느 이름을 붙였는지보다, 실제로 어떤 절차를 거쳤고 무엇을 찾을 수 있었는지를 기록합니다.
모임 코드를 검토할 때는 이름이 보기 좋은지보다, R3과 R4의 우선순위, 거절할 때 상태가 그대로인지, 복원 자료의 중복 아이디를 어떻게 처리하는지, 안내 문구가 실제 동작과 맞는지를 확인합니다. 실행하는 테스트가 이런 검토를 대신하지 못하고, 검토가 실행 중의 오류를 모두 찾아 주지도 못하므로 둘을 함께 씁니다. 검토에서 찾은 문제는 다음처럼 기록합니다.
검토 질문: 마감된 모임에서 취소하면 모집이 다시 열리는가?
근거: R6에 따라 취소한 뒤에도 마감 여부는 그대로여야 한다.
확인 대상: cancel 구현, 안내 문구, 회귀 테스트.
발견한 것: 안내 문구는 모집이 다시 열린다고 말하지만, 코어는 CLOSED를 유지한다. 문구를 고쳐야 한다.
완료 확인: 문구 검토와 마감 뒤 취소 시나리오의 재확인.프로세스 성숙도는 다른 질문
조직이 소프트웨어를 만드는 방식을 평가하는 모델도 있습니다. 원자료에 나오는 CMM(capability maturity model)은 조직의 프로세스가 발전하는 단계를 초기, 반복, 정의, 관리, 최적화의 다섯 수준으로 설명한 역사적인 모델입니다. 그 뒤를 이은 CMMI(capability maturity model integration)는 단계의 이름과 구성이 달라졌으므로, CMM의 표에 CMMI의 용어를 그대로 섞지 않습니다. 같은 이유로 SPICE라고도 불린 ISO/IEC 15504의 프로세스 평가와, 그 뒤를 이은 ISO/IEC 330xx 계열 표준도 구별해야 하며, 실제 조직을 평가하려면 어떤 모델의 어느 판본으로 어디까지 평가할지 정하고 그 근거를 따로 확인해야 합니다.
프로세스를 개선하는 목적은 성숙도의 표를 외우는 것이 아니라, 같은 방식으로 일을 되풀이할 수 있게 하고 그 결과를 보고 고쳐 가는 데 있습니다. "요구 검토에서 정책의 충돌을 찾는다, 그 상황을 회귀 사례로 남긴다, 다음 변경에서 같은 문제가 다시 생기는지 본다"는 흐름이 작은 개선의 반복입니다. 조직이 받은 인증이나 평가 등급과 이 교재의 코어 테스트 통과는 서로 다른 것을 알려 주는 결과입니다.
더 깊이: 지금의 CMMI는 수준을 어떻게 나누나
본문의 CMM은 다섯 수준이었지만, 지금의 CMMI는 수준의 수와 이름이 다릅니다. CMMI를 관리하는 CMMI Institute의 설명은 성숙도를 0부터 5까지 여섯 수준으로 나누며, 같은 번호에 다른 이름이 붙는 곳이 있습니다.
| 수준 | CMM | 지금의 CMMI |
|---|---|---|
| 0 | 없음 | 불완전(Incomplete) |
| 1 | 초기 | 초기(Initial) |
| 2 | 반복 | 관리(Managed) |
| 3 | 정의 | 정의(Defined) |
| 4 | 관리 | 정량적 관리(Quantitatively Managed) |
| 5 | 최적화 | 최적화(Optimizing) |
설명에 따르면 0수준은 일이 임시로 처리되어 끝날지도 알 수 없는 상태이고, 2수준은 프로젝트 단위로 계획하고 측정하고 통제하며, 4수준은 측정할 수 있는 성과 목표에 따라 데이터로 움직입니다. '관리'라는 이름이 CMM에서는 4수준, CMMI에서는 2수준을 가리키므로, 두 모델의 표를 섞으면 수준을 잘못 읽게 됩니다. 다루는 범위도 넓어져, ISACA는 2023년 4월에 내놓은 CMMI V3.0이 제품 개발을 넘어 보안, 안전, 데이터 관리, 인력 관리, 원격 근무의 영역까지 하나의 모델에 묶었다고 설명합니다. 그래서 "CMMI 3수준"이라는 말을 들으면 어느 판본의 어떤 영역으로 평가받았는지까지 확인해야 합니다.
정리
- 지표는 질문에 답하려고 측정값을 정해진 방식으로 계산한 것이며, 목표, 질문, 지표의 순서로 정하는 GQM 방식을 쓸 수 있습니다.
- 지표를 비교하려면 무엇을 세었는지, 분모, 기간, 방법, 환경을 맞추어야 합니다.
- 같은 비율도 표본이 작으면 불확실성이 크므로, 비율과 함께 표본의 크기와 구성을 밝힙니다.
- 워크스루, 인스펙션, 정적 분석은 실행하지 않고 문제를 찾는 활동이며, 실행하는 테스트와 서로 대신할 수 없습니다.
- CMM, CMMI, ISO/IEC 15504와 330xx는 조직의 프로세스를 평가하는 모델이며, 판본을 섞지 않고 제품의 품질과 구별합니다.
연습 문제
1. 좋은 숫자가 만든 나쁜 선택
테스트 통과율을 높이려고 실패하던 저장 복원 테스트를 실행 목록에서 뺐더니, 보고서의 통과율이 100%가 되었습니다. 무엇이 잘못되었으며 보고를 어떻게 바꾸어야 할까요?
해설 보기
분모를 바꾸어 아직 해결하지 못한 위험을 숨겼습니다. 보고서에는 실행한 테스트와 뺀 테스트, 뺀 이유, 실패한 상태, 그 테스트가 확인하던 요구를 함께 적고, 저장 복원은 확인하지 못했거나 실패한 것으로 남겨야 합니다. 테스트가 실행할 때마다 결과가 달라져 믿기 어렵다면 그 원인을 찾아 고치되, 제품의 결함인지 테스트의 결함인지를 근거로 구별합니다. 숫자를 높이는 것과 확인하는 범위를 넓히는 것은 같은 일이 아닙니다.
2. GQM으로 지표 정하기
"참가자가 마감 뒤 취소 정책을 잘못 이해해 문의하는 일을 줄인다"는 목표에 대해, 질문 두 가지와 각 질문에 답할 지표를 하나씩 제안하세요.
해설 보기
첫 질문으로 "마감 뒤 취소에 대한 문의가 줄었는가?"를 두고, 지표로 "한 달 동안 마감 뒤 취소에 관해 들어온 문의 수를 같은 기간의 마감 뒤 취소 건수로 나눈 값"을 쓸 수 있습니다. 문의 수만 세면 모임이 늘어 취소가 많아진 달에 나빠진 것처럼 보이므로 분모를 함께 둡니다. 둘째 질문으로 "안내만 보고 정책을 바르게 이해하는가?"를 두고, 사용성 시험에서 "안내를 읽은 뒤 마감 뒤 취소의 결과를 바르게 답한 참여자의 비율"을 지표로 쓸 수 있으며, 참여자의 수와 구성도 함께 기록합니다.
3. 같은 0.8, 다른 결론
A 팀은 참여자 10명 가운데 8명이, B 팀은 100명 가운데 80명이 과업을 끝냈다고 보고하며 "두 팀의 화면은 사용성이 같다"고 결론 내렸습니다. 이 결론에 대해 무엇을 더 확인해야 할까요?
해설 보기
본문의 계산처럼 A 팀의 0.8은 표본이 작아 B 팀보다 불확실성이 훨씬 크므로, 비율이 같다는 것만으로 두 화면의 사용성이 같다고 말할 수 없습니다. 또 두 팀의 참여자가 같은 종류의 사용자였는지, 같은 과업을 같은 환경에서 했는지, 완료를 어떻게 판정했는지를 확인해야 합니다. 이런 조건이 다르다면 두 비율은 애초에 비교할 수 없으며, 같은 조건에서 표본을 늘려 다시 측정해야 합니다.
개선한 기록은 다음 담당자가 같은 근거를 찾을 수 있도록 함께 묶어 관리해야 합니다. 다음 장의 형상과 변경 기준선에서는 코드와 문서, 테스트를 하나의 기준선으로 묶어 변경을 관리하는 방법을 다룹니다.