[심층분석] 전화번호도, 아이디도 없는 메신저? SimpleX가 '익명'을 다시 정의하는 법

메신저는 왜 항상 "너 누구야?"부터 물을까요

우리가 쓰는 메신저들을 한번 떠올려 볼까요. 카카오톡은 전화번호로 친구를 찾고, 텔레그램도 가입할 때 전화번호를 넣어야 하죠. 프라이버시로 유명한 시그널(Signal)조차도 전화번호가 있어야 가입이 돼요. 이게 너무 당연해 보여서 우리가 평소엔 의심조차 안 하는데요, 사실 여기에 프라이버시의 근본적인 구멍이 하나 숨어 있어요.

무슨 말이냐면요, 메신저가 당신에게 '고유 식별자(user identifier)'를 부여하는 순간 문제가 시작돼요. 식별자라는 건 쉽게 말해서 "이 사람은 12345번 사용자"라고 딱지를 붙이는 거예요. 전화번호든, 사용자 아이디든, 심지어 랜덤하게 생성한 긴 숫자든, 그게 하나라도 있으면 서버는 "12345번이 67890번한테 오후 3시에 메시지를 보냈다"는 기록을 남길 수 있게 되거든요.

여기서 핵심은 메시지 내용이 아니라 '누가 누구랑 언제 대화했는지'예요. 이걸 어려운 말로 메타데이터(metadata)라고 해요. 내용은 암호화해서 못 봐도, 관계망과 시간만 모으면 무서울 정도로 많은 걸 알아낼 수 있어요. 누가 누구랑 자주 연락하는지, 새벽에 누구랑 대화하는지... 정보기관들이 "우리는 메타데이터만으로 사람을 죽인다"고 했던 유명한 말이 괜히 나온 게 아니거든요.

오늘 소개할 SimpleX Chat은 바로 이 지점을 정면으로 공략한 메신저예요. "식별자가 아예 없는 최초의 메시징 네트워크"라는 게 이들의 슬로건인데요, 이게 마케팅 문구가 아니라 실제 아키텍처(시스템 설계 구조)가 그렇게 되어 있다는 게 흥미로운 지점이에요.

SimpleX는 '사용자' 대신 '메시지 큐'를 식별해요

자, 이게 핵심이라 천천히 풀어볼게요. 보통 메신저의 구조는 이래요. 서버에 사용자 계정이 줄줄이 있고, A가 B한테 보내면 서버가 "A 계정에서 B 계정으로"라고 라우팅(경로 배정)을 해요. 모든 게 계정 중심이에요.

SimpleX는 발상을 완전히 뒤집어요. 여기엔 사용자 계정이라는 개념 자체가 없어요. 대신 모든 통신의 단위가 단방향 메시지 큐(unidirectional message queue)예요. 큐가 뭐냐면, 쉽게 말해 '편지를 넣어두는 우편함' 하나라고 생각하면 돼요.

비유를 하나 들어볼게요. 친구랑 비밀 편지를 주고받는데, 서로의 집 주소를 절대 알려주기 싫은 상황이에요. 그래서 이렇게 해요. 동네 어딘가에 익명 사물함을 하나 빌리고, 그 사물함 열쇠를 친구한테 줘요. 친구는 나한테 편지를 보낼 때 그 사물함에 넣어두기만 하면 돼요. 나는 그 사물함만 열어보면 되고요. 답장은 또 다른 사물함을 통해서 보내요.

여기서 중요한 건, 사물함 관리인(=서버)은 "누가 이 사물함의 주인인지" 전혀 몰라요. 그냥 "몇 번 사물함에 뭔가 들어왔다" 정도만 알아요. 게다가 친구마다 서로 다른 사물함을 써요. 그래서 사물함 관리인이 여러 사물함을 봐도 "이게 다 같은 사람 거구나" 하고 연결할 수가 없어요. 이게 SimpleX가 식별자 없이 작동하는 원리예요.

조금 더 기술적으로 말하면요:

• 두 사람이 연결될 때마다 새로운 큐 한 쌍이 생겨요 (보내는 용, 받는 용)
• 각 큐는 임시 익명 자격증명으로만 접근해요. 내 신원이 아니라 "이 큐에 접근할 권한이 있나"만 확인하거든요
• 큐를 운영하는 서버는 SMP 서버(SimpleX Messaging Protocol)라고 부르는데, 이 서버들은 메시지를 잠깐 들고 있다가 전달하면 바로 삭제해요
• 받는 쪽과 보내는 쪽이 서로 다른 서버를 쓸 수도 있어서, 한 서버가 양쪽을 다 보는 일도 막아요

암호화는 시그널 수준에 한 겹을 더 얹었어요

그럼 내용 보안은 어떨까요? 여기서도 탄탄해요. SimpleX는 시그널이 쓰는 것과 같은 더블 라쳇(Double Ratchet) 종단간 암호화를 써요.

더블 라쳇이 뭐냐면, 쉽게 말해 메시지 하나 보낼 때마다 자물쇠 열쇠를 계속 바꾸는 방식이에요. 일반 암호화는 열쇠 하나로 쭉 잠그는데, 더블 라쳇은 매번 새 열쇠를 만들고 옛날 열쇠는 버려요. 그래서 혹시 지금 열쇠가 털려도 과거 메시지는 못 풀고(이걸 '순방향 비밀성'이라고 해요), 미래 메시지도 곧 다른 열쇠로 바뀌니까 안전해요.

SimpleX는 여기에 추가 암호화 레이어(layer)를 한 겹 더 얹어요. 큐를 통과하는 구간에서 한 번 더 감싸는 거예요. 양파 껍질처럼 여러 겹으로 싸는 거죠. 거기에 더해 양자내성암호(post-quantum)도 도입하고 있는데요, 이건 "먼 미래에 양자컴퓨터가 나와서 지금 암호를 다 풀어버리면 어쩌지?"에 대비한 보험이라고 보면 돼요. 메시지 길이도 일정하게 맞춰서(content padding) "길이를 보고 내용을 짐작하는" 공격까지 막아요.

시그널, 텔레그램, 매트릭스랑 뭐가 다른 거죠?

비슷해 보이는 프라이버시 메신저들이 많으니까, 차이를 비유로 정리해 볼게요.

텔레그램은 사실 기본 대화가 종단간 암호화가 아니에요. 서버가 내용을 볼 수 있는 구조라, '비밀 대화'를 따로 켜야 해요. 비유하자면 편지를 봉투에 넣긴 했는데 우체국이 봉투를 열 수 있는 상태예요.

시그널은 암호화는 최고 수준이에요. 내용은 정말 안전해요. 근데 가입할 때 전화번호가 필요하죠. 봉투는 완벽하게 봉인됐는데, 봉투 겉면에 보낸 사람·받는 사람 전화번호가 적혀 있는 셈이에요. 시그널도 'Sealed Sender' 같은 기술로 이걸 가리려고 노력하지만, 계정 자체가 전화번호에 묶여 있다는 근본 구조는 남아요.

매트릭스(Matrix)는 탈중앙화가 장점인데, 그래도 @user:server.org 같은 고정된 계정 주소가 있어요. 서버를 옮겨다닐 순 있어도 '나'라는 식별자는 계속 따라다녀요.

SimpleX는 아예 봉투에 보낸 사람·받는 사람을 안 적어요. 대신 "이 사물함으로 와"라고만 약속하고, 사물함은 친구마다 다 달라요. 식별자라는 개념 자체를 설계에서 제거한 게 이 메신저의 가장 급진적인 부분이에요.

물론 단점도 솔직히 짚을게요. 식별자가 없다 보니 여러 기기에서 같은 계정 쓰기나 연락처 자동 동기화 같은 편의 기능이 까다로워요. 친구를 추가하려면 QR코드나 초대 링크를 주고받아야 하고, 카톡처럼 "전화번호부에서 친구 자동 추가" 같은 건 구조상 안 되거든요. 프라이버시와 편의성은 늘 줄다리기인데, SimpleX는 프라이버시 쪽으로 확 당긴 선택을 한 거예요.

한국 개발자에게 주는 시사점

그럼 우리가 실무에서 뭘 얻어갈 수 있을까요?

첫째, '식별자 없는 설계'라는 발상 자체가 자산이에요. 우리는 시스템을 만들 때 거의 반사적으로 user_id를 가운데 두잖아요. 근데 SimpleX는 "관계(연결) 자체를 단위로 삼으면 식별자 없이도 라우팅이 된다"는 걸 보여줘요. 만약 여러분이 민감한 데이터를 다루는 헬스케어·금융 서비스를 설계한다면, "이 데이터가 굳이 사용자 ID에 묶여야 하나?"를 한 번쯤 의심해 볼 가치가 있어요.

둘째, 직접 서버를 띄워볼 수 있어요. SMP 서버는 오픈소스라 도커(Docker)로 자체 호스팅이 돼요. 사내 보안 메신저가 필요한 팀이라면, 외부 서비스에 의존하지 않고 우리 인프라 위에 프라이빗 메시징 망을 올리는 실험을 해볼 수 있어요. 메시지 메타데이터가 외부로 안 나가는 게 규제 대응에 큰 무기가 되거든요.

셋째, CLI와 봇 연동이 가능해요. SimpleX는 터미널(콘솔) 앱과 봇 프레임워크를 제공해요. 알림이나 자동화 메시지를 보내는데 "사용자 계정을 만들 필요 없이" 익명 큐로 처리하는 파이프라인을 짜볼 수 있어요.

학습 로드맵을 제안하자면 이래요. ① 먼저 앱을 깔아서 QR로 친구와 연결해보며 "식별자 없는 연결"이 체감상 어떤지 느껴보세요. ② 그다음 더블 라쳇과 시그널 프로토콜 문서를 읽어 암호화 기초를 다지고요. ③ 마지막으로 SMP 서버 명세와 깃허브 저장소를 뜯어보며 큐 기반 라우팅 구현을 살펴보면, 분산 시스템 설계 감각이 확 늘 거예요.

마무리하며

SimpleX가 당장 카카오톡을 대체하진 않을 거예요. 편의성의 벽이 분명히 있으니까요. 하지만 이 프로젝트가 던지는 질문은 묵직해요. "우리는 정말 식별자가 필요했던 걸까, 아니면 그냥 익숙해서 당연하게 여겼던 걸까?"

프라이버시 규제가 점점 강해지고, 메타데이터의 위험성에 대한 인식이 높아지는 흐름 속에서, '식별자 제로'라는 설계 철학은 앞으로 더 많은 서비스에 영향을 줄 거라고 봐요. 적어도 "왜 우리 서비스는 사용자를 이렇게 식별하지?"라고 되묻게 만드는 것만으로도 충분히 의미가 있고요.

여러분은 어떻게 생각하세요? 프라이버시를 위해 친구 자동 추가 같은 편의 기능을 포기할 수 있나요? 아니면 편의성 없는 프라이버시는 현실에서 살아남기 어렵다고 보시나요? 직접 운영하는 서비스에서 "사용자 식별자를 없앨 수 있는" 부분이 있는지 한번 점검해보고, 경험을 댓글로 나눠주세요!