패스키 로그인 원리 — 비밀번호 없이 인증하는 방식 정리

비밀번호는 30년 넘게 인터넷 인증의 기본이었지만, 동시에 가장 약한 고리이기도 했다. 유출·재사용·피싱·무차별 대입 공격이 모두 비밀번호라는 ‘공유된 비밀(shared secret)’에서 비롯된다. 패스키(passkey)는 이 비밀 자체를 없애 버리는 접근이다. 사용자는 더 이상 외울 문자열을 입력하지 않고, 지문이나 얼굴 인식, 기기 잠금 해제만으로 로그인한다. 그렇다면 비밀번호 없이도 서버가 “이 사람이 맞다”고 어떻게 확신할까? 이 글은 패스키 로그인 원리를 공개키 암호화와 FIDO2 표준 관점에서 단계별로 풀어 본다.

비밀번호의 구조적 한계, 패스키가 출발한 지점

패스키를 이해하려면 먼저 비밀번호가 왜 무너졌는지 짚어야 한다. 비밀번호 방식의 본질은 “사용자와 서버가 같은 비밀을 나눠 갖는다”는 데 있다. 사용자는 비밀번호를 기억하고, 서버는 그 해시(hash)를 저장한다. 로그인할 때 둘을 대조한다.

문제는 이 ‘공유’에서 시작된다.

유출: 서버 데이터베이스가 털리면 수억 개의 해시가 한꺼번에 노출된다. 약한 해시는 오프라인에서 복원된다.
재사용: 한 사이트의 비밀번호가 유출되면 같은 비밀번호를 쓰는 다른 서비스까지 연쇄로 뚫린다(크리덴셜 스터핑).
피싱: 가짜 사이트가 비밀번호를 입력받아 그대로 진짜 사이트에 흘려 넣으면, 사용자는 속았다는 사실조차 모른다.

2단계 인증(OTP, SMS 코드)은 이 약점을 덜어 주지만 근본 해결은 아니다. OTP 코드 역시 사용자가 ‘입력’하는 값이라, 정교한 피싱 페이지는 코드까지 실시간으로 가로채 중계한다. 결국 “사람이 입력하는 비밀”이 존재하는 한 피싱은 사라지지 않는다는 결론에 이른다.

패스키는 발상을 뒤집는다. 사용자가 입력하는 비밀을 아예 만들지 않는다. 대신 기기 안에서 수학적으로 증명하는 방식으로 신원을 확인한다. 그 핵심 도구가 공개키 암호화다.

패스키 로그인 원리 — 공개키 암호화가 핵심이다

패스키는 비대칭 암호화(public-key cryptography)에 기반한다. 하나의 비밀번호 대신, 짝을 이루는 두 개의 키를 사용한다.

구분	개인키(Private Key)	공개키(Public Key)
저장 위치	사용자 기기의 보안 영역(Secure Enclave·TPM 등)	서비스(웹사이트) 서버
외부 노출	절대 기기 밖으로 나가지 않음	공개돼도 무방
역할	서명 생성	서명 검증
유출 시 위험	치명적이지만 기기 밖으로 안 나감	거의 없음(검증용일 뿐)

핵심은 개인키가 기기를 떠나지 않는다는 점이다. 서버는 공개키만 보관하는데, 공개키는 그 자체로 아무것도 증명하지 못한다. 서버가 털려도 공격자가 손에 넣는 것은 ‘자물쇠’뿐, ‘열쇠’가 아니다.

등록(Registration) 단계

사용자가 어떤 서비스에 패스키를 처음 만들 때 일어나는 과정은 이렇다.

1. 서버 → 기기: "패스키를 만들어 달라" 요청 (challenge 포함)
2. 기기: 해당 서비스 전용 키 쌍(개인키+공개키) 생성
3. 사용자: 지문·얼굴·PIN으로 본인 확인 (로컬 인증)
4. 기기 → 서버: 공개키만 전송 (개인키는 기기에 봉인)
5. 서버: 사용자 계정에 공개키 저장

여기서 생성된 키 쌍은 그 서비스의 도메인(origin)에 묶인다. 즉, naver.com용으로 만든 패스키는 오직 naver.com에서만 작동한다. 이 도메인 결합이 뒤에서 설명할 피싱 내성의 뿌리다.

인증(Authentication) 단계

다음 로그인부터는 다음 흐름을 탄다.

1. 서버 → 기기: 로그인 요청에 일회성 challenge(랜덤 값) 전달
2. 사용자: 지문·얼굴 등으로 기기 잠금 해제 (개인키 사용 승인)
3. 기기: 개인키로 challenge에 디지털 서명
4. 기기 → 서버: 서명된 값 전송 (개인키 자체는 전송 안 함)
5. 서버: 저장된 공개키로 서명 검증 → 일치하면 로그인 성공

비유하자면, 비밀번호가 “암호를 말하면 통과”라면 패스키는 “매번 다른 수수께끼(challenge)에 정답 도장(서명)을 찍어 보이는” 방식이다. 도장(개인키)은 보여 주지 않고, 도장이 찍힌 결과만 보여 준다. 매번 challenge가 달라지므로 한 번 가로챈 서명을 재사용할 수도 없다(재전송 공격 차단).

FIDO2·WebAuthn·CTAP — 패스키를 떠받치는 표준

패스키는 특정 회사의 독점 기술이 아니라 공개 표준 위에서 동작한다. 그래서 애플·구글·마이크로소프트 기기가 서로 호환된다. 이 표준의 묶음이 FIDO2다.

FIDO2는 FIDO 얼라이언스(FIDO Alliance)와 W3C가 함께 만든 표준으로, 두 개의 사양으로 구성된다.

WebAuthn(Web Authentication): W3C가 표준화한 웹 API. 브라우저와 웹사이트가 공개키 인증을 주고받는 규약이다. 개발자는 이 API를 호출해 패스키 등록·인증을 구현한다.
CTAP(Client to Authenticator Protocol): FIDO 얼라이언스가 정의한 프로토콜. 브라우저(클라이언트)와 인증 장치(authenticator, 예: 휴대폰·보안키) 사이의 통신을 담당한다.

정리하면 FIDO2 = WebAuthn + CTAP이며, 패스키는 이 FIDO2 표준을 일반 사용자가 쓰기 쉽게 다듬은 인증 수단이다. 과거 FIDO 보안키(USB 형태)가 ‘기기에 묶인(device-bound)’ 형태였다면, 오늘날의 패스키는 클라우드를 통해 여러 기기에 동기화되는 점이 다르다.

이 표준 기반 구조 덕분에 패스키는 한 회사의 생태계에 갇히지 않는다. 웹 개발자 입장에서도 WebAuthn은 브라우저 내장 API라 별도 설치 없이 접근할 수 있다. (웹 표준의 최근 흐름이 궁금하다면 Next.js 15 신기능 정리에서 프런트엔드 쪽 변화도 함께 살펴볼 만하다.)

패스키가 피싱에 강한 이유

패스키의 가장 큰 보안 가치는 피싱 내성(phishing resistance)이다. 이는 마케팅 수사가 아니라 구조에서 나온다. 두 가지 메커니즘이 작동한다.

첫째, 도메인 결합(origin binding)이다. 앞서 등록 단계에서 키 쌍이 특정 도메인에 묶인다고 했다. 사용자가 naver-login.com 같은 가짜 사이트에 접속하면, 브라우저는 도메인이 일치하지 않으므로 진짜 naver.com 패스키를 아예 꺼내 주지 않는다. 사용자가 속고 싶어도 기술적으로 서명이 일어나지 않는다. 비밀번호처럼 “실수로 입력해 버리는” 사고가 원천 차단된다.

둘째, 비밀이 전송되지 않는다. 로그인 과정에서 네트워크를 오가는 것은 개인키가 아니라 ‘서명된 challenge’뿐이다. 중간에 누가 가로채도 재사용할 수 없고, 서버가 저장하는 것도 공개키라 유출돼도 악용이 어렵다.

여기에 로컬 사용자 확인이 더해진다. 개인키를 쓰려면 반드시 기기에서 생체 인증이나 PIN으로 본인을 확인해야 한다. 분실한 휴대폰을 주운 사람이 함부로 로그인할 수 없는 이유다.

실제 성과는 어떨까. FIDO 얼라이언스가 2025년 10월 발표한 Passkey Index(아마존·구글·마이크로소프트·페이팔 등 9개 기업이 1~3년간 패스키를 운영한 데이터)에 따르면, 패스키 로그인 성공률은 93%로 다른 인증 방식의 63%보다 30%포인트 높았다. 로그인에 걸린 시간도 패스키는 평균 8.5초로, 전통적 다중 인증(MFA)의 31.2초 대비 73% 단축됐다. 로그인 관련 헬프데스크 문의는 최대 81%까지 줄었다고 보고됐다.

패스키 동기화와 기기 간 사용

초기 FIDO 보안키의 큰 약점은 “기기를 잃어버리면 끝”이라는 점이었다. 개인키가 그 장치에만 있으니, 분실하면 계정 복구가 까다로웠다. 오늘날의 패스키는 이 문제를 두 가지 방식으로 푼다.

동기화 패스키(synced passkey): 애플 iCloud 키체인, 구글 비밀번호 관리자 같은 플랫폼 클라우드를 통해 같은 계정의 여러 기기에 패스키가 자동 동기화된다. 새 아이폰을 사도 iCloud에 로그인하면 기존 패스키가 따라온다. 편의성은 높지만, 클라우드 계정 보안이 곧 패스키 보안의 일부가 된다는 트레이드오프가 있다.

기기 간 인증(cross-device authentication): 노트북에서 로그인하려는데 패스키가 휴대폰에만 있다면, 화면의 QR 코드를 휴대폰으로 스캔해 인증할 수 있다. 이때 블루투스로 두 기기의 물리적 근접을 확인하므로, 원격지의 공격자가 QR만으로 가로챌 수 없다.

여기서 독자가 던질 만한 질문이 하나 있다. “안드로이드에서 만든 패스키를 아이폰으로 옮길 수 있나?” 오랫동안 플랫폼 간 이전은 불가능에 가까웠지만, FIDO 얼라이언스가 자격 증명 교환 프로토콜(CXP)을 표준화하면서 비밀번호 관리자·플랫폼 사이의 이전 길이 열리고 있다. 다만 2026년 현재까지도 모든 조합에서 매끄럽지는 않아, 중요한 계정은 여러 기기에 패스키를 등록해 두는 편이 안전하다.

국내 도입 현황 — 카카오·네이버·삼성패스

해외만의 이야기가 아니다. 국내 주요 서비스도 패스키 도입에 속도를 내고 있다.

카카오는 2024년 11월 25일 카카오계정에 패스키 로그인을 도입했다. 특히 국내 대부분 서비스가 앱 환경에 한정해 패스키를 적용한 것과 달리, 카카오는 웹 기반으로 구현해 카카오 로그인을 쓰는 외부 서비스까지 범용성을 넓혔다.
네이버와 나무위키, 닌텐도 계정 등은 아이디 입력 없이 패스키만으로 로그인하는 경험을 제공한다.
삼성패스(Samsung Pass)는 패스키를 저장·관리하는 인증기(authenticator) 역할을 맡아, 여러 웹사이트와 앱에 아이디·비밀번호 없이 로그인하도록 돕는다.

다만 한국에서 가장 큰 장벽은 따로 있다. 금융·공공 분야에 깊게 뿌리내린 공동인증서·간편인증·본인확인 체계와 패스키를 어떻게 접목할지가 과제다. 글로벌 표준인 패스키와 국내 고유의 인증 인프라가 만나는 지점에서 정책·기술 정합성을 맞추는 작업이 2026~2027년의 관전 포인트가 될 전망이다.

패스키의 한계와 도입 시 고려사항

패스키가 만능은 아니다. 균형 잡힌 판단을 위해 한계도 분명히 짚어야 한다.

계정 복구의 역설: 비밀번호가 없으니 “비밀번호 찾기”도 없다. 모든 패스키와 동기화 계정을 잃으면 복구 절차가 오히려 복잡해질 수 있다. 백업 인증 수단을 함께 설계해야 한다.
클라우드 의존: 동기화 패스키는 편리한 만큼 플랫폼 클라우드 계정 보안에 묶인다. iCloud·구글 계정이 뚫리면 연쇄 위험이 생긴다.
공유 계정과의 불일치: 한 계정을 여러 사람이 쓰는 환경(가족 OTT, 업무용 공용 계정)에서는 개인 생체 인증 중심의 패스키 모델이 어색할 수 있다.
과도기적 혼란: 비밀번호와 패스키가 한동안 공존하면서 사용자에게 “이번엔 뭘로 로그인하지?” 하는 인지 부하가 생긴다.

도입을 검토하는 서비스라면 패스키를 비밀번호의 즉시 대체재로 보기보다, 비밀번호와 병행하며 점진적으로 비중을 높이는 전환 전략이 현실적이다. 사용자 관점에서는 보안에 민감한 계정(이메일·금융·클라우드)부터 패스키를 먼저 등록해 두는 것을 권할 만하다.

정리: 패스키는 ‘입력하는 비밀’을 없앤다

패스키 로그인 원리를 한 문장으로 압축하면, “사용자가 입력하는 비밀을 없애고, 기기 안 개인키의 디지털 서명으로 신원을 증명한다”가 된다. 공개키 암호화 덕에 서버는 공개키만 보관하고, 도메인 결합 덕에 피싱이 구조적으로 막히며, FIDO2(WebAuthn+CTAP)라는 공개 표준 덕에 플랫폼을 넘나든다.

비밀번호가 완전히 사라지기까지는 시간이 더 걸리겠지만, 9개 글로벌 기업 데이터에서 확인된 성공률·속도·비용 개선은 방향이 분명함을 보여 준다. 보안과 편의를 동시에 끌어올리는 인증 방식으로서, 패스키는 더 이상 실험이 아니라 주류로 진입하고 있다. 당신의 가장 중요한 계정은, 아직도 외워야 하는 비밀번호에 의존하고 있는가?

패스키 로그인 원리: 비밀번호 없이 어떻게 인증하나