본문 바로가기
서비스 기획/바닥부터 이커머스 시스템 기획

03. 회원 플로우차트

2020. 12. 27.

1단계: 회원가입 플로우 분석

앞서 회원가입폼과 필수 입력 값을 정의하면서 회원가입 플로우를 분석했다. 언급한대로 회원가입 플로우는 고려해야할 사항이 많아서 다음과 같은 삽질을 했다.

  • 만 14세 미만은 회원가입 시 보호자의 동의가 필요하다는 사실을 몰랐다.
  • 만 14세 미만을 어떻게 걸러내지? (여기서 완전 멘붕이었다. 정석대로라면 휴대폰 본인인증으로 통신사로부터 생년월일을 검증받아야 한다.)
  • 다른 이커머스들을 살펴봤는데 천차만별이었다. 육육걸즈(카페24)는 생년월일을 직접 입력해야 한다. ssg과 무신사는 반드시 휴대폰 본인인증을 거쳐야만 한다. 쿠팡과 29cm는 본인인증 없이 가입은 할 수 있지만 주문서 작성 시 본인인증을 거친다. (여기서 기준을 잡고 필수 항목을 표로 정리했어야 했는데 정신없이 들락날락했다.)
  • 회원가입 시 반드시 본인인증을 받아야만 하는가? 왜 받아야할까? 14세 미만은 아예 온라인에서 전자거래가 불가능한걸까?

정보통신망법 제 23조제2항, 제3항에 따르면 서비스 본질의 기능을 수행하는데 필요한 개인정보만을 수집하는 것을 원칙으로 한다. 따라서 불필요한 '이용자 본인확인'을 강제하여 개인정보를 요구하는 것은 최소수집 원칙에 반한다. 이 때 만 14세 미만 아동 여부 확인은 다음과 같이 권고된다.

이와 같이 법령과 타사 케이스를 분석한 결과, 최소수집 원칙을 준수하면서 만 14세 미만 여부를 검증하는데 29cm의 회원가입 절차가 가장 이상적인 것으로 결론내릴 수 있었다.


2단계: 회원가입 플로우차트 그리기

가장 이상적이라고 판단내렸던 29cm의 케이스를 염두하면서 회원가입을 위한 최소한의 정보 수집, 법령 준수를 고려한 범용적인 회원가입 플로우차트를 그려보았다.

유효성 체크 단계에서는 프론트와 백엔드에서 모두 유효성 검증을 한다는 가정을 세웠다. 유효성 체크는 데이터 형식 체크/중복 체크/정합성 체크로 구분할 수 있다. 이 부분에서 어디서부터 백엔드가 검증하는지 고민을 많이 했는데 아래 이미지로 완전히 납득할 수 있었다.

출처: 신입 개발자를 위한 코드의 정석 (https://www.theteams.kr/teams/1092/post/67641)
출처: 신입 개발자를 위한 코드의 정석 (https://www.theteams.kr/teams/1092/post/67641)

 

신입 개발자를 위한 코드의 정석 by 주식회사 브랜디

Overview대학을 수석으로 졸업했지만, 정작 회사에서는 A부터 Z까지 제대로 할 줄 아는 게 없었습니다. 실수를 남발할 때마다 느꼈던 좌절감은 아직도 생생하지만 되돌아보면 그때의 삽질이 소중

www.theteams.kr

다음의 블로그 글도 참고했다. 결론은 다음과 같았다.

  • 프론트와 백엔드 양쪽에 모두 검증 코드를 작성한다.
  • 백엔드에 검증 코드를 작성 후, 백엔드 결과에 따라 프론트는 메세지만 노출한다.
 

프론트엔드에서"만" 유효성 검사가 문제인 이유

안녕하세요? 이번 시간엔 프론트엔드에서 유효성 검사가 문제인 이유에 대해 간단한 예제를 통해 소개하려고 합니다. 모든 코드는 Github에 있기 때문에 함께 보시면 더 이해하기 쉬우실 것 같습

jojoldu.tistory.com

회원정보 입력이나 약관동의 절차는 실제 화면에서 별도의 화면으로 구성할 수도 있고 입력 순서가 변경될 수 있다.

비슷한 이치로 본인인증 역시 생략되거나 순서가 변경될 수 있다. 처음에는 휴대폰 본인인증으로 시작하면 가입여부와 14세 미만 여부를 검증하고 들어가기 때문에 깔끔하게 걸러질 수 있겠다고 생각했다. 하지만 정보통신망법에 의거해 본인인증 강제 자체가 권고되지 않는다는 사실과 더불어 서비스의 성격에 따라 인증 방법이나 시점이 달라질 수 있음을 생각하게 되었다.

+남아있는 의문점은 시스템 알럿의 용도이다. 입력 필드의 경우 필드 하단에 메시지를 노출하는 것이 일반적이지만 종종 약관 동의도 시스템 알럿이 아니라 체크박스 하단에 메시지를 출력하는 경우가 있다. 정확히 시스템 알럿이 노출되는 시점과 용도를 알고 싶다. (가령 submit을 눌렀을 때라든지)

+ 다음은 지금 단계에서는 정의하지 못했지만 추후 추가할 내용이다. 아래 블로그에서는 유효성 검증 시점에 대해 세분화하여 분석했다. 에러 체킹/컬러/메시징으로 구분한 분석 기준을 참고하면 좋을 것 같다.

출처: 회원가입 폼 유효성 검증의 중요성 (https://brunch.co.kr/@rachelykim/10)

 

회원가입 폼 유효성 검증의 중요성

실제 서비스들 회원가입 입력 폼 Validation UX 리서치 | 2017년 이후로 삶이 바쁘다는 핑계로 글을 쓰지 못했습니다. 2019년 절반이 지나고 나서야 2017년부터 쓰려고 에버노트에 저장해두었던 제 글을

brunch.co.kr

마치며
정리해놓고 보면 아주 당연하고 기본적인 내용들 뿐이라 허탈하다. 이럴 때 나는 비슷한 연차의 기획자나 개발자를 교육해야 하는 상황이라고 가정한다. 교육을 통해 앞으로 사용할 용어를 통일하고 서로 배경지식의 눈높이를 맞춘다고 생각하면 청자의 입장에서 어떤 내용을 추가해야 할지 좀 더 구체적으로 와닿는다. '그거 알지?' 하고 넘어가서 생긴 커뮤니케이션 미스를 얼마나 호되게 겪었는지.. 그리고 이러한 과정이 문서화, 더 나아가서 커뮤니케이션을 위해 나의 생각을 말과 글로 전달하는 연습이라고 생각한다.
그리고 나에게는 일정 시점에서 끊고 다음 단계로 나아가는 힘도 필요하기 때문에 당장 미완성된 부분도 일단락하고 넘어가기로 한다.

추가적으로 로그인과 아이디/비밀번호 찾기, 비밀번호 변경, SNS 회원가입 등을 정의할 것.

+ 정책 설계 방법에 대해 더 자세히 알고 싶다면

 

기획자가 알아야 할 정책 설계 가이드: 회원 정책(템플릿 제공)

아직도 화면 중심으로 서비스를 기획하고 있다면 / 정책 설계의 4가지 요소

publy.co

 

댓글