디스플레이 V2는 NFT와 온체인 오브젝트가 지갑, 익스플로러, 마켓플레이스 어디서든 동일하게 보이도록 하는 수이의 프로토콜 레벨 렌더링 시스템의 대규모 재설계다. 타입당 하나의 디스플레이만 존재하도록 강제하여, 기존에 "어떤 디스플레이가 진짜인가"를 판별해야 했던 문제를 근본적으로 해결했다.
이번 변경은 수이가 데이터 인프라 전체를 JSON-RPC에서 gRPC/GraphQL로 전환하는 큰 그림의 일부다. 기존 방식으로는 새 인프라에서 디스플레이가 아예 동작하지 않았기 때문에, V2의 도입은 선택이 아닌 필수였다. 디스플레이 V1과 JSON-RPC 모두 2026년 7월에 지원이 종료된다.
V2는 컬렉션 데이터, 자식 오브젝트, 기본값 등 기존에 오프체인 서비스 없이는 불가능했던 정보를 템플릿에서 직접 표현할 수 있게 했다. 빌더들이 이를 활용하기 시작하면, 지갑 화면에서 볼 수 있는 NFT 정보의 풍부함이 지금과는 달라질 수 있다.
이더리움이나 솔라나에서 NFT를 하나 민팅한 뒤, 지갑에서 확인하면 이미지가 잘 뜨지만, 마켓플레이스로 가져가면 이름이 빠져있거나 설명이 아예 다르게 나오는 경험을 다들 해보았을 것이다. 대부분의 블록체인에서 이런 일은 매우 흔하게 발생하며, 이는 NFT의 "보여지는 방식"이 체인이 아니라 각 플랫폼의 메타데이터 API, 서드파티 서비스, 혹은 암묵적 컨벤션에 의존하기 때문이다.
수이(Sui)의 디스플레이(Display)는 이 문제를 프로토콜 레벨에서 풀려는 시도였다. 오브젝트가 어떻게 렌더링될지를 온체인에서 직접 정의하여, 어느 지갑이든 익스플로러든 동일한 결과를 보여주겠다는 구상이다. Sui v1.68과 함께 출시된 디스플레이 V2는 이 시스템의 첫 번째 대규모 재설계인데, 이는 단순히 수이 디스플레이에 기능이 추가됐다기보다는 수이 인프라 스택 전체가 움직이고 있는 맥락에서 읽어야 그 온전한 의미를 파악할 수 있다.
디스플레이는 "이 타입의 오브젝트는 이렇게 보여줘라"고 네트워크에 등록하는 온체인 오브젝트다. 창작자는 NFT 컬렉션을 만들 때, Display<T>를 생성하여 name, image_url, description 같은 필드를 템플릿으로 정의한다. 이후 지갑이나 익스플로러가 해당 오브젝트를 조회하면, 이 템플릿에 온체인 데이터가 대입되며 렌더링이 진행된다.
우선, V1의 Display<T> 구조체를 살펴보자.
fields에 키-값 쌍으로 템플릿을 저장하는 단순한 구조다. 예를 들어 image_url 필드에 "<https://api.capy.art/capy/{id}/svg>"를 넣으면, 각 오브젝트의 id 값이 자동으로 삽입된다. 핵심은 이것이 온체인에 존재하고, 타입 소유자에 의해 제어되기에 외부 메타데이터 서비스가 필요 없다는 것이다.
다른 체인에서는 이런 기능을 프로토콜이 아니라 생태계에 맡긴다. ERC-721의 tokenURI가 대표적인데, NFT의 메타데이터에 있는 URI가 가리키는 서버가 다운되면 NFT 이미지도 사라진다. 수이는 이걸 네트워크가 직접 관리하겠다는 입장을 취한 것이고, 디스플레이는 그 구현체이다.
개념은 좋았지만, V1의 구현에는 실용적 한계가 있었다.
첫 번째 문제로, 같은 타입에 디스플레이가 여러 개 존재할 수 있었다. V1에서 디스플레이는 Publisher 권한만 있으면 누구나 몇 개든 만들 수 있었다. 디스플레이가 생성될 때 발행되는 이벤트를 보면 이 구조가 드러난다.
코드 원문에서 표현되듯, 지갑이나 익스플로러가 어떤 타입의 디스플레이를 찾으려면 과거 이벤트 히스토리를 뒤져야 했다. 디스플레이가 하나뿐이라는 보장이 없으니, 여러 개가 나오면 어떤 것이 원본인지 클라이언트가 알아서 판단해야 했다.
두 번째 문제는 이러한 이벤트 스캐닝 방식이 수이의 새 인프라와 호환되지 않는다는 것이다. 수이는 현재 데이터 접근 레이어를 JSON-RPC에서 gRPC와 GraphQL로 전환하고 있다.
JSON-RPC는 텍스트 기반 JSON으로 데이터를 직렬화하고, 요청-응답 구조에 의존하며, 느슨한 타입을 사용한다. 수이처럼 대량의 오브젝트 상태를 빠르게 조회해야 하는 환경에서 이 세 가지는 모두 병목이 된다. gRPC는 Protocol Buffers 바이너리 직렬화로 3~10배 빠른 성능을 제공하고, 서버 사이드 스트리밍을 네이티브로 지원해 폴링 없이 실시간 데이터를 받을 수 있으며, .proto 파일 기반의 강타입 인터페이스로 컴파일 타임에 에러를 잡을 수 있다. GraphQL도 필요한 필드만 정확히 쿼리할 수 있어 오버페칭을 줄여준다. 수이가 JSON-RPC를 버리는 것은 단순한 기술 트렌드를 좇는 것이 아니라, 오브젝트 중심 블록체인에서 데이터 접근 자체를 근본적으로 개선하려는 판단이다.
문제는, 이 새로운 gRPC 환경에서 히스토리컬 이벤트를 스캔하는 것은 설계 자체가 맞지 않는다는 점이다. gRPC는 상태 조회와 실시간 스트리밍에 최적화되어 있지, 과거 이벤트를 뒤지는 용도로 만들어진 것이 아니다. 실제로 gRPC에서는 디스플레이 렌더링 자체가 불가능했다.
세 번째 문제는 템플릿이 너무 단순하다는 것이다. 현재의 디스플레이는 오브젝트의 최상위 필드만 참조할 수 있다. 속성 목록이나 맵, 동적 영역 같은 구조화된 데이터는 템플릿에서 접근할 수 없어서, 결국 오프체인 서비스를 만들어야 했다. 온체인에서 메타데이터를 관리하겠다는 디스플레이의 취지가 오프체인 우회로 인해 희석되는 아이러니가 발생한 것이다.
V2에서 가장 근본적인 변화는 디스플레이가 더 이상 아무데나 생성되는 일반 오브젝트가 아니라, 글로벌 레지스트리에서 결정론적으로 도출되는 오브젝트가 되었다는 것이다. 필자는 object.move에서 이 레지스트리의 싱글톤 주소를 확인할 수 있었다.
DisplayRegistry는 주소 @0xd에 고정된 싱글톤 오브젝트다. V2에서 Display<T>의 ID는 이 레지스트리의 UID와 타입 T를 조합하여 결정론적으로 도출된다. 이것은 수이의 Derived Object 패턴을 활용한 것으로, (DisplayRegistry UID, DisplayKey<T>) 조합으로부터 유일한 ID가 계산된다.
V1에서는 디스플레이 생성 시 object::new(ctx)로 일반 UID를 만들었기 때문에, ID가 트랜잭션 컨텍스트에 의존해 비결정론적으로 생성되었다.
V2에서는 레지스트리로부터 ID가 파생되므로, 같은 타입 T에 대해 항상 같은 ID가 도출된다. 따라서 클라이언트가 이벤트를 스캔하거나, 어떤 디스플레이가 정본인지 고민하는 등의 부가적인 노력을 필요로 하지 않는다.
이것이 왜 사용자에게도 중요한가? 지갑이 NFT를 표시할 때, V1에서는 이벤트 히스토리를 뒤져야 했기 때문에 속도가 느리거나, 풀노드가 히스토리를 보관하지 않으면 아예 디스플레이를 찾지 못할 수 있었다. V2에서는 ID를 즉시 계산할 수 있으므로 디스플레이 조회가 빠르고 확실해진다. gRPC에서 처음으로 디스플레이 렌더링이 가능해진 것도 이 결정론적 룩업 덕분이다.
V2는 템플릿이 표현할 수 있는 범위도 크게 넓혔다.
컬렉션 접근: 벡터, 셋, 맵 등 오브젝트에 저장된 구조화된 데이터를 템플릿에서 직접 참조할 수 있다. 예를 들어, 트레이트 목록을 가진 NFT에서 특정 트레이트만 골라 표시하는 것이 오프체인 서비스 없이 가능해졌다.
외부 오브젝트 로딩: 다이나믹 필드나 관련 오브젝트를 디스플레이 해석 과정에서 불러올 수 있다. 게임 아이템에 장착된 장비(자식 오브젝트)의 정보를 디스플레이에서 직접 보여주는 식이다.
기본값(default): {{image_url}} | <default_image> 형태로, 필드가 없거나 비어 있을 때 폴백을 정의할 수 있다. 누락된 이미지 대신 기본 이미지가 표시되므로, 지갑에서 "이미지 없음"으로 뜨는 상황이 줄어든다.
이 세 가지 변경을 합치면, 빌더가 이전에 오프체인에서 별도로 만들어야 했던 메타데이터 서비스의 상당 부분이 불필요해진다. 사용자 입장에서는 NFT나 온체인 오브젝트의 시각적 정보가 더 풍부하고 일관되게 표시될 것으로 기대할 수 있다.
기존 V1 디스플레이는 시스템 스냅샷을 통해 V2로 자동 마이그레이션되었다. 기존에 지갑이나 마켓플레이스에서 보이던 NFT 표시가 깨지거나 바뀌는 일은 없다.
V2의 디스플레이 수정 권한은 DisplayCap<T>라는 별도의 권한으로 분리되었다. 기존 Publisher 오브젝트로 클레임하거나, 레거시 V1 디스플레이를 소각하며 클레임할 수 있다. 새 패키지에서는 sui::display 대신 sui::display_registry를 사용한다.
2026년 7월 31일 이후로 V1 API는 호출할 수 없게 되며, 이 시점은 JSON-RPC의 지원 종료와 동일하다.
디스플레이 V2만을 떼어놓고 본다면, 이번 업그레이드는 단순한 NFT 메타데이터 시스템의 개선 정도로 읽힐 수 있다. 하지만 이것은 수이가 진행 중인 더 큰 전환의 한 조각이다.
수이는 현재 데이터 접근 인프라 전체를 JSON-RPC에서 gRPC와 GraphQL로 재편하고 있다. 텍스트 기반 직렬화의 성능 한계, 폴링에 의존하는 실시간 데이터 접근의 비효율, 느슨한 타입으로 인한 런타임 에러 가능성을 바이너리 직렬화, 네이티브 스트리밍, 강타입 인터페이스로 대체하려는 것이다. JSON-RPC 지원 종료 시점이 2026년 7월로 예고되어 있고, 디스플레이 V1의 종료 시점도 이에 맞춰져 있다. 디스플레이 V2가 이벤트 스캐닝을 버리고 결정론적 룩업을 도입한 것은 이 인프라 전환의 전제 조건이었다. 새 데이터 스택에서 오브젝트 렌더링이 동작하려면, 이벤트 히스토리에 의존하는 V1의 구조로는 불가능했기 때문이다.
사용자 입장에서 당장 체감할 변화는 크지 않을 수 있다. 기존 NFT의 표시가 바뀌는 것은 아니기 때문이다. 하지만 빌더들이 V2의 확장된 템플릿을 활용하기 시작하면, NFT와 온체인 오브젝트가 보여줄 수 있는 정보의 풍부함이 달라질 수 있다. 다이나믹 필드, 자식 오브젝트, 컬렉션 데이터까지 디스플레이에서 직접 표현할 수 있으니, 지금까지 별도 웹페이지나 외부 서비스에서만 볼 수 있었던 정보가 지갑 화면 안으로 들어올 수 있는 것이다.
한편, 프로토콜이 오브젝트의 렌더링 방식에까지 의견을 갖는 것은 수이만의 독특한 선택이라는 점도 짚을 필요가 있다. 이더리움이나 솔라나에서 NFT가 어떻게 보이는지는 전적으로 생태계의 몫이다. tokenURI가 가리키는 곳에 무엇을 넣든, 마켓플레이스가 그것을 어떻게 해석하든 프로토콜은 관여하지 않는다. 이 방식은 유연하지만, 앞서 언급했듯 플랫폼 간 불일치와 외부 서비스 의존이라는 비용을 치른다. 수이는 반대 방향을 택했다. 네트워크가 렌더링 표준을 제공하고, V2에서는 아예 타입당 하나의 디스플레이를 강제한다. 이것은 일관성을 확보하는 대신 유연성을 일부 포기하는 트레이드오프다. 빌더가 같은 타입에 대해 컨텍스트별로 다른 표시 방식을 원할 경우(예: 마켓플레이스용과 게임 내 표시를 다르게 하고 싶을 때), V2의 "타입당 하나" 모델이 제약이 될 수도 있다. 이 설계가 장기적으로 생태계의 다양성을 제한하지 않는지는 지켜봐야 할 부분이다.
Sui
Pharos
Solana
Ethereum