Firebase Email/Password 인증을 사용하지 않은 이유— SNS 로그인만 채택한 서비스 설계 판단 기록

앱을 만들다 보면 가장 먼저 마주치는 선택지 중 하나가 로그인 방식이다.
Firebase를 사용하는 경우, 기본적으로 제공되는 인증 방식은 다음과 같다.

• Email / Password
• Google
• Apple
• 기타 SNS Provider

처음에는 “Email / Password + 이메일 인증” 조합이
가장 보편적이고 안전해 보일 수 있다.

하지만 PulseBoard 프로젝트에서는 이 방식을 채택하지 않았다.
그 이유를 정리해보면, 단순한 기술 선택이 아니라 서비스 정책과 신뢰도의 문제였기 때문이다.

 

1. Email / Password 인증의 본질적 한계

Firebase의 Email / Password 인증은 다음을 보장한다.

• 사용자가 해당 이메일을 실제로 소유하고 있다
• 동일한 이메일로 중복 가입은 불가

하지만 이것이 보장하지 않는 것이 더 중요하다.

Email / Password 인증이 보장하지 않는 것

• 동일 개인 여부
• 실존 인물 여부
• 계정 수 제한
• 다계정 생성 방지

Firebase가 확인하는 것은 오직 이 한 가지뿐이다.

“이 이메일 문자열이 이전에 사용된 적이 있는가?”

 

즉, 이메일 인증은 ‘개인 식별 수단’이 아니다.

 

2. 이메일 인증(Email Verification)은 왜 해결책이 아닌가

Email / Password 인증에는 흔히 이메일 인증(Verify Email) 기능이 함께 언급된다.
그래서 이런 생각이 들 수 있다.

“이메일 인증까지 하면 무분별한 회원가입을 어느 정도 막을 수 있지 않을까?”

결론부터 말하면: 거의 효과가 없다.

이메일 인증이 보장하는 것은 다음과 같다.

• “이 이메일 주소에 접근할 수 있는 사람이 가입했다”

하지만 현실에서는 다음이 너무 쉽다.

• 임시 이메일 서비스 사용
• Gmail alias (user+1@gmail.com, user+2@gmail.com)
• 이메일 자동 생성 서비스

이 모든 경우는:

• 이메일 인증 통과 가능
• 계정 무한 생성 가능

즉,

이메일 인증 = 계정 소유 확인
≠ 개인 식별
≠ 다계정 방지

 

이메일 인증은 봇 방지에는 일부 효과가 있지만,
의도적인 다계정 생성에는 거의 무력하다.

 

3. PulseBoard에서 Email 인증이 특히 부적합했던 이유

PulseBoard는 다음과 같은 성격의 앱이다.

• 사용자가 직접 카테고리를 생성
• 카테고리 생성에 명확한 제한 정책 존재
• 사용자 생성 콘텐츠의 신뢰도가 중요

이 구조에서 가장 위험한 시나리오는 다음이다.

한 사람이 여러 계정을 만들어
카테고리를 무분별하게 생성하고
제한 정책을 우회하는 경우

 

Email / Password 인증은 이 시나리오에 구조적으로 취약하다.

 

4. SNS 로그인만 채택한 이유

그래서 PulseBoard는 다음과 같이 결정했다.

Email / Password 인증을 제외하고
SNS 로그인만 제공한다.

SNS 로그인의 장점

• 계정 생성 비용이 상대적으로 높음
• 다계정 생성 난이도가 높음
• Firebase UID의 신뢰도가 상대적으로 높음
• 제한 정책을 UID 기준으로 적용 가능

물론 SNS 계정도 여러 개 만들 수 있다.
하지만 중요한 점은 이거다.

“완벽한 방지”가 아니라
“현실적으로 신뢰 가능한 기준선”을 선택한 것

 

대부분의 서비스도 이 선에서 타협한다.

 

5. “SNS 가입을 싫어하는 사용자”에 대한 판단

Email / Password 인증을 선택하는 가장 흔한 이유는 이 질문이다.

“SNS 로그인 싫어하는 사용자는 어떻게 할 것인가?”

 

이 질문은 모든 서비스에서 동일한 무게를 갖지 않는다.

PulseBoard의 목적은:

• 대규모 사용자 확보 ❌
• RxSwift + Firebase 학습 ⭕
• 서비스 설계 사고력 증명 ⭕
• 정책을 가진 앱 구조 구현 ⭕

이 경우에는:

가입 장벽을 낮추는 것보다
정책의 신뢰도를 지키는 것이 더 중요

 

6. 최종 결론

PulseBoard에서 다음과 같이 결정했다.

• Email / Password 인증 ❌
• Email Verification ❌
• SNS 로그인 전용 (Apple / Google) ✅

이 선택은 보안 강화가 아니라,
서비스 정책을 지키기 위한 설계적 판단이다.

 

7. 다음 앱을 만들 때를 위한 판단 기준 정리

이 경험을 통해 얻은 기준은 명확하다.

Email / Password 인증이 적합한 경우

• 개인 식별이 중요하지 않은 서비스
• 정책 우회가 큰 문제가 되지 않는 경우
• 계정 수 자체가 중요한 서비스

SNS 로그인이 적합한 경우

• 사용자 생성 콘텐츠의 신뢰도가 중요한 서비스
• 제한 정책이 존재하는 서비스
• 운영 리소스가 제한적인 개인 프로젝트

마무리

로그인 방식은 단순한 기술 선택이 아니다.
서비스가 어떤 문제를 중요하게 보는지에 대한 선언이다.

 

PulseBoard에서는
“누가 얼마나 쉽게 들어오는가”보다
“들어온 사용자를 얼마나 신뢰할 수 있는가”를 선택했다.

 

이 판단은
다음 앱을 만들 때도 그대로 다시 사용할 수 있는 기준이 될 것이다.