게임 출시 전 Blocker 이슈 관리: 런치 일정 조율 실무 가이드
게임 출시 직전 Blocker 이슈를 명확한 기준으로 분류하고 영향도·해결 가능성·일정 여유를 수치화해 출시일과 스코프를 합리적으로 조율하는 실무 방법을 정리합니다.
출시 전 Blocker는 ‘불편한 버그’가 아니라 현재 빌드로는 출시 승인 조건을 충족할 수 없게 만드는 문제다. 해결의 핵심은 이슈를 많이 닫는 것이 아니라 출시 기준을 먼저 고정하고 각 Blocker가 일정·품질·플랫폼 심사에 주는 영향을 같은 언어와 수치로 판단하는 데 있다.
게임 출시 전 Blocker 이슈란 무엇인가?
Blocker는 다음 중 하나 이상을 충족하는 이슈로 정의하는 편이 실무에서 명확하다.
- 플레이어가 핵심 진행, 결제, 로그인, 저장을 완료할 수 없다.
- 크래시, 데이터 손상, 심각한 보안 문제로 정상 플레이가 불가능하다.
- Steam, PlayStation, Xbox, Nintendo Switch, 모바일 스토어 등 목표 플랫폼의 필수 인증 또는 정책 조건을 통과할 수 없다.
- 법무·등급분류·개인정보 처리와 관련된 출시 요건을 충족하지 못한다.
‘치명적’이라는 표현만으로 우선순위를 정하면 팀마다 판단이 달라진다. 따라서 Severity, 출시 영향, 우회 가능성, 재현율을 분리해 기록해야 한다.
| 항목 | 확인 질문 | Blocker 판정 예시 |
|---|---|---|
| 핵심 경로 | 신규 사용자가 튜토리얼 후 핵심 콘텐츠에 진입하는가? | 특정 기기에서 튜토리얼 완료 후 무한 로딩 |
| 데이터 안전성 | 저장 데이터가 유실 또는 손상되는가? | 자동 저장 중 앱 종료 시 세이브 파일 손상 |
| 결제·계정 | 구매·로그인·복구가 정상 작동하는가? | 인앱 결제 완료 뒤 지급 실패 |
| 플랫폼 요건 | 제출 빌드가 인증·정책을 통과하는가? | 필수 연령 등급 고지 누락 |
| 우회 방법 | 일반 플레이어가 안전하게 회피할 수 있는가? | 설정 변경으로도 진행 불가 |
출시 Blocker는 왜 일정 충돌로 번지는가?
출시 막바지에는 기능 개발, QA 회귀 테스트, 로컬라이제이션, 퍼스트파티 제출, 마케팅 소재 확정이 동시에 진행된다. 이때 Blocker 하나의 실제 비용은 수정 시간만이 아니다. 수정 이후의 빌드 생성, 대상 플랫폼 검증, 회귀 테스트, 제출 재심사까지 포함해야 한다.
출시 의사결정에는 최소한 다음 값을 함께 본다.
여기서 Impact는 핵심 경로·매출·인증에 미치는 영향, Reproduction Rate는 재현율, Workaround Coverage는 안전한 우회가 가능한 사용자 비율, Uncertainty는 원인과 수정 검증의 불확실성이다. 정확한 수식 자체보다 모든 직군이 같은 기준으로 판단하는 것이 중요하다.
Blocker 이슈를 어떻게 분류하고 우선순위를 정할까?
1. 출시 기준을 이슈보다 먼저 문서화한다
Jira, Linear, Notion, 스프레드시트 중 어떤 도구를 쓰든 출시 승인 기준을 한 페이지로 고정한다. 예를 들어 ‘P0 이슈 0건’, ‘저장 데이터 손상 이슈 0건’, ‘목표 기기군 크래시 프리 세션 99.5% 이상’, ‘플랫폼 제출 체크리스트 완료’처럼 검증 가능한 문장으로 쓴다.
P0는 심각도 자체가 아니라 출시 승인 불가 상태를 뜻하도록 정의하면 혼선을 줄일 수 있다.
2. 이슈마다 단일 책임자와 다음 검증 시점을 지정한다
각 Blocker에는 담당 개발자 외에도 의사결정 책임자(DRI, Directly Responsible Individual)를 둔다. DRI는 원인 분석이 막혔을 때 사람을 모으고 일정 판단에 필요한 정보를 갱신하며 해결 여부를 QA와 합의하는 역할을 맡는다.
이슈 템플릿에는 다음 필드를 권장한다.
| 필드 | 기록 내용 |
|---|---|
| ID·제목 | 증상보다 사용자 영향이 드러나는 제목 |
| 빌드 정보 | 게임 버전, 커밋 SHA, 플랫폼, 디바이스, OS 버전 |
| 재현 절차 | 시작 상태부터 입력 순서까지 |
| 영향 범위 | 신규·복귀 사용자, 지역, 결제 수단, 기기군 |
| 임시 우회책 | 안전성 검증 여부와 안내 가능 여부 |
| DRI | 상황 공유와 의사결정 준비 책임자 |
| 다음 판정 시각 | 예: 오늘 16:00 원인 확정 또는 일정 재평가 |
| 종료 조건 | 수정 머지뿐 아니라 QA 통과 기준 |
3. ‘수정 완료’와 ‘출시 가능’을 구분한다
코드가 머지되었다고 Blocker가 닫히는 것은 아니다. 최소한 재현 시나리오 통과, 인접 기능 회귀 테스트, 대상 플랫폼 빌드 검증까지 완료되어야 한다. 특히 Unity의 Addressables, Unreal Engine의 패키징 설정, 서버 피처 플래그처럼 빌드 환경과 배포 설정이 관여하는 문제는 릴리스 후보 빌드에서 다시 확인해야 한다.
런치 일정은 어떤 순서로 조율해야 할까?
Step 1. 사실과 가정을 분리한다
상태 회의에서는 ‘오늘 안에 고칠 것 같다’ 대신 다음처럼 기록한다.
- 사실: Android 14, Galaxy S23에서 결제 후 아이템 지급 실패가 재현된다.
- 사실: iOS 빌드에서는 같은 계정으로 재현되지 않는다.
- 가정: 서버 영수증 검증 요청의 타임아웃 처리가 원인일 수 있다.
- 다음 확인: 서버 로그와 클라이언트 요청 ID를 14:00까지 대조한다.
이 구분은 낙관적인 일정 추정을 줄이고 논의를 해결 행동으로 되돌린다.
Step 2. 수정 경로와 대체 경로를 함께 산정한다
각 P0 이슈에는 최소 두 가지 경로를 준비한다.
| 경로 | 내용 | 일정 영향 | 사용 조건 |
|---|---|---|---|
| 근본 수정 | 원인을 고치고 전체 회귀 테스트 | 높음 | 수정 범위와 검증 시간이 확보될 때 |
| 기능 제한 | 피처 플래그로 위험 기능을 비활성화 | 중간 | 핵심 경험과 정책 요건을 유지할 수 있을 때 |
| 출시 연기 | 런치일 또는 플랫폼별 출시일 조정 | 높음 | 안전한 우회와 제한이 불가능할 때 |
기능 제한은 단순히 버튼을 숨기는 작업이 아니다. 기존 저장 데이터, 고객 지원 안내, 분석 이벤트, 스토어 설명, 라이브 운영 대응까지 확인해야 한다. 기능을 끄는 것이 더 큰 Blocker를 만들지 않는지 검토한다.
Step 3. 의사결정 마감 시각을 정한다
출시일보다 중요한 것은 ‘언제까지 결론을 내리지 않으면 선택지가 사라지는가’다. 이를 결정 게이트로 관리한다.
flowchart TD
A[Blocker 등록] --> B{출시 기준 위반 여부}
B -- 아니오 --> C[일반 우선순위로 처리]
B -- 예 --> D[DRI 지정 및 원인 분석]
D --> E{결정 게이트 전 검증 가능?}
E -- 예 --> F[수정 및 회귀 테스트]
E -- 아니오 --> G{기능 제한이 안전한가?}
G -- 예 --> H[스코프 조정 후 검증]
G -- 아니오 --> I[출시일 또는 출시 범위 조정]
F --> J{출시 승인 기준 충족?}
H --> J
J -- 예 --> K[릴리스 승인]
J -- 아니오 --> I예를 들어 플랫폼 제출 마감이 수요일 18:00이고 전체 회귀에 8시간이 필요하다면 화요일 10:00은 단순 중간 점검이 아니라 수정·기능 제한·연기를 가르는 결정 게이트다. 이 시각을 문서와 캘린더에 명시해야 마케팅, 커뮤니티, 퍼블리싱 담당자도 준비할 수 있다.
Blocker 회의는 어떻게 운영해야 할까?
하루 15~20분의 짧은 Blocker 회의는 상태 보고가 아니라 장애물 제거 회의여야 한다. 참석자는 PM, QA 리드, 관련 개발 리드, 빌드·릴리스 담당자처럼 결정을 내리거나 즉시 지원할 수 있는 사람으로 제한한다.
회의마다 다음 네 가지를 갱신한다.
- 새 P0 또는 Blocker가 생겼는가?
- 각 이슈의 재현 조건, 원인 가설, 수정 범위가 달라졌는가?
- 다음 결정 게이트까지 남은 검증 시간이 충분한가?
- 기능 제한, 출시 범위 축소, 일정 변경 중 의사결정이 필요한 항목은 무엇인가?
회의록은 긴 서술보다 결정 로그로 남긴다. ‘무엇을 누가 언제까지 어떤 조건에서 다시 판단하는가’를 한 줄씩 기록하면 다음 회의의 반복 논의를 막을 수 있다.
자주 묻는 질문 (FAQ)
Blocker가 한 건이라도 있으면 무조건 출시를 연기해야 하나?
아니다. 출시 승인 기준을 실제로 위반하는지 안전한 우회책이 있는지 기능 제한 뒤에도 핵심 경험과 플랫폼 요건을 충족하는지를 검증해 판단한다. 단, 데이터 손상과 결제 실패처럼 신뢰를 직접 훼손하는 문제는 연기 기준을 엄격하게 잡는 편이 안전하다.
P0와 Blocker는 같은 뜻인가?
같게 운용할 수도 있지만 분리하는 편이 더 명확하다. P0는 심각도 또는 긴급도를 나타내고 Blocker는 현재 출시 승인 자체를 막는 상태로 정의하면 된다. 팀의 이슈 트래커에서 정의와 종료 조건을 문서로 고정해야 한다.
기능 제한으로 출시할 때 가장 자주 빠뜨리는 것은 무엇인가?
기능을 비활성화한 뒤의 저장 데이터 호환성, 고객 지원 안내, 분석 이벤트, 스토어 문구, 재활성화 계획을 놓치기 쉽다. 피처 플래그 변경도 하나의 릴리스 변경으로 보고 대상 환경에서 검증해야 한다.
마무리
Blocker 관리는 개발팀의 야근으로 해결하는 문제가 아니라 출시 기준과 결정 시간을 관리하는 일이다. 명확한 판정 기준, 이슈별 DRI, 검증까지 포함한 종료 조건, 선택지가 사라지기 전의 결정 게이트를 운영하면 일정 압박 속에서도 품질과 런치 계획을 함께 지킬 수 있다.
