콘솔 인증 제출 전 Content Freeze 날짜 역산법: 수정 허용 범위와 재심사 리스크 관리
콘솔 인증 제출일에서 역산해 Content Freeze 날짜를 정하는 실무 가이드입니다. 패키징·검증·수정·재심사 버퍼를 계산하고 인증 이후 허용할 수정 범위와 릴리스 리스크를 줄이는 협업·문서화 기준까지 단계별로 정리합니다.
핵심 요약
콘솔 인증 제출용 Content Freeze 날짜는 출시일이 아니라 인증 제출 목표일에서 역산해야 합니다. 계산에는 빌드 패키징, 내부 검증, 수정 버퍼, 재심사 대응 시간을 포함합니다. Freeze 이후에는 인증 실패를 막는 필수 수정만 예외 승인으로 허용하고 신규 콘텐츠나 일반적인 품질 개선은 다음 빌드로 분리해야 재심사 리스크를 통제할 수 있습니다.
Content Freeze란 무엇인가?
Content Freeze는 인증 제출에 사용할 빌드의 기능과 콘텐츠를 고정하는 시점입니다. 이 날짜가 지나면 팀은 새로운 기능을 추가하거나 대규모 에셋을 교체하지 않고 제출 빌드의 안정성과 인증 대응에 집중합니다.
중요한 점은 Content Freeze가 모든 수정의 금지를 의미하지 않는다는 것입니다. 인증 실패를 유발하는 치명적 결함이나 플랫폼 요구사항 위반은 수정할 수 있지만 수정 가능 여부와 승인 절차를 사전에 문서화해야 합니다.
플랫폼마다 인증 문서의 명칭과 세부 요구사항은 다를 수 있습니다. Technical Requirements Checklist, Technical Certification Requirements, TRC, TCR 등 현재 사용 중인 파트너 포털의 최신 문서를 기준으로 판단해야 합니다.
Content Freeze 날짜는 어떻게 역산하는가?
먼저 출시일에서 역산하지 말고 인증 제출 목표일을 정합니다. 제출 목표일은 인증팀이 실제로 빌드를 업로드할 예정일이며 플랫폼의 심사 완료 예정일과는 구분해야 합니다.
기본 계산식은 다음과 같습니다.
예를 들어 인증 제출 목표일이 10월 20일이고 다음 시간이 필요하다고 가정해 보겠습니다.
| 항목 | 소요 시간 |
|---|---|
| 골드 후보 빌드 패키징과 업로드 | 1영업일 |
| QA·플랫폼별 체크리스트 검증 | 3영업일 |
| 검증 중 발견된 문제 수정 | 3영업일 |
| 수정 빌드 재검증 버퍼 | 2영업일 |
| 인증 실패 시 대응 버퍼 | 5영업일 |
| 합계 | 14영업일 |
이 경우 Content Freeze는 인증 제출 목표일보다 최소 14영업일 앞에 설정합니다. 실제 일정에는 주말, 공휴일, 플랫폼 포털의 업로드 지연, 패키지 재생성 시간을 별도로 반영해야 합니다.
역산할 때 반드시 분리해야 하는 날짜
| 날짜 | 의미 | 담당 의사결정 |
|---|---|---|
| Content Freeze | 기능·콘텐츠 변경을 원칙적으로 중단하는 날 | 프로덕트 매니저, 디렉터 |
| RC 빌드 시작 | 인증 제출 후보 빌드 제작을 시작하는 날 | 클라이언트·릴리스 엔지니어 |
| 인증 제출일 | 플랫폼 포털에 빌드를 업로드하는 날 | 인증 담당자 |
| 인증 결과 예상일 | 승인 또는 실패 결과를 예상하는 날 | 프로덕트 매니저 |
| 출시일 | 소비자에게 빌드를 배포하는 날 | 전체 릴리스 팀 |
인증 결과 예상일을 출시일과 동일하게 잡으면 실패 결과에 대응할 시간이 사라집니다. 따라서 출시일이 고정되어 있다면 인증 제출일은 출시일보다 충분히 앞서야 하며 인증 제출일이 고정되어 있다면 Content Freeze가 자동으로 앞당겨집니다.
콘솔 인증 일정의 임계경로는 무엇인가?
인증 제출 일정에서 임계경로는 다음처럼 이어집니다.
flowchart LR
A[Content Freeze] --> B[RC 빌드 생성]
B --> C[플랫폼 체크리스트 검증]
C --> D[결함 수정 및 재검증]
D --> E[인증 패키징]
E --> F[콘솔 인증 제출]
F --> G[심사 결과 대응]이 경로에 포함된 작업은 하나가 지연되면 인증 제출일 전체가 지연됩니다. 특히 플랫폼별 패키징, 서명, 매니페스트 생성, 저장 데이터 호환성 검증, 네트워크 계정 설정 검증은 일반 QA와 별도 시간이 필요할 수 있습니다.
일정표에는 단순한 작업명보다 산출물을 적는 편이 효과적입니다. 예를 들어 QA 진행보다 체크리스트 100% 완료 및 실패 항목 Issue ID 등록이라고 작성하면 완료 조건과 책임 범위가 분명해집니다.
Freeze 이후 어떤 수정을 허용해야 하는가?
수정 허용 범위는 감정이나 직급이 아니라 인증 실패 가능성과 변경 영향도로 판단해야 합니다. 다음 기준을 사용할 수 있습니다.
| 수정 유형 | Freeze 이후 허용 | 예시 | 조건 |
|---|---|---|---|
| 인증 차단 결함 | 허용 | 플랫폼 요구사항 위반, 제출 불가 오류 | 인증 담당자와 PM 승인 |
| 크래시·데이터 손상 | 허용 | 특정 저장 데이터에서 크래시, 진행도 손실 | 재현 절차와 회귀 테스트 필수 |
| 보안·개인정보 문제 | 허용 | 민감 정보 노출, 권한 우회 | 즉시 수정 및 릴리스 리스크 보고 |
| 출시 차단 수준의 기능 결함 | 조건부 허용 | 핵심 진행이 불가능한 소프트락 | 영향 범위와 대체 방안 기록 |
| 일반 버그 수정 | 조건부 허용 | UI 오탈자, 비핵심 연출 오류 | 변경 영향이 작고 테스트 가능할 때 |
| 밸런스 조정 | 원칙적 금지 | 피해량, 보상량, 난이도 변경 | 다음 인증 빌드로 분리 |
| 신규 콘텐츠 추가 | 금지 | 신규 퀘스트, 아이템, 대사 | 다음 빌드로 분리 |
| 대규모 리팩터링 | 금지 | 렌더링 구조, 저장 시스템 교체 | 인증 이후 별도 계획 |
| 마케팅·상품 구성 변경 | 금지 | 번들 구성, 가격, 에디션 변경 | 별도 승인 및 인증 영향 검토 |
허용 여부가 애매할 때는 다음 세 가지 질문을 순서대로 확인합니다.
- 이 변경을 하지 않으면 인증 실패 또는 출시 불가가 발생하는가?
- 변경된 코드와 에셋의 영향 범위를 검증할 수 있는가?
- 전체 회귀 테스트를 완료할 시간이 남아 있는가?
세 질문 중 하나라도 답하기 어렵다면 해당 수정은 다음 빌드로 미루는 편이 안전합니다.
예외 수정은 어떤 절차로 관리해야 하는가?
Freeze 이후의 예외 수정은 별도 승인 큐로 관리합니다. 메신저에서 구두로 합의하면 같은 변경이 다른 팀에 전달되지 않거나 제출된 빌드와 소스 브랜치의 상태가 달라질 수 있습니다.
1단계: 변경 요청 등록
모든 요청에는 Issue ID를 부여하고 다음 정보를 기록합니다.
- 문제 재현 절차와 발생 빈도
- 인증 요구사항 또는 출시 차단과의 관계
- 변경 대상 브랜치와 빌드 번호
- 코드·에셋·로컬라이제이션 영향 범위
- 필요한 테스트 범위
- 수정하지 않았을 때의 리스크
2단계: 변경 영향도 평가
PM은 QA, 클라이언트, 서버, 인증 담당자와 함께 변경을 분류합니다.
| 평가 항목 | 낮은 영향 | 높은 영향 |
|---|---|---|
| 변경 파일 수 | 단일 파일 | 여러 시스템 또는 공용 모듈 |
| 실행 경로 | 특정 메뉴 | 로그인·저장·결제·핵심 진행 |
| 플랫폼 의존성 | 공통 로직 | 플랫폼 SDK, 트로피, 네트워크 권한 |
| 회귀 테스트 | 단일 시나리오 | 전체 인증 체크리스트 |
| 제출 영향 | 기존 패키지 유지 | 새 패키징·서명 필요 |
높은 영향으로 평가된 요청은 문제가 심각하더라도 즉시 반영하지 말고 제출 일정과 재심사 가능성을 함께 비교해야 합니다.
3단계: 승인과 검증 증적 남기기
승인된 수정은 변경 전 빌드, 변경 후 빌드, 테스트 결과, 승인자, 적용 시간을 남깁니다. 인증 제출 패키지에는 최종 커밋 해시와 빌드 번호를 연결해 두어야 합니다.
예시 문서 형식은 다음과 같습니다.
| 필드 | 예시 |
|---|---|
| Issue ID | CERT-042 |
| 문제 | 특정 저장 데이터 로드 시 크래시 |
| 분류 | 인증 차단 결함 |
| 변경 범위 | SaveLoader.cs 및 회귀 테스트 4건 |
| 승인 | PM, QA Lead, 인증 담당자 |
| 최종 빌드 | RC-1.4.0-218 |
| 검증 결과 | 저장·로드·신규 게임 시나리오 통과 |
재심사 리스크는 어떻게 계산하고 관리하는가?
재심사 리스크는 수정 자체보다 수정이 인증 제출물의 다른 부분에 영향을 줄 가능성에서 커집니다. 다음처럼 단순한 점수표를 사용하면 논의를 빠르게 정리할 수 있습니다.
각 항목을 1점에서 5점으로 평가하고 점수가 높을수록 다음 원칙을 적용합니다.
- 1~20점: 제한된 회귀 테스트 후 반영 검토
- 21~50점: 인증 담당자와 PM의 공동 승인 필요
- 51점 이상: 제출 빌드에서 제외하고 다음 인증 사이클로 이동
이 점수는 공식 플랫폼 정책이 아니라 팀 내부 의사결정을 위한 관리 도구입니다. 실제 인증 실패 가능성은 플랫폼의 최신 요구사항과 빌드별 테스트 결과를 우선해야 합니다.
재심사를 유발하기 쉬운 변경
- 저장 데이터 구조와 마이그레이션 로직 변경
- 로그인, 계정 연동, 온라인 서비스 설정 변경
- 결제 상품, 가격, 권한, 지역별 노출 변경
- 트로피·업적 조건 변경
- 플랫폼 SDK 또는 권한 설정 변경
- 패키지 식별자, 버전, 서명, 매니페스트 변경
- 핵심 게임 진행과 튜토리얼 흐름 변경
이런 변경은 작은 코드 수정처럼 보여도 플랫폼 체크리스트의 여러 항목을 다시 검증해야 할 수 있습니다.
팀 운영에서 Content Freeze를 지키는 방법
Content Freeze는 개발팀만의 일정이 아니라 전체 릴리스 계약입니다. 다음 운영 규칙을 캘린더와 프로젝트 관리 도구에 함께 등록합니다.
- Freeze 기준 브랜치와 기준 빌드 번호를 공지한다.
- Freeze 이후 변경 요청은 하나의 승인 큐로 통합한다.
- 인증 제출 후보 빌드에는 커밋 해시와 패키지 해시를 기록한다.
- QA는 테스트 완료 항목과 미완료 항목을 분리해 보고한다.
- 매일 예외 요청 수, 미해결 인증 블로커, 남은 회귀 테스트 시간을 확인한다.
- 출시 전날에는 신규 변경을 받지 않고 이미 승인된 수정만 패키징한다.
특히 수정 가능과 수정해야 함을 구분해야 합니다. 수정이 가능하다는 이유만으로 반영하면 안정적인 인증 빌드가 변경 리스크가 큰 빌드로 바뀔 수 있습니다.
Content Freeze 역산 체크리스트
일정
- 인증 제출 목표일을 플랫폼별로 확정했는가?
- 패키징, 서명, 업로드 시간을 영업일 기준으로 계산했는가?
- 내부 검증과 회귀 테스트 시간을 별도로 확보했는가?
- 인증 실패 시 재제출 버퍼를 확보했는가?
스코프
- Freeze 이후 허용 수정과 금지 수정을 문서화했는가?
- 신규 콘텐츠와 밸런스 변경을 다음 빌드로 분리했는가?
- 플랫폼 SDK, 저장 데이터, 결제 변경을 별도 승인 대상으로 지정했는가?
협업과 문서화
- 기준 브랜치, 빌드 번호, 커밋 해시가 연결되어 있는가?
- 예외 수정마다 Issue ID와 승인자가 기록되어 있는가?
- 최종 인증 체크리스트의 미완료 항목이 공개되어 있는가?
- 출시 결정권자와 인증 실패 시 대응 책임자가 명확한가?
자주 묻는 질문 FAQ
Content Freeze 이후 버그를 하나도 수정하면 안 되나요?
아닙니다. 인증 실패, 크래시, 데이터 손상, 보안 문제처럼 출시를 막는 결함은 예외적으로 수정할 수 있습니다. 다만 영향도 평가와 회귀 테스트를 거쳐야 합니다.
인증 제출일과 Content Freeze 날짜의 차이는 며칠이 적당한가요?
고정된 정답은 없습니다. 패키징 시간, 테스트 범위, 팀의 수정 속도, 플랫폼별 재심사 가능성을 기준으로 계산해야 합니다. 최소한 내부 검증 시간과 재심사 대응 버퍼를 별도로 확보해야 합니다.
인증 중에 발견된 문제를 바로 다음 패치에 넣어도 되나요?
문제가 인증 실패나 출시 차단으로 이어지는지 먼저 판단해야 합니다. 필수 수정은 제출 빌드에 반영할 수 있지만 일반 개선은 인증 중인 빌드와 분리해 다음 패치 브랜치에서 관리하는 편이 안전합니다.
정리
콘솔 인증 제출 전 Content Freeze는 단순한 개발 중단일이 아니라 제출 빌드의 품질과 변경 범위를 통제하는 운영 기준입니다. 인증 제출 목표일에서 패키징, 내부 검증, 수정, 재심사 버퍼를 역산하고 Freeze 이후의 예외 수정은 영향도와 증적을 기준으로 승인해야 합니다.
최종 목표는 수정 요청을 완전히 없애는 것이 아니라 어떤 수정이 출시를 보호하고 어떤 수정이 재심사 리스크를 키우는지 팀 전체가 같은 기준으로 판단하게 만드는 것입니다.
