개념
테스트 예산이 깎이는 이유
테스트 예산은 효과가 보이지 않을 때 가장 잘 돌아간다 는 역설을 갖는다. 사고가 없으면 "이만큼 쓸 필요가 있나" 가 되고, 사고가 나면 "그만큼 썼는데 왜" 가 된다. 양쪽 다 테스트에 불리하다.
품질 비용(Cost of Quality) 은 이 대화를 같은 단위 로 끌어온다. 테스트는 비용이 아니라 다른 비용을 줄이기 위한 지출 이라는 구조를 보이는 틀이다.
네 분류 — 경계를 먼저 정한다
| 분류 | 성격 | 예 |
|---|---|---|
| 예방 비용 | 결함이 생기지 않게 하는 지출 | 교육, 표준·템플릿 정비, 설계 검토, 도구 도입 |
| 평가 비용 | 결함을 찾는 지출 | 테스트 설계·실행, 코드 리뷰, 자동화 유지, 시험 환경 |
| 내부 실패 비용 | 출시 전에 발견된 결함의 처리 비용 | 재작업, 재시험, 재배포, 일정 지연 |
| 외부 실패 비용 | 출시 후에 발견된 결함의 비용 | 장애 대응, 긴급 배포, 보상, 고객 이탈, 평판 |
앞 둘은 의도적 지출, 뒤 둘은 발생한 손실 이다. 그래서 논지가 만들어진다 — 예방·평가에 쓰는 돈이 실패 비용을 얼마나 줄이는가.
실무에서 가장 중요한 작업이 경계 정하기 다. 같은 활동이 분류에 따라 갈린다.
- 코드 리뷰 — 결함을 찾으니 평가인가, 만들지 않게 하니 예방인가. 조직이 하나로 정하고 일관되게 쓴다
- 자동화 구축 — 처음 만드는 비용은 예방에 가깝고, 유지·실행은 평가다
- 재시험 — 내부 실패다. 평가 비용에 섞으면 테스트가 비싸 보인다
- 운영 모니터링 — 외부 실패를 줄이는 평가인가, 운영 비용인가
분류가 흔들리면 추세 비교가 무의미해진다. 올해와 작년의 숫자가 다른 분류 기준으로 모였으면 비교할 수 없다. 그래서 분류 정의서를 먼저 만들고 합의받는다.
숫자를 어디서 가져오는가
CoQ 가 실무에서 실패하는 가장 큰 이유는 데이터가 없는데 표를 만들려 하는 것 이다. 없는 숫자를 추정으로 채우면, 한 칸이 의심받는 순간 표 전체가 버려진다.
실제로 모을 수 있는 것부터 시작한다.
| 모으기 쉬운 것 | 어디서 |
|---|---|
| 인건비 × 투입 시간 | 작업 기록, 이슈 추적 도구의 시간 기록 |
| 도구·환경 비용 | 구매·구독 내역, 클라우드 사용량 |
| 결함 건수와 발견 단계 | 결함 추적 도구 |
| 재배포 횟수 | 배포 기록 |
| 장애 건수와 대응 시간 | 장애 기록 |
| 모으기 어려운 것 | 왜 |
|---|---|
| 고객 이탈로 인한 손실 | 인과를 증명하기 어렵다 |
| 평판 손실 | 금액화 근거가 없다 |
| 기회 비용 | 가정이 많다 |
어려운 것은 금액으로 넣지 않는다. 표에 넣는 대신 "금액화하지 않은 항목" 으로 따로 열거 한다. 그러면 "여기 적힌 금액은 보수적으로 집계한 하한" 이라는 위치를 얻는다. 이것이 과장보다 훨씬 강한 설득이다. 숫자를 부풀려 한 번 반박당하면 다음에 같은 표를 들고 가도 읽히지 않는다.
발견 단계가 비용을 바꾼다 — 우리 데이터로
"결함을 늦게 발견하면 비용이 커진다" 는 주장은 널리 쓰이지만, 흔히 인용되는 배수(10배·100배 같은 수치) 는 출처와 적용 조건이 명확하지 않은 경우가 많다. 그런 숫자를 인용하면 경영진 중 누군가가 출처를 묻고, 답할 수 없으면 신뢰를 잃는다.
대신 우리 조직의 숫자를 만든다. 방법은 단순하다.
단계별 결함 1건당 처리 시간 = (해당 단계 결함 처리 총 시간) ÷ (해당 단계 결함 건수)
단계: 요구/설계 검토 → 개발 중 → 시스템 테스트 → 출시 후결함 추적 도구에 발견 단계 와 처리 시간 이 기록되어 있으면 바로 계산된다. 없으면 그 두 필드를 추가하는 것이 CoQ 작업의 첫 단계다 — 몇 달 뒤에 쓸 데이터를 지금 쌓기 시작한다.
우리 숫자로 만든 배수는 외부 인용보다 작을 수도 있다. 그래도 그 숫자가 강하다. "우리 조직에서 출시 후 결함 1건은 시스템 테스트 단계 결함의 N 배 시간이 듭니다" 는 반박하기 어렵다.
예산 협상에 쓰는 방식
CoQ 표를 그대로 들고 가는 것은 효과가 낮다. 경영진이 보는 질문은 하나다 — "이 지출로 무엇이 줄어드는가." 그래서 세 가지 형태로 바꿔 쓴다.
1) 구성 비율의 변화. 전체 품질 비용에서 실패 비용이 차지하는 비율을 추세로 보인다. 예방·평가를 늘렸더니 실패 비율이 줄었다는 모양이 나오면 그것이 근거다. 절대 금액보다 구성 비율이 설명하기 쉽다.
2) 한 가지 투자에 대한 전후 비교. 전체를 설명하려 하지 않고, 구체적 투자 하나 를 고른다. "회귀 자동화에 N 인월을 썼고, 그 뒤 재배포가 월 M 회에서 K 회로 줄었다." 범위가 좁을수록 인과가 분명하고 반박이 어렵다.
3) 줄이지 않는 경우의 비용. 삭감 제안이 들어왔을 때 쓰는 방향이다. "평가 비용을 줄이면 실패 비용이 어디로 가는지" 를 시나리오로 보인다. 확정 예측이 아니라 시나리오라는 점을 분명히 하는 것이 정직하고, 오히려 받아들여진다.
모듈 44 레슨 1 의 비즈니스 케이스, 레슨 3 의 경영진 보고와 같은 문법이다 — 숫자 하나가 아니라 결정에 쓰이는 형태 로 만든다.
개선 우선순위에도 쓴다
CoQ 는 예산 방어 도구만이 아니다. 어디를 개선할지 고르는 데 더 자주 쓰인다.
내부 실패 비용을 원인별로 쪼개면 개선 대상이 보인다 — 요구 변경에 의한 재작업, 환경 문제로 인한 재시험, 회귀 누락으로 인한 재배포, 결함 재현 실패로 인한 왕복. 가장 큰 덩어리가 개선 1순위다.
여기서 흔한 함정이 있다. 테스트 조직이 통제할 수 없는 원인이 1순위로 나오는 경우 다. 예 — 요구 변경에 의한 재작업. 그때 "우리 문제가 아니다" 로 끝내면 아무것도 달라지지 않는다. 그 숫자를 요구 관리 개선의 근거로 다른 조직에 전달 하는 것이 테스트 매니저의 일이다. 모듈 44 레슨 5 의 변화 관리로 이어진다.
하지 말아야 할 것
- 전부 금액화하려 하지 않는다. 금액화 못 한 항목을 열거하는 쪽이 강하다
- 출처 불명의 배수를 인용하지 않는다. 우리 데이터로 만든다
- 단일 숫자로 보고하지 않는다. 구성 비율과 추세로 보인다
- 분류를 그때그때 바꾸지 않는다. 추세 비교가 무의미해진다
- 개인·팀 평가에 쓰지 않는다. 결함 수가 평가 지표가 되면 결함이 숨겨진다. 모듈 48 레슨 5 의 지표 오염과 같은 문제다
마지막 항목이 가장 중요하다. CoQ 데이터가 평가에 쓰인다는 신호가 한 번만 나면 그 뒤의 모든 숫자가 왜곡된다.
실무에서 왜 필요한가
테스트 매니저가 예산 협상에서 지는 이유는 논거가 없어서가 아니라 논거의 단위가 달라서 다. 품질을 품질의 언어로 말하면 경영진에게 전달되지 않는다. CoQ 는 같은 단위로 바꾸는 가장 표준적인 틀이고, 그래서 테스트 관리 자격 체계에서도 다뤄진다.
그리고 실무에서 더 자주 쓰이는 쪽은 개선 우선순위 다. 개선하고 싶은 것은 항상 많고 자원은 적다. 내부 실패 비용을 원인별로 쪼개면 가장 비싼 낭비 가 숫자로 드러나고, 그 숫자가 우선순위 논쟁을 끝낸다.
채용시장에서의 위치
테스트 매니저·QA 리드 공고에 "예산 수립", "비용 관리", "ROI" 같은 말이 적히면 이 영역을 묻는 것이다. 면접에서 가르는 질문은 "CoQ 네 분류를 말해 보세요" 가 아니라 "테스트 예산 삭감 제안에 어떻게 대응하시겠습니까" 이고, 시나리오 형태로 답할 수 있는 사람이 적다. ISTQB CTAL-TM 의 범위와도 겹친다.