앱 MVP 심사 데모 계정: 로그인·권한·검토 노트를 나누는 5가지 기준
앱 MVP 심사 데모 계정: 로그인·권한·검토 노트를 나누는 5가지 기준
로그인이 필요한 앱 MVP를 스토어 심사에 제출할 때, “테스트 계정 하나를 만들었다”만으로는 충분하지 않을 수 있습니다. 심사자가 실제로 로그인할 수 있는지, 로그인 뒤 핵심 기능에 들어갈 수 있는지, 추가 인증·QR 코드·구독 화면처럼 막히는 지점은 없는지까지 연결되어야 합니다.
먼저 답하면, 심사용 계정 자체·접근 절차·허용 권한·검토용 데이터·심사 노트와 담당자를 별도로 기록하면 됩니다. Apple은 계정 기반 기능이 있는 앱에 심사용 전체 접근과 활성 데모 계정 또는 완전한 데모 모드를 제공하라고 안내합니다. Google Play도 검토팀이 모든 앱 기능에 로그인·접근할 수 있는 정보를 제출하도록 요구합니다. 이 글은 특정 앱의 심사 통과를 보장하는 안내가 아니라, 출시 전에 접근 정보를 점검하는 실무 기록법입니다.
공식 원문 확인일: 2026년 9월 17일 · 작성: 유인어스(UINUS)
왜 ‘아이디와 비밀번호’만 남기면 심사가 막힐까요?
로그인 정보는 출발점일 뿐입니다. 앱이 일회용 비밀번호, 2단계 인증, 초대 코드, 특정 국가, 특정 역할, 샘플 QR 코드, 유료 구독, 사내망처럼 추가 조건을 요구한다면 심사자는 아이디와 비밀번호만으로 핵심 화면을 확인하지 못할 수 있습니다. 심사자에게만 예외를 만든다고 해도, 그 경로가 현재 빌드에서 실제로 동작하는지와 무엇을 검토할 수 있는지는 별도의 문제입니다.
Apple의 심사 지침은 계정 기반 기능에 활성 데모 계정 또는 완전한 데모 모드, 그리고 로그인 정보나 샘플 QR 코드처럼 검토에 필요한 자원을 제공하라고 설명합니다. Apple은 로그인 앱의 경우 데모 계정 정보를 포함하고 백엔드 서비스를 켜 두라고도 안내합니다. Google Play 역시 테스트용 로그인 정보, 사전 구성한 데모 계정, QR 코드, 제한 영역 접근 지침 등을 심사 정보로 제출할 수 있다고 명시합니다.
따라서 심사용 접근은 실제 고객 계정을 전달하는 일이 아닙니다. 고객 데이터와 권한을 섞지 않는 별도 검토용 환경 또는 계정을 준비하고, 그 범위와 만료·변경 책임을 운영 기록에 남기는 일입니다.
심사 접근 정보에 나눠 둘 5가지 기준
1. ‘심사자용 신원’과 일반 운영 계정을 분리하세요
심사용 계정에는 이름, 이메일, 비밀번호 같은 식별 정보보다 먼저 어떤 역할까지 볼 수 있는 계정인가를 적습니다. 예를 들어 일반 사용자 흐름만 검토하면 되는지, 운영자 메뉴까지 필요한지, 특정 기능을 보기 위해 초기 설정이 필요한지를 구분합니다. 실제 고객·직원 계정을 재활용하면 개인정보, 결제 내역, 알림 수신, 권한 변경이 얽힐 수 있으므로 피하는 편이 안전합니다.
기록 칸에는 계정 별칭, 역할, 허용 기능, 생성일, 만료 또는 변경 예정일, 관리 담당자를 남기세요. 비밀번호 원문이나 비밀 키를 이 글, 스크린샷, 공개 문서에 복사하지 말고, 플랫폼 제출란과 내부의 승인된 비밀 관리 경로를 분리합니다. 외주 개발 인수 단계라면 앱 외주개발 시작 전 접근권한 점검처럼 계정 공유가 아닌 역할 기반 접근을 먼저 정리할 수 있습니다.
2. 로그인 뒤의 ‘전체 검토 경로’를 한 줄씩 적으세요
심사자는 앱을 처음 여는 순간부터 핵심 기능까지 도달해야 합니다. 그래서 “ID 입력 → 비밀번호 입력” 뒤에 나오는 약관 동의, 비밀번호 변경, 초기 프로필 설정, OTP, 조직 선택, QR 인식, 구독 화면, 권한 요청을 순서대로 적어 두는 편이 좋습니다. 각 단계마다 심사자가 해야 할 행동과 기대 화면, 막히면 볼 대체 경로를 짧게 붙입니다.
Google Play는 로그인 정보가 언제나 접근 가능하고 재사용 가능하며, 사용자 위치와 무관하게 유효해야 한다고 안내합니다. 앱에 2단계 인증이나 일회용 비밀번호가 있다면 재사용 가능한 심사 접근 방법을 제공해야 하며, 다른 계정으로 로그인하는 구조라면 계정 정보와 명확한 지침이 함께 필요합니다. 그러므로 ‘로그인 가능’이라는 말 대신 실제 제출 빌드에서 한 번 끝까지 따라간 경로를 심사 노트로 바꾸세요.
3. 권한·유료 기능·제한 기능의 시작 상태를 표시하세요
카메라, 위치, 알림 권한이나 유료 기능은 로그인 다음에 다시 검토를 막을 수 있습니다. 심사자가 어떤 권한을 허용해야 하는지, 거부해도 어디까지 확인할 수 있는지, 구독 또는 결제 뒤에만 보이는 기능이 있는지, 사내 고객 전용 기능은 어떤 데모 데이터로 확인하는지를 적습니다. Google Play는 로그인 없이도 구독 결제벽 뒤에 기능이나 콘텐츠가 있다면 전체·무료 검토가 가능하도록 추가 접근 정보나 지침을 제공하라고 안내합니다.
이때 운영팀이 임의로 심사 기능을 숨기거나 실제 결제·개인정보를 넣을 필요는 없습니다. 기능별로 ‘검토 가능’, ‘검토에 추가 설명 필요’, ‘이번 제출 범위 아님’을 구분하고, 현재 빌드에서 보이는 상태와 제출 노트의 설명이 같은지 확인하세요. 권한 요청의 타이밍을 함께 다듬어야 한다면 앱 MVP 알림 권한 요청 점검도 별도로 검토할 수 있습니다.
4. 검토용 데이터는 실제 고객 데이터와 구분하세요
심사자가 주문·프로필·콘텐츠·대시보드 같은 화면을 이해하려면 샘플 데이터가 필요할 수 있습니다. 그러나 실제 고객의 이름, 연락처, 결제 내역, 위치, 대화 내용을 보여 주는 것은 해결책이 아닙니다. 가상의 명칭과 비식별 샘플을 사용하고, 어떤 데이터가 미리 들어 있는지와 심사 중 변경될 수 있는 상태를 노트에 적습니다.
Apple은 스크린샷과 미리보기 등에 실제 인물의 데이터 대신 가상 계정 정보를 표시하라고 안내합니다. 이 원칙을 심사용 앱 데이터에도 적용하면, 심사 이해에 필요한 예시는 남기되 고객 정보를 검토 경로에 섞지 않을 수 있습니다. 오류 추적 기록에서도 개인정보와 토큰을 남기지 않는 기준은 앱 MVP 오류 로그 점검에서 별도로 다룹니다.
5. 제출 직전에는 ‘지금도 유효한가’를 다시 읽으세요
데모 계정은 만들어 둔 뒤에도 비밀번호 만료, 기능 플래그 변경, 백엔드 중지, 테스트 데이터 초기화, 국가 제한, 앱 업데이트 때문에 작동하지 않을 수 있습니다. Apple은 심사에 필요한 백엔드 서비스를 활성화하고, 로그인 앱에 데모 계정 정보를 포함하라고 안내합니다. Google Play도 제출한 정보가 오류 없이 지속적으로 유지되어야 한다고 설명합니다.
제출 직전에는 다른 기기나 새로운 세션에서 심사 정보만 사용해 로그인해 보세요. 이어서 핵심 기능, 제한 기능의 안내, 로그아웃 뒤 재로그인, 심사 노트와 빌드 번호가 일치하는지 확인합니다. 실패했다면 새 비밀번호만 바꾸고 끝내지 말고 원인·수정·재확인 시각·다음 담당자를 남겨야 다음 제출에서 같은 문제가 반복되지 않습니다.
제출 전 10분 점검표
현재 제출 빌드 번호와 심사 노트의 대상 기능이 일치하는지 확인합니다.
심사용 계정의 역할·허용 범위·담당자·변경 예정일을 확인합니다.
새 세션에서 로그인부터 핵심 기능까지 실제로 따라갑니다.
OTP·QR·다른 계정 로그인·위치·구독 결제벽 같은 추가 조건의 접근 지침을 확인합니다.
검토용 샘플에 실제 고객 정보, 운영 비밀, 결제 수단이 섞이지 않았는지 확인합니다.
백엔드, 테스트 데이터, 외부 연동이 제출 시점에도 사용할 수 있는지 확인합니다.
막히는 화면과 대체 경로를 심사 노트에 짧고 명확하게 적습니다.
심사 데모 접근의 목적은 계정을 많이 만드는 데 있지 않습니다. 제출한 빌드의 핵심 경험을 심사자가 재현할 수 있게 하고, 실제 고객 정보나 내부 권한을 불필요하게 노출하지 않도록 경계를 정하는 데 있습니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 Apple·Google의 개별 심사 결과, 앱 출시 또는 사업 성과를 보장하지 않습니다.
자주 묻는 질문
심사용 데모 계정에 실제 고객 데이터를 넣어도 되나요?
피하는 편이 좋습니다. 심사 이해에 필요한 범위에서 가상의 명칭과 비식별 샘플 데이터를 사용하고, 실제 고객·직원 계정과 권한을 분리하세요. Apple은 메타데이터와 미리보기에서 실제 인물 데이터 대신 가상 계정 정보를 표시하라고 안내합니다.
2단계 인증이 있는 앱은 심사용으로 어떻게 준비하나요?
Google Play는 심사 정보가 재사용 가능하고 지속적으로 유효해야 하며, 앱이 2단계 인증이나 일회용 비밀번호를 요구하면 이를 우회할 수 있는 재사용 가능한 로그인 수단을 제공하라고 안내합니다. 구현 방식과 현재 정책은 앱의 보안 요구사항을 검토한 뒤 Play Console 제출 정보에서 확인하세요.
구독 뒤에만 보이는 기능도 심사자가 확인할 수 있어야 하나요?
Google Play는 로그인 정보가 필요 없는 앱이라도 구독 결제벽 뒤에 기능이나 콘텐츠가 있으면 전체·무료 검토가 가능하도록 추가 지침이나 접근 정보를 제공하라고 안내합니다. 현재 앱의 과금 구조와 심사 제출 화면을 기준으로 필요한 범위를 다시 확인하세요.
심사 노트에는 무엇을 적어야 하나요?
계정 정보의 전달 경로와 함께, 로그인부터 핵심 기능까지의 단계, 추가 인증·QR·다른 계정 로그인·특정 권한·유료 기능의 접근 방법, 검토용 데이터의 의미, 막혔을 때의 대체 경로를 간단히 적으세요. 노트는 현재 제출 빌드와 일치해야 합니다.