Brain354. 결함 심각도 (Severity) vs 결함 우선순위 (Priority)
핵심 인사이트 (3줄 요약)
- 본질: 결함 심각도 (Severity)는 결함이 시스템에 미치는 영향의 정도를 나타내며, 결함 우선순위 (Priority)는 결함 수정을 얼마나 빨리 수행해야 하는지를 나타낸다. 두 개념은 다르며, 반드시 일치하지는 않는다.
- 가치: 심각도와 우선순위를 정확히 설정하면 결함 수정의 순서를 적절히 결정하고, 리소스를 효율적으로 배분하며, 프로젝트 성공 가능성을 높일 수 있다.
- 융합: 심각도와 우선순위는 프로젝트 관리, 릴리스 계획, 스프린트 계획에서 활용되며, 심각도는 테스트팀이, 우선순위는 프로젝트 매니저가 결정하는 것이 일반적이다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 결함 심각도 (Severity)는 결함이 시스템의 기능, 성능, 사용성, 신뢰성 등에 미치는 영향의 정도를 나타낸다. 심각도는 주로 테스트팀이나 품질 관리팀에서 평가하며, 기술적 관점에서 결함의 영향도를 평가한다. 결함 우선순위 (Priority)는 해당 결함을 얼마나 빨리 수정해야 하는지를 나타낸다. 우선순위는 비즈니스 관점에서 조사의욕, 출시 일정, 고객 영향도 등을 고려하여 결정한다.
-
필요성: 심각도와 우선순위를 혼동하면 리소스가 잘못 배분되어 중요한 결함이 제때 수정되지 않거나, 긴급하지 않은 결함에 리소스가 과다投入될 수 있다. 예를 들어, 단순한 UI 결함이 우선순위 High로 설정되면 (심각도 Low) 개발 리소스가 잘못 배분될 수 있다.
-
💡 비유: 심각도와 우선순위의 차이는 "지진의震度と被害規模"에 비유할 수 있다.震度(심각도)는地震の規模를 나타내고,被害規模(우선순위)는경제적/사회적 영향을 나타낸다. 대지진(심각도 High)이라도 인구稀疏 지역(우선순위 Low)일 수 있고,中小地震(심각도 Medium)이라도大都市(우선순위 High)일 수 있다.
-
📢 섹션 요약 비유: 심각도와 우선순위의 차이는 "사고の重症度と紧急度"에 비유할 수 있다. 重症度(심각도)는患者の状態の深刻さを意味하고、紧急度(우선순위)는응급실 도착 순서를 결정하는 것이다. 重症でも意識が清明なら(심각도 High + 우선순위 Low)後回しにされる可能性がある。
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
심각도 (Severity) 등급
┌─────────────────────────────────────────────────────────────────┐
│ 결함 심각도 (Severity) 등급 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 1. Critical (치명적) │ │
│ │ │ │
│ │ 정의: 시스템의 핵심 기능 전체가 동작하지 않는 상태 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 결제 기능이 완전히 동작하지 않음 │ │
│ │ • 보안 취약점으로 인해 데이터 유실 위험 │ │
│ │ • 시스템 전체가 다운됨 │ │
│ │ • 데이터 무결성이 완전히 깨짐 │ │
│ │ │ │
│ │ 테스트 관점: 모든 테스트 블럭됨 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 2. High (높음) │ │
│ │ │ │
│ │ 정의: 핵심 기능이严重影响되거나 주요 기능이 동작하지 않는 상태 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 주요 기능의 일부가 동작하지 않음 │ │
│ │ • 심각한 성능 저하 발생 │ │
│ │ • 데이터 손실 없이 일부 기능 마비 │ │
│ │ │ │
│ │ 테스트 관점: 관련된 테스트大部分 실패 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 3. Medium (보통) │ │
│ │ │ │
│ │ 정의: 기능이影响받지만 우회 방법이 있는 상태 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 주요 기능의 일부가影响받지만 우회 가능 │ │
│ │ • UI 표시 문제가 있지만 기능 자체는 동작 │ │
│ │ • 部分적인 성능 저하 발생 │ │
│ │ │ │
│ │ 테스트 관점: 관련된 테스트失敗하지만 其他テストは進行可能 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 4. Low (낮음) │ │
│ │ │ │
│ │ 정의: 미미한 문제로 시스템 동작에 영향을 주지 않는 상태 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • UI 표시 미비 (레이아웃 약간 어긋남 등) │ │
│ │ • 키보드 단축키 동작 안 함 │ │
│ │ • 문서 오탈자 │ │
│ │ • 美観上的 문제 │ │
│ │ │ │
│ │ 테스트 관점: 테스트 진행에 영향 없음 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
우선순위 (Priority) 등급
┌─────────────────────────────────────────────────────────────────┐
│ 결함 우선순위 (Priority) 등급 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 1. Critical / P1 (즉시 수정) │ │
│ │ │ │
│ │ 정의: 즉시 수정이 필요한 매우 긴급한 상태 │ │
│ │ │ │
│ │ 기준: │ │
│ │ • 출시/배포 전 반드시 수정 필요 │ │
│ │ • 비즈니스에 즉각적인 영향 │ │
│ │ • 고객으로부터 긴급 클레임 발생 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 주요 고객이 사용하는 핵심 기능 장애 │ │
│ │ • 규정 준수 문제 발생 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 2. High / P2 (빠른 수정) │ │
│ │ │ │
│ │ 정의: 빠른 시일 내 (현재 스프린트 내) 수정이 필요한 상태 │ │
│ │ │ │
│ │ 기준: │ │
│ │ • 차기 배포 전에 수정이 필요 │ │
│ │ • 상당수의 사용자에게 영향 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 빈번히 사용되는 기능의 주요 부분 결함 │ │
│ │ • 중요한 데이터 처리에 영향 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 3. Medium / P3 (표준 수정) │ │
│ │ │ │
│ │ 정의: 일반적인 우선순위로 정규 일정에 따라 수정 │ │
│ │ │ │
│ │ 기준: │ │
│ │ • 현재 스프린트/반복 내에서 수정 │ │
│ │ • 사용자 그룹에 영향 있으나 우회 가능 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 일반적인 기능 결함 │ │
│ │ • UI 문제 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 4. Low / P4 (낮은 우선순위) │ │
│ │ │ │
│ │ 정의: 수정이Delay되어도 큰 문제가 없는 상태 │ │
│ │ │ │
│ │ 기준: │ │
│ │ • 장기적으로 개선 사항으로 분류 │ │
│ │ • 소수의 사용자에게만 영향 │ │
│ │ • 거의 사용되지 않는 기능의 문제 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 미미한 UI 미비 │ │
│ │ • 문서 오탈자 │ │
│ │ • 低優先度の改善提案 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
심각도와 우선순위의 불일치 사례
┌─────────────────────────────────────────────────────────────────┐
│ 심각도와 우선순위 불일치 사례 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [사례 1: 심각도 High + 우선순위 Low] │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 상황: 핵심 기능의 성능 저하 (심각도 High) │ │
│ │ 이유: 매우 드물게 사용되는 기능이므로 (우선순위 Low) │ │
│ │ 조치: 수정을Delay하여 다른 중요 기능 개발에 리소스 집중 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ [사례 2: 심각도 Low + 우선순위 High] │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 상황: 대량 고객이 사용하는 화면의 오타 (심각도 Low) │ │
│ │ 이유: 출시 전 클레임 발생 예상되므로 (우선순위 High) │ │
│ │ 조치: 빠르게 수정하여 고객 불만 방지 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ [사례 3: 심각도 Medium + 우선순위 Critical] │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 상황: 일부 고객의 정상 동작에 문제가 되는 버그 (심각도 Medium) │ │
│ │ 이유: VIP 고객 관련 기능으로 즉시 수정 필요 (우선순위 Critical) │ │
│ │ 조치: 즉각 수정 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ [결론] │
│ ※ 심각도와 우선순위는 다르며, 각각獨立적으로評価必要 │
│ ※ 심각도는 기술적 영향, 우선순위는 비즈니스 관점에서 평가 │
│ │
└─────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 심각도와 우선순위는 동일한 척도가 아니며, 서로 독립적으로 평가되어야 한다. 심각도 High + 우선순위 Low는 드물게 사용되는 핵심 기능의 성능 저하와 같이, 기술적으로는 중요하지만ビジネスへの影響는 낮은 경우에 해당한다. 심각도 Low + 우선순위 High는 대량 고객이 보는 화면의 오타와 같이, 기술적 영향은 적지만顧客 удовлетворенность에 영향을 미쳐 수정이 긴급한 경우에 해당한다. 이러한 불일치를正しく認識하여 각각適切하게評価하고 대응해야 한다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
심각도/우선순위 매트릭스
┌─────────────────────────────────────────────────────────────────┐
│ 심각도/우선순위 매트릭스 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 우선순위 Low 우선순위 Medium 우선순위 High
│ ┌─────────────┬─────────────┬─────────────┐
│ 심각도 Critical │ P3 │ P2 │ P1 │
│ ├─────────────┼─────────────┼─────────────┤
│ 심각도 High │ P4 │ P3 │ P2 │
│ ├─────────────┼─────────────┼─────────────┤
│ 심각도 Medium │ P4 │ P3 │ P3 │
│ ├─────────────┼─────────────┼─────────────┤
│ 심각도 Low │ None │ P4 │ P4 │
│ └─────────────┴─────────────┴─────────────┘
│ │
│ 매트릭스 활용 가이드: │
│ • P1: 即座修正、全リソース投入 │
│ • P2: 速やかに修正、優先的にリソース配分 │
│ • P3: 定常プロセスで修正 │
│ • P4: 改善事項としてBacklogに积み │
│ • None: 修正不要 (Invalid, Duplicate 등) │
│ │
└─────────────────────────────────────────────────────────────────┘
릴리스 의사결정에 활용
| 상황 | 심각도 | 우선순위 | 릴리스 결정 |
|---|---|---|---|
| 치명적 결함 있음 | Critical | Critical | 배포延期 필수 |
| 높은 우선순위 결함 있음 | - | High | 수정 후 배포 |
| 중간 우선순위 결함 있음 | - | Medium | 상황에 따라 판단 |
| 낮은 우선순위 결함만 있음 | - | Low | Deploy 가능 |
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
심각도/우선순위 설정 가이드라인
| 구분 | 결정자 | 고려 사항 | 설정 시점 |
|---|---|---|---|
| 심각도 | 테스트팀/품질팀 | 기능への影響,影響範囲,修复难度 | 결함 발견 시 |
| 우선순위 | 프로젝트 매니저/스토크홀더 | 비즈니스 중요도, 출시 일정, 고객 영향 | 심각도 평가 후 |
주의사항
- 심각도와 우선순위의 혼동 금지: 기술적 영향과 비즈니스 긴급도를 구분
- 일관된 기준 적용: 팀 내 심각도/우선순위 기준 공통화
- 정기적 재평가: 상황 변화에 따라 심각도/우선순위 재조정
- 과잉 분류 지양: 모든 결함을 High/Critical로 설정하지 말 것
- 📢 섹션 요약 비유: 심각도와 우선순위는 "응급실 triage"에 비유할 수 있다. 患者의 중증도(심각도)는医学的に평가되고, 응급실 도착 순서(우선순위)는医療자원의 효율적 활용을 위해 결정된다. 重症でも状態が安定していれば(심각도 High + 우선순위 Low) 다른重症患者를 먼저 치료할 수 있다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
AI 기반 심각도/우선순위 추천
- 머신러닝 기반 분류: 과거 결함 데이터를 학습하여 심각도/우선순위 자동 추천
- 텍스트 분석: 결함 설명에서 주요 단어을 추출하여 분류
- 유사 결함 분석: 유사한 과거 결함의 분류 결과를 참고하여 추천
향후 동향
- 자동화된 분류: AI가 결함 등록 시 자동으로 심각도/우선순위 제안
- 실시간 재조정: 상황 변화에 따라 자동으로 우선순위 재조정
- 통합 의사결정 지원: 다양한 데이터를 종합하여 릴리스 의사결정 지원
- 📢 섹션 요약 비유: 심각도와 우선순위 관리는 "재난 대응 체계"에 비유할 수 있다. 재해의 규모(심각도)는地震의 크기로評価되고,救援の紧急度(우선순위)는 survivor 현황, resources 가용량 등을 고려하여 결정된다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────┐
│ 심각도 vs 우선순위 비교 핵심 정리 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 심각도 (Severity) │ │ 우선순위 (Priority) │ │
│ ├──────────────────┤ ├──────────────────┤ │
│ │ 결정자: 테스트팀 │ │ 결정자: 프로젝트 │ │
│ │ │ │ 매니저 │ │
│ │ 고려: 기술적 영향 │ │ 고려: 비즈니스 │ │
│ │ - 기능への影響 │ │ 중요도 │ │
│ │ - 영향 범위 │ │ - 출시 일정 │ │
│ │ -修复难度 │ │ - 고객 영향 │ │
│ │ │ │ │ │
│ │ 평가 시점: │ │ 평가 시점: │ │
│ │ 결함 발견 시 │ │ 심각도 평가 후 │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ ※ 심각도와 우선순위는 다르고, 독립적으로 평가되어야 함 │
│ │
└─────────────────────────────────────────────────────────────────┘
참고
- 모든 약어는 반드시 전체 명칭과 함께 표기:
API (Application Programming Interface) - 일어/중국어 절대 사용 금지 (한국어만 사용)
- 각 섹션 끝에 📢 요약 비유 반드시 추가
- ASCII 다이어그램의 세로선 │와 가로선 ─ 정렬 완벽하게
- 한 파일당 최소 800자 이상의 실질 내용