iOS 앱 거절, 수정해서 재신청하기

앱 스토어 리뷰 거절을 받으면 뭔가 실패한 것 같은 기분이 드는데, 사실 이건 개발 사이클의 자연스러운 부분이다. 특히 iOS의 경우 Apple의 까다로운 심사 기준이 있기 때문에, "첫 제출 탈락 → 수정 → 재신청"은 거의 필수 코스다. 이번 작업도 그런 배경에서 시작됐다.

거절의 원인, ATT 정책

이번엔 ATT(App Tracking Transparency) 관련 이슈였다. iOS 14부터 Apple은 사용자 추적 권한을 매우 엄격하게 관리하기 시작했다. 앱이 광고 ID나 기타 추적 데이터를 수집하려면 반드시 사용자에게 명시적으로 동의를 구해야 하고, 그 UI/UX도 Apple의 가이드라인을 정확히 따라야 한다. 우리가 놓친 부분이 있었나 보다.

Apple 심사팀이 지적한 부분을 다시 정리해서 수정본을 만들었다. 그 과정에서 세 군데를 건드렸다:

버전 관리: 언제 뭘 올릴까

build 1.0.0+4라는 표기가 좀 아리송할 수 있다. Flutter에서는 이렇게 구분한다:

1.0.0  → semantic version (사용자에게 보이는 버전)
+4     → build number (내부 빌드 카운트)

같은 기능, 같은 내용이면 semantic version은 건드리지 않는다. ATT 정책 수정도 "외부 인터페이스가 변한 게 아니라 내부 동작만 조정한 것"이니, 1.0.0은 유지하고 빌드 번호만 올린다. 하지만 App Store Connect는 거절된 빌드를 재신청할 때 "새 빌드"로 인식해야 하니까, +4가 필수다.

이 과정을 처음 겪는 팀원이 물어봤다: "어, semantic version을 왜 안 올려?" 좋은 질문이다. 답은 "사용자 입장에선 기능이 추가되거나 변경된 게 아니니까"다. 하지만 빌드는 구분해야 한다. 이런 미묘한 부분도 팀 onboarding 체크리스트에 있으면 좋다.

왜 문서를 계속 쓰는가

APPLE-REVIEW-STATUS.md는 단순한 일지가 아니다. 이걸 계속 갱신하면:

• 다음 번 심사 담당자가 맥락을 빠르게 이해 — 같은 설정이 왜 있는지 문서를 보고 알 수 있다
• 패턴 인식 — 같은 종류의 거절이 반복되면 근본 원인을 찾을 수 있다
• 팀 전체의 학습 — iOS 심사 정책은 계속 변한다. 그 변화에 어떻게 대응했는지 기록해두면, 나중에 새 기능 추가할 때 참고할 수 있다

내 경험상, 앱 거절은 "실수"가 아니라 "규정을 다시 읽는 계기" 다. Apple은 매해 심사 기준을 조정한다. 우리 앱의 의존성이나 광고 네트워크 정책도 변한다. 그 변화를 주기적으로 따라가지 못하면 다음 업데이트 때 또 거절받는다. 문서를 남겨두면 그 다음 사람도, 그 다음 팀도 그걸 디딤돌 삼을 수 있다.

다음, 그리고 배움

이제 재신청했다. 보통 1~3일 안에 심사 결과가 나온다. Apple이 다시 거절할 수도, 승인할 수도 있다. 만약 또 거절받으면 문서를 갱신하고, 피처팀이나 마케팅팀과도 함께 본다. ATT는 광고 관련이니까.

앱 스토어 심사는 빌드 → 거절 → 수정 → 재신청 → 승인의 순환이다. 처음엔 답답했지만, 지금은 이 과정 자체가 "규정을 읽는 시간", "팀의 정책 이해도를 높이는 시간"으로 본다.

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

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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