백서는 프로젝트의 문제 정의·설계·경제 구조를 설명하는 주장 문서이며 구현이나 성능 검증 결과가 아니다. 핵심 주장마다 공개 코드·배포 계약·재현 가능한 측정·권한 구조를 연결해 읽어야 한다.
백서는 검증 결과가 아니라 주장 문서다
백서는 프로젝트가 문제·설계·경제 구조를 설명하는 문서일 뿐 감사·법적 공시·구현 완료 증명은 아니므로, 주장·코드·권한·측정 가능한 이정표를 나눠 읽어야 한다
백서는 프로젝트가 해결하려는 문제, 설계, 토큰 역할을 설명하는 제안 문서다. 실제 코드가 배포됐는지, 성능이 재현되는지, 약속한 권리가 법적으로 존재하는지는 별도 증거로 확인해야 한다. 문서 공개 자체는 검증 완료가 아니다.
백서는 질문의 출발점이며 공개 코드·배포 상태·재현 가능한 측정이 답을 보강한다.
JOBCOIN 해설
문제·구현·경제 구조를 읽는 순서
먼저 해결하려는 문제와 기존 대안 대비 필요한 이유를 본다. 이어 합의·계약·데이터 흐름을 실제 구현과 비교하고, 토큰이 기능에 꼭 필요한지 확인한다. 공급·배분·언락·관리자 권한을 표로 옮긴 뒤 저장소·감사·메인넷·거버넌스 증거를 연결한다.
먼저 현재 방식의 어떤 비용을 줄이려는지 읽고, 다음으로 데이터 흐름과 신뢰 주체를 그린다. 마지막에 토큰 발행·배분·권한이 그 기술에 꼭 필요한지 본다. 토큰 가격 전망부터 읽으면 설계의 빈칸을 놓치기 쉽다.
설계 주장·구현 증거·경제 약속 비교
설계 주장은 합의·네트워크 구조로, 구현 증거는 공개 코드·테스트넷·측정 방법으로 확인한다. 경제 약속은 공급 일정·수수료 수취·거버넌스 권한으로 나눈다. 서로 다른 증거를 한 장의 로드맵으로 대신할 수 없다.
| 구분 | 작동 방식 | 확인 포인트 |
|---|---|---|
| 설계 주장 | 어떻게 작동할 것인지 설명 | 가정·위협 모델·비교 기준 |
| 구현 증거 | 코드·배포 계약·테스트 결과 | 버전·재현성·메인넷 주소 |
| 경제 약속 | 공급·배분·보상·권리 | 언락·변경 권한·법적 의무 |
초당 10만 건 주장을 검증하는 질문
'초당 10만건'이라는 수치가 있어도 테스트 환경, 거래 정의, 하드웨어, 데이터 가용성, 최종성 조건이 없으면 비교할 수 없다. '탈중앙화'라는 문구도 검증자 수보다 관리자 키·업그레이드·프론트엔드 의존성을 확인해야 한다.
초당 10만 건이라는 수치에는 거래 복잡도, 노드 수, 하드웨어, 최종성 시간, 실패율, 데이터 가용성 조건이 필요하다. 제한된 실험의 서명 전송 수를 실제 메인넷 사용자 거래 처리량으로 소개했는지 살핀다.
수식이 많아도 증거가 되지는 않는다
수식과 기술 용어가 많다고 검증된 문서는 아니다. 출처 없는 시장 규모, 익명 파트너, 보장 수익, 확정되지 않은 상장 계획을 근거처럼 받아들이지 않는다. 백서 날짜가 오래됐으면 최신 코드·거버넌스와 달라졌을 수 있다.
수식은 가정을 명확히 표현할 수 있지만 입력값이 현실에서 관측 가능한지와 공격 상황을 다루는지는 별도다. 출처 없는 매개변수, 정의되지 않은 기호, 결과만 제시한 시뮬레이션은 재현 증거가 아니다.
주장별 증거표 만드는 법
문서의 핵심 문장을 주장, 필요한 증거, 현재 확인 상태로 쪼갠다. 저장소 커밋, 배포 계약, 성능 보고서, 감사 문서의 날짜와 버전을 연결한다. 향후 계획은 완료 항목과 분리하고 변경 이력도 기록한다.
- 문서 버전·발행자·변경 이력을 확인한다
- 핵심 주장마다 구현 또는 독립 검증 링크를 붙인다
- 토큰 권리와 회사 지분·수익 권리를 구분한다
- 실패 조건·관리자 권한·중단 시 출구를 찾는다
기술 성공과 토큰 가치의 간격
백서 검토는 투자 적합성 판정이 아니다. 기술이 작동해도 토큰 가치가 생긴다는 보장은 없고, 시장 수요가 있어도 보안·법률 위험이 사라지지 않는다. 모르는 항목을 점수로 억지 환산하기보다 '확인됨·주장만 있음·상충·미확인'으로 표시하면 업데이트가 쉽다.
기술이 의도대로 작동해도 토큰 수요가 생기거나 보유자에게 수익이 귀속된다는 결론은 자동으로 나오지 않는다. 서비스 이용자가 토큰을 써야 하는지, 수수료가 누구에게 가는지, 희석이 어떤지 별도로 분석한다.
토큰 배분표에서는 총비율이 100%인지뿐 아니라 베스팅 시작일, cliff, 선형 해제 기간, 조기 해제 권한을 본다. 팀·투자자·재단 주소가 실제 온체인 잠금 계약에 들어갔는지 확인하지 않으면 표는 운영 약속에 머문다. 거버넌스가 일정을 바꿀 수 있는지도 중요하다.
백서 버전이 바뀌면 삭제된 약속과 새로 추가된 위험을 추적한다. 웹페이지 최신본만 읽지 말고 발행일과 파일 해시, 저장소 태그를 보관한다. 구현이 백서와 달라졌다면 무조건 실패라고 결론 내리기보다 변경 제안과 보안상의 이유, 이용자에게 공지된 범위를 확인한다.
감사 보고서가 있으면 대상 커밋과 범위 밖 항목, 미해결 지적을 확인한다. 백서가 설명한 핵심 모듈이 감사에서 제외됐거나 배포 후 변경됐다면 보고서 표지만으로 현재 시스템을 평가할 수 없다. 수정 확인서도 같은 버전인지 대조한다.
자주 묻는 질문
백서가 있으면 신뢰할 수 있나요?
아니다. 누구나 작성할 수 있어 코드·공시·배포 증거와 교차검증해야 한다.
기술 수치는 어떻게 검증하나요?
측정 환경·단위·최종성·하드웨어를 확인하고 재현 가능한 테스트나 독립 자료를 찾는다.
로드맵 지연은 사기 증거인가요?
지연만으로 단정할 수 없다. 변경 공지·자금·개발 활동·설명 책임을 함께 본다.
