Cocos Creator 미니게임 출시 전 체크리스트: 성능, 패키지 용량, 적응, 심사까지

처음 심사를 제출하던 날, 저는 “심사 반려” 팝업을 보고 머리가 멍해졌습니다. 패키지 용량 초과. 메인 패키지가 6.8MB였고, WeChat의 하드 제한은 4MB였습니다. 텍스처 압축부터 오디오 트랜스코딩, 엔진 모듈 가지치기까지 3일을 고쳐서야 패키지 용량을 3.2MB로 줄이고 심사를 통과했습니다.

그 경험 덕분에 출시 전 점검에는 사실 따라갈 수 있는 흔적이 있다는 걸 깨달았습니다. 운에 맡기는 일이 아니라, 구체적인 수치 기준과 명확한 확인 방법이 있는 일이었습니다. 이후 제가 밟았던 함정을 체크리스트로 정리했고, 제출 전마다 하나씩 확인했습니다. 지금은 이 체크리스트도 십수 번 업데이트되어 성능, 패키지 용량, 화면 적응, 심사 4개 모듈 15개 항목을 포함하게 되었습니다.

이 글에서는 제가 실제로 사용해 온 체크리스트를 공유합니다. 각 항목마다 구체적인 수치 기준을 제시하고, 어떤 도구로 확인할지, 가장 흔한 함정이 어디에 있는지 설명합니다. 다 읽고 나면 이 체크리스트를 들고 항목별로 자체 점검할 수 있고, 한 번에 심사를 통과할 확률을 크게 높일 수 있습니다.

1. 성능 점검: 끊김 때문에 경험을 망치지 않기

성능 문제는 플레이어 이탈의 주요 원인 중 하나입니다. 내 휴대폰에서는 게임이 아주 부드럽게 돈다고 느낄 수 있지만, 잊지 말아야 합니다. 당신의 테스트 기기는 대개 최신 모델이고, 실제 사용자는 3년 전 구형 휴대폰을 쓰고 있을 수 있습니다. iOS 고급 기기와 저사양 기기의 성능 차이는 3-4배까지 벌어질 수 있습니다. 농담이 아닙니다.

1. FPS 안정성 점검

점검 기준: 고급 기기(iPhone X 이상)는 60 FPS, 저사양 기기(iPhone 6s/7/8)는 30 FPS를 목표로 합니다. 피크가 목표값의 80% 아래로 내려가면 안 됩니다. 즉 고급 기기는 최저 48 FPS, 저사양 기기는 최저 24 FPS가 기준입니다.

확인 방법: Cocos Creator 내장 FPS 표시를 cc.macro에서 켭니다.

// 개발 단계에서 FPS 표시
cc.macro.SHOW_FPS = true;

또는 Stats.js를 쓰면 더 직관적입니다. WeChat 개발자 도구의 “성능 패널”에서도 실시간 FPS 곡선을 볼 수 있습니다.

정량 지표:

• 고급 기기에서 55-60 FPS 안정 유지
• 저사양 기기에서 28-32 FPS 안정 유지
• 피크 변동 폭 20% 이하

흔한 문제: DrawCall이 너무 많거나, 복잡한 장면 전환에서 끊기거나, 많은 파티클이 동시에 발생하는 경우입니다. 예전에 한 프로젝트에서 Boss가 사망할 때 파티클 200개를 터뜨렸더니 저사양 기기에서 곧바로 15 FPS까지 떨어졌습니다. 이후 파티클을 50개로 줄이고 easing 애니메이션을 더했더니 오히려 효과가 더 좋아졌습니다.

자체 테스트 팁: iPhone 7 한 대를 찾아 실제 기기에서 10분 동안 실행해 보세요. FPS 선이 계속 30 전후에서 흔들리는 정도라면 괜찮지만, 자주 20 아래로 떨어진다면 원인을 찾아야 합니다.

2. 메모리 피크 점검

점검 기준: iOS에는 메모리 하드 제한이 있습니다. 저사양 기기(iPhone 6s/7/8)는 상한이 1GB, 고급 기기(iPhone X/XR/11)는 상한이 1.4GB입니다. 피크는 기기 제한의 70%를 넘지 않는 것이 좋습니다. 즉 저사양 기기는 700MB 이하, 고급 기기는 1GB 이하로 관리합니다.

확인 방법:

• WeChat 개발자 도구: “디버거-Memory” 패널을 열면 메모리 곡선을 볼 수 있습니다.
• Safari 원격 디버깅: 실제 기기를 Mac에 연결한 뒤 Safari 개발자 메뉴에서 해당 기기를 선택합니다.

// 메모리 사용량을 주기적으로 출력
const memoryInfo = cc.sys.getMemoryInfo();
console.log('현재 메모리: ' + memoryInfo.used + 'MB');

정량 지표:

• 저사양 기기 피크 ≤700MB
• 고급 기기 피크 ≤1000MB
• 크래시율 2% 이내로 관리(어떤 프로젝트는 최적화 후 15%에서 2%로 낮아졌습니다)

흔한 문제: 같은 리소스를 두 번 로드하는 이중 텍스처 문제, 리소스를 제때 해제하지 않는 문제, 큰 아틀라스를 나누지 않는 문제입니다. Cocos 공식 문서에서도 아틀라스는 가능하면 1024x1024 이내로 관리하라고 설명합니다. 너무 큰 아틀라스는 저사양 기기에서 메모리를 터뜨리기 쉽습니다.

자체 테스트 팁: 저사양 기기에서 같은 장면에 20회 반복해서 들어갔다 나오세요. 메모리 곡선이 계속 올라가고 내려오지 않는다면 리소스 누수가 있다는 뜻입니다.

3. DrawCall 수 점검

점검 기준: DrawCall은 렌더링 성능에 직접 영향을 줍니다. 같은 프레임 안에서 DrawCall이 많을수록 GPU 부담이 커집니다. 첫 화면(게임 진입 후 첫 화면)은 100 이하, 게임 진행 중에는 200 이하로 관리합니다.

확인 방법: Cocos Creator의 “빌드 및 배포” 패널에는 렌더링 통계 옵션이 있습니다. 체크하면 런타임에 DrawCall 수를 볼 수 있습니다.

// 현재 DrawCall 수 확인
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

정량 지표:

• 첫 화면 ≤100
• 게임 중 ≤200
• 피크는 350 이하(극단적인 장면에서는 조금 완화 가능)

흔한 문제: 아틀라스 병합을 하지 않았거나, 동적 아틀라스가 켜져 있지 않거나, BMFont를 너무 많이 쓰는 경우입니다. 한 프로젝트에서는 최적화 전 DrawCall이 350까지 올라갔는데, 흩어진 작은 이미지를 큰 아틀라스로 묶고 BMFont를 TTF로 바꾸자 120까지 바로 낮아졌습니다.

최적화 팁:

• 정적 아틀라스: TexturePacker로 패킹해 조각 이미지를 줄입니다.
• 동적 아틀라스: Cocos Creator는 기본으로 켜져 있지만, 텍스처 크기가 2048보다 작은지 확인해야 합니다.
• BMFont: TTF를 쓸 수 있으면 TTF를 쓰세요. BMFont는 char마다 DrawCall 하나가 생깁니다.

4. 첫 화면 로딩 시간 점검

점검 기준: 첫 화면 로딩이 3초를 넘으면 사용자 이탈률이 7% 올라갑니다. 제가 꾸며낸 말이 아니라 업계 데이터입니다. WeChat 클라우드 테스트 플랫폼 데이터에 따르면 3.5MB 패키지 게임의 첫 화면 소요 시간은 4500-9000ms이고, 이 구간에서는 이탈률이 눈에 띄게 상승합니다.

확인 방법:

• WeChat 개발자 도구: “상세-로컬 코드”에서 패키지 크기를 확인할 수 있습니다.
• WeChat 클라우드 테스트 플랫폼: 실제 기기 네트워크 환경을 시뮬레이션해 실제 첫 화면 소요 시간을 얻습니다.

// 첫 화면 로딩 시간 기록
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('첫 화면 소요 시간: ' + loadTime + 'ms');
});

정량 지표:

• 첫 화면 렌더링 ≤3000ms(이상적 기준 ≤1500ms)
• 진행률 표시 비율 ≥80%(사용자는 진행률 표시줄을 보면 더 오래 기다립니다)

흔한 문제: 첫 장면에 리소스를 너무 많이 넣거나, 초기 장면을 서브패키지로 나누지 않거나, resources 디렉터리 리소스가 전부 로드되는 경우입니다. 당시 저는 첫 장면에 캐릭터 3개, 배경 2개, UI 묶음을 넣었고 결과적으로 첫 화면 로딩이 5초였습니다. 이후 loading 이미지 1장과 서브패키지 로딩 구조로 바꾸어 2초까지 줄였습니다.

최적화 팁:

• 첫 장면에는 배경 이미지 1장과 진행률 표시줄만 둡니다.
• 초기 장면은 서브패키지 옵션을 켭니다.
• 꼭 필요하지 않은 리소스는 원격 로딩으로 옮깁니다.

2. 패키지 용량 점검: 4MB라는 문턱은 반드시 넘어야 합니다

WeChat 미니게임의 메인 패키지 하드 제한은 4MB이고, 전체 패키지(서브패키지 포함)는 16MB를 넘을 수 없습니다. 이건 레드라인입니다. 넘으면 바로 반려되고 협상의 여지는 없습니다. 저도 바로 이 함정을 밟았습니다. 메인 패키지가 6.8MB였고, 반려된 뒤 3일을 고쳐서야 3.2MB까지 줄였습니다.

5. 메인 패키지 크기 점검

점검 기준: 메인 패키지 ≤3.8MB. 왜 200KB 여유를 남길까요? 빌드할 때 동적으로 생성되는 파일이 있을 수 있고, WeChat의 측정 방식에도 가끔 미세한 차이가 있기 때문입니다. 숨 쉴 공간을 조금 남겨 두는 편이 좋습니다.

확인 방법: 빌드가 끝난 뒤 WeChat 개발자 도구에서 “상세-로컬 코드”를 클릭하면 정확한 패키지 크기 통계를 볼 수 있습니다.

정량 지표:

• 메인 패키지 ≤3.8MB(안전선)
• 메인 패키지 ≤4.0MB(레드라인, 반드시 줄여야 함)

흔한 문제:

• resources 디렉터리에 리소스를 너무 많이 둠: 이 디렉터리의 파일은 전부 메인 패키지에 들어갑니다.
• 엔진 모듈을 가지치기하지 않음: Cocos는 기본적으로 모든 모듈을 패키징하지만, 실제로는 몇 개만 필요할 수 있습니다.
• 의존성 라이브러리가 너무 큼: npm 패키지를 추가하고 크기를 확인하지 않은 경우입니다.

자체 테스트 팁: 빌드 전에 먼저 resources 디렉터리를 확인해 꼭 필요하지 않은 리소스를 다른 디렉터리로 옮기세요. 그다음 Cocos의 “프로젝트 설정-모듈 설정”에서 쓰지 않는 모듈을 체크 해제합니다.

// 모듈 가지치기 설정 예시(project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // 필요 없는 모듈은 선택하지 않습니다. 예:
  // "physics" - 물리 엔진이 필요 없음
  // "tween" - tween 시스템이 필요 없음
}

6. 전체 패키지 크기 점검

점검 기준: 전체 패키지(메인 패키지 + 서브패키지)는 16MB를 넘지 않아야 합니다. 서브패키지는 원격으로 로드할 수 있지만 다운로드 속도는 네트워크의 영향을 받습니다. 그래서 핵심 콘텐츠는 여전히 메인 패키지와 첫 화면 서브패키지에 넣는 편이 좋습니다.

확인 방법: 빌드 출력 로그에 각 서브패키지의 크기가 표시됩니다. 모두 더하면 전체 패키지 크기입니다.

정량 지표:

• 전체 패키지 ≤15MB(안전선)
• 전체 패키지 ≤16MB(레드라인)

서브패키지 전략 제안:

• 핵심 패키지(메인 패키지 + 첫 화면 서브패키지) <10MB
• 기능 패키지(보조 플레이) 20-50MB
• 장면 패키지(원격 로딩) 30-100MB

흔한 문제: 서브패키지 구분이 합리적이지 않거나, 첫 화면 서브패키지가 너무 크거나, 사용자가 다운로드를 너무 오래 기다리는 경우입니다. 한 프로젝트에서는 모든 캐릭터 모델을 첫 화면 서브패키지에 넣었고, 사용자가 게임에 들어가기까지 8초를 기다려야 했습니다.

7. 리소스 압축률 점검

점검 기준: 텍스처, 오디오, 폰트는 패키지 용량의 3대 핵심 리소스입니다. 실측 데이터로 보면 텍스처가 45%, 오디오가 25%, 폰트가 15%를 차지합니다. 이 세 가지를 제대로 압축하면 패키지 크기를 절반까지 줄일 수 있습니다.

확인 방법: 원본 파일 크기와 빌드 후 크기를 비교합니다.

정량 지표:

• PNG → JPG(투명 채널이 없는 이미지): 50-70% 감소
• WAV → OGG: 65-70% 감소
• 폰트 서브셋 추출(fontmin): 80-90% 감소

추천 도구:

• TinyPNG: PNG 압축 도구입니다. 웹 버전에서 드래그하면 됩니다.
• TexturePacker: 아틀라스 패킹과 압축을 한 번에 처리합니다.
• Audacity: 오디오 트랜스코딩 도구입니다. WAV를 OGG로 바꾸기 쉽습니다.
• fontmin: 폰트 서브셋을 추출해 게임에서 쓰는 문자만 남깁니다.

흔한 문제:

• 배경 이미지를 PNG로 사용: 사실 투명 채널이 없다면 JPG면 충분합니다.
• 오디오를 WAV로 사용: 용량이 몇 배 커지므로 OGG로 바꿉니다.
• 폰트 추출을 하지 않음: 전체 폰트 파일은 10MB가 넘을 수 있지만, 필요한 글자만 추출하면 100KB 정도일 수 있습니다.

자체 테스트 팁: TinyPNG로 PNG 한 장을 압축하고 전후 크기를 비교해 보세요. 놀랄 수 있습니다. 500KB 배경 이미지가 압축 후 150KB밖에 안 될 수도 있습니다.

8. 서브패키지 설정 점검

점검 기준: 서브패키지 로딩 전략은 합리적이어야 하며, 시작 경험을 해치면 안 됩니다. 첫 장면은 반드시 서브패키지를 선택하고, 꼭 필요하지 않은 리소스는 메인 패키지에 두지 않습니다.

확인 방법: 서브패키지 로딩 순서와 첫 장면 의존 관계를 확인합니다.

정량 지표:

• 첫 장면 서브패키지 선택: 예
• 첫 장면 로딩 시간: ≤3000ms
• 불필요한 리소스가 메인 패키지에 없음: resources 디렉터리 확인

흔한 문제:

• 첫 장면이 메인 패키지 밖 리소스를 참조함: 서브패키지를 먼저 다운로드해야 장면에 들어갈 수 있습니다.
• 서브패키지를 비즈니스 로직 기준으로 나누지 않음: 사용자가 특정 플레이에 들어간 뒤에야 서브패키지가 아직 다운로드되지 않았다는 걸 알게 됩니다.
• 서브패키지 로딩 시점이 맞지 않음: loading 화면에서 후속 서브패키지 다운로드를 시작해야 합니다.

// 서브패키지 로딩 예시
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('서브패키지 로딩 실패', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

자체 테스트 팁: 4G 네트워크 환경에서 서브패키지 로딩 속도를 테스트하세요. 첫 화면 서브패키지 다운로드가 5초를 넘는다면 서브패키지 전략이 합리적인지 다시 봐야 합니다.

3. 화면 적응 점검: 특정 기기에서 무너지지 않기

화면 적응 문제는 가장 쉽게 놓치는 부분입니다. 내 테스트 기기에서는 잘 돌아갈 수 있지만, 출시 후에는 UI가 가려졌다거나, 검은 여백이 보기 싫다거나, 가로 화면 전환 때 위치가 틀어진다는 사용자 불만이 쏟아질 수 있습니다. 기기 적응은 시스템적인 문제라서 한 대만 테스트해서는 안 됩니다.

9. 화면 적응 점검

점검 기준: 디자인 해상도, 적응 전략, 검은 여백 처리입니다. 세로 게임은 디자인 해상도 720x1280(9:16) 또는 750x1334를 추천하고, 가로 게임은 반대로 설정합니다.

확인 방법: 최소 3가지 화면 비율의 실제 기기 테스트를 포함합니다.

• 16:9(전통 비율, 대부분의 Android 기기)
• 18:9(현대 비율, Xiaomi와 Huawei 신형 기기)
• 19.5:9(iPhone X 시리즈, 노치 화면)

정량 지표:

• 디자인 해상도: 720x1280 또는 750x1334
• 적응 전략: 세로 화면은 높이 기준, 가로 화면은 너비 기준
• 검은 여백: 없음, 또는 균등하게 분포

핵심 코드:

// 세로 화면에서 높이 기준 적응
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// 가로 화면에서 너비 기준 적응
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// 실제 가시 영역 가져오기
const visibleSize = cc.view.getVisibleSize();
console.log('가시 영역: ' + visibleSize.width + 'x' + visibleSize.height);

흔한 문제:

• 적응 전략을 잘못 선택함: 세로 화면에서 너비 기준을 골라 위아래 검은 여백이 생깁니다.
• Widget 컴포넌트를 제대로 쓰지 않음: 노드가 화면 가장자리를 자동으로 따라가지 않습니다.
• 디자인 해상도가 너무 넓음: 일부 기기에서 전체가 표시되지 않습니다.

자체 테스트 팁: Widget 컴포넌트로 핵심 UI를 화면 가장자리에 고정하세요. 예를 들어 오른쪽 위의 코인 숫자는 Widget으로 우상단에 고정하면 어떤 화면 비율에서도 위치가 틀어지지 않습니다.

10. 노치 화면/물방울 화면 점검

점검 기준: 안전 영역을 처리하고, 핵심 UI가 가려지지 않도록 합니다. iPhone X 시리즈의 노치, Android의 물방울 화면과 펀치홀 화면은 모두 화면 상단 영역을 차지합니다.

확인 방법: iPhone X/XR/11 시리즈 실제 기기와 Android 노치 화면 기기(Huawei Mate 시리즈, Xiaomi 고급 기기)에서 테스트합니다.

정량 지표:

• 핵심 UI와 상단 간격 ≥50px
• 핵심 UI와 하단 간격 ≥50px(가상 Home 키 영역)
• 안전 영역 감지: SafeArea API 사용

적응 팁:

// iOS SafeArea 가져오기
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// 노드 위치 적응
this.topNode.y = -topPadding;  // 아래로 이동
this.bottomNode.y = bottomPadding;  // 위로 이동

또는 Widget 컴포넌트에서 가장자리 간격을 직접 설정하되, 동적으로 가져온 안전 영역 값을 사용하면 됩니다.

흔한 문제:

• 제목이 노치에 가려짐: 사용자가 게임 이름을 볼 수 없습니다.
• 하단 버튼이 가상 Home 키에 가려짐: 터치 영역이 겹칩니다.
• Android 펀치홀 화면을 테스트하지 않음: 브랜드마다 펀치홀 위치가 다릅니다.

자체 테스트 팁: WeChat 개발자 도구 시뮬레이터에서 “iPhone X” 기기를 선택해 UI가 노치에 가려지는지 보세요. 그다음 Android 노치 화면 실제 기기를 찾아 한 번 더 테스트합니다.

11. 기기 호환성 점검

점검 기준: 주류 기기를 포함하고 저사양 기기의 성능이 기준을 충족해야 합니다. 클라우드 테스트 플랫폼은 여러 기기 테스트를 한 번에 도와주므로 직접 휴대폰을 잔뜩 살 필요가 없습니다.

확인 방법:

• WeChat 클라우드 테스트 플랫폼: 무료이며 WeChat 미니게임의 주류 기기를 포함합니다.
• Testin 클라우드 테스트: 유료이며 더 넓은 기기 범위를 제공합니다.

권장 포함 기기:

• iPhone 6s/7/8: 저사양 기준 기기, 성능 하한 테스트
• iPhone X/XR/11: 중고급 기기, 노치 화면 적응 테스트
• Huawei/Xiaomi/OPPO/vivo 주류 Android 기기: 기기 호환성 테스트

정량 지표:

• 저사양 기기 FPS ≥30
• 저사양 기기 메모리 ≤기기 제한의 70%
• 크래시율 ≤2%
• 설치 성공률 ≥99%

흔한 문제:

• iPhone만 테스트함: Android 기기 차이가 크고, 저사양 Android는 iPhone 6s보다 약할 수도 있습니다.
• 구형 기기를 무시함: 2024년에도 iPhone 7 사용자는 있습니다.
• WebGL 지원을 테스트하지 않음: 일부 기기는 WebGL 버전이 낮아 특정 효과가 표시되지 않습니다.

자체 테스트 팁: 3가지 기기를 중점적으로 테스트하세요. 개발 기기(고급), iPhone 7(iOS 저사양), 2019년형 Android 중급 기기 하나입니다. 이 세 가지면 대부분의 상황을 포괄할 수 있습니다.

12. 가로/세로 화면 전환 점검

점검 기준: 가로/세로 화면 적응 방식과 전환 부드러움입니다. 일부 게임은 가로/세로 전환을 지원합니다. 예를 들어 특정 퍼즐 게임처럼 전환이 필요한 경우, UI가 자동으로 재배치되어야 합니다.

확인 방법: 실제 기기 회전 테스트, 강제 가로/세로 장면 테스트를 진행합니다.

정량 지표:

• 전환 소요 시간 ≤500ms
• UI 재배치에 위치 어긋남 없음
• 전환 후 장면이 정상 렌더링됨

흔한 문제:

• 전환 시 노드 위치가 흐트러짐: Widget이 업데이트되지 않았습니다.
• 전환 후 검은 화면: 장면 재로딩에 실패했습니다.
• 전환 시 끊김: 장면이 너무 커서 다시 렌더링하는 데 오래 걸립니다.

// 화면 회전 감지
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// UI 재배치 로직
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // 가로 화면 레이아웃
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // 세로 화면 레이아웃
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

자체 테스트 팁: 게임이 세로 화면 또는 가로 화면만 지원한다면 프로젝트 설정에서 방향을 강제로 잠그세요. 사용자가 휴대폰을 돌렸을 때 화면이 틀어지는 일을 피할 수 있습니다.

4. 심사 점검: 자격, 개인정보, 콘텐츠라는 세 관문

심사 단계는 개발자에게 가장 골치 아픈 부분입니다. 기술 문제는 직접 테스트할 수 있지만, 심사 규정은 사전에 정확히 알기 어렵습니다. WeChat의 심사 규정은 자세히 쓰여 있지만, 실제 집행에는 주의해야 할 디테일이 많습니다. 2026년부터 WeChat은 AI 보조 심사를 도입했고, 업데이트 버전은 2-4시간이면 완료될 수 있습니다. 하지만 첫 버전 심사는 여전히 1-2영업일이 필요합니다.

13. 자격 요건 완비 점검

점검 기준: 소프트웨어 저작권, ICP 등록, 판호(인앱 구매 필수)입니다. 이 세 항목은 하드 요구사항이고, 하나라도 빠지면 바로 반려됩니다.

확인 방법: 공식 자격 목록과 하나씩 대조해 명칭과 주체가 완전히 일치하는지 확인합니다.

정량 지표:

• 소프트웨어 저작권: 주체와 명칭이 계정과 완전히 일치(글자 하나도 틀리면 안 됨)
• ICP 등록: 심사 통과(7-20영업일)
• 판호: 인앱 구매 게임은 필수, 순수 광고 수익화는 면제 가능

흔한 문제:

• 소프트웨어 저작권 명칭에 글자 하나가 더 있음: 예를 들어 소프트웨어 저작권은 “比邻消消乐”인데 게임 이름은 “比邻消消乐小游戏”이면 바로 반려됩니다.
• ICP 등록 통과를 기다리지 않고 제출함: 심사 주기는 7-20일이므로 미리 제출하면 거절됩니다.
• 판호 주체 불일치: 판호는 A 회사 명의인데 게임 계정은 B 회사 명의이면 통과하지 못합니다.

자체 테스트 팁: 소프트웨어 저작권 증서, ICP 등록 스크린샷, 판호(있는 경우)를 한곳에 놓고 명칭과 주체를 글자 단위로 대조하세요. 글자 하나가 더 있거나 빠져도 안 됩니다. 이 부분은 정말 꼼꼼해야 합니다.

14. 개인정보 처리방침과 미성년자 보호 점검

점검 기준: 개인정보 처리방침 진입점, 실명 인증, 중독 방지 시스템입니다. 이 세 항목은 미성년자 보호의 강제 요구사항이며, 2026년 심사에서 중점적으로 확인됩니다.

확인 방법: 미성년자 사용자 로그인 과정을 시뮬레이션해 중독 방지 로직이 실제로 동작하는지 확인합니다.

정량 지표:

• 개인정보 처리방침: 홈 화면의 눈에 잘 띄는 위치에 진입점이 있음(팝업 또는 버튼)
• 중독 방지: 미성년자는 하루 ≤1시간, 22:00-8:00 플레이 금지
• 적정 연령 안내: 홈 화면에 건강한 게임 이용 안내 표시

흔한 문제:

• 개인정보 처리방침 팝업 동의 누락: 사용자가 게임에 들어가자마자 플레이할 수 있고 개인정보 처리방침이 뜨지 않습니다.
• 중독 방지 로직 누락: 실명 인증 진입점이 없거나, 인증 후에도 중독 방지 제한을 실행하지 않습니다.
• 건강한 게임 이용 안내가 표시되지 않음: 심사 때 보완 요구를 받을 수 있습니다.

자체 테스트 팁: 미성년자 신분증 번호(18세 미만)로 로그인 과정을 테스트하세요. 중독 방지 제한이 트리거되는지, 22:00 이후 로그인 시 플레이 금지 안내가 나오는지 확인합니다.

15. 콘텐츠 준수 점검

점검 기준: 명칭 규정, 광고 규정, 콘텐츠 레드라인입니다. 명칭은 자격 서류와 일치해야 하고, 광고는 핵심 기능을 가리면 안 되며, 콘텐츠는 레드라인을 건드리면 안 됩니다.

확인 방법: 심사 규정을 기준으로 자체 점검하고 명칭, 광고, 콘텐츠 요소를 하나씩 확인합니다.

정량 지표:

• 명칭: 영어/브랜드 단어를 포함하지 않으며 자격 서류와 일치
• 광고 비율: ≤50%, 핵심 기능을 가리지 않음
• 콘텐츠: 폭력, 선정성, 도박, 정치적으로 민감한 요소 없음

흔한 문제:

• 명칭에 “软件” 같은 표현 포함: 예를 들어 “XX软件小游戏”이면 반려될 수 있습니다.
• 광고가 핵심 버튼을 가림: 사용자가 “게임 시작”을 누르려다가 광고를 누르게 됩니다.
• 공유 유도: “친구에게 공유하면 스테이지 해금” 같은 문구는 심사에서 바로 반려됩니다.
• 명칭에 영어 포함: 예를 들어 “CocosGame”은 중국어 명칭으로 바꿔야 합니다.

자주 반려되는 원인 TOP 5:

1. 패키지 용량 초과(메인 패키지 >4MB)
2. 명칭과 소프트웨어 저작권 불일치
3. 개인정보 처리방침 팝업 동의 누락
4. 공유/팔로우 유도
5. 광고가 핵심 기능을 가림

자체 테스트 팁: 이 TOP 5 목록을 기준으로 하나씩 자체 점검하세요. 이 5가지가 반려 사례의 80%를 차지하므로, 여기만 피해도 기본적으로 한 번에 통과할 가능성이 커집니다.

빠른 자체 점검표: 출시 전 15개 체크리스트

아래 체크리스트는 바로 출력해서 심사 제출 전 하나씩 체크할 수 있습니다.

모듈	점검 항목	기준	충족 여부
성능	FPS 안정성	고급≥55, 저사양≥28	□
성능	메모리 피크	저사양≤700MB, 고급≤1000MB	□
성능	DrawCall 수	첫 화면≤100, 게임≤200	□
성능	첫 화면 로딩 시간	≤3000ms	□
패키지	메인 패키지 크기	≤3.8MB	□
패키지	전체 패키지 크기	≤15MB	□
패키지	리소스 압축률	PNG 50%+ 감소, 오디오 65%+	□
패키지	서브패키지 설정	첫 장면 서브패키지 선택	□
적응	화면 적응	검은 여백 없음, 가림 없음	□
적응	노치 화면 처리	UI와 가장자리 간격≥50px	□
적응	기기 호환	저사양 기기 FPS≥28	□
적응	가로/세로 전환	≤500ms, 위치 어긋남 없음(지원하는 경우)	□
심사	자격 요건 완비	소프트웨어 저작권+ICP 등록+판호(인앱 구매)	□
심사	개인정보와 중독 방지	약관 진입점+중독 방지 로직	□
심사	콘텐츠 준수	명칭/광고/콘텐츠 규정	□

각 항목을 충족한 뒤 체크하고, 15개 항목을 모두 체크한 다음 심사에 제출하세요. 요행을 바라지 마세요. 어느 한 항목이라도 기준에 미달하면 반려될 수 있고, 다시 고치는 데 시간이 낭비됩니다.

정리

출시 전 점검은 있어도 되고 없어도 되는 절차가 아니라, 심사 통과율에 직접 영향을 주는 핵심 단계입니다. 성능 문제는 사용자 이탈을 만들고, 패키지 용량 초과는 바로 반려되며, 화면 적응 문제는 사용자 불만으로 이어지고, 심사 규정 미준수는 일주일의 수정 시간을 낭비하게 만듭니다.

이 체크리스트의 핵심 가치는 분명합니다. 각 항목마다 구체적인 수치 기준이 있어 추측하지 않아도 되고, 각 항목마다 확인 방법이 있어 감으로 처리하지 않아도 되며, 각 항목마다 흔한 문제가 있어 다른 사람이 밟았던 함정을 피할 수 있습니다.

이 체크리스트를 출력해서 모니터 옆에 붙여 두는 것을 추천합니다. 심사 제출 전마다 하나씩 체크하세요. 번거롭게 느껴질 수 있지만, 반려된 뒤 3일 동안 고치는 것에 비하면 이 정도 시간 투자는 충분히 가치가 있습니다.

마지막으로 한마디 덧붙이자면, 첫 출시가 긴장되는 건 정상입니다. 하지만 이 체크리스트가 있으면 체계적으로 점검하고 확신을 가지고 제출할 수 있습니다. 당신의 미니게임이 한 번에 심사를 통과해 순조롭게 출시되길 바랍니다.