Web App 과 Web DApp

nanaones
B!ock.Chain
Published in
12 min readApr 29, 2019

개인적으로 구상하고 있던 DApp 을 구현하기 위한 검색 도중에 Web App을 DApp으로 바꾸는 과정을 상세히 적은 글을 찾았습니다. 글을 읽기 전에 들던 가장 첫 질문이 바로

그렇다면, Web App과 Web DApp은 뭐가 다를까?

였습니다. 두 가지 종류의 Application 을 비교해 보겠습니다.

우선, 사전적 의미부터

근데, Web App은 말이야…

구조 살펴보기

  • Web App 구조
  • Web DApp 구조

그래서, 둘이 뭐가 달라?

  • 아직은 초기단계인 DApp
  • 이익의 분배와 참여의 가치에 중점을 두다.

우선, 사전적 의미부터

DApp에 관련된 내용은 저의 지난글을 보신 분들은 이미 알고 계실겁니다.

DApp의 사전적 의미 [출처 : 해시넷 ]

보통 ‘응용 프로그램’이라고 부르는 App에 ‘탈중앙화’를 의미하는 Decentralized 를 더하여, 문자 그대로 이해하게 된다면 ‘탈중앙화된 응용프로그램’ 이라고 받아들일 수 있습니다.

출처 : 제글(DApp의 종류에 관하여)

Application 이라는 단어 자체가 ‘응용프로그램’을 의미합니다.

결국, 아래와 같습니다.

Web App ←웹 + 응용프로그램
Web DApp ←웹 + 탈중앙화 + 응용프로그램

근데, Web App은 말이야…

Web App : 웹 애플리케이션(web application) 또는 웹 앱소프트웨어 공학적 관점에서 인터넷이나 인트라넷을 통해 웹 브라우저에서 이용할 수 있는 응용 소프트웨어를 말한다.

웹 애플리케이션은 클라이언트로서 웹 브라우저를 사용하는 사람이 많기 때문에 인기를 누리고 있다. 수천만 대의 PC에 굳이 소프트웨어를 배포해서 설치하지 않아도 웹 애플리케이션을 유지 관리할 수 있다는 점이 장점 중의 하나이다. 웹 애플리케이션은 웹 메일, 온라인 전자상거래 및 경매, 위키, 인터넷 게시판, 블로그 및 MMORPG 게임 등 다양한 기능을 구현할 수 있다.

출처 : Web App (웹 어플리케이션) 위키

Web App은 브라우저를 클라이언트로 실행되는 응용프로그램입니다.

구조 살펴보기

Web App과 Web DApp의 구조는 당연하게도, 서로 다릅니다.

1. Web App 구조

기본적인 Web App의 구조

보통의 Web App의 구조는 위와 같습니다. Middle Ware가 Server와 Web Application 들을 연결해줍니다.(알맞는 Application을 호출하여 실행해줍니다.)

Web Server는 정적입니다. HTTP Request를 통해 리소스를 요청하면, 그 리소스를 그대로 보내줍니다. 이렇게 정적인 Web Server에서 동적인 작업을 처리하기 위해서 Middle Ware가 존재합니다.

사실, 한 번에 ‘Middle Ware’ 라고 적어놓았지만, 각 인터페이스에 따라서 지원하는 방법이 조금씩 다릅니다.

사용자가 Web Server로 HTTP Request를 전송하면, Web Server는 Middle Ware로부터 해당되는 Application을 호출하여 결과를 다시 사용자에게 보냅니다.

2. Web DApp 구조

지난 저의 글에서 언급하였던 DApp의 종류 중에서, Hybrid 방식을 기준으로 이야기 해보겠습니다.

Web DApp을 만들었을 때의 구조

네에… 뭔가 큰게 하나 생겼습니다.

그리고, Middle Ware의 일부분까지 Blockchain Platform이 덮친(?) 것을 확인할 수 있습니다.

그럼… 너가 다 해주는거야…?
출처 : ICON공식 깃헙 T-Bears 설명

Blockchain Platform 부분의 내용을 알아보기 위해서
ICON의 T-Bears 라는 SCORE(ICON의 Smart Contract)개발툴의 구조를 ICON 공식 깃헙에서 가지고 왔습니다.

그림에서 지금 설명에는 필요 없는 부분을 지우고, 약간의 편집을 해 보면…

짜잔!

T-Bears CLI, T-Bears Block Manager를 삭제한 그림

IICON Service 모듈은
SCORE(ICON의 Smart Contract)의 생명주기를 관장합니다.

ICON 의 RPC Server GitHub에 들어가보면 RPC Server 에 대한 설명이 나와있습니다.

This is intended to give an introduction ICON RPC Server. ICON RPC Server receives request messages from external clients, and send a response to clients. when receiving the message, ICON RPC Server checks the method of requests and transfer it to appropriate components (loopchain or ICON Service). ICON RPC Server also checks the basic syntax error of messages.

출처 : ICON 공식 Github, ICON-rpc server

메세지를 수신받게 되면,
적절한 구성요소로 전달한다는 내용이 기록되어있습니다.

어라..? 이건…?

네, Middle Ware 가 하는 역할과 비슷합니다.

따라서, Blockchain Platform 에 필요한 기능이 구현되어있으므로 우리는 Smart Contract 를 통해서 원하는 비즈니스 로직을 구현하면 됩니다.

Web DApp을 만든다면, 위와 같은 구조일 것 입니다.(물론, BlockChain platform이 구현했기 때문에 개발자는 Smart Contract만 구현하면 됩니다.)

사실, 이런 구조는 BlockChain에서 최초로 도입된게 아닙니다.

출처 : fullstack Python

Spring, Django 와 같은 Web Framework를 통해서 개발하게 된다면, 위와 같은 구조의 Web을 개발할 것 입니다. (사실 다 쓰지 않는 경우가 더 많긴 하지만…)

Framework들은 사실, 개발자가 서비스의 개발에 집중 할 수 있도록, 그리고 개발 속도가 더욱 빨라질 수 있도록 뒤에서 해주는 역할이 아주 많이 있습니다.

위 그림과 같이 Heroku같은 Cloud Service에서 Django 를 사용하여 사용자들이 원하는 기능을 빨리 편하게 만들어 서비스 할 수 있도록 제공되는 경우를 Platform-as-a-Service, PaaS 라고 부릅니다.

Django가 PaaS의 구성품으로서 개발자가 웹 어플리케이션에만 집중할 수 있도록 해줍니다.

위 그림은 Platform-as-a-Service(PaaS)가 어떤 부분을 포함하는지를 간단하게 그린 그림입니다.

[덧]as-a-Service 시리즈

그림 출처 : MS AZURE HomePage

그래서, 둘이 뭐가 달라?

지금까지 이야기했던 내용을 보면, 딱히 달라보이는것도 없습니다.
사용자가 접하는 화면 (UI)도 다를건 없습니다.

사실, 사용하다보면 “이게 DApp인가?” 싶은 DApp도 많습니다.

잘만들었다는 뜻 입니다.
이쯤에서 다시보는 갓 — SOMESING

그래도 다른점을 이야기 해 보자면

아직은 초기단계인 DApp

크게 다른점이 있다기 보다는, DApp과 Blockchain 기술이 아직 초기 단계이기 때문에 Troubleshooting의 이슈가 큽니다.

확장성과 성능의 문제를 해결하기 위한 솔루션의 부재

기존의 Web App :

마이크로 서비스 아키텍쳐 도입을 통해, 서비스가 커짐에 따라 특정 기능을 담당하는 여러 서버를 구성할 수 있습니다.

오토스케일링(Auto Scaling)의 도입을 통해, 트래픽에 따라 자동적으로 서버를 증축, 감축할 수 있습니다.

현재의 Web DApp :

…?

사용하는 플랫폼에 종속되는 DApp의 성질

사용되는 Blockchain Platform에 따라 DApp들의 성격이 많이 달라집니다. Blockchain은 SandBox Ploicy를 따르기 때문에, 규제가 상당히 엄격합니다.

따라서, Platform에서 지원하는 기능만 사용할 수 있는데, 그 기능이 기존의 Web App을 위한 Platform에 비해 빈약합니다.

예를 들자면, ERC-721 의 인기를 뜨겁게 만들었던 ‘크립토키티’가 있습니다.

“ 없어…? 그럼 그냥 만들고말지 -_-”

지금 당장 원하는 사양의 토큰을 만들어도, 사실상 내 마음대로 설계하는것은

정해진 규격을 따르지 않았으므로
다른 사람들의 신뢰를 얻을 수 없습니다.

물론, 그 규격또한 ‘제언’을 통해 채택됩니다.
정말 필요하다면 EIP, IIP와 같은 제언창구에 제언해 봅시다.

수수료….??????

블록체인에서 사용자는, 사용자의 상태 변화를 일으키는 Transaction을 발생할 때 마다 트랜잭션 수수료를 물게됩니다.

수수료와 같은 정책또한 플랫폼에종속되는 속성중 하나입니다. 출처 : steemit / twinbraid

그리고 열일하는 Platform일 수록, 더 많고 빠른 변화가 일어납니다.

ICON은 DiD, FEE2.0과 같은 큰 변화가 5월에 있을 것 이라고 말했습니다.

이익의 분배와 참여의 가치에 중점을 두다.

많은(?) 단점이 있음에도 불구하고, 우리가 블록체인 DApp을 개발하는 이유는

사용자의 합의에 의해서 변경사항이 적용될 수 있기 때문이고, 표준 암호화 알고리즘과 Open된 Source를 통해 쌓인 신뢰를 바탕으로 소비자가 직접 DApp에 참여하고, 기여하여 더욱 진화 할 수 있기 때문입니다.

그리고, 기여로 인한 이익을 실제 기여자에게 분배할 수 있기 때문입니다.

토큰을 활용한 기술을 통해서 만들어진 이익을 실제 기여자에게 분배할 수 있기때문입니다.

그럼, 어떻게 이익을 분배하는데..?

실제 만들어진 DApp을 통해서 확인해 보겠습니다.

아래는 팬들이 덕질(?) 할 수 있도록 만들어진 STAYGE 라는 DApp입니다.

DApp중 하나인 STAYGE의 화면

이 화면만으로는 DApp인지 확인이 불가능합니다. 하지만, STAYGE의 지갑 탭에 들어가면 …

제가 팬이 된 가수의 이름으로된 Token이 발행된 것을 확인할 수 있고, 실제 ICON Tracker를 통해 다음과 같이 확인할 수 있습니다.

만들어진 지갑에 자동으로 들어와있는 토큰을 Tracker에서 확인할 수 있다.

만약, 제가 STAYGE DApp에서 팬활동을 하게 된다면, 이에따른 보상이 주어집니다.

덧글과 Like를 통한 ACT 토큰이 부여되는것을 알 수 있습니다.

--

--