체인을 고르는 자리에는 대개 비교표가 먼저 올라옵니다.
처리 속도와 수수료와 생태계 규모가 나란히 적힌 표를 보고 있으면 곧 답이 나올 것 같습니다.
그런데 정작 몇 년 뒤 프로젝트를 갈라놓는 변수는 그 표에 적혀 있지 않습니다.
비교표는 우리 사업의 질문에 답하지 못합니다
비교표의 숫자는 이상적인 조건에서 측정된 값이고, 실제 서비스는 그 조건에서 돌지 않습니다.
사업에 영향을 주는 것은 혼잡할 때의 수치이고, 그 혼잡이 언제 오는지입니다.
더 중요한 것은 그 숫자가 우리 병목이 아닐 가능성입니다. 초기 서비스 규모에서 처리 성능이 병목인 경우는 드물고, 병목은 대개 사용자가 지갑을 만들다 이탈하는 지점에 있습니다.
비교표는 "어느 쪽이 더 좋은가"를 묻지만, 실제 질문은 "우리 사용자와 운영 조직에 무엇이 맞는가"입니다.
FD인터내셔널이 기술을 논의할 때 "무엇을 개발할 수 있는가"보다 "사업을 구현하기 위해 무엇이 필요한가"를 먼저 보는 이유입니다. 기술은 사업을 위해 존재합니다.
질문 1 · 사용자가 누구인지에 따라 선택지 전체가 달라집니다
이미 지갑을 쓰는 사람인지, 우리 서비스에서 처음 만들 사람인지에 따라 선택지가 달라집니다.
후자라면 첫 사용 과정의 이탈 지점이 그대로 사업 지표가 됩니다.
어느 지역, 어떤 환경에 있는지도 조건입니다. 모바일 중심인지, 어떤 지갑이 깔려 있는지, 자산을 현금으로 바꾸는 통로가 열려 있는지.
사용자가 이미 다른 곳에 자산을 들고 있다면 그 자산이 있는 곳이 후보를 좁힙니다. 자산을 옮기게 만드는 순간이 가장 큰 이탈 지점입니다.
질문 2 · 수수료를 누가 내는지는 기술 항목이 아니라 원가 항목입니다
사용자가 직접 낸다면 수수료 변동이 그대로 사용자 경험의 변동이 됩니다. 소액 결제나 소액 보상 모델은 수수료가 조금만 올라도 성립하지 않습니다.
운영사가 대신 낸다면 그것은 기술 항목이 아니라 원가 항목입니다. 사용자가 늘수록 함께 늘어나는 변동비이므로 손익 모델 안에 들어가 있어야 합니다.
수수료를 자체 토큰으로 받는다면 사용자가 그 토큰을 미리 확보해야 합니다. 이 한 단계의 장벽은 거의 언제나 과소평가됩니다.
이 질문에 답이 없으면 어떤 체인을 골라도 같은 문제가 반복됩니다.
질문 3 · 진입 이후 운영을 맡을 사람이 지금 팀에 있어야 합니다
개발이 끝난 뒤에도 매일 누군가는 키를 관리하고, 지갑을 지키고, 발행·소각·전송 기록을 회계와 맞춰야 합니다.
이 일을 할 사람이 지금 팀에 있는지가 선택의 조건이 됩니다.
유통 관리와 유동성 관리는 개발 조직의 업무가 아닙니다. 그런데 체인 선택이 이 두 가지가 실제로 가능한 범위를 미리 결정해버립니다.
그 환경에서 일해본 개발자를 구할 수 있는지, 회계·감사·수탁 지원이 있는지도 운영 난이도를 좌우합니다.
운영 주체가 정해지지 않은 상태에서 내린 기술 판단은 결국 나중에 운영을 맡게 된 사람이 감당합니다.
FD가 전략을 만들 때 계획을 실제로 실행해야 할 사람과 조직의 역량까지 포함해서 설계하는 이유입니다.
토큰 표준은 기능 선택이 아니라 의무 선택입니다
표준을 고르는 순간 따라오는 것은 기능이 아니라 제약입니다.
전송에 조건을 걸 수 있는지.
발행과 소각 권한을 누가 갖는지.
락업을 코드로 강제할지 계약서로 관리할지.
코드로 강제한 조건은 나중에 바꿀 수 없고, 문서로만 정한 조건은 지켜지고 있음을 계속 증명해야 합니다. 어느 쪽이 맞는지는 사업 구조가 결정합니다.
관리자 키가 무엇을 할 수 있는지, 몇 사람이 어떻게 나눠 갖는지는 실사에서 되풀이해 나오는 항목입니다.
그래서 표준 선택은 개발팀 단독 판단이 될 수 없습니다. 법률 검토와 재무가 같은 자리에 앉아야 하는 판단이며, 법률의견서는 법무법인이 발급합니다.
되돌리는 비용을 먼저 계산합니다
나중에 옮기는 일은 기술적으로 가능하지만, 실제 비용은 사람에게서 발생합니다.
보유자 명부, 교환 공지, 교환되지 않는 물량 처리, 파트너 재계약이 전부 사람의 일입니다.
시장에 나간 뒤의 이전은 가격과 신뢰에 영향을 주고, 그래서 옮겨야 하는 줄 알면서도 오래 버티는 팀이 생깁니다.
선택 기준 하나는 "얼마나 좋은가"가 아니라 "틀렸을 때 얼마나 싸게 고칠 수 있는가"여야 합니다.
되돌릴 여지를 남기는 설계는 비관적인 태도가 아니라 비용 절감입니다.
질문 순서만 바꿔도 같은 회의가 다른 결론을 냅니다
성능 비교로 시작한 회의는 결론이 잘 나지 않습니다.
반면 사용자·수수료·운영 세 질문으로 시작한 회의는 대개 후보가 두세 개로 좁혀진 채 끝납니다.
좁혀지고 나면 남은 후보 사이의 차이는 대부분 사업적으로 무의미해집니다. 그때부터는 개발팀이 익숙한 쪽을 고르는 것이 합리적입니다.
반대로 사업 질문에 답하지 못한 채 고른 체인은 첫 사용자 유입 시점에 문제가 드러납니다. 그 시점이 고치는 데 가장 비싼 시점입니다.
비교표는 검색으로 구할 수 있지만 질문 순서는 그렇지 않습니다. FD가 반복된 실행에서 축적한 것도 답이 아니라 질문의 순서입니다.
기술 후보군은 판단 순서의 마지막 칸에 놓습니다
사용자 정의 → 수수료 부담 주체 → 운영 주체 → 규제·회계 요건 → 그다음이 기술 후보군입니다.
각 단계의 제약을 한 문장씩 적고, 만족하지 못하는 후보를 지웁니다. 남은 것 중에서 고릅니다.
판단 문서에는 "왜 골랐는가"보다 "무엇을 포기했는가"를 남깁니다.
그렇다고 기술이 덜 중요하다는 뜻은 아닙니다
어떤 프로젝트에서는 기술이 핵심 경쟁력입니다. 그때는 기술에 자원을 집중하는 것이 맞습니다.
FD가 말하는 것은 기술의 비중이 아니라 순서입니다. 사업과 디지털자산 구조를 구현하기 위해 필요한 기술 범위를 먼저 정하고, 그 안에서 무엇이 실제로 필요하고 무엇은 불필요한지 구분합니다.
정해지는 것은 체인이 아니라 사업의 조건입니다
체인과 표준을 고르는 자리는 개발 회의처럼 보이지만, 실제로 정해지는 것은 우리 사용자가 누구이고 비용을 누가 부담하며 몇 년 뒤 누가 이것을 운영할 것인가입니다.
순서를 바꾸는 데는 돈이 들지 않고, 순서를 잘못 잡은 대가는 시장에 나간 뒤에 청구됩니다.
FD인터내셔널이 기술 후보군을 보기 전에 사업 구조부터 확인하는 이유는 여기에 있습니다.
토큰보다 먼저 사업을 봅니다.