코인 백서 작성법: 구조와 흔한 실수

백서가 뒷받침해야 할 결정부터 시작하세요

유용한 암호화폐 백서는 특정 독자가 프로젝트의 내용, 설계 방식 및 불확실한 부분을 이해하도록 돕습니다. 초안을 작성하기 전에 주요 독자가 사용자, 개발자, 토큰 참여자, 파트너 또는 평가자인지 결정하세요. 문서는 여러 대상을 대상으로 할 수 있지만, 각 대상이 자신의 답을 찾기 위해 헤매게 해서는 안 됩니다.

문서의 목적을 한 문장으로 작성한 후 다음 질문에 답하세요:

• 프로젝트가 해결하는 문제는 무엇이며, 누구를 위한 것인가?
• 제안된 시스템이 문제 해결에서 어떤 역할을 하는가?
• 독자가 오늘 검사하거나 사용할 수 있는 것은 무엇이며, 아직 계획된 것은 무엇인가?
• 문서가 설명하는 결정 중 제품이나 계약에서 명확하지 않은 것은 무엇인가?

답변은 범위를 설정하는 데 도움이 됩니다. 새로운 기술 설계를 가진 프로토콜은 상당한 아키텍처 세부 정보가 필요할 수 있으며, 기존 인프라 위에 구축된 애플리케이션은 사용자 흐름, 종속성 및 토큰 유틸리티에 더 많은 공간이 필요할 수 있습니다. 관련성을 설명하지 않고 기술적 깊이를 대체 수단으로 사용하지 마세요.

백서는 또한 문단으로 확장된 피치덱이 아닙니다. 덱은 관심을 끌기 위한 사례를 소개합니다. 백서는 가정과 제약 조건을 포함하여 사례를 검사 가능하게 만들어야 합니다. 팀이 둘 다 필요하다면, 각 형식에 고유한 역할을 부여하면서 핵심 사실을 일치시키세요. 동반 문서의 역할은 암호화폐 피치덱 가이드를 참조하세요.

암호화폐 백서는 어떤 구조를 따라야 하나요?

암호화폐 백서는 독자를 문제에서 설계 및 그 의미로 이끄는 순서가 필요합니다. 아래 순서는 시작 프레임워크이지 필수 목차가 아닙니다. 실제 독자 질문에 답할 때만 섹션을 유지하세요.

개요를 사용하여 독자에게 신뢰할 수 있는 지도를 제공하고, 압축된 세일즈 피치를 제공하지 마세요. 기술 섹션에서는 용어를 사용하기 전에 정의하고 각 구성 요소를 기능에 연결하세요. 다이어그램은 흐름을 더 쉽게 따라갈 수 있게 하지만, 레이블과 경계는 산문과 일치해야 합니다.

프로젝트에 토큰의 정의된 역할이 있는 경우에만 토큰을 설명하세요. 유틸리티, 거버넌스 및 할당 세부 정보를 구분하고, 하나가 자동으로 다른 것을 생성한다고 암시하지 마세요. 토큰 데이터를 더 자세히 확인하려면 토큰 공급 가이드를 사용하세요. 주제가 프로젝트와 관련이 없으면 간략히 언급하거나 생략하세요. 일반적인 섹션을 추가하면 제품이 답하지 못하는 질문이 생길 수 있습니다.

기술 및 토큰 주장을 어떻게 신뢰할 수 있게 만들 수 있나요?

신뢰할 수 있는 주장은 독자가 검토할 수 있을 만큼 구체적이고 프로젝트의 실제 상태와 일치할 만큼 절제되어 있습니다. 모든 중요한 진술에 대해 초안에 도달하기 전에 출처, 소유자 및 상태를 식별하세요.

주장 검토는 세 가지 레이블을 사용할 수 있습니다:

• 현재: 라이브 제품, 게시된 코드, 문서화된 프로세스 또는 확인된 결정에 의해 뒷받침됨.
• 계획됨: 아직 제공되지 않은 의도된 기능 또는 이정표; 계획으로 설명하세요.
• 가정: 설계가 의존하지만 팀이 사실로 확립하지 않은 조건.

그런 다음 표현을 테스트하세요. "완전히 분산된"과 같은 광범위한 표현을 어떤 결정이 분산되어 있는지, 어떤 역할이 권한을 유지하는지, 변경을 관리하는 메커니즘에 대한 설명으로 대체하세요. 보안 작업은 실제 상태와 범위로 설명하세요. 감사, 테스트 또는 통합이 실제보다 더 많이 포함된다고 암시하지 마세요.

토큰 섹션에도 동일한 규율이 필요합니다. 이름, 단위, 할당, 베스팅 설명 및 공급 진술이 프로젝트의 승인된 자료와 일치하는지 확인하세요. 수치나 정책이 확정되지 않은 경우, 빈칸을 임의의 답변으로 채우지 말고 책임 팀에 표시하세요. 토큰 런칭 체크리스트는 일관된 언어를 사용해야 하는 관련 자료를 식별하는 데 도움이 될 수 있습니다. 이러한 과정은 코인 백서 작성법의 핵심 원칙을 따릅니다.

이 검토는 단순한 편집이 아닙니다. 기술 책임자에게 시스템 설명을 확인하도록 요청하고, 토큰 소유자에게 토큰 세부 정보를 확인하도록 요청하며, 프로젝트 책임자에게 로드맵 또는 거버넌스에 대한 진술을 해결하도록 요청하세요. 특정 섹션에 대한 승인을 기록하여 검토자가 전체 문서를 다시 읽는 대신 결정에 집중할 수 있도록 하세요.

초안을 작성하기 전에 팀은 무엇을 준비해야 하나요?

팀은 작성자가 확인된 사실과 미해결 질문을 구분할 수 있는 소스 팩을 준비해야 합니다. 크고 잘 정리되지 않은 폴더보다는 현재 상태를 표시한 작고 잘 정리된 자료 세트가 더 유용합니다.

가능한 경우 다음을 포함하세요:

• 제품 워크스루 또는 의도된 사용자 흐름 설명.
• 아키텍처 노트, 다이어그램 및 지명된 기술 검토자.
• 현재 토큰 모델 및 이를 확인할 권한이 있는 사람.
• 로드맵 결정, 알려진 종속성 및 미해결 항목.
• 기존 웹사이트, 피치덱, 문서 및 공개 성명.
• 대상 청중 우선순위, 선호 용어 및 비밀 유지 경계.

첫 번째 작업 세션에서는 범위를 설정해야 합니다: 가장 중요한 대상, 문서가 설명해야 할 내용, 존재하는 증거 및 후속 조치가 필요한 주장. 작성자는 조용히 가정하기보다는 질문 로그를 반환해야 합니다. 이 로그는 팀이 격차를 해결할 실용적인 방법을 제공하고 각 답변을 제공할 자격이 있는 사람에게 할당합니다.

그런 다음 초안 작성은 개요에서 섹션으로 진행되며, 최종 전달 시에만이 아니라 계획된 시점에 기술 및 프로젝트 검토가 이루어집니다. 절제된 편집 과정은 반복을 제거하고, 용어를 일관되게 정의하며, 제품 사실과 계획을 구분해야 합니다. 백서와 라이트페이퍼 형식은 또한 다른 세부 수준을 제공합니다. 올바른 선택은 독자가 전체 설명이 필요한지 간결한 개요가 필요한지에 달려 있습니다. 전용 작성 지원은 백서 및 라이트페이퍼 작성을 참조하고, 범위 비교는 암호화폐 백서 가격을 참조하세요.

어떤 백서 실수가 독자의 신뢰를 약화시키나요?

가장 해로운 백서 실수는 일반적으로 불일치입니다: 주장과 증거, 야망과 현재 역량, 또는 토큰 언어와 프로젝트 현실 사이의 불일치입니다. 최종 읽기에서는 문장 리듬을 다듬기 전에 이러한 불일치를 찾아야 합니다.

일반적인 문제는 다음과 같습니다:

• 거창한 주장으로 시작하기: 독자는 먼저 구체적인 문제와 제안된 대응에 대한 명확한 설명이 필요합니다.
• 설명되지 않은 기술 용어 사용: 처음 사용 시 용어를 정의하고 설계 선택이 중요한 이유를 설명하세요.
• 로드맵을 약속으로 취급하기: 계획된 작업을 계획됨으로 표시하고, 종속성을 식별하며, 의도를 완료된 기능으로 제시하지 마세요.
• 맥락 없이 토큰 세부 정보 제공: 각 명시된 기능을 설명하고 공급 또는 할당 언어를 승인된 프로젝트 자료와 일관되게 유지하세요.
• 템플릿을 기계적으로 채우기: 프로젝트에 맞지 않는 섹션을 제거하고, 이를 채우기 위해 일반적인 주장을 하지 마세요.
• 다이어그램과 산문의 불일치: 동일한 기술 검토자가 시스템의 두 표현을 모두 확인하도록 하세요.

또한 내부 모순을 확인하세요. 반복되는 용어, 날짜, 공급 설명 및 제품 이름을 검색하고 현재 웹사이트 및 문서와 비교하세요. 편집 중에 표준 사실을 유지할 한 사람을 지정하세요. 한 문단에서 수정하면 다른 곳에 오래된 진술이 남을 수 있기 때문입니다.

간결한 문서는 가정을 숨기지 않고 필수 질문에 답하면 완전할 수 있습니다. 길이만으로 논증이 엄격해지지는 않습니다. 어떤 점이 아직 입증될 수 없는 경우, 한계를 명확히 명시하거나 이후 개정을 위해 남겨두세요.

게시 전에 암호화폐 백서를 어떻게 검토해야 하나요?

게시 전 검토는 정확성, 일관성 및 가독성을 순서대로 확인해야 합니다. 기본 사실을 책임지는 사람부터 시작한 다음, 낯선 독자가 라이브 브리핑 없이 설명을 따라갈 수 있는지 평가하세요.

다음 검토 순서를 사용하세요:

1. 기술 검토: 기술 소유자와 아키텍처, 용어, 시스템 경계 및 다이어그램을 확인하세요.
2. 토큰 및 운영 검토: 관련 프로젝트 소유자와 토큰 설명, 거버넌스 언어, 역할 및 운영 세부 정보를 확인하세요.
3. 독자 검토: 초안 작성 그룹 외부의 사람에게 읽은 후 문제, 메커니즘, 토큰 역할 및 현재 상태를 요약하도록 요청하세요.
4. 일관성 검토: 주장을 웹사이트, 문서, 덱 및 기타 공개 자료와 비교하고, 출처에서 차이를 해결하세요.
5. 카피 및 레이아웃 검토: 제목, 정의, 링크, 표, 버전 세부 정보 및 문서가 화면에서 읽기 쉬운지 확인하세요.

중요한 편집 사항에 대한 변경 로그를 유지하고 최종 사실 버전을 승인한 사람을 표시하세요. 이렇게 하면 제품, 토큰 모델 또는 로드맵이 변경될 때 이후 업데이트가 더 쉬워집니다. 백서를 영구적인 기록이 아니라 유지 관리되는 참고 자료로 취급하세요.

작성자는 프로젝트 정보를 구성하고 명확히 할 수 있지만, 팀을 대신하여 기술적 사실을 결정할 수 없습니다. 팀은 또한 문서가 자체 법적 및 공개 의무를 충족하는지 제어합니다. 백서 자체는 승인, 상장 또는 독자 수용을 보장하지 않습니다. MediaStrategy에서는 명명된 검토 단계가 주장 및 출처 검토입니다: 우리는 뒷받침되지 않는 진술을 표시하고, 미해결 질문을 올바른 소유자에게 할당하며, 최종 초안을 승인한 자료와 조정합니다. 현재 문서, 토큰 자료 및 의도된 독자를 보내주시면, 초안 작성 전에 범위가 지정된 개요와 해결해야 할 질문을 반환합니다.

가격

USD 기준 시작 가격입니다. 맞춤 번들 및 볼륨 할인은 요청 시 제공됩니다. USDT, USDC, BTC, ETH, SOL, TON 또는 프로젝트 토큰으로 결제 가능합니다.

이용 방법

1. 문서의 역할 설정주요 독자와 백서가 답해야 할 질문을 지정하세요. 이 범위를 사용하여 문서에 포함할 내용을 결정하세요.
2. 승인된 출처 수집현재 제품, 기술, 토큰 및 로드맵 자료를 수집하고 각 사실 영역의 소유자를 식별하세요.
3. 개요 초안 작성독자 중심 순서로 섹션을 배열하고, 전체 초안 작성 전에 누락된 증거나 해결되지 않은 결정을 표시하세요.
4. 주제별 작성 및 검토섹션을 개발한 후 기술, 토큰 및 프로젝트 주장을 확인할 자격이 있는 사람에게 전달하세요.
5. 조정 및 게시의견을 해결하고, 문서를 다른 공개 자료와 일치시키며, 최종 사실 버전의 승인을 기록하세요.