코인 백서 작성법: 프로젝트 사실을 읽기 쉬운 문서로 만드는 방법

서문에서 독자가 무엇을 확인할 수 있도록 해야 하나요?

한 문장의 목적 진술문은 독자에게 전체 백서를 평가할 수 있는 기준을 제공합니다. 이 진술문은 프로젝트, 의도된 독자, 그리고 문서가 지원하는 결정 또는 이해를 식별해야 합니다. 목적을 시장에 대한 광범위한 약속이 아닌 제품에 특화되도록 유지하세요.

초안을 작성하기 전에 주요 독자를 선택하세요. 개발자는 구성 요소 동작 및 통합 가정이 필요할 수 있습니다. 잠재적 사용자는 제품 흐름과 현재 한계가 필요할 수 있습니다. 토큰 보유자는 문서화된 토큰 기능 및 거버넌스 규칙이 필요할 수 있습니다. 백서는 여러 그룹을 대상으로 할 수 있지만, 첫 번째 대상을 명시하고 그에 따라 세부 정보를 정렬하세요.

다음 4가지 프롬프트로 간단한 사전 검토 노트를 작성하세요.

• 프로젝트가 해결하는 문제는 무엇이며, 누구를 위한 것인가?
• 사용자나 개발자가 오늘 할 수 있는 것은 무엇인가?
• 어떤 기능이 제안되었거나 개발 중인가?
• 독자가 읽은 후 무엇을 평가할 수 있어야 하는가?

각 답변을 라이브, 테스트 완료, 계획됨 또는 미해결로 표시하세요. 이 상태 어휘는 로드맵 항목이 사용 가능한 기능처럼 읽히는 것을 방지하는 데 도움이 됩니다. 프로젝트가 초기 단계라면 아직 알려지지 않은 것이 무엇인지 명시하세요. 그런 다음 목적 진술문을 사용하여 지명된 독자가 프로젝트를 이해하거나 평가하는 데 도움이 되지 않는 구절을 제거하세요.

백서의 문서 맵에는 어떤 부분이 포함되어야 하나요?

7개 부분으로 구성된 개요는 독자를 프로젝트 문제에서 미해결 질문으로 안내할 수 있습니다. 이를 필수 템플릿이 아닌 작업 맵으로 취급하세요. 이 프로젝트에 대해 중요한 것을 설명할 때만 섹션을 추가하세요.

유용한 순서는 다음과 같습니다.

• 요약: 문제, 접근 방식 및 현재 개발 상태.
• 문제 및 맥락: 누가 문제에 직면하고 있으며, 기존 접근 방식이 무엇을 해결하지 못하고 있는가.
• 제품 또는 프로토콜: 구성 요소, 사용자 흐름 및 시스템 경계.
• 기술 설계: 관련 아키텍처, 종속성 및 보안 가정.
• 토큰 설계(해당하는 경우): 기능, 공급 규칙, 할당 및 거버넌스 메커니즘.
• 로드맵 및 책임: 계획된 작업, 의사 결정권자 및 종속성.
• 위험 및 미해결 질문: 알려진 한계 및 해결되지 않은 설계 선택.

토큰이 없는 프로젝트에 토큰 경제학을 추가하지 마세요. 토큰 프로젝트의 경우 핵심 메커니즘을 부록에 숨기지 마세요. 전문가 세부 정보 앞에 간단한 설명을 배치하세요. 주장을 뒷받침하지만 주요 설명을 방해하는 자료는 부록을 사용하세요.

백서를 넘어서는 런칭 계획에 대해서는 토큰 런칭 체크리스트를 참조하세요. 프로젝트 사실을 백서와 일치시키세요. 상장 준비에 대한 별도 개요는 CoinMarketCap 상장 및 CoinGecko 상장 가이드를 참조하세요. 이러한 자료는 서로 다른 작업을 다루며, 프로젝트가 플랫폼 요구 사항을 충족한다는 증거로 사용되어서는 안 됩니다.

독자가 주장을 출처까지 어떻게 추적할 수 있나요?

주장 인벤토리는 산문을 다듬기 전에 어떤 진술에 검증이 필요한지 보여줍니다. 제품 동작, 토큰 메커니즘, 보안 가정 또는 프로젝트 상태에 관한 모든 중요한 진술에 대해 하나를 만드세요. 이 기록은 초안을 쉽게 변경할 수 있는 동안 허점을 드러냅니다.

각 항목에 대해 4개의 필드를 사용하세요: 정확한 주장, 출처 또는 명시된 가정, 상태 및 검토자. 기본 검토는 3개의 체크포인트를 사용합니다: 출처 일치, 상태 일치 및 담당자 승인. 제품 매뉴얼은 사용자 흐름 설명을 뒷받침할 수 있습니다. 설계 기록은 아키텍처 결정을 설명할 수 있습니다. 예측은 관찰된 결과로 제시되지 않고 추정치로 식별되어야 합니다. 뒷받침 자료가 없으면 진술을 한정하거나 제거하세요.

토큰 관련 구절은 정확한 정의가 필요합니다. 각 공급 용어가 의미하는 바와 할당 또는 해제 규칙이 어떻게 작동하는지 설명하세요. 어떤 규칙이 문서화되어 있고 어떤 규칙이 거버넌스 또는 다른 명시된 프로세스를 통해 변경될 수 있는지 식별하세요. 프로젝트 약관이 해당 해석을 뒷받침하지 않는 한 토큰 보유가 권리를 부여한다고 암시하지 마세요.

이 기록은 또한 향후 편집자가 제품 변경의 영향을 받는 텍스트를 찾는 데 도움이 됩니다. 항목을 프로젝트의 현재 자료 및 토큰 런칭 체크리스트와 비교하세요. GeoMarketing Experts에서는 검토자가 담당자별로 질문이 그룹화된 표시된 초안을 반환할 수 있습니다. 코인 백서 작성법에 대한 자세한 내용은 백서 및 라이트페이퍼 작성을 참조하세요. 유료 작업 범위에 대해서는 암호화폐 백서 가격을 참조하세요.

본문에는 어느 정도의 기술적 세부 정보가 포함되어야 하나요?

시스템 다이어그램과 그 캡션은 산문과 동일한 이야기를 전달해야 합니다. 기술적 세부 정보를 사용하여 구성 요소가 어떻게 상호 작용하고 그 동작이 어떤 가정에 의존하는지 보여주세요. 체인, 계약 또는 암호화 용어 목록만으로는 이러한 관계 없이 충분하지 않습니다.

평이한 언어로 된 시스템 개요부터 시작하세요. 그런 다음 각 중요한 구성 요소를 역할, 입력, 출력 및 종속성별로 설명하세요. 다중 행위자 프로세스의 경우 누가 작업을 시작하는지, 시스템이 무엇을 확인하는지, 종속성을 사용할 수 없을 때 어떤 일이 발생하는지 식별하세요. 전문 용어는 처음 사용 시 정의하세요. 문서 전체에서 하나의 용어를 하나의 의미로 유지하세요.

다이어그램을 사용하여 흐름, 신뢰 경계 또는 데이터 이동을 보여주세요. 다이어그램에 포함된 내용과 제외된 내용을 명명하는 캡션을 추가하세요. 다이어그램은 오프체인 프로세스가 스마트 계약에 의해 강제된다고 제안해서는 안 됩니다. 독자가 백서의 목적을 넘어서는 구현 세부 정보가 필요할 때 더 깊은 기술 문서에 링크하세요.

각 중요한 다이어그램에 대해 2가지 검사를 실행하세요: 레이블이 텍스트와 일치하는지 확인한 다음 기술 검토자에게 묘사된 동작을 확인하도록 요청하세요. 각 다이어그램에 대해 4개의 필드를 기록하세요: 목적, 구성 요소, 경계 및 검토자. 프로젝트 증거가 레이블을 뒷받침하는 경우에만 구성 요소를 테스트 완료, 감사 완료 또는 제안됨으로 표시하세요. 이러한 설명은 상호 교환할 수 없습니다. 설계가 변경 중인 경우, 확정된 사실로 작성하는 대신 어떤 세부 정보가 잠정적인지 식별하세요.

어떤 편집 점검이 암호화폐 백서의 허점을 드러내나요?

토큰 설명과 로드맵 간의 모순은 스타일 문제가 아닌 콘텐츠 결함입니다. 문장을 다듬는 데 시간을 쓰기 전에 상태, 정의 및 증거를 검토하세요. 이러한 점검은 초안을 더 쉽게 평가할 수 있게 만듭니다.

• 메커니즘 없는 약속: 결과를 주장하는 대신 시스템과 그 종속성을 설명하세요.
• 납품으로 작성된 계획: 향후 작업에 레이블을 지정하고 사용 가능한 기능과 구분하세요.
• 모호한 토큰 기능: 토큰이 시스템에서 수행하는 작업을 설명하세요.
• 정의되지 않은 수치 또는 용어: 각 값 또는 레이블이 참조하는 대상을 명시하세요.
• 맥락 없는 기술 용어: 용어를 정의하고 그것이 왜 중요한지 설명하세요.
• 충돌하는 이름 또는 규칙: 섹션 전반에 걸쳐 공급 설명, 거버넌스 역할 및 상태 레이블을 비교하세요.
• 일반적인 구절: 이 프로젝트의 설계나 책임을 설명하지 않는 언어를 제거하세요.

각 섹션에 대해 주의 깊은 독자가 그 내용에서 무엇을 확인할 수 있는지 질문하세요. 답변이 명확하지 않을 때 출처를 추가하고, 가정을 한정하거나 진술을 수정하세요. 그런 다음 순서와 가독성을 위해 별도의 편집 패스를 실행하세요. 사실 확인을 카피 편집과 분리하면 더 부드러운 표현이 해결되지 않은 주장을 숨길 위험을 줄일 수 있습니다.

검토자는 출시 전에 변경 사항을 어떻게 기록해야 하나요?

변경 로그는 팀에 무엇이 변경되었고 그 이유가 무엇인지에 대한 기록을 제공합니다. 주제별로 검토를 할당하세요: 엔지니어는 시스템 설명을, 토큰 담당자는 메커니즘을, 편집 검토자는 구조와 일관성을 확인합니다. 법적 평가가 필요한 언어는 법무 담당자가 검토해야 합니다.

다음 순서를 사용하세요.

• 개요를 확정하고 현재 원천 자료를 수집하세요.
• 설명을 초안 작성하고 자료의 주장을 증거에 매핑하세요.
• 각 주장을 확인 책임이 있는 사람에게 전달하세요.
• 의견을 해결하고 중요한 변경 이유를 기록하세요.
• 링크, 다이어그램, 용어 및 버전 레이블을 최종 텍스트와 대조 확인하세요.

담당자별로 질문이 그룹화된 표시된 문서는 다음 수정에 명확한 경로를 제공합니다. 창업자가 범위와 상태를 해결하는 데 도움이 되고, 기술 검토자는 시스템 설명에 집중할 수 있습니다. 출판까지 변경 로그를 유지하여 검토자가 어떤 주장이 이동했고 그 이유를 볼 수 있도록 하세요.

백서를 넘어서는 프로젝트 커뮤니케이션을 위해 문서를 암호화폐 마케팅 가이드 및 프로젝트의 현재 기술 자료와 비교하세요. 둘 중 하나를 원천 사실 확인을 대체하는 용도로 사용하지 마세요. GeoMarketing Experts에서는 초안 검토가 자료의 주장을 증거에 매핑하고 담당자별로 질문을 반환합니다. 현재 개요, 제품 문서, 해당하는 경우 토큰 자료 및 검토가 필요한 모든 주장을 보내 백서 작성 지원에 대해 논의하세요.

출판된 백서는 무엇을 입증하지 못하나요?

버전 레이블과 지정된 담당자는 독자가 어떤 문서를 읽고 있는지 식별하는 데 도움이 됩니다. 백서에서 현재 프로젝트 문서로의 경로를 유지하세요. 중요한 기능, 토큰 규칙, 거버넌스 프로세스 또는 프로젝트 상태가 변경될 때 백서를 검토하세요. 더 이상 프로젝트를 반영하지 않으면 업데이트하거나 오래된 것으로 표시하세요.

공식 문서는 구현이 설명된 대로 동작한다는 것을 입증하거나 보안을 인증할 수 없습니다. 토큰 및 거버넌스 조건도 프로젝트의 문서화된 규칙에 따라 달라집니다. 백서에 가정과 해결되지 않은 종속성을 명시한 다음, 이러한 자료로 해결할 수 없는 질문에 대해 적격한 기술 및 법률 검토를 구하세요.

출판 전에 최종 텍스트가 제품 및 관리 문서와 일치하는지 확인하세요. 다이어그램, 용어, 버전 레이블 및 링크가 검토된 초안과 일치하는지 확인하세요. 문서가 저절로 최신 상태를 유지할 것이라고 가정하지 말고 명명된 팀원에게 향후 업데이트에 대한 책임을 할당하세요.

초안 작성을 시작하려면 개요, 현재 제품 문서, 해당하는 경우 토큰 자료 및 검토가 필요한 주장 목록을 수집하세요. 해당 항목을 GeoMarketing Experts로 보내세요. 다음 단계는 주장 대 출처 확인이며, 그 다음에는 각 질문을 해결할 책임이 있는 사람들을 위한 격차 목록이 이어집니다.

이용 방법

1. 독자와 목적 설정주요 대상을 지정하고 백서가 그들이 평가하는 데 도움이 되어야 할 것을 명시하세요. 이 작업을 마케팅, 법적 약관 및 상세한 기술 문서와 분리하세요.
2. 현재 사실 수집 및 레이블 지정제품, 아키텍처, 토큰 및 로드맵 자료를 수집하세요. 각 항목을 라이브, 테스트 완료, 계획됨 또는 미해결로 표시하세요.
3. 섹션 및 주장 매핑독자의 필요에 따라 개요를 정렬하세요. 각 중요한 주장에 대한 출처와 검토자를 기록하세요.
4. 설명 초안 작성구현 세부 정보를 추가하기 전에 시스템을 평이한 언어로 설명하세요. 다이어그램에 캡션을 추가하고 그 한계를 식별하세요.
5. 백서 검토 및 유지 관리주장을 올바른 검토자에게 전달하고, 모순을 해결하며, 향후 업데이트를 위한 담당자를 지정하세요.