비밀번호를 '기억'하는 시대가 저물고 있습니다
로그인할 때 비밀번호 대신 지문이나 얼굴로 인증해 본 경험, 한 번쯤 있으실 겁니다. 이것이 바로 패스키(Passkey)입니다.
구글·애플·마이크로소프트는 물론, 네이버·카카오까지 도입하면서 2026년 패스키는 더 이상 실험이 아니라 사실상 표준이 됐습니다.
패스키가 왜 안전한지(원리), 어떻게 쓰는지(설정), 그리고 서비스를 운영한다면 어떻게 도입할지(기업 전략)까지 한 번에 정리했습니다.
개요
1. 패스키란 무엇인가
패스키 개요 [01]
패스키는 FIDO2와 WebAuthn이라는 국제 표준 위에 세워진 공개키 기반 로그인입니다. FIDO Alliance와 W3C가 공동으로 만들었습니다.
사용자 입장에서는 간단합니다. 비밀번호를 외울 필요 없이, 기기의 지문·얼굴·PIN으로 로그인이 끝납니다.
| 구분 | 내용 |
| 기반 표준 | FIDO2 · WebAuthn (공개키 암호) |
| 인증 수단 | 지문·얼굴·화면잠금(PIN) |
| 지원 서비스 | 구글·애플·MS·네이버·카카오 등 |
대중화의 방아쇠는 '동기화 패스키(synced passkey)'였습니다. 개인키를 애플·구글 클라우드에 안전하게 동기화해, 폰을 바꿔도 패스키가 따라오게 되면서 쓰기 편해졌습니다.
비교
2. 비밀번호와 무엇이 다른가
비밀번호와 패스키 비교 [02]
핵심 차이를 표로 정리하면 패스키의 강점이 분명해집니다.
| 항목 | 비밀번호 | 패스키 |
| 서버 저장물 | 해시(유출 위험) | 공개키(유출 무의미) |
| 피싱 저항 | 없음 | 있음(도메인 바인딩) |
| 재사용 위험 | 높음 | 없음(사이트별 키쌍) |
| 로그인 경험 | 입력 + 2FA | 지문·얼굴 한 번 |
가장 중요한 건 서버에 저장되는 것이 '공개키'라는 점입니다. 비밀번호는 서버가 털리면 해시가 유출돼 위험하지만, 패스키의 공개키는 유출돼도 그 자체로는 쓸모가 없습니다. 로그인에 필요한 개인키는 내 기기를 떠나지 않기 때문입니다.
원리
3. 어떻게 안전한가 — 작동 원리
패스키 작동 원리 [03]
패스키는 공개키 암호의 원리로 동작합니다. 조금 전문적이지만, 두 단계로 이해하면 쉽습니다.
| 단계 | 내용 |
| ① 등록 | 기기가 키쌍 생성 → 공개키만 서버에 저장 |
| ② 보관 | 개인키는 생체·PIN으로 잠긴 기기 보안영역에 |
| ③ 로그인 | 서버의 도전값(challenge)에 개인키로 서명 |
| ④ 검증 | 서버가 등록된 공개키로 서명 유효성 확인 |
🛡️ 피싱이 '구조적으로' 막히는 이유
패스키는 생성될 때 특정 도메인과 고유하게 묶입니다.
네이버에서 만든 패스키는 '진짜 네이버 도메인'에서만 작동해,
주소를 흉내 낸 가짜 사이트에서는 인증 절차 자체가 시작되지 않습니다.
비밀번호로는 불가능했던, 피싱에 대한 근본적 방어입니다.
설정
4. 사용자 — 3분이면 등록 끝
서비스별 패스키 설정법 [04]
사용자라면 각 서비스의 보안 메뉴에서 몇 분이면 등록할 수 있습니다.
| 서비스 | 등록 경로 |
| 구글 | 계정 → 보안 → 패스키 만들기 |
| 네이버 | 내정보 → 보안설정 → 패스키 등록 |
| 카카오 | 카카오계정 보안 설정에서 등록 |
| 애플/MS | 계정 보안 메뉴에서 생성 |
🔑 등록 후 반드시 할 일
· 복구 이메일·전화번호를 최신 상태로 점검
· 패스키를 기기 2개 이상(예: 폰 + 보안키)에 등록
기기를 하나만 쓰다 분실하면 로그인이 막힐 수 있어,
복수 등록이 안전합니다.
참고로 지문·얼굴 정보 자체는 서버로 전송되지 않습니다. 생체정보는 기기 안에서 개인키의 잠금을 푸는 열쇠로만 쓰이고, 기기를 벗어나지 않습니다.
도입
5. 기업·개발자 도입 전략
기업 도입 실무 체크포인트 [05]
서비스를 운영하신다면, 패스키 도입은 '한 번에 교체'가 아니라 '점진적 전환'으로 접근하는 것이 현실적입니다.
| 전략 | 내용 |
| 병행 운영 | 비밀번호 유지하며 로그인 후 패스키 등록 유도 |
| 복수 패스키 | 사용자당 2개 이상(폰+보안키) 등록 유도 |
| 디스커버러블 | 아이디 없이 계정 선택 로그인 지원 |
| 검증 로깅 | challenge·origin·signCount 반드시 확인 |
| 복구 설계 | 패스키 분실 대비 복구 흐름 미리 마련 |
라이브러리(SimpleWebAuthn, WebAuthn4J 등)를 쓰더라도 검증 지점(도전값·출처·서명 카운터)을 이해하고 로그로 남기는 것이 핵심입니다. 이 부분을 소홀히 하면 '패스키를 도입했는데도 안전하지 않은' 상황이 생깁니다.
한계
6. 그래도 완벽하진 않다
패스키의 한계와 유의점 [06]
패스키가 강력한 건 분명하지만, '만능'은 아닙니다. 전문가라면 한계도 알아야 합니다.
| 쟁점 | 내용 |
| 계정 복구 | 복구 흐름이 약하면 거기가 새 공격 표면 |
| 호환성 | 플랫폼 종속·서드파티 패스키 호환 이슈 |
| 구현 취약점 | FIDO 서버 구현 결함 사례 존재 |
| 기기 관리 | 분실·공유기기 환경의 관리 과제 |
특히 계정 복구가 맹점입니다. 아무리 패스키가 튼튼해도, '패스키를 잃어버렸을 때' 복구하는 경로가 허술하면 공격자는 그 약한 고리를 노립니다. 실제로 FIDO 서버 구현에서 사용자 확인 절차를 우회할 수 있던 취약점 사례도 보고된 바 있습니다.
🧭 실무자를 위한 결론
패스키는 '피싱과 비밀번호 재사용'을 구조적으로 없애는 분명한 진전입니다.
다만 복구·운영 설계까지 마쳐야 진짜 보안이 완성됩니다.
'패스키 도입 = 끝'이 아니라, '복구 흐름 설계 = 시작'입니다.
정리하며
패스키는 수십 년간 우리를 괴롭혀 온 비밀번호의 근본 문제(유출·재사용·피싱)를 구조적으로 해결하는 기술입니다.
사용자라면 오늘 주요 계정부터 패스키를 등록하고 복구 수단을 점검하시고, 서비스를 운영한다면 병행 운영으로 점진 도입하되 복구 흐름을 탄탄히 설계하시길 권합니다.
비밀번호 없는 세상은 이미 시작됐습니다. 남은 건 얼마나 잘 준비하느냐입니다.
※ 이 글은 2026년 10월 기준 FIDO Alliance·구글·보안업계 자료를 정리한 것입니다. 서비스별 지원 범위와 설정 경로는 변경될 수 있습니다. 기업 도입 시 세부 구현과 보안 검증은 전문가 검토를 거치시길 권하며, 이 글은 일반 기술 정보 제공이 목적입니다.
'IT 이모저모' 카테고리의 다른 글
| 랜섬웨어 대비 백업 전략 — 3-2-1 규칙과 그 진화형 3-2-1-1-0 실무 가이드 (0) | 2026.10.31 |
|---|---|
| 내 개인정보·계정 털렸는지 확인하는 법 — 무료 조회부터 명의도용 차단까지 4단계 (0) | 2026.10.30 |
| 중소기업·소상공인 보안 기본 체크리스트 — 담당자 없이도 지키는 5대 영역 (0) | 2026.10.28 |
| 더존비즈온 해킹 — 토종 1위 ERP 침해사고, 고객사 11만 곳이 알아야 할 것 (0) | 2026.10.27 |
| PHP2Shell 긴급 대응 — PHP 엔진을 뚫는 RCE 취약점(CVE-2026-109618·109619) 총정리 (0) | 2026.10.27 |
