소셜 로그인

제품마다 계정을 따로 만들던 시절이 있었습니다. 새 서비스를 쓰려면 이메일을 적고 비밀번호를 정하고 그것을 기억해야 했습니다. 서비스가 열 개를 넘어가면 사람은 둘 중 하나를 합니다. 같은 비밀번호를 돌려쓰거나, 매번 잊어버리고 재설정을 누르는 것입니다.

두 습관이 회사 쪽에 흔적을 남깁니다. 태오가 페이지덱의 지난 분기 문의 티켓을 분류했을 때 가장 많은 항목은 기능 문의가 아니라 로그인이 안 된다는 내용이었습니다. 전체의 3분의 1이었고 대부분이 비밀번호를 잊은 경우였습니다. 응대하는 사람 시간이 여기 들어가는데 그 응대는 제품을 나아지게 하지 않습니다.

가입 화면 쪽에서도 같은 값이 붙었습니다. 계정을 만들려고 온 사람에게 이메일, 비밀번호, 비밀번호 확인, 이름 네 칸을 세워 두면 상당수가 되돌아갑니다. 이미 구글 계정을 가진 사람에게 새 비밀번호를 하나 더 만들라는 요구는 얻을 것 없는 부담이기 때문입니다. 두 문제를 같은 수단으로 덮으려는 것이 이 방식입니다.

이 방식이 덮는 문제는 넷입니다.

1. 입력 부담입니다. 칸 네 개가 버튼 하나로 줄어듭니다. 페이지덱은 가입 흐름, 즉 계정을 만들기까지 지나는 화면의 순서에서 제출까지 도달하는 비율이 75퍼센트에서 88퍼센트로 올랐습니다.
2. 비밀번호를 새로 만들고 기억하는 부담입니다. 사용자는 이미 로그인된 브라우저에서 버튼만 누르므로 기억할 것이 늘지 않습니다.
3. 이메일 확인 단계입니다. 구글이나 카카오가 이미 그 주소가 본인 것임을 확인해 두었으므로 제품이 인증 메일을 따로 보낼 이유가 없습니다. 사용자가 제품을 떠나 메일함으로 가는 자리가 흐름에서 사라집니다.
4. 비밀번호를 보관하는 위험입니다. 제품 쪽 데이터베이스에 비밀번호가 없으면 그것이 유출될 일도 없습니다. 재설정 문의도 같이 사라집니다.

작동하는 방식은 비밀번호를 넘겨받지 않는 데 있습니다. 사용자가 버튼을 누르면 구글 화면으로 이동해 거기서 동의하고, 제품은 구글이 발급한 증표만 받습니다. 이 주고받는 절차를 정해 둔 표준이 OAuth입니다. 비밀번호를 넘기지 않고 권한만 위임하는 방식이라, 제품은 사용자의 구글 비밀번호를 알지 못한 채로 그 사람이 누구인지만 확인합니다.

받는 정보는 대개 이메일 주소와 이름, 프로필 사진까지입니다. 회사명이나 팀 규모 같은 값은 여기 들어오지 않으므로 그것이 필요한 제품은 다른 자리에서 따로 물어야 합니다. 그래서 이 방식은 필요한 정보를 나눠 받는 점진적 정보 수집과 짝으로 쓰이는 일이 많습니다. 가입은 버튼 하나로 열고, 필요한 값은 제품을 쓰는 동안 하나씩 받는 식입니다.

이 방식만이 답은 아닙니다. 고르는 기준은 무엇에 의존하느냐입니다.

1. 이메일과 비밀번호를 직접 받는 기본 방식입니다. 어떤 사용자에게도 막히지 않는다는 장점이 크고, 대신 앞에서 본 부담이 그대로 남습니다. 어느 제품이든 이 방식 하나는 열어 둡니다.
2. 매직 링크입니다. 비밀번호를 만들지 않고, 이메일 주소를 적으면 그 주소로 온 링크를 눌러 들어옵니다. 기억할 것이 없다는 점은 같지만 메일이 제때 도착하는지에 전부를 맡깁니다. 회사 메일 서버가 링크를 지우거나 메일이 3분 늦게 오면 로그인이 실패합니다.
3. 패스키입니다. 기기의 지문이나 얼굴 인식으로 확인합니다. 비밀번호도 메일도 필요 없지만 기기를 바꿀 때의 처리가 아직 사용자에게 쉽지 않습니다.
4. 기업 고객에게는 회사가 관리하는 계정 체계를 연결합니다. 구성원이 회사 계정으로 들어오고 퇴사하면 접근이 함께 끊기는 방식이라, 직원 계정을 회사가 통제해야 하는 곳에서는 이쪽이 요구 조건입니다.

실무에서는 하나를 고르지 않고 둘셋을 같이 엽니다. 개인 사용자에게는 소셜 버튼 두 개와 이메일 방식을 함께 보여 주고, 기업 고객에게는 회사 계정 연결을 따로 엽니다. 버튼을 늘리는 값도 있습니다. 방법이 다섯 개면 지난번에 무엇으로 들어왔는지 고르는 일 자체가 새 걸림돌이 됩니다.

"가입 화면에 구글 버튼만 먼저 붙여 보죠. 이메일 방식은 아래에 작게 두고요."

가장 많이 쓰는 방법을 눈에 띄게 놓아 제출까지의 손실을 줄이자는 제안입니다.

"이 고객사는 소셜 로그인으로는 안 됩니다. 회사 계정으로 통제해야 한다고 해서요."

기업 고객의 요구가 개인 계정 연결이 아니라 회사가 관리하는 계정 체계라는 뜻입니다.

"구글로 가입했던 사람이 이메일로 또 가입해서 계정이 두 개가 됐어요."

같은 사람의 계정이 갈라지는 문제, 즉 계정 병합 처리가 빠졌다는 지적입니다.

페이지덱은 구글 버튼 하나를 먼저 붙였습니다. 두 주 뒤 가입 흐름의 제출 구간이 75퍼센트에서 88퍼센트로 올랐고, 로그인 관련 문의는 전체의 33퍼센트에서 19퍼센트로 내려갔습니다. 대신 태오에게 새 일이 생겼습니다. 같은 이메일 주소로 이미 계정이 있는 사람이 구글 버튼을 누르면 어떻게 할지 정해야 했고, 두 계정을 하나로 묶는 처리를 따로 만들었습니다.

수아 쪽에서는 반대 방향의 요구가 들어왔습니다. 계약을 논의하던 고객사가 구성원의 개인 구글 계정으로는 쓸 수 없다고 해, 기업 고객용 계정 연결을 따로 열기로 했습니다.

붙이면 전환이 오른다고 읽는 경우가 가장 많습니다. 칸이 줄어드니 그렇게 보입니다. 하지만 제품의 사용자가 누구인지에 따라 결과가 갈립니다. 회사 규정으로 개인 계정 사용이 막힌 조직에서는 그 버튼이 쓸 수 없는 문이고, 그런 사용자가 많은 제품에서는 이메일 방식을 위에 놓는 편이 낫습니다. 이 오해를 그대로 두면 팀은 버튼을 붙인 뒤 숫자가 안 움직이는 이유를 화면에서만 찾습니다.

만들기 쉽다고 보는 것도 오해입니다. 버튼 하나와 연동 코드 몇 줄로 보이니 그렇습니다. 시간을 먹는 것은 그 뒤입니다. 같은 사람이 이번엔 구글로 다음엔 이메일로 들어올 때 계정을 하나로 볼지, 사용자가 구글 쪽에서 연결을 끊었을 때 무엇을 보여 줄지를 다 정해야 합니다. 이 결정을 미루면 계정이 둘로 갈라진 사용자가 쌓이고, 나중에 합치는 일은 훨씬 비쌉니다.