버그 심각도 S1, S2, S3, S4 - 우리는 왜 싸우나?

오전 10시, 또 시작됐다

회의실에 앉았다. 개발자 민호형, PM 수진누나, 나. 테이블 위에 노트북 세 대. 화면엔 Jira 티켓 #3847.

“이거 S2 아니에요.” 민호형이 먼저 쏘아붙였다. “로그인 안 되는 게 S2가 아니면 뭔데요?” 내가 받았다. “특정 기기에서만 그러잖아. 갤럭시 S20. 점유율 3%.”

수진누나가 한숨 쉬었다. “일단 S3으로 타협하죠.” 타협. 맨날 이거다.

버그 심각도. S1부터 S4까지. 겉으론 객관적 기준처럼 보인다. 실제론 협상 테이블이다.

우리 회사 기준, 종이에만 있다

입사할 때 받았다. QA 가이드 문서. 40페이지짜리 PDF. 14페이지에 나온다.

S1 - Critical

• 서비스 전체 다운
• 결제 불가
• 데이터 손실

S2 - Major

• 주요 기능 장애
• 다수 사용자 영향
• 임시 우회 방법 없음

S3 - Normal

• 일부 기능 장애
• 우회 가능
• 사용자 불편

S4 - Minor

• UI 오류
• 텍스트 오타
• 사용성 개선

깔끔하다. 명확하다. 실전에선 쓸모없다.

“로그인 안 되는 거 S2죠.” “특정 기기잖아. S3.” “그 기기 쓰는 사람도 사용자예요.” “전체 0.8%래. 로그 확인했어.”

가이드엔 없다. 점유율 얼마부터 “다수”인지. 우회 방법이 “로그아웃 후 재설치”면 진짜 우회인지.

결국 목소리 큰 사람이 이긴다. 아니면 직급 높은 사람.

개발자의 논리, QA의 논리

민호형 입장은 이해한다. 버그 심각도 높으면 당장 고쳐야 한다. 다른 작업 밀린다. 일정 늦어진다.

S1 붙으면 핫픽스 배포. 주말에도 나와야 한다. 그래서 S1은 정말 아껴 쓴다.

개발팀 내부에도 기준 있다. “서버 죽었어?” → S1 “앱 크래시?” → S2 “버튼 안 눌려?” → S3 “글자 깨짐?” → S4

QA 입장은 다르다. 사용자 관점이다.

갤럭시 S20 점유율 0.8%. 전체 사용자 50만 명이면 4천 명. 4천 명이 로그인 못 한다.

“0.8%니까 S3요.” “4천 명이요, 형.” “통계적으론 소수지.” “그 4천 명한테는 100%잖아요.”

말싸움 시작.

숫자 게임

작년 12월. 결제 버그 발견했다. “결제 완료” 떴는데 실제론 실패. 30분 뒤에 다시 결제하면 중복 결제.

나: “S1이요.” 민호형: “발생 빈도 확인했어?” 나: “3건 리포트 들어왔어요.” 민호형: “3건? 하루 거래 5만 건인데?”

PM 수진누나가 계산기 두드렸다. “0.006%. S3 맞네요.”

기가 막혔다. “돈 문제인데요?” “발생률 낮잖아.” “한 번이라도 당하면 민원 폭탄인데.”

결국 S2로 낙점. 2주 뒤 수정.

그 2주 동안 중복 결제 37건 더 발생. 고객센터 난리 났다. 환불 처리, 사과문, 쿠폰 보상.

회의 때 수진누나가 말했다. “이거 S1이었네요.” 민호형은 아무 말 없었다.

숫자는 거짓말 안 한다. 해석이 거짓말한다.

직급과 심각도의 상관관계

신입 때는 몰랐다. 버그 심각도가 정치라는 걸.

S1 버그 등록하면 회의 소집된다. CTO까지 올라간다. 누가 이 버그를 놓쳤나 추적 시작.

그래서 개발팀은 S1 싫어한다. QA팀도 부담스럽긴 하다. “이거 진짜 S1 맞아?” 팀장한테 물어본다.

작년 3월. 앱 크래시 발견. 재현율 100%. 특정 화면 진입 시.

나: “S1이죠?” 팀장: “사용자 얼마나 그 화면 가?” 나: “통계 봐야 알 것 같은데요.” 팀장: “일단 S2로 올려. 확인 후 조정.”

S2로 등록했다. 다음 날 통계 나왔다. 일 방문자 200명. “S1으로 올릴까요?” “이미 S2로 올렸잖아. 그냥 두자.”

2주 뒤 수정됐다. 그 2주간 400명이 크래시 경험했다.

리뷰에 별점 1점 달렸다. “앱 켜자마자 꺼져요. 쓰레기.”

심각도는 기술적 판단이 아니다. 조직 내 협상력이다.

배포 2일 전의 법칙

배포 일정 잡힌다. D-7부터 분위기 바뀐다.

D-7: “버그 있으면 다 올려.” D-5: “S1, S2만 급해.” D-3: “S1만 본다.” D-2: “이거 진짜 S1 맞아?” D-1: “이거 S2 아니야?” D-day: “일단 배포하고 다음 버전에.”

심각도가 시간에 따라 변한다. 같은 버그. 다른 평가.

지난달 있었다. D-5에 발견한 버그. 검색 필터 작동 안 함.

나: “S2요.” 민호형: “이틀 안에 못 고쳐.” PM: “우회 방법 있어?” 나: “필터 안 쓰고 스크롤.” PM: “그럼 S3 아닌가?” 나: “검색이 주요 기능인데요.” PM: “배포 밀리면 안 돼. 다음 버전.”

S3으로 강등. 다음 버전 때 다시 S2.

버그는 안 변했다. 일정이 심각도를 결정했다.

고객 민원이 진짜 심각도

앱스토어 별점 3.2. 예전엔 4.1이었다.

리뷰 읽으면 안다. 우리가 S3, S4 처리한 것들. 사용자한테는 S1이다.

“뒤로가기 누르면 앱 꺼짐” → 우리는 S3 “매번 로그인 풀림” → 우리는 S4 “알림 안 옴” → 우리는 S2

리뷰는 가차없다. 별 하나. “못 쓰겠어요.”

고객센터 통계 받았다. 지난 3개월 불만 접수 1위. “검색 필터 오류”

우리가 S3 처리한 거다. 사용자 4만 명이 민원 넣었다. 4만 명한테는 S1이었다.

회의 때 수진누나가 보여줬다. “이거 다음 버전에 꼭 고쳐야 해요.”

민호형이 중얼거렸다. “진작 S1로 할 걸.”

우리 기준과 사용자 기준. 언제나 다르다.

심각도 회의, 매주 1시간

QA팀이 제안했다. “심각도 판정 회의 만들자.”

매주 목요일 2시. QA 2명, 개발 2명, PM 1명. 지난주 올라온 버그 리뷰.

처음엔 효과 있었다. 명확한 케이스들 정리됐다.

• 결제 관련 → 무조건 S1 검토
• 로그인/회원가입 → S1 또는 S2
• 크래시 → 재현율에 따라 S1/S2
• UI 오류 → S4, 단 주요 버튼은 S3

하지만 애매한 건 여전했다.

“푸시 알림 안 옴” 개발: “OS 권한 문제 아닌가?” QA: “앱 버그예요. 로그 있어요.” 개발: “얼마나 발생해?” QA: “20건 리포트.” 개발: “일 사용자 10만인데 0.02%.” QA: “알림이 핵심 기능인데요.”

한 시간 회의. 결론은 “다음 주 재논의”.

다음 주엔 다른 버그로 또 싸운다.

객관 기준을 찾아서

팀장이 자료 가져왔다. 해외 회사들 사례.

구글 기준 (추정)

• P0: 사용자 5% 이상 영향, 또는 수익 차단
• P1: 주요 기능 장애, 우회 없음
• P2: 부분 기능 장애, 우회 있음
• P3: 개선 사항

아마존 기준 (추정)

• SEV1: 서비스 다운, 즉시 대응
• SEV2: 주요 기능 실패, 24시간 내
• SEV3: 불편 사항, 1주일 내
• SEV4: 개선, 백로그

핵심은 숫자다. “사용자 5% 이상” “24시간 내”

우리도 기준 만들기로 했다.

S1 - Critical

• 일 사용자 5% 이상 영향 (2500명)
• 결제/환불 오류 (금액 무관)
• 개인정보 유출 가능성
• 서비스 접속 불가 → 즉시 수정, 핫픽스 배포

S2 - Major

• 일 사용자 1% 이상 영향 (500명)
• 주요 기능 장애 (로그인, 검색, 주문)
• 우회 방법 어려움
• 앱 크래시 (재현율 30% 이상) → 3일 내 수정

S3 - Normal

• 일 사용자 1% 미만 영향
• 부분 기능 오류
• 우회 방법 있음
• 사용자 불편 → 다음 정기 배포

S4 - Minor

• UI 깨짐, 오타
• 기능 동작하나 비효율
• 개선 제안 → 백로그 관리

종이에 적었다. 회의실에 붙였다.

3개월 후, 여전히 싸운다

새 기준 적용 12주. 완벽하진 않다.

여전히 애매한 케이스 나온다. “이거 주요 기능 맞아?” “우회가 쉬운 거야 어려운 거야?” “1% 직전이면 어쩌고?”

하지만 달라졌다. 협상이 데이터 기반으로 바뀌었다.

“이거 S2 아니에요?” “사용자 몇 명 영향받아?” “350명이요.” “기준이 500명이니까 S3.” “근데 로그인 관련인데.” “주요 기능 조항 해당. S2 인정.”

숫자로 말한다. 기분이 아니라.

버그 처리 속도도 빨라졌다. S1은 진짜 S1만 남았다. 개발팀도 집중한다.

S3, S4는 우선순위 밀려도 이해한다. 명확한 기준 있으니까.

완벽한 기준은 없다. 하지만 없는 것보단 낫다.

결국 사람이 판단한다

기준 있어도 예외는 생긴다.

지난주 있었다. 특정 지역 사용자만 영향받는 버그. 서울/경기 OK. 부산/경남만 오류.

영향 사용자 230명. 0.4%. 기준상 S3.

하지만 올렸다. S2로. 이유는 간단했다.

“부산 사용자한테는 100%잖아.”

민호형이 동의했다. “맞아. 고치자.”

기준은 출발점이다. 최종 판단은 사람이 한다.

중요한 건 근거다. “왜 이게 S2인가?” “부산 지역 사용자 전원 영향, 우회 불가”

설명 가능하면 된다. 서로 납득하면 된다.

심각도 협상의 미래

요즘 고민한다. AI가 심각도 판정하면 어떨까.

로그 데이터 던져주면 “영향 사용자 1237명, S2 권장” 이렇게 나온다.

공정할 것 같다. 싸움도 줄어들 것 같다.

하지만 찝찝하다.

버그는 숫자만이 아니다. 맥락이 있다. 타이밍이 있다.

배포 하루 전 S2 버그와 배포 2주 후 S2 버그. 같은 S2가 아니다.

결제 버그 3건 발생과 UI 버그 300건 발생. 어느 게 더 심각한가.

이건 사람이 판단해야 한다. 데이터 + 상황 + 경험.

AI는 보조다. 결정은 우리가.

싸움보단 대화

QA 4년 하면서 배웠다. 개발자랑 싸워서 좋을 건 없다.

버그 심각도 논쟁. 결국 같은 목표다. 좋은 제품 만들기.

차이는 관점. 개발자: 일정, 리소스 QA: 사용자, 품질

둘 다 맞다. 둘 다 필요하다.

중요한 건 대화. “왜 이게 S2라고 생각해?” “사용자 경험 측면에서 치명적이라서.” “알겠어. 그럼 우선순위 올려볼게.”

명확한 기준 있으면 대화 쉽다. 감정 아니라 사실로 말한다.

“너는 맨날 S1이래”가 아니라 “이건 기준상 S1 조건 충족해”

팀 분위기 달라진다. QA vs 개발이 아니라 우리 vs 버그.

---

오늘 S1 버그 하나 올렸다. 민호형이 물었다. “근거 있어?” “결제 실패율 8%, 하루 400건 영향.” “오케이. 당장 본다.” 기준 있으니까 빠르다. 협상 아니라 합의. 이게 맞는 것 같다.