XMTP 개요¶

Umul의 메시징은 직접 만든 것이 아니라 XMTP 프로토콜 위에 얹은 것입니다. 이 장은 그 프로토콜이 무엇이고 왜 이런 모양인지를 설명합니다. Umul이 실제로 어느 부분을 쓰는지는 Umul의 XMTP 사용에 있습니다.

한 줄로: XMTP(Extensible Message Transport Protocol)는 지갑 신원 기반의 종단간 암호화 메시징 프로토콜이고, 그 메시지를 맡아 나르는 공용 노드 네트워크입니다.

이메일에 빗대면¶

Gmail 사용자가 네이버 메일 사용자에게 편지를 보낼 수 있는 이유는 두 회사가 제휴해서가 아니라 같은 규약(SMTP)을 따르기 때문입니다. XMTP는 메신저 세계에서 그 규약 자리를 노립니다.

이메일과 다른 점은 두 가집니다. 계정이 이메일 주소가 아니라 지갑에서 출발하고, 종단간 암호화가 기본이라 서비스 운영자도 내용을 읽지 못합니다.

용어를 집에 빗대면¶

프로토콜 용어가 처음에는 잘 안 붙습니다. 집으로 바꿔 읽으면 관계가 보입니다.

비유	프로토콜 용어	뜻
너라는 사람 = 집	`Inbox`	메시지가 도착하는 곳. 사람 하나에 하나
그 집 열쇠를 든 식구들 = 기기	`installation`	폰, 노트북 각각. 실제로 암복호화하는 주체
대화방 = 공동 금고	MLS 그룹	멤버만 아는 비밀번호를 나눠 가집니다
우체국 = 노드	`xmtpd`	봉투를 맡아 나르고 사본을 보관합니다
등기소 = 블록체인	(없음)	"누구 집인지", "금고 멤버가 누구인지"만 공식 기록

열쇠를 든 식구가 여럿이라는 점이 중요합니다. 집(Inbox)은 하나지만 폰과 노트북은 각자 다른 열쇠를 가지고, 금고를 연 적 없는 새 식구는 그 전에 오간 이야기를 들을 수 없습니다. 이것이 대화 기록의 복구 한계로 이어집니다.

세 층¶

프로토콜은 세 층으로 나뉘고, 이 장의 나머지 문서가 그 구분을 따릅니다.

층	답하는 질문	문서
Identity	보내는 사람과 받는 사람이 누구인가	신원
Encryption	내용을 어떻게 숨기는가	암호화와 전달
Delivery	메시지가 어떻게 도달하는가	암호화와 전달

flowchart LR
  subgraph apps["앱들 (Umul, Base App, Convos, ...)"]
    a1["앱 A 클라이언트"]
    a2["앱 B 클라이언트"]
  end
  subgraph proto["XMTP 프로토콜"]
    id["Identity<br/>누가 보내고 받는가"]
    enc["Encryption<br/>MLS 로 내용 숨김"]
    del["Delivery<br/>topic 구독으로 도달"]
  end
  subgraph net["공용 노드 네트워크"]
    n1["노드 1"]
    n2["노드 2"]
    n3["노드 3 ..."]
    n1 <-->|"사본 복제"| n2
    n2 <-->|"사본 복제"| n3
  end
  a1 --> id
  a2 --> id
  id --> enc
  enc --> del
  del -->|"아무 노드에나 접속"| n1

네트워크가 상자 하나가 아니라 노드 여럿인 것이 핵심입니다. 서로 다른 운영자의 노드들이 전체 암호문 사본을 복제해 들고 있어서, 클라이언트는 아무 노드에나 붙으면 되고 한 노드가 죽어도 메시지가 유지됩니다.

앱이 달라도 메시지가 통합니다¶

통합니다. 단 "XMTP를 붙인 앱들 사이에서"라는 전제가 붙습니다.

원리는 데이터의 위치입니다. 일반 메신저는 계정과 대화가 회사 서버에 있어서 카카오톡 계정으로 라인 친구에게 말을 걸 수 없습니다. XMTP는 계정(Inbox)과 암호화된 메시지가 특정 앱이 아니라 공용 네트워크에 있고, 앱은 그 수신함을 여는 창입니다. 같은 Inbox로 앱 A에서 시작한 대화를 앱 B에서 이어받을 수 있습니다.

다만 "어떤 메신저 서비스든"으로 읽으면 틀립니다. 성립 조건이 다섯 개 있습니다.

조건	내용
XMTP 채택	WhatsApp, Telegram, 카카오톡과는 안 통합니다. SMTP를 안 쓰는 팩스에 이메일이 안 가는 것과 같습니다
같은 네트워크 환경	`dev` / `production` / `local`은 완전히 별개이며 호환되지 않습니다. 환경이 다르면 신원도 메시지도 넘어가지 않습니다
같은 프로토콜 세대	v2 대화는 v3로 이식되지 않았습니다. 세대가 갈리면 단절됩니다
content type 지원	메시지는 도달해도, 받는 앱이 모르는 타입이면 대체 텍스트(fallback)로만 보입니다
수신 동의 상태	모르는 발신자의 메시지는 도달하되 요청함으로 분류될 수 있다 (consent)

Umul은 dev 환경을 씁니다. 그래서 production 환경의 XMTP 앱과는 지금 통하지 않습니다. 이건 제약이 아니라 선택이고, Umul의 XMTP 사용에서 다룹니다.

짧은 역사¶

2021년 시작한 초기 버전(v1/v2)은 자체 암호화 방식을 썼습니다. 2024년 6월부터 IETF 표준 MLS 기반의 v3로 넘어갔고, v2는 2025-06-23 읽기 전용으로 폐기됐다(XIP-53). 2025년 12월부터는 회사가 운영하던 중앙 네트워크를 탈중앙 노드 네트워크로 옮기는 중입니다.

세대 교체가 4년 만에 한 번 있었다는 뜻이고, XMTP 위에 앱을 짓는 것은 이런 교체를 따라갈 운영 비용을 감수한다는 뜻입니다. 한계에 다시 적습니다.