[웹기획가이드] 회원가입 서비스 ② - 본인인증, 왜 해야할까?

야메군
2021-01-12
조회수 3028

안녕하세요? 야메군 입니다.

지난 주, 회원가입 서비스 ①편 - 정보수집 구조의 설계 편을 정리해봤는데요, 오늘은 조금 더 깊게 들어가서 왠지 모르지만 회원가입의 레귤러 멤버가 된 듯한 본인인증을 왜 해야 하는 지 대해 한 번 정리해볼까 합니다. 


웹/모바일을 포함하여 상당 수의 서비스들은 휴대폰 통신사를 통하는 휴대폰 본인인증이나 신용정보 회사를 거치는 실명인증, 혹은 휴대폰의 존재유무를 따지는 휴대폰 인증1이나 이메일의 실존 여부를 따지는 이메일 인증 중 한 가지 정도는 회원가입 영역에 적용해두고 있습니다.2 그런데 이들 인증서비스를 왜 적용해야 하는지 고민해보신 적 있나요? 아무런 이유없이 적용하진 않았을 거 같은데... 방식이나 인증을 위해 필요한 정보의 내용은 다르지만 공통적으로 뭔가를 인증한다는데 그 목적을 가지고 있습니다. 아이핀이나 마이핀 인증은 생각하지 말죠.


휴대폰 본인인증? 실명인증?


일단 그 전에 인증방식의 유형을 간단하게 살펴보죠. 먼저 가장 많은 정보를 요구하는 휴대폰 본인인증 입니다. 휴대폰 본인인증은 국내 3대 통신사의 가입자 정보를 비교, "네가 정말 이 휴대폰의 소유자인지를 검증할꺼야."를 알아보는 방식입니다. 이를 위해 이름과 내/외국인 정보, 생년월일, 성별, 휴대폰 번호에 보안숫자 입력 단계를 거쳐, SMS로 발송되는 6자리의 인증번호 검증까지 이중의 엄격한 검증단계를 거칩니다. 때문에 휴대폰 소유자의 개인정보를 알고 있다 손 치더라도 소유자의 휴대폰을 가지고 있지 않은 경우 인증을 통과할 수 없죠. 이러한 엄격성 탓에 위 네 가지 인증방식 중 가장 신뢰도가 높은 편이나 휴대폰을 보유하지 않은 사람은 휴대폰 보인인증을 통과할 수 없습니다.


실명인증 서비스를 제공하는 코인거래소 빗썸 (bithumb.com)


두 번째 실명인증 방식은 한국신용평가정보(한신평)나 서울신용평가정보(서신평)를 거치는 인증방식으로 이들 기관에 등록된 이름과 생년월일 그리고 성별 검증을 통해 "살아있는 사람인가?"를 따지게 됩니다. 실존인물 여부만을 따지기에 당사자인지는 확인할 수 없으며, 금융거래 정보3가 없는 미성년자의 경우 실명인증을 통과할 수 없다는 단점이 있습니다. 더불어 개인정보만 알고 있다면 당사자가 아니더라도 인증 통과가 비교적 쉬운 축에 속합니다.


 

휴대폰 본인인증

실명인증

휴대폰 인증

이메일 인증

 인증방식

개인정보+인증번호 

개인정보

인증번호

인증번호4

 인증기관

휴대폰 통신사 

신용평가기관 

 실존인물 여부

X

X

 유료여부

X

 제약사항

휴대폰 미보유

금융정보 미보유

휴대폰 미보유

이메일 미보유

 보안성

★★★ 

★★

 ★☆


세 번째로 휴대폰 인증입니다. 점유인증으로도 불리는 이 방식은 통신사나 신용평가기관과 무관하게 "이 번호가 진짜 있는 번호야?"를 따지는 방식입니다. 통상적으로 4자리에서 6자리의 숫자를 SMS로 발송하고 이를 가입 시 입력하여 검증하는 방식으로 보안성에 근간을 두기 보다는 휴대폰 번호의 진성여부를 따지는 방식입니다.


마지막 네 번째 이메일 인증은 "이 이메일이 진짜 있는 이메일이고 니꺼가 맞아?"를 따지는 방식입니다. 이 방식은 휴대폰 인증처럼 단순히 진성 이메일 주소 여부만을 따지는 것이 아니라 이메일을 제공하는 네이버나 다음, 구글 서비스의 가입 보안 프로세스에 기대는 측면이 있습니다. "어짜피 얘네들도 가입받을 때 인증하니까 가입 당사자가 쓰는 이메일일 가능성이 높잖아?"를 고려하는 것이죠. 다만, 가입자가 실제로 쓰는 이메일인지는 알 수 있지만, 그 가입 당사자가 김개똥인지 신짱구인지는 알 수 없다는 맹점이 있습니다.


왜 인증을 적용해야 하는 걸까?


온라인 서비스 가입 시 제공하는 이들 네 가지의 인증방식은 서비스의 특성에 따라 적용여부가 갈리게 되는데요, 보통 어떤 인증방식을 제공할 지에 대한 고민을 하는 경우는 많지만 "가입 시, 왜 인증을 적용해야 할까?"를 고민하는 경우는 많지 않습니다. 통상적으로 인증을 거치는 이유는 두 가지 정도 입니다. 하나는 가입자의 본인 여부 확인이 필요한 경우와 진정 정보의 수집 목적 입니다. 


첫 번째 목적인 가입자 본인 여부 확인은 서비스 이용자의 실존성을 기반에 두고 있으며, 가입자가 꼭 본인이어야만 하는 검증이 필요한 경우에 적용하게 됩니다. 대표적으로 은행5이나 대출관련 서비스6, 신용평가 서비스, 마일리지 연계 서비스 등이 여기에 해당됩니다. 두 번째 목적인 진성 정보의 수집은 마케팅을 고려한 경우로 고객의 휴대폰 SMS나 카카오톡 또는 이메일 주소를 활용, 자사의 광고나 서비스 내 알림을 내보내려는 목적을 가지고 있고 다수의 서비스들이 두 번째 목적에 근거를 둔 가입 인증절차를 적용하고 있습니다.


그런데 가입 인증절차 적용 시 서비스의 목적성을 판단하는 경우보다는 유/무료 정도를 고려하거나 의례적으로 적용하는 경우가 많은 것 같습니다. 하지만 이들 인증방식의 공통적인 문제는 바로 고객에게 허들을 안겨준다는 점입니다. 고객에게 허들을 준다는 것. 고객에게 일부러 불편함을 줄 의도가 아니라면 기획 시 가능한한 불편요소를 걷어내는 것은 서비스기획의 당연한 과정입니다. 이러한 맥락에서 우리 서비스에 과연 가입 인증절차가 필요한가를 진지하게 생각해 볼 필요가 있습니다.


아마존의 회원가입 페이지 (amazon.com)


여기서 잠시 해외 서비스의 사례를 살펴보죠. 우리가 매우 잘 알고 있는 페이스북이나 인스타그램, 유튜브, 구글, 아마존이나 이베이, 알리익스프레스 등의 서비스들은 어떠한 인증절차도 적용하지 않았습니다. 그 이유는 무엇일까요? 단순히 국내 법에 적용받지 않기 때문일까요? 아니면 고객에게 정확한 정보를 제공 받아 마케팅을 하고 싶지 않아서 일까요? 앞에서 열거한 서비스의 대부분을 이용하는 저로썬 문뜩 이런 생각이 들었습니다.



"허수로 분류되는 고객까지 챙길 필요가 없다는 걸까?"



지금까지 많은 서비스의 회원가입 영역을 기획해왔던 저로썬 강하게 뒤통수를 맞는 느낌이었습니다. 우리가 회원가입 서비스를 기획하며 어떻게 하면 더 많은 가입자를 유치하고 어떻게 하면 고객의 진성정보를 얻을 수 있을까만을 생각했지, 정확한 정보를 입력할 의사가 없는 고객은 서비스를 제대로 이용할 의사가 없는 고객이라고까지는 생각 해보지 못했던 거죠.


고객중심, 고객지향적 서비스?


다시 말해, 제대로 이용할 생각이라면 당연히 정상적인 정보를 입력할 것이고, 우리는 이들 고객들만 잘 챙기면 되는 것이라는 어찌보면 아주 당연한 접근방식. 그간 우리 서비스에 가입하는 모든 고객은 잠재적인 이용자 혹은 구매자이기 때문에 이들이 실질적인 이용자로 전환될 수 있도록 다양한 수단을 통해 관심있는 정보를 제공해주기 위해서 꼭 진성정보를 받아야 한다는 공급자적 마인드로 서비스를 기획해왔던 것이 아닐까하는 생각을 해보았습니다. 뜻밖의 고해성사



이러한 맥락에서 다시 생각해보면 일반적인 서비스가 가입 인증절차를 통해 특별히 고객이나 서비스 제공자 양 측에게 특별한 이득이 없네요? 가입자에겐 불편만 주고, 서비스 제공자에겐 쓸데없는 비용을 들여 의미없는 진성정보를 획득하고 말이죠. 지금 여러분들이 기획했거나 운영하는 서비스를 한 번 살펴보죠. 정말 인증절차가 필요한가요?


물론 그럼에도 불구하고 회사의 정책과 방향이 인증절차 유지를 바라보고 있다면 어찌할 수는 없을 겁니다. 또한 꼭 인증절차를 거쳐야 하는 서비스도 있을 겁니다. 하지만 가능한한 설득의 과정을 통해 말만 고객지향적 서비스가 아닌 서비스 환경까지도 고객중심, 고객지향적 서비스로 탈바꿈하는 계기가 되어야 합니다. 


회원가입을 필요로 하는 다수의 서비스에 적용되어 있는 인증절차. 워낙 보편화된 절차이다보니 고객의 입장에서도 당연한 과정으로 인식하고 생각보다 큰 불편을 느끼지 않을 가능성도 충분히 있습니다. 저 역시도 회원가입 시 인증 자체에 큰 불편을 느껴보지 못했습니다. 지극히 당연한 과정이라 생각했기 때문입니다. 이래서 습관이 무서운거죠. 하지만 인증절차를 걷어냄으로써 고객에게 새로운 경험을 줄 수 있다는 것은 정말 값진 성과가 아닐까 생각해봅니다...


출처: https://www.yamestyle.com/415?category=325794 [야메의 이상한 생각과 공감] 

0 0

Data Chef.

datachef00@gmail.com

ⓒ 2023 Data Chef.

Hosting by I'M Datachef

Data Chef.
e-Mail

datachef00@gmail.com


Seoul, Korea  ㅣ  Biz License 000-00-00000  ㅣ Hosting by Datachef.