솔직히 말하면 백서를 처음 열었을 때 첫 페이지에서 덮은 적이 한두 번이 아닙니다. 영어에 기술 용어까지 빽빽하게 들어차 있으니 그나마 지금은 국문도 있지만, 눈이 먼저 돌아갑니다. 그런데 투자를 어느 정도 해보고 나서 깨달은 게 있습니다. 백서를 전부 이해할 필요는 없지만, 몇 가지 핵심만 골라 읽을 줄 아는 것과 아예 안 읽는 것은 완전히 다른 결과를 낳는다는 것입니다. 백서가 뭔지, 뭘 봐야 하는지 하나씩 짚어보겠습니다.
1. 코인 백서가 의미하는 것
백서(Whitepaper)는 원래 정부나 기업이 특정 정책이나 기술에 대한 공식 입장을 담아 발표하는 문서를 뜻하는 말이었습니다. 암호화폐 세계에서 백서는 새로운 코인이나 블록체인 프로젝트가 세상에 나올 때 발표하는 공식 기술 문서를 가리킵니다.
쉽게 말하면 이 프로젝트가 어떤 문제를 해결하려 하는지, 어떤 기술로 그걸 구현하는지, 토큰은 어떻게 발행하고 운영할 것인지를 담은 프로젝트의 이력서이자 설계도입니다.
백서의 시초는 2008년 사토시 나카모토가 발표한 비트코인 백서입니다. 단 9페이지짜리 문서였지만, 탈중앙화된 전자 화폐 시스템의 작동 원리를 명확하게 설명하며 암호화폐 혁명의 출발점이 됐습니다.
이후 모든 암호화폐 프로젝트는 백서 발표를 정식 론칭의 첫 단계로 삼는 것이 업계의 관례가 됐습니다. 백서가 없는 프로젝트는 신뢰하기 어렵고, 백서가 부실하거나 다른 프로젝트를 베낀 흔적이 있다면 그 자체로 심각한 경고 신호입니다. 투자 전에 백서를 확인하는 습관은 선택이 아니라 기본 중의 기본입니다.
2. 코인 백서에 꼭 있어야 할 내용
백서를 처음 보는 분이라면 어디서부터 봐야 할지 막막할 수 있습니다. 수십 페이지짜리 기술 문서를 처음부터 끝까지 읽기보다, 아래 여섯 가지 항목이 백서 안에 제대로 담겨 있는지 먼저 확인하는 것이 훨씬 효율적입니다. 제대로 된 프로젝트라면 반드시 이 내용들이 구체적으로 서술되어 있어야 합니다.
첫째, 문제 정의(Problem Statement)입니다. 이 프로젝트가 어떤 현실적인 문제를 해결하려 하는지 명확히 서술되어 있어야 합니다. 문제 정의가 모호하거나 너무 거창하기만 하면 실체가 없는 경우가 많다고 합니다.
둘째, 해결책과 기술 구조(Solution & Technology)입니다. 문제를 어떤 기술로 해결하는지, 기존 기술과 무엇이 다른지 설명이 있어야 합니다. 기술 설명이 지나치게 추상적이거나 검증되지 않은 주장만 나열되어 있다면 주의가 필요합니다.
셋째, 토크노믹스(Tokenomics)입니다. 토큰 총 발행량, 팀·투자자·생태계 배분 비율, 락업(잠금) 기간이 구체적으로 나와 있어야 합니다. 팀 보유 비율이 지나치게 높거나 락업 기간이 없다면 러그풀 위험 신호일 수 있습니다.
넷째, 로드맵(Roadmap)입니다. 단계별 개발 계획과 목표 시기가 명시되어 있어야 합니다. 로드맵이 지나치게 낙관적이거나 이미 지난 시기의 목표가 달성되지 않았다면 실행력을 의심해봐야 합니다.
다섯째, 팀 정보(Team)입니다. 개발팀과 어드바이저의 실명과 경력이 공개되어 있어야 합니다. 익명 팀이라면 그만큼 책임 소재가 불분명하다는 뜻이고, 링크드인에서 경력을 직접 확인해 보는 것도 좋은 방법입니다.
여섯째, 경쟁 프로젝트와의 차별점(Competitive Analysis)입니다. 비슷한 목표를 가진 기존 프로젝트들과 비교해서 왜 이 프로젝트가 필요한지 설명이 있어야 합니다. 차별점이 없거나 경쟁 현황 자체를 언급하지 않는 백서는 완성도가 낮다고 할 수 있습니다.
이 여섯 가지 항목이 구체적이고 일관성 있게 서술되어 있다면 일단 기본은 갖춘 백서입니다. 반대로 화려한 디자인과 그럴듯한 문구만 가득하고 위 내용이 두루뭉술하게 처리되어 있다면, 아무리 마케팅이 요란해도 신중하게 접근하는 것이 맞습니다.
3. 코인 백서 쉽게 읽기
백서를 처음부터 끝까지 완독 하려다 포기하는 경우가 대부분입니다. 사실 기술 백서는 개발자가 아닌 일반 투자자를 위해 쓰인 문서가 아닌 경우도 많습니다. 그러니 전부 이해하려는 욕심은 처음부터 내려놓는 것이 좋습니다. 대신 이 순서대로 읽으면 핵심을 훨씬 빠르게 파악할 수 있습니다.
가장 먼저 초록(Abstract 또는 Executive Summary)을 읽어보시기 바랍니다. 백서 맨 앞에 있는 한두 페이지짜리 요약문으로, 이 프로젝트가 무엇인지 한눈에 파악할 수 있습니다. 여기서 읽히지 않으면 나머지를 읽어도 이해하기 어렵습니다.
다음은 문제 정의와 해결책 부분입니다. 이 프로젝트가 왜 존재해야 하는지 납득이 되는지를 스스로에게 물어보면서 읽으면 됩니다. 납득이 안 되면 굳이 더 읽을 필요가 없습니다.
그다음은 토크노믹스 항목입니다. 숫자가 나오는 부분이라 읽기 부담스럽지만, 팀 보유 비율과 락업 기간만큼은 반드시 확인해야 합니다. 이 두 가지가 불투명하면 다른 내용이 아무리 좋아도 리스크가 큽니다. 마지막으로 로드맵과 팀 정보를 확인하면서 실현 가능성과 팀의 신뢰도를 짚어보시면 됩니다.
기술적인 부분이 이해가 안 된다고 해서 자책할 필요는 없습니다. 백서를 읽다가 모르는 용어가 나오면 찾아보거나 넘어가면 되고, 커뮤니티에서 다른 사람들이 분석한 내용을 참고하는 것도 좋은 방법입니다. 중요한 건 읽었느냐 아니냐가 아니라, 핵심 항목들을 스스로 확인하고 납득이 됐느냐입니다.
백서를 100% 이해하는 전문가가 되지 않아도 됩니다. 다만 내 돈이 들어가는 프로젝트의 설계도를 한 번도 열어보지 않는 것과, 핵심만 골라 훑어보는 것의 차이는 생각보다 훨씬 크다는 것을 꼭 기억하시기 바랍니다.