a16z가 Move 언어의 아버지와 나눈 대화: 프로그래밍 언어에서 출발해 왜 Move가 미래 스마트 계약의 중요한 방향인지
정리 번역: Sui World
지난해 a16z 등 다수의 기관이 Sui를 중심으로 한 Move 블록체인을 적극적으로 지지하면서, Meta Diem의 폐허 위에서 Move 언어가 다시 주목받기 시작했다. 동시에 Sui Move가 등장한 순간부터 긍정적이지 않은 시각도 존재해 왔다.
단지 Move 언어가 Solidity나 다른 개발 언어보다 더 우수할 가능성이 있다는 이유만으로, 우리는 반드시 새로운 스마트 계약 언어를 필요로 하며, 매번 새롭게 Layer1을 구축하는 데 열중해야 하는가?
최근 a16z Crypto 팀은 MystenLabs 공동창업자이자 CTO이며 Move 언어의 창시자인 Sam Blackshear와 '프로그래밍 언어와 암호화폐(Crypto)'라는 주제로 팟캐스트 대담을 진행하며 왜 Move가 미래 스마트 계약의 중요한 방향인지에 대해 논의했다.
이번 팟캐스트에서 a16z Crypto는 Sam Blackshear와 함께 전통적인 프로그래밍 언어와 스마트 계약 프로그래밍 간의 유사점과 차이점, 블록체인 고유의 제약과 기회에 대한 논의를 나누었으며, Move 언어의 설계 철학, 객체 및 자산 중심의 프로그래밍, 보안성, 형식적 검증(formal verification), 거버넌스 및 커뮤니티 도구, 플랫폼 간 호환성 등 다양한 주제를 공유했다.
주요 내용 요약:
1. 프로그래밍 언어와 스마트 계약의 역사
전통 프로그래밍에서 스마트 계약 프로그래밍, 그리고 Move 프로그래밍까지. Move는 타입 시스템, 정적 타이핑, 컴파일타임 검사를 위해 언어를 어떻게 설계할지를 가장 먼저 고민한 언어 중 하나다.
2. Move 스마트 계약의 혁신
EVM은 이더리움을 위해 설계된 플랫폼 구현 세부사항에 과도하게 맞춰져 있다. 개발자들은 결국 이더리움의 많은 설계 결정을 그대로 물려받아야 하며, 일부는 확장성을 어렵게 만드는 오류까지 포함된다.
Move는 핵심 언어에 어떠한 블록체인 특화 요소도 포함하지 않았다. 소스 코드 수준의 혁신이 매우 중요하며, Move는 궁극적으로 코드 검증기와 VM 수준의 보호를 제공하여 다른 프로그래머들의 공격으로부터 안전할 수 있다.
3. Sui Move의 설계 철학
Move는 사용자 거래와 스마트 계약을 실행하기 위한 실행 가능한 바이트코드 언어다. Sui Move에서는 검증자가 더 효율적으로 병렬 처리를 수행할 수 있으며, 이를 통해 저장 및 실행이 더욱 쉬워지고, 이러한 요소들을 프로토콜 수준에 인코딩하거나 사용자와 프로그래머가 직접 고려할 필요가 없다.
4. 보안성
스마트 계약 세계에서는 제약 상태에 놓여 있다. 극소량의 코드를 작성하되 완벽해야 하며, 보안이 최우선 고려 사항이어야 한다. Move의 보안성은 프로그래머가 스스로 발을 저리게 하는 것을 막고, 올바른 원시(primitives)를 제공함으로써 공격에 대비할 수 있도록 해야 한다.
5. 객체 및 자산 중심 프로그래밍
Move는 객체 및 자산 중심의 스마트 계약 프로그래밍 언어로 설계되었다. 대부분의 Web2 객체지향 프로그래밍 언어가 그렇듯이 설계된 것이다. Sui Move에서는 객체 중심으로 사물을 배치하고, 세분화된 접근 권한을 정확히 표현하도록 강력히 유도한다. Sui Move의 글로벌 스토리지는 객체 ID에서 객체 ID로의 매핑 구조를 가진다.
6. 보안성 비교
Move는 재진입(reentrancy) 문제와 스마트 계약 프로그래밍에서 누락되는 권한 확인 문제를 기본적으로 제거한다. 객체 소유권 정보는 객체 메타데이터에 실제로 저장되며, 이는 프로그래머가 제어할 수 있는 것이 아니다. Move Prover는 언어로 작성된 스마트 계약의 오류를 방지하기 위해 설계되어, 개발자가 많은 기본적인 실수를 피할 수 있도록 한다.
7. 스마트 계약 언어의 거버넌스
초기 Move는 Facebook에서 개발되었으며, 실질적인 거버넌스는 없었다. 우리는 언어 확장을 매우 신중하게 다뤄왔다. 간결함이 가장 중요한 요소지만, 적극적으로 확장해 나갈 것이다. Sam Blackshear은 Move가 웹2 개발자와 신규 진입자 모두에게 적용 가능한 유연한 크로스플랫폼 언어로 설계되기를 원한다.
8. 개발자를 위한 학습 조언
많은 코드를 읽는 것, 이것이 언어를 이해하는 최고의 방법이다. 공유하고 깊이 있게 토론하며, 자신의 코드를 기꺼이 공유하고 오픈소스 커뮤니티를 함께 만들어가는 사람들과 교류하라. 업무를 더 쉽게 만들어주는 모든 도구의 작동 원리를 배워야 한다.
아래는 팟캐스트 전체 내용이다. 전체 분량 약 25,000자, 독서 시간 약 30분.
진행자 Sonal Chokshi 소개
Web 3.0에 오신 것을 환영합니다. a16z Crypto 팀이 제작한 차세대 인터넷 구축을 위한 프로그램입니다. 저는 진행자 Sonal Chokshi입니다.
본 프로그램은 개발자, 창작자, 아키텍트, 기업 리더, 정책 입안자 등 암호화폐와 Web 3.0에 관심 있는 모든 이를 위한 것입니다. 오늘은 프로그래밍 언어와 암호화폐를 주제로 다룹니다. 기존 스마트 계약 개발자는 물론 이 분야에 진입을 원하는 개발자들에게도 유용하며, 프로그래밍 언어의 진화와 출현에 호기심을 가진 분들에게도 추천합니다.
오늘의 특별 게스트는 MystenLabs의 공동창업자이자 CTO인 Sam Blackshear입니다. 그는 Web 3.0의 탈중앙화 미래를 위한 기반을 마련하고 있습니다. Sam은 박사 학위부터 Facebook 근무, Move 및 스마트 계약 구축을 위한 오픈소스 언어의 창시자로서 프로그래밍 언어 분야에서 오랜 경력을 쌓아왔습니다. 이에 대해 더 깊이 이야기해볼 예정입니다.
프로그램 전체에 걸쳐 a16z Crypto의 스마트 계약 연구 엔지니어 Noah도 함께합니다. 그는 최근 이더리움을 위한 경량 클라이언트 Helios를 개발했으며, 어려운 gas 최적화 문제를 해결했습니다.
또한 a16z Crypto의 엔지니어 책임자 Eddy Lazzarin도 참여합니다. 그는 이전에 Netflix에서 소프트웨어 엔지니어링을, Facebook에서는 데이터 엔지니어링과 데이터 과학을 담당했습니다. 참고로 아래 내용은 투자, 비즈니스, 법률 또는 세금에 대한 조언이 아님을 알려드립니다.
1. 프로그래밍과 스마트 계약의 역사
진행자 Sonal Chokshi:
전통 프로그래밍의 역사부터 시작하겠습니다. 먼저 Noah가 발언하고, 그 후 Sam Blackshear와 Eddy가 말하겠습니다.
a16z Crypto Noah:
프로그래밍 역사가 스마트 계약 프로그래밍 역사에 어떤 영향을 미쳤는지 알고 싶습니다. 왜냐하면 전통 프로그래밍, 스마트 계약 프로그래밍, 그리고 Move 언어라는 세 가지가 각각의 역사를 가지고 있다고 생각하기 때문입니다. 맞죠?
Sui CTO Sam Blackshear:
맞습니다. 저는 이런 틀을 좋아합니다. 사람들이 언어를 문법이나 감정적인 면에서 설계한다는 것은 맞지만, 그것만으로 끝나는 건 아닙니다. 그래서 저는 이런 큰 그림의 틀을 아주 좋아합니다.
a16z Crypto Eddy Lazzarin:
이어서 말씀드리면, 전통 프로그래밍은 지난 2~30년간 다양한 트렌드를 겪었습니다. 전통 프로그래밍 언어는 계속 변화해왔으며, 유행하는 주제들이 오갔습니다. 한동안 동적 프로그래밍 언어와 매우 느슨한 타입 체크가 매우 인기가 있었습니다. 타입을 잊고, 모든 기술적인 디테일을 무시한 채 코드를 작성하는 것이 더 인간 친화적인 방식이라고 여겨졌습니다.
Sui CTO Sam Blackshear:
하지만 최근 사람들은 타입 시스템, 정적 타이핑, 컴파일타임 검사 등의 문제를 더 깊이 고민하기 시작했습니다. 프로그램이 실행되기 전에 가능한 모든 세부사항을 파악하려는 노력입니다. 이러한 트렌드는 계속해서 변화합니다. 그러나 스마트 계약 프로그래밍은 너무나도 새로운 분야이기 때문에, 아직 그러한 역사적 흐름이 나타나지 않았습니다. 이 점에서 매우 다릅니다.
저는 Move 언어가 타입 시스템, 정적 타이핑, 컴파일타임 검사 등을 위해 언어를 어떻게 설계할지를 가장 먼저 고민한 증거라고 생각합니다. 앞으로 어떤 변화가 있을지, 예를 들어 정적 타이핑과 동적 타이핑 같은 스마트 계약 프로그래밍 내에서 나타날 수 있는 주제들에 대해 기대하고 싶습니다. 이런 주제들은 현재 Solidity라는 단 하나의 언어밖에 없기 때문에 아직 나타나지 않았을 수 있습니다.
진행자 Sonal Chokshi: 그러면 이것이 스마트 계약 프로그래밍으로의 전환과 어떻게 연결되는지 설명해주실 수 있나요? 다시 Sam에게 부탁드리겠습니다.
Sui CTO Sam Blackshear:
EVM이 스마트 계약 언어로서 처음 등장했던 이 스마트 계약 공간에는 다양한 트렌드가 있었습니다. 사람들은 스마트 계약으로 무엇을 하고 싶은지 몰랐고, 어떻게 작성해야 할지도 몰랐습니다. 따라서 유연성이 더욱 중요하다고 생각했습니다. 전문가들이 사용 사례를 발견하기 위해 필요한 것을 알아내는 데 도움이 되었죠. 지금은 이미 알거나, 적어도 블록체인 구축의 기본 구성 요소에 대해 어느 정도 이해하고 있다고 생각합니다.
스마트 계약의 트렌드는 극도로 특정 분야에 국한되어 있습니다. 자산에 대한 템플릿을 정의하고, 자산 이전 전략을 정의하며, 접근 제어와 권한을 확인합니다.
이것이 기본입니다. 스마트 계약 언어로 컴파일러나 운영체제 같은 것을 만들지는 않습니다. 따라서 일반적인 프로그래밍 언어와 비교해 매우 특화된 장점을 가집니다.
ERC-20 표준이 EVM이 프로그래밍 가능해진 이후에야 등장했다는 사실을 생각해보면, EVM은 이더리움 프로그램의 기본 구성 요소 중 하나로 여겨졌음에도 불구하고, 그 이전에 명확하게 정의된 기본 요소가 있었는지는 의문입니다.
그렇기 때문에 이제는 타입을 당연하게 여길 수 있습니다. 저는 타입을 우회하는 것이 일정한 기술 부채를 감수하는 것으로 볼 수 있다고 생각합니다. 규모가 작고 빠르게 움직이며 코드를 버릴 수 있다면, 이러한 기술 부채는 완전히 수용 가능합니다. 하지만 회사나 스타트업 규모에서 보면, 작은 회사가 빠르게 성장하고 모든 사람이 전체 코드베이스를 이해할 수 있을 때는 이러한 기술 부채가 용인될 수 있습니다.
그러나 매우 규모가 크고, 많은 사람들이 코드를 변경하며, 새로 구축된 객체와 시스템의 결과를 모를 때는 문제가 됩니다. 타입 시스템을 통해 명확하고 직접적인 방식으로 코드를 작성할 때 장애물이 생기게 되며, 나중에 다른 사람이 부딪히게 될 유리 울타리를 우연히 만들지 않게 됩니다.
예를 들어, 여러분이 언급한 복제 방지, 자산의 최대 공급량 설정 등은 규모에 상관없이 유지되어야 하는 매우 중요한 제약 조건입니다. 이는 프로젝트의 건전성과 보안을 유지하기 위한 필수적인 제약입니다. 이러한 경계를 이해한다는 것은 이제 당신이 이를 시행할 수 있도록 하는 프로그래밍 언어를 만들 수 있다는 것을 의미합니다. 제가 Move 언어를 바라보는 관점입니다.
우리가 올바른 일을 하기 위해 필요한 제약 조건의 유형을 이해하게 되면서, 이제 그것을 언어 자체에 포함시킬 수 있는 능력을 갖추게 되었습니다. 그래서 저는 이것이 여러분이 말한 타입과 어느 정도 유사하다고 생각합니다.
타입이 프로그램의 건전성과 보안에 매우 중요하다고 말씀하셨습니다. 여러분은 동적 타이핑이 소규모 프로젝트에는 적합하지만, 프로젝트가 커지면 정적 타이핑을 사용해야 한다고 말했습니다. 저는 이에 다소 반대 의견을 가지고 있는데, 완전한 정적 타이핑이 더 적합할 수 있다고 생각합니다. 이것은 다소 새로운 관점일 수 있습니다. 이는 프로그래머의 건전성을 위한 것입니다. 제가 Python을 작성할 때 'control k' 단축키를 눌렀을 때 함수 시그니처가 매개변수 이름만 보이는 것을 보면 정말 두렵습니다. '정말로 내가 무엇을 해야 하는지 모르겠네'라고 생각하게 됩니다.
a16z Noah: 사람들이 코드를 작성한 후 다시는 보지 않는 방식을 받아들이는 것이 믿기지 않습니다.
a16z Eddy Lazzarin: 그들은 마음속으로 시스템 요구사항을 기억할 수 있다는 것을 기본 전제로 삼습니다.
a16z Noah: 하지만 100줄짜리 프로그램이라도 저는 그런 전제를 가질 수 없다고 생각합니다.
Sam Blackshear : 작동은 하지만 완벽하지는 않습니다.
a16z Eddy Lazzarin:
여러분 말씀이 맞다고 생각합니다. 그리고 이러한 마인드셋은 진화해 왔다고 생각합니다. 이전에는 타입 시스템이 동료로부터 자신을 보호하기 위한 것이었습니다. 스타트업이 너무 커졌을 때 유용했죠. 하지만 지금은 오히려 자기 자신을 보호하기 위한 수단이 되었습니다.
스마트 계약 환경에서는 공격자로부터 자신을 보호하기 위한 것입니다. 이것이 진정한 차이점입니다. 일반 프로그램에서는 타입 시스템의 제약을 받는 상태에서 프로그램을 배포하지 않습니다. 공격자는 다른 언어로 머신 코드를 작성할 수 있기 때문입니다. 자신의 방화벽만 지키면 됩니다. 하지만 여기서는 잘 정의된 타입 객체를 작성하고, 그것이 공격자의 코드로 흘러가더라도 무결성이 유지되어야 합니다. 타입 시스템이 내 안전을 보장해야 합니다.
말씀하신 것처럼, 이는 멋진 도구이며 다른 요구사항을 가져옵니다. 예를 들어 복제 방지와 같은 것을 시행해야 합니다. 일반적인 타입 시스템에서는 고려하지 않는 문제이며, 삭제 방지나 특정 방식으로 값 사용 또는 파괴를 보장하는 것도 마찬가지입니다. 우리는 스마트 계약을 연구하고 이러한 사용 사례를 위한 의미 있는 타입 시스템을 제공하려 하기 때문에 결국 이것들을 Move에 추가하게 되었으며, 미래의 스마트 계약 언어에도 추가될 수 있습니다.
진행자 Sonal Chokshi:
사실, 여러분들 전통 프로그래밍과 스마트 계약 프로그래밍 사이의 다른 차이점들에 대해 좀 더 이야기해봅시다. 그런데 그 전에, 스마트 계약 프로그래머가 사용할 수 있는 언어들에 대해 간단히 소개해주실 수 있나요? 큰 그림을 이해하고 싶습니다. Solidity, Viper 등 어떤 언어들이 있는지 아는 것이 더 빨리 시작하는 데 도움이 될 것입니다.
Sui CTO Sam Blackshear :
네, 기본적으로 스마트 계약을 작성하고자 한다면 거의 항상 Solidity를 사용하게 됩니다. 다만 다른 소규모 생태계 중 하나에 속해 있다면 예외입니다.
폴카닷(Polkadot) 생태계에 있다면 ink!를 사용합니다(Sui World 주: ink!는 Parity가 개발한 스마트 계약 언어로, Rust로 스마트 계약을 작성한 후 Wasm 코드로 컴파일). 스타크넷(StarkNet) 생태계에 있다면 Cairo를 사용합니다(Sui World 주: Cairo는 STARK 증명 시스템의 프로그래밍 언어 중 하나).
하지만 대부분의 경우, 스마트 계약을 작성하는 법을 배우고 싶다면 저는 Solidity와 EVM을 배우라고 조언합니다. Viper도 사용할 수 있지만, 단점은 Viper가 비교적 새롭기 때문에 취약점이 더 많을 수 있다는 점입니다. 몇 년 전, 입금 계약을 검증할 때 Viper 컴파일러에 여러 취약점이 발견된 적이 있습니다. 이 취약점을 발견한 사람은 현재 16z에서 일하고 있으며, Day June이라는 형식 검증 전문가입니다.
Day June이 형식 검증 전문가이기 때문에 현재 a16z에서 일하고 있습니다. 현실은 여러분이 무언가를 배워야 하며, 어떤 언어라도 배워야 한다는 것입니다.
심지어 EVM에 대해서도 깊이 이해해야 합니다. 진정한 훌륭한 스마트 계약 엔지니어가 되고 싶다면, EVM에 대해 터무니없이 깊은 이해를 가져야 합니다. 각 연산의 가스 비용을 말할 수 있어야 하며, 가스 비용과 관련된 코드를 정확히 설명할 수 있어야 합니다. 이것이 우리가 현재 살아가는 세상입니다.
a16z Eddy Lazzarin: 언급할 만한 점은, 소프트웨어 엔지니어라면 언제나 코드를 실행하는 기계에 대해 알아야 한다는 것입니다. 프로그래밍 환경에 대해 알아야 할 것이 많습니다. 하지만 스마트 계약 프로그래밍에서는 환경이 매우 풍부하고 복잡합니다. 알아야 할 컨텍스트가 많으며, 이는 언어 자체와 거의 관련이 없습니다. 주변에서 발생하는 일, 주변의 객체들, 서로 다른 코드가 어떻게 호출되는지 등이 매우 특이한 현상입니다.
진행자 Sonal Chokshi: 그렇다면 Solidity를 배우는 데 가장 가까운 언어는 자바스크립트인가요?
Sui CTO Sam Blackshear : 모두 자바스크립트라고 말하는데, 'function'이라는 키워드를 사용하기 때문입니다. 하지만 불행히도 두 언어는 크게 다르지 않습니다.
a16z Eddy Lazzarin: 구문상으로는 Solidity가 자바스크립트의 많은 특징을 계승했습니다. 눈을 가늘게 뜨거나 기분이 나쁘면 비슷해 보일 수도 있지만, 실제로는 전혀 다릅니다. 가상 머신 환경이 크게 다르기 때문에 공통점은 거의 없습니다.
진행자 Sonal Chokshi: 비슷한 프로그래밍 언어가 있나요?
a16z Noah: 네, 저는 직접적으로 비슷한 프로그래밍 언어는 없다고 생각합니다. Was(Sui World 주: WebAssembly Studio, C/C++ 및 Rust 코드를 WASM 형식으로 컴파일하는 온라인 도구)에 익숙하고, Surplus처럼 높은 격리가 필요한 환경에서 코드를 작성하려는 시도는 가장 가까울 수 있습니다. 이 코드는 독립적으로 실행되지만 일정 수준의 통신이 필요합니다. 하지만 여전히 매우 다르며, 사상이 완전히 다릅니다. 겉보기의 유사성은 위험할 수 있습니다.
a16z Eddy Lazzarin: 아마도 관련 있는 것은 프로그래밍 언어 역사상의 몇 가지 중대한 실수일 것입니다. 블록체인 분야에서도 잘못된 길을 걷는 혹독한 역사가 있었는지 궁금합니다. 우리는 끔찍한 길을 걷고 있는 건가요?
진행자 Sonal Chokshi: 좋은 질문이네요.
Sui CTO Sam Blackshear :
좋은 질문입니다. 1977년 C 언어가 발표되었고, Standard ML도 같은 해에 발표되었습니다. Standard ML은 큰 영향을 미쳤습니다. 지금도 OCaml 언어, Rust 언어 등이 그 영향을 많이 받았으며, Move 언어 역시 영향을 받았습니다. 하지만 이러한 아이디어들은 이미 오래전부터 존재했습니다. 많은 사람들이 C 언어가 주류가 되지 않고 Standard ML의 사상, 즉 강력한 타이핑과 내장 보안성이 널리 수용된 대체 미래를 상상합니다.
진행자 Sonal Chokshi: 그렇다면 컴퓨터 기술의 발전 추세는 어떤가요? 이것이 실수라고 말하는 것은 아니지만, Standard ML 같은 언어가 오늘날에도 매우 현대적으로 보인다는 점이 흥미롭습니다. 그런 대체 우주를 상상하는 것은 재미있는 일이며, 처음 알았을 때 정말 충격적이었습니다.
a16z Eddy Lazzarin: 호기심이 생기는데, 왜 C 언어와 비슷한 언어들이 그렇게 직관적이고 명령형인지, 컴퓨터를 낮은 수준에서 사고하는지 궁금합니다. 프로그래밍 언어로서는 컴퓨터 하드웨어 수준에서 직접적으로 사고하는 언어들이 많다고 느껴집니다. 이것이 제가 C 언어를 바라보는 관점인데, 왜 이런 길을 걷게 된 것일까요?
Sui CTO Sam Blackshear :
当时的 하드웨어 제약이 C 언어를 사용하도록 강요했기 때문이라고 생각합니다. 효율적인 프로그램을 작성하거나 컴퓨터의 한계를 밀어붙이고 싶었다면, 저는 하드웨어를 앞당긴다면 다른 길을 선택했을 것입니다. 하지만 함수형 프로그래밍은 어렵고, 여러 면에서 직관적이지 않습니다. C 언어가 어렵지 않다고 말하는 것은 아니지만, 더 쉽게 입문할 수 있다고 생각합니다. 하지만 이미 매우 복잡한 작업을 수행하고 있다는 것을 깨달았을 때는 이미 늦었습니다. 함수형 언어는 확실히 더 가파른 학습 곡선을 가지고 있지만, 일단 익히면 코드를 독립적으로 잘 생각할 수 있고, 모든 것이 잘 해결된다는 것을 깨닫게 됩니다.
a16z Eddy Lazzarin: 컴퓨터가 하드웨어 수준에서 어떻게 작동하는지 많이 생각한다면 C 언어와 같은 언어가 더 직접적이라고 생각합니다. 하지만 프로그래밍 언어에 대해 잘 모른다면 C 언어가 더 쉽게 시작할 수 있습니다. 하지만 프로그래밍 언어에 대해 잘 안다면 ML과 함수형 프로그래밍 같은 언어들이 더 탐구할 가치가 있다고 생각합니다.
Sui CTO Sam Blackshear :
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
