자체 메인넷을 준비하다 표준 체인으로 돌아오는 프로젝트가 있습니다.
밖에서 보면 실패처럼 보이지만, 옆에서 보면 그렇지 않습니다.
돌아온 것 자체는 좋은 판단입니다. 문제는 돌아오기까지 쓴 시간과 자원이고, 그 시간에 무엇을 놓쳤는지는 돌아온 프로젝트들 사이에서 놀랄 만큼 비슷합니다.
돌아오는 것은 실패가 아니라 수정입니다
먼저 분명히 할 것이 있습니다.
메인넷 계획을 접고 표준 체인으로 가는 것은 실패가 아니라 수정입니다. 방향이 틀렸다는 것을 알고 바꾼 팀이, 모르고 계속 간 팀보다 낫습니다.
그런데 수정에는 비용이 있습니다.
개발에 쓴 시간. 채용한 인력. 커뮤니티에 한 약속. 투자자에게 보여준 로드맵.
이 비용은 돌아오는 시점이 늦을수록 커집니다.
그래서 봐야 할 것은 왜 돌아왔는가가 아니라, 왜 그렇게 늦게 돌아왔는가입니다.
FD인터내셔널은 300건 이상의 거래소 시장진입을 지원하며 되돌아온 프로젝트를 여러 번 옆에서 봤습니다.
그 안에서 반복된 것은 기술 문제가 아니었습니다. 판단의 순서였습니다.
한두 건이면 우연이지만, 같은 순서가 반복되면 구조입니다.
놓친 것 1 · 사용자보다 체인이 먼저였습니다
돌아온 프로젝트들의 초기 로드맵을 보면 순서가 같습니다.
메인넷 개발 → 테스트넷 → 메인넷 출시 → 그다음 서비스.
사용자는 맨 뒤에 있습니다.
이 순서에서는 체인이 완성될 때까지 사용자가 없습니다. 사용자가 없으니 체인이 실제로 어떤 부하를 받을지, 어떤 기능이 필요한지 알 수 없습니다.
추측으로 만든 체인은 사용자가 왔을 때 맞지 않고, 그때 처음으로 "이 체인이 필요했나"라는 질문이 나옵니다.
표준 체인으로 돌아온 뒤에 이 프로젝트들이 가장 먼저 한 일은 서비스를 내는 것이었습니다.
처음부터 그 순서였다면 메인넷이 필요한지 여부는 서비스가 답했을 것입니다.
메인넷을 먼저 만드는 것이 목표 달성에 필요한 전략인 경우도 있습니다. 다만 그 경우 "왜 지금 체인이 필요한가"에 답이 있어야 하고, 돌아온 프로젝트들은 그 답이 없었습니다.
놓친 것 2 · 유지 비용이 개발비 옆에 적혀 있지 않았습니다
메인넷 예산은 대개 개발비로 잡힙니다.
그런데 체인의 실제 비용은 만드는 데 드는 것이 아니라 돌리는 데 듭니다.
노드 인프라. 검증자 보상. 장애 대응 인력. 탐색기와 지갑 지원. 자산 이동 통로의 보안.
이 비용이 매달 나가기 시작하면 프로젝트의 자금 성격이 바뀝니다. 성장에 쓸 돈이 유지에 들어갑니다.
돌아온 프로젝트들은 대개 이 시점에 판단했습니다. 체인이 완성돼서가 아니라, 체인을 유지하는 비용이 서비스를 만드는 비용을 넘어선 것을 확인한 시점입니다.
이 계산은 착수 전에 할 수 있었던 계산입니다. 몇 해 치 유지 비용을 개발비 옆에 적어보는 것만으로 답이 나오는 경우가 많습니다.
하지 않은 이유도 비슷합니다. 개발 견적서에는 유지 비용 칸이 없기 때문입니다. 견적서는 만드는 비용을 적는 문서이지 돌리는 비용을 적는 문서가 아닙니다.
놓친 것 3 · 되돌릴 수 있는 설계로 시작하지 않았습니다
가장 비싼 차이가 여기서 났습니다.
처음부터 표준 체인 위에서 시작해 나중에 옮길 수 있는 구조로 설계한 프로젝트와, 처음부터 독립 체인을 전제로 설계한 프로젝트는 돌아오는 비용이 달랐습니다.
전자는 돌아올 것이 없었습니다. 애초에 떠나지 않았기 때문입니다. 메인넷은 나중 선택지로 남겨두고 서비스를 먼저 만들었고, 필요해지면 옮길 수 있게 해두었습니다.
후자는 컨트랙트, 지갑 연동, 토큰 표준, 커뮤니티 약속까지 전부 독립 체인을 전제로 만들어져 있었습니다. 돌아오는 것은 수정이 아니라 재구축이었습니다.
미래의 선택지를 남기는 것 역시 자원관리의 일부입니다.
셋 다 기술 판단이 아니라 순서의 문제였습니다
세 가지를 나란히 놓으면 공통점이 보입니다.
사용자를 먼저 볼 것인가.
유지 비용을 먼저 계산할 것인가.
되돌릴 여지를 먼저 남길 것인가.
세 질문 모두 착수 전에 답할 수 있었고, 착수 뒤에는 답하는 비용이 계속 올라갔습니다.
더 큰 실행보다 더 나은 판단을 먼저. 이 원칙이 가장 비싸게 증명되는 곳이 자체 메인넷입니다.
돌아온 뒤에는 하지 않기로 한 판단을 문서로 남기게 됩니다
돌아온 프로젝트들에게 공통으로 생긴 것도 있습니다. 하지 않기로 한 판단을 문서로 남기는 습관입니다.
왜 접었는지, 어떤 조건이 되면 다시 검토할지.
그 문서는 다음 투자자 미팅에서 쓰였습니다. 무엇을 만들었는지보다 무엇을 왜 접었는지를 설명할 수 있는 팀이 더 신뢰를 얻었습니다.
그리고 대부분은 돌아온 뒤에 서비스를 냈습니다. 체인을 만들던 시간을 서비스에 썼더니 사용자가 생겼고, 그 사용자가 나중에 체인이 필요한지를 답해줬습니다.
체인을 접었다고 기술 역량이 사라진 것도 아니었습니다. 그 역량은 서비스 쪽에서 쓰였습니다.
개발이 절반쯤 진행된 시점에 여쭙는 것은 기술이 아닙니다
FD가 자주 보는 장면은 메인넷 개발이 이미 절반쯤 진행된 시점에 오시는 경우입니다.
이때 여쭙는 것은 기술이 아닙니다.
지금 사용자가 몇 명인가.
몇 해 치 유지 비용이 얼마로 계산돼 있는가.
지금 만든 것 중 표준 체인으로 옮길 수 있는 것이 얼마나 되는가.
세 답이 나오면 계속 갈지 돌아올지가 대개 정해집니다.
그리고 돌아오기로 한 경우, 가장 아까워하시는 것은 돈이 아니라 시간이었습니다.
프로젝트의 상태가 바뀌면 전략도 다시 진단되어야 합니다. 기존 체인을 쓰다가 사용자와 거래가 증가하면서 자체 네트워크가 필요한 시점이 올 수도 있습니다.
어느 방향이든 순서가 먼저입니다.