Jira와 Trello로 게임 버그 트래킹·백로그 우선순위 정하는 법

게임 개발에서 버그 트래킹의 핵심은 티켓을 많이 만드는 일이 아니라 같은 기준으로 재현·판단·처리하는 운영 체계를 만드는 것이다. Jira는 이슈 상태와 작업 이력을 설정할 수 있고 Trello는 리스트와 카드로 작업을 시각화할 수 있다. 제품 기능은 플랜과 설정에 따라 다르며, 아래 역할 구분과 점수식은 팀이 선택할 수 있는 운영 예시다.

Jira와 Trello를 함께 써야 하는 이유는 무엇인가?

두 도구는 경쟁 관계라기보다 관리 밀도가 다르다. Jira는 버그 원인, 재현 절차, 담당자, 연결된 스프린트와 릴리스까지 추적하기 좋다. Trello는 오늘 처리할 일과 병목을 보드에서 빠르게 공유하기 좋다.

구분	Jira	Trello
적합한 대상	버그, 기술 부채, 릴리스 이슈	주간 목표, 소규모 태스크, 회의 후 액션 아이템
강점	워크플로, 필드, 필터, 리포트, 이력	단순한 보드, 빠른 가시성, 낮은 진입 장벽
권장 운영	원본 이슈 저장소(Source of Truth)	실행 큐와 협업 보드
주의점	필드·워크플로를 늘리면 등록 절차가 복잡해질 수 있음	카드가 늘면 상세 이슈와 상태의 기준 저장소를 별도로 정할 필요가 있음

가장 안정적인 방식은 Jira를 단일 원본 저장소로 두고 Trello에는 이번 주 또는 현재 스프린트에서 실제로 움직일 카드만 올리는 것이다. Trello 카드에는 Jira 이슈 키와 링크를 넣고 우선순위 변경과 완료 처리의 최종 기록은 Jira에서 한다.

게임 버그 티켓에는 무엇을 기록해야 하는가?

버그 제목만 보고 수정할 수 있는 티켓은 드물다. 특히 프레임 의존 문제, 저장 데이터 손상, 네트워크 동기화 오류는 재현 환경이 빠지면 조사 정보가 부족할 수 있다.

Jira 버그 이슈에 둘 수 있는 필드

필드	작성 예시	목적
제목	[Android][전투] 60fps에서 회피 후 피격 판정이 남음	플랫폼과 증상을 한 줄에 식별
빌드 버전	0.8.14 (412)	수정 여부와 회귀 범위 판단
환경	Galaxy S23, Android 15, 60Hz	기기·OS·성능 조건 확인
재현 절차	아래 1~5단계	개발자가 독립적으로 재현
기대 결과	회피 무적 시간에는 피해가 없어야 함	기획 의도 명시
실제 결과	회피 애니메이션 중 피해 UI가 표시됨	관찰된 현상 분리
재현율	5/5, 2/10	조사 우선순위와 검증 난이도 판단
증거	영상, 로그, 스택 트레이스, 저장 파일	추측 대신 근거 제공
영향 범위	전투, 튜토리얼, PvP	사용자와 시스템 영향 판단

재현 절차는 테스트 케이스처럼 번호를 붙인다.

1. 빌드 0.8.14 (412)를 새로 설치한다.
2. 튜토리얼을 완료한 뒤 스테이지 3-2에 진입한다.
3. 적 궁수의 투사체가 플레이어에게 닿기 직전 회피 버튼을 누른다.
4. 화면 녹화와 combat.log를 저장한다.
5. 캐릭터가 회피 상태인데도 체력이 감소하는지 확인한다.

티켓 제목에 원인을 단정하지 않는 것도 중요하다. Collider가 꺼지지 않음보다 회피 중 피격 판정이 남음이 낫다. 전자는 가설이고 후자는 관찰 결과이기 때문이다.

버그 심각도와 우선순위는 어떻게 다르게 정할까?

심각도(Severity)는 버그 자체가 제품에 주는 피해를 기술하는 팀의 분류이고, 우선순위(Priority)는 팀이 처리 순서를 정하는 값이다. 아래 S1~S5 분류는 한 가지 예시이며 Jira의 보편 표준이 아니다. 동일한 버그라도 출시일, 우회 방법, 발생 빈도에 따라 우선순위는 달라질 수 있다.

등급	심각도 기준	게임 예시
S1 Blocker	진행 불가, 데이터 손실, 결제·보안 문제	저장 파일이 초기화됨, 결제 후 재화 미지급
S2 Critical	핵심 플레이가 광범위하게 손상됨	모든 전투에서 입력이 멈춤
S3 Major	주요 기능은 동작하지만 경험이 크게 저하됨	특정 보스전에서 보상 계산이 잘못됨
S4 Minor	우회 가능하며 제한된 범위의 문제	특정 해상도에서 버튼이 일부 겹침
S5 Trivial	기능 영향이 거의 없는 표현 문제	오탈자, 미세한 UI 정렬 오류

우선순위는 별도 필드로 P0부터 P3까지 운영할 수 있다.

• P0: 핫픽스 또는 즉시 작업. 라이브 장애, 데이터 손상, 결제 문제.
• P1: 현재 스프린트에서 처리. 핵심 루프나 출시 품질을 위협.
• P2: 다음 계획 시점에 재평가. 우회 가능하거나 제한된 문제.
• P3: 백로그 보관. 수정 효용이 낮거나 증거가 부족함.

백로그 우선순위는 점수로 어떻게 합의할까?

점수는 결정을 자동화하는 도구가 아니라 팀의 판단 근거를 드러내는 공통 언어다. 아래는 RICE를 참고해 만든 팀별 예시이며, 공식 Jira/Trello 표준 점수식이나 검증된 우선순위 지표는 아니다.

$$PriorityScore = \frac{Impact \times Urgency \times Confidence}{Effort}$$

각 값은 1~5점으로 제한한다.

항목	1점	3점	5점
Impact	일부 화면의 미관 문제	특정 콘텐츠의 완료율 저하	결제, 저장, 핵심 진행을 막음
Urgency	다음 분기까지 영향이 작음	다음 스프린트에 필요	라이브 장애 또는 출시 차단
Confidence	제보 1건, 재현 불가	재현 가능, 원인 불명	로그와 재현 절차로 원인 범위가 좁혀짐
Effort	반나절 이내	1~3일	여러 시스템 변경 또는 회귀 테스트 필요

예를 들어 결제 완료 후 재화가 지급되지 않는 버그가 Impact 5, Urgency 5, Confidence 4, Effort 2라면 점수는 다음과 같다.

$$PriorityScore = \frac{5 \times 5 \times 4}{2} = 50$$

반면 특정 장식 UI의 1픽셀 정렬 오류가 Impact 1, Urgency 1, Confidence 5, Effort 1이면 점수는 5다. 다만 점수가 높아도 작업을 바로 시작하기 전에 담당자가 재현과 영향 범위를 한 번 더 확인해야 한다.

Jira와 Trello 기반 버그 트래킹 프로세스 3단계

1. Jira에서 접수와 분류를 표준화한다

Jira 이슈 유형은 최소한 Bug, Task, Story, Spike로 구분한다. 버그에는 Severity, Priority, Found In Build, Reproduction Rate, Platform, Component 필드를 둔다. Component는 예를 들어 Combat, UI, Save, Network, LiveOps처럼 담당 영역과 연결한다.

상태는 너무 세분화하지 말고 아래 정도로 시작한다.

flowchart LR
    A[Reported] --> B[Triage]
    B --> C[Ready]
    C --> D[In Progress]
    D --> E[Code Review]
    E --> F[QA Verify]
    F --> G[Done]
    F --> H[Reopened]
    H --> C
    B --> I[Won't Fix]

Triage에서 재현 여부, 중복 이슈, 심각도, 우선순위 점수를 확정한다. 정보가 부족하면 바로 개발자에게 넘기지 말고 Need Info 라벨을 붙여 제보자에게 로그나 영상을 요청한다.

2. Trello에는 실행할 작업만 동기화한다

Trello 보드는 This Week, In Progress, Review/QA, Done 네 개의 리스트로 충분하다. Jira의 모든 이슈를 옮기지 않고 계획 회의에서 선택된 P0, P1 이슈와 꼭 필요한 P2만 카드로 만든다.

카드 제목 앞에는 Jira 키를 붙인다. 예를 들어 [GAME-1842] 전투 회피 피격 판정처럼 작성한다. 카드 설명에는 Jira 링크, 담당자, 목표 빌드만 넣고 상세 재현 절차와 판정 기록은 Jira에 남긴다. 이 원칙을 지키면 Trello가 또 하나의 낡은 백로그가 되는 일을 막을 수 있다.

3. 매주 30분 트리아지 회의로 백로그를 갱신한다

회의 참석자는 프로듀서 또는 PM, QA 대표, 클라이언트 또는 서버 담당자, 필요 시 기획 담당자 등으로 정할 수 있다. 예를 들어 주 1회 짧은 트리아지를 운영한다면 다음 순서로 진행할 수 있다.

1. 새 Reported 이슈에서 중복과 재현 불가 항목을 먼저 정리한다.
2. 재현 가능한 이슈에 심각도와 점수를 부여한다.
3. 점수 상위 항목을 출시 일정, 담당자 가용성, 의존성과 함께 검토한다.
4. 이번 주 Trello 카드와 Jira 스프린트를 동시에 갱신한다.
5. Won't Fix와 Deferred 항목에는 판단 이유와 재검토 시점을 기록한다.

Won't Fix는 실패가 아니다. 수정 비용이 효용보다 큰 문제를 명시적으로 관리하는 결정이다. 단, 사용자에게 영향이 있는 항목이라면 릴리스 노트, 고객 지원 매크로, Known Issues 문서에 반영할지 함께 결정한다.

우선순위 산정에서 자주 실패하는 패턴

모든 버그를 긴급으로 표시하는 경우

모든 이슈가 P1이면 실질적으로 우선순위가 없다. P0는 라이브 서비스 장애와 출시 차단처럼 즉시 대응이 필요한 경우로 제한한다. 각 등급의 예시를 팀 위키에 고정해 두면 담당자마다 기준이 달라지는 문제를 줄일 수 있다.

발생 빈도만 보고 결정하는 경우

발생 빈도가 낮아도 저장 데이터 손상이나 결제 오류는 높은 우선순위다. 반대로 자주 보이는 시각적 문제라도 수정 비용과 실제 이탈 영향을 함께 봐야 한다. 빈도는 Impact를 보완하는 데이터이지 단독 기준이 아니다.

수정 완료를 곧바로 종료로 처리하는 경우

개발 완료와 검증 완료는 다르다. Jira는 In Progress에서 바로 Done으로 보내지 말고 QA Verify를 거치게 한다. QA는 원래 재현 절차, 수정 주변 경로, 대상 플랫폼과 빌드 번호를 확인한 뒤 종료한다.

자주 묻는 질문 (FAQ)

Jira와 Trello 중 하나만 써도 되나요?

소규모 팀이 단기 프로젝트를 진행한다면 Trello만으로 시작할 수 있다. 그러나 빌드별 버그 이력, 릴리스 추적, 누적 백로그가 중요해지면 Jira를 원본 이슈 저장소로 두는 편이 안정적이다.

버그 점수는 누가 정해야 하나요?

PM 또는 프로듀서가 최종 우선순위를 책임지되 영향도는 기획·QA, 긴급도는 라이브 운영, 수정 비용은 개발 담당자의 의견을 함께 반영해야 한다. 한 사람이 모든 값을 단독으로 정하면 점수의 신뢰도가 떨어진다.

재현되지 않는 버그는 닫아야 하나요?

즉시 종료하기보다 Need Info 또는 Cannot Reproduce 상태로 두고 빌드 버전·기기·영상·로그를 요청한다. 같은 제보가 누적되거나 신규 증거가 생기면 다시 트리아지한다.

정리

Jira에는 버그의 사실과 의사결정 이력을 남기고 Trello에는 팀이 지금 실행할 일만 올린다. 여기에 심각도와 점수 기반 우선순위를 결합하면 백로그는 단순한 할 일 목록이 아니라 출시 품질과 팀의 시간을 함께 관리하는 도구가 된다.