백서를 써야 한다는 말은 대개 내부에서가 아니라 밖에서 먼저 옵니다.
투자 검토 자리에서, 거래소 서류 목록에서, 파트너 실사 요청에서 "백서 주세요"라는 한 마디로 시작됩니다.
그래서 첫 질문이 "우리 사업을 어떻게 설명할까"가 아니라 "언제까지 몇 장이 필요한가"가 되기 쉽습니다.
FD인터내셔널이 백서를 들고 오신 프로젝트와 마주 앉을 때 문서를 펼치기 전에 먼저 확인하는 것이 있습니다.
이 문서가 지금 필요한 것인가, 아니면 아직 정해지지 않은 것이 남아 있는가.
마감이 기준이 되면 문서는 나오지만 판단은 남지 않습니다
마감을 기준으로 쓰면 문서는 제 날짜에 나옵니다.
다만 그 문서를 근거로 다음 결정을 내리기는 어려울 수 있습니다.
완성된 백서를 앞에 두고도 팀 안에서 서로 다른 설명이 나온다면, 그것은 문서의 문제가 아니라 아직 정해지지 않은 것이 있다는 신호에 가깝습니다.
FD가 프로젝트를 볼 때 문서의 완성도보다 팀 안에서 같은 설명이 나오는가를 먼저 보는 이유입니다.
목차부터 채우면 문서의 순서가 사업의 순서를 밀어냅니다
목차는 이미 답의 순서가 정해진 질문지입니다.
칸을 채우기 시작하는 순간 사업의 순서가 아니라 문서의 순서를 따라가게 됩니다.
토큰 경제구조 항목이 앞에 놓이면 발행량과 배분 비율이 먼저 정해지고, 사업 설명은 그 숫자를 뒤늦게 정당화하는 자리로 밀립니다.
일반적으로 백서는 문제 정의, 해결 방식, 제품, 토큰 설계, 자본 구조, 로드맵, 팀 순으로 구성됩니다.
문제는 이 순서를 아는 것이 아니라, 앞 항목이 비어 있는 채로 뒤 항목이 먼저 채워지는 것입니다.
FD가 프로젝트를 볼 때 순서를 중요하게 보는 이유도 같습니다. 순서가 곧 효율입니다.
첫 장에는 "토큰이 없어도 성립하는가"라는 질문이 와야 합니다
"토큰 없이도 이 사업이 성립하는가"는 토큰을 부정하는 질문이 아닙니다.
토큰이 정확히 무엇을 해결하는지 분명히 하기 위한 질문입니다.
토큰이 없어도 고객과 매출이 존재한다면 토큰은 성장의 도구가 됩니다.
토큰을 빼면 남는 것이 없다면, 지금 쓰고 있는 것은 사업 계획이 아니라 발행 계획일 수 있습니다.
첫 장에 필요한 것은 비전 문장이 아니라 세 가지 답입니다.
누가 고객인가.
왜 지불하는가.
그 지불이 반복되는가.
이 세 답이 있는 사업 안에서 정확하게 설계된 토큰은 사업의 성장을 확장하는 강력한 디지털자산이 될 수 있습니다.
그렇다고 사업이 완성된 뒤에 토큰을 만들라는 뜻은 아닙니다
FD가 토큰보다 먼저 사업을 본다고 말하는 것은 실행 순서를 정해 놓는다는 의미가 아닙니다.
프로젝트에 따라 토큰이 초기 성장 과정에서 먼저 필요할 수도 있습니다. 네트워크 참여자를 확보하거나, 초기 커뮤니티를 만들거나, 생태계 인센티브를 제공하거나, 사업 확장을 위한 자본구조를 만드는 과정에서 그렇습니다.
중요한 것은 순서 자체가 아니라 그 순서를 선택한 이유가 명확한가입니다.
토큰을 먼저 발행하는 백서라면 첫 장에 그 이유가 적혀 있어야 합니다. 왜 지금 토큰이 필요한지, 이 토큰이 향후 어떤 사업에 연결되는지, 초기 보유자에게 어떤 역할을 제공할 것인지가 문서 안에 있어야 합니다.
토큰의 설계보다 사업의 논리가 먼저 존재해야 한다는 것이 원칙입니다.
토큰은 사업 구조가 정해진 뒤에 결정되는 변수입니다
토큰의 역할은 결제 수단, 접근 권한, 기여 보상, 거버넌스 등 여러 형태를 가집니다.
이 역할은 사업 모델에서 나오는 것이지, 먼저 고른 뒤 사업을 맞추는 것이 아닙니다.
역할이 정해지면 발행량과 배분은 그 역할을 수행하는 데 필요한 만큼으로 좁혀집니다.
수요가 어디서 발생하는지 문장으로 설명되지 않으면 발행량도 배분표도 근거 없는 숫자가 됩니다.
숫자는 논리의 결과이지 논리의 대체물이 아닙니다.
체인 선택, 발행 방식, 컨트랙트 구조도 같은 순서를 따릅니다. 기술은 사업을 위해 존재하지, 기술 사양이 사업을 정의하지 않습니다.
백서를 읽는 사람은 각자 다른 것을 확인합니다
| 읽는 사람 | 확인하는 것 |
|---|---|
| 투자자 | 성장 논리와 자본 구조 |
| 거래소 | 유통량과 상장 이후 운영 계획 |
| 법률 검토자 | 토큰의 성격과 권리 관계 |
| 파트너 | 실제 제품과 일정 |
토큰의 법적 성격에 대한 의견서는 법무법인이 발급하는 문서이며, 백서는 그 검토의 입력값이 됩니다.
한 문서가 이 서로 다른 시선을 함께 통과하려면, 모든 항목이 같은 사업 정의에서 나와 있어야 합니다.
항목마다 설명이 조금씩 어긋나는 백서는 대부분 사업이 바뀐 결과가 아니라 문서가 여러 번 덧칠된 결과입니다.
FD가 백서 자리에서 반복해서 마주치는 장면
FD인터내셔널이 백서를 들고 오신 분과 마주 앉으면 문서를 펼치기 전에 먼저 여쭙습니다.
"이 사업을 한 문장으로 말씀해 주시겠습니까."
여기서 막히면 문서를 고치는 것보다 사업 정의를 다시 잡는 편이 결과적으로 훨씬 빠릅니다.
백서가 이미 완성돼 있는데 대표님과 개발 총괄의 설명이 다른 경우가 드물지 않습니다. 문서가 팀보다 먼저 만들어졌을 때 특히 그렇습니다.
반대로 백서가 아직 한 장도 없는데 사업 설명이 또렷한 팀은 문서 작업이 오히려 빨리 끝납니다. 쓸 내용이 이미 팀 안에 있기 때문입니다.
"문서를 다듬어 달라"로 시작한 자리가 "이 토큰이 지금 시점에 필요한가"라는 질문으로 되돌아가는 일도 자주 있습니다.
그 자리에서 발행을 미루기로 한 판단이 결과적으로 더 나은 선택이 되기도 했습니다. 하지 않는 결정 역시 전략입니다.
다만 하지 않기로 했다면 거기서 끝나지 않습니다. 어떤 조건이 만들어지면 다시 검토할 것인지, 그때까지 무엇을 준비할 것인지를 함께 설계합니다. 하지 않는 것에도 다음 계획이 있어야 합니다.
백서 파일을 열기 전에 스스로 답해볼 질문
- 이 사업은 토큰이 없어도 고객이 존재하는가. 존재한다면 그 고객은 지금 무엇에 지불하고 있는가.
- 토큰이 해결하는 문제를 한 문장으로 말할 수 있는가. 그 문장이 팀 전원에게 동일한가.
- 지금 필요한 것이 백서라는 문서인가, 아니면 사업 구조에 대한 판단인가.
- 이 문서를 가장 먼저 읽을 사람이 누구이고, 그 사람이 확인하려는 것은 무엇인가.
네 질문에 답이 나오면 목차는 그다음에 채워집니다.
답이 나오지 않는 칸이 있다면 그 칸이 지금 백서보다 먼저 해야 할 일입니다.
백서는 잘 쓰인 문서가 아니라 잘 내려진 판단의 기록입니다
문장이 정리되지 않는다면 대개 표현이 부족한 것이 아니라 아직 정해지지 않은 것이 남아 있는 것입니다.
그 상태에서 목차를 채우면 문서는 완성되지만 판단은 남지 않습니다.
FD인터내셔널이 프로젝트와 마주 앉을 때 늘 같은 자리에서 시작하는 이유도 여기에 있습니다.
토큰보다 먼저 사업을 봅니다.
순서를 지키면 문서는 그다음에 따라옵니다.