스크린샷 때문에 앱 심사가 거절되는 이유
앱 심사에서 반려되면 보통 기능이나 정책 위반을 먼저 떠올리지만, 실제로는 스크린샷 하나 때문에 전체 심사가 다시 처음부터 시작되는 경우도 적지 않습니다. 특히 인디 개발자나 1인 스튜디오는 마지막 순간에 급하게 스크린샷을 준비하다가 사소한 항목을 놓치는 경우가 많습니다. 이 글에서는 스크린샷 관련해서 자주 발생하는 거절 사유와 예방법을 정리합니다.
1. 규격 불일치
가장 흔한 사유입니다. iOS는 기기별로 요구하는 픽셀 해상도가 정확히 일치해야 하는데, 디자인 툴에서 캔버스를 반올림된 값으로 내보내면서 1px 단위로 어긋나는 경우가 자주 생깁니다. 구글 플레이는 상대적으로 유연하지만 최소 해상도 미달이나 알파 채널이 포함된 PNG를 그대로 올렸다가 업로드 단계에서 걸리기도 합니다.
예방법: 기기별 정확한 규격표를 기준으로 캔버스를 처음부터 맞춰 작업하고, 업로드 전에 실제 픽셀 값을 다시 한번 확인합니다.
2. 실제 앱과 다른 화면
스크린샷에 나온 화면이 실제 배포 버전의 UI와 다르면 반려 사유가 됩니다. 개발 중인 임시 화면, 아직 출시되지 않은 기능, 혹은 디자인 시안 단계의 목업 이미지를 그대로 스크린샷으로 올리는 경우가 여기에 해당합니다. 심사자는 실제로 앱을 설치해서 스크린샷과 비교하기 때문에, 화면이 조금이라도 다르면 사용자를 오도하는 자료로 판단될 수 있습니다.
예방법: 반드시 심사 제출 직전 빌드에서 직접 캡처한 화면만 사용합니다.
3. 타 플랫폼 UI 노출
iOS용 스크린샷에 Android 상태 표시줄이나 다른 기종의 알림 아이콘, 뒤로가기 버튼 같은 요소가 그대로 남아 있는 경우입니다. 여러 플랫폼을 동시에 개발하다 보면 캡처 화면을 헷갈려서 실수로 잘못된 스크린샷을 올리는 일이 생각보다 자주 발생합니다.
예방법: 플랫폼별로 캡처 파일을 명확히 분리해서 관리하고, 업로드 직전에 상태 표시줄이나 시스템 UI가 해당 플랫폼과 일치하는지 확인합니다.
4. 플레이스홀더 텍스트
"Lorem ipsum" 같은 더미 텍스트나 "샘플 텍스트입니다" 같은 미완성 문구가 스크린샷에 그대로 노출되는 경우입니다. 개발 단계에서 임시로 넣어둔 텍스트를 캡처 후 미처 지우지 않고 그대로 사용하는 실수에서 비롯됩니다.
예방법: 캡처 전에 모든 텍스트 필드에 실제 사용 가능한 예시 데이터를 채워 넣습니다.
5. 그 외 자주 걸리는 사유
| 사유 | 설명 |
|---|---|
| 과도한 마케팅 문구 | 실제 기능과 무관한 과장된 카피나 확인되지 않은 수치 표기 |
| 저작권 미확인 소재 | 라이선스가 없는 폰트, 이미지, 캐릭터를 스크린샷 장식에 사용 |
| 이미지 개수 미달 | 플랫폼별 최소 등록 장수를 채우지 못한 경우 |
| 다른 앱 화면 혼입 | 여러 프로젝트 작업 중 잘못된 캡처 파일 업로드 |
6. Google Play 피처 그래픽·아이콘 금지 문구
피처 그래픽(1024×500)과 앱 아이콘은 다른 스크린샷보다 심사 기준이 더 엄격합니다. 다음 요소가 포함되면 반려 사유가 됩니다.
| 금지 유형 | 예시 |
|---|---|
| 순위·수상 문구 | "1위 앱", "OO 어워드 수상", "베스트 앱 선정" 등 검증되지 않은 순위·수상 주장 |
| 프로모션·가격 문구 | "50% 할인", "무료 체험", "지금 다운로드" 같은 판촉성 텍스트나 가격 표기 |
| CTA(행동 유도) 문구 | "지금 클릭", "설치하기" 등 사용자 행동을 직접 지시하는 버튼 형태의 텍스트 |
| 이모지·과도한 장식 | 아이콘·피처 그래픽에 이모지, 별점 흉내, 배지 형태의 장식 요소 |
피처 그래픽과 아이콘은 스토어 UI 위에 얹히는 자리라, 실제 UI 요소(별점, 배지, 버튼)를 흉내 낸 장식도 "가짜 UI"로 간주되어 반려될 수 있습니다.
7. Steam 캡슐 규칙
Steam 헤더·메인·스몰 캡슐 등 캡슐 이미지는 Steamworks 정책상 아트워크와 게임명 정도로 구성이 제한됩니다.
- 리뷰 점수, 평점, "압도적으로 긍정적" 같은 스팀 리뷰 문구를 캡슐 이미지에 직접 넣는 것은 금지됩니다.
- "출시 기념", "할인", "수상" 같은 프로모션·수상 문구도 캡슐에는 넣을 수 없습니다.
- 캡슐은 어디까지나 아트워크 중심으로 구성하고, 프로모션 정보는 스토어 페이지 본문이나 별도 공지로 전달하는 것이 원칙입니다.
과장 없이 원칙만 정리하면, 두 플랫폼 모두 "성과를 주장하는 텍스트"와 "실제 UI를 흉내 낸 장식"을 피하고 아트워크·제품명 중심으로 구성하는 것이 가장 안전합니다.
반려 후 재제출 시 유의점
스크린샷 문제로 반려되면 단순히 이미지만 교체해서 재제출하면 되는 경우가 대부분이지만, 심사 큐에 다시 들어가면서 대기 시간이 그대로 추가됩니다. 출시 일정이 정해져 있다면 이 왕복 시간이 생각보다 크게 작용하기 때문에, 처음 제출 전에 규격과 화면 내용을 한 번 더 점검하는 편이 결과적으로 시간을 아끼는 방법입니다.
규격을 손으로 맞추다 보면 실수가 나오기 쉬운데, StoreShot에서는 기기별 정확한 규격에 맞춰 스크린샷을 만들고 iOS·Android 전 규격을 한 번에 출력할 수 있어 이런 종류의 실수를 줄이는 데 도움이 됩니다.
정리
스크린샷 관련 반려 사유는 대부분 화려한 디자인 문제가 아니라 규격, 실제 화면과의 일치 여부, 플랫폼 UI 혼입, 플레이스홀더 텍스트처럼 기본적인 점검만으로 막을 수 있는 것들입니다. 제출 직전 빌드에서 캡처한 화면인지, 정확한 픽셀 규격을 지켰는지, 텍스트가 모두 실제 내용인지 세 가지만 확인해도 스크린샷 관련 반려는 대부분 예방됩니다.