이렇게 기획하면 안 돼요! #회원가입

Posted in Planning // Posted at 2020. 3. 18. 09:00

나도 한 IT서비스 기획자로서 완벽한(?) 서비스를 기획하고 싶지만 항상 마음대로 되지 않는다. 이유가 어찌 됐든 간에 자랑스럽기보단 부족하다는 생각에 부끄러울 때가 더 많다. 그만큼 완벽한 서비스를 기획하고 개발하는 것이 어렵다는 것을 잘 알고 있기에 타 서비스의 잘못된 부분을 언급하는 것은 항상 조심스럽다.
남 이야기할 것도 없이 나부터 잘해야 하니까! :(
그럼에도 불구하고 불편을 겪을 사용자와 이로 인해 회원 가입률이 떨어지고 있을 것이 염려되어 한 서비스의 회원가입 페이지에 잘못 기획된 부분을 이야기하고자 한다. 이 글은 비난의 목적이 아니라 개선을 통해 사용자에게 보다 좋은 사용자 경험을 제공했으면 하는 바램으로 작성하는 글임을 밝힌다.

 

'참 쉬운 회원가입'을 클릭하면, 아래와 같이 회원가입 페이지로 이동을 하게 된다.

 

평범해 보이는 회원가입 페이지인데...

 

자! 이제 이 서비스가 안내한 것처럼 '참 쉬운 회원가입'인지 한번 살펴보도록 하자.

 


아이디 및 비밀번호 입력 조건

 

아이디 및 비밀번호의 입력 조건이 언급되지 않은 상황에서 입력 후 포커스 아웃을 하면 다음과 같이 유효성 검사 메시지(Validation Message)를 통해 생성 조건을 확인할 수 있다. 그런데 생성 조건을 보면 대다수 사용자들이 입력 후 수정을 할 수밖에 없는 조건이다. 즉, 모든 사용자는 아이디와 비밀번호를 2번 이상 입력할 수밖에 없다. :( 

 

입력을 하고 나서야 그 생성 조건을 보여주면 어떻게 해요?
게다가 비밀번호는 문자 조합과 자릿수 기준을 서로 다른 Validation Message로 알려주다 보니 자칫 잘못하면 3번 이상 입력하는 상황이 발생한다.

 

그런데 아이디와 비밀번호 생성 조건을 살펴보면, 아이디는 6-12자의 영문, 숫자, 기호( - _ )만 사용이 가능하고 비밀번호는 반드시 8-20자 이내 숫자, 특수문자, 영문자 중 2가지 이상을 조합해야 한다고 한다. (굳이 이렇게 까지 복잡하게 만들어야 하는 이유는 뭘까 싶지만 사실 이유가 있긴 있었다. 물론 과거체다.)

아이디의 경우 기호를 제외하고 6-12자 이내 영문, 숫자 사용 가능으로 입력 박스(인풋 박스, Input Box) 하단에 설명 문구(Description Message)나 요새 구글 등이 사용하는 방식으로 입력 박스 내 설명 문구(Placeholder Message)와 라벨(Label)로 표시하고 자동 대문자 또는 소문자 입력 처리 및 12자 초과 입력을 막으면 혼동을 줄이며 쉽게 입력할 수 있다.

비밀번호는 8자 이상 문자, 숫자, 기호 사용 가능으로 안내하고 8자 이하 입력 시에만 입력 박스 하단에 Validation Message를 표시하면 좋을 것 같다.

 

(위) 입력 전  (아래) 입력 후
비밀번호의 Validation Message는 비밀번호 안전성 표시 위치에 다음과 같이 표시한다.


이렇게 이야기를 하면, 한국인터넷진흥원 KISA에서 제시하는 비밀번호 가이드라인을 언급하는 기획자들이 있을 것이다. (굳이 비밀번호 생성 조건을 복잡하게 만드는 이유이다.)

 

최소 길이
- 최소 10자리 이상 : 영어 대문자, 소문자, 숫자, 특수문자 중 2종류 문자 조합으로 구성
- 최소 8자리 이상 : 영어 대문자, 소문자, 숫자, 특수문자 중 3종류 문자 조합으로 구성

추측하기 어려운 비밀번호 사용
- 일련 번호, 전화번호 등 쉬운 문자열이 포함되지 않도록 함
- 잘 알려진 단어, 키보드 상에서 나란히 있는 문자열이 포함되지 않도록 함

주기적 변경
- 비밀번호에 유효기간을 설정하고 최소 6개월마다 변경 

 

이 기준은 미 국립표준기술연구소(NIST, National Institute of Standards and Technology)에 근무하던 빌 버(Bill Burr)가 2003년에 해커로부터의 비밀번호 해킹을 어렵게 하기 위해 만든 규칙으로 동 기관에서 발간한 '전자인증 가이드라인(Electronic Authentication Guideline) 문서에 담겨있던 규칙을 KISA에서도 인용한 것이다.


그런데 2017년 NIST에서 새로 발간한 디지털 아이덴티티 가이드라인(Digital Identity Guidelines)에서 복잡한 조건들로 인해 사용자들이 비밀번호를 제대로 관리하지 않아 오히려 보안성이 떨어져 이용자 보호 측면에서 실익이 없다고 인정하고 비밀번호를 여러 문자로 조합하고 일정 기간마다 바꾸도록 한 내용을 삭제하였으며 최근 빌 버 또한 이 규칙을 만든 것에 대해 후회한다고 밝혔다.
 
따라서 KISA도 이 새로운 디지털 아이덴티티 가이드라인 정책을 준용하여 아래와 같이 비밀번호 가이드라인을 수정하였는데 대다수 기획자들이 이 정책의 변화를 인지하거나 반영하지 못하고 있는 것 같다. (그리고 가이드라인은 가이드라인일 뿐이다.)

 

최소 길이
- 최소 10자리 이상 : 문자 조합 필요 없음
- 최소 8자리 이상 : 문자, 숫자, 기호 중 2종류 조합 구성

주기적 변경 조건은 삭제되었다. 

 

여기서 잠깐! 구글의 비밀번호 생성 조건을 살펴보면 다음과 같다.

비밀번호 필수 조건
비밀번호는 8자 이상이어야 하며 문자, 숫자, 기호(ASCII 표준 문자만 해당)를 조합하여 만들 수 있습니다. 악센트 및 발음 기호는 지원되지 않습니다. 

다음과 같은 비밀번호는 사용할 수 없습니다.
- 매우 취약한 비밀번호 (예:password123)
- 내 계정에서 이전에 사용한 적 있는 비밀번호
- 공백으로 시작하거나 끝나는 비밀번호

 

참고로 KISA는 허위정보로도 가입이 가능한 해외 서비스와 달리 대다수 국내 서비스가 중요 개인정보를 수집 및 관리하는 경우가 많다 보니 여전히 이용자 환경에서 엄격한 패스워드의 조합 규칙이 실질적인 보안 효과가 있다는 입장이다.

그래서 나는 어떻게 기획하냐고? 나는 구글의 비밀번호 생성 조건과 동일한 조건(8자 이상 문자, 숫자, 기호 사용 가능)으로 기획을 하고 있다.

 


라벨 처리

 

Placeholder Message로 Label을 처리하다 보니 입력 시 Label이 보이지 않는다. 회원가입의 경우 입력값이 많지 않아 Label이 없어도 혼동할 가능성이 적지만, 입력 박스가 많은 페이지에서 수정이 필요한 경우 Label이 보이지 않으면 해당 입력 박스의 입력 항목이 무엇인지 혼동할 가능성이 있기 때문에 입력 박스 좌측 상단에 Label을 표시하는 것이 좋다.

 


입력 박스 초과 입력 제한

 

대다수 입력 박스에는 입력 글자수 제한이 있다. 해당 서비스의 경우에도 아이디는 12자, 비밀번호는 20자, 이름은 10자, 휴대폰 번호는 11자, 이메일은 넣어보니 없는 것 같군. 그런데 입력 박스에서 제한 글자수 이상 입력을 막지 않으면 어떻게 된다? 아래와 같이 된다. :(

 

라벨이 문제가 아니였군! :(

입력 글자수 제한이 있는 경우, 반드시 입력 박스에서 초과 입력을 막아야 한다. 그래야 사용자가 초과 입력을 빠르게 인지하고 불필요한 입력이나 수정을 막을 수 있다. 
그리고 이메일은 형식 조건만 있지 글자수 제한은 없는 것 같지만 사실 주소 앞자리 64자 + @ + 도메인 255자로 최대 320자를 넘을 수 없다.

 

조금 더 센스 있는 기획자라면, 휴대폰 번호나 카드번호, 연월일시 등과 같이 일정 형식이 있는 인풋 박스의 경우 Input Masking 처리를 통해 사용자가 형식에 맞게 입력하고 그 입력값을 삭제 버튼을 통해 초기화할 수 있도록 지원해주면 좋다. (난 기획자니까 정규식까진 언급하지 않는 걸로... 욕먹을 느낌 아니까... )

 

이런 건 센스이자 디테일이다.

 


인증하지 않은 이메일

 

사용자 고유 식별 아이디가 있음에도 불구하고 핸드폰 번호는 인증을 하는데 이메일은 인증을 하지 않고 그냥 입력만 받는다. 그런데 Placeholder Message에 이메일이 아이디 찾기에 사용된다고 하여 살펴보니 아이디 찾기 및 비밀번호 찾기는 물론 서비스 메일도 발송한다. 실수나 고의로 잘못된 이메일 주소 또는 타인의 이메일 주소를 입력하면 어떻게 될까 싶어 테스트를 해보니 타인의 이메일 주소로 엄청난 스팸 폭탄을 보낼 수 있다. :(
가끔 핸드폰이나 이메일 인증 절차가 번거롭고 불편하다 보니 회원 가입률이 떨어질 수 있다며 이를 꼼수로 처리하려는 모습들이 보인다. 그런데 이렇게 꼼수로 처리했을 때 발생하는 사용자의 불편함이나 운영 상의 문제들이 눈덩이처럼 더 큰 문제를 불러일으킬 수 있다는 점은 인지를 못하는 것 같다. 회원 가입률이 떨어질 것 같다면 가장 필수적인 정보 인증을 회원 가입 시 받고 서비스 제공을 위해 필요한 상황에서 추가적인 정보 수집 및 인증을 받을 수 있도록 설계하자. 사용자는 바보가 아니다.

 


인증 버튼 중복 클릭 제한

 

이메일이나 SMS 등으로 인증 메지시를 발송하는 버튼 등은 타인의 이메일이나 핸드폰 번호를 입력해 중복 발송하여 타인에게 불편을 초래하거나 회사 입장에서 비용을 낭비할 수 있기 때문에 발송 후 5분 대기 또는 발송 횟수 제한 등의 중복 발송 제한을 반드시 걸어야 한다. SMS 발송 비용을 무시하지 말라! 그런데 해당 서비스, 중복 클릭 제한이 없다! @.,@;;

 

순식간에 SMS를 연달아 수신했다.

 

인증 메일이건 SMS를 발송할 때에는 반드시 발송 후 대기 시간이나 발송 횟수 등의 제한을 두어야 한다.

 


데이터 유효성 체크

 

이미 회원가입을 했지만, 이 글을 작성하기 위해 다시 회원가입을 시도하며 이메일 인증을 하지 않았으니 혹시나 하는 생각에 동일한 이메일 주소를 넣어봤는데 형식 유효성만 체크하는지 통과가 된다. 그렇다! 서로 다른 계정임에도 불구하고 동일한 이메일을 등록해서 사용할 수 있다는 이야기다. 이메일 형식은 체크하지만 이메일 중복 여부는 체크를 하지 않는다니 다시 한번 놀랍다. 이메일도 데이터 유효성을 체크해서 중복 시 중복 여부 안내를 통해 다른 이메일 주소를 입력받았어야 했다.

데이터 유효성 체크를 이야기하고 있으니 여기서 잠깐 입력값의 유효성 체크에 대해서 살펴보자.

 

 

나는 회원가입 페이지는 사용자들이 또는 한 사용자가 빈번하게 접근하는 페이지가 아니기 때문에 서버 트래픽이 엄청나게 발생하지 않아 가입하기(Submit) 버튼 클릭 시, 팝업이나 Validation Message로 데이터 유효성을 안내하기보다는 이메일 입력 박스에서 포커스 아웃을 트리거 삼아 즉시 데이터 유효성 여부를 체크 및 안내하는 방식으로 기획을 한다.
서버 트래픽이나 개발 편의를 생각하면 아이디나 이메일, 핸드폰 주소를 모두 입력한 다음 Submit 버튼 클릭을 통해 API를 한 번만 호출하면 좋긴 하지만 사용자 입장에서는 입력 시 바로 사용 가능 여부를 확인하는 것이 편하기 때문이다.

 


약관 및 그 동의 처리

해당 서비스는 선택 약관만 표시하고 필수 약관은 가입 시 동의한 것으로 간주하고 있다.
약관 동의 절차가 사용자 가입 시 불편하다며 이를 간소화하거나 무시하는 경향이 있는데 이는 사용자를 기만하는 행위라고 생각한다. 사용자들이 서비스 정책의 내용을 명확하고 쉽게 확인하고 이해할 수 있도록 UI와 약관 내용을 제공해야 한다.
금융 서비스는 금융법과 약관규제법 등 관련 법의 강력한 제재를 받는데 IT서비스는 제재가 미비하다 보니 약관 작성 및 동의 절차 등에 소홀한 경향이 있다. 소프트웨어가 세상을 집어삼키는 시대에 사용자 보호를 위해서라도 보다 엄격한 관리 및 제재가 필요해 보인다. 다른 회사의 약관을 수정해서 사용하다 보니 미쳐 회사명을 다 수정 못 해 타사의 사명이 버젓이 표시된 것을 보고 있자면 그냥 실소밖에 나오지 않는다. 그나마 이 정도면 애교라지.

 


버튼 활성화 처리

 

필수 입력값을 입력하지 않고 [동의하고 가입하기] 버튼 클릭 시, 모든 필수 입력 박스의 Validation Message가 동시에 표시된다.
필수 입력값을 모두 입력한 경우에 한해 [동의하고 가입하기] 버튼을 활성화 하자!

 

나는 버튼 활성화 전에는 버튼 메시지에 활성화 조건을 안내하고 모든 필수 입력값을 입력한 경우에 버튼을 활성화한다.

 

 


필수 입력값 표시

 

모든 입력값이 필수 입력값인 경우에 굳이 모든 입력 박스마다 필수 입력값이라는 표시를 할 필요가 있을까?
위와 같이 필수 입력값을 모두 입력한 경우에 [가입하기] 버튼을 활성화하는 것만으로도 사용자는 충분히 인지할 수 있으니 (필수)라는 메시지는 모두 제거해도 된다. 
설령 필수 및 선택 입력값이 혼재되어 있다면 상단에 ' 필수 입력 항목'을 안내하고 필수 입력 항목에만 을 표시하거나 입력 박스가 많아 한 페이지에서 확인이 불가능한 경우에는 선택 입력값에만 (선택 입력) 또는 (옵션) 등으로 표시하는 것이 좋다.

 


페이지 이동 버튼 제공


잘못 클릭하거나 착오로 이미 회원가입을 했음에도 불구하고 회원가입 페이지로 온 경우 로그인 페이지로 이동할 수 있는 경로를 제공해야 하는데 그런 버튼이 없다. 그래서 다시 홈 메인으로 이동했다가 로그인 버튼을 클릭해서 로그인 페이지로 이동을 해야 한다. 이런 기본적인 버튼도 제공하지 않는다니 놀라울 따름이다.
 

 


 

얼핏 보면 인풋 박스도, 버튼도, 기능도 적다 보니 로그인 및 회원가입 페이지를 기획하는 것이 쉽다고 생각하는 사람들이 있다. 그런데 그 단순해 보이는 로그인 및 회원가입 페이지도 사용자에게 더 좋은 UIUX를 제공하기 위해서는 고민해야 할 것들이 엄청 많다.

자! 이제 자신이 기획한, 또는 기획하고 있는 서비스의 로그인 및 회원가입 페이지를 다시 한번 살펴보도록 하자!
그래서 나는 어떻게 회원가입을 기획하냐고?

 

 

 

P.S. :
제가 잘못 이해 또는 오해하고 있는 부분이 있거나 관련해서 더 좋은 기획이 있다면 댓글로 말씀 부탁드립니다. 
역시 내 것 기획하는 것은 너무 어려운데 남의 것 이야기하는 것은 참 쉽네요. :(
다음에는 로그인이나 한번 살펴 볼까!?!?

author image
'세균무기, 지구별에 흔적을 남기다!' 블로그를 운영하는 세균무기입니다.
법학과 행정학을 전공한 IT서비스 기획자이자 프로덕트 매니저이며, 변방의 한 블로거입니다. IT와 스타트업에 관심이 많으며 여행과 애플 제품, 블랙아이드피스의 음악, 커피를 격하게 애정합니다.


  1. BlogIcon 명지대학교 미슐랭

    구독 꾸욱 눌렀습니다~ 제 블로그에도 함 놀러오셔요! 소통해여 우리~

  2. 굿굿

    이런 주제 좋습니다!

    회원가입도 뜯어보면 이야기할 주제가 다양하네요 ㅠㅠ
    회원 정책, 회원 등급, 휴면회원/탈퇴회원 등등 머리가 어지러워집니다

    네이버나 카카오로 가입하기 등 소셜 로그인은 어떻게 생각하시는지 궁금합니다
    보안이 중요한 금융 서비스에서는 사용하기 어려울 것 같지만.. 또 가입하기 편하긴 하니까요

    • BlogIcon 세균무기

      서비스 도메인 및 그 특성에 따라 B2C 회원도 14세 미만과 그 이상, 18세 미만과 그 이상, 14세 미만과 18세 미만의 경우 법정대리인의 동의 확인 절차, B2B 기업 고객 등 다양한 회원의 종류가 있을 수 있고 이에 따른 가입 정책 및 절차, 인증 방식 등을 고려해야 하며, 회원의 등급을 둘 수 있고, 휴면 및 탈퇴 회원의 처리 정책 및 그에 따른 데이터 삭제, 이관 처리 등 각 한 꼭지만으로도 수 시간을 이야기할 수 있을 것 같네요. ^^;;

      카카오싱크나 네이버 아이디로 로그인(네이버는 이를 '네아'라고 부르는 @.,@) 등의 SSO 적용 시 각 SSO의 특징과 차이로 인해 프런트와 백엔드, DB에서 필요한 처리 및 절차, 고려사항 등은 생각만 해도 머리가 아프네요. ㅠㅠ
      참고로 네아는 연동 시 던져주는 이메일 주소가 변경될 가능성이 있는 로그인 연동만 염두한 SSO이지만, 카카오는 회원가입 및 로그인을 모두 고려하여 자사 서비스 정책도 카카오 측 페이지에서 처리할 수 있게 지원하는 등 참 신경을 많이 썼다는 점이 인상 적인데 이런 SSO들의 차이 때문에 SSO를 제대로 적용한 IT기업을 찾기가 어려울 정도입니다. 네이버 보고 있나!

      그리고 금융 서비스는 강력한 보안이 필요하다 보니 2FA, FDS 적용 등 수많은 보안 강화 조치들 때문에 로그인/회원가입만 놓고 봐도 그 난이도가 훨씬 높죠. @.,@;;

      암튼 모두 간단히 다룰 주제들이 아니다 보니 틈나는 대로 한 꼭지씩 다뤄보도록 하겠습니다. OTL

  3. 비밀댓글입니다

    • BlogIcon 세균무기

      말씀하신 내용을 보고 깜짝 놀라 제가 비밀번호의 형식이 아닌 데이터 유효성 체크를 서버 통신 없이 프런트에서 가능하다고 작성했는지 글을 다 읽어 봤는데 그런 실수는 안 했네요. ㅎ

      이 글이 로그인 페이지가 아닌 회원가입 페이지를 가지고 이야기를 하다 보니 형식 유효성 체크만 하면 됐고, 로그인 페이지를 가지고 이야기를 했다면 말씀하신 것처럼 비밀번호는 종단간 암호화가 필요하기 때문에 반드시 Submit 버튼 클릭 시 서버 통신을 통해 데이터 유효성을 체크해야 합니다.

  4. 굿굿

    결국 정해진 시간내에 필요한 만큼 잘 녹여내는 것이 좋다는 생각이 드네요
    기회될 때 잘 써먹겠습니다~

    답변 감사합니다

  5. r__a65__

    글 잘보았습니다! 어떻게보면 단순하게도 볼 수있는 폼이 기획자 센스에따라서 이렇게 달라지네요! 혹시 기술하신 이런 작업을 어떻게 문서화하고 개발자와 커뮤니케이션하시는건가요?? 이런류의 작업을 기술할 문서가 있는지 궁금합니다.

    • BlogIcon 세균무기

      저는 페이지나 기능마다 일일이 설명하기 어렵기 때문에 기획서 앞부분에 UI Component Guide 또는 Common UI/UX Definition라는 제목의 장을 따로 만들어 디자이너와 개발자에 전달하고 있습니다.
      우측 사이드바에 있는 '서비스 기획자를 위한 가이드' 배너 클릭해 제가 예전에 작성했던 기획서를 보시면 조금이나마 도움이 되실 것 같습니다.

    • r__a65__

      감사합니다! ^^

  6. JJJ

    위에 이메일 도메인 자동완성은 앱에서만 사용 가능한 기능아닌가요 웹에서도 제공해주는 곳을 못봐서요
    그리고 가입 후 본인인증이 있는 서비스는 인증을 여러번 하게 되는 느낌이라 위에 말씀하신 ‘인증하지 않은 이메일’ 이부분이 항상 고민인데 좋은 방법이 있을까요

    • BlogIcon 세균무기

      웹에서도 이메일 자동 입력 및 자동완성 기능의 지원이 가능합니다.

      서비스의 도메인이나 특성, 정책 등에 따라 회원가입 시 필요한 필수 인증이 다릅니다. 그것이 이메일 인증이 될 수도 있고 어떤 경우에는 모바일 점유 인증, 휴대폰 본인 인증 등이 될 수 있겠죠. 회원가입 시 꼭 필요한 인증을 제외한 기타의 인증이 도대체 왜 필요한지 고민을 해보신 다음 서비스 이용 중 꼭 필요한 순간에 받아도 됩니다.
      말씀하신 내용을 보면 휴대폰 기반의 인증 처리 후 이메일을 추가 수집하시는 것 같은데 그런 경우 서비스 내 결제 알림이나 마케팅 용도로 필요하신 것으로 예상되는 바 결제 시 수집을 하시거나 추가적인 혜택을 제공하며 수집 및 인증을 받으시는 등 수집 및 인증 단계를 회원가입 시가 아닌 다른 플로우에서 처리하시는 것을 고민해보시면 좋을 것 같습니다.
      어쩔 수 없이 회원가입 시 중복 인증이 필요하다면, 그 필요한 이유를 사용자에게 잘 설명해보세요.

  7. 밧슈

    제가 매번 가장 신경쓰는 페이지가 회원가입인데 이렇게 다루어 주시니 감사하네요.^^

  8. hue

    활동중인 웹기획자 방에 공유되었길래 봤더니 세균무기님 글이었네요.
    언제나 좋은 글 잘 보고 있습니다 (팬이에요 소곤소곤)
    로그인 편도 기대됩니다! ㅎㅎ

    • BlogIcon 세균무기

      글의 취지를 떠나 누군가에겐 도움이 되는 글이었을지도 모르겠는데 누군가에겐 악몽이 되어버렸을 것 같아 마음이 편치만은 않네요.
      부족한 글 좋아해 주셔서 고맙습니다.

  9. gm

    안녕하세요. 글 잘 읽었습니다. 제가 기획자분들을 많이 접해보지 못해서 궁금한게 몇 가지 있습니다.

    기획자 포지션에 계신데, 첨부하신 작업물은 디자이너없이 직접 만드셨는지 궁금합니다.
    기획 - 디자인 - 개발 프로세스로 프로젝트를 진행하실 때 기획자가 해야하는 일의 범위가 어디까지라고 생각하시는지 궁금합니다.

    • BlogIcon 세균무기

      저는 주로 PPT로 스토리보드를 작성하고 있기 때문에 디자이너 없이 직접 작성하였습니다.
      '기획자는 R&R마저 기획해야 한다.'라는 글에서 언급한 것처럼 10여 개가 넘는 회사에서 기획자로 일을 했지만 회사마다 기획자에게 요구하는 업무와 스킬이 너무 상이하다 보니 회사에서 기획자에게 요구하거나 또는 필요로 하는 업무는 일단 다 했습니다만, 제가 생각하는 기획자로서의 일의 범위는 '서비스 기획이란?', '기획자가 무슨 일을 하는지 모르겠다고?', '기획자는 R&R마저 기획해야 한다.'와 같은 글을 참고해주시면 좋을 것 같습니다.

submit