패스키는 함정일까 | '쓰지 말라'는 글과 반박이 갈린 지점, 내 계정에 할 일 3가지 (2026년 10월 기준)

패스키를 켜라는 안내가 계정마다 뜨는데, 같은 주에 "패스키는 함정이다. 쓰지 마라"는 글이 크게 돌았습니다. 10월 10일 Non-Functional 블로그에 올라온 이 글은 해커뉴스에서 큰 논쟁이 됐고, 보안 연구자 Scott Helme가 10월 14일 "패스키는 함정이 아니다"라는 반박을 냈습니다.

두 글은 같은 기술을 놓고 정반대 결론에 도착했습니다. 이 글은 누구 말이 맞는지 판정하지 않고, 어디까지가 확인된 사실이고 어디부터가 앞날에 대한 예측인지를 나눠 정리합니다. 다 읽으면 오늘 내 계정에서 할 일이 세 가지로 좁혀집니다.

논쟁의 핵심은 패스키가 약하냐가 아니라 "증명(attestation)"이라는 기능이 나중에 사용자의 선택권을 줄이느냐입니다. 지금 소비자 서비스가 증명을 요구하지 않는다는 점은 양쪽 글이 모두 인정하지만, 앞으로도 그럴지는 아직 아무도 모릅니다. 그래서 패스키는 쓰되 복구 수단을 따로 두는 쪽이 안전합니다.

목차

1. "쓰지 말라"는 글이 말한 것

2. 반박이 말한 것: Helme의 네 가지

3. 쟁점 정리: 확인된 것과 아직 모르는 것

4. 이식성과 사용자 확인: 갇히는 느낌의 정체

5. 일반 사용자는 오늘 무엇을 하면 되나

6. 서비스를 만드는 쪽이라면

1. "쓰지 말라"는 글이 말한 것

글쓴이는 비전문가 독자를 향해 "패스키가 비밀번호보다 훨씬 안전할 수 있지만, 사용자의 이익을 우선해 설계되지는 않았다"고 씁니다. 중심에 있는 것은 증명(attestation)입니다. 사이트가 증명을 요구하기 시작하면 승인된 패스키 관리자와 운영체제, 펌웨어만 통과하고, 직접 만든 소프트웨어나 LineageOS 같은 커스텀 운영체제는 걸러질 수 있다는 걱정입니다.

글은 이것을 "숨겨진 다이얼"이라고 부릅니다. 지금은 대부분의 사이트가 증명을 요구하지 않지만, 대부분의 이용자가 영향을 받지 않는다고 판단되면 사이트가 조금씩 올릴 수 있다는 예상입니다. 아래 표는 글의 주장과, 글이 스스로 인정한 부분을 나란히 놓은 것입니다.

글의 주장	글이 든 근거	글이 직접 인정한 것
증명이 선택권을 줄인다	증명이 걸리면 승인된 소프트웨어·운영체제만 통과할 수 있다	지금은 대부분의 사이트가 증명을 요구하지 않는다
FIDO 얼라이언스는 사용자 편이 아니다	회원사에 빅테크·정부 기관·은행이 있고 소비자 단체는 없다	회원사의 동기가 나쁘다고 단정하지는 않는다
패스키 종류를 구분하기 어렵다	복제 가능 여부, 하드웨어 보관 여부 등 여러 종류가 모두 패스키로 불린다	내가 만드는 패스키가 어떤 종류인지 알고 만들라고 권한다
대안은 인증 앱(TOTP)과 보안 키	TOTP는 개방 표준이라 앱을 직접 고를 수 있다	글 끝에서 패스키가 도메인에 묶여 중간자 공격에 강하다는 점을 인정한다

핵심 글쓴이도 패스키가 비밀번호보다 훨씬 안전할 수 있다고 인정합니다. 이 논쟁은 패스키가 뚫리기 쉽다는 이야기가 아니라, 앞으로 누가 선택권을 쥐느냐에 대한 이야기입니다.

2. 반박이 말한 것: Helme의 네 가지

Helme는 패스키를 직접 구현한 오픈소스 라이브러리를 만들고 자기 서비스에 패스키를 배포한 보안 연구자입니다. 10월 14일 글에서 "많이 받은 질문이라 답한다"며 네 가지를 짚었습니다. 아래는 같은 쟁점에 대한 두 글의 말을 비교한 표입니다.

쟁점	글쓴이	Helme
내 패스키가 증명을 보내나	증명은 승인된 관리자·운영체제·펌웨어 사용을 입증한다	iCloud 키체인, 구글 비밀번호 관리자, 1Password, Bitwarden 같은 동기화 패스키는 증명서를 주지 않고, 사이트가 요청해도 none이 돌아온다
증명이 알려 주는 것	승인된 소프트웨어·운영체제·펌웨어	제조사와 모델(AAGUID)이며 운영체제·브라우저·확장 프로그램·루팅 여부는 알려 주지 않는다
보안 키 추천	보안 키는 운영체제 전체 증명을 피한다	YubiKey 같은 보안 키가 오히려 증명을 하는 장치다
TOTP	이미 훌륭한 해법이다	코드를 엉뚱한 사이트에 입력하면 피싱에 뚫린다. 패스키는 도메인에 묶여 가짜 사이트에서 쓰이지 않는다

Helme의 결론은 "패스키를 계속 써라"입니다. 증명이 소비자 로그인으로 퍼지면 그때 크게 반대하면 되고, 아직 일어나지 않은 일을 피하려고 지금 패스키를 끊으면 피싱 위험만 남는다는 논리입니다. 다만 Helme도 증명을 쓰지 않는 방식(attestation none)의 한계를 별도 글로 다룬 적이 있습니다. 사이트에 악성 스크립트가 들어오면 공격자가 만든 패스키를 등록당할 수 있다는 내용이며, 1Password 확장 프로그램 분석 글에서도 이 점을 다시 짚었습니다.

주의 위 표의 Helme 설명은 본인의 주장입니다. 동기화 패스키가 실제로 증명을 주지 않는지는 독립적으로 확인된 결과가 아니라는 점을 기억하세요.

3. 쟁점 정리: 확인된 것과 아직 모르는 것

여기서는 두 글의 주장 대신 W3C의 웹 인증(WebAuthn) 명세로 확인되는 것만 따로 모았습니다. 명세는 사이트가 증명에 대한 선호를 밝히는 옵션을 두는데, 기본값은 none(증명에 관심 없음)입니다. 인증 장치가 증명서를 만들었더라도 사이트가 none을 고르면 브라우저가 이를 빈 증명으로 바꿉니다(자기 증명은 제외). 사이트가 정하는 것은 증명을 요청할지와 어떤 증명을 받아들일지의 기준이고, 증명의 종류와 형식은 인증 장치가 정합니다.

출처: W3C WebAuthn Level 3 명세 5.4.7절 갈무리

증명에 담기는 내용은 형식마다 다릅니다. 안드로이드 키 증명 형식은 사이트가 키가 보안 하드웨어(TEE) 안에서 만들어졌는지를 따져 볼 수 있게 하고, TPM 형식에는 펌웨어 버전 같은 값이 들어 있지만 명세는 이 값을 검증에는 쓰지 않고 위험 판단의 입력으로만 쓸 수 있다고 적습니다. 그래서 "제조사와 모델 정도"라는 설명도, "승인된 운영체제와 펌웨어를 모두 입증한다"는 설명도 모든 경우에 맞는 일반론은 아닙니다.

재구성한 예시 화면 (실제 실행 출력이 아니라 설명용 구성)

질문	확인 상태	근거
증명의 기본값은?	확인됨: none	W3C 명세 5.4.7
사이트와 장치의 역할은?	확인됨: 사이트는 요청 선호와 허용 기준을 정하고, 증명의 종류와 형식은 장치가 정한다	W3C 명세 6.5절(증명)
동기화 패스키가 증명을 안 주나?	Helme의 설명, 독립 확인 없음	Helme 글
소비자 사이트가 지금 증명을 요구하나?	양쪽 글이 모두 대부분 요구하지 않는다고 씀	두 글
앞으로 큰 사이트가 증명을 요구할까?	확인 불가: 양쪽 모두 예측	두 글
보안 키는 증명을 하나?	두 글이 다른 범위를 말함: Helme는 보안 키가 제조사 증명서를 담는 장치라고, 글쓴이는 보안 키의 증명이 운영체제 전체로 번지지 않는다고 설명	두 글

제 판단으로는 마지막 줄의 두 설명은 부딪히지 않을 수 있습니다. 보안 키가 증명을 할 수 있다는 점은 Helme가 짚었고, 그 증명이 운영체제 전체를 제한하지는 않는다는 점은 글쓴이가 강조합니다. 걱정하는 범위가 다른 것입니다.

핵심 논쟁의 핵심은 앞날 예측입니다. 현재 기술을 설명하는 부분에도 차이가 있지만, 지금 증명을 요구하지 않는다는 점은 양쪽이 같고 앞으로 요구할지는 어느 쪽도 증명하지 못합니다.

4. 이식성과 사용자 확인: 갇히는 느낌의 정체

해커뉴스 댓글에는 패스키를 다른 관리자로 옮길 수 있느냐는 질문이 이어졌고, 가능하다는 답도 달렸습니다. FIDO 얼라이언스는 자격 증명 교환 형식(Credential Exchange Format) 1.0을 제안 표준으로 공개했고, 교환 프로토콜은 아직 초안 단계라고 안내합니다. 애플에서 비밀번호 관리와 웹 인증 분야를 맡고 있다고 밝힌 Ricky Mondello는 개인 블로그에서 iOS 26과 macOS 26부터 앱 사이 이전이 시스템 기능으로 들어왔고 1Password·Bitwarden·Dashlane 등이 지원한다고 적었습니다. 같은 글에서 맥에서는 1Password를 포함한 일부 앱이 아직 이 기능을 채택하지 않았다고도 밝혔습니다. 회사 입장이 아닌 개인 설명이라는 단서가 붙은 글입니다.

이식성과 별개로 일상에서 체감되는 불편도 나왔습니다. 한 댓글 작성자는 1Password에 저장한 패스키가 일부 사이트에서 사용자 확인을 요구해, 지문 인식이 없는 데스크톱에서는 로그인 비밀번호를 입력해야 한다고 적었습니다. 1Password 커뮤니티에도 맥 크롬 확장 프로그램에서 패스키를 쓸 때마다 맥 계정 비밀번호를 묻는다는 사용자 글이 있습니다. 노트북 덮개를 닫고 쓰는 경우라고 합니다.

1Password 직원은 9월 22일 커뮤니티 답변에서 확장 프로그램이 이제 사이트가 요청한 인증 수준을 확인해 필요할 때 추가 확인을 요구하며, 추가 확인이 필요한지는 1Password가 아니라 사이트가 정한다고 설명했습니다. 사용자들은 설정으로 예전의 한 번 클릭 방식으로 돌아갈 수 없다는 점에 불만을 남겼습니다.

사이트가 요청하는 값은 userVerification입니다. web.dev 문서는 기본값 preferred일 때는 사용자 확인을 건너뛸 수 있지만, required로 두면 반드시 확인을 거치고 Touch ID를 쓸 수 없는 맥(덮개를 닫은 경우 포함)은 시스템 비밀번호를 묻는다고 설명합니다.

출처: web.dev 'userVerification 심층 분석' 문서 갈무리

주의 이 사례는 증명(attestation) 논쟁과 별개의 요구입니다. 다만 사이트가 요구 수준을 올리면 관리자 앱이 그대로 따라간다는 점에서, 글쓴이가 말한 다이얼 걱정이 작은 규모로 보이는 장면이라고 제 판단으로는 봅니다. 위협이라기보다 번거로움이고, 요구 수준은 사이트마다 다릅니다.

5. 일반 사용자는 오늘 무엇을 하면 되나

상황별로 골라 보세요. 아래 세 줄 중 내 경우 하나만 읽어도 됩니다.

내 상황	이렇게 하세요
비밀번호를 여러 사이트에 돌려 쓰는 중이다	패스키를 켜는 쪽이 낫습니다. 글쓴이도 패스키가 비밀번호보다 훨씬 안전할 수 있다고 썼고, Helme는 TOTP보다 피싱에 강하다고 설명합니다
쓰는 소프트웨어를 내가 고르고 싶다	패스키를 켜되 옮길 수 있는 관리자를 고르고, 비밀번호나 인증 앱을 두 번째 길로 남겨 두세요
회사·학교 계정이다	조직이 승인한 보안 키를 요구할 수 있습니다. Helme는 이런 용도를 위한 기업용 증명이 따로 있다고 설명합니다. 관리자 안내를 따르세요

다음은 오늘 할 일 세 가지입니다. 구글 계정은 myaccount.google.com/signinoptions/passkeys에서, 네이버는 네이버ID, 보안설정, 패스키 관리에서 등록된 패스키를 볼 수 있습니다. 만드는 방법은 패스키 5분 설정 글에 있습니다.

재구성한 예시 화면 (확인된 이름은 주소와 '패스키 생성' 버튼뿐, 나머지는 회색 막대)

반응형

제 판단으로는 중요한 계정의 첫째는 메일입니다. 다른 계정의 비밀번호 재설정이 메일로 오기 때문입니다. 둘째는 휴대폰과 클라우드 계정, 셋째는 코드 저장소나 금융처럼 뚫리면 피해가 큰 계정입니다. 아래 메모를 복사해 빈칸을 채워 두세요.

내 계정 패스키 점검 메모(복사해서 쓰세요)

계정 1(메일):
- 패스키 저장 위치: 동기화됨 / 이 기기에만
- 두 번째 패스키 또는 복구 코드: 있음 / 없음
계정 2(휴대폰·클라우드):
- 패스키 저장 위치: 동기화됨 / 이 기기에만
- 두 번째 패스키 또는 복구 코드: 있음 / 없음
계정 3(코드 저장소·금융):
- 패스키 저장 위치: 동기화됨 / 이 기기에만
- 두 번째 패스키 또는 복구 코드: 있음 / 없음
복구 코드 보관 장소: 종이 / 오프라인 저장소

비밀번호 관리 앱을 고르는 기준은 비밀번호 관리 앱 글에, 계정이 털렸을 때의 대응은 금융권 해킹 대응 글에 정리해 두었습니다.

6. 서비스를 만드는 쪽이라면

웹 인증 명세의 기본값이 none이므로, 규정이나 계약 때문에 특정 하드웨어를 요구해야 하는 경우가 아니라면 증명을 요청하지 않는 것이 기본 방향입니다. Helme도 소비자 사이트에 대한 안내는 오래전부터 증명을 요청하지 않는 쪽이라고 썼습니다. 사용자가 패스키 하나를 잃어도 들어올 수 있도록 복구 경로를 반드시 남기세요. 사용자 확인을 required로 두면 일부 환경에서 비밀번호 입력이 따라붙으니, 정말 필요한 화면에만 쓰는 편이 마찰이 적습니다.

Q. 패스키가 정말 함정인가요?

지금 확인되는 사실만으로는 함정이라고 단정할 근거가 부족합니다. 증명의 기본값은 none이고 양쪽 글 모두 소비자 사이트가 대부분 증명을 요구하지 않는다고 인정합니다. 다만 앞으로도 그럴지는 확인할 수 없으니, 복구 수단과 옮길 수 있는 관리자를 준비해 두는 것이 안전합니다.

Q. 동기화되는 패스키는 안전하지 않나요?

안전하지 않다기보다 지켜야 할 곳이 바뀝니다. 제 판단으로는 패스키가 저장된 애플·구글·관리자 앱 계정 자체를 잘 지키는 것이 더 중요해집니다. 그 계정의 복구 수단을 먼저 챙기세요.

Q. TOTP로 돌아가야 하나요?

글쓴이는 TOTP를 권하지만 Helme는 코드를 가짜 사이트에 입력하는 피싱에 뚫린다고 반박합니다. 패스키를 쓰기 어려운 계정의 두 번째 길로는 좋은 선택입니다.

Q. 보안 키(YubiKey)는 어떤가요?

두 글 모두 보안 키 자체는 좋은 수단으로 봅니다. 다만 Helme는 보안 키가 제조사 증명서를 담고 있어 증명에서 자유롭지 않다고 설명합니다. 예비 열쇠를 하나 더 두면 분실에 대비할 수 있습니다.

Q. 지금 모든 계정을 바꿔야 하나요?

아니요. 중요한 계정 세 개부터 시작하세요. 패스키 저장 위치를 확인하고 복구 수단을 따로 두는 것까지가 오늘 할 일입니다.

3줄 핵심 요약

1. "패스키는 함정이다"라는 글은 증명(attestation)이 나중에 선택권을 줄일 수 있다고 주장했고, Helme는 동기화 패스키는 증명을 보내지 않는다며 반박했다.
2. 증명의 기본값은 none이고 소비자 사이트가 대부분 증명을 요구하지 않는다는 점은 양쪽이 일치한다. 앞으로 요구할지는 확인 불가다.
3. 오늘 할 일은 중요한 계정 세 개의 패스키 저장 위치를 확인하고, 복구 수단을 따로 두는 것이다.

마치며

보안 논쟁은 결론이 나지 않는 것이 보통입니다. 그래서 논쟁이 끝나기를 기다리기보다 내 계정이 어떤 상태인지부터 보는 편이 빠릅니다. 오늘 할 일은 하나입니다. 가장 중요한 계정 하나를 열어 등록된 패스키 목록을 보고, 그 패스키가 동기화되는지, 하나가 없어져도 들어갈 두 번째 길이 있는지 확인하세요. 그 확인이 끝나면 어느 쪽 주장이 앞으로 맞더라도 내 계정이 크게 흔들릴 일이 줄어듭니다.

NEXT READ

이어서 읽어 볼 글

01  비밀번호 대신 지문으로, 패스키 5분 설정 · 구글·네이버 패스키 만드는 법과 폰 바꿀 때 확인할 것

02  비밀번호 관리 앱, 폰 기본 기능이면 충분할까 · 애플 암호·구글·삼성 비교

03  금융권 연쇄 해킹, 내가 대상인지 확인하는 법 · 2차 피해 막는 오늘 할 일

#패스키,#패스키함정,#attestation,#WebAuthn,#ScottHelme,#계정보안,#비밀번호없는로그인,#HackerNews,#안전하게쓰기,#보안