개념
Critical은 우선순위의 값이 아니다
모듈 6 레슨 1에서 심각도와 우선순위가 다른 축이라는 것과, 2x2 매트릭스의 네 조합을 배웠다. 개념은 거기서 끝났다. 이 레슨은 그 개념이 도구에서 왜 무너지는가 를 다룬다.
Jira를 열어보자. 이슈에 Priority(우선순위) 필드가 있고, 값이 보통 이렇게 되어 있다.
Blocker / Critical / Major / Minor / Trivial여기서 이상한 점을 알아챌 수 있어야 한다. 이 다섯 단어는 전부 "얼마나 망가졌는가"를 말하는 단어다. "얼마나 급한가"를 말하는 단어가 아니다. Critical은 심각도의 언어이고, 우선순위의 언어는 "지금 / 이번 스프린트 / 다음 분기 / 나중에"다.
즉 많은 조직이 우선순위 필드에 심각도 값을 넣어 쓰고 있다. 심각도 라벨이 우선순위 옷을 입고 있는 셈이다.
표준은 둘을 나눠 둔다
IEEE 1044(소프트웨어 이상 분류 표준)는 이상(anomaly)에 붙이는 속성들을 정의하는데, 심각도(Severity)와 우선순위(Priority)를 별도 속성으로 둔다. 심각도 식별은 필수 범주이고, 우선순위는 다른 모든 영향 범주를 고려한 주관적 순위 로 규정한다.
이 정의에서 두 가지를 읽을 수 있다.
심각도 영향을 보고 판정한다. 비교적 객관적이다
→ 같은 결함이면 누가 봐도 비슷한 값이 나온다
우선순위 "다른 모든 것을 고려한" 순위다. 주관적이라고 명시되어 있다
→ 일정·고객·계약·시장 상황에 따라 달라진다표준이 우선순위를 "주관적"이라고 명시한 것 이 중요하다. 그건 흠이 아니라 성질이다. 우선순위는 판단이고, 판단은 상황이 바뀌면 바뀐다.
두 축의 성질 차이
| 심각도 (Severity) | 우선순위 (Priority) | |
|---|---|---|
| 묻는 것 | 얼마나 망가졌는가 | 언제 고칠 것인가 |
| 판정 주체 | QA·기술 판단 | PM·PO·비즈니스 판단 |
| 성질 | 비교적 객관적 | 주관적(표준 명시) |
| 변동성 | 한 번 정하면 거의 안 바뀐다 | 상황에 따라 계속 바뀐다 |
| 근거 | 영향 범위, 데이터 손상, 우회로 유무 | 일정, 고객, 계약, 매출, 리스크 |
변동성 차이가 필드를 나눠야 하는 결정적 이유다. 심각도는 결함 자체의 성질이라 릴리즈가 바뀌어도 그대로다. 우선순위는 스프린트마다 바뀐다. 한 필드에 두면 바뀌는 값이 안 바뀌는 값을 덮어쓴다.
[한 필드일 때 벌어지는 일]
1주차: 결제 실패 결함 → Critical 등록
3주차: 데모 일정 때문에 다른 것부터 → Major로 낮춤
→ 결함의 심각도가 낮아진 게 아니다. 순서만 미뤘을 뿐인데
기록상으로는 "덜 심각한 결함"이 되어버렸다
6주차: 릴리즈 직전 집계 → "Critical 결함 0건" 이라고 보고됨 ← 거짓심각도 이력이 우선순위 조정에 의해 파괴된다. 이게 한 필드 운영의 가장 비싼 대가다.
왜 도구는 이렇게 되어 있나
Jira는 초기에 심각도를 기본 필드에서 뺐다. 대부분의 사용자가 심각도를 잘못 판단한다는 판단이었다고 알려져 있다. 그 결과 하나 남은 Priority 필드에 심각도 성격의 기본값이 들어가게 됐다.
문제는 파급이다. 많은 사람이 표준보다 Jira를 먼저 배웠다. 도구의 기본값이 사실상 교과서 역할을 하면서, "우선순위 = Blocker/ Critical/Major"라는 인식이 업계 전반에 자리 잡았다. 레슨 1에서 말한 '원인 ① — 도구가 먼저 가르쳤다'의 대표 사례다.
도구가 Severity 필드를 안 줄 때
문제를 알았다고 필드가 생기지는 않는다. 도구가 기본으로 주는 것이 선택지를 제한한다.
| 도구 | 기본 제공 | 현실적 대응 |
|---|---|---|
| Jira | Priority 만 | 커스텀 필드로 Severity 추가. 필드 스킴·화면·권한까지 함께 손댄다 |
| GitHub Issues | 둘 다 없음. 라벨뿐 | sev/S1·pri/P1 처럼 접두어 라벨 두 묶음 으로 나눈다 |
| Azure DevOps | 둘 다 기본 제공 | 드물다. 대신 둘 다 비어 있는 이슈가 쌓인다 |
외주·수탁에서는 설정 권한이 발주처에 있다. 선택은 둘이다. [A] 커스텀 필드 추가 — 권한이 있고 추세를 쓸 사람이 있을 때. 비용은 관리자 작업, 기존 이슈 일괄 처리, 참조처 점검이다. [B] 한 필드 유지 — 권한이 없을 때. 순서·기한은 백로그 순서로 관리한다.
[B]의 요점은 "하나만 쓴다" 가 아니라 "그 하나가 어느 축인지 문서에 적는다" 는 것이다. 축을 정하지 않은 한 필드가 가장 나쁘다.
필드를 하나로 합치면 잃는 것 셋
[B]를 고를 때는 무엇을 포기하는지 알아야 한다.
| 잃는 것 | 구체적으로 |
|---|---|
| 집계 | 릴리즈 판정과 스프린트 계획이 같은 숫자를 공유한다 |
| 추세 | 등급별 추세가 제품 품질의 것인지 팀 운영의 것인지 구별되지 않는다 |
| 변경 이력 | 이력에 "Critical → Major" 만 남아 심각도를 깎은 것인지 순서를 미룬 것인지 알 수 없다 |
셋 중 추세가 가장 늦게 발견된다 — 반년 뒤 "작년 대비 나아졌나" 라는 질문 앞에서다.
진단 — 우리 팀은 어느 상태인가
□ Priority 필드 값이 Blocker/Critical/Major/Minor/Trivial 이다
□ Severity 필드가 없다
□ "우선순위를 Critical로 올렸다"는 말을 쓴다
□ 릴리즈 일정 때문에 Priority를 내린 적이 있다
□ "Critical 결함 0건"을 릴리즈 판정 기준으로 쓴다
□ 트리아지 회의에서 "이게 왜 Critical이냐"는 논쟁이 반복된다
3개 이상 해당하면 두 축이 한 필드에 섞여 있다.마지막 항목이 특히 진단적이다. 그 논쟁의 정체는 대부분 "심각도 얘기를 하는 사람과 우선순위 얘기를 하는 사람이 같은 필드를 두고 대화하는 것" 이다. 축이 나뉘면 논쟁 자체가 사라진다.
재설계 — 필드를 둘로 나눈다
실무에서 검증된 구성은 이렇다.
① 기본 Priority 필드는 유지하되, 값을 진짜 긴급도 언어로 바꾼다
Blocker/Critical/Major/Minor/Trivial
↓
P1 / P2 / P3 / P4 (또는 "즉시 / 이번 릴리즈 / 다음 릴리즈 / 백로그")
② Severity 커스텀 필드를 추가한다
Blocker / Critical / Major / Minor / Trivial
→ QA가 트리아지 시점에 정하고, 이후 거의 바꾸지 않는다
③ 심각도 → 권장 우선순위 매트릭스를 만든다
→ 트리아지가 빈 칸에서 시작하지 않게 한다①에서 값 이름을 바꾸는 것이 핵심이다. 필드만 추가하고 Priority 값을 그대로 두면 사람들이 계속 혼동한다. 이름이 바뀌어야 인식이 바뀐다.
각 필드의 값 정의
값에 기준이 없으면 다시 주관 논쟁이 된다. 정의를 붙인다.
심각도 (QA가 판정)
| 값 | 기준 |
|---|---|
| Blocker | 시스템·핵심 기능이 전면 사용 불가. 테스트 진행 자체가 막힘 |
| Critical | 핵심 기능 실패, 데이터 손상·유실, 보안 노출. 우회로 없음 |
| Major | 주요 기능 실패하나 우회로 존재. 또는 일부 사용자에게만 발생 |
| Minor | 부가 기능 이상, 사용성 저하. 업무 수행에 지장 없음 |
| Trivial | 오탈자, 정렬 어긋남 등 표시 수준 |
판정 근거를 세 가지로 고정하면 편차가 줄어든다 — 영향 범위(몇 명), 데이터 영향(손상·유실 여부), 우회로 유무.
우선순위 (PO·PM이 판정)
| 값 | 기준 |
|---|---|
| P1 | 즉시. 진행 중인 작업을 멈추고 착수 |
| P2 | 이번 릴리즈 안에 반드시 |
| P3 | 다음 릴리즈 목표 |
| P4 | 백로그. 여유가 생기면 |
정의는 판정 가능한 문장으로 쓴다
위 표의 기준이 작동하는 이유는 형용사가 아니라 관측 가능한 조건 으로 쓰였기 때문이다.
| 약한 정의 | 판정 가능한 정의 | 예시 결함 |
|---|---|---|
| "심각한 영향" | 핵심 흐름이 막히고 우회로가 없다 | 결제 요청이 서버 오류로 떨어진다 |
| "중요한 기능의 오류" | 주요 기능이 실패하나 다른 경로로 수행 가능 | 목록 검색 실패, 상세 주소 접근은 된다 |
정의마다 우리 제품의 예시 결함을 붙인다. 사람은 정의보다 자기가 아는 결함과 비교해서 판정하기 때문이다.
판정이 사람마다 달라지는 것을 줄이는 세 장치
정의를 붙여도 편차는 남는다. 편차를 지우려 하기 전에 재는 것 부터다.
① 예시 결함 사전(앵커) 등급마다 우리 제품의 실제 결함 2~3건을 박아 둔다
② 샘플 교정(월 1회 20분) 닫힌 결함 10건을 등급 지운 채 각자 판정한다
→ 일치율을 센다. 70% 미만이면 예시가 부족한 것이다
③ 이견 처리 규칙 한 단계 차이 → 등록자 값을 유지한다
두 단계 이상 → 리드가 판정하고 앵커에 추가한다②의 일치율 숫자가 핵심이다. "우리 팀은 등급을 잘 붙인다" 는 믿음은 대개 측정된 적이 없다. 한 번 재 보면 Major와 Minor 경계에서 절반이 갈리는 것이 보통이고, 그 경계에만 예시를 보강하면 된다. 완벽한 일치보다 일관된 기준이 추세에 더 중요하다 — 모두가 한 단계 낮게 보는 팀의 그래프는 쓸 수 있지만, 사람마다 다르게 보는 팀의 그래프는 못 쓴다.
심각도 → 권장 우선순위 매트릭스
트리아지를 빈 칸에서 시작하지 않게 하는 장치다.
| 심각도 \ 상황 | 기본 권장 | 상향 요인 | 하향 요인 |
|---|---|---|---|
| Blocker | P1 | — | (거의 없음) |
| Critical | P1 | 결제·보안·데이터 | 발생 빈도 극히 낮음 |
| Major | P2 | 다수 사용자·주요 고객 | 우회로 안내 가능 |
| Minor | P3 | 데모·마케팅 일정 | — |
| Trivial | P4 | 대외 노출 화면 | — |
"기본 권장"은 출발점일 뿐 확정이 아니다. 상향·하향 요인이 있으면 조정하고, 조정한 이유를 코멘트에 남긴다. 이 한 줄이 나중에 "왜 이건 안 고쳤냐"는 질문에 답한다.
매트릭스가 만드는 네 조합, 다시
모듈 6 레슨 1의 2x2 중 필드가 하나이면 표현 자체가 불가능해지는 두 칸 만 다시 본다.
심각도 높음 + 우선순위 낮음 연 1회 결산 화면 크래시
→ Critical 그대로 두고 P3 ★
심각도 낮음 + 우선순위 높음 내일 데모용 로고 오류
→ Trivial 그대로 두고 P1 ★★ 두 칸이 필드 분리의 존재 이유다. 심각도를 낮추지 않고 순서만 미룰 수 있어야 한다. 한 필드로는 불가능하다.
외부 조직과 등급이 다를 때 — 매핑표
사내에서 축을 나눠도 발주처·협력사의 등급 체계는 우리와 다르다. 공공 SI·SM 계약에서는 발주처의 4단계 장애등급을 쓰고 우리는 5단계를 쓰는 식이다.
| 발주처 장애등급 | 계약서상 정의 | 우리 심각도 | 주의 |
|---|---|---|---|
| 1급 | 서비스 전면 중단 | Blocker | 대개 일치한다 |
| 2급 | 주요 업무 처리 불가 | Critical | 우리 Blocker 일부도 2급으로 접수된다 |
| 3급 | 부분 기능 장애, 우회 가능 | Major | 가장 넓은 칸. 분쟁이 난다 |
| 4급 | 단순 오류·문의 | Minor + Trivial | 두 등급이 한 칸으로 합쳐진다 |
마지막 두 줄이 문제의 전부다. 우리 5단계를 4단계로 보내는 것은 되지만 받아올 때 복원되지 않는다. "4급 12건" 안에 Minor와 Trivial이 몇 건씩인지 알 수 없다. 매핑은 양방향이 아니다 는 전제로 운영한다.
분쟁은 이렇게 난다. 우리가 "Critical 3건 미해결" 로 보고하면 발주처는 "2급 3건, 계약상 4시간 내 복구 대상" 으로 읽는다. 우회로가 있어 우리는 P3로 두었는데 SLA 위반 통보의 근거가 우리가 보낸 숫자가 된다.
막는 방법은 둘이다. 등급 이름만 보내지 않고 판정 근거 한 줄을 같이 보낸다. 그리고 매핑표를 품질 합의서에 박아 둔다.
마이그레이션 — 기존 데이터는 어떻게 하나
이미 수천 건이 쌓여 있는 경우가 보통이다.
[전환 계획]
1. Severity 커스텀 필드를 만든다 (기본값 없음)
2. 기존 Priority 값을 Severity로 일괄 복사한다
→ 지금까지의 Priority는 사실상 심각도였으므로 이 복사가 맞다
3. Priority 값 이름을 P1~P4로 바꾸고 기존 값을 매핑한다
Blocker/Critical → P1, Major → P2, Minor → P3, Trivial → P4
4. 열린 이슈만 트리아지에서 재검토한다 (닫힌 건 그대로 둔다)
5. 대시보드·필터·자동화 규칙에서 Priority를 참조하는 곳을 점검한다 ★
6. 리포트 템플릿에 두 필드를 모두 넣는다★ 5단계가 가장 자주 사고를 낸다. "Priority = Critical"로 걸어둔 알림 자동화, 대시보드 필터, SLA 규칙이 값 이름을 바꾸는 순간 조용히 동작을 멈춘다. 바꾸기 전에 참조처를 전부 찾는다.
등급 체계를 바꾸면 추세가 끊긴다
참조처 다음으로 비싼 것은 과거와 비교할 수 없게 되는 것 이다. 축을 나눈 날 전후의 데이터는 같은 그래프에 올릴 수 없다.
| 선택 | 하는 일 | 언제 고르나 |
|---|---|---|
| 소급 재판정 | 과거 이슈를 새 체계로 다시 라벨링(1,000건에 수십 시간) | 감사에서 과거 기간의 심각도 증빙을 요구받는다 |
| 기계적 복사 | 과거 Priority를 Severity로 옮긴다 | 과거 Priority가 사실상 심각도였다(대부분) |
| 단절 기록 | 과거는 그대로 두고 전환 시점만 표시한다 | 추세 독자가 분기 리포트 독자뿐이다 |
대부분은 두 번째와 세 번째를 함께 고른다. 기계적 복사로 Severity 칸을 채우고, 대시보드와 분기 리포트에 전환 날짜 한 줄과 이전 기간 값의 출처 한 줄 을 남긴다. 이 기록이 없으면 반년 뒤 누군가 그래프의 꺾인 지점을 품질 개선으로 읽는다. 모듈 6 레슨 5의 지표들이 전부 이 단절에 걸린다.
정착시키는 법
도구 설정을 바꾸는 것보다 사람이 두 필드를 다 채우게 만드는 것 이 어렵다.
- Severity를 필수 필드로 만든다 (QA가 등록 시 반드시 입력)
- Priority는 트리아지 전까지 비워둔다 → PO가 채운다
→ "누가 채우는 필드인가"가 분명해진다
- 트리아지 회의 화면에 매트릭스를 띄워둔다
- 릴리즈 판정 기준을 두 축으로 다시 쓴다
예: "Blocker·Critical 심각도의 미해결 결함 0건" (심각도 기준)
"P1 미해결 0건" (우선순위 기준)마지막 항목이 중요하다. 릴리즈 판정 기준을 심각도로 쓸지 우선순위로 쓸지 정해야 한다. 대개 심각도 기준이 안전하다 — 우선순위는 조정 가능하지만 심각도는 제품의 상태 그 자체이기 때문이다.
사례 — 한 필드로 버틴 6개월의 청구서
금융 계열사 내부 시스템 SM 팀이다. Jira에 Priority 한 필드만 있었고, 6개월간 등록된 결함이 1,240건 이었다.
실패. 상반기 보고에 "Critical 미해결 0건" 으로 올렸는데, 발주처 검수에서 2급 장애에 해당하는 미해결 결함 3건 이 지적됐다.
원인. 이력에 Critical에서 Major로 내린 건이 11건 있었고 그중 3건이 지적된 결함이었다. 사유는 전부 일정이었다. 내릴 자리가 우선순위밖에 없어서 심각도를 내린 것이다.
바꾼 것. Severity를 필수 커스텀 필드로 추가하고(기존 1,240건은 당시 Priority를 복사), Priority 값을 P1~P4로 바꾸며 참조처 17곳 을 먼저 고쳤고, 발주처 4단계 매핑표를 품질 합의서에 첨부했다.
결과. 다음 반기에 등급 이견이 월 평균 9건에서 2건 으로 줄고 샘플 교정 일치율이 62%에서 88% 로 올랐다. 검수 보완 요구는 0건이었다.
- "Critical 0건" 은 심각도 필드가 따로 있을 때만 참이 될 수 있다. 필드가 하나면 그 숫자는 품질이 아니라 일정의 결과다
- 참조처 17곳이 작업량의 대부분이었다. 필드를 나누는 일은 개념 작업이 아니라 설정 작업이고, 매핑표도 문서에 박아야 효력이 있다
실무에서 왜 필요한가
반복 논쟁이 사라진다
트리아지의 "이게 왜 Critical이냐"는 대화는 대부분 두 사람이 서로 다른 축을 말하고 있어서 생긴다. QA는 "데이터가 깨진다"(심각도)를 말하고, PM은 "이번 스프린트에 못 넣는다"(우선순위)를 말한다. 둘 다 옳고, 필드가 하나라 충돌한 것뿐이다.
릴리즈 판정이 거짓말을 하지 않는다
"Critical 0건"이 일정 압박으로 값을 내려서 만들어진 숫자라면 그 판정은 거짓이다. 심각도가 독립 필드면 이 조작이 불가능해진다.
품질 추세가 보인다
심각도별 결함 추세는 제품 품질의 지표다. 우선순위별 추세는 팀 운영의 지표다. 두 그래프가 다른 것을 말한다. 한 필드일 때는 이 분리가 불가능하다.
규제·감사 대응이 쉬워진다
안전·의료·금융처럼 감사를 받는 도메인에서는 "심각한 결함을 어떻게 처리했는가" 를 증명해야 한다. 심각도가 조정 가능한 필드면 증명이 성립하지 않는다. 모듈 25에서 다룬 도메인 규격들이 요구하는 추적성의 기초가 이것이다.
채용시장에서의 위치
모듈 6 레슨 1의 두 축 개념 은 신입 면접의 기본 문항이다. 이 레슨의 범위는 그 다음 — 도구에서 어떻게 구현했는가 이고, 경력 2~3년 이상 QA 리드 포지션에서 나온다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "Jira 기본 우선순위 값의 문제는?" | "문제는 없습니다" | "다섯 값이 전부 심각도의 언어입니다. 우선순위 필드에 심각도가 들어가 있습니다" |
| "도구에 Severity 필드가 없으면요?" | "Priority로 대신 씁니다" | "커스텀 필드를 추가하거나, 권한이 없으면 그 필드가 심각도임을 문서에 못 박고 순서는 백로그로 관리합니다" |
| "두 필드를 합치면 뭘 잃습니까?" | "구분이 안 됩니다" | "집계·추세·변경 이력입니다. 한 번의 편집으로 사실과 일정이 동시에 바뀝니다" |
| "발주처 등급이 다르면요?" | "맞춰서 보고합니다" | "매핑표를 품질 합의서에 첨부하고 등급과 함께 판정 근거를 보냅니다. 4단계로 보내면 복원이 안 되니까요" |
| "체계를 바꿀 때 과거 데이터는요?" | "전부 다시 라벨링합니다" | "열린 건만 재검토하고, 과거 값은 복사한 것임을 전환 기록으로 남깁니다" |
가장 변별력이 큰 것은 다섯 번째다. 앞의 네 개는 읽어서 알 수 있지만, 다섯 번째는 데이터로 리포트를 내 본 사람만 하는 걱정 이다. "전부 다시 라벨링한다" 는 답은 성실해 보이지만 1,000건을 재판정하는 비용을 계산해 본 적이 없다는 뜻으로 읽힌다. "전환 시점을 표시한다" 는 답은 그래프를 읽는 사람이 있다는 것을 알고 있다 는 신호다.
두 번째도 실행 경험을 가린다. "커스텀 필드를 추가한다" 까지는 많이 말하지만 권한이 없는 상황 을 답에 넣는 사람은 적다. 공고의 "QA 프로세스 설계"·"이슈 트래킹 체계 구축" 이 이 레슨에 걸리고, 결함을 등록하는 능력이 아니라 데이터가 쌓이는 구조를 설계하는 능력 으로 평가된다.