게임 버그 리포트 관리와 P1~P4 우선순위 분류 체계 구축 가이드
게임 개발팀이 버그 리포트를 일관되게 기록하고 P1~P4 우선순위를 판정하는 방법을 정리합니다. 재현 절차, 영향도, 긴급도, SLA와 라이브 패치 기준까지 실무형으로 안내합니다.
게임 버그 리포트의 목적은 발견 목록을 쌓는 일이 아니라 같은 기준으로 고칠 순서를 결정하는 일이다. P1~P4는 버그의 심각도 자체가 아니라 플레이어 영향, 서비스 위험, 우회 가능성, 수정 시급성을 기준으로 정해야 한다. 재현 가능한 리포트와 명시적인 SLA를 함께 운영하면 QA·개발·라이브 운영팀의 판단 비용이 크게 줄어든다.
게임 버그 리포트는 왜 우선순위 체계가 필요한가?
버그가 많아질수록 팀은 “무엇부터 고칠 것인가”보다 “왜 이것을 먼저 고쳐야 하는가”를 설명하는 데 시간을 쓴다. 특히 라이브 게임에서는 크래시, 결제, 데이터 손실, 이벤트 보상, 매치메이킹 문제가 동시에 들어올 수 있다.
우선순위가 없는 리포트는 다음 문제를 만든다.
- QA마다 같은 현상에 다른 중요도를 부여한다.
- 개발자가 재현 정보 부족으로 조사 시간을 다시 쓴다.
- 라이브 이슈가 일반 연출 오류와 같은 대기열에 놓인다.
- 핫픽스 판단이 담당자의 경험이나 목소리 크기에 좌우된다.
따라서 버그 리포트에는 최소한 재현성, 영향 범위, 우회 방법, 발생 환경, 증빙 자료, 우선순위 근거가 있어야 한다.
P1~P4 버그 우선순위는 어떻게 정의할까?
P1~P4는 프로젝트마다 이름을 바꿀 수 있지만 판정 축을 바꾸면 안 된다. 권장 축은 플레이 불가 여부, 금전·데이터 위험, 발생 범위, 우회 가능성, 라이브 일정 영향이다.
| 우선순위 | 판정 기준 | 대표 사례 | 권장 대응 |
|---|---|---|---|
| P1 | 서비스 지속, 결제, 계정, 저장 데이터 또는 다수 이용자의 핵심 플레이를 막는다 | 실행 직후 크래시, 결제 후 재화 미지급, 저장 데이터 손실, 로그인 불가 | 즉시 에스컬레이션, 핫픽스 또는 기능 차단 검토 |
| P2 | 핵심 기능이 크게 훼손되며 우회가 어렵거나 영향 범위가 넓다 | 매치 시작 불가, 퀘스트 진행 불가, 특정 기기군에서 반복 크래시 | 다음 긴급 패치 또는 가장 가까운 릴리스에 수정 |
| P3 | 기능은 동작하지만 품질·밸런스·표현에 명확한 문제가 있고 우회 가능하다 | 특정 스킬 판정 오류, UI 갱신 지연, 잘못된 현지화 텍스트 | 계획된 스프린트에 배정 |
| P4 | 플레이와 운영에 미치는 영향이 작거나 미관상 문제다 | 경미한 애니메이션 끊김, 오탈자, 드문 조건의 UI 정렬 오류 | 여유 일정에 처리 또는 누적 관리 |
심각도와 우선순위는 무엇이 다른가?
심각도(Severity)는 현상이 제품에 주는 기술적·기능적 피해다. 우선순위(Priority)는 지금 수정해야 하는 사업적·운영적 순서다.
예를 들어 개발자 콘솔에서만 보이는 렌더링 오류는 심각도가 높아도 출시 빌드에 포함되지 않는다면 P3 또는 P4가 될 수 있다. 반대로 이벤트 첫날 모든 이용자에게 잘못된 보상이 지급되는 문제는 크래시가 아니어도 P1이 될 수 있다.
P1~P4를 일관되게 판정하는 3단계
1. 플레이어 영향 범위를 확인한다
먼저 영향을 받은 사용자가 누구인지 확인한다.
- 전체 이용자 또는 특정 플랫폼 전체인가?
- 신규 설치자, 복귀 이용자, 결제 이용자처럼 중요한 집단에 집중되는가?
- 한 번 발생하면 진행·저장·보상이 복구되지 않는가?
예를 들어 Android 14 기기에서만 발생하더라도 해당 OS가 전체 활성 이용자의 큰 비중을 차지하고 앱이 실행 즉시 종료된다면 P1 또는 P2 후보가 된다.
2. 우회 가능성과 데이터 위험을 확인한다
앱 재시작, 스테이지 재진입, 설정 변경, 서버 설정 수정처럼 안전한 우회책이 있는지 확인한다. 단, 이용자에게 복잡한 조작을 요구하거나 고객센터 문의가 필요한 방법은 실질적인 우회책으로 보기 어렵다.
다음 중 하나라도 해당하면 우선순위를 올리는 편이 안전하다.
- 결제 금액, 유료 재화, 인벤토리, 세이브 데이터가 사라지거나 중복된다.
- 악용으로 경쟁·경제 시스템이 훼손된다.
- 서버 설정이나 콘텐츠 비활성화로도 피해를 멈출 수 없다.
3. 수정·검증 가능한 처리 시점을 결정한다
P1은 “중요해 보이는 버그”가 아니라 온콜 담당자와 릴리스 책임자가 즉시 알아야 하는 이슈다. 따라서 우선순위와 함께 목표 대응 시간을 기록해야 한다.
| 우선순위 | 최초 확인 목표 | 대응 원칙 |
|---|---|---|
| P1 | 즉시, 최대 30분 이내 | 담당자 호출, 영향 완화, 핫픽스 판단 |
| P2 | 업무 시간 기준 당일 | 원인 분석과 수정 일정 확정 |
| P3 | 다음 트리아지 | 스프린트 백로그에 정식 등록 |
| P4 | 정기 정리 시점 | 누적 후 묶어서 수정 여부 결정 |
flowchart TD
A[버그 접수] --> B{핵심 플레이·결제·데이터에 영향이 있는가?}
B -->|예| C{다수 이용자에게 발생하거나 우회가 어려운가?}
C -->|예| P1[P1: 즉시 에스컬레이션]
C -->|아니오| P2[P2: 긴급 패치 후보]
B -->|아니오| D{기능 품질 또는 밸런스에 명확한 영향이 있는가?}
D -->|예| P3[P3: 스프린트 배정]
D -->|아니오| P4[P4: 누적 관리]재현 가능한 게임 버그 리포트는 어떻게 작성할까?
리포트의 품질은 재현 단계에서 결정된다. “가끔 발생함”으로 끝내지 말고 다른 사람이 같은 빌드와 조건에서 같은 결과를 얻을 수 있게 적는다.
필수 필드 템플릿
제목: [플랫폼][기능] 현상 요약
빌드: 1.12.0(345) / Live 또는 Staging
환경: Android 14, Galaxy S24, Wi-Fi
발생 빈도: 5/5 또는 2/10
사전 조건: 계정 레벨 20, 챕터 4-8 완료, 파티에 캐릭터 A 편성
재현 절차:
1. 로비에서 원정 메뉴를 연다.
2. 4-8 스테이지를 선택한다.
3. 전투 시작 직후 자동 전투를 켠다.
4. 캐릭터 A의 궁극기 발동을 기다린다.
기대 결과: 궁극기 종료 후 적 HP와 전투 UI가 정상 갱신된다.
실제 결과: 적 HP가 0으로 표시되지만 전투가 종료되지 않고 입력도 불가능하다.
영향: 해당 조건에서 스테이지 클리어 불가. 앱 재시작 외 우회 불가.
증빙: 화면 녹화, player.log, 크래시 스택, 요청 ID
우선순위: P2
판정 근거: 핵심 진행을 막고 재현율이 높으며 안전한 우회책이 없다.Unity 프로젝트라면 Application.version, Application.platform, 기기 모델, Player.log, Crashlytics 또는 Sentry의 이벤트 ID를 함께 남긴다. 서버 연동 문제라면 HTTP 상태 코드, API 경로, 요청 ID, 응답 시간과 서버 배포 버전도 포함한다. 개인 정보와 인증 토큰은 첨부 전에 반드시 제거한다.
버그 트리아지 회의는 무엇을 결정해야 하는가?
트리아지는 버그를 읽는 회의가 아니라 결정을 기록하는 회의다. 리포트마다 아래 네 가지를 확정하면 충분하다.
- 재현 여부와 재현 조건을 확정한다.
- P1~P4와 판정 근거를 확정한다.
- 담당 팀과 목표 수정 빌드를 정한다.
- 차단, 롤백, 공지, 보상 같은 라이브 완화 조치를 결정한다.
회의 뒤에는 상태를 New → Confirmed → In Progress → Ready for QA → Verified → Closed처럼 단순하게 유지한다. Cannot Reproduce, Duplicate, Won't Fix 상태에는 반드시 근거와 연결된 원본 이슈를 남긴다.
자주 묻는 질문 (FAQ)
P1 버그는 반드시 즉시 핫픽스해야 하나요?
아니다. 먼저 서버 설정으로 기능을 끄거나 롤백해 피해를 멈출 수 있는지 확인한다. 이용자 피해가 계속되거나 완화책이 없으면 핫픽스가 필요하다.
크래시는 항상 P1인가요?
아니다. 개발 환경에서만 발생하거나 매우 드문 선택 경로에서만 발생하고 재시작으로 복구된다면 P2 또는 P3일 수 있다. 반대로 시작 직후 크래시는 P1이다.
QA가 우선순위를 최종 결정해야 하나요?
QA는 재현성과 사용자 영향을 근거로 초기 등급을 제안한다. 최종 우선순위는 QA, 개발, 프로덕트 또는 라이브 운영 담당자가 일정과 서비스 위험을 함께 보고 확정하는 것이 좋다.
정리
좋은 버그 관리 체계는 복잡한 점수표보다 모든 팀원이 같은 질문에 같은 순서로 답하게 만드는 기준이다. P1~P4를 플레이어 영향, 데이터·금전 위험, 우회 가능성, 발생 범위로 판정하고 리포트에 재현 절차와 판정 근거를 남기면 수정 우선순위가 흔들리지 않는다.
