brunch

You can make anything
by writing

C.S.Lewis

by 성시리 Mar 31. 2023

회원가입/계정 프로세스에서 기획의 역할

사이드프로젝트를 하면서 공부한 내용

회원가입과 계정은 서비스 기획의 시작 단계의 역할을 합니다. 최근에 사이드프로젝트를 하면서 알게 된 내용을 조금씩 브런치에 정리하면서 기록하려고 합니다. 인터넷의 선배님들이 공유해주신 정보들 덕분에 많이 배울 수 있었고 언제든지 참고하며 보고 싶어서 정리하게 되었습니다.

이 단계에서 가장 신경써야 하는 것은 우리는 유저에게 어떤 정보를 받고 가입시킬 것이고 어떻게 활용할지를 먼저 고민하는 것입니다.

만약 핸드폰으로 꼭 알림을 보내야 하는 서비스라면 핸드폰 번호를 필수로 받고 인증하는 프로세스를 넣어야 하고, 1인당 1계정의 정책을 가져가야 한다면 본인인증을 회원가입 단계에 넣어야 합니다. 금융 서비스라면 보안과 법령에 따라 계좌 인증 케이스도 고려를 해야 하고요.

이렇게 우리가 제공하고자 하는 서비스를 정확하게 이해하고 관련 산업의 법령, 개인정보보호법 등의 이해가 바탕이 되어야 합니다. 내용이 어렵고 보안과 직결되는 문제이기 때문에 큰 서비스에서는 연차가 높은 회원/계정 기획자, PM만을 뽑기도 합니다.

0. 회원 정보수집 과정

회원가입은 유저 온보딩하는 과정에서 이탈을 어떻게 하면 덜하게 할까? 그리고 어떤 정보를 더 잘 받을 수 있을까? 에 대한 고민입니다. 개인정보를 더 받고자 하면 이탈이 많아지고 덜 받자니 나중에 활용할 수 있는 정보가 줄어드는 딜레마에 빠지게 됩니다.

1) 분산하여 정보 받기

마케팅과 서비스 프로세스에서 활용하기 위해서 고객의 정보를 많이 받는 것을 희망하지만, 고객의 정보를 한번에 많이 받게 되면 허들이 되고 서비스를 제대로 사용하기 전에 유저의 입장에선 부담으로 작용하여 가입 단계 이탈이 발생할 수 있습니다.

그렇기 때문에 단계 별로 필요한 정보만 적절하게 받는 설계가 필요합니다. 예를 들어, 커머스 플랫폼에서 핵심 기능은 구매이기 때문에 결제 수단의 정보를 처음부터 받으면 어떨까라는 생각을 할 수 있습니다. 결제 수단을 등록하는 것은 카드 정보를 입력하거나 간편 결제 수단을 등록해야 하기 때문에 비교적 복잡하여 가입 단계에서 받기에는 무리가 있어 이후의 구매를 하는 단계에서 적절히 유도하는 것이 낫습니다.

2) 정보 입력의 당위성 주기

많은 정보를 입력하게 하는 것은 유저에게 부담이 되는 일이지만, 유저가 많은 정보를 입력하는것이 비즈니스의 도움이 된다면 다른 이야기입니다.

링크드인은 유저가 많은 정보를 적는다면 더 매력적인 구직자가 있는것으로 인식 되기 때문에 이를 유도해야 합니다. 그래서 링크드인에서는 '프로필 조회수가 최대 3.9배 높아집니다.'라는 문구를 통해서 구직자인 유저가 직접적으로 얻게 될 이익을 보여주고 유저의 정보 작성을 독려하고 있습니다.

3) 받은 정보의 유형과 목록 정리하기

전체적인 과정이 정해졌다면 받은 정보와 유형을 목록화하여 정리합니다.

1. 개인정보 보호법

회원이 이용하는 서비스는 모두 개인정보를 수집하고 이용하고 파기하고 있습니다. 그렇기 때문에 기획과 설계 단계부터 개인정보를 보호하기 위한 기술과 정책이 적용되어야 하고 기획자는 이 과정을 잘 알고 있어야 합니다.

[개인정보 보호법]에서는 개인정보는 살아있는 개인을 알아볼 수 있는 정보를 말합니다. 특정 개인을 알아볼 수 없더라도 다른 정보와 결합하여 알아볼 수 있는 정보도 포함됩니다.

핸드폰 번호와 이름, 주민등록번호와 같이 가입을 하면서 입력하는 정보부터 서비스를 사용하면서 발행하는 구매내역, 배송지, 잔고 등까지도 개인정보가 될 수 있습니다.

개인정보를 잘수집하기 위해서는 유저의 동의를 받아야 하고 아래 항목을 반드시 안내해야 합니다.

1. 수집 항목

2. 수집 목적

3. 보유 및 이용 기간

- 탈퇴 후 파기 시점

- 탈퇴 후 남겨지는 정보

인터넷 기업의 개인정보 보호 가이드라인을 함께 첨부합니다. (https://privacy.naver.com/download/guideline_for_internet_corporation.pdf)

뿐만 아니라 활용하지 않을 개인정보를 목적없이 받고 보유해서는 안되기 때문에 최소한의 개인정보를 받아야만 합니다.

2. 입력받는 정보의 정책을 확인한다.

일일이 모든 데이터마다의 정책을 확인하기 어렵다면, 비슷한 서비스의 회원가입 프로세스와 이용약관을 벤티마킹하면서 1차적인 정책을 잡는것이 좋습니다.

한 가지 중요한 점은 핸드폰 번호를 계정 시스템의 주요 Key 값으로 기획/설계되면 안된다는 것입니다. 이메일에 스팸 메일로 가득차기도 하면서 한국의 유저에게는 핸드폰 문자/전화가 훨씬 도달율이 높은 수단인것은 사실입니다.

하지만, 핸드폰 번호는 가변적인 정보이기 때문에 번호를 바꾸면 계정/비밀번호를 찾기 어렵고, 핸드폰을 구입하여 새로운 번호를 사용하게된 사람은 이전에 그 번호를 사용하던 사람으로 인해 계정을 만들거나 찾지 못할 수 도 있습니다.

그리고 핸드폰 본인인증과 점유인증은 비용이 많이 발생하기 때문에 자주 발생하면 수익에 영향을 줄 수 도 있습니다. 그렇기 때문에 핸드폰 인증의 횟수를 제한하거나 다른 방식으로 유저가 자신의 계정을 관리할 수 있게 하는 방법도 고민해야 합니다.

아이디/비밀번호

- 아이디의 보안을 고려해서 일정 수준의 Validation으로 가이드를 잡아야 합니다. 비밀번호의 경우 실제 법적 고지사항이 있기 때문에 이를 잘 확인해야 하고 비밀번호를 입력할 때마다 직전의 입력한 값까지는 마스킹(**)처리 하면서 보이지 않게 해야 합니다.

한국보건산업진흥원의 가이드라인을 첨부합니다. (한국보건산업진흥원 비밀번호 생성규칙 안내)

ex)

1. 아이디: 영문, 숫자 조합으로 최소 8자

2. 비밀번호: 영문, 숫자, 특수문자 조합으로 최소 10자

또한, 알맞은 가이드 문구와 에러 메세지로 유저의 올바른 입력을 유도해야 합니다.

에러 문구 예시

- 이미 사용 중인 이메일입니다.

- 비밀번호와 비밀번호 확인이 일치하지 않습니다.

- 아이디는 영문, 숫자 조합으로 최소 8자여야 합니다.

3. 본인 인증

많은 서비스에서 1) 핸드폰 본인인증 2) 실명인증 3) 이메일 인증 등의 본인 인증을 받고 있습니다. 인증방식을 사용하는 이유는 가입자의 본인 확인과 유효한 정보 수집의 목적입니다.

금융 서비스와 같이 보안이나 자금세탁 여부 등을 확인해야 한다면 강력하게 본인인지를 반드시 확인해야 합니다. 그렇기 때문에 핸드폰 본인인증이나 계좌 인증 등을 하게 됩니다.

하지만, 본인인증의 장애물이 높아질 수록 유저의 접근성은 떨어지게 됩니다. 너무 많은 유저의 정보를 확인할 필요가 없다면 문턱을 낮추고 쉬운 본인인증으로 대체하는 것이 좋은 기획이라고 할 수 있습니다.

핸드폰 본인인증은 이 핸드폰 번호의 소유자가 맞는지 유저를 검증하는 과정입니다. 이를 위해 핸드폰 소유자의 이름, 번호, 인증번호까지의 이중 검증을 거치게 됩니다. 비용이 많이 발생하는 방법이기 때문에 비용 지불에 대해서 고려하는 기획을 해야 합니다.

실명인증은 한국신용평가정보나 서울신푱평가정보를 거쳐서 인증하는 방식으로 이름과 생년월일, 성별을 검증하여 실존 여부를 확인합니다.

휴대폰 점유인증은 점유인증만을 하는 것으로 핸드폰에 SMS 문자를 발송하여 해당 번호의 핸드폰을 실제로 소유하고 있는지를 확인합니다.

이메일 인증은 입력한 이메일의 소유자가 맞는지를 확인하는 것으로 이메일 제공사인 네이버나 다음, 구글의 보안 프로세스에도 어느 정도 의존할 수 있습니다. 하지만 가입자가 실제로 이메일 계정주와 동일인인지는 판별하기가 어렵습니다.

4. 각 소셜 로그인 기능의 정책을 한다.

1) 각 소셜 로그인마다 받을 수 있는 정보

소셜 로그인은 유저의 입장에서 편리하지만, 유저의 정보를 이용해야 하는 플랫폼의 입장에서는 활용할 수 있는 정보를 잘 확인해야 합니다.

가령, 카카오싱크로 카카오 로그인을 제공하면 가입하는 시점에서 이용 동의를 받고 서비스 이용약관과 마케팅 수신 동의도 동시에 받을 수 있습니다.

구글 로그인을 제공한다면 구글 계정 이메일 주소를 받을 수 있지만 이외의 개인정보는 해당 회원이 공개로 설정한 개인정보만을 활용할 수 있습니다. 그렇기 때문에 추가로 다른 화면에서 이용약관과 개인정보를 받아야 할 수 있습니다.

이처럼 소셜 로그인 마다의 정보를 받는 기준을 확인하여서 온보딩 프로세스를 알맞게 기획해야 합니다.

구글에서는 회원이 공개하는 개인정보를 정할 수 있다.

카카오 싱크를 활용하면 원하는 정보를 받기 쉽다.

2) 앱 서비스라면 Apple 로그인 기능은 필수

iOS 출시 규정에서 Apple ID로 로그인 후, 앱 서비스를 정상적으로 이용할 수 있어야 한다는 내용이 있어 앱스토어에 출시하고자 하는 서비스는 Apple 로그인을 필수적으로 추가해야 합니다. 그렇지 않으면 앱 심사 거절 사유가 될 수 있습니다.

5. 유저의 동의 받기

서비스의 비즈니스와 목표에 따라서 유저의 동의를 받아야 합니다. 대표적으로 받아야 하는 약관을 나열해 보겠습니다. 각 동의는 디폴트로 체크되어 있으면 안되고 유저가 직접 체크하여 받을 수 있게 해야 합니다.

1) 서비스 이용약관

제공하는 서비스에서 지켜야 하는 내용이나 규칙에 대해서 상세히 기술되어야 하고 서비스의 기본 전제라고 보아도 됩니다.

2) 개인정보 수집 및 이용동의

어떤 유저의 정보가 수집이되고 활용되는지 그리고 얼마나 보관하는지 명시해야 하고 유저의 동의를 받아야 한다. 물론 개인정보 보호법을 준수한 내용이어야 합니다.

3) 개인정보 제 3자 제공 동의

개인정보를 제공받는 자(제 3자)의 이익/목적을 위해 개인정보를 제 3자에게 제공하는 것을 말합니다. 커머스 서비스라면 배송을 하는 배달원에게 회원의 개인정보(주소, 핸드폰 번호)를 전달하기 위해서 동의를 받는 것 입니다.

4) 개인정보 처리 위탁 동의

사업자의 이익/목적을 위해 개인정보 취급 업무를 제3자에 위탁하는 것을 말합니다. 콜센터 업체에게 cs 업무를 이관한 다면 고객의 개인정보 또한 위탁하게 되어 해당 동의를 받아야 합니다.

5) 광고성 정보 수신 동의

영리 목적으로 광고성 정보를 메일, 문자, 앱 푸시 등으로 전송하는 경우 사업자는 이용자에게 수신 동의를 받아야 하고 수신 동의를 받고 2년마다 확인해야 합니다.

또한, 메세지/ 메일/ SMS 등의 방법마다 따로 체크를 하여 동의받을 수 있게 해야 합니다.

수신거부 처리는 14일 이내에 통지해야 하고 전송자 명칭/ 수신동의 및 수신 철회 사실, 해당의사를 표시한 날짜, 처리 결과를 담아야 합니다.

6. 회원 정보를 안전하게 저장한다.

회원이 입력한 정보(ID, 비밀번호, 이름, 전화번호, 이메일 등)는 서버의 DB에 저장되게 됩니다. 법령에서 암호화 대상에 속하게 되면 반드시 암호화하여 저장하여야 합니다.

기술적으로는 Salt를 하고 Hash 함수를 수행하거나 Hash 함수를 여러 번하여 저장함을 통해 개인정보를 안전하게 저장하고 있습니다. 대상이 되는 개인정보는 아래와 같습니다.

(개인정보보호위원회) 개인정보의 기술적·관리적 보호조치 기준

제6조(개인정보의 암호화)
① 정보통신서비스 제공자등은 비밀번호는 복호화 되지 아니하도록 일방향 암호화하여 저장한다.
② 정보통신서비스 제공자등은 다음 각 호의 정보에 대해서는 안전한 암호알고리듬으로 암호화하여 저장한다.
1. 주민등록번호
2. 여권번호
3. 운전면허번호
4. 외국인등록번호
5. 신용카드번호
6. 계좌번호
7. 바이오정보
③ 정보통신서비스 제공자등은 정보통신망을 통해 이용자의 개인정보 및 인증정보를 송·수신할 때에는 안전한 보안서버 구축 등의 조치를 통해 이를 암호화해야 한다. 보안서버는 다음 각 호 중 하나의 기능을 갖추어야 한다.
1. 웹서버에 SSL(Secure Socket Layer) 인증서를 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능
2. 웹서버에 암호화 응용프로그램을 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능
④ 정보통신서비스 제공자등은 이용자의 개인정보를 컴퓨터, 모바일 기기 및 보조저장매체 등에 저장할 때에는 이를 암호화해야 한다.