코인 백서 작성법: 회의적인 독자도 납득할 수 있는 문서

독자는 무엇을 결정할 수 있어야 하나요?

빠른 테스트: 팀 외부 사람에게 초안을 주고 확인할 수 없는 모든 주장에 밑줄을 긋도록 요청하세요. 어떤 섹션에 증거가 필요한지 즉시 알 수 있습니다.

코인 백서는 독자가 프로젝트가 제안하는 내용, 의도된 작동 방식, 그리고 불확실한 부분을 이해하도록 도와야 합니다. 작성 전에 누가 문서를 필요로 하고, 읽은 후 무엇을 평가할 수 있어야 하는지 결정하세요. 개발자는 아키텍처 세부 사항이 필요할 수 있고, 잠재적 토큰 보유자는 명확한 효용과 분배 정보가 필요할 수 있으며, 파트너는 프로젝트의 운영 모델을 이해해야 할 수 있습니다.

초안 작성 전에 팀을 위한 간단한 브리프를 작성하세요. 다음을 포함하세요:

• 주요 독자와 그들이 가져올 가능성이 높은 질문.
• 프로젝트가 해결하는 문제를 홍보성 주장 없이 표현.
• 문서가 다루는 내용과 별도의 기술 문서, 로드맵 또는 법적 문서에 속하는 내용.
• 독자가 다음에 취할 수 있는 조치(예: 문서 검토 또는 팀 연락).

이러한 브리프는 유용한 계획 점검 도구입니다. 제안된 섹션이 독자의 질문에 답하거나 프로젝트 주장을 입증하지 못하면 제거하거나 그 이유를 설명하세요. 백서는 모든 독자를 동등하게 만족시키려 해서는 안 됩니다. 프로젝트에 초기 대화를 위한 간결한 개요가 필요할 때는 라이트페이퍼가 더 나은 동반자가 될 수 있습니다. 두 문서는 서로를 반복하기보다는 별도의 역할을 가질 수 있습니다.

따라가기 쉬운 구조

강력한 구조는 독자의 문제에서 프로젝트의 제안된 솔루션으로 이동한 다음, 설계와 한계를 평가할 수 있는 충분한 세부 사항을 제공합니다. 모든 프로젝트에 필수적인 개요는 없지만, 예측 가능한 순서는 독자가 필요한 정보를 찾는 데 도움이 됩니다.

다음 순서로 문서를 구성하는 것을 고려하세요:

• 요약: 문제, 제안된 접근 방식, 의도된 사용자를 명시합니다.
• 맥락과 필요성: 현재의 어려움과 그것이 중요한 이유를 설명합니다.
• 솔루션과 제품: 사용자 경험과 시스템의 주요 구성 요소를 설명합니다.
• 기술 설계: 관련 아키텍처, 종속성, 구성 요소 간 상호 작용 방식을 설명합니다.
• 토큰 설계: 토큰이 존재하는지, 어떤 역할을 하는지, 공급과 할당이 어떻게 설명되는지 명시합니다.
• 로드맵과 거버넌스: 현재 역량과 계획된 작업을 구분하고 누가 결정을 내리는지 설명합니다.
• 위험과 가정: 중요한 종속성, 미해결 질문, 가능한 제약 조건을 명시합니다.

개요를 프로젝트에 맞게 조정하고, 그 반대는 하지 마세요. 프로토콜 문서는 소비자 애플리케이션 개요보다 더 많은 기술적 설명이 필요합니다. 관계나 프로세스를 명확히 할 때만 다이어그램을 추가하고, 시각 자료를 한눈에 해석할 수 없는 독자를 위해 본문이 이를 설명하도록 하세요. 토큰 정보에 초점을 맞춘 체크리스트는 CoinGecko에서 공급량 확인 방법을 참조하고, 백서 자체의 공급량 진술을 프로젝트 기록과 일관되게 유지하세요.

기술 및 토큰 주장을 검증 가능하게 만들기

각 중요한 주장을 독자가 무엇이 이를 뒷받침하는지 알 수 있을 정도로 구체적으로 만드세요. "완전히 탈중앙화된" 또는 "설계상 안전한"과 같은 광범위한 진술은 어떤 시스템 속성을 의미하는지, 어떤 증거가 이를 뒷받침하는지, 또는 어떤 트레이드오프가 남아 있는지 설명하지 않습니다.

모든 중요한 주장에 대해 출처와 확인을 담당하는 사람을 기록하세요. 그 출처는 구현된 기능, 기술 문서, 게시된 감사, 팀이 승인한 토큰 할당, 또는 명확히 표시된 가정일 수 있습니다. 계획을 기존 역량으로 제시하지 마세요. 세부 사항이 결정되지 않은 경우 그렇게 말하고 결정을 소유한 사람을 식별하세요.

다음 영역에 특히 주의하세요:

• 아키텍처: 구성 요소의 이름을 지정하고 정보나 자산이 구성 요소 간에 어떻게 이동하는지 설명합니다.
• 보안: 검토된 사항과 검토되지 않은 사항을 명시하고, 검토가 모든 위험을 제거한다는 인상을 주지 않습니다.
• 토큰 역할: 추상적인 설명에 의존하기보다는 제품 내 기능을 설명합니다.
• 공급 및 할당: 카테고리, 시기, 팀이 실제로 승인한 조건을 표시합니다.
• 거버넌스: 의사 결정 권한을 식별하고 제안된 변경 사항이 어떻게 처리되는지 설명합니다.

작업 초안에 주장, 출처, 담당자, 검토 상태가 포함된 증거 테이블을 유지하세요. 테이블은 편집 보조 도구일 뿐, 그 자체로 증거는 아닙니다. 공개 버전의 경우 가능한 경우 기술 용어를 번역하고 필요한 용어는 첫 사용 시 정의하세요. 독자는 팀이 의미하는 바를 추측할 필요 없이 주장을 추적할 수 있어야 합니다.

초안 작성 및 검토

문서를 여러 번에 걸쳐 초안을 작성하고, 주제 담당자가 본문이 다듬어지기 전에 주장을 확인하도록 하세요. 이렇게 하면 불필요한 재작성을 줄일 수 있습니다. 작가는 명확성을 개선할 수 있지만, 토큰 결정을 해결하거나 팀이 확정하지 않은 아키텍처를 검증할 수는 없습니다.

실용적인 순서는 다음과 같습니다:

1. 소스 자료 수집. 제품 문서, 아키텍처 노트, 승인된 토큰 정보, 로드맵 세부 사항, 기존 공개 진술을 수집합니다.
2. 개요 설정. 각 독자 질문을 섹션에 매핑하고 담당자나 확인된 답변이 없는 주제를 표시합니다.
3. 의미 중심 초안 작성. 먼저 직접적인 설명을 작성합니다. 프로젝트 용어를 일관되게 유지하고 용어가 나타날 때 정의합니다.
4. 주제별 검토 실행. 기술, 제품, 토큰 설계 담당자에게 현재 결정 및 출처에 대해 해당 섹션을 확인하도록 요청합니다.
5. 편집 및 승인. 구조, 일관성, 다이어그램, 버전 세부 사항, 프로젝트에 필요한 법률 또는 규정 준수 검토를 확인합니다.

검토자에게 일반적인 "한 번 봐주세요"보다는 집중된 요청을 하세요. 예를 들어, 엔지니어링 리드에게 구성 요소 설명을 확인하도록 요청하고, 토큰 설계 담당자에게 승인된 모델에 대해 할당 언어를 확인하도록 요청하세요. 마스터 사본 하나를 유지하고 어떤 변경 사항이 수락, 연기 또는 해결되지 않았는지 기록하세요. 외부 작성 지원이 필요한 경우 백서 및 라이트페이퍼 작성이 프로젝트 자료를 독자 친화적인 문서로 만드는 데 도움을 줄 수 있습니다. 킥오프 전에 소스 팩과 의사 결정 담당자를 준비하세요.

7가지 백서 체크리스트

팀 외부에서 보기 전에 각 초안을 다음 7가지 항목에 대해 확인하세요. 모든 항목을 통과하면 Q&A에서 방어하기 쉽고 다른 형식으로 축약하기도 쉬워집니다.

• 1페이지에 독자와 목적을 명시합니다.
• 문제를 3문장 이내로 정의합니다.
• 제품과 기술을 평이한 언어로 설명합니다.
• 토큰의 기능, 공급 및 분배를 설명합니다.
• 솔직한 위험 섹션을 추가합니다.
• 모든 숫자를 출처 또는 계약에 연결합니다.
• 2명의 검토자(기술 1명, 법률 1명)의 승인을 받습니다.

한 줄 용어

백서(평이한 언어로: 프로젝트의 기술, 토큰 및 계획을 설명하는 긴 문서).

라이트페이퍼는 요점만 알고 싶은 독자를 위한 백서의 짧은 요약본입니다.

신뢰를 잃게 하는 실수

흔한 실수: 기술 섹션에 마케팅 언어를 혼합하는 것. 주장과 판매 카피를 분리하고 독자가 결정하도록 하세요.

가장 해로운 백서 실수는 일반적으로 불일치, 입증되지 않은 확신, 프로젝트를 설명하기보다는 모호하게 만드는 세부 사항입니다. 세련된 레이아웃은 제품이나 서로 모순되는 주장을 복구할 수 없습니다.

검토 중에 다음 문제를 주의하세요:

• 일반적인 개요 복사: 프로젝트에 없는 기능에 대한 섹션은 문서를 신뢰하기 어렵게 만듭니다. 제거하거나 관련성을 설명하세요.
• 현재 시제와 미래 시제 혼합: 사용 가능한 것, 구축 중인 것, 제안된 것만 명확히 구분하세요.
• 토큰 용어를 정의하지 않고 사용: 토큰이 제품 사용, 거버넌스 또는 다른 명시된 기능과 어떻게 관련되는지 설명하세요.
• 할당 언어를 모호하게 남겨두기: 독자는 일관된 카테고리와 관련 조건에 대한 설명이 필요하며, 홍보용 약어가 아닙니다.
• 절대적인 보안 또는 성능 주장: 문서가 입증할 수 없는 결과를 주장하는 대신 설계와 증거를 설명하세요.
• 피치 반복: 백서는 실질적인 질문에 답해야 하며, 모든 섹션에서 슬로건을 반복해서는 안 됩니다.
• 다이어그램이 텍스트와 모순되도록 두기: 작성된 설명에 대해 레이블, 흐름, 버전을 확인할 담당자를 지정하세요.

최종 일관성 검토에서는 백서를 웹사이트, 문서, 토큰 자료 및 현재 제품 상태와 비교해야 합니다. 세부 사항이 다른 경우 어떤 출처가 최신인지 확인하고 다른 출처를 업데이트하세요. 더 광범위한 프로젝트 런칭 시퀀스의 경우 문서 검토와 함께 토큰 런칭 마케팅 체크리스트를 사용하세요.

백서가 증명할 수 있는 것과 추가 검토가 필요한 것

백서는 프로젝트의 설계를 설명하고 주장의 근거를 공개할 수 있지만, 결정되지 않은 설계를 완성하거나 전문가 검토를 대체할 수는 없습니다. 이를 유지 관리되는 프로젝트 문서로 취급하고, 기술 검증, 법률 자문 또는 정확한 제품 기록을 대체하지 마세요.

한계 및 위험: 기술 설명은 구현이 변경됨에 따라 구식이 될 수 있으며, 토큰 및 규정 준수 질문은 책임 있는 프로젝트 담당자와 자격을 갖춘 고문의 확인이 필요합니다. 명확한 문서는 독자가 명시된 정보를 검사하는 데 도움이 되지만, 시스템이 설명된 대로 작동할 것이라고 인증하거나 외부 당사자가 이를 해석하는 방식을 결정할 수는 없습니다.

게시 전에 문서를 유지 관리할 담당자를 지정하고 검토 트리거를 설정하세요. 유용한 트리거로는 제품, 아키텍처, 토큰 설계, 거버넌스 또는 로드맵의 중대한 변경이 있습니다. 버전 날짜를 기록하고 변경된 사항을 요약하여 독자가 현재 정보와 이전 초안을 구분할 수 있도록 하세요. 다이어그램의 소스 파일을 보관하고 주장 승인에 사용된 증거를 보존하세요.

백서가 거래소 또는 데이터 플랫폼 신청을 지원하는 경우, 사실적 세부 사항을 프로젝트가 제출한 자료와 일치시키세요. 문서 자체가 플랫폼의 검토 결과를 결정하지는 않습니다. 해당 신청 절차는 별도의 CoinMarketCap 상장 및 CoinGecko 상장 가이드를 참조하세요. 간결하고 일관된 소스 문서는 팀이 프로젝트를 설명하는 데 도움이 되지만, 각 플랫폼은 자체적으로 결정을 처리합니다.

라이트페이퍼가 더 나은 선택인 경우는 언제인가요?

라이트페이퍼는 즉각적인 목표가 독자에게 간결한 소개를 제공하는 것일 때 더 적합하며, 독자가 설계와 그 가정에 대한 더 깊은 설명이 필요할 때는 전체 백서가 유용합니다. 이름만으로 계획이 정의되지는 않습니다. 독자가 평가해야 할 사항과 팀이 준비한 입증된 자료의 양에 따라 결정하세요.

라이트페이퍼는 모든 기술적 선택을 문서화하려고 시도하지 않고 문제, 제품, 토큰 역할 및 다음 단계를 소개할 수 있습니다. 더 포괄적인 백서는 아키텍처, 거버넌스, 공급, 종속성 및 위험에 대해 확장할 수 있습니다. 짧은 형식은 중요한 주의 사항을 숨기거나 해결되지 않은 계획이 확정된 것처럼 암시해서는 안 됩니다. 두 문서가 모두 존재하는 경우 각 세부 사항에 대한 진실의 원천을 결정하고 결정이 변경될 때 함께 업데이트하세요.

형식을 선택하기 전에 이 결정 체크를 사용하세요:

• 의도된 독자가 제안을 이해하는 데 구현 세부 사항이 필요한가요?
• 프로젝트의 핵심 주장이 소스 자료와 담당자 검토에 의해 뒷받침되나요?
• 팀이 게시할 계획인 세부 수준을 유지 관리할 준비가 되었나요?
• 지금은 짧은 개요가 더 유용하고, 나중에 더 심층적인 문서를 제공하는 것이 나을까요?

초안을 준비 중이라면 MarketingExtra에 현재 버전, 프로젝트 문서, 승인된 토큰 정보, 기술 및 제품 주장을 확인할 수 있는 사람의 이름을 보내주세요. 자료의 격차를 검토하고 명확한 백서 또는 라이트페이퍼 계획을 수립하는 데 도움을 드릴 수 있습니다. 백서 작성 개요로 시작하세요.

이용 방법

1. 독자와 목적 설정문서가 누구를 위한 것이며 그들이 무엇을 이해해야 하는지 기록하세요. 이를 사용하여 백서에 포함할 내용을 결정합니다.
2. 현재 프로젝트 소스 수집기술, 제품, 토큰, 로드맵, 거버넌스 자료를 수집합니다. 누락된 결정을 표시하고 각각에 담당자를 지정합니다.
3. 주장을 증거에 매핑중요한 진술에 대한 출처와 검증자를 기록합니다. 구현된 역량을 계획 및 가정과 분리합니다.
4. 초안 작성 후 집중 검토 실행독자 친화적인 순서로 작성하고 관련 주제 담당자에게 자신이 관리하는 섹션을 확인하도록 요청합니다.
5. 문서 승인 및 유지 관리게시 전에 일관성, 버전 세부 사항, 다이어그램 및 필요한 전문가 검토를 확인합니다. 향후 업데이트를 위한 담당자를 지정합니다.