패스키는 안전한데 왜 사용자는 어디에 저장됐는지 모를까요?

패스키는 안전한데 왜 사용자는 어디에 저장됐는지 모를까요?

패스키 보안과 사용자 경험 썸네일

패스키는 비밀번호를 직접 입력하지 않아도 되고 피싱에도 강한 인증 수단이에요. 그런데 로그인 화면에서 패스키를 만들라는 안내를 만나면 어디에 저장되는지, 다른 기기에서도 쓸 수 있는지, 휴대폰을 잃으면 어떻게 복구하는지 알기 어려워요. X의 프로덕트 책임자 Nikita Bier가 이 간극을 거칠게 비판하면서 패스키의 보안성과 사용자 경험을 둘러싼 논쟁이 다시 커졌어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
논쟁의 출발	Nikita Bier는 사용자가 패스키의 정체와 저장 위치를 이해하기 어렵다고 비판했어요	기술의 장점을 설명하지 못하면 안전한 기능도 설정 단계에서 외면받을 수 있어요
패스키의 원리	사이트마다 공개키와 개인 키를 이용해 로그인하고, 기기 잠금 해제 방식으로 사용을 승인해요	비밀번호 문자열을 서버와 로그인 화면에 전달하지 않아 피싱 위험을 줄여요
사용자의 혼란	휴대폰, 운영체제, 브라우저, 비밀번호 관리자 중 누가 키를 보관하는지 화면만 보고 판단하기 어려워요	기기 변경과 복구 방법을 모르면 사용자는 계정 접근을 잃을 위험부터 떠올려요
제품 설계	등록 전에 저장 위치, 사용할 수 있는 기기, 복구 수단을 알려줘야 해요	보안 설명보다 다음 로그인과 분실 상황을 구체적으로 보여주는 편이 이해하기 쉬워요

1. 패스키의 보안 장점보다 저장 위치가 먼저 궁금해져요

Nikita Bier는 패스키가 소비자 심리를 이해하지 못한 보안 엔지니어에게서 나왔다고 비판했어요. 사용자가 패스키의 장점을 따져 보기도 전에 정체를 알 수 없는 인증 수단을 요구받는다는 주장이에요. 휴대폰, 브라우저, 운영체제, 생체 정보 중 무엇이 패스키인지 알기 어렵다는 표현도 썼어요. 비판의 말투는 강하지만, 로그인 설정 화면에서 사용자가 실제로 하는 질문을 정확히 건드려요. 2

FIDO Alliance의 설명을 보면 패스키는 FIDO 표준을 따르는 암호학적 인증 자격 증명이에요. 사이트나 앱의 계정과 연결되고, 사용자는 평소 기기를 여는 생체 정보나 PIN, 패턴으로 로그인을 승인해요. 지문이나 얼굴 정보 자체가 패스키는 아니에요. 생체 정보와 PIN은 기기에 보관된 개인 키를 사용해도 되는지 확인하는 수단에 가까워요. 3

웹사이트는 공개키를 보관하고 로그인 때 기기가 보낸 서명을 확인해요. 사용자가 입력할 비밀번호 문자열이 없으므로 가짜 로그인 페이지가 자격 증명을 받아 가기 어려워요. 사이트마다 다른 키 쌍을 쓰기 때문에 한 서비스에서 인증 정보가 새더라도 같은 비밀번호를 재사용한 다른 계정까지 연쇄적으로 뚫리는 문제도 줄일 수 있어요.

728x90

문제는 이 설명만으로 다음 행동을 결정하기 어렵다는 데 있어요. 패스키를 만든 직후 다른 휴대폰이나 노트북에서 로그인할 수 있는지, 특정 운영체제 계정이나 비밀번호 관리자를 통해 동기화되는지, 기기를 잃었을 때 어떤 복구 수단을 쓸지는 제공자와 서비스 구현에 따라 달라질 수 있어요. 화면에 "패스키 만들기"만 보이면 사용자는 키를 누가 관리하는지 확인하지 못한 채 선택해야 해요.

Hacker News 토론에서도 비슷한 질문이 반복됐어요. 여러 운영체제와 브라우저를 함께 쓰는 개발자는 한 기기에서 만든 패스키를 다른 조합에서도 쓸 수 있는지, 계정 하나에 몇 개를 등록할 수 있는지, 가족과 공유하는 계정은 어떻게 처리하는지 물었어요. 반대로 Apple 기기나 1Password처럼 동기화 환경을 이미 맞춘 사용자는 비밀번호보다 편하다는 경험을 적었어요. 패스키 자체의 원리보다 저장소와 기기 조합이 체감 품질을 가른다는 사례예요. 4

서비스가 패스키를 도입할 때는 등록 버튼 앞에서 세 가지를 알려주는 편이 좋아요. 첫째, 이번 패스키가 어디에 저장되는지 보여줘야 해요. 둘째, 어떤 기기와 브라우저에서 다시 쓸 수 있는지 설명해야 해요. 셋째, 휴대폰 분실이나 계정 이전 때 사용할 복구 방법을 먼저 알려줘야 해요. "더 안전해요"라는 한 줄보다 "이 iCloud 키체인에 저장되고 같은 Apple 계정의 기기에서 쓸 수 있어요"처럼 다음 상황을 구체적으로 말하면 선택 부담이 줄어요.

복구 수단도 인증 설계의 일부예요. 패스키가 강해도 고객센터가 간단한 신원 질문만으로 계정을 열어주면 공격자는 약한 우회로를 노릴 수 있어요. 이메일 매직 링크나 기존 비밀번호를 계속 남겨두면 계정 잠금 위험은 낮아지지만, 피싱에 강하다는 장점은 줄어들 수 있어요. 서비스팀은 패스키 등록률만 볼 게 아니라 기기 변경 성공률, 복구 요청, 로그인 이탈률을 함께 봐야 해요.

왜 중요한가요

패스키 논쟁은 보안 기술의 성능과 사용자가 느끼는 통제감이 따로 움직일 수 있다는 사례예요. 개발팀은 공개키 암호와 피싱 저항성을 설명할 수 있어도, 사용자는 "내 열쇠가 지금 어디에 있고 잃으면 누가 되찾아 주는가"를 먼저 확인해요. 이 질문에 답하지 못하면 안전성보다 계정 잠금 위험이 더 크게 보여요. 3

제품팀은 패스키를 비밀번호 입력창의 대체 버튼으로만 다루기 어려워요. 등록, 동기화, 기기 변경, 복구, 삭제까지 하나의 흐름으로 설계해야 해요. 운영체제나 비밀번호 관리자마다 화면과 동작이 다르면 도움말도 실제 환경에 맞춰 나눠야 해요. 특히 여러 플랫폼을 오가는 사용자에게는 패스키를 만들기 전에 현재 선택한 저장소와 쓸 수 있는 기기를 보여주는 안내가 필요해요.

패스키의 보안 원리는 이미 쓸 만해요. 이제 경쟁력은 사용자가 열쇠의 위치와 복구 경로를 이해한 채 선택할 수 있게 만드는 데서 갈려요. 로그인 성공률만 높이는 설계보다 기기를 잃거나 바꾼 뒤에도 계정에 다시 들어올 수 있는지까지 측정해야 실제 사용 경험을 개선할 수 있어요. 4

참고 자료

1. Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 — GeekNews
2. Nikita Bier의 Passkey 사용자 경험 비판 — X
3. Passkeys — FIDO Alliance
4. Passkeys were invented by engineers with zero understanding of consumer brain — Hacker News