앱 심사가 왜 이렇게 오래 걸리나요?

느린 검토가 자동으로 앱에 문제가 있다는 의미는 아닙니다. 대기열 지연과 차단된 제출을 구별하는 방법, Apple과 Google이 실제로 약속하는 것, 지원팀에 연락할 시기를 알아보세요.

빌드를 업로드하고 스크린샷을 확인했으며 출시를 계획했습니다. 그런데 아무 일도 일어나지 않습니다. App Store Connect에는 여전히 '심사 대기 중'으로 표시되거나 Play Console에서 변경 사항이 계속 심사 중입니다. 그동안 불확실한 매일이 마케팅, 고객 지원, 출시 발표를 조정하기 어렵게 만듭니다.

답답한 점은 지연에 여러 가지 가능한 설명이 있다는 것입니다. 제출이 단순히 차례를 기다리고 있을 수 있습니다. 리뷰어가 정보를 필요로 할 수 있습니다. 빌드가 검토에 전혀 도달하지 못했을 수 있습니다. 또는 검토가 이미 완료되었고 게시가 사용자를 기다리고 있을 수 있습니다. 이 가이드는 이러한 상황을 구별하는 방법을 설명합니다. Apple App Review에 초점을 맞추고 Google Play 비교를 별도로 제공합니다. 출처는 2026년 10월 3일에 확인했습니다.

앱 심사는 얼마나 걸려야 하나요?

Apple은 평균적으로 제출물의 90%가 24시간 이내에 검토된다고 말합니다. 이는 유용한 맥락이지만 개별 앱에 대한 보장된 처리 시간은 아닙니다. 일부 제출물은 그 창 밖에 있으며, 통계는 예외에 대한 완료 시간을 제공하지 않습니다. Apple은 또한 불완전한 제출물이 검토를 지연시킬 수 있다고 경고합니다. [1]

그 숫자를 출시 약속이 아닌 계획 참고용으로 취급하세요. 하루 이상 걸리는 제출 자체가 거부나 계정 문제의 증거는 아닙니다. 마찬가지로 평균 때문에 실행 가능한 메시지를 무시해서는 안 됩니다. 상태와 리뷰어 서신이 다른 개발자의 가장 빠른 승인과의 비교보다 더 중요합니다.

먼저 지연이 실제로 어디에 있는지 확인하세요

모든 노란색 표시를 "Apple이 내 앱을 검토 중"으로 번역하지 말고 정확한 상태를 읽으세요. 검토 대기 중은 제출이 대기열에 있음을 의미하고, 검토 중은 검토가 시작되었음을 의미합니다. 개발자 출시 대기 중은 앱이 승인되었지만 여전히 출시 조치가 필요함을 의미합니다. 수출 규정 준수 대기 중은 다른 프로세스입니다. 승인된 항목도 제출의 다른 항목이 거부된 경우 게시되지 않은 상태로 남을 수 있습니다. [2]

업로드된 빌드뿐만 아니라 앱 버전과 제출을 함께 확인하세요. 빌드 목록의 스크린샷은 제출 페이지와 다른 이야기를 할 수 있습니다. 버전, 빌드 번호, 제출 시간, 현재 상태를 기록하세요. 이 작은 기록으로 이전 빌드를 문제 해결하거나 TestFlight 제출을 App Store 출시와 혼동하는 것을 방지할 수 있습니다.

리뷰어는 전체 앱을 경험해야 합니다

검토자는 접근할 수 없는 기능을 평가할 수 없습니다. Apple의 제출 체크리스트는 전체 액세스, 활성 데모 계정 또는 적절한 데모 모드, 필요한 하드웨어 또는 샘플 리소스, 라이브 백엔드 서비스를 요구합니다. 또한 개발자가 검토 노트에 명확하지 않은 기능과 구매를 설명하도록 요청합니다. 이러한 요구 사항은 액세스를 조사할 첫 번째 장소로 만듭니다. [3]

제공한 정확한 자격 증명을 테스트하세요. 가급적 깨끗한 기기에서. 계정에 이메일 확인, 유료 권한, 초대 또는 일회용 비밀번호가 필요한지 확인하세요. 개발 계정 없이 온보딩 경로를 시도하세요. 기능에 특정 지역이나 두 번째 사용자가 필요한 경우 리뷰어가 해당 설정을 재현할 수 있는 방법을 설명하세요. 리뷰어가 의도한 워크플로를 추론할 것이라고 가정하지 마세요.

짧고 재현 가능한 연습이 판매 홍보보다 더 유용합니다. 예: 제공된 계정으로 로그인하고, 라이브러리를 열고, 샘플 프로젝트를 선택하고, 내보내기를 탭합니다. 예상되는 제한 사항과 그 이유를 포함하세요. 이것은 우선순위를 사는 것이 아니라 누군가 제출물에 도달했을 때 피할 수 있는 모호성을 줄입니다.

거절에는 더 많은 기다림이 아니라 답이 필요합니다

Apple이 앱을 거부하면 메시지에 문제와 관련 가이드라인이 설명됩니다. App Store Connect에서 답장하고 지원 자료를 첨부할 수 있습니다. Apple은 메타데이터 거부는 동일한 빌드로 해결하고 다시 제출할 수 있다고 명시합니다. 따라서 새 바이너리가 항상 필요한 것은 아닙니다. [4]

특정 반론에 답하세요. 리뷰어가 기능을 찾지 못했다면 탐색 단계를 제공하세요. 우려가 오해의 소지가 있는 스크린샷이라면 스크린샷을 수정하세요. 동의하지 않는다면 경쟁 앱도 그렇게 한다고 반복하기보다 동작을 설명하고 증거를 제시하세요. 변경한 내용과 Apple에 명확히 해달라고 요청하는 내용을 구분하세요.

간단한 이슈 로그를 유지하세요: 검토자의 질문, 귀하의 응답, 변경된 자산 또는 빌드, 다음 필수 조치. 이렇게 하면 이후 서신을 더 쉽게 따라갈 수 있습니다. 또한 팀이 독립적으로 서로 다른 설명을 제출하는 것을 방지합니다. 심사 커뮤니케이션은 가장 긴 답변을 보내는 경쟁이 아니라 디버깅 대화입니다.

빌드 처리와 TestFlight는 별도의 체크포인트입니다

업로드된 빌드가 반드시 제출 준비가 된 것은 아닙니다. Apple의 빌드 상태 참조는 처리 중, 규정 준수 정보 누락, 제출 준비 상태를 구분합니다. 또한 TestFlight의 검토 대기 및 베타 검토 중 상태를 내부 테스터용 가용성과 구분합니다. 외부 베타 테스트에는 TestFlight 앱 검토가 필요할 수 있습니다. [5]

베타가 막혀 있다면 App Store 심사 대기열 문제를 찾기 전에 빌드 상태를 점검하세요. 규정 준수 누락의 경우 Apple은 개발자에게 암호화 질문에 답하거나 관련 문서를 제공하도록 안내합니다. 일부 빌드는 구성을 통해 적용 가능한 면제를 선언할 수 있지만, 프롬프트를 우회하기 위해 설정을 변경하기보다는 정확하게 답변해야 합니다. [6]

승인이 항상 즉시 사용 가능을 의미하지는 않습니다

Apple의 게시 워크플로는 빌드 선택, 가용성 설정, 제출, 검토 문제 해결, 배포를 구분합니다. 승인된 앱이 라이브로 전환되는 데 최대 24시간이 걸릴 수 있다고 말합니다. 릴리스가 수동, 자동 또는 단계적일지도 선택합니다. 승인된 버전을 "아직 검토 중"이라고 설명하기 전에 해당 설정을 확인하세요. [7]

업데이트의 경우 단계적 출시는 자동 업데이트가 활성화된 적격 사용자에게 7일 동안 버전을 점진적으로 배포합니다. 이는 출시 선택이지 7일의 추가 검토가 아닙니다. 한 고객이 여전히 이전 버전을 본다면 검토자가 승인을 보류했다고 가정하기 전에 먼저 출시 방법과 가용성을 확인하세요. [8]

Google Play는 다른 검토 기간을 가집니다

Apple의 헤드라인 타이밍을 Google Play에 적용하지 마세요. Google은 리뷰가 몇 시간 또는 최대 7일이 걸릴 수 있으며 예외적인 경우 더 오래 걸릴 수 있다고 말합니다. 게시 개요에서는 변경 사항이 검토 중일 때 다른 변경 사항을 제출하면 앱이 검토 대기열에서 뒤로 밀릴 수 있다고 경고합니다. 따라서 반복적인 작은 편집은 예측 가능한 출시에 역효과를 낼 수 있습니다. [9]

Play Console의 게시 개요는 검토 중인 변경 사항과 게시할 준비가 된 변경 사항을 구분합니다. 관리형 게시가 활성화되면 승인과 게시는 별개의 결정입니다. 휴대폰에서 새 리스팅이 보이는지만 보지 말고 변경 대기열을 확인하세요. 제출하기 전에 의도한 출시 패키지를 완성하고, 실제로 수정할 필요가 없는 한 기다리는 동안 관련 없는 편집을 피하세요.

실용적인 예: 재제출 전에 진단하기

월요일 아침에 제출된 습관 추적 앱을 상상해 보세요. 화요일 저녁, 창업자는 승인이 도착하지 않아 앱을 다시 빌드하기 시작합니다. 그 전에 세 가지를 확인합니다: 버전이 실제로 대기 중인지, 심사에서 메시지를 보냈는지, 제공된 계정으로 온보딩을 완료할 수 있는지. 이는 예시 시나리오이며 측정된 AsoTheory 고객 사례가 아닙니다.

앱이 단순히 대기 중이고 액세스가 작동한다면 교체 빌드는 입증된 해결책을 제공하지 않습니다. 검토자가 로그인 실패를 보고한다면 액세스를 수정하는 것이 실제 장애물을 해결합니다. 상태가 개발자 출시 대기 중이라면 올바른 조치는 재제출이 아니라 출시입니다. 동일한 경과 시간에도 완전히 다른 세 가지 대응이 필요할 수 있습니다. 그래서 해결책을 선택하기 전에 상태를 진단하는 것이 먼저입니다.

언제 Apple에 문의해야 하나요?

설명할 수 없고 비정상적으로 긴 지연의 경우 간결한 타임라인과 제출 식별자를 포함하여 Apple의 검토 연락 경로를 사용하세요. 현재 상태, 이전 서신, 이미 확인한 사항을 설명하세요. 인용된 지침에는 에스컬레이션을 보장하는 보편적인 일수 임계값이 없습니다. 임계값을 지어내거나 지원 메시지가 앱을 앞으로 이동시킬 것이라고 약속하지 마세요.

신속한 검토는 별도의 요청입니다. Apple은 중요한 버그 수정 또는 직접 관련된 이벤트와 연계된 출시와 같은 예를 제시합니다. 실제 상황과 영향을 설명하세요. 일반적인 마케팅 조바심은 같은 것이 아닙니다. 신속한 요청은 보장된 지름길로 제시해서는 안 됩니다. [1]

불확실성을 중심으로 출시 계획

유용한 내부 릴리스 노트에는 네 가지 필드가 있습니다: 무엇이 바뀌는지, 고객이 현재 접근할 수 있는 것, 누가 검토 서신을 지켜보는지, 무엇이 발표를 촉발하는지. 제출을 소유할 한 사람을 지정하세요. 모두가 오후 내내 콘솔을 새로 고치는 대신 체크인 일정에 합의하세요. 검토자 메시지와 제출된 정확한 버전을 포함한 증거를 함께 보관하세요. 이 중 어느 것도 Apple의 대기열을 단축하지는 않지만, 불확실성이 불필요한 재구축이나 상충되는 결정으로 변하는 것을 방지합니다.

출시에 새로운 구독이 추가되거나 온보딩이 변경된다면 승인이 도착하기 전에 지원 답변을 준비하세요. 마케팅 링크가 실제로 다운로드할 수 있는 버전을 설명하는지 확인하세요. 빌드가 승인되었다고 해서 기능이 라이브라고 발표하지 마세요. 첫 출시의 경우 대체 랜딩 페이지 메시지를 준비하세요. 이는 운영 권장 사항이며 스토어 요구 사항이나 심사 속도에 대한 약속이 아닙니다. 그 가치는 팀이 통제할 수 없는 일정 속에서도 현명하게 행동할 수 있다는 점입니다.

출시 체크리스트에 심사 준비를 포함하세요: 작동하는 액세스, 명확한 메모, 테스트된 구매 흐름, 정확한 자산, 모니터링되는 서신, 의도적인 게시 설정. 제출과 고정된 캠페인 날짜 사이에 여유를 두세요. 타이밍이 중요하다면 승인이 늦게 도착할 경우 어떻게 할지 미리 결정하세요: 발표를 일시 중지하거나, 현재 버전을 계속 제공하거나, 수정된 기간을 전달하세요.

마지막으로 증거와 이야기를 구분하세요. 다른 개발자의 긴 대기 시간은 실제일 수 있지만 앱이 지연되는 이유를 증명하지는 않습니다. 인용된 Apple 또는 Google 지침 어느 것도 AI 생성 앱이 백로그를 유발한다는 보편적인 설명을 확립하지 않습니다. 유용한 질문은 "어떤 소문이 이것을 설명하는가?"가 아니라 "내 제출 상태는 무엇이며 실제로 취할 수 있는 조치가 있는가?"입니다.