스타트업을 위한 모바일 앱 체크리스트: MVP부터 앱 스토어 승인까지 34개 항목 (2026)

스타트업을 위한 모바일 앱 체크리스트: MVP부터 앱 스토어 승인까지 34개 항목 (2026)

Apple App Store Review Guideline 5.1.1(v)는 저희가 지금까지 배포한 그 어떤 버그보다 더 많은 스타트업 출시일을 무산시켰습니다. 계정 삭제 버튼 하나가 빠진 채로 데모 데이 전날 밤에 제출하면 전체 일정이 일주일씩 밀려납니다. 이 스타트업 모바일 앱 체크리스트가 존재하는 이유는, 그 실수가 완전히 피할 수 있는 종류이기 때문입니다. 그런데도 원인이 된 guideline 번호를 메모해 두는 사람은 거의 없습니다.

핵심 요약:

• Apple은 계정 삭제 플로우와 개인정보 처리방침 링크 누락을 이유로 앱을 리젝합니다. Guideline 5.1.1과 1.5가 정확히 그 항목을 지목합니다.
• Google Play는 인앱 계정 삭제 경로와 공개 웹 계정 삭제 경로 두 가지를 모두 요구하며, 2024년 5월 31일 연장 기한 이후 본격적으로 시행 중입니다.
• iOS와 Android 제출 체크리스트는 다릅니다. 두 가지를 하나의 통합 리스트로 다루는 것이 막판 출시 지연의 1순위 원인입니다.

코드 한 줄 쓰기 전에

첫 화면 디자인에 들어가기 전에 세 가지를 확정해야 합니다. MVP가 실제로 무엇인지, 개인정보 처리방침이 필요한지(필요합니다), 그리고 GDPR이나 터키의 KVKK 중 어떤 것이 사용자에 적용되는지입니다. 이 단계를 건너뛰면 파운더는 제출하려던 바로 그 주에 법적 페이지를 급하게 쓰게 됩니다.

MVP를 한 문장으로 정의하면, 핵심 가설을 실사용자로 검증하는 제품의 최소 버전입니다. 전체 비전을 축약한 버전이 아닙니다. 범위가 아직 흐릿하다면, 코드 한 줄 쓰기 전에 빌드 범위를 제대로 설정하는 방법을 읽어보세요. 빌드 중간에 기능을 잘라내는 대신, 시작 전에 잘라내게 해줍니다.

개인정보 처리방침 요건에 대해 Apple의 guideline은 직설적입니다. **Guideline 5.1.1(i)**는 앱이 App Store Connect 메타데이터에, 그리고 많은 경우 앱 내부에도 "개인정보 처리방침 링크를 포함해야 한다(must include a link to their privacy policy)"고 명시합니다. 권고가 아닙니다. 없으면 제출 자체가 막히는 항목입니다.

• MVP 범위를 한 문장으로 정의
• 개인정보 처리방침이 필요한지 확인 (거의 항상 필요합니다)
• Support URL 초안 작성 (Apple Guideline 1.5에서 요구)
• EU 또는 터키 사용자가 있다면 GDPR/KVKK 적용 여부 확인
• 네이티브 vs. 크로스 플랫폼 스택 결정

MVP 빌드 위크

MVP 빌드 위크는 실제로 무엇을 출시하고 무엇을 잘라낼지 결정하는 자리입니다. 솔직한 답은 이렇습니다. 파운더의 예상보다 훨씬 많이 잘라냅니다. 분석 도구와 crash reporting은 빌드 후에 넣는 것이 아니라 빌드 중에 넣습니다. 출시 후에 끼워 넣으면 첫 번째 가설을 검증하는 데 꼭 필요한 데이터를 그대로 잃게 됩니다.

저희가 v1 범위에서 실제로 잘라내는 것은, 대개, 테스트 중인 그 한 가지와 무관한 모든 것입니다. 푸시 알림, 소셜 로그인, 토글 여섯 개 달린 설정 화면, 전부 기다릴 수 있습니다. 파운더는 당연히 이를 꺼립니다. 미완성 제품을 내놓는 기분이니까요. 사실 미완성입니다. 그게 핵심입니다.

앱을 여러 번 출시해 본 한 파운더는 dev.to 체크리스트 글에서, 초기에 피드백 메커니즘을 생략한 것을 "매번 후회했다"고 썼습니다. 지금 집어넣으세요. 첫 리뷰가 달린 뒤가 아니라요. 스코핑 논의 자체를 빠르게 진행하고 싶다면, 빌드 시작 전에 AI로 스코핑을 빠르게 진행하는 방법도 볼 가치가 있습니다.

• 첫 TestFlight/사내 빌드 전에 분석 도구 계측
• Crash reporting 연동 (Sentry 또는 Firebase Crashlytics)
• 앱 안에 피드백 메커니즘 구축
• 테스트 중인 핵심과 무관한 기능은 모두 삭제
• 첫 버전 문자열 작성 (아래 버전 관리 참고)

제출 일주일 전

경쟁사 체크리스트들이 통째로 건너뛰는 단계가 바로 여기이고, 가장 예방 가능한 지연이 일어나는 곳도 여기입니다. 앱의 **시맨틱 버저닝(semantic versioning)**은 MAJOR.MINOR.BUILD 패턴을 따릅니다 (1.0.0, 패치는 1.0.1, 기능 추가는 1.1.0). 지금 체계를 정하세요. 일관성 없는 버전 번호는 앱 스토어와 팀 모두를 혼란스럽게 만듭니다.

단계적 rollout은 업데이트를 먼저 소규모 사용자 비율(보통 1%, 그다음 10%, 그다음 50%)에 배포한 뒤 전체로 확대하는 방식입니다. 저희가 검토한 세 개의 경쟁사 체크리스트 중 이를 언급한 것은 하나뿐이었고, 그마저도 스치듯 지나갔습니다. 크래시가 빠져나가도 단계적 rollout은 피해 반경을 제한해 줍니다. 사용자 100%가 한꺼번에 맞는 대신에요.

저희가 클라이언트 제출을 승인하기 전에 던지는 질문은 간단합니다. 핵심 경로가 지금 이 순간 실기기에서 끝까지 동작하는가? 시뮬레이터가 아니라요. Crash-free rate이 허용 가능한가? 스토어 리스팅 에셋이 플레이스홀더가 아니라 실제로 최종본인가?

• 버전 번호가 일관된 체계를 따르는지 확인
• 핵심 경로를 실기기에서 한 번 더 끝까지 테스트
• 스토어가 지원하면 단계적 rollout 비율 준비
• 제출 전 crash-free rate이 허용 범위인지 확인
• 스토어 리스팅 에셋 전체를 스크린샷으로 준비

제출 당일: iOS vs. Android

iOS와 Android 제출은 서로 다른 이유로 실패합니다. 그리고 두 가지를 하나의 통합 체크리스트로 다루는 것이, 저희가 보는 막판 출시 지연의 단일 최대 원인입니다. Apple App Store Review Guidelines와 Google Play 개발자 정책은 각각 구체적으로 확인 가능한 요건을 명시하고 있는데, 대부분의 파운더는 리젝 이메일을 받고 나서야 이를 알게 됩니다.

저희의 실제 앱 제출 경험에서, 처음 제출하는 파운더를 가장 자주 걸려 넘어지게 하는 두 가지는 계정 삭제 요건과 접속되지 않는 Support URL입니다. 둘 다 제출 전에 발견하면 한 줄이면 고칩니다. 발견하지 못하면 둘 다 자동 리젝입니다.

Apple의 App Store Review Guidelines는 구체적입니다. **Guideline 5.1.1(v)**는 계정 생성을 지원하는 앱에 인앱 계정 삭제도 제공하도록 요구합니다. Guideline 1.6은 Data Security 공개 항목을 다루고, Guideline 1.5는 동작하는 Support URL을 요구합니다. Android에서는 Google Play 개발자 정책이 인앱 삭제 경로와 계정 삭제 요청용 공개 웹 URL 두 가지를 모두 요구합니다. Google은 2023년 4월에 이 요건을 발표했고, Data safety form의 데이터 삭제 질문에는 2023년 12월 7일 기한을 정했으며, 2024년 5월 31일까지 연장을 허용했고, 그 이후에는 미준수 앱이 제재를 받습니다. 작은 앱은 예외로 남은 구식 규정이 아닙니다. 지금도 적용됩니다.

두 제출 플로우는 문서상으로만 다른 것이 아니라 기계적으로도 갈라집니다. iOS에서는 Xcode나 Transporter로 빌드를 업로드하고, App Store Connect가 이를 처리하며 (몇 분에서 한 시간 이상 걸립니다), 그다음 TestFlight로 내부/외부 테스터에게 보내거나 바로 App Review에 제출합니다. TestFlight는 선택적 잡일이 아닙니다. 리뷰어가 리젝할 버그를 미리 잡아내는, Apple이 기대하는 방식입니다. Android에서는 Google Play Console이 단일 제출 대신 트랙으로 작동합니다. 내부 테스트, 그다음 비공개 또는 공개 테스트, 그다음 프로덕션 순으로 이동하며, 각 트랙에는 자체 대상자와 자체 승격 단계가 있습니다. 단계적 rollout은 기존 프로덕션 릴리스를 업데이트할 때만 나타납니다. Google의 자체 릴리스 문서가 말하듯, "첫 릴리스를 배포하는 경우에는 rollout 비율 선택 옵션이 표시되지 않습니다." 그러니 첫 출시를 비율 램프 중심으로 계획하지 마세요. 그건 나중 일입니다.

실제로 처음 제출을 막는 것은 코드가 아니라 서류입니다. Apple은 자주 쓰이는 서드파티 SDK 목록(광고 네트워크, 분석, crash reporter)에 대해 privacy manifest를 요구하며, 책임 소재에 대한 Apple의 안내는 직설적입니다. Apple의 서드파티 SDK 요건 페이지에 따르면, "앱에 서드파티 SDK를 사용하면 SDK가 앱에 포함하는 모든 코드에 대해 여러분이 책임지며, 해당 SDK의 데이터 수집 및 사용 관행을 파악하고 있어야 합니다." 목록에 있는 SDK의 manifest를 빠뜨리면 빌드는 App Store Connect를 통과하지 못합니다. Google Play의 대응되는 서류 관문은 Data safety form이며, 내부 테스트 전용 빌드를 제외한 모든 트랙의 모든 앱에 필수입니다. Google Play Data safety 문서에 따르면, "Google Play에 앱을 게시한 모든 개발자는 비공개, 공개, 프로덕션 테스트 트랙의 앱을 포함하여 Data safety form을 작성해야 합니다." 잘못 작성하면 Google은 선언한 내용과 실제 앱 동작 사이의 불일치가 드러나는 경우 "제재 조치를 포함해 적절한 조치를 취할 수 있다"고 분명히 말합니다.

정책 문구와 무관한 세 번째 실패 모드도 있습니다. 리뷰어가 말 그대로 앱을 테스트할 수 없는 경우입니다. Apple Guideline 2.1은 이를 직접 명시합니다. "앱에 로그인이 포함되어 있다면 데모 계정 정보를 포함하고 (백엔드 서비스도 켜 두세요!)" 동작하는 데모 자격 증명이 없거나, 심사 기간에 백엔드가 내려가 있거나, Support URL이 접속되지 않으면, 계정 삭제 플로우가 아무리 완벽해도 리젝입니다. 앱의 일부가 페이월이나 로그인 뒤에 있다면, 리뷰어가 거기에 도달하는 방법을 정확히 설명하는 리뷰어 노트를 작성하세요. 2분이면 되는 단계인데, 처음 제출하는 파운더가 끊임없이 건너뜁니다.

같은 대화에 넣어야 할 Android 전용 관문이 하나 더 있습니다. target API level입니다. Android 자체 개발자 문서는 "새 앱과 앱 업데이트는 Google Play에 제출하려면" 현재 요구되는 Android API level을 "target으로 해야 한다"고 명시하며, "최신 버전의 Android가 탑재된 기기의 신규 사용자에게는 오래된 앱을 제공할 수 없다"고도 합니다. 계정 삭제나 Data Safety와 무관하지만, 제출을 막는 것은 마찬가지로 단호합니다. 게다가 매년 바뀌는 종류의 요건이므로, 릴리스를 빌드하기 전에 현재 숫자를 확인하세요.

이 검색어에서 상위 랭킹된 체크리스트 중 App Store guideline 번호를 하나라도 인용한 글은 0개입니다. 저희는 인용합니다. compliance를 추측으로 판단하는 방식으로 출시가 한 번에 일주일씩 밀리기 때문입니다. 더 넓은 데이터 처리 체계를 갖추고 있다면, 출시 전 데이터 처리 체크리스트가 여기서 중복하지 않는 보안 측면을 다룹니다.

iOS 제출 체크리스트:

• 개인정보 처리방침 URL이 라이브 상태이고 접속 가능
• 인앱 계정 삭제 경로 배포 완료 (Guideline 5.1.1(v))
• Support URL 라이브 상태 (Guideline 1.5)
• Data Security 공개 항목 작성 완료 (Guideline 1.6)
• 공개 제출 전 TestFlight 빌드 승인 완료

Android 제출 체크리스트:

• Play Console에서 Data Safety form 작성 완료
• 인앱 계정 삭제 경로 배포 완료
• 계정 삭제 요청용 공개 웹 URL 라이브 상태 (Google Play 요건)
• 단계적 rollout 비율 설정
• Target API level이 현재 Play 요건을 충족

출시일

출시일은 앱이 실제로 실사용자에게 공개되는 날입니다. 며칠 또는 몇 주 먼저 일어날 수 있는 제출과는 별개이고, 그 여파인 1주차와도 별개입니다. 첫날의 단계적 rollout 모니터링이 확대를 계속할지, 일시 중지할지를 알려줍니다.

첫 24시간 동안은 App Store Connect나 Play Console 대시보드를 매일이 아니라 매시간 확인하세요. Crash-free rate이 떨어지면, 사용자 100명이 같은 버그에 더 부딪힌 다음 날 아침이 아니라 그 시간 안에 알아야 합니다. 롤백 빌드를 대기시켜 두세요. AI 기능에 적용하는 안정화-배포 원칙이 여기에도 그대로 적용됩니다.

• 첫 24시간 동안 crash-free rate을 매시간 모니터링
• 지원 채널에 담당자를 배치하고 대기
• 단계적 rollout이 계획대로 확대되는지 확인
• 심각한 버그에 대비해 롤백 빌드 대기

출시 후 첫 일주일

출시 후 첫 일주일에 실제 작업의 대부분이 일어납니다. 그런데 거의 아무도 이 부분을 계획하지 않습니다. 매일 crash report 검토와 첫 스토어 리뷰에 응답하는 일은 출시일 당일에 한 어떤 일보다 중요합니다.

한 파운더는 자신의 출시 후 체크리스트 글에서 이렇게 썼습니다. "출시 자체는 생각보다 덜 중요합니다. 중요한 것은 그 후 몇 주 동안 무엇을 하느냐입니다." 이것이 첫 일주일의 솔직한 버전입니다. 빠르게 패치하고, 직접 응답하고, 실제 사용자가 대신 테스트하기 전에 데이터 삭제 플로우가 동작하는지 실제로 확인하세요. 이제 이 모든 것을 만들고 유지하는 데 비용이 얼마나 드는지 궁금하다면, 출시 후 유지보수 및 업데이트 예산 짜기가 짝이 되는 글입니다. 이 글은 준비 상태를 다루고, 그 글은 청구서를 다룹니다.

• 첫 일주일 동안 매일 crash report 검토
• 첫 10개 스토어 리뷰에 직접 응답
• 심각한 버그는 48시간 안에 분류하고 패치
• 데이터 삭제 요청 프로세스가 실제로 끝까지 동작하는지 확인
• 원래 MVP 가설과 분석 데이터를 대조하는 주기 설정

Techsy의 접근 방식

저희는 모든 클라이언트 빌드에서 제출 전 리뷰를 같은 방식으로 진행합니다. 제출을 승인하기 전에, 핵심 경로가 실기기에서 동작하는지, crash-free rate이 유지되는지, guideline이 요구하는 모든 플로우(계정 삭제, 개인정보 처리방침, Support URL)가 실제로 기능하는지를 묻습니다. 목업에 존재하기만 하는지가 아니라요. 짧은 리스트지만, 앱이 첫 시도에서 심사를 통과하는지를 결정하는 리스트가 바로 이것입니다.

이 guideline들을 이미 헤쳐본 사람이 제출을 맡아주길 원한다면, 저희 모바일 앱 개발 프로세스는 정확히 이 제출 전 리뷰 단계를 중심으로 설계되어 있습니다. 여러분이 스스로 해야 할 숙제를 대체하는 것이 아니라, 여러분이 숙제를 마친 뒤에 저희가 하는 일입니다.

자주 묻는 질문 (FAQ)

MVP란 무엇이며, 출시 체크리스트에서 왜 중요한가요?

MVP는 하나의 핵심 가설을 실사용자로 검증하는 제품의 최소 버전입니다. 여기서 중요한 이유는, 이 체크리스트의 모든 항목이 범위와 함께 커지기 때문입니다. MVP가 타이트할수록 제출 시점에 잘못될 수 있는 것이 줄어들고, 첫 일주일에 계측하고 모니터링하고 패치할 기능도 줄어듭니다.

앱이 App Store에서 리젝당하는 이유는 무엇인가요?

가장 흔하고 예방 가능한 이유는 개인정보 처리방침 링크 누락(Guideline 5.1.1(i)), 인앱 계정 삭제 없음(Guideline 5.1.1(v)), 접속되지 않는 Support URL(Guideline 1.5)입니다. 이 중 어느 것도 고치는 데 엔지니어링 노력이 들지 않습니다. 버그가 아니라 체크리스트 항목입니다.

앱에 계정 삭제 옵션을 넣지 않으면 어떻게 되나요?

iOS에서는 앱이 계정 생성을 지원하는 경우 Guideline 5.1.1(v)가 이를 자동 리젝 사유로 만듭니다. Android에서는 Google Play가 인앱 삭제 경로와 공개 웹 삭제 경로 두 가지를 모두 요구하며, 2024년 5월 31일 연장 기한 이후 미준수 앱은 제재를 받습니다. 이를 생략하면 두 플랫폼 모두에서 제출이 막힙니다.

스타트업도 모바일 앱에 개인정보 처리방침이 필요한가요?

네, 거의 항상 필요합니다. Apple은 Guideline 5.1.1(i)에 따라 링크된 개인정보 처리방침을 요구하고, Google Play는 Data Safety form 안에 하나를 요구합니다. 사용자 데이터를 조금이라도 수집한다면, 가입용 이메일 하나만 받아도, 제출 전에 필요합니다.

App Store 제출과 Google Play 제출의 차이점은 무엇인가요?

Apple의 심사는 guideline 기반이며 조항 번호(5.1.1, 1.5, 1.6)와 사람 리뷰어가 있습니다. Google Play는 Data Safety form과 자동화 검사에 의존합니다. 계정 삭제 요건은 취지가 비슷하지만 방식이 다릅니다. 위의 비교표를 참고하세요.

앱 스토어 심사는 실제로 얼마나 걸리나요?

두 스토어 모두 보장된 처리 기간을 공개하지 않습니다. 그러니 어디서 읽은 숫자든 약속이 아니라 대략적인 기대로 취급하세요. 저희 클라이언트 제출 경험상, Apple 승인은 보통 하루 이틀 안에 도착했고, 계정 삭제나 데이터 공개에 걸리는 것은 더 오래 걸렸습니다. Google Play는 보통 더 빨랐습니다. 어느 쪽이든 출시일에는 여유를 두고 계획하세요.

단계적 rollout이란 무엇이며, 사용하는 것이 좋나요?

단계적 rollout은 업데이트를 먼저 소규모 사용자 비율에 배포한 뒤, 100%로 한꺼번에 보내는 대신 점진적으로 확대하는 방식입니다. 스토어가 지원할 때마다 사용하세요. 일시 중지하고 고칠 수 있기 전에 버그에 노출되는 사용자 수를 제한해 줍니다.

앱을 제출할 때 Support URL이 필요한가요?

네. Apple Guideline 1.5는 제출의 일부로 동작하는 Support URL을 요구하며, Google Play도 지원 연락처를 기대합니다. 여기의 죽은 링크나 확인하지 않는 수신함은, 쉽게 피할 수 있는 리젝 사유입니다.

앱 출시 후 첫 일주일 동안 무엇을 모니터링해야 하나요?

매일 crash report, 첫 10개 스토어 리뷰, 그리고 데이터 삭제 요청 프로세스가 실제로 끝까지 동작하는지입니다. 또한 MVP가 검증하려고 만든 가설과 실제 사용 데이터를 대조하기 시작하는 시점도 이때입니다.

GDPR 또는 KVKK가 작은 스타트업 앱에도 해당되나요?

EU에 사용자가 있다면, 회사 규모와 무관하게 GDPR이 적용됩니다. 터키에 사용자가 있다면, KVKK도 같은 방식으로 적용됩니다. 두 법 모두 작은 스타트업 면제 조항이 없습니다. 그러니 실제 보호할 사용자 데이터가 생긴 뒤가 아니라, 스코핑 단계에서 적용 여부를 확인하세요.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위해 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축합니다. Techsy 팀이 실제로 프로덕션에서 사용하는 LLM 툴링 스택에 대해 글을 씁니다. LinkedIn에서 연결하기.

결론

스타트업 모바일 앱 체크리스트가 제자리를 차지하려면 오늘 바로 실행할 수 있을 만큼 구체적이어야 합니다. MVP를 한 문장으로 정의하고, 빌드 전에 분석 도구를 계측하고, 제출 일주일 전에 버전 체계를 검토하고, iOS와 Android 체크리스트를 하나의 리스트로 다루지 말고 분리하세요. 계정 삭제와 개인정보 처리방침 항목만으로도, 저희가 보는 피할 수 있는 리젝의 대부분이 설명됩니다.

체크리스트를 출력해서 단계별로 진행하고, 출시 후 첫 일주일을 건너뛰지 마세요. 모든 경쟁사 체크리스트가 빠뜨리는 부분이 바로 여기이고, 출시가 실제로 자리 잡는지를 결정하는 부분도 여기입니다. 보내기 전에 제출물을 한 번 더 봐줄 사람이 필요하다면, 무료 상담 받기 →