10월 10일 HN 258표 — '패스키스는 함정'이 지적하는 건 패스키가 아니라 내 기기의 승인권이었다

발행 2026-10-12 · 분류 보안·표준 · 난이도 중급 · 읽는 시간 9분

세 줄 요약. ① 패스키는 실제로 비밀번호보다 안전하다. 그게 이 글의 쟁점이 아닐 뿐이다. ② 쟁점은 '원격 인증(attestation)'이라는 선택 옵션 하나다. 이걸 자리잡히 두면 사이트 운영자가 내 기기의 칩과 운영체제와 앱을 심사하고, 낙오자를 로그인에서 쫓아내는 권한을 손에 넣는다. ③ 표준 문서는 이미 열려 있었다. 2022년에 플래그가 늘었고, 예약 자리가 두 개 남았다. 오늘은 대안(TOTP, FIDO2 보안 키)을 알아두는 날이다.

10월 10일, 'Non-Functional'이라는 블로그에 「Passkeys are a trap. Do not use them.」이 올라왔다. 제목은 선동적이고 필자는 기술자 아닌 일반 독자를 자처했는데, 해커뉴스 표는 하루 반 만에 258(댓글 140)이 붙었다. 스레드는 갈렸고, 갈린 지점은 예상대로 '패스키가 안전한가'가 아니라 '누구를 위한 표준인가'였다.

논픽션으로서의 완성도는 인정해 줄 만하다. 이 글은 그 논지 구조를 재료 삼아, 패스키를 쓸 사람과 아직 미룰 사람이 어디서 갈리면 되는지를 우리말로 다시 짠다.

30초 요약

1. 무엇이 터졌나

사건의 실체는 결함도 유출도 아니다. 사이트들이 앞다퉈 비밀번호 자리를 패스키로 바꾸라는 캠페인을 벌이는 지금, 그 표준에 '사용자 승인권'을 잠그는 장치가 기본 장착돼 있다는 걸 일반 사용자에게 처음 설명한 글이다. 폭발 지점은 표준 문서가 아니라 이름 짓기다.

출발점은 표준화 기구다. 패스키는 FIDO Alliance라는 컨소시엄이 밀어내는 WebAuthn 계열 자격증명의 상품 이름이다. 회원은 거대 기술 기업, 정부, 정보기관, 은행, 공공기관, Mozilla 같은 비영리까지 '패스키는 옳다'로 합의한 집단이다. 저자의 지적은 여기서 비수처럼 꺾인다 — 회원 목록에 소비자 권익 단체가 한 곳도 없다.

비교 대상으로 W3C를 소환하는 데에는 이유가 있다. 웹 표준 기구에는 기업 외에 대학과 공익 그룹, 그리고 1989년에 웹을 발명한 팀 버너스리가 앉아 있다. '표준'이라는 단어는 같지만 이해관계의 지도가 다른 물건이다.

문제의 메커니즘을 풀자. WebAuthn 표준 문서를 넘기면 'passkey'라는 단어가 거의 안 나온다. 대신 사전 식별 가능 여부, 복사 가능 여부, 전송 가능 여부, 하드웨어 보관 여부, 사용자 재현·확인 여부, 인증 여부가 각각 독립 스위치로 정의돼 있다. 저자의 표현을 빌리면 표준서라기보다 부품 카탈로그다. 그런데 시장에서는 이 카탈로그 전체가 '패스키'라는 상표 하나로 팔린다.

혼동이 사고가 아니라 설계라는 게 이 글의 출발 가정이다. 사용자는 세밀한 조건을 고를 기회가 없고, 사이트는 '더 안전'이라는 한마디만 던진다.

진짜 열쇠는 마지막 스위치다. 인증(attested) 패스키는 원격 인증을 쓴다. '네가 쓰는 패스키 관리자는 우리가 승인한 관리자다'를 암호학적으로 증명하는 장치인데, 성립 조건이 가혹하다. 기기의 보안 칩, 패스키 관리자 소프트웨어, 운영체제, 펌웨어가 모두 승인 목록에 올라 있어야 한다. 보안 칩은 본래 탈취 방지용이라 '넷플릭스도, 내 운영체제조차, 심지어 나 자신도' 비밀을 칩 밖으로 못 빼는 물건으로 통한다 — 그 성질을 뒤집으면 '사이트가 내 칩을 신뢰할 수 있다'가 된다.

이때부터 권력의 방향이 바뀐다. 사이트는 조건을 걸 수 있다: 사용자 확인 필수, 복사 불가 필수, 하드웨어 보관 필수. 사용자가 조건을 거짓으로 신고하는 걸 원격 인증이 막아 준다. 인증 요구가 아직 대부분 사이트에서 필수는 아니다 — 저자의 표현대로 '자리만 잡으면 된다'는 뜻이다. 사이트는 먼저 인증 대응 여부를 몰래 관찰하다가, 사용자가 충분히 몰려들면 스위치를 돌려 인증 없는 패스키를 거부하기 시작할 수 있다.

2. 왜 대단한 논점인가

① 비밀번호·TOTP와 갈리는 축은 '저장처 통제'다
비밀번호는 적어 둘 장소를 내가 고르고, 인증기 앱은 거의 호환되며, 물리 보안 키는 신뢰하는 동료에게 손으로 넘길 수 있다. 패스키는 이 중 어디에도 해당하지 않는다 — 인증 없는 복사용 패스키는 예외다. 원저자는 표준화된 패스키를 직접 만들어 이메일로 첨부했고 그와 동시에 사이트 로그인이 됐다며, '내가 내 것처럼 다루는 권리' 자체는 아직 가능하다고 증명한다. 통제권 상실은 기술 필수가 아니라 인증 옵션의 확산 경로라는 얘기다.

② 인증기는 이미 10년 전에 같은 문제를 해결했다
패스키가 해결하겠다고 나온 문제, 즉 비밀번호 취약성은 2단계 인증과 TOTP가 먼저 처리한 영역이다. TOTP(표준 RFC 6238)은 문자도 인터넷도 안 쓰고, 30초마다 시각과 시드로 숫자를 뽑고, 소프트웨어를 자유롭게 고를 수 있고, 실수로 유출돼도 몇 분만 위험하다. 게다가 '시간만 재는 기계'라면 90년대 휴대용 게임기에서도 돌아간다 — 실제로 저자는 그 포팅을 근거로 든다. 패스키가 제시한 개선은 '편리함' 한 칸이고, 그 대가로 준 게 인증기에는 없던 승인권이다.

③ 표준은 플래그 단위로 자란다
WebAuthn Level 1 시절 인증 정보 플래그는 4개였다. 2022년의 Level 3로 복사본 존재 여부가 추가됐고, 예약 자리는 2개가 남았다. 사이트가 요구 조건을 늘릴 통로가 표준 문서 안에 이미 제도화돼 있다는 뜻이다. 오늘의 요구 사항은 내일의 최소 사양이 되고, 예약된 2자리는 뭐가 들어갈지 모른다.

④ 종착역은 구독 공유 단속이 아니라 기기 통제다
저자가 진짜 무섭다고 지목한 건 넷플릭스 계정 차단이 아니다. 원격 인증은 '승인받지 않은 소프트웨어 금지'로도 쓸 수 있다. 경쟁 앱 차단, 확장 프로그램이 깔린 브라우저 거부, 커스텀 롬 낙오까지 — 기기의 주인이 누가 되느냐의 문제다. 구글이 올해 uBlock Origin을 크롬에서 퇴역시킨 전례와, 그 판단을 다른 브라우저까지 묶어 강제할 수단으로 인증이 쓰일 수 있다는 서술이 이어진다.

⑤ 반대로, 이 글이 약한 자리도 있다
패스키의 진짜 보안 이점 — 도메인 결합으로 중간자 공격을 막는 성질 — 은 저자 스스로 부록에서 인정한다. 그리고 이 성질만 취하는 물건이 이미 있다: YubiKey류의 자체 완결형 보안 키는 원격 인증 요구가 운영체제 전체로 번지지 않는다. '패스키를 다 거부'가 아니라 '인증 없는 패스키와 자기 물리로 남기고 인증만 막아라'가 합리적 결론에 가깝다.

3. 바로 써먹기

① 종류 확인 — 만들 때 이걸 고른다
패스키 생성 화면에서 사용자가 실제로 통제할 수 있는 선택지는 '어느 종류의 패스키로 만들 것인가' 한 칸이다. 계정을 관리하는 사용자라면 중요도별로 표를 적용해 볼 만하다.

② 분산 — 모든 계정을 패스키로 통합하지 않는다
중요도가 높고 아직 인증을 요구할 기미가 없는 계정은 TOTP(표준 RFC 6238)나 자기 물리로 남긴다. 인증기 앱은 호환이 자유다 — 사이트가 특정 앱 아이콘을 떠받들어도 시드만 옮기면 끝난다. 패스키를 쓴다면 '인증 요구가 아직 없는 사이트'에 먼저 두고, 인증을 요구하는 순간 옮겨 둘 출구(TOTP 백업)를 열어 둔다.

③ 출구 점검 — 내 환경은 인증을 통과할까
원격 인증은 칩·관리자·운영체제·펌웨어의 4중 신뢰다. 일상에서 이탈 사례는 이미 존재한다: 보안 업데이트가 끊긴 폰에 커스텀 운영체제를 올려 쓰는 경우, 커스텀 롬과 사설 인증기, 그리고 리눅스 데스크톱. 이 중 하나라도 해당하면 '나중엔 못 들어갈 수 있는 계정'을 패스키 단독으로 만들면 안 된다.

④ 예의 — 반대로 패스키의 좋은 구석도 쓴다
원저자도 마지막에 인정하듯, 패스키의 도메인 결합은 비밀번호·SMS 코드가 못 넘본 중간자 방어다. 그 이점만 취하고 승인권은 피하는 조합이 자체 완결형 보안 키다. YubiKey류는 WebAuthn을 쓰되 인증의 요구 범위가 기기 전체로 번지지 않는다. '패스키 싫다'와 '패스키류 도구를 안 쓴다'는 다른 결정이다.

4. 해외 반응 쟁점

해커뉴스 스레드의 첫 진영은 '제목이 과장'이라는 지적이다. 표준 자체를 거부하라는 주장이 아니라 인증 요구를 거부하라는 주장인데, 제목이 그 구별을 지운다는 댓글들이 표를 받았다. 정독 후 '전문가용 문서 서사는 정확하다'는 평가도 같은 진영이다.

두 번째는 실무 반론이다. 규모 있는 서비스 운영자 입장에서 패스키는 비밀번호 재설정 티켓과 계정 탈취를 줄여 주는 '경영자 설득용' 표준이고, 인증 요구는 아직 현실의 문제가 아니라는 실용주의다. 인증을 요구하는 사이트가 드물다는 지적은 원저자도 인정하는 부분이다.

세 번째는 '이미 늦었다'는 체념형이다. 주류 사용자 대다수는 4개 운영체제(Windows·macOS·Android·iOS) 위에 살고, 폰 OS가 죽으면 OS를 교체하는 대신 폰을 교체한다 — 인증 통과 실패가 생활에서 거의 발생하지 않는다는 것이다. 이 논리대로라면 저자의 경고는 일반 사용자용이 아니라 플랫폼 종속을 경계하는 집단에 대한 경고다.

네 번째는 '진짜 문제는 접근성'이라는 축이다. 저자가 '패스키의 종류를 확인하라'고 할 때, 그 선택지가 일반 사용자에게 노출되는 사이트가 거의 없다는 점이다. 확인하라는 조언 자체가 전문가용이라는 반론은 원저자도 부록으로 인정하는 지점이다.

5. 마시기 전 주의

첫째, 이 글은 논픽션이지 매뉴얼이 아니다. '원격 인증이 곧 의무화된다'는 예측은 저자의 추론이지 표준 일정표가 아니다. Level 3 이후 추가 개정 일정은 인용하지 않았다.

둘째, 패스키의 정의는 업체마다 흔들린다. 이 글이 쓰는 '패스키=카탈로그 전체'는 저자의 프레임이고, 각 플랫폼 홍보물은 그중 편한 조각만 가리킨다.

셋째, TOTP 예찬은 유출 시나리오 한정이다. 인증기 계정이 통째로 새면 코드 생성기가 아니라 시드가 새므로, 인증기 자체의 백업·잠금 관리가 전제다.

넷째, 기기 통제 비유(브라우저 확장·AI 스캐너)는 저자의 정치철학에 가깝다. 기술 논거와 소신은 분리해서 읽는 편이 안전하다.

바로 가기

• 원문 — Passkeys are a trap. Do not use them.
• 해커뉴스 댓글창(표 258·댓글 140)
• WebAuthn Level 3 표준 문서

같이 읽기

• 클릭 한 번에 계정 통째로 — 세미콜론 한 글자 걸러 안 넣은 메신저에서 무슨 일이
• 앱마켓이 2.0으로 갈아탈 때 사용자가 확인할 세 가지