# 패스키 로그인 원리와 구글·애플 계정 설정법

- 게시: 2026.07.17
- 원문(HTML): https://trendbrief.news/articles/%ED%8C%A8%EC%8A%A4%ED%82%A4-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9B%90%EB%A6%AC%EC%99%80-%EA%B5%AC%EA%B8%80-%EC%95%A0%ED%94%8C-%EA%B3%84%EC%A0%95-%EC%84%A4%EC%A0%95%EB%B2%95.html
- 발행: [트렌드브리프](https://trendbrief.news/)

![패스키 로그인 원리와 구글·애플 계정 설정법](https://trendbrief.news/assets/articles/%ED%8C%A8%EC%8A%A4%ED%82%A4-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9B%90%EB%A6%AC%EC%99%80-%EA%B5%AC%EA%B8%80-%EC%95%A0%ED%94%8C-%EA%B3%84%EC%A0%95-%EC%84%A4%EC%A0%95%EB%B2%95/hero-auto.png)

> 패스키는 비밀번호 대신 기기의 지문·얼굴로 로그인하는 FIDO2·WebAuthn 표준 자격 증명이다. 공개키 암호로 동작하는 원리부터 구글 계정에서 패스키를 만들고 삭제하는 방법, 아이폰·네이버의 지원 방식까지 개발자 시선으로 짚었다.

패스키(passkey)는 비밀번호를 입력하는 대신 기기의 지문·얼굴 인식이나 화면 잠금 PIN으로 로그인하는 방식이다. 외워서 서버에 저장해 두는 문자열이 아니라, 공개키 암호를 쓰는 로그인 자격 증명이라는 점이 본질이다. FIDO 얼라이언스와 W3C가 만든 표준(FIDO2·WebAuthn) 위에서 동작하며, 2026년 7월 기준 구글·애플·네이버를 비롯한 주요 서비스가 이미 지원한다.

이 글은 개발자 눈높이에서 패스키가 비밀번호와 무엇이 다른지, 브라우저 안에서 실제로 어떻게 동작하는지, 구글·애플·네이버 계정에서 직접 만들고 지우는 방법을 함께 다룬다. 특정 앱 하나의 사용법이 아니라, 표준과 플랫폼별 제공자의 관계를 기준으로 본다.

## 패스키는 비밀번호와 무엇이 다른가

가장 큰 차이는 서버에 비밀이 저장되지 않는다는 점이다. 비밀번호 방식은 사용자가 정한 문자열을 서버가 해시 형태로 보관하고 로그인 때 대조한다. 반면 패스키는 기기 안에서 공개키 암호(서로 짝을 이루는 개인키와 공개키 두 개를 쓰는 비대칭 암호)의 키 한 쌍을 만든다. 개인키는 기기의 보안 영역을 벗어나지 않고, 서버에는 공개키만 등록된다.

로그인 순간에는 서버가 무작위 값인 챌린지를 보내고, 기기가 개인키로 그 값에 서명해 돌려준다. 서버는 저장해 둔 공개키로 서명을 검증한다. 이 구조라면 서버가 털려도 공개키만 새어 나가므로 그 자체로는 계정을 열 수 없다. 비밀번호 유출이나 재사용으로 생기던 사고가 원천적으로 사라진다.

피싱에 강한 이유도 여기서 나온다. 패스키는 등록된 도메인(출처, origin)에 묶인다. 브라우저는 자격 증명이 만들어진 도메인과 지금 접속한 도메인이 다르면 그 패스키를 꺼내 주지 않는다. 가짜 사이트가 진짜와 똑같이 생겨도 도메인이 다르면 서명 자체가 일어나지 않는다. 사용자가 속더라도 브라우저가 막아 준다. W3C는 2019년 WebAuthn을 웹 표준으로 확정했고, FIDO 얼라이언스는 2022년 이 자격 증명에 '패스키'라는 이름을 정의했다.

![왼쪽은 열쇠가 서버까지 이동해 복제본이 서버 안에 남는 비밀번호 방식, 오른쪽은 열쇠가 기기 속 보호막 안에 머물고 물결 모양 서명만 서버로 건너가는 패스키 방식을 나란히 그린 선화](https://trendbrief.news/assets/articles/%ED%8C%A8%EC%8A%A4%ED%82%A4-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9B%90%EB%A6%AC%EC%99%80-%EA%B5%AC%EA%B8%80-%EC%95%A0%ED%94%8C-%EA%B3%84%EC%A0%95-%EC%84%A4%EC%A0%95%EB%B2%95/sec-passkey-1.png)

비밀번호는 비밀 자체가 서버에 저장되지만, 패스키는 개인키가 기기를 떠나지 않고 서명만 오간다.

## WebAuthn으로 본 패스키 동작 원리

표준 이름부터 정리하면, WebAuthn은 브라우저가 제공하는 자바스크립트 API이고 FIDO2는 이 WebAuthn과 인증기 통신 규약인 CTAP2를 묶은 상위 표준이다. 서비스 개발자가 실제로 다루는 접점은 함수 두 개다. 등록은 navigator.credentials.create(), 로그인은 navigator.credentials.get()으로 이뤄진다.

등록 흐름은 이렇다. 사용자가 패스키 만들기를 누르면 서버가 무작위 챌린지를 생성해 내려보내고, 브라우저가 그 값을 담아 create()를 호출한다. 이때 relying party(자격 증명을 요구하는 서비스 서버) 정보와 사용자 식별자, 허용할 서명 알고리즘을 함께 넘긴다.

```
const cred = await navigator.credentials.create({
 publicKey: {
 challenge: serverChallenge,    // 서버가 발급한 무작위 값
 rp: { name: "Trend Brief", id: "trendbrief.news" },
 user: { id: userId, name: "dev@example.com", displayName: "김데브" },
 pubKeyCredParams: [{ type: "public-key", alg: -7 }], // -7 = ES256
 authenticatorSelection: {
  residentKey: "required",
  userVerification: "required"
 }
 }
});
```

여기서 rp.id는 relying party ID, 곧 이 패스키가 어느 도메인에 묶일지를 정하는 값이다. 이 도메인이 앞서 말한 피싱 방어의 기준선이 된다. 호출이 성공하면 공개키가 담긴 자격 증명이 돌아오고, 서버는 그 공개키와 자격 증명 ID를 사용자 계정에 저장한다. 로그인 때는 get()으로 다시 챌린지에 서명을 받아 검증한다. 챌린지를 발급하고 공개키를 저장하는 이 서버 엔드포인트는 결국 [REST API 한 벌](https://trendbrief.news/articles/rest-api-%EB%9C%BB%EA%B3%BC-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99-%ED%82%A4%EC%9B%80%EC%A6%9D%EA%B6%8C-api-%EC%82%AC%EB%A1%80.html)이라, 인증 검증만 표준을 따르면 나머지는 익숙한 백엔드 작업이다.

서명과 챌린지 검증을 직접 짜기보다 검증된 서버 라이브러리를 쓰는 편이 안전하다. 자바스크립트는 SimpleWebAuthn, 파이썬은 py_webauthn, Go는 go-webauthn 같은 라이브러리가 이 과정을 대신 처리해 준다. API의 상세 규격은 MDN의 [Web Authentication API 문서](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)에 정리돼 있다.

## 구글 패스키는 어떻게 만들고 지우나

구글 계정 설정의 패스키 관리 화면에서 만들고 지운다. 구글 계정 고객센터 안내에 따르면 myaccount.google.com/signinoptions/passkeys 주소에서 '패스키 만들기'를 눌러 생성하고, 등록된 패스키 옆의 X 버튼으로 삭제한다.

주의할 지점이 하나 있다. 구글에 로그인해 둔 안드로이드 기기가 있으면 패스키가 자동으로 등록되기도 한다. 이렇게 기기 단위로 자동 추가된 항목은 목록에서 바로 지우는 대신, 구글 계정에서 그 스마트폰이나 태블릿 자체를 제거해 정리한다. 또 시크릿 모드(비공개 브라우징)에서는 패스키 생성이 막히니, 만들 때는 일반 창을 쓴다.

구글 계정 로그인에서 패스키가 어떤 자리에 놓이는지는 [구글 패스키 안내 페이지](https://www.google.com/intl/ko/account/about/passkeys/)에서 확인할 수 있다.

## 아이폰·삼성·네이버의 패스키 지원 방식

패스키 표준은 하나지만, 그 키를 저장하고 기기 사이에 동기화하는 제공자는 플랫폼마다 다르다. 아이폰은 iCloud 키체인, 안드로이드는 구글 비밀번호 관리자가 기본 제공자이고, 각 서비스는 그 위에 로그인 옵션을 얹는다.

애플 지원 문서에 따르면 iCloud 키체인 패스키를 쓰려면 iOS 16, iPadOS 16, macOS 13, tvOS 16 이상이 필요하고, 계정에서 iCloud 키체인과 2단계 인증을 켜 둬야 한다. 같은 애플 계정을 쓰는 기기끼리 패스키가 동기화되며, 애플은 iCloud 키체인을 256비트 AES로 암호화한다고 설명한다.

삼성 갤럭시에서는 삼성 패스를 패스키 제공자로 지정할 수 있고, 지정하지 않으면 안드로이드 기본값인 구글 비밀번호 관리자가 쓰인다. 국내에서는 네이버가 2025년 1월 PC와 모바일 웹에 패스키 로그인을 우선 도입한다고 밝혔다. 바이낸스 같은 암호화폐 거래소도 패스키 로그인을 제공하는 등 금융 서비스로도 적용이 넓어지고 있다.

기본 제공자를 한눈에 비교하면 다음과 같다.

| 플랫폼 | 기본 제공자 | 동기화 범위 |
| --- | --- | --- |
| 아이폰·맥 | iCloud 키체인 | 같은 애플 계정 기기 |
| 안드로이드 | 구글 비밀번호 관리자 | 같은 구글 계정 기기 |
| 삼성 갤럭시 | 삼성 패스 또는 구글 | 지정한 제공자 기준 |

## 동기화 패스키와 기기 바인딩 패스키의 차이

같은 패스키라도 두 종류로 갈린다. FIDO 얼라이언스는 2023년 패스키를 동기화 패스키와 기기 바인딩 패스키로 구분했다. 동기화 패스키는 같은 제공자를 쓰는 기기들에 복제돼 새 기기에서도 그대로 로그인되고, 기기 바인딩 패스키는 하드웨어 보안 모듈이나 물리 보안 키 안에 갇혀 밖으로 내보낼 수 없다.

서비스를 설계한다면 이 차이가 곧 정책 결정이 된다. 소비자용 로그인은 편의를 위해 동기화 패스키를 허용하고, 기기 밖으로 나가면 안 되는 고보안 환경은 기기 바인딩만 받는 식이다. 한 가지 더, 패스키만 단독으로 강제하면 기기를 잃었을 때 계정이 잠기므로 복구 수단(이메일 재인증, 백업 코드 등)을 반드시 함께 설계해 둔다.

표준 원문 정의와 최신 지원 현황은 [FIDO 얼라이언스 패스키 페이지](https://fidoalliance.org/passkeys/)에서 확인할 수 있다.

## 관련 글

- [대규모 웹 검색 엔진의 해부학, 구글 원형을 설계한 1998년 논문](https://trendbrief.news/articles/%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%9B%B9-%EA%B2%80%EC%83%89-%EC%97%94%EC%A7%84%EC%9D%98-%ED%95%B4%EB%B6%80%ED%95%99-%EA%B5%AC%EA%B8%80-%EC%9B%90%ED%98%95%EC%9D%84-%EC%84%A4%EA%B3%84%ED%95%9C-1998%EB%85%84-%EB%85%BC%EB%AC%B8.md)
- [추상 구문 트리(AST), 코드를 트리로 다루는 원리와 실무 도구](https://trendbrief.news/articles/%EC%B6%94%EC%83%81-%EA%B5%AC%EB%AC%B8-%ED%8A%B8%EB%A6%AC-ast-%EC%BD%94%EB%93%9C%EB%A5%BC-%ED%8A%B8%EB%A6%AC%EB%A1%9C-%EB%8B%A4%EB%A3%A8%EB%8A%94-%EC%9B%90%EB%A6%AC%EC%99%80-%EC%8B%A4%EB%AC%B4-%EB%8F%84%EA%B5%AC.md)
- [Metal이란? 애플 GPU를 직접 다루는 저수준 API](https://trendbrief.news/articles/metal-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC%EB%A1%9C-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-gpu-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D.md)
- [OfficeCLI 사용법: 설치부터 AI 에이전트 연동까지](https://trendbrief.news/articles/officecli-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%84%A4%EC%B9%98%EB%B6%80%ED%84%B0-ai-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%EC%97%B0%EB%8F%99%EA%B9%8C%EC%A7%80.md)
- [AI 도입 단계, 개발팀이 실험에서 멈추는 지점](https://trendbrief.news/articles/ai-%EB%8F%84%EC%9E%85-%EB%8B%A8%EA%B3%84-%EA%B0%9C%EB%B0%9C%ED%8C%80%EC%9D%B4-%EC%8B%A4%ED%97%98%EC%97%90%EC%84%9C-%EB%A9%88%EC%B6%94%EB%8A%94-%EC%A7%80%EC%A0%90.md)