개념
심사는 기능 테스트가 아니라 계약 검사다
QA가 통과시킨 앱이 스토어에서 반려되면 팀은 당황한다. "우리가 뭘 놓쳤지?"라는 질문이 나오지만, 사실 놓친 것은 결함이 아니라 계약 조항 인 경우가 대부분이다. 스토어는 우리 앱이 잘 만들어졌는지를 보는 곳이 아니라, 자기 플랫폼의 규칙을 지켰는지를 보는 곳이다.
이 차이를 받아들이면 대응 방식이 달라진다. 심사 대응은 탐색적 테스트가 아니라 문서 대조 작업 이다. 정본 문서가 세 벌 있고, 우리 앱의 어떤 속성이 그 문서의 어느 조항에 걸리는지 매핑하면 된다.
| 스토어 | 정본 문서 | 특징 |
|---|---|---|
| App Store | App Store Review Guidelines | 사람이 직접 심사. 조항이 서술형이라 해석 여지가 있다 |
| Google Play | Google Play 정책 센터 + 개발자 프로그램 정책 | 자동 검사 비중이 크고, 사후 제재(앱 내림)도 많다 |
| 원스토어 | 원스토어 상품 검증 가이드라인 | 국내 법령·사회통념을 명시적 기준으로 둔다 |
App Store 심사 지침의 5개 장
App Store Review Guidelines는 다섯 개의 큰 장으로 나뉜다. 반려 통지에는 거의 항상 이 번호가 붙어 오므로, 구조를 외워 두면 통지를 읽는 속도가 달라진다.
| 장 | 이름 | 대표 관심사 |
|---|---|---|
| 1 | Safety | 유해 콘텐츠, 사용자 생성 콘텐츠 관리, 신체적 위해 |
| 2 | Performance | 앱 완성도, 베타, 메타데이터 정확성, 하드웨어·소프트웨어 요건 |
| 3 | Business | 결제, 구독, 수수료 모델 |
| 4 | Design | 최소 기능, 복제 앱, 확장 프로그램 |
| 5 | Legal | 프라이버시, 지식재산권, 게임·도박, 그 외 법적 요건 |
QA가 가장 자주 부딪히는 것은 2장과 5장이다. 2장의 하위 절은 2.1 App Completeness, 2.2 Beta Testing, 2.3 Accurate Metadata, 2.4 Hardware Compatibility, 2.5 Software Requirements로 구성된다. 5.1 Privacy 아래에는 5.1.1 Data Collection and Storage, 5.1.2 Data Use and Sharing, 5.1.3 Health and Health Research, 5.1.4 Kids, 5.1.5 Location Services가 있다. 4장에서는 4.3 Spam 이 중복·유사 앱 문제를 다룬다.
조항 번호와 문구는 개정된다. 릴리스 직전에는 항상 원문(개정 이력이 함께 공개된다)을 다시 확인한다. 이 레슨의 번호도 2026년 9월 기준이다.
QA가 실제로 잡을 수 있는 반려 사유
심사 반려 중 상당수는 QA가 출시 전에 잡을 수 있는 종류다. 사업 모델이나 법률 판단이 아니라 빌드와 메타데이터의 상태 이기 때문이다.
| 유형 | 전형적인 모습 | 관련 지침 | 출시 전 확인 방법 |
|---|---|---|---|
| 미완성 빌드 | 심사용 계정이 로그인 안 됨, 결제 샌드박스 미설정, placeholder 텍스트 | 2.1 | 심사 노트에 적은 계정으로 리뷰어처럼 처음부터 따라 해 본다 |
| 크래시·명백한 버그 | 특정 화면 진입 시 즉시 종료 | 2.1 | 제출 직전 빌드로 스모크를 다시 돈다. 업로드한 바이너리와 테스트한 바이너리가 같은지 확인 |
| 메타데이터 불일치 | 스크린샷이 실제 화면과 다름, 설명에 없는 기능, 타 플랫폼 언급 | 2.3 | 스크린샷·설명·키워드를 현재 빌드와 1:1 대조 |
| 권한 설명 부족 | 권한 요청 사유 문자열이 비었거나 형식적 | 5.1.1 | 실기기에서 모든 권한 팝업을 띄워 문구를 눈으로 확인(레슨 2) |
| 개인정보 처리방침 | 링크 깨짐, 앱 내에서 접근 불가, 수집 항목과 불일치 | 5.1.1 | 링크를 실제로 열어 보고, 선언과 실제 수집을 대조 |
| 로그인 강제 | 계정 없이도 쓸 수 있는 기능에 로그인 벽 | 5.1.1 | 비로그인 사용자 경로를 별도 시나리오로 테스트 |
| 최소 기능 | 웹사이트를 그대로 감싼 껍데기 앱 | 4.2 / 4.3 | 웹뷰 비중과 네이티브 기능 유무를 제품팀과 사전 점검 |
2.1은 반려 사유의 만능 주머니 다. 리뷰어가 앱을 제대로 실행하지 못하면 대부분 여기로 분류된다. 그래서 심사 제출 시 적는 리뷰 노트(App Review Information) 가 QA의 산출물이 된다. 테스트 계정, 2단계 인증 우회 방법, 특정 기능을 보려면 필요한 조건(예: 결제 후에만 열리는 화면), 지역 제한이 있으면 그 사실을 적는다.
Google Play — 자동 검사와 사후 제재
Play는 심사 방식이 다르다. 제출 시점의 사람 리뷰보다 정책 위반의 자동 탐지와 사후 조치 비중이 크고, 앱이 이미 배포된 뒤에 내려가는 일도 있다. QA 입장에서 중요한 축은 셋이다.
- 타깃 API 레벨 요건 — 신규 앱과 업데이트는 정해진 기한까지 최소 타깃 API 레벨을 맞춰야 한다. 2025년 8월 31일부터는 Android 15(API 35) 이상, 2026년 8월 31일부터는 Android 16(API 36) 이상이 기준이다(연장 신청 시 11월 1일까지 가능). 타깃을 올리면 OS 동작 변경이 앱에 그대로 적용 되므로, 타깃 상향은 QA에게 대규모 회귀 테스트 이벤트다. 어떤 동작이 바뀌는지는 Android 버전별 "동작 변경 사항" 문서를 읽고 테스트 범위를 잡는다(모듈 17 레슨 3의 OS 업데이트 대응과 이어진다).
- 민감 권한·API 선언 — 백그라운드 위치, 전체 파일 접근, SMS/통화 기록, 접근성 서비스 등은 Play Console에서 별도 선언 양식을 요구한다. 백그라운드 위치는 핵심 기능 관련성 과 눈에 띄는 고지(prominent disclosure) 를 요구하고, 기능을 시연하는 짧은 영상 링크까지 제출해야 한다. 고지는 앱을 정상적으로 쓰는 중에 보여야 하고, 설정 메뉴 안이나 개인정보 처리방침 안에만 있으면 인정되지 않는다.
- 데이터 안전 섹션 — 레슨 2에서 자세히 다룬다. 선언과 실제 동작이 다르면 정책 위반이다.
포그라운드 서비스를 쓴다면 타깃 Android 14(API 34) 이상에서 서비스 타입 선언 이 필수이고, Play Console의 앱 콘텐츠 페이지에서도 타입을 신고해야 한다(레슨 3).
원스토어 — 국내 유통의 세 번째 관문
원스토어는 국내 앱, 특히 통신사 제휴·게임·금융 앱에서 실질적인 유통 채널이다. 원스토어 상품 검증 가이드라인 은 심의 기본원칙으로 서비스 대상 국가의 법령과 사회통념 존중, 불법·음란·폭력 정보로부터 이용자와 청소년 보호, 개발자 표현의 자유 보장, 앱 생태계의 윤리성·공공성 확보를 든다. 구글·애플 정책과 방향은 비슷하지만, 국내 법령을 명시적 기준으로 둔다는 점 이 다르다 — 게임물 등급 분류, 청소년 보호, 위치정보 사업자 신고 같은 국내 규제가 그대로 심사 항목이 된다.
QA 관점에서 원스토어 출시가 따로 테스트를 요구하는 이유는 빌드가 다르기 때문 이다.
- 인앱 결제 SDK가 다르다(원스토어 IAP). 결제·환불·구독 복원 시나리오를 별도로 돌려야 한다
- 푸시 경로가 다를 수 있다. FCM 대신/과 함께 다른 경로를 쓰는 앱이 있다
- 서명·번들 형식이 다르다. 업로드 키 구성이 Play와 달라 서명 오류로 업로드가 막히는 일이 잦다
- Google Play 서비스 의존 코드(예: Play Integrity, GMS 전용 API)가 GMS 없는 기기에서 어떻게 동작하는지 확인이 필요하다
세 스토어에 같은 기능을 올린다면, 스토어별로 달라지는 부분만 뽑은 회귀 세트 를 따로 유지한다. 전체를 세 번 돌리는 것은 대부분의 팀에서 불가능하다.
반려 통지를 읽는 법
반려 통지가 오면 반사적으로 코드를 고치기 전에 원인을 분류 한다. 분류에 따라 다음 행동이 다르다.
| 분류 | 판단 기준 | 다음 행동 |
|---|---|---|
| 사실 오인 | 리뷰어가 기능을 찾지 못했거나 조건을 몰랐다 | 코드 수정 없이 재현 경로를 상세히 적어 회신 . 필요하면 영상 첨부 |
| 명백한 위반 | 조항을 읽어 보니 우리가 틀렸다 | 수정 후 새 빌드 제출 |
| 해석 차이 | 조항은 알겠는데 우리 사례에 적용되는지 다툼이 있다 | 근거를 정리해 소명. 그래도 안 되면 공식 이의 제기 절차 |
| 메타데이터 문제 | 빌드가 아니라 설명·스크린샷·연령 등급 문제 | 대개 새 빌드 없이 메타데이터만 수정해 재제출 |
분류를 건너뛰면 손해가 크다. 사실 오인인데 코드를 고쳐 새 빌드를 올리면 심사 대기가 처음부터 다시 시작된다. 반대로 명백한 위반인데 소명만 반복하면 심사자와의 왕복이 길어진다.
반려 통지 수신
│
├─ 인용된 조항 번호를 원문에서 찾아 전문을 읽는다
├─ 통지에 첨부된 스크린샷·영상에서 리뷰어의 실제 경로를 복원한다
├─ 그 경로를 우리 실기기에서 그대로 재현해 본다
│ ├─ 재현됨 → 결함 또는 위반. 수정 후 새 빌드
│ └─ 재현 안 됨 → 기기·OS·지역·계정 조건 차이를 좁힌다
│ ├─ 조건 찾음 → 그 조건에서 수정
│ └─ 못 찾음 → 재현 경로를 적어 회신
└─ 결과와 조항을 사내 반려 이력에 기록한다반려 이력은 팀의 자산이다
한 번 반려된 사유는 다시 반려된다. 사람이 바뀌고 기억이 흐려지기 때문이다. 반려 이력 표 를 유지하면 다음 릴리스의 체크리스트가 저절로 생긴다.
| 일자 | 스토어 | 조항 | 요지 | 원인 분류 | 조치 | 재발 방지 체크 항목 |
|---|---|---|---|---|---|---|
| 2026-03-11 | App Store | 2.1 | 심사용 계정 로그인 실패 | 사실 오인 | 계정 재발급·회신 | 제출 전 리뷰 노트 계정으로 로그인 확인 |
| 2026-05-02 | Play | 데이터 안전 | 광고 SDK 수집 항목 누락 | 명백한 위반 | 선언 수정 | SDK 추가 시 데이터 선언 갱신 |
| 2026-06-20 | 원스토어 | 결제 | IAP 복원 미동작 | 명백한 위반 | 수정 후 재제출 | 스토어별 결제 회귀 세트 실행 |
마지막 열이 핵심이다. 이 열만 모으면 출시 전 체크리스트 가 된다.
릴리스 전 스토어 체크리스트 뼈대
[공통]
□ 제출할 바이너리 = 스모크 테스트를 통과한 바이너리인가 (버전·빌드 번호 대조)
□ 심사용 계정이 살아 있고, 2FA 없이 또는 우회 방법과 함께 전달되는가
□ 스크린샷·앱 설명이 현재 빌드와 일치하는가
□ 개인정보 처리방침 URL이 열리고 내용이 최신인가
□ 모든 권한 요청 문구가 실제 사용 목적을 설명하는가
□ 연령 등급 설문 답변이 실제 콘텐츠와 일치하는가
[App Store]
□ 리뷰 노트에 조건부 기능 진입 경로가 적혀 있는가
□ 로그인 없이 쓸 수 있는 기능에 로그인 벽이 없는가
□ 프라이버시 매니페스트와 App Privacy 라벨이 최신인가 (레슨 2)
[Google Play]
□ 타깃 API 레벨이 기한 요건을 충족하는가
□ 민감 권한 선언 양식과 고지 화면이 준비되었는가
□ 데이터 안전 섹션이 현재 SDK 구성과 맞는가 (레슨 2)
□ 포그라운드 서비스 타입이 선언·신고되었는가 (레슨 3)
[원스토어]
□ 원스토어 빌드의 결제·구독·복원 시나리오를 돌렸는가
□ GMS 없는 기기에서 핵심 기능이 동작하는가
□ 서명 구성이 업로드 요건과 맞는가실무에서 왜 필요한가
심사 반려는 결함 하나보다 비용이 크다. 재제출하면 심사 대기가 다시 시작되고, 마케팅 일정과 프로모션, 제휴사 공지가 모두 밀린다. 그런데 앞의 표에서 보듯 반려 사유의 절반 이상은 테스트로 사전에 걸러낼 수 있는 종류 다. 심사용 계정이 죽어 있는지, 스크린샷이 옛 화면인지, 권한 문구가 비었는지는 모두 출시 전 30분이면 확인된다.
또 이 작업은 QA가 릴리스 프로세스에서 자기 자리를 만드는 방법이기도 하다. 기능 테스트는 누가 해도 비슷하지만, 정책 문서를 읽고 체크리스트로 번역하는 일 을 하는 사람은 팀에 대개 없다. 반려 이력 표와 스토어 체크리스트는 리드나 PM에게 곧바로 가치가 보이는 산출물이다.
채용시장에서의 위치
"앱 출시 경험 있으신가요"라는 질문에 "심사 반려를 세 번 겪었고, 그 사유를 정리해 체크리스트를 만들어 이후 반려가 없었습니다"라고 답할 수 있으면 강하다. 반려 이력 표는 기밀성이 낮아 조항과 조치만 남기고 포트폴리오에 넣기도 쉽다. 국내 앱 조직에서는 원스토어·갤럭시 스토어까지 다뤄 본 경험이 특히 드물어 차별점이 된다.