패스키를 이중 잠금장치가 달린 우편함이라고 생각해보자. 누구나 공개된 투입구에 편지를 넣을 수 있지만, 오직 개인 열쇠를 가진 사람만이 그것을 열고 신원을 확인할 수 있다. 이는 최근 한 테크 매체의 설명 기사가 패스키 메커니즘을 풀이할 때 사용한 비유다—공개 키는 웹사이트 쪽에 있고, 개인 키는 당신의 기기 안에 잠겨 있으며, 둘 중 하나라도 없으면 성립하지 않는다.
전통적인 비밀번호의 문제점은 다들 익히 알고 있다. 웹사이트는 비밀번호를 평문으로 저장해서는 안 되므로 해시 연산을 거치고, 무작위 '솔트값'을 더해 같은 비밀번호라도 다른 해시 결과가 나오게 함으로써 데이터베이스 유출 시 복원될 위험을 낮춘다. 하지만 이 체계의 허점은 알고리즘이 아니라 사람에게 있다—대다수가 기억하기 편하다는 이유로 여러 서비스에서 동일한 약한 비밀번호를 재사용하며, 피싱 사이트는 바로 이 점을 노려 사용자가 스스로 비밀번호를 '넘겨주도록' 유도한다.
패스키는 어떻게 이 약점을 메웠나
패스키는 어떤 문자도 기억할 필요가 없다. 로그인할 때 웹사이트는 기기가 공개 키에 대응하는 개인 키로 인증을 완료하도록 요구하는데, 이 개인 키는 스마트폰이나 컴퓨터의 보호된 저장 공간에 보관되어 있으며 Face ID, Windows Hello PIN, 또는 지문 인식으로 활성화된다. 즉, '기기를 소유하고 있다'는 조건과 'PIN이나 생체 정보를 알고 있다'는 조건을 동시에 충족해야 하며, 이는 과거 이중 인증을 거쳐야만 도달할 수 있었던 보안 수준을 한 번에 만족시키는 셈이다.
더 결정적인 것은, 패스키를 생성할 때 특정 도메인에 묶이도록 설계되어 있다는 점이다. 외관이 완전히 똑같은 가짜 사이트를 열더라도 기기는 개인 키를 넘겨주지 않으며, 이는 '피싱 페이지에 비밀번호를 입력한다'는 행위 자체를 근본적으로 무의미하게 만든다. 또한 패스키 규격 자체가 높은 강도를 요구하기 때문에 '간단한 패스키를 설정'하는 것 자체가 불가능하며, 데이터베이스가 유출되더라도 공격자가 얻을 수 있는 것은 애초에 비밀이 아닌 공개 키뿐이다.
저장 위치, 진짜 골칫거리는 여기서 시작된다
패스키의 대가는 기기나 소프트웨어에 종속된다는 점이다. 분실하거나 다른 시스템으로 넘어가면 곧바로 막힌다. iOS와 macOS는 기본적으로 Apple Passwords에 저장되고, Android는 Google Password Manager에 의존하며, Windows 11은 '설정 > 계정 > 패스키' 아래에 보관된다. Linux는 아직 네이티브 지원이 없다. 만약 기기가 서로 다른 생태계에 흩어져 있는데 모든 패스키를 단일 시스템의 앱에만 남겨둔다면, 다른 스마트폰으로 옮겨 로그인할 때 번거로워진다. 일부 서비스가 QR코드를 통한 기기 간 로그인을 지원하긴 하지만 매번 매끄럽게 작동하는 것은 아니다.
공유 역시 또 다른 현실적 제약이다. 예전에는 믿을 만한 사람에게 비밀번호를 알려주는 게 말 한마디로 끝나는 일이었지만, 패스키로 같은 편의성을 얻으려면 공유 비밀번호 저장소를 지원하는 비밀번호 관리 도구가 필요하며, 단순한 기기 내장 방식으로는 불가능하다. 이런 이유로 패스키를 여러 플랫폼 동기화를 지원하는 하나의 비밀번호 관리자에 통합해 저장하는 편이 각 시스템에 흩어진 기본 도구를 쓰는 것보다 더 실용적이다. 한 걸음 더 나아가고 싶다면 YubiKey 같은 실물 보안 키에 패스키를 저장하는 방법도 선택할 수 있다.
현재 대다수 서비스는 여전히 패스키와 비밀번호를 병행하고 있으며, 어떤 경우에는 패스키가 비밀번호를 완전히 대체하지만 다른 경우에는 대체가 아니라 보강일 뿐이다—만약 당신의 계정이 후자에 해당한다면, 그 비밀번호 자체가 충분히 강력해야 한다는 점을 잊지 말아야 한다. 그렇지 않으면 전체 체계가 가장 약한 고리 하나에 의해 무너질 수 있다.
