지난 몇 달간 블록체인 기술을 공부하면서 여러 블록체인 ICO 기술 백서를 읽고 몇 개의 ICO에 직접 참여해 보기도 하였습니다.

좋은 ICO와 나쁜 ICO를 구분하는 방법에 정답은 없지만, 소프트웨어 엔지니어 입장에서 최소한의 기준을 이야기해 보려고 합니다.

기술 백서

단순히 기술 백서가 존재하는 것만으로 충분하지 않습니다. 기술 백서의 내용이 명확하고 검증 가능해야 합니다. 많은 프로젝트가 합의 알고리즘의 성능 개선을 말하면서 구현 없이 아이디어와 성능 목표치만 이야기하는데, 성능은 실제로 구현하고 숫자로 증명하지 않는 이상 아이디어만 가지고는 아무 것도 안 한거나 마찬가지입니다.

그럴 듯해 보이는 아이디어도 실제로 구현하면 예상치 못한 이유로 성능이 안 나오는 경우가 많고, 겨우 겨우 성능 목표를 달성해도 버그 투성이 코드가 되거나 유지 보수가 불가등 할 정도로 복잡한 코드가 나오는 경우도 비일비재합니다.

구현해서 검증하지 않은 성능 개선 방법을 대단한 기술처럼 포장해서 보여주는 백서는 그만큼 기술적으로 보여줄 게 없다는 반증입니다. 리눅스 토발즈의 명언을 다시 한 번 인용합니다. “Talk is cheap. Show me the code.”

소스 코드

GitHub에 소스 코드가 공유되어 있어야 합니다. 단순히 코드를 공개한 것만으로는 부족합니다. 소스 코드 공개 후에도 지속적인 활동이 있어야 합니다. 매일 새로운 코드, 이슈, PR이 올라오고 활발한 개발 활동이 일어나야 합니다. 그게 아니라면, 그저 소스 코드가 있다는 걸 보여주기 위한 요식 행위일 가능성이 큽니다.

다른 프로젝트를 포크해서 시작한 프로젝트의 경우, 포크 이전과 이후를 구분해서 포크 이후에 얼마나 수정이 이루어졌는지를 파악해야 합니다. 이미 ICO를 받은 국내의 한 프로젝트는 stellar-core를 포크하여 README만 조금 고친 후에 전혀 개발 활동이 이루어지지 않았습니다. 물론 내부적으로 개발이 이루어지고 있을 수도 있곘지만, 개발 활동을 숨겨야 한다면 뭔가 이유가 있는 거겠죠.

그리고 개발팀에 포함된 개발자들이 실제 개발 활동을 하는지도 확인해야 합니다. 개발팀 명단에 이름만 올려놓고 실제로 개발에 참여하지 않는 개발자들이 생각보다 많습니다. 반대로 상당한 양의 코드를 작성한 개발자가 개발팀에 포함되지 않은 경우도 있습니다. ICO용으로 PoC 코드만 외주를 줬을 가능성도 있고, 개발팀은 개발 역량이 없을 가능성도 의심해야 합니다.

많은 ICO 프로젝트가 ICO 자체를 수익 모델로 하고 있습니다. 그러다 보니 기술 백서, 소스 코드 공개도 요식 행위 수준에서 이루어지고 있습니다. 다른 사람은 몰라도 소프트웨어 엔지니어라면 기술 백서, 소스 코드 존재만 확인하지 말고, 그 내용까지 꼼꼼히 살펴보시고 기본이 튼튼한 프로젝트에 투자하시기 바랍니다.