패스키(Passkey)란 무엇인가요? 패스워드리스·FIDO2·피싱 저항 인증으로 본 2026 기업 도입 완전 가이드

비밀번호 없이 로그인하는 패스키, 정말 안전한가요?

패스키(Passkey)로 넘어가는 흐름의 핵심은 훔칠 수 있는 비밀 자체가 사라진다는 데 있습니다. 파이도 얼라이언스(FIDO Alliance)가 2026년 세계 패스키의 날에 공개한 조사에서 전 세계에 사용 중인 패스키는 약 50억 개에 이르렀고, 기업의 68%가 임직원 로그인에 패스키를 도입했거나 도입을 진행 중이라고 답했습니다. 로그인 성공률은 약 93%로, 기존 비밀번호 방식의 63%를 크게 앞섰습니다. 비밀번호처럼 서버로 전송되어 새어 나갈 수 있는 값이 없기 때문에 피싱과 크리덴셜 스터핑 같은 공격이 구조적으로 막힙니다. 이 글은 패스키의 작동 원리부터 동기화형·기기고정형의 차이, 계정 복구와 IdP 이관 같은 실무 과제, 기업 도입 4단계까지를 한 번에 정리합니다.

패스키는 무엇이고 비밀번호와 무엇이 다른가요
패스키는 어떻게 동작하나요
동기화형과 기기고정형, 무엇을 골라야 하나요
왜 2026년 기업이 패스키로 몰려가나요
도입 전 반드시 짚어야 할 과제
기업 패스키 도입 4단계 로드맵
자주 묻는 질문
같이 읽으면 좋은 것들

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

몇 해 전, 어느 중견 이커머스 회사의 보안 담당자와 이야기를 나눈 적이 있는데요. 그 회사는 분기마다 비밀번호를 바꾸게 하고, 특수문자와 숫자를 섞도록 강제하고, 다단계 인증까지 붙여 두었는데도 계정 탈취 사고가 끊이지 않았다고 했습니다. 원인을 추적해 보면 대부분 같은 자리로 돌아왔습니다. 직원이 진짜처럼 생긴 가짜 로그인 페이지에 비밀번호와 문자 인증번호를 그대로 입력한 경우였습니다. 사람이 속는 한, 아무리 복잡한 비밀번호도 결국 넘어간다는 사실을 그때 실감했습니다.

패스키는 이 문제를 정면으로 다시 봅니다. 비밀번호는 사용자와 서버가 같은 비밀 문자열을 공유하는 방식입니다. 서버에 저장된 값이 유출되거나, 사용자가 엉뚱한 곳에 값을 입력하면 그대로 뚫립니다. 반면 패스키는 공개키 암호 기술을 씁니다. 로그인할 때마다 문자열을 주고받는 대신, 기기 안에 안전하게 보관된 개인키(private key)로 서버가 보낸 값을 서명하고, 서버는 미리 등록해 둔 공개키(public key)로 그 서명을 검증합니다. 개인키는 절대 기기를 떠나지 않고, 서버에는 공개해도 무방한 공개키만 남습니다.

그래서 패스키는 이론이 아니라 사용자 경험으로 먼저 다가옵니다. 화면에는 그저 지문을 대거나 얼굴을 인식하거나 기기 잠금을 푸는 동작만 보입니다. 외울 문자열이 없으니 재사용할 비밀번호도, 어딘가에 흘릴 비밀번호도 더는 필요없습니다. 겉으로는 단순해졌는데 안에서는 훨씬 튼튼해진 셈입니다.

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

패스키의 뼈대는 두 개의 표준입니다. 브라우저와 웹사이트가 대화하는 규약인 웹오센(WebAuthn)과, 기기와 인증 하드웨어가 대화하는 규약인 시탭(CTAP)입니다. 이 둘을 묶은 것이 파이도2(FIDO2)이고, 패스키는 그 위에서 사용자 눈높이로 다듬은 결과물입니다.

등록과 로그인은 이렇게 흐릅니다. 먼저 계정을 만들 때, 기기가 그 서비스 전용 키 쌍을 생성해 개인키는 기기의 보안 영역에 저장하고 공개키만 서버로 보냅니다. 이후 로그인 시점에는 서버가 매번 새로운 무작위 값(챌린지)을 던지고, 기기는 사용자의 생체 인증이나 잠금 해제를 확인한 뒤 그 값을 개인키로 서명해 돌려줍니다. 이 과정에서 오가는 것은 서명뿐이고, 재사용할 수 있는 비밀은 네트워크에 흐르지 않습니다.

피싱에 강한 이유도 여기서 나옵니다. 웹오센은 서명할 데이터에 정당한 사이트의 출처(origin) 정보를 함께 묶습니다. 가짜 도메인에서 로그인을 시도하면 출처가 어긋나 서명 자체가 성립하지 않습니다. 사용자가 실수로 속더라도, 기기가 대신 거절해 주는 구조인 셈이죠. 사람의 주의력에 기대던 방어를 암호 수준으로 끌어내린 것이 패스키의 진짜 차별점입니다.

구분	비밀번호	패스키(Passkey)
인증 방식	공유 비밀 문자열 입력	공개키·개인키 서명 검증
서버 저장 값	비밀번호(해시)	공개키(유출돼도 안전)
피싱 저항	없음(입력 시 탈취 가능)	있음(출처 바인딩)
사용자 동작	문자열 기억·입력	지문·얼굴·기기 잠금 해제

동기화형과 기기고정형, 무엇을 골라야 하나요

패스키라고 다 같은 패스키는 아닙니다. 크게 두 갈래로 나뉘는데, 이 구분을 모르면 도입 설계가 흔들립니다.

첫째는 동기화형(synced) 패스키입니다. 애플, 구글, 마이크로소프트 같은 플랫폼의 클라우드를 통해 개인키가 종단간 암호화된 채로 여러 기기에 자동 복제됩니다. 휴대폰을 새로 사도 로그인 정보가 따라오니 일반 소비자 서비스에 잘 맞습니다. 카카오(Kakao)가 카카오계정에 도입한 패스키도 iOS와 안드로이드 플랫폼 클라우드를 통해 자동 동기화되는 방식입니다. 편의성이 높은 대신, 키가 플랫폼 생태계 안에서 복제된다는 점이 통제 관점에서는 부담이 될수 있습니다.

둘째는 기기고정형(device-bound) 패스키입니다. 개인키가 특정 하드웨어(보안 키나 기기의 보안 칩)를 절대 떠나지 않습니다. 복제가 안 되니 불편하지만, 그만큼 보증 수준이 높습니다. 미국 표준 기준으로 동기화형은 AAL2를, 하드웨어 증명(attestation)을 붙인 기기고정형은 AAL3까지 충족할 수 있어 금융·정부·핵심 인프라처럼 규제가 강한 영역에서 선호됩니다.

구분	동기화형 패스키	기기고정형 패스키
키 복제	클라우드로 여러 기기 동기화	복제 불가, 단일 하드웨어 고정
보증 수준	AAL2	AAL3(하드웨어 증명 시)
강점	편의성·기기 교체 대응	최고 수준 보증·유출 차단
적합 영역	소비자 서비스, 일반 임직원	관리자·개발자, 규제 산업

실무에서는 둘 중 하나만 고르기보다, 위험 등급에 따라 섞어 씁니다. 일반 임직원 계정은 동기화형으로 넓게 깔아 편의를 확보하고, 특권 계정이나 프로덕션 접근에는 기기고정형을 요구하는 이중 설계가 최근의 정석입니다.

왜 2026년 기업이 패스키로 몰려가나요

숫자를 보면 흐름이 분명합니다. 파이도 얼라이언스가 열 개 나라의 소비자 1만1000명과 기업 의사결정자 1400명을 조사한 2026년 자료에서, 사람들의 90%가 패스키를 인지하고 있었고 75%가 최소 한 개 이상의 계정에 패스키를 설정해 둔 것으로 나타났습니다. 상위 100대 웹사이트 가운데 48%가 이미 패스키를 지원하는데, 이는 2022년의 두 배가 넘는 수치입니다.

기업 쪽 지표는 더 공격적입니다. 임직원 로그인에 패스키를 도입했거나 도입 중인 조직이 68%였고, 완전한 패스워드리스를 최종 목표로 삼은 곳이 82%, 이미 목표를 달성한 곳도 28%였습니다. 구글(Google)은 자사 서비스에서 패스키 로그인이 비밀번호보다 약 4배 더 잘 성공한다고 밝혔습니다.

이유는 단순합니다. 기업입장에서 계정 탈취는 대부분 피싱과 재사용된 비밀번호에서 시작되는데, 패스키는 바로 그 두 경로를 함께 닫습니다. 여기에 비밀번호 재설정 문의가 줄면서 헬프데스크 비용이 내려가고, 로그인 성공률이 오르며 이탈이 줄어듭니다. 보안을 강화하면 대개 불편해지는데, 패스키는 보안과 편의가 같은 방향으로 움직인다는 점에서 드문 기술입니다. 국내에서도 네이버, 카카오, SK텔레콤, KT 등이 로그인과 인증 앱에 패스키를 얹으며 이 흐름에 올라타고 있습니다.

한 가지 덧붙이면, 이 전환은 규제 흐름과도 맞물려 있습니다. 그동안 많은 서비스가 비밀번호에 문자 인증을 더하는 방식으로 규정을 맞춰 왔는데, 이 조합은 피싱 앞에서 여전히 취약합니다. 그래서 각국의 보안 지침이 점차 피싱 저항 인증을 명시적으로 요구하는 쪽으로 옮겨가고 있고, 패스키는 그 요건을 자연스럽게 충족하는 선택지로 자리잡았습니디. 규제 대응과 사용자 경험 개선을 한 번에 처리할수 있다는 점이, 비용을 들여서라도 지금 도입하려는 조직이 늘어난 배경입니다. 실무자 입장에서 보면 이건 단순한 로그인 교체가 아니라 인증 체계 전체를 다시 그리는 작업에 가깝습니다.

도입 전 반드시 짚어야 할 과제

물론 패스키가 만능은 아닙니다. 도입을 준비하는 기업이라면 다음 지점들을 먼저 설계해야 합니다.

계정 복구: 기기를 잃으면 그 기기에 묶인 패스키도 사라집니다. 복구 절차가 허술하면 그곳이 새로운 공격 표적이 됩니다. 실제로 성숙한 조직은 영상 확인이나 신분증 대조, 관리자 승인을 거친 뒤에야 1회용·1시간 유효의 임시 접근 패스를 발급하는 방식으로 복구 경로를 좁혀 둡니다.
IdP 이관: 패스키 자격증명은 등록 당시의 신원 공급자(IdP) 식별자에 묶입니다. 옥타(Okta)에서 마이크로소프트 엔트라(Microsoft Entra ID)로 옮기면 자격증명이 그대로 넘어오지 않아 전 직원 재등록이 필요합니다. 운영상 가장 까다로운 대목입니다.
공용 PC와 등록 마찰: 여러 사람이 쓰는 공용 단말은 도입의 최대 걸림돌로 꼽히며, 조직의 31%가 이를 첫 번째 장벽으로 지목했습니다. 자격증명을 직원 기기에 안정적으로 올리는 초기 등록 단계에서 대부분의 프로젝트가 헤맵니다.

새로운 위협도 함께 등장했습니다. 옥타 위협 인텔리전스는 공격자가 전화로 직원을 속여 엔트라 패스키 등록 자체를 가로채려 한 사례를 보고했는데요. 기술이 튼튼해지자 공격이 등록과 복구라는 사람의 절차 쪽으로 옮겨간 것입니다. 결국 패스키 도입은 기술 설정만이 아니라 등록·복구 프로세스 설계가 절반이라는 뜻입니다.

기업 패스키 도입 4단계 로드맵

1단계: 특권 계정부터 좁게 시작

전 직원에게 한꺼번에 밀지 않습니다. 관리자, 개발자, 프로덕션 접근 권한을 가진 고위험 계정부터 기기고정형 패스키나 하드웨어 보안 키를 의무화합니다. 피해가 가장 큰 곳을 먼저 막는 것이 순서입니다.

2단계: 신원 공급자(IdP)와 정책 정비

옥타, 엔트라, 핑아이덴티티(Ping Identity) 같은 IdP에서 패스키를 중앙 관리하도록 붙입니다. 이때 앞으로 IdP를 바꿀 계획이 있는지 반드시 먼저 점검해야 합니다. 이관 시 재등록 부담이 크기 때문입니다.

3단계: 등록과 복구 절차 표준화

가장 공들여야 할 단계입니다. 초기 등록을 어떻게 검증할지, 기기를 잃었을 때 어떤 고보증 절차로 복구할지 문서로 못 박습니다. 임시 접근 패스는 1회용에 짧은 유효시간으로 제한합니다.

4단계: 확대와 비밀번호 폐기

일반 임직원에게 동기화형 패스키를 넓게 배포하고, 로그인 성공률과 헬프데스크 문의 감소를 지표로 추적합니다. 안정화가 확인되면 비밀번호 로그인 경로를 단계적으로 닫아 완전한 패스워드리스로 이행합니다. 처음부터 비밀번호를 없애기보다, 패스키를 기본값으로 만들고 비밀번호를 예외로 밀어내는 순서가 현실적입니다.

FAQ

패스키를 쓰면 정말 비밀번호가 완전히 없어지나요?

장기적으로는 그 방향이지만, 전환기에는 공존합니다. 대부분의 기업은 패스키를 기본 로그인으로 두고 비밀번호를 예비 경로로 남겼다가, 도입이 안정화된 뒤 비밀번호를 폐기합니다. 조사에서도 완전 패스워드리스를 목표로 삼은 조직은 82%였지만 실제 달성한 곳은 28%로, 아직은 이행 과정에 있습니다.

휴대폰을 잃어버리면 계정에 못 들어가나요?

동기화형 패스키라면 클라우드를 통해 다른 기기에서 그대로 복구됩니다. 기기고정형이라면 미리 정해 둔 복구 절차(영상 확인, 신분증 대조, 관리자 승인 등)를 거쳐 임시 접근 패스를 발급받아 재등록합니다. 그래서 복구 절차 설계가 도입만큼 중요합니다.

패스키가 기존 다단계 인증(MFA)보다 안전한가요?

문자(SMS) 인증번호나 일회용 코드는 사용자가 가짜 사이트에 그대로 입력하면 탈취됩니다. 패스키는 서명에 정당한 사이트 출처를 묶기 때문에 가짜 도메인에서는 인증이 성립하지 않습니다. 이 때문에 피싱 저항 인증으로 분류되며, 기존 MFA보다 한 단계 높은 방어로 평가됩니다.

중소기업도 패스키를 도입할 수 있나요?

가능합니다. 이미 구글·마이크로소프트·애플 계정이나 주요 IdP가 패스키를 지원하므로, 별도 대규모 개발 없이도 기존 로그인에 얹을 수 있습니다. 다만 특권 계정 우선 적용과 복구 절차 문서화라는 원칙은 규모와 무관하게 동일하게 지켜야 합니다.

패스키를 도입하면 로그인 관련 업무가 실제로 줄어드나요?

비밀번호 재설정 문의가 감소하면서 헬프데스크 부담이 내려가는 효과가 보고됩니다. 로그인 성공률도 약 93%로 비밀번호 방식(약 63%)보다 높아, 인증 단계에서의 이탈과 재시도가 줄어듭니다. 다만 초기에는 등록 지원 문의가 늘 수 있어, 그 구간을 감안한 온보딩 설계가 필요합니다.