Turn a request into a screen flow

1. 사용자가 하려는 일

• 이메일로 직접 가입한 사용자는 내 계정의 비밀번호를 새로 설정해서 다시 로그인하고 싶다.
• 소셜 로그인 사용자는 내 계정에 비밀번호가 필요한 상황인지, 아니면 카카오·네이버로 계속 로그인해야 하는지 알고 싶다.

즉, 모든 사용자가 실제로 “비밀번호를 찾는” 것은 아닙니다. 특히 소셜 가입자는 서비스에 등록된 비밀번호가 없을 수 있습니다.

2. 사용자 흐름

3. 요청에 포함된 가정

사용자가 이미 알고 있다고 가정한 것

• 사용자가 로그인에 사용하는 이메일 주소를 알고 있다.
• 해당 이메일 계정에 접근할 수 있다.
• 인증코드를 받기 위해 메일함을 확인할 수 있다.
• 사용자가 자신의 가입 방식을 알고 있거나, 비밀번호 방식으로 가입했다고 생각한다.
• 인증코드를 입력하면 비밀번호를 바꿀 수 있다는 흐름을 이해한다.

데이터가 존재한다고 가정한 것

• 입력한 이메일 주소와 연결된 계정이 있다.
• 그 계정에 인증 가능한 이메일 주소가 등록되어 있다.
• 인증코드를 보낼 수 있는 메일 발송 시스템이 정상 작동한다.
• 소셜 가입 계정과 이메일 가입 계정을 구분할 수 있다.
• 하나의 이메일이 여러 로그인 방식 또는 여러 계정과 연결될 수 있는지에 대한 정책이 정해져 있다.
• 인증코드 만료, 재전송, 시도 횟수 제한을 처리할 수 있다.
• 비밀번호를 설정해도 되는 계정인지 판단할 수 있다.

하나의 경로만 있다고 가정한 부분

요청은 다음과 같은 단일 경로만 설명합니다.

이메일 입력 → 인증코드 수신 → 코드 입력 → 새 비밀번호 설정

하지만 실제로는 최소한 아래 경로가 나뉩니다.

• 이메일 직접 가입 사용자
• 카카오로 가입한 사용자
• 네이버로 가입한 사용자
• 이메일 주소가 존재하지 않는 사용자
• 이메일은 존재하지만 인증 메일을 받지 못하는 사용자
• 인증코드가 만료되거나 틀린 사용자
• 이메일 가입자이지만 계정이 정지된 사용자
• 동일 이메일에 소셜 로그인과 이메일 가입이 함께 연결된 사용자

특히 소셜 가입자에게 무조건 비밀번호를 설정하게 할지, 원래 사용한 소셜 로그인으로 안내할지가 핵심 정책입니다.

4. 필요한 화면

요청 문구가 아니라 사용자 단계에서 도출하면 다음 화면이 필요합니다.

1. 비밀번호 재설정 시작 화면

   • 계정 식별에 필요한 이메일 입력
   • 재설정 대상과 절차에 대한 안내

2. 이메일 인증코드 입력 화면

   • 인증 대상 이메일 안내
   • 코드 입력
   • 재전송
   • 이메일 주소 수정
   • 만료·오류·시도 제한 상태

3. 가입 방식 또는 계정 상태 안내 화면

   • 이메일 가입자라면 비밀번호 설정으로 연결
   • 카카오·네이버 가입자라면 해당 소셜 로그인으로 안내
   • 정책에 따라 비밀번호 설정 가능 여부 안내

4. 새 비밀번호 설정 화면

   • 새 비밀번호 입력
   • 비밀번호 확인
   • 조건 및 오류 안내

5. 완료 화면 또는 로그인 복귀 상태

   • 변경 완료 안내
   • 로그인으로 이동

별도의 화면이 필요하지 않을 수도 있는 상태도 있습니다. 예를 들어 인증코드 재전송, 잘못된 코드, 만료 코드는 기존 인증 화면 안의 상태로 처리할 수 있습니다. 다만 실제 화면 구조는 기존 로그인·인증 경험을 봐야 판단할 수 있습니다.

5. 요청에서 말하지 않은 것

• 사용자는 어디에서 이 기능으로 진입하는가?
  • 로그인 화면
  • 로그인 실패 후
  • 고객센터
  • 앱 설정
• 이미 로그인한 사용자가 비밀번호를 바꾸는 기능도 포함하는가?
• 소셜 가입자에게는 무엇을 보여주는가?
  • 카카오·네이버 로그인을 다시 하도록 안내
  • 이메일 인증 후 별도 비밀번호 설정 허용
  • 해당 기능 자체를 제공하지 않음
• 이메일 주소가 존재하지 않을 때 계정 존재 여부를 알려줄 것인가?
• 인증 메일이 오지 않을 때 어떤 도움을 줄 것인가?
• 사용자가 중간에 나가면 인증 상태를 유지하는가?
• 인증코드가 발송된 뒤 다시 들어오면 어디서 이어지는가?
• 인증코드 유효 시간과 재전송 제한은 얼마인가?
• 비밀번호 변경 후 자동 로그인하는가?
• 변경된 비밀번호로 기존 세션을 로그아웃시키는가?
• 계정이 휴면·정지·탈퇴 상태일 때 어떻게 처리하는가?
• 모바일 앱과 웹에서 동일한 흐름인가?
• 이메일이 로그인 ID인지, 연락처 이메일인지?
• 하나의 이메일로 여러 가입 방식이 연결될 수 있는가?

6. 디자인 전에 답해야 할 질문

가장 먼저 정해야 할 질문은 이것입니다.

이 기능의 대상은 이메일 직접 가입자만인가, 아니면 카카오·네이버 소셜 가입자도 포함하는가?

이 질문에 따라 흐름이 달라집니다.

• 이메일 직접 가입자: 이메일 인증 후 새 비밀번호 설정
• 소셜 가입자: 비밀번호 재설정 대상이 아닐 수 있으므로, 원래의 카카오·네이버 로그인으로 안내
• 두 방식을 모두 지원: 인증 후 계정의 가입 방식을 판별하고 분기

추가로 다음 정책도 디자인 전에 확정해야 합니다.

인증한 이메일이 소셜 가입 계정이라면, 사용자가 서비스용 비밀번호를 새로 만들 수 있는가?

7. 서로 다른 사용자의 서로 다른 흐름

이메일 직접 가입자

로그인 화면
→ 이메일 입력
→ 인증코드 확인
→ 새 비밀번호 설정
→ 로그인

카카오·네이버 소셜 가입자

로그인 화면
→ 비밀번호 재설정 선택
→ 이메일 입력
→ 계정이 소셜 가입임을 확인
→ 카카오 또는 네이버 로그인 안내
→ 해당 소셜 로그인으로 이동

소셜 가입자에게 이메일 인증 후 임의로 비밀번호를 설정하게 하면, 계정 보안 정책과 가입 방식의 의미가 달라질 수 있습니다. 이를 허용할지는 제품·보안 정책 결정이 필요합니다.

8. 잘라낼 수 있는 것

사용자에게 필요하지 않고 시스템 처리에 가까운 단계는 별도 화면으로 만들지 않는 것이 좋습니다.

• “인증코드 발송 중”을 별도 화면으로 만들기
• 내부적으로 가입 방식을 조회하는 과정
• 코드 유효성 검사를 별도 단계로 노출하기
• 비밀번호 변경 후 내부 세션 갱신을 사용자 단계로 보여주기
• 성공 여부와 관계없이 이메일 존재 여부를 자세히 알려주는 화면

사용자에게 필요한 것은 결국 다음 세 가지입니다.

1. 내 계정을 식별한다.
2. 내가 그 이메일에 접근할 수 있음을 인증한다.
3. 내가 사용할 로그인 방식을 안내받고, 필요한 경우 새 비밀번호를 설정한다.

현재 설명만으로는 기존 로그인 화면, 가입 방식 저장 구조, 동일 이메일의 중복 연결 정책, 비밀번호 정책과 오류 처리 방식을 볼 수 없으므로 화면 수와 각 상태의 구체적인 표현은 확정할 수 없습니다.