앱 MVP 심사 거절 대응: 수정·재제출과 이의제기 전 남길 5가지 기록

앱 MVP 심사 거절 대응: 수정·재제출과 이의제기 전 남길 5가지 기록

앱 MVP를 처음 제출한 뒤 ‘거절’ 안내를 받으면 팀은 곧바로 빌드를 고치거나, 반대로 심사 판단에 답해야 한다는 압박을 받기 쉽습니다. 하지만 거절이라는 한 단어만으로는 무엇이 거절됐는지, 지금 공개 중인 버전이 있는지, 수정해서 다시 낼지, 판단 오류라고 보고 이의제기를 검토할지 알 수 없습니다. 외주 개발사·내부 기획자·대표가 서로 다른 화면과 이메일만 보고 움직이면 같은 문제를 다시 제출하거나, 수정 전후의 차이도 설명하기 어려워집니다.

먼저 답하면, 플랫폼과 제출 단위, 안내된 정책 또는 가이드라인, 현재 공개 상태, 수정하려는 범위와 확인 결과, 재제출 또는 이의제기 결정을 뒷받침하는 근거를 한 기록에 나누어 남기는 편이 좋습니다. 이 글은 어느 선택이 심사를 통과시키거나 앱을 복구한다고 보장하지 않습니다. 실제 안내문과 현재 콘솔 상태, 적용되는 최신 공식 정책을 읽어 팀의 책임 범위 안에서 판단하기 위한 기록 틀입니다.

공식 원문 확인일: 2026년 9월 16일 · 작성: 유인어스(UINUS)

왜 ‘거절됨’만 적으면 다음 판단이 흐려질까요?

Google Play는 앱 상태, 업데이트 상태, 항목 상태를 구분해 보여 줍니다. 예를 들어 기존 앱의 업데이트가 거절된 경우와 처음 공개하려는 초안 앱이 거절된 경우는 같은 방식으로 설명되지 않습니다. Google은 기존 앱 업데이트가 거절됐을 때 수정 후 재제출 또는 이의제기를 선택할 수 있다고 안내합니다. 정책 상태 화면에서는 거절, 삭제, 정지처럼 현재 조치의 종류와 추가 정보를 확인할 수 있습니다.

Apple도 App Store Connect의 App Review 영역에서 현재·과거 제출을 보고, 통과하지 못한 제출에는 관련 App Review Guidelines 정보가 제공될 수 있다고 설명합니다. 즉, 팀의 첫 기록은 ‘스토어 심사에 실패했다’가 아니라 어느 플랫폼의 어느 제출·빌드·항목에서 어떤 안내가 왔는지부터 시작해야 합니다. 실제 문구나 스크린샷에는 계정 정보와 테스트 자격 증명이 포함될 수 있으므로, 공유 범위는 회사의 보안 절차에 맞춰 정하세요.

수정·재제출과 이의제기를 같은 작업으로 보지 마세요

Google Play의 게시 상태 안내는 업데이트 또는 앱이 정책이나 배포 계약에 맞지 않는다고 판정된 경우, 문제를 수정해 재제출하거나 이의제기를 낼 수 있다고 설명합니다. 정책 상태 안내는 정책 위반을 고치기 전에는 거절되거나 삭제된 앱을 다시 게시하지 말라고 명시합니다. 따라서 ‘일단 다시 올리기’ 전에 안내에서 지목한 제출 범위와 수정 대상이 실제로 연결되는지 먼저 대조해야 합니다.

Apple은 앱의 개념·기능을 오해했거나 부당하게 처리됐다고 판단하는 경우 App Review Board에 이의제기를 선택할 수 있다고 안내합니다. 이때 제출 단위당 한 번의 이의제기를 내고, 구체적으로 어떤 이유로 가이드라인을 충족한다고 보는지 제시하며, 추가 정보 요청이 있으면 먼저 응답하라고 설명합니다. 이는 모든 거절에 이의제기가 적합하다는 뜻이 아닙니다. 팀이 실제 문제를 수정할지, 이미 제출한 내용이 오해됐다고 보는지 분리하여 기록할 이유입니다.

외주 개발 중이라면 특히 “수정”이 코드 변경만 뜻하는지도 확인해야 합니다. 스토어 설명, 스크린샷, 로그인 접근 안내, 콘텐츠 선언처럼 앱 번들 밖의 제출 항목도 있을 수 있습니다. 기존 앱 MVP 스토어 등록 전 점검에서 설명·스크린샷·지원 정보의 일치를 먼저 보되, 거절 뒤에는 당시 제출본과 다음 제출본을 혼동하지 않도록 별도 기록을 만드세요.

우리 앱 MVP 출시 기록 범위 정리하기

심사 거절 뒤 남길 5가지 기록

이 표는 Apple이나 Google이 요구하는 양식이 아니며, 법률·플랫폼 정책의 해석도 아닙니다. 외주 계약, 서비스의 데이터 처리 범위, 실제 앱 기능에 따라 필요한 칸은 늘거나 줄 수 있습니다. 핵심은 구두로 “고쳤다”라고 끝내지 않고, 어느 제출의 어떤 안내에 대해 무엇을 확인했는지를 되짚을 수 있게 만드는 것입니다.

1. 제출 식별과 현재 상태를 먼저 고정하세요

Google Play에서는 앱·업데이트·항목 상태가 각각 보일 수 있고, ‘App rejected’는 처음 공개를 시도하는 초안 앱에 적용되는 구분이라고 안내합니다. 반면 이미 공개된 앱의 업데이트가 거절된 경우에는 이전에 성공적으로 게시된 버전이 계속 이용 가능할 수 있습니다. 이 차이를 추측하지 말고 해당 앱의 Play Console 상태를 직접 읽어 기록하세요. 상태 이름만 복사하기보다, 어떤 빌드·변경 묶음인지와 확인 시각을 함께 남겨야 다음 담당자가 같은 화면을 다시 볼 수 있습니다.

Apple에서도 제출의 현재 상태와 통과하지 못한 항목을 App Store Connect에서 확인할 수 있습니다. 외주사가 알려 준 빌드 번호, 내부 QA가 본 빌드, 심사에 들어간 제출이 서로 다를 수 있으므로, 코드 저장소의 변경과 스토어 제출을 같은 것으로 가정하지 않는 편이 안전합니다. 배포 전에 바뀐 내용을 고정하는 방법은 앱 MVP 업데이트 노트 기록과 함께 볼 수 있습니다.

2. 안내문을 ‘할 일’이 아니라 근거로 보관하세요

안내문에서 언급된 정책·가이드라인, 문제 위치, 추가 자료 요청은 다음 결정을 판단하는 출발점입니다. Apple은 통과하지 못한 제출의 세부 정보와 특정 App Review Guidelines 정보를 확인할 수 있고, App Review와 서신으로 문제를 해결한 뒤 빌드를 재제출할 수 있다고 안내합니다. Google은 정책 상태에서 활성 조치와 이용 가능한 추가 정보를 확인하도록 안내합니다.

따라서 내부 기록에는 이메일 전문을 무단으로 넓게 공유하기보다, 원문 보관 위치, 안내가 가리킨 항목, 읽은 담당자, 확인이 필요한 질문을 적습니다. ‘정책 위반’이라는 요약만 남기면 기능·메타데이터·로그인 안내·콘텐츠 선언 중 어디를 다시 봐야 하는지 사라집니다. 법률 판단이나 정책 해석이 필요하면 공식 안내만으로 결론 내리지 말고 필요한 전문가에게 검토를 요청하세요.

3. 수정은 변경 목록과 다시 확인한 흐름을 짝지으세요

수정하기로 했다면, 실제 변경과 검증을 한 칸에 붙입니다. 예를 들어 로그인 때문에 심사가 막혔다고 판단했다면 테스트 계정 값 자체를 문서에 남기지 말고, 심사자가 필요한 경로에 접근할 수 있도록 안내가 준비됐는지와 해당 흐름을 누구가 어떤 빌드에서 확인했는지 기록합니다. 기능 오류라면 재현 조건, 수정한 범위, 수정 뒤 같은 흐름의 관찰 결과를 분리합니다.

Google은 거절 후 문제를 고친 뒤 재제출할 수 있다고 안내하지만, 이는 변경이 실제 요구 사항을 모두 충족한다는 보장은 아닙니다. 그래서 재제출 체크에는 ‘수정 완료’뿐 아니라 미확인 항목과 다음 확인자를 남겨 두는 편이 좋습니다. 사용자 제보나 QA 내용을 재현 가능한 카드로 만드는 방법은 앱 MVP 베타테스트 피드백 기록에서도 이어 확인할 수 있습니다.

4. 이의제기는 ‘오해 가능성’과 제출 근거를 분리해 검토하세요

이의제기는 단순히 일정이 급하거나 수정 비용이 크다는 이유를 적는 자리가 아닙니다. Apple의 안내는 앱 개념·기능에 대한 오해 또는 부당한 처리가 있었다고 보는 경우에 이의제기를 선택할 수 있으며, 가이드라인을 충족한다고 보는 구체적 이유를 제시하도록 합니다. Google도 정책 조치가 오류라고 판단하면 안내된 절차 또는 정책 상태의 Appeal을 통해 이의를 제기할 수 있다고 안내합니다.

따라서 결정 기록에는 실제 화면·동작·제출 설명 중 무엇이 심사 관점에서 다르게 읽혔을 수 있는지, 그 설명을 뒷받침할 공개 가능한 자료가 무엇인지, 추가 정보 요청에 답했는지를 나누어 적습니다. 사실관계가 아직 불명확하면 이의제기 여부를 확정으로 표시하지 말고 ‘추가 확인 필요’로 남기세요. 플랫폼별 제출 기한이나 처리 시간은 이 글에서 정하지 않으며, 해당 시점의 공식 안내와 콘솔 화면을 다시 확인해야 합니다.

5. 다음 제출은 담당자·권한·결과까지 기록하세요

외주 앱 MVP에서는 누가 코드를 수정했는지와 누가 스토어에 제출할 권한이 있는지가 다를 수 있습니다. 제출 전에 변경 대상, 검토 결과, 예외와 다음 책임을 정리하는 코드 병합 기준을 연결하면 개발 기록과 스토어 제출 기록이 분리되는 일을 줄일 수 있습니다. 실제 플랫폼 계정의 역할이나 비공개 접근 정보는 문서에 쓰지 말고, 회사의 승인된 절차와 책임자만 남기세요.

재제출 또는 이의제기를 보낸 뒤에는 ‘완료’로 닫지 말고, 제출한 항목, 제출 시각, 콘솔에서 확인할 다음 상태, 확인 담당자를 기록합니다. 심사 결과는 개별 앱과 플랫폼의 당시 판단에 따라 달라질 수 있습니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 앱 심사 통과·복구·일정·사업 성과를 보장하지 않습니다.

우리 앱 MVP 출시 기록 범위 정리하기

자주 묻는 질문

Google Play에서 업데이트가 거절되면 기존 앱도 바로 사라지나요?

항상 그렇다고 볼 수는 없습니다. Google의 정책 상태 안내는 앱이 거절된 경우 마지막으로 성공적으로 게시된 버전이 계속 Google Play에서 이용 가능하다고 설명합니다. 다만 실제 상태는 해당 앱의 Play Console에서 직접 확인해야 합니다.

심사 거절을 받으면 수정 대신 바로 이의제기를 해야 하나요?

아닙니다. 수정이 필요한지, 앱의 개념·기능이 오해됐다고 보는지, 추가 정보 요청이 남았는지에 따라 판단이 달라집니다. Apple과 Google의 해당 안내, 현재 콘솔 상태, 실제 제출 내용을 함께 확인하세요.

이의제기에는 무엇을 적어야 하나요?

Apple은 가이드라인을 충족한다고 보는 구체적 이유를 제시하고, 제출당 한 번의 이의제기를 내며, 추가 정보 요청에 먼저 답하라고 안내합니다. 실제 제출 화면과 당시 공식 절차를 다시 확인해 필요한 사실만 정리하세요.

외주사가 수정했다고 하면 바로 재제출해도 되나요?

수정 범위와 확인 결과, 제출 대상 빌드·메타데이터, 다음 제출 책임자를 분리해 확인하는 편이 좋습니다. 수정 사실만으로 해당 심사 안내가 해결됐거나 다음 심사가 통과된다고 단정할 수는 없습니다.

공식 출처

• Apple Developer · App Review

• Google Play Console Help · Publish your app

• Google Play Console Help · Check your app’s policy status