Blockchain
1. Outline
TGrid 와 Remote Function Call 을 이용하면, 블록체인을 보다 쉽게 개발할 수 있습니다.
블록체인 프로젝트의 개발 난이도가 높다는 것은 매우 유명한 이야기입니다. 구태여 블록체인 개발자들의 몸값이 다락같이 높아서 그런 것만이 아닙니다. 순 기술적인 관점에서 보더라도, 블록체인은 그 자체로 난이도가 매우 높습니다. 단, 기술적으로 무엇이 그렇게 어렵냐고 물었을 때, 저는 이렇게 말하고 싶습니다.
진정 어려운 것은 Network System 때문이지, Business Logic 때문은 아니라고 말입니다.
2. Network System
블록체인을 개발하면서 진정 어려운 것은, 네트워크 통신을 이용한 분산처리 시스템을 구현하는 것입니다.
블록체인이 사용하는 Network System 은, 기본적으로 수 만 ~ 수십 만 대의 컴퓨터가 네트워크 통신으로 어우러져 연동되는, 초대형 분산처리 시스템입니다. 그리고 이런 종류의 초대형 분산처리 시스템들은 하나같이, 어마무시한 난이도를 자랑합니다. 그리고 이런 종류의 초대형 분산처리 시스템들은 하나같이, 어마무시한 난이도를 자랑합니다. 이를 개발하는 모든 과정에 '완벽' 이라는 무시무시한 수식어가 따라다닙니다.
완벽한 요구사항 분석, 완벽한 유즈케이스 도출, 완벽한 개념 설계와 데이터 구조 정립, 완벽한 네트워크 아키텍처 수립, 완벽한 구현과 모든 케이스를 아우르는 완벽한 테스트 프로그램 제작 등...
1 Requirements
종래의 방법으로 블록체인을 개발하려거든, 아주 뛰어난 아키텍트부터 구해야 합니다.
이 아키텍트는 제일 먼저, 새로 만들고자 하는 블록체인에 대한 모든 요구사항을 완벽히 수집하여 이를 문서로써 정리하여야 합니다. 만일 새 블록체인에 대한 요구사항 중 제대로 인지하지 못한 게 있다거나, 나중에 요구사항이 변하는 일이 생기면 모든 과정을 처음부터 다시 시작해야 합니다. 따라서 요구사항 분석은 매우 꼼꼼하게 세밀하게 이루어져야 합니다.
2 Analyses
수집한 요구사항을 철저하게 분석한 후, 모든 유즈케이스를 완벽하게 발굴해내야 합니다. 그리고 확정한 유즈케이스에 맞추어, 개념 설계도를 새로이 작성합니다. 만약 이전에 행하였던 요구사항 분석에 미진함이 있거나 모순점이 있거든, 다시 1 Requirements 로 돌아가 처음부터 다시 시작해야합니다.
3 Designs
개념 아키텍처를 완벽하게 설계했다면, 이어서 다음 설계도들을 그려야 합니다.
- Data Architecture
- Network Architecture
- Software Architecture
첫 번째로 그려야 할 것은 데이터 아키텍처로써, 새 블록체인 프로젝트가 사용할 데이터 모델에 대한 설계를 해야합니다. 이는 블록체인 중에 '블록' 에 해당한다고 볼 수 있습니다. 물론, 데이터 아키텍처를 잘못 설계하였거든, 이후 어떤 과정을 진행 중이던, 무조건 현 과정까지 후퇴해야 하므로 반드시 완벽하게 설계하도록 한다.
두 번째로 그려야 할 것은 바로 네트워크 아키텍처로써, 네트워크 분산처리에 대한 설계가 여기에서 이루어집니다. 먼저 분산처리 시스템을 구성하는 모든 컴퓨터에 각각의 역할을 부여합니다. 그리고 각 컴퓨터간에 이루어지는 모든 네트워크 통신에 대하여 정의를 해야 하기 때문에, 모든 개발 과정을 통틀어 이 과정이 제일 어렵습니다. 동시에 가장 완벽을 기해야 하는 설계 과정이기도 합니다.
- 네트워크 송/수신이 이루어지는 모든 순간에 대한 정의
- 송/수신되는 각 메시지에 대한 정의 (바이너리 구조체)
- 송/수신되는 각 메시지가 함축하는 의미 (실행해야 하는 명령어 등)
마지막 세 번째로 그려야 할 것은 네트워크 분산처리 시스템을 구성하는 개별 컴퓨터, 그 컴퓨터에서 가동될 개별 프로그램들에 대한 소프트웨어 아키텍처입니다. 데이터 아키텍처와 네트워크 아키텍처를 따라 해당 프로그램이 구현해야 할 바를 다이어그램으로 표현하게 됩니다.
4 Implementations
위 과정에서 도출된 아키텍처를 따라 분산처리 시스템을 구성하는 각 컴퓨터에 탑재될 소프트웨어 프로그램을 개발하는 과정입니다. 물론 개별 프로그램을 개발하는 중에 아키텍처에 미진한 점을 발견했거나 모순점을 찾아냈다면, 이전 과정으로 다시 돌아가야합니다.
만약, 그 잘못되었다는 것이 요구사항이나 비지니스 모델에 관한 것이라면...
5 Conservations
여지껏 이루어진 설계와 개발이 완벽했는가를 검증하는 단계입니다.
물론, 여지껏 이루어진 개발 과정 중에 누락이나 모순된 점이 있다면, 그 과정까지 전속 후퇴하고 처음부터 그 과정을 다시 밟아나가야 합니다. 가령 데이터 아키텍처가 잘못되었다면, 네트워크 아키텍처의 대다수를 파기하고 다시 그려야 하고, 이에 따라 소프트웨어 아키텍처와 프로그램 코드가 모조리 영향을 받는 사태가 생깁니다.
반대로 검증 과정을 통해 모든 개발 과정이 완벽하게 완료되었음을 확인한다면, 그제서야 해당 블록체인 시스템을 가동할 수 있게 되는 것입니다.
이처럼 실제 동작하는 블록체인 (초대형 네트워크 분산처리시스템) 을 개발하는 것은 매우 어려운 일입니다. 괜히 블록체인을 개발하려거든, 기라성같은 아키텍트와 천재의 반열에 든 우수한 개발자들이 필요하다는 게 아닙니다. 하지만 그 기라성같은 아키텍트와 천재 개발자들조차, 쉬이 성공을 장담할 수는 없습니다. 그들 또한 미진한 요구사항 분석이나 어설픈 아키텍처 설계로 인하여 파멸에 늪에 빠질지 모르거든요.
어쩌면 블록체인 프로젝트를 개발한다고 외치고 다니던 그 많던 사람들과 업체들이, 이후의 소식을 들을 수 없게 된 데에는, 이러한 사연이 숨어있을지도 모릅니다.
3. Business Logic
블록체인의 Business Logic 은 그다지 어렵지 않습니다.
블록체인의 핵심 요소를 말하라 그러면, 그 이름 그대로 "첫째는 Block 이요, Chain 입니다" 라고 대답할 수 있습니다. 이 중 Block 은 어떤 데이터를 다루냐에 관한 것이고, Chain 은 블록에 데이터를 기록함에 있어 '상호간 어떻게 합의할까' 같은 정책에 관한 것입니다.
| Component | Conception | Description |
|---|---|---|
| Block | Data Structure | 데이터를 저장하는 방법 |
| Chain | Requirements | 합의 도출에 관한 정책 |
만일 이 Block 과 Chain 을 단 한대의 컴퓨터에서 동작하는 단일 프로그램으로 개발한다고 생각해봅시다. 이 경우에는 그저 자료구조를 설계하여 이를 디스크에 저장할 수 있고, 정책 (요구사항) 을 분석하여 코드로 구현할 수만 있으면 됩니다. 소양있는 개발자라면 누구나 만들 수 있는 것, 그것이 바로 블록체인의 Business Logic 입니다. 여러분도 얼마든지 해내실 수 있습니다.
4. Conclusion
여태까지의 이야기를 정리하면, '블록체인은 Business Logic 은 간단하지만, 그것의 Network System 을 구성하는 것은 매우 어렵다' 라고 요약할 수 있습니다. 그리고 여기서, 우리는 한 가지 대목에 주목할 필요가 있습니다. 그것은 바로 '블록체인의 Business Logic 은 간단하다' 라는 것입니다.
기억하십니까? TGrid 와 Remote Function Call 을 이용하면, 여러 대의 컴퓨터를 한 대의 가상 컴퓨터 로 만들 수 있습니다. 그리고 이렇게 만든 가상 컴퓨터에서 동작하는 코드는, 실제로 단 한대의 컴퓨터에서 동작하는 프로그램과 그 Business Logic 코드가 동일합니다. 따라서, 우리는 다음과 같은 결론을 도출해낼 수 있습니다.
- 블록체인의 Business Logic 은 어렵지 않다.
- TGrid 를 사용하면, Business Logic 에만 집중할 수 있다.
- 따라서 TGrid 와 함께라면, 블록체인을 쉽게 만들 수 있다.
블록체인 프로젝트를 하나 새로이 만드신다구요? TGrid 와 Remote Function Call 을 사용하시어 Grid Computing 을 실현하십시오. 복잡한 Network System 은 잊어버리시고 여러분께서 만들고자 하시는 블록체인의 본질, Business Logic, 그 자체에만 집중하십시오.