[Project] 로그인&회원가입 기능을 설계할 때, UX관점에서 고려해야하는 부분

소셜 로그인은 왜 필요한가?

이전 글에서는 소셜로그인을 사용해야 하는 이유에 대해 알아보았습니다.
그렇다면 실제 '미리' 앱을 예시로, 소셜 로그인이 포함된 로그인&회원가입은 어떤 식으로 설계되는지 그 흐름에 대해 알아보겠습니다.

 

 

✓ "미리" 프로젝트의 로그인 및 회원가입 요약

[Project] 맛있는 외식의 시작, '미리'

"미리"는 유저를 기준으로 특정 거리 안에 있는 가게의 재고 상품을 할인된 가격으로 구매할 수 있도록 도와주는 O2O 커머스 애플리케이션입니다.

 

다시 말해 '미리'앱은 메인 화면으로 들어오기 전에 먼저 유저의 위치를 알고 있어야 그 주위의 가게를 노출시킨 후 관련된 서비스를 이용할 수 있습니다. 또한 커머스 앱의 특성상 개별 유저에게 포인트나 쿠폰등을 지급하는 이벤트도 존재하기 때문에 최대한 1인 1 계정을 가질 수 있도록 적절한 타이밍에 유저 중복검사를 하는 것도 필수적입니다.

 

 

✓ 설계

📌 유저 식별 데이터

가장 먼저 생각했던 부분은 "어떻게 유저의 계정을 유니크하게 관리하지?"였습니다.

유니크한 값을 가지려면 어떠한 이유로든 그 값이 변경되어선 안되며 항상 일관되게 값을 유지해야 합니다.

"미리"의 경우 소셜로그인을 사용하기 때문에 각 플랫폼에서 받은 Token을 통해 알 수 있는 "사용자 정보"들로 유니크한 값을 만들어야 했습니다.

• 소셜 로그인 Token으로 알 수 있는 공통적인 정보
  • 이메일
  • 사용자 식별번호(uid)
  • 닉네임 혹은 이름

(이 외의 정보는 제공하지 않거나 유저의 동의가 있어야 받아 올 수 있으므로 제외했습니다.)

 

여기서 유저 식별 데이터 후보로는 이메일과 uid로 생각할 수 있는데 여러 소셜 플랫폼으로 로그인을 시도할 수 있다는 점에서 다음과 같은 문제점이 발생할 수 있습니다.

 

• 이메일 
  • 계정 생성 시, 도메인 양식(niketjssun31@gmail.com)이 해당 플랫폼에 종속적이지 않는 경우가 존재합니다.
    만약에 앞서 말한 구글 이메일로 카카오나 애플 계정을 만들게되면 전부 동일한 이메일로 도메인 서비스에 가입되므로 최대, 플랫폼의 갯수만큼 중복 계정이 생성될수있습니다.
• uid(user identifier)
  • 현재는 카카오를 제외한 나머지는 UUID로 구성되어있어 무관하지만 이전에는 카카오, 구글, 네이버는 정수로 이루어져 있었으므로 플랫폼간에 uid가 겹칠 위험이 존재했었습니다.
  • uid는 당사 소셜 로그인 플랫폼에선 유니크한 값이기때문에 유출되었을 시 보안 및 개인정보 보호에 문제가 생겨 해당 플랫폼에서 불이익을 당할수있습니다.
  • 정책에 의해 유저 식별자 데이터가 변경 될 가능성이 존재합니다.

출처: naver developers

 

 

✍🏼 해결 방법

 

여러 소셜 로그인을 사용하기때문에 발생하는 문제점이니 플랫폼 별로 type을 지정해서 관리하면 해결됩니다.

 

하지만 uid는 type이 있어도 보안상의 리스크와 정책에 의해 데이터가 변경될수 있으므로 유저 식별데이터로 이메일 + 소셜Type을 사용하는 걸로 결정했었죠.

 

그러자 다음과 같은 상황에서 문제가 발생했습니다.

"만약 유저가 로그아웃을 한 뒤(디바이스 내장DB에도 소셜 정보가 없다고 가정) 다른 type의 소셜로그인을 시도한다면 실제로 중복된 계정은 아니지만 한 유저가 복수 계정 사용이 가능함"

 

이번에는 좀 더 명확하게 유저를 특정할 수 있는 게 필요 해 보입니다.

 

보통 결제시스템이 들어가는 서비스는 CS처리를 위해 전화번호는 입력 받은 후 따로 관리하게됩니다.

이러한 이유로 "미리"에서도 전화번호를 받는데 미리 받는 전화번호를 통해 유저 중복검사를 하니 100%까진 아니지만 높은 확률로 유저를 특정 할 수 있게 되었습니다.

 

 

📌 Login & Sign up Flow

• Splash
  • 대부분의 앱은 종료했다고해서 로그아웃이 되진않습니다. 앱 실행시 내장 데이터베이스에서 로그인에 사용되는 값을 저장하고있다가(ex. JWT accessToken) 다시 앱을 실행했을 때 로그인을 시도하는 로직이 진행되며 유저에겐 항상 로그인이 되어있는듯한을 경험을 주는데 이러한 로직이 수행될때 머물게 되는 화면을 스플래시 스크린이라고 합니다.
• Login
  •  (자동로그인 기능이 없다면) 토큰에 설정된 시간이 만료가 되어 사용할수 없거나 혹은 애초에 회원가입을 하지않아 값을 알수없는 경우 등 토큰발행을 시도해야하는 때에 필요한 화면입니다.  
• Sign up
  •   유저가 회원가입을 진행하는 화면입니다.

 

위의 플로우 대로 와이어프레임을 제작하면 회원가입은 아래와 같이 구성 할 수 있습니다.

 

'미리' 초기 회원가입 UI

이렇게 만들게되면 다음과 같은 문제점이 발생합니다.

• 피로도 증가
  
  • 포스텔의 법칙: UI/UX관점에서 유저가 입력해야할 정보가 한 페이지에 많이 존재하면 인지부하가 증가된다는 법칙입니다. 이러한 이유로 디자이너도 화면을 분할하는 방향으로 개선할 것을 주장했었습니다.
• 모호한 중복검사 타이밍
  • '미리'는 중복계정을 허용하지않습니다. 때문에 유저 중복검사를 필수적으로 하게되는데 이메일이나 전화번호 검사에서 이미 존재하는 유저임을 알면 회원가입시 필요한 추가 정보는 굳이 받을 필요가 없게 되지만 위의 화면대로라면 모든 정보를 입력해야 중복검사를 실시할 수있어 유저에게 필요없는 작업을 요구하는 셈이 됩니다.

---

 

 

 

 

회원가입 단계를 좀 더 세분화 하였고, 가입 도중 이미 가입된 유저라는 사실을 알게된다면 기존 계정으로 '로그인을 유도 하는 화면'으로 이동하도록 개선했습니다. 이로서 유저 입장에서는 불필요한 가입절차를 더 수행할 필요가 없어졌습니다!

 

보통 여기까지가 앱에 공통적으로 적용되는 로그인&회원가입의 기본 흐름이라고 생각됩니다.

---

 

여기서부터는 '미리'에서 추가로 진행되는 플로우를 정리한 글입니다. 

 

하지만 '미리'의 경우, 메인화면의 데이터들은 유저 위치를 기반으로 조회하기때문에 메인화면에 도달하기전에 위치를 설정할수있도록 관련 화면으로 라우팅을 시켜줘야했습니다.

 

보통 메인화면에 도달하기전까진 회원가입을 수행하는 단계라고 생각할수있죠. 하지만 위치설정을 한다는 것은 단순히 로그인 화면과 메인화면사이에 있다고해서 회원가입 플로우에 둘 순 없었습니다. 이유는 다음과 같습니다.

 

 

✍🏼  회원가입 절차가 너무 길어진다

 

 

와이어프레임의 회원가입 부분을 보면, 위치설정을하기전까지 이미 4개의 화면을 거쳐왔습니다.

그 뒤에 위치 설정 할 때도 또 4개의 화면을 거쳐야할텐데 만약 위치 설정 하기 전에 어떠한 이유로 앱을 끄거나 꺼지게되면 여태 입력한 데이터들은 서버에 저장하지않았으므로 모두 사라지게 되죠. 그러고 다시 접속한 후에 유저가 또다시 회원가입을 할때 가장 첫단계부터 입력하게된다면 앱에대해 불편하다는 이미지를 심어 줄 수도 있습니다.

 

 

✍🏼 회원 테이블과 회원위치 테이블은 분리되어있다

 

만약 회원가입 플로우에 위치설정을 하는 단계가 존재한다고 생각했을 때, 회원 정보를 서버로 보내는 타이밍은 언제가 가장 적절할까요?

일반적으론 회원의 정보를 모두 입력받아 회원을 등록할수있을 때, 다시말해 회원 테이블을 생성할수있을때가 가장 이상적이라고 생각을 합니다. 그런데 회원가입 절차에 회원정보를 받은 다음 위치를 설정하는 단계가 껴버리면 그만큼 서버에 데이터를 보내는 타이밍이 밀리게되 심지어 데이터들은 회원 테이블과 관계없는 '위치 설정 데이터'도 보내게 됩니다.

 

🤷🏻‍♂️ "그럼 회원가입정보를 입력했을때 회원테이블에 데이터를 넣고, 위치설정이 끝났을때 등록한 위치를 데이터에 넣고 메인화면으로 가면되지않나요?"

 

지금 회원가입정보를 모두 입력한 뒤에 위치설정을 하고있는데 어떠한 이유로 앱이 종료되었다고 생각해봅시다.
이미 회원테이블에 데이터는있는 상태이기때문에 다시 접속했을때, 서버는 회원데이터를 지우고난 후 다시 처음부터 가입을 진행해야하는 이상한 현상이 벌어지는 등 불필요한 단계가 추가되거나 버그를 야기할 수도 있습니다.

 

 

✍🏼 위치설정은 회원가입 이후에도 가능하다

 

사실 위치설정은 회원을 생성하는 것과는 전혀 관계가 없스빈다. 위치를 검색하고 등록하는 화면들은 회원가입후, 서비스를 이용하다가 위치를 변경하고싶을때 이동하게 될 화면과 동일합니다. 완전히 똑같이 기능하기때문에 위치 설정을 '회원가입'이라는 관심사의 일부분이라고 보지않고 '위치'라는 독립적인 관심사로 분리했습니다.

 

 

이렇게 회원가입에서 '위치'를 분리하고나니 이 화면에 진입하게 될 케이스를 결정해야했습니다.

 

 

체크가 되어있는 주소가 현재 활성화된 주소를 뜻한다.

 

 

처음에도 말했지만 앱의 메인화면에 들어오기전에 이미 등록된 주소정보가 있어야하고, 그 주소는 활성화가 되어있어야합니다.

그리고 홈화면의 상단 버튼안에 현재 활성화된 주소를 노출시켜줍니다.

 

그래서 "활성화 된 주소의 유무"를 기준으로 삼아

있다면 메인화면으로, 없다면 주소를 설정하는 화면으로 보내주는 기능을 추가 해 보았습니다.

 

그럼 아래와 같이 동작하게 만들수있습니다.

 

 

---

 

 

개인적으로 로그인&회원가입부분은 굉장히 고민하고 시행착오도 많았던 부분이었습니다.

플로우에 대해 정리해봤으니 다음엔 실제로 구현 부분을 간단히 코드와 함께 정리 해 보겠습니다.

긴 글 읽어주셔서 감사합니다!

*로고, 디자인 출처: 미리

이 글이 꼭 정답은 아닙니다. 잘못된 부분이나 부족한 부분을 알려주시면 학습 후 수정하겠습니다.