데이터베이스 솔루션으로 블록체인 활용하기

이 글은 zdnet의 George Anadiotis가 쓴 How to use blockchain to build a database solution
을 번역한 글입니다. 블록체인 기술이 컴퓨터 과학의 인프라인 데이터베이스와 어떻게 결합이 가능한지, 그 내용이 궁금하여 번역하게 되었습니다. BigchainDB는 개발중으로 보이며, 공식 홈페이지와 github에서 확인하실 수 있습니다. 참고로 Star가 1,230에 Fork가 236이네요.

블록체인으로 데이터베이스 솔루션을 구축하려는 이유는 무엇인가요? 어떻게 할 수 있을까요? BigchainDB가 답을 제안합니다.

처음에는 월 스트리트였고, 이제는 데이터베이스입니다. 대부분의 사람들은 블록체인이 뭔지, 비트코인과 차이가 뭔지 알아보려 하고 있고, 다른 사람들은 다양한 도메인에서 사용하고 있습니다. 과대 선전일까요, 개 발에 편자일까요, 아님 블록체인을 데이터베이스 영역에서 의미를 가질 수 있을까요?

BigchainDB의 창시자는 블록체인과 데이터베이스가 오래오래 행복하게 살아야 할 이유와 해결 방법이 있다고 봅니다.

블록체인 기술은 간단히 말하자면 거래, 계약서, 판매 등을 기록하는 디지털 원장입니다. 이 기술은 탈중앙화인데, 이게 뭐냐면 데이터를 전세계의 컴퓨터에 나누어져 저장하고, 분산되어 있는 물류, 잔고, 계약, 계정 정보 등을 실시간으로 안전하게 갱신하기 위해 레코드들을 블록으로 묶고 연대순으로 '체인화' 하여 관리합니다.

뭔가여?

블록체인은 비트코인에 의해 소개되었으며, 논란의 여지가 있었으나 다양한 새로운 기술이 소개되었습니다.

• 탈중앙화 제어 : 네트워크의 어느 누구도 제어권을 가지지 않습니다.
• 불변성 : 쓰여진 데이터는 영원히 위조되지 않습니다.(tamper-resistant)
• 네트워크 자산 거래 : 중앙의 관리가 없는 네트워크에서 자산의 생성과 거래가 이루어집니다.

비트코인을 둘러싼 첫번째 관심은 자산으로 토큰의 활용으로, 예를 들어 법정 화폐를 대체하는 것 입니다. 이제 비트코인과 기저의 블록체인 기술의 분리는 점차 진행되어 블록체인 기술 그 자체와 블록체인 기반 애플리케이션의 연구로 확장되고 있습니다.

확장된 연구 영역은 하나의 블록체인 기술을 4단계의 기술 스택으로 바라보게 하고 있습니다.

1. 애플리케이션

2. 탈중앙화 (블록체인) 연산 플랫폼

3. 탈중앙화 처리 (스마트 컨트렉트), 탈중앙화 저장소 (파일 시스템, 데이터베이스), 통신

4. 암호화 방법, 합의 프로토콜, 기타 등등

블록체인에서 사용하는 데이터 역시 블록체인의 한 부분으로 저장되어 있습니다. 예를 들어, 한 노드에서 다른 노드로 자산을 전송 할 때, 보내는 수량, 송신자, 수신자, 보내는 시간은 블록체인에 저장됩니다. 따라서 블록체인을 데이터베이스로 활용해서 이점 챙기기가 관심을 받고 있습니다.

왜해여?

단순히 블록체인을 데이터베이스로 활용하는 것은 전통적인 데이터베이스 표준에 비하면 끔찍합니다. 초당 트랜잭션 처리량(tps)은 넘나 낮고, 한번의 쓰기 승인은 10분가량 걸리고, 용량은 몇기가에 머무릅니다. 더 나아가, 노드를 추가할 때 문제가 발생하는데.. 노드 숫자를 2배로 늘리면 네트워크 트래픽은 4배가 되고 처리량, 지연 시간, 용량은 개선되지 않습니다. 추가로, 블록체인은 기본적으로 질의 기능이 없습니다.

어떻게 동작하게 할 수 있을까요? BigchainDB의 Trent McConaghy와 공동 창업자들은 이 문제를 근본적으로 해결하려 합니다. 블록체인을 데이터베이스로 사용하는게 아니라, 데이터베이스에 블록체인 특징을 집어넣는 것 입니다. 초기에 그들은 RethinkDB를 기반으로 작업하였으며, 그 이유는 RethinkDB의 깔끔하고 효율적인 노드 갱신 프로토콜을 사용하기 위해서였습니다.

BigchainDB는 블록체인을 DB로 사용하는게 아니라, DB 위에 블록체인 특징을 구축하여 동작한다. 이미지 출처 : BigchainDB

속을 들여다 보면, BigchainDB는 두개의 분산 데이터베이스를 사용합니다.

• S : 트랜잭션 집합, "백로그"
• C : 블록체인

S와 C는 BigchainDB 합의 알고리즘 (BCA)로 연결되어 있습니다. 각 서명 노드에서 BCA가 수행되며, 서명 노드들은 연합을 형성합니다. 서명되지 않은 클라이언트들은 BigchainDB와 연결될 수 있으며, 권한에 따라 읽거나, 자산의 발행, 거래 등을 할 수 있습니다.

분산 DB인 S와 C는 상용 빅데이터 DB입니다. BigchainDB는 내부 동작에 관여하지 않으므로, 잘 코드화된 확장성, 갱신 이력 관리 같은 기능을 이용할 수 있습니다. 각각의 DB는 일관성을 보장하기 위한 내부 합의 알고리즘으로 구동됩니다.

어떻게여?

BigchainDB는 MongoDB와 파트너쉽을 채결하여 이를 사용하고 있습니다. 왜 MongoDB일까요? 다른 오픈소스 분산 DB를 사용할 수도 잇었습니다. "다양한 DB를 고려해보았지만, 우리는 JSON을 사용하는 도큐먼트 DB를 원했고, MongoDB는 당연한 선택이었습니다."

그렇지만, BigchainDB는 블록체인과 최근 공격받은 MongoDB의 결합은 보안 관점에서 적신호를 키는게 아닐까요? McConaghy는 지금 시점에서 하부의 DB가 보안 결함이 있을 수 있음은 인정하였으나, MongoDB에 치명적이거나 사과를 불러일으키는건 아니라 합니다.

McConaghy는 다음과 같이 말합니다. "MongoDB는 접근성을 높이기 위해 강력한 보안을 제거하였습니다. 만약에 보안이 없는 인터넷에 설치하고 내버려 둔 것은 MongoDB의 책임이 아닙니다. 지금은 중앙 집중형 솔루션에 비해 더 좋거나 나쁜게 없지만, 출시 과정에서 보안 기능을 향상하도록 조치를 취할 것입니다."

BigchainDB는 블록체인의 이점에 확장성을 더하려한다. 추가내용 참고. 이미지 출처 : BigchainDB

BigchainDB는 하부 데이터베이스 위에 API를 제공하여 동작합니다. 이는 하부 데이터베이스가 무엇이든지 상관없는 독립적인 레이어로 탈중앙화, 불변셩, 자산 전송의 블록체인 특징의 동작을 목표로 하기 때문입니다. 그러나, 여기에서 흥미로운 이슈가 나옵니다.

만약에 어떤 사용자들이 서로 다른 하부 데이터베이스를 사용하고 싶다면 어떻게 해야될까요? BigchainDB는 서비스 제공자 인터페이스로 서로 다른 데이터베이스를 플러그인 할 수 있도록 합니다. 이 방식으로 MongoDB위에서 동작할 수 있는거고, McConaghy에 따르면 관계형이던지 키-밸류 스토어던지간에 어떠한 데이터베이스도 사용할 수 있을거라고 합니다.

물론 말하긴 쉽죠. 또 다른 이슈도 발생합니다. 바로 어떻게 질의할 것이냐. 물론 BigchainDB의 질의처리는 아직 잘 동작하지 않습니다. 목표는 BigchainDB의 하부 데이터베이스가 뭐던지간에 그 위에서 질의하는 단 하나의 통합 인터페이스를 제공하는 것 입니다. 겁나 어려운 일이죠. 모든 데이터베이스가 하나의 언어를 쓰는 것도 아니고, 언어 포용성도 다르기 때문입니다.

그렇지만, 데이터베이스 시장은 추세는 기능 통합이며, 특히 질의 표준으로 SQL에 대한 새로운 관심과 전환은 이를 가능하게 할 수도 있습니다. NoSQL 데이터베이스라 불리는 MongoDB조차 최근 SQL 지원하기 시작했습니다. BigchainDB의 가장 바람직한 방향은 SQL 인터페이스 입니다.

현재 BigchainDB 질의의 대부분은 MongoDB의 API를 직접적으로 이용하지만, BigchainDB를 MongoDB와 밀접하게 연결하는 우회로로, BigchainDB의 자체 API로 나아가는 중간 솔류션으로 볼 수 있습니다.

누가해여?

지금까지 볼 때에 BigchainDB는 어떻게 보아도 일반적인 데이터베이스는 아닙니다. 또한 보통의 창업자가 운영하는 일반적인 스타트업도 아닙니다. McConaghy는 냉대받고 해커들의 놀이일 때부터 AI 영역의 경력을 가지고 있습니다. "90년대에 AI를 하는건 아마 가장 인기없는 것들 중 하나였을껍니다. 저는 유행에 편승해서 하지 않았습니다."

McConaghy는 Facebook의 일원이 될 수 있었지만 그 제안을 거절하였습니다. 그를 움직이는건 그런게 아니었고, BigchainDB에서도 마찬가지 입니다. BigchainDB에서 그가 행동하는 것은 성공적인 판매나 IPO가 아닙니다. 그가 원하는 것은 인터넷의 재구축과 확장입니다.

McConaghy는 중앙형은 권력의 집중을 일으킨다고 생각합니다. 소셜 미디어의 소유권과 데이터의 제어권, 예술에서의 창작자와 구매자의 수수께끼, 일반적인 콘텐츠, 인터넷에서의 초상권 등이 그 사례입니다.

McConaghy의 직전 벤처인 Ascribe는 디지털 예술가들의 작품의 소유권을 구매자에게 이전하는 것을 도와줍니다. 물론 이것으로 일상적인 예술작품인 음악이나 동영상에 적용할 수 있을지는 의문이지만, Ascribe는 디지털 예술가들의 독착적인 작품과 그것을 소유하고자 하는 구매자 간의 거래를 탈중앙화를 이용하여 이뤄내려 합니다. 어떤점에서 Ascribe에서 부터 BigchainDB가 탄생한 것으로 볼 수 있습니다.

누군가는 쓸대없이 복잡한 솔루션이라 말할 수 있지만, McConaghy는 복잡성을 피하지 않는 사람입니다. 예를 들어, Numerai와 그에 대한 비판에 대한 질문이 주어졌을 때 그는 "저는 그게 지나치게 복잡하다고 생각하지 않습니다. 반대로 굉장하다고 생각하고, 블록체인과 AI의 최고의 조합이 아닌가 싶네요. 수익에 대해서 투자자, 직원, 사용자에게 굉장히 잘 배분하고 있어요. 페이스북에서 사용자가 만들어낸 가치를 가져간다고 생각하면 어떨 것 같으세요? 그게 Numerai가 하고 있는거고, 권력의 구조와 협력에 대한 인센티브가 생기는 것을 전환하고 있는겁니다. 제로섬 게임은 양의 게임으로 바꾸는겁니다."

어디서여?

BigchainDB은 멀고 험난한 길의 어디쯤 와있을까요? 베를린에 위치한 BigchainDB는 최근 300만 유로의 시리즈A 투자를 포함해 500만 유로의 투자금을 유치했습니다. RWE와 Internet Archive를 비롯한 여러 얼리 어답터 고객과의 긴밀한 협력을 하고 있습니다.

Internet Archive는 Open Media 나 [Human Data Commons Foundation] (https://humandatacommons.org/)와 같은 다른 기관들 함께 IPDB를 지원하고 있습니다. IPDB(행성간DB; Inter-Planetary DB)는 BigchainDB의 공개 인스턴스로, 탈중앙화 방식으로 안전하게 콘텐츠를 저장하고 관리하는 것 입니다. IPDB는 인터넷 데이터베이스라는 동일한 목표를 비전으로 가지고 있습니다.

Internet Archive를 예로 들자면, 이 것은 전통적인 저장소 기술에서 이동하여 탈중앙화하며 협력이 가능한 저장소 모델로 나아가며, BigchainDB가 그 역할을 합니다. Internet Archive는 데이터 주권 문제를 해결하기 위해 캐나다로 이전하는 것을 검토하고 있기 때문에, 탈중앙화 저장소에 불변성을 추가하는 가능성은 매우 매력적입니다.

RWE의 경우는 조금 다릅니다. 전통적으로 대형 전기 운용사는 에너지 생산자와 수요자를 연결하여왔습니다. 규제 철회는 이를 바꾸어, 누구나 연결될 수 있게 하였습니다. RWE는 에너지 교환, 전기차 충전, 결제와 같은 여러개의 블록체인 프로젝트를 운용하여 앞서 나가고 있습니다.

BigchainDB는 최근 0.9 버전을 출시하였고, 2017년 로드맵에 따르면 안정화된 버전 1.0이 여름에 출시되며 모든 기능이 동작하게 됩니다. 상업화 가능하며 오픈소스인 엔터프라이즈 버전은 연말에 사용가능할 예정입니다.

그 목표가 실현 가능한지, 비전에 다다를 수 있는지에 대한 의문은 여전히 남아있습니다. 그러나, 그들의 야망과 기술이 부족하지는 않습니다.

2017년 3월 8일 추가 내용: 이 기사가 나간 후 BigchainDB의 CEO로부터 확장성에 대한 다음과 같은 설명을 받았습니다.

"우리가 처음 BigchainDB를 배포했을 때, 우리는 "이미" 100만 쓰기/초를 달성하였다는 인상을 주었으나, 이는 하부 데이터베이스의 성능에 지나지 않았습니다. 우리는 BigchainDB의 알고리즘을 개선하고 최적화하여 그 목표를 달성하려합니다.

피드백을 모은 결과 우리는 적절한 기대치 설정을 위해 목표를 수정하였습니다. 100만 쓰기/초를 향하는 것으로. 사용자들은 쓰기 성능보다 고용량과 사용성에 더 큰 요구를 가지고 있었으며 우리는 100만 쓰기/초를 달성하는 것 보다 사람들이 필요로 하는 곳에 개발 자원을 배분하였습니다. (로드맵에는 분명히 포함되어 있으며, 최우선순위가 아닐 뿐 입니다.)

저는 [지난 5월 블로그 글]을 통해 지난 여정을 다루었습니다. 적절하지 못한 목표 설정에 대한 사과, 그동안 자랑스럽게 지켜온 앞으로의 노력을 다루었습니다. 제 경력에서 사람들의 기대치를 잘 못 읽은 것은 처음이었습니다. 다시는 없을겁니다! :)