개념
결함을 찾는 것과 결함이 고쳐지게 만드는 것은 다른 일이다. 이 모듈은 후자를 다루고, 이 레슨은 그 출발점이다.
응급실을 떠올리면 이 레슨의 두 축이 한 번에 잡힌다. 환자가 들어오면 간호사가 "얼마나 위험한가" 를 보고(심각도), 의사는 "누구를 먼저 보는가" 를 정한다(우선순위). 둘은 대개 같이 가지만 항상 같지는 않다 — 상태가 안정된 중증 환자보다, 당장 숨이 막히는 경증 환자를 먼저 보는 순간이 있다.
그리고 환자는 접수 → 진료 → 처치 → 경과 관찰 → 퇴원이라는 정해진 단계를 거친다. 결함도 똑같다. "버그 있어요" 라고 말로 전하고 끝내면 그 결함은 아무 단계에도 들어가지 않았으므로 고쳐질 가능성이 운에 달린다.
결함의 생명주기
모듈 1(레슨 2)에서 오류(error)·결함(defect)·실패(failure)를 구분했다. 결함이 발견되면 그걸로 끝이 아니다 — 팀 안에서 정해진 상태를 거쳐 종결될 때까지 추적된다. 흔히 쓰이는 흐름은 다음과 같다.
New(신규)
→ Assigned(담당자 배정)
→ In Progress(수정 중)
→ Fixed(수정 완료)
→ Retest(재검증)
→ Closed(종결)재검증 단계에서 문제가 남아 있으면 두 갈래로 갈린다.
- Reopened(재오픈): 수정했다고 했지만 재검증 결과 여전히 재현된다 → 다시 In Progress로 되돌아간다
- Rejected(반려): 애초에 결함이 아니다(의도된 동작, 재현 불가, 환경 문제 등) → 별도 상태로 종결
- Duplicate(중복): 이미 등록된 다른 결함과 같은 것 → 원본 결함에 병합하고 종결
상태마다 누가 무엇을 하나
흐름만 외우면 실무에서 막힌다. 각 상태에서 공이 누구 손에 있는지가 중요하다.
| 상태 | 공을 든 사람 | 그 사람이 할 일 |
|---|---|---|
| New | 등록자(대개 QA) | 재현 절차·증거를 빠짐없이 적는다 |
| Assigned | 리드·PM | 담당자와 우선순위를 정한다 |
| In Progress | 개발자 | 원인을 찾아 고친다 |
| Fixed | 개발자 | 무엇을 어떻게 고쳤는지 남긴다 |
| Retest | QA | 원 절차를 다시 밟아 확인한다 |
| Closed | — | 끝. 통계에 들어간다 |
Fixed 칸의 "무엇을 어떻게 고쳤는지" 가 자주 빈다. 비어 있으면 QA가 재검증할 때 어디를 더 봐야 하는지 모른다. "조건문 수정" 한 줄만 있어도 재검증 범위가 달라지므로, QA는 이 기록을 요청할 자격이 있다.
상태는 적을수록 좋다
도구를 쓰다 보면 상태가 자꾸 늘어난다. "Pending", "On Hold", "Need Info", "Verified", "Deferred"… 그런데 상태가 많아지면 아무도 정확히 쓰지 않는다.
- 상태 5개짜리 흐름은 사람들이 외워서 쓴다
- 상태 12개짜리 흐름은 설명 문서를 봐야 하고, 결국 안 본다
- 쓰이지 않는 상태가 섞이면 통계가 못 쓰게 된다
새 상태를 만들기 전에 물어야 할 것은 "이 상태가 없으면 어떤 결정을 못 하나" 다. 답이 안 나오면 필요하지 않은 상태다.
하나만 예외로 둘 만한 것이 "정보 필요(Need Info)" 다. 재현 정보가 부족해 개발자가 손을 못 대는 상태는 실제로 자주 생기고, 이것을 In Progress로 두면 고치는 중인 것처럼 보여서 숫자가 거짓이 된다.
Rejected의 네 가지 얼굴
반려는 한 가지가 아니다. 사유마다 QA가 해야 할 다음 행동이 다르다.
| 반려 사유 | 실제 의미 | QA의 다음 행동 |
|---|---|---|
| 의도된 동작 | 기획대로다 | 문서를 확인한다. 문서에 없으면 "문서 공백"으로 따로 올린다 |
| 재현 불가 | 개발 환경에서 안 난다 | 환경·계정·데이터를 맞춰 다시 시도(레슨 2) |
| 환경 문제 | 테스트 환경 탓 | 환경 이슈로 전환. 결함 통계에서 빠진다 |
| 사양 변경 예정 | 곧 없어질 화면 | 언제 없어지는지를 받아 적고 그때까지 추적 |
첫 줄이 가장 중요하다. "의도된 동작" 으로 반려됐을 때 문서에 그 내용이 없다면 결함이 아니라 더 큰 문제다. 다음에 누가 봐도 같은 혼란이 생기고, 실제로는 아무도 그게 의도인지 모르는 상태일 수 있다.
Duplicate — 어느 쪽을 원본으로 둘까
중복이 뜨면 보통 "먼저 등록된 것" 을 남긴다. 그런데 나중 것이 더 잘 쓰여 있을 때가 있다.
- 재현 절차가 더 정확한 쪽을 원본으로 삼고, 다른 쪽을 닫는다
- 닫는 쪽에 원본 링크를 반드시 남긴다
- 양쪽의 증거(화면·로그)는 원본으로 옮긴다
링크를 안 남기면 나중에 "그 버그 어디 갔지" 가 되고, 같은 결함이 세 번째로 등록된다. 중복이 반복되는 영역은 그 자체가 신호다 — 여러 사람이 같은 것을 계속 발견한다면 사용자도 그만큼 자주 만난다는 뜻이다.
재검증은 모듈 1(레슨 4)의 "확인"이다
Retest 단계는 모듈 1(레슨 4)에서 배운 확인(Confirmation Testing) 그 자체다 — 개발자가 "고쳤다"고 보고한 것을 그대로 믿지 않고, 원래 결함을 재현했던 정확한 절차를 다시 밟아 실제로 사라졌는지 QA가 직접 확인한다.
재검증에서 볼 것은 세 가지다. 첫 번째만 하고 닫는 경우가 많다.
- 원래 절차 — 적어 둔 그대로. 한 단계도 바꾸지 않는다
- 주변 조건 — 다른 계정·다른 데이터·다른 브라우저에서도 사라졌나
- 옆에 붙은 기능 — 고치는 과정에서 다른 것이 깨지지 않았나(회귀)
2번이 특히 값지다. 특정 계정에서만 고쳐진 수정이 실제로 있다. 조건을 하나도 바꾸지 않고 통과하면 "그 조건에서는 고쳐졌다" 까지만 증명된다.
Reopened가 반복되면 그것은 신호다
같은 결함이 두 번 넘게 재오픈되면 그 결함 하나의 문제가 아니다.
| 재오픈 횟수 | 대개의 원인 | 해야 할 일 |
|---|---|---|
| 1회 | 흔하다. 조건을 좁게 잡아 고쳤다 | 재현 조건을 더 자세히 전달 |
| 2회 | 원인을 아직 못 찾았다 | 증상만 막고 있는지 함께 확인 |
| 3회 이상 | 문제를 서로 다르게 이해하고 있다 | 얼굴 보고 같은 화면에서 재현한다 |
세 번째 줄에서 리포트를 더 자세히 쓰는 것은 효과가 없다. 글이 아니라 같이 보는 것이 답이고, 레슨 3의 비난 없는 소통이 여기서 쓰인다.
심각도(Severity)와 우선순위(Priority)는 다른 축이다
이 둘을 같은 말로 혼동하는 경우가 많지만, 실무에서는 명확히 다른 두 질문에 대한 답이다.
| 축 | 질문 | 누가 정하는가 |
|---|---|---|
| 심각도 | 이 결함이 시스템에 얼마나 나쁜 영향을 주는가? | QA가 기술적으로 판단 |
| 우선순위 | 이 결함을 얼마나 빨리 고쳐야 하는가? | 비즈니스 관점에서 팀/PM이 판단 |
심각도는 "결함 자체의 무게"이고, 우선순위는 "지금 상황에서 이걸 먼저 고칠지 말지에 대한 줄서기 순서"다. 둘은 대체로 비례하지만, 항상 같이 움직이지는 않는다 — 이게 이 레슨의 핵심이다.
심각도 등급을 어떻게 나누나
팀마다 이름은 다르지만 뼈대는 비슷하다. 네 단계가 가장 흔하다.
| 등급 | 뜻 | 판단 기준 |
|---|---|---|
| S1 치명 | 서비스를 못 쓴다 | 핵심 흐름이 아예 막힌다. 우회로가 없다 |
| S2 중대 | 주요 기능이 안 된다 | 되지만 우회로가 필요하거나 데이터가 틀린다 |
| S3 보통 | 불편하지만 쓸 수 있다 | 화면이 어색하거나 드문 조건에서만 난다 |
| S4 경미 | 거의 영향 없다 | 오탈자, 미세한 정렬 |
경계가 애매할 때 물을 것은 "우회로가 있는가" 다. 안 되지만 다른 길로 갈 수 있으면 S2, 아예 길이 없으면 S1이다. 이 한 줄이 S1/S2 논쟁의 절반을 줄인다.
데이터가 틀리는 결함은 한 단계 올린다. 화면이 안 나오는 것은 사용자가 알아채지만, 금액이 100원 틀린 것은 아무도 모른 채 쌓인다. 나중에 되돌리는 비용이 훨씬 크다.
우선순위 등급과 그 뒤에 있는 약속
우선순위는 심각도와 달리 언제까지 고친다는 약속을 담는다.
| 등급 | 보통의 약속 | 대표 상황 |
|---|---|---|
| P1 즉시 | 당일. 필요하면 긴급 배포 | 결제 불가, 로그인 불가, 데이터 유실 |
| P2 높음 | 이번 스프린트 안 | 주요 기능 오류 |
| P3 보통 | 다음 스프린트 | 불편 사항 |
| P4 낮음 | 여유 있을 때 | 개선 희망 |
P4가 사실상 "안 고친다" 라는 것을 서로 아는 게 낫다. 솔직하지 않으면 P4 목록이 수백 건 쌓이고, 그 목록은 아무도 보지 않는 묘지가 된다. 레슨 5에서 다룰 결함 지표가 이 지점에서 왜곡된다.
그리고 P1은 희소해야 힘이 있다. 모든 것이 P1이면 아무것도 P1이 아니다. P1을 한 달에 몇 건 쓰는지 세어 보면 그 팀의 우선순위 체계가 살아 있는지 바로 알 수 있다.
2x2 매트릭스로 보는 네 가지 조합
| 우선순위 높음 | 우선순위 낮음 | |
|---|---|---|
| 심각도 높음 | 결제 실패로 주문 자체가 안 됨 → 즉시 수정 | 연 1회 결산 화면 크래시(다음 결산까지 시간 있음) → 심각하지만 급하지 않음 |
| 심각도 낮음 | 로그인 화면 로고가 회사명과 다른 로고로 표시(내일 투자자 데모) → 사소하지만 지금 당장 급함 | 설정 페이지 오탈자 하나 → 심각하지도 급하지도 않음 |
심각도 높음·우선순위 낮음의 예(연 1회 결산 화면)와 심각도 낮음·우선순위 높음의 예(내일 데모용 로고)를 보면, 왜 이 둘을 하나로 뭉뚱그리면 안 되는지 분명해진다. 결함 리포트를 쓸 때는 이 두 값을 각각 독립적으로 판단해서 채워야 한다.
네 칸에서 실제로 해야 할 행동도 다르다.
| 칸 | 행동 |
|---|---|
| 심각 + 급함 | 지금 멈추고 이것부터. 필요하면 릴리즈를 미룬다 |
| 심각 + 안 급함 | 날짜를 받아 둔다. "다음 결산 전까지" 를 적어 두지 않으면 잊힌다 |
| 안 심각 + 급함 | 빨리 처리하고 왜 급한지를 기록한다(데모·행사는 지나간다) |
| 안 심각 + 안 급함 | 쌓아 둔다. 분기마다 한 번 정리한다 |
두 번째 칸이 가장 자주 사고로 돌아온다. "급하지 않다" 로 미뤄 둔 심각한 결함은 급해지는 날에 한꺼번에 급해진다. 연 1회 결산 화면이 결산 당일 아침에 터지는 식이다. 그래서 이 칸에는 반드시 기한을 적는다.
심각도를 낮춰 달라는 압력
실무에서 흔히 겪는 상황이다. "이거 S1은 너무 과한데요" 라는 말이 온다. 심각도는 협상 대상이 아니고, 우선순위는 협상 대상이다. 이 구분을 알고 있으면 대화가 쉬워진다.
"심각도는 S1로 두겠습니다 — 우회로가 없으니까요. 다만 우선순위는 P2로 내려도 됩니다. 영향 받는 사용자가 하루 3명이면 이번 스프린트 안에 고치는 것으로 충분합니다."
이렇게 나누면 상대도 받아들이기 쉽다. 심각도를 깎아 버리면 나중에 그 결함이 통계에서 사라지고, 같은 유형의 문제가 얼마나 자주 나는지 알 수 없게 된다. 기록은 사실대로, 일정은 협상으로 — 이것이 원칙이다.
상태 통계가 알려 주는 것
생명주기를 제대로 쓰면 세 가지 숫자가 공짜로 나온다.
| 숫자 | 뜻 | 나쁜 신호 |
|---|---|---|
| 재오픈율 | 재검증에서 되돌아간 비율 | 15%를 넘으면 수정이 성급하거나 전달이 부실하다 |
| 반려율 | Rejected 비율 | 높으면 리포트 품질 또는 기획 문서 공백 |
| 평균 체류 시간 | 상태별로 머문 시간 | New에 오래 머물면 아무도 안 보고 있다는 뜻 |
세 번째가 가장 쓸모 있다. 결함이 New 상태로 2주를 넘기고 있으면 그 팀에는 결함 관리 절차가 있는 것이 아니라 등록 양식만 있는 것이다.
사례 — S1이 뒤집힌 하루
쿠폰 적용 화면에서 적용 버튼을 누르면 아무 반응이 없는 결함을 찾았다. 우회로가 없어 S1으로 올렸고, P1으로 요청했다.
개발 쪽 회신은 "특정 브라우저의 특정 버전에서만 납니다" 였다. 여기서 흔한 실수는 심각도를 깎는 것이다. 대신 이렇게 정리했다.
| 항목 | 값 | 근거 |
|---|---|---|
| 심각도 | S1 유지 | 그 환경에서는 우회로가 없다 |
| 우선순위 | P2로 조정 | 해당 브라우저 사용자 비중 0.8% |
| 기한 | 이번 스프린트 | 숫자가 작아도 쓰는 사람은 못 쓴다 |
이틀 뒤 사용자 문의가 다섯 건 들어왔다. 비중은 0.8%였지만 그 브라우저 사용자가 특정 기업 고객 전체였던 것이다. 우선순위는 P1으로 올라갔고, 심각도는 처음부터 S1이었기 때문에 올릴 필요가 없었다.
여기서 남은 교훈이 두 개다. 심각도를 사실대로 두면 나중에 설명할 일이 없다. 그리고 "비중 0.8%" 는 사람 수가 아니다 — 누가 쓰는지를 봐야 한다.
실무에서 왜 필요한가
이슈 추적 도구(결함과 할 일을 등록해 두고 상태를 따라가는 웹 도구 — 레슨 4에서 다룬다)의 Severity·Priority 필드를 QA가 직접 채우는 경우가 많다. 도구 화면은 대개 영어라 심각도가 Severity, 우선순위가 Priority 로 적혀 있다. 이 둘을 구분 못 하면, 사소한 버그에 최고 우선순위를 붙여 팀의 신뢰를 잃거나, 반대로 심각한 버그를 낮은 우선순위로 묻어버려 사고로 이어질 수 있다. 심각도·우선순위를 정확히 분리해서 판단하는 능력은 QA가 개발팀·PM과 대화할 때 쓰는 공용 언어다.
두 값이 섞이면 어떤 일이 벌어지나
하나로 뭉뚱그린 팀에서 반복되는 패턴이 있다.
- 모든 것이 급해진다. 심각한 것을 알리려면 우선순위를 올려야 하니, S1이면 자동으로 P1을 붙인다. P1이 수십 건이 되고 아무도 P1을 안 믿는다
- 반대로 기록이 깎인다. "지금 급하지 않다" 는 이유로 심각도를 낮추면, 그 결함 유형이 얼마나 자주 나는지 통계에서 사라진다
- 협상할 곳이 없어진다. 두 값이 하나면 "조금 미루자" 는 말이 곧 "심각하지 않다고 인정하자" 가 되어 대화가 감정 싸움이 된다
세 번째가 QA가 가장 많이 지치는 지점이다. 축을 둘로 나누는 것만으로 일정 대화가 사실 대화에서 분리된다.
생명주기는 사람을 지키는 장치다
상태 흐름의 또 다른 쓸모가 있다. 누가 공을 들고 있는지가 명시되면 "왜 안 고쳐졌냐" 가 사람 문제가 되지 않는다. New에 2주 머문 결함은 담당자가 게으른 것이 아니라 배정 단계가 비어 있는 것이고, 그것은 절차로 고칠 수 있다. 레슨 3의 비난 없는 소통이 서는 바탕이 여기다.
채용시장에서의 위치
이 레슨의 내용은 신입 면접에서 거의 반드시 나오는 범위다. 그리고 답이 갈리는 지점이 분명하다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "심각도와 우선순위 차이가 뭐죠?" | "비슷한데 조금 다릅니다" | "심각도는 영향의 크기, 우선순위는 처리 순서입니다. 각각 QA와 비즈니스가 판단합니다" |
| "둘이 어긋나는 예를 들어 보세요" | "잘 떠오르지 않습니다" | "연 1회 결산 화면 크래시는 심각하지만 급하지 않고, 내일 데모용 로고 오류는 사소하지만 급합니다" |
| "개발자가 심각도를 낮춰 달라면?" | "조정합니다" | "심각도는 사실이라 유지하고, 우선순위는 조정 가능하다고 설명합니다" |
| "Fixed를 바로 Closed로 못 하는 이유는?" | "확인해야 하니까요" | "원 절차·주변 조건·회귀 세 가지를 봅니다" |
| "결함 관리가 잘 되는지 어떻게 보세요?" | "쌓인 수를 봅니다" | "재오픈율과 New 상태 체류 시간을 봅니다" |
세 번째가 주니어와 그 다음 단계를 가르는 질문이다. 압력 앞에서 기록을 지키면서 일정은 협상하는 태도는 경력으로만 생기는 판단으로 읽힌다.
다섯 번째는 리드급 질문이다. 결함을 잘 등록하는 사람은 많지만, 결함 관리 체계가 건강한지 숫자로 보는 사람은 적다. 레슨 5에서 이 숫자들을 더 다룬다.
공고 표현으로는 "결함 관리", "이슈 트래킹", "QA 프로세스 운영" 이 이 레슨에 걸린다. 그리고 거의 모든 QA 공고의 기본 요건이라서, 못 하면 떨어지고 잘해도 가점은 적은 종류의 능력이다. 그래서 빨리 확실히 익혀 두는 편이 낫다.