결함 재현성에서 시작하는 Severity·Priority 기반 결함관리

결함 티켓이 쌓이는 문제는 등록 건수보다 재현 정보의 품질, 등급 판단의 일관성, 처리 책임의 불명확성에서 시작되는 경우가 많다. 결함관리 프로세스는 결함을 수집하고 분류한 뒤 우선순위를 정해 수정·검증·종결하는 전 주기를 관리한다. 입력 정보, 상태 전이, SLA, 지표를 표준화해 품질과 처리 속도, 운영 일관성을 함께 확보하는 것이 목적이다.

Severity는 사용자와 시스템에 미치는 기술적 영향도를 나타낸다. 데이터 손실, 보안 사고, 서비스 중단 여부가 판단의 중심이다. 반면 Priority는 비즈니스 긴급도와 처리 순서를 정하는 기준으로, 고객·시장·컴플라이언스 영향과 마일스톤 정렬을 반영한다. Triage는 재현성을 확인하고 데이터를 보강한 뒤 Severity와 Priority를 산정하고 담당 팀을 배정하는 초기 결정 단계다.

티켓이 닫힐 때까지 유지해야 할 상태와 책임

상태는 New → Triage → Open → In Progress → In Review → Ready for Test → Verified → Closed → Reopened로 관리할 수 있다. 각 상태가 무엇을 의미하는지와 다음 상태로 전환할 수 있는 조건을 명확히 해야 티켓이 담당자나 팀 사이에서 멈추지 않는다.

Reporter, Triage Lead(QA/EM), Dev Owner, QA Verifier, PM/CS, SRE의 책임 범위를 두고 RACI 기준으로 승인 권한을 정한다. Severity 또는 Priority 변경에는 Triage Lead 승인을 요구하고, 릴리스를 막는 Blocker는 배포 승인 절차를 거치게 한다.

재현 가능한 결함 기록이 분류의 기반이 된다

결함 입력에는 재현 단계, 기대 결과와 실제 결과, 환경 정보(버전·클라우드 리전·디바이스), 로그·덤프·스크린샷, 영향 범위, 발견 소스(테스트·운영·고객)가 포함돼야 한다. Component, Affected/Fixed Version, Severity, Priority, Root Cause, Regression 여부와 Incident·Commit·Test Case 링크도 정규 필드로 관리한다.

스택트레이스와 시그니처를 활용한 중복 검출 해시를 적용하면 같은 결함이 여러 티켓으로 분산되는 일을 줄일 수 있다. 필수 필드가 빠진 티켓은 저장을 거부하고, 작성자가 필요한 정보를 채울 수 있도록 템플릿 가이드를 제공한다.

영향도와 긴급도를 분리해 판단한다

Severity는 기술적 피해 수준을 기준으로 한다. S1은 서비스 중단·데이터 손실·보안 사고, S2는 우회가 불가능한 핵심 기능 장애, S3는 우회 가능한 문제, S4는 경미한 문제나 UX 이슈를 뜻한다.

Priority는 처리 시점과 순서에 관한 판단이다. P0은 즉시 처리, P1은 단기 처리, P2는 스프린트 내 처리, P3는 백로그로 구분한다. Severity와 Priority를 교차 매핑하면 SLA와 에스컬레이션을 자동으로 연결할 수 있다.

구분	의미	평가 기준	주책임자	변경 가능성	SLA 영향	예시
Severity(심각도)	기술적 영향도 수준	데이터 손실, 보안, 가용성, 기능 불가	QA/Triage Lead	중간(재현/증거 기반)	높음(기본 SLA 결정)	서비스 전체 장애, 치명적 크래시
Priority(우선순위)	처리 긴급도/순서	고객 영향, 마일스톤, 계약/규제	PM/EM	높음(비즈니스 맥락 변화)	중간(SLA 보정)	출시 임박 핫픽스, VIP 고객 이슈

SLA 타이머와 에스컬레이션을 티켓 흐름에 연결한다

S1/P0의 SLA 샘플은 triage≤30분, fix start≤1시간, resolve≤4시간, verify≤2시간으로 둔다. S2/P1은 triage≤4시간, resolve≤2영업일을 기준으로 삼을 수 있다.

SLA의 50% 시점에는 알림을 보내고, 100%를 넘기면 EM/PM을 자동 호출한다. 운영 이슈는 온콜로 라우팅한다. 데이터가 불충분하거나 외부 의존성이 있는 경우에는 타임스톱 정책을 적용하되, 코멘트에 근거를 기록한다. SxPy 매핑표로 triage·resolve·verify 타임박스를 관리하면 임박 알림, 관리자 호출, 경영 보고로 이어지는 3단계 에스컬레이션을 구성할 수 있다. 예외 승인 로그와 타임스톱 근거는 감사 지원과 공정성 확보에도 쓰인다.

이슈 트래커와 배포 파이프라인에서 흐름을 자동화한다

Component에서 담당 팀으로 연결되는 라우팅, 태그 기반 온콜 호출, 운영 Incident와 Defect의 양방향 링크를 이슈 트래커에 둔다. 미해결 Blocker가 있으면 CI/CD 릴리스 게이트에서 배포를 막고, Fix Commit은 티켓 상태 전이와 연결한다.

SLA 위반, 재오픈율, 누락 필드 현황은 대시보드로 확인하고 주간 품질 리뷰에는 자동 리포트를 활용한다. Backlog Health, SLA Breach, Reopen Rate, Escape Rate를 추적하며, 분기별 기준 재평가와 교육·샘플 캘리브레이션 문서로 Severity와 Status 드리프트를 막는다.

⤢✕

티켓 업데이트는 원자적 트랜잭션으로 처리하고, 버전 필드를 이용한 낙관적 락을 적용한다. 충돌이 나면 롤백 후 재시도를 요청한다. 필수 필드가 없거나 재현할 수 없는 결함은 Rework 상태로 전이하고, SLA 타임스톱과 코멘트 근거를 남긴다.

제품과 운영 환경에 따라 달라지는 적용 방식

대규모 SaaS에서는 운영 Incident와 연계해 S1/P0을 자동 생성하고 온콜 페이징으로 연결할 수 있다. Blocker가 해결되지 않은 경우 배포 게이트가 릴리스를 차단한다. 다중 테넌트 환경이라면 테넌트 수와 매출 영향을 영향 분석 필드에 추가하고, 그 결과에 따라 에스컬레이션 정책을 달리 적용한다.

모바일·임베디드 제품은 기기와 OS 매트릭스에 맞춘 재현환경 템플릿이 필요하다. 하드웨어 리그 예약을 결함 티켓과 연결하고, OTA 릴리스 파이프라인에는 Regressions=Blocker 규칙을 적용해 결함 유출을 막는다.

금융·의료처럼 규제를 받는 환경에서는 변경 이력, 승인 체인, 증적 첨부를 의무화한다. SOX/ISO 13485 감사를 위해 필드 잠금과 ACL을 강화하고, SLA 위반 시 RCA(근본원인분석) 제출 및 시정조치(CAPA) 워크플로우를 자동 생성한다.

품질 리스크를 수치와 운영 기준으로 통제한다

이 체계를 적용했을 때 MTTA/MTTR 3050% 단축, 재오픈율 2040% 감소, SLA 준수율 95% 이상, 유출 결함률(Release Escape) 30% 감소를 정량 효과로 둔다. 분류 기준의 일관성을 높이고 커뮤니케이션 비용을 줄이며 릴리스 예측 가능성을 높이는 효과도 기대할 수 있다.

데이터 손실이나 보안 사고는 S1, 핵심 경로 기능 불가는 S2, 우회 가능한 문제는 S3, UI·카피 문제는 S4로 두는 가드레일이 필요하다. Priority는 고객·매출·규제 영향의 즉시성과 마일스톤 정렬을 바탕으로 P0~P3을 정한다. 재현성 기반의 데이터 품질, Severity·Priority의 분리, SLA와 에스컬레이션 자동화가 함께 갖춰져야 결함 흐름을 지속 가능한 품질 운영으로 연결할 수 있다.