앱 MVP passkey 로그인: 계정 연결·서버 검증·복구 경로를 나누는 5가지 기준
앱 MVP에 passkey 로그인을 넣을 때 ‘생체인증 버튼을 하나 더 둔다’고 생각하면 기획이 빠르게 섞입니다. 사용자가 어떤 서비스 계정에 passkey를 연결하는지, 앱이 서버에서 어떤 생성·로그인 옵션을 받는지, 기기 안의 credential provider와 서버가 각각 무엇을 보관하는지, 새 기기에서 어떤 경로를 확인할지, passkey를 쓸 수 없을 때 어떤 대체 경로를 둘지는 서로 다른 결정입니다.
Android 공식 문서는 Credential Manager가 passkey뿐 아니라 비밀번호·연동 로그인 같은 여러 인증 수단을 다룬다고 설명합니다(C001). 따라서 passkey를 추가한다고 기존 로그인이나 고객지원 복구 흐름이 저절로 사라진다고 가정하지 않는 편이 안전합니다. 이 글은 특정 앱의 보안성·심사·출시 결과를 판단하지 않으며, 실제 서비스는 서버 구조와 적용 정책을 별도로 검토해야 합니다.
먼저 구분할 것: passkey와 기기 잠금 방식은 같은 말이 아닙니다
passkey는 서비스 계정에 연결된 인증 수단이고, 사용자는 기기의 화면 잠금 방식으로 사용을 승인할 수 있습니다. Android와 FIDO Alliance의 설명에는 PIN·패턴·기기 비밀번호·생체인식이 예로 나옵니다(C004). 이것은 앱 서버가 사용자의 지문이나 얼굴 정보를 받는다는 뜻이 아닙니다. 기기에서 어떤 승인 화면이 보였는지와 서버가 어떤 인증 응답을 검증했는지를 따로 설계해야 합니다.
제품 문서에서는 적어도 ‘계정 식별자’, ‘사용자에게 제시되는 계정 선택 정보’, ‘passkey 등록이 가능한 시점’, ‘등록 취소 뒤 남는 로그인 수단’을 나눠 두세요. 같은 사람이 여러 계정을 쓰는 서비스라면 특히 계정 선택과 passkey 생성 완료를 하나의 신호로 합치지 않는 편이 좋습니다. 화면을 열었다는 기록만으로 등록 완료나 로그인 완료를 계산해서도 안 됩니다.
기준 1: passkey를 만들 계정과 서버의 생성 옵션을 먼저 맞춥니다
Android의 passkey 흐름에서 클라이언트 앱은 먼저 앱 서버에 credential 생성에 필요한 옵션을 요청합니다. 그 다음 앱은 이 옵션을 Credential Manager API에 전달해 공개키·개인키 쌍을 생성합니다(C002). 즉, 앱 화면의 ‘등록’ 버튼과 서버가 어떤 계정에 어떤 생성 요청을 허용했는지는 동일한 거래로 추적할 필요가 있습니다.
이 단계의 완료 기준을 ‘기기에서 화면이 떴다’로 잡으면 부족합니다. 팀은 서버가 발급한 옵션이 어느 계정·어느 요청에 속하는지, 중복 탭·네트워크 재시도·계정 전환 때 어떤 요청을 폐기하거나 다시 시작하는지, 사용자가 취소했을 때 UI가 어느 상태로 돌아가는지를 문서화하세요. 이런 제품 규칙은 공식 문서가 모든 앱에 하나의 답을 주는 영역이 아니므로, 서비스의 계정 정책으로 별도 결정해야 합니다.
기준 2: 공개키 보관과 private key 보관을 한 저장소로 말하지 않습니다
Android 문서는 생성 뒤 공개키는 앱 서버에 저장되고, private key는 Google Password Manager 같은 credential provider를 통해 사용자 기기에 안전하게 저장된다고 설명합니다(C002). 따라서 운영 체크리스트에는 ‘서버의 공개키·credential 식별 정보’와 ‘기기 또는 provider가 다루는 private key’를 구분해 적는 편이 좋습니다.
여기서 중요한 것은 private key 값을 앱의 자체 데이터베이스에 복사해 관리하겠다는 식으로 흐름을 바꾸지 않는 것입니다. 어떤 provider가 사용 가능한지와 계정 선택 UI가 어떤 조건에서 달라지는지는 Credential Manager 통합 범위와 앱 지원 환경을 확인하며 정하세요(C001).
WebView나 다른 로그인 수단과 어떤 전환 규칙을 둘지도 별도 결정입니다. 지원하지 않는 환경에서 보여 줄 안내는 ‘passkey 실패’라는 한 문장보다 다음 가능한 로그인 방법을 정확히 제시하는 편이 낫습니다.
우리 앱 MVP의 로그인·계정 연결 흐름을 출시 전 점검하기
기준 3: 로그인 성공은 assertion 수신이 아니라 서버 검증까지입니다
로그인 단계에서 앱은 서버로부터 credential 요청 옵션을 받습니다. 서버는 나중에 확인할 challenge를 저장하고, 사용자가 기기 잠금으로 passkey 사용을 승인하면 credential provider가 private key로 assertion에 서명합니다. 앱은 이 assertion을 서버로 보내고, 서버는 저장한 challenge와 assertion의 signature를 공개키로 검증합니다(C003).
따라서 앱 화면에서 계정을 골랐거나 assertion이 앱에 도착한 상태는 로그인 완료와 다릅니다. 제품 이벤트도 ‘로그인 시작’, ‘사용자 취소’, ‘provider 응답 수신’, ‘서버 검증 통과’, ‘세션 발급 또는 다음 화면 진입’을 별개로 두세요.
실패 원인을 사용자에게 노출할 때에는 서명·challenge 같은 내부 상세를 그대로 보여 주기보다, 재시도·다른 로그인 수단·지원 문의 중 실제로 가능한 다음 행동을 안내하는 것이 좋습니다.
기준 4: 새 기기 이동과 passkey의 일반 로그인 흐름을 섞지 않습니다
새 기기에서의 로그인 경험은 passkey 화면만으로 완성되지 않습니다. Android에는 Restore Credentials라는 별도 기능이 있으며, 이전 기기에서 사용자가 인증한 뒤 restore key를 만들고 새 기기의 설정 과정에서 이를 사용해 접근을 복원하는 흐름을 설명합니다(C005).
이 기능은 passkey·비밀번호·Google 로그인과 함께 쓸 수 있는 별도 기능이며, Android 데이터 백업·기기 잠금 같은 조건과 다계정·시스템 프로필 제약도 문서에 있습니다(C005).
그러므로 ‘passkey를 넣으면 모든 새 기기에서 자동 로그인된다’고 안내하면 안 됩니다. 앱이 Restore Credentials를 실제로 통합할지, passkey provider 동기화에 의존할지, 새 기기에서 사용자에게 다시 어떤 로그인 수단을 보여 줄지는 제품·플랫폼·계정 정책에 따라 검수해야 합니다. 사용자 데이터와 로컬 설정을 함께 옮기는 문제도 인증 복원과는 다른 작업입니다.
기준 5: 대체 로그인과 복구는 passkey 실패 화면 뒤에 따로 설계합니다
passkey 사용자가 기기를 잃어버렸거나 provider에 해당 credential이 없거나 계정을 잘못 선택했을 때, 서비스가 어떤 대체 경로를 제공할지는 팀이 결정해야 합니다. 공식 문서가 passkey의 공개키 기반 검증 흐름을 설명한다고 해서 모든 서비스의 복구 정책을 대신 정해 주지는 않습니다.
기존 비밀번호, 연동 로그인, 이메일 확인, 고객지원 이관 중 무엇을 남길지와 위험도가 높은 변경에 어떤 재확인이 필요한지는 서비스의 계정 구조와 위협 모델에 맞춰야 합니다.
복구 흐름을 만들 때는 ‘복구 요청 시작’, ‘계정 소유 확인’, ‘새 인증 수단 등록 허용’, ‘기존 인증 수단의 유지·해제’, ‘세션과 알림 처리’를 하나의 완료로 묶지 마세요. 특히 계정 삭제나 외부 인증 연결 해제와 같은 되돌리기 어려운 동작은 로그인 성공과 별도 권한·확인 규칙을 두는 편이 좋습니다. passkey 도입은 계정 복구를 없애는 일이 아니라, 어떤 상황에서 어느 인증 수단을 신뢰할지 명확히 정하는 작업입니다.
출시 전 확인표
구분 | 팀이 확인할 질문 | 완료로 보지 말아야 할 것 |
|---|---|---|
계정 연결 | 생성 옵션과 대상 계정이 서버에서 일치하는가 | 등록 화면만 연 상태 |
키 경계 | 서버 공개키 기록과 provider 처리 범위를 구분했는가 | 앱이 임의로 private key를 보관한다고 가정한 상태 |
로그인 검증 | challenge 저장과 assertion 검증 뒤에만 세션을 발급하는가 | 계정을 선택했거나 assertion을 받은 상태 |
새 기기 | 실제 지원 기능·조건·다계정 제약을 QA했는가 | 모든 기기에서 자동 복원을 약속한 상태 |
대체 경로 | provider 미사용·취소·기기 분실 때의 다음 행동이 있는가 | 오류 문구만 보여 준 상태 |
관련 글: 앱 MVP 생체인증 의사결정은 기기 잠금 기반 확인과 대체 수단을 다룹니다. 이번 글은 passkey의 서버 challenge 검증과 계정·provider·복구 경계를 중심으로 다룹니다.
앱 MVP passkey 로그인과 복구 경로를 함께 정리하기
자주 묻는 질문
passkey 로그인은 생체인증 로그인과 같은 뜻인가요?
같은 뜻으로 단정할 수 없습니다. passkey는 서비스 계정에 연결된 인증 수단이며 사용자는 기기 잠금 방식으로 사용을 승인할 수 있습니다. Android와 FIDO Alliance 문서에는 PIN·패턴·비밀번호·생체인식 등이 예시로 제시됩니다. 서버가 생체정보를 받는다고 해석해서는 안 됩니다.
앱이 assertion을 받으면 바로 로그인 처리해도 되나요?
아닙니다. Android 문서는 서버가 저장한 challenge가 맞는지와 공개키로 assertion signature를 검증하는 단계를 설명합니다. 계정 선택이나 앱의 응답 수신은 서버 검증·세션 발급과 별도 상태로 기록하세요.
passkey를 넣으면 계정 복구 기능은 없어도 되나요?
그렇게 단정할 수 없습니다. passkey의 인증 흐름과 서비스의 복구 정책은 별도 결정입니다. provider에 credential이 없을 때, 사용자 취소, 기기 분실 등에서 어떤 대체 수단을 제공할지는 계정 구조와 실제 지원 환경을 검토해 정해야 합니다.
새 기기에서는 자동으로 로그인되나요?
모든 경우에 자동 로그인된다고 안내하면 안 됩니다. Android Restore Credentials는 새 기기 접근 복원을 위한 별도 기능이며, 데이터 백업·기기 잠금·다계정과 시스템 프로필 같은 조건과 제약을 문서에 명시합니다. 실제 통합 범위와 테스트 결과를 기준으로 안내하세요.
공식 출처
Android Developers: Credential Manager (2026-09-21 확인)
Android Developers: About passkeys (2026-09-21 확인)
Android Developers: Restore Credentials (2026-09-21 확인)
FIDO Alliance: Passkeys (2026-09-21 확인)
발행일: 2026-09-21 · 작성: 유인어스 정책자금·정부지원사업 인사이트