TL;DR 저는 딱히 하드웨어 쟁이도 아니고 완전히 소프트웨어 쟁이도 아니라서, 각 분야의 전문가들이 보시면 웃으실 부끄러울 글입니다. 다만 제가 왜 쓸데없이 주석 한글화 프로젝트를 진행하고 있는지, 또 이 블로그에 허접한 분석글을 남기고 있는지에 대한 명분 찾기 같은 거라고 생각해주시면 감사하겠습니다.
==== 하드웨어 설계를 경험해 본 적 있으신가요? ====
아니면, 'AS', 'MAS', 'CFS'에 대해 혹시 들어본적 있으신가요?? 어떤 새로운 하드웨어를 설계할때 사용하는 단어들인데요. 각각 아키텍쳐 스펙, 마이크로 아키텍쳐 스펙, 크로스 펑셔널 스펙의 줄임말입니다.
갑자기 이더리움에 왜 하드웨어를 끼얹으시나요? 라고 물으신다면, 뭔가 익숙하지 않은 날 것의 이더리움이, 주로 저런 다듬어진 스펙들에 둘러쌓여 살아왔던 저에겐 소화하기 너무 어려웠기 때문이라고 대답하겠습니다. 이더리움에 대해 공부를 하면 할수록, 제대로된 문서화가 아쉽다는 느낌을 지울수가 없었거든요.
물론 현존하는 이더리움 위키와, 각 구현체별 위키에 방대한 내용들을 무시하는 것은 절대 아닙니다. 여기서 제대로라 함은 "정리된"으로 해석하셔도 무방할것 같습니다. 왜 정리된 자료가 필요할까요?
==== 스펙에도 종류가 있습니다.===
흔히들 하드웨어 스펙이라고 하면, 한권짜리 두툼한 프린트물을 생각하실것 같아요.
소프트웨어 개발자들께서는 '저 제본 책은 냄비 받침인걸까?' 라는 반응을 가질수도 있겠네요.
그런데 사실 스펙에는 다양한 종류가 있습니다.
아키텍쳐 스펙.
기본적으로 이더리움 백서+황서 라고 보면 될것 같습니다. 이더리움은 이런 철학으로 만들어졌고, 이런 이런 모듈을 가지고 있으며, 각 모듈은 이런 이런 동작을 처리해야 한다를 정의하게 되는 부분입니다. 그러다보니 각 모듈의 전체를 담당하는 아키텍트들이 존재합니다. "전체적인 동작에서 이 모듈은 이런 일을 담당하겠다" 를 정의하는 것이 아키텍쳐들의 주 업무가 되겠죠. 이건 한번 수정되면, 프로젝트의 큰 변화가 일어나게 됩니다. 그렇기 때문에 통찰력을 가진 몇몇 고수들의 영역이라고 봐도 무방합니다.
이더리움 P2P 패키지를 예를 들어 볼까요?
p2p패키지는 모든 딜리버리와 싱크를 담당하고 있고 그에 관련된 모든 패키지를 포함합니다.
딜리버리와 싱크는 내가 전담할테니, 걱정말고 데이터를 넘기시오! 내머릿속에 어떤 어떤 패키지로 어떻게 운용할지 다 정리해뒀습니다! 뭐 이런거구요. 문제 발생시 어디를 어떻게 고치는게 전체적인 그림에서 좋은지 판단도 해야합니다( 개발자님 그렇게 고치면 당장은 동작이 되지만, 전반적으로는 안좋아 질것 같은데요..라던지...)
마이크로 아키텍쳐 스펙
아키텍쳐들이 정의한 각 구성의 동작을 실제 구현체로 표현할 때 작성하는 문서입니다.(엔지니어가 만드는 스펙!) 그러다보니 대부분의 엔지니어들이 이곳에 삽니다. 어떻게 구현했는지, 왜 그래야만 했는지 성능상 이득을 보기위한 포인트는 어디어디인지 정리한 문서입니다. 특성상 자주 바뀌고, 바뀔때마다 조금씩 성능이 개선되거나, 버그가 사라집니다. 마이크로 아키텍쳐 스펙 작성자들은 아키텍쳐와 자주 토론을 해야합니다. 이상을 현실로 끌어오는 과정을 함께 극복해 나가야 하기 때문이죠.
이번엔 트라이 패캐지를 예를 들어 볼까합니다. 아키텍트님이 머클 패트리샤 트리를 사용하라고 하셨어요. 뭔가 증명을 해야된데요. 머클 패트리샤 트리를 그대로 사용하려니 DB 저장량이 커져서, 일단은 패트리샤 트리로만 구현하고 필요할때만 머클을 생성하도록 구현했어요. 성능은 거의 차이 없고 DB저장량은 20%이상 감소했어요. 뭐 이런겁니다. 굳이 이더리움코드로 따지자면 geth wiki나 코드상 주석, github/gitter등의 질답/로그 등등 이라고 볼수 있을것 같네요. (한글 주석 프로젝트도 같은 선상에서 진행되고 있어요..뭐라도 기여할만한 부분이 있을까? 하는 거죠.)
크로스 펑셔널 스펙 (가장 이더리움 코드를 보면서 가장 안타까워 하는 부분입니다.)
크로스 펑셔널 스펙은 각 모듈간 인터오퍼레이션(Inter-op)을 정리한 문서입니다 A모듈과 B모듈은 어떤 어떤때에 서로 동작을 하게 되는데, 이때 뭐가 필요하고 뭘 해야하고..이런것을 정의하는 것이죠. 제가 패키지별로 분석을 시작하게 된 이유도,사실은 이거였습니다. 이더리움 코드는 상당히 복잡하게 서로 얽혀있는 형태인데, 코드를 따라 돌아돌아 다니다보면 제자리로 돌아오는게 다반사거든요. 이 패키지는 어떤 상황에서 어떤 역할을 하고, 누구랑 협업을 하는지만 정의가 잘되어 있다면, 보기좋고 읽기도 좋은 훌륭한 교과서로서 이더리움이 자리잡을수 있을것 같습니다. 아무래도 협의가 가장 많이 필요한 부분이다 보니, 크로스 펑셔널 스펙을 작성할때는 AS/MAS 작성자들이 모두 모여서 협의를 통해 완성합니다.역할의 배분이나 이런것이 전체 성능에 큰 영향을 미치기 때문이고, 아주 가끔 내가 고쳐야 하는게 맞지만 니가 고치면 전체적으로 좋아지는 경우도 나옵니다. (물론 이건 아키텍쳐가 조금 잘못 설계되었다고 봐야하지만...완벽한 아키텍처는 처음부터 존재하지 않죠). 이 부분을 제 블로그가 채울수 있도록 조금씩 정리해가고 있는것이고 현재로는 많이 부족합니다.
==== 꿈꾸는 자가 계속 꿈을 이어가도록 ====
예전에 어떤분께서 저에게 질문을 주셨어요. 메인넷 만드는건 어려운 일이라는걸 누구보다 잘 알고 있을텐데 계속 이더리움 코어를 분석하는 이유는 무엇인지, 코어보다는 dapp을 고려할 타이밍이 아닐지.
"저 역시도 아직은 아키텍쳐가 될 깜냥의 그릇은 아니기에, 메인넷을 반드시 만들어야지 하며 코어를 공부하는건 아닙니다. 다만, 누군가 꿈꾸는 사람이 있을때 그 꿈을 현실화 시켜줄 사람이 내가 될수 있기 때문에 하고 있다"고 답변을 드렸던 기억이 있습니다.
현재 많은 분들이 다양한 방식과 개발론으로 코드를 분석하고 개선해 나가고 있을것이라 생각합니다.
이더리움 코드를 분석하고, 문서화 하고, 공유하는 작업은 누군가의 단순한 개인 만족으로 해석될 수도 있으나, 누군가에게는 내가 좋아하는 기술이 발전할 수 있도록, 내가 한번 밟은 길을 깨끗히 닦아두는 훌륭한 일이 될 수 있습니다. 다양한 문서들이 어느정도 동일한 기준을 가지고 만들어 진다면 엄청난 힘을 만들어 낼수 있지 않을까 하는 생각에 몇자 남겨봅니다.
물론, 하드웨어적인 접근으로 인해 풀수 없는 소프트웨어 개발 세계만의 어떤것도 있을 것입니다. 그냥 저렇게 생각하는 사람도 있구나 정도로 너그러이 지나쳐주시길 바라며. 또한 저뿐만아니라, 이더리움 연구회에서도 다양한 노력들이 지속되고 있으니 많은 응원 부탁드립니다.
오늘도 이멘!
