4단계 테스트 파이프라인
코드 리뷰(검출률 65%), 단위 테스트(70%), 통합 테스트(60%), QA(80%)를 거치면 버그 생존율은 0.35×0.30×0.40×0.20 = 0.84%입니다.
100개 버그 중 약 1개만 프로덕션에 도달합니다. 4단계 조합의 위력입니다.
버그 생존율
테스트 단계별 검출률에 따른 버그 생존율을 계산합니다.
입력
단계
코드 리뷰, 유닛 테스트, QA 등 각 검증 단계
%
버그 생존율
버그 생존율 0.243000%
1 in 412 — 프로덕션까지 살아남을 확률
검출 확률99.8%
생존 확률0.2%
- 전체 검출 확률99.757000%모든 단계에서 잡힐 확률
1 in 412 — 프로덕션까지 살아남을 확률: 0.243000%
단계별 버그 생존율
차트 그리는 중…
단계별 상세
| 단계 | 단계 검출률 | 누적 검출률 | 생존율 |
|---|---|---|---|
| 1단계 | 70.0% | 70.00% | 30.0000% |
| 2단계 | 70.0% | 91.00% | 9.0000% |
| 3단계 | 70.0% | 97.30% | 2.7000% |
| 4단계 | 70.0% | 99.19% | 0.8100% |
| 5단계 | 70.0% | 99.76% | 0.2430% |
풀이 보기
결과 공유하기
버그 생존율 계산기는 소프트웨어 개발의 각 테스트 단계(코드 리뷰, 단위 테스트, 통합 테스트, QA, 프로덕션 모니터링)별 검출률에 따라 최종적으로 사용자에게 도달하는 버그 비율을 계산하는 도구입니다. 각 단계의 검출률이 80%라면, 3단계를 거친 후 버그 생존율은 (1-0.8)³ = 0.8%입니다. 하지만 검출률이 50%인 단계가 하나라도 있으면 생존율이 급증합니다. 업계 평균적으로 프로덕션까지 도달하는 버그 비율은 전체 버그의 약 5~15%입니다. 이 계산기를 통해 어떤 테스트 단계를 강화하는 것이 가장 효과적인지 비용 대비 효율을 분석할 수 있습니다.
실생활 예시
이럴 때 이렇게 계산해요.
단위 테스트 누락의 영향
위 파이프라인에서 단위 테스트를 생략하면 생존율이 0.35×0.40×0.20 = 2.8%로 3.3배 증가합니다.
한 단계를 건너뛰면 효과가 급격히 떨어집니다. 모든 단계를 유지하는 것이 중요합니다.
Google의 테스트 자동화 사례
Google은 코드 변경 시 자동 코드 리뷰(검출률 약 60%), 단위 테스트(85%), 통합 테스트(75%), 카나리 배포(90%)의 4단계를 운영합니다. 버그 생존율은 0.40×0.15×0.25×0.10 = 0.15%입니다.
높은 자동화 수준과 카나리 배포의 조합으로 1,000개 버그 중 약 1.5개만 사용자에게 도달합니다.
Microsoft의 보안 개발 생명주기(SDL)
Microsoft SDL은 설계 리뷰(40%), 정적 분석(35%), 코드 리뷰(60%), 보안 테스트(70%), 침투 테스트(50%) 5단계로 보안 버그를 걸러냅니다. 보안 버그 생존율은 0.60×0.65×0.40×0.30×0.50 = 2.34%입니다.
보안 버그는 일반 버그보다 생존율이 높아 더 많은 단계가 필요합니다. 5단계로도 약 2%가 통과하여 지속적인 모니터링이 필수입니다.
스타트업 vs 대기업 버그 생존율 비교
스타트업(코드 리뷰 50% + QA 60%): 생존율 0.50×0.40 = 20%. 대기업(4단계 풀 파이프라인): 생존율 약 1%. 스타트업의 버그 생존율이 20배 높습니다.
리소스가 제한된 스타트업은 자동화된 테스트 도입만으로도 버그 생존율을 극적으로 개선할 수 있습니다.
관련 계산기
같이 쓰면 좋아요. 옆으로 넘겨 보세요.
자주 묻는 질문
궁금한 거 모아 봤어요. 눌러서 펼쳐 보세요.
어떤 테스트 단계를 강화하는 것이 가장 효과적인가요?
일반적으로 가장 앞 단계(코드 리뷰, 단위 테스트)를 강화하는 것이 비용 대비 효과가 큽니다. 버그를 일찍 잡을수록 수정 비용이 낮고, 이후 단계에서 잡아야 할 버그 수가 줄어들기 때문입니다. 프로덕션 버그 수정 비용은 설계 단계의 약 100배입니다.
검출률 80%는 현실적인 수치인가요?
코드 리뷰의 버그 검출률은 약 60~70%, 단위 테스트는 약 50~80%, QA 테스트는 약 70~90%입니다. 단계마다 다르며, 여러 단계를 조합하여 전체 검출률을 높이는 것이 핵심입니다.
버그 생존율을 0%로 만들 수 있나요?
현실적으로 불가능합니다. 각 단계의 검출률이 100%가 아닌 한 일부 버그는 통과합니다. 목표는 0%가 아니라 비즈니스에 미치는 영향을 최소화할 수 있는 수준으로 관리하는 것입니다.
프로덕션 버그 수정 비용이 왜 설계 단계의 100배인가요?
IBM의 Systems Sciences Institute 연구에 따르면, 프로덕션에서 버그를 수정하려면 원인 분석, 핫픽스 개발, 긴급 배포, 데이터 복구, 사용자 보상 등의 추가 작업이 필요합니다. 설계 단계에서는 문서 수정만으로 해결되므로 비용 차이가 극적입니다.
정적 분석 도구는 검출률에 얼마나 기여하나요?
SonarQube, ESLint 같은 정적 분석 도구는 코드 스멜, 보안 취약점, 타입 오류 등을 자동으로 검출합니다. 단독 검출률은 약 20~40%이지만, 사람이 놓치기 쉬운 패턴을 잡아주므로 코드 리뷰와 결합하면 시너지 효과가 큽니다.
테스트 커버리지가 높으면 버그 검출률도 높은가요?
커버리지(실행된 코드 비율)와 검출률은 다른 개념입니다. 커버리지 100%라도 모든 입력 조합을 테스트하지 못하면 버그를 놓칠 수 있습니다. 다만 커버리지가 낮으면 검출률도 낮아지는 경향이 있어, 최소 80% 이상을 권장합니다.
회귀 테스트(regression test)는 버그 생존율에 어떤 영향을 주나요?
회귀 테스트는 이전에 수정한 버그가 재발하는 것을 방지합니다. 회귀 테스트 없이는 수정된 버그의 약 15~25%가 재발한다는 연구가 있습니다. 자동화된 회귀 테스트 스위트는 검출률을 10~15%p 추가로 높일 수 있습니다.
계산 원리
## 버그 생존율의 수학적 배경
### 기본 생존율 공식 각 테스트 단계의 검출률을 d₁, d₂, ..., dₙ이라 하면, 각 단계의 통과율(생존율)은 (1-dᵢ)입니다.
최종 버그 생존율 = ∏(1 - dᵢ) = (1-d₁)(1-d₂)...(1-dₙ)
### 예시 검출률이 모두 70%인 4단계: 생존율 = (0.3)⁴ = 0.81% 검출률이 모두 50%인 4단계: 생존율 = (0.5)⁴ = 6.25%
### 한계 검출률 분석 목표 생존율을 S, 단계 수를 n이라 하면 각 단계에 필요한 최소 검출률:
d_min = 1 - S^(1/n)
생존율 1%를 4단계로 달성하려면: d_min = 1 - 0.01^(1/4) = 1 - 0.316 = 68.4%
### 비용 효율 분석 각 단계의 비용을 Cᵢ, 검출률 개선량을 Δdᵢ라 하면:
비용 효율 = |Δ생존율| / Cᵢ
일반적으로 초기 단계(코드 리뷰, 단위 테스트)의 비용 효율이 가장 높습니다.
사용 방법
테스트 단계 설정
각 테스트 단계의 이름을 입력합니다.
검출률 입력
각 단계의 버그 검출률(%)을 입력합니다.
결과 확인
단계별 누적 생존율과 최종 프로덕션 도달 비율을 확인합니다.
용어 사전
- 버그 검출률(Defect Detection Rate)
- 특정 테스트 단계에서 유입된 버그 중 발견된 버그의 비율입니다. 검출률 70%이면 10개 버그 중 7개를 발견합니다.
- 버그 탈출률(Defect Escape Rate)
- 검출되지 않고 다음 단계로 넘어간 버그의 비율입니다. 검출률의 반대 개념으로, 검출률이 70%이면 탈출률은 30%입니다.
- 코드 리뷰(Code Review)
- 다른 개발자가 작성된 코드를 검토하여 결함, 설계 문제, 코딩 표준 위반 등을 찾는 과정입니다.
- 회귀 테스트(Regression Test)
- 코드 변경 후 기존 기능이 정상 동작하는지 확인하는 테스트입니다. 수정한 버그의 재발을 방지합니다.
- 정적 분석(Static Analysis)
- 코드를 실행하지 않고 소스 코드 자체를 분석하여 잠재적 결함을 찾는 기법입니다. SonarQube, ESLint 등이 대표적입니다.
- 테스트 커버리지(Test Coverage)
- 테스트가 실행한 코드의 비율입니다. 라인 커버리지, 브랜치 커버리지 등의 종류가 있으며, 높을수록 테스트가 코드를 넓게 검증합니다.
- 카나리 배포(Canary Deployment)
- 새 버전을 전체 사용자의 소수(1~5%)에게만 먼저 배포하여 문제를 조기 발견하는 배포 전략입니다.