어떻게 회원가입(+로그인) 하게 만들까?

Yehyeok Bang·2024년 8월 27일
15
post-thumbnail

많은 서비스에 구현된 로그인 기능을 어떻게 구현하면 좋을 지 고민하며 작성하는 글이에요. 또한, 왜 그렇게 하고 싶은가?를 포함하여 프로젝트 팀원에게 제안하기 위한 글이에요.

저번 글에서는 서버의 로그인 기능을 어떻게 구현할 것인가에 대해 살펴봤어요. (JWT, session, cookie 등) 이번 글에서는 회원가입 및 로그인 방식에 대해 알아보고 사용자 경험에 대해 살펴보려고 해요. 이후 팀원들과 함께 제일 적합한 방식은 무엇인지에 대해 이야기할 예정이에요.

회원가입

요즘 대부분의 웹 서비스를 원활하게 사용하기 위해서는 해당 서비스의 회원이 되어야 해요. 물론 회원이 아닌 경우에도 서비스를 이용할 수 있는 경우도 있지만, 서비스 이용 내역이나 개인 맞춤화 데이터들을 저장하고 활용하기 위해서는 회원가입이 필요해요.

회원가입을 진행하는 과정은 크게 2가지로 분류돼요.

  • 자사 서비스 회원가입
  • SNS 계정을 통한 회원가입

가끔 공공기관에서 금융 인증서를 통한 로그인 방법도 존재하지만, 가장 많이 사용되는 2가지 방식을 알아볼게요.

자사 서비스 회원가입

직접 아이디와 비밀번호, 선택적으로 입력 가능한 개인정보 등을 입력하여 회원으로 등록한 후 가입된 계정으로 로그인하여 서비스를 이용하는 방법이에요. 어디서나 쉽게 볼 수 있었던 가입 방법이에요. 아래는 네이버 회원 가입 과정을 캡쳐한 것이에요.

사진에서 볼 수 있듯이 회원가입을 진행하면 약관에 동의해야 하며, 휴대전화 인증 등의 번거로운 과정을 거쳐야 해요. 추가적으로 보안성 문제를 이유로 비밀번호를 어렵게 만들기를 권장하고 있어요. 덕분에 로그인 할 때 비밀번호를 까먹고 재설정하는 경험을 겪어본 적이 있을 거에요. 또한 사용자들은 우리 서비스 외에도 다양한 서비스에 회원으로 가입되어 있기 때문에 이를 기억하기는 더더욱 쉽지 않아요.

Anrain이라는 소셜 미디어 ROI 솔루션 기업 2013년의 자료에 따르면, 약 80% 이상의 인터넷 이용자들이 각각 다른 패스워드를 기억하고 관리하고 있으며, 92% 이상의 인터넷 이용자들이 로그인 아이디나 비밀번호를 잊어 이를 복구하거나 재설정하기보다 아예 해당 서비스를 사용하는 것을 포기한다고 조사되었다. 이와 같은 비밀번호 피로(Password fatigue)로 인한 고객이탈 혹은 고객유입 저해 현상은 기업 측면에서 잠재적 위험 요소로 간주할 수 있다.
구소연, 고준 (2018). "소셜 로그인 서비스 태도에 영향을 미치는 요인: 개인 혁신성의 조절효과"

자료에서 볼 수 있듯이 이러한 회원가입 방식은 신규 사용자의 유입을 막거나 비밀번호를 까먹는 것처럼 사용자에게 부정적인 경험을 제공할 수 있어요.

그런데 왜?

단순하게 신규 유입, 사용자 경험을 생각하면 자사 서비스의 회원가입 기능보다 SNS 계정으로 회원가입하는 것이 좋아보여요. 그렇다면 언제, 왜? 회원가입 기능을 직접 구현하면 좋을까요?

  • 독립성 유지 : SNS 회원가입을 제공할 경우, 특정 플랫폼에 의존하게 돼요. 이는 해당 SNS 서비스가 중단되거나 정책이 변경될 경우, 사용자 로그인 방식에 큰 영향을 미칠 수 있어요. 일반 로그인은 이러한 제약에서 벗어나 독립적인 사용자 관리가 가능해요. 직접 회원가입을 통해 수집된 데이터라면 동의 여부에 따라 직접 관리할 수 있어요. (명확한 데이터 소유권을 주장할 수 있어요!)

  • UX/UI, 디자인 유지 : 사용자에게 회원가입과 로그인까지 모든 과정에서 우리 서비스의 UX/UI 디자인과 기능을 온전히 제공할 수 있어요. 이는 사용자 경험을 최적화하고, 브랜드 일관성을 유지하는 데 중요한 역할을 해요. 예를 들어, 화려한 색상의 동그란 디자인을 채택한 서비스에서 SNS 로그인을 위해 단색의 각진 Google 로그인이 나온다면, 어색하다고 느낄 수 있어요.

  • 다양한 선택지 제공 : 모든 방식의 회원가입을 제공해요. 일부 사용자들은 개인정보 보호나 개인적인 이유로 SNS 회원가입을 선호하지 않을 수 있어요. 그래서 일반 회원가입도 제공하면서 다양한 선택지를 제공해요.

이외에도 SNS를 제공하는 기업보다 더 강력한 보안이 필요한 경우 직접 고객의 개인정보를 관리해야 하는 경우 사용할 수 있을 것 같아요.

SNS 계정으로 회원가입

SNS 계정을 통한 회원가입 및 로그인은 사용자 입장에서 반복적인 등록을 피하게 하여 사용자 편의성을 높여서 서비스 제공자 입장에서는 신규 회원을 빠르게 확보, 참여와 재방문율을 높일 수 있는 중요한 장점을 제공해요. 또한 소셜 로그인의 방식을 이용할 때 개인정보를 많이 제공하지 않아도 된다는 것도 큰 장점이에요.

저도 SNS 계정을 통해 서비스를 이용하는 빈도가 늘어났어요. 이유는 번거로운 회원가입 과정과 계정을 직접 기억하고 있어야 되기 때문이에요. 물론 기기 내부에 계정을 저장해두고 인증(Face ID, 지문 인식 등)을 통해 쉽게 로그인할 수 있지만, 자주 사용하는 계정(구글, 카카오 등)으로 쉽게 로그인 하는 과정이 더욱 간편하기 때문에 많이 사용했던 것 같아요.

위 이미지는 대한항공 사이트의 로그인 화면이에요. 이처럼 요즘은 다양한 곳에서 SNS 계정을 통한 회원가입 및 로그인을 제공하고 있어요.

소셜 로그인 도입 결과 분석

Yelp는 2009년 7월에, TripAdvisor는 2010년 12월에 페이스북 로그인 기능을 도입했기 때문에, 기간 전후 12개월의 리뷰를 비교하여 어떤 변화가 있었는지 보았습니다. 분석 결과, 소셜 로그인을 통한 새로운 가입자가 증가하고 기존 가입자도 더 많은 리뷰를 남기게 되어 리뷰의 양은 증가했습니다. 그리고 연구 전 예상했던 대로 리뷰에서 더 감정에 관련된 단어가 더 많이 등장하고, 분석적이거나 또는 논리적인 문장 구조를 만드는 단어는 더 줄어들었습니다.

이와 더불어 부정적인 단어를 덜 사용하게 되는 것으로 나타났습니다. 사용자가 직접 작성하는 리뷰가 서비스의 가치를 만든다는 점에서 양이 증가한다는 점은 주목할 만합니다. 하지만 이전 연구들을 돌이켜 보았을 때, 실질적으로 다른 사용자들에게 도움이 되는 리뷰는 덜 감정적이고 부정적인 리뷰라는 점에서 리뷰의 질이 떨어지게 되지는 않는지 우려할 부분이 있습니다. 따라서 소셜 로그인은 양날의 칼이라고 볼 수 있으며, 서비스 운영자들 입장에서는 이 점을 유의하여 시스템을 디자인할 필요가 있겠습니다. 카이스트MBA 추천 해외 논문, 소셜 로그인 서비스의 양면성- KCB Insights

이런 측면에서도 한번 살펴보면 좋을 것 같아서 블로그 글을 인용했어요.

그럼 당연히 이거 아냐?

이제 막 시작하는 서비스라면 신뢰가 없고, 비교적 보안이 좋지 않을 수 있다는 인식이 있기 때문에 신규 유입, 사용자 경험을 생각하면 SNS 계정을 통한 회원가입 및 로그인 기능을 사용하는 것이 좋아보여요. 그러면 무조건 SNS 계정을 통한 회원가입 기능을 제공해야 할까요? (사실 소셜 로그인을 사용하는 것이 좋아보이는데, 단점을 알아야 생길 문제를 예방하거나 대처하기 쉬울 것 같다고 생각했어요.)

  • SNS 종속성 : 서비스 제공자는 SNS 플랫폼의 정책 변화나 서비스 중단에 종속돼요. 예를 들어, SNS 로그인을 진행할 때마다 10원씩 납부하라고 한다면 서비스 이용에 차질이 생기거나 추가적인 비용 문제도 발생할 수 있어요.

  • 보안 문제 : 자주 사용하던 SNS 계정에 문제(탈취, 삭제 등)가 생긴 경우 여러 서비스 이용에 어려움을 겪을 수 있어요.

  • 어떤 계정으로 했더라.. : 소셜 로그인을 제공하는 대부분의 서비스는 여러 개의 SNS 계정을 통해 가입할 수 있도록 지원해요. 어떤 SNS 계정으로 로그인하더라도 각각 누구인지 구분할 수 있다면, 통합하여 제공할 수 있어요. 하지만 모든 서비스가 그렇게 구현되어 있지는 않아요. 어떤 계정으로 서비스를 이용했는지 몰라서 여러 개의 계정으로 가입되는 불편한 경험을 겪을 수 있어요. (이에 대한 좋은 해결책은 관련 포스팅를 읽어보면 좋을 것 같아요.)

사실 SNS 계정을 통한 소셜 로그인 기능에 가장 큰 단점은 계정 하나로 연결된 모든 서비스를 쉽게 이용할 수 있다는 것이에요. 해당 서비스의 간편결제까지 연결된 경우라면 SNS 계정 탈취 하나로 큰 문제가 발생할 수 있어요.

연결 관리 (참고)

카카오 계정을 예시로 가져왔어요. 계정 설정에서 연결된 서비스 관리 탭에 들어가면 제가 카카오 계정을 통해 가입한 서비스들을 볼 수 있어요. 보안을 위해 가끔씩 확인하시면 좋을 것 같아요.

저도 확인해보니 기억에 없는 서비스들에 카카오 계정을 통해 가입되어 있었어요. 이처럼 카카오 계정 하나로 많은 서비스에 접근할 수 있게 되기 때문에 소셜 로그인을 주로 사용하시는 분들은 SNS 계정을 잘 관리해야 해요. 이러한 것도 사용자에게 부담이 될 수 있을 것 같아요.

정리하면

자체적인 회원가입의 경우 회원가입 및 로그인 화면까지 서비스에 맞게 구현할 수 있기 때문에 언제나 동일한 UX/UI 경험을 제공할 수 있고, 개인적인 이유로 SNS 계정을 사용하고 싶지 않은 경우 대체 선택지가 될 수 있어요. 추가적으로 SNS 플랫폼에 종속되지 않기 때문에 SNS 계정을 탈퇴하거나 보안 문제가 발생한 경우 서비스에는 영향을 끼치지 않을 수 있어요. 하지만 사용자 인증(이메일, 휴대전화 인증 등)을 위한 시스템을 직접 구축해야 하며, 가입을 진행하다가 많은 개인정보 입력 요구에 사용자가 이탈하게될 가능성이 높아요.

SNS 계정을 통한 회원가입의 경우 사용자가 직접 계정을 기억하고 있지 않아도 되며, 평소 사용하던 SNS 계정을 통해 아주 쉽게 서비스에 가입할 수 있고, 민감한 정보를 직접 작성하지 않기 때문에 가입 시 부담을 줄일 수 있어요. 즉, 새로운 사용자가 쉽게 가입할 수 있고 이후에도 SNS 계정으로 쉽게 로그인할 수 있기 때문에 사용자 입장에서 서비스 이용을 위한 계정 관리 부담이 줄어들어요. 하지만, SNS 플랫폼에 종속되어 생길 수 있는 문제 때문에 이를 분리하고 싶은 사용자도 나타날 수 있어요.

저는 서비스 접근성 하나 만으로 소셜 로그인을 도입할 이유가 충분하다고 생각해요. 하지만, 앞서 살펴본 것처럼 SNS 플랫폼 종속성 관련 문제가 발생하더라도 쉽게 대처할 수 있게 만들면 좋을 것 같아요. (예를 들어, SNS 계정으로 가입했지만 일반 계정으로 변경할 수 있다거나 등)

소셜 로그인?

지금까지 말한 SNS 계정을 통한 회원가입이 소셜 로그인이라고 할 수 있어요. 소셜 로그인 구현이라고 구글에 검색하면 OAuth 라는 키워드를 아주 많이 볼 수 있어요.

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)받을 수 있는 표준 프로토콜이다.

쉽게 말하자면, 우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 권한을 타사 플랫폼으로부터 위임 받는 것 이다.
OAuth 2.0 포스팅

제가 작성한 내용은 아니지만 개념, 동작 메커니즘 등 이해하기 쉽게 설명되어 있어요. 만약 OAuth에 대한 개념을 잘 모르시는 경우 먼저 읽으시면 도움이 될 것 같아요!

주의사항

소셜 로그인은 만능이 아니에요. SNS 계정을 통해 인증을 진행하고, 해당 SNS 계정 주인의 정보(이메일, 이름, 나이 등)를 가져오는 것까지가 소셜 로그인의 역할이라고 생각하시면 편할 것 같아요. 즉, 사용자가 SNS 계정으로 로그인하도록 구현하고 이후 로그인한 사용자의 정보를 SNS 플랫폼으로부터 제공받는 것이에요.

서버는 제공받은 사용자의 정보를 토대로 가입 여부를 확인하여 로그인 또는 회원가입 과정을 진행해야 해요.

흐름

사용자 입장에서 바라본 소셜 로그인 과정이에요. SNS 계정을 통한 가입 이후에 별도의 추가 로직(닉네임을 추가로 입력받는 등)이 없는 경우 매우 간단하게 로그인 또는 회원가입을 처리해요. 사용자는 미리 준비된 로그인 화면에서 SNS 계정으로 로그인하면 가입 또는 로그인 처리가 이루어져요.

즉, 서비스를 개발한다면 미리 준비된 로그인 화면, SNS 플랫폼과 협동할 서버, DB, 별도 서비스 로그인 방법(JWT, 세션 쿠키 등) 등을 직접 구현해야 해요.

사용자 정보 저장 방법

사용자가 SNS 계정으로 로그인하면 SNS 플랫폼으로부터 동의 여부에 따라 사용자의 이름, 이메일, 나이 등을 제공해요.

만약 일반적인 회원가입으로 가입한 사용자와 SNS 계정으로 가입한 사용자를 통합시켜 관리하려면 이메일을 기반으로 같은 사용자인지 확인할 수 있을 것 같아요. 반대로 분리하여 관리하고 싶다면 테이블을 분리하거나 가입 경로를 저장하는 방법도 있을 것 같아요.

이처럼 주어진 정보를 어떻게 활용하고 저장하느냐에 따라 사용자 경험이 달라질 수 있어요. 이번에는 생각할 수 있는 시나리오를 살펴보고 비교해보려고 해요.

통합 회원 관리

통합 회원 관리 방식은 사용자가 다양한 경로(일반 회원가입, 카카오톡, 구글 등)로 서비스를 이용할 때, 하나의 통합된 계정처럼 느끼게 제공하는 것이에요. 사용자가 여러 경로로 회원가입을 하더라도 하나의 계정으로 모든 서비스를 이용할 수 있다면, 중복 가입이나 별도의 계정 관리 부담을 덜 수 있어요.

서버 측면에서는 각 경로로 들어온 사용자의 정보를 기반으로 동일한 사용자임을 식별하고, 이를 바탕으로 통합된 계정으로 관리해야 해요. 이를 구현하기 위해 서버는 아래의 부분을 고려해야 할 것 같아요.

  • 고유 정보 수집 및 관리 : 통합 계정을 구현하려면, 각 회원가입 경로에서 고유한 식별 정보를 수집해야 해요. 주로 이메일 주소를 사용할 것 같아요. 이메일은 대부분의 회원가입 과정에서 필수적으로 입력되는 편이에요.
    그러나 모든 SNS 계정에 동일한 이메일이 사용되지 않을 수 있어요. 저도 카카오톡은 네이버 이메일을 사용하고, 인스타는 구글 이메일을 등록하여 사용하고 있어요. 이를 동일한 사용자로 인식하는 것은 불가능하기 때문에 통합 회원 관리의 범위가 제한될 수 있어요.

  • 복합 키를 통한 사용자 구분 : 동일한 사용자임을 파악하기 위해 이메일 대신 이름, 성별, 생년월일 등을 복합 키처럼 사용하여 사용하여 사용자를 구분할 수 있을 것 같아요. 그러나 이 경우 중복 가능성이 있기 때문에, 동일 정보를 가진 다른 사용자의 계정과 잘못된 통합이 발생할 수 있어요.
    이런 문제를 방지하기 위해, 복합 키를 사용할 때는 추가적인 확인 절차를 도입하는 것이 필요한데, 추가 구현에 대한 부담이 발생해요.

  • 부가 서비스 통합 : SNS 계정을 통해 가입한 사용자는 해당 SNS의 부가적인 서비스도 사용할 수 있습니다. 예를 들어, 네이버 로그인 사용자는 네이버 캘린더, 카페 등의 부가 서비스에 접근할 수 있어요. 통합 회원 관리가 이루어진다면, 이러한 부가 서비스에 대한 권한 관리도 필요할 것 같아요. 즉, 부가 서비스를 사용하는 경우 통합 관리의 복잡성을 높일 수 있을 것 같아요.

각 가입 경로마다 분리

통합 회원 관리 방식과는 반대로, 각 경로로 가입한 사용자를 서로 다른 사용자로 관리할 수 있어요.

  • 독립적인 사용자 관리 : 각 경로로 들어온 사용자 계정을 독립적으로 관리함으로써, 통합 계정 관리에서 발생할 수 있는 중복, 잘못된 계정 통합 등의 문제를 방지할 수 있어요. 하지만 다수의 계정을 쉽게 만들 수 있는 환경이 조성되기 때문에 예를 들어, SNS 서비스인 경우 여러 사용자가 다른 사람인척 특정 분위기를 조성할 수 있으니 주의가 필요해요. (이런 부분이 중요한 서비스라면, 휴대폰 인증 등을 추가할 수 있을 것 같아요.)

  • 사용자 선택의 폭 : 사용자가 특정 경로를 선호하는 경우, 해당 경로로만 서비스에 접근하고, 다른 경로는 사용하지 않는 선택을 할 수 있게 돼요. 개인정보 보호를 중요하게 생각하는 사용자에게 좋은 경험이 될 수 있어요.
    그러나 이 방식은 사용자가 각 경로로 만들어진 다수의 계정을 관리해야 한다는 단점이 있어요. (이 서비스에는 구글 계정이었나...?)

  • 서비스 제공자의 부담 감소 : 통합 계정 관리에 비해 구현이 상대적으로 간단하기 때문에 구현 부담이 줄어들어요. 각 경로로 들어온 사용자끼리 쉽게 그룹핑하여 관리할 수 있다는 것도 장점이 될 수 있을 것 같아요.

각 가입 경로마다 별도로 관리하는 경우 사용자가 어떤 SNS 계정을 사용했는지 기억해야 하는 단점이 있어요. 하지만 이는 관련 포스팅에서 다룬 방식을 활용하면 사용성이 더 좋아질 것 같아요. 추가로 인프런에서는 최근에 로그인 시 사용한 SNS 계정을 표시하여 알려주기도 해요.

일반 로그인 기반에 소셜 인증

일반 로그인 기반에 소셜 인증을 추가하는 방식을 말해요. 기본적으로 자사 서비스의 회원가입을 통해 사용자 계정을 생성하고, 이후에 소셜 인증을 통해 추가적인 보안이나 편의성을 제공해요.

  • 편의와 선택을 동시에 : 사용자는 기본적으로 자사 서비스의 회원가입을 통해 계정을 생성하고, 이 계정으로 로그인해요. 이후에 사용자가 원할 경우, SNS 계정을 연결하여 추가적인 인증 수단으로 활용할 수 있어요. (SNS 계정을 통한 빠른 로그인 사용 가능) 이때, 개인적인 이유로 SNS 계정 연동을 취소하고 싶다면 기본 서비스 계정이 존재하기 때문에 비교적 쉽게 연결을 취소할 수 있어요.
  • 추가적인 보안 : 금융 서비스나 중요한 개인정보를 다루는 서비스에서 유용하게 사용될 수 있을 것 같아요. SNS 계정 인증을 통해 서비스 로그인 시 추가적인 보안 확인 절차를 거칠 수 있어요.

마무리

직접 구현하는 회원가입 vs SNS 계정을 통한 회원가입 vs 퓨전..?

각 구현 방식마다 장단점이 있어요. (다 좋은 것은 찾기 힘들어요..) 중요한 것은 만드려는 서비스를 이해하고, 사용자의 입장을 바탕으로 요구사항을 분석하는 것이 중요한 것 같아요. 분석에 시간을 아끼려면 비슷한 서비스에서 어떤 이유로 어떤 방식을 택했는지 찾아보는 것이 도움이 될 것 같아요.

우리 서비스는 모임 생성 및 가입 기능이 추가될 예정이에요. 따라서 한 명의 사용자가 다수의 계정을 만드는 것을 억제하여 계정에 책임감을 갖게 하고, 각 계정마다 신뢰도를 높이는 것이 중요하다고 생각해요.

다양한 가입 경로를 제공하는 것은 많은 사용자에게 편의를 제공하지만, 빠르게 개발해야 하는 경우 구현 및 사용자 관리에 큰 부담이 될 수 있어요. 따라서 SNS 계정 가입 경로를 2개 이하로 설정하고 많은 사람들이 사용하는 카카오와 네이버 또는 구글 중에서 선택하는 것이 좋을 것 같아요.

빠르게 만들고 확인해볼 서비스에서 회원가입을 직접 구현하는 것은 구현 부담, 보안 문제, 사용자 이탈 관점에서 관심이 크게 가진 않는 것 같아요.

팀원 분들의 생각이 궁금해요. 방식이 결정되면 구현 코드에 대해서도 함께 이야기하면 좋을 것 같아요.

긴 글 읽어주셔서 감사합니다. 본인 인증(SMS 인증)에 대한 글도 추가됐어요.

참고

profile
부담 없이 질문하고 싶은 개발자가 목표입니다.

2개의 댓글

comment-user-thumbnail
2024년 9월 6일

추가로 하나. 개인정보보호법에서 자유로워진다.
모든 개인정보 위탁을 제3자로 돌리고, 우리는 받아서 쓰겠다. 중요한정보는 절대 저장안한다.
라는 정책으로 간다면

나중에 개인정보를 활용하던지 혹은 해킹으로 인해 유출당했을때 책임을 개인정보 제공자로 돌릴 수 있습니다.

1개의 답글