Mozilla의 익명 자격 증명 구상: WEI를 거부하고 분산형 신원 구조를 제안하다

2026년 6월 현재, 봇 트래픽 폭증에 대응해 웹사이트들이 CAPTCHA와 로그인 요구를 강화하면서 정상 사용자도 접근 마찰과 프라이버시 저하를 함께 겪고 있다. Mozilla는 이런 흐름이 Web Environment Integrity(WEI) 같은 기기 신뢰 증명 방식으로 가면 통제권이 소수 OS·하드웨어 업체로 넘어간다고 보고, Cloudflare·다른 브라우저·웹 이해관계자들과 함께 익명 자격 증명(Anonymous Credentials) 설계를 시작했다.

왜 지금 다시 자격 증명인가

봇 남용이 늘면서 사이트 운영자는 봇과 사람을 가리기 위해 더 강한 신호를 원한다. 그 결과 CAPTCHA 빈도와 로그인 요구가 늘고, 정상 사용자가 불필요한 차단과 자기 식별 요구를 받는다. 캡차 한 번 푸는 데 24분이 평균 소요된다는 보고도 있다. 사용자는 프라이버시와 웹 접근 중 하나를 선택하라는 압박을 받게 됐다.

브라우저는 추적 방지를 강화한다. 서드파티 쿠키 제거, 브라우저 지문 제한, IP 주소 마스킹이 대표적이다. 그런데 이런 신호는 남용 방지에도 동시에 쓰였다. IP 주소와 브라우저 지문은 사용자 프로파일링 도구이지만, 사이트 입장에서 비정상 트래픽을 거르는 기준이기도 했다. 신호를 약화시키면 봇은 통과시키고 사람만 막힐 수 있다.

WEI가 만드는 함정

Web Environment Integrity 제안은 사용자 기기와 소프트웨어가 신뢰할 수 있음을 사이트에 증명하게 한다. Mozilla는 이 접근이 기기 통제권을 사용자에서 소수 OS·하드웨어 공급사로 옮긴다고 본다. 어떤 기기와 어떤 운영체제가 웹에 접근할 수 있는지 결정하는 권한이 한쪽에 모이는 구조다. 오픈 웹의 방향과는 반대다.

Apple의 Private Access Tokens도 Privacy Pass 기반의 단회용 토큰을 제공한다. 다만 Mozilla는 이 방식도 하드웨어 게이트키핑을 피하지 못하고, 통제권이 소수에게 집중될 수 있다는 한계를 지적한다. 더 많은 주체가 사용자를 보증하면서도 프라이버시를 유지하는 구조가 필요하다.

익명 자격 증명의 핵심 원리

Mozilla가 지향하는 구조의 핵심은 두 가지다. 첫째, 사용자의 신원과 보증 출처를 노출하지 않고도 합리적 이용 한도 안의 실제 사용자임을 증명할 수 있어야 한다. 둘째, 누구나 사용자를 보증할 수 있고, 각 사이트가 신뢰할 보증자를 스스로 선택할 수 있어야 한다.

익명 자격 증명은 발급자, 사용자, 검증자 사이의 관계를 분리한다. 자격 증명은 한 주체가 발급하고, 사용자는 제한된 횟수만 사이트에 제시한다. 사이트와 발급자는 서로의 사용 패턴을 추적하지 못한다. 자격 증명을 누가 발급했는지도 숨긴다. 신뢰된 발급자 집합 중 하나에서 나왔다는 사실만 증명된다.

| 구성 요소 | 역할 | 추적 가능 여부 |

|-----------|------|----------------|

| 발급자 (Issuer) | 사용자에게 자격 증명 발급 | 사이트에 제시 사실 추적 불가 |

| 사용자 (User) | 제한된 횟수 내 자격 증명 제시 | 신원 노출 없음 |

| 검증자 (Verifier, 사이트) | 자격 증명 유효성 확인 | 발급자 식별 불가 |

VPN 사례가 이 접근이 필요한 이유를 잘 보여준다. 많은 웹사이트가 정상 트래픽과 남용 트래픽이 섞여 있다는 이유로 VPN 트래픽을 통째로 차단한다. VPN 서비스가 가입자별로 보증할 수 있다면 사이트는 가입자 단위 속도 제한을 관리할 수 있다. 다만 보증 시스템이 VPN 사용자를 추적하게 만들면 VPN을 쓰는 목적이 훼손된다.

부트스트랩과 현실적 한계

익명 자격 증명 시스템도 부트스트랩 문제를 안는다. 처음 방문한 사용자에게는 발급자가 없다. Mozilla가 제시한 흐름은 이렇다. 사용자가 적절한 Anchor로부터 Endorsement를 전혀 갖고 있지 않으면 CAPTCHA, 계정 생성, 연합 로그인 같은 기존 메커니즘으로 Credential을 부트스트랩할 수 있다는 것이다.

다만 이 부분은 업계에서도 의문이 제기된다. CAPTCHA는 사용자가 지문 채집될 만큼 오래 머물게 하는 수단 말고는 잘 작동하지 않고, 계정 생성과 연합 로그인도 결국 다른 메커니즘으로 관문을 세워야 한다. 도서관 컴퓨터에서 은행에 로그인하려고 다른 웹사이트에 새 계정을 만들라고 요구하는 상황은 만들어지기 어렵다. 기존 메커니즘이 브라우저 지문 채집에 크게 의존하거나, Apple처럼 하드웨어 증명에 기대는 한계가 있다.

아래 의사코드는 익명 자격 증명 발급·제시·검증 흐름을 단순화한 예시다.

# 1. 발급: 사용자에게 단회용 자격 증명 N개 발급
issuance(user_id, anchor_endorsement):
    return blind_sign(user_id, anchor_endorsement)

# 2. 사용: 사이트에 제시 시마다 카운트 1 감소
present(site_request):
    if credential.count <= 0:
        raise "리필 필요"
    return unblind(credential, site_request)

# 3. 검증: 사이트는 발급자 추적 없이 유효성만 확인
verify(presented_credential):
    return verify_signature(presented_credential, public_params)

이 흐름은 한 사이트에서 제시한 사실이 다른 사이트나 발급자에 알려지지 않도록 설계돼 있다. 다중 제시 익명 자격 증명은 현재 Privacy Pass에 배포된 일회용 토큰보다 타이밍 부채널을 줄이는 데 도움이 된다.

누가 이 설계에 참여하는가

Mozilla는 Cloudflare, 다른 브라우저, 웹 이해관계자들과 함께 설계를 시작했다. 최종 목표는 CAPTCHA 감소, 불필요한 차단 감소, 자기 식별 요구 감소를 프라이버시 훼손 없이 달성하는 것이다. 자세한 접근은 Mozilla Hacks의 PACT: Anonymous Credentials for the Web에서 확인할 수 있다.

Lobste.rs 기술 커뮤니티에서도 비슷한 논점이 공유된다. Kagi가 Origin, Attester, Issuer를 모두 한꺼번에 운영해 Privacy Pass 아키텍처의 핵심 원칙을 어긴다는 우려가 나온다. 다만 RFC 9576 §4.6는 한 주체가 세 역할을 모두 맡는 방식을 명시적으로 지원한다. 기술적으로는 가능해도, 정책적으로 그 권한을 한 곳에 집중시키는 것은 다른 문제를 만든다.

정리

봇 시대에 프라이버시를 지키면서도 합리적 이용을 보장하는 길은 단일 기기 증명이 아니다. 사용자 신원과 보증 출처를 모두 숨기면서도 정당한 사용자임을 증명할 수 있는 분산형 구조가 필요하다. Mozilla가 Cloudflare와 함께 밀고 있는 익명 자격 증명은 그 후보 중 하나다. WEI가 닫힌 통제를 강화하는 방향이라면, 익명 자격 증명은 여러 보증자가 각자의 책임 영역 안에서 사용자를 보증하는 개방형 구조다.

핵심 요약은 세 가지다. 첫째, WEI는 기기 통제권이 소수 공급사에 모이는 위험이 있다. 둘째, 익명 자격 증명은 발급자·사용자·검증자 분리 구조로 추적을 끊는다. 셋째, 부트스트랩과 기존 메커니즘의 한계는 아직 풀리지 않은 숙제다. 2026년 6월 기준으로 표준화 작업이 진행 중이며, 웹 접근성과 프라이버시를 함께 살릴 수 있는지 여부가 향후 1~2년의 핵심 관전 포인트가 될 것이다.