블록체인 UX의 7대 죄악

Kain Seo

Published in

Clay

44 min readNov 7, 2018

Clay.one은 어떤 팀인가요? — 블록체인의 유저 난제들을 암호화폐 지갑을 통해 해결해나가려는 팀입니다. 근데 어떤 문제들이 있는지 잘 모르시죠?

원래는 성경에 나오는 7대 죄악 — 교만/질투/분노/나태/탐욕/식탐/색욕. 필자 포함 애니메이션 강철의 연금술사로 이를 배운 사람도 많다. ㅎㅎ

존칭을 생략하고, 편한 말투로 글을 전개하려 합니다. 양해를 부탁드립니다.

나는 Clay.one 이라는 팀의 서결(Kain)이다. 오랫동안 IT 서비스 Product Manager, 창업가로 일해왔고, 지금은 회사의 제품뿐만 아니라 비즈니스, 비전 등에 관한 전략을 짠다.

우리 팀에서 서비스하는 클레이(Clay)는, 암호화폐 멀티지갑이자 dApp 플랫폼을 지향한다. 간단하게 말하자면, 어떤 곳에(Where) 있는 암호화폐든지, 어떤 것이든(What) 하나의 플랫폼을 통해(One) 할 수 있게 하려고 한다.

이미 iOS/Android 모바일 앱을 출시하고, 이더리움, 온톨로지 등의 블록체인과 Binance, Bittrex, HitBTC 등의 거래소 지갑을 통합하여 제공하고 있다.

*참고 : 이 글에서는 엄밀한 구분 없이, 블록체인이나 암호화폐를 쓰는 모든 응용 서비스를 ‘블록체인 서비스’ 혹은 dApp 이라고 부르기로 한다.

누가 블록체인을 쓰는가?

수많은 사람들이 블록체인을 이야기하지만, 그 동기와 영감은 제각각이다. 모두가 내일의 ‘기술’, 그리고 ‘가격’에 대해 이야기하지만, 우리 팀은 지금 오늘 하루하루를 살며 일희일비하고 있다.

우리는 현재의 ‘사용자’에 대해 상상하고, 그들이 당장 블록체인 서비스를 어떻게 쓸지를 고심한다. 하지만 그런 이야기는 이 시장에 너무도 없는 것 같다. 마치 내년 쯤에 어떻게든 되리라, 하는 느낌으로 치부되게 마련이다.

대부분의 문제는 디자인에서 나오지만, 그걸 해결할 디자이너는 1%에 불과하다. / 출처 — 한국 이더리움 사용자 그룹, 정우현(Atomrigs)님

블록체인, 혹은 암호화폐가 대중화되기 위해서는 어떻게 되어야 할까? 인터넷의 초기와 비교해보자면, 블록체인은 TCP/IP 라든지 WWW와 같은 프로토콜, 그리고 암호화폐 지갑은 그안의 데이터를 사용자 친화적으로 표시해주는 웹 브라우저, 그리고 dApp들이 인터넷을 기반으로 한 다양한 웹 서비스, 앱들이라고 비유할 수 있다.

즉, 1) 데이터를 안정적이고 빠르게 통신할 수 있는 프로토콜과 네트워크 시스템 (→ 블록체인) , 2) 분산된 노드에 담긴 데이터들을 사용자 친화적으로 보여줄 수 있는 인터페이스 (→ 암호화폐 지갑), 3) 이를 바탕으로 사용자 니즈를 해결하여 가치를 창출하는 응용 서비스 (→ dApp) 모두가 준비되어야 한다.

한꺼번에 말이다.

블록체인 기술을 단지 Private Blockchain을 통해 B2B 정도의 용도로 쓸 생각이었다면 이렇게까지 누구나 기대하고 열광하는 업계가 만들어지지 않았을 것이다. 결국 블록체인과 암호화폐는 Mass Adoption을 이루어내야 하며, 그러기 위해서는 블록체인의 비직관성을 여러가지 방법으로 극복해내야 한다.

그렇다면 과연 지금 시장에 출시된 어떤 블록체인 서비스를 우리 할머니, 이제 막 입학한 문과 여대생, 10살짜리 사촌동생 등에게 쓰게 할 수 있는가? 그들이 서비스를 쓰기 위해서 이해해야 하는 개념은 얼마나 많은가? 얼마나 많은 시간이 소요되는가? (필자는 ‘비트코인’을 일반인에게 충분히 설명하는 시도를 참 많이 해왔다. 하지만 20분 이내로 성공한 적이 없었다)

비트코인과 그로부터 파생된 분산원장 블록체인은 분명 인류 역사상 유례없는 발명임이 분명하다. 최초로 중앙이 없이도 자발적으로 돌아가는 가치 저장/전달 시스템을 만들어낸 것이 아닌가. 하지만 블록체인 자체는 여러가지 이유로 (기술적인 효율 혹은 엔지니어의 무신경함?) 사용자에겐 굉장히 비직관적으로 설계되어있다.

필자는 블록체인의 비직관성을 ‘블록체인 UX의 7대 죄악’으로 이름붙이고 정리해보았다.

누군가 명시적인 잘못을 했다기 보다, 인간이 그러하듯 그냥 블록체인이 어쩌다가 이런 특성들을 내포하게 되었기 때문에, 그리고 우리는 이를 극복하기 위해 끊임없는 노력을 해야 하기에 이러한 네이밍이 적절하다고 생각했다.

UX가 핵심이다, 바보들아

블록체인 업계 사람들은 UX를 얕보고 있다. 기술만 있으면 유저 경험은 어떻게든 될 거라고 생각하는 것 같다. 물론 결국 어떻게든 될 것이다. 하지만 대부분의 팀들은 유저 경험 개발에 드는 시간과 노력 없이 대중화를 상상하고 약속한다. 아니, UX 문제들이 해결될 때 까지 꽤 오랜 시간과 많은 노력이 들 것이다. 적어도 기존의 블록체인 상에서 무언가를 하려는 모든 프로젝트들에 대해서는 말이다.

UX(유저 경험)은 우리가 생각하는 것보다 큰 기술장벽이기도 하고, 생각보다 큰 혁신을 가져다주기도 한다. 마우스의 발명, DOS와 Windows의 차이, 아이폰 이전의 스마트폰들과 아이폰 등을 생각해보자. 뭐 더 길게 이야기하진 않겠다.

이 글에서는 주로 블록체인이 왜 비직관적인지를, 짚고 이에 대한 대안들을 제시하고자 한다. 블록체인은 지금 브라우저 생기기 전의 인터넷같다. 한마디로 대중들이 쓰기엔… 도저히 봐줄만하지 않은 상태라는 것이다.

탈중앙화고 나발이고 아래 것들은 모두 UX적인 기술장벽들이고 대중화를 위해서는 꼭 넘어야 할 장애물들이다. 아예 허들을 치울 수 있는 것들도 있고 치울수 없기에 허들을 넘어달라고 열심히 빌어야 하는 것들도 있다.

키 관리 — 백업과 보관, 운영
자산 구매 — 구매 방법, 자산 환전
송금 경험 — 송금 주소, Gas 개념, 거래 시간, 지불-자산 변동성
토큰 관리 — 토큰 밸런스, 커스텀토큰 추가, 토큰/수수료 이원화, 스팸 토큰
플랫폼/프로토콜 파편화 — 자산 보관, 블록체인 개념, 서비스 사용, d앱 사용
탈중앙화 — vs 중앙화, 비직관성과 보안의 딜레마
규제 이슈 — KYC, dApp의 환급성, …

이 ‘7대 죄악’은 블록체인 서비스를 처음 접하는 유저가 ‘한꺼번에 모두’ 경험하고, 넘어야 하는 장애물들이다.

하나하나 풀어서 설명하려 하기에 긴 글이 될 것이다… 글 쓴 정성을 보아서라도 앱스토어에서 “클레이” 검색해서 다운로드 받아주세요. 제발.

1. 키 관리

블록체인 계정은 ID/PW 대신 Public Key / Private Key를 얼추 비슷하게 쓴다. 이 두가지 개념은 동치가 아니고 상당히 다른 개념이지만 굳이 비교하는 이유는 Use Case가 대충 비슷하고 그렇게라도 안하면 대중들에게 이 생소한 암호학 개념을 이해시킬 방도가 없기 때문이다.

Private Key를 통해 사용자는 블록체인 내의 계정을 가진다. 그 계정(혹은 ‘계좌’) 안에 암호화폐 자산들이 보관된다. Private Key는 패스워드 역할을 하기에 Public Key가 일종의 입금주소, ID처럼 기능한다.

Public Key와 Private Key를 사용자 구별에 쓰는 것은 아무래도 원래부터 디지털 화폐에 오랫동안 쓰이던, 안전하고 검증된 인증 방식이기 때문이었겠지만 이를 대중들에게 직접 쓰라고 들이미는 것은 전례미문이고 생소하다.

아래 후술할 단점들을 극복하기 위해서는 간단하게 중앙화 형태로 ID/PW를 발급하고 그 안에 Private Key를 넣어 관리하면 모두 해결되긴 한다. 하지만 중앙화는 선택하기 정말 쉽지 않기에 (6. 탈중앙화 — vs 중앙화 부분에서 더 자세히 서술한다) 보통 굳이 탈중앙화 형태의 지갑, 즉 유저 개개인에게 Private Key를 지급하는 형태를 쓰게 되고, 그럴 경우의 허들들을 논해보기로 한다.

1.1. 백업

꽤 많은 암호화폐 지갑이 그렇게 해왔기에, 정말 불편하지만 다들 하는 것이 백업이다.

요즘은 Private Key 대신 주로 Mnemonic 이라는 방식을 쓰는데, 이는 Private Key와 대응되는 12개의 Word 조합이다. 왜 이렇게 하는가? Private Key를 적는거보다는 훨씬 쉬우니까…

이런 식으로 정말 Cold하게 Mnemonic을 백업하여 보관하는 제품도 있다..

탈중앙화 지갑 서비스의 경우 사용자의 Private Key 데이터를 자신의 서버에 두지 않는 것이 목표이기에 (그랬다가 해킹당하거나 or 내부자가 탈취하면 안되니까 — 역시 자세한 것은 6. 탈중앙화 vs 중앙화 문단 참조) 이 데이터를 어떻게든 사용자에게 보관을 시켜야 한다.

해당 지갑 서비스들을 쓸 때에는 보통 해당 지갑이 있는 곳에 Private Key 데이터가 암호화되어 저장된다. MEW 웹 지갑을 쓰면 내 하드디스크에, Ledger 같은 하드웨어 지갑을 쓰면 해당 하드웨어에, Clay 같은 모바일 지갑을 쓰면 휴대폰의 저장소에 저장된다.

문제는 이 데이터가 물리적으로 소실되기 너무 쉽다는 것이다. 하드디스크에 저장된 키스토어 파일이 랜섬웨어에 걸린다면? Ledger 기기를 잃어버린다면? 폰을 잃어버리거나 모바일 앱을 지운다면? 속절없이 내 재산은 날아가버린다.

보통의 대안 : 12개의 Mnemonic Word를 백업하라고 한다. 꼭 종이나 다른 곳에 보관하라고, 스크린샷 기능을 막거나 하여 강하게 권하는 경우도 있다. (스크린샷을 찍으면 모바일 기기 분실 시 한꺼번에 다 잃어버리기 쉽다) 필자는 Private Key를 백업해둔 TXT를 암호화한 파일을 여러 곳에 분산 저장한다. (가끔은 1Password와 같은 서비스를 쓰기도 한다)
중앙화 : 그냥 회사의 서버에 DB를 구축하고 Private Key를 그 안에 담아서, 사용자에게는 ID/PW로 지갑에 접근하라고 하면 깔끔하다. 가장 큰 지갑인 Coinbase나 Blockchain.com 도 이런 방식을 취하고, 암호화폐 거래소들도 보통 이렇게 한다. 대신 어떻게 완전한 보안을 장담할 것인가는 문제이다. 암호화폐 Private Key는 탈취된 후에 대응할 수 있는게 아무것도 없다.

1.2. 보관

이제 Mnemonic / Private Key 를 어디에, 어떻게 보관해야 하는가?의 문제가 있다. 서비스에서 사용자의 잔고를 불러오고, 암호화폐를 받거나 보내려면 보관된 Private Key를 불러와야 하면서도, 여러가지 돌발상황에도 안전하게 잘 저장되어있어야 하는 것이다.

기기에 보관 : 대부분의 탈중앙화 서비스들은 Private Key를 유저가 설정한 비밀번호로 암호화한 파일을 (이를 Keystore라고 한다) 사용자 기기에 보관한다. 이 경우 서비스 공급자는 해킹 위협을 걱정하지 않고 안심하고 서비스를 제공할 수 있다. 서버가 해킹당할 경우 모든 유저의 모든 자산이 위험해지게 되는데, 사용자들의 기기에만 키를 보관하면 최악의 경우에도 개별 사용자의 자산만 위험해진다.
Keystore 이슈 : 그리고 이 경우 Keystore 를 어느 정도 엄격하게 암호화하여 구성할지도 하나의 이슈 중 하나이다. 어쨌든 완벽한 보안이란 것은 없기에 최악의 상황을 가정하자면, 사용자들의 Keystore 파일은 탈취되기 어렵지 않다. (특히 PC, 안드로이드 폰, 탈옥된 iOS 폰의 경우 그렇다) 이 경우 해커가 암호를 무차별 대입할 경우(Brute-Force Attack) Keystore는 쉽게 풀릴 수 있다.
보통의 중앙화된 서비스들은 틀린 암호를 많이 대입할 경우 제한시간을 두거나 아예 계정을 잠그지만… Keystore 파일은 그냥 무제한으로 암호 대입을 시도할 수 있다.
그런 면에서 정말 안전한 수준의 비밀번호는 영문-숫자-특수문자까지 섞인 11자 이상의 비밀번호이다. 하지만 이렇게 될 경우 굉장히 사용성이 떨어지게 된다. (매 Transaction 마다 — 특히 트랜잭션 생성이 잦은 dApp 의 경우 — 11자 이상의 복잡한 비밀번호를 넣는다면..)
모바일 지갑의 경우는 Keystore 파일을, 외부 접근이 불가능한 저장소 (Apple의 Secure Enclave) 등에 넣고, 암호는 4~6자의 PIN을 쓰고 얼굴/지문인식으로 대체 가능하도록 한다. 참고로 얼굴/지문 인식은 고정된 값을 모바일 OS 차원에서 내려주지 않기 때문에 암호화가 불가능하다고 한다.

Howsecureismypassword.net 에 가면 내 비밀번호가 얼마나 빨리 털릴 수 있는 지 보여준다. 이건 필자가 라이트한 용도로 자주 쓰는 8자리의 비밀번호… 1분이면 털린다.

전용 하드웨어에 보관 : 보통 ‘콜드 월렛’은 이를 지칭하는데, 이 경우 키 관리를 전문으로 하는 하드웨어(HSM — Hardware Security Machine) 안에 Private Key를 담도록 하고 이 하드웨어만이 해당 Private Key를 도출할 수 있도록 하는 방식이다.
B2C 제품의 경우 Ledger, Trezor같은 하드웨어 월렛이 이에 속한다. 이 경우 사용자는 절대 Private Key를 알 수 없게 되어있고, 오직 하드웨어 기기를 통해서만 암호화폐를 송금할 수 있게 된다.
지갑을 제공하는 많은 B2B 회사들도 이런 방식을 지원하곤 한다. 회사 내에 수억원의 거대한 HSM 장비를 갖추고, 이를 통해 멀티시그 방식의 지갑 서비스를 제공하거나 기관을 대상으로 한 Custody 서비스를 제공하는 등이다. (주로 거래소가 고객이 되겠다)

Xapo는 심지어 스위스의 벙커 안에 Bitcoin 금고를 보관하고 있다고 자랑한다.

서버에 보관 (중앙화) : 역시나 그냥 중앙화 하면 쉽다. 조금 세밀하게 분류해보자면, Keystore나 Private Key를 사용자마다 따로 지급하고 이를 서버에 저장하는 방식이 있고 (많은 dApp들의 자체 지갑 제공 시 이렇게 한다), 아니면 그냥 자신들이 가지고 있는 Private Key 계좌 안에 고객들의 자산을 저장하고 각 개개인의 자산은 장부상의 숫자로 기록하여 관리하는 방식이 있다. (보통 거래소 지갑이 이런 방식을 쓴다)
서버에 보관하는 것과 관련해서도, 서비스 제공자 서버에 직접 보관할지 / 외부 지갑 제공자를 사용할 지에 대한 결정 이슈가 있다. 물리적인 우리 서버와 HSM 장비를 쓸 지, AWS와 같은 클라우드 서버에 그냥 저장할 지, 그리고 BitGo와 같은 외부 지갑 제공업체의 솔루션을 쓸 지에 관한 것이다.
예를 들어 BitGo는 멀티시그 방식의 B2B 지갑 솔루션을 제공하여, BitGo — 운영업체 — 사용자 중 둘 이상이 동의해야만 송금을 할 수 있게 해준다. 즉 특정 사용자의 송금을 막아야 하는 경우, 운영 업체가 해킹을 당한 경우, 혹은 BitGo 자체가 해킹을 당한 경우의 자산 유출을 막는 것이다. 대신 BitGo 솔루션은 송금 자체가 수수료가 비싸고 (0.01ETH 이상), 지갑 자체를 모두 BitGo에 의지해야 하기에 확장성이 낮다고 볼 수 있다. 즉 블록체인 트랜잭션을 많이 생성해야 하는 dApp 플랫폼에는 적합하지 않고, 거래소에는 매우 적합하다.
운영 업체의 서버에 그냥 보관한다고 했을 때는 정말 안전한 것이 맞는지 점검해 보아야 한다. 해킹을 막을 여러가지 보안 솔루션들, 그리고 내부자가 고객의 돈을 의도하든 의도하지 않든 탈취할 수 없게 하는 관리적인 조치들이 필요하다. 사실 많은 거래소의 경우 경영진이 마음만 먹으면 고객의 자산을 빼갈 수 있는 구조로 되어있는 경우가 많다. (문제는 심지어 그렇게 횡령하고 거래소가 해킹당했다고 주장해도 정말 그런 지 알 수 있는 명확한 방법이 없다)
이런 것들은 전통 금융업체들이 잘 준수하는 편이다. 예를 들어 회사 컴퓨터를 망분리하거나 (외부에서 회사 내 실무자들의 컴퓨터 접속 불가, 회사 실무자들- 특히 개발자들 컴퓨터는 인트라넷으로만 연결 등) 민감한 데이터를 HSM을 통해 관리하거나 등등…
그럼에도 불구하고 전통 금융업체들, 예를 들어 은행의 경우 이런 리스크를 회피하기 위해 공인인증서를 사용한다. 중앙 권한이 모두 털려도, 고객들의 PC/폰에 보관된 인증서를 이용하지 않으면 침입자가 아무것도 할 수 없는 구조인 것이다. 중앙화-탈중앙화의 하이브리드 방식이라고 평해볼 수 있겠다. (한편 아무리 은행처럼 철통같이 보안을 신경써도 리스크가 항상 있다고 생각해볼 수 있겠다.)

어쨌든 우리는 사용자의 Private Key 데이터 혹은 암호화폐 자산을, 1) 해커로부터의 위협에서 보호하고 2) 사용자의 부주의로 소실되지 않고 3) 서비스에서 사용하기 편하게 관리해야만 한다.

사용자의 부주의에 대해 조금 더 언급하자면, 사용자의 기기가 랜섬웨어나 바이러스에 걸리는 경우, 폰을 분실하거나, 집안에 화재가 나는 경우 (이러면 종이에 적어서 백업했던 것도 ‘소각’되어 버린다...), 비밀번호를 분실하는 경우 (OTP 분실 포함) 등이 있겠다.

서비스 사용성이란, 사용자가 자신의 암호화폐 자산을 가지고 블록체인 서비스에서 뭔가 하기 위해 어떤 것들을 입력해야 하느냐에 대한 이슈다. ID/PW만 입력하면 내 자산 잔고를 볼 수 있고 송금을 할 수 있는지, 그밖에 PIN 번호 (지문/얼굴 인증), OTP, 입/출금 제한, 이메일 인증, SMS 인증 등 어디까지 해야 하는지… 에 대한 것들이다. 서비스 운영업체의 보안 정책에 의해 부여되는 사용자 의무들이지만, 이게 과하다면 서비스 UX에 큰 영향을 미친다.

예를 들어 게임 dApp 에서 매 트랜잭션마다 블록체인에 올린다면, 사용자들에게 내 캐릭터가 한발짝 움직일 때 마다, 아이템 하나를 옮길 때 마다 비밀번호를 입력하라고 할 것인가? 에 대해 생각해보자. (EOSKnight 를 한번 써보길 권한다.)

가장 이상적인 저장소, 보관 방식이란 무엇일까? 이건 아직 결론이 나지 않은 문제인 듯 하다. 단순히 거래소 비즈니스를 한다면 그만큼의 고객 보유 자산에 대해 책임을 지면 되지만, dApp과 지갑이 계속 커진다면 암호화폐 지갑은 정말 많은 고객의 자산과 계정을 보관하게 된다. 그리고 한 번이라도 시스템 취약성이 있다면 돌이킬 수 없는 큰 문제가 발생한다. 어려운 문제다.

1.3. 운영

서비스를 사용하는 사용자가 자신의 키를 분실하거나 도난당했을 경우, 탈중앙화된 입장에서 해줄 수 있는게 없다고 해도 결과적으로 CS 문의는 들어오게 된다. 사용자 입장에서는 이 서비스를 쓰느라 내 돈이 날아갔으니, 책임질 수 있는 곳이 책임져주길 원하는데… 나름 절박한 심정으로 뭐라도 하려고 할 것이다.

한번은 아는 친구가 ICO를 들어가려다가 누가 자신의 노트북을 써서 Private Key를 훔친 사실을 알았다면서, 쓰던 지갑인 MyEtherWallet 에 연락해서 계좌를 정지해달라고 하면 되냐고 필자에게 물어왔다. 하…

(MyEtherWallet은 블록체인 내의 장부를 정리해서 보여줄 뿐, 그 이상 아무것도 하지 못한다…)

MyEtherWallet 에 들어가면 항상 뜨는 화면. 해줄게 없다면 미리 경고라도 해야 하나?

탈중앙화 서비스에서는 CS가 들어와도 해줄 것이 별로 없다. 단지 안내만 해줄 수 있을 뿐… 그리고 욕만 먹을 뿐…
중앙화 서비스의 경우 ID/PW 분실 이슈 등은 당연히 쉽게 해결해줄 수 있다. 그리고 어떻게 보면 개인의 보관 소홀에 대한 리스크가 별로 없으므로 이런 부분에 대해서는 더 안전하다고 생각해볼 수 있겠다. (물론 보안 차원에서는 절대 그렇다고 볼수 없다 — 6. 탈중앙화 부분에서 서술)

2. 자산 구매

대부분의 블록체인 응용 서비스를 쓰기 위해서는, 일단 암호화폐 자산을 구매해야 한다. 예를 들어 Binance를 사용하려면, 일단 국내 거래소에서 비트코인이나 이더리움 등을 구매하고 보낸 후 이용할 수 있다. 최근 이슈가 되었던 Dogeworker (폰지사기 주의) 를 쓰려면, Dogecoin이 상장된 해외 거래소를 찾아서 Dogecoin을 먼저 구매한 후 해당 사이트에 보내야 한다.

대부분의 국가에서 암호화폐와 법정화폐 간 교환이 쉽지 않다. 미국에서는 각 주에서 허가를 받아야만 USD로 암호화폐를 매매할 수 있고 (Coinbase, Kraken 등), 중국은 아예 불법으로 규정되어있어 대부분의 거래소는 OTC (개인 간 물물교환 — 쉽게 말해 중고나라 거래하듯 개인 간에 거래)을 통해 암호화폐를 취득하도록 유도한다. 국내에서는 빗썸, 업비트, 코인원, 코빗만이 은행과 공식적으로 협업하여 가상실명계좌 입금을 제공하고, 나머지 거래소들은 속칭 ‘벌집계좌’ 라고 불리는 법인계좌를 통한 입금을 통해 법정화폐 — 암호화폐 간 매매를 제공하고 있다.

2.1. 오더북/차트 이용

즉 일단 여러분의 블록체인 서비스를 쓰기 위해서, 사용자에게

빗썸, 업비트, 코인원, 코빗 등의 거래소에 이렇게 이렇게 가입하고, KYC를 마친 후에, 오더북에서 거래해서, 이 주소로 보내세요

라고 말해야 한다. 그리고 대부분의 거래소는 ‘환전소’가 아니라 ‘(주식) 거래소’의 형태로, 오더북을 기반으로 한 거래만을 지원하고 있다. 필자도 블록체인 업계 입문 전 주식 트레이딩 경험이 없어, 오더북과 차트를 볼 줄 몰랐던 것을 감안하면… 이 부분도 쉽지 않은 허들이다.

단지 여러분의 서비스를 쓰기 위해 사용자에게 거래소 가입과 계좌등록, KYC, 오더북에 오더를 올리고 (필요하다면 차트와 스프레드까지 이해시키고), 암호화폐 송금까지 다시 한번 시켜야 한다. (3.에서 서술할 어려운 송금 경험도 당연히 자동으로 포함된다)

2.2. 자산 환전

조금 마이너한 이야기일 수도 있겠으나, 여러분의 서비스가 사용하는 토큰이 있고 이 토큰이 법정화폐로 거래할 수 있는 거래소에 상장되어있지 않다면 (대부분 그러할 것이다), 다시 한번 어디에선가 이를 환전해와야 한다.

그러면 “업비트에서 이더리움을 사고, XX거래소에서 AA코인으로 바꾼 후 BBB주소로 입금하세요” 라고 해야 한다.

암호화폐 자산 간 환전 서비스는 Shapeshift나 Kyber Network 같은 프로젝트에서 제공하고 있다. 예를 들어 이더리움만 있어도 Kyber Network의 API를 쓰면 손쉽게 바로 환전이 가능할 것이다. (대신 Kyber Network 에 당신의 토큰이 상장되어있어야 할 것이다)

대안

대체 이 단계까지 남아있을 사용자가 얼마나 될 것인가? 여러분의 블록체인 서비스는 그만큼의 베네핏을 줄 수 있는가? ㅠㅠ (현실세계에서 이 정도 허들이면 그 어떤 서비스를 제공해도 남아있을 사용자가 하나도 없다)

이런 문제들에 대한 대안은 간단하다.

규제 이슈 : 규제가 풀려서 누구나 손쉽게 법정화폐를 통해 암호화폐를 매매할 수 있도록 선행되어야 한다. 이는 7. 규제 이슈에서 좀 더 자세히 다루겠다.
상장 포기: 여러분의 코인이 꼭 거래소에서 상장되고 거래되어야만 하는가? 이를 포기하면 그냥 이더리움으로 서비스를 제공하거나, 그 이더리움 혹은 유틸리티 토큰을 운영 주체가 직접 판매하거나 사들이는 방법이 있다. (마치 게임머니를 결제하듯이)
대신 토큰을 현금으로 파는 건 몰라도 환급해주는 것은 고려해볼 이슈가 많다. 게임사에서 게임 머니를 현금으로 바꿔주지 않는 이유를 생각해보면 좋겠다.
지갑/결제 서비스 출현 : 규제가 풀리고 은행 입금이 자유로워진다면, 거래소 이외에 암호화폐 매매/결제를 지원하는 수많은 사업자들이 나올 수 있다. 블록체인 응용 서비스를 사용하려면 이런 사업자들이 등장하여, 사용자와 dApp 간의 거리를 좁혀주어야 한다.

막간 홍보를 다시 한번 하자면… Clay에서는 Kyber Network를 탑재하여 이더리움과 ERC-20 토큰들의 환전을 가장 쉽게 할 수 있도록 지원하고 있다. 여기서 한 발짝 더 나아간다면, 애초에 송금할 때에 환전이 동시에 일어나도록 인터페이스를 제공할 수도 있을 것이다.

3. 송금 경험

암호화폐 자산의 송금 경험은 한 마디로 말해서 거지같다. ‘송금’ 이라고 떠올렸을 때 기본적으로 당연하다고 생각하는 모든 것들이 다르다고 봐도 좋다. 뭔가 돈이 전송된다라는 기본적인 개념만 빼고 말이다.

*물론 국제송금은 그것보다 10000000배 더 상거지같으니 암호화폐를 이용한 송금 서비스가 이쪽에서 화두가 되는 건 당연한 일이다. (국내 은행에서 브라질 은행에 100만원 보내는데 드는 수수료가 44만원이라나… / SWIFT 코드와 IBAN 코드)

이런 것들을… 블록체인과 탈중앙화의 감수성이라고 치부하고 이해하고 받아들여야 하는 것인지는 모르겠다. 하지만 분명한 건, 일반 사용자 입장에서는 겁나 비직관적이라는 사실이다.

3.1. 송금 주소

블록체인은 Public Key를 일종의 계좌번호처럼 사용한다. 이는 보통 이렇게 생겼다

비트코인 : 17A16QmavnUfCW11DAApiJxp7ARnxN5pGX
이더리움 : 0x5e8b33ebd72c7d9f32020174f5e827d796a16b43 (ENS라는 도메인 시스템이 있지만 아무도 안쓰니 무시하자. 구리다.)
이오스 : eosyskoreabp (이오스는 블록체인 중 거의 유일하게 사용자가 정할 수 있는 문자열을 계좌주소로 이용한다. 그나마 낫다.)

누가봐도 자명한 문제들이 있다. 1) 일단 외우기 힘들고 2) 입력하기 힘들다. 그래서 이런 주소를 통해 송금해보았다면… 내가 입력한 주소가 맞는지 마음졸였던 경험이 한 번쯤 있을 것이다. 실제로 이를 이용해 복사-붙여넣기할 때 비슷한 주소로 클립보드를 바꿔치기해서 자산을 갈취한 바이러스 사례도 있었다. (돈을 쉽게/안전하게 벌 수 있다보니 별별 바이러스가 다 만들어진다)

심지어 이오스를 비롯해서, 리플/스텔라 등은 주소 말고 ‘메모’라는 것을 또 받는다. 많은 거래소들은 이를 통해, 내 계좌로 들어온 돈이 누구 돈인지를 판별해낸다. 하지만 이 생소한 개념때문에 또 많은 유저들이 메모를 적지 않고 송금하여, 수많은 CS를 생산해내기도 한다.

그리고 또 하나의 큰 문제가, ‘이 주소가 누구의 것인지’ 판별하기 어렵다는 것이다. 우리가 은행에서 입금을 하면 예금주 정보가 뜨고, 이름을 한번 더 확인하게 된다. 하지만 블록체인 계좌는 단지 Public / Private Key만 있을 뿐이기에, 소유자와 관련된 정보가 연결되어있지 않다. 이 익명성이 또 하나의 불편함을 만들곤 한다.

주소들과 소유자 정보에 대한 DB를 구성하는 방법이 있다. 크게 본다면 일종의 DNS 처럼 오픈하여 관리할 수도 있겠고, 그냥 우리 유저들 간의 트랜잭션을 위해서만 운영할 수도 있다. 대부분의 경우 이 DB는 운영 주체의 서버에만 기록되기에, 서비스 간 호환성은 기대하기 힘들다.
어쨌든 이런 DB를 사용하면 Facebook / Kakao 등의 SSO 아이디, 전화번호부 등을 통한 암호화폐 송금이 가능해진다. 물론 같은 회원끼리만 가능할 테니… 이는 마치 메신저처럼 Networking Effect가 요구되는 부분이다. 회원이 많으면 많을수록 강력하고 그렇지 않다면 약하다.
우리 Clay의 경우 Sentinel Protocol 과의 협업을 통해, Whitelist (검증된 사업자들)와 Blacklist (해커, 사기꾼들)를 관리하여 송금 전에 표시해주는 솔루션을 개발 중에 있다. (관련 기사)

3.2. Gas 개념

대부분의 블록체인에는 Gas라는 것이 있다. 트랜잭션을 위해 네트워크에 지불하는 사용료이자, 네트워크를 유지하는 노드들의 보상으로 쓰인다.

Gas는 은행이나 여타 서비스들에서 으레 지불하는 수수료와는 조금 다른 것이, 일단 가격이 고정되어있지 않다. 예를 들어 하나의 트랜잭션에 대해서도, 단순 ETH를 보내는 것인지 토큰을 보내는 것인지, 혹은 스마트 컨트랙트를 만드는 것인지에 따라 수수료가 천차만별로 달라진다.

따라서 유저 입장에서 ‘왜 이렇게 수수료가 많이 드냐’ 라고 당황하게 되는 포인트가 있을 수 있다. 또한, dApp에서 트랜잭션을 만들 때에도 Gas와 Gas Limit를 어느 정도로 책정할 지에 대해서 결정해야 한다.

Gas를 너무 낮게 책정하면 만든 Transaction 이 처리가 안될 수 있고, 너무 높게 책정하면 유저 입장에서 너무 비싼 이용료를 내게 된다. 또한 근본적으로 dApp에서는 모든 블록체인 트랜잭션에 대해서 Gas를 사용자에게 부과해야 하기에, 주요 트랜잭션을 모두 블록체인에 올릴 경우 사용자가 말도 안되는 양의 수수료를 모두 지불해야 한다. (게임 캐릭터가 한발짝 움직일 때 마다 100원씩 지불해야 한다고 상상해보자..)

Gas를 얼마나 책정해야 할 지에 대한 몇몇 솔루션이 있어, (주로 블록체인 익스플로러에서 제공하는 추천 수수료 금액이 있다 — 예를 들어 ethgasstation 등) 참조하여 불러오곤 한다. 하지만 가끔 이 서비스가 다운될 때가 있다… 그러면 Gas 책정을 못해서 트랜잭션을 못 만드는 어처구니없는 경우가 있다.

3.3. 거래 시간

블록체인은 거래가 완료되는데 시간이 많이 걸린다. 비트코인이 대략 하나의 블록이 생성되는데 10분이 걸리고, 이더리움은 15초 정도, 이오스나 온톨로지 등은 1~2초 정도 걸린다. 내 트랜잭션이 다음 블록에 담길지 아닐지는 모르지만, 어쨌든 비트코인이나 이더리움은 분 단위의 거래 완료시간이 걸린다고 보아야 한다.

일단 dApp들의 경우 매 트랜잭션마다 이런 시간이 걸린다는 것 자체로 큰 허들이 되곤 한다. 그래서 사이드체인을 구성하거나, EOS 처럼 TPS가 높은 블록체인을 쓰게 된다.

앞서 말한 거래소 사용까지 유도해야 하는 경우, 거래소가 입/출금을 운영 인력이 확인해야 하는 시간과 입금 후 기본적으로 요구하는 Block Confirmation (보통 15~30 개의 블록이 지날 것을 요구한다)까지 고려하면 한번의 트랜잭션마다 1시간 이상이 걸릴 때도 많다.

3.4. 지불 — 자산 변동성

블록체인 바깥의 문제이지만… 많은 블록체인 서비스들이 암호화폐를 유저 보상을 위해 사용한다. 그리고 많은 암호화폐 (사실상 대부분)는 거래소에 상장이 되어있다.

이 때문에, 예전에 약속했던 보상의 가치가 변동되어있거나, 혹은 지불/결제해야 할 것들이 자산 변동으로 인해 한 쪽의 예기치않은 이득/손해로 잡히는 경우들이 있다.

예를 들어 음식 값을 암호화폐로 내는 서비스가 있는데, 10코인이 2만원이었는데 하루 사이에 1만원 가치로 떨어져서, 상점에 주기로 약속한 가치를 줄 수 없거나 결제 업체에서 손해를 보는 케이스이다. 암호화폐를 기반으로한 해외 송금서비스들도 모두 이런 리스크가 있다.

리스크를 줄이는 하나의 방법으로는 보유하는 암호화폐만큼의 암호화폐 선물을 BitMEX 등에서 사서 Hedge하는 방법이 있다. (참조)

현실세계 경제와 연동된 블록체인 프로젝트들은 때문에 자신들이 사용하는 토큰이나 화폐의 변동성까지 신경쓰거나 관리해야 하는 경우가 많다. 사용자 입장에서도 이는 생경한 경험이다.

3.5. 공개된 트랜잭션

대부분의 블록체인에서 모든 트랜잭션은 모두에게 공개되어있다. 물론 모든 트랜잭션이 공개되어있다는 것이 탈중앙화의 이념이기도 하지만, 기존의 송금 경험을 떠올려볼 때 이는 분명 익숙하지 않은 경험이다.

예를 들어 나는 어떤 이더리움 주소를 단순히 암호화폐를 관리하기 위해 사용하고 있었고, 중앙화된 서비스에 넣어서 dApp을 쓰고 있었다. 그리고 또 아무 생각없이, 이더리움 도박 서비스를 내 주소를 이용하여 사용했다.
당국이 해당 중앙화된 서비스의 DB 접근 권한을 가지고 있다면, 도박 서비스를 이용한 유저가 나라고 특정할 수 있을 것이다. 모든 트랜잭션이 공개되기 때문에 이더리움 서비스의 익명성에 대해 착각한 것이다.

이처럼 모든 트랜잭션이 공개되어있기에 생기는 불편함들이 분명 있고, 모든 정보가 공개된다고 다 좋은 것은 아니고 모두가 탈중앙화 이념을 따르고 싶은 것은 아니기에, 여기서 생기는 불편함들은 dApp들이 대중화될 수록 더 많은 이슈를 불러올 것이 분명하다. (남편의 이더리움 주소를 아내가 알고 있다면..?)

대안

사이드체인 : 많은 dApp들은 사이드체인을 구성하여 이 문제를 해결하곤 한다. ETH 수수료를 일일이 내지 않는 자신들의 체인에 트랜잭션들을 올리고, 이를 모아서 이더리움 블록체인에 연결하는 식이다. 국내에서는 탈중앙화 거래소 Allbit 가 대표적이다. (하지만 기술적으로 쉽지 않고, ‘탈중앙화가 맞냐’ 하는 논란에 휘말리곤 한다)
중앙화 vs 덜중앙화 vs 탈중앙화? : 어쨌든 얼마나 우리 서비스를 Off-chain / On-chain 할지에 대한 결정은 내리기 정말 어려운 편이다. 많은 서비스들은 마치 거래소처럼, 실제 고객의 돈이 서비스 안팎으로 이동할 때에만 On-chain 입출금을 지원하고, 나머지 트랜잭션은 자신들의 서버에서 그냥 처리해버리곤 한다. 하지만 이런 앱은 ‘탈중앙화 서비스’라고 엄밀히 보기 힘들기도 하고, 앞서 이야기한 보관의 이슈를 엄밀하게 해결해주지 못한다.
EOS : 여러가지 이유로 논란이 많지만 이오스는 분명히 가장 사용자 직관적으로 설계된 블록체인임에는 분명하다. 사용자가 낼 수수료도 없고, 주소도 id 형식으로 되어있다. 아직 많이 쓰이진 않지만 블록체인 자체에 Identity 기능도 있는 것으로 알고 있다. 하지만 이오스 지갑을 만드는 데 이오스가 소요되고 CPU/NET/RAM 자원을 스테이킹/구매해야 하는 점 등이 결국 또 다른 장애물이 생길 뿐이라는 생각이다.

4. 토큰 관리

‘화폐’의 목적으로 개발된 비트코인, 대쉬, 모네로, … 등을 제외하면 대부분의 플랫폼은 ‘토큰’이 존재한다. 예를 들어 ERC-20 토큰은 누구나 만들 수 있는 ‘이더리움’ 같은 암호화폐이다.

이더리움은 누구나 자신의 토큰을 쉽게 발행하고, 유통할 수 있게 만들었고 이를 통해 수많은 프로젝트들이 토큰을 발행하고 ICO를 하고 거래소에 상장하고 Utility Token 으로서 쓰임새를 만들어나가고 있다.

사용자 입장에서는 ETH를 쓰나 토큰을 쓰나 서비스에서 쓰이는 일종의 포인트라고 생각하겠지만, 여기에도 존재하는 장애물들은 있다. 앞서 2.2. 에서 자산 구매/환전에 대해 이미 서술했고, 여기서는 서비스 제공 차원에서 마주할 기술적인 부분을 좀 더 이야기하겠다.

4.1. 토큰 자산 확인

‘내 계좌에 어떤 토큰들이 얼마가 있어?’ 하는 질문(Query)은, 사실 별로 어려워보이지 않는 질문이다. 이를 위해서는 기술적으로 1) 어떤 토큰이 있는가 2)그 토큰이 얼마나 있는가

를 질문해야 한다. 문제는 블록체인이라는 분산원장은 인덱싱이 전혀 안 된 DB라는 것이다.

뭔가 이럴 거 같은데 실제로는 이렇게 되어있다. (토큰은 스마트 컨트랙트 상의 소스 코드이기에 실제로는 더 복잡하고 비효율적이다)

이더리움의 총 트랜잭션은 3.3억개이다. 그러면 내 계좌의 이더리움, 토큰 자산을 모두 알려면 이 3.3억개의 트랜잭션에 대해 수천개의 모든 토큰에 대해서 해당하는 것이 있는지 없는지 다 뒤져야 하는 식인 것이다. (주로 비개발자를 위한 글이므로 엄밀하지 않게 설명하는 것을 양해해주길 바란다)

그렇기 때문에 대표적으로 마이이더월렛에서는, 원하는 토큰의 자산이 얼마나 되는지를 하나하나 클릭해서 확인하도록 하고 있다. (토큰 종류가 너무 많으므로 모든 토큰에 대해서 미리 다 검색한다면 너무 느리기 때문이다) 그렇기 때문에 사용자는 특정 토큰을 내가 얼마나 가지고 있는지 보려면 수천개의 토큰 안에서 이를 찾아서 클릭해야만 한다.

물론 대부분의 블록체인 서비스는 꼭 계좌 안의 모든 암호화폐를 보여주어야 하는 것은 아니다. 하지만 암호화폐 지갑같은 몇몇 서비스의 경우 이런 이슈가 있고, 해결책이 그리 간단하지 않다.

가장 쉬운 것은 지속적으로 인덱싱하여 중앙DB에 블록체인 장부를 정리하여 저장하는 서비스를 직접 구축하거나, 그런 일을 하는 회사에서 정보를 가져오는 것이다.
이런 서비스를 직접 구축하는 것은 상당히 큰 공수가 따르므로, 대부분 하지 않는다. 필자가 알기로는 중국의 암호화폐 지갑 업체 Imtoken 정도가 직접 하고 있다고 알고 있다.
대부분의 지갑은 그냥 자신들이 선호하는 토큰들의 목록에 대해서만 자산 정보를 제공한다. 그중 일부의 지갑만이 또한 커스텀 토큰 추가 기능을 가지고 있다. (아래 4.2. 커스텀 토큰 추가 부분을 참고)
Etherscan, Ethplorer, Infura 등이 이런 정보를 서드파티 개발사에 제공한다. 하지만 이는 이더리움 블록체인에 국한되고 있고, 이런 회사의 서버가 다운된다면 해당 서드파티 입장에서도 안정적인 서비스 제공이 쉽지 않게 된다. 또한 앞으로 이런 정보들은 유료화될 것이다.
비슷한 이유로, 특정 코인/토큰의 입출금이나 트랜잭션에 대한 푸시 알림을 사용자에게 제공하는 것도 그리 쉽고 안정적인 일이 아니다.

Clay의 경우에는 여러가지 곳에서 정보를 받아와서, 어떤 토큰을 얼마나 가지고 있는지, 실시간으로 반영하여 쉽게 제공하고 있다. 푸시 알림도 잘 온다.

4.2. 커스텀 토큰 추가

대부분의 지갑에서는 이를 목록에서 선택하도록 하고, 목록에 없는 토큰은 커스텀 토큰을 추가하도록 유도한다.

여기서 생기는 또 하나의 문제 중 하나가 ‘커스텀 토큰 추가’ 라는 UX이다. 자체 토큰을 사용하지만 그 토큰이 유명하지 않은 많은 dApp 개발사들은, 사용자의 지갑에서 해당 토큰을 지원하지 않는다면 유저들이 그 토큰을 지갑에서 관리할 수 없게 된다.

자신의 토큰이 있는 프로젝트의 경우 토큰을 Etherscan 등의 유명한 블록체인 익스플로러에 등록해두는 것이 중요하다. 많은 지갑 서비스들이 이런 곳에서 정보를 받아오기 때문이다.
그밖에... 아주 많은 유저들이 사용하는 지갑 서비스에 본인들의 토큰이 잘 뜨는지 체크해보는 것이 필요할 수도 있다. (커스텀 토큰 추가 기능을 지원하지 않는 지갑들도 꽤 많다.)

4.3. 송금 수수료 이원화

사실 가장 심각하고 큰 문제는 이것이다. 대부분의 케이스에서 서비스에서 쓰이는 토큰과 블록체인에 수수료로 지불하는 코인은 이원화되어있다는 것이다.

예를 들어 KAINGAME 이라는 내 게임 dApp에서 KAIN 이라는 토큰을 쓴다고 하자. 나는 페북에 광고를 냈고 유저는 내 dApp을 쓰기 시작했다. 게임을 열심히 해서 나는 KAIN 이라는 토큰을 벌었다. (게임을 하기 위해서 KAIN 을 처음에 사야 하진 않았다) 그런데… KAIN 을 출금하려면 나는 내 지갑에 수수료로 쓰일 ETH를 넣어두어야 한다.

수수료가 있다는 것 자체도 받아들이기 힘든데, 심지어 서비스에서 쓰이는 토큰이 아닌 다른 암호화폐를 수수료 내는 용도로 가지고 있어야 한다.

그러면 어떻게 해야할까?

중앙화 : 이런 차원에서는 차라리 거래소 지갑이 명쾌하다. KAIN을 출금할 때는 KAIN을 수수료로 내기 때문이다. 물론 이는 완전히 중앙화된 관리 체계를 가지고 있기에 가능한 일이다. Cosmee나 몇몇 에어드랍 서비스와 같은 꽤나 많은 서비스들이 이런 식으로 서비스를 구성한다. 암호화폐 자산은 서버 내 DB에 자체 장부로 관리하고, 입출금 할 때에만 토큰을 운영 주체가 처리하는 방식이다. (그래서 필자는 가끔 이런 것을 ‘덜중앙화’ 서비스라고 일컫기도 한다.)
사이드체인 혹은 자체 블록체인 : 그래서 몇몇 팀들은 사이드체인을 구성하거나 자체 블록체인을 만들기도 한다. 하지만 대부분의 개발자들에게는 엄두가 나지 않는 일이다.
EOS : 이오스는 수수료가 없기 때문에 이런 문제에서 (일단은) 자유롭다.

4.4. 토큰 정체성

지금은 크게 이슈가 되진 않는 이슈이다. 하지만 종종 이슈가 될 수 있다고 생각한다.

토큰은 저마다의 심볼을 가지고 있다. 예를 들어 ETH, KNC, EOS, … 이런 식이다. 하지만 누구나 토큰을 발행할 수 있기 때문에, 겹치는 심볼의 토큰은 얼마든지 나올 수 있다.

예를 들어, 내가 토큰을 직거래를 통해 구매하기로 했는데, 판매자가 똑같은 심볼의 다른 KNC를 보낸다면? 앞서 이야기했던 예에서, 암호화폐로 된 게임 머니를 거래하는데 판매자가 발행한 허위 게임 머니를 받게될 가능성이 있다.

우리 프로젝트에서는 이런 이슈가 문제되진 않을까? 점검해볼 필요가 있다. 실제로 Newdex 라는 EOS 기반 탈중앙화 거래소에서는, ‘EOS’ 라는 심볼을 가진 허위 토큰이 잘못 거래되어 고객에게 손해를 끼쳤던 일이 있다. (관련 공지)

5. 블록체인 플랫폼 파편화

가장 대표적인 플랫폼인 이더리움과 EOS 뿐만 아니라, 이미 유명한 Tron, Ontology, ICON, Aelf, Zilliqa, Waves, 그리고 국내에서도 카카오의 클레이튼, 라인의 LINK, TTC, …등 수많은 플랫폼이 또한 출시되었거나 출시를 준비중에 있다.

유저 입장에서는 플랫폼이 많으면 좋은가? 그럴 수도 있겠지만 대부분의 경우 그렇지 않겠다. 암호화폐라는 것도 생경한데 내가 쓰는 서비스에 따라서 암호화폐 자산들의 속성이 다 달라지는 것이다.

이 dApp을 쓰면 여기 포인트는 이런 속성이 있고, 이 dApp을 쓰면 여기 포인트는 이런 속성이 있다… 를 따로따로 이해해야 한다. 이 또한 재앙이 아니고 무엇일까.. 비유하자면 해피포인트와 CJONE 포인트가 완전히 다른 UX를 가지게 되고 이를 사용자가 굳이 이해해야 하는 식이다. (필자는 스팀잇 Steemit을 예전부터 알았지만 아직도 스팀-스팀달러-스팀파워 등의 구조에 대해서 명확히 설명하지 못한다. 솔직히 이해하고 싶지도 않다.)

5.1. 자산 보관의 파편화

사용자 입장에서, dApp A와 B와 C를 쓴다고 가정해보자. A에서 A토큰, B에서 B토큰, C에서 C토큰을 받았다. 그리고 대부분의 경우 토큰들은 환급성을 가지기 때문에, 사용자는 하나의 어떤 서비스에서 이런 토큰들을 관리하거나 소유하거나 원할 때 마다 환전하고 싶을 것이다.

보통 이러한 역할을 하는 것이 암호화폐 지갑이다. (물론 거래소 이기도 하지만 필자는 dApp이 활성화되면 될수록 지금 모습의 ‘거래소’는 단지 시세를 결정하는 역할만 제한적으로 할 것이라 생각한다.) 적어도 각 dApp에서 얻은 토큰을 환전하기 위해서라도, dApp 외부의 지갑/거래소를 사용해야 하고 엔간하면 그 지갑/거래소가 하나이길 바랄 것이다.

그런데 거래소가 그러하듯, 암호화폐 지갑이 모든 블록체인과 토큰을 지원할 수가 없다. 그러면 사용자는 “A는 이더리움 기반이니까 Clay를 쓰고, B는 네오 기반이니까 일단 업비트로 보내고, C는 Waves 기반이네.. 어디로 보내야하지..” 이런 생각을 해내야만 한다.

그리고 서비스를 만드는 입장에서는, 토큰을 발행할 것이라면 무조건 거래소/지갑에서 많이 쓰는 블록체인 기반 토큰을 발행할 수 밖에 없게 된다. 그래서 대부분 dApp의 토큰은 이더리움의 ERC-20 토큰 기반으로 되어있다. 심지어 서비스는 다른 블록체인을 써서 굴러가더라도 말이다. 다른 블록체인 토큰으로 만들어진 대부분의 프로젝트는 대형 거래소 상장이 거의 불가능한 수준이다.
Clay는 현재 이더리움과 온톨로지 블록체인을 지원하고, 곧 EOS와 비트코인 블록체인 정도를 지원하려 하고 있다. 하지만 결국 모든 블록체인을 커버하는 것이 사실상 불가능하다는 것을 알고, 주요 거래소들의 지갑을 API Key를 통해 연결할 수 있도록 지원하고 있다. 현재 Bittrex, Binance, HitBTC 지갑을 추가하여 하나의 서비스에서 편하게 입/출금, 트레이딩까지 할 수 있고, 곧 Upbit, Huobi 와 몇 개 거래소가 더 추가된다.
이걸 조금이라도 해결해줄 것이라 기대했던 것이 Cosmos, Polkadot 등의 Interchain 솔루션이지만, 대체 언제 나오는지도 모르겠다.

5.2. 블록체인 개념의 파편화

여태껏 언급한 블록체인 UX들은, 숨기면 숨길수록 사용자 친화적이고 좋겠지만 현실적으로 그럴 수가 없다. Public Key (송금주소), Gas, Transaction, Smart Contract… 등의 개념들은 결국 서비스에 어떤 식으로든 노출될 수 밖에 없는 것이다.

그러면 사용자들은 A라는 dApp을 사용하기 위해 a블록체인에서의 개념을 어찌어찌 숙지했는데, b블록체인 기반의 B라는 dApp에서는 그 개념들이 또 다르게 쓰이기 때문에 다시 혼란을 겪게 된다.

예를 들어보면

이더리움은 Gas를 ETH로 사용자가 지불한다. 이더리움 기반의 서비스는 사용자가 이더리움을 구해서 사용해야 한다. 트랜잭션들을 일으키다가 ETH가 부족해지면 더 구해와야 한다.
이오스는 수수료가 없다. 대신 지갑 생성 과정에서 EOS가 필요하고, 이를 CPU, NET, RAM 등의 자원에 할당해야 한다. 아무 생각 없이 dApp을 쓰다가는 CPU 등의 자원이 부족해서 더 이상 dApp을 못 쓰게된다.
온톨로지는 수수료를 ONG로 지불한다. 메인 코인인 ONT를 가지고 있으면 ONG가 자동으로 생성되지만, 생성된 ONG를 Claim 하는데에도 ONG가 필요해서 결국 사용자는 ONG를 어디서 구해오는 것 부터 시작해야 한다.

EOS 댑을 쓰다 보면 겪는 문제들.. 그나마 이렇게 친절하게 보여주는 것도 정말 모범사례 인 것이다. (EOSKnights)

결국… 블록체인 서비스를 개발하는 대부분의 개발사 입장에서는 사이드체인을 쓰거나, 자체 블록체인을 개발하거나, 그냥 서비스 내의 화폐를 실제 블록체인 기반 암호화폐로 발행하지 않거나, 주요 Transaction을 Off-chain화 시키게 될 수 밖에 없을 것이다.

5.3. 지갑 이용 문제

dApp을 쓸 때 Metamask / Scatter / 내장 지갑의 서명 요청 화면

결국 블록체인 서비스를 만드는 입장에서도, 사용자의 입장에서도 암호화폐 지갑은 쓸 수 밖에 없게 된다. 블록체인 (B2C) 서비스란 대부분 암호화폐를 가지고 뭔가를 하는 서비스이고, 그러기 위해서는 사용자의 암호화폐를 보관하고 입/출금하는 계좌가 있어야 하기 때문이다.

물론 여기서 ‘지갑’은 Clay와 같은 암호화폐 지갑 서비스만을 이야기하기보다도, 거래소 내의 지갑이라든지 dApp 게임 내 탑재된 지갑 모듈이라든지 하는 것들을 통칭해서 부르고 있다.

블록체인 서비스 개발자는 내부적으로 지갑을 개발할 지, SDK를 제공하는 외부 지갑을 사용할 지 (Metamask, Scatter, …)를 선택해야 하고, 전자의 경우 탈중앙화 방식을 써서 기기에 데이터를 저장할 지, 중앙화 방식으로 서버에 보관할 지도 선택해야 한다. 비유하자면 쇼핑몰을 하나 하려고 하는데, 결제 서비스 구축을 직접 고민해야 하는 셈이다. 게다가 외부 지갑의 경우에도 선택지가 너무 없어서, 크롬 익스텐션으로 개발된 Metamask, Scatter를 사용자에게 설치하라고 강제해야 하고 모바일 dApp 플랫폼 지갑은 아예 없는 실정이다. (dApp Browser 라는 형태의 지갑들이 있지만 이는 오직 웹만 지원하는 임시적인 형태로 보기에 논외로 친다)

대부분의 dApp들이 지갑을 직접 개발하는 것을 부담스러워하기에 Metamask, Scatter 등의 dApp 플랫폼 SDK를 사용해서 사용자의 블록체인 계정을 연결하는데, 이럴 경우 사용자들은 ‘게임을 하고 싶은데 XX월렛 앱도 깔아야 하고, 거기에 돈도 넣어야 하고, …’ 뭐 이런 경우가 생긴다.

그리고 dApp들이 트랜잭션을 생성할 때 마다 (ex: 게임 캐릭터가 한 칸 움직일 때, 아이템을 장착하고 해제할 때..) 지갑으로 넘어가서 사용자에게 승인을 받아야 한다. 그렇지 않으면 사용자가 모르는 사이에 악성 dApp들이 돈을 모두 빼갈 수 있기에 꼭 필요한 절차이긴 하다. 그래도 실제 코인이 빠져나가는 트랜잭션이 아니면 이런 절차 없이 쉽게 쉽게 하면 좋을 텐데… 아직 dApp 플랫폼 지갑들의 UX 연구는 턱없이 부족한 실정이다.

국내에서 개발된 EOS 게임 dApp인 EOSKnight과, 탈중앙화 거래소인 Allbit, Bancor Network 의 사례를 그나마 지금 할 수 있는 최선의.. 사례라고 생각한다. 자체적으로 지갑을 내장하고, 원래 쓰던 지갑을 불러오거나 새로 만들거나 할 수 있게 사용자 편의를 제공하고 있다.
dApp들은 지갑 부분을 직접 만들 수 없다. 그렇기 때문에 더 쓰기 편하고 확장성이 있는, 모바일도 깔끔하게 대응되는 dApp 플랫폼 지갑이 출시되어야 한다. 이 부분은 Clay의 궁극적인 비전이기도 하다.

6. 탈중앙화

블록체인 업계에서 가장 동상이몽이 심한 주제는 개인적으로 ‘탈중앙화’ 일 것이라 생각한다. 비트코인과 블록체인은 탈중앙화 이념을 숭상하는 사이버펑크 아나키스트 성향을 가진 Geek들이 고안하고 발명했다고 생각하지만, 인터넷이 그러했듯 결과적으로는 이 이념 자체는 옅어지고 결과적으로 어떤 가치와 효용을 창출할 수 있는지에 산업은 집중하게 될 것이다.

탈중앙화는 ‘멋지고 훌륭한’ 이념이다. 하지만 그것이 ‘당연하지’ 않은 이유는, 그것이 지금 관점에서 볼 때 비효율적이기 때문이다. 하지만 마치 제왕집권 시대와 민주주의 시대를 비교해볼 수 있듯, 장기적으로는 이 담론이 우리에게 더 멀리, 높은 곳으로 나아갈 수 있는 영감을 준다고 생각한다.

하지만 어쨌든 우리가 앞으로 나아가려면 그 비효율성을 직면할 필요가 있다. 그리고 서비스 공급자와 유저 입장에서도, 스스로 어떤 이념들과 비효율을 택하고 버릴지에 대해서 생각해야 하지 않을까.

6.1. vs 중앙화

모든 탈중앙화는 결국 중앙화의 유혹, 혹은 도전을 받게 된다. 탈중앙화 이념으로 인해 생긴 암호화폐는 결국 중앙화 서비스에 가장 많이 담겨서 관리되고 있다.

앞서 몇몇 항목에서, 탈중앙화와 중앙화를 많이 비교했던 것 같아 여기서는 조금 더 핵심적인 부분만 러프하게 정리해보자면.

탈중앙화 : 해킹/보안 위험성에서 자유롭고 구현 비용이 적다. 유저에게 자신의 데이터/자산 주권을 주지만 대신 그만큼의 보관 책임을 부여한다. 보관 소홀 (데이터 소실, 개인적인 해킹) 문제가 발생할 수 있고 이에 대한 사후 대책이 없다. 비직관적이고 사용이 불편하다.
중앙화 : 해킹/보안에 취약하다. 중앙 운영 주체가 해킹당하면 모든 유저의 자산이 위험해진다. 유저의 데이터와 자산을 중앙 주체가 위탁하여 컨트롤한다. 유저 입장에서는 쓰기 편하고 직관적이라서 좋다. 유저의 보관 소홀 등의 문제에 대해서 운영적으로 대처해줄 수 있다.

정도라고 보면 되겠다. 주요 UX 쟁점에 대해서는 다른 항목에서 많이 다뤘던 것 같아 생략하겠다. 음.. 탈중앙화 서비스는 정말 불편하다. 정말로.

다만 그렇기에 중앙화 요소를 어떤 부분에서건 섞기 쉬운데, ‘해킹/보안에 취약하다’ 라는 말의 무게에 대해서 다시 한번 부연하면… 여기에 대해 100% 만족할 만한 답을 어떻게 낼 수 있는 것일지를 진지하게 생각해보아야 한다. 정말 많은 IT회사, 심지어 거대한 자본을 가진 회사들도 종종 해킹을 당한다. 금융회사들도 마찬가지이다.

중앙화된 금융 시스템은, 그럼에도 불구하고 언제든 사후대처를 할 수 있도록 되어있다. 자금의 흐름은 추적될 수 있고, 데이터는 복구될 수 있다. 하지만 암호화폐는 애초에 탈중앙화 이념에 의거해서 만들어졌기에, 자금의 흐름도 알 수 없고 데이터는 복구될 수 없다. 해커 입장에서 이렇게 좋은 먹잇감이 없다.

따라서 ‘우리는 해킹을 당하지 않는다’ 가 아니라, ‘해킹을 당하더라도 유저의 자산은 안전하다’라는 시나리오를 만들어야 한다. 아예 해킹을 당할 수 없는 시나리오는 없기 때문이다. 예를 들어 중앙화되어 유저의 데이터를 직접 보관하지만, 해당 Key들을 개별적으로 강한 수준의 암호화를 하여 보관한다든지, 거래소처럼 책임질 수 있는 만큼의 자산만 Hot Wallet에 보관하고 나머지는 콜드 월렛에 보관한다든지, 혹은 보험회사와 계약을 하여 자산 손실에 대해 책임을 지든지 하는 것들이다.

6.2. 비직관성

탈중앙화라는 것은 그 자체로 생소한 개념임을 우리 모두 다시 한 번 주지해야 한다.

예를 들어 탈중앙화 지갑 사용을 시작한 대부분의 유저들은 ‘내 자산이 이 지갑 서비스에 들어있다’라고 착각하는 것이다. 아닌데. 유저의 자산은 블록체인에 저장되어있고 지갑 서비스는 이를 편하게 쓸 수 있게 중개한다.

지갑이 웹 브라우저와 비슷하다고 이야기하는 이유중에 하나다. 크롬, 익스플로러에서 보이는 정보들은 구글, 마이크로소프트 서버에 담긴 것이 아닌 것과 비슷하다.

그밖의 비직관성에 대해서는 앞서 논한 바 있어 생략한다. 백업, 보관, 송금, 토큰, 블록체인 플랫폼 등등…

7. 규제 이슈

탈중앙화 이념으로 시작된 이 업계이지만… 역설적으로 중앙화의 상징인 정부나 은행 등에 가장 큰 영향을 받고 있는 것이 사실이다. 어쨌든 블록체인 서비스를 애초에 할 수 있는가 하고 생각할 때 가장 중요한 것이 바로 이 규제/법률 이슈이다. 본인이 관련 전문가는 아니기 때문에 자세히 언급하기 보다는 서비스와 유저 차원에서 적용되는 것들만 간단히 짚고 넘어간다.

사실 이 부분에서는 대안이 별로 없다. 해외로 나가서 법인을 설립하거나 그냥 기다릴 뿐…

7.1. 법정화폐 — 암호화폐 간 매매

2. 의 자산 구매 부분에서 언급한 바 있다. 어쨌든 암호화폐를 법정화폐로 매매할 수 없다는 것 자체가 사용자에게 굉장한 허들이다.

7.2. KYC 의무

암호화폐를 판매하거나 관련하여 사용자에게 법정화폐 입금을 받아야 하는 경우, 대부분 KYC 의무가 있고 이는 서비스를 시작하기 전 사용자에게 매우 큰 불편사항이 될 때가 많다. 운영하는 차원에서도 매우 큰 부담이기도 하다.

가장 바람직한 것은 결국 암호화폐 제공/보관/입출금 에만 신경쓰는 지갑 서비스와, 관련 응용 서비스가 분리되는 것이다. 마치 결제 서비스들과 게임/쇼핑몰 등이 분리되어있듯. 각자는 각자가 할 일이 정말 많다.

7.3. 자본시장법

행여나 여러분의 토큰이 Security Token에 속하진 않는지, 예를 들어 배당을 주거나, 회사의 가치에 토큰의 가격이 반영되어 수익을 낼 수 있거나 하는 점들. 그리고 토큰 판매가 유사수신행위에 해당하진 않는지 등을 따져보아야 한다.

7.4. dApp의 환급성

그런 차원에서 대부분의 dApp들은 법을 어기는지에 대한 이슈에서 자유롭다고 할 수 없다. 결과적으로 암호화폐를 쓰는 대부분의 dApp들은 돈을 내고 돈을 버는 구조이기 때문이다. (일방적으로 돈을 유저에게 주는 경우는 제외)

이 부분도 사실 지금 규제가 딱히 명확히 있다고 볼 수는 없기에, 우리 서비스가 ‘도박’에 해당하는지 아닌지만 일단 체크해보면 될 것 같다. ‘도박’은 한마디로 돈을 버는 것에 조금이라도 ‘우연성’이 들어가는가 하는 점이다.

문제는 사실 대부분의 dApp 게임의 경우 이 우연성이 개입될 수 밖에 없고 결국 도박이 된다. (왜 국내 게임들이 게임머니를 환급하지 않겠는가) 예를 들어 장기나 바둑을 가지고 하는 내기는 우연성을 훨씬 배제한다고 볼 수 있으나, 내기 골프는 당사자들의 정신적-육체적 능력 이외의 우연적 변수가 많이 결부되므로 도박으로 인정된 판례가 있다거나 한 것들이다. 명확한 기준이 있다고 보기는 힘들긴 하다.

맺으며

암호화폐 지갑을 만들어나가는 게 이런 힘든 일이다라는 징징대는 글을 쓰려다가, 우리가 이런 거창한 일을 해나가고 있다는 글을 쓰려다가, 결국 ‘이런 문제들이 있는데 같이 좀 해결해봅시다’ 하는 생각을 하며 글을 마무리하게 되었다. 안그래도 작고 쪼그라든 파이를 너보다 더 나눠먹겠다고 눈을 부릅뜨지 말고, 같이 머리를 맞대고 파이를 키울 방법을 생각해보고 좋은 노하우들을 공유하고 멋진 성공사례들을 만들어내면 좋겠다.

위의 모든 내용은 나, Kain의 개인적인 의견이다. Clay.one의 공식 입장은 아니고, 위에 쓰여진 어떤 내용에 대해서도 책임지지 않는다. (뭐가 되었든 참고만 하기 바란다)

보고서나 책, 논문을 쓰는 것이 아니므로 항목을 MECE (Mutually Exclusive, Collectively Exhaustive) 하게 나누거나, 각 내용들에 대해 굳이 주석을 달거나 하지 않겠다. 사실 글을 이렇게 길고 장황하게 쓴 것만 해도 충분히 시간이 아깝다…

우리 Clay 팀은 dApp을 쓰기 편한 암호화폐 지갑을 만들고 있다. 하지만 지금 우리가 상상하는 미래와 현재의 사용자 간의 간극은 어마어마하고, 그것을 어디서부터 어떻게 줄여나갈지를 계속 역산하고 역산하다보니 고민은 끝이 없어진다.

한편 당장 할 수 있는 최선이 무엇인가를 고민하다보면 하나 둘 씩 밟아야 할 징검다리들이 보이곤 한다. Clay는 지갑의 Side에서 블록체인 Mass Adoption 을 이루기 위해 하나 둘 노력하고 이루어나갈 것이다. 많은 도움과 응원을 부탁한다.