2026년 7월 27일, Cloudflare Research 팀은 pvcli라는 개인 네트워크 프로토콜을 위한 콘솔 클라이언트를 공개했습니다. 외관상으로는 "OHTTP를 위한 curl"과 같으며, 동일한 명령 스타일을 가지고 있지만, 일반적인 요청 대신 이 도구는 서버 수신자가 귀하의 IP를 볼 수 없고 중간 노드가 요청 내용을 볼 수 없는 삼자 암호화 교환을 수집합니다. 코드는 Apache 2.0 라이센스 하에 있으며, MASQUE 및 Privacy Pass 지원이 계획되어 있습니다.
프록시 산업에 있어 이것은 "또 다른 GitHub 릴리스"가 아닙니다. 이는 Apple, Google, Mozilla 및 Meta가 수년간 조용히 도입해온 프로토콜 스택을 손으로 만져볼 수 있는 첫 번째 편리한 방법이며, 이는 정기적으로 "프록시의 대체"로 소개됩니다. 실제로 무엇이 있는지 살펴보고, 사람들이 거주형 및 모바일 프록시를 구매하는 이유를 해결할 수 있는지에 대한 주요 질문에 정직하게 답해봅시다. 스포일러: 아닙니다. 그 이유는 "아직 성장하지 않았다"가 아닌 아키텍처적 문제입니다.
무엇을 공개했는가: pvcli의 세부사항
pvcli는 Rust로 작성되었으며 cargo install --git 명령어로 한 번에 설치할 수 있습니다. README에 따르면, 이는 GET 및 POST, TLS 1.3 및 HPKE 암호화(RFC 9180)를 지원하는 HTTP/2 및 HTTP/3 클라이언트입니다. 기본 모드는 Oblivious HTTP입니다: 클라이언트는 첫 번째 홉(릴레이)과 게이트웨이를 지정하고, 도구는 모든 암호화 및 이진 HTTP 포장을 자동으로 수행합니다.
- 일반 요청:
pvcli https://example.com/cdn-cgi/trace,--http3플래그와 함께 — QUIC 위에서. - OHTTP 모드:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - 전통적인 프록시:
pvcli -x https://proxy.example.com https://target.example.com— 즉, HTTP CONNECT는 여전히 존재합니다.
저자들은 소프트웨어가 실험적이며 감사(audit)를 통과하지 않았고, 포스트 양자 HPKE는 아직 지원되지 않으며, 일부 사양은 아직 RFC가 되지 않았음을 정직하게 경고합니다. 이는 디버깅 도구이지 프로덕션을 위한 완제품이 아닙니다. 그래서 더욱 흥미롭습니다: 이전에는 다른 사람의 OHTTP 통합을 확인하려면 Swift 또는 Rust로 자체 코드를 작성해야 했습니다.
Oblivious HTTP: 나누고 지배하지 말라
OHTTP는 2024년 1월 12일 RFC 9458로 표준화되었습니다. 아이디어는 우아할 정도로 간단합니다: "당신이 누구인지"와 "당신이 요청하는 것이 무엇인지"에 대한 정보를 두 개의 독립적인 참가자 간에 분산시키는 것입니다.
- 클라이언트는 게이트웨이의 공개 키로 임시 키를 사용하여 요청을 암호화합니다 — 각 요청마다 새로운 키 쌍이 생성됩니다.
- 릴레이는 귀하의 IP 주소를 볼 수 있지만 암호문을 받습니다: 그는 물리적으로 귀하가 어디에 대해 무엇을 요청하는지 읽을 수 없습니다.
- 게이트웨이는 요청을 복호화하고 원본으로 전달하지만, 귀하의 IP 대신 릴레이의 IP를 봅니다.
핵심 보장은 unlinkability입니다: 원본은 두 개의 요청을 서로 연결할 수 없습니다. 핵심 제한 사항은 신뢰입니다: 릴레이와 게이트웨이가 공모하거나 동일한 운영자에게 속한다면 모든 개인 정보 보호가 무너집니다. NCC Group은 감사에서 키 회전, 속도 제한 및 네트워크 지연에 대한 허용과 같은 실제적인 문제를 지적했습니다.
프로덕션에서 프로토콜은 이미 작동하고 있으며, 목록은 인상적입니다:
- Apple — Apple Intelligence 및 "사진"의 Enhanced Visual Search 요청을 위한 Private Cloud Compute; Swift에서 OHTTP 지원은 2024년 8월에 추가되었습니다.
- Google — Privacy Sandbox, k-익명성 및 IP를 공개하지 않고 Safe Browsing에서 URL 검증; 릴레이 역할은 Fastly가 수행합니다.
- Mozilla — 사용자 식별 없이 Firefox의 성능 메트릭 수집.
- Meta — WhatsApp의 Meta AI를 위한 Private Processing(2025), 역시 Fastly를 통해.
- Flo — 2022년부터 Cloudflare Privacy Gateway 기반의 주기 추적기 "익명 모드".
Cloudflare와 Fastly 외에도 Internet Security Research Group이 Divvi Up 서비스에서 게이트웨이를 운영합니다. 즉, 인프라는 실제로 존재하며, 단순한 문서가 아닙니다.
MASQUE: 이제는 프록시와 비슷해 보인다
Cloudflare가 pvcli에 추가할 것이라고 약속한 스택의 두 번째 부분은 MASQUE입니다. 이는 HTTP 내부에서 프록시를 전송하는 IETF 작업 그룹의 프로토콜 집합입니다:
- RFC 9298 (2022년 8월), CONNECT-UDP — HTTP 내부에서 UDP 프록시; 클라이언트는
:protocol: connect-udp를 포함한 확장된 CONNECT를 보내고, 프록시는 QUIC DATAGRAM 프레임을 UDP 패킷으로 변환합니다. - RFC 9484 (2023년 10월), CONNECT-IP — 완전한 IP 수준: 원시 IP 패킷이 HTTP Datagrams로 포장되고, HTTP/3 서버는 TCP, UDP 및 ICMP를 동시에 처리할 수 있는 VPN 게이트웨이로 변환됩니다.
두 사양 모두 QUIC 및 UDP가 네트워크 수준에서 차단된 경우 HTTP/2로의 폴백을 요구합니다 — 이는 기업 및 제공업체 네트워크에서 정기적으로 발생합니다. 본질적으로 MASQUE는 트래픽이 두 개의 독립적인 홉을 통과하는 현대의 "개인 릴레이"를 구축하는 기반입니다: 첫 번째는 귀하를 알고 있지만 수신자를 알지 못하고, 두 번째는 그 반대입니다.
Privacy Pass: 캡차 대신 익명 통행증
세 번째 요소는 Privacy Pass로, 세 개의 문서로 표준화되었습니다: RFC 9576 (아키텍처), RFC 9577 (HTTP 인증 스킴) 및 RFC 9578 (비공식 및 공식적으로 검증 가능한 토큰 발행 프로토콜). 논리는 두 단계로 구성됩니다: 발급 — 한 번 사람이나 신뢰할 수 있는 클라이언트임을 증명하고, 맹목적으로 서명된 토큰 묶음을 받습니다; 교환 — 사이트에 토큰을 제시하면 캡차 없이 통과하게 되며, 발급 시점과 토큰을 연결할 수 없습니다.
이는 "좋은 봇에게 합법적인 접근을 허용하자"는 아이디어의 기초가 되는 메커니즘입니다 — 이는 서명된 에이전트 및 Web Bot Auth의 기초이기도 합니다. 트렌드는 동일합니다: 네트워크 정체성(IP)과 접근 권한(토큰, 서명)을 분리하는 것입니다.
이것이 프록시를 대체할 것인가? 환상 없는 분석
이 스택에서 뉴스가 나올 때마다 "이제 OHTTP가 있으니 프록시는 필요 없다"는 주장이 떠오릅니다. 문제는 개인 프로토콜과 프록시가 서로 다른 문제를 해결하고 있으며, 하나를 다른 것으로 대체하는 것은 네 가지 요인에서 무너진다는 것입니다.
1. OHTTP는 사이트가 이를 배포한 경우에만 작동합니다
이는 인터넷 위의 오버레이가 아니라 수신자의 옵트인입니다: 게이트웨이는 원본(또는 그의 계약자)을 설정하고 구성합니다. 임의의 마켓플레이스나 소셜 네트워크에 "OHTTP를 통해 들어갈 수"는 없습니다 — 거기에는 게이트웨이가 없습니다. 나열된 모든 구현은 자신의 사용자 IP를 자신의 백엔드로부터 숨기는 회사들입니다. 외부 사이트에서 데이터를 수집하기 위한 메커니즘은 원칙적으로 적용할 수 없습니다.
2. 출구 지점은 데이터 센터이며, 모두가 이를 알고 있습니다
게이트웨이가 있더라도, 외부 요청은 Cloudflare, Fastly 또는 ISRG의 주소에서 나옵니다. 이는 공개 범위를 가진 호스팅 제공자의 알려진 ASN입니다. 안티봇 시스템은 네트워크 유형에 따라 IP를 평가하며, 클라우드 릴레이의 주소는 다른 데이터 센터 주소와 동일한 점수를 받습니다. 원본으로부터 개인 정보를 얻었지만, "일반 가정 사용자처럼 보이기"는 아닙니다. 이는 실제 제공자의 주소와 모바일 CGNAT 네트워크의 풀을 가진 거주형 프록시가 담당합니다.
3. 지리적 위치, 회전 및 스티키 세션이 없습니다
프록시 인프라는 개인 프로토콜이 설계상으로 제공하지 않는 것을 제공합니다: 국가, 지역 및 제공자 선택, 관리되는 IP 회전, 필요한 시간 동안의 스티키 세션, 다양한 계정에 대한 다양한 풀. OHTTP는 "독일에서 특정 ISP 네트워크를 통해 나가기를 선택"할 수 없습니다 — 귀하의 재량에 따라 출구 지점의 개념이 전혀 없습니다. 지역별 가격 확인이나 지리적 제한 콘텐츠 작업을 위한 것은 피할 수 없는 차이입니다.
4. 신뢰 모델이 다릅니다
OHTTP는 릴레이와 게이트웨이가 독립적일 경우 특정 원본에 대한 요청 연결을 방지합니다. 프록시는 사이트가 귀하의 실제 주소와 네트워크 프로필을 볼 수 없도록 보호합니다. 첫 번째는 사용자 요청 및 텔레메트리의 개인 정보 보호에 관한 것이고, 두 번째는 접근 및 부하 분산에 관한 것입니다. 두 가지 작업은 부분적으로만 겹치며, 하나에서 다른 것으로의 "이전"은 불가능합니다.
실제로 유용한 것은 무엇인가
- 귀하가 텔레메트리 또는 API 요청을 보내는 제품 개발자라면 — Privacy Gateway 또는 Divvi Up을 통한 OHTTP는 수집되는 개인 데이터의 양을 실제로 줄이고 법률가와의 대화를 간소화합니다. 이제 pvcli를 사용하여 클라이언트를 처음부터 작성하지 않고도 이를 디버깅할 수 있습니다.
- 공공 데이터를 수집하는 경우 — 스택은 아무것도 변경하지 않습니다: 출구 지점과 그 평판은 여전히 귀하의 과제입니다. 대량 파싱의 경우 여전히 작업하는 조합은 데이터 센터 프록시와 충성도 높은 플랫폼에서의 회전 및 심각한 안티봇이 활성화된 곳에서의 거주형 프록시입니다.
- 여러 계정으로 작업하는 경우 — 개인 프로토콜은 격리 문제를 해결하지 않습니다: 플랫폼에서의 세션은 IP뿐만 아니라 브라우저 지문 및 행동에 따라 연결됩니다. IP 레이어와 정체성 레이어 간의 차이는 프록시와 VPN의 차이에 대한 자료에서 설명되었습니다.
- 합법적으로 접근을 자동화하는 경우 — 여기서는 주의 깊게 살펴봐야 합니다. Privacy Pass와 서명된 에이전트는 봇에게 "사람처럼 보이기"가 아닌 제시된 토큰에 따라 접근을 허용하는 모델로 나아가고 있습니다. 이는 뉴스의 가장 유망한 부분입니다.
결론
pvcli의 출시는 성숙도의 좋은 지표입니다: 개인 프로토콜이 연구 프리프린트 단계를 벗어나 디버깅 도구를 갖추게 되었습니다. OHTTP, MASQUE 및 Privacy Pass는 실제로 인터넷이 클라이언트 주소를 처리하는 방식을 재편하고 있으며, 몇 년 후에는 "사이트가 귀하의 IP를 본다"는 것이 사용자 트래픽에 대한 공리로 남지 않을 것입니다.
하지만 데이터를 수집하거나 여러 계정을 관리하거나 지역별 결과를 확인하는 사람들에게는 아무것도 변경되지 않습니다. 개인 프로토콜은 귀하를 초대받은 곳에서 숨깁니다. 프록시는 초대장을 받지 않는 곳에서 필요하며, 여전히 네트워크 유형, 주소 평판 및 풀의 품질이 모든 것을 결정합니다. Privacy Pass를 봇을 위한 미래의 합법적인 경로로 주의 깊게 지켜보는 것이 합리적이며, 동시에 실제를 위한 정상적인 프록시 인프라를 유지하는 것이 중요합니다.
```