비탈릭 블로그 포스트 해설: Web3 인프라의 다음 단계는 래핑인가, 확장인가?
작자: CP, Artela CTO 겸 공동 창립자
지난주 Vitalik은 블로그 포스트 <Should Ethereum be okay with enshrining more things in the protocol?>를 발표하며, 이더리움이 상위 계층 애플리케이션에 필요한 기반 기능들을 프로토콜에 '포함(enshrine)'해야 하는지에 대한 사고를 공유했으며, 더 많은 핵심 기능들을 체계적으로 포함시키기 위한 프레임워크 수립 방안을 논의했다.
이는 전형적인 플랫폼형 시스템이 직면하는 핵심 과제이다. 핵심 기능들을 하위 계층에 '포함'시킬 것인지, 아니면 애플리케이션 개발자가 상위 계층에서 직접 '확장(extend)'할 것인지 말이다. 인프라가 대규모 확장을 앞두고 있는 단계에서 '포함 vs 확장' 설계는 성패를 좌우하는 중요한 결정 중 하나다.
최근 반년간 주요 인프라들은 각각 중요한 기술 업데이트를 발표했다. Uniswap은 커스텀 풀(pool) 기능을 지원하는 Hook 메커니즘을 도입했으며, MetaMask 지갑은 사용자 확장 기능 추가를 위한 Snaps를 출시했다. 또한 이더리움 역시 현재 '포함 vs 확장' 문제에 직면해 있다.
본 글에서는 Web3 인프라들이 '포함 vs 확장'에 대해 어떤 설계적 선택을 해왔는지 살펴보고, 공용 블록체인 인프라가 마주한 이 문제에 대한 개인적인 견해를 제시하고자 한다.
이더리움이 직면한 문제: 포함할 것인가, 확장할 것인가
'포함 vs 확장' 문제에 있어 이더리움은 일관되게 '확장' 쪽을 선택해왔다.
이더리움의 설계 철학은 유닉스(Unix)에서 비롯된다. 즉, 극도로 간결하고 범용적인 코어를 만들어 두고, 사용자 요구사항은 애플리케이션 계층에서 개발자가 구현하도록 하는 것이다. 이를 가능하게 하는 핵심 기술은 바로 EVM이다. 튜링 완전성을 갖춘 스마트 계약 언어를 통해 개발자는 앱 계층에서 자유롭게 기능을 정의할 수 있다.
일견 타당해 보이는 이 모델이지만, '탈중앙화된 유닉스'라는 맥락에서는 다소 한계를 드러낸다. 그 이유 중 하나는 EVM의所谓 '튜링 완전성'이 실제 사용 시 그리 '완전하지' 않다는 점이다. 가스 메커니즘과 제한된 opcode 하에서 모든 프로그램은 제한된 단계 안에서 제한된 명령어만으로 작업을 완료해야 하며, 이는 웹2 앱이 유닉스 사용자 공간에서 할 수 있는 거의 모든 것을 Web3 앱이 재현하기 어렵게 만든다. 롤업(Rollup)이나 AA 지갑과 같은 고급 dApp들도 L1 수정 없이 동작은 하지만 MVP 수준에 머물며 효율성과 사용성 면에서 목표와 큰 차이를 보인다.
개발자들 앞에는 이제 선택지 하나가 남는다. 바로 EIP다. 자신이 필요로 하는 핵심 기능을 이더리움 코어 팀이 하위 계층에 '포함'하여 제공받는 길이다.
EVM 기반의 '확장'만으로는 애플리케이션 발전 수요를 더 이상 감당할 수 없으므로, 이제는 어떻게 '포함'할지를 진지하게 고민해야 한다.
그러나 탈중앙화 인프라에서 상위 앱 기능을 '포함'하는 것은 단순히 코드를 통합하는 것을 넘어선 문제다. 가장 큰 장애물은 바로 탈중앙화 시스템의 핵심 난제인 거버넌스(governance)다. '포함'은 코어 팀이 개발 및 유지보수 외에도 해당 기능의 거버넌스 책임까지 떠안아야 함을 의미하며, 이는 이더리움의 신뢰 모델을 약화시키고 지속 가능성에 부정적 영향을 줄 수 있다.
결국 현실은 이렇다. 코어 팀이 '포함'할 수 있는 기능의 수는 제한적이며, 반드시 넓은 커뮤니티의 합의를 얻어야 하고, 구현 속도도 느려서 종종 수 년이 소요된다.
또한, 당신이 원하는 기능이 광범위한 합의를 얻지 못한 기초 기능이라면, 이더리움은 그것을 수용하지 못할 가능성이 크다. 심지어 시도조차 어려울 수 있으며, 결국 별도의 앱 체인을 구축해 높은 개발 및 운영 비용을 감수하고, 스마트 계약 생태계의 컴포저빌리티(composability)라는 장점을 잃게 될 수도 있다.
'포함 vs 확장' 문제에 대해 이더리움은 아직 명확한 해결책을 내놓지 못했다. '포함'을 어떻게 체계적으로 진행할 것인가—즉, Vitalik이 언급한 바와 같이, 어떤 기능을 포함할지, 어떻게 포함할지를 판단하는 프레임워크를 마련하는 방법에 대해서도 여전히 탐색 중이다.
유닉스에서 배울 수 있는 또 다른 교훈: 네이티브 확장(Native Extension)!
'포함 vs 확장' 문제에서 이더리움이 코어 팀의 '포함'에 의존하게 된 주요 원인은 EVM의 확장성 부족이다. 관점을 바꿔보자. 만약 앱 계층의 확장성을 높인다면, 많은 문제를 해결할 수 있지 않을까? 예컨대 개발자가 자신의 앱에 맞는 하위 계층 기능을 직접 커스터마이징할 수 있고, 더 이상 하위 계층 팀의 '포함'을 기다릴 필요가 없다면 말이다.
우리는 이더리움이 유닉스로부터 많은 설계 철학을 차용했다는 사실을 알고 있다. 그렇다면 유닉스 체계 안에서 더 깊이 아이디어를 찾아보자.
유닉스 기반의 상용 운영체제는 PC 시장을 대상으로 하며, 다양한 앱 계층의 요구와 기업 사용 환경의 확장 요구까지도 감당해야 한다. 그러나 이러한 운영체제의 코어 팀은 비교적 낮은 '포함' 부담을 가지고 있는데, 그 이유는 앱에 제공되는 확장성이 매우 높아 대부분의 기능을 사용자가 스스로 해결할 수 있기 때문이다.
맥OS X를 예로 들면, 일반적으로 운영체제는 커널 상태(kernal mode)와 사용자 상태(user mode)로 나뉘며, 사용자 앱은 일반적으로 사용자 상태에서 커널 상태 프로그램이 제공하는 기능을 이용한다. 간단히 (완전하진 않지만) 비유하자면, EVM 위의 스마트 계약은 모두 사용자 상태 앱에 해당하고, 이더리움 프로토콜 계층은 커널 상태에 해당한다고 볼 수 있다.
그러나 맥OS X는 개발자가 자신의 프로그램을 커널 상태에 직접 배치해 커널 기능을 확장할 수 있도록 허용한다. 즉, 운영체제 코어 팀이 일일이 기능을 '포함'할 필요 없이 말이다. 맥OS X는 '커널 확장(Kernel Extension)'과 '시스템 확장(System Extension)'이라는 핵심 메커니즘을 제공하는데, 이는 개발자가 일정한 보안 모드 하에서 커널 확장을 개발하고, 더 높은 권한의 기능을 활용해 사용자 상태 앱으로는 불가능한 기능을 구현할 수 있게 한다.
여기서 얻을 수 있는 교훈은, '커널 확장' 모델이 '탈중앙화된 유닉스'에서도 가능한가 하는 점이다. 그 구조는 아래 이미지와 같다.
블록체인 프로토콜은 '스마트 계약' 외에도 또 다른 형태의 프로그램인 '네이티브 확장(Native Extension)'을 지원한다. 이는 다음과 같은 특징을 갖는다:
1) 스마트 계약보다 더 많은 하위 프로토콜 API 접근 권한을 가짐
2) 실행 환경의 효율성이 EVM 대비 수십 배 이상 향상됨
3) 하위 프로토콜과 분리되어 있어, 프로토콜의 안정성에 영향을 주지 않음
4) 따라서 거버넌스 측면에서도 하위 계층 팀이 유지보수할 필요 없이, 앱 팀이 자체적으로 배포 및 관리 가능
기술적으로 위 네 가지 조건을 만족한다면, 개발자는 더 이상 하위 계층 팀의 '포함'을 기다리지 않고도 자신이 원하는 하위 기능을 자유롭게 커스터마이징할 수 있을 것이다.
이 패러다임을 우리는 잠정적으로 '네이티브 확장(Native Extension)' 패러다임이라 부르고자 한다. 다음으로 기존 Web3 인프라에서 이 개념의 흔적이 있는지 살펴보자.
훅(Hook), 훅(Hook), 훅(Hook)들…
소프트웨어 세계에서 위대한 기술은 종종 위대한 사용 사례에서 비롯된다. 디파이(DeFi) 인프라로서의 Uniswap은 '플랫폼'으로서의 전환기에 있으며, '포함 vs 확장' 문제에 놀라운 답을 제시했다. 바로 훅(Hook)이다. 개발자는 훅을 이용해 풀(pool)에 무허가로 확장 기능을 추가할 수 있으며, 다양한 기능을 가진 풀 경험을 제공할 수 있다. 핵심 팀이 계속해서 '포함'을 통해 기능을 업그레이드할 필요가 없다.
훅 메커니즘은 앞서 언급한 네이티브 확장의 여러 조건과 유사하다:
· 훅은 풀의 실행 생명주기 중 특정 시점에 개입할 수 있으며, 런타임 데이터에 접근할 수 있어 더 높은 수준의 접근 권한을 가짐
· 훅과 풀은 서로 독립된 계약이며, 훅의 보안 결함이 풀에 영향을 미치지 않음
· 거버넌스 측면에서, 훅은 제3자 개발자가 무허가로 개발 및 배포할 수 있으며, 전역 활성화되지 않고, 각 풀이 필요에 따라 특정 훅을 연결해 커스텀 기능을 활성화함
훅은 작고 아름다운 설계로, 풀의 확장성 문제를 해결했다. 애플리케이션 계층 인프라가 먼저 이러한 개념을 적용한 사례이며, 이제 좀 더 복잡한 하위 계층 프로토콜(L1/L2)의 접근법을 살펴보자.
새로운 공용 블록체인 프로젝트들의 확장 전략
이더리움이 어려움을 겪고 있는 가운데, L1 확장을 추구하는 L2 프로젝트들은 어떤 생각을 갖고 있을까?
Arbitrum Stylus: 개발자가 직접 프리컴파일드 계약을 '포함'하게 하라!
아마도 잘 알겠지만, EVM은 '프리컴파일드 계약(precompiled contract)'을 통해 기능을 확장할 수 있다. 이 코드는 EVM 내에서 실행되지 않고 노드에 통합되어 하위 계층에서 실행된다. 예를 들어 새로운 암호 알고리즘을 추가할 때, 계산이 너무 복잡하고 비용이 많이 들기 때문에 프리컴파일드 계약으로 구현하면, 앱 계약이 이를 호출해 사용할 수 있다. 그러나 프리컴파일드 계약 추가 권한은 개발자에게 열려 있지 않으며, EIP를 통해 이더리움 개발팀이 '포함'해야만 가능하다.
Arbitrum Stylus는 'EVM+' 패러다임을 제안한다. 즉, L2는 EVM 호환성을 유지하면서도, 개발자가 EVM의 한계를 넘어서 무허가로 고성능 프리컴파일드 계약을 배포할 수 있도록 한다. 그 실현 원리는 실행 계층에 WASM 실행 환경을 추가해 WASM 계약을 동적으로 로드하고 실행하는 것이다. WASM은 EVM 대비 수십 배 높은 효율을 제공하며, 다양한 프로그래밍 언어도 지원한다.
이는 이더리움의 '포함' 문제를 최적화할 수 있는 구현 중 하나다. EVM 확장 수요가 더 이상 하위 계층 팀의 '포함'을 기다릴 필요가 없으며, 하위 팀은 실행 환경 유지보수에 집중하고, 신규 기능의 도입·개발·거버넌스는 앱 계층에 위임된다.
다만 Stylus는 초기 단계에 있으며, 이 모델의 더 큰 도전 과제들은 아직 나타나지 않았고, 해결 가능한 문제도 제한적이다. 현재는 동적 프리컴파일드 계약 캡슐화만 지원하며, 이더리움은 프리컴파일드 계약 외에도 더 많은 '포함' 과제를 안고 있다. 하지만 기쁜 점은 이것이 네이티브 확장 패러다임에 가장 근접한 구현 중 하나라는 점이며, 차세대 인프라의 대표로써 확장성 설계를 도입해 생태계의 미래 규모화에 따른 '포함' 문제를 해결하고 장기 생태계 발전을 고려했다는 점이다.
네이티브 확장: '모듈화된 포함' 접근법!
Web2와 Web3의 여러 인프라 프로젝트를 검토한 후 다시 '포함 vs 확장' 문제를 돌아보면, 명확한 방향성을 찾을 수 있다. 바로 확장성을 높여 개발자가 모듈화 방식으로 자신이 원하는 기능을 직접 '포함'할 수 있도록 하는 것이다.
이것이 바로 네이티브 확장 패러다임이 인프라에서 수행하는 핵심 역할이다. 인프라의 확장성을 높임으로써 선택권을 개발자에게 돌려주고, 핵심 프로토콜의 안정성은 유지한 채로 개발자가 모듈화 방식으로 자유롭게 기능을 포함하고 확장할 수 있게 된다.
이더리움은 '포함'의 효율성을 높이려 노력하고 있으며, Arbitrum Stylus는 프리컴파일드 계약의 해방을 추진하고 있다. 더 먼 미래를 바라보면, 공용 블록체인은 네이티브 확장 패러다임을 통해 앱 계층의 창의성을 완전히 해방시킬 수 있으며, 이는 Uniswap V4가 우리에게 준 느낌과도 같다.
네이티브 확장 패러다임 기반의 새로운 L1 공용 블록체인: Artela
관점을 전환하자. 여기서 '우리'란, 필자가 CTO로 있는 팀인 Artela를 말한다. 우리가 이 문제에 대해 어떤 사고를 하고 행동하고 있는지 공유하고자 한다.
Artela 블록체인에서는 EVM 외에도 WASM 실행 환경을 추가로 탑재했다. 이는 상태를 가진(stateful) 프로그램을 실행할 수 있으며, 일종의 상태 저장형 프리컴파일드 계약과 유사하다. 더 나아가, 이 위에 훅(Hook)과 유사한 메커니즘을 제공하여 블록 및 트랜잭션 처리의 여러 생명주기 단계에서 실행을 트리거할 수 있다. 즉, Arbitrum Stylus처럼 프리컴파일드 계약만을 위한 것이 아니라, 트랜잭션과 블록의 실행 흐름 자체를 커스터마이징할 수 있어 더욱 폭넓은 기능 포함이 가능하다. 예를 들어 트랜잭션 검증 단계에서 WASM 기반 네이티브 확장을 트리거해 새로운 알고리즘으로 트랜잭션을 식별하고 검증할 수 있다. 이러한 훅은 Artela에서 '조인 포인트(Join Point)'라 불리며, 이 네이티브 확장은 스마트 계약이 아니라 '어스팩트(Aspect)'라 불린다. AOP(Aspect-oriented Programming) 개념과 유사하게, 실행 중인 블록체인 시스템 내에서 동적으로 각 조인 포인트에 새로운 기능을 삽입하는 것이다!
구체적인 예를 들어보자. 우리는 투자자들과 Web2 기관들과의 대화에서 Web3로 대규모 자산을 가져오는 데 가장 큰 장벽이 무엇인지 논의했으며, 가장 많이 언급된 것은 '보안' 문제였다. Web2 수준의 리스크 관리 기술은 수십억 달러의 자산을 안전하게 보호하지만, 이러한 기술은 Web3 기술 스택에 쉽게 통합되지 않는다. NASA 항공 분야 출신의 Carl도 동일한 의견을 제시했다. "왜 우리는 Runtime Protection과 Aspect가 필요한가?"
런타임 프로텍션(Runtime Protection)은 보안 리스크 관리의 핵심 수단이다. 현재 Web3에서는 정적 감사, 형식적 검증, 실시간 모니터링, 프론트런ning 대응 등 강력한 보안 회사들이 존재하지만, Web2 수준의 실시간 리스크 관리에는 여전히 크게 못 미친다. 핵심 원인은 mempool 주변의 보안 수단이 한정되어 있다는 점이다. 트랜잭션이 once mempool을 지나면 더 이상 대응할 수 없다. 그러나 mempool 이후의 트랜잭션 실행 단계에서 확장성이 있다면, 보안 전문가가 런타임 수준의 보안 전략을 배포할 수 있어 보안 수준이 한 단계 올라갈 것이다. 어스팩트(Aspect)는 개발자에게 실행 계층 깊숙이 침투하는 보안 확장 능력을 제공한다!
개발자는 자신의 프로젝트만을 위한 전용 어스팩트를 배포해 원하는 프로토콜 계층 기능을 커스터마이징할 수 있다. 예를 들어 런타임 보안을 추가해, 대규모 자금 유출을 초래할 수 있는 트랜잭션을 어스팩트에서 차단할 수 있다.
또한 개발자는 공용 어스팩트를 배포해 여러 프로젝트가 재사용할 수 있는 기반 기능을 포함시킬 수도 있다. 예를 들어 특정 알고리즘과 트랜잭션 유형을 구현한 어스팩트로 AA 지갑을 더욱 프로그래머블하고 컴포저블하게 만들고, 다른 개발자들도 이 어스팩트를 활성화해 자신의 프로젝트에 이 기반 기능을 사용할 수 있다.
Artela로서, 우리의 생각은 점점 더 확고해지고 있다:
· 개발자가 앱 계층에서 네이티브 확장을 통해 무허가로 문제를 해결할 수 있도록 하고, 하위 계층 공용 블록체인 팀의 '포함'을 기다리지 않도록 한다
· Web2 배경의 대형 기관과 대규모 자금이 블록체인에 안심하고 스테이킹할 수 있도록 한다(Web2 수준의 런타임 리스크 관리 강화를 통해)
· 개발자가 파이를 키우는 혁신을 할 수 있는 좋은 생태환경을 제공한다(EVM은 빠르게 한계에 도달할 수 있지만, EVM+네이티브 확장은 더 큰 잠재력을 가질 수 있음)
· 올체인 게임, RWA 등 더 많은 비즈니스 로직을 블록체인에 올리려는 dApp들에게 이상적인 집을 제공한다
우리는 현재 이더리움이 앱 특성 기능을 어떻게 '포함'할지 고민하는 단계에 머물러 있으며, '포함' 부담을 해소해 창의성을 다시 개발자에게 돌려주는 계획은 보이지 않는다는 점을 본다. 탈중앙화 앱의 경계를 뚫고 혁신을 시도하려는 차세대 혁신자들에게 이 상황은 매우 답답하다. 그들은 견고한 탈중앙화 네트워크를 필요로 하지만, 동시에 자유롭게 발휘할 수 있는 공간도 필요하다. 바로 이러한 이유로 우리는 네이티브 확장 패러다임 기반의 새로운 L1 공용 블록체인을 구축하는 데 몰두하고 있다. 인프라가 혁신의 발걸음을 거부하지 않도록 하기 위해서 말이다.
Web2 도입하기
마지막으로, 이 두 단어로 글을 마무리하고자 한다. 코드 작성 측면에서 탈중앙화된 Web3 스택과 Web2 스택은 완전히 다른 사고방식을 요구하지만, 설계 철학과 발전 역사라는 관점에서 Web2라는 도서관 속 보물을 찾는 것을 포기할 필요는 없다. keep building!
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@Artela_Network
