---
type: knowledge
domain: qa
status: active
last-reviewed: 2026-07-27
---

# 결함 관리 실전

> 한 줄 정의
> 결함 관리의 목표는 "버그를 다 고치는 것"이 아니라 **모든 결함이 상태·소유자·판정 근거를 갖고 종결까지 추적되는 것**이다. 리포트 작성 품질·심각도 판정은 [[QA 원리]], 원인 추적은 [[디버깅 원리]], 운영 중 장애는 [[장애 대응 실전]] — 여기는 발견 이후의 관리 규율이다.

## 결함 수명주기 — 단계마다 소유자가 다르다

| 단계 | 소유자 | 완료 조건 |
|------|--------|----------|
| 등록 | 발견자 (QA·현업·발주사) | 재현 단계·기대 vs 실제 포함 → [[QA 원리]] 리포트 품질 |
| 트리아지 | 수행사 리드 (발주사 창구와 합의) | 3분류 판정 + 심각도 확정 + 담당자 배정 |
| 수정 | 개발 담당자 | 원인 한 줄 + 수정 커밋 연결 → [[디버깅 원리]] |
| 확인 | **보고자 (또는 보고자 환경의 검증자)** | 보고자 환경 기준 재현 불가 + 회귀 확인 |
| 종결 | 트리아지 권한자 | 판정 근거 기록 (수정·중복·재현불가·범위외) |

- 소유자 없는 상태가 곧 결함의 무덤이다 — "누구 차례인가"가 항상 조회로 답해져야 한다.
- 수정자가 자기 결함을 스스로 종결하는 구조 금지 — 확인 단계는 반드시 다른 사람(원칙은 보고자)이 닫는다.

## 심각도 vs 우선순위 — 섞으면 협상이 된다

- **심각도 = 영향의 사실**(데이터 유실·기능 불가·우회 가능·표시 결함), **우선순위 = 수정 순서의 비즈니스 판단.** 심각도는 발견자·QA가 사실 기준으로 확정하고, 우선순위는 발주사와 함께 정한다 → [[QA 원리]].
- 외주 지점: 심각도 등급의 **정의 표(예: 치명=데이터 유실·전면 불가, 중요=핵심 업무 차단·우회 없음…)를 착수 전에 발주사와 합의**한다. 검수 중에 "이게 치명이냐"를 토론하기 시작하면 등급이 협상 카드가 된다 — [[검수·UAT 대응 실전]]의 통과 조건이 이 등급 위에 서기 때문이다.

## 트리아지 규율

- **재현 불가 = 종결이 아니다.** "정보 요청" 상태로 보고자에게 돌려보내고, 기한 내 무응답일 때만 근거를 남기고 닫는다. 재현 안 되는 리포트의 절반은 리포트 문제지만, 나머지 절반은 환경·데이터 차이가 단서다 → [[디버깅 원리]] "가정이 틀렸다".
- **중복은 병합하되 리포트는 남긴다** — 중복 신고 횟수 자체가 빈도·영향의 데이터다. 병합 시 원본에 링크를 걸어 보고자가 진행을 추적할 수 있게 한다.
- 트리아지는 매일, 짧게 — 미분류 결함이 쌓인 백로그는 심각도가 아니라 등록 순서로 처리되는 복권이 된다.

## 결함 vs CR vs 사용법 문의 — 외주 분쟁 1순위

| 분류 | 판정 기준 | 처리 |
|------|----------|------|
| 결함 | **합의된 요구사항·검수 기준과 다르게 동작** | 무상 수정 (수명주기 진입) |
| CR (변경요청) | 요구사항에 없던 새 동작·개선 요구 | 영향 산정 후 승인 절차 → [[SI 수주와 범위 관리]] |
| 사용법 문의 | 시스템은 합의대로 동작, 사용자가 절차를 모름 | 안내 + 매뉴얼·교육 보강 (반복되면 UX 개선 후보) |

- 판정의 유일한 근거는 **착수 전 합의된 요구사항·검수 기준 문서**다 — 문서에 없으면 "당연히 되는 줄 알았다"는 결함의 근거가 아니다 → [[요구사항과 완료 조건]].
- 이견 시 에스컬레이션 경로를 미리 정한다: 실무 트리아지 → 양측 PM 협의 → 계약 문서 대조 회의. 경로 없이 실무 선에서 밀고 당기면 관계와 일정이 같이 망가진다.
- "결함으로 등록됐지만 사실은 CR"을 무료로 계속 수정해 주는 것은 호의가 아니라 범위 붕괴다 — 작은 것도 CR 기록을 남긴다.

## 수정 확인 — 보고자 환경 기준

- "내 로컬에선 고쳐졌다"는 확인이 아니다. **보고자가 신고한 환경(검수 환경·해당 데이터)에서** 재현 절차를 다시 돌려 통과해야 확인이다.
- 확인 시 회귀 세트를 함께 돈다: 수정 지점 주변 + 같은 기능의 기존 통과 케이스 — 범위 선정은 [[QA 원리]] RCRCRC, 자동화된 회귀는 [[테스트 전략 실전]]. 수정은 새 버그의 산지다(Repaired).
- 수정 확인 후 회귀 테스트를 자산으로 남긴다 — "왜 기존 테스트가 못 잡았나"에 답하는 테스트 → [[디버깅 원리]] 수정 후 3종 세트.

## 결함 지표의 함정 — 건수 목표제는 은폐를 만든다

- "결함 N건 이하" 같은 건수 목표를 팀 평가에 걸면 그날부터 결함은 등록되지 않고 구두로 처리된다 — **추적 밖의 결함이 가장 비싼 결함**이다.
- 볼 만한 신호는 건수가 아니라: 재오픈율(수정 품질), 트리아지 대기 시간(관리 붕괴 신호), 발견 단계 분포(검수·운영에서 발견 비중이 크면 앞 단계 테스트의 구멍).
- 무성 실패 금지가 판정 기준이다 — 알고도 등록하지 않은 결함은 발견 안 된 결함보다 나쁘다.

## 하자보수 기간의 결함

- 무상 하자보수의 범위는 **검수 통과 시점에 합의된 기능 기준**이다 — 검수 시점 스냅샷(요구사항·검수 결과·잔여 결함 목록)이 판정의 정본이 된다 → [[검수·UAT 대응 실전]].
- 하자보수 기간에도 3분류는 동일하게 적용한다: 검수 기준 위반=무상 결함, 신규 요구=유상 CR, 환경 변화(발주사 측 인프라·연동 시스템 변경)로 인한 오동작=협의 대상.
- 운영 중 발생한 긴급 장애의 대응 절차는 결함 관리가 아니라 [[장애 대응 실전]]이다 — 복구 후 원인이 결함으로 판정되면 그때 수명주기에 태운다.

## 안티패턴

- **상태 없는 결함 관리** — 메신저·구두로 접수하고 아무 데도 등록하지 않으면, 종료 시점에 "고쳐줬다/안 고쳤다" 공방만 남는다.
- **개발자 셀프 종결** — 수정자가 확인·종결까지 하면 재오픈율이 보이지 않고, 같은 결함이 검수장에서 다시 터진다.
- **재현 불가 즉시 종결** — 검수 중 발주사가 겪은 결함을 "재현 안 됨"으로 닫으면 신뢰가 죽는다. 정보 요청 + 재현 지원이 먼저다.
- **심각도 인플레이션 방치** — 모든 결함이 치명이면 치명이 없는 것이다. 정의 표로 되돌린다.
- **CR을 결함으로 계속 수용** — 분쟁을 피하려는 무료 수정의 누적이 일정 붕괴의 실체다.

## 관련 문서

- [[00_QA 허브]] — 09_QA 진입점
- [[QA 원리]] — 리포트 품질·심각도/우선순위·회귀 범위(RCRCRC)
- [[디버깅 원리]] — 재현·원인 추적·수정 후 3종 세트
- [[검수·UAT 대응 실전]] — 검수 중 결함 처리 SLA·통과 조건·스냅샷
- [[테스트 전략 실전]] — 회귀 자산화
- [[SI 수주와 범위 관리]] — CR 프로세스·하자보수 경계의 계약 측 정본
- [[요구사항과 완료 조건]] — 결함 판정의 근거 문서
- [[장애 대응 실전]] — 운영 장애의 대응 (결함 관리와 구분)