블록체인으로 서비스를 만들기로 판단하고 나면, 거의 예외 없이 따라오는 질문이 하나 있습니다.
어디까지를 체인 위에 올리고, 어디서부터는 지금까지 쓰던 서버에 그대로 두어도 되는가.
온체인이냐 오프체인이냐는 기술 취향의 문제가 아닙니다
이 질문은 개발팀 회의에서 시작되지만 실제로는 사업 질문입니다.
어떤 데이터를 체인에 올릴지 정하는 일은 "무엇을 앞으로 마음대로 바꾸지 않겠다고 약속할 것인가"를 정하는 일입니다.
온체인의 본질적 이득은 속도도 비용도 아니라 두 가지입니다.
되돌릴 수 없다는 것.
우리를 거치지 않고 제3자가 직접 확인할 수 있다는 것.
이 두 가지가 사업적으로 필요하지 않은 영역에 온체인을 쓰면 장점은 없고 제약만 남습니다.
반대로 웹2 구간이 남아 있다고 덜 웹3인 것도 아닙니다. 오래 운영되는 서비스들은 대부분 온체인과 오프체인이 섞여 있고, 섞여 있다는 것은 타협이 아니라 설계의 결과입니다.
FD인터내셔널이 기술을 독립된 목표가 아니라 사업을 실제 서비스로 구현하기 위한 실행 인프라로 보는 이유입니다.
체인 위에 올려야 하는 것은 외부가 직접 확인해야 하는 것들입니다
첫째, 운영사가 사라져도 사용자가 "내 것"이라고 주장할 수 있어야 하는 상태값입니다.
소유권과 잔액이 여기 해당합니다.
둘째, 여러 당사자가 같은 장부를 봐야 하고, 그중 누구도 상대를 전적으로 믿지 않아도 되어야 하는 정산·분배 논리입니다.
셋째, 외부가 운영사의 말을 거치지 않고 직접 확인해야 하는 약속입니다.
총발행량, 락업 해제 일정, 수수료율처럼 "말로 하면 믿기 어려운" 항목들입니다.
세 가지 중 어디에도 해당하지 않는데 온체인에 올라가 있는 기능은 대개 "웹3 프로젝트니까"라는 이유로 올라간 것입니다.
서버에 두는 편이 나은 영역도 분명히 있습니다
| 무엇 | 왜 |
|---|---|
| 개인정보와 신원 정보 | 지우기 어렵다는 온체인의 장점이 여기서는 그대로 법적 부담이 됩니다 |
| 자주 바뀌는 정책값 | 순위 가중치, 이벤트 보상 계수, 추천 논리처럼 시장 반응을 보며 손보는 값은 배포와 검증이 따라붙는 구조에 두면 운영 속도를 갉아먹습니다 |
| 즉각적인 반응을 기대하는 상호작용 | 처리 대기 시간을 사용자에게 전가하면 이탈로 돌아옵니다 |
| 사람의 판단이 필요한 예외 처리 | 오입금, 분쟁, 악용 대응을 수정이 어려운 코드에 넣으면 문제가 두 배가 됩니다 |
온체인 범위가 넓어질 때 늘어나는 것은 개발비만이 아닙니다
컨트랙트는 배포된 다음부터 수정 비용이 급격히 올라갑니다.
서버라면 하루면 끝날 수정이 온체인에서는 검증·이전·사용자 공지까지 함께 딸려옵니다.
온체인 코드는 공개되고 남습니다. 취약점은 곧바로 자금 문제로 이어지고, 보안 검증은 기능이 추가될 때마다 반복됩니다.
업그레이드 가능성을 열어두면 이번에는 "누가 바꿀 수 있는가"라는 권한 구조가 새로 생깁니다. 이 권한은 나중에 파트너와 투자자가 반드시 확인하는 항목이 됩니다.
그래서 온체인 범위는 개발비가 아니라 몇 년 치 운영 부담으로 계산해야 합니다.
기능이 아니라 그것을 유지하는 조직을 늘리는 판단이기 때문입니다.
경계선은 다섯 질문에 답한 뒤에 그으면 좁아집니다
- 이 데이터가 조작되었을 때 손해를 보는 사람은 누구인가. 그 사람이 우리 회사 바깥에 있는가.
- 이 기능을 앞으로 바꿔야 할 가능성이 있는가. 몇 달 안에 바뀔 것 같은가.
- 이것을 직접 확인하고 싶어 하는 외부 당사자가 실제로 있는가, 아니면 있을 거라고 우리가 가정하고 있는가.
- 이 값이 개인을 식별할 수 있는가.
- 온체인으로 만들면 사용자가 추가로 겪어야 하는 절차(지갑, 서명, 수수료, 대기)가 몇 개 늘어나는가.
다섯 질문에 답하고 나면 온체인 영역은 대개 처음보다 좁아집니다.
대신 그 영역은 훨씬 단단해지고 설명하기도 쉬워집니다.
FD가 반복해서 보는 것은 필요보다 넓게 잡힌 범위입니다
기획서에 온체인으로 표시돼 있던 기능을 하나씩 되물어보면, 상당수가 "기록해두면 좋겠다"는 이유였고 그 기록을 확인하겠다는 외부 당사자는 없었던 경우가 있습니다.
온체인 비중을 넓게 잡은 프로젝트일수록 첫 출시가 늦어지고, 그 사이 시장이 바뀌어 설계를 다시 손보는 순환에 들어가는 경우도 반복됩니다.
파트너사나 시장진입 실사 자리에서 실제로 확인하는 것은 온체인 기능의 개수가 아니라 권한 구조입니다. 관리자 키가 무엇을 할 수 있고 그 키를 누가 나눠 갖고 있는지가 반복해서 나옵니다.
축소는 늦게 할수록 비쌉니다. 배포된 것을 걷어내는 일은 만들지 않는 것보다 언제나 비쌉니다.
이 말을 먼저 꺼내기 어려운 자리도 있습니다
온체인 범위는 곧 개발 범위이고, 개발 범위는 곧 견적입니다.
실행을 수주하는 자리에서 "여기까지는 서버로 두셔도 됩니다"라는 말은 자기 매출을 줄이는 말이 됩니다. 나쁜 의도의 문제가 아니라 이해관계의 구조 문제입니다.
그래서 경계선은 실행을 맡지 않는 자리에서 먼저 긋고, 그다음 실행 파트너와 협의하는 순서가 안전합니다.
다만 좁힌 범위가 실행으로 이어지지 않으면 의미가 없습니다. 판단만 남기고 떠나는 자문은 부담만 늘립니다.
FD인터내셔널이 진단 다음에 설계와 실행, 운영까지 이어서 보는 이유도 여기에 있습니다. 자문은 실행으로 이어져야 합니다.
그렇다고 온체인을 줄이는 것이 목표는 아닙니다
어떤 사업에서는 온체인이 상품의 본체입니다. 규칙을 누가 어떻게 바꾸는지가 핵심 가치인 프로젝트라면 넓게 잡는 것이 맞습니다.
FD가 말하는 것은 범위의 크기가 아니라 범위의 근거입니다.
온체인이어야 할 이유를 설명할 수 있는 부분만 온체인이어야 합니다
온체인 비중이 높은 프로젝트가 좋은 프로젝트인 것이 아닙니다.
온체인이어야 할 이유를 문장으로 설명할 수 있는 부분만 온체인인 프로젝트가 오래 갑니다.
경계선을 좁게 긋는 일은 야심이 없어서가 아니라, 바꿔야 할 때 바꿀 수 있는 여지를 남겨두기 위해서입니다.
가장 저렴하게 실수를 수정할 수 있는 시점은 실행하기 전입니다.
FD인터내셔널이 기술 논의보다 사업 구조를 먼저 보는 이유는 하나입니다. 기술은 사업을 위해 존재합니다.