Flexible Authentication - 수백만 사용자를 위한 Airbnb의 인증 재설계

Airbnb는 여행 예약처럼 로그인 간격이 길고 사용 환경이 다양한 서비스에서 인증 실패가 예약과 매출 손실로 이어진다고 보고, 10년간 누적된 로그인 방식을 Flexible Authentication으로 재설계함 핵심은 Identify first, then Challenge로, 사용자가 먼저 어떤 계정에 들어가려는지 식별한 뒤 서버의 정책 엔진이 계정 이력/지역/플랫폼 등을 바탕으로 성공 가능성이 높은 인증 방식을 선택함 인증 화면마다 Try another way를 제공해 막다른 흐름을 없애고, 현재 계정에서 사용할 수 있는 다른 인증 수단을 성공 가능성 순으로 보여줘 처음부터 다시 시작하지 않아도 되게 함 인증 흐름 전체를 서버 주도형 UI로 바꿔 클라이언트는 화면을 렌더링하고 액션만 전달하도록 단순화했으며, 앱 업데이트 없이 인증 순서/문구/실험을 변경할 수 있게 됨 그 결과 클라이언트 코드가 60% 감소, 웹 번들이 100KB 줄었고, 인증 성공률은 2.6% 증가, 중복 계정은 27% 감소, SMS OTP 비용은 약 11% 절감됨 로그인 간격이 긴 서비스의 인증 문제 Airbnb 사용자는 매일 로그인하는 경우도 있지만, 여행객은 몇 달에 한 번 서비스를 사용할 수 있고 호스트도 예약이 들어올 때만 접속할 수 있음 이런 긴 세션 간격에서는 비밀번호나 이전에 사용한 로그인 방식을 잊는 일이 예외가 아니라 서비스 구조에서 자연스럽게 발생하는 문제임 인증 시스템도 10년 동안 Social Login, Email OTP, Phone 등 새로운 수단이 계속 추가되면서 복잡해짐 목표는 사용자가 언제, 어떤 기기에서 돌아오더라도 이전 계정을 쉽게 다시 찾고 로그인하도록 만드는 것이었음 Identify first, then Challenge 기존 인증은 사실상 "이 사람이 본인임을 증명할 수 있는가"라는 하나의 질문으로 처리했지만, 실제 문제는 현재 사용자에게 어떤 인증 방법이 가장 성공 가능성이 높은가에 가까움 예를 들어 브라질에서 전화번호로 가입한 사용자는 SMS보다 WhatsApp OTP가 더 적합할 수 있음 한국의 재방문 호스트는 Google보다 Naver 로그인이 더 적합할 수 있음 새 방식에서는 인증을 두 단계로 분리함 사용자가 이메일/전화번호/Social Login 등 원하는 방식으로 어떤 계정인지 먼저 식별 계정이 확인되면 서버의 정책 엔진이 가장 성공 가능성이 높은 Challenge를 선택 정책 엔진은 ...