블록체인 SDK 써야할까? 써야 한다면 왜 써야할까?

Key Takeaways

• 블록체인 SDK는 시간과 자본을 절약하여 양질의 블록체인을 생산할 수 있는 블록체인 생산 프레임 워크이다.

• 블록체인 SDK를 활용하면 단순히 비용을 절감할 수 있을 뿐만 아니라, 이들이 구축해놓은 생태계와 다른 인프라 자원들을 누릴 수 있다는 장점이 있다.

• 하지만 기술이 표준화 되어있다는 부분에서, SDK를 사용했을 때 기술적 해자를 가져가기 어렵고, 생태계에 대한 의존도가 발생한다는 단점도 생각해보아야한다.

• 블록체인 SDK들이 늘어나고 있다는 것은 블록체인 산업의 저변이 넓어지고 있다는 뜻이기도 하기 때문에 양질의 SDK들이 더 나와서 블록체인 산업의 인프라가 더 견고해지길 바란다.

요즘 시장에서 가장 많이 언급되는 레이어2 롤업체인인 베이스(Base), 최근에 메인넷을 런칭한 세이 네트워크(Sei Network). 이들의 공통점은 무엇일까? 물론 시장에서 많은 주목을 받고있는 이른바 ‘블루칩’ 네트워크라는 것도 있겠지만, 기존에 존재하는 SDK를 기반으로 구축한 블록체인 네트워크라는 점도 이들이 가진 공통점이다(물론, 세이 네트워크는 좀 많이 변경을 했지만). 이들이 시장에서 높은 평가를 받고 있다는 점을 고려해봤을 때, 억지로 자체적인 블록체인을 처음부터 끝까지 구축하는 것이 능사가 아니라는 것을 알 수 있다. 또한, 현재 다양한 SDK들의 퀄리티가 절대로 부족하지 않다는 방증이기도 하다. 블록체인 시장의 규모가 더 커지면서 다양한 시장 참여자들이 들어올테고 결국 이들은 자체적인 체인들을 구축하고 싶어할텐데, 그럴수록 블록체인 SDK가 가져가는 중요성 역시나 굉장히 커질 것이다. 따라서, 현재 블록체인 SDK들은 어떠한 것들이 있고 어떤 블록체인 SDK가 어떤 목적에 좀 더 적합한지를 알아보고자 한다. 우선, 블록체인 SDK, 더 나아가서 SDK란 무엇일까?

1. 블록체인 SDK, 뭘까?

사실 SDK는 블록체인 이전에도 자주 사용되던 단어로, 소프트웨어 개발 키트(Software Development Kit)의 약자이다. 원래 소프트웨어 개발을 하기 위해선, 코드를 처음부터 다 작성해야 하는 번거로움이 있는데, SDK는 시작부터 그 틀은 만들어놓은 형태라고 볼 수 있다. 해서, SDK를 사용하면 기본적인 코드는 다 되어있는 상태이고(정말로 완성도 높은 SDK의 경우엔 가이드 문서나 기타 문서 작업들도 굉장히 잘 해두어서 개발자들이 굉장히 편리하게 소프트웨어 작업을 할 수 있다), 이 코드들 위에다가 자신들이 만들고자하는 소프트웨어의 목적에 맞게 새로운 코드들을 입히는 것으로 자신만의 소프트웨어를 구축할 수 있다.

쉬운 이해를 위해서 비유를 들어보자면, SDK는 오늘날 우리가 가구를 구매할 때, 가구를 쉽게 만들 수 있도록 어느정도는 조립이 되어서 판매되는 상품과 비슷하다. 예전엔 책상을 만들기 위해선 책상의 다리, 판, 모든 것들을 손수 만들어야 했지만 요즘엔 그런 부분들은 다 만들어져서 나오고 우리는 그것들을 구매한 뒤 조립만 하면 되는 방식이다. SDK 역시나 그런 방식이라고 볼 수 있다(물론 엄밀히 말하면 가구 조립 세트와는 조금 다르다. 가구 조립 세트는 딱 한가지 정해둔 방식의 가구로만 조립할 수 있지만, SDK는 개발자의 취향과 목적에 맞게 다시 설계할 수 있고 같은 SDK로 만들더라도 전혀 다른 소프트웨어가 될 수 있다).

블록체인 SDK는 그러한 특성들을 블록체인에 적용한 것이다. 물론 어떤 소프트웨어든 처음부터 구축하는 것이 매우 어려운 것은 사실이지만, 블록체인을 처음부터 끝까지 구축하는 것은 이보다도 더 어려운 일이다. 블록체인은 단순히 컴퓨터 공학이 아니라, 합의 과정이나 거버넌스, 경제적 인센티브 모델 그리고 그 외에 부가적인 인프라 기술들까지 고려해야하는 종합예술이기 때문에 다양한 분야의 지식을 요할 수 밖에 없고 이러한 진입장벽은 새로운 시장 참여자가 자체적인 블록체인을 구축하는데에 있어서 큰 어려움으로 여겨져왔다. 부수적이고 복잡한 기본 설정들을 누군가가 다 만들어뒀다면 얼마나 좋을까? 이러한 고민들을 해결하기 위해서 나오게 된 것이 블록체인 SDK들이다. 이제 구체적으로 블록체인 SDK가 왜 필요한지 알아보자.

1.1 SDK가 왜 필요한가?

이미 블록체인 SDK를 정의하면서 대략 블록체인 SDK가 필요한 이유에 대해서 알아보았지만, 구체적으로 어떠한 부분에서 블록체인 SDK가 필요한지에 대해서 알아보자.

1.1.1 비용 절감(Cost Efficient)

우선 비용이 절감된다. 필자가 위에서 SDK에 비유했던 가구 조립 세트의 경우는, 우리가 돈을 주고 사오는 것이지만 블록체인 SDK의 경우 대게 아무런 대가를 지불하지 않고 가져오는 경우가 많다. SDK가 공짜인 것은 비단 블록체인 SDK에만 적용되는 것은 아니고, 대부분의 SDK는 거의 무료로 배포되는 경우가 많다. 그렇기 때문에 무료로 SDK를 배포받아 해당 SDK위에 자신이 원하는 소프트웨어를 만들게 된다면 시간적 & 금전적인 비용을 아낄 수 있다. 다양한 소프트웨어가 만들어진 SDK라면, 이미 그 성능이 어느정도 검증되었기 때문에 사용하는 입장에서 매우 효율적인 선택지가 될 것이다.

이러한 장점은, 초기 비용이 부담되는 스타트업들 뿐만 아니라, 비교적으로 큰 규모이지만 블록체인 시장에 대한 큰 확신이 없는 상태에서 PoC를 진행해야하는 기업들에게도 SDK가 매력적인 선택지가 되는 이유일 것이다. 설령 비용 떄문이 아니더라도, 요즘 나오는 SDK들(후술하겠지만)은 상당히 좋은 기술력을 가지고 있기 때문에 어설프게 블록체인을 처음부터 만드는 것보다 이미 많은 고민을 했던 집단들이 이미 구축해놓은 인프라를 사용하는 것이 더 효과적이기도하다.

1.1.2 커뮤니티: SDK로 만들어진 것은 코드만이 아니다

보통 SDK가 있으면, 해당 SDK를 대표하는 블록체인들이 있다. 코스모스 SDK의 경우엔 코스모스 허브(ATOM)가 대표적인 블록체인이고, OP Stack의 경우엔 옵티미즘(OP)이 대표적인 블록체인이. 그리고 파라체인을 대표하는 블록체인은 폴카닷(DOT)이다. 이들은 각각 멀티체인 생태계를 지향하기 때문에 독립적인 체인들이 모여있는 생태계이지만, 그래도 같은 SDK를 써서 블록체인을 구축한 경우 마치 하나의 블록체인 커뮤니티처럼 활동한다. 같은 SDK를 가지고 블록체인을 구축했다고 하더라도, 이들은 독립적인 체인이기에 서로에게 직접적인 영향을 줄 수 없음에도 왜 이들은 하나의 커뮤니티로 묶여있을까?

간단하게 말하면 이들은 ‘어느정도의 이해관계를 공유’하고 있기 때문이다. 이들이 각각 독립적인 블록체인을 구축하는 생태계라고 하더라도, 같은 SDK로 만들어진 블록체인이 잘 되면 자신들의 블록체인들도 여러 기회를 얻을 수 있다. 우선 같은 인프라를 공유하기 때문에 네트워크들이 상호작용하기 매우 쉽고, 이를 통해 개발자 커뮤니티와 유저를 공유하기도 쉽다. 해서, 만약 자기의 블록체인이 속한 생태계에 굉장히 성공한 블록체인이 나오게 된다면, 자기의 블록체인을 간접적으로 홍보할 수 있는 기회가 생기는 것 뿐만 아니라 성공한 블록체인에 몰리는 유저와 개발자들을 일부 흡수해올 수 있다. 이러한 이유로 같은 SDK를 사용해서 블록체인을 구축하면 대게 같은 커뮤니티를 공유하는 것이다. 즉, 블록체인 SDK를 사용하여 블록체인을 구축했을 때 미리 만들어졌던 것은 비단 코드 뿐만이 아니라 커뮤니티도 있는 것이다.

1.1.3 표준화와 상호운용: 일관성은 매우 중요하다

위에서 언급했듯, 같은 블록체인 SDK로 블록체인을 구축��게 된다면, 같은 커뮤��티와 생태계를 공유하게 되고, 결국 이들은 여러가지 규칙들을 표준화하여 체인간 호환성을 극대화시킬 수 있다. 이것의 대표적인 예시가 바로 코스모스 생태계다. 코스모스 SDK 기반의 코스모스 생태계는 IBC라는 통신 프로토콜을 표준화하여 코스모스 생태계의 블록체인들간에 유기적인 소통을 가능하게했다. 또, 최근에는 RS. ICA, ICQ와 같은 새로운 표준들을 제시하여 코스모스 생태계의 유기적인 화합을 도모하고 있다 (RS, ICA, ICQ에 대해서 좀 더 자세히 알고싶다면, 예전에 필자가 작성한 스트라이프 소개글을 참조).

1.2 명확한 단점도 있다

지금까지 우리는 블록체인 SDK가 주는 장점에 대해서 알아보았다. 하지만, 블록체인 SDK가 장점만 가지고 있다면 모든 블록체인이 SDK를 기반으로 만들어졌을 것이지만 안타깝게도 현실은 그렇지 않다. 모든 것이 일장일단이 있기 마련인데 그렇다면 블록체인 SDK가 가진 단점은 무엇일까?

1.2.1 기술적인 해자를 구축하기 어렵다

우선 기술적인 문제다. SDK는 말 그대로 기본적인 코드가 다 되어있는 상태고 그 위에 목적에 맞춰서 변형하거나 추가를 시키는 것이다보니 같은 블록체인 SDK를 사용하는 체인들은 대부분 기술적으로 매우 비슷하다. 예를 들어서 같은 코스모스 SDK를 사용하는 오스모시스(Osmosis)와 마스(Mars)는 굉장히 비슷한 컨센서스 구조(사실상 둘 다 텐더민트를 사용하기 때문에 같다고 볼 수 있다)를 가지고 있고 차별점을 찾는다면 이들이 영위하고 있는 프로덕트에서 찾아야 한다. 즉, SDK로 블록체인을 구축하면 블록체인을 빠르고 편리하게 구축할 수 있다는 장점은 있지만, 빠르고 편리하게 구축했기 때문에 기술적인 해자는 없을 가능성이 높다. 만약에 기술적 해자를 구축하고 싶다면, SDK 를 사용하지 않거나, 사용했더라도 일부를 수정해서 배포해야 하는데(대표적인 예시가 바로 텐더민트를 수정해서 만든 세이 네트워크(Sei Network)이다. 세이 네트워크에 대한 자세한 설명글은 이전에 Four Pillars가 작성한 세이 네트워크 소개글을 참조) 어떤 경우엔 기존에 존재하는 도구들을 수정해서 배포하는 것이 처음부터 만드는 것보다 더 복잡하고 어려울때도 있다.

만약 정말로 기술적 우위를 강조하고 싶은 블록체인을 구축하는 것이 목표라면, 블록체인 SDK를 통한 블록체인 구축은 고려하지 않는 것이 좋다.

1.2.2 의존도가 발생한다

같은 SDK를 사용하는 생태계에 편입된다는 것은 필자가 위에서 언급한 장점이기도 하지만, 반대로 단점으로 작용될 여지도 많다. 보통 같은 블록체인 SDK 를 사용하는 블록체인들은 기술적으로 비교적 쉽게 상호 소통이 가능한데, 이러한 경우 서로가 시너지를 낼 수도 있겠지만 반대로 간접적인 피해를 입을 수 있다. 예컨데, 테라 블록체인이 크게 무너졌을 때, 테라와 IBC로 연결되어있는 코스모스 기반의 앱체인들이 간접적인 피해를 입었었다. 또한, 소프트웨어가 발전하는 방향성도 되도록이면 표준에 맞춰서 따라갈 수 밖에 없다. 한 번 표준에서 어긋나기 시작하면, SDK의 새로운 업데이트가 배포되더라도 기술적으로 호환되지 않을 수도 있기 때문이다. 한 번 SDK를 통해서 구축하면, 특별한 일이 없는 한 지속적으로 해당 SDK를 따라가야한다는 부분이 충분히 단점으로 작용될 수 있다.

2. List of Useful Blockchain SDKs

분명히 블록체인 SDK는 기업과 개발자들로 하여금 쉽게 블록체인을 구축할 수 있는 간편한 프레임워크를 제공하지만, 반대로 이야기하면 블록체인들을 다 획일화 시킨다는 점에서 시장이 급진적으로 나아가는 정도를 완화한다고 볼 수도 있다. 또한, 블록체인 SDK별로 특성이 다르기 때문에 만약 블록체인 SDK로 자신만의 블록체인을 구축하고자 한다면, 자신의 목적과 쓰임새에 맞는 SDK를 사용하는 것도 매우 중요하다. 해서, 시장에 나와있는 블록체인 SDK들을 분석해보고, 이들의 특성을 분류해보기로 하였다.

2.1 Cosmos SDK: 생태계와 유연성이 중요하다면.

코스모스 SDK는 오늘날 우리가 블록체인 SDK라고 부르는 것의 대명사가 되어버렸다. 그 이유는, 현재까지 블록체인 SDK를 활용해 성공적인 블록체인을 만든 사례가 코스모스 SDK가 가장 많으며, 생태계 구성원들이 굉장히 활발하여 다양한 사건/사고들이 일어나기도 했기 때문이다. 코스모스 생태계를 제외하고도 어플리케이션 특화 체인(이하 앱체인)들이 모여있는 생태계를 지향하는 곳은 많지만 여태까지 가장 많은 앱체인을 배출한 것도 코스모스 생태계와 코스모스 SDK이기 때문에 대중들에게 가장 잘 알려져있는 블록체인 SDK이기도 하며, 현재 기업들도 코스모스 SDK를 활용하여 블록체인을 구축하고 있는 경우가 많다. 코스모스 SDK를 통해 구축한 블록체인들 중에서 여러분이 아실만한 블록체인들을 소개하겠다.

2.1.1 Terra: a god that failed.

Source: 코스모스 블로그

코스모스 SDK로 만든 가장 유명한 블록체인이라는 수식어가 아직도 따라붙는 블록체인인 테라는, 한 때는 시가총액 기준으로 코스모스 허브를 넘어서 전 세계 블록체인 시가총액 10위권 안에까지 드는등 엄청난 성장세를 보이기도 하였다. 오늘날 우리가 코스모스 SDK에 대해서 가장 잘 알게 된 계기이기도 하다. 현재 코스모스 기반 블록체인들이 주로 스마트 컨트랙트를 구현할 때 사용하는 멀티체인 스마트 컨트랙트 플랫폼인 Cosmwasm 역시 테라가 가장 먼저 적용한 블록체인 중에 하나다. 하지만 알고리드믹 스테이블 코인이라는 참신한 프로덕트와 다양한 DeFi 어플리케이션 출시로 시장에서 높은 평가를 받던 테라는, 결국 알고리즘으로 가치가 안정화되는 스테이블 코인의 가치를 안정화 시키지 못하고 실패한 프로젝트가 되었다.

테라의 가치 안정화 실패는 블록체인 자체의 오류라기 보단, 알고리드믹 스테이블 코인의 문제였기에 지금까지도 코스모스 SDK를 활용해 구축한 프로젝트들 중에서 가장 성공한 사례로 언급되고있다. 실제로 테라의 성공은, “블록체인 SDK를 활용해 블록체인을 만들면, 독창적일 수 없고 결국 주목받기 어렵다.”는 통상적인 업계의 편견을 깬 사례로도 언급된다(필자가 위에서 언급했던 블록체인 SDK의 단점을 상쇄한 경우인 것이다).

2.1.2 dYdX: Killer Application to Killer Chain

Source: dYdX Blog

정말로 다사다난했던 작년에 충격적인 소식들중 하나를 꼽으라면, 바로 이더리움 레이어2에서 가장 유명했던 오더북 기반의 탈중앙 선물 거래소인 dYdX가 레이어2 생태계를 떠나 자체적인 블록체인을 구축한다는 소식이었을 것이다. 위에서 언급했던 테라는, 시작부터 코스모스 SDK를 사용해서 구축한 블록체인이라면, dYdX는 스타크웨어와 협력하여 스타크엑스(StarkEx) 엔진을 통해 개발한 프로덕트로 시작했으나 그 한계를 느끼고 이더리움 생태계를 떠나 코스모스 SDK 기반의 체인을 구축한 경우기 때문에 굉장히 흥미로운 사례이다. dYdX 측은 자신들이 원하는 오더북과 매칭엔진 환경을 구축하기 위해서는 코스모스 SDK 같이 쉽게 블록체인을 만들 수 있으면서도 블록체인이 어떻게 작동하는지에 대한 맞춤형 제작이 가능한 환경이 필요했다고 주장했다(실제로 dYdX는 트레이더의 경험 극대화를 위하여 트레이딩 수수료를 자체적으로 없애는등. 코스모스 SDK의 유연성을 십분 활용하고 있다).

실제로 dYdX는 벨리데이터들이 컨센서스 과정에만 참여하는 것이 아니라 컨센서스와는 분리된 환경에서 오더북도 작동시켜야 하기 때문에 컨센서스를 비롯해 인프라 딴의 제약이 있는 레이어2 보다는 자체적인 레이어1 체인을 구축할 수 있는 코스모스가 더 매력적으로 느껴졌을 것이다. 아직 dYdX 체인의 메인넷은 나오지 않았지만, 메인넷 이후에 dYdX 체인이 어떠한 퍼포먼스를 보이느냐에 따라서, 어플리케이션이 자체적인 블록체인을 구축하는 것이 굉장히 흔해지는 시대가 도래할 수도 있을 것이다.

2.1.3 Sei Network: 코스모스 SDK를 내 맘대로

Source: Sei’s blog

코스모스 SDK가 어디까지 유연하게 변화하는지가 궁금하다면, 세이 네트워크를 보면된다. 물론 필자가 위에서 언급한 테라와 dYdX 역시나 코스모스 SDK에 자신들의 코딩을 더하여 기존에 없는 기능을 추가하거나 새로운 기능들을 추가하는등의 노력을 했지만, 세이 네트워크는 코스모스SDK의 컨센서스까지 수정하여 지금의 세이 네트워크를 설계하였다. 이들은 Intelligent Block Propoagtion을 통해 노드가 트랜잭션을 두 번 전파하는 부분을 단순화 하였고, Optimistic Block Processing을 통해서 텐더민트의 합의 과정을 단축시켰다. 그 외에도 트랜잭션 병렬처리를 자체적으로 진행하여 기존 코스모스 앱체인들과 비교했을 때, 월등히 빠른 트랜잭션 속도를 갖추게 되었다(세이 네트워크에 대해서 좀 더 자세하게 알고 싶으시다면, 포필러스가 작성한 세이 네트워크 소개글을 참고하시라). 이제 세이는 코스모스 SDK 기반의 체인이라고 불리는 것이 어색할만큼 SDK의 틀을 벗어나서 본인만의 색깔을 만들고 있다.

2.1.4 코스모스 SDK의 특장점

필자가 든 세 가지 실질적 사례를 기반으로 봤을 때, 코스모스 SDK는 블록체인 SDK로써, 레이어1 블록체인을 쉽게 구축할 수 있는 프레임워크를 제공해주면서도, 체인을 개발함에 있어서 유연성도 확보할 수 있어서 본인이 추구하는 방향성과 목표에 맞게 체인을 설계할 수 있다는 장점이있다. 테라는 알고리드믹 스테이블 코인을 추가해서 만들었고, dYdX는 벨리데이터에게 새로운 임무를 주었으며, 세이는 컨센서스 전반을 수정하여 극단적으로 빠른 확장성을 추구하였다. 만약 여러분이 SDK를 통해 블록체인을 구축하더라도 어느정도의 자율성을 추구한다면 코스모스 SDK는 꽤 좋은 선택지가 될 수도 있다.

2.2 OP Stack: EVM- equivalency와 이더리움의 보안을 어느정도 가져가고 싶다면.

OP Stack은 옵티미스틱 롤업을 구축할 수 있도록 제공되는 옵티미스틱 롤업 SDK라고 할 수 있다. OP Stack은 기본적으로 개발자가 자체 롤업 체인을 생성하고 롤업을 통한 확장성 개선을 누릴 수 있도록 필요한 도구를 제공한다. 개발자는 OP Stack 을 통해 기존 스마트 컨트랙트 플랫폼보다 더 효율적이고 비용 절약적인 롤업 체인 구축이 가능하다. 이를 통해 사용자 경험을 개선하고 블록체인 기술을 더 빠르게 채택할 수 있다. 전반적으로 OP Stack은 이더리움의 보안을 어느정도 가져가면서도 효율적인 탈중앙화 애플리케이션을 구축하고자 하는 모든 개발자이나, EVM Equivalent 한 개발환경을 중요하게 생각하는 개발자들에게 추천한다(Op Stack에 대해서 더 자세히 알고 싶으신 분은, 포필러스가 작성한 Op Stack 소개글을 참고하시라).

물론 옵티미스틱 롤업은, 7일 분쟁 기간이라는 것이 있고 이 분쟁 기간은 이더리움에서 옵티미스틱 롤업 체인으로 넘어간 자산들에 한해서 의미가 있는 것이라서, Op Stack을 통해 구축한 블록체인이 이더리움의 보안성을 완벽하게 물려받는다고 말하는 것은 어렵지만 코스모스 SDK 와 같이 완전히 자체 체인을 구축하는 프레임워크 보다는 보안적인 측면에서 장점이 있다(물론 뒤에서 후술하는 opBNB의 경우엔 보안적 측면에서 장점이 있다고 보여지진 않는다). 현재 Op Stack을 활용하여 만들어진 블록체인은 무엇이 있을까?

2.2.1 Coinbase의 체인, Base.

Source: Coinbase

암호자산 거래소들이 각자 저마다 블록체인을 만들 때도 조용했던 코인베이스가 작년에 자체 블록체인을 런칭할 것이라고 발표하였는데, 그게 바로 베이스 블록체인(이하 베이스)이었다. 베이스는 Op Stack을 활용하여 현재 이더리움 네트워크가 제공할 수 있는 것보다 더 빠르고 저렴하며 확장 가능한 트랜잭션을 제공하여 종국에는 10억명이 넘는 유저를 온체인에 온보딩 시키는 것을 목표로 삼고있다. 베이스는 Op Stack을 기반으로 하였기 때문에 Optimism과 비슷하게 다목적 체인(general purpose blockchain)을 지향하고 있고, 이더리움의 EVM과 완전히 같은 환경은 아니지만 EVM-equivalency를 달성한 정도의 EVM 친화성을 가지고 있다. 해서, 기존에 솔리디티에 익숙한 개발자라면 베이스 체인을 활용하기 쉬울 것이다. 실제로 현재 베이스는 디파이라마가 집계한 TVL 을 기준으로 블록체인 중에서 12위(레이어2들 중에서는 3위)에 올라서는등 매우 짧은 기간동안 엄청난 퍼포먼스를 보여주고 있다.

베이스가 Op Stack을 선택한 이유는 크게 두 가지라고 할 수 있다: 1) EVM은 이제 블록체인 시장의 표준이 되었고. 2) 이더리움의 보안은 앞으로 방대한 자산을 관리함에 있어서 굉장히 중요하다고 생각했기 때문에 이더리움의 롤업을 쉽게 올려주는 Op Stack을 선택한 것이다. 물론 이것은 어디까지나 코인베이스의 의견이지만, 블록체인을 구성함에 있어서 코인베이스와 생각을 공유하고 있다면, Op Stack은 굉장히 유용한 툴일 것이다.

2.2.2 굳이 이더리움이 아니어도, opBNB

Source: BNB Chain

코인베이스는 이더리움의 보안과 EVM 때문에 Op Stack을 사용했지만, 바이낸스는 조금 다르다. 물론 EVM Equivalency 한 Op Stack의 특성 때문에 Op Stack을 사용한 것은 맞지만, 이더리움 때문은 아니다. opBNB가 흥미로운 부분은, opBNB가 Op Stack 기반 체인임에도 이더리움 위에 올라간 것이 아니라 바이낸스의 자체 네트워크인 BSC(BNB Smart Chain) 체인의 레이어2로 올라간다는 부분이다. 이더리움보다 BSC 네트워크가 gas limit도 훨씬 높고 확장성도 더 뛰어나다는 측면에서 레이어2 역시나 이에 대한 혜택을 받을 수 있을 것으로 기대되고있다.

opBNB를 통해서 알 수 있는 사실은 Op Stack 기반의 블록체인을 꼭 이더리움 위에서만 구현하지 않아도 된다는 것이다. 현재 많은 사람들이 우려하듯, 이더리움 기반의 롤업 체인들이 늘어날수록 종국엔 롤업들도 이더리움이 가지고 있는 확장성의 한계에 부딪혀 이들이 기존에 가지고 있었던 목적을 달성하지 못할수도 있다. 결국 이더리움의 레이어2들도 자신들의 트랜잭션을 이더리움 메인 체인에 보내야 하는데, 이더리움의 블록에 담을 수 있는 공간 역시나 한정적이기 때문에 만약 ‘롤업 포화 상태’가 된다면 롤업들도 확장성의 문제에서 결코 자유로울 수 없다. 해서, opBNB 같은 시도는, 굳이 이더리움이 아니더라도 레이어2를 구현해야하는 이유에 대한 정답이 될지도 모른다.

2.3 Substrate: Rust에 익숙하고, 모듈러리티가 중요하다면.

Source: Parity

Substrate 는 폴카닷 네트워크를 개발한 패리티 테크놀로지스가 개발한 블록체인 SDK이다. Substrate는 코스모스 SDK와 비슷하게, 블록체인 구축에 필요한 기능들을 제공하여 개발자가 블록체인 인프라의 세부적인 부분보다는 애플리케이션 로직에 집중할 수 있도록 개발되었다. 개발자는 Subsrate를 통해 애플리케이션의 특정 요구사항에 맞는 맞춤형 블록체인을 만들 수 있다. 여기까지 들으면 코스모스 SDK와 굉장히 비슷해 보이는데 사실상 코스모스 SDK와 거의 동일한 목적을 가지고 있는 블록체인 SDK라고 볼 수 있다.

서브스트레이트의 가장 주목할 만한 기능 중 하나는 런타임 모듈 라이브러리("SRML" 또는 간단히 "팔레트"라고도 한다)다. 팔레트는 토큰 잔고, 스테이킹 또는 거버넌스와 같은 특정 기능을 캡슐화해서 구성 가능한 플러그 앤 플레이 모듈이다. 개발자는 이러한 사전 구축된 모듈을 사용하거나, 아니면 처음부터 직접 만들 수 있어 블록체인 설계에 있어 비교할 수 없는 유연성을 제공한다. 해서, Substrate의 모듈러리티(또는 유연성)가 다른 SDK랑 비교했을 때 가장 강조되는 부분이기도 하다.

그렇다면 Substrate 를 기반으로 만든 블록체인은 무엇이 있을지 알아보자.

2.3.1 Acala Network: Substrate의 유연함을 보여주다.

Source: Acala

Acala Network(이하 아칼라)은 Substrate 블록체인 개발 프레임워크 위에 구축된 탈중앙화 금융(DeFi) 플랫폼입니다. 아칼라는 Polkadot 생태계의 일부로 스테이블 코인, 탈중앙 거래소(DEX), 렌딩을 포함한 전반적인 금융 애플리케이션을 제공하는 것을 목표로 한다. 아칼라의 독특한 기능 중 하나는 사용자가 다양한 디지털 자산들을 담보로 제공하여 스테이블 코인을 받을 수 있다는 부분이다. 이로 인해 사용자는 유동성을 확보하고 DeFi 활동에 참여하는 데에 더 큰 혜택을 누릴 수 있게된다.

사실 제일 흥미로운 부분은 바로 Acala의 수수료 메커니즘인데, 블록체인을 사용함에 있어서 수수료를 지불해야하는 문제, 특히 네트워크마다 수수료로 지불해야하는 토큰이 변하는 문제도 유저 경험을 악화시키는 부분중에 하나였다. 하지만, Substrate은 수수료 지불 로직도 변경시킬 수 있어서 아칼라는 아칼라 DEX에서 거래되는 모든 토큰들을 수수료로 받을 수 있도록 설계하였다. Substrate가 얼마나 유연한 프레임워크를 제공하는지 알 수 있는 부분이다.

2.3.2 아스타 네트워크: EVM과 WASM을 동시에 사용하는 사례

Source: Astar Network

Astar Network(이하 아스타)은 Substrate 위에 구축된 블록체인으로 일본에서 주요 블록체인 프로젝트 중 하나로 알려져 있다. EVM과 WASM을 모두 지원하여 개발자가 어느 언어로든 스마트 계약을 개발할 수 있도록 설계된 것이 특징이다. EVM과 WASM을 동시에 지원한다는 것도 흥미롭지만, dApp Staking이라는 독자적인 기능을 넣어서 개발자들에게 지속적인 인센티브를 제공해준다는 사실도 Substrate가 얼마나 유연한 블록체인 프레임워크인지 알 수 있다. 특히 가상머신 두 가지를 같이 지원해주는 기능의 경우, 현재까지 코스모스 생태계에선 이러한 케이스가 없다는 것을 감안해보면 Substrate의 유연함이 명확하게 돋보이는 사례라고 할 수 있을 것이다.

2.4 Linera SDK: 새로운 도전을 하고싶다면.

Source: Linera

리네라 SDK는 Meta의 크립토 월렛 서비스인 Novi와 페이먼트 인프라인 FastPay에 대한 페이퍼를 작성했던 Mathieu Baudet이 만들고 있는 프로토콜로, 앱토스, 수이와 더불어 Meta 에서 파생되어 나온 블록체인 중 하나로 유명하다. 물론 앱토스 수이와 비슷한 DNA를 공유하지만, 다른점이라고 한다면 이들은 자체적인 블록체인을 출시하기도 전에 SDK를 만들어서 시장에 선보이고 있다는 점이다. 최근엔 자신들이 만든 SDK를 시험해보기 위해서 개발자 스쿨을 개최하는등 굉장히 다른 행보를 보이고 있다는 부분이 주목할만하다. 언급했듯 리네라SDK는 아직 테스트 단계이기 때문에 리네라 SDK를 직접적으로 활용한 사례는 없으나, 리네라의 백서를 보면 리네라 SDK를 활용해 만들 수 있는 체인들을 미리 간접적으로 관찰할 수 있었다:

리네라에 참여하는 주체는 우선 체인의 오너, 벨리데이터, 유저가 있고. 벨리데이터가 있다. 여기서 오너(owner)는 체인에 대한 참여자 전부가 될 수 있으며 오너와 벨리데이터의 관계는 고객과 서비스 프로바이더의 관계로 볼 수 있다. 오너의 주 역할은 새로운 블록을 생산하고 제안하는 일을 하고, 벨리데이터는 그 블록들을 검증하는 역할만 한다는 것이 다른 기존 체인들과 다른 점이다(물론 리네라에서도 퍼블릭 체인의 경우 벨리데이터가 기존 블록체인과 비슷한 역할을 한다). 리네라에선 체인들을 마이크로 체인이라고 부르고 이 체인들은 약 세 가지 카테고리로 분류가 가능하다:

• 싱글 오너 체인(Single Owner Chain): 하나의 유저만이 블록을 제안할 수 있는 구조의 체인

• 퍼미션드 체인(Permissioned Chain): 선택된 다수의 유저들만 블록을 제안할 수 있는 구조의 체인

• 퍼블릭 체인(Public Chain): 모든 유저들이 다 자유롭게 블록을 제안할 수 있는 구조의 체인

누가 블록을 생산할 수 있는 권한이 있느냐에 대해선 세 체인이 다 다른 구조를 가지고 있으나, 이들이 다음 블록을 생산하기 위해서는 Certificate 이 필요하다는 점은 동일하다. 하지만 그 Certificate이 나오는 구조는 다 다른데, 싱글 오너 체인에선 reliable broadcast를 통해서 Cerficiate이 발행되고, 퍼블릭 체인에선 벨리데이터가 BFT 방식으로 발행해준다. 여기서 주의해야하는 점은, 싱글 오너 체인이라고 해서 벨리데이터로부터 완전히 자유로운 구조는 아니기 때문에, 리네라 생태계가 활성화 된다면, 벨리데이터의 역할은 매우 중요할 것으로 보여진다는 부분이다.

Substrate가 팔레트 형식으로 SDK의 유연성을 확보했다면, 리네라는 마이크로체인의 종류를 세 가지로 나눠서 목적에 맞게 가장 알맞는 체인의 형태를 고르는 방식으로 유연성을 확보한 것처럼 보인다. First Mover가 되고 싶다면, 리네라 SDK를 활용하여 자체 체인을 구축하는 것도 시도해볼법하다.

2.5 Hyper SDK: 무엇보다 속도가 중요하다면

Source: Avalanche

다른 멀티체인 생태계가 그렇듯, 아발란체도 블록체인을 간편하게 만들 수 있는 SDK(Software Development Kit)을 세상에 내놨다. HyperSDK(이하 하이퍼 SDK)가 바로 그것이다. 아발란체는 하이퍼SDK 를 고성능 가상머신을 만들 수 있는 프레임워크로 소개하고 있으며, 많은 양의 코딩을 하지 않아도(아발란체 팀에 의하면 약 500-1000개의 라인으로 커스텀 디자인을 할 수 있다고 한다, 물론 메커니즘 디자인을 얼마나 하느냐에 따라서 달라질 수 있을 것) 빠르게 자신들이 원하는 블록체인을 구현할 수 있다는 것을 장점으로 꼽았다. 하이퍼 SDK를 기반으로 만들어진 블록체인은 HyperChain으로 불리며, 아발란체 팀에 의하면 체인을 구축함에 있어서 많은 개발자를 온보딩하지 않아도 된다는 간편성과 편의성을 강조하였지만 아직은 알파 단계이기 때문에 더 많은 실험과 수정을 거쳐야 할 것으로 보인다. 하지만 명확한 사실은, 단순히 아발란체의 VM을 포크하여 네트워크를 구축했던 과거 시절보다 더 쉽고 간편한 툴을 제공하여 아발란체의 멀티 네트워크 생태계의 성장에 불을 지피는데에 하이퍼SDK가 큰 역할을 할 수 있을 것이라는거다.

재미있는 것은, 하이퍼 SDK가 추구하는 가치인데, 하이퍼라는 단어에서 알 수 있듯 이들이 하이퍼 SDK를 구축하면서 가장 중요하게 여겼던 것이 바로 ‘속도’다. 아발란체에서 하이퍼 SDK의 개발을 주도한 Patrick O’ Grady에 의하면 SDK를 활용해서 만드는 블록체인이 빠르지 않는다면 아무리 해당 SDK가 블록체인을 쉽게 만들어줄 수 있다고 하더라도 큰 의미가 없다고 한다. 해서, 하이퍼 SDK는 개발자들이 어떻게 고성능 블록체인을 빠르고 간편하게 만들 수 있는지에 초점을 뒀다고 볼 수 있다.

물론 Linera와 마찬가지로, 아직 개선의 여지가 많고 아직 하이퍼 SDK를 통해 제대로된 사례를 만들어내지 않았기 때문에 리스크는 있지만, 새로운 SDK를 통해 새로운 블록체인을 구축하는 경험이 더 중요한 집단에게는 한 번 시도해볼만한 SDK라고 생각된다.

2.6 Polygon CDK: SDK 경력직 신입의 등장

Source: Polygon

2023년 8월30일에 발표한 폴리곤의 L2 프레임워크로, 정말 가장 최신의 SDK이다. 물론 폴리곤이 SDK를 만든 것은 이번이 처음이 아니고, Supernets이라고 불리는 레이어1 구축 프레임워크도 가지고 있었다. 그렇기 때문에 SDK를 만든 경험이 이미 있는 팀이 새로운 L2 SDK를 만들었다는 부분에서 상당히 고무적인 부분이다. 또 주목해야하는 부분은 바로 CDK 체인들은 Interop Layer를 공유한다는 부분인데, Interop Layer는 말 그대로 체인들의 상호운용 레이어로 이 레이어를 공유하는 체인들은 영지식 증명을 통해 자유롭게 상호소통이 가능해진다. 이미 현재 Immutable, Aavegotchi 와 같은 유명한 플레이어들이 CDK를 사용하고 있다는 사실이 밝혀지면서, 단기간에 큰 입지를 가지게 될 레이어2 프레임워크로 급부상하고있다.

여태까지 많은 레이어2 SDK가 있었지만, 폴리곤 CDK처럼 명확하게 L2간 체인 상호운용 방법에 대해서 공개한 곳은 많이 없기 때문에 앞으로 L2 구축을 고민하시는 분들은 Polygon CDK를 활용하는 것도 좋은 방법이 될 것이다(우선 immutable과 Aavegotchi가 어떻게 되는지를 지켜보시고 결정하시는 것도 좋다).

3. Conclusion: Should We Use It or Not?

지금까지 우리는 블록체인 SDK가 무엇인지, 그리고 이들을 활용한 사례를 통해서 각각의 SDK가 가진 특성들에 대해서 알아보았다. 각각의 SDK는 저마다 특이한 특성들을 가지고 있고, 장단점들이 명확하기 때문에 어떤 SDK가 우월한지에 대한 관점보다는, 어떤 SDK가 자신의 목적에 더 부합하는지에 더 포커스를 맞추는 것이 좋다. 그렇다면 마지막으로, 블록체인 SDK를 정말로 사용해야할까? 사용해야 한다면 사용해야하는 이유는 무엇이고 사용하지 말아야 하는 이유는 무엇일까? 마지막으로 아티클을 정리하면서 이유들을 적어본다.

3.1 사용해야 하는 이유 1: 자본력과 인력의 문제를 해결할 수 있다

블록체인을 개발하는 대부분의 회사들은 직원 50명 미만의 스타트업이라고 할 수 있는데, 이들의 경우 블록체인을 처음부터 끝까지 만들 수 있는 인력과 자본력, 그리고 시간이 많지않다. 초기 스타트업 입장에서 어설픈 블록체인이 아닌 완성도 높은 블록체인을 만드는 것은 사실상 거의 불가능에 가깝다고 할 수 있다. 블록체인 산업 초기에야 시간이 많이 있었기 때문에 소규모의 팀이 여러 시행착오를 거치면서 블록체인을 완성해나갈 수 있었지만(명확히 하자면, 이러한 경우에도 거의 대부분의 블록체인이 시장의 선택을 받지 못해서 사라졌다. 오늘날 우리가 아는 대부분의 블록체인은 열악한 시장환경 속에서 다양한 검증을 통해 살아남은 프로젝트라고 볼 수 있다), 지금은 블록체인 시장의 규모도 달라졌고 다양한 분야에서 경험 많은 개발자들이 들어오게 되면서 시장이 변화하는 속도도 굉장히 빨라졌다. 이러한 경우엔 이미 검증된 블록체인을 빠르게 만들어내는 것이 중요할 수 있다. 완성도 높은 SDK가 현재 블록체인 씬에서 매력적이게 다가오는 이유이기도 하다. 더 솔직하게 말하면, 코인베이스 같은 세계적인 블록체인 기업도 Op Stack을 사용하여 자체 블록체인을 구축하는 마당에, 다른 크립토 스타트업이 굳이 자체적인 블록체인을 구축할 이유가 없지 않나?

3.2 사용해야 하는 이유 2: 상호운용성이 중요하다면

블록체인을 구축하는 입장에서, 다른 블록체인과 유기적인 소통이 가능하게 만든다는 것은 매우 어려운 일이다. 실제로 작년엔 크로스 체인 솔루션에서만 천문학적인 자금이 해킹당했고, 그만큼 블록체인들을 연결하는 작업은 매우 난이도가 높은 작업이다. 하지만 SDK를 사용해서 구축한 생태계를 활용한다면, 적어도 같은 SDK를 활용한 체인들간에는 비교적으로 쉬운 상호운용이 가능하다. Op Stack을 활용할 경우, 물론 어떤 베이스 레이어(레이어1) 위에 구축되느냐에 따라서 다르겠지만 같은 베이스 레이어 위에 Op Stack 기반의 체인을 구축한다면, 적어도 이들끼리는 매우 유기적인 상호운용이 가능하다.

베이스 레이어를 공유하지 않더라도, 코스모스 SDK나 Substrate의 경우 각각 IBC(inter-blockchain communication)와 XCMP(Cross Chain Message Passing)을 기반으로 생태계간 유기적인 상호운용성을 확보했다. 즉, 크로스체인 기술에 대한 전문가가 아니더라도 해당 SDK로 블록체인을 구축하면 적어도 같은 생태계에 있는 체인들 간에는 쉽게 소통할 수 있는 인프라를 사용할 수 있다는 것이다.

3.3 사용하지 말아야 할 이유 1: 공짜 점심은 없다

이렇게 보면 SDK는 반드시 사용해야하는 툴킷이다. 이미 훌륭한 전문가들이 만들어준 프레임워크위에 블록체인을 구성했을 때 누릴 수 있는 장점들이 정말로 많기 때문이다. 하지만 공짜 점심이 없듯, SDK를 사용했을 때의 단점도 명확하다. 결국 SDK를 만드는 재단이 원하는 것은 SDK 기반 체인들이 많아지는 것이고, 이를 통해 자신들, 또는 자신들이 만든 체인이 이들을 통해 가치를 창출하는 것이다. 실제로 코스모스 생태계는 이를 위해서 RS(Replicated Security) 라는 새로운 기능을 도입하여 코스모스 생태계에서 새롭게 런칭하는 체인들이 늘어날수록 코스모스 허브에 가치가 누적될 수 있도록 새로운 설계 모델을 제안하였다(물론 이 모델도 현재 논란이 많은 상황이다). Op Stack 기반의 베이스 체인의 경우 옵티미즘 체인과 수익을 공유하는 계약을 체결하기도 하였다. 물론 이러한 것들이 나쁘기만 하다고 할 수는 없지만, 명확하게 해두어야하는 사실은 SDK를 만드는 팀들이 단순히 봉사 차원에서 SDK를 배포하고 공유하는 것이 아니라는 사실이다. 이 세상 모든 것들이 그렇듯, 공짜로 보이는 것일지라도 공짜는 없다(수수료가 강제되지 않는 상황이더라도, 점점 수수료를 받거나 이익을 공유하는 형태로 수렴하고 있는데다, 그렇지 않더라도 생태계에 대한 의존성이 존재한다는 것은 SDK로 블록체인을 만들기 전에 반드시 생각해봐야 하는 부분일 것이다).

3.4 사용하지 말아야 할 이유2: 야망이 있다면

팀보다 더 위대한 개인은 없다는 말처럼, SDK를 사용하면 SDK 생태계 또는 SDK 생태계를 대표하는 체인들(Op Stack의 경우 Optimism, 코스모스 SDK의 경우 허브, Substrate의 경우엔 폴카닷, CDK의 경우는 폴리곤)을 뛰어넘기 어렵다. 위에서 얘기했듯, SDK를 설계할 때 SDK 생태계가 커질수록 이러한 대표격 체인들에게 가치가 축적되는 방식을 채택했고 채택할 예정이므로 SDK로 체인을 구축해서 생태계를 뛰어넘는다는 것은 어쩌면 거의 불가능에 가까울지도 모른다. 물론 우리는 테라라는 굉장히 특이한 경우(테라의 경우 코스모스 SDK를 기반으로 만들어졌지만, 코스모스 허브는 물론이고 코스모스 생태계 전체보다 규모가 컸을 정도로 성장했었다) 를 봤지만, 이는 정말로 특이한 경우였다. 아마 앞으로 테라와 같은 경우는 나오지 않을지도 모른다. 해서, 야망이 있는 팀이라면 SDK로 블록체인을 구축하는 것은 어쩌면 자신의 야망을 SDK 생태계로만 제한하는 것일수도 있다. 정말 자신이 있고 그럴 자본도 있다면, 자체적인 블록체인을 구축하는 것이 지금도 가장 최선이다.

3.5 결론의 결론: 신중론

세상의 모든 것이 그렇듯, 명확한 정답은 없다. 하지만 오늘 필자가 소개한 SDK들과 이들의 장단점, 더 나아가 SDK자체의 장단점들을 신중하고 면밀하게 검토하고 자신만의 블록체인을 구축하는 것은 반드시 필요하다고 생각한다. 하지만 한 가지 긍정적인 사실은 블록체인 업계가 더 성숙해지면서 SDK들의 종류가 많아지고, 이들이 SDK로 경쟁하면서 SDK를 사용하는 사용자들에게 좀 더 다양한 혜택들이 제공될 수 있다는 것이다. 경쟁은 곧 질의 향상과 비용의 절감을 의미한다. SDK도 이제는 산업의 핵심 인프라로 자리잡은 만큼, 양질의 SDK들을 통해 블록체인 생태계가 더 풍요로워지기를 기대한다.

이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.