Signal의 번호 없는 등록, 전화번호 인증을 영지식 증명으로 대체

Signal의 번호 없는 등록은 수년간 전화번호 인증을 의무화해 온 끝에, 오랜 사용자 요청에서 실제 작동하는 Android 코드로 옮겨갔다. 최근 커밋에는 번호 없는 계정 생성, 로그인, 결제 처리, 복구 및 종단 간 테스트가 추가됐다. 이 코드는 등록 과정에서 기본 구매 기록을 노출하지 않고도 권한을 증명할 수 있는 영지식 자격 증명도 사용한다.

이 조합이 중요한 이유는 전화번호를 제거하면 악용 방지라는 어려운 문제가 생기기 때문이다. 전화번호가 실제 신원을 보장한 적은 없지만, 일회용 계정을 만드는 사람들이 번호를 얻으려면 어느 정도의 마찰을 감수해야 한다. Signal은 결과적으로 생성되는 계정과 결제를 분리하면서, 이 불완전한 장벽을 유료 자격 증명으로 대체할 준비를 하는 것으로 보인다.

이는 단순한 프라이버시 설정 이상의 변화다. Signal은 2024년에 사용자 이름을 도입했지만, 사용자는 여전히 등록을 위해 전화번호가 필요했다. SimpleX와 같은 서비스는 식별자 없는 커뮤니케이션을 설계의 핵심으로 삼아 왔다. Signal은 이제 주류 암호화 메신저가 구매를 지속적인 추적 수단으로 만들지 않으면서 전화번호를 제거할 수 있는지 시험하고 있다.

Signal의 번호 없는 등록, 이제 Android 코드에서 확인 가능

Signal은 공개 출시를 발표하지 않았지만, Android 리포지토리에는 고립된 실험이 아닌 통합된 번호 없는 등록 흐름이 나타나 있다.

2026년 9월 2일, Signal 개발자들은 “번호 없는 계정” 등록 작업을 공개 Android 리포지토리에 커밋했다. 이 커밋은 49개 파일을 변경하며 871줄을 추가하고 359줄을 제거했다. 범위는 등록 화면, 계정 상태, 네트워크 요청, 복구, 테스트 및 사용자 이름 생성에 걸쳐 있었다.

코드 변경으로 등록 시스템은 전화번호를 선택 사항으로 처리할 수 있게 됐다. 또한 애플리케이션은 기본 기기에 내부적으로 PNI로 알려진 전화번호 식별자가 없는 계정을 인식할 수 있다. 이러한 구분은 최초 가입 화면을 넘어선다.

Signal 애플리케이션은 이전까지 기본 계정에 국제 전화번호 표기 형식인 E.164 전화번호가 있다고 가정했다. 번호 없는 지원은 등록, 복원, 연락처 검색 또는 계정 상태가 번호에 의존하는 모든 지점에서 이러한 가정을 다시 검토하도록 클라이언트에 요구한다.

같은 9월 2일 커밋 그룹은 번호 없는 계정에 적용되지 않는 설정도 숨긴다. 여기에는 전화번호 검색 가능성 제어와 일부 PIN 알림이 포함된다. 다른 변경 사항은 특별한 번호 없는 국가 코드 구성과 기존 번호 없는 계정의 로그인 지원을 추가한다.

별도 커밋에서는 Signal의 zkgroup 암호화 라이브러리에서 새 자격 증명을 도입했다. 이 라이브러리는 프라이버시를 보존하는 자격 증명과 그룹 작업을 지원한다. 등록 클라이언트는 전화번호를 제공하지 않고 계정을 만들 때 이러한 자격 증명을 제시할 수 있다.

Signal은 9월 9일 결제 처리와 추가적인 번호 없는 계정 수정 사항을 내놓으며 이 작업을 이어갔다. 추가 내용은 백업 온보딩, 계정 복원, 연락처 검색, 다중 기기 동기화 및 등록 잠금 오류를 다룬다. Signal은 번호 없는 흐름을 다루는 619줄의 “등록 테스트”도 추가했다.

이처럼 넓은 범위는 중요하다. 프로토타입은 새 등록 화면을 표시하는 데서 멈출 수 있다. 반면 이 커밋들은 정체성 시스템 변경이 실제 사용자에게 도달하지 못하게 하는, 덜 눈에 띄는 의존성을 다룬다.

리포지토리에 따르면 이 기능은 여전히 내부 빌드에서 제한돼 있다. 공개 Android 사용자는 병합된 코드를 즉각적인 제공으로 해석해서는 안 된다. Signal은 출시일, 지원 국가 목록, 결제 정책 또는 최종 사용자 문서를 공개하지 않았다.

따라서 증거가 뒷받침하는 결론은 제한적이다. Signal은 결제 및 프라이버시 메커니즘을 포함한 번호 없는 계정을 적극적으로 구현하고 테스트하고 있다. 그러나 Signal의 번호 없는 등록이 언제 일반 기능이 될지는 아직 확인되지 않았다.

이 구분은 기존 사용자에게 특히 중요하다. 눈에 보이는 코드는 번호 없는 계정을 생성하고 복원하지만, 이미 등록된 사용자가 연결된 번호를 제거할 수 있다고 명확히 약속하지는 않는다. 한 커뮤니티 참여자는 기존 계정의 연결을 해제할 수 있는지 물었고, 다른 기여자는 공개된 변경 사항으로는 그 옵션이 확인되지 않는다고 말했다.

따라서 첫 출시에서는 기존 계정을 전환하지 않고 새 번호 없는 계정만 지원할 수 있다. 또한 플랫폼, 지역 또는 테스트 코호트에 따라 기능을 제한할 수도 있다. Signal이 설계를 공개하기 전까지 이러한 질문은 열려 있다.

Signal이 전화번호 인증의 대안을 필요로 하는 이유

전화번호를 제거하면 Signal이 자동화된 등록과 일회용 계정 악용을 늦추는 데 사용해 온 희소 자원도 사라진다.

전화번호는 메시징 시스템에서 여러 역할을 수행한다. 사용자가 연락처를 찾는 데 도움을 주고, 익숙한 복구 채널을 제공하며, 사람들이 이미 이해하는 계정 식별자를 만든다. 또한 공격자가 수백 또는 수천 건의 등록을 시도할 때 비용을 발생시킨다.

이러한 이점 중 어느 것도 전화번호를 기본적으로 비공개이거나 안전하게 만들지는 않는다. 전화번호는 법적 신원, 청구 기록, 고용주 및 위치 이력과 연결되는 경우가 많다. 사람들은 번호 재할당, 계정 해지 또는 SIM 스와핑 공격으로 번호를 잃을 수 있다.

Signal은 2024년에 사용자 이름과 새로운 프라이버시 제어 기능을 도입하며 개인 간 노출을 줄였다. 공식 “사용자 이름 설계”를 통해 사람들은 번호를 공유하지 않고 대화를 시작할 수 있다. 정확한 사용자 이름이 필요하며, Signal은 검색 가능한 공개 디렉터리를 제공하지 않는다.

그러나 사용자 이름은 등록이 아니라 검색 방식을 바꿨다. Signal의 현재 지원 문서는 여전히 서비스가 기존 전화번호를 사용한다고 명시한다. 일반적인 계정 생성 과정에서 번호는 SMS 메시지 또는 전화 통화를 받아야 한다.

이 간극은 수년간 프라이버시를 중시하는 사용자들을 좌절시켜 왔다. 기자는 개인 번호를 노출하지 않고 Signal 사용자 이름을 공개하고 싶을 수 있다. 활동가는 다른 이동통신 회선을 구매하지 않고 별도의 정체성이 필요할 수 있다. 태블릿 사용자는 아예 사용할 수 있는 번호가 없을 수도 있다.

전화 기록이 고용주, 통신 회사 또는 정부에 접근 가능한 사람들에게는 위험이 더 커진다. 종단 간 암호화는 전송 중인 메시지 내용을 보호한다. 하지만 전화번호를 취득하고 유지하는 동안 생성된 모든 외부 기록을 지우지는 않는다.

그렇다고 단순히 번호 요구 사항을 삭제하면 계정 생성이 저렴하고 반복 가능해진다. 스패머는 차단된 뒤에도 사용자 이름을 바꿔가며 활동할 수 있다. 사기 운영자는 계정 재고를 다시 구축할 수 있고, 자동화 시스템은 메시지 요청이나 인프라를 압도할 수 있다.

Signal은 이미 원치 않는 발신자가 할 수 있는 일을 제한하지만, 콘텐츠 암호화는 서버 측 검토를 제한한다. 이 서비스는 암호화되지 않은 플랫폼처럼 모든 대화를 검사하고 악성 텍스트를 분류할 수 없다. 따라서 등록 과정의 마찰은 더 큰 비중을 갖는다.

한 커뮤니티 참여자는 또 다른 전환 문제를 지적했다. 사용자가 하나의 번호로 등록한 뒤 즉시 이를 분리할 수 있다면, 하나의 번호로 많은 무료 계정을 만들 수 있다. 대기 기간은 이 순환을 늦추겠지만, 의지가 있는 공격자는 기다리거나 활동을 분산할 수 있다.

결제 요구 사항은 다른 희소 자원을 제공한다. 각 등록자에게 유효한 전화번호 대신 유효한 구매를 확보하도록 요구한다. 이 비용은 Signal이 전화번호에 연결된 신원을 보관하지 않고도 대량 생성을 억제할 수 있게 한다.

이 접근법은 압박을 없애기보다 옮긴다. 결제 시스템은 자체적인 기록, 지역적 제한 및 접근 장벽을 만든다. 지원되는 결제 수단이 없는 사람은 번호 없는 등록이 SMS 인증보다 접근하기 어렵다고 느낄 수 있다.

스토어 운영자도 구매가 발생했다는 사실을 알 수 있다. Google Play, 금융 중개업체 또는 다른 결제 제공업체는 해당 거래를 기존 계정과 연결할 수 있다. 핵심 프라이버시 질문은 Signal이 어떤 최종 메시징 계정이 구매했는지 알지 못한 채 구매를 사용할 수 있는지다.

바로 이 지점에서 영지식 자격 증명이 설계에 들어온다. 이는 원래 함께 도달했을 두 가지 진술, 즉 유효한 구매가 존재한다는 점과 바로 이 Signal 계정이 그 구매를 했다는 점을 분리하는 것을 목표로 한다.

영지식 자격 증명이 결제 연결을 끊는 방식

제안된 메커니즘은 Signal이 결제를 새 계정에 직접 연결하는 재사용 가능한 기록을 피하면서 자격을 검증할 수 있게 한다.

영지식 증명은 한 당사자가 그 진술의 배후에 있는 비밀을 공개하지 않고도 진술이 참임을 입증하게 한다. 여기서 관련 진술은 사용자의 이름이나 금융 신원이 아니다. 등록자가 승인된 영수증 자격 증명을 보유하고 있다는 점이다.

확인 가능한 Android 코드는 무작위화된 영수증 요청을 생성해 결제 관련 등록 엔드포인트로 보낸다. 구매가 검증된 후 클라이언트는 자격 증명 응답을 받는다. 그런 다음 클라이언트는 해당 응답을 확인하고 계정 등록을 위한 자격 증명 제시를 구성한다.

이 과정은 블라인드 자격 증명 개념을 사용한다. 블라인드 자격 증명은 발급자가 나중에 인식할 수 있는 형태로 그 값을 알지 못한 채 숨겨진 값을 승인할 수 있게 한다. 사용자는 이후 발급과 사용 사이의 연결 가능성을 제한하면서 소유를 증명할 수 있다.

실질적으로 Signal의 결제 서비스는 구매 토큰을 검증하고 암호학적 영수증을 발급할 수 있다. 등록 서비스는 나중에 해당 영수증 제시를 검증할 수 있다. 올바르게 설계된 프로토콜은 서버가 제시를 이전 발급 기록과 대조하지 못하게 한다.

9월 코드에서는 여러 개의 개별 객체를 통해 이러한 분리가 드러난다. 여기에는 영수증 일련번호, 요청 컨텍스트, 자격 증명 응답, 자격 증명 및 자격 증명 제시가 포함된다. 클라이언트가 요청 컨텍스트를 생성할 때 무작위성이 도입된다.

결제 구현은 또한 구매를 구독이 아닌 재사용 가능한 제품 카테고리로 취급한다. 확인 가능한 “결제 흐름”은 동일한 일회성 항목을 반복 구매하는 방식을 지원한다. 또 다른 결제를 시작하기 전에 소비되지 않은 구매가 있는지 확인한다.

성공적으로 사용된 뒤 앱은 구매 토큰을 소비할 수 있다. 이렇게 하면 동일한 토큰이 반복 등록을 승인하지 못하도록 막는 동시에 스토어 항목을 다시 구매할 수 있게 된다. 이 세부 사항은 스팸 방지 목표를 자격 증명 설계와 연결한다.

따라서 시스템에는 두 가지 보호 장치가 동시에 필요하다. 자격 증명은 등록자를 보호할 만큼 충분히 연결 불가능해야 하며, 사용 규칙은 중복 사용을 막아야 한다. 어느 한쪽의 취약점도 기능을 훼손할 수 있다.

결제와 등록 기록이 직접 연결된다면, 번호 없는 가입은 통신 식별자를 금융 식별자로 바꾸는 것에 불과하다. 이는 편의성을 제공할 수는 있지만, 이 기능이 시사하는 프라이버시 개선을 제공하지는 못할 것이다.

자격 증명이 복사되거나 재사용될 수 있다면 공격자는 한 번 구매하고 많은 계정을 만들 수 있다. 그러면 Signal은 결제를 도입한 동기인 악용 저항성을 잃게 된다. 코드의 영수증 일련번호, 검증 단계 및 소비 절차는 이러한 결과를 막도록 설계된 것으로 보인다.

Signal은 이미 다른 영역에서 관련 암호학적 개념을 적용하고 있다. Signal의 비공개 그룹 시스템은 일반적인 운영 환경에서 서버가 그룹 구성원을 알지 못한 채 그룹 작업을 강제할 수 있도록 익명 자격 증명을 사용한다. 기부 배지 역시 영수증 자격 증명을 사용해 결제와 프로필 배지를 분리한다.

이러한 이력은 구현의 새로움은 낮추지만, 배포 위험을 없애지는 않는다. 검토된 기본 요소를 재사용하는 편이 새로운 것을 발명하는 것보다 안전하다. 하지만 등록 과정에는 여전히 새로운 엔드포인트, 상태 전이, 스토어 의존성, 실패 사례가 추가된다.

공개된 소스 코드만으로는 프로덕션 서버가 무엇을 보관하는지 증명할 수 없다. 클라이언트 측 암호화는 유효한 프로토콜이 드러내는 정보를 제한할 수 있다. 연구자들이 전체 주장을 평가하려면 최종 서버 구현, 프로토콜 명세, 보존 정책, 배포 동작이 여전히 필요하다.

Signal의 이전 “private discovery” 작업은 같은 철학을 보여준다. Signal 클라이언트는 가능한 한 서버가 평문 소셜 그래프를 신뢰받아 보관하지 않도록 해야 한다. 전화번호 없는 등록은 이 원칙을 계정 생성으로 확장한다.

이 메커니즘은 모든 형태의 메타데이터가 아니라 특정 관계를 보호한다. 스토어는 누군가 Signal 관련 항목을 구매했다는 사실을 여전히 알 수 있다. Signal 역시 일반적인 서비스 아키텍처 내에서 네트워크 요청, 타이밍, 기기 정보, 이후의 계정 활동을 관찰할 수 있다.

따라서 사용자는 “zero knowledge”를 정확히 이해해야 한다. 이는 정의된 프로토콜 안에서 증명이 무엇을 숨기는지 설명한다. 모든 참여자가 모든 이벤트에 대해 아무것도 알지 못한다는 뜻은 아니다.

고위험 사용자에게는 특히 타이밍이 여전히 중요하다. 자격 증명을 구매하고 몇 초 뒤에 사용하면 분리된 시스템 전반에서 상관관계 분석이 가능해질 수 있다. 네트워크 분리, 일괄 처리, 지연 사용 또는 기타 운영상의 선택이 이러한 노출을 줄일 수 있다.

Signal은 최종 워크플로에 이러한 조치가 포함되는지 설명하지 않았다. 또한 서버가 어떤 결제 메타데이터를 수신하거나 보관하는지도 밝히지 않았다. 이런 공백은 암호화에 붙은 안심시키는 라벨보다 더 중요하다.

전화번호 없는 가입이 Signal의 경쟁 구도를 바꾼다

Signal은 대화 내에서 전화번호를 숨기는 수준을 넘어 계정 생성 단계에서 전화번호를 제거하려 하고 있으며, 여러 프라이버시 우선 경쟁사들은 이미 이 지점에서 차별화하고 있다.

WhatsApp은 메시지 암호화에 Signal Protocol을 사용하지만, 계정 등록은 여전히 전화번호를 중심으로 한다. Telegram도 일반적인 가입 과정에서 전화번호를 사용하고 검색을 위해 사용자 이름을 제공한다. 이러한 설계는 손쉬운 연락처 매칭을 유지하지만 전화번호 기반 신원이 수반하는 프라이버시 비용도 물려받는다.

Signal은 역사적으로 비슷한 위치에 있었다. 메시지 암호화는 높은 평가를 받았지만, 비판자들은 의무적인 전화번호 인증을 근본적인 신원 연결고리로 지적할 수 있었다. 사용자 이름은 등록 시 그 연결고리를 없애지는 못하면서 연락처 간 노출을 줄였다.

Signal의 전화번호 없는 등록은 대체 식별자를 중심으로 설계된 서비스와의 격차를 줄일 수 있다. 예를 들어 SimpleX는 네트워크가 사용자에게 전역 식별자를 부여하지 않는다고 말한다. 연락처는 보편적인 전화번호나 사용자 이름 대신 초대 링크와 쌍별 주소를 통해 연결된다.

Session은 전화번호 대신 계정 식별자를 사용하며, 탈중앙화 네트워크 전반에 메시지 라우팅을 분산한다. Matrix는 독립적으로 운영되는 서버에서 계정을 허용하며, 보통 선택한 홈서버에 연결된 사용자 이름을 사용한다. 각 방식은 검색, 모더레이션, 메타데이터, 사용성 측면에서 서로 다른 절충안을 만든다.

Signal은 이들 시스템의 아키텍처를 채택하는 것은 아니다. 여전히 클라이언트와 서버의 관계를 엄격히 통제하는 중앙 운영 서비스다. 전화번호 없는 작업은 연합이나 인프라 거버넌스에 대한 접근법이 아니라 등록 자격 증명을 바꾼다.

이러한 초점은 Signal이 밝힌 우선순위에 부합한다. 중앙 운영을 통해 프로토콜 업데이트, 악용 방지 제어 배포, 클라이언트 동작 조율이 가능하다. 암호화가 가용 데이터를 최소화하더라도, 이는 Signal의 구현과 정책에 신뢰를 집중시키기도 한다.

따라서 경쟁 구도의 변화는 “Signal이 익명화된다”는 표현보다 좁다. 전화번호 없는 계정에도 사용자 이름, 프로필 이름, 기기, 네트워크 주소, 연락처, 행동 패턴이 있을 수 있다. 프라이버시는 이런 신호가 사용자의 실제 신원과 어떻게 상호작용하는지에 달려 있다.

달라지는 점은 가입 전에 전화 통신 종단점을 제시해야 한다는 기본 요건이다. 이는 전화번호가 유난히 지속적이고 상호운용 가능한 식별자이기 때문에 중요하다. 전화번호는 메시징, 금융, 광고, 고용, 정부 시스템 전반을 오간다.

유료 자격 증명은 다른 특성을 가진다. 연락처가 사용하는 주소가 되지 않으면서 경제적 마찰을 부과할 수 있다. 암호학적 분리가 작동한다면 구매는 계정에 계속 연결된 채 남지 않고 등록을 승인할 수 있다.

이 설계는 사용성 경쟁도 바꾼다. Signal은 더 사적인 진입 경로를 제공하면서도 친숙한 사용자 이름과 매끄러운 연락처 경험을 유지할 수 있다. 익명 식별자를 중심으로 구축된 경쟁 서비스는 종종 사용자에게 초대 링크, 서버 선택, 낯선 복구 모델을 이해하도록 요구한다.

그러나 Signal의 접근 방식은 지원되는 스토어나 결제 수단을 이용할 수 없는 사람들을 배제할 수 있다. 프라이버시 도구는 제한된 환경의 사용자들, 앱 스토어가 제한된 지역을 포함해, 자주 지원한다. 결제 의존형 옵션은 Android 결제 통합 하나보다 더 폭넓은 접근성을 필요로 한다.

현재 커밋은 Google Play 결제 지원을 드러내며, Play가 아닌 빌드에서는 구매를 사용할 수 없다고 보고할 수 있다. 이는 대체 Android 스토어와 직접 배포 애플리케이션 패키지를 쓰는 사용자에게 즉각적인 의문을 제기한다. Signal은 최종 크로스플랫폼 계획을 발표하지 않았다.

Apple 플랫폼에는 별도의 구현과 검토가 필요하다. 오늘날 데스크톱 기기는 모바일 클라이언트와 같은 전제하에 기본 계정을 만들 수 없다. 완전한 출시는 어떤 기기와 결제 조합이 전화번호 없는 신원을 생성할 수 있는지 결정해야 한다.

전화번호 인증과의 비교도 지역에 따라 달라질 것이다. 일부 국가에서는 SMS 전송이 실패할 수 있지만, 다른 곳에서는 선불 번호를 쉽게 구할 수 있다. 스토어 결제는 어떤 사용자에게는 잘 작동하지만 다른 사용자에게는 불가능할 수 있다.

Signal은 전화번호 없는 등록을 명확한 제한 사항이 있는 옵션으로 제시해야 한다. 이를 전화번호의 보편적 대체재로 다루는 것은 현재 코드가 지원하는 범위를 과장하는 일이다. 가장 강력한 설계는 여러 등록 경로를 유지하면서 각각의 프라이버시 속성을 명확히 하는 방식일 수 있다.

증명이 성공한 뒤 가장 어려운 질문이 시작된다

영지식 자격 증명은 하나의 연결고리를 끊을 수 있지만, 복구, 악용 방지, 결제 접근성, 메타데이터가 전체 시스템이 신뢰받을 만한지를 결정한다.

계정 복구는 첫 번째 압박 지점이다. 전화번호는 SIM 스와핑 위험을 만들지만, 사용자에게 신원을 되찾을 외부 채널을 제공한다. 전화번호 없는 계정은 비밀 정보, 기기, 백업 또는 기타 자격 증명에 의존해야 한다.

Android 변경 사항에는 전화번호 없는 로그인용 비밀번호 관리자 지원과 조정된 백업 온보딩이 포함된다. 또한 전화번호 없는 계정에서는 일부 PIN 동작을 제거한다. 이런 세부 사항은 Signal이 복구 자료가 더 큰 책임을 맡을 것으로 예상한다는 점을 시사한다.

이러한 변화는 신중한 사용자에게 보안을 개선할 수 있다. 반면 자격 증명을 잃어버리거나 복구 비밀 정보를 저장하지 못한 사람에게는 영구적인 계정 손실을 초래할 수 있다. Signal은 기기가 사라진 뒤가 아니라 등록 전에 그 결과를 설명해야 한다.

코드는 백업 및 복구 워크플로 전반에서 사용되는 고엔트로피 비밀 정보인 계정 엔트로피 풀을 언급한다. 비밀번호 관리자는 사람의 기억보다 이러한 정보를 더 안정적으로 보관할 수 있다. 그러나 비밀번호 관리자가 없는 사용자에게는 안전하고 이해하기 쉬운 대안이 필요하다.

악용은 두 번째 압박 지점이다. 결제는 비용과 사용 규칙이 공격자에게 실질적인 영향을 미칠 때만 대량 등록을 억제한다. 사기 조직은 도난당한 결제 수단, 탈취된 스토어 계정, 환불 악용 방식을 사용할 수 있다.

Signal은 차단 조치가 새 자격 증명과 어떻게 상호작용할지도 결정해야 한다. 차단된 행위자가 즉시 다른 등록을 구매할 수 있다면, 시스템은 지속적인 악용을 막지 못한 채 마찰만 만든다. 차단을 집행하기 위해 Signal이 너무 많은 정보를 연결하면 프라이버시 약속은 약화된다.

이 긴장은 암호학만으로 해결할 수 없다. 영지식 증명은 유효한 구매가 발생했음을 보여주고 단순한 재사용을 막을 수 있다. 하지만 Signal이 어떤 악용 신호를 수집해야 하는지, 서비스를 얼마나 적극적으로 상관관계 분석해야 하는지는 결정할 수 없다.

결제 접근성은 세 번째 우려를 낳는다. 공개된 Android 작업은 구현된 구매 경로에서 Google Play에 의존한다. 코드 주석에 따르면 Play 결제가 없는 기기는 사용할 수 없는 상태를 반환한다. 여기에는 일부 프라이버시 지향 Android 구성과 배포 채널도 포함된다.

따라서 통신사 의존도를 줄이려는 기능이 앱 스토어 운영자에 대한 의존도를 높일 수 있다. Google은 최종 Signal 계정을 알지 못할 수 있지만, 고객이 Signal 등록 항목을 구매했다는 사실은 알 수 있다.

이 차이는 의미 있지만 완전하지는 않다. 일부 사용자는 Signal 계정을 전화번호와 분리하는 것을 주로 원한다. 다른 사용자들은 Signal 사용을 나타내는 스토어 또는 금융 기록을 만드는 것 역시 피하고 싶어 한다.

Signal은 궁극적으로 대체 결제 제공업체나 바우처를 지원할 수 있다. 한 사람이 다른 사람의 등록을 승인할 수 있도록 양도 가능한 자격 증명을 설계할 수도 있다. 현재 저장소는 이러한 옵션을 확립하지 않으므로, 기대가 아니라 가능성으로 남겨야 한다.

메타데이터는 네 번째 우려를 만든다. 프라이버시를 보존하는 자격 증명은 수학적으로 연결 불가능할 수 있지만, 운영 이벤트는 여전히 상관관계를 보일 수 있다. 발급 시간, 사용 시간, 네트워크 주소, 기기 지문, 오류 로그는 익명성의 범위를 좁힐 수 있다.

Signal의 클라이언트는 서버에 더 적은 데이터를 드러내도록 설계됐지만, 메타데이터 없이 운영되는 배포 네트워크는 없다. 관련 기준은 완벽한 비가시성이 아니다. 시스템이 필요한 정보만 수집하고 피할 수 있는 연결을 방지하는지가 중요하다.

독립적인 평가는 프로토콜 설명과 명확한 위협 모델을 요구한다. Signal은 어떤 당사자들이 협력할 수 있다고 가정하는지 밝혀야 한다. 이 목록에는 스토어 운영자, 결제 처리업체, 자격 증명 발급자, 등록 서비스, 네트워크 관찰자가 포함된다.

연구자들은 하나의 조직이 여러 역할을 통제하는지도 평가해야 한다. 공동 운영 환경에서도 암호학적 분리는 여전히 가치가 있을 수 있다. 그 보장은 올바른 구성, 키 관리, 로그 동작, 배포 경계에 달려 있다.

커뮤니티 스레드는 코드가 드러나는 데 도움을 주었지만, 커뮤니티 토론은 공식 제품 발표가 아니다. 일부 참여자는 설계를 자신 있게 설명하는 반면, 다른 이들은 연결 불가능성과 결제 프라이버시에 의문을 제기한다. 이들의 논의는 유효한 쟁점을 드러내지만 결론을 내리지는 않는다.

Android 저장소는 구현에 관한 더 강력한 증거를 제공한다. 그러나 여전히 개발 중인 소프트웨어를 나타낸다. 기능 플래그, 인터페이스, 테스트, 주석은 출시 전에 바뀔 수 있으며, 서버 동작은 클라이언트 코드에서 도출한 가정과 다를 수 있다.

Signal은 상당한 클라이언트 작업을 검토 가능하게 만든 점에서 인정받아야 한다. 이러한 가시성은 개발자가 영수증 자격 증명, 결제 경계, 전화번호 없는 계정 상태를 식별할 수 있게 한다. 또한 마케팅 언어가 이야기를 규정하기 전에 검토를 가능하게 한다.

책임 있는 결론은 조건부다. 이 메커니즘은 일회성 승인을 강제하면서 결제와 계정 간의 직접적인 연결을 막도록 설계된 것으로 보인다. 배포된 서비스가 이 목표를 달성하는지는 아직 독립적으로 검증되지 않았다.

Signal이 전화번호 없는 계정을 출시하기 전에 주목할 점

신뢰할 수 있는 개인정보 보호 기능으로 자리 잡을지 가늠할 세 가지 신호는 공개 출시, 문서화된 위협 모델, 폭넓은 등록 접근성이다.

첫 번째 신호는 공개 베타 또는 정식 출시다. 현재 Android 코드에서는 전화번호 없는 등록이 내부 빌드에서만 가능하도록 제한돼 있다. 이 제한이 베타로 옮겨진다면 Signal이 개발 환경 밖에서도 이 절차를 사용할 수 있다고 판단했다는 의미가 된다.

베타는 실제 온보딩 절차도 보여줄 것이다. 사용자는 결제가 필수인지, 사용자 이름 생성을 건너뛸 수 있는지, 어떤 복구 정보를 저장해야 하는지를 확인할 수 있다. 스토어 이용 가능 여부와 국가별 제한도 측정 가능해진다.

기존 계정이 전화번호를 분리할 수 있는지도 지켜봐야 한다. 신규 계정만 지원하면 앞으로 가입하는 사용자의 등록 문제는 해결되지만, 현재 Signal 사용자는 과거의 전화번호 식별자와 계속 연결된 상태로 남는다. 마이그레이션 절차가 마련되면 이 기능의 영향력은 크게 확대될 것이다.

Signal은 ‘분리’가 무엇을 의미하는지 설명해야 한다. 인터페이스에서 전화번호를 제거하는 일은 관련 서버 기록을 모두 삭제하는 것과 같지 않다. 사용자에게는 정확한 계정 상태 정의와 보존 정책이 필요하다.

두 번째 신호는 기술 설계 문서의 공개다. 유용한 문서라면 자격 증명 발급, 구매 상환, 재사용 방지, 복구, 관련 메타데이터를 설명해야 한다. 또한 결제 제공업체와 Signal 서비스가 무엇을 관찰할 수 있는지도 명시해야 한다.

공식 보안 검토가 이 주장을 더 뒷받침할 수 있다. zkgroup 라이브러리는 Signal 내부에서 이미 사용된 사례가 있지만, 전화번호 없는 등록은 새로운 프로토콜 조합을 만든다. 검토자는 수학적 설계와 이를 둘러싼 애플리케이션 흐름을 모두 살펴야 한다.

가장 중요한 질문은 연결 가능성이다. Signal은 발급자가 상환된 자격 증명을 식별할 수 있는지, 여러 번의 제시를 상관관계로 묶을 수 있는지, 어떤 타이밍 정보가 계속 노출되는지를 정의해야 한다. 광범위한 익명성 주장보다 명확한 한계가 더 신뢰할 만하다.

세 번째 신호는 플랫폼 및 결제 수단의 지원 범위다. 현재 Android 구현에는 Google Play 결제가 적용된 것으로 보인다. 직접 설치한 Android 빌드, iOS 사용자 또는 지원되지 않는 지역에 등록 경로가 없다면 개인정보 보호 기능은 Signal의 전체 사용자를 지원할 수 없다.

대체 자격 증명은 이런 의존도를 낮출 수 있다. 기프트 코드, 비영리단체 배포 또는 결제 제공업체에 중립적인 결제 방식은 지원되는 스토어 계정이 없는 사용자에게 도움이 될 수 있다. 어떤 경로든 일회성 상환과 대량 악용에 대한 저항성을 유지해야 한다.

개발자는 서버 저장소와 프로토콜 라이브러리도 살펴봐야 한다. 새로운 엔드포인트, 자격 증명 유형, 문서는 어떤 보장이 암호학적으로 강제되는지 보여줄 수 있다. 클라이언트 인터페이스만으로는 모든 보존 관련 질문에 답할 수 없다.

개인정보 보호에 민감한 조직은 온보딩 지침을 변경하기 전에 이러한 세부 사항을 기다려야 한다. 언론인, 연구자, 활동가, 기업은 전화번호 노출 감소와 함께 복구 및 계정 손실 위험도 이해해야 한다.

개인정보 보호 도구를 평가하는 지식 노동자는 이러한 설계 가정을 개인 지식 베이스에 기록할 수 있다. 그러면 Signal이 문서를 공개하거나 출시 방식을 변경할 때 지속 가능한 비교 기준이 생긴다.

Signal의 전화번호 없는 등록은 실제 모순을 다룬다. 이 서비스는 최소한의 데이터로 가입받기를 원하지만, 일회용 계정이 암호화된 네트워크를 압도하지 않도록 막아야 한다. 유료의 연결 불가능한 자격 증명은 일관된 해법이지만, 작동 여부는 구현 세부 사항에 달려 있다.

다음 행보는 Signal에 달려 있다. 기능을 출시하고, 관찰 가능한 메타데이터를 문서화하며, 암호학 용어 뒤에 불확실성을 숨기지 않고 복구 방식을 설명해야 한다. 그때 독자는 한 가지 실용적인 질문을 던져야 한다. 각 당사자가 필요한 사실을 증명하면서도 개인에게 다시 이어지는 지속적인 경로를 얻지 않을 수 있는가?