Web3가 불러오는 기존 웹의 변화들

일년 전, 저는 제가 당시에 이해하고 있었던 Web3 스택의 모습을 설명한 바 있습니다. 더 최근에는 멀티코인사의 암호자산 핵심 투자 철학을 통해서 Web3 관련 투자전략을 자세히 소개했었습니다. 이때도 강조했지만, Web3의 주요 시사점 중 하나는 데이터 소유권과 어플리케이션 논리가 언번들링, 즉 분리될 것이라는 점입니다.

이번 포스팅에선 이와 같은 언번들링에 내재된 구체적인 문제점에 대해 설명하고, 멀티코인에서 Web3 스택 투자에 대해 어떻게 생각하는지에 대해 소개하도록 하겠습니다.

데이터베이스와 데이터의 위치

이해를 돕기 위해 단순화 하자면, 대부분의 현대 어플리케이션은 데이터베이스에 UX를 입힌 프로그램입니다. 비디오 스트리밍이나 비디오게임 등 예외도 있지만 보편적으로 적용되는 정의입니다. 페이스북, 트위터, 구글 닥스, 지메일, 에버노트, 레딧, iMessage 등 모든 주요 B2C 서비스는 데이터베이스에 UX를 덧씌운 형태를 띄고 있습니다.

기존의 웹 기반 모델, 즉 Web2에서는 어플리케이션 공급사들이 사용자를 대신해 데이터를 저장 및 관리합니다. 또한 Web2 어플리케이션 공급사는 24시간 내내 서버를 운영하며 항상 온라인 상태를 유지하는 반면, 사용자들은 지하철을 타거나, 통신 연결이 끊기거나, 디바이스 배터리가 닳는 등의 문제 때문에 자주 오프라인 상태가 됩니다. Web3 모델에는 어떠한 중앙화된 어플리케이션 제공자도 존재하지 않습니다. 그렇기 때문에 데이터 소유권 패러다임을 전면적으로 변화시킬 필요가 있습니다.

자연스럽게 몇 가지 질문이 나옵니다.

1. 독자적인 서버를 운영하지 않는다는 가정 하에 사용자(편의상 지금부터 ‘앨리스’라고 칭함)는 어디에 데이터를 저장해야 할까요?
2. 앨리스가 오프라인 상태일 때 상대방은 어떤 방법으로 앨리스에게 컨텐츠를 보낼 수 있을까요?

이 질문에 대한 답은 간단합니다. 항상 온라인이고 접근 가능한 어딘가에 컨텐츠를 저장해놓고, 앨리스가 언제든 온라인에 접속했을 때 컨텐츠 저장 경로를 알면 됩니다. 이는 메세징 같은 P2P 어플리케이션이나, 신문, 소셜 미디어, 노트 필기 앱 같은 기존 데이터베이스 어플리케이션 모두에 적용 가능한 추상화(Abstraction) 패러다임입니다.

하지만 이를 실행하기 위해서는 해결해야 할 기술적인 문제들이 있습니다.

1. 앨리스 본인이 아닌 제 3자가 컨텐츠 저장 방법과 색인을 알고 있어야 합니다. 그래야 앨리스가 나중에 다운로드할 수 있겠죠.
2. 앨리스는 해당 목록의 색인을 어디서 찾아야 할지 알고 있어야 합니다.
3. 앨리스는 그 색인을 활용해 해당 데이터를 검색 및 다운로드할 수 있어야 합니다.
4. 데이터를 저장하는 주체는 컨텐츠의 내용을 열람(비공개 데이터인 경우) 및 검열할 수 없어야 합니다.

위의 문제들을 해결하면 데이터 소유권과 어플리케이션 로직의 언번들링이 가능해집니다. 그러면 Web3는 더욱 발전할 수 있겠죠.

최근 등장한 Web3 스타트업들이 어떻게 이런 문제를 해결하고 있는지 살펴보기 전에, 먼저 과거에는 어떤 주체들이 어떻게 해답을 찾으려 했는지 살펴보도록 하겠습니다.

인터넷 탈중앙화를 향한 과거 노력

Zeronet, Freenet, Scuttlebutt을 비롯한 몇몇 플랫폼들은 “인터넷의 탈중앙화”를 위해 노력해 왔습니다. 사실 우리가 오늘날 알고 있는 암호화폐 시대가 도래하기 이전부터 계속 시도했었죠. 하지만 이러한 노력의 상당 부분은 제한적인 활용 사례에 초점이 맞춰져 있었습니다. 이를테면 권위주의 정권의 집권 하에 있는 사용자를 타겟팅한 검열 저항적인 메시징 및 메시지 보드 앱들처럼요.

궁금하시다면 직접 이 플랫폼을 써 보시길 추천하지만 아마 UX상 아쉬운 부분을 많이 느끼실 것입니다. UX도 그렇지만 가장 큰 문제는 아무래도 속도일 것입니다. 정말 답답할 정도로 너무나 느리거든요.

도대체 이유가 뭐길래 이렇게 느린 걸까요?

답은 간단합니다. 코드의 논리가 탈중앙화 되어 있기 때문입니다.

위 플랫폼들은 아래에서 소개할 몇몇 구조를 변형해 차용했습니다. 암호화된 P2P 메시징 앱의 맥락에서 해당 구조를 자세히 설명해 보겠습니다.

1. 위 플랫폼들은 만약 누군가가 앨리스에게 메시지를 보냈는데 그녀가 오프라인 상태라면, 해당 주체는 이를 대신 밥에게 전달해 밥이 앨리스 대신 메시지를 보관하도록 하는 구조입니다.
2. 앨리스가 다시 온라인으로 접속하면, 밥에게 “오프라인이었을 때 놓친 것이 있는지” 물어보겠죠. 즉 메시지의 색인을 찾을 것입니다.

3. 하지만 문제가 있습니다. 앨리스에게는 1) 본인이 온라인인 시점에 밥도 온라인일지, 2) 본인이 오프라인이었을 때 밥이 온라인이었을지, 3) 본인이 오프라인이었을 때 밥이 모든 메시지의 색인을 받아 보관했을지에 대한 보장이 없습니다. 한 가지 해결책으로 밥이 주위 사람들에게 앨리스에게 가야 할 메시지가 있는지 물어볼 수 있겠죠. 하지만 그들도 마찬가지로 오프라인이었을 수 있으며, 설사 온라인이었다 해도 정보를 부분적으로만 소유했을지 모르는 일입니다.

   이런 패러다임에서는 메세지가 잘 전달된다고 보장하기가 불가능합니다. 메시지가 어디로 전달되어야 하며, 누가 메시지 색인을 저장해야 하는지 불확실하기 때문입니다. 사용자가 온라인 상태로 복귀했을 때 본인이 받아야 할 메시지를 찾을 경로나, 메시지들이 참조하는 데이터를 알 수 없기 때문에 불확실성이 배가됩니다.

   P2P 소셜 네트워크를 구축하고자 하는 플랫폼인 Scuttlebutt는 이 문제를 페이스북과 유사한 ‘더블 옵트인 친구 시스템’을 활용해 해결하려 하고 있습니다. 위 시스템은 앨리스와 밥이 친구를 맺으면 본인의 친구 리스트를 서로와 공유하여 ‘앨리스의 친구들이 발행한 컨텐츠’를 밥이 앨리스 대신 인덱싱 및 저장할 수 있게 되는 구조입니다. 이렇게 되려면 앨리스는 본인의 모든 친구들에게 밥이 자신을 대리한다는 사실을 알려야 합니다. 반대의 경우도 마찬가지죠. 이 구조에서는 앨리스가 오프라인일 때 친구가 상태 업데이트를 하면 해당 업데이트를 밥에게 보내 대신 호스트 하도록 할 수 있습니다.

   P2P 소셜 네트워킹 플랫폼보다는 더 보편적인 사용처가 있는 Zeronet과 Freenet도 비슷한 모델을 사용하지만, ‘더블 옵트인 친구 시스템’을 사용하지는 않습니다. 이 때문에 시스템상 꽤나 복잡한 문제들이 생기고 속도가 느려지기도 합니다. 친구들이 서로를 도와 정보의 경로를 찾는 데 동의한 Scuttlebutt 모델과는 달리, Zeronet과 Freenet 사용자들은 임의로 다른 사용자들과 접촉해 어떤 정보를 알고 있는지 물어봐야 합니다. 바로 이런 이유 때문에 이 플랫폼들의 속도가 굉장히 느려지는 거죠.

4. 앨리스가 어떻게든 본인이 오프라인이었을 때 미처 보지 못했던 모든 정보의 색인을 찾아냈다고 가정해 봅시다. 캐롤이라는 친구가 사진을 보냈고, 데이브라는 다른 친구가 “dave.com/alicepic1.png” 경로에 사진을 저장했음을 알아냈습니다. 이때 데이브가 오프라인이라면 앨리스는 어떻게 사진에 접근할 수 있을까요?

이러한 문제는 사소하지 않습니다. 인터넷의 탈중앙화란 결코 쉬운 일이 아닌 것입니다.

논리 및 구조적 (탈)중앙화

지금까지 설명한 모든 문제의 근원은 논리가 중앙화된 저장 및 인덱싱 과정의 부재입니다. 논리적으로 중앙화된 저장이란 무엇일까요? 이 질문에 답하기 위해서는 분산 시스템상에서의 탈중앙화를 구성하는 세 가지 요소를 먼저 이해해야 합니다.

1. 구조적 요소
   • 시스템 내 컴퓨터의 수
2. 정치적 요소
   • 시스템에 영향을 줄 수 있는 사람의 수
3. 논리적 요소
   • 시스템과 외부 에이전트 간 상호작용을 가능하게 하는 인터페이스의 수

위 세 가지 요소를 보다 깊게 이해하고 싶다면 비탈릭 부테린의 에세이를 참고하시기 바랍니다.

기존에 독점적인 지위를 누렸던 Web2 기반 체계들은 논리적으로 중앙화된 저장소에 의존함으로써 앞서 설명한 모든 문제들을 해결했습니다. 다시 앨리스의 비유를 들어 보자면, 앨리스는 온라인에 재접속한 후 중앙화 저장소를 관리하는 중앙화 웹 서비스에 어떤 메시지를 놓쳤는지 물어보기만 하면 웹 서비스는 모든 메시지를 보관하는 데이터베이스를 쿼리(Query)하여 앨리스의 메시지를 반환(Return) 됩니다.

해당 모델의 문제점은 Web2 시스템이 모든 유형의 중앙화를 번들링, 즉 엮고 있다는 점입니다. 논리적으로도, 정치적으로도, (확장할 때를 제외하고는) 구조적으로도 중앙화되어 있습니다.

그렇다면 과연 논리적으로는 중앙화되어 있지만 정치, 구조적인 측면에서는 탈중앙화된 저장 체계가 존재할까요?

다행히도 대답은 확실한 ‘Yes’ 입니다. 컨트랙트 기반 저장소로는 Interplanetary filesystem(IPFS), 영구 저장 저장소로는 Arweave등이 존재합니다. 여기서 컨트랙트 기반 저장이란 ‘X 바이트의 데이터를 Y라는 기간 동안 Z 만큼 가져올(retrieve) 수 있도록 저장하는’ 시스템입니다. AWS, GCP, Azure, Filecoin, Sia 등은 모두 이러한 시스템입니다.

그럼 ‘논리적으로는 중앙화되어 있지만 정치, 구조적 측면에서는 탈중앙화된 저장시스템’은 정확히 무엇을 의미할까요? 이해하기 위한 최선의 접근법은 오늘날 컴퓨터가 어떻게 웹상에서 다른 서버로부터 기본적인 파일을 가져오는지(위치기반 어드레싱) 생각해 본 후 컨텐츠 기반 어드레싱 방식을 채택하는 IPFS나 Arweave의 접근법과 대조해 보면 됩니다.

Web2 구조상 앨리스가 서버에서 사진을 다운로드 받고 싶어한다면 앨리스는 “website.com/image.png”와 같은 URL에 접속할 것입니다. 그러면 정확히 어떤 일들이 일어날까요?

앨리스는 DNS를 통해 website.com의 서버를 찾아낼 수 있으며, 해당 서버에 “/image.png.”라는 디렉토리 상 로컬 파일 시스템에 위치한 이미지를 요청할 것입니다. 서버가 협조적일 것이라 가정한다면 디렉토리 내 /image.png를 확인해 이미지 파일이 존재한다면 앨리스에게 반환할 것입니다.

이 시스템이 얼마나 취약한지 주목해야합니다. 너무 많은 변수가 있습니다. 파일 저장 위치가 이동하거나, 파일 자체가 변경되었거나, 서버가 다른 작업으로 바쁘거나, 어떤 이유로든 협조할 수 없다면 앨리스의 요청은 실패하도록 되어있습니다.

하지만 오늘날의 웹은 이러한 시스템에 기반하고 있습니다.

IPFS나 Arweave가 사용하는 컨텐츠 기반 어드레싱 시스템에서, 앨리스가 찾는 URL은 대충 이런 모습입니다: QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D

사람이 해독 가능한 형태는 아니지만, 위 URL은 본래의 컨텐츠에 따라 결정론적으로 생성됩니다. 한 마디로, 해시 함수에 넣었을 때 100% 동일한 해시값을 생성하는 컨텐츠는 전세계에 단 하나만 존재한다는 것입니다. IPFS나 Arweave은 놀랍게도 뒷단에서 모든 복잡한 과정을 처리하여 컴퓨터가 QmTkzDwW...으로 시작하는 해시값을 이 웹페이지로 풀어낼 수 있도록 한다는 점입니다.

(만약 IPFS가 작동하는 방식에 대해 좀더 알고 싶다면 이 6부작 을 읽어보길 추천합니다.)

IPFS와 Arweave 네트워크상의 컨텐츠는 여러 장치에 나눠 저장되어 있습니다. 컨텐츠가 몇 개의 장치에 걸쳐 저장되어 있는지, 장치들이 전세계 어디에 위치해 있는지, 또 실제 컨텐츠의 저장 위치가 어디인지와 관계없이 프로토콜은 QmTkzDwW...로 시작되는 복잡한 주소를 처리할 수 있습니다.

컨텐츠 기반 어드레싱의 놀라운 저력은 여기서 나타납니다. ‘컨텐츠 기반 주소’라는 단 하나의 논리 인터페이스를 활용하여 구조적, 정치적으로 탈중앙화된 수많은 컴퓨터 네트워크상에 저장된 데이터의 실제 위치와 상관없이 정확한 결과를 전달할 수 있습니다.

포스팅 초반에 제시한 네 가지 주요 기술적 문제 중 컨텐츠 기반 어드레싱이 해결할 수 있는 건 1번(컨텐츠 저장하기), 3번(컨텐츠 다운로드를 가능하게 하기), 그리고 4번(저장 주체의 개인정보 열람 방지하기) 입니다. 그렇다면 2번(데이터 경로 찾기) 문제는 어떻게 해결해야 할까요?

인덱싱 (Indexing)

IPFS와 Arweave가 ‘논리적으로 중앙화되었지만 정치적, 구조적으로는 탈중앙화된 파일 시스템’으로 기능하긴 하지만, 데이터베이스인 것은 아닙니다. 즉 이런 플랫폼에 “X~Y 기간 중 밥이 앨리스에게 보낸 모든 메시지를 보여줘”라는 요청을 할 수는 없다는 거죠.

다행히 이런 문제를 해결할 몇 가지 방법이 있습니다.

한가지 접근 방법은 블록체인에 직접 메시지의 색인을 저장하는 것입니다. 블록체인은 논리적으로는 중앙화되었지만 구조/정치적으로는 탈중앙화된 데이터베이스입니다. 탈중앙화된 Graph나 중앙화된 dFuse같은 서비스를 활용하여 앨리스는 블록체인상 저장된 색인들을 쿼리할 수 있습니다. 블록체인은 기반 데이터 자체보다는 해시된 데이터를 저장합니다. 이 해시는 IPFS나 Arweave에 저장된 컨텐츠를 알려주는 포인터 역할만 합니다. Graph와 dFuse는 현재 운영되고 있으며, 많은 어플리케이션들이 컨텐츠 기반 어드레싱 시스템 상에 저장된 데이터 위치를 알려주는 해시를 온체인으로 저장하는 모델을 적용하고 있습니다.

두번째로는 Textile을 레버리지하는 방식이 있습니다. Textile은 스레드(Threads)라고 불리는, IPFS 상에서 암호화된 비공개 데이터베이스 역할을 하는 독자적 고유기술을 구축했습니다. 데이터베이스가 IPFS상에 구축되어 있기 때문에 논리적으로는 중앙화되었지만 구조/정치적으로는 탈중앙화되어 있는 것입니다. 중앙화 데이터베이스로서 전송자와 수신자는 각자 정보를 어디로 보내야 하고 어디에서 가져와야 하는지를 알 수 있습니다. 나아가 Textile은 최근 Cafes를 출시하여 사용자가 자신들의 스레드를 로컬 장치에서 호스트 하는 대신 서버를 설립하여 호스트 할 수 있도록 했습니다. Textile의 다음 단계는 Filecoin이 IPFS의 경제적 레이어로서 작용하는 것과 유사하게 검증인들이 다른 사용자를 대상으로 Cafe를 호스팅할 인센티브를 제공하는 경제적인 레이어를 구축하는 것입니다.

세번째 접근 방식은 OrbitDB을 활용하는 것입니다. OrbitDB는 Textile의 스레드와 유사하지만, 공공데이터만(예. 탈중앙화된 트위터를 구축하는 데 필요한 데이터)을 위해 디자인되었다는 점이 다릅니다. 반면 Textile의 스레드는 개인정보(P2P 메시징 등) 보호를 위하여 암호화와 키 관리를 상위 단에서 체계와 통합한 방식을 채택했습니다. Textile처럼 OrbitDB는 실제 사용되고 있으며, OrbitDB 팀은 현재 기반 기술 위에 경제적 레이어를 구축할 수 있는 방법을 연구 중입니다.

마지막으로, 기존 데이터베이스에 탈중앙화의 다양한 요소들을 결합하고자 하는 팀들이 몇몇 있습니다. Fluence의 데이터베이스는 BFT가 보장되는 무허가성 환경에서 구현될 것이며, Bluzelle은 두 개 티어로 이루어진 시스템을 통해서 한편으로는 마스터 노드로 구성된 정치적으로 중앙화된 세트를, 다른 한편으로는 구조적으로 탈중앙화된 레플리카 노드 세트를 갖춘 모델을 구현하려고 하고 있습니다.

Solana의 Replicators과 같이 데이터 가용성 문제를 해결하려고 하는 스마트 컨트랙트 팀들이 많기 때문에 기존 데이터베이스에 BFT 레이어를 추가하는 방식에는 회의적입니다. 대신 Textile 처럼 ‘원천적으로 블록체인에 기반한’ 데이터베이스와, Graph나 dFuse과 같은 형태의 개발자 API 레이어에 투자하기로 결정했습니다.

위에서 언급한 IPFS, Filecoin, Arweave, The Graph, dFuse, Textile, OrbitDB과 같은 프로토콜이나 서비스를 잘 활용하면 Web3는 확실히 성장할 수 있을 것입니다. 비록 바로 상용화가 가능하거나 검증된 암호화폐적 경제성을 아직 갖춘 것은 아니지만, 모두 이미 존재하는 서비스들입니다. 어찌됐든 가장 중요한 문제점에는 이미 알려진 해결방안들이 있습니다. 바로 정치적, 구조적으로 탈중앙화된 시스템에 단일 중앙화 인터페이스를 입히는 것이죠.

더 남은 이야기가 있을까요?

상위 논리

지금까지 논리적으로 중앙화되었지만 구조적으로 탈중앙화된 저장시스템, 인덱싱, 정보 ‘가져오기’에 대해 논의했으니, 상위 논리에 대해 생각해 볼 수 있을 것 같습니다. 아래 예시를 보시죠.

1. 앨리스가 여러 개의 신원을 관리하고 싶어한다면 어떨까요? 일례로 앨리스는 페이스북/구글/스냅챗/레딧 등의 플랫폼에서 동일한 퍼블릭 키를 사용하고 싶지 않을 수 있습니다. 실제로는 한 사람이라는 사실을 공개적으로 알리지 않으면서 다수의 신원을 단일 인터페이스 상에서 관리하고 싶다면 어떻게 할 수 있을까요?
2. 앨리스가 밥에게 개인 정보를 보내고 싶어하지만 사실상 공공 시스템인 IPFS나 Arweave상에 저장하길 원한다면 완벽전달비밀성(Perfect Forward Secrecy, PFS) 악수(Handshake)를 레버리지 해야 합니다. PFS을 어떻게 비동기식으로 구축하고 관련 키들을 모두 관리할 수 있을까요?
3. 기존의 암호화 시스템의 설계 의도가 당사자 두 명 사이의 소통만을 감안했다는 점을 고려했을 때, 메시지 보드나 큰 채팅 그룹에서처럼 다수 간의 사적인 소통을 지원하기 위해선 어떻게 해야 할까요?
4. 새로운 그룹 찾기, 사용자 데이터 복구, 컨텐츠 제거 등의 흔한 UX 패턴은 어떻게 구현할 수 있을까요?

모두 서로 다른 기술적 도전과제이지만, ‘상위 논리에서 해결할 문제’라는 공통된 카테고리로 분류할 수 있을 것 같습니다.

Textile의 스레드는 이런 문제들을 정확히 대응했습니다. Textile은 많은 측면에서 ‘IPFS를 위한 iCloud’로 생각할 수 있습니다. 비록 완벽한 비유는 아니지만, 전반적으로는 어느 정도 맞습니다. 보다 나은 사용자, 개발자 환경을 제공하여 장치간 동기화와 어플리케이션 데이터 백업을 지원하는 iCloud 처럼, Textile 또한 IPFS 위에 ‘상위 논리 툴’을 제공해 개발자들이 수월하게 어플리케이션 개발을 할 수 있도록 하는 한편 원활한 장치간 동기화와 IPFS 사용자 데이터 백업도 지원합니다.

향후 전망

Web3 생태계는 해결되는 문제의 유형들, 관련 팀의 위치, 활용되고 있는 경제적 모델 등 여러 측면에서 굉장히 다양합니다. Web3 스택이 전반적인 협조를 총괄하는 중앙화된 단일 주체가 없음에도 불구하고 성과를 이뤄내고 있는 점은 인상 깊습니다. 하지만 Web3 내부에는 여전히 무질서가 존재하기 때문에 전반적인 테마를 이해하기가 어렵습니다. 이번 포스팅에서 제가 정리한 테마는 다음과 같습니다.

Web2에서 Web3으로의 전환에 있어 가장 큰 도전과제는 중앙화의 세가지 축 (논리, 구조, 정치)이 모두 번들링된 시스템에서 ‘논리적으로는 중앙화되었지만 구조/정치적으로는 탈중앙화된 시스템’으로 전환해야 한다는 점입니다.

만약 Web3 스택에서 코어 인프라나 앱을 개발하고 있다면, 트위터로 DM을 주시거나 이 링크로 연락 주시기 바랍니다. 우리는 Web3에서 더 많은 투자 기회를 찾고 있습니다. Web3는 향후 10년간 수십 조 달러의 경제적 가치를 발생시킬 패러다임 변화일 것으로 생각되며, Web3의 인프라를 구축할 뛰어난 기업가들과 함께하고 싶습니다.

이 글에 도움을 준 Andrew Hill 과 Sam Williams 에게 감사의 말씀을 전합니다.

고지사항: 멀티코인 캐피털은 본 포스트에서 언급된 Solana, The Graph, Textile, Arweave, Dfuse등에 투자하고 있습니다. 멀티 코인 캐피탈은 공개 후 72 시간 동안이 보고서에 나열된 자산에 대해서는 “거래 금지 정책”을 준수합니다 (“ 거래 금지 기간”). 임원, 이사 또는 직원은 거래 금지 기간 동안 위에 언급된 자산을 구매 또는 판매할 수 없습니다.