"초대 스팸"의 시대를 끝낼 수 있을까? Bluesky의 친구 찾기는 무엇이 다른가

「친구 찾기」——SNS가 당연한 기능으로 제공해 온 이 기능은 사실 오랫동안 “골칫거리”이기도 했다. 스마트폰의 연락처를 읽어들이고, 누가 같은 SNS에 있는지를 찾아내며, 등록되지 않은 상대에게 초대 메시지를 보내는 것이다. 사용자에게는 재회의 지름길이지만, 받는 사람에게는 갑작스럽게 도착하는 “앱 초대 SMS”가 되기 쉽고, 게다가 전화번호라는 강력한 개인 정보가 얽히는 이상, 유출 및 남용의 위험도 항상 함께했다. Bluesky가 12월, 「Find Friends」를 “프라이버시 중시”로 내세운 배경에는, 이 오래된 성공 패턴을 그대로 답습하지 않겠다는 강한 의지가 엿보인다. TechCrunch

「초대 스팸」을 하지 않겠다는 선언

TechCrunch가 전한 이번 포인트는 명확하다. Bluesky는, 연락처를 업로드해도 앱 측이 자동으로 초대 SMS를 보내지 않는다. 한다고 해도 “사용자가 자신의 의사로 친구에게 텍스트를 보내는” 수동 액션으로 제한한다. 지금까지 많은 SNS가 연락처 대조를 성장 해킹(바이럴의 도선)으로 사용하고, 반강제적으로 초대를 보내온 것을 감안하면, 상당히 도전적인 입장 표명이다. TechCrunch

하지만, 여기에는 트레이드오프가 있다. Bluesky는 「개별 전화번호를 저장·추적하지 않는다」는 설계 때문에, 상대가 이미 Bluesky에 있는지를 사전에 판단할 수 없다. 그 결과, 친구가 선의로 초대 텍스트를 보냈다고 해도, 받는 사람이 “이미 참여 중”이어도 도착할 가능성이 있다. 9to5Mac은 이를 「결점」으로 보면서도, 프라이버시 보호의 대가로서는 작다고 평가하고 있다. 9to5Mac

구조: 이중 동의(더블 옵트인)＋번호 확인

Bluesky의 Find Friends는, 다음 조건이 갖춰지지 않으면 매치되지 않는다.

• 양측이 Find Friends를 활성화하고 있다

• 서로를 연락처에 등록하고 있다 (짝사랑의 연락처 등록으로는 성립하지 않는다)

• SMS로 자신의 번호를 확인한 후 연락처를 업로드한다

TechCrunch의 설명에 따르면, 이용 시 SMS로 도착하는 6자리 코드를 입력해 번호를 검증하고, 랜덤한 번호를 대량으로 투입해 「이 번호는 Bluesky에 있는가?」를 낚아채는 “피싱” 같은 악용을 억제할 목적이 있다고 한다. 게다가, 애초에 사용하지 않으면 「전화번호로 발견되는 측」이 되지 않는다——직장의 지인에게 발견되고 싶지 않은 사람은, 기능을 사용하지 않는 선택이 남는다. TechCrunch

제공 지역도 단계적으로, 초기에는 모바일 앱의 일부 국가(일본 포함)에 한정되어 있다. TechCrunch

「해시 페어」＋「별도의 하드웨어 키」—유출 전제의 방어

이번에 가장 흥미로운 것은, Bluesky가 “연락처 대조”를 보안 설계의 문제로 정면으로 다루고 있는 점일 것이다. TechCrunch 및 Bluesky의 공식 블로그에 따르면, 업로드된 전화번호는 단순한 해시화가 아니라, 「자신의 번호×상대의 번호」를 조합한 “hashed pairs(해시 페어)”로 저장된다. 이를 통해, 만약 데이터가 유출되더라도 역산(리버스 엔지니어링)을 어렵게 한다는 논리다. 게다가 암호화는, DB와는 별도로 보관된 하드웨어 보안 키에 연결된다고 한다. 사용자 측은 나중에 데이터 삭제·옵트아웃도 가능하다. TechCrunch

또한 TechCrunch는, 이 기술적 세부사항이 사전에 RFC로서 보안 커뮤니티에 공유되어, 피드백을 모집하고 있었다는 점도 전하고 있다. 뒤집어 말하면, Bluesky 자신도 「연락처 대조는 위험한 구현이 많다」는 것을 인정하고, 갑자기 본격 투입하는 것이 아니라 설계를 공개하여 논의했다는 것이다. TechCrunch

왜 이렇게까지 하는가: 「콜드 스타트」와 “현실의 친구”

Bluesky는 블로그에서, SNS가 본래 「실제로 아는 사람과 연결되는 장소」였는데, 알고리즘이나 참여 경쟁의 소음으로 그것이 사라졌다고 문제 제기하고 있다. 이제 다시 “아는 사람을 만날 수 있는 SNS”를 목표로 한다면, 친구 발견은 피할 수 없다. 게다가 Bluesky는, RFC의 문맥에서는 「소셜 그래프의 밀도를 세우는 콜드 스타트 문제」에 대해 언급하고, 사용자 규모에도 언급하고 있다. Bluesky

요컨대, Find Friends는 편리 기능의 추가라기보다는, 「분산형(을 지향하는) SNS가, 어떻게 인간관계의 초동을 만들 것인가」라는, 서비스의 근간에 가까운 테마이기도 하다.

SNS(커뮤니티) 상의 반응: 환영과 회의가 공존

이번 설계는 곧바로 논쟁을 불러일으켰다. 여기서는 “SNS의 반응”으로서, Hacker News와 GitHub Discussions에서의 목소리를 중심으로 경향을 정리한다.

1) 「Private Set Intersection 같은 발상」—더 암호적인 해결을 시사

Hacker News에서는, 관련 기술 영역으로 Private Set Intersection(집합의 공통 부분만을 비밀로 유지한 채 구하는 발상)을 언급하며, 「전화번호를 평문으로 공유하지 않음으로써 공격 클래스를 통째로 피할 수 있다」는 방향성이 화제가 되었다. 한편으로는 「스케일 면에서는 과도할지도 모른다」며 현실적인 선을 긋는 댓글도 있다. Hacker News

2) 「보안은 적혀 있지만, 결국 서버를 신뢰하는 것이 아닌가？」라는 지적

마찬가지로 Hacker News에서는, RFC가 “보안”을 다루고 있는 한편으로 「최종적으로는 서버/인스턴스를 신뢰하는 구조로 보인다」는 회의적인 시각도 나왔다. 번호 검증(스푸핑 대책)과, 서버에 번호를 넘기지 않는 설계는 양립하기 어렵다는, 현장감 있는 댓글이다. Hacker News

3) 「전화번호는 해시라도 위험하다」—번호 공간의 작음 문제

다른 댓글에서는 「전화번호는 유니크함이 부족하고, 해시는 룩업 테이블로 대응될 수 있다」며, 이른바 “번호 공간이 좁다”는 문제를 지적하는 목소리도 있다. Bluesky가 「해시 “페어”」로 역산 난도를 높이려는 목적은 여기에 있지만, 사용자 측의 불안으로서는 뿌리 깊다. Hacker News

4) GitHub에서는 「사양을 더 명확히」「애초에 연락처＝소셜이 아니다」

GitHub의 디스커션에서는, 설계의 세부에 들어간 피드백이 눈에 띈다. 예를 들어 **전화번호 재활용(번호의 재할당)**에 관한 설명이 이해하기 어려우니, 의사 코드를 빨리 제시하는 것이 좋다는 건설적인 지적이 있다. GitHub

또 다른 댓글에서는 「자신의 전화번호부는 소셜 그래프와 일치하지 않으므로, 이 기능은 사용하지 않는다」고 말하면서, 옵트인 상태로/불필요한 “명확용의 부가 정보”를 저장하지 않는 한은 우려하지 않는다는 거리감을 나타냈다. GitHub

요약: Find Friends는 “기능”이라기보다 「약속」의 형태

Bluesky의 Find Friends는, 표면적으로는 「드디어 친구 검색이 왔다」는 업데이트다. 그러나 내용은, (1) 자동 초대로 늘리는 유혹을 끊고, (2) 이중 동의로 “발견되는 측”에도 선택권을 남기며, (3) 유출 전제로 설계를 다지고, (4) 사전에 RFC를 공개해 외부 리뷰를 받는——라는, 프라이버시와 성장의 균형에 대한 “약속”을 구현한 것으로 보인다. TechCrunch

물론, 전화번호라는 소재 자체가 너무 강력한 이상, 완전히 논쟁이 사라지지는 않을 것이다. Hacker News나 GitHub의 반응이 보여주듯이, 서버 신뢰나 번호 공간의 문제, 그리고 「연락처＝친구가 아니다」라는 근본적인 논의도 남아 있다. Hacker News

그럼에도 불구하고, 연락처 대조를 “성장 장치”가 아니라 “안전 설계의 과제”로 다루는 자세는, 앞으로 같은 종류의 기능을 구현하는 SNS에 있어 하나의 기준점이 될지도 모른다. Bluesky