소프트웨어 테스트 과정에서 결함, 즉 버그를 발견하면 우리는 결함 관리 시스템에 이를 기록합니다. 이때 거의 모든 시스템은 ‘심각도(Severity)’와 ‘우선순위(Priority)’라는 두 가지 중요한 속성을 입력하도록 요구합니다. 많은 사람들이 이 두 용어를 혼용하거나 비슷한 개념으로 오해하곤 합니다. “심각하니까 당연히 우선적으로 처리해야 하는 것 아닌가?”라는 생각은 얼핏 합리적으로 들립니다. 하지만 이 둘을 명확히 구분하지 못하면, 프로젝트는 엉뚱한 버그를 수정하는 데 시간을 낭비하고 정작 비즈니스에 치명적인 문제는 방치하는 우를 범할 수 있습니다.
‘심각도’가 버그 자체가 시스템에 미치는 기술적인 영향의 정도를 나타내는 객관적인 척도라면, ‘우선순위’는 해당 버그를 언제, 얼마나 빨리 수정해야 하는지를 결정하는 비즈니스 관점의 주관적인 척도입니다. 마치 병원의 응급실에서 환자를 분류하는 것과 같습니다. 심장이 멎은 환자(높은 심각도)는 즉시 처치해야 하지만(높은 우선순위), 깊게 베였지만 생명에 지장이 없는 상처(중간 심각도)는 출혈이 심한 다른 환자(낮은 심각도, 높은 우선순위)보다 나중에 치료받을 수도 있습니다.
본 글에서는 결함의 심각도와 우선순위가 각각 무엇을 의미하는지, 누가 결정해야 하는지, 그리고 이 둘의 관계가 어떻게 설정되어야 하는지를 구체적인 사례를 통해 명확하게 파헤쳐 보고자 합니다. 이 글을 읽고 나면, 여러분은 더 이상 두 개념을 혼동하지 않고, 한정된 개발 자원을 가장 중요한 문제에 집중시키는 현명한 의사결정을 내릴 수 있게 될 것입니다.
결함 심각도 (Defect Severity): 버그의 기술적 파괴력
핵심 개념: 이 결함이 시스템에 얼마나 큰 충격을 주는가?
결함 심각도는 발견된 결함이 소프트웨어의 기능이나 성능, 데이터 등에 얼마나 심각한 악영향을 미치는지를 나타내는 기술적인 척도입니다. 이는 철저히 ‘품질 보증(QA)팀’이나 ‘테스터’의 관점에서 평가됩니다. 심각도를 판단할 때는 비즈니스적인 영향이나 수정 일정 등은 고려하지 않고, 오직 해당 결함이 기술적으로 얼마나 위험하고 파괴적인지에만 집중합니다.
심각도는 보통 다음과 같은 단계로 분류됩니다. 단계의 명칭이나 개수는 조직이나 프로젝트마다 다를 수 있지만, 그 의미는 대부분 유사합니다.
- 치명적 (Critical / Blocker): 시스템의 핵심 기능이 완전히 동작하지 않거나, 시스템 전체가 다운되는 경우. 데이터베이스의 데이터가 손상되거나 보안에 심각한 구멍이 뚫리는 경우도 여기에 해당합니다. 더 이상 다른 테스트를 진행할 수 없을 정도로 심각한 상태를 의미합니다. 예를 들어, 쇼핑몰 앱에서 ‘결제’ 버튼을 눌렀을 때 앱이 무조건 종료되는 버그가 여기에 해당합니다.
- 주요 (Major / High): 시스템의 주요 기능이 의도와 다르게 동작하거나, 일부 기능이 작동하지 않아 사용자가 큰 불편을 겪는 경우. 기능은 동작하지만 잘못된 결과 값을 반환하는 경우도 포함됩니다. 예를 들어, 장바구니에 상품 5개를 담았는데 3개만 표시되는 버그입니다.
- 보통 (Moderate / Normal): 시스템의 비핵심적인 기능이 제대로 동작하지 않거나, 사용자가 다소 불편함을 느끼지만 다른 우회적인 방법을 통해 작업을 완료할 수 있는 경우. UI(사용자 인터페이스)가 깨져 보이거나, 특정 조건에서만 발생하는 사소한 기능 오류 등이 여기에 해당합니다. 예를 들어, 검색 결과 페이지의 정렬 기능 중 ‘오래된 순’ 정렬만 동작하지 않는 버그입니다.
- 사소 (Minor / Low): 사용자의 사용성에 거의 영향을 미치지 않는 경미한 문제. 문구의 오타, 이미지의 색상 차이, UI 요소의 미세한 위치 어긋남 등 기능적으로는 아무런 문제가 없는 경우입니다. 예를 들어, 회사 소개 페이지의 대표자 이름에 오타가 있는 경우입니다.
심각도를 결정하는 주체는 QA 엔지니어입니다. 그들은 시스템의 내부 구조와 기능적 요구사항을 깊이 이해하고 있기 때문에, 해당 결함이 시스템 전체에 미칠 기술적인 파급 효과를 가장 객관적으로 판단할 수 있습니다.
현실 속의 심각도 판단: 항공권 예약 시스템
항공권 예약 시스템에서 발견된 여러 결함의 심각도를 판단해 보겠습니다.
- 결함 A: 항공권 검색 후 ‘예약’ 버튼을 누르면 시스템이 멈추고 에러 페이지가 나타난다.
- 심각도: 치명적(Critical). 사용자가 예약을 할 수 없다는 것은 시스템의 존재 이유를 부정하는 핵심 기능의 완전한 실패입니다.
- 결함 B: 성인 2명, 유아 1명으로 조회했을 때, 유아의 항공권 가격이 성인과 동일하게 계산된다. (원래는 90% 할인되어야 함)
- 심각도: 주요(Major). 예약 기능 자체는 동작하지만, 핵심적인 비즈니스 로직인 가격 계산이 잘못되어 사용자에게 직접적인 금전적 피해를 줍니다.
- 결함 C: 예약 내역 조회 페이지에서 ‘항공편 변경’ 버튼의 색상이 디자인 가이드라인과 다르게 파란색 대신 회색으로 보인다.
- 심각도: 사소(Minor). 기능적으로는 아무런 문제가 없고 사용자가 작업을 완료하는 데 아무런 지장을 주지 않습니다. 단순히 시각적인 불일치일 뿐입니다.
- 결함 D: 1년에 한두 번 있을까 말까 한 특정 공휴일(예: 윤년의 2월 29일)을 출발일로 지정하고, 특정 항공사의 마일리지를 특정 구간 이상 적용하면, 시스템 로그에 의미 없는 경고 메시지가 대량으로 쌓인다.
- 심각도: 보통(Moderate). 일반 사용자에게는 아무런 영향이 없지만, 서버 리소스를 낭비하고 잠재적인 성능 저하를 유발할 수 있는 기술적인 문제입니다.
이처럼 심각도는 철저히 기술적인 관점에서 결함의 ‘영향력’과 ‘파괴력’을 평가하는 과정입니다.
결함 우선순위 (Defect Priority): 버그 해결의 긴급성
핵심 개념: 이 결함을 얼마나 빨리 해결해야 하는가?
결함 우선순위는 발견된 결함을 수정해야 하는 ‘긴급성’과 ‘중요성’의 정도를 나타내는 비즈니스적인 척도입니다. 이는 주로 ‘프로젝트 관리자(PM)’나 ‘제품 책임자(PO)’가 결정합니다. 우선순위를 결정할 때는 결함의 기술적 심각도뿐만 아니라, 비즈니스에 미치는 영향, 개발 리소스, 출시 일정, 고객과의 계약 관계 등 다양한 요소를 종합적으로 고려해야 합니다.
우선순위 역시 보통 다음과 같은 단계로 분류됩니다.
- 즉시 해결 (Urgent / Highest): 해당 릴리스에 반드시 포함되어야 하며, 다른 모든 작업을 중단하고라도 가장 먼저 해결해야 하는 결함. 보통 심각도가 ‘치명적(Critical)’인 결함이 여기에 해당하지만, 항상 그런 것은 아닙니다.
- 높음 (High): 가능한 한 빨리, 이번 개발 주기(스프린트) 내에 해결해야 하는 결함. 주요 기능에 영향을 주거나 많은 사용자가 불편을 겪는 문제들이 해당됩니다.
- 보통 (Medium): 정규 작업 흐름에 따라 해결해야 할 결함. 다음 릴리스나 다음 스프린트에서 수정되어도 무방합니다.
- 낮음 (Low): 시간과 리소스가 허락될 때 수정할 결함. 수정하지 않고 넘어가거나, 장기적인 개선 과제로 남겨둘 수도 있습니다.
우선순위를 결정하는 주체는 PM이나 PO입니다. 그들은 프로젝트의 전체적인 목표와 일정, 고객의 요구사항을 가장 잘 이해하고 있기 때문에, 한정된 개발 자원을 어디에 먼저 투입해야 비즈니스 가치를 극대화할 수 있을지 판단할 수 있습니다. QA 엔지니어는 심각도에 대한 의견을 제시하며 우선순위 결정에 도움을 줄 수 있지만, 최종 결정권은 비즈니스를 책임지는 사람에게 있습니다.
현실 속의 우선순위 결정: 같은 결함, 다른 운명
앞서 심각도를 판단했던 항공권 예약 시스템의 결함들에 대해, PM이 우선순위를 결정하는 상황을 살펴보겠습니다.
- 결함 A (심각도: Critical): ‘예약’ 버튼 클릭 시 시스템 다운.
- 우선순위: 즉시 해결(Urgent). 시스템의 존재 이유가 사라졌으므로, 다른 모든 것을 멈추고 즉시 해결해야 합니다. 이 경우는 심각도와 우선순위가 모두 최고 등급입니다.
- 결함 B (심각도: Major): 유아 항공권 가격 계산 오류.
- 우선순위: 높음(High). 사용자에게 직접적인 금전적 피해를 주고 회사 이미지에 심각한 타격을 줄 수 있으므로, 이번 릴리스 전에 반드시 수정해야 합니다.
- 결함 C (심각도: Minor): 버튼 색상 오류.
- 우선순위: 낮음(Low). 기능에 전혀 영향이 없고, 대부분의 사용자는 인지조차 못 할 가능성이 높습니다. 개발팀이 더 중요한 문제를 모두 해결한 뒤에 시간이 남으면 처리하도록 합니다.
- 결함 D (심각도: Moderate): 특정 조건에서만 발생하는 서버 로그 과다 발생.
- 우선순위: 낮음(Low). 일반 사용자에게는 전혀 영향이 없고, 매우 드문 조건에서만 발생합니다. 당장 수정하지 않아도 시스템 운영에 큰 문제가 없다고 판단되면, 장기적인 기술 부채 개선 과제로 분류하고 우선순위를 낮출 수 있습니다.
이처럼 우선순위는 기술적인 문제 자체보다는, 그것이 비즈니스와 사용자에게 미치는 영향, 그리고 해결에 드는 비용과 일정을 고려한 전략적인 판단의 결과입니다.
심각도와 우선순위의 4가지 조합: 흥미로운 관계의 역학
심각도와 우선순위는 서로 관련이 깊지만, 항상 정비례하지는 않습니다. 이 둘의 관계를 2×2 매트릭스로 분석해 보면 매우 흥미로운 시나리오들을 발견할 수 있습니다.
| 높은 우선순위 (High Priority) | 낮은 우선순위 (Low Priority) | |
| 높은 심각도 (High Severity) | 1. 즉시 해결해야 할 재앙 (예: 결제 불가) | 2. 위험하지만 급하지 않은 시한폭탄 (예: 드문 조건의 서버 다운) |
| 낮은 심각도 (Low Severity) | 3. 사소하지만 중요한 얼굴 (예: 회사 로고 오류) | 4. 나중에 해결해도 될 사소한 문제 (예: 도움말 오타) |
시나리오 1: 높은 심각도 & 높은 우선순위 (High Severity & High Priority)
가장 명확하고 이견이 없는 경우입니다. 시스템이 다운되거나, 핵심 기능이 동작하지 않거나, 데이터가 손상되는 등 기술적으로 매우 심각하며 비즈니스에도 치명적인 영향을 미치는 결함입니다. 모든 팀원이 즉시 이 문제를 해결하는 데 집중해야 합니다.
- 예시: 은행 앱에서 ‘이체’ 버튼을 누르면 앱이 강제 종료되어 아무도 송금을 할 수 없는 경우.
시나리오 2: 높은 심각도 & 낮은 우선순위 (High Severity & Low Priority)
가장 흥미롭고 논쟁이 많을 수 있는 경우입니다. 기술적으로는 시스템을 다운시키는 등 매우 심각한 결과를 초래할 수 있지만, 그 결함이 발생하는 조건이 매우 드물고 예외적이어서 일반 사용자에게는 거의 영향을 미치지 않는 경우입니다.
- 예시: 10년 이상 된 구형 브라우저의 특정 버전에서만 관리자 페이지에 접속할 때 웹 서버가 다운되는 결함. 기술적으로는 서버 다운이라는 심각한 문제이지만, 해당 브라우저 사용자가 회사 내에 아무도 없고 외부 공격 가능성도 희박하다면, PM은 더 시급한 다른 기능 개발을 위해 이 문제의 해결 우선순위를 낮출 수 있습니다.
시나리오 3: 낮은 심각도 & 높은 우선순위 (Low Severity & High Priority)
기술적으로는 아무런 문제가 없거나 아주 사소한 문제이지만, 비즈니스적으로나 마케팅적으로 매우 중요하여 즉시 수정해야 하는 경우입니다.
- 예시: 회사의 메인 홈페이지 첫 화면에 표시되는 회사 로고 이미지가 깨져서 보이는 경우. 시스템의 기능은 100% 정상 작동하지만, 회사의 이미지를 심각하게 훼손할 수 있으므로 개발자는 즉시 이미지를 교체해야 합니다. 또 다른 예로, 법적으로 반드시 명시해야 하는 문구(예: 저작권 연도)에 오타가 있는 경우, 이는 기능적 심각도는 ‘사소(Minor)’하지만 법적 문제와 직결되므로 우선순위는 ‘즉시 해결(Urgent)’이 될 수 있습니다.
시나리오 4: 낮은 심각도 & 낮은 우선순위 (Low Severity & Low Priority)
기술적으로도 사소하고 비즈니스적으로도 중요하지 않은 결함입니다. 웹사이트의 잘 보이지 않는 곳에 있는 문구의 오타, 디자인 가이드와 약간 다른 UI 요소 등이 여기에 해당합니다. 이러한 결함들은 보통 ‘시간이 남으면’ 해결하거나, 다음 대규모 업데이트 시 함께 수정하는 방식으로 처리됩니다.
마무리: 효과적인 소통과 의사결정을 위한 필수 도구
결함의 심각도와 우선순위를 명확하게 구분하고 올바르게 사용하는 것은 성공적인 프로젝트 관리를 위한 필수 역량입니다. 이 두 개념은 서로 다른 관점(기술 vs. 비즈니스)에서 결함을 바라보고, 각기 다른 책임자(QA vs. PM)에 의해 결정되며, 궁극적으로는 한정된 자원을 가장 효율적으로 배분하기 위한 의사결정의 도구로 사용됩니다.
- 심각도 (Severity) = 기술적 영향력 (by QA)
- 우선순위 (Priority) = 비즈니스 긴급성 (by PM/PO)
QA팀은 발견한 결함의 기술적 심각도를 객관적으로 평가하여 개발팀과 PM에게 정확한 정보를 제공해야 합니다. PM은 이 정보를 바탕으로 비즈니스의 큰 그림 안에서 해당 결함의 해결 우선순위를 전략적으로 결정해야 합니다. 이 과정에서 두 역할 간의 활발한 소통과 상호 존중은 필수적입니다. QA가 “이건 심각도 Critical입니다!”라고 외칠 때, PM은 “알겠습니다. 하지만 지금은 더 중요한 저 문제부터 해결해야 합니다”라고 답할 수 있어야 하며, 그 이유를 팀원 모두가 이해할 수 있어야 합니다.
이처럼 심각도와 우선순위라는 두 개의 렌즈를 통해 결함을 입체적으로 바라볼 때, 비로소 우리 팀은 허둥대지 않고 가장 중요한 문제부터 차근차근 해결해 나가는 스마트한 조직이 될 수 있을 것입니다.