코딩관계론

[SSO 인증 도입기: 회원가입의 귀찮음과 신뢰도 문제를 해결하라] 본문

개발/Hot-Stock

[SSO 인증 도입기: 회원가입의 귀찮음과 신뢰도 문제를 해결하라]

개발자_티모 2025. 4. 4. 12:52
반응형

1. “회원가입, 충분히 만들 수 있지 않아?”라는 의문에서 시작

프로젝트 초기에 “그냥 회원가입 로직을 하나 만든 후, 이메일/패스워드(암호화)를 DB에 저장하면 되지 않을까?”라고 생각했습니다. 사실 기능적으로는 문제될 것이 없어 보였습니다.

  • 기본 로직:
    1. 사용자가 가입 폼에서 이메일+비밀번호를 입력
    2. 서버가 DB에 사용자 정보를 저장
    3. 로그인 시 입력받은 정보와 비교
    4. 세션 or JWT 발행하여 인증 처리

이 구조는 백엔드 개발자라면 누구나 손쉽게 구축할 수 있습니다. 그런데 사이트를 운영하면서 계속 생각해보니, 서비스 입장에서야 간단하지만 사용자 입장에선 어떨까? 하는 의문이 생겨나기 시작했습니다.

 

2. 사용자는 새 사이트에 정보 제공하기가 꺼림칙하다

아무리 제가 만든 사이트라고 해도, 사용자 입장에서는 “이 서비스가 안전한가?”, “비밀번호를 입력해도 괜찮을까?”라는 걱정을 할 수 있습니다.

  • 이미 사용자들은 구글, 페이스북 등 믿을 만한 계정(SNS나 기업 계정)을 가지고 있습니다.
  • 새로운 사이트마다 매번 계정 생성, 비밀번호 입력 하는 것은 귀찮고 보안적으로도 취약합니다(동일 비밀번호를 여러 곳에 재사용할 수 있으니까요).

이런 맥락에서, 사용자들이 저희 사이트에 직접 이메일과 비밀번호를 입력해야 한다면 심리적 장벽이 꽤 높을 거라는 결론에 이르렀습니다.

 

3. “SSO 도입으로, 가입 과정을 건너뛰다”

생각해보니, SSO(Single Sign-On) 인증을 지원하면 사용자는 이미 가입된 구글, 카카오, 네이버, 페이스북 등 다른 서비스 계정을 그대로 사용하여 로그인할 수 있습니다.

  1. 신뢰도:
    • 사용자는 “내 구글 계정이나 카카오 계정을 이용해 OAuth로 인증”하고, 저희 사이트 측에서 패스워드를 따로 보관하지 않음을 알게 됩니다.
    • 이 방식은 저희 사이트 자체는 별도의 회원가입을 요구하지 않으므로, 사용자에게 “비밀번호 입력” 부담을 덜어주는 효과가 있습니다.
  2. 가입 편의성:
    • 이메일 인증, 비밀번호 규칙 등 귀찮은 과정을 한 번에 생략 가능
    • 특히 모바일 환경에서는 가입 폼을 일일이 작성하는 일이 더 번거롭기 때문에, 간편 로그인 버튼 몇 개가 있으면 훨씬 접근성이 좋아집니다.

4. 도입 과정에서의 고민: 직접 구현할 것인가, 라이브러리를 사용할 것인가?

1) 직접 구현

  • OAuth 2.0 표준을 공부하고, Google, Facebook, Naver, Kakao 등 공급자별 인증 Endpoint를 호출해 Access Token을 받고, 사용자 정보를 가져오는 과정을 일일이 코드로 작성
  • 장점: 구현 디테일을 잘 파악하게 되고, 서비스별로 세밀한 커스터마이징이 가능
  • 단점: 개발 시간유지보수 부담이 커지며, 각 플랫폼별 API 업데이트에 따라 자주 변경해야 함

2) 라이브러리/SDK 활용

  • 스프링 같은 프레임워크라면 Spring Security OAuth2, Node.js라면 passport.js 등 검증된 라이브러리들이 존재
  • 장점: 표준 프로토콜을 쉽게 구현할 수 있고, 플러그인이나 어댑터 형태로 제공되므로 유지보수가 상대적으로 용이
  • 단점: 별도의 학습 비용이 필요하고, 특정 라이브러리나 프레임워크에 종속될 수도 있음

실제로 저는 처음에는 Spring Security OAuth2를 이용해 간단한 인증을 구현했습니다. 추가로 필요하면 passport.js 같은 Node.js 라이브러리도 연동해볼 수 있겠다고 생각했죠.

 

5. 결과: 사용자 스트레스 감소 & 사이트 신뢰도 상승

SSO를 적용하고 보니, 다음과 같은 효과를 바로 체감할 수 있었습니다.

  1. 새로 가입하는 사용자들의 가입 절차가 매우 편리해졌습니다.
    • “카카오로 로그인하기” 버튼만 누르면 간단히 서비스에 들어올 수 있으니 이탈률이 크게 줄더군요.
  2. 개발팀 입장에서 비밀번호 보안 문제를 덜어냈습니다.
    • 사용자 패스워드를 저장하지 않으니, 데이터 유출 시 리스크가 줄어들고, 내부 보안 규정 준수도 훨씬 수월합니다.
  3. 트러스트 확보:
    • 사용자들은 “이 사이트가 내 패스워드를 직접 요구하지 않는다”는 사실에 훨씬 안심하고 사용하게 됩니다.

6. 마무리 및 개인 소감

처음에는 “굳이 SSO까지 해야 하나?” 싶었지만, 실제로 도입해보니 유저 경험(UX)과 보안, 신뢰도 측면에서 이점이 많았습니다.

  • 대규모 트래픽을 감당하는 서비스라면, 로그인/회원가입 과정을 간소화하는 것이 유저 락인을 강화하는 관건이 됩니다.
  • 작은 서비스라도, 사용자들이 “내 정보가 안전하다”는 느낌을 받아야 장기적으로 살아남을 수 있죠.

SSO 인증을 적용하기 위한 구글 OAuth, 카카오 로그인, 네이버 로그인 등은 다양한 예제가 있으니, 혹시 아직 도입하지 않았다면 한 번 시도해보시길 권합니다. 개발 비용이 약간 올라가더라도, 신뢰도유저 편의성 면에서 충분히 투자 가치가 있다고 생각합니다.

긴 글 읽어주셔서 감사합니다.
더 궁금한 점이나 공유하고 싶은 내용이 있다면 언제든 편하게 댓글 남겨주세요!

 

실제로 연동 후에 모르는 사용자 한명이 가입해서 크나큰 기쁨을 느꼈습니다.

반응형