Brave 브라우저의 패스키(2026년): 작동하는 것과 문제가 발생하는 것

1. 서론: 오늘날 Brave의 패스키 지원#

Brave의 패스키 지원은 코드 수준에서 Chromium과 유사하지만 사용자 경험은 몇 가지 중요한 부분에서 차이를 보입니다. 2026년 4월 기준으로 광범위한 brave/brave-browser 저장소에는 여전히 passkey 또는 WebAuthn과 일치하는 열린 이슈가 24개 있었던 반면, brave/brave-core에는 WebAuthn에 특화된 사용자 정의가 단 하나만 존재했습니다. 주요 문제 발생 지점은 확장 프로그램 가로채기, Windows Hello 프롬프트, Google 종속성이 제거된 기기에서의 Android 흐름입니다.

Brave는 업스트림 Chromium과 동일한 WebAuthn 코드 경로를 통해 패스키를 제공하며 자격 증명 저장을 운영 체제에 위임합니다. 이러한 아키텍처 덕분에 Brave는 이론적으로 표준을 준수하는 것처럼 보이지만, 실제 동작은 비밀번호 관리자 확장 프로그램, Windows Hello 및 Google Play 서비스와 같은 주변 시스템에 크게 의존합니다. 각 플랫폼별 동작을 개별적으로 이해할 수 있도록 아래 섹션에서는 이러한 실패 모드를 분리하여 설명합니다.

2. Brave의 WebAuthn 스택은 Chromium과 어떻게 다른가요?#

Brave의 WebAuthn 구현은 눈에 띄는 UI 텍스트 변경이 하나 있는 것을 제외하면 사실상 Chromium의 구현과 동일합니다. brave/brave-core 저장소에는 저장 대화 상자에서 "시크릿"을 "비공개"로 변경하는 문자열 재정의라는 단일 WebAuthn 관련 사용자 정의가 포함되어 있으며 WebAuthn 핵심 로직을 건드리는 C++ 패치는 없습니다. 즉, Brave는 Google이 2023년 6월의 Chromium 115 이후 제공한 Chromium 패스키 스택을 상속합니다.

이는 두 가지 이유로 중요합니다. 첫째, 일반적인 업스트림 병합을 통해 WebAuthn 수정 및 기능 추가가 브라우저 자체의 심하게 분기된 패스키 구현 없이 전달됩니다. brave/brave-core에서 이 유일한 문자열 재정의를 직접 확인할 수 있습니다. AAGUID 매핑에서 Chromium 브라우저 인증기 경로는 흔히 참조 목록에서 "Chromium Browser"로 라벨이 지정된 b5397666-4885-aa6b-cebf-e52262a439a2로 식별됩니다. 둘째, 보고된 대부분의 실패(확장 프로그램 가로채기, 자동 완성 충돌, Android의 Google Play 서비스 종속성)는 자동 완성, 권한, Shields 또는 지갑 통합과 같은 인접 시스템에서 발생합니다. 이들은 WebAuthn 흐름을 대체하는 것이 아니라 그 주변을 둘러싸고 있습니다.

3. macOS에서 생성한 패스키를 다른 Apple 기기의 Safari에서 사용할 수 있나요?#

네, 패스키가 iCloud 키체인에 저장된 경우에만 가능합니다. macOS에서 Brave는 Chromium의 WebAuthn 스택을 사용하며 새 패스키를 Apple 플랫폼 인증기 또는 생성 프롬프트에 표시되는 다른 저장 대상에 저장할 수 있습니다. iCloud 키체인에 저장된 패스키는 Apple ID를 통해 동기화되며, 동일한 Apple ID를 공유하는 Apple 기기의 Safari, Chrome 및 기타 WebAuthn 지원 브라우저에서 사용할 수 있게 됩니다.

macOS가 Brave의 iCloud 키체인에 저장된 패스키 접근 권한을 확인하면, 브라우저는 Safari에서 보는 것과 동일하게 동기화된 패스키를 사용할 수 있습니다. 이 권한 프롬프트는 Apple 기기에서 브라우저 간 이식성이 이론이 아닌 실제로 구현되는 실질적인 순간입니다.

macOS의 Brave는 기기 간 인증 흐름에도 참여할 수 있습니다. 사용자가 Bluetooth 접근을 허용하면 Brave는 CDA 중에 주변 기기를 검색하고 통신할 수 있어, 데스크톱 브라우저에서 모바일 기반 패스키 승인 절차를 매우 원활하게 진행할 수 있습니다.

브라우저 프로필 저장소나 로컬 전용 저장소에 저장된 패스키는 다른 Apple 기기의 Safari에서 자동으로 사용할 수 없습니다. OS 수준의 플랫폼 인증기 동기화와 브라우저 프로필 동기화가 서로 다른 규칙을 따르기 때문에 이러한 차이가 중요합니다. Brave는 Chrome의 Google 비밀번호 관리자 패스키 동기화를 제공하지 않으므로, iCloud 키체인 경로만이 Apple 기기에서 Apple 스타일의 교차 브라우저 이식성을 제공합니다.

4. Google Play 서비스가 없는 Android에서는 왜 패스키가 안정적으로 작동하지 않나요?#

Android의 자격 증명 관리자(Credential Manager)는 그 자체로 Google Play 서비스의 일부가 아닙니다. Android 14 이상에서 Chromium은 시스템의 자격 증명 관리자 경로를 사용할 수 있는 반면, 이전 Android 버전은 Google Play 서비스 기반의 FIDO2 계층에 크게 의존합니다. 실제로 Brave는 여전히 이슈 #45415에 문서화된 실패를 상속합니다. 필요한 Play 서비스 경로가 없는 GrapheneOS, CalyxOS, /e/OS 및 기타 Google 종속성이 제거된 Android 빌드에서는 패스키 등록 및 인증 시간이 초과될 수 있습니다. 2026년 4월 기준으로 이는 개인정보 보호를 중시하는 Android 사용자에게 여전히 해결되지 않은 호환성 격차로 남아 있습니다.

이 동작은 2025년 4월에 열려 1년 후에도 여전히 열려 있는 brave/brave-browser 이슈 #45415에 문서화되어 있습니다. Google의 자격 증명 관리자 문서는 이전 Android 버전에서 사용되는 선택적 Play 서비스 인증 종속성과 자격 증명 관리자 API를 구분하며, 더 광범위한 Android 가이드에서는 Android 14+가 활성화된 비밀번호 관리자와 작동할 수 있다고 언급합니다. 이 스레드에서는 동일한 실패 모드가 Chromium 기반 브라우저 전반에 영향을 미치는 반면, Firefox 기반 브라우저는 동일한 방식의 영향을 받지 않는다는 점도 지적합니다. 원래 보고자는 GrapheneOS가 자체 Chromium 포크인 Vanadium에서 해당 종속성을 패치했으므로 다운스트림 수정이 기술적으로 가능해 보이지만 아직 이루어지지 않았다고 밝혔습니다.

여러 사용자가 해당 스레드에서 이 동작을 독립적으로 확인했습니다. 2025년 12월의 한 깔끔한 테스트에서는 동일한 기기를 두 개의 프로필로 사용했습니다. Brave의 패스키는 Play 서비스가 활성화된 프로필에서만 작동한 반면, Vanadium과 Cromite는 둘 다에서 작동했습니다. 2026년 4월 현재, Brave 유지 관리자 중 누구도 해당 스레드에 응답하지 않았습니다. Google 종속성이 제거된 사용자가 불균형적으로 많이 포함된 Brave의 개인정보 보호 중심 Android 사용자층에게 이는 매우 가시적인 간극으로 남아 있습니다. Android의 Firefox는 자체 WebAuthn 스택을 사용하며 Play 서비스에 동일한 방식으로 의존하지 않습니다. 오늘날 실질적인 해결 방법은 Play 서비스가 없는 Android에서 패스키 흐름에 Firefox를 사용하거나, 호환 가능한 클라이언트가 있는 하드웨어 보안 키를 대안으로 사용하는 것입니다. 광범위한 Android 실패 환경에 대해서는 네이티브 앱 패스키 오류를 참조하세요. Google Play 서비스 및 자격 증명 관리자 세부 사항에 대해서는 Android 및 Google Play 서비스 패스키 오류 코드를 참조하세요.

5. 설정에서 비활성화했는데도 왜 Windows Hello 패스키 프롬프트가 나타나나요?#

Brave의 "패스키 저장 제안" 설정을 비활성화해도 WebAuthn 흐름 중 Windows Hello가 나타나는 것을 막을 수 없습니다. 사이트에서 WebAuthn을 호출하고 Windows Hello가 등록되면 Windows는 Hello를 플랫폼 인증기로 제공하며, Brave는 이를 차단할 수 있는 사용자 대면 제어 기능을 제공하지 않습니다. 2026년 1월 기준으로 기기 잠금 해제에는 Hello를 사용하지만 패스키에는 사용하고 싶지 않은 사용자들에게 Windows Hello 억제 문제는 여전히 미해결 상태로 남아 있습니다.

2026년 1월에 열린 이슈 #51858과 더 긴 커뮤니티 스레드 646042는 동일한 현상을 설명합니다. 원래 보고자는 레지스트리 편집, 그룹 정책, 플래그 전환 및 새로 설치를 시도했지만 어떤 것도 동작을 바꾸지 못했습니다.

스레드 646042에 설명된 기술적 이유는 간단합니다. 브라우저의 비밀번호 관리자 설정은 페이지와 OS 사이의 WebAuthn 경계가 아니라 브라우저 자체의 자동 완성 동작을 제어합니다. Windows는 Hello를 독립적으로 노출하며, 이 논의에서는 Windows Hello를 기기 잠금 해제용으로 유지하면서 WebAuthn 플랫폼 인증기로서는 완전히 차단하는 문서화되고 지원되는 구성을 찾지 못했습니다.

현재 이러한 프롬프트를 억제하는 유일하고 확실한 방법은 Windows Hello 등록 자체를 완전히 비활성화하는 것인데, 이는 대부분의 사람들이 기기를 잠금 해제하는 방식과 분명히 상충됩니다. Edge는 Windows의 자격 증명 관리 계층과 더 긴밀하게 통합되어 있고 Chromium 포크가 현재 제공하지 않는 제어 기능을 노출하기 때문에 다르게 동작합니다. Windows의 패스키 동작에 대한 자세한 내용은 Windows 11의 패스키를 참조하세요.

6. 패스키를 기본적으로 저장해야 할까요, 아니면 비밀번호 관리자에 저장해야 할까요?#

단일 생태계 내에서는 기본 패스키 저장이 가장 간단한 옵션인 반면, 비밀번호 관리자 확장 프로그램은 여전히 광범위하게 사용 가능한 유일한 크로스 플랫폼 동기화 계층입니다. iCloud 키체인은 Apple 기기 전반에서 잘 작동하고, Windows Hello는 Windows에서 작동하며, 1Password 또는 Bitwarden과 같은 확장 프로그램 기반 저장소는 사용자가 Windows, macOS, Linux 및 Android 전반에서 패스키를 일관되게 사용하고자 할 때 여전히 유일하게 현실적인 옵션입니다. 기기 간 인증(CDA 또는 QR 코드 및 Bluetooth를 통한 하이브리드 전송)은 로그인 시점에 기기를 연결할 수 있지만 자격 증명 자체를 동기화하거나 기본적으로 모든 곳에서 로컬로 사용할 수 있게 만들지는 않습니다. 여기서의 절충안은 신뢰성입니다. 기본 흐름은 더 단순하고 확장 프로그램 흐름은 이식성이 더 높으며 CDA는 저장 전략이라기보다는 폴백 경로로 가장 잘 이해됩니다.

이 결정은 주로 사용하는 플랫폼 수, 확장 프로그램 흐름에 대한 신뢰도, 그리고 자격 증명을 이미 어디에 보관하고 있는지의 세 가지 요소로 귀결됩니다. 주로 단일 OS 생태계(모두 Apple 또는 모두 Windows)에 머무르는 경우 기본 플랫폼 인증기 경로가 가장 깔끔한 옵션입니다. 이 설정에서 Brave는 Chrome이나 Safari와 거의 동일하게 동작합니다. Windows, macOS, Linux 및 Android 전반에서 패스키를 사용해야 하는 경우 1Password, Bitwarden, Dashlane 또는 Proton Pass와 같은 타사 비밀번호 관리자 확장 프로그램이 여전히 유일하게 널리 작동하는 동기화 계층입니다.

문제는 2024년 4월부터 기본 패스키 UI가 간헐적으로 확장 프로그램 주도 흐름을 가로챈다는 보고가 계속 접수되고 있다는 점입니다. 이슈 #37762의 사용자들은 Bitwarden 또는 1Password가 자격 증명을 소유해야 함에도 불구하고 OS 인증 대화 상자가 나타난다고 설명합니다. 2026년 3월까지, brave://flags/#web-authentication-new-passkey-ui를 비활성화하는 이전 우회 방법은 해당 플래그가 버전 146에서 제거되었기 때문에 더 이상 사용할 수 없게 되었습니다.

실제로 2026년에 개인정보 보호를 중시하는 많은 사용자들이 선택하는 패턴은 하이브리드 방식입니다. 단일 생태계 내에서의 일상적인 로그인에는 OS 플랫폼 인증기를 사용하고, 크로스 플랫폼 이식성이 중요한 곳에서는 비밀번호 관리자 확장 프로그램을 사용하며, 가치가 높은 계정을 위해 하드웨어 보안 키를 보관합니다.

7. 2026년에 사용자들이 보고하는 패스키의 문제점은 무엇인가요?#

2026년에 제기된 Brave의 열린 패스키 이슈는 세 가지 반복되는 주제, 즉 확장 프로그램 가로채기, Google 종속성이 제거된 기기에서의 Android 실패, 데스크톱 보안 키 문제에 집중되어 있습니다. 2026년 4월 기준으로 광범위한 저장소에는 여전히 webauthn 또는 passkey와 일치하는 열린 이슈가 24개 있었으며, 이는 마찰이 무작위가 아니라 특정 부분에 집중되어 있음을 시사합니다.

가장 번잡한 이슈 클러스터는 기본 패스키 UI가 1Password, Bitwarden 또는 Dashlane 프롬프트를 재정의할 수 있는 확장 프로그램 가로채기입니다. Google Play 서비스가 없는 Android 호환성이 두 번째 반복되는 문제이며, 데스크톱 보안 키 감지가 세 번째입니다. 여기서 가장 자주 참조되는 이슈 스레드는 #37762, #50561, #45415, #15650, #43043, #34441, #33237 및 #51858입니다. 활성 스레드는 많은 직접적인 인용 없이도 동일한 방향을 가리킵니다.

이러한 이슈 중 일부는 지난 90일 이내에 새로운 의견이 등록되었으며, 이는 과거의 호기심거리가 아닌 활발히 진행 중인 회귀 버그임을 의미합니다. 패스키 흐름을 구축하는 개발자의 관점은 명확합니다. Brave에서 확장 프로그램 주도 흐름을 명시적으로 테스트하고 WebAuthn 호출이 실패할 때 합리적인 대체 방안을 제공하십시오. 사용자를 위한 교훈 역시 실용적입니다. 중요한 계정에는 하드웨어 보안 키 또는 다른 복구 수단을 구성해 두십시오.

8. 결론#

Brave의 패스키 스토리는 코드 수준에서는 깔끔하지만 사용자 경험 수준에서는 복잡합니다. WebAuthn 경로는 사실상 Chromium의 경로이며, 이 구현이 업스트림에 얼마나 가깝게 유지되는지 확인하는 단일 문자열 재정의만 있습니다. Apple 플랫폼에서는 iCloud 키체인이 자격 증명을 소유하므로 패스키 이식성이 사용자가 예상하는 대로 정확하게 작동합니다. 실제 마찰은 다른 곳에서 발생합니다. 확장 프로그램 가로채기(#37762), Windows Hello 억제(#51858) 및 Android의 Google Play 서비스 종속성(#45415)입니다. 이러한 문제가 해결될 때까지 개발자는 Chrome과의 동등성을 가정하지 말고 Brave를 별도로 테스트해야 하며, 사용자는 중요한 계정에 대해 강력한 폴백(이상적으로는 하드웨어 보안 키)을 유지해야 합니다.

9. Corbado 소개#

Corbado는 소비자 로그인을 위한 패스키 인프라를 구축하고 패스키 및 인증 시스템을 대규모로 운영해야 하는 팀을 위한 패스키 인텔리전스 플랫폼을 제공합니다. 우리는 실제 배포, 직접적인 소스 검사 및 기본 사양의 면밀한 분석을 기반으로 여러 브라우저 및 운영 체제 전반에 걸친 WebAuthn 및 패스키 동작에 대한 기술 분석을 게시합니다. 질문이나 수정 사항은 언제나 환영합니다.

10. 자주 묻는 질문 (FAQ)#

10.1 macOS의 Brave에서 생성된 패스키를 다른 Apple 기기의 Safari에서 사용할 수 있나요?#

네, 하지만 Brave가 iCloud 키체인에 패스키를 저장하는 경우에만 가능합니다. macOS에서 Brave는 Chromium의 WebAuthn 스택을 사용하며 생성 프롬프트에 표시되는 다른 저장 대상이나 iCloud 키체인에 새 패스키를 저장할 수 있습니다. iCloud 키체인에 저장된 패스키는 Apple ID를 통해 동기화되며 동일한 Apple ID를 공유하는 Apple 기기의 Safari, Chrome 및 기타 브라우저에서 사용할 수 있습니다. 브라우저 프로필 저장소나 로컬 전용 저장소에 저장된 패스키는 다른 Apple 기기의 Safari에서 자동으로 사용할 수 없습니다.

10.2 Google Play 서비스가 없는 Android의 Brave에서 패스키가 실패하는 이유는 무엇인가요?#

Brave는 Google Play 서비스 없이 Android에서 실패할 수 있지만 그 이유는 "자격 증명 관리자가 Play 서비스의 일부이기 때문"보다 더 구체적입니다. Android의 자격 증명 관리자는 시스템 및 Jetpack API인 반면, 이전 Android 버전은 Google Play 서비스 기반의 FIDO2 계층에 크게 의존합니다. 실제로 Brave는 brave/brave-browser 이슈 #45415에 문서화된 실패를 여전히 상속합니다. 필요한 Play 서비스 경로가 없는 GrapheneOS, CalyxOS 또는 기타 Google 종속성이 제거된 Android 빌드에서는 패스키 대화 상자가 열리지 않고 등록 또는 인증 시간이 초과됩니다.

광범위한 Android 실패 환경에 대해서는 네이티브 앱 패스키 오류를 참조하세요. Google Play 서비스 및 자격 증명 관리자 세부 사항에 대해서는 Android 및 Google Play 서비스 패스키 오류 코드를 참조하세요.

10.3 Brave는 Chrome처럼 여러 기기 간에 패스키를 동기화하나요?#

아니요. Brave는 Google 비밀번호 관리자를 통한 Chrome의 브라우저 프로필 패스키 동기화에 상응하는 기능을 제공하지 않습니다. Brave에서 생성된 패스키는 Apple의 경우 iCloud 키체인, Windows의 경우 Windows Hello, Android의 경우 Android 자격 증명 관리자와 같은 기본 OS 플랫폼 인증기에 저장되며 해당 OS 계정을 통해서만 동기화됩니다. 일관된 기기 간 동기화를 원한다면 OS 공급업체나 타사 비밀번호 관리자 확장 프로그램에 의존해야 합니다.

10.4 설정에서 패스키 옵션을 비활성화했는데도 왜 Brave는 Windows Hello 패스키 프롬프트를 표시하나요?#

Brave의 brave://password-manager/settings 토글은 Brave 자체가 패스키 저장을 제안할지 여부만 제어합니다. Windows가 해당 페이지에 WebAuthn 플랫폼 인증기로 Windows Hello를 제공하는 것을 막지는 않습니다. 사이트가 WebAuthn을 호출하면 Windows가 Hello를 표시하며 Brave에는 OS 대화 상자를 억제하는 브라우저 내 스위치가 없습니다. 이 동작은 brave/brave-browser 이슈 #51858에서 추적됩니다.

10.5 패스키를 Brave의 기본 흐름에 저장해야 할까요, 아니면 내 비밀번호 관리자에 저장해야 할까요?#

단일 생태계 내에 머무르고 움직이는 부분을 최소화하려면 플랫폼을 통한 Brave의 기본 OS 흐름(iCloud 키체인 또는 Google 비밀번호 관리자)을 사용하세요. 패스키가 Windows, macOS, Linux 및 Android 전반에서 일관되게 따라오게 하려면 1Password 또는 Bitwarden과 같은 타사 비밀번호 관리자 확장 프로그램을 사용하거나 이미 거기에 비밀 데이터를 보관하고 있는 경우 사용하십시오. 2024년 이후 Brave의 기본 UI가 확장 프로그램 패스키 흐름을 반복적으로 가로채고 있으므로 확장 프로그램이 여전히 프롬프트를 소유하고 있는지 확인하는 것이 좋습니다.

10.6 Brave 패스키 동작에 대해 brave/brave-browser 저장소에는 현재 얼마나 많은 패스키 및 WebAuthn 이슈가 열려 있나요?#

2026년 4월 기준으로 brave/brave-browser에는 passkey 또는 WebAuthn 검색과 일치하는 24개의 열린 이슈가 있었습니다. 패스키 태그가 지정된 열린 이슈는 2022~2023년에 연간 약 2개에서 2025년에는 6개로 증가했습니다. Brave의 주요 이슈 주제는 데스크톱에서의 확장 프로그램 가로채기, Windows Hello 억제 및 Android Google Play 서비스 종속성입니다.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Authentication Intelligence Platform입니다. IDP 로그와 일반 analytics 도구가 보여주지 못하는 것을 볼 수 있게 해드립니다: 어떤 디바이스, OS 버전, 브라우저, credential manager가 passkey를 지원하는지, 왜 등록이 로그인으로 이어지지 않는지, WebAuthn 플로우가 어디서 실패하는지, OS나 브라우저 업데이트가 언제 조용히 로그인을 망가뜨리는지 — Okta, Auth0, Ping, Cognito 또는 자체 IDP를 교체하지 않고도 전부 파악할 수 있습니다. 두 가지 제품: Corbado Observe는 passkey 및 다른 모든 로그인 방식에 대한 observability를 더합니다. Corbado Connect는 analytics가 내장된 managed passkey를 제공합니다 (기존 IDP와 함께). VicRoads는 Corbado로 500만+ 사용자에게 passkey를 운영하고 있습니다 (passkey 활성화율 +80%). Passkey 전문가와 상담하기 →