앱 심사 제출 전 체크리스트, 실제 환경 설정과 검증으로 다시 정리

빌드5를 앱 스토어에 제출하기 직전, 실제 환경에서 작동해야 할 광고와 결제 관련 설정들을 최종 점검했다. 이전 빌드들의 심사 과정에서 놓치기 쉬웠던 부분들을 문서로 정리하면서, 앞으로 팀 내에서도 심사 전 체크리스트로 활용할 수 있겠다는 생각이 들었다.

빌드5, 세 가지 핵심 항목 점검

제출 문서에 정리한 내용은 크게 세 가지였다.

AdMob 실제 ID를 적용한다는 건, 로컬 개발 환경이나 테스트 빌드에서는 테스트 광고 ID를 썼다가, 이제 프로덕션 환경으로 나가면서 실제 광고 네트워크에 연결된다는 뜻이다. 과거에 테스트 ID 그대로 제출했다가 "광고 네트워크 접근 오류", "광고 렌더링 실패" 같은 이유로 거절받은 사례들이 있어서, 이번엔 미리 점검 항목으로 명시했다.

IAP(인앱 결제) 검증 보강도 마찬가지다. Apple은 심사 기준을 주기적으로 업데이트하는데, 영수증 검증 로직이 최신 표준을 따르는지 확인하는 게 중요하다. 구버전 검증 방식을 그대로 두면, 심사 과정에서 "결제 검증 미흡"이라는 지적을 받을 수 있다. 팀 입장에서는 이런 요구사항 변화를 자동으로 추적하기 어려우니, 주요 빌드 제출 전마다 체크리스트로 확인하는 게 보험이다.

왜 이런 사전 문서가 필요했는가

팀장 포지션에서 볼 때, 이 문서는 세 가지 역할을 한다.

첫째, 심사 거절 리스크를 줄이기 위한 의사결정 기록이다. 빌드5 제출 여부를 결정할 때 "이 세 가지를 확인했으니 제출 가능하다" 또는 "이 항목이 미흡하니 수정 후 제출하자" 같은 판단 근거가 생긴다. 특히 신규 입사자나 다른 팀원이 나중에 "왜 이렇게 했는가" 물었을 때 참고할 문서 역할을 한다.

둘째, 반복 가능한 체크리스트 구축이다. 앱 스토어 심사는 한 번 끝나는 게 아니라 매 빌드마다 반복된다. AdMob, IAP 같은 중요 항목들은 매번 동일하게 확인해야 하는 사항이니, 이를 문서화하면 다음 빌드 때 "빌드4 때 뭘 했더라" 하고 헤맬 필요가 없다.

셋째, 팀 차원의 학습 기록이다. 빌드5 심사 과정에서 "AdMob 실제 ID 미적용으로 거절" 같은 일이 생기면, 그 원인을 분석하고 다음엔 "빌드5 체크리스트에 AdMob 항목 추가" 이렇게 반영한다. 개별 개발자의 실수를 팀 차원의 프로세스로 승격시키는 거다.

문서 관리, 팀 사이즈와 빌드 주기에 맞춰

처음엔 "이 정도 항목 뭐 하러 문서로?" 싶을 수도 있다. 소규모 팀이고 빌드 사이클이 길면, 팀장이 머릿속으로 기억하고 구두로 "이것 확인했나" 물으면 된다. 하지만 규모가 조금만 커져도 이런 구두 커뮤니케이션은 빠진 항목이 생기기 마련이다. 심사 제출 직전에 다급할 때는 더욱 그렇다.

또한 심사 결과가 나올 때까지 평균 수일에서 수주가 걸린다. 그 기간 동안 팀은 다음 기능을 개발 중이고, 심사 거절이 들어오면 "아, 빌드4 때 이 부분 빠뜨렸었네" 하고 다시 돌아가야 한다. 이런 리사이클을 줄이려면, 제출 전 체크리스트가 체계적일수록 좋다.

다음 빌드를 위한 확장 포인트

빌드5 제출 현황을 정리하면서 든 생각은, 앞으로 빌드6, 빌드7… 가 나올 때마다 이 문서 구조를 재사용할 수 있다는 점이다. 버전마다 추가되는 기능이 있으면 (예: 신규 권한, 새로운 외부 API), 그에 맞춘 심사 항목도 늘어날 것이다. 문서를 선제적으로 관리하면, 팀의 심사 대응 역량이 점진적으로 쌓인다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.