Jira·Trello 백로그 관리: 게임 버그 P1~P4 우선순위 분류 가이드
게임 개발팀이 Jira 또는 Trello 백로그에서 버그 크리티컬 등급 P1~P4를 일관되게 분류하는 기준과 티켓 작성법, 대응 절차를 실무적으로 정리합니다.
게임 프로젝트에서 P1~P4는 ‘버그가 얼마나 눈에 띄는가’가 아니라 플레이어 영향, 진행 차단 여부, 발생 범위, 우회 가능성을 함께 판단하는 우선순위 체계다. Jira와 Trello의 백로그에 공통 기준을 적용하면 긴급 대응은 빨라지고 스프린트 계획에서 무엇을 미룰지 투명하게 결정할 수 있다.
게임 버그 P1~P4 등급이란 무엇인가?
버그 우선순위는 수정해야 하는 순서를 뜻한다. 심각도(Severity)와 같은 의미로 쓰이기도 하지만 팀 운영에서는 둘을 분리하는 편이 좋다.
- 심각도: 기능·데이터·서비스에 발생한 기술적 손상의 크기
- 우선순위: 지금 어떤 티켓부터 처리할지에 대한 사업·운영 판단
예를 들어 특정 그래픽 효과가 깨지는 버그는 기술적으로 눈에 띄어도 출시 직전 결제 실패나 저장 데이터 손실보다 우선순위가 낮다. P1~P4는 이런 판단을 백로그에서 빠르게 합의하기 위한 공용 언어다.
| 등급 | 기본 의미 | 대표 상황 | 목표 대응 |
|---|---|---|---|
| P1 | 즉시 대응이 필요한 치명적 문제 | 실행 불가, 결제 불가, 데이터 손실, 대규모 접속 장애 | 핫픽스 또는 즉시 작업 전환 |
| P2 | 핵심 경험을 크게 해치는 높은 우선순위 문제 | 메인 퀘스트 진행 불가, 광범위한 크래시, 주요 플랫폼 인증 실패 | 현재 스프린트 내 수정 |
| P3 | 기능은 우회 가능하지만 품질을 떨어뜨리는 문제 | 일부 기기 UI 깨짐, 특정 조건의 보상 오류, 드문 충돌 | 일정과 위험을 고려해 계획 |
| P4 | 영향이 작거나 개선 성격이 강한 문제 | 오탈자, 미세한 정렬 불일치, 재현이 어려운 경미한 연출 오류 | 백로그 보관 후 묶음 처리 |
P1, P2, P3, P4는 어떻게 구분할까?
등급을 정할 때는 단일 기준보다 네 가지 질문을 순서대로 확인한다.
- 플레이를 막는가?
- 게임 실행, 로그인, 결제, 저장, 매치메이킹, 메인 진행이 막히면 P1 또는 P2 후보가 된다.
- 영향 범위가 얼마나 넓은가?
- 전체 사용자, 특정 플랫폼, 특정 지역, 일부 퀘스트 사용자 순으로 범위를 확인한다.
- 안전한 우회 방법이 있는가?
- 재시작, 재접속, 설정 변경으로 해결되더라도 데이터 손실이나 결제 오류가 남으면 우회 가능으로 보지 않는다.
- 시간 민감도가 있는가?
- 라이브 이벤트, 스토어 심사, 광고 캠페인, 시즌 종료와 연결되면 같은 심각도라도 우선순위를 올린다.
아래처럼 점수화하면 담당자마다 판단이 흔들리는 일을 줄일 수 있다.
각 항목을 0~1 범위로 정규화해도 좋지만 수식의 정밀함보다 팀이 같은 기준으로 판단하는 것이 더 중요하다. 예를 들어 Impact=1, Scope=1, Urgency=1, Workaround=0인 결제 실패는 가장 높은 대응 점수를 받는다.
P1: 서비스·데이터·핵심 진입을 즉시 막는 버그
P1은 개발자가 바쁜 상태라는 이유만으로 미룰 수 없는 문제다. 일반적으로 당번을 정하고 진행 중인 작업을 중단해 원인 파악과 완화 조치부터 시작한다.
P1 예시는 다음과 같다.
- 프로덕션 빌드가 실행되지 않거나 로그인할 수 없다.
- 인앱 결제가 실패하거나 결제는 됐지만 상품이 지급되지 않는다.
- 저장 데이터가 삭제·덮어쓰기되어 복구가 어렵다.
- 다수 사용자가 매치에 입장하지 못하거나 서버가 반복적으로 종료된다.
- 악용 시 유료 재화 또는 핵심 경쟁 공정성이 무너지는 복제 취약점이 있다.
P1 티켓에는 수정 완료만 적지 말고 임시 완화 여부를 먼저 기록한다. 예를 들어 문제가 되는 상점을 원격 설정으로 비활성화하거나 위험한 보상 버튼을 숨기는 조치가 가능하다.
P2: 핵심 진행 또는 주요 사용자군을 크게 해치는 버그
P2는 즉각적인 서비스 중단까지는 아니어도 현재 스프린트에서 처리해야 할 문제다. 특히 메인 콘텐츠 진행 불가, 특정 콘솔 플랫폼의 반복 크래시, 출시 후보 빌드의 인증 차단은 P2로 두는 경우가 많다.
다만 ‘한 명이라도 진행이 막히면 무조건 P2’라고 정하면 백로그가 과열된다. 발생 조건, 영향을 받는 사용자 비율, 고객지원으로 안전하게 안내할 수 있는 우회 방법을 함께 확인해야 한다.
P3: 계획된 수정이 필요한 일반 버그
P3는 플레이어 경험을 분명히 해치지만 플레이를 지속할 수 있고 위험이 제한적인 문제다. 다음 스프린트에 배치하거나 같은 기능을 수정하는 작업과 묶어서 해결한다.
- 특정 해상도에서 버튼 간격이 어긋난다.
- 선택형 사이드 퀘스트의 보상 아이콘이 잘못 표시된다.
- 특정 장비 조합에서 이펙트가 한 프레임 늦게 재생된다.
P4: 기록은 남기되 즉시 비용을 쓰지 않는 문제
P4는 ‘무시해도 되는 티켓’이 아니다. 반복되는 오탈자, 튜토리얼 문구 혼선, 드문 카메라 흔들림처럼 작은 문제를 기록해 품질 저하가 누적되지 않도록 한다.
P4는 주기적으로 묶어 처리한다. 예를 들어 스프린트마다 전체 개발 여력의 5~10%를 폴리시와 결함 정리에 배정하거나 기능 담당자가 관련 파일을 수정할 때 함께 해결하도록 운영할 수 있다.
Jira와 Trello 백로그에 P1~P4를 어떻게 설정할까?
도구가 달라도 필드와 흐름은 같게 유지하는 편이 좋다. Jira는 Priority 필드와 JQL 필터를 중심으로 Trello는 라벨·사용자 지정 필드·자동화를 조합해 구현한다.
| 항목 | Jira 권장 설정 | Trello 권장 설정 | 운영 원칙 |
|---|---|---|---|
| 우선순위 | Priority: P1, P2, P3, P4 | 단일 선택 사용자 지정 필드 또는 전용 라벨 | P1~P4를 하나만 선택 |
| 상태 | Open, Triage, In Progress, Verify, Done | Inbox, Triage, Doing, Verify, Done 리스트 | 우선순위와 상태를 분리 |
| 영향 범위 | Affected Users, Platform, Build 필드 | 카드 사용자 지정 필드 | 추측 대신 측정값 기록 |
| 재현 정보 | Description 템플릿, 첨부 파일 | 카드 설명, 체크리스트, 첨부 파일 | 재현 절차를 필수화 |
| 긴급 알림 | P1 생성·변경 자동 알림 | P1 라벨 부여 자동 알림 | 알림 대상과 당번을 제한 |
Jira 티켓 템플릿 예시
요약: [P2][Android] Chapter 3 보스 처치 후 다음 퀘스트가 시작되지 않음
환경
- 빌드: 1.8.0 (482)
- 플랫폼: Android 14 / Galaxy S23
- 계정 상태: Chapter 3 진행 중
재현 절차
1. Chapter 3의 보스 전투를 시작한다.
2. 보스를 처치하고 결과 연출이 끝날 때까지 기다린다.
3. 월드 맵으로 돌아간 뒤 메인 퀘스트 목록을 확인한다.
실제 결과
- 다음 메인 퀘스트가 생성되지 않는다.
기대 결과
- Chapter 4 시작 퀘스트가 자동으로 생성된다.
영향 및 우회
- 영향: Chapter 3 완료 사용자
- 우회: 없음
- 발생률: QA 10회 중 10회 재현
증거
- 로그: quest-state-482.log
- 영상: chapter3-quest-block.mp4티켓 제목에 [P2]를 넣는 방식은 검색성과 알림 가독성에는 도움이 되지만 우선순위의 원본 데이터는 반드시 Jira의 Priority 필드 또는 Trello의 단일 필드에 둔다. 제목만 바꾸면 필터, 보고서, 자동화가 쉽게 깨진다.
버그 트리아지는 어떤 순서로 진행해야 할까?
트리아지는 새 버그를 등록한 뒤 방치하지 않고 재현 가능성·영향·우선순위·담당을 결정하는 짧은 운영 절차다. 매일 10~15분 또는 스프린트 중 2~3회처럼 팀 규모에 맞는 고정 리듬을 만든다.
flowchart TD
A[버그 등록] --> B{재현 가능한가?}
B -->|예| C[영향 범위와 우회 방법 확인]
B -->|아니오| D[로그·영상·빌드 정보 요청]
C --> E{실행·결제·저장·핵심 진행 차단인가?}
E -->|예| F[P1 또는 P2 지정]
E -->|아니오| G{사용자 영향이 넓거나 출시 일정에 민감한가?}
G -->|예| H[P2 또는 P3 지정]
G -->|아니오| I[P3 또는 P4 지정]
F --> J[담당자·목표 수정 버전·검증 조건 설정]
H --> J
I --> J
D --> K[재현 대기 백로그]1. 등록 품질을 먼저 확인한다
우선순위를 논의하기 전에 빌드 번호, 플랫폼, 재현 절차, 실제 결과, 기대 결과, 로그나 영상이 있는지 확인한다. 이 정보가 없으면 ‘재현 대기’ 상태로 보내고 P1~P4를 확정하지 않는다.
2. 영향과 우회 가능성을 판정한다
‘크래시가 난다’는 설명만으로 P1을 정하지 않는다. 전체 세션의 크래시율, 특정 기기·콘텐츠에서만 나는지 재시작 뒤 진행 가능한지 저장 손상 가능성이 있는지를 확인한다.
3. 우선순위와 수정 목표를 함께 확정한다
P1은 담당자와 완화 계획을 즉시 정한다. P2는 현재 스프린트 또는 다음 핫픽스 목표 버전을 지정한다. P3·P4도 단순히 Backlog로 보내지 말고 재검토 시점이나 연관 에픽을 남긴다.
P1 백로그가 너무 많아지는 이유와 해결 방법
P1이 계속 늘어난다면 버그가 갑자기 더 심각해진 것보다 등급의 정의가 넓어졌을 가능성이 크다. 특히 ‘고객이 불만을 제기했다’, ‘담당자가 빨리 고치고 싶다’, ‘데모에서 보이면 곤란하다’만으로 P1을 부여하면 긴급도가 무뎌진다.
해결 방법은 다음과 같다.
- P1의 필수 조건을 문서화한다. 실행 불가, 결제 오류, 데이터 손실, 광범위한 서비스 장애, 심각한 악용 가능성처럼 명확한 조건을 둔다.
- P1 승인자를 정한다. QA 리드, 프로덕트 오너, 온콜 리드처럼 등급 변경 권한자를 정해 둔다.
- P1 종료 조건을 정의한다. 코드 수정뿐 아니라 운영 완화, 모니터링 확인, 회귀 테스트까지 완료해야
Done으로 옮긴다. - 주간 지표를 검토한다. 생성 건수, 평균 대응 시간, 재오픈 수, 원인 영역을 보면 반복 문제를 찾을 수 있다.
자주 묻는 질문 (FAQ)
P1과 P2의 가장 큰 차이는 무엇인가?
P1은 즉시 대응하지 않으면 서비스 운영, 결제, 데이터 안전성, 다수 사용자의 핵심 진입이 계속 손상되는 문제다. P2는 심각하지만 안전한 범위 제한 또는 단기 대응이 가능하며 현재 스프린트나 가까운 핫픽스에서 해결할 문제다.
재현되지 않는 크래시는 어느 등급으로 등록해야 하나?
처음에는 확정 등급 대신 Triage 또는 재현 대기로 두고 로그·기기·빌드·발생 시각을 수집한다. 다만 크래시율 급증, 결제 직후 발생, 다수 사용자 보고처럼 운영 신호가 강하면 조사 작업 자체를 P1 또는 P2로 올릴 수 있다.
버그 우선순위는 누가 결정해야 하나?
QA가 증거와 재현 정보를 정리하고 개발 리드가 기술 위험을 판단하며 프로덕트 오너 또는 프로듀서가 일정·매출·라이브 운영 영향을 반영하는 구조가 안정적이다. P1은 당번 또는 지정 승인자가 빠르게 확정할 수 있어야 한다.
정리
좋은 백로그 관리는 모든 버그를 빨리 고치는 일이 아니라 같은 기준으로 가장 위험한 문제부터 처리하는 일이다. Jira와 Trello에 P1~P4 필드, 재현 정보 템플릿, 고정된 트리아지 리듬을 함께 도입하면 우선순위 논쟁을 줄이고 팀의 수정 여력을 중요한 문제에 집중할 수 있다.
