로그인 설계 결정 트리: 직접 구현, 라이브러리, 외부 서비스 중 무엇을 고를까

로그인은 기능이 아니라 리스크 관리다

1인 개발자에게 로그인은 “회원가입 폼 하나 만들기”가 아니다. 비밀번호 저장, 이메일 인증, 세션 만료, 계정 복구, 소셜 연동, 봇 가입, 개인정보 삭제 요청까지 이어지는 작은 보안 시스템이다. 그래서 인증 방식 선택은 취향보다 리스크 배분에 가깝다.

대체로 선택지는 세 가지다. 직접 구현, better-auth·NextAuth 같은 라이브러리 사용, Supabase Auth·Clerk 같은 외부 서비스 사용. 중요한 질문은 “내가 어디까지 책임질 것인가”다.

1. 세 가지 선택지를 먼저 나눈다

직접 구현은 단순해 보이지만 실제로는 가장 넓은 책임을 떠안는다. 특히 이메일/비밀번호 로그인을 직접 다룬다면 해시 정책, 토큰 재발급, 비밀번호 재설정 링크 만료, 계정 탈취 대응 같은 운영 이슈가 따라온다.

라이브러리는 프레임워크 안에서 인증 흐름을 통제하고 싶은 경우에 좋다. DB 구조와 세션 전략을 이해해야 하지만, 제품이 커졌을 때 수정 가능한 여지가 남는다.

외부 서비스는 로그인 화면, 소셜 연동, 관리자 콘솔, 보안 옵션을 빠르게 가져올 수 있다. 대신 요금제, 제공 지역, 데이터 이동성, 서비스 정책을 초기에 확인해야 한다.

2. 결정 트리는 이렇게 타면 된다

첫 MVP라면 질문을 단순하게 시작하자.

• 지금 비밀번호 로그인이 꼭 필요한가?
• 사용자가 결제·민감정보·팀 초대를 다루는가?
• 인증 화면 커스터마이징이 핵심 경험인가?
• 나중에 다른 인증 시스템으로 옮겨야 할 가능성이 큰가?
• 장애가 났을 때 내가 직접 대응할 수 있는가?

답이 애매하다면 보통은 소셜 로그인 중심으로 시작하는 편이 현실적이다. 구글, 깃허브, 카카오처럼 사용자가 이미 계정을 가진 제공자를 쓰면 비밀번호 저장 책임을 줄일 수 있다. 다만 소셜 로그인만 제공하면 일부 사용자는 가입을 꺼릴 수 있으니, 대상 고객이 어떤 계정을 자연스럽게 쓰는지 먼저 봐야 한다.

3. 소셜 로그인만으로 시작해도 되는 경우

다음 조건에 가까우면 이메일/비밀번호를 뒤로 미뤄도 된다.

• 개발자, 메이커, B2B 초기 사용자처럼 특정 계정 사용이 자연스럽다.
• 초기 목표가 결제보다 사용성 검증이다.
• 계정 복구와 고객지원에 쓸 시간이 부족하다.
• 커뮤니티, 대기자 명단, 간단한 대시보드처럼 인증 깊이가 얕다.

이 접근의 핵심은 “영원히 소셜 로그인만 쓰겠다”가 아니다. 처음에는 위험한 책임을 줄이고, 제품 신호가 확인되면 이메일 로그인이나 SSO 같은 요구를 단계적으로 추가하는 것이다.

4. 1인 개발자의 추천 출발점

Next.js 기반 MVP라면 외부 서비스나 검증된 라이브러리로 시작하는 것이 대체로 합리적이다. 이미 Supabase를 DB로 쓴다면 Supabase Auth가 자연스럽고, 사용자 관리 화면과 빠른 연동이 중요하면 Clerk류 서비스가 편하다. 자체 DB와 인증 흐름을 더 강하게 통제하고 싶다면 better-auth나 NextAuth 계열을 검토할 만하다.

직접 구현은 다음 조건이 맞을 때만 고려하자. 인증이 제품의 핵심 차별점이거나, 조직 내부 정책상 외부 서비스 사용이 어렵거나, 보안 운영 경험이 충분한 경우다. 단순히 “라이브러리 설치가 귀찮아서” 직접 만드는 선택은 장기적으로 더 비싸질 수 있다.

5. 나중에 갈아탈 수 있게 설계하기

어떤 방식을 고르든 앱 전체가 특정 인증 도구에 달라붙지 않게 얇은 경계를 두는 것이 좋다.

• getCurrentUser() 같은 내부 함수로 사용자 조회를 감싼다.
• DB에는 외부 제공자 ID와 내부 사용자 ID를 분리한다.
• 권한 체크는 UI가 아니라 서버 로직에 둔다.
• 탈퇴, 이메일 변경, 세션 만료 정책을 문서로 남긴다.
• 인증 실패 로그를 최소한으로 확인할 수 있게 한다.

인증은 한 번 만들고 끝나는 기능이 아니다. 제품이 유료화되고, 팀 기능이 붙고, 개인정보가 늘어날수록 요구사항이 바뀐다. 지금의 최선은 완벽한 인증 시스템이 아니라, 현재 리스크를 줄이면서 다음 선택지를 막지 않는 구조다.