긴급 버그 vs 기획 이슈, 우선순위를 정하는 기준
- 15 Dec, 2025
긴급 버그 vs 기획 이슈, 우선순위를 정하는 기준
목요일 오후 3시, 슬랙 폭탄
목요일이다. 릴리즈 전날. 슬랙 알림이 17개.
“회원가입 버튼이 안 눌려요 (iOS 14)” “메인 배너 이미지 깨져요” “근데 프로필 수정 기능은 언제 들어가요?”
한숨. 개발팀장이 전화했다.
“K님, 뭐부터 할까요?”
이게 매주 반복된다. 릴리즈 주간마다.
3개월 전의 나
예전엔 소리 큰 사람 먼저 처리했다.
대표님이 언급하면 → 최우선 개발팀이 짜증내면 → 미뤄짐 디자이너가 조용하면 → 잊혀짐
결과? 릴리즈는 계속 미뤄지고. 팀은 지치고. 내 신뢰도는 바닥.
스프린트 회고에서 개발자가 말했다. “우선순위 기준이 뭔가요?”
대답 못 했다.
기준이 없으면 매번 싸운다
기준 없이 판단하면. 매번 설명해야 한다.
“왜 내 이슈는 안 해요?” “이거 급한데요?” “지난주엔 이런 거 바로 했잖아요”
에너지 소진. 시간 낭비. 팀 사기 저하.
그래서 만들었다. 우선순위 매트릭스.
내가 쓰는 4단계 기준
1단계: 영향도 확인
질문 3개
- 몇 명한테 영향?
- 핵심 기능인가?
- 비즈니스 임팩트?
회원가입 버튼 안 눌림 → 전체 유저, 핵심 기능, 매출 직결 프로필 이미지 안 보임 → 일부 유저, 부가 기능, 매출 무관
숫자로 본다. 감이 아니라.
예시
- 결제 버그: 전체 유저(100%) + 핵심 + 매출 직결 → Critical
- 설정 화면 오타: 소수 유저(5%) + 부가 + 매출 무관 → Low
2단계: 시급성 판단
3가지 기준
- 지금 안 하면 릴리즈 불가?
- 회사 평판 리스크?
- 법적/보안 이슈?
하나라도 Yes면 급함.
배너 이미지 깨짐 → 릴리즈 가능, 평판 영향 적음, 법적 무관 → 중간 개인정보 노출 버그 → 즉시 핫픽스
타임라인을 본다. “급하다”는 말만으론 부족.
3단계: 공수 산정
개발자한테 묻는다. “얼마나 걸려요?”
30분 이하 → 바로 반나절 → 스프린트 내 하루 이상 → 백로그
중요하지만 시간 오래 걸리면? 다음 스프린트.
작은 거 먼저 처리하면. 팀 사기도 오른다.
실제 케이스
- iOS 버튼 버그: 영향도 高, 시급 高, 공수 2시간 → 당일 처리
- 프로필 수정: 영향도 中, 시급 低, 공수 3일 → 다음 스프린트
- 배너 이미지: 영향도 中, 시급 中, 공수 30분 → 당일 처리
4단계: 기회비용 계산
이걸 하면 뭘 못 하나?
A 버그 잡으면 → B 기능 개발 미뤄짐 B 개발하면 → C 테스트 시간 부족
트레이드오프. 항상 존재한다.
회의에서 말한다. “이거 하면 저건 다음 주입니다”
명확하게.
실전 적용: 지난주 목요일
상황
- 릴리즈 D-1
- 긴급 이슈 5개
- 기획 요청 3개
이슈 리스트
- [P0] 결제 실패율 급증 (20% → 35%)
- [P1] 검색 결과 정렬 오류
- [P1] 푸시 알림 이미지 깨짐
- [P2] 프로필 편집 느림
- [P2] 메인 배너 오타
- [기획] 소셜 로그인 추가
- [기획] 위시리스트 기능
- [기획] 알림 설정 세분화
판단 과정
먼저 매트릭스 그렸다. 화이트보드에.
| 영향도 | 시급성 | 공수 | 결정 |
|---|---|---|---|
| 결제 버그 | 高 | 高 | 2시간 |
| 검색 오류 | 中 | 中 | 4시간 |
| 푸시 이미지 | 中 | 低 | 1시간 |
| 프로필 느림 | 低 | 低 | 1일 |
| 배너 오타 | 低 | 低 | 10분 |
| 소셜 로그인 | 中 | 低 | 3일 |
| 위시리스트 | 低 | 低 | 1주 |
| 알림 설정 | 低 | 低 | 2일 |
최종 결정
- 목요일: 결제 버그 + 배너 오타
- 금요일 오전: 검색 오류
- 금요일 오후: 푸시 이미지 + 릴리즈
- 다음 주: 프로필 개선
- 2주 후: 소셜 로그인
개발팀한테 공유했다. 이유와 함께.
“결제가 안 되면 매출이 멈춥니다. 검색은 불편하지만 우회 가능합니다.”
반발 없었다. 기준이 명확하니까.
팀과 공유하는 방법
혼자 판단하면 안 된다. 기준을 투명하게.
매주 월요일
- 우선순위 매트릭스 리뷰
- 이번 주 Top 3 합의
- 백로그 정리
이슈 발생 시
- 슬랙에 즉시 기준 적용
- “영향도 高, 시급 中, 공수 4시간 → 내일 처리”
- 반론 있으면 회의
스프린트 회고
- 잘한 판단 / 아쉬운 판단
- 기준 업데이트
컨플루언스에 문서화했다. “우선순위 판단 가이드”
누가 물어도. 여기 보라고.
자주 하는 실수들
실수 1: 목소리 큰 사람 먼저
대표님 요청이라고. 무조건 최우선 아니다.
영향도 낮으면. 정중하게 설명한다.
“네, 중요하지만 결제 버그가 먼저입니다. 내일 시작할게요.”
근거 있으면. 받아들인다.
실수 2: 완벽주의
“모든 버그 다 잡고 릴리즈”
불가능. 영원히 못 낸다.
Critical만 잡고. 나머지는 백로그.
완벽보다 실행.
실수 3: 기준 없이 ‘감’으로
“이거 급해 보이는데?”
숫자로 말한다. “전체 유저의 3%에게만 발생, P2입니다.”
데이터 기반. 감정 배제.
실수 4: 개발자한테 판단 떠넘김
“어떻게 생각해요?”
내가 정해야 한다. PM/기획자니까.
개발자는 공수만. 우선순위는 내 일.
판단 못 할 때
그래도 애매할 때 있다.
해결법 3가지
- 데이터 확인
- GA 보고 영향 받은 유저 수
- CS 문의 건수
- 실패율 그래프
- 이해관계자 회의
- 15분 긴급 미팅
- 각자 입장 청취
- 다수결 or PM 결정
- MVP 사고
- 최소한으로 해결 가능?
- 임시 방편 먼저
- 근본 해결은 나중
완벽한 판단은 없다. 빠른 판단이 중요.
3개월 후
이제는. 이슈 터져도 덜 당황한다.
기준이 있으니까. 팀도 안다.
개발자가 먼저 말한다. “이거 P1인 것 같은데요?”
디자이너도. “이건 다음 스프린트 가능한가요?”
우선순위 언어. 팀 전체가 쓴다.
릴리즈 주간. 여전히 바쁘다.
하지만. 싸우진 않는다.
기준 없으면 매번 싸운다. 기준 있으면 한 번만 설명한다.