앱 회원탈퇴 구현 체크리스트: iOS·Android 심사와 데이터 삭제

1 계정 생성 방식과 플랫폼별 요구사항을 확인합니다

먼저 이메일 가입, 소셜 로그인, 자동으로 생성되는 계정, 웹 가입 연결 등 실제 가입 경로를 목록으로 만듭니다. 로그인 버튼이 없다는 이유만으로 계정이 없다고 판단하지 마세요.

Apple은 계정 생성을 지원하는 앱에 앱 내 계정 삭제 기능을 요구합니다. App Review Guidelines 5.1.1에서 적용 기준을 확인할 수 있습니다.

Google Play는 앱 내 가입이나 외부 가입 연결이 있으면 앱 내 삭제 경로와 웹 요청 경로를 요구합니다. 웹에서는 앱 또는 개발자 이름을 표시하고, 재설치 없이 요청할 수 있어야 합니다. Google Play 계정 삭제 요구사항을 기준으로 확인하세요.

이 글은 일반적인 모바일 앱의 구현 점검안입니다. 계정을 만들지 않는 서비스나 규제 산업 등은 실제 기능과 적용 예외를 별도로 확인해야 합니다.

2 삭제 요청 화면과 완료 화면을 구분합니다

설정에서 찾을 수 있는 회원탈퇴 항목을 만들고, 다음 화면에서 삭제 대상과 이용할 수 없게 되는 기능을 설명합니다. 로그아웃이나 일시 정지를 회원탈퇴처럼 표시하지 마세요.

Apple은 일반적인 앱에서 전화나 이메일 문의를 삭제의 필수 단계로 강제하지 않도록 안내합니다. 시간이 필요한 경우에는 예상 처리 시간과 완료 결과를 알려야 합니다. Apple 계정 삭제 안내를 참고하세요.

화면 설계에서는 다음 상태를 나누는 편이 좋습니다.

• 요청 전: 지워질 데이터와 남겨야 하는 항목, 되돌릴 수 있는지 안내
• 본인 확인: 실제 계정 소유자인지 검증
• 접수됨: 서버에 요청이 기록됐지만 정리는 진행 중인 상태
• 완료됨: 정해 둔 삭제 작업과 검증이 끝난 상태
• 확인 필요: 처리 지연이나 실패가 있어 담당자가 확인하는 상태

접수 직후 “모든 정보가 삭제되었습니다”라고 보여주면 실제 처리 상태와 안내가 어긋납니다. 문구는 서버가 확인한 결과에 맞추세요.

3 로그인 계정과 서비스 데이터를 함께 목록화합니다

인증 계정은 로그인에 쓰는 식별자이고, 서비스 데이터는 사진, 글, 이용 기록처럼 별도 저장소에 쌓이는 자료입니다. 삭제 범위는 인증 시스템 화면만 보고 정할 수 없습니다.

구현 전에 데이터별 저장 위치와 연결 키, 삭제 담당 작업, 완료 확인 방법을 적습니다.

• 계정과 프로필: 인증 사용자, 프로필 문서, 연결된 로그인 제공자
• 사용자가 만든 자료: 게시글, 댓글, 사진 원본과 썸네일
• 운영용 자료: 알림 대상, 검색 색인, 고객지원 기록과 분석 식별자
• 외부 처리: 앱이 사용하는 서비스 업체의 보관 데이터
• 보관 예외: 별도로 검토한 근거에 따라 남기는 최소한의 자료

예를 들어 Cloud Firestore는 일반적인 문서 삭제로 하위 컬렉션의 문서까지 자동 삭제하지 않습니다. 상위 프로필 문서가 사라졌다는 확인만으로 전체 삭제를 완료 처리하면 안 됩니다. Firestore 삭제 동작을 확인하세요.

Google Play는 이용하는 외부 처리 업체에도 삭제를 요청하도록 안내합니다. 외부 처리 데이터 관련 안내를 기준으로, 업체별 요청 방법과 확인 결과를 기록하세요.

4 본인 확인과 접근 권한 차단을 설계합니다

삭제 API는 요청에 담긴 회원 번호를 그대로 신뢰하면 안 됩니다. 서버가 검증한 로그인 정보로 대상 계정을 결정하고, 다른 사람의 계정을 지정해도 삭제할 수 없도록 해야 합니다.

오래된 로그인 상태, 계정 전환, 여러 기기에서 동시 이용하는 경우도 테스트합니다. 예를 들어 Firebase의 클라이언트 계정 삭제는 최근 로그인을 요구하므로 재인증을 취소하거나 실패했을 때의 흐름이 필요합니다. Firebase 사용자 관리에서 동작을 확인할 수 있습니다.

삭제 처리가 시작되면 새 데이터가 계속 쌓이지 않도록 쓰기 권한과 백그라운드 작업을 제어하는 구조를 권합니다. 기존 세션과 알림 대상도 함께 점검하세요. 단순히 앱 한 대에서 로그아웃시키는 것과 서버 접근을 막는 것은 다릅니다.

Sign in with Apple은 토큰 철회도 포함합니다. Apple 계정 삭제 안내와 토큰 철회 API를 확인하고, 처리에 필요한 연동 정보를 먼저 없애 재시도할 수 없게 만들지 않도록 순서를 정하세요.

5 일부 실패해도 이어서 처리할 수 있게 만듭니다

여러 저장소를 정리하는 요청을 휴대전화에서 끝까지 실행하게 하면 앱 종료나 통신 중단에 취약합니다. 실무 설계안으로는 서버에 삭제 작업을 등록하고 단계별 결과를 기록하는 방식을 고려할 수 있습니다.

예를 들어 프로필 삭제는 성공했지만 파일 저장소의 삭제가 실패할 수 있습니다. 이때 전체 완료로 처리하지 않고 실패 단계만 다시 시도할 수 있어야 합니다.

• 같은 요청이 두 번 들어와도 중복 처리로 다른 데이터에 영향을 주지 않게 합니다.
• 이미 없는 자료는 안전하게 처리하되, 권한 오류와 통신 실패를 성공으로 숨기지 않습니다.
• 재시도 횟수와 간격, 장시간 멈춘 작업의 담당자를 정합니다.
• 앱이 꺼져도 서버 작업 상태를 확인하고 필요한 조치를 이어갈 수 있게 합니다.
• 검증용 기록에는 요청 식별자와 단계별 결과 등 필요한 최소 정보만 남깁니다.

관리자용 일괄 삭제도 별도로 검수하세요. Firebase Admin SDK의 일괄 사용자 삭제는 개별 사용자 삭제 이벤트를 발생시키지 않습니다. 삭제 이벤트에 데이터 정리 작업을 연결했다면 이 경로에서 빠질 수 있습니다. Firebase Admin 사용자 삭제 안내를 확인해야 합니다.

6 구독 해지와 보관 예외를 따로 처리합니다

회원탈퇴, 구독 해지, 환불은 같은 작업으로 가정하면 안 됩니다. 결제 경로와 현재 구독 상태를 확인하고, 사용자가 어떤 조치를 해야 하는지 안내합니다.

Apple 자동 갱신 구독은 계정 삭제 후에도 청구가 이어질 수 있습니다. 구독 관리로 안내하고, 만료일에 맞춘 삭제 예약을 제공하더라도 즉시 삭제 선택지를 함께 제공해야 합니다. Apple의 구독 관련 계정 삭제 안내를 확인하세요.

Google Play도 앱 삭제만으로 구독이 취소되지는 않는다고 안내합니다. 계정 삭제와 결제 처리를 연결했다면 실제 취소 결과까지 확인하고, 연결하지 않았다면 별도의 구독 관리 경로를 명확히 안내하세요. Google Play 구독 관리를 참고할 수 있습니다.

일부 기록을 남겨야 한다면 “법 때문에 보관”이라는 한 문장으로 끝내지 마세요. 적용 근거, 대상 항목, 보관 기간, 접근 권한과 기간 종료 후 처리 방법을 구분합니다. 기간은 서비스와 관할에 따라 검토해야 하며, 모든 앱에 같은 숫자를 적용할 수 없습니다.

백업 복구 때 삭제된 사용자의 자료가 다시 서비스로 돌아오지 않게 하는 절차도 정하세요. 보관이 필요한 자료와 일반 서비스용 데이터를 구분하고, 실제 운영 방식과 사용자 안내가 일치하는지 검토합니다.

7 테스트 결과와 제출 정보를 맞춥니다

회원탈퇴 검수는 버튼을 눌러 로그아웃되는지만 확인하는 테스트가 아닙니다. 테스트 계정에 사진과 기록 등 데이터를 실제로 만든 뒤 삭제 전후를 비교해야 합니다.

• 이메일과 소셜 로그인 등 지원하는 가입 방식별로 요청이 가능한가
• 재인증 취소와 로그인 만료를 안내하고 안전하게 복구하는가
• 두 번 누르거나 여러 기기에서 요청해도 대상 계정이 바뀌지 않는가
• 앱 종료와 통신 중단 후에도 접수 상태와 결과를 확인할 수 있는가
• 파일 삭제나 외부 서비스 호출 실패를 발견하고 재시도하는가
• 삭제 이후 기존 세션과 예약 알림, 동기화 작업이 어떻게 동작하는가
• 앱을 지운 사용자도 웹 요청 경로를 이용할 수 있는가
• 개인정보 안내와 스토어에 제출한 설명이 실제 구현과 일치하는가

심사 담당자가 찾을 경로와 테스트 방법을 제출 정보에 구체적으로 적으세요. 회원탈퇴 테스트로 계정이 사라질 수 있으므로 검수용 계정과 재테스트 준비도 따로 관리하는 편이 좋습니다.

개발 외주를 맡길 때는 회원탈퇴 화면뿐 아니라 서버 정리, 웹 요청 경로, 구독 안내와 실패 복구까지 어디에 포함되는지 확인하세요. 기존 앱을 점검하려면 가입 방식과 사용 중인 저장소, 삭제가 막히는 단계를 먼저 정리하면 됩니다. 처음 문의에 비밀번호나 실제 고객 데이터를 보낼 필요는 없습니다.

출시 준비는 앱스토어와 구글 플레이 심사 대응, 작업 범위는 Flutter 앱 유지보수 안내에서 이어서 확인할 수 있습니다.

2026년 10월 13일 기준 공식 안내를 확인한 기술 점검안입니다. 심사 승인이나 법률 준수를 보장하지 않으며, 보관 의무와 예외는 서비스에 적용되는 최신 정책 및 법률 검토가 필요합니다.