로그인 화면에 ‘패스키로 로그인’ 버튼을 추가했다고 비밀번호 위험이 사라지는 것은 아니다. 사용자가 패스키를 잃어버렸을 때 기존 비밀번호나 이메일 링크만으로 같은 계정에 들어갈 수 있다면, 공격자는 그 우회 경로를 노릴 수 있다. 반대로 비밀번호를 무조건 없애면 휴대전화를 교체한 사용자나 공유 PC에서 일하는 직원이 계정에 갇힐 수 있다. 패스키 도입의 핵심은 버튼이 아니라 로그인·등록·복구를 하나의 흐름으로 설계하는 것이다.
이 글은 기업용 관리자 화면과 고객 포털을 만드는 팀을 위한 실무 가이드다. 패스키가 무엇을 해결하고 무엇을 해결하지 못하는지 살핀 뒤, 어떤 순서로 도입하고 어떤 상황을 시험해야 하는지 정리한다. 특정 서비스의 보안 성과나 도입률을 가정하지 않는다.
문제부터 분리하자: 피싱, 계정 탈취, 계정 잠김
기존 로그인은 사용자가 비밀번호를 입력하고 서버가 이를 검증한다. 여기에 SMS 코드나 앱 승인 절차를 더해도 사용자가 가짜 사이트에 입력한 정보를 공격자가 중계하는 경로는 남을 수 있다. 패스키는 웹사이트의 도메인과 연결된 공개키 기반 인증 정보를 사용한다. 진짜 사이트용 패스키를 다른 도메인의 가짜 사이트에서 그대로 쓰게 만들기 어렵다는 점이 강점이다. FIDO Alliance의 패스키 설명도 이 사이트 결속성과 피싱 저항성을 핵심 특성으로 소개한다.
하지만 로그인 경로의 안전성과 계정 전체의 안전성은 다르다. 공격자가 약한 비밀번호 초기화나 상담원 계정 복구 절차로 새 패스키를 등록할 수 있다면 강한 로그인 버튼은 우회된다. 또 휴대전화 하나에만 패스키가 있는 직원이 기기를 잃어버리면, 피싱은 막았더라도 업무를 재개하지 못한다. 그래서 설계 질문은 ‘패스키를 지원할까?’가 아니라 ‘누가 어떤 증거로 계정 소유권을 확인하고, 잃어버린 인증 수단을 어떻게 교체할까?’여야 한다.
패스키는 비밀번호를 서버에 보내는 방식이 아니다
패스키를 만들 때 기기나 패스키 제공자는 해당 서비스에 묶인 공개키·비밀키 쌍을 만든다. 서비스 서버는 인증 정보의 식별자와 공개키를 저장한다. 비밀키는 서비스 서버에 전달되지 않고, 기기 또는 동기화를 제공하는 패스키 제공자 영역에서 관리된다. 사용자가 지문·얼굴·기기 PIN 등으로 화면 잠금을 풀어 인증하면, 기기는 서버가 보낸 새로운 요청값(challenge)에 대한 서명 정보를 돌려준다. 서버는 보관한 공개키로 응답을 검증한다. 생체 정보 자체가 웹서비스 서버로 전송되는 구조라고 이해해서는 안 된다.
이 설명은 개념을 단순화한 것이다. 실제 WebAuthn 검증은 서명 하나만 보는 일이 아니다. 서버는 예상한 사이트 출처(origin), 서비스 도메인에 대응하는 RP ID, 요청값, 사용자 확인 상태, 등록된 공개키를 함께 확인해야 한다. 요청값은 로그인 시도마다 새로 만들어 재사용 공격을 막는다. Google의 서버 측 패스키 인증 가이드는 이 검증 항목과 서버 라이브러리 활용을 구체적으로 설명한다. 암호학적 검증 코드를 처음부터 직접 짜기보다 검증된 WebAuthn 서버 라이브러리로 구현하고, 우리 서비스의 권한·세션 정책을 그 위에 연결하는 편이 안전하다.
동기화 패스키와 기기 종속 패스키, 어느 쪽이 맞을까
패스키라는 이름 아래에도 사용 환경은 다르다. 여러 기기에서 쓰도록 패스키 제공자가 동기화하는 방식은 일반 고객과 여러 기기를 사용하는 직원에게 접근성이 좋다. 보안키 등 특정 기기에 묶이는 방식은 별도 물리적 소유를 요구하고 통제가 쉬운 반면, 기기 분실 시 예비 수단과 교체 절차를 더 세심하게 준비해야 한다. 어느 방식이 절대적으로 우월하다고 정할 수는 없다. FIDO Alliance의 기업 도입 자료도 조직의 보안 요구, 작업 환경, 인력 유형에 따라 패스키 유형과 배포 방식을 고르게 한다.
예를 들어 일반 직원 포털은 개인 기기에서 동기화 패스키를 기본으로 안내할 수 있다. 반면 결제 승인이나 대량 데이터 내보내기 같은 고위험 관리자 작업은 조직 정책에 따라 기기 종속 보안키 또는 재인증을 요구할 수 있다. 이는 제품의 기본값을 그대로 적용한다는 뜻이 아니라, 업무 위험도와 기기 관리 방식을 분리해 결정한다는 뜻이다. 공용 PC·교대근무·외주 인력처럼 개인 기기 사용이 어려운 팀은 등록부터 별도 사용성 검토가 필요하다.
계정 하나에 패스키를 여러 개 붙일 수 있게 모델링하라
비밀번호는 계정당 하나를 상정하기 쉽지만 패스키는 그렇지 않다. 직원은 노트북과 휴대전화, 예비 보안키를 각각 등록할 수 있다. 따라서 데이터 모델은 ‘사용자 테이블에 패스키 한 칸’보다 계정 1개 : 인증 정보 여러 개가 자연스럽다. 각 인증 정보에 고유 ID, 공개키, 연결된 계정, 등록·마지막 사용 시각, 사용자가 알아볼 이름, 폐기 상태를 관리한다. 기기 이름은 화면에 보여 줄 보조 정보일 뿐 보안 검증의 근거가 되어서는 안 된다. Google의 서버 측 등록 가이드도 다중 패스키를 위한 별도 인증 정보 테이블을 예시로 제시한다.
‘새 패스키 등록’은 일반 로그인보다 민감한 작업이다. 이미 열린 오래된 세션만으로 아무 기기나 추가할 수 있으면, 세션을 탈취한 사람이 자신의 기기를 등록할 수 있다. 등록 직전에 충분히 최근의 재인증을 요구하고, 추가·삭제 사실을 사용자에게 알리며, 의심스러운 변경을 되돌릴 운영 경로를 둔다. 관리자 계정이라면 기기 교체 승인자와 수행자를 분리하는 것도 고려할 만하다. 이 정책은 서비스의 위험도에 따라 조정하되, 첫 번째 패스키 등록과 두 번째 패스키 추가를 같은 난도로 취급하지 않는 편이 좋다.
진짜 어려운 부분은 분실과 복구다
휴대전화 분실 시 가능한 경로를 미리 그려 보자. 동기화된 패스키가 다른 기기에서 사용 가능한가? 예비 보안키가 등록돼 있는가? 둘 다 없으면 누가 어떤 증거를 보고 계정을 되찾게 해 줄 것인가? 복구가 성공한 뒤 기존 분실 기기의 인증 정보를 어떻게 폐기할 것인가? 이 질문에 답이 없으면 고객지원팀의 임기응변이 사실상의 보안 정책이 된다.
실무적으로는 단계가 필요하다. 먼저 사용 가능한 다른 패스키로 로그인하고 분실된 인증 정보를 제거하는 경로를 제공한다. 다른 패스키가 전혀 없다면 조직이 정한 신원 확인과 승인 절차를 거쳐 새 기기를 등록한다. 고위험 계정은 복구 직후 주요 변경이나 민감 작업에 추가 확인을 요구할 수 있다. 복구 요청·승인·인증 정보 폐기 내역은 감사할 수 있게 기록한다. 이메일 링크나 기존 비밀번호를 복구 수단으로 남긴다면 그것이 패스키 로그인과 동등한 보안 수준이라고 홍보해서는 안 된다.
이 지점은 여러 기기를 등록하는 사용성 문제인 동시에 보안 경계다. FIDO Alliance의 피싱 방어 단계별 가이드는 비밀번호를 함께 허용하는 경우 해당 경로가 패스키의 피싱 저항성을 우회할 수 있다고 짚는다. 전환기에는 기존 로그인을 유지할 수 있지만, 그때는 ‘패스키 사용자도 전체 계정이 피싱에 완전히 안전하다’고 단정하지 말고 우회 경로의 사용량과 위험을 따로 측정해야 한다.
한 번에 전환하지 말고 경로별로 출시하라
도입 순서는 조직마다 달라도, 다음과 같은 단계는 위험을 낮춘다.
- 현황을 그린다. 직원·고객·관리자 계정, 사용하는 기기와 브라우저, 공유 단말, 기존 SSO와 복구 절차를 적는다. ‘비밀번호를 없앤다’가 아니라 실제 계정 접근 경로를 먼저 파악한다.
- 등록을 제한적으로 연다. 로그인한 사용자에게 패스키 추가를 제안하되, 등록 성공·취소·기기 미지원·중복 등록을 구분해 처리한다. 계정 설정 화면에는 등록된 패스키와 제거 기능을 제공한다.
- 로그인 경험을 다듬는다. 가능하면 기존 로그인 화면에서 자연스럽게 패스키를 제안하고, 다른 기기 사용·취소·실패 후 재시도 경로를 분명히 보여 준다. 사용자가 ‘지문이 서버에 저장된다’고 오해하지 않도록 설명한다. Google의 패스키 사용자 여정 가이드는 로그인, 등록, 복구 순간의 안내를 별도로 다룬다.
- 복구를 실제로 연습한다. 휴대전화 분실, 패스키 제공자 변경, 퇴사자 기기, 관리자 보안키 분실, 상담원 오인증을 모의 시험한다. ‘로그인은 쉬운데 복구 티켓이 쌓이는’ 문제를 출시 전에 발견한다.
- 약한 경로를 줄여 간다. 패스키 사용자가 충분히 늘고 예비 수단이 준비된 계정부터 비밀번호·SMS·지원센터 우회 경로의 허용 범위를 재검토한다. 전 계정을 한날 한시에 전환할 필요는 없다.
성공 기준은 버튼 클릭 수가 아니다
패스키 등록 수만 보면 운영 현실을 놓친다. 가입·로그인 성공률과 중도 포기 지점, 기기별 실패 원인, 복구 요청 건수, 복구 완료까지 걸리는 시간, 비밀번호 우회 경로 이용량을 함께 본다. 보안팀은 분실·삭제·새 등록 이벤트의 감사 가능성을 보고, 고객지원팀은 사용자가 스스로 해결 가능한지를 본다. 어떤 지표든 개인 식별 정보를 과도하게 수집하지 않으면서 오류 유형을 분리하는 것이 중요하다.
특히 ‘패스키가 등록된 계정’과 ‘패스키로만 접근 가능한 계정’을 혼동하지 말아야 한다. 전자는 새로운 로그인 옵션이 생긴 상태이고, 후자는 기존 우회 경로까지 정책으로 통제한 상태다. 둘을 분리해 집계해야 실제 피싱 위험 감소를 해석할 수 있다. 이는 위 FIDO 가이드에서 설명하는 단계적 방어 모델을 운영 지표로 옮긴 실무적 해석이다.
출시 전 체크리스트
- 서비스의 RP ID와 허용 origin을 명확히 고정하고, 등록·인증 응답을 검증된 라이브러리로 확인하는가?
- 계정당 여러 패스키를 등록·이름 변경·폐기할 수 있는가?
- 새 패스키 등록과 기존 패스키 삭제에 재인증, 사용자 알림, 감사 기록이 있는가?
- 기기 분실 시 예비 패스키, 동기화, 고객지원 복구의 순서와 승인 기준이 문서화돼 있는가?
- 비밀번호·이메일·SMS가 남아 있다면 패스키 보안을 우회하는 경로로 평가했는가?
- 공유 단말, 보안키 사용자, 모바일·데스크톱, 브라우저 취소 상황을 실제로 시험했는가?
- 도입률 외에 로그인 실패와 복구 실패를 원인별로 관찰하는가?
패스키는 비밀번호를 안전하게 ‘대체할 가능성’을 주는 기술이지, 계정 운영 설계를 자동으로 완성해 주는 기능이 아니다. 좋은 도입은 빠른 로그인, 여러 기기의 연속성, 신뢰할 수 있는 복구 경로를 함께 만든다. 새 기능을 켜기 전에 계정이 처음 만들어지는 순간과 마지막 기기를 잃어버린 순간을 둘 다 그려 보면, 보안과 사용성 사이의 빈틈이 훨씬 잘 보인다.
