패스키(Passkey), 쉽게 풀어보기

DEV Community

Passkeys Explained Simply

You’ve probably seen that little prompt that says “Sign in with Face ID” or “Use a passkey” instead...

Thomas Bnt · 2026-07-27

개요 #

로그인 화면에서 비밀번호 입력란 대신 "Face ID로 로그인" 또는 "패스키 사용"이라는 문구를 본 적이 있을 것이다. 그게 바로 패스키(Passkey)다. 개발자 Thomas Bnt는 Dev.to에 올린 글에서 패스키가 단순히 "지문 뒤에 숨긴 비밀번호"가 아니라, 비밀번호라는 개념 자체를 대체하는 새로운 인증 방식이라고 설명했다.

핵심은 하나다. 네트워크로 비밀이 오가지 않는다는 것. 서버에는 훔쳐갈 것이 없고, 피싱 사이트는 애초에 작동하지 않는다.

비밀번호는 어디서 무너지는가 #

비밀번호는 사용자가 기억해야 하고, 웹사이트가 (해시 형태로라도) 저장해야 하는 비밀이다. 이 구조에는 약점이 두 군데 있다.

• 새 비밀번호를 만들기 귀찮아서 어디서나 같은 비밀번호를 재사용하는 사용자
• 해킹당하면 비밀번호 데이터베이스가 통째로 유출될 수 있는 웹사이트

여기에 피싱까지 더해진다. 진짜와 똑같이 생긴 가짜 사이트는 사용자가 눈치채지 못하는 사이에 비밀번호를 빼돌린다. 사소한 문제가 아니다. Verizon이 매년 발간하는 DBIR 보고서는 소셜 엔지니어링, 피싱, 탈취된 자격 증명이 소프트웨어 취약점과 함께 전 세계 해킹의 주요 원인으로 꼽힌다고 짚는다.

비밀번호 관리자와 2단계 인증(2FA)을 써도 근본적인 취약점은 남는다. 실수로 남에게 넘어갈 수 있는 "비밀"이 존재한다는 사실 자체다.

패스키는 어떻게 동작하나 #

패스키의 기반은 **비대칭 암호화(asymmetric cryptography)**다. 서버 접속용 SSH 키 쌍을 만들어 본 적이 있다면 이미 아는 원리다.

웹사이트에 패스키를 만들면 이런 일이 일어난다.

1. 사용자의 기기(폰, 컴퓨터, 보안 토큰)가 개인 키와 공개 키로 이루어진 키 쌍을 생성한다.
2. 개인 키는 기기를 절대 떠나지 않는다. iPhone/Mac의 Secure Enclave, Windows의 TPM, 또는 YubiKey 같은 USB 키의 칩 안에 보관된다.
3. 공개 키만 웹사이트로 전송되어 서버에 저장된다.

로그인할 때는 사이트가 챌린지(무작위 숫자)를 보내고, 기기가 개인 키로 서명하고, 사이트가 공개 키로 서명을 검증한다. 서명이 일치하면 인증 완료다.

네트워크를 오가는 것은 서명뿐, 비밀은 어디에도 전송되지 않는다. W3C WebAuthn 명세에 명시된 설계다. 훔칠 것도, 피싱할 것도 없다.

비밀번호와 뭐가 다른가 #

가장 중요한 지점은 패스키가 생성된 도메인에 결속된다는 점이다. paypal.com이 아니라 paypa1.com에 접속하면 기기는 아예 패스키를 제안하지 않는다. 이 검증을 수행하는 주체는 사용자가 아니라 브라우저와 OS다. Google도 공식 블로그에서 패스키는 생성된 사이트에 암호학적으로 결속되어 가짜 사이트에서 가로채거나 재사용하는 것이 불가능하다고 설명했다. 사용자의 주의력이 아니라 설계 자체가 피싱을 막는다.

내부 구조: WebAuthn과 FIDO2 #

기술적으로 패스키는 W3C의 WebAuthn 표준 위에 서 있다. WebAuthn은 FIDO Alliance(Google, Apple, Microsoft, Yubico 등이 참여)가 주도하는 더 큰 표준인 **FIDO2**의 일부다. 브라우저가 JavaScript로 노출하는 이 API로 자격 증명을 만들고 사용한다.

클라이언트에서 패스키를 생성하는 코드는 이렇다.

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32), // 서버가 제공
    rp: { name: "My Super Site", id: "mysupersite.com" },
    user: {
      id: new Uint8Array(16),
      name: "thomas@example.com",
      displayName: "Thomas",
    },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
    authenticatorSelection: { userVerification: "required" },
  },
});

이미 만든 패스키로 로그인할 때는 이렇게 한다.

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(32), // 서버가 제공
    userVerification: "required",
  },
});

challenge는 서버가 생성하고, 생체 인증과 잠금 해제는 브라우저가 전부 처리한 뒤 검증할 서명을 돌려준다. 서버 쪽에서는 Node.js의 @simplewebauthn/server 같은 라이브러리가 검증 작업 대부분을 대신한다.

폰을 잃어버리면 어떻게 되나 #

누구나 여기서 막힌다. 단일 실패 지점(single point of failure) 문제는 패스키에도 그대로 적용된다. 다행히 2022년부터 Apple, Google, Microsoft가 패스키 동기화를 지원하기 시작했다.

• iOS/macOS에서는 iCloud 키체인으로 동기화된다.
• Android/Chrome에서는 Google 계정의 Google Password Manager가 종단간 암호화로 동기화한다.
• Windows에서는 Windows Hello를 쓰지만, 기기 간 동기화는 Apple이나 Google보다 제한적이다.

폰을 잃어버려도 새 기기에서 iCloud나 Google 계정에 다시 접근하면 패스키도 함께 복원된다. 동기화되지는 않지만 호환되는 어떤 기기에서든 동작하는 YubiKey 같은 물리 보안 키를 백업으로 둘 수도 있다. 기존 2FA와 똑같은 조언이 여기서도 유효하다. 계란을 한 바구니에 담지 말 것.

오늘 바로 써보려면 #

이미 많은 서비스가 패스키를 지원한다. Google, Apple, GitHub, Microsoft, PayPal, Amazon, X 등이다. Google은 한발 더 나아가 개인 계정의 기본 로그인 수단을 패스키로 바꿨다. 보통 계정 보안 설정에서 "액세스 키" 또는 "패스키" 항목을 찾으면 된다.

일반적인 절차는 이렇다.

1. 서비스의 보안 설정으로 이동한다.
2. "액세스 키 추가" 또는 "패스키 만들기"를 클릭한다.
3. 브라우저나 OS가 Face ID, Touch ID, Windows Hello, 또는 폰의 잠금 코드로 확인을 요청한다.
4. 끝. 다음 로그인부터는 비밀번호가 필요 없다.

OS 키체인 대신 다른 곳에서 패스키를 관리하고 싶다면(여러 플랫폼을 오가는 경우 유용하다), 원문 저자는 비밀번호와 같은 곳에 종단간 암호화로 패스키를 만들고 보관할 수 있는 ProtonPass를 예로 들었다.

정리 #

원문 저자는 패스키가 "지문 뒤에 숨긴 비밀번호"가 아니라 모델 자체의 전환이라고 강조한다. 외울 것도, 훔칠 것도 없다. 사용 중인 서비스가 패스키 생성을 제안한다면 만들어 두는 편이 낫다. 지금 쓰는 비밀번호보다 훨씬 안전하고 빠르다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.