나도 dApp 개발해보자 강좌 - 2

※ 이 글은 chaintalk의 atomrigs 님이 쓰신 글을 인용하였습니다.

(2) dApp 의 아키텍쳐

dApp - 탈중앙화된 어플리케이션이 도대체 무엇인지를 알아보기 전에 우선 기존 인터넷 서비스의 중앙화된 서버-클라이언트 모델 아키텍처를 먼저 살펴보도록 하겠습니다.

 

 

현재 대부분의 웹사이트는 기본적으로 다음과 같은 구조를 하고 있습니다.

중앙서버는 한 회사나 조직에 의해 소유, 관리, 통제됩니다.

 

이 중앙서버에는 웹서버란게 있습니니다.

 

 

이 웹서버는 외부의 클라이언트들이 보낸 요청(request)을 받아서, 이를 가공해서 데이타베이스에 저장하거나, 또는 클라이언트가 요청한 정보를 데이터베이스로부터 검색, 가공해 다시 클라이언트로 보내주는(response) 역할을 합니다.

예를 들자면 제가 지금 쓰고 있는 이 글을 웹서버가 데이터베이스에 저장할 것이고 나중에 다른 멤버분들이 이 글을 클릭해서 읽으려 하면 웹서버가 데이터베이스에 저장된 이 글을 다시 보여주게 되는 것입니다.

 

즉, 저와 이 글을 읽는 분들이 바로 클라이언트들이고 웹서버는 중앙에서 우리가 쓰고 읽는 과정을 통제하는 역할을 하는 것입니다.

 

다시 정리하자면 웹서버는 클라이언트와 서버의 모든 리소스(글이든, 그림이든, 영상이든)를 연결하는 ‘중계자’ 또는 ‘콘트롤러’의 역할을 하고 있는 것입니다.  

 

웹서버에 필요한 기능을 구현하기 위해 사용하는 프로그래밍 언어는 매우 다양한데, php, jsp, asp.net, node.js 등이 많이 쓰이고 있습니다.

웹사이트가 런칭되고 활발해지기 시작하면 중앙서버 데이터베이스에는 많은 데이터가 쌓이기 시작합니다.

 

데이터베이스의 쌓이는 양이 점점 커짐에 따라 데이터를 분산해서 저장하거나, 혹시라도 모를 데이터의 분실을 막기 위해 동일한 내용의 데이터를 여러 데이타베이스에 저장해두기도 하며 이 모든 것은 중앙의 웹서버에 의해 관리, 통제되는 것입니다.

  

이러한 중앙의 웹서버에 접속하는 대표적인 클라이언트가 바로 사용자 브라우저입니다.

바로 여러분과 제가 지금 이 글을 읽고 쓰고 있는데 사용하고 있는 브라우저가 클라이언트인 것입니다.

(크롬, 익스플로러 브라우저 등등)

 

웹 브라우저는 중앙의 웹서버가 보내준 html, css, 자바스크립트(js) 파일을 받아서 이를 사용자의 화면에 보여줍니다

(이것을 랜더링이라고 합니다).

또한 사용자가 키보드나 마우스로 입력한 값을 받아서 이를 다시 중앙의 웹서버로 보내어서 처리할 수 있게 해줍니다.

 

html 은 웹 브라우저가 이해하는 기본적인 문서양식입니다. 웹사이트를 제작하는 사람들은 html 양식으로 사이트를 제작해야 웹브라우저가 이해할 수가 있다는 이야기입니다.

css 는 html 문서를 시각적으로 더 멋지게 꾸며주는 기능을 제공합니다.

 

javascript 는 여기에서 좀더 나아가 클라이언트의 브라우저내에서 추가적인 다이나믹한 기능을 구현할 수 있도록 해주는 프로그래밍 언어입니다.

 

이를 다시 정리하자면 html 은 웹사이트를 제작하는 가장 기본적인 문서양식이고. css 는 웹사이트를 더 멋지게 만들어주는 스킬들. javascript 는 웹사이트를 더 빡세게 멋지게 만들어주는 스킬들이라 할 수 있습니다.

 

 

웹 브라우저 초창기에는 자바스크립트의 기능이 매우 한정되어 있었고, 주로 브라우저에서 동적인 효과를 내는 UI 보조수단 정도로 인식되었습니다. 

예를 들어 아이콘 애니메이션을 구현하거나 ( 막 아이콘 움직이고 그런 것) 사용자의 입력값에 따라 페이지의 내용이 부분적으로 다이나믹하게 업데이트되는 그런 정도의 단순한 기능 구현에 많이 사용되었습니다.

 

 

하지만 중앙서버 웹 아키텍쳐 모델이 발전함에 따라 갈수록 더 많은 기능과 역할이 브라우저 쪽에 주어지고 있고, 그러한 기능을 구현하는 핵심에 자바스크립트와 이를 베이스로 한 여러가지 솔루션들이 보편화되어 왔습니다.

심지어는 웹서버에서도, 자바스크립트를 기본 언어로 사용하는 node.js 가 그 비중을 계속 늘려가고 있습니다.

 

 

중앙서버를 사용한 웹 애플리케이션 아키텍쳐들 – 우리가 아는 거의 모든 웹사이트 서비스들이 이렇게 광범위하게 사용되고 보급된 것은 그만큼 많은 장점을 가지고 있기 때문입니다.

 

 

가장 우선적으로 꼽을 수 있는 것은 효율성이겠지요.  

공통적으로 처리해야 할 데이터와 작업을 단일 시스템에 모아놓고 집중적으로 처리하니 효율성이 올라가겠지요.

 

 

시스템의 처리능력의 증가가 필요할 때, 전체 클라이언트들의 업데이트 없이도, 중앙 서버만의 업그레이드만으로도

처리능력을 증가시키기도 매우 쉽습니다.

 

데이타에 대한 접근 권한 통제에 있어서도 중앙서버는 매우 유리합니다. 사용자별 권한을 정해서 부여하면 서버 외부의 사용자는 전적으로 이 권한의 테두리 안에서만 접근이 가능해집니다.

 

 

그런데 이러한 기술적 장점 이외에, 경제적 측면에서의 동기도 매우 중요합니다.

 

인터넷의 개념이 처음 소개 되었을 때, 강조점은 중앙서버적인 모델이 아니라 오히려 p2p 적인 성격에 더 많이 두어졌습니다.

 

군사 네트워크의 기술로 개발된 인터넷은 전체 네트워크를 통제하고 관장하는 중앙 기관이 없이 각자 합의된 프로토콜을 준수하면 통신할 수 있도록 하고자 한 것이었습니다.   

중앙 통제 시설이 있다면, 유사시 이곳만 파괴해버리면 전체 군사 네트워크가 마비될 테니까요.

 

 

인터넷 초기 대중적으로 가장 먼저 활용되기 시작한 이메일 서비스도 p2p 개념이 우선이었습니다.

  

각자 smtp 라는 기본 프로토콜 문법을 따르면 외부서버에 의존함 없이 각자의 프로그램으로 이메일을 주고 받을 수 있도록 설계되었습니다.

 

지금도 대부분의 리눅스는 기본적으로 독립 이메일 에이전트 프로그램을 가지고 있습니다.

 

하지만 인터넷 서비스를 대중화시키는 과정에서 이를 이용한 이윤창출이라는 경제적 목적이 절대적인 비중을 차지하기 시작했습니다.

 

 

닷컴버블을 통해 많은 새로운 인터넷 서비스에 투자가 이루어졌는데 여기서 투자자들의 이익을 극대화하고 보장해줄 수 있는 가장 최선의 방법이 서비스를 중앙화하고, 이를 통해 생산되는 가치를 집중화하고 이에 대한 지분을 늘리는 것이었습니다. 

 

더구나 네트워크 효과로 인해 규모가 큰 서비스는 더욱 많은 효용성을 사용자들에게 제공할 수 있기 때문에, 인터넷 서비스들의 집중화, 중앙화, 독점화는 더욱 가속되게 됩니다. 그 결과 이전 어떤 산업보다도 인터넷은 더 독점적인 기업들이 중심이 된 시스템이 되어가게 된 것이죠.

 

 

중앙화된 서비스들이 가진 많은 장점들에도 불구하고, 점차 이들 서비스 모델에서도 한계와 문제점들이 드러나기 시작하게 됩니다. 

많은 사용자들의 정보가 중앙서버에 전부 모아져 있다보니 늘 내부, 외부집단에 의한 해킹과 데이타 유출에 대한 위험성이

지적되고 있습니다.

 

정부와 소수 독점기업에 의한 개인 사생활에 대한 침해, 감시에 대한 우려도 높아지고 있습니다.

지나친 이윤의 집중으로 새로운 혁신적인 서비스들이 경쟁할 수 있는 기반이 약화되고 있고, 독점적인 지위를 차지한 기업들의 시장지배 때문에 생기는 비효율성도 생겨나고 있습니다.

 

예를 들어 우버라는 공유경제 모델을 지향한 서비스 모델도 등장했지만, 이 역시 중앙화된 서버를 가진 회사가 이 시스템의 효율성에 의해 생긴 부의 대부분을 다 가져가고 막상 이에 종사하는 운전사들은 이전 택시 운전사들보다 더 열악한 근무조건에서 일해야 되는 경우도 많아졌습니다.

 

 

한편으로는 IoT 라는 새로운 네트워크 환경의 등장도, 기존의 중앙서버 중심의 모델이 더 이상 가장 효율적일 수 없는 상황이 되어가고 있습니다.

 

소수의 서버들로 처리하기에는 너무나 많은 인터넷 디바이스(장치)들이 네트워크에 물려있게 되는 것이지요. 

 

탈중앙화된 어플리케이션은 이러한 중앙화된 모델에서 파생하는 여러가지 문제들에 대한 대안으로서 부각되기 시작하고 있습니다.

 

물론 모든 인터넷 서비스를 탈중앙화시키는 것이 바람직한 것은 아닙니다. 어떠한 서비스에서 어떤 조건일 때 탈중앙화된 모델이 더 바람직 할지에 대한 많은 고민과 시도들의 축적이 우선 필요할 것이라 봅니다.

 

 

자 이제 본론으로 들어와서, 이더리움을 베이스로한 탈중앙화된 어플리케이션의 기본 아키텍쳐를 살펴 봅시다.

위의 중앙화된 모델과 비교해서 가장 큰 차이점은 중앙 서버가 없다는 점입니다.

 

 

각각의 사용자가 모두 독립노드가 되어서 똑같은 역할을 하게 됩니다. 

 

그림에서는 2개의 노드들만 연결시켜 놓았지만, 이러한 노드들이 무수하게 서로 연결되어 이더리움 네트워크를 이루게 됩니다.

 전체 네트워크 모양은 이런 형태가 될 것입니다. 

우선 dApp 을 이용하는 사용자 측면에서 보자면, 기존 인터넷 사용환경과 크게 다르지 않습니다. 블록체인 관련 기능이 추가된 인터넷 브라우저가 주 사용환경이 됩니다. 

 

전용 브라우저인 미스터나 패러티를 작동시키면 커스터마이징된 일반 인터넷 브라우저라는 느낌을 받습니다. 심지어는 크롬과 같은 기존 브라우저에 블록체인에 엑세스하고 지갑을 관리할 수 있는 익스텐션인 메타마스트를 깔고 사용해도

거의 비슷한 환경이 됩니다. 

 

기본적으로 기존 인터넷 브라우저와 동일한 환경이다 보니, 클라이언트용으로 개발된 많은 툴이나 프레임워크들을 거의 그대로 사용할 수 있습니다.

 

 

특히 단일페이지 어플리케이션(single-page application, SPA)이라고 부르는 프레임워크들은 dApp 개발환경에 매우 잘 맞아 들어갑니다.  

 

가능한 많은 비지니스 로직과 기능들을 서버에 두는 대신 로컬 브라우저에서 처리하려고 하기 때문입니다. 이중에서 특히 Meteor 가 이더리움 dApp 개발에 많이 쓰이고 있습니다.

 

즉, 흔히 말하는 프론트엔드 작업은 (외부로 웹사이트가 보여지는 부분을 작업하는 외부영역 – 웹사이트 디자인이라든지)

기존의 웹 어플리케이션 개발과 큰 차이가 없다고 할 수 있습니다.

 

 

데이타스토리지인 백엔드 (웹서버와 데이터스토리지 등을 작업하는 내부영역) 에 접근하는 방식 역시 개념적으로 별로 다르지 않습니다. API RPC 방식을 사용한 웹 어플리케이션들과 매우 유사합니다.

 

 

web3.js 는 백엔드과 커뮤니케이션하는 기본적인 기능 또는 함수들을 묶어 놓은 라이브러리입니다. 

어떤 어카운트의 밸런스를 확인하거나, 새로운 트랜잭션을 블록체인에 올리거나 할 때 모두 이 web3.js 를 사용합니다. 

컨트랙트 ABI 는 블록체인 컨트랙트에 올려져 있는 비지니스 로직 코드에 엑세스하기 위한 인터페이스입니다.

 

web3.js 가 모든 dApp 들에 필요한 기본적인 인터페이스를 제공해주는 반면, 컨트랙트 ABI는 각 dApp 이 가지는 특정한 컨트랙트에 액세스하기 위한 인터페이스를 제공합니다. 

즉, 컨트랙트 코드가 제공하는 함수와 변수들을 식별할 수 있게 해줍니다.

 

이 외에도 용량이 큰 자료를 보관하기 위한 별도의 p2p 스토리지에 엑세스하기 위한 인터페이스도 필요하고, p2p 리얼타임 메시징 서비스에 엑세스하기 위한 인터페이스도 필요합니다. 이더리움은 p2p 스토리지로 사용하기 위해 swarm 이라는 프로토콜을 제공하고, p2p 메시징을 위해서는 whisper 를 제공합니다. 이들 서비스는 dApp 구현을 위해 반드시 필요한 것은 아니며, 필요에 따라 추가할 수 있는 선택 사양입니다. 또한 다른 p2p 네트워크를 바탕으로 한 p2p 서비스인 ipfs 와 같은 서비스와 연동해도 상관 없습니다.

 

중앙서버 모델과 비교해서 탈중앙화된 모델은 가장 결정적인 차이는 결국 백엔드에 있습니다.

중앙서버가 없다면 백엔드 데이타와 비지니스 로직은 도대체 어디에 저장되는 것일까요?

 

이것을 이해하는 것이 dApp 아키텍쳐를 이해하는 가장 핵심적인 사항이겠지만, 기술적인 측면에서 블록체인의 세부적인 메카니즘을 이 글에서 전부 설명하기는 힘들 것 같습니다.

 

이더리움 블럭체인의 구조의 세부사항에 대해서는 별도의 문건을 통해 살펴보는 것이 좋겠습니다.

 기본적인 아이디어는 이렇습니다.

 

데이타를 중앙서버가 가지는 것이 아니라, 각 노드들이 동일한 복제본을 각각 보관하는 것입니다. 각 노드들이 가진 데이타를 지속적인 싱크를 통해서 일치시켜 나감으로써 데이타의 정합성을 유지합니다.

 

이 데이타는 다수의 어카운트로 구성되는데, 어카운트에는 두가지 형태가 있습니다.

1. 사용자 어카운트 (프라이빗 키에 의해 제어됨)

2. 컨트랙트 (코드에 의해서 제어됨)

 

이들 어카운트들은 모두 상태(state) 정보를 가집니다.

이 상태정보를 바꾸는 것이 트랜잭션입니다. 트랜잭션은 사용자 어카운트에서 일으킬 수도 있고, 컨트랙트가 발생시킬 수도 있습니다.

 

이 중 컨트랙트에 포함되는 코드가 바로 애플리케인션의 핵심적인 비지니스 로직을 구성하게 됩니다.

 

 

이더리움은 컨트랙트 코드를 프로그래밍하는 상위 언어를 제공하는데, 그 중 가장 보편적으로 쓰이는 것이 솔리디티(solidity) 입니다. 

 

이더리움 컨트랙트 코드는 EVM 이라는 가상머신을 통해 수행되고 그 결과에 의해서 어카운트의 상태가 변화하게 됩니다.

 

 

트랜잭션들은 일정한 주기마다 블록이라는 그룹으로 묶여서 다른 노드들로 전파가 됩니다.

 

각 블록에는 이 안에 포함된 트랜잭션들의 해시값과 이전 블록의 해시값을 포함하게 됨으로써 상호간에 불일치가 있거나, 과거기록에 대한 변조가 있을시 쉽게 발견될 수 있도록 합니다.

 

네트워크에 참가하는 모든 노드들(정확히는 Full Node입니다)은 이들 블록을 각자 처리하고 그 결과가 동일함을 서로 합의해(consensus) 갑니다.

 

이 합의과정이 블록체인 기술의 가장 중요한 메카니즘입니다.

이 합의 방식에는 여러 가지 솔루션들이 있는데, 이더리움이 현재 사용하고 있는 방식은 Proof of Work 의 일종입니다. 하지만 보안성을 더 높이고, 처리속도와 용량을 대폭적으로 향상시키기 위해 Proof of Stake 의 한 형태인 캐스퍼 방식으로 전환하고자 계획 중입니다.

 

이렇게 각 노드들의 합의에 의해 dApp 의 백엔드인 블록체인의 정합성이 유지됩니다.

 

 

그렇다면 dApp 아키텍쳐가 중앙서버 모델에 비해 가지는 장점은 무엇일까요?

● 운영주체에 대한 신뢰가 필요 없거나 최소화

 

● 투명한 운영 원칙과 규칙 관철 용이

 

● 보안 향상

 

● 프라이버시 보호

 

● 이미 투자된 자원의 활용도 증가

 

● 국가별 규제를 넘어선 글로벌 서비스 용이

 

● IoT 네트워크에 매우 유리

 

● 소수기업의 서비스/이윤 독점화 해소

 

 

이들 장점들이 dApp 만 사용한다고 해서 모두 발휘되고 기존 중앙서버 모델의 문제를 단번에 모두 해결한다고는 볼 수 없을 겁니다. 

독자적인 인터넷 서비스로서 사용자들에게 경쟁력있는 사용가치를 만들어내지 못한다면, 탈중앙화된 모델을 사용한다는 것만으로는 큰 장점이 되지 못하는 경우가 많을 것입니다.

 

반면, 탈중앙화된 어플리케이션들이 넘어야 할 제약 또는 단점들도 존재합니다.

  

어떤 트랜잭션을 실행하기 위해서는, 네트워크에 있는 모든 노드들이 전부 이를 다 실행해봐야 한다는 비효율성이 항상 존재합니다. 스케일링에 매우 제한이 되는 요소입니다.

 

 

이를 해결하기 위한 노력, 예를 들어 샤딩 기법, 멀티체인 솔루션들이 활발히 연구되고 있지만, 안정적인 솔루션이 나오기까지는 아직 많은 시간이 필요합니다. 스케일링에 제한이 있다 보니, 트랜잭션에 대한 비용이 부담이 될 수도 있습니다.

  

너무 복잡한 트랜잭션이나 로직을 구현하려다 보면 이에 소모되는 비용이 너무 클 수 있습니다. 아직까지는 비교적 단순한 형태의 로직에 촛점을 맞추는 이유들 중의 하나입니다.

 

 

블록체인에서 직접 제공되는 데이터는 단순 키-밸류에 불과합니다. 다른 현대적인 데이터베이스에 비하면 형편없이 초보적인 기능만이 제공됩니다. 따라서 이를 보완하기 위해 블록체인과 함께 별도의 여러 가지 형태의 인덱스와 필터링을 제공하는 로컬 데이터베이스를 운용하는 기법들도 더 많이 발전할 것으로 예상됩니다.

 

 

dApp 을 기획하고 설계함에 있어서 탈중앙화된 모델이 가진 장점들을 극대화시키면서도, 피하기 어려운 단점들을 잘 보완하는 것이 좋은 설계의 핵심일 것 같습니다. 그리고 이런 좋은 설계는 한 번에 완성되는 것이 아니라 많은 실패와 경험의 축적이 필요하리라 생각합니다.

 

 

다음번 글에서는 dApp 의 핵심인 컨트랙트의 가장 단순한 형태를 살펴보고자 합니다.