이동 쌍둥이자리: 수이와 앱토스가 블록체인 환경에 도전하는 방법

소개duction

최근에는 시장이 크게 냉각되어 업계 베테랑들조차도 업계의 존재 목적에 의문을 제기하고 있습니다. 제 개인적인 생각을 몇 가지 말씀드리고자 합니다: 저는 과거의 많은 위대한 비전들이 처음부터 논리적으로 일관성이 없었기 때문에 “증명되지 않았다”고 생각합니다.

비금융 디앱은 종종 탈중앙화를 강조하여 제품 자체가 충분하지 않다는 사실을 은폐하려고 합니다. 실제로는 구글, 트위터, 유튜브는 불신하고 대신 다중 서명 지갑과 단일 서버 설정이 안전하다고 믿으라고 요구합니다.

많은 비전이 증명되지는 않았지만 진정한 검증을 받지 못했습니다. 저는 여전히 대부분의 비전이 거창하지는 않더라도 의미가 있으며, 이를 뒷받침할 수 있는 탄탄한 기반이 필요할 뿐이라고 믿습니다. 결국에는 탈중앙화 또는 웹2.0에 필적하는 사용자 경험 중 적어도 하나는 제공될 수 있을 것입니다.

TON과 솔라나가 한때 과소평가되었지만 지금은 여러 측면에서 전임자를 따라잡고 있는 것처럼 말이죠. 애플리케이션을 지원하는 퍼블릭 체인에는 혁신이 필요하며, 이는 매 주기마다 업계 발전을 이끌고 있습니다. 그래서 오늘은 오랫동안 간과되어 왔던 퍼블릭 체인의 한 유형인 무브 생태계에 대해 살펴보겠습니다.

1. 이동

Move 프로그래밍 언어는 원래 메타의 메타버스 비전을 위한 기반으로서 보다 안정적이고 규제된 스테이블코인을 개발하기 위해 중단된 프로젝트인 디엠(초기에는 리브라라고 불렸습니다)을 위해 만들어졌습니다.

그러나 이 프로젝트는 전 세계 규제 당국의 강력한 반대와 지속적인 압력에 직면했습니다. 규제 당국은 Diem의 규모와 Facebook의 방대한 사용자 기반이 금융 안정성, 통화 정책, 데이터 프라이버시를 위협할 수 있다고 우려했습니다. 바이든 행정부가 압력을 가하는 과정에서 결국 메타는 Diem 프로젝트를 포기할 수밖에 없었습니다.

다행히도 디엠의 핵심은 버려지지 않았습니다. 원래 팀에서 분리된 여러 파벌이 계속해서 무브를 탐구하고 발전시켜 오늘날 우리가 알고 있는 무브의 쌍둥이인 수이와 앱토스로 진화했습니다. 또한, 무브에서 영감을 받은 Rust 기반 블록체인인 리네라와 최근 추진 중인 무브먼트와 같은 다른 프로젝트도 아직 초기 단계에 있습니다.

중단된 프로젝트의 잔영이 왜 그렇게 큰 영향을 미쳤나요? 선도적인 웹2.0 기업이 개발한 블록체인 프로그래밍 언어인 Move는 탄탄한 기반을 갖추고 있습니다. 기존 블록체인 언어, 특히 솔리디티에 만연한 성능과 보안 문제를 해결하는 데 중점을 두고 설계되었습니다. 설계 목표는 자산 관리와 접근 제어에 적합한 유형 시스템을 만드는 것이었습니다. 핵심 사항을 요약하면 다음과 같습니다:

• 보안: 정적 유형 검사 및 리소스 관리를 사용하여 오버플로 오류 및 재진입 공격과 같은 일반적인 취약성을 방지하는 등 보안을 우선시하는 설계를 채택하고 있습니다. 다른 언어 가상 머신에 비해 Move는 아래 Nansen의 비교에서 볼 수 있듯이 다양한 보안 기능을 지원합니다.
  
• 구성 가능성: Move는 모듈성과 구성 가능성을 지원하여 개발자가 다양한 스마트 컨트랙트를 쉽게 만들고 결합하여 더 복잡한 애플리케이션을 구축할 수 있도록 합니다.
• 성능: Move의 가상 머신이 최적화(병렬 처리, 메모리 관리, 컴파일러 최적화 지원)되어 스마트 컨트랙트를 효율적으로 실행하고 트랜잭션 속도와 처리량을 향상시켰습니다.

모듈형 EVM 체인으로 포화 상태인 시장에서 무브는 다른 것을 시도하는 용감한 프로젝트입니다. 많은 퍼블릭 체인 프로젝트의 소개에서 비슷한 주장을 접하셨겠지만, 이러한 개념을 제대로 이해하려면 직접 경험해 보시는 것이 좋습니다.

2. Sui

2.1 아키텍처

무브 쌍둥이 중 하나인 수이는 초기에 에어드랍 및 토큰 릴리스 메커니즘과 관련된 문제로 비판에 직면했습니다. 그러나 이러한 문제를 제쳐두고 프로젝트 자체에만 집중한 수이는 특히 게임 부문에서 성능과 사용자 경험 모두에서 우수성을 입증했습니다.

이러한 성공은 주류 채택을 위해 특별히 개선된 아키텍처와 밀접한 관련이 있습니다. 다음은 Sui의 아키텍처 혁신에 대한 간략한 개요입니다:

1. 오브젝트 스토리지 모델: 이 구성 요소는 이동에 대한 Sui의 향상된 기능의 핵심입니다. 객체 스토리지 모델은 데이터를 각각 고유 식별자를 가진 개별 객체로 저장합니다. 기존 데이터베이스 시스템과 달리 객체 스토리지 모델은 고정된 데이터 구조가 없으며 텍스트, 이미지, 동영상, 오디오 등 다양한 데이터 유형을 저장할 수 있습니다. 이 모델은 병렬 실행과 수평적 확장(노드를 추가하여 스토리지 용량을 확장하는 것)이 가능합니다. Sui의 설계는 이 모델을 중심으로 이루어졌습니다.
2. 인과 관계 순서: 데이터 충돌과 불일치를 피하면서 인과 관계를 존중하는 순서로 트랜잭션이 실행되도록 보장합니다. 이를 통해 Sui는 데이터 일관성을 유지하면서 대량의 동시 트랜잭션을 처리할 수 있습니다.
3. 일각고래와 불상어 합의 엔진: Sui는 합의 엔진으로 고래고래와 불샤크를 사용합니다. Narwhal은 로컬 트랜잭션 풀을 유지하고, 인과 관계에 따라 트랜잭션을 정렬하고, 이를 브로드캐스트함으로써 트랜잭션 순서 지정 및 유효성 검사를 담당합니다. Bullshark는 Narwhal로부터 정렬된 트랜잭션 목록을 받으면 비잔틴 장애 허용(BFT) 합의를 사용하여 목록에 투표하여 모든 노드가 트랜잭션 순서에 동의하는지 확인합니다.
4. 수이 무브: Sui가 NFT 지원, 자산 관리, 데이터 저장 등의 새로운 기능을 추가하여 Move 언어를 확장합니다.
5. 수이 프레임워크: Sui는 개발자가 애플리케이션을 빠르게 구축하고 배포하는 데 도움이 되는 완벽한 프레임워크를 제공하며, 여기에는 Sui 지갑, Sui SDK, Sui CLI와 같은 도구 및 라이브러리가 포함됩니다.

Sui의 아키텍처는 빠른 속도, 낮은 수수료, 보안을 유지하면서 대량의 동시 트랜잭션을 처리할 수 있습니다. 또한 Move 언어와 Sui 프레임워크는 개발자에게 안전하고 확장 가능하며 사용자 친화적인 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

2.2 합의

수이 블록체인은 짧은 지연 시간과 높은 처리량을 위해 설계된 비잔틴 장애 허용(BFT) 합의인 미스티세티라는 합의 메커니즘을 사용합니다.

미스틱티는 여러 검증자가 동시에 블록을 제안할 수 있어 네트워크 대역폭을 최대한 활용하고 검열에 대한 저항력을 제공합니다. 또한, 이 프로토콜은 방향성 비순환 그래프(DAG)에서 블록을 완성하는 데 세 번의 메시지 라운드만 필요하며, 이는 pBFT와 마찬가지로 이론적 최소값과 일치합니다.

제출 규칙은 병렬 투표와 블록 리더 인증을 허용하여 중간값과 꼬리값 지연 시간을 더욱 줄여줍니다. 또한 제출 규칙은 지연 시간을 크게 늘리지 않고 리더를 사용할 수 없는 상황도 허용합니다.

미스틱티는 수이 메인넷 출시 전 3개월 동안 테스트넷에서 운영되었으며, 지연 시간이 80% 감소하는 등 상당한 성과를 보였습니다. 이제 Sui 네트워크는 초당 수만 건의 트랜잭션을 처리할 수 있으며, 엔드투엔드 지연 시간은 1초 미만입니다.

또한 Sui 블록체인은 위임 지분 증명(DPoS)이라는 특정 유형의 지분 증명(PoS) 합의를 사용합니다. 공유 객체와 관련된 트랜잭션(복합 트랜잭션이라고 함)이 발생할 때, Sui는 앞서 언급한 일각고래와 불샤크 합의 엔진을 사용하여 트랜잭션 순서를 정합니다. 다른 BFT 합의 메커니즘과 비교했을 때 Sui의 장점과 단점은 6가지로 요약할 수 있습니다:

장점:

1. 짧은 지연 시간 및 높은 처리량: 미스틱티 프로토콜은 병렬 블록 제안과 최적화된 메시지 흐름을 통해 합의 지연 시간을 크게 줄이고 네트워크 처리량을 증가시켜, Sui가 1초 미만의 엔드투엔드 지연 시간으로 초당 수만 건의 트랜잭션을 처리할 수 있도록 지원합니다.
2. 검열 저항: 미스틱티 프로토콜은 여러 검증자가 동시에 블록을 제안할 수 있도록 하여 검열에 대한 네트워크의 저항력을 향상시킵니다.
3. 리더 장애 허용 오차: 제출 규칙은 지연 시간을 크게 늘리지 않고 리더 노드에 장애가 발생하면 자동으로 새 리더를 선출하여 리더를 대신할 수 있도록 허용합니다.

단점:

1. 복잡성: 미스틱티 프로토콜의 설계는 비교적 복잡하며, 운영 메커니즘을 완전히 이해하기 위해서는 보다 깊은 기술적 이해가 필요합니다.
2. 보안: 미스틱티 프로토콜은 테스트넷에서 좋은 성능을 보였지만, 실제 애플리케이션에서는 보안에 대한 추가적인 검증이 필요합니다.
3. 확장성: 미스틱티 프로토콜의 확장성은 향후 네트워크 규모와 거래량의 증가에 적응할 수 있는지 확인하기 위해 추가적인 관찰이 필요합니다.

2.3 추상 계정

수이의 추상 계정 모델(계정 추상화)은 기본 블록체인 프로토콜에서 계정과 거래 로직을 추상화하여 사용자가 계정과 거래를 더 간단하고 안전하게 관리할 수 있는 메커니즘으로, 더 높은 수준의 계정 관리 및 거래 처리를 달성합니다.

수이의 추상적 계정 모델에서 계정은 더 이상 단순한 공개-개인 키 쌍이 아니라 더 풍부한 속성과 동작을 가진 객체입니다. 각 계정에는 계정의 공개 및 비공개 키 쌍과 연결된 계정 ID라고 하는 고유 식별자가 있습니다.

Sui의 추상 계정 모델에는 다음과 같은 주요 구성 요소가 포함되어 있습니다:

• 계정 개체: 수이에서 계정의 기본 단위입니다. 각 계정 개체에는 고유한 계정 ID가 있으며 계정의 속성 및 동작을 포함합니다.
• 계정 데이터: 계정 ID 및 공개-비공개 키 쌍과 같은 기본 계정 정보를 포함하는 계정 객체의 핵심 구성 요소입니다.
• 트랜잭션 컨텍스트: 거래 ID, 계정 ID, 거래 데이터 등 거래 관련 정보를 포함하는 수이 거래의 기본 단위입니다.
• 계정 로직: 계정에서 트랜잭션을 처리하고 상태를 관리하는 방법을 정의하는 Sui의 계정 동작 및 규칙 모음입니다.

Sui의 추상 계정 모델에서 거래를 처리하는 과정에는 다음 단계가 포함됩니다:

1. 거래 생성: 사용자가 트랜잭션을 생성하여 Sui 네트워크로 전송합니다.
2. 거래 유효성 검사: Sui 네트워크는 트랜잭션의 유효성과 무결성을 검증합니다.
3. 계정 조회: Sui 네트워크는 트랜잭션의 계정 ID를 기반으로 해당 계정 객체를 찾습니다.
4. 계정 로직 실행: Sui 네트워크가 계정 로직을 실행하여 트랜잭션을 처리하고 계정 상태를 업데이트합니다.
5. 거래 확인: 수이 네트워크가 트랜잭션 결과를 확인하고 블록체인에 기록합니다.

간단히 말해, Sui의 추상 계정 모델은 계정 관리와 거래 처리를 간소화하여 애플리케이션을 더욱 애플리케이션답게 만드는 혁신적인 메커니즘입니다.

2.4 게임

블록체인이 두각을 나타내려면 먼저 탄탄한 기반을 구축해야 합니다. 앞서 Move 생태계를 대담한 실험이라고 언급한 이유는 크게 두 가지입니다.

첫째, 모듈화 개념이 널리 확산되고 있는 시대에 네이티브 Move 에코시스템(특히 Move 트윈)은 현재 트렌드에 역행하는 레이어 1 솔루션의 마지막 시도라는 점입니다.

그러나 최근 여러 이기종 체인이 등장하면서 모듈화가 유일한 해답이 아님을 증명하고 있습니다.

둘째, 새로운 프로그래밍 언어를 사용하여 블록체인을 재구축하는 것은 오늘날 스마트폰 시장에서 iOS와 안드로이드에 도전하기 위해 새로운 운영체제를 만드는 것과 비슷하며, 이는 필연적으로 도전으로 가득 찬 길입니다.

앞으로 몇 년 안에 Move 생태계가 솔라나처럼 빛을 발할 수 있을지 여부는 어떤 방향을 선택하느냐에 따라 크게 달라집니다. 이 과제에 대한 수이의 답은 게임입니다.

게임은 웹3.0의 주요 관문 중 하나이지만, 대부분의 블록체인은 게임을 잘 지원하지 않습니다. 이는 블록체인 기술이 원래 금융 애플리케이션을 중심으로 설계되었고, 탈중앙화된 아키텍처는 본질적으로 성능이 낮기 때문에 게임에는 적합하지 않기 때문입니다.

하지만 수이는 다릅니다. 이 모델은 DeFi 애플리케이션과 게임을 포함한 비금융 애플리케이션 모두에 적합합니다. 앞서 언급했듯이 Sui에서는 모든 것이 객체입니다. Sui에서는 객체가 다른 객체를 소유할 수 있으므로 게임이나 애플리케이션에서 흔히 볼 수 있는 복잡한 자산 계층 구조를 모델링할 수 있습니다.

영웅 캐릭터가 인벤토리를 가지고 있고 그 인벤토리에는 캐릭터에 속한 다른 디지털 자산이 있는 게임을 한다고 상상해 보세요. Sui는 다른 블록체인에서는 불가능한 방식으로 이러한 데이터 계층 구조를 모델링할 수 있습니다. 이를 통해 개발자는 체인의 내재적 한계를 해결하지 않고도 애플리케이션을 구축할 수 있습니다.

또한, 수이는 전통적인 웹2.0 대기업과도 적극적으로 협업하고 있습니다. 작년에 Sui는 한국의 4대 게임 업체 중 3개 업체(넷마블, NHN, 엔씨소프트)와 파트너십을 맺었습니다. 올해에는 틱톡과 파트너십을 맺고 블록체인 게임과 소셜파이 프로젝트를 개발하여 전통적인 대기업을 웹3.0 영역으로 끌어들였습니다.

3. Aptos

Aptos는 Move 언어를 기반으로 하는 또 다른 레이어 1 블록체인으로, 고성능의 확장 가능한 웹3 인프라 구축에 전념하고 있습니다. 아키텍처 설계는 Sui와 많은 유사점을 공유하지만 몇 가지 고유한 기능도 도입하고 있습니다.

3.1 아키텍처

1. 모듈식 디자인: 앱토스는 개발자가 다양한 모듈을 독립적으로 개발하고 업그레이드할 수 있는 모듈형 아키텍처를 채택하여 개발 속도와 유연성을 향상시킵니다.
2. 병렬 실행 엔진(Block-STM): 사전 선언된 데이터 종속성이 필요한 다른 블록체인과 달리 앱토스의 병렬 실행 엔진은 데이터 위치에 대한 사전 지식 없이도 트랜잭션을 병렬로 처리할 수 있어 처리량을 늘리고 지연 시간을 줄일 수 있습니다.
3. 파이프라인 트랜잭션 처리: 앱토스는 트랜잭션 처리를 전파, 메타데이터 순서 지정, 배치 저장 등 여러 단계로 나누어 파이프라이닝을 통해 이러한 단계를 병렬로 실행하여 처리량을 극대화하고 지연 시간을 최소화합니다.
4. 프로그래밍 언어 이동: 앱토스는 Move 프로그래밍 언어를 사용하며, Sui에 비해 혁신보다는 개선에 중점을 두고 있습니다. 예를 들어 언어를 표준화하고, 더 강력한 기능 지원을 도입하고, 사용자 지정 기능을 강화했습니다.
5. 유연한 상태 동기화: 노드가 전체 기록 동기화 또는 최신 상태만 동기화 등 다양한 상태 동기화 전략을 선택할 수 있어 노드 유연성이 향상됩니다.
6. 앱토스BFT 합의 메커니즘: AptosBFT는 Aptos에서 사용하는 비잔틴 장애 허용 합의 메커니즘입니다. 이는 검증자 간의 통신과 동기화를 최적화하여 처리량을 개선하고 지연 시간을 줄입니다. DiemBFT의 개선된 버전이라고 볼 수 있는 Sui와 비교했을 때, AptosBFT는 효율성과 크래시 복구에서 일정한 발전을 이루었으므로 여기서는 간략하게 언급하겠습니다.

앱토스의 아키텍처는 빠른 속도, 낮은 수수료, 보안을 유지하면서 많은 수의 동시 트랜잭션을 처리할 수 있습니다. 또한 Move 언어와 앱토스 프레임워크는 개발자에게 안전하고 확장 가능하며 사용자 친화적인 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

3.2 블록-STM

앱토스의 핵심 혁신 기술인 병렬 실행 엔진 Block-STM에 대해 자세히 알아보겠습니다:

블록-STM의 핵심 원칙:

1. 사전 정의된 순차 실행: 블록-STM은 블록 내에서 미리 정의된 트랜잭션 순서에 의존합니다. 최종 상태의 일관성을 보장하기 위해 모든 트랜잭션은 이 순서대로 실행되어야 합니다.
2. 낙관적 동시성 제어: Block-STM은 충돌이 발생하지 않는다고 가정하고 낙관적으로 트랜잭션을 병렬로 실행합니다. 이 제어 방식은 충돌이 거의 발생하지 않는다는 가정에 기반하여 트랜잭션이 잠금 없이 데이터에 액세스하고 수정할 수 있도록 합니다. 동시 충돌의 가능성이 낮다고 가정하므로 최종 커밋 전에 충돌을 확인하면서 수정을 진행할 수 있습니다.
3. 다중 버전 데이터 구조: 최적의 동시성 제어를 지원하기 위해 Block-STM은 다중 버전 데이터 구조를 사용해 데이터를 저장합니다. 모든 쓰기 작업은 새 데이터 버전을 생성하고 읽기 작업은 해당 데이터 버전에 액세스합니다.
4. 유효성 검사 및 재시도: 트랜잭션을 실행한 후 Block-STM은 읽은 데이터의 버전이 여전히 유효한지 확인합니다. 유효성 검사에 실패하여 충돌이 발생하면 트랜잭션이 유효하지 않은 것으로 표시되고 다시 실행됩니다.
5. 공동 작업 일정: Block-STM은 협업 스케줄러를 사용하여 다양한 스레드의 실행 및 유효성 검사 작업을 조정하여 병렬성을 극대화합니다.

블록-STM 워크플로:

1. 거래 그룹화: 블록 내에서 트랜잭션을 그룹화하고 병렬 실행을 위해 다른 스레드에 할당합니다.
2. 낙관적 실행: 각 스레드는 할당된 트랜잭션을 최적으로 실행하고 각 트랜잭션의 읽기/쓰기 세트를 기록합니다.
3. 유효성 검사: 스레드가 트랜잭션을 완료하면 읽기 세트의 데이터 버전이 여전히 유효한지 확인합니다.
4. 다시 시도합니다: 유효성 검사에 실패하여 충돌이 발생하면 트랜잭션이 유효하지 않은 것으로 표시되고 다시 실행됩니다.
5. 커밋합니다: 모든 트랜잭션이 유효성 검사를 통과하면 그 결과가 블록체인 상태에 기록되어 트랜잭션 커밋이 완료됩니다.

Block-STM의 장점:

1. 높은 처리량: 최적의 동시성 제어와 협업 스케줄링을 활용하여 Block-STM은 멀티코어 프로세서를 최대한 활용함으로써 높은 처리량을 달성합니다.
2. 짧은 지연 시간: 트랜잭션을 병렬로 실행할 수 있기 때문에 Block-STM은 트랜잭션 확인 시간을 크게 단축합니다.
3. 보안: Block-STM의 사전 정의된 순차 실행 및 유효성 검사 메커니즘은 최종 상태의 일관성과 보안을 보장합니다.

요약하자면, Block-STM은 최적의 동시성 제어, 다중 버전 데이터 구조, 협업 스케줄링을 결합하여 블록체인 처리량을 극대화하는 동시에 보안과 정확성을 보장하는 효율적인 병렬 트랜잭션 실행 엔진입니다.

3.3 계정 추상화

계정 추상화에 대한 Sui의 보다 직접적인 접근 방식과 달리 앱토스는 보다 제한된 추상화 차원을 지원하며 미리 정의된 특정 표준이 부족합니다. 계정 추상화 기능은 주로 다음 영역에서 나타납니다:

1. 모듈식 계정 관리: 이동 모듈을 사용하여 계정을 정의하고 관리하여 개발자가 다양한 계정 유형과 기능에 맞는 사용자 지정 모듈을 만들 수 있습니다.
2. 유연한 키 관리: 사용자가 거래 서명에 한 키를 사용하고 계정 관리에 다른 키를 사용하는 등 계정 작업마다 다른 키를 사용할 수 있습니다.
3. 프로그래밍 가능한 거래 확인: 개발자는 이동 모듈에서 다중 서명 또는 제한과 같은 사용자 지정 트랜잭션 확인 로직을 정의하여 다양한 애플리케이션 시나리오를 충족할 수 있습니다.

3.4 Microsoft와의 파트너십

게임 개발에 더 집중하는 수이에 비해 앱토스는 구체적인 개발 목표가 없습니다. 앱토스의 슬로건은 생산에 가장 적합한 블록체인이 되는 것입니다.

주목할 만한 점은 앱토스와 마이크로소프트의 지속적인 협업으로, 마이크로소프트의 AI 기술을 블록체인에 통합하는 것을 목표로 하고 있다는 점입니다. 첫 번째 협업 제품인 앱토스 네트워크에 구축된 생성형 AI 비서인 앱토스 어시스턴트는 이미 공식 웹사이트에 출시되었습니다. 앞으로 몇 달에 걸쳐 추가 AI 제품이 발표될 예정입니다.

4. 이동 생태계

Sui는 최근 좋은 성과를 거두었지만, 무브 생태계는 EVM 기반 체인, 솔라나, 톤 및 기타 이기종 체인에 비해 아직 성숙하기까지 시간이 필요합니다. 수이와 앱토스가 주목을 받고 기술적인 혁신을 이루고 있지만, 무브 생태계의 전반적인 규모와 활동은 아직 다른 성숙한 생태계에 미치지 못합니다.

개발자 수, 애플리케이션 유형, 사용자 기반이 성장하려면 아직 시간이 필요합니다. 외부 협업과 운영 측면에서 보면, Sui와 Aptos는 웹3의 본질이 일부 결여된 웹2 사고방식이 강하며, 이로 인해 업계에서 상대적으로 프로젝트가 덜 주목받고 있습니다.

하지만 무브 생태계의 잠재력을 고려하면 많은 가능성을 가지고 있습니다. 일부 개발자들은 이미 무브의 미래 가치를 인정하고 있습니다. 서문에서 언급했듯이 이미 이더리움 레이어 2 솔루션에 무브를 통합하는 프로젝트들이 있습니다. 앞으로 무브 생태계는 이더리움 레이어 2 공간에서 빛을 발할 수 있습니다. 현재는 무브 생태계를 더욱 활성화하는 방법에 초점을 맞추고 있습니다.