앱스토어 심사 거절, 왜 출시 직전에 반복되는가 — 발주 단계에서 막아야 할 6가지 리젝 사유

앱스토어 심사 거절 통보는 대부분 가장 나쁜 타이밍에 도착합니다. 개발사로부터 “개발 완료” 보고를 받고, 출시일을 확정하고, 보도자료와 광고 집행 일정까지 잡아 둔 상태에서 애플이나 구글의 거절 메일이 오는 것입니다. 개발사에 문의하면 돌아오는 답은 대개 한 문장입니다. “수정해서 재제출하겠습니다.” 언제까지, 무엇을, 왜 고치는지에 대한 설명은 없습니다. 그 사이 마케팅 일정은 그대로 흘러가고, 출시가 몇 주씩 밀리는 일은 이 업계에서 전혀 드물지 않습니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하며 98%의 고객 만족도를 유지해 왔습니다. 그 과정에서 반복적으로 확인한 패턴이 하나 있습니다. 심사 단계에서 일정이 무너지는 프로젝트에는 공통점이 있다는 것입니다. 스토어 심사 대응을 “누가 책임지는지”가 계약 어디에도 명시되어 있지 않다는 점입니다.

심사 거절이 반복되는 진짜 이유

앱스토어 심사 거절은 운이 나빠서 생기는 사고가 아닙니다. 애플과 구글의 심사 가이드라인은 공개되어 있고, 거절 사유의 대부분은 심사 기준을 아는 사람이라면 제출 전에 예측할 수 있는 것들입니다. 그런데도 거절이 반복되는 이유는 기술 문제가 아니라 구조 문제입니다.

발주사 입장에서 “개발 완료”와 “출시 완료”는 같은 말처럼 들립니다. 그러나 계약서상 두 지점 사이에는 공백이 있는 경우가 많습니다. 개발사는 기능 구현까지를 자신의 범위로 보고, 스토어 제출은 형식적인 마지막 절차로 취급합니다. 발주사는 심사 기준을 모르기 때문에 확인할 방법이 없습니다. 결과적으로 권한 설계, 결제 구조, 심사용 계정 준비, 완성도 기준 같은 심사 통과의 핵심 요건을 아무도 소유하지 않은 채 제출 버튼이 눌립니다.

내부에 개발 조직이 없는 기업이 앱 개발 외주를 맡길 때 이 공백은 더 커집니다. 개발사가 보내온 결과물이 심사 기준을 충족하는지 발주사가 스스로 검증할 수 없기 때문입니다. 이것이 핵심입니다. 심사 거절은 제출하는 순간에 발생하지만, 그 원인은 몇 주 혹은 몇 달 전 개발 단계의 의사결정에서 이미 만들어져 있습니다.

가장 자주 걸리는 6가지 리젝 사유

아래 여섯 가지는 애플과 구글이 공개한 심사 가이드라인에서 반복적으로 문제가 되는 대표 유형입니다. 주목할 점은 여섯 가지 모두 제출 시점이 아니라 개발 초기의 결정에서 비롯된다는 사실입니다.

1. 완성도 미달

크래시, 명백한 버그, “준비 중입니다” 같은 플레이스홀더 콘텐츠가 남아 있는 앱은 애플 가이드라인 2.1이 요구하는 최소 완성도에 미달해 거절됩니다. 이것은 마지막 주에 테스트를 며칠 더 한다고 해결되는 문제가 아닙니다. 프로젝트 초기에 “어느 수준을 완성으로 볼 것인가”라는 QA 기준을 합의하지 않았기 때문에 생기는 문제입니다. 완성 기준이 문서화되어 있지 않으면 개발사의 “다 됐습니다”와 심사자의 판단은 다를 수밖에 없습니다.

2. 권한·개인정보 처리 미비

카메라, 위치, 연락처 같은 권한을 요청하면서 그 목적을 사용자에게 설명하지 않거나, 개인정보처리방침 URL이 누락된 경우입니다. 권한을 어디에 쓸지, 방침 문서를 누가 작성해 어디에 게시할지는 요구사항 정의 단계에서 결정되어야 할 항목입니다. 개발이 끝난 뒤에 “방침 페이지가 필요하다더라”는 사실을 처음 알게 되는 구조라면, 이미 설계 단계에서 심사 요건이 빠져 있었다는 뜻입니다.

3. 결제 정책 위반

디지털 콘텐츠나 구독처럼 인앱결제(IAP) 대상인 기능을 외부 결제 링크로 연결하면 거절됩니다. 결제 구조는 수수료와 직결되기 때문에 개발사가 임의로 정할 수 없고, 발주사가 사업 모델 차원에서 판단해야 하는 사안입니다. 이 논의가 개발 착수 전에 이루어지지 않으면, 결제 모듈을 다 만들어 놓고 심사 단계에서 구조를 통째로 바꾸는 최악의 재작업이 발생합니다.

4. 메타데이터 불일치

스토어에 올린 스크린샷과 설명이 실제 앱 기능과 다르면 거절 사유가 됩니다. 흔한 원인은 단순합니다. 개발 도중 기능이 바뀌었는데 스토어 등록 자료는 초기 기획서 기준으로 만들어지는 것입니다. 개발 산출물과 스토어 자산을 한 사람이 함께 관리하지 않으면, 두 문서는 시간이 지날수록 반드시 어긋납니다.

5. 심사용 데모 계정 미제공

로그인이 필요한 앱인데 심사자가 쓸 수 있는 데모 계정을 제공하지 않으면, 심사자는 핵심 기능을 확인할 수 없어 그대로 거절합니다. 기술적으로는 사소해 보이지만 실제로 매우 자주 발생하는 유형입니다. 심사자용 계정과 테스트 데이터를 누가 준비하는지가 업무 분장에 없기 때문입니다. 개발사는 발주사 일이라 생각하고, 발주사는 그런 것이 필요한지조차 모릅니다.

6. 최소 기능성 미달

기존 웹사이트를 웹뷰로 감싼 수준의 앱은 “앱으로서의 고유한 가치가 없다”는 이유로 거절됩니다. 이것은 코딩 품질의 문제가 아니라 기획 단계의 문제입니다. 웹뷰 중심으로 갈지, 네이티브로 갈지, 아니면 크로스플랫폼 앱 개발 방식으로 양쪽 스토어를 함께 노릴지는 착수 전에 심사 기준까지 고려해 결정해야 합니다. 견적을 낮추기 위해 웹뷰를 선택해 놓고 심사에서 막히면, 절감했다고 믿었던 비용은 재개발 비용으로 돌아옵니다.

여섯 가지의 공통점이 보이실 것입니다. 어느 것도 제출 직전의 체크리스트로 막을 수 없습니다. 전부 요구사항 정의와 설계 단계에서 결정되는 사안이고, 내부 개발 조직이 없는 발주사가 스스로 감시할 수 있는 영역이 아닙니다.

어느 나라가 아니라 어떤 구조에 발주할 것인가

그렇다면 발주사가 실제로 선택할 수 있는 것은 무엇일까요. 개발사를 더 다그치는 것도, 심사 가이드라인을 직접 공부하는 것도 근본 해법이 아닙니다. 선택지는 발주 구조입니다. 앱 개발 기간과 비용만 놓고 국내와 해외를 비교하는 경우가 많지만, 실제 차이를 만드는 것은 “개발 완료에서 출시 완료까지의 공백을 누가 소유하는가”입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
스토어 심사 대응	개발사 (계약 범위에 따라 다름)	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

국내 개발사는 언어 장벽이 없지만 단가가 높고, 심사 대응이 계약 범위에 들어 있는지는 회사마다 다릅니다. 해외 직접 발주는 단가는 낮지만 요구사항 정의부터 심사 대응까지 전부 발주사 담당자가 영어로 직접 감당해야 하므로, 내부 전문 인력이 없다면 절감분이 담당자 인건비와 재작업 비용으로 사라집니다. 세 번째 구조는 글로벌 개발팀의 단가를 취하되, 요구사항 정의와 심사 대응이라는 두 개의 공백을 한국 PM이라는 단일 책임자에게 귀속시키는 방식입니다.

디비컨설팅은 심사 리스크를 이렇게 통제합니다

디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 IT 아웃소싱 구조로 프로젝트를 수행합니다. 발주사는 처음부터 끝까지 한국인 PM과 한국어로만 소통하며, 심사 대응은 별도 옵션이 아니라 5단계 프로세스 안에 포함되어 있습니다.

1단계 — 상담 및 요구 분석. 요구사항을 한국어로 문서화합니다. 이 단계에서 권한 설계, 결제 구조, 심사용 계정 준비, 개인정보처리방침 같은 스토어 심사 요건이 함께 정의됩니다. 앞서 본 여섯 가지 리젝 사유가 발생하는 지점이 바로 여기이므로, 여기서 문서로 못 박으면 재작업의 대부분이 사라집니다. 첫 발주라면 MVP 개발 범위를 이 단계에서 함께 좁혀 심사 리스크와 예산을 동시에 통제합니다.

2단계 — 개발팀 구성. 50개 이상의 글로벌 파트너사 네트워크에서 프로젝트에 맞는 전담팀을 2~4주 내에 구성합니다.

3단계 — 프로젝트 개발. 애자일 방식으로 진행하며, 진행 상황을 투명하게 공유합니다. 개발 중 기능이 바뀌면 PM이 스토어 등록 자료와의 정합성까지 함께 관리합니다.

4단계 — 테스트 및 배포. QA를 거쳐 출시하며, 스토어 제출 대응이 이 단계의 정식 업무입니다. 심사에서 거절이 나오면 PM이 거절 사유를 분석하고 수정과 재제출을 관리합니다. “수정해서 재제출하겠다”는 통보가 아니라, 무엇을 왜 고치고 언제 다시 제출하는지가 발주사에게 한국어로 보고됩니다.

5단계 — 운영 및 유지보수. 출시 후 문서와 함께 인계하며, 운영 단계의 지원 범위와 앱 유지보수 비용을 항목별로 명확히 구분해 제시합니다.

이 구조로 국내 채용 대비 평균 40~60%의 비용 절감을 유지하면서도, 심사 대응의 책임 소재가 계약과 프로세스에 명시됩니다.

실제 앱 구축 사례

아래는 디비컨설팅이 구축에 참여해 스토어에 실제로 출시되어 운영 중인 서비스들입니다.

• 삼성물산 홈닉 — 입주민을 위한 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스
• 교보생명 글펍 — 사내벤처로 출발한 커뮤니티 서비스
• 직방 호갱노노 — 부동산 데이터 서비스

이런 기업에 적합합니다 — 그리고 권하지 않는 경우

적합한 경우

• 내부 개발 조직이 없는데 앱 출시 일정이 사업 일정과 묶여 있는 기업
• 첫 앱 발주라 스토어 심사 절차 자체를 모르는 기업
• 이미 앱스토어 심사 거절을 겪었는데 개발사가 대응을 미루고 있는 기업

권하지 않는 경우

• 내부에 iOS/Android 출시 경험이 있는 개발팀이 이미 있는 기업 — 심사 대응을 자체 소화할 수 있으므로 이 구조의 이점이 크지 않습니다.
• 스토어 출시가 아니라 사내 배포용 앱만 필요한 기업 — 심사 자체가 없으므로 더 저렴한 다른 선택지가 있습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임이며, 글로벌 개발팀과의 커뮤니케이션은 발주사 업무 범위에 들어오지 않습니다.

심사에서 거절되면 재심사 대응은 누가 하나요?

재심사 대응은 테스트·배포 단계의 일부로 프로세스에 포함되어 있습니다. 앱스토어 심사 거절이 발생하면 PM이 거절 사유를 분석하고, 수정 범위와 재제출 일정을 관리해 발주사에 보고합니다.

기획서가 없는데 견적이 가능한가요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 희망 일정과 예산 범위만 정리되어 있으면 개략 견적을 산출할 수 있습니다. 상세 요구사항 문서화는 1단계에서 함께 진행합니다.

비용은 어떻게 산정되나요?

투입 인력의 등급별 단가에 투입 기간을 곱해 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 비용이 쓰이는지 명확히 확인하실 수 있습니다.

소스코드와 스토어 계정 소유권은 누구에게 있나요?

소스코드는 발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계하며, 스토어 개발자 계정도 발주사 명의로 개설하는 것을 권장합니다. 개발사가 바뀌어도 서비스 운영이 끊기지 않는 구조를 만들기 위해서입니다.

정리

앱스토어 심사 거절은 제출 버튼을 누르는 순간이 아니라 발주 구조를 정하는 순간에 이미 결정됩니다. 권한 설계, 결제 구조, 심사용 계정, 완성도 기준은 전부 개발 초기의 의사결정이고, 내부 개발 조직이 없는 기업이 이를 스스로 감시할 방법은 없습니다. 따라서 물어야 할 질문은 “심사에 통과할 수 있는 개발사인가”가 아니라 “요구사항 정의부터 재심사 대응까지, 출시 완료를 계약과 프로세스로 책임지는 구조인가”입니다. 심사 대응까지 책임지는 구조로 발주하는 것이 출시 일정을 지키는 가장 확실한 방법입니다.