목차
관련 프로젝트
웹3 앱을 만들다 보면 어느 시점에 길드 채팅, 고객 지원, DAO 논의, 거래 협상 등 사용자 간 커뮤니케이션 기능을 구현할 필요가 발생한다. 그런데 이를 온체인에서 풀려고 하면 선택지가 마땅치 않다. 대부분은 결국 텔레그램이나 디스코드 같은 외부 서비스로 빠지거나, 중앙화된 메시징 API를 붙인다. 이러한 방식은 지갑 아이덴티티와 연결되지 않고, 온체인 활동과 분리되어 있고, 접근 제어가 앱의 나머지 로직과 따로 논다는 단점을 갖는다.
Source: Sui
수이의 메시징(Messaging) SDK는 이 간극을 메우려는 프로젝트다. 암호화된 메시징을 수이 블록체인의 아이덴티티, 접근 제어, 스토리지와 같은 스택 위에서 네이티브로 제공한다는 구상이다. 2025년 9월 알파로 처음 공개된 뒤, 몇 달간의 피드백과 아키텍처 재설계를 거쳐 어제 (2026.3.31) 베타 버전이 수이와 월루스(Walrus) 메인넷에 배포되었다.
이번 베타는 단순한 버전 업이 아니다. 알파가 부딪힌 근본적인 질문, "모든 메시지를 온체인 트랜잭션으로 처리해야 하는가"에 대한 답이 바뀌었고, 그에 따라 아키텍처 전체가 재설계되었다.
1. 알파가 시도한 것, 그리고 부딪힌 벽
알파 버전에서는 메시지를 수이 온체인에 직접 저장하고, 첨부파일을 월루스에 저장하고, Seal로 전구간 암호화하는 설계를 구현했다. API 레퍼런스를 보면 이 구조가 그대로 드러난다. 메시지 전송은 아래와 같이 수이 트랜잭션을 빌드하고 서명하는 방식이었다.
통신 채널 생성하는 방식도 마찬가지였다. 아래 코드와 같이 온체인 트랜잭션으로 채널을 만들고, 별도 트랜잭션으로 암호화 키를 부착하는 2단계 플로우를 갖고 있었다.
이러한 접근 방식은 강력한 검증 가능성을 갖는다. 모든 메시지가 수이 객체로 존재하므로 누가 언제 무엇을 보냈는지를 온체인에서 증명할 수 있고, 스마트 컨트랙트로 메시지 기반의 로직을 프로그래밍할 수 있다. 멤버십도 MemberCap과 CreatorCap이라는 온체인 객체로 관리되어, 권한 검증이 프로토콜 수준에서 이루어졌다.
수이는 chatty.wal.app이라는, 실제 동작하는 데모 앱을 제공했고, 이를 통해 개발자 관심을 끌어왔다. 그러나 알파 버전을 실제로 사용해본 개발자들은 확장성 한계를 맞이했다. 수이 블로그에서도 이를 직접적으로 언급하고 있다.
모든 메시지가 트랜잭션이어야 하는가?
체인을 압도하지 않으면서 실시간 채팅을 어떻게 전달하는가?
수백만 건의 메시지로 확장될 수 있는 앱의 비용을 어떻게 예측 가능하게 유지하는가?
중앙화된 백업 없이 크로스 디바이스 복원을 어떻게 지원하는가?
게임 길드 채팅이 초당 수십 건의 메시지를 발생시키는 상황을 생각해보면, 각 메시지를 온체인 트랜잭션으로 처리하는 것은 비용과 지연 시간 모두에서 현실적이지 않다. 이 질문들은 결국 웹3 메시징의 근본적인 트레이드오프를 드러낸다. 완전한 온체인 메시징은 검증 가능하지만 느리고 비싸다. 완전한 오프체인 메시징은 빠르지만 기존 중앙화 서비스와 다를 게 없다.
2. 베타 아키텍처: 무엇을 온체인에 두고, 무엇을 빼는가
베타의 답은 "전부 온체인"도 "전부 오프체인"도 아닌, 책임의 분리다. 세 개의 컴포넌트가 각자의 역할을 맡는다.
그룹(Groups) SDK - 수이 온체인: 채널 생성, 멤버십, 권한, 설정을 관리한다. 채널의 상태는 온체인에 존재하여, 누가 어떤 채널에 접근할 수 있는지가 검증 가능하고 스마트 컨트랙트로 강제할 수 있다. 핵심은 여기서 관리하는 것이 "메시지 자체"가 아니라 "멤버십과 권한"이라는 점이다. 알파의
MemberCap/CreatorCap모델이 여기에 해당한다.백엔드 릴레이어(Backend Relayer) - 오프체인: 베타 버전에서 가장 큰 변화가 일어난 지점으로, 실시간 메시지 교환을 처리한다. 개별 메시지를 트랜잭션으로 쓰는 대신, 릴레이어가 수이 풀노드에서 gRPC로 멤버십 데이터를 가져와 검증하고, 메시지를 전달한다. 알파에서
sendMessage가 수이 트랜잭션을 빌드했던 것과 달리, 베타에서는 릴레이어가 이 과정을 대신한다. 릴레이어는 일반 서비스로 운영하거나, 노틸러스(Nautilus)를 사용해 TEE(Trusted Execution Environment, 신뢰실행환경) 안에서 실행할 수 있다. 메시지는 주기적으로 월루스에 백업된다.메시징 SDK - 통합 레이어: 개발자가 직접 다루는 인터페이스다. 권한 그룹과 릴레이어를 추상화하면서, Seal 암호화, 월루스를 통한 첨부파일 저장과 메시지 복원을 처리한다.
한 문장으로 요약하자면, 베타 버전에서 멤버십은 온체인, 메시지는 오프체인, 백업과 첨부파일은 탈중앙 스토리지를 통해 관리된다.
3. 암호화 모델: 릴레이어로 부터의 평문 보호
베타의 암호화 모델에서 주목할 점은, 메시지 전달의 상당 부분이 오프체인 릴레이어를 거치지만, 릴레이어가 메시지 내용을 볼 수 없다는 것이다.
알파의 메시지 타입을 보면 암호화 구조가 드러난다.
모든 메시지와 첨부파일은 Seal로 암호화된 후 클라이언트를 떠난다. 릴레이어는 암호문만 다룬다. 첨부파일은 클라이언트 측에서 암호화되어 월루스에 저장되고, 메시지는 주기적으로 월루스에 아카이빙된다. 복호화 권한은 채널 멤버십이 제어하는데, 이 멤버십이 온체인(Groups SDK)에서 관리되므로 접근 제어 자체는 검증 가능하다.
이 구조가 의미하는 것은, 릴레이어를 신뢰하지 않아도 메시지 보안이 유지된다는 점이다. 릴레이어가 해킹당하거나 악의적으로 행동하더라도 메시지 내용은 노출되지 않는다. 릴레이어를 TEE에서 실행하면 메타데이터 수준의 보호까지 추가된다.
다만 알파에서는 메시지 자체가 온체인 수이 객체였기 때문에 "이 메시지가 존재한다"는 사실까지 온체인에서 증명 가능했던 반면, 베타에서는 이 속성이 월루스의 주기적 아카이빙으로 대체된다. 개별 메시지의 실시간 온체인 증명은 사라졌지만, 아카이브 단위의 탈중앙 저장과 가용성 보장은 유지된다. 이것이 확장성을 위해 지불한 트레이드오프다.
4. 프로그래머블 메시징이라는 방향
이 SDK가 궁극적으로 목표하는 것은 채팅 UI가 아니라 "프로그래머블한 통신 인프라"이며, 그룹 SDK가 독립적으로 사용 가능하다는 것이 이 방향을 뒷받침한다. 채널 멤버십과 권한이 수이 스마트 컨트랙트로 관리되므로, 멤버 추가 하나에도 온체인 권한 검증이 따라붙는다.
CreatorCap을 가진 주소만 멤버를 추가할 수 있고, 추가된 멤버에게는 MemberCap이 발급된다. 이 모든 것이 수이 객체이므로, "누가 이 채널의 멤버인가"는 온체인에서 누구나 검증할 수 있다. 이를 기반으로 다음과 같은 시나리오가 코드 수준에서 가능해진다.
특정 NFT를 보유한 사용자만 입장 가능한 토큰 게이팅 채널
거버넌스 투표 결과에 따라 자동으로 생성/해산되는 논의 채널
AI 에이전트가 암호화된 채널 안에서 다른 에이전트나 사용자와 통신
온체인 이벤트(거래 확인, 청산 알림 등)가 트리거하는 메시지 플로우
프로토콜 간 크로스앱 조율
기존의 텔레그램이나 디스코드 기반 커뮤니케이션에서는, 접근 제어가 앱 레벨에서 API 키나 봇 권한으로 관리된다. 수이 기반에서는 접근 제어가 온체인 상태에 연동되어 스마트 컨트랙트로 강제되므로, 메시징 로직을 앱의 비즈니스 로직과 같은 검증 가능한 레이어에서 다룰 수 있다.
5. 어떻게 봐야할까
메시징 SDK의 알파에서 베타로의 전환은, 웹3 메시징이라는 카테고리 자체가 아직 최적의 설계를 찾아가는 과정에 있다는 것을 보여준다. 모든 것을 온체인에 올린다는 알파의 나이브한 접근이 실제 사용에서 부딪힌 한계를 인정하고, 하이브리드 모델로 재설계한 것은 솔직한 엔지니어링 판단이다.
베타가 제시하는 "멤버십은 온체인, 메시지는 오프체인, 저장은 탈중앙" 패턴은 웹3 메시징의 현실적인 설계 기준점이 될 수 있다. 완전한 온체인 메시징의 이상과 실시간 커뮤니케이션의 현실 사이에서, 어디에 선을 긋는 것이 맞는지를 고민한 결과물이다. 이 선이 올바른 위치에 그어졌는지는 실제 프로덕션 앱들이 이 위에서 구축되면서 검증될 것이다.
한가지 의문점은, 메시지 전달의 가용성이 릴레이어 운영에 의존하지 않는가에 대한 것이다. 셀프 호스팅과 TEE 실행이 지원되지만, 대부분의 앱에서는 결국 누군가가 릴레이어를 운영해야 한다. 또한 월루스 아카이빙이 주기적이라는 것은, 아카이빙 주기 사이에 릴레이어가 다운되면 그 구간의 메시지가 유실될 수 있다는 뜻이기도 하다. 이러한 사항들에 대해서는 추후 업데이트를 통해 지켜보아야할 것으로 보인다.
