App Store에 앱을 올리다 보면, 가끔 "아,, 수정할 게 있네?" 하고 심사를 취소하고 다시 올려야 하는 경우가 생긴다.
이번 앱 배포는 평소와 달랐다. CI/CD 파이프라인이 한 번 실패했고, 그 여파로 재배포까지 진행해야 했기 때문이다. 원인은 사소했다. Fastlane의 release_description에 포함된 이모지 때문이었다.
이모지 때문에 GitHub Actions의 파이프라인이 멈췄고, 배포는 자동으로 진행되지 않았다. App Store Connect에는 이미 빌드가 올라가 있었지만, 설명이 누락되어 배포가 보류된 상태였다.
결국 수동으로 설명을 입력해 배포를 완료했지만, GitHub Actions 기록에 failed라는 붉은 흔적이 남는 것이 마음에 걸렸다.
개발자에게 commit 이력이나 build 로그처럼 '기록의 일관성'은 매우 중요한 가치이기에, 문제를 수정한 뒤 다시 CI/CD를 돌려 최종 배포를 완료했다
평소라면 빌드를 올리고 반나절이면 심사가 통과되곤 했다.
그런데 이번에는 달랐다. 빌드를 올렸다가 급하게 수정할 내용이 생겨 심사를 취소했고, 수정한 뒤 새 빌드를 다시 올렸다. 그런데 하루가 지나도 심사가 Waiting For Review
상태였다.
혹시 심사자가 취소된 빌드만 보고 새로 올린 빌드를 놓친 건가 싶어, 일부러 몇 시간 텀을 두고 다시 올려보기도 했다. 하지만 결과는 똑같았다. 평소보다 훨씬 오래 걸렸다. "왜 취소하면 더 오래 걸리지?" 라는 궁금증이 생겼다.
이유를 찾아보니, 애플 앱 심사는 완전 자동화가 아니라 사람이 직접 리뷰를 한다고 한다. 이 사실을 바탕으로 프로세스를 역으로 추론해보니 다음과 같은 결론에 도달했다.
즉, 취소하는 순간 '우선순위가 초기화'되고 큐 맨 뒤로 밀려나는 것 같았다. '반나절 컷'이 가능했던 빌드도, 취소 후에는 하루 이상 걸린다는 것을 직접 경험하며 알게 된 사실이다.
내가 직접 겪어본 경험을 한마디로 요약하자면 이렇다.
App Store 심사 취소는 사실상 '심사 초기화 버튼'과 같다.
물론 심사 대기 시간이 길어진다고 해서 앱에 문제가 생긴 건 아니다. 하지만 나처럼 App Store에 배포 경험이 많지 않은 학생 개발자라면, 괜히 취소했다가 심사 시간이 더 오래 걸려서 당황하지 않도록 이 점을 미리 알아두면 좋을 것 같다.
앱 설명, 스크린샷 같은 단순 수정이라면 빌드를 굳이 취소하지 말고, 메타데이터만 변경해서 심사를 다시 요청하는 것이 훨씬 효율적이다. 정말 빌드를 바꿔야만 하는 상황이라면 심사가 늦어지는 것은 감수해야 할 부분인 것 같다. (물론 급한 상황이라면 Expedite Review
같은 방법을 활용할 수 있다고 하지만, 나는 아직 직접 해보진 않았다.)
이번 경험을 통해 App Store 심사 시스템에 숨겨진 비밀(?) 같은 것은 없고, 그저 시스템 특성상 그런 것이라는 걸 알게 되었다. 작지만 귀중한 경험이었다.