1.
요즘 재택 프로젝트중입니다. 금융회사의 IDB(Inter Dealer Broker)시스템을 구축중입니다. 오래전에 기획했던 HiperBond의 경험을 살려서 구현중입니다. 온사이트가 아닌 프로젝트라서 Redmine으로 협업을 진행중이만 역시나 일정관리가 무척이나 어렵습니다. 난관없는 프로젝트가 없으니까 최선의 노력을 다하는 중입니다. 재택하면 편할 듯 하지만 출근을 지하 사무실로 하고 끼니를 집에서 하는 것 말고 출퇴근과 크게 다르지 않습니다. 그래도 아쉬운 것이 햇볕입니다. 아쉬움을 풀 겸 오랜 만에 여의도로 나갔습니다. 고객사를 방문해서 몇 가지 서류를 전달하고 후배를 만났습니다. 후배를 만나서 이런저런 대화를 하는 중 잠시 '암호통화거래소'가 화두였습니다. 이야기를 들어보니까 ICO를 목적으로 거래소를 개발하려는 수요가 많은 듯 하더군요. 자체로 거래소를 개발한 후 코인을 상장하여 유통을 한 후 대형거래소에 상장을 시키려고 하는 의도입니다. 불순한 의도를 가지면 코인사기(Scam)일 수 있습니다. 그래서 저는 얼마전 암호통화거래소 개발자가 구속된 이야기를 꺼냈습니다.
가상화폐(암호화폐) 거래소 가운데 하나인 한국블록체인거래소(HTS코인) 대표 등 관계자 3명이 구속됐다.서울남부지법 이환승 영장전담 부장판사는 14일 HTS 대표 신모씨와 프로그램 개발자, 시스템 운영 책임자 등 관계자 3명에 대한 구속영장을 발부했다고 밝혔다. '유령코인' 가상화폐거래소 대표 구속중에서
거의 8개월동안 유명한 암호통화거래소 시스템을 개발하였습니다. 빅뱅이 아닌 개선방식의 개발이었습니다. 처음 시작할 때 여의도에서 배웠던 업무지식을 적용하려고 했습니다. 그런데 무척 달랐습니다. 거래라는 형식은 같지만 시장의 논리는 완전히 달랐습니다. FX와 비슷한 점이 있지만 다릅니다. 소숫점이라는 새로운 장벽도 경험하였습니다. 거래소라고 하면 매매체결시스템으로 이해합니다만 그것이 전부는 아닙니다. 한국거래소도 매매체결시스템외에 청산결제시스템을 구축한 것과 유사합니다. 따라서 온전한 암호통화거래소는 증권회사의 HTS시스템과 매매체결시스템을 합한 시스템을 구축하여야 합니다.
암호통화거래소를 어떻게 만들어야 할까요? 최근의 흐름을 보면 두가지가 가능합니다. 보편적인 중앙집중적인 거래소이거나 분산형(Decentralized Exchange)입니다. 오늘은 중앙집중형 거래소를 인터넷에 올라온 글을 인용하면서 소개할까 합니다. 먼저 거래소를 만든다고 할 경우 어디서 시작해야 할까요? How To Start Your Exchange – A Beginner’s Guide은 다음과 같은 다섯가지를 먼저 결정하라고 합니다.
Decide where you want to do business Learn about relevant regulations in that area Partner with a bank or payment processor Create Liquidity on Your Exchange(Establish a transaction history and liquidity on the exchange) Implement best security practices Offer customer support
어디서 사업을 할지는 무척 중요합니다. 어디인지를 확정하여야 어떤 규제가 있는지를 확인할 수 있습니다. 제가 만났던 사람들에게 반대로 "꼭 암호통화사업을 하려면 규제가 거의 없는 곳을 찾아라"라고 권고를 합니다. 미국 뉴욕에서 사업을 하려면 BitLicense를 준수하여야 하고 일본에서는 관련법을 지켜야 합니다. 규제가 있다는 것은 사업의 안정성을 높히지만 투입비용과 시간이 늘어납니다. 규제에 따라 금융회사 혹은 금융서비스와 제휴하는 방법이 달라집니다. 대부분의 암호통화거래소는 Fiat통화로 암호통화를 매매하는 모델을 따릅니다. 이 때문에 FIAT통화를 입출금할 수 있는 방법이 무척이나 중요합니다. 물론 암호통화로 암호통화를 거래하는 시장을 만들면 관계없지만 암호통화를 입출금하기 위한 - 블록체인에 접근하기 위한 - 전자지갑시스템을 만들어야 합니다. 입출금을 해결한 후 가장 중요한 유동성공급을 어떤 방식으로 할지 결정하여야 합니다. 앞서 소개한 글은 세가지 방법을 제시합니다.
You can simulate trading activity within your exchange by buying and selling between two artificial accounts within your own exchange. You can implement an API interface which connects your bitcoin exchange to another existing exchange. You can join a whole network of cryptocurrency exchanges such as Trust-Deposit which will tie together the liquidity of all exchanges within its network. The bigger the network, the better the liquidity.
거래소를 만들었다고 거래가 일어나지 않습니다. 투자자를 유치하여야 합니다. 만약 암호통화거래소를 한국에서 하겠다고 하면 투자자를 유치할 수 있을까요? 빗썸, 코인원, 코빗을 상대로 고객을 뺏어올 수 있을까요? 업비트는 이런 거래소들과 다른 방법을 택하였고 그것이 위에서 언급한 두번째 방법입니다. 미국의 Bittrex와 제휴를 하였고 업비트의 MTS노하우를 살려서 주식투자경험이 있는 투자자를 유지할 수 있었습니다. 더구나 암호통화거래소는 약간의 제약이 있기는 하지만 국경 없는 거래가 가능합니다. 경쟁상대가 한국에 있는 거래소뿐 아니라 해외거래소도 경쟁상대입니다. 시스템을 개발하는 것은 쉽습니다. 운영하는 비 또한 절감하는 방법을 찾을 수 있습니다. 그렇지만 유동성을 쉽게 풀기 어려운 문제입니다. 막대한 홍보비가 발생합니다. ICO 등으로 대박의 꿈을 이룰 수 있는 기회를 제공하야야 하지만 쉽지 않습니다. 사기로 끝날 확률이 많습니다. 제가 암호통화거래소를 하지말라고 하는 이유입니다.
또다른 글입니다. How To Develop A Cryptocurrency Exchange Platform 을 살펴보겠습니다. 개발의 시작은 설계입니다. 어떤 그림을 그릴지는 비즈니스모델에 달렸습니다. 이 글은 세가지정도를 이야기합니다.
Direct trade platforms provide tools for making immediate deals between users. This type of exchange platforms does not involve a market-established price on the market; instead, traders set their own exchange rate. (환전모델) Brokerage platforms are sites that any person can use to buy currencies at a rate that was set by an agent. Cryptocurrency agents are similar to foreign currency dealers.(브로커모델, 일반적인 모델) Cryptocurrency funds are investment pools with professional management, where you can buy and hold digital currency assets.(펀드)
초창기에 만들어진 거래소들은 거래소보다는 환전소에 가까운 모델이었습니다. 시장이 커지고 유동성이 늘어나면서 브로커모델로 바뀌었습니다. 펀드모델도 가능하지만 한국에서는 불법입니다. 첫번째 글에서 소개한 것처럼 나라별 규제가 다르기때문에 가능한 모델도 다양합니다. 모델이 정해지면 그에 따른 기능요건이 정해집니다. UI를 기준으로 등록,입출금, 계좌,주문,체결,잔고,포지션,차트,실시간 등의 요건이 나옵니다.
A perfect interface should provide the user with the following features
Fast registration; Access to trading accounts; Depositing and withdrawal of cryptocurrencies and fiat currencies; Review of the order book history and past transactions; Changes in balance and statistics monitoring; Analytical infographics and charts; 24/7 customer support.
개인적으로 볼 때, 일반 주식시장에 비해 종목이 적은 암호통화시장에서 가장 중요한 것은 Market Depth정보입니다. 유명한 암호통화거래소는 Full Market Depth정보를 제공합니다. 물론 실시간입니다. 여기에 더하면 주문유형입니다. 국내 거래소와 해외거래소를 비교할 때 차이가 크게 나는 부분이 주문유형입니다. 시장가, 지정가주문외에 다양한 주문이 가능합니다. 다양한 주문유형은 매매체결엔진을 어떻게 설계하느냐에 따라 달라집니다. 너무 상투적인 표현이지만 유연한 설계가 무척이나 중요합니다.
이상의 기능보다 중요도에서 훨신 높은 기능요건이 있습니다. 전자지갑입니다. 요즘 문제가 되는 업비트와 관련한 기사중 일부입니다.
암호화폐는 블록체인 기술로 암호화된 분산원장(distributed ledger)에 어느 참여자(또는 노드)가 얼마만큼의 암호화폐를 보유하고 있는지 기록해두는 시스템이다. 지갑은 이 분산원장에 기록된 정보를 열람(인터넷뱅킹의 ‘잔고조회’를 떠올리면 된다)하고, 거래를 할 수 있는 기능(인터넷뱅킹의 ‘계좌이체’와 같다)을 갖춘 어플리케이션이다. 암호화폐를 개발하는 재단이 공식적으로 제공하는 지갑도 있고, 모든 암호화폐가 오픈소스로 공개된 만큼 이를 이용해 제3자가 만든 공개형 지갑도 있다. ‘bitcoin.org’나 ‘마이이더월렛’ 등이 이런 공개형 지갑이다. 하지만 지금 업비트에서 문제가 되고 있는 지갑은 이런 지갑이 아니다. 위에서 설명한 지갑은 블록체인에 직접 연결된 ‘온체인’ 지갑인 반면, 업비트 등 거래소들이 회원들에게 제공하는 지갑은 해당 암호화폐의 블록체인과 연결되지 않은 ‘오프체인’ 지갑, 즉 거래소 내부용 지갑이다. 온체인 지갑은 거래를 실행할 경우 블록체인에 기록이 되지만, 오프체인 지갑은 해당 거래소 내부 장부에만 기록이 남는다. 업비트 안에서 암호화폐 거래가 아무리 많이 일어나도, 즉 업비트 회원들 사이에 어느 암호화폐의 주인이 아무리 여러 번 바뀌어도 해당 기록은 오프체인 지갑과 거래소 내부 장부에만 남을 뿐, 블록체인 상에서는 아무 일도 일어나지 않는다는 말이다. 회원이 업비트의 오프체인 지갑에서 다른 거래소(또는 다른 온체인 지갑)로 암호화폐를 옮기겠다고 ‘이체’ 주문을 해도, 이는 회원이 업비트에 자신의 의사를 전달한 것일 뿐 실제 블록체인 상에서 이체를 실행시키는 것은 아니다. 업비트가 회원의 주문에 따라 자신의 온체인 지갑에서 다른 거래소의 온체인 지갑으로 블록체인 상의 거래를 체결해야 비로소 이체가 된다. 오프체인 지갑이 사용되는 이유는 현재 블록체인 기술의 한계 탓이다. 온체인 상에서 거래가 체결되기까지는 암호화폐에 따라 짧게는 몇 분, 길게는 며칠이 걸리기도 한다. (물론 이 문제를 해결하기 위해 전세계의 수많은 개발자들이 노력하고 있다.) 시시각각 큰 폭으로 변동하는 암호화폐 시세를 감안하면, 거래가 체결될 때까지 한참을 기다려가며 온체인상에서 암호화폐를 사고파는 것은 현실적이지 않다.의혹의 원인: 업비트 지갑은 입출금이 안된다?
업비트에 대해 의혹이 제기되는 이유는 지갑(정확히는 입출금 기능)을 제때 제공하지 않았기 때문이다. 작년 10월 문을 연 업비트는 미국의 암호화폐 거래소 비트렉스와 제휴를 맺었다. 비트렉스와 API를 연동해 C2C(비트코인, 이더리움, USDT 등 암호화폐로 다른 암호화폐를 거래하는 것)로 137개 코인 거래가 가능하다.업비트가 자체적으로 거래를 체결하는 원화마켓(원화로 암호화폐를 거래하는 것)에서는 현재 47개 코인이 거래된다. 업비트는 지난해 말까지만 해도 원화마켓에 상장된 코인 중 비트코인, 이더리움 등 주요 암호화폐만 입출금 기능을 제공했다. 11월에 상장된 네오, 리스크, 오미세고 등은 원화마켓에 상장한 뒤 1달 이상 지나서야 입출금 기능이 제공됐다. 빗썸, 코인원, 코빗, 고팍스 등 주요 암호화폐 거래소들이 거래 중인 모든 코인의 지갑을 상장과 동시에 제공한 것과 대비된다. 이후 업비트는 순차적으로 지갑을 늘려 지금은 47개 가운데 1개(디크레드)만 입출금 기능이 없는 상태다. 거래소가 회원들에게 상장된 코인의 입출금 기능을 제공하지 않았다고 실제 코인이 없다는 뜻은 아니다. 역으로 입출금 기능을 제공했다고 해서 실제로 코인이 존재한다는 뜻도 아니다. 거래소가 회원들에게 제공하는 지갑은 어차피 코인들의 블록체인과 상관없는 내부 장부를 반영하는 것일 뿐이기 때문이다.문제는, 업비트가 입출금 기능을 제공하지 않음으로써 고객들이 자신이 산 코인을 다른 거래소나 다른 온체인 지갑으로 이체할 수 있는 길을 원천적으로 막아둔 것이다. 이 때문에 “실제 존재하지 않는 코인을 팔았으니까 고객이 코인을 외부로 옮기지 못하도록 한 것 아니냐”는 의혹이 꾸준히 제기됐다.
업비트가 답해야할 정말 중요한 의문중에서
기사는 온체인지갑과 오프체인지갑으로 구분했지만 제가 보기에 오프체인 지갑은 지갑이 아니라 계좌(Account)이고 온체인지갑만이 지갑(Wallet)으로 하는 것이 좋을 듯 합니다. Wallet은 암호통화를 주고받을 수 있는 창구입니다. 새로 거래소를 구축하여 서비스를 하려고 하면 투자자가 다른 거래소 계좌에 보유하고 있는 코인을 받아서 입금할 수 있는 전자지갑서비스가 필요합니다. 기사처럼 전자지갑을 자체적으로 개발하여 고객에게 제공할 수 있지만 공개서비스를 이용할 수도 있습니다. Bitgo와 같은 서비스의 API를 이용하는 것이 직접 구축하는 것보다 효율적일 수 있습니다. 전자지갑서비스를 개발하는 것보다 더 중요한 것이 보안이기때문입니다.
지금까지 소개한 글이 원론적인 수준이라면 마지막으로 소개하는 글은 개발자에게 유용한 아이디어를 제공합니다. Design Principles Risk Management은 2013년에 중국 암호통화거래소를 개발하였던 개발자의 글입니다. 글쓴이는 크게 세가지 구조를 제시합니다. 초창기에 만들어졌고 오픈소스프로젝트로 소개된 거래소모델은 대부분 Small, Synchronous입니다.
b: ScalabilityI group the scale of an exchange into three categories: small, medium, and large, or alternatively synchronous, asynchronous, and distributed.
Small, synchronous exchanges are simple and easy to build: they process all customer request in a single transaction, from the interface to the order book to updating the customer’s account record. They have very limited scaling abilities and will fail at large transaction volumes.
Medium, asynchronous exchanges use independent layers to process requests. The interface takes user requests and submits it to a queue. Each queue runs as a service – possibly on a different machine. The service executes the request, the communicates the status to the interface. For example, when a customer places an order, the interface inserts a request into an order book, the polls for status updates. An order matching service processes the order, then returns the response, which is shown by the interface. There is a service for each major features of the exchange, as well as maintenance services which are independent of user-triggered requests. This kind of exchange can scale to much larger transaction volumes. Each feature of the exchange runs as an independent service. This exchange can scale much higher than a small exchange.
A large, distributed exchange is like a medium exchange, but the split the customer activity into segments (shards). The shards are independent, and if using cloud auto-scaling the exchange can scale indefinitely.
문제는 asynchronous 모델입니다. 꼭 증권사가 채택한 HTS 플랫폼으로 접근할 필요가 없습니다. 세계적인 수준에서 보면 한국적인 환경이 만든 플랫폼입니다. 멀티디바이스를 고려하면 웹이 표준인데 비동기식환경을 구축하기 위해 node.js, Websocket이나 Messaging Middleware를 고려해도 좋은 선택이라고 생각합니다. 그러면 앞서 개발자가 만들었던 시스템을 기준으로 정리한 자료를 소개합니다.
Open Source Bitcoin Trading Engine
Bitcoin Exchange Project Part 2: Order Matching Algorithm
사실 Github를 검색하면 수많은 매칭엔진이나 암호통화거래소 소스를 얻을 수 있습니다. 완성도가 무척 높은 프로젝트도 많습니다. 적절히 선택하여 사용할 수도 있습니다.
이상의 글에서 언급되지 않았지만 반드시 집고 넘어가야할 사안이 있습니다.
암호통화거래가 다른 거래와 다른 점이 몇가지 있습니다. 최대 소숫점 32자리까지 사용하여 거래량을 정합니다. 이를 FIAT통화로 교환할 때 현실에서 존재하지 않는 소숫점이하의 금액이 나옵니다. Rounding을 하여야 합니다. 또한 암호통화를 거래와 동시에 결제가 일어납니다. Rounding과 Payment가 동시에 일어나면서 다양한 문제가 일어납니다. 그래서 위험관리가 무척이나 중요합니다. 거래소사업자가 손실을 입을 수 있기때문입니다.
두번째는 펌프앤덤프와 같은 경우에 대한 대비입니다. 국내외 암호통화거래소가 자주 장애에 노출되는 이유는 거래소 시스템의 구조에도 문제가 있을 수 있지만 예측하기 힘든 접속수요입니다. 시스템을 구축할 때 일정한 수요를 예측하고 하드웨어를 도입하고 소프트웨어를 구축합니다. 그렇기때문에 수요예측치를 벗어난 경우 장애가 발생할 확율은 높습니다. 그렇다고 막대한 비용을 들여서 최대치로 구축하는 것은 현실적이지 않습니다. 2017년을 기준으로 시스템을 구축할 경우 2018년 현재 용량의 10%만 가동하는 비극이 발생합니다. 장애를 최소화하고 수요가 늘어날 경우 용량의 증설을 효율적으로 할 수 있는 구조를 만드는 것, 무척 중요합니다.
Posted from my blog with SteemPress : http://www.smallake.kr/?p=25870