본문 바로가기
Planning

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

by 세균무기 2020. 3. 18.

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

반응형

댓글39

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

  • 굿굿 2020.03.19 23:32

    이런 주제 좋습니다!

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

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

    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.03.20 00:13 신고

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

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

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

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

  • 익명 2020.03.20 07:15

    비밀댓글입니다
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.03.20 08:33 신고

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

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

  • 굿굿 2020.03.21 20:48

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

    답변 감사합니다
    답글

  • r__a65__ 2020.03.25 08:17

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

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.03.25 13:20 신고

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

    • r__a65__ 2020.03.26 16:21

      감사합니다! ^^

  • JJJ 2020.03.25 08:47

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

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.03.25 13:40 신고

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

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

  • 밧슈 2020.03.25 14:30

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

  • hue 2020.03.26 09:44

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

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.03.26 10:17 신고

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

  • gm 2020.04.02 00:48

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

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

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2020.04.02 01:33 신고

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

  • 김개미 2020.10.17 20:46

    많은 도움이 되었습니다. 감사합니다!
    답글

  • J 2021.04.05 10:32

    안녕하세요!

    웹포트폴리오를 제작중인 개발자 취준생입니다.
    회원가입 기능을 기획중에 좋은 글을 읽게되어 먼저 감사드립니다.

    다름이 아니라 제 포스팅에 이 글의 일부를 인용하고 싶은데(물론 링크는 남기겠습니다!)
    허락 해주실 수 있을까요?

    또 로그인 편도 참고하고 싶은데 제가 못 찾는건지 글이 없어 아쉽네요ㅜ
    다시 한번 좋은 글 감사드리며
    좋은 하루 보내세요~!






    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2021.04.05 20:59 신고

      공개적으로 발행한 글이니 편하게 인용 및 링크를 하셔도 괜찮습니다.
      요즘 이런저런 핑계로 블로깅을 하지 않다 보니 다시 글을 쓰기가 너무 힘드네요;;;

    • BlogIcon J 2021.04.05 22:25

      감사합니다!

      봄이라 더 나른하셔서 그럴수도 있겠네요ㅋㅋ

      부디 이렇게 좋은 글 더 많이 써주시길 바라겠습니다ㅎㅎ

  • hh 2021.09.26 18:37

    안녕하세요 세균무기님! 항상 글 잘 보고있는 주니어 기획자입니다.
    글 중에서 이메일 중복체크 관련해 헷갈리는 부분이 있어 댓글 남깁니다~

    디스크립션을 보니, 이메일 중복체크(이미 사용중인 이메일입니다)도 유효성 체크 시점이 "입력 즉시"로 기획하신 것으로 보이는데,
    기존회원 db와 비교해야 하는 이메일 중복체크도 서버통신 없이 입력 즉시 확인 가능한 사항이 맞는거죠??

    제가 기획할 때도 이메일 중복체크 역시 입력 즉시 사용자에게 피드백을 주는 식으로 기획했는데, 프론트 개발자께서 이메일 중복체크는 서버를 통신해야 하는 사항이라 입력 즉시 체크가 불가능하다고 말씀하셔서 [가입 완료] 버튼 클릭 시에 체크되는 것으로 합의를 봤던 적이 있습니다. 제가 겪은 상황이 세균무기님의 기획서와는 상반되는 것 같아 질문드립니다~!
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2021.09.26 21:34 신고

      이메일 중복 사용 여부는 당연히 유저 테이블을 조회해야 하니 API 통신이 필요합니다.
      다만, 회원가입 시 정보 입력 및 약관 동의 등을 한 페이지에서 처리하는 경우 스크롤이 생성되어 페이지 상단에 위치한 이메일 인풋 박스의 Validation Message를 사용자가 인식하기 어렵고 상단으로 이동하여 수정하는 것이 UX적으로 불편하기 때문에 제 경우에는 이메일 인풋 박스에서 포커스 아웃을 트리거 삼아 서버 통신하여 실시간 데이터 유효성을 체크하는 것을 선호하는 편입니다.

  • Favicon of https://starsu.tistory.com BlogIcon starsu 2022.03.19 21:04 신고

    안녕하세요, 글 잘 보았습니다! 혹시 회원가입 후 자동로그인 되는 것에 대해 어떻게 생각하시는지 궁금합니다. 자동로그인 편해서 오히려 이탈률이 줄어들 것 같은데 업계에서는 지양하는지도 궁금합니다.
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.03.20 10:34 신고

      회원가입 후 자동 로그인이 UX적으로 편하다는 의견에는 동의합니다만, 이탈률이 줄어들 것 같다는 의견에는 크게 동의하기는 어려울 듯싶습니다.
      IT업계에서 지양하는지는 사실 관계가 없고 회원가입이나 이용계약의 체결 시점을 사용자에게 명확하게 안내(통지 등의 수단을 포함)해야 하고 이를 이용약관에 명시해야 합니다. 이에 따라 회원가입 완료 후 표시되는 회원가입 완료 페이지로 갈음 처리하거나 이메일, 문자 등의 통지를 발송합니다.
      때문에 자동 로그인을 지원하더라도 가입이 완료되었다는 완료 페이지를 표시하며 수 초 경과 후 자동 로그인으로 처리하는 것이 관련 법을 준수한 기획이라고 생각합니다.

  • 기획공부 2022.03.25 03:06

    안녕하세요! 저는 3년차 서비스 기획자 입니다. 1년 전 디테일한 SB 작성을 못해서 개발팀과 어려움이 있었습니다. 세균무기님 블로그 참고하여 문서에 대해 많이 고민하고 SB를 작성한 뒤로는 개발팀장이 따로 불러서 놀랄 정도로 성장했다고 칭찬받았습니다. 이제는 제가 이직을 하게되어 블록체인 영역으로 가게 되었습니다. 세균무기님 이력 중 다수의 블록체인 플랫폼 기획 경험을 해보신것으로 알고있는데요. 새로운 회사에 가기 앞서 공부할 목적으로 블록체인 플랫폼 SB, 정책정의서 등 실무에 도움되는 문서를 공유받을 수 있을까요~?
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.03.25 09:11 신고

      찾아보니 (컨플루언스 등에 기록한 경우에는 별도 정책서 파일을 가지고 있지 않다 보니) 정책서는 없고 스토리보드만 가지고 있네요. 이메일 주소 알려주시면 보내드리도록 하겠습니다.

  • 익명 2022.03.25 10:02

    비밀댓글입니다
    답글

  • Tachibana Hinata 2022.06.08 15:48

    회원가입도 이것저것 생각하면 할게 많은 부분인데,

    현실 개발은 "두시간이면 작업 끝내지?"
    개발일정 3h
    (개발자단위테스트, 문서작업 포함)
    답글

  • 020 2022.06.20 11:37

    안녕하세요 주니어기획자입니다. 기존 서비스에서 비밀번호를 8자리로만 설정해두었다가 보안취약성 항목으로 판단되어 KISA 매뉴얼 대로 2종류이상,10자리 비밀번호 설정을 변경하려합니다. 기존 유저들의 비밀번호를 변경하도록 해야 하는데, 어떤 방법이 좋을까요?
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.06.20 12:03 신고

      30일 이상 사전 고지 및 공지 후 로그인 시 변경되는 형식에 맞게 신규 비밀번호로 변경할 수 있는 프로세스를 제공하면 됩니다.

    • BlogIcon 020 2022.06.20 12:11

      답변 감사드립니다..!!기존 서비스 특성 상 자동로그인되는 서비스라 회원이 평소에 비밀번호를 입력해야하는 일이 적어서 기존 비밀번호를 까먹은 회원들이 많을 것이라고 생각됩니다..이런 상황때문에 비밀번호 변경 시 기존 비밀번호 입력 절차를 생략해도 될까요? (해당 상황에만)

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.06.20 12:18 신고

      자동 로그인을 지원하더라도 세션이나 토큰 만료 시간이 있을테니 만료 시 해당 프로세스를 진행하면 되고 기존 비밀번호는 반드시 확인하고 신규 비밀번호로 변경할 수 있도록 해야 합니다.

    • BlogIcon 020 2022.06.20 12:22

      자꾸 질문드려 죄송합니다..ㅠㅠ(사수가 없어서..) 자사 서비스에 현재 자동로그인 만료 시간이 딱히 없습니다. 이럴 경우에 앱 실행 시 비밀번호를 변경하도록 프로세스를 제공해도 될까요..?

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.06.20 12:37 신고

      어떤 도메인의 서비스인지, 서비스를 제공하는 환경이나 설계 방식 등에 따라 기획이 다를 수 있기 때문에 기획에 왕도나 정답이 없다고 하는 것인데 제가 정확히 파악이 안 된 서비스에 디테일한 조언을 하기에는 조금 어려움이 있을 것 같네요;;;

    • BlogIcon 020 2022.06.20 13:38

      답변 감사합니다

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.06.20 13:58 신고

      급하시면 연락주세요. 제 연락처는 010-9636-7152 입니다.

    • BlogIcon 020 2022.06.20 14:24

      작성해주신 글과 댓글로 충분한 도움이 된 것 같습니다. 감사드립니다..