동기

EOS는 차세대 dAPP 플랫폼 중 개발 측면에서 파보려는 프로젝트이다.

큰 프로젝트니까 아마 한국어 백서도 있을 것 같은데, 정말로 영어를 전혀 못하는 것이 아닌 이상 당연히 영어로 읽어야 한다. 아직까지 한국어로 제대로 번역해 놓은 사람이 있을 수 없으니까 말이다.

소개 백서
기술 백서

소개 백서 및 기술 백서를 읽던 중 흥미로운 부분들을 발견했기 때문에 관심이 생겼다.

첫 줄에 보면 EOS의 블록체인이 High performance messaging using event sourcing을 갖췄다고 나와있다. 나 또한 회사에서 이 방법론을 기본으로 cloud 솔루션을 만들고 있다. 인터넷을 보니 messaging을 이용한 event sourcing은 한국에서는 작년에서나 글들이 보이기 시작하고 최신 기술로 많이 받아들여지고 있는 것 같다. 그러나 이미 2005년부터 구현도 마친 상태로 소개되던 것이고, 한국의 비즈니스 기술 수준이 낮아서 이제야 쓰이는 것이다. 그렇지만 현재 cloud 기반의 소프트웨어들을 이끌어가는 이 개발방식을 블록체인 위에 구현한다는 것은 분명히 대단한 시도라고 본다. 그리고 위 한 문장을 보는 순간 (물론 구현을 완벽히 한다는 가정 하에) 이더리움은 절대로 쫓아올 수 없는 영역을 EOS가 제시했다는 것을 곧바로 알 수 있었다.

하지만 부끄럽게도 나 또한 솔루션의 프레임워크에 내재된 기능으로서 event sourcing을 사용할 뿐, 구현은 커녕 그 핵심 개념을 잘 넣은 비즈니스 모델링을 할 능력이 없다. 그러므로 event sourcing의 기본 글을 다시 한번 읽고 머릿속에 정리해보았으며, 이 글에서는 EOS 백서에서 언급한 내용을 가지고 간단히 다뤄보았다.

event sourcing이란

event sourcing


위의 글이 오리지널 버전으로 보인다. 저 사람이 최초로 고안한 건지 아닌지는 모르겠다. 글이 아주 쉽고 명확하게 쓰여 있다.

event sourcing은 현재 소프트웨어 프로그램이 state machine이기 때문에 가지고 있는 한계들을 해결하기 위해, 소프트웨어의 state에 영향을 줄 수 있는 event라는 것을 정의하고 소프트웨어는 그것을 handling하는 machine이라는 관점에서 접근한 개발 방식을 말한다.

한국어 컨텐츠를 찾아보면 "event들을 저장해놓고, 그것에 의해 소프트웨어를 제어하고 필요한 경우 이전 상태로 돌려놓을 수 있게 하는 것 등등" 이 event sourcing이라고 적당히 써두었다. 기술적으로 틀린 말이 아니지만 정확히는 A라는 개념을 설명할 때 A의 부분집합을 갖고 설명한 거라 볼 수 있다. 컴퓨터 공학에서 새로 나오는 주제들은 그 개념 자체로 이해하지 않으면 여러 오류에 빠질 수 있다. 구현이 비슷해보인다고 같다고 착각하거나 반대로 구현이 다르다는 이유로 다른 개념이라고 착각하게 만들기 때문이다. 심지어 컨텐츠는 event sourcing이 event의 히스토리를 보게 만들기 때문이라는 이유로 CQRS와 궁합이 맞는 개념이라고 얘기하던데 그런 것이 전형적인 오류이다. 둘은 전혀 상관도 없는 방법론들이기 때문이다.

event sourcing 특징

event sourcing이 각광 받는 이유는 현재 소프트웨어는 state machine의 형태를 벗어날 수 없기 때문이다. 디지털 기술은 어느 순간 메모리에 전기 신호가 어느 상태로 있는지에 따라 동작하게 된다. 자연스럽게 '현재 상태'라는 것이 존재하고 어떤 변화가 나타나는 것은 '다음 상태'로 이전 시키면서 프로그래밍 하게 되어있다.

원 글에서 보면 위와 같이 state machine으로 화물을 배를 통해 운송하는 아주 간단한 모델이 있다. 배 (ship)는 장소(location) 정보를 갖고 있고, 배 이동을 추적하는 서비스가 (tracking service) 배 위치가 바뀔 때마다 장소를 해당 항구(port)로 바꿔준다.
프로그래밍 하는 개발자는 저런 상황에서 배가 이동했다는 이벤트가 있으면, recordArrival/recordDeparture 메소드를 부르고 그 메소드가 배의 장소를 바꿔넣게 된다는 것이다. 즉, 배의 장소는 전형적인 state 를 의미하게 된다.

하지만 event sourcing 방법을 사용한다는 것은 다음과 같은 것을 의미한다.

바로 shipping event를 합쳐놓은 것이다. '배가 이동한다'는 정보를 전달할 때 그 배의 장소 자체를 바로 변경하는 것이 아니라, 먼저 arrival/departure event라는 데이터를 만들어 쌓으면서 그걸 전달한다. 그 배라는 것은 해당 event를 받아서 걸맞는 처리를 해주는 것이다. 즉, 다음과 같은 event 데이터가 생기게된다.

• X 배가 목포 항구를 출발
• Y 배가 인천 항구에 도착
• X 배가 인천 항구에 도착

state machine은 각 event마다 X의 위치 및 Y의 위치를 바꿔서 결과적으로 X,Y가 인천항에 있다는 것만 가지고 있는다. 하지만 event sourcing에서는 그 과정을 모두 알고 있게 된다.

언뜻 보기에는 그냥 배의 장소를 변경하는 것보다 더 복잡하게 일을 만들어서 하는 것으로 보인다. 하지만 저런 event 데이터가 만들어져 있을 때의 부가가치는 상상을 초월하는 것이다.

1. event 이력을 안다
   먼저 개발자들은 평소에 개발하면서 당연히 'event log'가 필요하게 된다는 것을 알 것이다. 배가 "어디어디를 거쳐서" 현재 장소를 왔는지 알아야 하기 때문이다. state machine은 현재 state만 알기 때문에 state를 거칠 때마다 그 이력을 log로 쌓아야 한다. event sourcing은 이력을 log 수준이 아니라 프로그램 자체를 통제하는 데이터로 만들어버린 것이다.
   그러나 이력을 조회하기 쉽게 하는 것이 event sourcing의 핵심이 아니다. state machine이 본질적으로 가지고 있는 한계를 해결한 것이 가장 중요하다.

2. scalability의 해결
   event sourcing을 통해서는 하나의 소프트웨어의 현 state를 처음 시작 단계에서부터 event를 하나하나 밟아가면서 쫓아갈 수 있다. 즉, A라는 엔진이 현재 있는데 퍼포먼스가 모잘라서 B를 추가로 구입했다고 하면, A가 보고 있는 event 데이터를 쫓아가면서 내부 state를 맞추면 된다. 즉, B는 처음의 상태에서 시작해서 위 예시의 X,Y 배가 움직이는 과정을 내부적으로 실행해서 A의 상태와 똑같이 맞춰지게 된다.
   A의 state 자체를 카피하는 건 의미가 없는데, 그 state를 정리해놓는 것도 일이거니와 A,B가 같은 state가 되었어도 둘이 계속 sync를 맞추는 방법이 향후 존재해야 한다. 그게 결국 event sourcing 방법일 수 밖에 없다. event sourcing 하에서는 A,B가 같은 event 데이터를 바라봄으로서 sync를 맞출 수 있다. 그것이 곧 cloud 환경에서 사용에 따라서 서버 instance를 늘려 요금을 과금할 수 있게 만드는 근본 원리가 된다.
   state machine에서는 event와 그것에 영향 받는 모든 요소가 하나로 통합되어있을 수 밖에 없다. 왜냐하면 같은 역할을 하는 여러개의 엔진이 같은 state를 공유하는 것이 매우 어렵기 때문이다. 데이터베이스 분야에서는 여러 방식으로 이를 해결하려 했지만 개발을 하는 방식에서는 한계가 있을 수 밖에 없다.

event sourcing 개념적 함의

나는 한동안 process mining을 공부해본 적 있다. 그 주제에서도 비슷한 문제의식이 공유가 된다. 세상의 복잡한 인간사에서 일어나는 일들은 분명 순서가(process) 있지만, 대체 어떤 순서로 이루어지고 어떤 순서가 효율적/비효율적인지 알 길이 없다. 그것을 많은 event들을 모아 통계분석해보려는 시도가 그것이었다. 그리고 이 때 가장 골치아픈 것은 데이터를 끌어모으는 것이다. 'event'라는 것을 어떻게 정의할 것이며, 그 시점을 정확히 언제 잡을 것인가. 그리고 그 event 데이터를 대체 어떻게 추출할 것인가. 모두 하나하나 해결하기 너무 어려운 문제들이다.
하지만 event sourcing을 사용하는 소프트웨어 한정으로는 훨씬 내용이 쉬워진다. event들의 이력 즉, process 그 자체를 이미 손에 쥐고 있기 때문이다. 이 때 중요한 것은 각 state를 변화시키는 것들이 더이상 'state를 변화시키는 주체'로서 역할을 하지 않고 'state를 변화시키는 event를 handling하여 하란 일을 해주는 것'으로 한발짝 수동적인 개념으로 바뀐다는 것이다.

이렇게 event가 오는 것을 소프트웨어 특히 MSA (Micro service architecture) 방식을 사용하는 경우 message를 받는다고 말한다. 그리고 message를 받는 주체로서 각 소프트웨어의 객체를 message handler라고 말한다. 이렇듯 복잡하게 프로세스가 오가며 그 와중에 scalability를 확보해야 하는 구조에서는 수동적인 역할만 하는 작은 단위의 소프트웨어를 정의해놓고 event를 바라보게 하는 이 방식이 개발을 훨씬 쉽게 만들어준다.

EOS와 event sourcing

EOS는 어떤 경위로 event sourcing을 말하게 되었을까?

dAPP 플랫폼들이 public key를 어떻게 해석하느냐에 따라 개발 방식을 다르게 유도할 것이라는 점을 이전 글에서 다뤄보았다. 바로가기
EOS는 기술백서에서 다음과 같이 말하고 있다.

모든 계좌는 다른 계좌로 message를 보내는 기능을 가지며 또 다른 계좌는 message handler로서의 역할을 할 수 있다. 여기서 계좌와 message는 모두 일상어가 아니라 개발적 용어다. 계좌라 함은 사람의 구좌 같은 의미가 아니라 public key로 정의되는 모든 transaction 생성 가능한 객체라고 보아야 한다. message는 계좌가 비즈니스 로직을 담아 보내는 내부적인 명령이 될거고, 보통 event sourcing 구조에서는 message 성격에 따라 event들을 정의하고 누적시키게 될 것이다.
그러므로 publick key를 이더리움에서는 "eth를 저장할 수 있는 계좌"라고 정의한 데 반해 EOS는 "message handler 역할을 수행할 수 있는 객체"라고 정의한 것이다. 각각의 객체는 사람의 구좌일 수도 있지만 smart contract를 구성하기 위한 기본 단위가 될 수도 있는 등 아주 다양하고 복잡한 비즈니스를 해결지을 수 있게 될 것이다.

예를 들어 "내일 비가 오면 A에게 , 안오면 B에게 돈을 송금하는 " smart contract의 구조를 생각해보자. 이더리움 기반에서는 X라는 smart contract를 만들어야 할 것이며, 그 안에 A계좌와 B계좌 주소를 저장해둬야 할 것이다. 내일이 되면 바깥의 어떤 사람/봇에 의해서 smart contract가 실행될 것이다. 그리고 파라미터가 비가 내린다 하면 A에게 아니면 B에게 돈을 송금할 것이다.
만약 EOS가 말하듯 message handler 방식이라면 아마 A계좌와 B계좌가 비가 오거나 오지 않는 것에 대한 행위를 갖고 있을 것이다. 즉, smart contract를 맺는 순간 A 계좌에는 "비가 오는 event"가 참조된다면 B에게 돈을 송금하도록, 또 반대로 B도 자기 동작을 하도록 만들어질 것이다. 그리고 event를 보내는 주체는 따로 정의하게 되는 것이다.

예시가 그냥 보기에는 비슷해보일 수 있어도, dAPP가 점점 엄청나게 복잡해진다고 가정하면 분명히 후자의 강점이 생기게 된다. 만약 해당 smart contract에서 어떤 사람은 비가 억수로 많이 오면 더 돈을 많이 송금하기로 하는 규칙을 더했다면? smart contract에서 억수로 많이 왔을 때 송금할 리스트를 정의해야 한다. 만약 사용자가 100만명을 넘어가기 시작한다면? 내부 구조가 점점 복잡해질 것이다. 아주 간단한 헷지 펀드 모델이 그러한데 현실로 적용하려면 말도 못할 것이다.

마무리

아직 EOS의 github 코드를 한줄도 봐본 적 없고 그래서 정확히 어떻게 개발했는 지 전혀 알지 못한다. 하지만 백서에서 말하고 있는 바대로 event sourcing, messaging을 제대로 구현하고 있다면, 정말로 큰 규모의 프로젝트를 실현할 수 있을 거라 생각이 든다.