아침 8시 10분, 출근길 지하철에서 휴대폰이 사라졌다고 가정해 보겠습니다. 회사 메일은 패스키로 로그인하고, 비밀번호는 몇 달 전에 지웠습니다. 새 휴대폰을 사면 다시 들어갈 수 있을까요?
정답은 “패스키라서 된다”도, “패스키라서 안 된다”도 아닙니다. 평소 쓰던 패스키가 다른 기기와 동기화되는 방식인지, 노트북이나 물리 보안키 같은 두 번째 인증기가 있는지, 그리고 패스키를 보관하는 계정 자체를 복구할 수 있는지에 달려 있습니다.
이 글은 패스키를 만드는 법보다 조금 더 중요한 질문을 다룹니다. 주 기기가 없어졌을 때 어떤 길로 계정에 다시 들어갈 것인가입니다.
평소 로그인 경로는 하나여도 괜찮지만, 복구 경로는 같은 사고에 함께 사라지지 않도록 나눠 두는 편이 안전합니다.
패스키를 ‘외우지 않는 비밀번호’라고 부르면 놓치는 것
패스키(passkey)는 외울 필요가 없는 비밀번호가 아닙니다. 로그인 방식 자체가 다릅니다.
비밀번호 로그인에서는 사용자가 비밀 문자열을 사이트에 보내고, 사이트가 그 값이 맞는지 확인합니다. 패스키에서는 기기가 사이트마다 서로 다른 공개키와 개인키 한 쌍을 만듭니다. 공개키는 사이트가 보관하고, 개인키는 휴대폰·PC·보안키 또는 패스키 관리 시스템에 남습니다.
로그인할 때 사이트는 “이번 요청이 진짜인지 증명해 달라”는 일회용 문제를 보냅니다. 사용자가 얼굴·지문·기기 PIN으로 승인하면, 기기가 개인키로 답에 서명합니다. 사이트는 공개키로 그 서명을 확인합니다. 개인키 자체는 사이트로 가지 않습니다.
호텔 프런트에는 어느 열쇠가 어느 방과 짝인지 확인할 정보가 있습니다. 실제 열쇠는 투숙객이 갖습니다. 얼굴이나 지문은 프런트에 보내는 정보가 아니라, 내 휴대폰이 “이 열쇠를 지금 사용해도 되는 사람인지” 확인하는 장치에 가깝습니다.
지문이나 얼굴 사진이 사이트에 저장되는 것은 아니다
패스키에서 생체정보는 보통 기기 안에서 사용자 확인에 쓰입니다. 사이트가 받는 것은 얼굴 사진이나 지문 원본이 아니라, 인증 장치가 만든 유효한 서명입니다. 기기 PIN을 써도 같은 원리로 동작할 수 있습니다.
그래서 “생체인증을 바꾸면 패스키가 사라지는가”와 “사이트가 내 지문을 갖는가”는 별개의 질문입니다. 사이트는 패스키의 공개키를 갖고, 기기는 누가 개인키를 사용할 수 있는지를 자체적으로 판단합니다.
다만 잠금이 풀린 기기를 누군가 오래 쓸 수 있다면 다른 위험이 생깁니다. 화면 잠금 PIN을 생일처럼 쉽게 정하지 않고, 원격 잠금·삭제 기능과 운영체제 업데이트를 켜 두어야 하는 이유입니다. 기기 안에서 처리되는 정보와 외부로 나가는 정보를 구분하는 기준은 온디바이스 LLM 개인정보 가이드에서도 같은 관점으로 설명합니다.
가짜 로그인 페이지에서 강한 이유
비밀번호 피싱은 사람이 주소창을 잘못 보고 비밀 문자열을 입력하는 순간 성립합니다. 패스키는 등록된 웹사이트의 도메인과 연결됩니다. example.com용 패스키는 모양이 비슷한 examp1e.com에서 정상적으로 작동하지 않습니다.
이 성질 덕분에 패스키는 다음 문제를 줄이는 데 유리합니다.
| 기존 로그인에서 생기는 문제 | 패스키가 바꾸는 부분 |
|---|---|
| 같은 비밀번호를 여러 사이트에서 사용 | 사이트마다 서로 다른 키 쌍 생성 |
| 가짜 페이지에 비밀번호 입력 | 등록된 도메인에서만 서명 |
| 서버에서 비밀번호 데이터 유출 | 서버에는 로그인용 개인키가 없음 |
| 문자 인증번호를 실시간으로 가로챔 | 일회용 코드 입력 대신 기기 서명 |
그렇다고 계정 사기가 사라지는 것은 아닙니다. 공격자는 이미 로그인된 세션, 약한 복구 절차, 원격제어 앱, 통신사 사칭, 잠금 해제 PIN 엿보기를 노릴 수 있습니다. 전체 보안은 가장 약하게 남아 있는 로그인·복구 경로의 영향을 받습니다.
같은 ‘패스키’여도 잃어버린 뒤의 모습은 다르다
사용자 입장에서는 둘 다 얼굴을 보고 로그인하지만, 저장 방식은 크게 두 갈래입니다.
동기화되는 패스키
운영체제 계정이나 패스키 관리자가 암호화된 형태로 여러 기기 사이에 패스키를 동기화합니다. 휴대폰이 없어져도 같은 제공자 계정을 새 기기에서 안전하게 복구하면 패스키가 다시 나타날 수 있습니다.
편리한 대신, 패스키 제공자 계정이 여러 서비스의 관문이 됩니다. 그 계정의 복구 이메일, 전화번호, 2단계 인증과 복구 코드를 허술하게 두면 편리한 동기화가 새로운 단일 실패 지점이 될 수 있습니다.
특정 기기에 남는 패스키
물리 보안키나 일부 기업용 인증처럼 개인키가 특정 장치를 떠나지 않는 방식입니다. 복제 범위가 작지만 장치를 잃으면 자동으로 새 기기에 나타나지 않습니다. 두 번째 보안키나 조직의 비상 복구 절차가 필요합니다.
| 확인할 질문 | 동기화형 | 기기 귀속형 |
|---|---|---|
| 새 휴대폰에서 바로 쓸 수 있나 | 제공자 계정 복구 뒤 가능한 경우가 많음 | 새 장치를 서비스에 다시 등록해야 할 수 있음 |
| 가장 중요한 보호 대상 | 동기화 계정과 복구 수단 | 물리 장치와 예비 인증기 |
| 일반 사용자에게 편한가 | 대체로 편함 | 관리가 더 필요함 |
| 고권한 업무 계정에 적합한가 | 조직 정책에 따라 다름 | 분리 보관한 보안키와 함께 자주 사용 |
화면에 “패스키”라고만 적혀 있으면 유형이 보이지 않을 수 있습니다. 패스키를 저장하는 운영체제·비밀번호 관리자와 해당 서비스의 도움말에서 동기화 범위를 확인해야 합니다.
휴대폰이 사라진 오전을 시간순으로 따라가 보기
08:10 — 기기를 먼저 잠근다
다른 기기에서 ‘기기 찾기’를 열어 분실 휴대폰을 잠급니다. 회수가 어렵다면 원격 삭제를 검토하고, 통신사에도 분실 신고를 합니다. 이것은 패스키만의 문제가 아니라 이미 로그인된 앱, 문자, 사진과 결제 수단을 함께 보호하는 조치입니다.
08:25 — 열린 세션을 끊는다
이메일, 클라우드, 금융, 비밀번호 관리자에서 분실 기기의 로그인 세션을 종료합니다. 서비스에서 패스키 항목을 삭제하는 것과, 이미 발급된 로그인 세션을 끊는 것은 서로 다른 작업일 수 있습니다.
08:40 — 남아 있는 인증 경로를 고른다
노트북에 같은 패스키가 있다면 가장 빠릅니다. 동기화형이라면 새 휴대폰에서 패스키 제공자 계정을 복구할 수 있습니다. 기기 귀속형이라면 분리 보관한 보안키가 필요할 수 있습니다. 이 셋이 모두 없다면 서비스 사업자의 계정 복구 절차로 넘어갑니다.
09:00 — 무엇을 삭제하는지 이름을 확인한다
보안 설정에는 비슷한 기기 이름과 여러 패스키가 함께 보일 수 있습니다. 등록 날짜, 마지막 사용 시각, 기기 이름을 확인한 뒤 분실 기기의 패스키와 세션을 제거합니다. 정상 기기의 항목을 잘못 지우면 복구 경로까지 줄어듭니다.
09:20 — 사고가 끝나기 전에 백업을 되돌려 놓는다
새 휴대폰에서 로그인이 됐다고 끝난 것이 아닙니다. 예비 보안키, 노트북 패스키, 복구 코드 중 비어 버린 자리를 다시 채워야 다음 사고에도 버틸 수 있습니다.
복구 수단 두 개가 있어도 둘 다 같은 휴대폰 안이라면 한 개다
패스키와 인증 앱, 문자 수신 번호, 복구 이메일 앱이 모두 같은 휴대폰에만 있다면 한 번의 분실로 함께 사라질 수 있습니다. 복구 경로는 개수보다 동시에 잃지 않는 구조가 중요합니다.
개인 사용자에게 현실적인 조합은 다음과 같습니다.
- 주 휴대폰에 동기화형 패스키
- 집이나 사무실의 노트북에 같은 계정으로 로그인
- 주 기기와 떨어진 곳에 보관한 복구 코드 또는 물리 보안키
- 오래된 번호가 아닌 최신 복구 연락처
관리자 계정이나 회사의 핵심 시스템은 조금 다르게 설계합니다.
- 일상용 보안키와 별도 장소의 예비 보안키
- 평소 쓰지 않는 비상 접근 계정
- 한 사람이 아닌 조직이 통제하는 복구 절차
- 분기별 실제 복구 시험과 기록
A 이메일의 복구 주소를 B 이메일로, B의 복구 주소를 A로만 두는 순환 구조도 피해야 합니다. 두 계정이 동시에 잠기면 어느 쪽에서도 출발할 수 없습니다.
모든 계정을 하루에 바꾸지 않는 편이 낫다
패스키 전환은 ‘등록’보다 ‘검증’에 시간이 듭니다. 영향이 작은 서비스에서 흐름을 익힌 뒤, 다른 계정의 비밀번호를 재설정할 수 있는 뿌리 계정으로 넘어가는 편이 안전합니다.
한 번에 한 계정씩 다음 순서로 진행해 보세요.
| 시점 | 실제로 할 일 | 통과 조건 |
|---|---|---|
| 등록 전 | 현재 비밀번호·인증 앱·복구 연락처 기록 | 막혔을 때 돌아갈 기존 경로가 보임 |
| 첫 등록 | 주 기기에 패스키 추가 | 기존 로그인도 그대로 남아 있음 |
| 교차 시험 | 다른 기기와 비공개 창에서 로그인 | 이미 열린 세션 없이 성공 |
| 복구 시험 | 주 휴대폰을 옆에 두고 사용하지 않는다고 가정 | 노트북·보안키·복구 코드 중 하나로 진입 |
| 정리 | 오래된 번호·불필요한 인증 수단 제거 | 독립된 복구 경로 두 개는 유지 |
| 기록 | 패스키가 저장된 위치와 예비 수단 보관 장소 메모 | 본인 또는 조직이 나중에 찾을 수 있음 |
주 이메일, 운영체제·클라우드 계정, 비밀번호 관리자는 다른 계정의 복구에 쓰이므로 특히 신중해야 합니다. 첫 패스키를 추가한 날 바로 비밀번호와 모든 대체 수단을 삭제하지 마세요.
QR 로그인은 패스키를 공용 PC에 저장하는 기능이 아니다
호텔이나 회의실 PC에서 QR 코드를 띄운 뒤 휴대폰으로 승인하는 방식은, 휴대폰의 패스키를 이용해 다른 기기의 세션을 열어 주는 흐름입니다. 공용 PC에 패스키 자체를 새로 저장할 필요는 없습니다.
사용자가 시작하지 않은 QR 요청은 승인하지 않고, 휴대폰 화면에 표시된 사이트 이름과 PC 주소가 같은지 확인합니다. 작업이 끝나면 서비스 로그아웃과 브라우저 데이터 삭제를 확인해야 합니다. 패스키가 피싱에 강해도, 로그인 후 열린 세션을 공용 PC에 남겨 두면 다른 문제가 됩니다.
가족이나 팀은 하나의 패스키를 돌려 쓰지 않는다
패스키는 기기 소유자 확인과 결합되기 때문에 공동 비밀번호처럼 공유하기에 적합하지 않습니다. 가족 초대, 팀 멤버, 역할 기반 권한이 있다면 각 사람이 자신의 계정과 패스키로 들어가는 편이 낫습니다.
이렇게 해야 누가 어떤 작업을 했는지 남고, 퇴사나 역할 변경 때 한 사람의 접근만 제거할 수 있습니다. 바이브 코딩으로 로그인 기능을 구현하고 있다면 바이브 코딩 배포 기준의 권한·복구 항목도 함께 확인할 만합니다. AI 에이전트가 계정 설정을 대신 바꾸는 서비스라면 프롬프트 인젝션 방어 설계의 실행 승인 원칙도 필요합니다.
오늘 할 수 있는 가장 작은 복구 시험
주 휴대폰의 전원을 끄거나 서랍에 넣고, 비공개 창을 연 노트북에서 가장 중요한 계정 하나에 로그인해 보세요. 다른 기기의 패스키가 나타나는지, QR 로그인이 가능한지, 예비 보안키가 작동하는지, 복구 연락처가 최신인지 확인합니다.
성공했다면 사용한 경로를 한 줄로 기록합니다. 실패했다면 비밀번호를 없애기 전에 막힌 지점을 고칩니다. 패스키의 편리함은 평소 몇 초 빠르게 로그인하는 데서 느껴지지만, 패스키의 완성도는 휴대폰이 없는 아침에도 계정으로 돌아갈 수 있을 때 드러납니다.
