테스트가 끝났다. 결과가 나왔다. 이제 무엇을 봐야 하는가.
기존 방식에서 품질 지표는 대개 두 가지였다. 테스트 통과율과 코드 커버리지. 숫자는 있다. 그런데 그 숫자가 말해주는 것이 생각보다 적다. 통과율 95%는 좋아 보이지만, 어떤 기능이 그 5% 안에 있는지 알지 못하면 안심할 수 없다. 커버리지 80%는 코드의 80%가 실행됐다는 뜻이지, 비즈니스 기능의 80%가 검증됐다는 뜻이 아니다.
SOM은 세 가지 기준으로 품질을 측정한다. 커버리지, 정합성, 영향도.
첫 번째 지표: SOM 커버리지 The first metric: SOM coverage
SOM 커버리지는 간단하다.
SOM 커버리지 = 검증 완료된 Program 수 / 전체 Program 수
전체 Program이 43개인 프로젝트에서 38개의 테스트가 통과했다면, SOM 커버리지는 88%다. 이 숫자는 기획자도 바로 이해한다. "43개 기능 중 38개가 검증됐다"는 것.
나머지 5개가 어떤 Program인지도 목록으로 볼 수 있다.
미검증 Program: SOM-0011 첨부파일 업로드 (개발 완료, 테스트 미착수) SOM-0022 처리 이력 (개발 완료, 테스트 미착수) SOM-0041 민원 처리 (개발 진행중) SOM-0042 통계 (개발 진행중) SOM-0031 신청 내역 (테스트 실패 — 재검증 필요)
커버리지를 등급으로 읽기 Reading coverage by priority grade
SOM 커버리지를 Program의 우선순위와 결합하면 더 정밀해진다.
| 등급 | 대상 | 목표 커버리지 |
|---|---|---|
| P1 (핵심) | 서비스 핵심 기능 | 100% |
| P2 (중요) | 주요 업무 기능 | 90% 이상 |
| P3 (보통) | 보조 기능 | 70% 이상 |
| P4 이하 | 관리/설정 기능 | 50% 이상 |
P1 Program이 하나라도 미검증이면, 전체 커버리지가 95%여도 출시할 수 없다. SOM 커버리지는 전체 숫자와 등급별 숫자를 함께 봐야 한다.
두 번째 지표: 정합성 지수 The second metric: consistency index
정합성은 "기획한 것과 실제 구현된 것이 얼마나 일치하는가"를 측정한다.
소프트웨어 개발 과정에서 기획과 구현 사이에는 크고 작은 불일치가 생긴다. 버튼 레이블이 다르게 구현됐거나, API 응답 형식이 기획과 다르거나, 오류 메시지가 빠져있거나. 이것들이 누적되면 "기획자가 설계한 소프트웨어"와 "사용자가 쓰는 소프트웨어"가 달라진다.
SOM에서 정합성은 세 축으로 측정된다.
UI 정합성: 기획 속성(버튼 텍스트, 필드 레이블, 화면 흐름)과 실제 DOM이 일치하는가.
API 정합성: 기획에서 정의한 API 계약(요청/응답 형식, 상태 코드)과 실제 통신이 일치하는가.
로직 정합성: 기획에서 정의한 분기 조건과 실제 코드 커버리지가 대응되는가.
세 축을 종합한 정합성 지수가 SOM-0003에 대해 85%라면, 이 화면의 15%는 기획과 구현이 어긋나 있다는 뜻이다. 어느 부분이 어긋났는지는 SOM ID로 추적해서 확인한다.
세 번째 지표: 영향도 The third metric: impact
영향도는 "변경이 생겼을 때 무엇이 함께 흔들리는가"를 미리 파악하는 지표다.
코드가 변경될 때마다 전체 테스트를 재실행하는 것은 비효율적이다. 그렇다고 변경된 파일의 테스트만 돌리면 영향받는 다른 기능을 놓친다. SOM은 중간 답을 제시한다.
소스 파일이 변경되면 → 그 파일과 연결된 SOM ID를 찾고 → 해당 SOM의 테스트만 재실행한다.
변경 파일: UserService.java UserService.java 와 연결된 SOM: SOM-0002 로그인 SOM-0003 회원가입 SOM-0004 비밀번호 찾기 SOM-0030 내 정보 수정 재실행 대상: 위 4개 Program의 테스트 케이스 건너뛸 대상: 나머지 39개 Program (영향 없음)
43개 테스트 전체를 돌리는 대신 4개만 돌린다. 정확하고 빠르다.
영향도는 배포 전 리그레션 테스트 범위를 결정하는 데도 쓰인다. 이번 배포에 변경된 SOM이 어디인지 파악하면, 테스트 팀이 어디에 집중해야 하는지 자동으로 결정된다.
세 지표를 함께 읽기 Reading the three metrics together
세 지표는 각각 다른 질문에 답한다.
| 지표 | 질문 |
|---|---|
| SOM 커버리지 | 얼마나 많은 기능이 검증됐는가 |
| 정합성 지수 | 검증된 기능이 기획과 얼마나 일치하는가 |
| 영향도 | 변경이 생기면 무엇을 다시 검증해야 하는가 |
커버리지가 높아도 정합성이 낮으면, 테스트는 많이 했지만 기획과 다른 것을 테스트한 것이다. 커버리지와 정합성이 모두 높아도 영향도 관리가 없으면, 다음 배포에서 회귀 결함이 발생할 가능성이 높다.
세 지표가 모두 기준을 충족할 때, "이 소프트웨어는 품질이 있다"고 말할 수 있다.
숫자에서 대화로 From numbers to conversation
SOM 지표의 진짜 가치는 숫자가 아니라 대화에 있다.
기존 품질 보고는 개발자가 기획자에게 숫자를 설명하는 자리였다. SOM 지표는 기획자가 직접 읽고 질문하는 자리를 만든다.
"SOM-0031 신청 내역이 왜 아직 미검증이죠?"
"SOM-0003 정합성이 85%인데, 어느 부분이 다른가요?"
"이번 배포에 SOM-0002가 영향받는다면 로그인 테스트를 다시 해야 하는 건가요?"
이 질문들은 기획자가 스스로 할 수 있는 질문이다. SOM ID가 공통 언어가 된 덕분이다. 품질 회의의 성격이 바뀐다. 개발자가 설명하는 자리에서, 팀 전체가 함께 읽는 자리로.