패스키(passkey)란 무엇인가 — 비밀번호 없는 로그인의 원리와 한계

비밀번호 관리 앱에 저장된 계정, 몇 개인지 세어보신 적 있나요. 100개를 넘기는 사람이 드물지 않습니다. 그런데 그 목록 자체가 조만간 쓸모없어질 물건이라면 어떨까요.

애플과 구글, 마이크로소프트가 몇 년째 같은 방향으로 밀고 있는 게 있습니다. 패스키(passkey). 이름은 들어봤는데 정확히 뭔지 모르겠다는 반응이 가장 흔한데, 사실 여러분 주머니 속 폰에는 이미 들어 있습니다.

비밀번호가 없는데 로그인이 된다고?

왜 이걸 굳이 바꾸려는지부터 짚고 가겠습니다. 비밀번호는 '내가 알고 있는 것'으로 신원을 증명하는 방식입니다. 알고 있다는 건 남에게 말해줄 수도 있다는 뜻이고, 어딘가에 적어둘 수도 있다는 뜻이며, 서버 어딘가에 저장돼 있다는 뜻이기도 합니다. 유출·재사용·피싱이라는 3대 사고가 여기서 전부 파생됩니다.

패스키는 증명 방식 자체를 바꿉니다. 처음 등록할 때 여러분의 기기가 열쇠 한 쌍을 만듭니다. 하나는 개인키, 하나는 공개키.

인감도장에 비유하면 이해가 빠릅니다. 도장 자체는 내가 금고에 보관하고, 관공서에는 '이 사람 도장은 이렇게 생겼다'는 증명서만 등록해 둡니다. 서류를 낼 때 도장을 관공서에 맡기지 않죠. 찍어서 보내면 상대가 등록된 모양과 대조합니다.

패스키도 똑같습니다. 개인키(도장)는 폰·노트북·보안키 밖으로 절대 나가지 않고, 서비스 서버에는 공개키(증명서)만 저장됩니다. 로그인 순간에 서버가 무작위 질문을 던지면 기기가 개인키로 서명한 답을 돌려주고, 서버는 갖고 있던 공개키로 그 서명이 맞는지 확인합니다. 개인키는 오가지 않습니다. "내가 그 열쇠를 갖고 있다"는 사실만 증명하는 겁니다.

여기서 오해가 하나 자주 생깁니다. 얼굴이나 지문은 서버로 전송되지 않습니다. 생체 인식은 기기 안에 잠겨 있는 개인키를 꺼내 쓰기 위한 잠금 해제 수단일 뿐이고, 기기 PIN으로 대체해도 보안 수준은 같습니다. 여러분의 지문이 어느 회사 데이터베이스에 쌓이는 구조가 아닙니다.

서버가 통째로 털려도 로그인은 안 된다

이 구조가 만드는 결과가 꽤 셉니다.

서버에 공개키만 있다는 건, 그 데이터베이스가 통째로 유출돼도 공격자가 얻는 게 없다는 뜻입니다. 공개키로는 로그인할 수 없습니다. 해마다 반복되는 "회원 정보 유출, 비밀번호 즉시 변경하세요" 공지가 구조적으로 성립하지 않는 겁니다.

피싱 쪽은 더 흥미롭습니다. 패스키는 등록된 도메인에서만 동작합니다. 진짜와 글자 하나 다른 가짜 사이트에 들어가면 브라우저가 애초에 패스키를 꺼내주지 않습니다. 사람의 주의력에 기대던 방어를 프로토콜이 대신 하는 셈이죠. 아무리 정교한 가짜 로그인 화면을 만들어도 입력할 게 없으니 훔쳐갈 것도 없습니다.

이미 깔린 판: 50억 개

특정 회사의 독점 기술이 아니라는 점이 중요합니다. 패스키는 FIDO 얼라이언스의 FIDO2와 W3C 웹 표준인 WebAuthn 위에서 돌아가는 개방 표준입니다. 애플이 만든 것도, 구글이 만든 것도 아닙니다.

FIDO 얼라이언스 추산으로 전 세계에서 사용 중인 패스키는 약 50억 개. 조직 1,400곳을 대상으로 한 설문에서는 68%가 직원용 패스키를 이미 도입했거나, 도입 중이거나, 파일럿을 돌리고 있다고 답했습니다.

지원 범위도 넓습니다. iOS 16 이상, 안드로이드 9 이상, 윈도우 10·11의 윈도우 헬로. 애플·구글·마이크로소프트가 각자 생태계 안에서 패스키를 동기화해 주기 때문에, 대부분의 사용자는 별도 하드웨어를 사지 않고도 지금 당장 쓸 수 있습니다. 보안키를 따로 사야 했던 몇 년 전과 가장 크게 달라진 지점입니다.

그런데 왜 비밀번호가 안 사라지고 있을까

여기까지 읽으면 "그럼 왜 아직 비밀번호를 치고 있지?" 싶을 겁니다. 정직하게 말하면, 도입은 진짜지만 고르지 않습니다.

소비자 쪽은 빠르게 넘어가는데 서비스 지원이 들쭉날쭉합니다. 어떤 사이트는 이미 되고, 어떤 사이트는 계획조차 없습니다.

더 근본적인 문제는 폴백입니다. 대부분의 서비스가 패스키를 도입하면서도 비밀번호 로그인을 함께 남겨둡니다. 뒷문을 열어둔 채 앞문에만 지문 인식기를 단 셈이죠. 비밀번호가 살아 있는 한 공격면은 완전히 줄지 않습니다. 기업 도입이 소비자보다 더딘 이유가 여기 있습니다. 절반만 적용하면 보안 이득이 절반이 아니라 그보다 훨씬 적어지니까요.

기기 문제도 남습니다. 폰을 잃어버리면 어떻게 되는지, 안드로이드에서 아이폰으로 갈아탈 때 패스키가 따라오는지, 계정 복구는 어떤 경로로 하는지. 생태계 안에서는 매끄럽지만 생태계를 건너는 순간 이야기가 복잡해집니다.

그래서 제 생각은 이렇습니다. 지금 패스키를 "비밀번호의 완전한 대체"로 기대하면 실망하기 쉽고, "쓸 수 있는 곳부터 켜두는 추가 방어선"으로 보면 이득이 확실합니다. 당장 구글·애플·마이크로소프트 계정은 오늘 켤 수 있고, 이 세 개만 해도 대부분의 계정 복구 경로가 걸려 있는 핵심 열쇠고리입니다. 문자로 오는 인증번호를 기다리는 것보다 빠르고, 그 문자를 가로채는 공격에서도 자유롭습니다. 국내 서비스에서도 도입 사례가 나오고 있지만 아직 고르지 않으니, 기대치는 "중요 계정부터"로 잡는 게 현실적입니다.

개발자 입장에서는 판단할 게 하나 더 있습니다. 자체 로그인을 운영한다면 WebAuthn을 붙일지 말지인데, 신규 서비스라면 처음부터 넣는 편이 낫고 기존 서비스는 병행 도입이 현실적입니다. 다만 진짜 어려운 부분은 인증 그 자체가 아니라 폴백과 계정 복구 설계입니다. 복구 경로를 이메일 링크 하나로 두면 결국 그 이메일 계정이 시스템 전체에서 가장 약한 고리가 됩니다. 패스키를 붙이는 작업은 라이브러리 문제지만, 복구 경로를 설계하는 건 제품 문제에 가깝습니다.

정리하면

비밀번호는 '아는 것'으로, 패스키는 '가진 것을 증명하는 방식'으로 신원을 확인합니다. 서버엔 공개키만 남고 개인키는 기기를 떠나지 않으니 유출·피싱이 구조적으로 막힙니다. 50억 개라는 숫자가 말해주듯 판은 이미 깔렸고, 남은 건 서비스들이 언제 비밀번호라는 뒷문을 닫느냐입니다.

여러분은 어떠신가요. 이미 패스키로 로그인하는 계정이 있으신가요, 아니면 아직 비밀번호 관리 앱이 더 편하신가요. 기기를 잃어버렸을 때가 걱정돼서 미루고 계신 분들 이야기도 궁금합니다.

📎 출처: 원문 보기