자꾸만 헷갈리는 점유인증vs본인인증

😶‍🌫️ 무슨 인증? 게슈탈트 붕괴의 시작

회사에서 신규 서비스를 기획하던 어느 날, 회원 가입 단계에서 인증을 어떻게 할 것인지에 대해 기획자와 개발자, 디자이너끼리 열띤 논쟁에 불이 붙었다. 우리가 기획하던 서비스는 캐시워크, 캐시슬라이드처럼 자사몰이 포함된 리워드 앱이었다. 기존에 운영하던 서비스는 모두 점유인증으로 진행하고 있었는데, 아무래도 '쇼핑'과 '리워드'라는 특성상 본인인증을 해야 하지 않을까 하는 의문이 들었다.

며칠 내내 인증에 대해서만 이야기하다 보니 급기야 게슈탈트 붕괴 현상이 발생했다. "인증이요? 무슨 인증을 말씀하시는 거죠?" 게다가 '점유인증'이라는 명칭은 왜인지 입에 잘 붙지 않아 회의 때마다 "아, 그, 그 인증 있잖아요. 본인인증 말고 문자로 하는 거."라는 말을 반복했다.

어느 서비스에서나 인증 절차는 뼈대가 되는 매우 중요한 기능이다. 이번 기회를 통해 정확한 명칭과 기술적, UX적 차이를 확실하게 짚고 넘어가고자 한다.

👥 '전화번호'를 아는 것과 '그 사람'을 아는 것의 차이

기획서에 무심코 적는 ‘인증’은 크게 두 가지로 나뉜다. 두 방식은 목적도, 비용도, 유저가 겪는 허들도 완전히 다르다.

점유인증은 폰을 쥔 사람이 본인인지는 알 수 없다. 가입 이탈률을 낮추는 데는 유리하지만, 가상 번호 또는 추가 이메일을 통한 다중 계정 생성을 막기는 어렵다.

본인인증은 인증을 통과하면 서버로 CI와 DI라는 식별값이 넘어오며, DI 값을 활용해 1인 1계정 원칙을 통제할 수 있다. 하지만 외부 모듈을 띄워야 하므로 서비스 초기에는 비용 부담이 되며, 유저 이탈률이 크게 높아질 가능성이 있다.

🤔 리워드 앱, 그래서 무슨 인증을 써야 하는가

다시 처음의 고민으로 돌아와서, 자사몰이 포함된 리워드 앱은 도대체 어떤 인증을 써야 하는 걸까? 이 도메인은 본인인증과 점유인증 사이의 딜레마가 가장 극명하게 드러난다. 어뷰징을 막으려면 본인인증이 필수지만, 신규 서비스의 초기 단계인 만큼 첫 화면부터 무거운 팝업을 띄우면 앱을 막 다운로드한 유저들의 전환율은 곤두박질칠 것이 뻔했다.

길고 긴 논의 끝에 우리 팀이 내린 결론은 허들의 분산 및 초기 지표 확보였다. 신규 서비스 런칭 시점에는 무엇보다 가입자 수와 활성 사용자 지표를 확보하는 것이 가장 중요하다고 판단했다. 중복 가입하는 허수 유저가 섞이더라도, 초기에는 일단 어떻게든 볼륨을 만들어내는 것이 서비스 성장에 유리할 것이라는 가설을 세웠다.

이렇게 할 경우 법적으로 문제가 없는지에 대해서도 더블 체크를 거쳤다.

• 현금 출금(환급) 기능을 제공하지 않고 앱 내 포인트로만 재화를 교환하는 리워드 앱은
  전자금융거래법상 엄격한 실명확인 의무 대상이 아님

→ 법적으로 회원가입 시 반드시 본인인증을 써야 하는 것은 아니다!
     다만, 자사몰에서 실제 상품을 결제한다면 본인인증이 불가피하다.

1. 가입 단계
2. 사용 단계

이렇게 기획의 방향을 잡음으로써, 초기 트래픽 유입을 극대화하면서도 결제 단계에서 어뷰저들이 포인트를 실제 재화로 바꿔가는 리스크는 차단할 수 있을 것으로 기대했다. 이미 모아둔 포인트가 아까운 진성 유저라면 결제 단계의 본인인증 허들을 기꺼이 넘어줄 것이라는 게 우리의 핵심 가설이다.

비록 서비스 출시 전이라 실제 유저 전환율 데이터로 우리의 가설을 증명하진 못했지만, 이 기획 과정 자체가 주니어 PM인 나에게는 엄청난 레슨런이었다.

"인증 붙여주세요"라는 말 한마디에는 유저의 이탈률, 회사의 인프라 비용, 어뷰징 리스크, 그리고 무엇보다도 현재 우리 서비스가 가장 집중해야 할 비즈니스 목표(초기 지표 확보)가 모두 얽혀 있다. 단순히 남들이 다 하니까, 혹은 기존에 이렇게 해왔으니까 화면을 그리는 것이 아니라, 우리 서비스의 비즈니스 모델과 법적 요건을 파악하고 논리적으로 최적의 방식을 선택하는 과정을 겪었다.

한동안의 게슈탈트 붕괴 사태를 겪으며 결국 우리는 답을 찾아냈다. 출시 후 우리가 세운 이 가설이 실제로 맞아떨어졌는지 확인할 수 있는 기회가 생기기를 바란다.