지난 칼럼에서 소프트웨어와 건축의 유사함에 대해 잠시 언급했다.

소프트웨어 공학에도 ‘아키텍처’라는 구조가 있다. 무릇 건축물에 구조가 없다면 말이 안 되고, 잘못된 구조는 커다란 참사로 연결된다. 슬프게도 잘못된 구조 설계와 관리로 건물이 무너지고 많은 피해가 발생하듯이, 소프트웨어도 잘못된 아키텍처(구조)가 시스템 안전에 큰 문제를 가져온다.

아키텍처는 단순히 기술 측면만의 문제가 아니다. 특히 블록체인은 BM(사업모델)을 중심으로 놓고 구조를 점검하고 설계해야 한다. 또 블록체인에서 거래 기록을 보관하는 블록은 ‘자료의 구조’라는 측면에서 아키텍처를 살펴야 한다. 소프트웨어를 공부한 사람이라면 쉽게 이해할 듯하다. 그리고 굳이 소프트웨어를 따지지 않더라도 우리가 많이 보는 장부나 장표와 같은 출력물, 기록을 위한 입력물 등을 봐도 마찬가지다. 잘 구성된 것과 허술한 양식은 장단점이 한눈에 보인다.



필자는 중앙에 대형 컴퓨터를 놓고 유저(User)들이 연결해 쓰던 시대에 공부했다. 메인프레임(Mainframe)이라 불리는 호스트 컴퓨팅 환경에서 프로그래밍을 해 본 마지막 세대쯤이 될 듯하다.

초기의 3세대 언어로 불리는 코볼(Cobol)은 사무용으로 최적화된 프로그래밍언어다. 지금은 거의 사용되지 않는다. 이렇게 된 이유는 기능의 문제보다 시대적 흐름 때문이다. 지금은 웹 기반 환경에서 진행하는 JAVA 개발이 최고로 꼽히는 상황이 됐다.

과거 코볼에서 쓰던 자료구조와 저장방식은 ‘파일시스템’ 기반이다. 데이터를 구조화해 같은 형태로 연속해서 저장하고, 필요한 경우 다시 불러서 작업한다. 흔히 순차적 접근이라고 표현한다. 독자 여러분이 A4지에 뭔가를 기록하고, 순서대로 클립으로 묶어서 보관하고 있다고 생각하면 쉽다. 이때 A4지에 넘버링을 하고 포스트잇으로 중간중간에 위치값을 붙이면 해당 자료를 찾기가 쉬워진다. 이를 ‘인덱스 작업’이라고 하고, ISAM(Indexed Sequential Access Method·색인순차접근방식)은 시스템 저장 방식으로 많이 사용됐다.

기술은 사용자 요구 또는 그 이상을 위해 진화·발전한다. 현재 대부분의 애플리케이션 시스템은 RDB(Relational Database·관계형 데이터베이스)라는 저장방식을 쓴다. RDB는 키(key)와 값(value)들의 간단한 관계를 정의하고 정규화(Normalization)라는 작업을 통해 값들이 중복되지 않도록 구성한다. 엑셀에 데이터를 정리하듯 테이블 형태로 저장하고, 필요하면 여러 개의 테이블을 합쳐 사용할 수 있도록 관리한다. 표 형태로 필요한 내용만 뽑아서 볼 수 있기 때문에 업무 내용을 다양한 형태로 보여주고, 한꺼번에 처리하도록 해주는 자료 구조다.

이제 블록체인으로 돌아와 보자.

블록체인은 저장하고자 하는 데이터를 블록이라는 형태로 순차적으로 기록한다. 해시(Hash)라는 점검 값을 생성해 다음 블록에 참조한다. 해시는 어떤 내용의 데이터든지 고정된 길이의 값으로 변환하는 함수의 계산 값이다. 블록의 값이 똑같이 유지되는지 확인하고, 블록의 내용을 중간에 바꿀 수 없도록 점검도 한다.

은행 통장을 생각하면 이해가 쉽다.

통장은 앞에서(처음에는 0) 넘어온 값에다 입금액을 더하고 출금액을 뺀 후 잔액을 기록한다. 앞칸의 잔액은 다음 칸의 기준값이 된다. 만약 수천 줄의 입출금이 기록돼 있는데 중간에 입금(또는 출금) 내용을 고치면, 해당 줄의 값부터 시작해서 마지막 값까지 모든 계산 값을 고쳐야 한다.

얼마나 힘들고 어려운 작업이 되겠는가? 거기에 통장내용을 수만 개가 넘는 곳에 똑같이 기록했다면 중간에 있는 금액을 변경(위변조)하는 일이 현실적으로 매우 어렵고 경우에 따라서는 불가능한 작업이라는 것은 쉽게 짐작이 된다. 더군다나 계속해서 입출금이 이뤄지고 있다면, 시도하는 것 자체가 ‘미션 임파서블’ 일 듯싶다.

‘빙고’라는 게임이 있다. 가로 5칸, 세로 5칸의 네모판에 임의의 숫자를 써 놓고 숫자를 뽑아서 가로, 세로, 대각의 직선을 먼저 만들면 이기는 게임이다. 운이 좋아서 직선이 돼야 하고 같이 만들었을 경우 ‘빙고’를 먼저 외쳐야 한다. 특별한 기술이나 능력보다는 행운과 집중력을 필요로 하는 복불복, 확률 게임이다. 나름 공평하게 기회가 주어지는 게임인데, 만약 참여자 중에 여러 사람이 모여 풀(Pool)을 만들고 구성원 중 누구든 ‘빙고’를 외치면 상품을 나눠 갖는다면 혼자 하는 것보다 승률은 높아진다. 물론 갖는 몫은 줄어든다. 어떤 방식이 좋은지는 각자의 판단이지만, 이길 확률과 효율은 뭉치는 것이 분명히 낫다.

패션에서 복고풍이라고 하면 과거에 유행했던 모습을 현재에 부흥시키는 것을 말한다. IT에서도 과거에 쓰던 기술을 보완 적용해 발전시키는 경우가 종종 있다. 메인프레임 중앙형에서 분산형으로 다시 호스트형에서 클라이언트-서버형으로 바뀌는 경우가 대표적 사례다.

최근에 많이 사용하는 RDB 방식이 아닌 예전의 파일시스템 방식을 접목해서 강점을 부각하고 있는 블록체인의 아키텍처를 살펴보고 있노라면, 언젠가는 파일시스템에서 RDB로 발전했듯이 블록체인도 RDB와 같은 방식이 제안되고 쓰일 것이라고 필자는 예측해 본다.

※ 필자주

블록체인 세계에서 벌어지고 있는 일들을 현실 세계와 소프트웨어 아키텍처를 넘나들면서 설명을 했다. 개발자에게는 지루한 기초적인 설명이고, 컴맹인 분들에게는 어려운 설명이 될 듯 하다. 그럼에도 우선은 이 칼럼의 목표인 ‘문송’ 탈출을 위해 당분간은 쉬운 이야기로 풀어가고자 한다. 최대한 쉬운 얘기로 쓴다고 썼지만, 기술 부분이 문과생에게는 어렵다는 독자분들이 계셔서 사족을 붙이게 됐다.

우승호 기자

derrida@sedaily.com