Airbnb는 게스트와 호스트가 수개월 간격으로 불규칙하게 로그인하는 특성 때문에 기존 10년 된 인증 시스템을 전면 재설계했다. "이 사람을 인증할 수 있는가?"가 아니라 "이 사용자에게 가장 쉬운 인증 방법은 무엇인가?"로 질문을 바꾼 것이 핵심 전환점이었다. 서버 주도(server-driven) 인증 아키텍처로 전환해 코드 60% 감소, 인증 성공률 2.6% 향상을 달성했다.
핵심 포인트- 인증을 "신원 확인"과 "챌린지 선택" 두 단계로 분리, 서버 정책 엔진이 세션 컨텍스트와 과거 데이터로 최적 방법을 결정한다.
- Challenge Picker를 도입해 어떤 인증 화면에서도 다른 방법으로 전환 가능 — 막힌 곳 없는 인증 흐름 구현.
- 모든 인증 화면을 서버 주도로 전환, 클라이언트는 thin renderer 역할만 해 앱 배포 없이 지역별 전략 즉시 변경 가능.
- 런칭 이후 20건 이상 실험 진행, 리드타임이 수 주에서 수 일로 단축.
- 코드 60% 감소, 번들 100KB 축소, 인증 성공률 +2.6%, 중복 계정 -27%, OTP 비용 -11%.
상세 정리- 문제 배경: 게스트는 여행 예약 간격이 길어 이전 로그인 방법을 기억 못 하고, 호스트는 예약 알림이 올 때만 접속한다. 로그인 실패 = 예약 손실이라 실패율이 핵심 비즈니스 지표였다.
- 단계 분리 설계: 사용자가 먼저 이메일/전화번호/소셜로 신원을 제시하면, 서버 정책 엔진이 세션 컨텍스트와 과거 데이터를 보고 최적 챌린지를 선택한다.
- 지역별 최적화: 브라질 사용자에게는 SMS 대신 WhatsApp OTP, 한국 호스트에게는 Google 대신 Naver 로그인 우선 제공 — 클라이언트 코드 변경 없이 서버에서만 조정.
- 클라이언트 무결정 원칙: 어떤 챌린지를 보여줄지는 클라이언트가 절대 결정하지 않는다. 서버가 결정하므로 앱 심사 없이 지역별 전략을 즉시 변경할 수 있다.
- Challenge Picker: 예측 성공률 순으로 대안 목록을 제공하는 서버 주도 컴포넌트. "다른 방법 시도"를 누르면 흐름이 재시작 없이 이어진다.
- 서버 주도 화면: 신원 입력, 챌린지, 계정 선택, 오류 복구 등 모든 단계가 서버가 정의하는 화면 단위로 추상화된다. 클라이언트는 화면 타입을 렌더링하고 액션만 반환한다.
- 타입 자동 생성: 서버 정의 화면에서 Web/iOS/Android용 타입 정의를 자동 생성, 클라이언트-서버 불일치를 개발 단계에서 포착한다.
- 실험 가속: 기존에는 앱 리뷰 + 롤아웃 대기로 수 주 소요. 서버 주도 전환 후 아이디어에서 측정 결과까지 수 일로 단축, 런칭 후 20건 이상 실험 진행.
- 결과: 코드 60% 감소, 번들 100KB 축소, 인증 성공률 +2.6%, 중복 계정 -27%, OTP 비용 -11%.
왜 읽나글로벌 다중 플랫폼에서 인증 시스템을 서버 주도 아키텍처로 전환하려는 백엔드·모바일 엔지니어에게 설계 원칙과 정량 결과를 담은 실전 참고.