들어가며: 로그인은 왜 어려운가?
에어비앤비 같은 양면 시장 플랫폼에서 로그인 실패는 단순한 기술적 문제가 아니라, 게스트의 예약과 호스트의 수익으로 직결되는 비즈니스 문제입니다. 사용자가 1월에 예약하고 6개월 후에 다시 앱을 여는 경우, 그 사이에 비밀번호를 잊거나 SMS를 수신하지 못하는 상황이 발생하기 쉽습니다. 이런 '비정기적 접속'이 오히려 정상적인 사용 패턴인 셈이죠.
기존 인증 시스템은 로그인을 단일 질문, 즉 "이 사람이 본인임을 증명할 수 있는가?"로만 접근했습니다. 하지만 에어비앤비는 여기에 제품 인사이트를 더합니다. "사용자의 컨텍스트에 맞는 가장 쉬운 인증 방법은 무엇인가?" 이 질문이 프로젝트 전체를 뒤바꿨습니다.
핵심 인사이트: '먼저 식별, 그다음 도전' (Identify first, then Challenge)
새로운 패러다임은 두 단계로 로그인을 분리합니다.
- 식별(Identify): 사용자가 이메일, 전화번호, 소셜 로그인 등 원하는 방법으로 자신이 누구인지 알립니다.
- 도전(Challenge): 서버의 정책 엔진이 계정 정보와 세션 컨텍스트를 분석해 성공 확률이 가장 높은 인증 수단을 제시합니다.
예를 들어, 브라질 여행자는 SMS보다 와츠앱 OTP가 더 적합하고, 한국 호스트는 Google보다 네이버 로그인이 더 익숙합니다. 이런 결정을 클라이언트가 아닌 서버가 내리는 것이 핵심입니다.
# 정책 엔진의 의사결정 로직 예시 (개념 코드)
def select_challenge(user_context, account_info):
"""사용자 컨텍스트와 계정 정보를 바탕으로 최적의 인증 방법을 선택합니다."""
# 지역별 메신저 선호도, 과거 성공 이력, 기기 지원 여부 등 고려
if user_context.region == 'BR' and user_context.has_whatsapp:
return Challenge.WHATSAPP_OTP
if user_context.region == 'KR' and account_info.has_naver:
return Challenge.NAVER_OAUTH
if account_info.last_success_method == 'EMAIL_OTP':
return Challenge.EMAIL_OTP
# 기본값으로 SMS OTP 반환
return Challenge.SMS_OTP
본론 1: '다른 방법으로 시도' — 막다른 길 제거
기존 시스템의 가장 큰 문제는 인증 실패 시 사용자가 갇히는 것이었습니다. 비밀번호를 잊으면 재설정 흐름으로 빠지고, SMS를 못 받으면 처음부터 다시 시작해야 했죠.
에어비앤비는 '모든 인증 화면에는 탈출구가 있어야 한다'는 원칙을 세우고, Challenge Picker라는 서버 주도 컴포넌트를 도입했습니다. 이 컴포넌트는 기본 인증 수단뿐 아니라, 예측 성공률에 따라 정렬된 대안 목록을 함께 반환합니다.
# Challenge Picker 응답 예시 (JSON)
{
"primary_challenge": "SMS_OTP",
"alternatives": [
{"method": "EMAIL_OTP", "rank": 1},
{"method": "PASSWORD", "rank": 2},
{"method": "NAVER_OAUTH", "rank": 3}
]
}
이렇게 하면 사용자가 '다른 방법으로 시도'를 탭해도 흐름이 재시작되지 않고, 맥락에 맞게 적응합니다. 실패 경험이 줄어들고, 로그인 성공률이 자연스럽게 올라갑니다.
본론 2: 서버 주도 화면 렌더링 — 코드 60% 감소의 비밀
에어비앤비는 인증 화면 자체를 서버 스키마로 정의하고, 클라이언트는 단순한 렌더러 역할만 하도록 설계했습니다. 화면의 순서, 문구, 흐름 로직이 모두 서버 응답에 포함되므로, 앱 업데이트 없이도 실험과 정책 변경이 가능합니다.
이 전환의 효과는 즉각적이었습니다:
- 클라이언트 코드 60% 감소 (웹 번들 100KB 축소)
- 실험 주기 단축: 아이디어에서 결과 측정까지 수주 → 수일
- 로그인 시간 대폭 감소 (가장 성공 확률 높은 도전을 먼저 제시)
# 서버 주도 화면 정의 예시 (개념)
SCREEN_SCHEMA = {
"type": "challenge",
"title": "본인 확인",
"fields": [{"type": "otp_input", "length": 6}],
"primary_action": {
"type": "verify_otp",
"endpoint": "/auth/challenge/verify"
},
"fallback": {
"type": "challenge_picker",
"alternatives": [...]
}
}
주의사항: 서버 주도 아키텍처의 한계
이 방식은 강력하지만, 모든 팀에 적합한 것은 아닙니다.
- 서버 의존성 증가: 오프라인 환경이나 네트워크 지연 시 인증 자체가 불가능할 수 있습니다.
- 복잡한 상태 관리: 서버와 클라이언트의 상태 동기화가 어렵고, 스키마 버전 관리가 필수적입니다.
- 초기 구축 비용: 서버 주도 시스템을 설계하는 데 상당한 엔지니어링 리소스가 필요합니다.
또한, 정책 엔진이 아직 초기 단계라는 점도 인지해야 합니다. 에어비앤비도 "최적화의 시작일 뿐"이라고 밝히고 있습니다.
한국 개발 생태계에서의 적용 맥락
한국은 네이버, 카카오, 토스 등 국내 신원 제공자가 강세인 시장입니다. 글로벌 서비스라면 반드시 한국 사용자에게 익숙한 인증 수단을 최우선으로 제공해야 합니다. 예를 들어, 카카오 로그인을 지원하지 않는 서비스는 한국에서 상당한 사용자 이탈을 경험할 수 있습니다.
또한, 국내 SI 환경에서는 레거시 시스템과의 통합이 큰 과제입니다. 서버 주도 화면을 도입하려면 기존 클라이언트 로직을 단계적으로 마이그레이션하는 전략이 필요합니다.
결론: 인증은 제품 경험이다
에어비앤비의 사례는 인증 시스템이 단순한 기술적 장벽이 아니라 제품 성장의 핵심 동인임을 보여줍니다. 식별-도전 모델, 막다른 길 제거, 서버 주도 렌더링은 모두 사용자 행동에 대한 깊은 이해에서 출발했습니다.
다음 단계로는, 인증 전용 정책 엔진을 직접 설계해보거나, 서버 주도 UI 프레임워크(예: Formly, JSON Forms)를 학습해보는 것을 추천합니다. 인증은 끝없이 진화하는 영역이며, 컨텍스트에 따라 최적의 경험을 제공하는 것이 핵심입니다.
함께 보면 좋은 글
본 글은 에어비앤비 엔지니어링 블로그의 사례를 기반으로 재구성한 것입니다.
