Move 언어의 아버지와의 대화: Move는 후발주자로서의 이점을 가지고 있으며, 블록체인은 근본적으로 마찰을 제거하는 기술이다
최근 우리는 Mysten Labs의 최고 기술 책임자이자 Move 프로그래밍 언어 창시자인 Sam Blackshear와 대화를 나누며, 그가 왜 Sui Move라는 새로운 스마트 계약 프로그래밍 언어를 개발하게 되었는지, Sui가 확장할 수 있는 기능들, 그리고 탈중앙화 기술이 개발자들에게 제공하는 이점에 대해 논의했습니다.
다음은 인터뷰 전문입니다:
01. 우선 프로그래밍 언어란 무엇인지 설명해주실 수 있나요? 개발자가 프로그래밍 언어를 선택할 때 가장 중요하게 여기는 특성은 무엇이며, 어떤 이유로 귀하께서 자체 언어를 개발하게 되셨나요?
프로그래밍 언어란 컴퓨터와 친숙하고 안전하며 효율적이고 명확하게 소통할 수 있게 해주는 도구일 뿐입니다. 특히 컴퓨터의 경우 이것이 매우 중요합니다. 우리는 자연어로 컴퓨터와 소통할 수 없습니다. 왜냐하면 자연어의 본질은 풍부한 의미와 표현력을 갖추는 데 있기 때문입니다. 약간 다른 어조나 미묘하게 다른 단어 선택을 통해 문장이나 단락의 의미가 전혀 달라질 수 있습니다.
반면 프로그래밍 언어에서 가장 중요한 것은 정밀하게 정의된 의미론(semantic)을 갖추는 것입니다. 프로그램을 작성할 때, 당신은 그것이 정확히 무엇을 할 것인지 분명히 알고 있어야 합니다. 코드에 사소한 조정을 가했을 때, 그 변화가 어떤 결과를 초래할지도 알아야 하죠. 이는 여러 층위에서 유지되어야 합니다. 예를 들어, 소스 언어로 코드를 작성하면 특정 의미를 가지며, 그 코드가 다른 형태로 변환되더라도 동일한 의미를 유지해야 하고, 궁극적으로 머신 레벨에서도 마찬가지여야 합니다.
제 생각에 프로그래밍 언어는 자연어와 달리 특정 영역 또는 특정 작업에 특화된 것이 본질입니다. 만약 하나의 언어로 모든 작업을 수행할 수 있다면 굳이 다양한 언어가 존재하지 않을 것입니다. 하지만 현실에서는 각각의 언어가 특정 문제 영역에 집중하여 설계되고 있으며, 그 문제들을 해결하는 데 최적화되어 있습니다. 예를 들어, 우리가 Sui 블록체인과 Mysten 내 대부분의 시스템 작업에 사용하는 Rust 언어를 보면, 빠르고 고성능의 코드 작성을 가능하게 하면서도 보안성을 보장합니다. 메모리, 스레드 구조, 동시성 등 저수준 세부사항에 접근할 수 있게 해주지만, C나 C++ 같은 과거 언어처럼 실수를 범하기 쉽게 만들지는 않습니다.
따라서 Move 언어의 이야기도 이와 매우 유사합니다. 제가 이를 창조했을 당시 목표는 새로운 언어를 만드는 것이 아니었습니다. 앞서 언급하셨듯이 개발자는 언어 선택 시 "이 언어가 내가 원하는 작업에 적합한가?"를 묻습니다. 하지만 더 중요한 질문은 "이 언어에 활발한 커뮤니티가 있는가?", "많은 데이터베이스가 지원되는가?", "많은 프로그래머들이 사용하고 있는가?", "좋은 교육 자료가 있는가?"일 수 있습니다. 이러한 요소들은 매우 중요하므로, 새 언어를 만드는 진입 장벽은 반드시 매우 높아야 합니다. 언어 자체가 더 우수하더라도 이러한 생태계가 없다면 그 이점은 무의미해집니다. 처음부터 방대하고 역동적인 커뮤니티를 구축하는 것은 극도로 어렵습니다.
02. Move 언어 개발에 대해 좀 더 말씀해주실 수 있나요?
Move는 페이스북의 리브라(Libra) 프로젝트에서 시작되었습니다. 제 임무는 새로운 언어를 만드는 것이 아니라 "리브라에는 스마트 계약이 필요하다. 그래서 우리가 무엇을 해야 할지를 찾아내라"였습니다. 저는 다양한 가능성을 검토했습니다. EVM에서 솔리디티(Solidity)를 사용할 수 있을까? WASM이나 JVM 같은 일반적인 범용 언어를 리브라에 사용해야 할까? 아니면 우리만의 것을 만들어야 할까?
우리만의 언어를 만들기로 한 결정은 기존 스마트 계약 언어들의 연구와, 프로그래머들이 실제로 무엇을 하려는지, 어떤 언어가 그들을 도와주고 또 실망시키는지를 파악한 데 기반합니다.저는 기존의 스마트 계약 언어들이 많은 경우에 실제로 프로그래머들을 실망시키고 있다고 결론지었습니다.
이는 솔리디티의 나쁜 보안 기록에서 명확히 드러납니다. 그러나 더 근본적으로, 스마트 계약은 전통적인 프로그램 유형과는 다릅니다. 솔리디티는 현재 사람들이 하는 일에 맞게 설계된 언어가 아닙니다. 제가 비판하려는 것은 아닙니다. 솔리디티는 첫 번째 스마트 계약 언어였고, 사람들이 그것으로 무엇을 하려 할지 몰랐던 상황이었으니까요. 사람들이 그것을 어떻게 사용하려는지 이해하게 되면, 솔리디티가 제공하는 추상화와 도구들로는 부족하다는 점이 분명해집니다. 다른 종류의 추상화와 프로그래밍 도구들이 필요하다는 것이죠.
이 스마트 계약들은 매우 간단합니다. 기본적으로 두 가지 일을 합니다.자산의 유형을 정의하며, 언제 자산을 이전할 수 있는지, 그것으로 무엇을 할 수 있는지, 누구에게 읽기/쓰기 권한이 있는지를 규정합니다.또한 접근 제어 정책을 확인하여 누가 해당 자산을 소유하고 있고, 누가 사용하거나 조작할 수 있는지를 판단합니다. 모든 것이 자산 중심이며, 물리적 자산과 동일한 속성을 가지기를 원합니다. 제가 당신에게 무언가를 건넨다면, 이제 그것을 당신이 소유하고 저는 더 이상 소유하지 않아야 합니다.
스마트 계약에는 소유권과 소유권 양도 개념이 있지만, 컴퓨터 세계에서는 모든 것이 디지털 비트와 바이트이며 자유롭게 복제될 수 있습니다. 게다가 이런 개념들은 현실 세계에도 존재하지 않습니다. 따라서 현실 세계와 같이 프로그래머가 매번 새로 발명하지 않아도 되도록 소유권과 동질성에 대한 좋은 추상화를 제공하는 언어를 원합니다. 기본적인 보안 보장을 제공받기를 원하는 것이죠.
이것이 바로 Move가 하는 일이며, 결국 새로운 언어를 개발하게 된 이유입니다. 이러한 작업은 스마트 계약 프로그래밍의 핵심입니다. 기존 언어들, 즉 기존 스마트 계약 언어들에서도 재현하기 어렵습니다. 우리는 이러한 기본 기능을 중심으로 전체 언어를 설계하여, 개발자가 매번 코드를 작성할 때마다 '바퀴를 다시 발명'하지 않고도 안전하고 효율적으로 코드를 작성할 수 있도록 하려 했습니다.
03. Sui는 Sui Move라는 Move의 변형을 사용하고 있습니다. 어떤 변화를 가져오게 되었으며, Sui Move의 어떤 특성이 Web3 제품 개발에 적합한가요?
이러한 변화를 가져온 몇 가지 요인이 있습니다. 그 중 하나는 초기 리브라 프로젝트의 목적이 규제를 준수하는 지불 네트워크를 구축하는 것이었다는 점입니다. 따라서 우리는 Move(https://docs.sui.io/learn/sui-move-diffs)를 보다 범용적인 언어로 설계하려 했습니다. 하지만 리브라의 요구사항에 따라 일부 의도적인 제한을 두기도 했습니다. 중요한 점 중 하나는 특정 자산을 어디든지 보낼 수 없도록 하겠다는 것이었습니다. 사용자가 명시적으로 계정을 생성하고, 계정 생성 시 KYC 인증을 받거나, 계정 생성 비용을 지불하거나, 소수의 승인된 사람들만 계정을 생성할 수 있도록 하는 등의 규칙을 설정하길 원했습니다. 리브라가 규제 준수 지불 및 스마트 계약을 지향했기 때문에 이러한 제약이 존재했습니다. 그러나 보다 일반적인 Web3 영역에서는 정반대입니다. 기본 계층에서 규제 준수를 강요하고 싶지 않으며, 이것이 바로 스마트 계약의 개념입니다. 어떤 항목이라도 자유롭게 어느 주소든 보낼 수 있기를 원합니다. 또한 명시적인 계정 생성을 하지 않아야 하는데, 그렇지 않으면 다양한 사용 사례가 막히게 됩니다. 이것이 중요한 요인 중 하나입니다.
또 다른 요인은, Move에서 자산에 초점을 두었지만 당시 리브라에서는 거래 자체에 자산 관점을 통합하는 방법을 고려하지 않았다는 점입니다. 따라서 거래 레벨에 도달하면 여전히 숫자와 불린 값 등 자산이 아닌 것을 입력받는 API만 존재합니다. Move에서는 이러한 숫자를 사용해 계정에서 자산을 추출하고 다른 작업을 수행합니다. 실제로 실행되는 대부분의 코드는 성가신 장부 작업으로 구성됩니다. 이것을 꺼내고, 저것을 꺼내고, 다른 것도 꺼냅니다. 좋아, 내가 원하는 모든 자산을 확보했습니다. 이제 내 작업 공간에 모두 있으니 의미 있는 작업을 시작할 수 있습니다. 이 과정의 마지막에 "이 자산은 이 계정에 돌려놓고, 저 자산은 저 계정에 돌려놓고 재정렬하자"고 말할 수 있습니다.
Sui에서는 매 프로그램이 이렇게 시작하고 끝난다면 이를 추상화할 수 있는지 깊이 고민했습니다. 따라서 거래 처리 로직이 이러한 작업을 프로그래머를 위해 수행합니다. 프로그래머 입장에서는 필요한 자산만 준비하면 바로 의미 있는 작업을 시작할 수 있습니다.이것이 Sui에 존재하는객체 중심 데이터 모델입니다. 원래의 Move에서는 기반 계정의 데이터 모델을 사용했으며, 자산은 계정 아래에 저장되고 프로그래머가 명시적으로 추출해야 했습니다. 반면 Sui에서는 거래의 Move 부분에 진입할 때 이미 Sui 런타임이 자산을 가져옵니다. 프로그래머에게는 훨씬 편리하며, 앞뒤의 번거로운 장부 작업을 할 필요가 없습니다. 또한 이를 통해 실제 실행 없이도 한 거래를 다른 거래와 병렬로 실행할 수 있는지 판단할 수 있으며, Sui의 수평적 확장성과 기타 일부 작업의 효율성을 높이는 핵심 기술이 됩니다.
우리는 또한 객체 기반 데이터 모델을 활용한 프로그래머블 트랜잭션 블록(Programmable Transaction Blocks)과 같은 매우 흥미로운 작업들도 진행했습니다. 다소 기술적인 주제이지만 깊이 있게 논의할 수 있습니다. 그러나 위 두 요인이 원래의 Move와 차별화된 주요 동인이었습니다.
04. 프로그래머블 트랜잭션 블록과 그 기능에 대해 좀 더 설명해주실 수 있나요?
비유를 들어 설명하는 것을 좋아합니다. 다른 블록체인은 쇼핑몰 푸드코트와 같습니다. 아이스크림을 먹고 싶으면 아이스크림 가게로 가서 신용카드로 결제합니다. 그런데 햄버거도 먹고 싶어진다면, 햄버거 가게로 가서 다시 결제해야 하죠. 저는 그리 많이 먹는 편이 아니지만, 8가지 음식을 먹고 싶다면 8번의 개별 거래를 해야 합니다. 반면 Sui는 뷔페와 같습니다. 각 거래가 단 하나의 일이 아닙니다. 일단 뷔페 요금을 지불하면 추가 비용 없이 여러 가지 일을 할 수 있습니다. 아이스크림을 먹을 수 있고, 햄버거도 먹을 수 있으며, 서로 섞어서 먹을 수도 있습니다.
좀 더 구체적으로 설명하면, 간단한 예로 100개의 NFT를 민팅하기 위해 100건의 거래를 보내는 대신, 하나의 거래로 100개의 NFT를 민팅할 수 있습니다. 이때 발생하는 비용은 NFT 하나를 민팅하는 것과 거의 동일합니다. 또한 이질적인 거래 패키징도 가능합니다. 예를 들어 블록의 첫 번째 거래에서 멀티시그 지갑에서 마리오 캐릭터를 꺼내고, 두 번째 거래에서 마리오를 요청해 게임을 플레이합니다. 게임에서 이겨서 트로피를 획득했다면, 세 번째 거래에서 그 트로피를 친구와 공유하는 트로피 캐비닛에 넣을 수 있습니다. 놀라운 점은 프로그래머블 트랜잭션 블록 덕분에 게임 개발자는 멀티시그 지갑이나 마리오 저장 방식, 혹은 트로피 캐비닛의 구현 방식을 알 필요가 없다는 것입니다.
프로그래머블 트랜잭션 블록은 입력 및 출력 객체를 포함하는 거래들로 구성됩니다. 입력 객체가 필요하면, 그 객체가 어디서 왔는지 신경 쓰지 않고 가져올 수 있으며, 출력은 그것을 필요로 하는 객체에 전달할 수 있고, 어디로 전달되는지도 신경 쓰지 않아도 됩니다. 다른 블록체인에서는 결합도(coupling)가 더 높아서, 게임이 반드시 멀티시그 지갑과 트로피 캐비닛과 통합되어야 하거나, 모두 동일한 인터페이스를 구현하고 더 강한 결합도를 가져야 합니다. Sui는 일시적인 조합(temporary composition)을 훨씬 쉽게 만들어 줍니다. 파이프가 잘 맞물리면 하나의 거래 안에서 모두 처리할 수 있습니다.
05. 그렇다면 프로그래머블 트랜잭션 블록이 사용자에게 어떤 이점을 제공하나요?
사용자 입장에서 프로그래머블 트랜잭션 블록의 이점으로는더 낮은 가스 비용이 있습니다. 여러 개별 거래 대신 모든 작업을 하나의 거래에 묶을 수 있기 때문입니다. 또한 승인 횟수도 줄어듭니다. 거래 승인이 필요한 시스템을 사용한다면, 한 번만 승인하면 모든 작업이 한꺼번에 완료됩니다. 또 다른 이점은원자성(atomicity)입니다. 세 가지 다른 작업을 수행하면서, 앞의 두 작업이 성공해야만 세 번째 작업이 성공하기를 원한다면, 개별 거래로는 이를 달성할 수 없습니다. 하지만 하나의 거래 안에 모두 넣으면 쉽게 구현할 수 있습니다.
06. Sui에서의 개발 경험이 프로그래머에게 매우 좋다고 들었고, 이것이 중요하다고 생각하신다고 하셨습니다. 경험 있는 Web3 개발자나 신규 개발자가 Sui Move를 시작할 때 들려주실 수 있는 일화가 있나요?
기타 Web3 프로그래밍 언어 출신의 개발자들에게,Move와 Sui Move는 정말 더 효율적이고 안전한 개발 경험을 제공합니다. 최근 Bucket Protocol에 관한 팟캐스트에 참여했는데, 그들은 Sui 위에서 아주 멋진 DeFi 프로젝트를 구축하고 있었습니다. 시스템 아키텍처를 설명하면서 서로 다른 컴포넌트들이 어떻게 협업하는지 소개했습니다. 그들은 만약 솔리디티로 이 프로젝트를 개발했다면 8개월 정도 걸렸겠지만, Sui Move로는 단 두 달 만에 완성했고, 보안성에 대해서도 매우 자신감을 가졌다고 말했습니다. 이 언어는 그들이 머릿속에서 프로젝트를 구성하는 방식과 매우 유사하게 작동했습니다. 반면 솔리디티 환경에서는 이러한 연결이 그렇게 직접적이지 않았습니다.
이건 하나의 예일 뿐이지만, 우리는 비슷한 이야기를 많이 듣습니다. 사람들은 이 언어로 개발 속도가 빨라졌고, 완성 후에도 더 큰 자신감을 갖게 되었다고 말합니다. 이런 얘기를 들으면 기쁩니다. 하지만 어찌 보면 당연한 일입니다. 우리는 솔리디티를 연구하고 그 문제점을 이해했습니다. 보다 안전하고 빠른 개발을 위한 설계를 명확히 했습니다. 이 언어를 사용하는 개발자들이 무엇을 하려는지 살펴보고, 그들의 필요에 맞는 언어를 설계했습니다. 기존 상황에 맞추는 대신, 실제로 겪는 문제에 맞춰 언어를 설계한 것이죠. 그래서 개발자들이 전환할 때 이 언어를 진정으로 높이 평가하는 것입니다.
선점 효과(first-mover advantage)가 중요하다고들 하지만, 저는 오히려 후발 효과(late-mover advantage)가 더 중요하다고 생각합니다.
맞습니다, 그대로입니다.
07. Sui Move와 Sui 전체의 객체 지향적 특성에 대해 말씀해주셨습니다. 하지만 Sui Move의 설계가 Sui가 Web3의 대규모 채택, 낮은 지연 시간, 낮은 비용, 확장성 등을 실현할 수 있도록 하는 데 어떤 연관이 있는지 좀 더 명확히 설명해주실 수 있나요?
Sui 개발에 기여하면서 우리가 매우 주의 깊게 살펴본 점은, 다른 플랫폼들이 직면한 문제입니다. 만약 용량이 제한되어 있다면, 예를 들어 이더리움의 초당 15건(TPS), 또는 100건, 1,000건과 같은 고정된 숫자라면, 플랫폼이 너무 성공적으로 성장하면 결국 용량 한계에 도달하게 됩니다. 그러면 모든 사용자의 경험은 나빠집니다. 비어있는 자리가 1,000개뿐이라면, 가장 중요한 1,000개를 선택해야 하는데, 가스 입찰이나 다른 방식으로 결정하게 됩니다. 모든 사람의 가스 비용이 올라가고, 지연 시간이 증가하거나, 그 둘 다 발생합니다. 높은 비용을 지불할 수 없는 사용 사례들은 배제되며, 다른 곳으로 가거나 더 오래 기다려야 합니다. 이는 좋은 상황이 아닙니다.
Sui의 목표는 수평적 확장성(horizontal scalability)입니다. 일정량의 하드웨어를 할당하면 일정량의 처리량을 얻을 수 있습니다. 더 많은 처리량이 필요하면 검증 노드가 더 많은 하드웨어를 추가할 수 있으며, 상한선이 없습니다. 이것은 모든 Web2 서비스가 작동하는 방식입니다. 물론 엔지니어링적인 제약을 해결해야 하며, 확실하거나 쉬운 일은 아니지만, 확장 가능한 웹 서비스를 설계할 때 모두가 수평적 확장성을 추구합니다.
Sui에 더 많은 고객이나 사용자가 생긴다면, 우리의 목표는 Sui가 계속 성장하면서도 모든 것이 정상적으로 작동하도록 하는 것입니다. 물론 동시에 매우 낮은 지연 시간을 유지해야 합니다. 처리량을 늘리면서 지연 시간을 희생하고 싶지는 않으니까요.
리브라 시스템에서는 이러한 특성을 고려하지 않았습니다. 그것은 수백 개의 지불 사업자만 있는 소규모 지불 시스템이었고, 하루에 수천만 건의 지불이 있었을지 모르지만, 그 이상은 아닙니다. 따라서 더 간단하고 충분한 단일 박스(single-box) 아키텍처를 채택했습니다. 그러나 Sui에서는 리브라 시스템이 통하지 않는다는 것을 알고 있었습니다. 왜냐하면 수평적 확장성 특성을 갖추지 못했기 때문입니다. 그래서 우리는 어떻게 하면 처음부터 이를 실현할 수 있는 시스템을 설계할 수 있을지를 고민했습니다. 이것이 바로 객체 지향 데이터 모델의 출발점입니다. 우리는 기존의 계정 기반 데이터 모델을 버렸습니다. 왜냐하면 그것으로는 수평적 확장성을 실현하기가 매우 어려웠기 때문입니다. 반면, 모든 것을 객체로 구성하면 글로벌 상태는 객체 ID에서 객체로의 대규모 매핑일 뿐입니다. 즉 키-값 저장소인데, 우리는 키-값 저장소를 확장하는 방법을 알고 있습니다. 이는 비교적 단순한 엔지니어링 문제입니다.
그 다음 문제는, 키-값 저장소에서 데이터를 가져오고 업데이트하는 과정에 맞는 트랜잭션 구조를 어떻게 설계할 것인지, 키-값 저장소를 어떻게 샤딩(sharding)할 것인지, 트랜잭션이 어디에서 처리되어야 할지를 어떻게 결정할 것인지입니다. 이것이 기본적인 출발점입니다. 우리는 이러한 요소들을 확장하는 방법을 알고 있습니다. 그런 다음 그것을 블록체인 특성, 검증 가능한 읽기, Move와의 협업 기능 등을 갖춘 것으로 어떻게 바꿀 수 있을지, 그리고 이를 얼마나 매끄럽게 통합할 수 있을지를 고민합니다.
08. 더 높은 수준에서, Web2 개발자들이 탈중앙화 기술의 잠재력에 대해 회의적인 시각을 가질 때 어떻게 대화를 나누시나요?
저는 블록체인과 암호화폐가 근본적으로 마찰을 제거하는 기술이라고 생각합니다. 금융 거래를 하거나 애플리케이션을 만들거나 정보를 설정할 때 어려움을 겪는 장애물들이 있습니다. 정보가 이러한 장벽을 넘지 못하거나, 넘는다고 해도 특정 제3자의 도움이 필요하며, 그들은 도움을 제공하는 대가로 수수료를 받습니다.
사람들이 자주 드는 전형적인 예는 집을 사는 것입니다. 구매자와 판매자가 있지만, 실제 결제 시에는 에스크로(Escrow) 에이전트가 필요합니다. 구매자와 판매자가 서로 완전히 신뢰하지 않기 때문이죠. 이 에이전트는 돈을 보관하는 역할 외에는 아무것도 하지 않습니다. 삶의 현실입니다. 우리는 이를 받아들여야 합니다. 하지만 만약 에스크로 에이전트가 코드로 되어 있어서 양측이 모두 확인할 수 있거나, 제3자가 검증할 수 있다면, 이 일을 무료 또는 훨씬 낮은 비용으로 수행할 수 있습니다. 블록체인의 목적은 부동산에서 에스크로 에이전트를 없애는 것이 아닙니다. 다만 이것은 하나의 사용 사례일 뿐이며, 일반적으로 이런 식입니다.
앱 A와 앱 B 사이의 상호 운용성 장벽이 사라지고, 동일한 기반 플랫폼 위에 구축된다면, 앱 내 아이템, 데이터, 크로스 프로모션, 또는 두 앱 위에 구축된 제3자 제품까지 하나의 앱에서 다른 앱으로 흐를 수 있게 됩니다. 인터넷을 상상해보세요. 웹사이트들이 쿠키를 통해 서로 데이터를 공유하지만, 이 쿠키는 읽기 전용 메타데이터일 뿐입니다. 만약 이 쿠키가 통화가 된다면? 또는 소비 가능한 아이템이 된다면? 또는 로열티 프로그램이나 쿠폰이 된다면? 모든 것이 이 기능을 내장한다면요? 매우 추상적이지만, 이것이 가능성입니다. 일반적으로 개발을 하는 사람은 이러한 것들을 더 매력적인 무언가를 만들기 위한 새로운 초능력으로 생각합니다.
09. 최종 사용자 입장에서 기술 지식이 없더라도 '코드에 대한 신뢰'를 고려할 때, 다른 선택지가 불투명한 대규모 중앙 기관이라는 점을 감안하면 망설임을 느끼는 편인가요?
그렇지 않다고 생각합니다. 우리는 매일 이런 일을 하고 있으니까요. 제가 이메일에 로그인할 때, 특정 이메일을 삭제하거나 메일을 보냈는데 실제로 전송되지 않을까 걱정하지 않습니다. 만약 그런 일이 발생하면 아마 이메일 사용을 중단하거나 다른 제공업체로 갈아탈 것입니다. 이와 매우 유사하다고 생각합니다. 물론 모든 사람이 내용을 읽고 동작 방식을 검증할 수는 없습니다.
게다가, 제가 이메일 코드를 검사하고 싶어도 코드가 없기 때문에 불가능합니다. 따라서 투명성은 중요한 측면입니다. 모두가 할 수는 없지만, 일부는 샘플 검사를 수행할 수 있습니다. 반복적인 사용과 함께 불변성(Immutability)과 결합되면, 이것이 핵심입니다. 제가 이메일에 로그인할 때, 지난번에 뭔가를 한 이후 코드가 변경되었는지 알 수 없습니다. 이런 투명성은 없습니다. 하지만 Web3에서는 가능하고, 다른 곳에서는 불가능합니다.
10. Sui Move의 미래 발전에 대해 어떤 기대를 가지고 계신가요?
현재 우리가 주목하고 있는 많은 기능들은 Sui Move 패키지를 처음으로 출시한 개발자들과의 경험을 바탕으로, 그들이 기능을 어떻게 발전시키고 싶어 하는지, 어떤 기능은 쉽게 확장되고 어떤 것은 어려운지를 관찰한 데서 비롯됩니다. Sui Move는 패키지를 처음 출시할 때는 매우 적합하지만, "이 타입을 변경하고, 필드를 추가하고, 함수를 추가하고, 기존 패키지를 사용하는 사용자의 신뢰를 깨뜨리지 않으면서도 일관성 있게 운영하고 싶다"는 요구는 매우 도전적인 문제로 바뀝니다. 우리는 이 문제를 연구하며, 프로그래머에게 확장 유연성을 제공하면서도 원래 코드 사용자의 신뢰를 유지할 수 있는 언어 수준의 기능을 추가할 수 있는지 판단하고 있습니다.
이와 관련된 많은 기능들을 연구 중이며, 특히 열거형(enum) 타입에 주목하고 있습니다. 또한 Move 코드와 프론트엔드 코드를 연결하는 경험을 개선하는 데도 많은 노력을 기울이고 있습니다. 우리는 흔히 농담으로 "표준적인 Sui 애플리케이션은 5%는 Move 코드이고 95%는 프론트엔드 코드다"라고 말합니다. 따라서 우리는 그 95%에 매우 주목하고 있습니다. 우리는 Move에 대해 많이 이야기하지만, 나머지 부분을 더 효율적으로 만들고 연결을 쉽게 만드는 것에도 매우 관심이 많습니다. 전반적으로 애플리케이션이 Move 코드로 더 많이 구성되어 보안성을 높이는 방법과, 그 95%의 코드를 Move 개발자뿐 아니라 비-Move 개발자들도 이해하기 쉽게 만드는 방법에 대해 깊이 고민하고 있습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Sui Network
