2026년 5월 7일 World Passkey Day에 맞춰 FIDO 얼라이언스가 내놓은 수치는 꽤 놀라워요. 전 세계에서 쓰이고 있는 패스키가 50억 개를 넘어섰다고 발표했습니다. 10개국 소비자 1만 1천 명과 기업 의사결정권자 1,400명을 대상으로 한 조사에서 응답자의 90%가 패스키를 인지하고 있었고 75%는 최소 한 개 계정에 패스키를 등록한 상태였어요. 로그인 화면에서 비밀번호 입력칸이 점점 사라지고 지문이나 얼굴 인식, PIN으로 대체되는 걸 이미 체감한 사람도 많을 텐데, 그렇다면 로그인 방식은 왜 이렇게 빠르게 패스키 중심으로 바뀌고 있고 비밀번호는 정말 사라지고 있는 걸까요?
패스키는 정확히 무엇인가
패스키는 아이디·비밀번호 조합 대신 공개키 암호를 이용해 로그인하는 FIDO2/WebAuthn 표준 기반 인증 방식이에요. 계정을 만들 때 기기 안에서 공개키-개인키 쌍이 생성되고, 공개키만 서비스 서버에 등록되며 개인키는 스마트폰이나 PC의 보안 영역을 벗어나지 않아요. 로그인할 때는 서버가 보낸 임의의 값에 개인키로 서명해서 돌려보내는 방식이라, 지문이나 얼굴 인식은 그 개인키를 “지금 이 사람이 쓰겠다”고 잠금 해제하는 로컬 인증 수단일 뿐 서버로 전송되는 값이 아니에요.
이 구조 덕분에 서버가 해킹당해 공개키 데이터베이스가 통째로 유출되더라도 공격자는 로그인에 쓸 수 있는 값을 아무것도 얻지 못해요. 비밀번호 유출 사고와 근본적으로 다른 지점이 바로 여기예요.
왜 하필 지금 이렇게 빠르게 확산되고 있나
지금 패스키 전환이 가속되는 이유는 애플·구글·마이크로소프트 같은 플랫폼 사업자들이 동시에 기본값을 바꿔버렸기 때문이에요. 마이크로소프트는 자사 보안 블로그를 통해 2025년 5월 1일부터 신규 마이크로소프트 계정 생성 시 패스워드리스 로그인 방식을 기본값으로 적용한다고 발표했고, 조이 치크 마이크로소프트 아이덴티티 부문 대표는 신규 가입자는 아예 비밀번호를 등록할 필요조차 없다고 설명했습니다. 같은 발표에서 마이크로소프트는 패스키 로그인 성공률이 약 98%로 비밀번호(32%)보다 세 배 가까이 높다는 수치도 함께 공개했어요.
구글도 흐름은 비슷해요. 구글은 공식 발표를 통해 패스키가 2022년 도입 이후 4억 개 이상의 구글 계정에서 10억 회 넘게 인증에 사용됐다고 밝혔고, 패스키 인증 속도가 비밀번호 대비 50% 빠르다는 자체 측정치도 공개했습니다. 기업 쪽에서는 더 뚜렷한 신호가 있는데, FIDO 얼라이언스의 2026년 워크포스 조사에서 조직의 68%가 이미 직원 로그인에 패스키를 도입했거나 도입을 진행 중이라고 답했어요. 앤드류 시키아 FIDO 얼라이언스 CEO는 “패스키가 주류로 자리잡는 이유는 업계가 수십 년간 풀지 못했던 문제, 즉 보안과 편의성을 동시에 잡는 인증을 실현했기 때문”이라고 설명했습니다. 결국 사용자가 자발적으로 옮겨간 게 아니라, 플랫폼이 기본값 자체를 바꿔버리면서 전환이 강제로 앞당겨진 셈이에요.
한국 서비스는 이 흐름을 어떻게 따라가고 있나
국내 대형 서비스들도 이미 패스키를 정식 로그인 수단으로 채택했어요. 카카오는 2024년 11월 카카오계정에 패스키 로그인을 도입하면서 카카오톡 같은 자사 서비스뿐 아니라 카카오계정으로 로그인하는 외부 서비스에서도 패스키를 쓸 수 있도록 설계했고, 네이버는 2025년 1월 PC와 모바일 웹에서 패스키 로그인을 정식으로 지원하기 시작했습니다. 네이버는 내정보 > 보안설정 > 패스키 관리 메뉴에서 등록할 수 있고, 지금 쓰는 기기에 바로 저장할지 스마트폰을 QR코드로 연결해 저장할지 선택하는 구조예요.
금융권과 쇼핑 앱에서도 패스키 도입 사례가 하나둘 늘고 있는데, 피싱 문자로 유도된 가짜 페이지에 비밀번호를 입력해버리는 사고가 구조적으로 차단된다는 점이 특히 금융 서비스 쪽에서 매력적으로 작용하고 있어요. 다만 국내는 아직 개별 서비스 단위로 도입이 진행 중이라, 미국·일본처럼 정부 차원의 패스워드리스 전환 가이드라인이 나오기까지는 시간이 더 필요해 보여요.
그래도 비밀번호가 완전히 사라지진 않는다
결론부터 말하면 아직은 “아니오”예요. FIDO 얼라이언스의 2026년 워크포스 조사를 보면 기업의 82%가 완전한 패스워드리스 인증을 목표로 삼고 있다고 답했지만, 실제로 이를 달성했다고 응답한 기업은 28%에 그쳤습니다. 여기서 끝이 아니에요. 오래된 내부 시스템이나 레거시 API 연동이 남아있는 회사일수록 비밀번호를 완전히 걷어내기가 쉽지 않고, 소비자 조사에서도 패스키를 등록한 사람(75%) 중 실제로 여러 계정에 걸쳐 정기적으로 쓰는 사람은 49%에 머물렀어요. 등록은 했지만 아직 습관이 완전히 옮겨가지 않은 사람이 꽤 많다는 뜻이에요.
그렇다고 방향성 자체가 흔들리는 건 아니에요. 비밀번호는 당분간 완전히 사라지기보다 “예외적으로만 남는 인증 수단”으로 위치가 바뀌어가는 중이고, 이 흐름은 제로 트러스트 보안 모델이 “아이디·비밀번호를 아는 것”이 아니라 “이 기기와 이 사용자가 맞는지”를 매번 검증하는 방향으로 옮겨가는 흐름과도 정확히 맞닿아 있어요.
결론: 비밀번호는 사라지는 게 아니라 밀려나는 중이다
50억 개라는 숫자와 마이크로소프트·구글의 기본값 전환이 보여주는 건 하나예요. 로그인 화면의 주인공이 “기억해야 하는 문자열”에서 “내가 가진 기기와 몸”으로 바뀌고 있다는 것이죠. 아직 모든 사이트가 패스키를 지원하지 않고 기업의 완전 전환율도 28%에 머물러 있지만, 플랫폼 사업자들이 이미 기본값을 바꿔버린 이상 이 방향은 되돌아가지 않을 가능성이 커요. 처음 질문으로 돌아가보면, 로그인 방식이 패스키 중심으로 바뀌는 이유는 결국 보안과 편의성을 동시에 만족시키는 유일한 대안이 지금 눈앞에 나타났기 때문이고, 비밀번호는 사라진다기보다 서서히 구석으로 밀려나는 중이라고 보는 게 정확해요.
자주 묻는 질문
Q1. 패스키(Passkey)와 비밀번호의 근본적인 차이는 무엇인가요?
패스키는 서버에 저장할 비밀 값 자체가 없는 공개키 암호 방식이에요. 비밀번호는 서버가 그 값을 저장하고 있다가 입력값과 대조하는 구조라 유출되면 그대로 도용되지만, 패스키는 개인키가 기기 밖으로 나가지 않기 때문에 서버가 털려도 로그인 정보 자체가 새어나가지 않아요.
Q2. 패스키를 저장한 기기를 잃어버리면 계정에 못 들어가나요?
아니요, 대부분의 서비스는 다른 인증 수단이나 다른 기기의 패스키로 복구할 수 있게 해뒀어요. 아이클라우드 키체인이나 구글 비밀번호 관리자, 윈도우 Hello처럼 클라우드 동기화를 지원하는 경우 새 기기에 로그인만 하면 기존 패스키가 그대로 복원돼요.
Q3. 패스키는 모든 웹사이트에서 다 쓸 수 있나요?
아직은 아니에요. FIDO2·WebAuthn 표준을 지원하는 서비스에서만 가능한데, 2026년 기준 구글·마이크로소프트·애플·네이버·카카오 등 대형 서비스는 대부분 지원하지만 중소규모 사이트는 여전히 비밀번호에 의존하는 경우가 많아요.
Q4. 회사에서 직원 로그인에 패스키를 도입하면 비밀번호를 완전히 없앨 수 있나요?
당장은 어려워요. FIDO 얼라이언스의 2026년 워크포스 조사에 따르면 기업의 82%가 완전 패스워드리스를 목표로 삼고 있지만 실제로 이를 달성했다고 답한 기업은 28%에 그쳤습니다. 레거시 시스템 연동이 남아있는 한 과도기적으로 비밀번호와 패스키가 함께 쓰이는 구간이 당분간 이어질 거예요.
Q5. 패스키를 쓰면 피싱 공격도 완전히 막을 수 있나요?
네, 패스키는 등록된 도메인에서만 동작하도록 설계돼 있어서 가짜 로그인 페이지에 속아 넘어가는 구조적 피싱이 원천적으로 차단돼요. 사용자가 URL을 착각해도 브라우저가 도메인을 대조해 인증을 거부하기 때문에, 비밀번호처럼 입력값 자체를 탈취당할 여지가 없어요.
Q6. 지문이나 얼굴 인식 정보가 서버로 전송되나요?
전송되지 않아요. 생체 인증은 기기 내부에서 개인키 사용 권한을 확인하는 용도로만 쓰이고, 실제로 서버와 주고받는 값은 생체정보와 무관한 암호화 서명뿐이에요.
Kali Linux는 해킹 전용? 오해와 실제 용도
영화에 자주 등장해 '해커의 OS'로 알려진 Kali Linux의 실제 목적과 정당한 사용 범위, 흔한 오해를 짚어봅니다.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.