스토어 심사 리젝 대응 플레이북: 재제출 전에 보는 체크 순서

TL;DR

심사 리젝 대응은 수정 속도보다 원인 분해 정확도가 먼저였습니다. 리젝 사유를 기능/메타/정책 문구로 쪼개서 확인하면 재리젝 확률이 확실히 줄었습니다.

내 상황

출시 직후 업데이트 빈도가 높은 시점이라 심사 지연이 수익과 유입 모두에 영향을 줬습니다. 빠른 재출시가 필요했지만, 근거 없는 수정은 오히려 재리젝을 만들었습니다. 앱 기능 자체는 크게 바뀌지 않았는데도 리젝 사유 문구가 반복되어, 기술 수정보다 제출 자료의 정합성이 중요한 상태였습니다. 운영팀과 개발팀이 서로 다른 체크리스트를 사용해 누락이 생겼고, 재제출 직전마다 책임 소재가 불명확해지는 문제가 있었습니다. 그래서 대응 프로세스를 “원인 분해 -> 증거 확보 -> 문구 정합성 검수” 순서로 고정했습니다.

문제 정의

리젝 메일 문구가 추상적이라 팀 내부 해석이 매번 달랐습니다. 해석이 갈리면 수정 범위가 불필요하게 커져 배포 일정이 미뤄졌습니다. 또한 스토어 메타데이터와 앱 내 안내 문구가 미세하게 어긋난 상태가 자주 발견됐고, 이 불일치가 재리젝 트리거로 작동했습니다. 결국 핵심 문제는 “한 번에 많이 고치는 것”이 아니라 “정확한 원인 항목만 고치는 것”이었습니다.

시도/실패/대안

처음에는 리젝 메시지 키워드만 바꾸고 재제출했지만 동일 사유로 반려됐습니다. 다음부터는 리젝 사유를 화면 캡처 기준으로 재현해 증거를 먼저 모았습니다. 이후 메타 문구와 앱 내 문구를 동시에 맞춰 제출하자 반복 리젝이 줄었습니다. 추가로 대응 문서를 1페이지 템플릿으로 표준화해, 어떤 항목을 수정했고 왜 수정했는지 심사관 시점에서 읽히도록 정리했습니다. 실패 패턴은 “릴리즈 직전 임시 수정”에서 가장 많이 나왔고, QA가 반영 범위를 놓쳐 재리젝이 발생했습니다. 대안으로 제출 전 24시간 냉각 구간을 두고, 체크리스트를 기준으로 교차 리뷰를 강제했습니다.

측정 방법

• 기간: 최근 3회 리젝 대응 로그
• 지표: 재제출 소요 시간, 재리젝 횟수
• 기준: 대응 체크리스트 도입 전/후 비교
• 보조 지표: 문구 불일치 발견 건수, 제출 전 교차 리뷰 누락 건수

결과

항목	도입 전	도입 후	변화
재제출까지 평균 시간	3.2일	1.6일	절반 단축
동일 사유 재리젝	2회	0회	재발 감소
메타/앱 문구 불일치	잦음	거의 없음	검수 안정화

리젝 대응 문서가 표준화되면서 팀 신규 인원도 같은 순서로 대응할 수 있었고, 특정 담당자 의존도가 낮아졌습니다. 가장 큰 변화는 “수정 양”이 아니라 “수정 정확도”였고, 이것이 일정 안정성으로 바로 연결됐습니다.

결론

리젝 대응은 수정 자체보다 확인 순서가 성과를 만들었습니다. 재현 증거와 문구 정합성 체크를 분리해 관리하면 일정 리스크를 크게 줄일 수 있습니다. 다음 운영 단계에서는 리젝 가능성이 높은 정책 항목을 릴리즈 체크리스트 초반으로 이동해 사전 차단 비율을 높일 예정입니다. 심사 이슈는 기술 문제가 아니라 운영 문제로 번지는 경우가 많기 때문에, 대응 프로세스를 제품 운영의 기본 루틴으로 내재화해야 합니다. 또한 대응 로그를 누적하면 어떤 사유가 반복되는지 월 단위로 확인할 수 있어, 출시 전 예방 항목을 점점 자동화할 수 있습니다. 결국 목표는 리젝 이후의 빠른 복구가 아니라, 리젝 자체를 덜 발생시키는 운영 체계를 만드는 것입니다.

체크리스트

• 리젝 사유를 기능/메타/정책 문구로 분해했는지 확인
• 리젝 화면 재현 캡처를 증거로 남겼는지 확인
• 앱 내 문구와 스토어 메타 문구가 일치하는지 확인
• 재제출 전에 변경 내역을 1페이지 요약으로 정리했는지 확인

관련 글

• AdMob 시작 7일차 eCPM 로그
• 전면 광고 빈도 vs 리텐션 실험
• 온보딩 퍼널 이벤트 설계