이 글의 순서
로그인 버튼보다 먼저 결정할 것이 있습니다
회원가입은 앱의 첫 화면이지만 단순히 로그인 버튼을 몇 개 배치하는 작업은 아닙니다. 어떤 정보로 같은 사용자를 식별할지, 휴대폰이나 이메일이 바뀌었을 때 어떻게 복구할지, 이미 가입한 사용자가 다른 로그인 방식을 선택하면 어떻게 연결할지까지 정해야 합니다.
앱 로그인 개발을 시작할 때는 ‘요즘 많이 쓰는 방식’을 모두 넣기보다 서비스가 정말 계정을 필요로 하는지부터 확인하세요. 저장·결제·예약·작성처럼 사용자를 계속 식별해야 하는 기능이 없다면 일부 내용은 로그인 없이 제공하는 편이 나을 수 있습니다.
1. 로그인 목적을 먼저 나눕니다
로그인을 요구하는 이유가 분명해야 필요한 정보와 인증 강도를 정할 수 있습니다.
개인화와 기록 보관
관심 항목, 작성 기록, 구매·예약 내역을 여러 기기에서 이어서 보기 위한 계정입니다.
권한과 책임 확인
판매자, 전문가, 직원, 보호자처럼 특정 역할의 권한을 부여하기 위한 계정입니다.
본인 확인
실명, 연령, 휴대폰 소유처럼 별도의 확인이 필요한 경우입니다. 일반 로그인과 법적·업무상 필요한 본인확인을 같은 기능으로 생각하면 불필요한 정보 수집이 늘어날 수 있습니다.
2. 이메일 가입은 직접 운영할 계정 체계가 필요합니다
이메일과 비밀번호 방식은 특정 SNS에 의존하지 않고 웹과 앱에서 같은 계정을 운영하기 좋습니다. 대신 비밀번호 보안, 이메일 확인, 비밀번호 재설정, 로그인 시도 제한과 고객 문의 대응을 직접 설계해야 합니다.
이메일 주소 자체를 절대 변하지 않는 사용자 식별값으로 사용하기보다 내부 회원번호를 따로 두는 것이 안전합니다.
확인해보세요
- 이메일을 로그인 이름으로 쓸지 연락 수단으로만 쓸지
- 가입 확인 메일이 도착하지 않을 때의 안내
- 비밀번호 재설정 링크의 유효 시간
- 이메일 주소 변경과 기존 계정 확인 절차
- 탈퇴 후 같은 이메일로 재가입할 수 있는 시점
3. SNS 로그인은 가입을 줄이지만 계정 연결이 필요합니다
Google, Apple, 카카오와 네이버 로그인을 사용하면 비밀번호를 새로 기억해야 하는 부담을 줄일 수 있습니다. 하지만 SNS마다 사용자 식별값과 제공 정보가 다르고, 이메일 공개 여부도 달라질 수 있습니다.
Google은 로그인 결과의 이메일 대신 변하지 않는 고유 식별값인 sub를 회원 식별에 사용하고, 서버에서 ID 토큰을 검증하도록 안내합니다. 상세 내용은 Sign in with Google 구현 권장사항에서 확인할 수 있습니다.
신규 가입
처음 로그인한 SNS 계정으로 새 회원을 만들 때 필수 약관 동의와 추가로 필요한 정보만 받습니다.
기존 회원 연결
같은 이메일처럼 보인다는 이유만으로 자동 합치지 않습니다. 기존 로그인 확인이나 추가 인증을 거쳐 두 로그인 수단이 같은 사람의 것인지 확인합니다.
연결 해제
사용자가 연결된 로그인 수단을 확인하고 해제할 수 있게 하되, 마지막 로그인 수단을 제거해 계정에 들어올 수 없게 되지 않도록 대체 수단을 먼저 안내합니다.
4. 휴대폰 인증은 연락처와 본인확인을 구분합니다
문자로 번호를 확인하는 기능과 본인확인기관을 통한 실명 인증은 목적과 비용이 다릅니다. 예약 안내를 받을 번호가 필요한 것인지, 동일인 중복 가입을 제한해야 하는지, 연령이나 실명을 확인해야 하는지 먼저 정해야 합니다.
휴대폰 번호 역시 바뀌거나 다른 사람에게 재할당될 수 있으므로 내부 회원번호와 분리해 관리하는 것이 좋습니다.
확인해보세요
- 단순 문자 인증인지 본인확인인지
- 해외 번호를 지원할지
- 번호 변경 시 기존 계정으로 들어오는 방법
- 가족이나 법인 공용 번호를 허용할지
- 인증 문자 비용과 재전송 제한
5. 한 사람의 중복 계정을 어떻게 처리할지 정합니다
사용자는 처음에는 카카오로 가입하고 다음에는 Apple이나 이메일 로그인을 누를 수 있습니다. 이때 새 계정을 계속 만들면 주문·예약·포인트와 작성 기록이 나뉩니다.
중복 가능성이 발견되면 자동 병합보다 다음 순서가 안전합니다.
결제나 정산이 있는 서비스는 포인트와 거래 기록을 단순 합산해서는 안 됩니다. 서비스 정책과 회계·법적 보관 기준을 함께 검토해야 합니다.
확인해보세요
- 기존 계정의 로그인에 성공하거나 추가 인증을 합니다.
- 합칠 계정의 주문·포인트·권한과 제재 상태를 확인합니다.
- 어느 계정을 기준으로 유지할지 사용자에게 보여줍니다.
- 연결 결과와 되돌릴 수 없는 항목을 안내합니다.
- 관리자에는 연결·해제 이력을 남깁니다.
6. 로그인 실패보다 계정 복구 과정을 먼저 설계합니다
실제 문의는 정상 가입보다 휴대폰 분실, 이메일 접근 불가, SNS 탈퇴와 직원 퇴사 같은 상황에서 많이 발생합니다. 고객센터가 어떤 정보로 본인을 확인하고 어디까지 처리할 수 있는지 정해야 합니다.
관리자가 비밀번호를 대신 알려주는 방식은 피하고, 재설정이나 로그인 수단 변경 절차를 사용합니다.
확인해보세요
- 비밀번호를 잊은 경우
- 가입 이메일을 더 이상 사용할 수 없는 경우
- 휴대폰 번호가 바뀐 경우
- SNS 계정을 탈퇴하거나 접근할 수 없는 경우
- 기업 담당자가 바뀐 경우
- 보호자·자녀 계정 관계를 변경해야 하는 경우
7. 가입·정상·정지·탈퇴 상태를 구분합니다
회원은 가입과 탈퇴 두 상태만 있는 것이 아닙니다. 이메일 확인 전, 추가 정보 입력 전, 정상, 이용 제한, 탈퇴 요청, 탈퇴 완료와 법적 보관 상태 등을 서비스에 맞게 구분합니다.
사용자 화면
현재 상태와 필요한 다음 행동을 설명하고, 로그인할 수 없는 이유와 문의 방법을 보여줍니다.
관리자 화면
상태 변경 권한, 사유, 처리자와 시각을 기록합니다. 정지와 탈퇴를 같은 처리로 만들면 복구와 데이터 보관 기준이 불분명해질 수 있습니다.
8. 앱 심사 전에 로그인과 탈퇴 정책을 확인합니다
Apple은 제3자 또는 소셜 로그인으로 앱의 기본 계정을 만들고 인증한다면 일정 조건을 충족하는 동등한 로그인 선택지를 함께 제공하도록 요구합니다. 또한 계정 생성을 지원하는 앱은 앱 안에서 계정 삭제를 제공해야 합니다. 예외와 최신 세부 조건은 Apple App Review Guidelines의 로그인·계정 항목을 확인하세요.
Google Play도 앱 안에서 계정을 만들 수 있다면 앱 안의 삭제 요청 경로와 앱을 다시 설치하지 않아도 사용할 수 있는 웹 삭제 요청 경로를 요구합니다. 보관해야 하는 데이터가 있다면 그 이유와 기준을 사용자에게 알려야 합니다. 상세 내용은 Google Play 계정 삭제 요구사항에서 확인할 수 있습니다.
정책은 바뀔 수 있으므로 제출 시점에 운영 주체가 최신 공식 문서를 다시 확인해야 합니다.
9. 로그인 방식을 선택하는 간단한 기준
서비스와 사용자를 기준으로 필요한 방식을 조합하세요.
로그인 버튼의 개수보다 중요한 것은 같은 사용자를 안정적으로 식별하고, 사용자가 로그인 수단을 잃어도 계정과 기록을 안전하게 복구하며, 탈퇴 요청을 실제 데이터 처리와 연결하는 구조입니다.
확인해보세요
- 공개 콘텐츠 중심: 로그인 없이 보기 + 필요한 행동에서만 가입
- 일반 소비자 서비스: 주요 SNS 로그인 + 복구 가능한 보조 수단
- 웹·앱을 함께 사용: 플랫폼별로 같은 회원번호와 연결 구조
- 예약·연락 중심: 연락처 확인 목적과 실명 본인확인을 분리
- 기업·기관 서비스: 조직 계정, 직원 권한과 담당자 변경 절차
- 결제·정산 서비스: 강한 인증, 거래 기록과 계정 복구 정책
