패스키란? 비밀번호를 없애기 전에 확인할 기기 분실과 복구

패스키의 로그인 편의와 별도로 복구 수단을 준비해야 한다는 점을 표현한 AI 생성 이미지입니다.

패스키를 등록하면 비밀번호 대신 휴대폰 잠금 해제와 비슷한 화면으로 로그인할 수 있습니다. 편리하지만 등록 버튼을 누르기 전에 한 가지를 더 물어야 합니다. 이 휴대폰을 잃어버린 뒤 새 기기에서는 어떻게 로그인할 것인가?

패스키의 암호 방식과 계정 복구는 같은 문제가 아닙니다. 패스키가 피싱에 강하더라도, 사용자가 저장 위치를 모르거나 유일한 기기를 잃으면 서비스가 제공하는 다른 복구 경로에 의존하게 됩니다. 비밀번호를 지우기 전에 패스키 제공자, 동기화 여부, 예비 로그인 수단을 확인해야 하는 이유입니다.

패스키 로그인에서는 무엇이 서버로 가는가

패스키는 FIDO 표준에 기반한 공개키 자격 증명입니다. 등록할 때 기기 또는 자격 증명 제공자가 공개키와 비밀키 한 쌍을 만들고, 사이트에는 공개키 쪽이 등록됩니다. 로그인할 때 사이트가 일회성 요청을 보내면 기기가 대응하는 비밀키로 서명한 결과를 돌려줍니다.

흐름을 줄이면 다음과 같습니다.

등록
사이트 ── 등록 요청 ──> 브라우저·운영체제
사이트 <── 공개키와 자격 증명 식별자 ── 기기

로그인
사이트 ── 새로운 challenge ──> 기기
사이트 <── 비밀키로 서명한 응답 ── 기기
사이트 ── 저장한 공개키로 검증 ──> 로그인 허용 또는 거부

여기서 지문, 얼굴, 기기 PIN은 비밀키 사용을 승인하는 장치입니다. FIDO Alliance의 패스키 안내는 패스키가 공개키 암호에 기반하며 사용자가 기기 잠금을 풀 때 쓰는 생체 정보·PIN·패턴으로 로그인을 승인한다고 설명합니다. 같은 안내는 생체 정보와 처리가 기기에 남고 원격 서버에는 생체 확인이 성공했다는 보증만 전달된다고 밝힙니다.

따라서 “쇼핑몰에 지문을 등록했다”는 설명은 정확하지 않습니다. 쇼핑몰은 패스키의 공개키와 로그인 검증에 필요한 정보를 보관하고, 지문 원본을 받아 비교하는 구조가 아닙니다. 다만 사이트가 별도로 수집하는 기기·계정 메타데이터까지 없어진다는 뜻은 아닙니다.

웹 서비스가 등록·로그인에서 확인할 값

사용자 입장에서는 화면만 보이지만, 서비스는 등록과 로그인에서 서로 다른 값을 주고받습니다. 아래는 WebAuthn 라이브러리의 내부 구현을 대신하는 코드가 아니라, 복구와 감사 설계를 위해 기록할 경계를 보여주는 표입니다.

단계	브라우저·패스키 제공자와 주고받는 값	서버가 보관·검증할 값
등록 시작	서버가 만든 일회성 challenge, 사이트의 rp.id, 사용자 식별자	challenge의 만료·사용 여부, 계정과 등록 세션의 연결
등록 완료	credential ID, 공개키, authenticator data, 사용자 검증 결과	credential ID·공개키·사용자 계정·sign counter 등 필요한 자격 증명 정보
로그인 시작	새 challenge와 허용된 credential 정보	challenge를 세션과 묶고 재사용을 거부
로그인 완료	credential ID, client data, authenticator data, signature	저장한 공개키로 서명 검증, origin·challenge·사용자 검증 결과 확인

서버에는 패스키의 비밀키나 생체 원본을 저장하지 않습니다. 반대로 challenge 재사용, 잘못된 origin, 다른 계정의 credential ID를 허용하면 패스키를 붙였다는 사실만으로 안전한 구현이 되지 않습니다. 정확한 필드와 검증 순서는 WebAuthn 구현체와 현재 사양을 따라야 합니다.

왜 비밀번호보다 피싱에 강한가

비밀번호는 사용자가 문자 그대로 입력하므로 가짜 사이트가 같은 화면을 만들면 빼앗을 수 있습니다. 패스키의 자격 증명은 등록된 사이트의 범위에 연결되고, 사용자가 복사해 다른 사이트에 붙여넣을 공통 비밀이 없습니다. FIDO는 이를 피싱 저항성의 핵심으로 설명합니다.

이 장점에도 경계가 있습니다.

• 패스키가 로그인 전 피싱을 줄여도 로그인 뒤 세션 탈취까지 자동으로 막지는 않습니다.
• 복구 이메일이나 고객센터가 약하면 공격자는 그 우회 경로를 노릴 수 있습니다.
• 사용자가 이미 로그인한 상태에서 악성 동작을 승인하는 문제는 패스키만으로 해결되지 않습니다.
• 사이트가 패스키와 비밀번호를 함께 허용한다면 실제 계정 보안은 남아 있는 약한 로그인 경로에도 영향을 받습니다.

즉 패스키는 인증 수단의 성질을 바꾸지만 계정의 모든 보안 경계를 대체하지는 않습니다.

기기를 잃었을 때는 저장 형태부터 확인합니다

FIDO는 패스키를 여러 기기에 동기화할 수 있는 형태와 한 기기에 묶인 형태로 구분합니다. 어느 쪽이 더 좋다고 단순 비교하기보다, 내 사용 환경에서 어떻게 다시 접근할지를 봐야 합니다.

저장 형태	새 기기에서 기대할 경로	잃었을 때 확인할 것
동기화형 패스키	같은 패스키 제공자 계정으로 새 기기에 동기화	제공자 계정 복구, 다른 로그인된 기기, 동기화 범위
기기 귀속형 패스키	등록한 기기 또는 하드웨어 보안 키를 직접 사용	두 번째 보안 키, 서비스의 별도 복구 절차
다른 기기의 패스키 사용	기존 휴대폰으로 QR 기반 교차 기기 인증	원래 휴대폰 없이도 가능한 독립 복구 경로
조직 관리 자격 증명	회사가 정한 등록·교체·폐기 절차	관리자 복구 정책과 퇴사·기기 교체 처리

동기화형이라면 패스키는 특정 휴대폰 한 대보다 패스키 제공자 계정에 의존합니다. 새 기기에서 같은 제공자 계정을 설정하면 패스키를 사용할 수 있다는 것이 FIDO 설명입니다. 이 경우 복구 질문은 “휴대폰을 잃으면 끝인가”에서 “패스키 제공자 계정을 어떻게 되찾는가”로 이동합니다.

기기 귀속형은 복제되지 않는 성질이 필요한 경우 유용할 수 있지만, 유일한 보안 키를 잃으면 그 키 자체를 복원할 수 있다고 기대해서는 안 됩니다. 두 번째 키를 등록하거나 서비스가 허용하는 별도 복구 경로를 준비해야 합니다.

QR 코드로 휴대폰 패스키를 노트북에서 쓰는 교차 기기 인증도 복구와 혼동하기 쉽습니다. 기존 휴대폰으로 새 기기의 로그인을 승인했다면 편의성은 확인했지만, 그 휴대폰이 사라진 상황은 아직 시험하지 않은 것입니다.

비밀번호를 지우기 전 15분 점검

중요한 계정이라면 기존 로그인 세션을 유지한 채 다음 순서로 확인합니다. 실제 메뉴 이름은 서비스와 운영체제에 따라 다릅니다.

1. 패스키가 어디에 저장됐는지 적습니다

등록 화면에 표시된 제공자를 기록합니다. 운영체제의 기본 자격 증명 관리자일 수도 있고, 타사 비밀번호 관리자나 하드웨어 보안 키일 수도 있습니다. “내 휴대폰”이라고만 적으면 새 기기에서 무엇을 복구해야 하는지 알기 어렵습니다.

2. 등록된 패스키 목록을 확인합니다

서비스의 보안 설정에서 패스키의 이름, 등록일, 기기 또는 제공자 단서를 확인합니다. 알아볼 수 없는 항목을 무작정 삭제하기 전에 현재 사용 중인 기기와 대조합니다.

3. 별도 환경에서 새 로그인을 시험합니다

기존 세션에서 로그아웃하지 말고 다른 브라우저 프로필이나 다른 지원 기기에서 새 로그인을 시도합니다. 성공 여부와 사용한 경로를 구분해 기록합니다.

관찰	실제로 확인한 것	아직 확인하지 못한 것
새 노트북에서 휴대폰 QR로 성공	교차 기기 인증	휴대폰 분실 뒤 복구
새 휴대폰에서 제공자 로그인 후 성공	제공자 동기화 경로	제공자 계정까지 잃은 경우
예비 보안 키로 성공	두 번째 기기 귀속 자격 증명	서비스 고객센터 복구
복구 코드 화면만 확인	코드 발급 가능	보관한 코드의 실제 유효성

4. 원래 기기 없이 남는 길을 확인합니다

다른 로그인된 기기, 두 번째 보안 키, 서비스가 제공하는 복구 코드나 계정 복구 절차 중 적어도 하나를 확인합니다. 복구 코드를 같은 휴대폰의 사진첩에만 보관하면 휴대폰 분실과 함께 사라질 수 있습니다.

5. 마지막에 약한 경로를 정리합니다

새 로그인과 복구가 확인된 뒤 비밀번호 유지 여부, SMS 복구, 오래된 패스키를 정리합니다. 서비스가 비밀번호 제거를 지원하지 않는다면 패스키를 추가했다는 사실만으로 비밀번호 공격면이 없어졌다고 보지 않습니다.

개발자는 등록 성공보다 복구 상태를 함께 보여줘야 합니다

서비스를 만드는 쪽이라면 “패스키 등록 완료”만 표시해서는 사용자가 무엇을 준비했는지 알기 어렵습니다. 최소한 다음 정보가 필요합니다.

• 현재 등록된 패스키 목록과 사용자가 알아볼 수 있는 이름
• 패스키 추가·이름 변경·삭제 시 재인증
• 마지막 패스키를 지울 때 남는 로그인 수단에 대한 경고
• 계정 복구가 패스키 제공자 동기화인지 서비스 자체 절차인지에 대한 설명
• 새 기기 등록과 기존 기기 폐기 순서
• 조직 계정이라면 관리자 복구와 감사 기록

삭제 동작도 주의해야 합니다. 기기에서 패스키를 지운 것과 서비스 계정의 등록 목록에서 자격 증명을 철회한 것은 같은 화면에서 동시에 처리되지 않을 수 있습니다. 사용자는 어느 쪽을 삭제했는지 확인할 수 있어야 합니다.

패스키를 켜기 전에 작성할 한 장

서비스:
패스키 제공자:
동기화형 / 기기 귀속형 / 확인 못함:
새 기기 로그인 시험 결과:
원래 기기 없이 가능한 경로:
예비 보안 키 또는 다른 로그인된 기기:
복구 코드 보관 위치:
남아 있는 비밀번호·SMS 경로:

이 기록의 목적은 복잡한 보안 설계를 사용자에게 떠넘기는 것이 아닙니다. “패스키를 만들었다”와 “계정을 계속 사용할 수 있다”를 분리해서 확인하려는 것입니다.

정리

패스키는 공개키 암호를 이용하므로 사이트에 공통 비밀번호나 지문 원본을 보내지 않고 로그인할 수 있습니다. 피싱 저항성은 큰 장점이지만, 휴대폰 분실 뒤의 접근은 패스키가 저장된 방식과 제공자 계정, 서비스의 복구 정책에 달려 있습니다.

패스키를 켠 직후 비밀번호부터 지우지 마세요. 저장 제공자를 확인하고, 기존 세션을 유지한 채 새 기기 로그인을 시험하고, 원래 기기 없이 남는 독립 경로를 준비한 뒤 약한 로그인 수단을 정리하는 순서가 안전합니다.

자료 확인일과 한계

자료 확인일은 2026년 9월 7일입니다. FIDO Alliance 패스키 안내, FIDO 인증 사양 개요, Google의 패스키 등록 설명을 기준으로 구조를 정리했습니다.

이 글은 특정 은행·쇼핑몰·운영체제 조합의 복구 메뉴를 직접 시험한 비교 글이 아닙니다. 패스키 제공자의 동기화와 서비스의 계정 복구는 제품별로 다르므로, 중요한 계정에서는 해당 서비스의 현재 안내를 함께 확인해야 합니다.