MUD 인덱서는 잘못된 설계인가?
글: ck, MetaCat
서론
이 글의 제목을 자극적으로 붙인 것은 아니다. 최근 MUD 프레임워크(보다 정확히는 프레임워크라기보다 '프레임워크적 구조')를 사용하면서 느낀 솔직한 생각이다. 우선 결론부터 말하자면 MUD Indexer는 최악은 아닌 설계라고 판단된다. 이 글에서는 이 결론을 자세히 설명하고, 더 나은 대안이 있는지 탐색해보려 한다. 아직 만족할 만한 답을 찾지는 못했고, 매우 초보적인 논의에 불과하지만, 이러한 생각들을 기록으로 남겨 혹시 모를 영감을 주고자 한다.
출처: https://mud.dev/
데이터베이스 중심 설계
「완전 체인 기반 2048: 우리가 MUD 엔진 사용에서 배운 것」에서 언급했듯이, MUD 프레임워크는 「데이터베이스 중심」 사상을 따르고 있다. MUD 프레임워크 안에서 이야기의 중심은 블록체인 상 데이터의 읽기와 쓰기에 있으며, 데이터 쓰기는 Store가 담당하고, 데이터 읽기는 주로 Indexer가 담당한다.여기서 ‘주로’라는 표현을 쓴 이유는, 체인 내 데이터 읽기는 Store가 수행하지만, 체인 외부(클라이언트)에서의 데이터 읽기는 Indexer가 맡기 때문이다.
출처: https://mud.dev/introduction
사용자의 대기 시간
Indexer는 본질적으로 블록체인 상 데이터(관계형 데이터베이스 형태로 존재)의 클라이언트 복제본이다. 브라우저 기반 DApp 환경에서는 이 말이 곧, 페이지를 새로고침할 때마다 클라이언트 측 데이터 복제본을 매번 다시 생성해야 한다는 의미다. 데이터가 ‘체인 방식’으로 저장되기 때문에 시간이 지날수록 복제본 생성에 필요한 시간도 증가하며, 결과적으로 사용자가 기다리는 시간도 늘어나고 사용자 경험(UX)은 점점 나빠진다.
출처: https://www.mud2048.fun/
예를 들어 mud2048.fun의 경우 현재 약 10~20초 정도 기다려야 게임 메인 화면에 진입할 수 있는데, 이런 경험은 정말 참기 힘들다.본문은 여기서 출발하여 MUD Indexer 설계의 장단점을 분석하고, 개선 가능성을 살펴본 후, 블록체인 애플리케이션 개발 프레임워크가 데이터 읽기/쓰기 패턴을 어떻게 설계해야 할지를 논의하고자 한다.
현재 이더리움 레이어 2(Layer 2) 기반 앱의 폭발적 성장이 기대되는 상황에서 이러한 논의는 상당한 현실적 의미를 갖는다.심지어 레이어 2 앱의 폭발 여부를 결정하는 '근원적 문제'라 할 수 있다. 만약 이 문제가 해결된다면 이더리움 레이어 2 앱 폭발을 가로막는 인프라 장벽이 사라지고, 이후 단지 새로운 서비스 모델 혁신만 있으면 된다.
MUD Store는 체인 상 데이터 기록의 더 나은 방법
Store는 Solidity 기본 데이터 패키징(Data Packaging) 방식보다 더욱 압축된 데이터 기록 방식을 제공하므로, 저장 비용이 낮아진다. 또한 체인 상 데이터 저장을 소프트웨어 엔지니어링 분야에서 이미 충분히 검증된 관계형 데이터베이스로 ‘매핑’함으로써 개발자에게 친숙하게 다가간다.따라서 Solidity 기본 데이터 기록 방식과 비교하면, Store는 더 나은 선택이다. 다만 이로 인해 일정 부분 데이터 읽기 효율 문제가 발생하는데, 타골이 말했듯이 "최고의 것은 홀로 오지 않는다. 모든 것을 동반하여 온다 :)"
출처: https://mud.dev/store/tables
이러한 데이터 기록 방식, 즉 데이터를 블록체인에 기록하는 방식은 데이터 읽기/쿼리에 다음과 같은 두 가지 경로만 가능하게 만든다:
첫 번째 경로: 체인 상에서 직접 읽기. 단점은 속도가 느리며 복잡한 쿼리를 지원하지 못한다.
두 번째 경로: 체인 상 데이터를 체인 외부로 복사하여, 그곳에서 복잡한 쿼리를 수행(MUD가 채택한 방식). 그러나 이 방식도 동시에 두 가지 문제를 야기한다:
1> 시간이 지날수록 데이터 복사 동기화에 필요한 시간이 계속 늘어나 사용자 경험(UX)이 점점 나빠진다;
2> 각 클라이언트 복제본마다 전체 범위 쿼리/연산(예: 순위표 계산)을 반복 수행하여 자원 낭비가 발생한다.
mud2048.fun 개발 중 우리는 첫 번째 문제에 대해 MUD 팀과 간단히 논의했으며 임시적인 해결책을 도출했지만, 근본적인 해결은 되지 못했다. 아래 이미지의 빨간 박스 부분이 MUD 프레임워크 내장된 체인 데이터 복사 과정이다.
출처: https://www.mud2048.fun/
궁극적 질문: 완전 체인 기반 앱은 어떻게 효율적인 데이터 읽기를 실현할 수 있는가?
인터넷 제품 발전 역사에서 알 수 있듯이, 대부분 제품의 90% 이상은 데이터 읽기 작업이며, 데이터 기록은 10% 미만이다. 따라서 효율적인 데이터 읽기 방식은 곧바로 제품의 사용자 경험을 결정한다.
블록체인 분야에서는 이와 유사한 개념으로 「데이터 가용성 계층」(Data Availability Layer)이 있다.비록 동일한 차원의 문제는 아니지만, 현재 고민하는 문제의 해법을 생각하는 데 어느 정도 도움이 될 듯하여 참고해보고자 한다.
출처: https://www.alchemy.com/overviews/data-availability-layer
블록체인 분야에서 일반적인 DA(Data Availability) 방식은 대략 두 가지로 나뉜다: 체인 상 DA와 체인 외부 DA. 비트코인 인스크립션은 체인 상 DA 방식에 해당한다(데이터는 비트코인 블록체인에 저장되지만 해석은 체인 외부에서 이루어짐). 반면 이더리움 레이어 2는 체인 외부 DA 방식인데, ZK 롤업과 OP 롤업은 이더리움 레이어 1에 CALLDATA 형식으로 데이터를 저장한다. 두 방식 모두 아직 경쟁 중이며 명확한 승자가 없는 상태인데, 이는 우리가 현재 문제의 해법을 고민하는 데 있어 긍정적·부정적 양면의 참고 사례를 제공한다.
Web2 방식을 그대로 적용할 수 없다
Web2 분야에서는 데이터베이스 읽기 성능이 부족할 경우, 데이터베이스 앞에 캐시 계층(Cache)을 추가하거나 여러 개의 데이터베이스 슬레이브를 통해 읽기 성능을 높이는 방법을 사용한다.
전형적인 Web2 서비스 아키텍처. 출처: https://smartbuilds.io/scaling-web3-social-media-blockchain-cache-layer/
그러나 블록체인 분야에서는 이러한 방식들이 현재로서는 모두 통하지 않는다. 서비스 제공 방식이 중앙집중형에서 탈중앙형으로 바뀌었고, 데이터 저장 방식도 구조화 저장에서 체인 방식 저장으로 변화했기 때문이다. 이러한 기반 설계의 변화는 상위 계층 솔루션 역시 함께 변화해야 함을 의미하지만, 아직 블록체인을 위한 ‘캐시’ 또는 ‘슬레이브 데이터베이스’에 해당하는 솔루션은 등장하지 않았다.
Web2 캐시 방식을 참고한 DApp 사례도 있지만, 보편성이 떨어진다. MUD 프레임워크 관점에서 보면 그러한 방식은 오히려 더 많은 중앙집중화 요소를 도입하므로 이상적이지 않다.
캐시 방식을 통합한 DApp 아키텍처. 출처: https://smartbuilds.io/scaling-web3-social-media-blockchain-cache-layer/
Indexer는 최악은 아닌 해결책
MUD 자체만 놓고 보면 이미 앱 체인 분야에서 큰 진전이다. 세 가지 문제를 동시에 해결했기 때문이다:
1> 스마트 계약 내 데이터와 로직이 결합되어 로직 업그레이드가 어려운 문제
2> 체인과 클라이언트 사이에 데이터 동기화 메커니즘이 없어 데이터 상태 불일치 문제
3> 블록체인에 통합된 접근 제어 메커니즘이 부족하여 중복 작업과 상호 운용성 장애 발생 문제
MUD가 데이터 읽기 문제를 해결하기 위해 선택한 방식은, 클라이언트 측에 특정 계약 데이터만을 관리하는 ‘풀 노드’를 배치하는 것이다. MUD 공식적으로 이를 「네임스페이스 기반 풀 노드(Namespaced Full-node)」라고 부르며, 우리가 말하는 Indexer가 바로 이것이다.
출처: https://youtu.be/tLGdup5wmck?si=ykgQ4qwut4VLgimF
앱 체인 분야에서 이 방식은 ‘무(無)에서 유(有)’를 만들어낸 것이며, 분명히 큰 진전이다. 완벽하지는 않지만, 나쁜 시작은 아니다. 후속 세대는 이러한 거인의 어깨 위에 서서 더 나은 해법을 찾아갈 수 있을 것이다.요약하자면, MUD Indexer는 최악은 아닌 설계이지만, 우리는 여전히 더 나은 것을 필요로 한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
