GCV 글로벌 백서

001 / 100 · GCV GLOBAL WHITEPAPER

Action, Trust and Global Utility

일상의 작은 실천을 세계의 연결로. 가장 신뢰받고 널리 쓰이는 글로벌 코인을 향한 GCV의 비전과 실행 원칙.

목차 ↑

002 / 100 · 문서 안내

발행 정보와 문서의 범위

Publication and Scope

GCV 백서 2026년 10월 9일 한국어 확장판은 글로벌 비전, 참여 규칙, 경제 구조와 서비스 발전 방향을 하나의 문서로 설명합니다.

독자를 위한 약속

이 백서는 처음 방문한 이용자부터 회원, 크리에이터, 연합회 참여자, 개발자와 잠재 판매자까지 함께 읽는 공개 설명서입니다. 서비스가 추구하는 방향을 충분히 제시하면서도, 현재 확인된 결과와 앞으로 갖춰야 할 조건을 구분합니다. 문서를 읽었다는 사실만으로 가입, 결제, 지갑 연결이나 자산 이전이 진행되지 않습니다.

판본과 기준일

이 판본은 표지와 목차, 부록을 포함한 A4 100쪽으로 구성됩니다. 본문은 한국어이며 영어 제목은 탐색을 돕습니다. 영어 제목이 있다는 이유로 전체 본문이 다른 언어로 번역되었다고 해석하지 않습니다. 정책은 해당 결정의 적용 범위를 따르고, 실행 결과에는 확인 날짜와 환경을 함께 표시합니다.

공개 운영 정보

공개 사업자명은 드림해피, 운영자는 이상재입니다. 사업자등록번호는 217-26-65881, 통신판매업 신고번호는 제2026-경북경주-0436호이며 공개 문의처는 gcv314159pi@gmail.com입니다. 이 사업자 표시는 등록된 모든 상품이나 결제수단의 준비 완료를 뜻하지 않습니다. 실제 상품은 상품 등록 준비 중 상태를 기준으로 설명합니다.

읽기와 갱신

공식 홈페이지는 백서와 공지, 안내를 제공하고 앱은 회원 기능의 실행 상태를 보여 줍니다. 서비스 이용 시에는 해당 기능의 최신 안내와 확인된 서버 결과를 함께 확인하십시오. 중요한 정책 변경은 바뀐 내용과 효력일을 밝히고, 이전 문서를 지워 과거의 기준을 알 수 없게 만들지 않는 방향으로 관리합니다.

목차 ↑

003 / 100 · 문서 안내

작은 일상의 참여에서 세계적 신뢰까지

The Founding Ambition

GCV가 품는 포부는 큽니다. 사람들이 이해하고, 안심하고, 실제 생활에서 다시 찾는 세계적 디지털 생태계로 성장하는 것입니다.

성장의 출발점

많은 디지털 서비스는 첫 방문의 관심을 얻지만, 오래 사용할 이유를 설명하는 데 어려움을 겪습니다. GCV는 채굴 참여, 운동, 게임, 초대와 정보 이용처럼 반복되는 경험을 출발점으로 삼습니다. 작은 행동이 어떤 기록으로 남았는지, 그 기록이 무엇을 의미하는지 이용자가 알 수 있어야 합니다. 복잡한 설명을 이해하지 못한 사람도 자신의 상태를 확인할 수 있는 서비스를 지향합니다.

세계 최고라는 목표의 뜻

세계 최고의 코인을 지향한다는 말은 현재의 순위나 가격을 선언하는 문장이 아닙니다. 이용하기 쉬운 경험, 정확한 기록, 책임 있는 운영, 실제 활용 가능성을 꾸준히 높이겠다는 의지입니다. 이름이 널리 알려지는 속도보다, 문제가 생겼을 때 사실을 설명하고 해결하는 능력이 오랜 신뢰를 만듭니다. GCV는 성장의 크기와 운영의 품질을 함께 평가받고자 합니다.

한 사람의 시작, 함께 만드는 생태계

1인 창업의 출발은 모든 일을 한 사람이 영원히 독점하겠다는 뜻이 아닙니다. 회원의 의견, 크리에이터의 설명, 지역 공동체의 도움, 개발자의 개선이 서로 연결되는 구조를 만드는 것이 중요합니다. 각 역할의 기여를 존중하되 지켜야 할 권한과 책임을 명확히 하는 방향으로 발전시키겠습니다.

포부를 실행으로 바꾸는 기준

백서는 완성을 선언하는 종착점이 아니라 다음 행동을 판단하는 기준입니다. 불편한 가입 과정을 줄이고, 보상 계산을 설명하고, 미완성 결제 흐름을 정확히 표시하는 일부터 시작합니다. 새로운 기능은 이용자에게 줄 가치와 검증할 조건을 함께 제시합니다. 이 축적이 국경을 넘는 성장의 기반이 되기를 기대합니다.

목차 ↑

004 / 100 · 문서 안내

사실, 정책, 목표를 구분해서 읽는 방법

How to Read This Paper

같은 문장 속에 계획과 실행 결과가 섞이면 서비스의 현재 모습을 이해하기 어렵습니다. 이 백서는 네 가지 성격의 설명을 구분합니다.

확인된 실행 사실

발행 거래, 배포 결과처럼 실행이 있었다는 설명에는 환경과 시점을 붙입니다. 예를 들어 Pi Testnet에서 확인된 GCV 첫 발행 기록은 해당 시험 네트워크의 사건입니다. 이 사실을 다른 네트워크의 발행이나 모든 회원에게 지급된 결과로 확대하지 않습니다. 과거에 성공한 기록도 현재 모든 기능이 정상이라는 실시간 증거는 아닙니다.

확정된 정책

채굴 주기, 보상 기준, 추천 계산처럼 승인된 규칙은 이용자가 이해할 수 있는 언어와 예시로 설명합니다. 규칙의 존재와 개별 사용자의 보상 확정은 구분해야 합니다. 실제 적용에는 회원, 유효 활동, 시각과 중복 여부 등의 조건이 함께 확인되어야 합니다. 더 최근의 직접 결정이 이전 규칙을 바꾸면 변경 범위를 명시합니다.

사업 목표와 발전 제안

300만 회원, 글로벌 성장, 폭넓은 생활 활용은 사업 목표입니다. 목표 회원 수를 현재 회원 수나 동시 접속 처리량으로 읽으면 안 됩니다. 로드맵에서 제안하는 개선은 가치, 선행 조건과 평가 방법을 설명하지만 확정되지 않은 출시일이나 성능 수치를 채워 넣지 않습니다.

실제 이용에서 확인할 것

어떤 기능을 사용하기 전에는 준비 중인지 이용 가능한지, 자신이 어떤 행동에 동의하는지, 결과가 요청 접수인지 최종 확정인지 확인하십시오. 특히 내부 GCV 기록, Pi 수익, Testnet 토큰과 실제 상품 결제는 서로 다른 의미를 갖습니다. 이 구분을 유지하면 새로운 기능이 추가되어도 자신의 기록을 일관되게 이해할 수 있습니다.

설명의 종류	읽는 기준
실행 사실	시점·환경·확인 근거
정책	적용 대상·조건·버전
목표	지향점·평가 방법
발전 제안	선행 조건·후속 검토

목차 ↑

005 / 100 · 문서 안내

100쪽 전체 목차

Contents

처음 읽을 때에는 비전과 핵심 요약을, 실제 이용 중에는 해당 활동과 경제 구조를 찾아 읽을 수 있도록 구성했습니다.

관심에 따른 탐색

회원은 제품 경험과 채굴·활동 규칙에서 시작할 수 있습니다. 크리에이터와 연합회는 참여자 역할과 공지·공동체를, 판매자는 쇼핑 생태계와 운영 책임을 함께 읽으십시오. 수량을 확인할 때에는 1차 발행량과 전체 공급 설계, 내부 잔액과 체인 기록을 서로 다른 항목으로 읽는 것이 중요합니다.

쪽	내용
1–6	표지·발행 정보·비전 선언·읽는 방법·목차·요약
7–14	글로벌 비전과 성장의 기준
15–22	회원 중심의 제품 경험
23–30	회원·크리에이터·연합회·본사·개발자·판매자의 역할
31–42	24시간 채굴·반감·부스트·선물·추천·QR·운동·게임·광고·정산
43–52	1차 발행량·전체 공급 설계·배분·원장·체인·Pi 수익
53–62	쇼핑·상품·주문·배송·환불·고객지원과 서비스 준비
63–70	공지사항·변경 이력·다국어 안내·피드백·공동체
71–78	기술 구조·인증·정합성·보안·개인정보·접근성
79–84	권한·변경관리·운영 증거·복구·투명성
85–90	단계별 성장·지역 확장·생태계 로드맵
91–96	품질 평가·성능·보안·경제 및 운영 위험·미확정 과제
97–100	용어·계산 예시·출처·정책 버전·변경 이력

목차 ↑

006 / 100 · 문서 안내

GCV를 이해하는 핵심 요약

Executive Summary

GCV는 일상 참여의 기록, 역할별 협력, 활동 보상과 향후 생활 서비스를 연결하는 글로벌 생태계를 지향합니다.

비전과 제품

세계적 신뢰와 이용 가치를 목표로 홈페이지, 앱, 공지, 회원 활동과 운영 체계를 함께 발전시킵니다. 300만 회원은 1차 사업 규모 목표이며 실제 가입자나 검증된 동시 접속 수를 뜻하지 않습니다. 확장은 이용 경험과 운영 품질이 함께 뒷받침되어야 합니다.

활동과 기록

채굴은 서버가 확인한 시작부터 24시간 뒤 종료하며 직접 재시작합니다. 부스트와 선물, 당일 채굴 추천의 증가분은 기본률에 가산합니다. 운동·게임·QR은 각각의 조건과 한도를 따릅니다. 총누적과 오늘 현황, 요청 접수와 보상 확정을 분리해 보여 주는 것이 기록의 기본 원칙입니다.

발행량과 자산 구분

1차 발행량은 31,415,900,000 GCV이며 2026년 10월 5일 Pi Testnet의 첫 발행 기록과 연결됩니다. 전체 공급 설계 기준은 314,159,000,000 GCV입니다. 공급 배분, 내부 활동 보상, 체인 토큰과 Pi 수익은 같은 표에서 무분별하게 합산하지 않습니다. 광고·수수료 Pi 수익 정책은 본사·코어팀 90%, 연합회 10%입니다.

쇼핑과 공개 소통

상품은 현재 등록 준비 중이며 실제 판매 상품·가격·재고를 만들어 표시하지 않습니다. 쇼핑의 방향은 Pi Browser에서 이용자가 승인하는 Pi 결제이고, 상품과 결제 금액은 서버가 확인하는 구조입니다. 공지사항은 준비, 출시, 변경과 장애를 정확히 구분하는 공식 소통 창구로 발전시킵니다.

다음 발전의 판단 기준

새 기능의 가치는 이용자에게 줄 편익과 검증 가능한 실행 결과로 판단합니다. 실제 자산 이전, 판매, 환불이나 대규모 운영은 해당 조건을 충족해야 합니다. 이 백서는 가격 약속보다 설명 가능한 규칙, 이용 경험과 책임 있는 성장에 중심을 둡니다.

목차 ↑

007 / 100 · 글로벌 비전

세계 최고의 코인을 지향하는 기준

A Standard for Global Ambition

큰 포부는 구체적인 품질 기준을 가질 때 설득력을 얻습니다. GCV는 널리 알려지는 것과 오래 신뢰받는 것을 함께 추구합니다.

이름보다 경험으로 평가받기

세계 최고의 코인을 지향하는 출발점은 이용자가 겪는 작은 경험입니다. 가입 과정에서 필요한 정보를 이해할 수 있는지, 활동 뒤 결과를 찾을 수 있는지, 오류가 나면 다음 행동을 알 수 있는지가 중요합니다. 복잡한 기술을 사용한다는 설명만으로 이 문제들이 해결되지는 않습니다. GCV는 첫 화면의 명확함부터 기록의 정확성, 문제 해결의 일관성까지 전체 경험을 발전시키려 합니다. 이용자가 이유를 알고 다시 찾는 서비스가 세계적 성장의 가장 실질적인 기반입니다.

최고라는 말을 측정 가능한 질문으로

품질을 판단할 때에는 확인할 질문이 필요합니다. 신규 이용자가 도움 없이 핵심 흐름을 이해하는가, 실패 후 자신의 기록을 잃지 않는가, 서로 다른 언어와 기기에서도 같은 정책을 이해하는가를 살펴볼 수 있습니다. 이 질문들은 평가의 방향이며 아직 측정하지 않은 성공률을 뜻하지 않습니다. 실제 조사에서는 대상 기기, 참여자 범위, 수행 과제와 결과를 함께 공개해야 합니다. 단일 화면의 만족도와 서비스 전체의 신뢰성을 같은 점수로 대신하지 않겠습니다.

코인의 의미를 활용 경험과 연결하기

GCV의 발전 방향은 코인 수량을 크게 보이게 하는 데 머물지 않습니다. 활동 기록과 보상의 관계를 설명하고, 회원이 자신의 상태를 확인하며, 향후 서비스에서 어떤 자산을 어떤 조건으로 사용하는지 이해하도록 돕는 것이 중요합니다. 실제 사용처는 결제, 판매자 책임과 운영 조건이 준비된 만큼 공개해야 합니다. 계획된 활용처를 이미 이용 가능한 서비스로 소개하면 단기 관심은 얻을 수 있어도 장기 신뢰를 잃게 됩니다.

성장 과정도 제품의 일부

서비스가 커지면 처음의 설계만으로 해결하기 어려운 문제가 나타납니다. GCV는 새로운 증거에 따라 개선하되, 정책을 바꾼 이유와 기존 이용자에게 미치는 영향을 설명하는 방향을 택합니다. 세계적 경쟁력은 오류가 전혀 없다는 선언보다 오류를 발견하고 기록하고 복구하는 능력에서 나옵니다. 공동체의 기대를 듣고 검증된 결과로 답하는 과정 자체를 제품의 품질로 삼겠습니다.

한 사람의 문제에서 찾는 기준

처음 가입한 회원이 자신의 활동 결과를 찾지 못했다면 방문자 수가 늘어도 그 경험은 해결되지 않은 채 남습니다. 도움말을 쉽게 찾게 하고, 같은 조건에서 다시 이용했을 때 혼란이 줄었는지 확인하는 일이 구체적인 개선입니다. GCV는 이런 작은 결과를 쌓아 누구에게 권해도 설명할 수 있는 서비스로 성장하고자 합니다. 세계적 포부는 바로 이 일상적인 품질에서 출발합니다.

목차 ↑

008 / 100 · 글로벌 비전

일상의 참여를 설명 가능한 가치로

Everyday Participation

GCV는 특별한 전문지식이 없는 사람도 일상의 참여를 이해하고 자신의 기록을 확인할 수 있는 경험을 지향합니다.

작은 행동에서 시작하는 서비스

운동 한 번, 게임 한 번, 유효한 초대와 채굴 참여는 각각 다른 경험입니다. GCV는 이 행동들을 무조건 같은 가치로 환산하기보다, 무엇을 했고 어떤 규칙이 적용됐는지를 분명히 보여 주려 합니다. 이용자는 활동을 마친 뒤 성공 여부와 오늘의 인정 횟수, 확인된 보상 상태를 구분할 수 있어야 합니다. 행동과 결과 사이의 연결이 보이면 사용자는 숫자만 따라가는 대신 자신의 이용 방식을 선택할 수 있습니다.

지속 가능한 참여의 조건

참여를 오래 이어가려면 쉬운 시작과 적절한 한계가 함께 필요합니다. 운동과 게임은 보상 한도 이후에도 이용 경험을 이어갈 수 있지만 추가 보상이 무제한으로 생기는 것은 아닙니다. 채굴은 유효한 주기와 실제 경과시간에 따라 계산됩니다. 이런 규칙을 숨기지 않고 설명하면 이용자는 지나친 기대 없이 기능을 활용할 수 있습니다. 일상의 리듬을 돕는 경험이 서비스 체류시간을 늘리는 것보다 우선해야 한다는 것이 발전 방향입니다.

활동의 의미를 과장하지 않기

화면에서 운동을 완료했다고 해서 의료적으로 운동 효과가 검증된 것은 아닙니다. 게임을 마쳤다고 해서 이용자의 모든 행동을 센서로 측정했다는 뜻도 아닙니다. 서비스는 실제로 확인하는 범위와 확인하지 않는 범위를 구분해야 합니다. 예를 들어 서버가 확인한 실행 기록은 해당 서비스의 인정 근거가 되지만, 신체 능력이나 건강 상태를 진단하는 자료로 바뀌지는 않습니다. 정확한 설명은 일상 참여의 가치를 낮추는 것이 아니라 올바르게 이용하도록 돕습니다.

기록을 통해 스스로 이해하기

오늘 현황과 누적 이력은 이용자가 자신의 참여를 돌아보는 도구입니다. 날짜가 바뀌어 오늘의 횟수가 초기화되어도 과거의 총누적 기록은 보존되어야 합니다. 잠시 접속하지 않았거나 기기를 바꾸더라도 확인된 기록의 의미가 달라지지 않아야 합니다. GCV는 단순히 숫자를 늘리는 화면보다, 어떤 활동에서 어떤 결과가 생겼는지 설명하는 기록 경험을 발전시키려 합니다. 이 이해 가능성이 회원의 자율적인 참여를 뒷받침합니다.

하루를 선택하는 예시

한 회원이 오전에 채굴을 시작하고 저녁에는 운동만 이용할 수 있습니다. 다른 회원은 게임과 QR 활동에 더 관심이 있을 수 있습니다. 모든 기능을 같은 날 수행해야만 정상 회원이 되는 것은 아닙니다. GCV는 각자의 생활에 맞는 참여를 돕고, 이용하지 않은 기능 때문에 이미 확인된 다른 활동의 의미가 사라지는 듯한 안내를 피하는 방향을 지향합니다.

목차 ↑

009 / 100 · 글로벌 비전

신뢰를 기록과 설명으로 쌓는 방식

Trust Through Evidence

신뢰는 멋진 표현을 반복해서 만들어지지 않습니다. 이용자가 확인할 수 있는 기록과 일관된 설명이 필요합니다.

결과의 이름을 정확히 붙이기

신청 접수, 처리 중, 확정, 실패는 서로 다른 상태입니다. 사용자가 버튼을 눌렀다는 사실과 서버가 요청을 받아 처리했다는 사실도 다릅니다. GCV는 이 차이를 화면과 이력에서 보존하는 방향으로 설계합니다. 응답이 늦을 때 성공처럼 보이게 하거나, 이미 처리된 요청을 새 요청으로 보내 중복 결과를 만드는 방식은 신뢰를 해칩니다. 불확실한 경우에는 무엇이 아직 확인되지 않았는지를 보여 주고 원래 요청의 결과를 찾는 절차가 필요합니다.

증거는 범위와 함께 읽기

하나의 시험이 통과했다고 해서 전체 운영이 검증된 것은 아닙니다. 예를 들어 합성 계정으로 중복 요청을 시험한 결과는 해당 처리 규칙을 확인하는 데 유용하지만 모든 실제 회원의 기기 상태까지 증명하지는 않습니다. 반대로 실제 배포된 파일이 일치한다는 결과는 게시 정확성의 근거이지 상품 배송이나 광고 수익의 근거가 아닙니다. GCV는 확인한 대상과 확인한 방법, 남은 범위를 함께 설명하는 문화를 지향합니다.

변경의 연속성 보존

서비스는 개선되지만 이용자의 과거 기록은 현재 설명에 맞추어 임의로 바뀌어서는 안 됩니다. 보상 규칙을 변경할 때에는 효력 시점과 대상이 필요하고, 예전 기록이 어떤 정책으로 계산됐는지 확인할 수 있어야 합니다. 문구를 수정하는 일과 실제 수량을 다시 계산하는 일은 별도의 판단입니다. GCV는 이전 오류나 실패 이력도 후속 성공으로 지워 버리지 않고, 어떻게 보완했는지 연결하는 방식으로 신뢰를 쌓고자 합니다.

설명 가능한 문제 해결

문제가 생겼을 때 이용자에게 모든 내부 기술을 보여 줄 필요는 없습니다. 대신 영향을 받은 기능, 보존되는 기록, 현재 상태와 다음 확인 방법은 명확해야 합니다. 복구 과정에서 비밀번호나 비밀키를 반복 요청하는 대신 이미 완료한 단계를 확인하는 것이 중요합니다. 운영자가 문제의 원인을 아직 모른다면 모른다는 사실과 조사 범위를 설명해야 합니다. 이런 정직한 대응은 짧은 성공 문구보다 오랜 이용 관계를 만드는 데 도움이 됩니다.

정정도 이해할 수 있는 정보로

예전 도움말의 표현을 바로잡을 때에는 단순히 문장을 지우기보다 바뀐 이유와 영향을 알려 주는 것이 좋습니다. 화면의 설명만 수정됐는지 실제 정책의 적용 시점도 달라졌는지 구분해야 합니다. 회원이 저장해 둔 이전 안내와 현재 안내를 비교할 수 있으면 잘못된 소문의 확산도 줄어듭니다. 정정의 기록은 완벽함을 주장하는 문장보다 책임 있는 운영을 보여 줍니다.

목차 ↑

010 / 100 · 글로벌 비전

더 많은 사람이 사용할 수 있는 접근성

Access for More People

글로벌 서비스의 입구는 언어와 기기, 신체 조건과 디지털 경험이 다른 사람들에게 열려 있어야 합니다.

이해하기 쉬운 시작

처음 방문한 이용자는 토큰, 원장이나 정산이라는 용어를 모를 수 있습니다. 중요한 설명은 짧고 구체적인 문장으로 제시하고, 자세한 내용은 필요할 때 찾아볼 수 있도록 계층을 나누는 것이 바람직합니다. 가입에 필요한 동의와 선택 사항을 구분하고, 준비되지 않은 기능을 이용 가능한 것처럼 배치하지 않아야 합니다. GCV는 기술에 익숙한 사람만 빠르게 지나갈 수 있는 화면보다 누구나 현재 위치를 이해할 수 있는 흐름을 지향합니다.

기기와 환경의 차이

같은 휴대폰 화면 크기라도 글자 설정, 브라우저 버전과 통신 환경은 다를 수 있습니다. 작은 화면에서 버튼이 가려지거나 설명이 잘리면 정책을 잘 작성해도 전달되지 않습니다. 따라서 핵심 행동은 한눈에 구분되고, 확대된 글씨에서도 순서가 유지되어야 합니다. 연결이 느릴 때에는 진행 상태를 알려 불필요한 연속 클릭을 줄여야 합니다. 특정 기기에서 한 번 성공한 결과를 모든 환경의 호환성으로 일반화하지 않는 것도 중요한 기준입니다.

색과 움직임에 의존하지 않기

성공과 실패를 색만으로 구분하면 정보를 놓치는 이용자가 생길 수 있습니다. 상태 이름, 짧은 설명과 적절한 표식이 함께 필요합니다. 움직임과 소리는 경험을 풍부하게 할 수 있지만, 사용자가 이를 줄이거나 다른 방식으로 정보를 이해할 수 있어야 합니다. 운동이나 게임 화면에서도 종료, 돌아가기와 현재 상태를 예측할 수 있게 만드는 것이 중요합니다. 접근성은 별도의 장식이 아니라 모든 기능의 기본적인 사용 품질로 다루어야 합니다.

검증할 과제로 남기는 태도

이 백서가 접근성의 모든 기준을 충족했다는 인증서는 아닙니다. 발전 과정에서는 키보드와 보조 기술, 글자 확대, 작은 화면과 여러 언어의 흐름을 구체적인 과제로 확인해야 합니다. 이용자가 어떤 지점에서 막혔는지 기록하고 동일 조건에서 개선 효과를 다시 확인하면 우선순위를 정할 수 있습니다. 더 많은 사람이 독립적으로 기능을 이해하고 사용할 수 있도록, 실패 경험을 제품 개선의 중요한 입력으로 받아들이겠습니다.

입력 오류에서도 길을 안내

가입 정보를 잘못 입력했을 때에는 어느 항목을 고쳐야 하는지 글로 알려 주는 것이 유용합니다. 화면 맨 위의 짧은 오류 표시만으로는 작은 화면의 이용자가 원인을 찾기 어렵습니다. 이미 올바르게 입력한 내용까지 모두 지우지 않고 수정할 위치를 안내하면 부담이 줄어듭니다. 접근성은 성공한 화면뿐 아니라 실수한 뒤 다시 시도하는 과정에서도 확인해야 합니다.

목차 ↑

011 / 100 · 글로벌 비전

다국어를 넘어 같은 의미를 전달하기

Meaning Across Languages

언어 선택지가 많다는 사실만으로 글로벌 경험이 완성되지는 않습니다. 중요한 규칙이 어느 언어에서도 같은 뜻으로 전달되어야 합니다.

번역에서 보존해야 할 것

보상 수량, 한도, 날짜와 자산 이름은 번역 과정에서 뜻이 달라지면 안 됩니다. 예를 들어 오늘 채굴 추천 반영 한도314명과 가입 QR 발급자의 평생 보상 한도314회는 숫자가 같아도 전혀 다른 규칙입니다. 이를 단순히 추천 한도라고 줄이면 모집 자체가 제한된다고 오해할 수 있습니다. GCV의 다국어 안내는 문장의 유창함과 함께 정책의 조건, 계산 단위와 적용 대상을 보존하는 방향으로 발전해야 합니다.

원문과 번역의 연결

정책이 바뀌면 어떤 원문이 바뀌었고 어느 번역이 갱신됐는지를 추적할 수 있어야 합니다. 모든 언어를 같은 시점에 검토하지 못했다면 확인된 언어와 준비 중인 언어를 구분하는 편이 정확합니다. 번역이 없는 부분을 다른 언어로 표시할 때에도 사용자가 이를 알아볼 수 있어야 합니다. 이 한국어100쪽 판본의 영어 제목과 웹 요약은 탐색을 돕는 범위이며 전체 언어판의 완역을 의미하지 않습니다.

화면 방향과 실제 표시

언어에 따라 문장의 길이와 읽는 방향, 숫자 주변의 배치가 달라집니다. 텍스트만 교체했는데 버튼이 겹치거나 금액의 자산 단위가 떨어져 보이면 중요한 정보가 왜곡될 수 있습니다. 따라서 번역 품질은 문구 검토와 실제 화면 확인을 함께 다뤄야 합니다. 긴 문장, 작은 화면, 오른쪽에서 왼쪽으로 읽는 언어, 원문으로 돌아오는 동작을 확인하는 것이 유용합니다. 국기 하나를 언어 전체의 의미로 대신하지 않는 설명도 필요합니다.

지역 이해와 공동체의 기여

지역 공동체와 크리에이터는 낯선 표현을 이해하기 쉽게 설명하는 데 기여할 수 있습니다. 다만 편의를 위한 설명이 원래 정책을 바꾸거나 별도 보상을 약속해서는 안 됩니다. 제안된 번역과 확인된 공식 안내를 구분하고, 오류를 발견하면 원문과 함께 수정할 수 있는 절차가 바람직합니다. GCV는 언어별 이용자의 의견을 단순 홍보 자료가 아닌 품질 개선의 근거로 받아들이며, 이해의 격차를 줄이는 글로벌 경험을 지향합니다.

숫자를 검토하는 별도 시선

소수점과 자릿수 구분 기호는 지역마다 다르게 익숙할 수 있습니다. 번역 검토에서는 문장뿐 아니라31,415,900,000이라는1차 수량이 같은 값으로 읽히는지, 시간당과 하루의 단위가 유지되는지 확인해야 합니다. 언어가 바뀌어도 계산 예시의 결과는 같아야 합니다. 원문과 번역을 나란히 대조하는 작은 검토가 경제 정책의 큰 오해를 막는 데 도움이 됩니다.

목차 ↑

012 / 100 · 글로벌 비전

지역 공동체와 세계적 연결

Local Roots, Global Reach

글로벌 성장은 지역의 실제 필요를 이해하는 데서 시작합니다. GCV는 하나의 정책을 명확히 유지하면서 다양한 이용 맥락을 존중하려 합니다.

지역의 문제를 듣는 역할

어떤 지역에서는 가입 설명이, 다른 지역에서는 기기 호환성과 연결 품질이 더 큰 장애가 될 수 있습니다. 연합회와 지역 참여자는 이러한 차이를 알려 주는 창구가 될 수 있습니다. 중요한 것은 회원의 불편을 정확히 전달하고 공식 안내로 해결하도록 돕는 일입니다. 지역별로 사실과 다른 보상 조건을 제시하거나 임의의 계정 승인을 약속하면 하나의 서비스 안에서 서로 다른 기대가 생깁니다. GCV는 지역의 목소리와 정책의 일관성을 함께 지키는 협력을 지향합니다.

동일한 규칙과 다양한 설명

회원이 어느 언어를 쓰든 보상 계산의 기준은 같은 정책에서 나와야 합니다. 반면 이용 방법을 설명하는 예시는 지역의 생활 방식과 익숙한 표현에 맞출 수 있습니다. 예를 들어 UTC-5 회계일의 변경 시각은 각 지역 시간으로 안내할 수 있지만 개인마다 별도 회계일이 생기는 것은 아닙니다. 공통 규칙과 현지 설명을 나누면 운영의 정확성을 유지하면서도 사용자의 이해를 높일 수 있습니다.

확장 전에 확인할 조건

새로운 지역에서 이용자가 늘었다는 이유만으로 판매, 배송이나 자산 지급의 준비가 끝난 것은 아닙니다. 실제 서비스를 확장하려면 지원 가능한 언어, 고객 문의 대응, 관련 운영 조건과 현지에서 필요한 검토를 구체화해야 합니다. 이 백서는 이미 운영하는 국가나 체결한 제휴사를 임의로 나열하지 않습니다. 지역 확장의 순서는 수요, 준비 수준과 지속적인 지원 가능성을 근거로 판단하는 발전 과제입니다.

연결의 가치를 되돌려 주기

공동체가 성장하면 정보를 빠르게 퍼뜨릴 수 있지만 오류도 같은 속도로 확산될 수 있습니다. 공식 공지와 문서가 공통 기준이 되고, 잘못된 설명을 쉽게 바로잡을 수 있어야 합니다. 지역 참여자의 기여는 신규 인원 수만이 아니라 질문 해결, 교육의 정확성과 건강한 참여 문화로도 평가할 수 있습니다. GCV는 사람을 단순한 모집 숫자로 보지 않고, 서로의 이해를 돕는 관계가 장기적인 생태계 가치를 만든다는 관점에서 성장하려 합니다.

시간 안내의 현지화 사례

한국 이용자에게 회계 경계를 오후2시로 설명하는 것은 이해를 돕지만 모든 국가의 현지 시각이 오후2시라는 뜻은 아닙니다. 다른 지역에는 같은UTC 기준을 현지 시각으로 풀어 안내해야 합니다. 공통 원칙을 유지하면서 표현을 바꾸는 사례입니다. 현지 설명을 공식 정책과 연결해 두면 지역마다 다른 하루 한도가 있다고 오해하는 일을 줄일 수 있습니다.

목차 ↑

013 / 100 · 글로벌 비전

이용자의 선택과 통제권

User Choice and Control

사용자가 자신이 하는 행동과 그 결과를 이해할 수 있어야 참여가 자발적 선택이 됩니다. GCV는 중요한 행동의 경계를 분명하게 만드는 방향을 지향합니다.

선택 전에 이해할 정보

가입, 추천인 선택, 지갑 연결과 결제는 서로 다른 목적의 행동입니다. 이용자는 어떤 정보를 제공하는지, 무엇을 승인하는지, 취소하면 어떤 상태가 남는지 확인할 수 있어야 합니다. 설명이 긴 약관에만 들어 있고 실제 화면에서는 보이지 않는다면 선택의 의미를 이해하기 어렵습니다. 핵심 조건은 행동 가까이에 배치하고 상세 문서로 이어지는 구조가 바람직합니다. 기능을 이용하지 않은 상태와 실패한 상태도 구별되어야 합니다.

직접 행동과 자동 처리 구분

편의를 위한 자동 갱신은 사용자의 의사결정을 대신해서는 안 됩니다. 채굴 상태를 다시 읽는 것과 새24시간 주기를 시작하는 것은 다르며, 결제 화면을 여는 것과 결제를 승인하는 것도 다릅니다. GCV는 중요한 실행에서 명확한 행동과 확인 절차를 유지합니다. 자동화가 적용되는 영역은 어떤 조건에서 어떤 처리가 이루어지는지 설명할 수 있어야 합니다. 예를 들어 빈 추천인 신규가입의24시간 유예 종료는 확정된 별도 규칙에 따라 처리됩니다.

정보와 기록의 주체

본인의 활동과 계정 기록은 확인하기 쉬워야 하지만 다른 회원의 민감한 정보가 함께 노출되어서는 안 됩니다. 운영자와 공동체 구성원의 역할이 다르더라도 접근 범위는 목적에 맞게 제한되어야 합니다. 계정이 바뀌거나 로그아웃한 뒤에는 이전 회원의 늦은 응답이 화면을 덮지 않도록 하는 경계도 중요합니다. 사용자의 통제권은 설정 메뉴의 존재뿐 아니라 실제 정보 흐름이 일관되게 처리되는지에 달려 있습니다.

선택을 존중하는 성장

성장을 위해 지나친 초대나 광고 클릭을 강요하면 이용 경험과 신뢰를 해칠 수 있습니다. GCV는 기능의 목적과 조건을 설명하고 이용자가 참여 여부를 판단할 수 있도록 돕는 방향을 택합니다. 문의와 오류 제기 역시 참여의 일부입니다. 이용자가 설명을 이해하지 못했을 때 책임을 돌리기보다 화면과 문서를 개선할 기회로 받아들여야 합니다. 자율적인 선택이 존중될 때 서비스에 머무르는 이유도 더 오래 지속될 수 있습니다.

도움을 받아도 본인이 결정

가족이나 지역 안내자가 기능을 설명해 줄 수 있지만 설명을 돕는 역할과 계정을 대신 통제하는 역할은 다릅니다. 가입자 본인이 추천 관계를 확인하고 중요한 자산 행동을 이해하도록 돕는 것이 바람직합니다. 비밀번호와 지갑 비밀정보를 넘겨주는 것을 편리한 지원 방법으로 만들지 않습니다. 누구에게 도움을 받든 최종 선택의 의미를 알 수 있는 경험이 목표입니다.

목차 ↑

014 / 100 · 글로벌 비전

속도와 지속 가능성을 함께 설계하기

Sustainable Growth

빠르게 늘어나는 관심을 실제 서비스의 지속적인 가치로 바꾸려면 이용 경험, 수익 구조와 운영 능력이 함께 성장해야 합니다.

규모와 품질의 균형

300만 회원이라는 사업 목표는 방향을 제시하지만 운영의 모든 조건을 설명하지는 않습니다. 가입자 수, 하루 이용자, 동시에 접속한 사람 수와 특정 기능에 집중되는 요청은 서로 다릅니다. 어떤 활동이 언제 몰리는지, 오류 뒤 재시도가 얼마나 발생하는지에 따라 필요한 처리 능력이 달라집니다. GCV는 목표 인원을 성능 인증처럼 사용하기보다 실제 이용 패턴과 기능별 부담을 확인하며 확장하는 접근을 지향합니다.

수익을 실제 흐름으로 보기

광고 노출 가능성, 추정 수익, 확정 수익과 실제 입금은 같은 단계가 아닙니다. 운영은 예상치만으로 지급 능력을 판단하지 않아야 합니다. Pi 수익 배분 정책은 존재하지만 그 정책 자체가 광고 계약이나 입금 완료를 만들지는 않습니다. 향후 쇼핑 역시 거래액과 매출, 환불과 비용을 분리해서 보아야 합니다. 지속 가능한 성장은 자산별 수입과 지출의 원천을 설명하고 운영에 필요한 부담을 감당할 수 있을 때 가능해집니다.

단계별로 넓히는 기능

새 기능이 많아질수록 서로 연결되는 지점도 늘어납니다. 보상 기능, 지갑 기록과 상거래 결제를 한 번에 묶어 성공으로 선언하면 어느 단계가 준비됐는지 알기 어렵습니다. GCV는 먼저 이용자가 얻는 가치를 정의하고, 필요한 검증과 운영 조건을 확인한 뒤 범위를 넓히는 방향을 제안합니다. 준비가 덜 된 상품을 허구의 가격과 재고로 채우기보다 등록 준비 중 상태를 정확히 보여 주는 것이 그 출발점입니다.

미래의 선택지를 보존하기

지속 가능성에는 기존 기록을 보존하고 잘못된 변경에서 돌아올 수 있는 능력도 포함됩니다. 정책이 바뀌더라도 과거 잔액과 거래의 의미를 알 수 있어야 하며, 장애 시 복구 절차가 준비되어야 합니다. 새로운 기술이나 시장의 변화는 검토할 기회이지만 자동적인 성공을 뜻하지 않습니다. GCV는 장기 포부를 유지하면서도 실제 관측과 이용자의 경험에 맞추어 우선순위를 조정하는 조직과 제품으로 발전하려 합니다.

다음 개선의 순서를 정하는 질문

새 메뉴를 하나 더 만드는 일과 반복되는 가입 오류를 고치는 일이 동시에 필요할 수 있습니다. 어떤 문제가 더 많은 이용자의 핵심 흐름을 막는지, 기록과 자산에 어떤 영향을 주는지 살펴 우선순위를 정하는 것이 좋습니다. 눈에 띄는 기능 수만으로 진척을 판단하지 않습니다. 실제 불편의 감소와 운영 부담의 완화가 함께 확인될 때 확장의 속도도 더 안정적으로 유지할 수 있습니다.

목차 ↑

015 / 100 · 제품 경험

공식 홈페이지는 이해의 출발점

The Public Portal

GCV 홈페이지의 역할은 처음 만나는 사람에게 생태계의 방향과 공식 정보를 설명하고 필요한 앱 기능으로 정확히 안내하는 것입니다.

공개 정보의 중심

백서, 이용 가이드, 공지와 운영 안내는 로그인 전에 읽을 수 있는 정보의 중심입니다. 이용자는 회원이 되기 전에 서비스가 무엇을 제공하고 어떤 상태인지 이해할 수 있어야 합니다. 홈페이지에서 개인 잔액이나 운영자 권한이 있는 자료를 공개할 이유는 없습니다. 공개 설명과 인증된 실행 영역을 분리하면 처음 방문한 사람도 필요한 내용을 탐색하기 쉽고, 회원의 정보가 홍보 화면에 섞이는 일을 줄일 수 있습니다.

홈페이지와 앱의 연결

홈페이지에서 앱으로 이동하는 링크는 실제 기능의 정본 주소로 이어져야 합니다. 안내 페이지와 앱 복사본이 서로 다른 규칙을 보여 주면 이용자는 어떤 상태를 믿어야 할지 알기 어렵습니다. 홈페이지는 앱의 목적과 사용법을 설명하고, 로그인과 개인 활동은 앱에서 확인하는 구조를 유지합니다. 이동 과정에서도 언어와 목적지가 예상과 맞아야 하며, 단순 링크 이동이 가입 동의나 결제 승인으로 바뀌어서는 안 됩니다.

새로운 소식을 읽는 방식

공지에는 날짜뿐 아니라 변화의 의미가 필요합니다. 백서가 확장됐다는 소식은 문서 공개이고, 상품 등록 준비 소식은 판매 개시와 다릅니다. 운영 상태는 확인된 시점의 정보이며 실시간 화면이라고 표시하려면 그에 맞는 갱신 근거가 필요합니다. 방문자가 지금 할 수 있는 일과 기다려야 하는 일을 구분하도록 제목과 본문을 구성하는 것이 바람직합니다. 과거 공지의 날짜를 오늘로 바꾸어 새 실행처럼 보이게 하지 않습니다.

검색으로 들어온 이용자

이용자는 브랜드 이름, Pi Browser, 게임이나 쇼핑을 검색하다 GCV를 처음 만날 수 있습니다. 검색용 제목과 설명도 실제 내용과 일치해야 합니다. Pi와 연결되는 기능이 있다는 사실을 공식 제휴나 승인으로 과장해서는 안 됩니다. 첫 화면에서는 GCV의 공식 주소와 핵심 안내로 이어지는 길을 제공하고, 개인 정보를 요구하는 화면으로 갑자기 이동시키지 않는 것이 신뢰를 만드는 데 도움이 됩니다.

일관된 정보의 유지

홈페이지와 앱, 백서의 중요한 수량과 정책이 달라지지 않도록 변경 대상을 함께 확인해야 합니다. 예를 들어 1차 발행량을 고칠 때에는 제목과 표, 요약의 의미가 서로 맞는지 살핍니다. 문서 연결이 끊기지 않도록 기존 주요 주소를 유지하는 것도 중요합니다. 공개 정보가 정돈되어 있으면 이용자 문의가 줄어드는 데 그치지 않고, 서비스가 발전하는 과정을 누구나 따라갈 수 있습니다.

목차 ↑

016 / 100 · 제품 경험

앱은 개인의 상태와 행동을 연결합니다

The Member App

앱의 중심은 많은 버튼이 아니라 이용자가 자신의 현재 상태를 알고 다음 행동을 선택할 수 있는 흐름입니다.

목적을 따라 이동하기

홈에서 활동을 시작하고, 기록을 확인하고, 필요하면 설정이나 도움말로 이동하는 흐름은 일관되어야 합니다. 같은 기능의 이름과 동작이 화면마다 달라지면 사용자는 잘못된 요청을 보내기 쉽습니다. GCV는 채굴, 운동, 게임과 QR처럼 서로 다른 활동을 구분하면서도 현재 위치와 돌아갈 곳을 예측할 수 있는 경험을 지향합니다. 메뉴가 늘어날 때에는 실제 사용 빈도와 중요한 상태를 기준으로 정보를 배치하는 것이 필요합니다.

보기와 실행을 구분하기

잔액을 조회하거나 안내를 여는 것은 새 보상을 요청하는 행동과 다릅니다. 화면에 들어왔다는 이유로 채굴이 자동 재시작되거나 지갑 지급이 요청되면 이용자는 자신의 의사를 통제하기 어렵습니다. GCV는 중요한 실행과 읽기 동작을 구분하는 원칙을 유지합니다. 버튼을 누른 후에도 접수, 처리와 완료를 나누어 보여 주어야 합니다. 화면의 동작은 가능한 한 사용자가 예상한 목적 안에서 끝나야 합니다.

준비 중 상태의 의미

서비스가 발전하는 동안 일부 기능은 소개만 제공하거나 연결 조건을 기다릴 수 있습니다. 준비 중 표시는 단순히 비활성 버튼을 놓는 것보다 왜 이용할 수 없는지와 무엇이 달라져야 하는지를 알려 주어야 합니다. 다만 운영자가 확인하지 않은 날짜를 약속할 필요는 없습니다. 쇼핑의 상품 등록 준비와 특정 시험 결제 기능을 일반 판매의 성공으로 묶지 않는 것처럼, 기능별 상태를 정확히 구분하는 경험이 필요합니다.

늦은 응답을 다루는 경험

이용자가 화면을 떠난 뒤 서버 응답이 도착할 수 있습니다. 그 사이 다른 회원으로 로그인했다면 이전 응답이 새 회원 화면을 덮어서는 안 됩니다. 같은 계정이라도 지난 요청이 최근 상태를 되돌리지 않도록 처리 순서를 확인해야 합니다. 이 문제는 빠른 통신 환경에서는 잘 보이지 않지만 기기 이동이나 불안정한 연결에서 중요해집니다. 앱의 신뢰성은 정상적인 클릭뿐 아니라 이런 시간차를 다루는 능력에도 달려 있습니다.

작은 개선의 축적

버튼 가까이에 실패 이유를 표시하고, 처리 중 중복 클릭을 줄이고, 돌아왔을 때 확인된 상태를 다시 읽는 개선은 개별적으로 작아 보일 수 있습니다. 그러나 이런 개선이 모이면 이용자는 불필요하게 처음부터 다시 시도하지 않아도 됩니다. GCV는 새 화면의 수보다 실제 흐름의 완결성을 중요하게 보며, 회원이 어떤 상태에서 막혔는지 구체적으로 확인해 다음 개선을 선택하는 방향으로 앱을 발전시키려 합니다.

목차 ↑

017 / 100 · 제품 경험

가입과 추천인 선택을 이해하는 순서

Signup and Referral Choice

가입 완료와 추천인 확정은 연결되어 있지만 같은 사건은 아닙니다. 신규회원의 선택과 각 보상의 발생 시점을 분리해서 이해해야 합니다.

서버가 확인하는 가입

GCV 신규가입의 기준은 Pi 인증과 필요한 동의를 서버가 확인한 완료 사건입니다. 화면에 Pi 사용자명이 보이거나 버튼을 눌렀다는 사실만으로 가입이 완료되는 것은 아닙니다. 또한 Pi 인증을 GCV가 이용자의 모든 신원이나 KYC 완료를 판정했다는 의미로 확대하지 않습니다. 가입 과정에서는 어떤 계정으로 진행하는지와 필요한 약관·개인정보 안내를 확인할 수 있어야 합니다. 확인된 가입 완료 시각이 이후 유예와 보상 처리의 기준이 됩니다.

직접 지정과 가입 QR

유효한 추천인을 직접 지정하거나 가입 QR로 들어온 경우의 관계는 가입 시 확정됩니다. 잘못된 코드를 입력했는데 조용히 다른 추천인으로 바꾸면 이용자의 선택이 훼손됩니다. 서버는 코드의 소유자와 유효성, 자기추천이나 순환 관계를 확인해야 합니다. 이용자는 완료 전에 적용될 추천인을 알아볼 수 있어야 하며, 단순히 링크에 이름이 포함되었다는 이유만으로 관계가 유효하다고 단정하지 않습니다.

두 보상의 시점

가입자에게는 확인된 가입 완료를 기준으로314 GCV 기준 보상이 한 번 발생하고, 추천인의6.28 GCV 기준 보상은 관계가 최종 확정된 뒤 한 번 발생합니다. 두 사건의 실제 시각이 다르면 적용 반감이나 정산일도 다를 수 있습니다. 추천인을 아직 정하지 않았다는 이유로 가입자의 확인된 정산을 막지 않는 것이 이 분리의 목적입니다. 재시도나 뒤늦은 추천 확정으로 가입자 보상이 다시 생겨서는 안 됩니다.

이용자가 확인할 결과

가입 완료, 추천인 선택 가능, 추천인 확정과 보상 상태를 각각 확인하면 흐름을 이해하기 쉽습니다. 가입자 적립만 확인된 상태를 양쪽 지급 완료로 표시하지 않아야 합니다. 오류가 발생하면 같은 가입 사건의 상태를 다시 확인하는 것이 먼저입니다. 이 과정은 내부 보상 기록의 처리이며, 외부 지갑에 실제 토큰을 보냈다는 결과는 별도의 지급 기록에서 확인해야 합니다.

목차 ↑

018 / 100 · 제품 경험

계정과 동의는 신뢰의 첫 경계

Identity and Consent

계정은 기록의 주인을 구분하고 동의는 허용한 행동의 범위를 설명합니다. 둘은 화면의 편의보다 먼저 지켜야 할 기준입니다.

같은 이름과 같은 사람의 차이

표시 이름이나 이메일이 비슷하다는 이유만으로 서로 다른 계정을 합치면 기록의 주인이 바뀔 수 있습니다. 계정 연결은 검증된 신원과 명시된 절차를 따라야 합니다. GCV는 기존 회원의 자료와 추천관계를 보존하는 원칙을 유지합니다. 새 인증 수단을 추가하더라도 예전 계정의 잔액을 이름만 보고 복사하지 않습니다. 이용자가 여러 기기에서 접속할 때에도 어느 계정의 정보를 보고 있는지 알아볼 수 있어야 합니다.

동의가 필요한 이유

약관과 개인정보 안내는 가입 버튼 옆에 놓는 장식이 아닙니다. 무엇을 위해 어떤 정보가 필요한지, 어떤 서비스가 제공되는지와 문의 방법을 설명하는 기준입니다. 동의 기록은 사용한 문서의 버전과 확인된 시점을 구분할 수 있어야 합니다. 아직 제공하지 않는 상품 구매나 자산 이전을 가입 동의 하나에 포함된 것처럼 처리해서는 안 됩니다. 목적이 다른 행동은 그 행동에 맞는 설명과 확인이 필요합니다.

세션이 바뀌는 순간

로그아웃하거나 인증이 만료되면 개인 정보의 조회와 진행 중인 화면 상태를 적절히 정리해야 합니다. 오래된 요청의 응답이 늦게 도착하더라도 새로 로그인한 회원에게 이전 회원의 잔액을 보여 주면 안 됩니다. 계정 전환은 단순히 상단 이름을 바꾸는 일이 아니라 모든 개인 데이터의 소유 범위를 다시 정하는 일입니다. 사용자는 다시 인증한 뒤 확인된 현재 상태를 읽고 필요한 행동을 이어갈 수 있어야 합니다.

비밀을 맡기지 않는 안내

이용 지원 과정에서 비밀번호나 지갑의 비밀키를 문서, 채팅이나 공개 문의에 입력하도록 안내해서는 안 됩니다. 운영자도 편의를 이유로 사용자의 서명을 대신하는 구조를 당연하게 취급해서는 안 됩니다. GCV의 문서는 사용자가 자신의 인증과 지갑 승인을 직접 처리하는 경계를 설명합니다. 문의에는 가능한 한 고정된 오류 종류와 필요한 최소 정보만 사용하고, 민감한 원문이 불필요하게 퍼지지 않도록 하는 것이 바람직합니다.

권한의 최소 범위

인증된 회원이라는 사실이 관리자 기능이나 QR 발급, 금융 실행의 모든 권한을 뜻하지는 않습니다. 기능마다 현재 역할과 허용 조건을 서버에서 확인해야 합니다. 공개 운영자 이름을 알고 있거나 화면 주소를 직접 입력했다고 해서 보호된 기능이 열려서는 안 됩니다. 계정, 동의와 권한을 나누어 다루면 기능이 늘어나도 각 요청이 누구의 어떤 선택에 근거하는지 일관되게 설명할 수 있습니다.

목차 ↑

019 / 100 · 제품 경험

오늘의 현황과 총누적을 함께 읽기

Daily Status and Lifetime Records

오늘 무엇을 했는지와 지금까지 무엇이 쌓였는지는 다른 질문입니다. 두 정보를 구분해야 숫자의 변화가 자연스럽게 이해됩니다.

오늘 현황의 역할

오늘 현황은 채굴, 부스트, 선물, 운동, 게임과 QR의 당일 상태를 보여 주는 공간입니다. 활동마다 실행 횟수와 보상 횟수, 적용 효과가 다르므로 모든 숫자를 같은 단위로 읽으면 안 됩니다. 부스트3회는 코인을3개 받았다는 뜻이 아니며, 게임을6번 했다고 여섯 번의 보상이 인정되는 것도 아닙니다. 각 항목에 무엇을 세고 있는지 표시하면 이용자는 오늘 남은 선택과 확인된 결과를 이해할 수 있습니다.

회계일이 바뀌는 순간

GCV의 일일 기준은 고정UTC-5이며 날짜 경계는 UTC05:00, 한국시간14:00입니다. 이 시각에 오늘의 표시와 일일 한도는 새 날을 기준으로 바뀝니다. 그렇다고 과거 총누적이나 회원 기록을 지우는 것은 아닙니다. 채굴24시간 주기의 종료 시각은 별도로 서버 시작 시각에서 계산됩니다. 회계일 변경과 채굴 주기 종료를 구분하면 정해진 시각에 모든 상태가 같은 방식으로 초기화된다는 오해를 줄일 수 있습니다.

예상 증가와 확정 기록

채굴 화면은 진행 중인 시간을 이해하도록 도울 수 있지만, 화면에서 움직이는 숫자가 모두 저장 확정량인 것은 아닙니다. 확인된 서버 기준시각과 유효한 요율을 바탕으로 표시한 현재 예상치와 저장된 정산 결과를 구분해야 합니다. 연결이 끊겼다면 미확인 값을0으로 바꾸어 정상 조회처럼 보이게 하지 않아야 합니다. 마지막 확인 시각과 조회 상태를 함께 보여 주면 이용자는 새로운 정보인지 이전 정보인지 판단할 수 있습니다.

효과를 두 번 더하지 않기

부스트와 선물은 기본 채굴률에 더해지는 효과입니다. 그 결과가 이미 채굴 적립량에 포함되었다면 전체 합계에 부스트 보상이라는 이름으로 다시 더하지 않습니다. 효과 사용 횟수와 효과로 달라진 요율을 따로 보여 주는 것은 설명을 위한 구분입니다. 실제 합계는 승인된 원장의 사건과 계산 기준에 따라 나와야 합니다. 같은 금액을 여러 카드에 표시한다는 이유로 여러 번 발생한 수익으로 읽지 않도록 안내가 필요합니다.

변화를 설명하는 화면

상태가 바뀌었을 때에는 숫자만 교체하기보다 이유를 이해할 수 있어야 합니다. 예를 들어 채굴 종료 뒤에는 주기가 끝났다는 점을, 새 회계일에는 오늘 횟수가 바뀌었다는 점을 설명합니다. 계정이 바뀌면 이전 회원의 값을 보존 표시하지 않고 새 계정의 상태를 확인합니다. GCV는 홈 화면을 수량을 크게 보이게 하는 공간보다 신뢰할 수 있는 개인 현황의 출발점으로 발전시키려 합니다.

목차 ↑

020 / 100 · 제품 경험

지갑과 이력에서 자산의 의미 찾기

Wallets and Records

같은 GCV라는 이름이 보여도 내부 보상 기록과 체인상의 토큰은 확인하는 곳과 상태가 다릅니다. 지갑 경험은 이 차이를 명확히 해야 합니다.

숫자 앞에 붙는 의미

대기 보상, 확정 잔액, 출금 가능한 수량과 체인 잔액은 서로 다른 질문에 답합니다. 아직 정산되지 않은 기록을 확정된 외부 자산처럼 보여 주면 사용자는 이용 가능한 범위를 잘못 판단할 수 있습니다. GCV는 수량과 함께 자산의 종류, 환경과 상태를 구분하는 원칙을 따릅니다. 특히 Testnet의 시험용 토큰을 실제 거래 가능한 시장 가치로 설명하지 않습니다. 표시를 단순하게 만들더라도 이 의미까지 지워서는 안 됩니다.

이력은 결과의 근거

현재 합계만 있으면 예상과 다른 변화가 생겼을 때 이유를 찾기 어렵습니다. 어떤 활동, 정산이나 내부 이동으로 값이 바뀌었는지 연결된 이력이 필요합니다. 이력에는 원래 사건, 상태와 확인 시점을 따라갈 수 있는 정보가 있어야 합니다. 같은 요청을 다시 조회했을 뿐인데 새로운 보상 행이 생기면 안 됩니다. 이용자는 과거 기록을 바탕으로 자신의 활동과 현재 잔액 사이의 관계를 이해할 수 있어야 합니다.

내부 이동과 외부 이전

서비스 내부에서 기록의 소유를 이동하는 것과 블록체인으로 토큰을 보내는 것은 같은 실행이 아닙니다. 외부 이전에는 지갑의 소유와 대상 네트워크, 실제 거래 결과를 확인하는 절차가 필요합니다. 내부에 처리됨이 표시됐다는 이유만으로 체인 거래가 성공했다고 판단할 수 없습니다. 두 단계가 연결될 때에도 중복 지급과 이중 사용을 막아야 하며, 대기 중인 요청은 원래 상태를 확인해 복구해야 합니다.

조회 실패를 해석하는 방법

연결 문제로 잔액을 읽지 못했다고 해서 잔액이 사라졌다고 단정할 수는 없습니다. 반대로 이전 값이 보인다고 해서 최신 거래가 반영됐다고 볼 수도 없습니다. 화면은 마지막 확인 정보와 실패 상태를 구분하고, 사용자가 필요할 때 다시 조회할 수 있어야 합니다. 금액을 추정해 채워 넣는 것보다 미확인이라고 알리는 편이 정확합니다. 계정과 네트워크를 확인하는 절차도 이런 오해를 줄이는 데 도움이 됩니다.

안전한 이용을 돕는 설명

지갑 화면은 코인의 미래 가격을 암시하는 곳보다 현재 기록을 정확히 설명하는 곳이어야 합니다. 외부 주소를 확인하거나 승인하는 중요한 선택은 이용자가 직접 수행해야 합니다. 서명이나 전송이 필요한 기능은 준비 상태와 확인 절차를 별도로 안내합니다. GCV는 지갑의 시각적 완성도와 함께 기록의 대사, 실패 복구와 자산별 구분을 발전시켜 이용자가 자신의 상태를 이해할 수 있도록 하려 합니다.

목차 ↑

021 / 100 · 제품 경험

안내는 필요한 순간에 답해야 합니다

Guidance at the Right Moment

좋은 이용 가이드는 기능을 나열하는 데 그치지 않습니다. 지금 무엇을 확인하고 다음에 무엇을 하면 되는지 알려 주어야 합니다.

처음 이용하는 사람의 질문

처음 방문한 사람은 백서 전체를 읽기 전에 공식 앱 주소, 가입 방법과 주요 기능을 알고 싶어 합니다. 처음 안내는 핵심 경로를 짧게 설명하고 자세한 정책으로 이어져야 합니다. 채굴이24시간 주기라는 사실, 추천인 선택의 조건과 활동별 한도처럼 이용 결정에 영향을 주는 내용은 쉽게 찾을 수 있어야 합니다. 모든 설명을 첫 화면에 모아 부담을 주는 대신, 필요한 순간에 필요한 깊이의 정보를 제공하는 것이 바람직합니다.

상태에 맞는 도움말

같은 버튼이 비활성화되어도 이유는 다를 수 있습니다. 로그인 전인지, 오늘 한도를 사용했는지, 서버 확인이 늦는지에 따라 다음 행동도 달라집니다. 준비 중이라는 한 문구로 모든 상황을 묶으면 이용자는 반복해서 시도하게 됩니다. 가능한 상태를 정확히 구분하고, 민감한 내부 정보를 노출하지 않는 범위에서 이유를 설명해야 합니다. 오류 안내는 성공하지 않은 요청을 성공으로 꾸미기보다 원래 기록을 보존하며 복구하도록 도와야 합니다.

예시와 실제 결과의 관계

계산 예시는 규칙을 이해하는 데 도움이 되지만 자신의 실제 보상과 같다고 생각하기 쉽습니다. 따라서 예시에는 기본률, 유효 시간, 횟수와 반감 여부를 명시해야 합니다. 하루 내내 효과가 유지된 가정과 늦게 활성화한 효과의 결과는 다릅니다. 가이드에서는 한 가지 최대값만 강조하기보다 일상적인 상황과 경계 사례를 함께 설명하는 것이 좋습니다. 사용자가 결과를 스스로 비교할 수 있을 때 문의의 질도 높아집니다.

문의에서 필요한 최소 정보

문제를 설명할 때에는 기능 이름, 발생 시각과 고정된 오류 종류처럼 필요한 정보를 중심으로 안내하는 것이 적절합니다. 비밀번호나 비밀키, 불필요한 개인정보를 공개 문의에 적도록 요구해서는 안 됩니다. 같은 내용을 반복 제출하는 것이 해결을 빠르게 만드는 것은 아니므로 원래 문의와 후속 확인을 연결할 수 있어야 합니다. 이용자가 무엇을 이미 완료했는지 기록하면 불필요한 로그인과 설정 반복을 줄일 수 있습니다.

문서도 제품처럼 개선하기

가이드는 한 번 작성하고 끝나는 문서가 아닙니다. 자주 생기는 오해와 새 정책을 반영하되 이전 설명의 적용 시점을 남겨야 합니다. 화면에서 사용하는 이름과 문서 제목이 맞는지, 링크가 실제 목적지로 이어지는지 확인하는 일도 중요합니다. GCV는 문의를 개별 답변으로만 끝내기보다 누구나 이해할 수 있는 설명으로 축적하려 합니다. 이 과정은 운영 부담을 줄이는 동시에 이용자의 독립적인 문제 해결을 돕습니다.

목차 ↑

022 / 100 · 제품 경험

휴대폰에서 이어지는 일관된 경험

Continuity on Mobile

모바일 이용은 항상 한 화면에서 끝나지 않습니다. 앱 전환, 통신 지연과 화면 복귀를 포함해 기록과 선택이 일관되게 이어져야 합니다.

Pi Browser와의 관계

GCV는 Pi 인증과 Pi 결제처럼 해당 환경의 기능을 사용하는 흐름을 구분해서 안내합니다. 일반 브라우저에서 공개 문서를 읽는 경험과 Pi Browser에서 이용자가 승인하는 기능은 같지 않습니다. 링크를 눌렀다는 사실만으로 다른 앱의 실행이나 인증이 완료됐다고 가정하지 않아야 합니다. 사용자는 현재 어떤 환경에 있는지와 다음 단계에서 무엇을 승인하는지 알 수 있어야 합니다. 공식 기능의 실제 지원 범위는 해당 문서와 실행 결과로 확인합니다.

기능 지원의 차이를 견디기

휴대폰의 브라우저 버전은 이용자마다 다릅니다. 새 기기에서 가능한 언어 기능이나 화면 동작이 다른 환경에는 없을 수 있습니다. 핵심 흐름이 특정 기능 하나의 부재로 조용히 중단되지 않도록 호환성을 확인하는 것이 필요합니다. 다만 오류가 있다는 이유로 회원 식별이나 응답 검증을 느슨하게 만들어서는 안 됩니다. 같은 안전 조건을 유지하면서 지원 환경을 넓히는 방식이 모바일 품질의 중요한 과제입니다.

떠났다가 돌아오는 상황

게임 중 다른 화면으로 이동하거나 광고 뒤 앱으로 돌아올 때에는 원래 실행의 상태를 확인해야 합니다. 복귀 자체를 새 활동으로 인정하거나 같은 종료를 여러 번 처리하면 횟수와 보상이 달라질 수 있습니다. 반대로 이미 확인된 결과를 단순 화면 이탈 때문에 잃어서는 안 됩니다. 앱 안에서 처리한 나가기와 운영체제의 강제 종료, 통신 단절은 서로 다르므로 실제로 확인된 종료 근거를 바탕으로 복구하는 흐름이 필요합니다.

시간과 연결의 표시

휴대폰의 시계가 서버와 다를 수 있고, 네트워크 요청도 즉시 끝나지 않을 수 있습니다. 중요한 기간과 만료는 서버가 확인한 기준을 따라야 합니다. 화면의 카운트다운은 이해를 돕는 표시이며 그 자체가 새 시간을 부여하지 않습니다. 오래 기다린 응답이 도착했다고24시간 주기가 연장되어서는 안 됩니다. 연결 상태를 정확히 알리고 원래 요청을 확인하는 경험이 불필요한 반복 실행을 줄입니다.

실기기 검증의 의미

자동 검사는 다양한 조건을 빠르게 확인할 수 있지만 실제 휴대폰의 터치, 소리와 앱 전환을 모두 대신하지는 못합니다. GCV는 기능별로 어떤 기기와 상황을 확인했는지 기록하는 접근을 지향합니다. 하나의 성공 화면을 모든 회원의 성공으로 확대하지 않고, 실패 사례의 조건을 이해해 개선해야 합니다. 모바일 경험의 완성도는 첫 진입뿐 아니라 중단과 복귀 뒤에도 이용자가 자신의 상태를 잃지 않는지에서 드러납니다.

목차 ↑

023 / 100 · 참여자와 생태계

회원은 생태계 경험의 중심입니다

Members at the Center

회원의 가치는 모집 숫자만으로 설명할 수 없습니다. 일상에서 서비스를 이용하고 기록을 이해하며 개선에 참여하는 경험이 생태계의 중심입니다.

참여 방식의 다양성

어떤 회원은 운동과 게임을, 다른 회원은 채굴 상태와 기록 확인을 중심으로 이용할 수 있습니다. 모든 사람이 같은 활동을 같은 빈도로 해야 하는 것은 아닙니다. GCV는 활동별 규칙을 설명하고 사용자가 목적에 맞는 이용 방식을 선택하도록 돕는 방향을 지향합니다. 서비스의 가치를 이해하기 위해 반드시 많은 사람을 초대해야 하는 구조로 설명하지 않습니다. 초대는 하나의 참여 경로이고, 개인의 실제 활동과 기록은 그 자체로 구분되어야 합니다.

본인 기록을 이해할 권리

회원은 자신의 활동이 인정됐는지, 오늘의 횟수가 어떻게 바뀌었는지와 보상이 어느 상태인지 알 수 있어야 합니다. 금액이 다르게 보인다면 반감이나 유효 시간, 한도 같은 근거를 찾아볼 수 있어야 합니다. 기록을 이해할 수 없으면 정상적인 차이도 오류처럼 느껴지고, 실제 오류를 발견하기도 어렵습니다. GCV는 회원에게 결과만 통보하기보다 결과를 판단하는 데 필요한 설명과 이력을 제공하는 방향을 택합니다.

회원이 지켜야 할 경계

다른 사람의 계정이나 지갑을 사용하거나, 같은 활동을 새 요청처럼 반복해 추가 보상을 얻으려 하면 기록의 신뢰성이 훼손됩니다. 자기추천과 순환추천, 유효하지 않은 QR 사용도 실제 조건을 충족한 참여와 구분됩니다. 정상적인 재시도는 원래 요청을 복구하는 수단이며 새 보상을 만드는 수단이 아닙니다. 회원은 자신의 인증과 승인 정보를 보호하고, 이해하지 못한 자산 이동을 다른 사람의 안내만으로 실행하지 않는 것이 중요합니다.

의견을 제품 개선으로 연결

이용자가 겪는 불편은 개발자가 시험 환경에서 발견하지 못한 조건을 알려 줍니다. 특정 화면에서 글씨가 잘리거나, 게임 뒤 상태가 갱신되지 않거나, 설명이 서로 다르게 느껴지는 사례가 그 예입니다. 구체적인 상황과 확인된 결과를 알려 주면 문제를 재현하고 우선순위를 정하기 쉬워집니다. 개인정보와 비밀을 공개하지 않는 범위에서 의견을 전달할 수 있는 안내가 필요하며, 개선 결과도 이해할 수 있는 말로 돌아와야 합니다.

성장을 함께 평가하는 기준

회원 수가 증가해도 기존 회원의 문의와 기록이 방치되면 생태계의 질은 높아졌다고 보기 어렵습니다. 새로운 기능이 실제로 도움이 되는지, 오류에서 복구하기 쉬워졌는지와 핵심 설명이 더 명확해졌는지를 함께 살펴야 합니다. GCV는 활발한 참여와 책임 있는 이용, 개선에 대한 의견이 함께 순환하는 공동체를 지향합니다. 회원을 단순한 보상 수령자나 홍보 대상으로만 보지 않는 것이 장기 관계의 출발점입니다.

목차 ↑

024 / 100 · 참여자와 생태계

크리에이터는 이해의 폭을 넓힙니다

Creators and Clear Communication

유튜버와 인플루언서는 복잡한 이용 방법을 쉽게 설명하고 서로 다른 공동체를 연결할 수 있습니다. 영향력에는 설명의 정확성이 함께 따라야 합니다.

교육과 소개의 역할

크리에이터는 가입 과정을 시연하고 활동 규칙을 설명하며 공식 문서를 찾기 쉽게 소개할 수 있습니다. 영상이나 짧은 게시물은 처음 이용하는 사람의 장벽을 낮추는 데 도움이 됩니다. 그러나 짧은 설명일수록 생략한 조건이 중요할 수 있습니다. 하루5회가 종목별5회인지 전체5회인지, Testnet과 다른 환경이 어떻게 다른지를 정확히 전달해야 합니다. GCV가 지향하는 좋은 홍보는 관심을 끄는 것과 이해를 높이는 일을 함께 수행합니다.

보상 자산을 정확히 설명

정책상 크리에이터의 확정된 활동·QR·홍보 보상 자산은 GCV입니다. 본사와 연합회의 Pi 수익 배분표에 크리에이터의 GCV 보상을 같은 금액으로 더하지 않습니다. 크리에이터가 Pi 또는 USDT 광고 수익의 일정 비율을 자동으로 받는다고 안내해서도 안 됩니다. 별도 채널의 추가 홍보 보상액과 조건, 지급 시기는 확정된 계약이 있어야 하며 영향력이나 팔로어 수만으로 임의의 지급 약속이 생기지 않습니다.

초대와 QR의 제한

일반 모집과 추천관계 저장은 무제한이지만 당일 채굴 추천의 계산 반영은 최대314명입니다. 전용 가입 QR별 발급자 보상 총314회도 별개의 제한입니다. 이 차이를 잘 설명하면 신규회원은 초대 링크와 보상의 관계를 올바르게 이해할 수 있습니다. 한 가입에서 발급자와 추천인 보상을 중복해서 더하는 방식은 사용하지 않습니다. QR 화면이 있다는 이유로 모든 계정에게 발급 권한이 있다고 소개하지 않는 것도 중요합니다.

과장 대신 재현 가능한 설명

최대 계산 예시를 일반 회원의 확정 수익처럼 제시하거나 가격 상승을 약속하면 이용자는 실제 조건을 오해할 수 있습니다. 설명에는 예시의 가정과 기준일을 붙이고, 실제 실행이 필요한 부분은 공식 화면으로 안내하는 편이 좋습니다. 오래된 영상의 정책이 바뀌었다면 수정 안내나 최신 링크를 연결해야 합니다. 비밀키 제출과 대리 서명, 광고 클릭 강요처럼 이용자의 통제권을 해치는 방식은 건강한 교육의 일부가 될 수 없습니다.

장기적인 신뢰의 자산

크리에이터의 기여는 처음 들어온 인원뿐 아니라 이용자가 정보를 이해하고 문제를 줄이는 데에도 있습니다. 반복되는 질문을 모아 공식 안내의 개선점을 제시하고 지역 언어의 오해를 알려 주는 일은 생태계 전체에 도움이 됩니다. GCV는 정확한 설명과 정직한 수정이 존중되는 협력 문화를 지향합니다. 구체적인 협업 프로그램은 실제 범위와 조건이 준비된 뒤 안내하며, 이 비전만으로 계약이나 지급을 약속하지 않습니다.

목차 ↑

025 / 100 · 참여자와 생태계

연합회의 지역 협력과 책임

Associations and Local Support

연합회는 지역의 질문과 경험을 공식 서비스에 연결하는 협력 역할을 지향합니다. 지원 활동, 업무 자격과 자산 배분은 각각의 기준으로 이해해야 합니다.

지역에서 필요한 도움

같은 기능을 제공하더라도 이용자가 어려움을 느끼는 지점은 지역마다 다를 수 있습니다. 연합회는 공식 이용 방법을 설명하고 자주 발생하는 질문을 모으며, 현지 이용 경험을 운영에 전달하는 역할을 할 수 있습니다. 지역 지원이 효과적이려면 개인적인 약속보다 공통 문서와 확인된 정보를 기준으로 답해야 합니다. 회원의 비밀번호나 지갑 비밀을 수집하지 않고도 어떤 화면에서 어떤 문제가 생겼는지 전달하는 방식이 바람직합니다.

자격과 실행 권한의 구분

연합회 관련 신청이나 승격의 업무 상태가 있다고 해서 회원 잔액을 바꾸거나 자산을 전송할 권한이 자동으로 생기는 것은 아닙니다. 업무 자격, 관리자 역할과 금융 실행 권한은 목적에 맞게 나누어야 합니다. 화면에서 보이는 메뉴 역시 실제 서버 권한 확인을 대신하지 않습니다. GCV는 지역 협력을 넓히면서도 보호된 정보와 중요한 실행의 범위를 명확히 하는 방향을 유지합니다. 권한은 이름이나 관계가 아니라 현재 승인된 조건에 따라 판단되어야 합니다.

두 종류의 배분

연합회에는 전체 GCV 공급 설계의5% 배정과 Pi 수익의 최종10% 배분 정책이 각각 존재합니다. 두 수치는 자산도 기준도 다릅니다. GCV 배정량은15,707,950,000 GCV의 전체 설계 수량이며 실제 지갑 배분 완료를 뜻하지 않습니다. Pi 수익은 확정된 배분 기준금액에 정책을 적용하는 별도의 흐름입니다. 예를 들어 기준이1,000 Pi라면 연합회 몫은100 Pi이며, 이 금액을 같은 숫자의 GCV 보상으로 바꾸어 기록하지 않습니다.

지역 운영의 투명성

지원 활동에서 발생한 문의와 해결 상태, 공식 안내의 변경 사항을 일관되게 기록하면 지역별 설명이 달라지는 문제를 줄일 수 있습니다. 실제 배분이 이루어질 때에는 예정과 완료를 구분하고 지급 근거가 있어야 합니다. 지역 조직의 이름만으로 공식 파트너십이나 독점 권한을 추정해서는 안 됩니다. 운영의 책임과 보고 범위를 구체적으로 정하는 일은 규모가 커질수록 더 중요해집니다.

협력의 성과를 보는 관점

지역 협력의 성과는 신규회원 수뿐 아니라 정확한 교육, 반복 문의의 감소와 문제 전달의 품질에서도 볼 수 있습니다. 이러한 평가는 앞으로 구체화할 운영 방향이며 현재의 보상 산식으로 새로 적용하지 않습니다. GCV는 지역 구성원이 자신의 경험을 공유하고 다른 이용자의 이해를 돕는 관계를 지향합니다. 단기 모집 경쟁보다 오랫동안 유지되는 신뢰를 중심으로 연합회 역할을 발전시키고자 합니다.

목차 ↑

026 / 100 · 참여자와 생태계

본사와 코어팀의 운영 책임

Headquarters and Core Responsibilities

생태계를 이끄는 역할은 많은 권한을 갖는 일만이 아닙니다. 규칙을 설명하고 기록을 보호하며 변경의 결과에 책임지는 일이 함께 필요합니다.

공통 기준을 유지하는 역할

본사와 코어팀은 제품의 방향, 정책과 운영 기준을 일관되게 관리하는 중심 역할을 맡는 방향입니다. 회원 화면, 홈페이지와 문서가 서로 다른 보상 규칙을 안내하면 이를 정리해야 합니다. 정책을 바꿀 때에는 이유, 적용 대상과 효력 시점을 설명하고 과거 기록의 의미를 보존해야 합니다. 운영자가 편리하다는 이유로 기존 회원의 관계나 잔액을 다시 만들어 넣지 않는 것도 공통 기준을 지키는 책임에 포함됩니다.

자산과 수익의 책임

전체 공급 설계에서 코어팀 배정은20%이며 Pi 수익 정책에서 본사·코어팀의 최종 비율은90%입니다. 두 비율은 같은 재원을 나누는 숫자가 아닙니다. 또한 Pi 수익90% 전체를 개인 순이익이나 자유롭게 사용할 수 있는 현금으로 단정할 수 없습니다. 실제 운영비, 조정과 지급의 흐름을 구분해야 합니다. 공급 계획, 실제 입금과 배분 완료를 각각 설명하는 것이 규모와 관계없이 필요한 기본 책임입니다.

변경을 실행하기 전의 판단

화면 문구를 바꾸는 일, 서버 기능을 배포하는 일과 실제 자산 이전은 영향이 다릅니다. 변경의 범위에 맞는 검증과 확인 절차가 필요합니다. 중요한 운영 실행에서는 대상 계정과 자원, 기존 자료의 보존 방법을 확인해야 합니다. 테스트가 성공했다는 이유만으로 별도 권한이 필요한 실행까지 자동으로 허용되는 것은 아닙니다. GCV는 개발 속도를 높이면서도 무엇을 변경했는지 설명할 수 있는 운영을 지향합니다.

문제 앞에서의 설명 책임

서비스 장애나 잘못된 안내가 발견되면 영향을 받은 기능과 현재 대응 상태를 알려야 합니다. 원인을 확인하지 못했는데 사용자의 입력 실수라고 단정하면 신뢰를 잃기 쉽습니다. 이미 완료한 설정과 확인을 보존하고, 새로 필요한 조치만 구체적으로 안내하는 편이 낫습니다. 복구가 완료됐다는 판단에도 실제 결과가 필요합니다. 임시 우회와 최종 해결을 구분하고 남은 위험을 이해할 수 있는 말로 설명해야 합니다.

장기적인 조직 역량

1인 창업의 민첩함은 장점이지만 서비스가 성장하면 업무가 특정 사람의 기억에만 의존해서는 안 됩니다. 승인된 결정과 실행 이력, 문의와 복구 절차를 이어받을 수 있는 구조가 필요합니다. GCV는 도구와 자동화를 이용하더라도 책임의 주체를 흐리지 않는 운영을 지향합니다. 자동화가 무엇을 했는지 확인하고 중요한 선택은 명확한 권한 아래 처리하는 체계가 글로벌 성장의 기반이 됩니다.

목차 ↑

027 / 100 · 참여자와 생태계

개발자의 기여는 연결의 정확성에서 시작됩니다

Developers and Reliable Connections

기능이 존재한다는 것과 끝까지 올바르게 연결된다는 것은 다릅니다. 개발자는 사용자의 선택이 기록과 결과로 이어지는 경계를 책임 있게 다뤄야 합니다.

화면에서 원장까지

버튼을 누르면 화면, 통신, 인증과 서비스 처리, 저장과 응답이라는 여러 단계를 거칩니다. 어느 한 단계가 성공했다고 전체 흐름이 끝난 것은 아닙니다. GCV의 개발 방향은 단계마다 입력과 결과의 의미를 명확히 하고, 실패하더라도 원래 요청을 추적할 수 있게 만드는 것입니다. 단순히 성공 문구를 표시하는 것보다 실제 처리 결과가 그 문구와 일치하는지 확인하는 일이 중요합니다. 기존 정상 기능을 새 코드로 불필요하게 다시 쓰지 않는 판단도 필요합니다.

기존 자료를 보존하는 개선

새로운 구조를 도입할 때에는 이전 자료의 의미를 먼저 이해해야 합니다. 과거 테스트 기록, 실제 회원 기록과 확인되지 않은 값은 같지 않습니다. 새 원장을 만든다는 이유로 기존 잔액을 복사하거나0으로 대체하면 안 됩니다. 기능의 전환에는 적용 시점과 원래 자료의 보존, 중복 계산 방지와 확인 방법이 필요합니다. 개발자의 편의보다 기록의 연속성을 우선하는 태도가 사용자 신뢰를 지키는 핵심입니다.

검증의 범위를 설명하기

계산 함수의 시험, 실제 통신 흐름의 시험과 운영 환경 확인은 서로 다른 증거를 줍니다. 각 시험이 무엇을 확인했는지 밝혀야 후속 작업자가 결과를 올바르게 활용할 수 있습니다. 이미 통과한 동일 조건을 반복하는 대신 재현 가능한 결함과 아직 연결되지 않은 계약을 우선하는 것이 효율적입니다. 실패와 미실행 항목도 남겨야 하며, 특정 시험의 건너뜀을 전체 시스템의 성공으로 해석하지 않습니다.

공개 정보와 보호 정보

개발 가이드와 공개 문서는 이용과 협력을 돕지만 내부 운영 자료나 비밀을 노출하는 통로가 되어서는 안 됩니다. 공개 빌드에 무엇이 들어가는지 확인하고, 인증이 필요한 설명은 적절한 권한 영역에서 제공해야 합니다. 코드와 문서에 비밀번호나 비밀키를 저장하지 않는 것은 기본입니다. 새로운 기술을 소개할 때에도 실제 지원 환경과 검증된 범위를 밝히고 아직 확인하지 않은 기능을 작동하는 것처럼 표현하지 않아야 합니다.

참여와 배정의 구분

전체 공급 설계에는 개발자5% 배정이 있습니다. 이 사실만으로 모든 코드 기여자에게 특정 수량이 자동 지급되거나 개별 계약이 성립하는 것은 아닙니다. 실제 협업의 범위와 조건, 평가와 지급은 별도로 정해야 합니다. GCV는 문서화, 오류 재현과 검토를 포함한 다양한 개발 기여를 존중하는 방향을 지향합니다. 기술적 성과는 기능 수뿐 아니라 유지와 설명, 복구가 쉬워졌는지로도 판단할 수 있습니다.

목차 ↑

028 / 100 · 참여자와 생태계

판매자는 실제 거래의 책임을 만듭니다

Sellers and Real Commerce

쇼핑은 상품 화면만으로 완성되지 않습니다. 판매자는 상품의 정확한 정보부터 배송과 문의, 취소·환불까지 연결되는 책임을 갖습니다.

현재 상품 등록 준비 단계

GCV 쇼핑의 실제 상품은 등록 준비 중입니다. 이 단계에서는 존재하지 않는 상품, 가격이나 재고를 운영 중인 판매 정보처럼 표시하지 않습니다. 상품을 소개할 공간이 마련되어 있다는 사실과 주문을 받을 준비가 끝났다는 사실은 다릅니다. 판매자를 위한 발전 방향은 실제 상품의 정보와 운영 조건을 확인한 뒤 이용자가 이해할 수 있는 형태로 공개하는 것입니다. 준비 상태를 정확히 안내하는 것도 거래 신뢰의 시작입니다.

상품 정보의 책임

실제 판매를 시작하려면 상품 이름과 설명, 이미지, 옵션과 가격의 의미가 일치해야 합니다. 색상이나 크기별 재고가 다르다면 이용자가 고른 조합이 무엇인지 확인할 수 있어야 합니다. 화면에 남은 오래된 정보만으로 주문을 확정하면 품절과 가격 차이가 발생할 수 있으므로 서버에서 다시 확인하는 구조가 필요합니다. 판매자는 설명과 실제 제공 내용이 맞도록 관리하고, 중요한 변경을 이용자가 알아볼 수 있게 전달해야 합니다.

결제 이후의 경험

결제가 확인되었다고 모든 거래 책임이 끝나는 것은 아닙니다. 주문 준비, 배송과 수령, 교환·반품과 문의가 이어집니다. 각 상태는 근거에 따라 갱신되어야 하며, 구매자의 개인정보를 공개 화면에 노출해서는 안 됩니다. 실제 배송비와 처리 기한, 반품 주소와 환불 수단은 운영 정보가 확정되어야 안내할 수 있습니다. 이 백서의 상거래 구상으로 아직 정하지 않은 조건을 임의의 약속으로 채우지 않습니다.

Pi 결제의 역할

승인된 방향은 Pi Browser에서 이용자가 직접 승인하는 Pi 결제입니다. 판매자가 임의로 보낸 금액을 그대로 결제하는 것이 아니라 서버가 확인한 상품, 가격과 주문 견적을 기준으로 해야 합니다. Pi SDK의 화면이나 콜백만으로 배송과 환불까지 성공했다고 표시할 수는 없습니다. 기존의 소유자 전용0.01 Test-Pi 시험 경로도 일반 판매를 대신하지 않습니다. 실제 상거래 연결은 별도의 상품과 주문 계약을 따라 준비해야 합니다.

상점 확장의 방향

향후 판매자가 늘어날 때에는 쉬운 등록뿐 아니라 정보 검토, 재고 갱신과 고객지원이 함께 확장되어야 합니다. 어떤 판매자가 이미 참여한다고 확인되지 않았다면 제휴 상점처럼 이름을 공개하지 않습니다. 판매자와 회원이 기대하는 역할을 명확히 하고 문제가 생겼을 때 책임과 문의 경로를 찾을 수 있도록 하는 것이 중요합니다. GCV는 상품 수를 늘리는 속도보다 실제로 제공할 수 있는 거래 경험을 중심으로 쇼핑을 발전시키려 합니다.

목차 ↑

029 / 100 · 참여자와 생태계

파트너십은 이름보다 실제 범위로

Partnerships with Clear Scope

협력은 생태계의 가능성을 넓힐 수 있지만, 사용자가 기대하는 제공 범위와 실제 책임이 명확할 때에만 지속적인 가치를 만듭니다.

함께 해결할 문제부터 정의

유통, 콘텐츠, 기술과 지역 지원 등 여러 협력 가능성이 있지만 모든 협력이 같은 목적을 갖지는 않습니다. 무엇을 개선하려는지, 누구에게 어떤 편익이 있는지와 어떤 역할이 필요한지를 먼저 설명해야 합니다. GCV는 유명한 이름을 나열하는 것보다 실제로 해결할 문제와 제공할 경험을 중심으로 협력을 검토하는 방향을 지향합니다. 이 문서는 아직 체결하지 않은 제휴나 운영 국가를 만들어 발표하지 않습니다.

공식 관계의 표현

특정 플랫폼의 도구를 사용하거나 공개 문서를 참고한다는 사실은 그 플랫폼의 공식 승인이나 제휴를 뜻하지 않습니다. Pi Browser와 Pi 기능을 이용하는 GCV의 흐름도 해당 범위로 설명해야 합니다. 공동 로고, 인증 표시와 제휴 문구는 실제 권한과 범위가 확인된 경우에만 사용하는 것이 적절합니다. 이용자는 관계의 이름보다 무엇이 제공되고 누가 책임지는지를 알 수 있어야 하며, 불분명한 표현으로 기대를 키우지 않아야 합니다.

데이터와 권한의 경계

협력 서비스가 늘어날수록 회원 정보가 어디로 이동하는지와 어떤 권한을 사용하는지가 중요해집니다. 필요한 최소 정보와 목적을 정하고, 기존 동의만으로 새로운 공유가 모두 허용된다고 가정하지 않아야 합니다. 외부 시스템의 오류가 회원 기록을 잘못 바꾸지 않도록 연결 결과를 확인할 방법도 필요합니다. 기술 연동은 편의의 문제뿐 아니라 정보 보호와 책임의 문제이므로, 실제 검토 없이 준비 완료라고 소개해서는 안 됩니다.

정산과 운영의 일치

협력에 수익이나 비용이 발생하면 어떤 자산으로 어떤 사건을 기준으로 기록하는지 분명해야 합니다. 추정 매출과 입금, 환불과 배분을 섞으면 각 참여자가 다른 결과를 기대하게 됩니다. 이미 확정된 Pi 수익90대10 정책과 별도 GCV 활동 보상도 이런 원칙에 따라 구분합니다. 새로운 파트너가 생겼다는 이유로 기존 배분을 조용히 바꾸거나 추가 보상을 만들지 않습니다. 구체 계약이 필요한 사항은 해당 범위에서 공개해야 합니다.

협력 이후의 평가

발표 시점의 관심보다 실제 이용 경험이 좋아졌는지가 중요합니다. 지원 문의가 줄었는지, 제공 범위가 약속과 맞는지와 문제 발생 시 서로 책임을 넘기지 않는지를 살펴볼 수 있습니다. 이 평가 방법은 발전 제안이며 임의의 성과 수치를 붙이지 않습니다. GCV는 시작뿐 아니라 운영과 종료, 변경 시의 안내까지 설명할 수 있는 협력을 지향합니다. 이용자에게 남는 편익이 분명할 때 파트너십의 가치도 오래 지속될 수 있습니다.

목차 ↑

030 / 100 · 참여자와 생태계

역할이 달라도 지켜야 할 공통 책임

Shared Responsibilities

회원, 크리에이터와 운영 조직의 역할은 다르지만 사실을 정확히 전달하고 기록과 선택을 존중해야 한다는 원칙은 같습니다.

기여와 권한을 혼동하지 않기

많은 사람을 초대하거나 활발하게 활동했다는 사실이 다른 회원의 정보에 접근할 권한을 만들지는 않습니다. 콘텐츠 제작, 지역 지원과 개발 기여도 각자의 범위에서 의미를 갖습니다. 역할 이름과 실제 실행 권한은 분리하여 확인해야 합니다. GCV는 참여를 넓히면서도 자산 이동, 개인정보 조회와 중요한 운영 변경의 책임을 명확히 하는 방향을 유지합니다. 누구나 같은 화면 주소를 알 수 있다는 이유로 보호 기능이 열려서는 안 됩니다.

같은 사건을 같은 뜻으로 설명

가입 완료를 가입자 적립과 추천인 지급 완료까지 모두 끝난 상태로 설명하거나, Testnet 발행을 Mainnet 상장으로 소개하면 역할 사이에 오해가 퍼집니다. 공통 용어와 상태의 뜻을 맞추는 것이 협력의 기본입니다. 정책의 최신 버전을 확인하고, 자신이 검증하지 않은 부분은 출처와 시점을 함께 전달해야 합니다. 과거 문서를 발견했을 때에도 최신 결정과 비교하여 그 문서가 어느 시점에 유효했는지 이해할 필요가 있습니다.

문제를 숨기지 않는 전달

회원의 오류 보고, 지역의 반복 문의와 개발 중 실패는 불편한 소식일 수 있지만 개선에 필요한 정보입니다. 성공한 부분만 전달하면 다음 담당자는 남은 위험을 알 수 없습니다. 어떤 조건에서 문제가 생겼는지와 기존 자료가 보존됐는지를 구체적으로 기록해야 합니다. 책임 있는 전달은 모든 내부 로그를 공개하는 일이 아니라, 해결에 필요한 사실을 적절한 범위에서 공유하는 일입니다. 비밀과 개인정보의 불필요한 노출도 피해야 합니다.

약속의 크기를 준비 수준에 맞추기

세계적 성장이라는 비전을 말할 수 있지만 아직 없는 상품과 판매자, 지급 일정이나 확정 수익을 만들어 약속할 수는 없습니다. 각 참여자는 자신의 역할에서 확인할 수 있는 범위를 설명해야 합니다. 새로운 프로그램이 필요하다면 대상과 조건, 운영 책임을 먼저 구체화하는 편이 좋습니다. 큰 목표를 향한 추진력과 작은 약속을 정확히 지키는 태도는 대립하지 않습니다. 실제 준비를 바탕으로 약속을 넓히는 것이 장기 신뢰를 만듭니다.

공동체가 유지되는 방식

건강한 생태계는 의견 차이를 없애는 곳이 아니라 근거를 바탕으로 개선할 수 있는 곳입니다. 이용자의 질문을 홍보에 대한 방해로 취급하지 않고, 정책과 경험의 차이를 찾는 기회로 받아들이는 문화가 필요합니다. GCV는 참여자의 다양한 기여가 공통 원칙 안에서 연결되는 구조를 지향합니다. 그 원칙은 정확한 정보, 본인의 선택, 기존 기록의 보존과 책임 있는 운영이며 이후 모든 장의 판단 기준이 됩니다.

목차 ↑

031 / 100 · 채굴과 활동의 원리

24시간 채굴 주기를 이해하기

The 24-Hour Mining Cycle

GCV의 현재 채굴 정책은 서버가 확인한 시작 시점부터24시간 동안 작동하고, 종료 뒤에는 이용자가 다시 시작하는 방식입니다.

한 번의 시작이 만드는 구간

채굴 시작 요청을 서버가 받아들인 시점을 기준으로 유효 구간을 계산합니다. 정해진 시각에 모든 회원이 동시에 시작하는 방식은 아닙니다. 오전9시에 유효하게 시작했다면 그 주기의 끝은 다음 날 오전9시입니다. 화면을 켜 둔 시간이나 기기의 시계를 바꾼 결과가 서버의 유효 시간을 대신하지 않습니다. 이용자가 확인해야 할 것은 현재 주기가 진행 중인지, 언제 끝나는지와 다음 시작이 필요한지입니다. 이 세 가지 정보가 채굴 경험의 기본 안내가 됩니다.

종료 뒤의 재시작

24시간이 끝나면 해당 주기의 채굴은 멈추고 다시 시작하는 행동이 필요합니다. 다음 날 정오에 재시작했다면 오전9시부터 정오까지의 공백을 채굴한 것으로 채우지 않습니다. 이용자는 일정에 맞게 돌아올 수 있으며, 늦게 돌아왔다는 이유로 이미 유효하게 쌓인 과거 구간을 지우는 구조를 뜻하지도 않습니다. 주기 종료와 기존 기록 보존을 함께 이해해야 합니다. 자동으로 끝없이 이어진다고 기대하는 것과 실제 정책 사이의 차이를 줄이는 설명이 필요합니다.

화면과 서버의 역할

화면의 숫자는 참여 상황을 이해하도록 돕지만 적립 판단은 서버의 유효 구간과 정책에 근거해야 합니다. 네트워크가 끊긴 동안 화면에 보이는 추정값과 나중에 확인한 결과가 다르면 어떤 시간이 인정됐는지 설명할 수 있어야 합니다. 앱을 새로 열거나 상태를 조회한 행동 자체가 채굴을 다시 시작한 것으로 처리되어서는 안 됩니다. 재시작은 분명한 행동과 확인된 결과로 구분할 때 이용자가 자신의 상태를 예측할 수 있습니다.

하루의 경계와 다른 시계

개인별24시간 주기와 UTC-5의 일일 회계 경계는 서로 다른 개념입니다. 회계 날짜가 바뀌었다고 모든 주기가 동시에 끝나지 않으며, 주기가 끝났다고 곧바로 다음 회계 날짜가 되는 것도 아닙니다. 서울 기준 오후2시는 일일 경계이지만 개인의 시작 시각은 언제든 다를 수 있습니다. 이 구분은 오늘 채굴하는 추천인 수, 활동 한도와 날짜별 내역을 함께 읽을 때 특히 중요합니다. 하나의 자정 표시로 두 개념을 합쳐 설명하지 않아야 합니다.

이전 기록에서 현재 정책으로

과거 자료에는 재접속 의무가 없다는 설명이 있었지만 현재의24시간 종료 후 재시작 정책이 그 설명을 대체합니다. 정책이 바뀌었다는 사실은 기존 회원의 검증된 적립을 새 규칙으로 소급해 없애라는 뜻이 아닙니다. 전환 시점과 기존 유효 구간을 구분하여 보존하는 것이 중요합니다. 회원이 오래된 안내를 접하더라도 현재 화면과 이 백서의 주기 설명을 통해 어떤 규칙이 적용되는지 이해하도록 안내를 일치시키는 것이 목표입니다.

목차 ↑

032 / 100 · 채굴과 활동의 원리

적립은 확인된 시간과 조건의 결과

Time-Based Accrual

채굴량을 이해하려면 시간당 표시율뿐 아니라 실제로 인정된 시간과 그 구간에 적용된 조건을 함께 보아야 합니다.

시간당 비율과 실제 수량

시간당0.5GCV라는 표시는 모든 사람에게 매시간 같은 수량을 무조건 준다는 뜻이 아닙니다. 유효 구간이30분이라면 다른 조건이 같을 때 시간에 비례한 계산의 기준은0.25GCV입니다. 한 주기 전체가 유효하고 비율이 바뀌지 않은 경우에만24시간을 곱한 예시를 사용할 수 있습니다. 화면에는 시간당 비율과 이미 확인된 누적량을 구분해 보여 주는 편이 이해하기 쉽습니다. 예상치를 확정 적립으로 먼저 소개하면 이후 확인 과정에서 오해가 생깁니다.

조건이 바뀌면 구간도 나누기

채굴 도중 부스트나 선물의 유효 상태, 오늘 채굴하는 추천인 수가 달라질 수 있습니다. 이 경우 마지막 순간의 높은 비율을 이전 모든 시간에 적용하는 방식으로 이해해서는 안 됩니다. 어떤 조건이 어느 시간에 유효했는지 확인하여 해당 구간의 계산을 설명할 수 있어야 합니다. 정확한 적용 시점은 서버가 확인한 사건과 정책을 따릅니다. 이용자는 한 줄의 총량만 보는 대신 비율이 바뀐 이유를 내역에서 확인할 수 있는 경험을 기대할 수 있습니다.

반복 요청이 시간을 늘리지 않기

느린 통신 때문에 시작 버튼을 여러 번 누르거나 같은 확인 요청이 다시 전달될 수 있습니다. 반복된 요청은 같은 사건을 확인하는 과정으로 처리되어야 하며, 같은 시간을 두 번 적립하는 근거가 되지 않습니다. 이 원칙은 정직하게 한 번 요청한 회원과 여러 번 새로 고침한 회원의 결과를 공정하게 만듭니다. 앱은 처리 중 상태와 완료 결과를 이해하기 쉽게 알려 불필요한 반복을 줄여야 합니다. 실패와 재시도도 최종 기록의 맥락 안에서 구분할 수 있어야 합니다.

회계 날짜를 넘는 예시

서울 오후1시에 채굴을 시작한 회원의 유효 구간은 오후2시 회계 경계를 지나 계속될 수 있습니다. 개인 주기는 그대로 이어지지만 날짜별 내역에서는 경계 전후 시간을 다른 날에 보여 줄 수 있습니다. 오늘의 추천인 판단에도 그 날짜와 겹치는 유효 구간이 중요합니다. 기기의 달력 날짜만 보면 이해하기 어려울 수 있으므로 앱은 적용 기준을 함께 안내해야 합니다. 일일 표시는 활동을 정리하는 방식이며 회원에게 특정 정각 접속을 요구하는 의미가 아닙니다.

오차를 설명할 수 있는 이력

화면의 자릿수 제한 때문에 보이는 합계와 세부 계산이 미세하게 다르게 느껴질 수 있습니다. 이런 경우 표시 반올림과 실제 저장 단위를 분리해 설명하는 것이 바람직합니다. 백서는 검증되지 않은 정밀도나 허용 오차를 임의로 정하지 않습니다. 제품은 사용자가 확인할 수 있는 시간, 적용률과 처리 상태를 제공하는 방향으로 발전해야 합니다. 숫자가 왜 그렇게 나왔는지 추적할 수 있어야 문의를 해결하고 계산 규칙에 대한 신뢰도 쌓을 수 있습니다.

목차 ↑

033 / 100 · 채굴과 활동의 원리

첫 반감의 기준과 보상 계산

The First Halving Threshold

반감은 채굴 보상의 공급 속도를 조정하는 정책입니다. 첫 단계의 기준은 정해진 풀의70% 소진이며, 해당 시점의 기본률을 절반으로 낮춥니다.

기준이 되는 첫 풀

첫 채굴 풀의 기준 수량은31,415,900,000GCV입니다. 이는 전체 설계 수량 중 채굴·회원 몫 안에서 사용하는 첫 단계의 풀로 이해해야 하며, 전체 수량 위에 새롭게 더하는 공급이 아닙니다. 이 풀의70%는21,991,130,000GCV입니다. 숫자의 크기보다 어떤 풀을 분모로 삼는지 정확히 아는 것이 중요합니다. 1차 발행량과 첫 풀의 숫자가 같더라도 발행 사건과 보상 정책상의 풀은 서로 다른 맥락이므로 각각의 기록으로 설명해야 합니다.

기본률이 절반이 되는 의미

반감 전 기본률0.5GCV/시간을 예로 들면 첫50% 반감 뒤의 기본률은0.25GCV/시간입니다. 반감은 조건을 충족한 시점 이후 적용되는 비율 변경으로 설명해야 하며 과거에 정당하게 확정된 보상을 절반으로 다시 깎는다는 뜻이 아닙니다. 이미 반감이 반영된 기본률을 b로 표기하면 이후 활동 가산도 그 b를 기준으로 계산합니다. 같은 반감을 기본률과 가산액에 따로 두 번 적용하지 않는 것이 일관된 계산의 핵심입니다.

도달 여부는 기록으로 확인

첫 반감이 실제로 시작됐다고 발표하려면 해당 풀의 소진 기준과 확인된 누적 기록이 맞아야 합니다. 회원 수가 늘었다거나 Testnet에서 발행이 이루어졌다는 사실만으로70% 소진을 추정할 수 없습니다. 백서는 반감의 규칙과 계산 예시를 제시하며 검증되지 않은 도달 날짜를 만들어 넣지 않습니다. 운영 안내에는 기준 시점과 적용 상태를 함께 제시하는 것이 바람직합니다. 예정과 실제 발동을 구분하면 회원도 비율이 바뀐 이유를 이해할 수 있습니다.

변경 이후에도 읽히는 내역

반감 전후의 내역을 볼 때 같은 활동이라도 적용 기본률이 달라 수량이 다를 수 있습니다. 이는 활동 횟수가 사라졌다는 의미가 아니라 비율이 달랐다는 의미로 설명해야 합니다. 앱의 정책 안내와 계산 기록이 같은 기준을 사용하면 오래된 활동을 확인할 때도 혼란이 줄어듭니다. 향후 단계의 세부 일정과 추가 수치는 별도로 확정하고 공개해야 하며, 첫 반감의 공식만으로 임의의 달력이나 지급 약속을 만들어서는 안 됩니다.

목차 ↑

034 / 100 · 채굴과 활동의 원리

부스트의 효과를 정확히 이해하기

Understanding Boost Effects

부스트는 채굴 계산에 더해지는 참여 효과입니다. 현재 계산식에서는 유효 부스트 한 개당 기본률의60%를 더하며 최대5개를 반영합니다.

곱셈이 아닌 기본률 기준 가산

부스트 수를 B로 두면 효과는 기본률 b에0.6×B를 곱한 가산입니다. 부스트가 늘 때마다 이미 증가한 총률에 다시60%를 곱하는 복리 방식이 아닙니다. 기본률0.5GCV/시간에서 부스트 한 개는0.3을 더하므로 총0.8이고, 두 개는0.6을 더하므로 총1.1입니다. 추천과 선물이 없다면 다섯 개의 총률은2GCV/시간입니다. 예시는 효과가 유효한 구간의 비율을 설명하며 버튼을 누르기만 하면 그 수량이 확정된다는 뜻은 아닙니다.

보유와 적용을 구분

회원이 화면에서 부스트 관련 항목을 보았다는 사실과 서버가 유효한 효과로 인정한 상태는 구분해야 합니다. 언제 시작됐는지, 현재 적용 중인지와 종료된 상태인지가 함께 확인되어야 합니다. 동일한 효과를 여러 화면에서 조회해도 수가 중복으로 증가해서는 안 됩니다. 앱은 최대 반영 수와 현재 유효 수를 나란히 설명하는 방향이 적절합니다. 이용자가 한도에 도달한 뒤 같은 행동을 반복했을 때 어떤 결과가 생기는지도 오해 없이 안내해야 합니다.

다른 효과와 함께 계산

부스트와 선물, 추천 가산은 같은 현재 기본률을 기준으로 합산합니다. 기본률0.5에서 유효 부스트 두 개, 선물 한 개와 오늘 채굴 추천인 세 명이면0.5×(1+1.2+0.4+0.6)로1.6GCV/시간이 됩니다. 부스트를 먼저 적용하고 그 결과에 선물과 추천을 차례로 곱하는 계산과는 다릅니다. 하나의 공식으로 설명하면 어떤 요소가 결과를 바꿨는지 확인하기 쉽고, 화면별로 다른 수치가 표시되는 문제도 줄일 수 있습니다.

반감 뒤의 일관성

기본률이0.25로 낮아진 뒤 부스트 한 개의 가산은0.15GCV/시간입니다. 이미 반감이 반영된 기본률에서60%를 계산하므로 효과 수가 같더라도 전체 비율은 바뀝니다. 과거에 확보한 효과가 있다는 이유로 계속 이전 기본률을 보장하는 것으로 설명하지 않습니다. 동시에 과거 유효 구간에서 이미 확정된 적립을 새로운 기본률로 재계산해 없애는 뜻도 아닙니다. 적용 시점별 조건이 남아 있어야 회원이 두 결과의 차이를 이해할 수 있습니다.

참여를 유도하는 안내의 책임

부스트 안내는 가능한 가산과 실제 조건을 설명하는 데 집중해야 합니다. 정해지지 않은 구매 가격, 확보 방법이나 확정 수익을 백서가 만들어 약속하지 않습니다. 광고나 다른 행동과 연결되는 경우에도 해당 행동의 확인과 효과 적용 결과를 분리해 알려야 합니다. 이용자가 이해한 뒤 선택하고 결과를 확인할 수 있는 경험이 목표입니다. 순간적인 높은 숫자만 강조하기보다 유효 시간과 적용 한도를 함께 보여 주는 것이 장기적인 신뢰에 도움이 됩니다.

목차 ↑

035 / 100 · 채굴과 활동의 원리

선물 효과와 자산 이동은 다릅니다

Gift Effects and Asset Records

채굴 계산에서 선물은 유효 개수에 따른 가산 효과로 다룹니다. 그 효과와 지갑의 토큰 송금은 동일한 사건으로 표현하지 않습니다.

한 개당40%의 가산

유효 선물 수를 G로 두면 현재 채굴 기본률 b에0.4×G를 곱한 값을 더합니다. 반영 한도는5개입니다. 기본률0.5GCV/시간에서 한 개는0.2를 더해 총0.7이고, 다섯 개는1을 더해 총1.5입니다. 이 예시는 다른 효과가 없을 때의 계산입니다. 선물 개수가 늘어날수록 이미 증가한 총률을 다시 곱하는 방식으로 소개하지 않습니다. 기본률과 개수를 나누어 읽으면 회원은 어떤 부분이 자신의 시간당 비율을 구성하는지 이해할 수 있습니다.

선물이 뜻하는 상태

선물이라는 친숙한 이름만으로 실제 토큰이 상대의 개인 지갑으로 이동했다고 생각하기 쉽습니다. 그러나 채굴 가산에 쓰이는 효과와 체인에서 서명한 자산 이동은 서로 다른 확인이 필요합니다. 제품은 선물 효과가 생성되거나 적용된 상태를 그 범위로 설명해야 합니다. 지갑 송금이 있는 경우에는 자산, 네트워크와 별도의 확인 내역이 필요합니다. 회원이 활동 기능의 완료 화면을 보고 외부 지갑 지급까지 끝났다고 오해하지 않도록 용어와 이력을 구분하는 것이 중요합니다.

유효 시간에 적용하는 원칙

선물 효과가 주기 중간에 유효해졌다면 적용 이전 시간까지 자동으로 같은 비율을 되돌려 붙이는 것으로 설명하지 않습니다. 서버가 확인한 적용 조건과 유효 구간을 기준으로 계산해야 합니다. 효과가 종료되거나 반영 한도에 도달했을 때도 현재 수와 적용 상태를 알 수 있어야 합니다. 이 백서는 확정되지 않은 선물의 가격, 구매 절차나 보존 기간을 새로 만들지 않습니다. 구체 행동의 조건은 해당 기능의 최신 안내와 서버 확인 결과에 따라 이해해야 합니다.

합산식으로 보는 사례

기본률0.5에서 부스트 한 개와 선물 두 개가 유효하고 오늘 채굴하는 추천인이 없다면0.5×(1+0.6+0.8)로1.2GCV/시간입니다. 기본률이0.25로 반감하면 같은 조건의 비율은0.6입니다. 선물 가산에도 이미 반감된 기본률을 사용하며 별도 추가 반감을 두 번 적용하지 않습니다. 조건이 유지된 실제 시간만 적립 계산의 대상입니다. 이런 예시는 효과 이름보다 공통 계산 구조를 이해하도록 돕고 과장된 복리 기대를 줄입니다.

사람 사이의 참여를 존중

선물 기능이 관계와 참여를 돕더라도 다른 사람에게 행동을 강요하거나 보상을 확정적으로 약속하는 수단이 되어서는 안 됩니다. 받는 사람의 상태와 선택, 이미 적용된 효과를 존중하는 안내가 필요합니다. 여러 요청이 겹쳤을 때 같은 사건을 중복 처리하지 않고 결과를 확인할 수 있어야 합니다. GCV가 지향하는 사회적 참여는 숫자를 더 크게 보이게 만드는 경쟁만이 아니라 회원이 기능의 의미를 알고 이용하는 경험입니다. 그 경험을 만드는 기준은 명확한 조건과 정확한 기록입니다.

목차 ↑

036 / 100 · 채굴과 활동의 원리

오늘 채굴하는 추천인의 가산

Active Referral Contributions

추천인을 모집하고 저장하는 수에는 제한이 없지만, 채굴률에는 오늘 유효하게 채굴한 추천인 중 최대314명을 반영합니다.

누적 인원과 오늘의 인원

누적 추천인이1,000명이어도 오늘 채굴한 사람이 없다면 추천 가산은0입니다. 기본률0.5GCV/시간에서 다른 효과가 없다면 총률도0.5입니다. 오늘 채굴하는 사람이5명이면 각0.1씩 더해1,10명이면1.5가 됩니다. 이 정책은 과거에 모집한 인원만으로 영구20% 보너스를 계속 더하는 방식과 다릅니다. 누적 추천 수는 관계의 규모를 설명하고 오늘 채굴 인원은 그날의 가산 조건을 설명하므로 두 숫자를 같은 이름으로 표시하지 않는 것이 중요합니다.

서버가 확인한 유효 구간

오늘 채굴했다는 판단은 서버가 인정한 채굴 구간이 해당 UTC-5 회계 날짜와 겹치는지를 기준으로 합니다. 어제 시작한 주기가 오늘까지 유효하게 이어졌다면 오늘의 판단에 포함될 수 있습니다. 오늘 앱을 열거나 로그인만 했다는 사실은 채굴 구간을 대신하지 않습니다. 반대로 오늘 유효한 구간이 있었다면 나중에 주기가 끝났다는 이유만으로 그 사실이 사라지는 것도 아닙니다. 개인 주기와 일일 기준을 나누어 설명해야 회원이 인원 변화를 이해할 수 있습니다.

314명 반영 한도의 계산

공식의 추천 항은0.2×min(N,314)이며 N은 오늘의 유효 추천인 수입니다. 기본률0.5에서314명을 반영하면 추천 가산31.4와 기본0.5를 합해31.9GCV/시간입니다. 오늘 인원이400명이 되어도 이 항에 반영되는 수는314명입니다. 이 한도는 새로운 사람을 초대하거나 추천 관계를 저장하지 못하게 하는 제한이 아닙니다. 가입 QR의 평생 보상 횟수314회와도 목적이 다른 규칙이므로 숫자가 같다는 이유로 하나로 합치지 않습니다.

관계와 활동을 임의로 만들지 않기

추천 가산은 실제로 확인된 관계와 유효 활동을 바탕으로 해야 합니다. 과거 명단에 이름이 있다는 이유로 확인되지 않은 채굴 시간이나 잔액을 만들어 넣는 방식은 정책에 포함되지 않습니다. 기존 추천 귀속도 새로운 캠페인이나 화면 개편을 이유로 임의 변경하지 않습니다. 회원은 자신의 추천 관계와 오늘 가산에 반영된 수를 서로 구분해 확인할 수 있어야 합니다. 숫자가 예상과 다를 때에는 어떤 기준으로 집계됐는지 설명할 수 있는 내역이 필요합니다.

반감과 다른 효과의 연결

추천 가산은 이미 반감이 반영된 현재 기본률의20%입니다. 기본률0.25에서 한 명은0.05를 더하며,314명을 반영하면 기본을 포함해15.95GCV/시간입니다. 부스트와 선물이 함께 있으면 같은 기본률을 기준으로 각각의 항을 더합니다. 특정 추천인을 초대하면 수익이나 토큰 가격이 보장된다는 의미는 없습니다. GCV가 추구하는 성장은 이해한 사람들이 참여하는 관계이며, 보상 공식은 그 관계에서 인정되는 활동을 일관되게 표현하는 역할을 합니다.

목차 ↑

037 / 100 · 채굴과 활동의 원리

가입 보상과 추천 관계가 확정되는 때

Signup Rewards and Referral Finalization

가입자의 한 번 보상, 추천인의 한 번 보상과 매일의 채굴 가산은 서로 다른 규칙입니다. 각각의 조건과 확정 시점을 구분해야 합니다.

가입 단계의 기준 보상

신규 가입자의 기준 보상은314GCV이며 한 번 적용하는 정책입니다. 추천인의 기준 보상은6.28GCV이며 추천 관계가 최종 확정된 뒤 한 번 적용하는 정책입니다. 이러한 기준값은 반감 적용 여부와 실제 처리 상태를 함께 읽어야 합니다. 가입 화면이 표시됐거나 입력을 시작했다는 사실만으로 보상이 확정되지는 않습니다. 같은 가입 요청이 반복됐을 때에도 같은 사건이 중복 지급되는 구조가 되어서는 안 됩니다. 가입과 보상 내역을 연결해 이해할 수 있어야 합니다.

세 가지 보상을 섞지 않기

추천인 가입 보상6.28, 오늘 채굴 추천인에 따른 시간당20% 가산과 가입 QR 발급자 보상은 각각 조건과 한도가 다릅니다. 같은 신규 가입 사건에서 가입 QR 발급자 보상과 추천인 보상을 중복해서 쌓는 것으로 설명하지 않습니다. 추천 관계가 존재한다는 사실만으로 그 회원이 오늘 채굴한 것으로 계산하지도 않습니다. 사용자에게는 어떤 사건의 보상인지 이름과 상태를 나누어 보여 주어야 합니다. 서로 다른 수량을 한 번의 초대 수익으로 합산하면 잘못된 기대를 만들 수 있습니다.

확정 전과 후의 확인

추천 관계를 확인하는 중이거나 보상 처리가 대기 상태일 수 있습니다. 대기라는 표현은 실패와 같지 않지만 완료와도 다릅니다. 회원은 어떤 조건이 남았는지와 이미 확정된 기록이 무엇인지 알 수 있어야 합니다. 운영자는 지연이 발생했다고 검증되지 않은 과거 보상을 임의로 생성하지 않고 원래 사건을 확인해야 합니다. 이 과정에서 기존 회원의 관계와 잔액을 보존하는 것이 기본입니다. 명확한 상태 표시는 가입 직후의 혼란과 반복 문의를 줄이는 데 도움이 됩니다.

목차 ↑

038 / 100 · 채굴과 활동의 원리

두 종류 QR의 목적과 한도

Two QR Experiences

회원 활동용 QR과 신규 가입용 QR은 서로 다른 참여를 연결합니다. 보상 대상, 횟수와 유효기간도 각각의 규칙으로 읽어야 합니다.

회원 활동용의 두 참여자

회원 활동용 QR의 기준 보상은 스캔한 회원31.4GCV와 발급자3.14GCV입니다. 스캔 회원의 보상 인정은 하루2회 한도이며, 같은 화면을 반복 조회하는 행동을 새로운 참여로 보지 않습니다. 기준값에는 해당 반감 정책과 실제 유효성 확인이 함께 적용됩니다. 발급자와 스캔 회원은 다른 역할이므로 각각의 내역에서 무엇이 인정됐는지 확인할 수 있어야 합니다. 링크가 열렸다는 사실과 서버가 유효한 스캔 사건으로 인정했다는 사실도 구분해야 합니다.

신규 가입용의 목적

신규 가입용 QR은 아직 회원이 아닌 사람이 가입 흐름에 진입하도록 돕습니다. 발급자에게 적용되는 평생 보상 횟수 한도는314회입니다. 이는 추천인을314명까지만 모집할 수 있다는 뜻도, 하루314번 보상한다는 뜻도 아닙니다. 가입 QR을 통해 확정되는 보상과 일반 추천인 가입 보상을 같은 사건에서 겹쳐 지급하는 것으로 소개하지 않습니다. QR 이름과 대상 안내를 분명히 하면 기존 회원과 신규 회원이 자신에게 맞는 흐름을 선택할 수 있습니다.

새 QR의 유효기간

현재 새로 발급하는 신규 가입용 QR에는 만료기간을 두지 않는 정책이며, 새로운 회원 활동용 QR은365일 유효기간을 사용합니다. 두 종류가 모두 같은 날 만료된다고 가정해서는 안 됩니다. 기존에 발급된 QR은 발급 당시 조건을 보존하므로 새 정책을 이유로 모든 이전 QR의 기한을 임의로 바꾸지 않습니다. 회원에게 필요한 정보는 자신이 보는 QR의 종류와 실제 유효 상태입니다. 일반 안내만으로 개별 QR의 남은 기간을 추정하지 않도록 표시해야 합니다.

발급과 스캔의 신뢰

QR 이미지를 보여 주는 일은 쉽게 반복할 수 있지만 보상 사건은 서버가 확인해야 합니다. 잘못된 코드, 유효하지 않은 대상과 이미 처리된 사건을 구분하는 과정이 필요합니다. 다른 사람의 QR을 캡처했다는 사실만으로 발급자 역할을 얻거나 귀속을 바꾸는 것은 아닙니다. 앱은 성공, 이미 처리됨과 유효하지 않음 같은 결과를 이해할 수 있게 전달해야 합니다. 사용자가 여러 번 눌러야만 완료되는 것처럼 느끼지 않도록 확인 흐름을 단순하게 만드는 것이 중요합니다.

세 가지314를 따로 기억

가입자 기준 보상314GCV, 가입 QR 발급자의 평생 보상314회와 오늘 추천 가산에 반영하는 최대314명은 단위와 목적이 다릅니다. 같은 숫자를 사용하는 정책이라도 금액, 횟수와 인원을 한 문장으로 섞으면 한도를 잘못 이해할 수 있습니다. 백서와 앱은 숫자 옆에 단위를 함께 적는 원칙을 지향합니다. 회원은 자신이 확인하려는 것이 가입 보상인지 QR 사용 이력인지 채굴률인지 먼저 구분하면 각 기능의 조건을 훨씬 쉽게 읽을 수 있습니다.

목차 ↑

039 / 100 · 채굴과 활동의 원리

운동 참여와 하루 보상 한도

Exercise Participation

운동 기능은 일상 속 참여를 연결하는 경험입니다. 기준 보상은 인정된 한 회당3.14GCV이며 운동 활동 전체의 보상 횟수는 하루5회입니다.

종류보다 공통 한도가 먼저

여러 운동 항목을 이용하더라도 각각에 별도의5회 보상이 무제한으로 생기는 것으로 이해해서는 안 됩니다. 운동 활동의 인정 횟수를 합쳐 하루5회 한도로 관리하는 정책입니다. 반감 전 기준값으로 다섯 회가 모두 인정됐다면3.14×5의 계산 예시는15.7GCV입니다. 이 숫자는 모든 사용자의 매일 자동 적립을 의미하지 않습니다. 실제로 시작하고 종료한 사건, 유효성 확인과 일일 기준이 맞아야 하며 내역에서는 인정 횟수와 참여 횟수를 구분할 수 있어야 합니다.

시작과 종료를 확인하는 과정

운동 화면을 열었다는 사실만으로 한 회가 인정되는 것은 아닙니다. 유효하게 시작된 활동이 완료되거나 정책상 인정되는 종료로 처리됐는지 확인해야 합니다. 시작 전 취소, 서버가 거부한 요청과 실제 활동의 종료는 다른 상태입니다. 기기를 강제로 종료했다는 사실만으로 정상적인 종료가 확인됐다고 단정하지 않습니다. 이런 차이를 화면에서 설명하면 회원은 어떤 행동이 기록됐는지 알 수 있고, 불안해서 같은 활동을 반복 제출하는 일도 줄어듭니다.

여섯 번째 이후의 참여

보상 한도를 모두 사용한 뒤에도 운동 경험을 계속 이용하는 것과 추가 보상을 받는 것은 별개의 문제입니다. 여섯 번째 활동을 할 수 있다는 이유로 여섯 번째 보상까지 발생한다고 소개하지 않습니다. 앱은 남은 보상 횟수와 활동 이용 가능 상태를 나누어 알려야 합니다. 한도가 끝났다는 안내가 이미 확정된 앞선 보상을 취소한다는 뜻으로 읽혀서도 안 됩니다. 숫자와 행동의 의미를 연결하면 보상만을 목적으로 무리하게 반복하는 경험을 줄일 수 있습니다.

기록이 말하는 범위

활동 버튼과 완료 기록은 앱 안에서 확인한 참여 사건을 설명합니다. 별도 검증 없이 특정 건강 효과, 정확한 운동량이나 의료적인 개선을 증명하는 자료로 소개하지 않습니다. 운동의 종류와 이용 안내는 회원이 자신의 상황에 맞게 선택할 수 있도록 명확해야 합니다. 참여 보상과 건강 성과를 동일하게 취급하지 않는 것이 책임 있는 표현입니다. GCV는 일상적 활동을 돕는 경험을 지향하며, 검증되지 않은 효과나 개인별 결과를 수치로 약속하지 않습니다.

날짜와 결과를 함께 보기

운동의 일일 한도는 UTC-5 회계 날짜를 기준으로 이해해야 합니다. 서울의 달력 자정이 지났다는 이유만으로 한도가 바로 새로 생긴다고 가정하면 혼란이 발생합니다. 앱은 어떤 회계 날짜의 남은 횟수인지 안내하고 완료 후 결과를 확인할 수 있게 해야 합니다. 광고가 이어지는 경우에도 운동 종료 확인과 광고 진행 상태를 구분하는 편이 명확합니다. 회원이 한 번의 참여가 어떻게 기록됐는지 알 수 있는 것이 반복 참여의 기본 신뢰를 만듭니다.

목차 ↑

040 / 100 · 채굴과 활동의 원리

게임의 재미와 보상의 경계

Games and Reward Limits

게임은 이용자가 선택해 즐기는 참여 경험입니다. 기준 보상은 인정된 종료 한 회당6.28GCV이며 게임 전체를 합쳐 하루5회까지 보상을 반영합니다.

여러 게임을 하나의 한도로

게임이 여러 종류라는 사실이 보상 한도를 종류별로 새로 만드는 것은 아닙니다. 한 게임에서 세 번, 다른 게임에서 두 번이 인정됐다면 합계 다섯 회입니다. 반감 전 기준 보상으로 계산하면 다섯 회의 예시는31.4GCV입니다. 게임의 점수나 순위가 별도의 확정 환전 금액이라는 의미는 없습니다. 보상은 인정된 참여 사건과 정책에 따릅니다. 이용자는 게임 종류를 바꿔도 공통 한도가 이어진다는 사실을 시작 전과 결과 화면에서 이해할 수 있어야 합니다.

종료의 의미를 분명하게

정상 완료와 정책상 인정된 중도 종료는 유효한 게임 시작과 종료 확인을 바탕으로 다룹니다. 시작 전에 취소했거나 서버가 요청을 받아들이지 않은 경우와는 다릅니다. 브라우저가 갑자기 닫혔다는 사실만으로 보상 가능한 종료를 확인한 것으로 보지 않습니다. 같은 종료 결과가 다시 전송돼도 한 번의 사건으로 처리되어야 합니다. 앱이 종료 중, 확인 완료와 재확인 필요 상태를 구분하면 회원은 자신이 무엇을 기다리는지 알 수 있습니다.

보상이 끝나도 경험은 계속

하루의 보상 한도를 채운 뒤 게임을 계속 즐길 수 있는 경험과 추가 적립은 분리해 안내합니다. 여섯 번째 플레이가 가능하다는 사실을 여섯 번째 지급으로 오해하지 않도록 남은 횟수를 보여 주어야 합니다. 이미 인정된 결과를 보존하고 이후의 참여에는 어떤 조건이 적용되는지 설명하는 방식이 바람직합니다. GCV가 지향하는 게임은 보상 숫자만 높이는 수단이 아니라 스스로 선택하는 재미와 참여의 공간입니다. 확정되지 않은 상금이나 경품을 임의로 약속하지 않습니다.

광고와 게임 상태의 분리

게임 종료 뒤 광고를 요청하는 흐름이 있더라도 광고 요청, 실제 노출과 광고 완료는 각각 다른 상태입니다. 광고가 준비되지 않았다는 이유로 화면이 게임 종료 자체를 알 수 없게 만들어서는 안 됩니다. 회원에게 어떤 사건이 확인됐는지와 어떤 화면이 이어지는지 명확히 알려야 합니다. 별도 광고보기 메뉴가 게임의 일일 보상 횟수를 함께 사용하는 정책이라면 그 공유도 안내해야 합니다. 메뉴 이름이 다르다는 이유로 독립된 추가5회 보상이 생긴다고 설명하지 않습니다.

공정한 참여 경험

통신 속도나 기기의 성능 차이가 같은 게임 사건을 중복 생성하는 이유가 되어서는 안 됩니다. 반복 클릭과 뒤로 가기, 재접속 후에도 결과를 일관되게 확인할 수 있어야 합니다. 잘못된 적립 요청을 막는 과정은 정상 회원에게도 이해 가능한 안내와 함께 제공하는 것이 중요합니다. GCV는 게임 경험의 안정성과 계산의 공정성을 함께 개선하는 방향을 지향합니다. 재미, 결과 확인과 보상 조건이 분리되어 읽힐 때 이용자는 기대와 실제 사이의 차이를 줄일 수 있습니다.

목차 ↑

041 / 100 · 채굴과 활동의 원리

광고 참여와 수익을 정확히 설명하기

Advertising with Clear States

광고는 GCV가 지향하는 주요 사업 수익원 중 하나입니다. 광고를 요청했다는 사실과 실제 수익, 회원 보상은 각각 확인해야 하는 다른 결과입니다.

요청에서 완료까지의 단계

앱이 광고를 요청해도 항상 광고가 제공되거나 노출되는 것은 아닙니다. 광고 요청, 광고 준비, 실제 노출과 완료는 서로 다른 상태이며 회원에게 필요한 안내도 다릅니다. 광고가 없을 때 끝없이 기다리게 하거나 완료되지 않았는데 완료 보상으로 표시하면 신뢰가 낮아집니다. 실제 수익은 광고 제공자의 확인과 정산 기록으로 이해해야 하며 화면의 요청 수만으로 계산하지 않습니다. 운영자는 어느 단계의 숫자를 보여 주는지 분명히 하고 실패와 미제공 상태도 설명할 수 있어야 합니다.

활동 뒤 광고와 별도 광고보기

게임이나 운동 뒤에 이어지는 광고와 광고보기 전용 메뉴는 이용 목적이 다릅니다. 별도 광고보기의 정책상 기준 보상은6.28GCV이며 게임의 하루5회 보상 한도를 공유하는 구조입니다. 그러나 정책과 화면 안내가 있다는 사실만으로 실제 광고 재고와 운영 승인이 모두 준비됐다는 의미는 아닙니다. 회원에게는 현재 이용 가능 여부와 한도 공유를 함께 알려야 합니다. 광고 미제공이나 중도 이탈을 완료로 간주하여 별도 광고보기 보상을 만들어 내지 않는 것이 원칙입니다.

클릭을 보상의 조건으로 만들지 않기

광고를 본다는 행동과 광고주의 사이트를 클릭하거나 구매한다는 행동은 다릅니다. 회원이 적립을 받으려면 광고를 반드시 클릭해야 한다는 식의 안내를 만들지 않습니다. 광고 참여 조건은 해당 서비스의 확인 절차와 실제 정책에 맞아야 합니다. 흥미가 없는 광고를 반복 클릭하도록 유도하면 사용자 경험과 광고 신뢰 모두 나빠질 수 있습니다. GCV는 참여자가 자신의 관심에 따라 행동하고, 무엇이 보상 조건인지 명확히 이해하는 경험을 지향합니다.

Pi 수익과 GCV 보상의 분리

광고·수수료에서 발생하는 Pi 수익은 본사·코어90%, 연합회10%의 정책으로 다룹니다. 반면 회원의 활동 보상은 GCV의 별도 규칙입니다. 광고 한 번의 수익이 얼마인지 확인되지 않은 상태에서 일정 Pi 수익을 회원에게 보장하거나 GCV 보상과 고정 비율로 교환된다고 설명하지 않습니다. 두 자산은 발생 사건, 단위와 기록이 다르기 때문입니다. 사업 수익의 배분과 참여 보상을 나누어 보여 주면 운영 성과와 회원 활동을 각각 정확히 이해할 수 있습니다.

지속 가능한 광고 경험

광고 수를 늘리는 것만으로 건강한 사업을 만들 수는 없습니다. 앱 이용을 방해하는 정도, 광고를 닫거나 돌아오는 경험과 실제 운영 비용을 함께 살펴야 합니다. GCV는 이용자의 시간과 선택을 존중하면서 광고 수익을 서비스 개선으로 연결하는 방향을 지향합니다. 승인 여부, 매출과 수익률을 근거 없이 확정적으로 발표하지 않습니다. 반복 노출보다 명확한 상태, 합리적인 한도와 실제 정산의 투명성이 장기적인 운영의 바탕이 됩니다.

목차 ↑

042 / 100 · 채굴과 활동의 원리

활동에서 내역까지 이어지는 확인

From Activity to Recorded Result

회원이 한 행동과 화면의 결과 사이에는 확인 과정이 있습니다. 대기, 인정, 확정과 자산 이동을 같은 완료 표시로 합치지 않는 것이 중요합니다.

사건을 먼저 확인

채굴 구간, 게임 종료와 QR 참여는 각기 다른 조건을 갖지만 모두 실제 사건을 확인해야 한다는 공통점이 있습니다. 요청을 받았다는 기록만으로 모든 조건을 통과했다고 보지 않습니다. 서버가 대상, 유효 시간과 중복 여부를 확인한 뒤 해당 결과를 내역에 연결해야 합니다. 회원에게는 기술적인 처리 과정 전체를 보여 줄 필요는 없지만 현재 상태와 남은 확인을 알 수 있어야 합니다. 이 흐름이 명확하면 버튼을 누른 즉시 모든 자산 처리가 끝났다는 오해를 줄일 수 있습니다.

대기를 실패로 단정하지 않기

연결 지연이나 확인 순서 때문에 처리 중인 상태가 잠시 이어질 수 있습니다. 대기는 아직 완료를 확인하지 못했다는 뜻이지 자동 실패나 자동 지급을 의미하지 않습니다. 앱은 기다릴지, 다시 확인할지와 문의가 필요한 상황을 구분해서 안내하는 방향이 적절합니다. 회원은 같은 사건을 새 활동으로 계속 생성하기보다 기존 결과를 확인할 수 있어야 합니다. 재시도는 원래 사건을 안전하게 마무리하는 수단이며 추가 보상을 얻는 새로운 기회가 아닙니다.

하루를 나누는 기준

GCV의 일일 활동 한도와 회계 날짜는UTC-5를 사용합니다. 이 경계는UTC 오전5시, 한국 시간 오후2시에 해당합니다. 한국의 자정에 일일 숫자가 바로 바뀌지 않아도 그 사실만으로 오류라고 단정할 수 없습니다. 날짜별 내역에는 어떤 기준으로 나눴는지 설명이 필요합니다. 반면 회원의24시간 채굴 주기는 자신의 시작 시각을 기준으로 별도로 움직입니다. 오늘이라는 같은 단어를 사용하더라도 집계 날짜와 주기 만료를 구분하면 결과를 훨씬 쉽게 해석할 수 있습니다.

확정 내역과 체인 지급

앱 내부에서 활동 적립이 확정됐다는 사실과 개인 지갑으로 토큰이 전송됐다는 사실은 다릅니다. 각 단계에는 서로 다른 기록과 조건이 필요합니다. 내부 수량이 표시됐다는 이유로 체인 거래 해시가 존재한다고 가정하지 않으며, Testnet의 발행 거래를 개별 회원의 지급 증거로 사용하지도 않습니다. 회원에게는 어떤 장부의 어떤 상태인지 정확히 알려야 합니다. 이 구분은 자산의 의미를 축소하는 것이 아니라 현재 확인된 범위를 분명히 하여 다음 단계의 신뢰를 만드는 방식입니다.

문의에 도움이 되는 정보

결과가 예상과 다를 때에는 활동 종류, 대략의 시각과 화면에 나온 상태를 확인하는 것이 출발점입니다. 비밀번호나 지갑의 비밀문구를 전달할 필요는 없습니다. 운영자는 동일 사건의 기록을 확인하고 오류가 있었다면 무엇을 바로잡았는지 설명할 수 있어야 합니다. 기존 정상 기록을 한꺼번에 초기화하는 방식으로 문제를 해결해서는 안 됩니다. GCV는 이력과 상태가 이어지는 경험을 통해 회원이 자신의 참여 결과를 스스로 확인하고 필요한 도움을 받을 수 있도록 발전시키고자 합니다.

목차 ↑

043 / 100 · 발행과 경제 설계

1차 발행량과 확인된 발행 기록

First Issuance and Evidence

GCV의 1차 발행량은31,415,900,000GCV입니다.2026년10월5일의 Pi Testnet 발행 기록이 있으며, 이번 판에서는 실제 확인된 이 사실을 기준으로 설명합니다.

먼저 읽어야 할 핵심 수량

사용자가 확정한1차 발행량은31,415,900,000GCV이며 전체 설계 수량314,159,000,000GCV와 구분합니다. 1차라는 표시는 발행 단계의 범위를 명확히 하기 위한 표현입니다. 전체 설계 수량이 이미 모두 발행되었다는 뜻으로 사용하지 않습니다. 또한1차 수량을 전체 수량에 더해 합계를 늘리지 않습니다. 홈페이지, 앱과 백서는 이 두 수량의 이름을 일관되게 사용하여 회원이 공급 설계와 확인된 사건을 각각 이해할 수 있도록 해야 합니다.

공개 기록이 확인하는 사실

확인된 발행 시점은2026년10월5일11시55분25초UTC이며 원장 번호는27008124입니다. 공개 Testnet 기록의 발행 수량은31,415,900,000.0000000GCV입니다. 이 정보는 발행 사건의 네트워크, 시점과 수량을 확인하는 근거입니다. 실제 기록이 존재하므로 현재 백서를 미발행 상태의 설명으로만 남겨 두는 것은 정확하지 않습니다. 동시에 이 기록의 범위를 넘어 모든 회원에 대한 지급이나 모든 운영 기능의 완료까지 선언해서도 안 됩니다.

발행이 뜻하지 않는 것

이번 근거는 Pi Testnet의 발행 기록입니다. Mainnet 발행, 거래소 상장과 개인 회원의 지갑 지급 완료는 각각 별도의 사건과 확인이 필요합니다. 특정 수량이 발행됐다는 사실만으로 시장가격, 거래 가능성이나 환금성이 생기는 것도 아닙니다. 독자는 발행량이라는 공급 정보와 실제 이용 가능한 기능을 따로 확인해야 합니다. GCV는 이 구분을 통해 확인된 성과를 정확히 전달하고, 다음 단계에서 무엇을 추가로 확인해야 하는지도 분명히 하고자 합니다.

다음 기록과 연결하는 방식

후속 단계가 진행되면 네트워크, 자산 식별 정보와 거래 시점을 연결하여 검증 가능한 이력을 이어 가야 합니다. 하나의 해시를 모든 활동의 완료 증거로 반복 사용하지 않고 각 사건에 맞는 근거를 제시하는 방식이 중요합니다. 발행 기록은 공급 사실을, 회원 지급 기록은 해당 지급을, 상품 결제 기록은 해당 주문의 결제를 설명합니다. 백서의 업데이트도 이 사건별 구분을 유지해야 이용자가 새로운 성과와 남아 있는 과제를 함께 이해할 수 있습니다.

목차 ↑

044 / 100 · 발행과 경제 설계

전체 설계 수량과 단계별 공급

Designed Supply and Issuance Stages

전체 설계 수량은314,159,000,000GCV입니다. 이 숫자는 경제 구조의 기준이며 실제 발행, 배분과 유통 상태는 별도의 기록으로 확인합니다.

설계 수량의 역할

전체 설계 수량은 각 목적에 얼마를 배정하는지 계산하는 공통 기준입니다. 같은 비율이라도 분모가 다르면 수량이 달라지므로 전체 공급 설계를 설명할 때에는 항상314,159,000,000GCV를 기준으로 합니다. 1차 발행량31,415,900,000GCV는 그10%에 해당합니다. 이 관계를 설명하는 목적은 공급의 구조를 쉽게 읽도록 돕는 것입니다. 전체 설계 수량의10%가 발행됐다는 사실만으로 경제적 가치나 시장에서 거래되는 비율을 추정할 수는 없습니다.

발행과 유통은 다른 질문

발행량은 특정 네트워크에서 생성된 수량을 묻고, 유통 상태는 누가 어떤 조건에서 실제 사용할 수 있는지를 묻습니다. 발행한 자산이 특정 지갑에 보관돼 있다는 사실과 일반 회원에게 배분돼 사용되는 상태는 다릅니다. 전체 설계 비율 역시 현재의 지갑별 잔액을 그대로 보여 주는 표가 아닙니다. 따라서 공급을 설명할 때에는 설계, 발행 기록, 보관과 배분의 증거를 나누어야 합니다. 확인되지 않은 유통량을 단순 차감이나 비율 계산만으로 발표하지 않습니다.

같은 숫자를 두 번 더하지 않기

1차 발행량과 첫 채굴 풀은 모두31,415,900,000이라는 수량을 사용하지만 의미는 다릅니다. 전자는 확인된 발행 단계의 양이고 후자는 채굴 보상 정책을 계산하는 풀의 기준입니다. 이 둘을 각각 새로운 공급으로 더하면 설계 수량을 잘못 이해하게 됩니다. 첫 채굴 풀은 전체 배분 중 채굴·회원50% 몫 안의 첫 단계입니다. 회원에게는 숫자의 단위뿐 아니라 그 숫자가 속한 구조를 함께 설명해야 공급과 보상의 관계가 명확해집니다.

남은 설계 수량의 해석

전체 설계 수량에서1차 수량을 뺀 산술적인 차이는282,743,100,000GCV입니다. 그러나 이 차이 자체가 특정 날짜에 자동 발행되거나 누구에게 즉시 지급될 잔액을 뜻하지 않습니다. 후속 발행의 시점, 네트워크와 실행 조건은 별도로 확정하고 기록해야 합니다. 백서는 확인되지 않은 다음 단계의 일정이나 판매 계획을 만들어 제시하지 않습니다. 수학적으로 계산할 수 있는 값과 실제로 승인되고 실행된 사건을 나누는 것이 공급 정보의 신뢰를 지킵니다.

장기적 일관성을 위한 공개

공급 정책을 설명하는 자료에는 기준 날짜와 적용 범위를 남기는 것이 중요합니다. 단계가 진행되면 이전 기록을 지워 새 숫자만 보여 주기보다 무엇이 추가됐는지 연결해 설명해야 합니다. 회원은 변화의 이유와 근거를 이해할 수 있어야 하고 운영자는 동일 자산을 중복 집계하지 않아야 합니다. GCV는 큰 발행 수량 자체를 경쟁력으로 내세우기보다 공급 구조를 읽을 수 있는 투명성과 실제 사용 경험을 통해 신뢰를 쌓는 방향을 지향합니다.

목차 ↑

045 / 100 · 발행과 경제 설계

전체 공급의 목적별 배분 설계

Allocation by Purpose

배분 비율은 전체 설계 수량314,159,000,000GCV를 어떤 목적으로 사용하는지 설명합니다. 현재 지갑에 모두 배분됐다는 완료 보고와는 다릅니다.

하나의 기준으로 계산

본사·코어, 개발, 유동성, 연합회, 채굴·회원과 마케팅의 여섯 몫을 합하면100%입니다. 아래 수량은 전체 설계 수량에 각각의 비율을 곱한 값입니다. 이 표에1차 발행량을 다시 더하거나 표의 모든 수량이 이미 발행·전송됐다고 읽지 않아야 합니다. 계획상의 용도와 실제 실행 내역을 구분해야 이후 발행과 배분의 기록을 일관되게 비교할 수 있습니다.

채굴·회원 몫의 위치

채굴·회원50%는157,079,500,000GCV이며 첫 풀31,415,900,000GCV는 이 몫 안에 포함됩니다. 첫 풀을 전체 공급 밖의 추가 보상으로 계산하지 않습니다. 회원의 개별 적립은 이 비율을 모든 회원에게 똑같이 나눈 자동 배당이 아니라 확정된 참여 규칙과 실제 인정된 사건에 따라 이해해야 합니다. 풀의 정책과 개인 내역은 서로 연결되지만 같은 종류의 정보는 아닙니다.

용도 이름과 실제 책임

개발과 마케팅이라는 이름만으로 지출이 자동 승인되는 것은 아닙니다. 어떤 목적에 어떻게 사용했는지 확인할 수 있는 기록이 있어야 용도에 대한 신뢰가 생깁니다. 유동성 몫 역시 거래소 상장이나 특정 가격을 보장한다는 뜻이 아닙니다. 본사·코어와 연합회의 GCV 공급 배분은 아래 비율을 따르며 Pi 광고·수수료 수익의90대10 정책과는 별도의 구조입니다.

배분을 실행할 때의 설명

실제 배분이 진행되면 대상 네트워크, 수량과 용도, 확인 가능한 시점을 따로 제시해야 합니다. 계획표만으로 개별 지갑 지급을 완료 처리하거나 미확정 잠금 기간을 만들어 발표하지 않습니다. 회원은 어떤 부분이 설계이고 어떤 부분이 실행됐는지 비교할 수 있어야 합니다. 이후의 변경도 기존 사실을 보존하면서 근거와 적용 범위를 설명하는 것이 바람직합니다.

목적	비율	설계 수량 GCV
본사·코어	20%	62,831,800,000
개발자	5%	15,707,950,000
유동성	15%	47,123,850,000
연합회	5%	15,707,950,000
채굴·회원	50%	157,079,500,000
마케팅	5%	15,707,950,000

목차 ↑

046 / 100 · 발행과 경제 설계

후속 발행은 조건과 기록으로 설명

Conditions for Later Issuance

1차 발행 다음의 과정은 공급 설계만으로 자동 결정되지 않습니다. 각 단계의 목적, 조건과 확인된 결과를 연결하는 방식이 필요합니다.

먼저 설명해야 할 목적

후속 발행을 검토할 때에는 어떤 필요를 해결하려는지부터 명확히 해야 합니다. 전체 공급 설계에 여유가 있다는 사실만으로 즉시 발행해야 한다는 결론이 나오지는 않습니다. 실제 기능의 준비, 기록의 일치와 운영 책임을 함께 보아야 합니다. GCV는 단계의 이름을 늘리는 것보다 각 단계가 어떤 상태를 만들었는지 설명하는 방향을 지향합니다. 이 백서는 확정된1차 수량을 유지하면서 이후 발행의 날짜나 수량을 임의로 새로 정하지 않습니다.

실행 전에 확인할 범위

새 단계에는 대상 네트워크와 자산 식별, 수량과 권한을 정확히 확인하는 과정이 필요합니다. 테스트에서 성공한 요청을 다른 네트워크에서 자동 반복하는 방식으로 이해해서는 안 됩니다. 실행을 담당하는 사람과 검토하는 자료가 분명해야 하며, 실제 서명과 키 사용은 별도의 통제 아래 이루어져야 합니다. 백서에 계획을 적거나 앱에 상태를 표시한 일은 그런 실행을 대신하지 않습니다. 문서, 사용자 선택과 체인 사건의 역할을 구분하는 것이 중요합니다.

후속 수량을 계산할 때

설계 수량, 지금까지 확인된 발행과 새로운 단계의 수량을 같은 단위와 네트워크 맥락으로 대조해야 합니다. 서로 다른 시험 자산이나 내부 장부 수량을 모두 합쳐 하나의 발행 총량처럼 보여 주면 의미가 왜곡됩니다. 이미 확인된 거래가 반복 조회됐다는 이유로 다시 더하지 않아야 합니다. 각 단계가 기존 공급 구조 안에서 어떤 위치에 있는지 설명하면 회원은 새로운 숫자를 이전 기록과 연결해서 읽을 수 있습니다. 단순히 큰 합계를 제시하는 것보다 중요한 원칙입니다.

보류와 중단도 상태의 일부

필요한 조건이 충족되지 않았다면 단계가 보류된 이유와 남아 있는 확인 사항을 설명하는 것이 적절합니다. 예정 날짜를 지키기 위해 기록을 생략하거나 불명확한 거래를 완료로 표시하지 않아야 합니다. 반대로 보류가 곧 모든 기존 성과의 무효를 뜻하는 것도 아닙니다. 확인된1차 발행과 진행 중인 후속 검토를 나누어 설명하면 현재 위치를 이해하기 쉽습니다. 일정은 새로운 근거에 따라 갱신하되 이전 안내가 어떤 조건에 기반했는지도 남기는 것이 바람직합니다.

실행 뒤의 확인과 공지

실행 이후에는 실제 거래 결과와 계획이 일치하는지 확인하고 관련 문서와 화면을 같은 사실로 맞추어야 합니다. 예상한 수량과 다른 결과가 나왔을 때에는 차이를 숨기지 말고 원인을 확인해야 합니다. 다음 단계의 성과는 발행량만이 아니라 확인 가능한 기록, 일관된 상태와 이용자의 이해까지 포함합니다. GCV의 장기 비전은 이런 단계를 성급히 건너뛰는 데 있지 않습니다. 작은 단계마다 설명 가능한 근거를 쌓아 더 넓은 이용으로 연결하는 데 있습니다.

목차 ↑

047 / 100 · 발행과 경제 설계

이름만으로 자산을 식별하지 않기

Recognizing the Correct Asset

GCV라는 이름과 로고는 브랜드를 알리지만, 체인에서 자산을 구분하려면 네트워크와 발행 주체 등 실제 식별 정보를 함께 확인해야 합니다.

표시 이름의 한계

비슷한 이름이나 같은 약어를 사용하는 자산이 존재할 수 있습니다. 화면에GCV라고 적혀 있다는 이유만으로 공식 기록과 같은 자산이라고 단정하지 않습니다. 공식 안내에서 제시하는 네트워크와 자산 식별 정보를 함께 확인하는 습관이 필요합니다. 로고와 설명문은 이해를 돕지만 자산의 출처를 증명하는 서명을 대신하지 않습니다. GCV는 브랜드의 일관성을 유지하면서도 회원이 실제로 어떤 환경의 자산을 보고 있는지 알 수 있는 안내를 지향합니다.

네트워크가 바뀌면 의미도 확인

Testnet에서 확인한 자산과 Mainnet에서 사용하는 자산은 같은 화면 이름을 쓰더라도 구분해야 합니다. 시험 환경에서 성공한 기록이 실제 운영 환경의 동일한 상태를 자동으로 증명하지는 않습니다. 이용자가 지갑이나 탐색기를 볼 때에는 어떤 네트워크를 선택했는지부터 확인해야 합니다. 앱이 연결 환경을 명확히 보여 주면 잘못된 기대와 실수를 줄일 수 있습니다. 이번 백서의 발행 근거는 Pi Testnet임을 밝히며 다른 환경의 완료 사실로 확대하지 않습니다.

공개 설명과 외부 승인

자산 설명, 홈페이지 링크와 로고 같은 공개 정보가 표시되는 것과 특정 플랫폼의 공식 승인이나 거래소 상장은 별개의 사건입니다. 메타데이터가 정상적으로 보인다는 사실만으로 거래가 가능하거나 검증을 모두 통과했다고 소개하지 않습니다. 외부 서비스의 표시 상태는 해당 시점과 범위를 함께 읽어야 합니다. 회원은 아름다운 소개 화면보다 어떤 기능이 실제로 가능한지 확인할 수 있어야 합니다. GCV는 설명 정보의 정확성과 운영 상태의 정확성을 함께 관리하는 방향을 지향합니다.

안내 경로를 확인하는 습관

새로운 거래나 기능을 소개하는 메시지를 받았을 때에는 공식 홈페이지와 앱의 공지에서 같은 내용을 확인하는 편이 좋습니다. 급하게 비밀문구를 입력하거나 모르는 상대에게 자산을 보내야만 보상을 받을 수 있다는 요구를 백서의 정상 흐름으로 받아들이지 않아야 합니다. 운영 문의에도 비밀키를 전달할 필요는 없습니다. 사용자에게는 복잡한 기술 설명보다 어느 안내가 공식인지와 어떤 정보가 필요한지 명확하게 알려 주는 것이 실제 판단에 도움이 됩니다.

잘못된 표시를 발견했을 때

공식 안내와 다른 이름, 네트워크나 수량이 보이면 먼저 그 화면의 시점과 대상을 확인해야 합니다. 서로 다른 환경의 자료를 비교하고 있는 경우도 있기 때문입니다. 문의에는 공개된 식별 정보와 문제의 범위를 전달하되 비밀정보를 포함하지 않습니다. 운영자는 잘못된 표시를 수정할 때 실제 자산의 기록까지 변경된 것처럼 설명하지 않아야 합니다. 표시의 정정과 체인 사건의 변경을 나누어 알리면 회원은 무엇이 바로잡혔는지 정확히 이해할 수 있습니다.

목차 ↑

048 / 100 · 발행과 경제 설계

내부 적립 장부와 체인 기록의 연결

Accrual Ledger and Blockchain Records

앱의 활동 장부와 블록체인의 자산 기록은 서로 다른 역할을 합니다. 정확한 연결은 두 기록을 하나로 뭉개는 대신 각 단계의 의미를 보존하는 데서 시작합니다.

활동 장부가 설명하는 내용

활동 장부는 회원이 어떤 조건에서 참여했는지와 그 결과로 어떤 적립이 인정됐는지를 기록합니다. 채굴 구간의 적용률, 활동의 일일 한도와 중복 여부처럼 서비스 정책에 필요한 정보가 포함될 수 있습니다. 이 장부의 수량은 그 기록 체계의 상태로 읽어야 합니다. 서버에 숫자가 저장됐다고 외부 지갑에 동일 수량이 이미 들어갔다고 가정하지 않습니다. 회원에게는 활동 결과와 보유 자산을 이해할 수 있는 이름과 상태를 제공하는 것이 중요합니다.

체인 기록이 설명하는 내용

체인의 거래 기록은 해당 네트워크에서 어떤 자산 이동이나 발행이 확인됐는지 보여 줍니다. 그러나 그 해시만으로 앱 내부의 모든 활동 조건과 보상 자격을 알 수 있는 것은 아닙니다. 한 번의 발행 기록은 발행 사건의 증거이며 모든 회원의 채굴 시간이 검증됐다는 증거가 아닙니다. 두 기록은 확인하는 질문이 다르므로 서로의 공백을 상상으로 채우지 않아야 합니다. 어느 사건에 어느 근거가 연결되는지를 명확히 하면 전체 흐름의 신뢰를 높일 수 있습니다.

하나의 지급을 한 번만 반영

내부 적립을 외부 자산 이동과 연결하는 단계에서는 같은 원천을 두 번 사용하는 일을 막아야 합니다. 요청이 재전송되거나 결과 확인이 늦어져도 원래 요청과 최종 결과를 연결할 수 있어야 합니다. 성공 여부가 불명확한 동안 새 지급을 반복하면 중복과 누락의 위험이 함께 커집니다. 여기서 중요한 원칙은 재시도의 수가 아니라 한 사건의 상태를 일관되게 관리하는 것입니다. 이 백서는 구체 지급 기능의 활성화를 선언하지 않고 연결에 필요한 설명 원칙을 제시합니다.

합계를 맞추는 확인

운영에서 필요한 대조는 단순히 두 화면의 큰 숫자가 같은지 보는 데 그치지 않습니다. 처리 중, 확정, 취소나 정정의 범위를 구분하여 같은 시점과 단위를 비교해야 합니다. 내부 장부의 합계를 체인 발행량과 무조건 동일하게 만들기 위해 기존 기록을 지우거나 미확인 수량을 추가하는 방식은 적절하지 않습니다. 차이가 있다면 어떤 단계의 차이인지 설명해야 합니다. 이러한 대조는 이용자 신뢰를 위해 필요한 운영 목표이며, 완료 여부는 실제 증거로 보고해야 합니다.

회원에게 보이는 통합 경험

기술적으로 기록이 나뉘어 있어도 회원은 자신의 참여가 어디까지 진행됐는지 쉽게 알 수 있어야 합니다. 활동 인정, 적립 확정과 지갑 이동의 상태를 연결하여 표시하는 것이 그 방향입니다. 각 단계의 처리 시점과 필요한 행동을 분명히 하면 불필요한 기다림과 반복 요청을 줄일 수 있습니다. GCV는 복잡한 내부 구조를 그대로 노출하기보다 이용자의 질문에 답하는 상태를 제공하고자 합니다. 정확한 구분이 있어야 편리한 통합도 신뢰할 수 있습니다.

목차 ↑

049 / 100 · 발행과 경제 설계

Testnet에서 확인한 성과와 다음 질문

What Testnet Evidence Establishes

Testnet은 확인 가능한 개발 단계를 만드는 환경입니다. 확인된1차 발행의 성과를 정확히 인정하면서 다음 운영 단계의 질문도 별도로 남겨야 합니다.

실제로 확인된 성과

GCV에는2026년10월5일 Pi Testnet의1차 발행 기록이 있습니다. 수량31,415,900,000GCV, 시점과 거래 식별값을 공개 기록으로 확인할 수 있다는 사실은 구체적인 개발 성과입니다. 과거 문서의 미발행 설명을 그대로 반복하면 현재 위치를 제대로 전달하지 못합니다. 백서는 이 사건을 날짜와 네트워크를 포함해 소개합니다. 성과를 과소평가하거나 부풀리는 대신 무엇이 실행됐는지 정확히 말하는 것이 다음 단계에 대한 건전한 기대를 만듭니다.

시험 환경에서 얻는 학습

시험 환경은 자산 식별과 거래 확인, 오류 처리와 안내를 점검하는 데 활용할 수 있습니다. 성공한 경우만 보는 것이 아니라 연결 지연, 중복 요청과 거부된 결과도 다룰 수 있어야 합니다. 같은 화면이 보인다는 이유만으로 모든 환경이 같은 조건에서 동작한다고 가정하지 않습니다. GCV는 시험 결과를 조건과 함께 기록하여 무엇을 재현할 수 있는지 설명하는 방향을 지향합니다. 이는 개발과 운영 사이의 차이를 발견하고 실제 이용 경험을 개선하는 기반입니다.

확인되지 않은 범위를 남기기

Testnet 발행은 Mainnet 발행이나 거래소 상장, 판매 상품의 결제 완료를 의미하지 않습니다. 개인 회원의 지급 내역도 별도로 확인해야 합니다. 이 구분은 성과를 부정하기 위한 문장이 아니라 다음에 필요한 근거를 구체화하는 방법입니다. 예를 들어 상품 결제는 주문과 결제의 연결, 회원 지급은 대상과 수량의 일치를 확인해야 합니다. 서로 다른 질문을 한 번의 시험 성공으로 모두 해결했다고 선언하면 실제 운영에서 무엇이 남았는지 알기 어려워집니다.

테스트용 흐름의 대상

기존의 소유자 전용0.01Test-Pi 단일 상품 경로는 제한된 검증 흐름이며 일반 회원에게 판매하는 실제 상품 카탈로그가 아닙니다. 이번 쇼핑 안내의 실제 상품 상태는 상품 등록 준비 중입니다. 시험용 가격과 흐름을 일반 판매 화면에 그대로 가져와 정상 운영 중인 것처럼 소개하지 않습니다. 테스트 대상을 분명히 하면 사용자는 자신이 실제 구매를 하는지 검증 화면을 보는지 이해할 수 있습니다. 정확한 대상 안내는 결제 경험에서 특히 중요한 기본입니다.

단계를 넘을 때의 기준

더 넓은 이용으로 전환하려면 현재의 증거뿐 아니라 새로운 범위에서 필요한 검증을 확인해야 합니다. 자산과 주문, 사용자 선택과 서버 결과가 일치하는지 보아야 하며, 운영 지원도 준비되어야 합니다. 정해지지 않은 출시 날짜를 먼저 약속하기보다 남은 질문을 구체적으로 해결하는 방식이 바람직합니다. GCV는 테스트를 반복했다는 횟수보다 실제로 무엇을 확인했고 어떤 문제가 남았는지 설명하는 성숙한 개발 문화를 세계적 성장의 기반으로 삼고자 합니다.

목차 ↑

050 / 100 · 발행과 경제 설계

자산을 다루는 이용자의 선택과 확인

User Control over Asset Actions

GCV가 지향하는 편의성은 이용자의 선택을 생략하는 편의성이 아닙니다. 자산과 결제에 관한 행동은 대상과 금액을 이해하고 확인할 수 있어야 합니다.

연결과 실행은 별도 행동

계정을 연결하거나 앱에 로그인한 사실만으로 모든 자산 이동을 미리 허용한 것으로 보지 않습니다. 상품을 둘러보는 행동, 주문을 준비하는 행동과 결제를 승인하는 행동도 서로 다릅니다. 이용자는 중요한 실행 전에 무엇을 어디로 보내는지 이해할 수 있어야 합니다. GCV는 Pi Browser에서 Pi 결제를 진행하는 방향을 사용하며 실제 승인은 이용자의 선택으로 이루어져야 합니다. 단순한 화면 이동이나 백서 열람이 결제 실행으로 이어져서는 안 됩니다.

확인할 정보의 우선순위

자산 관련 행동에는 네트워크와 자산, 금액과 대상이 중요합니다. 상품 결제라면 주문 내용과 서버가 확인한 가격, 재고와 견적 상태도 함께 읽어야 합니다. 화면에 보이는 숫자를 사용자가 임의로 바꾼 결과를 서버의 정상 가격으로 받아들여서는 안 됩니다. 현재 실제 상품은 등록 준비 중이므로 아직 없는 가격과 재고를 미리 제시하지 않습니다. 준비가 이루어진 뒤에도 사용자가 이해할 수 있는 주문 정보와 승인 화면이 일치하는 경험이 필요합니다.

비밀정보를 요구하지 않는 도움

일반적인 문의나 결과 확인을 위해 지갑의 비밀문구와 개인키를 운영자에게 전달할 필요는 없습니다. 공개 거래 식별값과 주문 상태처럼 문제를 설명하는 정보와 자산 통제에 쓰는 비밀정보는 다릅니다. 회원은 도움을 받는 과정에서도 자신의 통제권을 유지해야 합니다. 앱과 안내는 정상적인 지원 절차에 필요한 정보를 명확히 설명하는 방향으로 발전해야 합니다. 복잡한 문제일수록 사용자에게 비밀을 대신 보관해 주겠다는 방식보다 기록의 범위를 정확히 확인하는 방식이 중요합니다.

취소와 미확정 상태의 이해

사용자가 승인을 취소한 경우와 승인 후 결과를 확인하는 중인 경우는 서로 다른 상태입니다. 둘을 같은 실패 메시지로 처리하면 불필요한 재시도를 유도할 수 있습니다. 결제 화면의 응답만으로 배송이나 환불까지 완료됐다고 표시하지 않고 서버가 확인한 주문·결제 상태를 연결해야 합니다. 결과가 불명확한 경우에는 원래 사건을 다시 확인할 수 있어야 합니다. 이러한 구분은 이용자의 선택을 존중하면서 중복된 자산 행동을 줄이는 데 도움이 됩니다.

쉬운 경험과 명확한 책임

확인 단계가 많다고 반드시 안전하거나 이해하기 쉬운 것은 아닙니다. 회원에게 필요한 핵심 정보는 간결하게 보여 주되 중요한 선택을 숨기지 않아야 합니다. 복잡한 내부 설명 대신 현재 상태, 실행할 내용과 완료 후 확인 경로를 연결하는 편이 좋습니다. GCV의 목표는 누구나 자신의 행동을 이해하고 결과를 확인할 수 있는 경험입니다. 이 원칙은 초기 상품 등록부터 향후 기능 확장까지 이어져야 하며, 준비가 확인된 범위에서만 실제 이용을 안내해야 합니다.

목차 ↑

051 / 100 · 발행과 경제 설계

Pi 수익90대10과 GCV 보상의 분리

Pi Revenue and GCV Rewards

광고·수수료의 Pi 수익은 본사·코어90%, 연합회10%라는 별도 정책을 사용합니다. GCV 공급 배분과 활동 보상에 이 비율을 대신 적용하지 않습니다.

수익의 단위부터 구분

사업 수익을 설명할 때에는 어떤 자산이 어떤 사건으로 발생했는지 먼저 확인해야 합니다. Pi 광고·수수료 수익은Pi 단위의 정산 문제이며, 회원의 채굴과 활동 보상은GCV 단위의 정책입니다. 한 회원에게6.28GCV가 적립됐다는 사실만으로 본사에 일정Pi 수익이 발생했다고 역산할 수 없습니다. 두 숫자 사이의 고정 환율도 이 정책에 포함되지 않습니다. 자산과 발생 원인을 나누어 기록해야 매출과 보상을 각각 정확히 이해할 수 있습니다.

90대10의 계산 예시

배분 대상이 되는 확인된Pi 수익을1,000Pi라고 가정하면 본사·코어 몫은900Pi, 연합회 몫은100Pi입니다. 이 예시는 비율을 설명하기 위한 가상의 산술 사례이며 실제 매출 보고가 아닙니다. 연합회 몫10%는 해당 수익 기준의10%이지 본사90%에서 다시10%를 떼어 계산한90Pi가 아닙니다. 같은 기준을 사용해야 합계가 원래 배분 대상과 일치합니다. 실제 정산에서는 어떤 금액이 배분 대상인지와 적용 시점을 함께 확인해야 합니다.

매출과 순이익의 차이

본사·코어에90%가 배분된다는 설명을 개인에게 남는 순이익90%로 읽어서는 안 됩니다. 서비스 운영에는 비용과 환불, 다른 정산 항목이 발생할 수 있으며 실제 순이익은 확인된 회계 정보가 있어야 설명할 수 있습니다. 연합회10% 역시 세율을 뜻하지 않습니다. 백서는 확정되지 않은 세금이나 비용 공제 순서를 만들어 넣지 않습니다. 사업 구조의 비율과 실제 손익을 구분하면 초기의 목표를 과장된 수익 약속으로 전달하는 일을 줄일 수 있습니다.

공급 배분표와의 비교

GCV 전체 공급에서 연합회에 배정된 비율은5%이며, Pi 수익에서 연합회가 받는 비율은10%입니다. 두 비율이 다른 것은 계산 대상과 목적이 다르기 때문입니다. 공급 배분표는314,159,000,000GCV의 설계를 나누고, 수익 정책은 발생한Pi 수익의 배분을 설명합니다. 어떤 숫자가 맞는지 하나를 고르는 문제가 아니라 각각의 분모를 확인해야 하는 문제입니다. 앱과 공지에서 자산명과 기준을 생략하지 않는 것이 이런 혼동을 줄이는 실질적인 방법입니다.

사업의 지속성을 보는 관점

광고 수익이 증가한다는 기대만으로 운영이 안정된다고 단정할 수는 없습니다. 실제 수익의 발생과 입금, 비용과 지원 품질을 함께 보아야 합니다. GCV는 사업 수익이 서비스의 품질과 지속성으로 연결되는 구조를 지향합니다. 광고 승인과 매출을 아직 확인하지 못한 단계에서는 목표로 설명하고, 실제 결과가 생기면 같은 기준의 기록으로 보고해야 합니다. 회원 보상과 운영 수익을 구분하는 것은 생태계의 각 참여자가 무엇을 기대할 수 있는지 명확히 하는 출발점입니다.

목차 ↑

052 / 100 · 발행과 경제 설계

경제의 가치는 실제 사용과 신뢰에서

Value through Use and Trust

GCV의 경제적 비전은 큰 수량을 발행하는 데서 끝나지 않습니다. 사람들이 이해하고 참여하며 실제로 사용할 수 있는 생태계를 지속하는 것이 장기 목표입니다.

수량이 가격을 정하지 않는다

전체 공급 수량과 배분 비율은 설계의 중요한 정보이지만 그것만으로 토큰의 시장가격을 계산할 수는 없습니다. 채굴률이나 활동 보상을 특정 법정화폐 수익으로 곧바로 바꾸어 약속하는 것도 적절하지 않습니다. 실제 사용 가능성, 접근성과 신뢰는 각기 다른 조건에 영향을 받습니다. GCV는 이 백서에서 임의의 목표 가격이나 확정 수익률을 제시하지 않습니다. 세계 최고를 지향한다는 포부는 품질과 사용 경험의 목표로 설명하며 가격 상승 보증으로 사용하지 않습니다.

활동과 실제 이용의 연결

회원이 활동의 결과를 이해하고 앱을 다시 이용할 이유를 느끼는지가 중요합니다. 채굴과 게임, 운동과 QR은 참여 경험을 만들고 공지와 백서는 그 규칙을 설명합니다. 쇼핑은 실제 상품과 주문, Pi 결제의 확인이 준비되어야 사용 가치로 이어집니다. 현재 상품 등록 준비 중이라는 상태를 정확히 알리는 것은 이 연결의 시작입니다. 아직 없는 상품을 채워 넣어 완성된 경제처럼 보이게 하는 것보다 실제 등록과 운영 책임을 하나씩 준비하는 것이 지속 가능한 성장에 가깝습니다.

측정할 수 있는 발전 목표

경제의 발전을 평가할 때에는 단순 가입 수만 보지 않고 이용자가 기능을 이해하는지, 결과를 확인하는 데 어려움이 없는지와 실제 지원이 가능한지도 살펴야 합니다. 주문이 준비된 이후에는 주문과 결제의 일치, 상태 안내와 문제 해결 경험을 측정할 수 있습니다. 이러한 항목은 발전을 위한 제안이며 이미 달성한 성과 수치가 아닙니다.1차 회원300만명이라는 사업 목표도 같은 관점에서 다룹니다. 회원 목표와 현재 이용자 수, 검증된 처리 능력을 구분해야 합니다.

성장 과정의 균형

빠른 참여 확대와 운영 품질 사이에는 지속적으로 점검할 균형이 있습니다. 홍보가 늘어도 안내와 지원이 뒤따르지 않으면 처음의 기대가 실망으로 바뀔 수 있습니다. 새로운 보상을 추가하는 일도 공급 구조와 실제 기록을 함께 검토해야 합니다. GCV는 명확한 정책, 확인 가능한 사건과 사용자의 선택을 중심으로 확장을 판단하는 방향을 지향합니다. 각 단계에서 실제로 준비된 범위를 알리고 부족한 부분을 개선하는 과정이 장기적인 신뢰와 연결됩니다.

글로벌 비전의 경제적 의미

세계적인 생태계를 만든다는 것은 많은 국가 이름을 홍보 문구에 넣는 일이 아닙니다. 서로 다른 언어와 환경에서도 같은 규칙을 이해하고 자신의 참여 결과를 확인할 수 있게 하는 일입니다. GCV의 포부는 일상의 참여와 투명한 기록, 실제 사용 경험을 연결하여 오래 신뢰받는 디지털 생태계로 성장하는 것입니다. 다음 쇼핑 장에서는 이 비전을 상품 등록과 주문, Pi 결제라는 구체적인 이용 흐름으로 옮겨 설명합니다. 경제 설계의 가치는 결국 그런 실제 경험 속에서 평가되어야 합니다.

목차 ↑

053 / 100 · 쇼핑과 Pi 결제

상품이 등록되기 전의 쇼핑

Commerce Before Launch

GCV 쇼핑의 현재 상태는 상품 등록 준비 중이다. 이 상태를 분명히 보여 주는 것은 미완성 화면을 감추기 위한 설명이 아니라, 회원이 지금 할 수 있는 일과 앞으로 열릴 거래를 구분하는 출발점이다.

첫 화면이 답해야 하는 질문

회원이 쇼핑 메뉴를 열면 구매 가능한 상품이 있는지, 어느 자산으로 결제하는지, 어디서 주문을 확인하는지를 먼저 알 수 있어야 한다. 아직 등록되지 않은 상품을 품절 상품처럼 나열하면 실제 판매 이력이 있는 것으로 오해할 수 있다. 따라서 준비 화면에는 등록 상태와 Pi Browser 이용 경로, 기존 주문 확인 방법을 배치한다. 등록 예정이라는 문구만으로 상품 이름이나 가격을 추정해 채우지 않는다.

앱과 홈페이지의 역할

홈페이지는 쇼핑의 운영 원칙과 상품 등록 진행 상황을 설명하는 공개 창구다. 앱은 Pi Browser의 본인 계정과 연결되는 결제·주문 확인 흐름의 진입점이다. 공개 설명을 읽기 위해 로그인이나 지갑 연결을 요구할 이유는 없다. 반대로 회원의 주문 내역은 공개 문서의 일부가 아니므로 같은 화면에 섞지 않는다. 두 화면 사이를 이동해도 구매가 자동으로 시작되지 않는 연결이 기본이다.

준비 단계에서도 필요한 완성도

상품이 없어도 버튼과 안내는 정확해야 한다. 빈 목록은 통신 실패와 구분하고, 결제 화면을 열었다는 이유로 완료 메시지를 보여 주지 않는다. 안내 링크가 새 창으로 열리는지 현재 화면을 바꾸는지도 설명한다. 회원이 이전 주문을 확인하러 방문한 경우에는 새 상품 등록 여부와 무관하게 기존 요청을 찾을 수 있어야 한다. 준비 상태와 복구 기능의 가용성은 서로 다른 조건이다.

일반 판매로 넘어가는 조건

향후 판매 개시는 상품 설명 작성만으로 결정하지 않는다. 서버에 등록된 상품·옵션·가격·재고와 실제 제공 책임, 취소·문의 경로를 함께 확인해야 한다. 승인 계정의 기존 Testnet 확인 경로가 작동하더라도 일반 상품의 판매 준비가 끝난 것은 아니다. 상품 등록 준비가 끝나면 공지에 대상 상품과 지원 범위를 제시하고, 회원이 구매 전에 그 내용을 다시 확인하는 순서를 따른다. 회원이 준비 화면에서 나갔다가 돌아와도 임의의 상품 선택이나 결제 요청이 이어지지 않아야 하며, 진행 중인 원래 주문이 있는 경우에만 그 요청의 확인 경로를 제시한다.

목차 ↑

054 / 100 · 쇼핑과 Pi 결제

상품 정보는 하나의 원본에서

A Single Product Record

상품 소개와 결제 화면에 서로 다른 가격이나 옵션이 보이면 회원은 어느 정보를 믿어야 할지 알 수 없다. 향후 카탈로그의 중심은 화면에 적힌 숫자가 아니라 서버가 관리하는 상품 원본이어야 한다.

설명과 거래 데이터의 분리

상품 설명은 무엇을 제공하는지 이해시키는 콘텐츠다. 상품 식별자, 선택 가능한 옵션, Pi 가격, 판매 상태는 거래를 판정하는 데이터다. 번역이나 디자인 수정으로 상품의 의미를 쉽게 설명할 수는 있지만 거래 식별자를 바꾸어서는 안 된다. 예를 들어 한국어 상품명과 영어 상품명이 달라도 동일한 상품을 가리키는 원본 식별자는 같아야 한다. 화면 제목을 주문 식별자로 사용하는 설계는 피한다.

등록 항목의 검토

상품 등록 시에는 이름, 실제 제공 내용, 옵션별 차이, 제공 방식, 문의 방법을 검토한다. 사진은 설명하는 대상을 정확히 나타내야 하며 아직 확보하지 않은 사진이나 제휴사의 상표를 임의로 채워 넣지 않는다. 상품을 구성하는 데이터가 비어 있으면 해당 항목을 준비 중으로 남긴다. 정확한 정보가 없는 상태에서 그럴듯한 카탈로그를 만드는 것보다 등록 준비의 이유를 알리는 편이 거래 신뢰에 도움이 된다.

변경 이력과 적용 범위

설명 문구를 고친 경우와 가격 또는 옵션을 바꾼 경우는 별도로 추적할 필요가 있다. 이미 생성된 주문은 그 주문을 만들 때 확인한 정보를 참조해야 하기 때문이다. 새로운 상품 안내가 게시됐다고 과거 주문의 내용을 조용히 바꾸면 분쟁을 해석하기 어렵다. 향후 운영에서는 상품 원본의 개정 시점과 주문에 고정된 내용을 함께 조회할 수 있도록 설계하고, 구매자는 결제 직전의 확인 정보를 다시 읽는다.

빈 카탈로그의 의미

현재 등록 준비 상태에서는 상품 수가 없는 것을 정상적인 결과로 취급한다. 조회 중, 조회 실패, 등록 준비, 판매 중, 일시 중단의 상태를 다른 문구로 구분하는 것이 바람직하다. 빈 목록이 나왔을 때 과거 샘플 가격을 대체 표시하거나 임의의 재고를 생성하지 않는다. 과거 정적 쇼핑 데모의 원화 표시도 실제 Pi 상품 원본으로 전환하지 않으며, 새 원본이 승인됐을 때에만 거래 화면에 연결한다. 상품 원본의 상태를 공개 목록과 결제 직전 화면에서 같은 기준으로 사용하면, 소개는 남아 있는데 구매는 중단된 상황에서도 이유를 일관되게 설명할 수 있다.

목차 ↑

055 / 100 · 쇼핑과 Pi 결제

상품 등록 준비의 검토 순서

Product Registration Gates

등록 준비는 상품을 많이 늘리는 작업보다 구매자가 받을 내용과 운영자가 책임질 내용을 맞추는 작업에 가깝다. 첫 상품의 정확한 설명과 사후 처리 기준이 다음 상품을 등록할 때 재사용할 수 있는 기준이 된다.

무엇을 제공하는가

가장 먼저 상품의 범위를 한 문장으로 설명한다. 물리적 물품인지, 디지털 자료인지, 특정 기간의 서비스인지에 따라 전달 방식과 확인할 정보가 달라진다. 제공 항목과 제외 항목이 섞여 있으면 구매자가 기대하는 결과와 운영자가 준비한 결과가 어긋난다. 아직 상품 종류가 확정되지 않은 현재 단계에서는 특정 상품이나 공급자를 전제로 문구를 작성하지 않고, 등록할 때 확인할 질문을 준비한다.

누가 이행을 책임지는가

상품마다 설명을 작성하는 사람, 재고를 확인하는 사람, 주문 문의를 처리하는 사람이 같을 수도 있고 다를 수도 있다. 향후 역할이 나뉘면 각각 무엇을 결정할 수 있는지 기록해야 한다. 화면을 게시한 사람이 실제 제공 여부까지 확인한 것으로 간주해서는 안 된다. 결제 수단이 Pi라는 사실도 판매자의 이행 책임을 대신하지 않는다. 문의가 들어오면 어떤 주문과 어떤 제공 약속을 검토해야 하는지 찾을 수 있어야 한다.

검토와 공개의 구분

등록 초안은 공개 판매와 다른 상태다. 설명과 이미지가 준비됐어도 가격이나 제공 방식이 확인되지 않았다면 검토를 이어간다. 검토용 데이터가 공개 카탈로그에 섞이지 않도록 상태를 명확히 나누는 설계를 제안한다. 공개 전에 구매자 관점으로 내용을 읽고 빠진 조건을 확인하며, 오류 발견 시 이전 초안을 삭제하는 대신 변경 이유를 남겨 이후의 판단 근거로 활용한다.

첫 등록의 검증 사례

가상의 등록 검토를 예로 들면 설명은 충분하지만 제공 시점이 빠진 상품은 게시를 보류할 수 있다. 다른 예로 옵션 이름이 비슷해 선택을 구분하기 어려우면 구매 화면의 표현을 먼저 고친다. 이 사례들은 실제 판매 상품이 있다는 뜻이 아니라 검토 기준을 설명하기 위한 상황이다. 준비 완료의 판단은 항목 수가 아니라 구매자가 선택한 내용과 운영자가 이행할 내용을 서로 같은 말로 설명할 수 있는지에 둔다. 검토 담당자는 빠진 정보를 빈칸으로 남겨 다음 질문을 분명히 하고, 아직 답이 없는 항목을 일반적인 업계 관행으로 대신 채워 확정된 조건처럼 게시하지 않는다.

목차 ↑

056 / 100 · 쇼핑과 Pi 결제

옵션과 재고를 다루는 방법

Options and Inventory

선택 가능한 옵션과 실제 제공 가능한 수량은 별개의 정보다. 같은 상품 아래에 여러 옵션이 있더라도 구매자가 선택한 옵션의 재고를 기준으로 주문 가능 여부를 확인해야 한다.

선택의 모호함 줄이기

옵션을 제공할 경우 각 선택지가 어떤 차이를 만드는지 바로 알 수 있어야 한다. 색상이나 크기처럼 일반적인 예시도 실제 상품이 등록된 이후에만 표시한다. 기본 옵션을 미리 선택할지 여부는 구매자가 잘못 결제할 가능성과 함께 검토한다. 선택하지 않은 옵션을 서버가 임의로 바꾸거나, 품절된 옵션을 비슷한 다른 옵션으로 대체하여 주문을 생성하는 방식은 사용자의 확인과 맞지 않는다.

동시 주문의 처리

두 회원이 거의 동시에 같은 마지막 수량을 선택할 수 있다. 화면에 보였던 재고는 조회 시점의 정보이므로 결제 직전 또는 주문 확정 과정에서 다시 확인할 필요가 있다. 향후 재고 예약을 도입한다면 예약 시점과 해제 조건, 실패 후 회복 절차를 함께 설계해야 한다. 화면에서 수량을 줄이는 것만으로 서버 재고가 안전하게 관리됐다고 볼 수 없으며, 중복 요청에 같은 예약을 반환하는 기준도 필요하다.

표시 수량과 내부 기록

구매 화면의 수량 선택은 거래의 일부이며 입력 범위를 검증해야 한다. 빈 값, 음수, 소수점, 지나치게 큰 수량을 그대로 계산에 사용하지 않는다. 재고를 다른 단위로 관리하는 상품이 있다면 판매 단위와 재고 단위의 관계를 먼저 확정한다. 현재는 일반 판매 상품이 등록되지 않았으므로 특정 구매 상한이나 운영 재고를 백서에서 만들어 약속하지 않는다. 상한은 상품 정책과 서버의 승인된 계약에 따라 결정한다.

재고 부족을 알리는 경험

회원이 상품을 선택한 뒤 재고가 부족해졌다면 이전 선택을 알아볼 수 있는 상태에서 이유를 알려야 한다. 이때 가격이나 옵션을 바꾼 새 주문을 자동으로 시작하지 않는다. 이미 결제 결과가 불명확한 주문이라면 재고 문제와 결제 복구 문제를 섞지 않고 기존 주문의 상태부터 확인한다. 상품 등록 단계에서는 이런 경쟁 상황을 합성 환경에서 재현하여 안내와 서버 결과가 서로 모순되지 않는지 검토한다. 재고와 옵션의 경계 사례는 정상 수량뿐 아니라 판매 중단 직후와 수량 변경 직후를 포함하며, 주문에 남은 선택이 원래의 확인 내용과 같은지 비교한다.

목차 ↑

057 / 100 · 쇼핑과 Pi 결제

결제 전 견적을 확인하는 순간

Review Before Approval

결제의 핵심은 버튼의 색상이 아니라 회원이 승인하는 내용의 명확성이다. 현재의 결제 준비와 Pi 승인·결제 확정을 구분하고, 향후 일반 상품과 옵션을 연결할 때에도 회원이 선택한 내용을 다시 확인하는 경험을 유지해야 한다.

서버가 확정하는 값

가격은 브라우저의 표시값을 신뢰해 결정하지 않는다. 현재 결제 준비는 서버가 승인한 상품과 가격을 기준으로 하며, 향후 상품·옵션 확장에서도 이 원칙을 유지해야 한다. 주소에 붙은 임의 금액이나 화면에서 수정한 숫자가 실제 결제 금액이 되는 구조는 피한다. 상품 정보가 변경되었다면 확인할 내용을 다시 보여 주고, 이전 표시를 기억하고 있는 회원에게 변경 사실을 알릴 수 있어야 한다.

결제 준비와 승인의 경계

내용을 확인하는 단계와 Pi 승인·결제 확정은 구분한다. 현재 결제 준비 요청은 이후 조회할 수 있는 주문을 만들 수 있으므로 화면을 닫았다고 주문이 사라지거나 결제가 완료된 것으로 간주하지 않는다. 결과가 불명확하면 원래 주문을 확인한다. 옵션 지원, 견적 유효기간, 재고 예약은 향후 일반 상품의 계약과 함께 검토할 설계 항목이며 이 문서에서 이미 제공되는 기능이나 확정된 시간을 약속하지 않는다.

네트워크와 자산 표시

Pi 결제 안내에는 사용 네트워크와 자산을 구분해 표시한다. Testnet 확인을 실제 Mainnet 구매로 읽히게 하거나 내부 GCV 적립액을 Pi 결제 가능 잔액으로 바꾸어 표시하지 않는다. 회원은 Pi Browser에서 공식 승인 화면의 내용을 직접 확인한다. GCV 화면의 숫자와 공식 승인 화면의 숫자가 다르다면 승인을 진행하기보다 요청의 내용을 확인하는 것이 우선이다. GCV와 Pi 사이에 고정 교환비율을 가정하지 않는다.

검토 화면의 접근성

결제에 영향을 주는 정보는 작은 각주에만 넣지 않는다. 긴 상품명과 큰 수량도 화면 밖으로 잘리지 않게 구성하고, 언어가 바뀌어도 금액과 식별 정보의 뜻은 유지한다. 버튼을 연속으로 눌러도 새로운 주문이 반복 생성되지 않도록 진행 상태를 보여 준다. 확인 화면에서 뒤로 이동한 회원이 다시 들어왔을 때 이전 승인 여부를 추측하지 않고 서버의 원래 주문을 확인하는 흐름을 설계한다. 승인 버튼 주변에는 회원이 직전에 확인한 항목을 다시 볼 수 있는 경로를 두어, 화면을 오가면서 선택 내용을 기억에만 의존하지 않도록 하는 것이 좋다.

목차 ↑

058 / 100 · 쇼핑과 Pi 결제

Pi Browser에서 직접 승인하기

User Approved Pi Payments

사용자가 선택한 쇼핑 방향은 Pi Browser에서 Pi로 결제하는 경험이다. GCV는 상품과 주문 정보를 설명하고 서버 확인을 수행하며, 최종 결제 승인 행동은 회원이 공식 Pi 흐름에서 직접 수행한다.

단계를 명확히 보여 주기

결제 흐름은 내용 확인과 결제 생성, 서버 승인, 회원의 서명, 서버의 완료 확인을 구분해 설명한다. 공식 Pi 승인 단계는 회원이 직접 진행한다. 각 단계의 완료 조건은 서로 다르다. 승인 화면을 여는 데 성공했다고 결제가 완료된 것은 아니며, 회원이 화면을 닫았다고 모든 서버 처리가 취소됐다고 단정할 수도 없다. 준비된 원래 주문과 각 단계의 상태를 연결하면 기다려야 할 때와 결과를 확인해야 할 때를 구분하기 쉽다.

SDK 응답의 역할

Pi SDK의 응답은 앱이 다음 확인을 수행하는 데 필요한 신호다. 그 응답만으로 상품이 전달되거나 환불이 처리되었다고 표시하지 않는다. 서버는 원래 주문과 결제 식별 정보를 대조하여 승인된 요청인지 확인해야 한다. 브라우저와 서버가 서로 다른 시점의 상태를 보더라도 같은 주문을 기준으로 복구할 수 있어야 한다. 공식 SDK를 쓴다는 사실 자체도 GCV 일반 판매의 승인이나 실제 거래 성공을 의미하지 않는다.

Testnet 확인의 범위

기존에는 승인 계정에 한정된 0.01 Test-Pi 단일 상품 확인 경로가 있다. 이 경로는 일반 상품 카탈로그가 아니며 여러 회원에게 판매 중이라는 근거로 사용할 수 없다. 새 쇼핑 안내는 해당 제한을 숨기거나 바꾸지 않고 일반 상품 등록 준비 상태를 함께 설명한다. 실제 판매 범위를 넓히려면 상품·권한·네트워크·운영 절차를 별도로 검토해야 하며 과거의 확인 결과를 새 상품에 자동 적용하지 않는다.

직접 행동과 책임의 구분

GCV는 비밀번호나 지갑 복구 문구를 쇼핑 설명란에 요구하지 않는다. 회원이 공식 승인 내용을 읽고 직접 결정할 수 있도록 충분한 정보를 제공해야 한다. 승인 후에는 같은 주문의 상태를 조회하고 결과가 확정될 때까지 중복 결제를 유도하지 않는다. 이 백서의 개발·게시 과정에서 실제 돈을 보내거나 개인키를 사용하는 작업은 수행하지 않는다. 문서의 결제 흐름은 사용자에게 제공할 경험과 검증 기준을 설명한다. 공식 승인에서 돌아온 화면은 새 상품의 결제로 바로 이어지는 대신 방금 선택한 주문을 먼저 표시해야 회원이 같은 거래의 어느 단계에 있는지 이해하기 쉽다.

목차 ↑

059 / 100 · 쇼핑과 Pi 결제

응답이 끊겨도 원래 주문으로

Recover the Original Order

결제 화면에서 가장 어려운 순간은 명확한 실패보다 결과를 알 수 없는 상태다. 통신이 끊긴 뒤 새 주문을 만드는 대신 원래 주문을 찾을 수 있어야 중복 결제와 반복 문의를 줄일 수 있다.

불명확한 결과의 해석

요청 시간이 오래 걸리거나 화면을 새로 열었다는 이유만으로 결제 실패를 확정할 수 없다. 서버가 이미 요청을 받았지만 응답만 전달되지 않았을 수 있기 때문이다. 따라서 결과 확인 중이라는 상태는 실패와 구분한다. 같은 주문 식별자와 같은 요청의 내용을 보존하고, 회원에게 지금은 새 결제를 시작하지 말고 기존 주문을 확인하도록 안내한다. 이 원칙은 화면의 재시도 버튼 이름에도 반영되어야 한다.

조회 경로를 가까이 두기

기존 주문 확인 기능은 오류 화면 깊숙한 곳에만 두지 않는다. 쇼핑 첫 화면에서도 회원이 자신의 이전 요청을 찾을 수 있는 진입점을 제공하는 편이 좋다. 다만 개인 주문은 같은 계정으로 확인해야 하며 공개 페이지에 주문번호를 붙여 다른 사람이 조회하도록 설계하지 않는다. 주문을 찾는 과정에서 새 결제나 상품 선택을 강요하지 않고, 확인 가능한 원래 요청의 상태부터 보여 준다.

반복 요청의 의미

같은 버튼을 두 번 누르는 상황, 모바일 연결이 바뀌는 상황, 승인 화면에서 돌아오는 상황은 서로 다르지만 중복 요청이 생길 수 있다는 공통점이 있다. 서버는 같은 요청을 반복 수신했을 때 별개의 구매로 처리하지 않도록 원래 요청과 결과를 결합해야 한다. 복구를 위해 새 요청번호를 계속 만드는 방식은 문제를 키울 수 있다. 합성 검증에서는 응답이 유실된 뒤 같은 요청의 결과를 다시 확인하는 경로를 포함한다.

확정 결과 이후의 행동

원래 주문의 결제가 확인되면 다음 단계는 상품 제공 상태를 확인하는 것이다. 결제가 거절되거나 취소된 것으로 확정되면 그 결과에 맞는 안내를 제공한다. 어느 경우에도 브라우저의 임시 메시지만으로 서버 기록을 덮어쓰지 않는다. 회원이 문의할 때에는 민감한 인증 정보 대신 주문 식별 정보와 발생 시각, 화면에 표시된 고정 오류 문구로 상황을 설명하도록 안내한다. 복구 기록은 이후 원인 분석에도 쓰인다. 문의 담당자도 회원에게 같은 승인 행동을 반복하도록 요구하기 전에 원래 주문의 처리 상태와 이미 확보된 확인 자료를 검토하는 절차를 사용해야 한다.

목차 ↑

060 / 100 · 쇼핑과 Pi 결제

결제 이후의 제공과 문의

Fulfillment and Support

결제 성공은 쇼핑 경험의 끝이 아니다. 구매자가 약속된 내용을 실제로 받았는지 확인하고, 문제가 있을 때 주문과 연결된 문의를 할 수 있어야 거래의 전체 경험이 성립한다.

제공 방식에 따른 기록

물품 배송, 디지털 전달, 서비스 제공은 확인해야 하는 사건이 다르다. 실제 상품이 정해지면 제공 방식에 맞는 상태와 증거를 설계한다. 아직 상품이 등록되지 않은 단계에서 특정 배송 기간이나 다운로드 횟수를 약속하지 않는다. 중요한 것은 결제 상태와 제공 상태를 하나의 완료 표시로 합치지 않는 것이다. 결제는 확인되었지만 제공은 준비 중인 주문도 회원이 정확히 이해할 수 있어야 한다.

구매자에게 필요한 정보

주문 내역에는 선택한 내용과 주문 시점, 현재 상태, 다음에 확인할 행동이 필요하다. 제공에 필요한 개인정보가 있다면 그 목적과 입력 시점을 분명히 설명하고 필요한 범위에서만 취급하는 설계를 검토한다. 상품 안내를 읽는 사람에게 처음부터 배송지나 연락처를 모두 요구하지 않는다. 실제 제공 조건이 확정되기 전에는 임의의 반환 주소나 운영자의 개인 주소를 문서에 게시하지 않는다.

문의의 맥락 보존

주문 문의는 상품 설명, 결제 결과, 제공 진행 중 어느 문제인지 구분하면 해결이 빨라진다. 같은 주문을 여러 번 설명해야 하는 불편을 줄이려면 원래 주문과 문의 내용을 연결하되, 공개 게시판에 개인 정보를 노출하지 않아야 한다. 운영자가 회원의 설명을 수정할 때에는 원문과 처리 기록을 구분하는 편이 좋다. 공식 답변이 사실을 확인한 내용인지 추가 자료를 요청하는 내용인지도 명확히 표시한다.

운영 준비의 측정

일반 판매 전에는 문의 접수부터 담당 확인, 답변, 재확인까지 이어지는 절차를 연습할 수 있다. 이때 실제 고객이 없는 합성 사례를 사용하고 운영 실적처럼 발표하지 않는다. 단순히 응답 시간이 짧았다는 결과보다 주문을 잘못 분류하거나 다른 회원의 정보를 보여 주지 않았는지가 중요하다. 향후 판매가 시작되면 상품별 제공 지연과 문의 원인을 검토하여 설명과 운영 방식을 함께 개선한다. 제공 지연이 발생하면 상품 전체의 일반 안내만 보여 주기보다 해당 주문에서 확인된 상태와 다음 확인 경로를 제시하여 회원이 자신의 상황을 이해하도록 돕는다.

목차 ↑

061 / 100 · 쇼핑과 Pi 결제

취소와 환불을 설명하는 방식

Cancellation and Refunds

취소와 환불 안내는 구매 후에만 등장하는 문서가 아니라 구매 전에 판단하는 자료다. 실제 상품과 운영 조건이 확정되면 어떤 단계에서 무엇을 요청할 수 있는지 구체적으로 설명해야 한다.

취소 요청과 환불 결과

회원이 취소를 요청했다는 사건과 실제 금액이 반환됐다는 결과는 구분한다. 주문이 결제 전인지, 결제 확인 중인지, 제공이 시작되었는지에 따라 검토할 내용이 달라진다. 화면에서는 요청 접수와 처리 중, 확정 결과를 구분하고 확인할 수 없는 상태를 성공으로 표시하지 않는다. 아직 일반 판매 조건이 없는 현재 단계에서는 환불 기한이나 비용을 임의로 정해 게시하지 않는다.

원래 주문을 기준으로 검토

상품 설명이 개정되어도 구매 당시의 확인 내용이 사라져서는 안 된다. 취소·환불을 검토할 때에는 원래 주문의 상품·옵션·수량·결제 결과와 제공 기록을 함께 확인해야 한다. 회원과 운영자가 서로 다른 최신 화면만 보고 판단하면 같은 거래를 다르게 해석할 수 있다. 변경 이력을 보존하고 어떤 시점의 약속을 적용하는지 설명하는 것이 사후 처리의 핵심이다.

결제 수단과 권한 경계

Pi로 결제한다고 모든 반환 절차가 자동화되는 것은 아니다. 지원되는 처리 방식과 승인 권한을 실제 결제 계약에 맞추어 확인해야 한다. SDK 콜백이나 내부 관리 화면의 버튼 클릭만으로 반환이 완료됐다고 주장하지 않는다. 거래 결과가 불명확한 상태에서는 같은 반환 요청의 결과를 먼저 확인해야 하며 중복 실행을 피하는 기준이 필요하다. 개인키나 복구 문구를 고객지원 대화로 받아 처리하는 방식은 사용하지 않는다.

읽을 수 있는 조건 만들기

긴 문장을 한꺼번에 나열하기보다 상품별로 구매 전에 알아야 할 조건과 문의 방법을 가까이 배치한다. 제공 방식에 따라 다른 조건이 있다면 그 차이를 드러내고, 언어 변경 후에도 핵심 조건이 빠지지 않도록 검토한다. 법률상 요구 사항은 실제 판매 지역과 상품을 정한 뒤 별도로 확인해야 하므로 이 백서에서 국가별 의무를 추정하지 않는다. 확정되지 않은 조건은 준비 상태로 남기고 공개 전에 검토한다. 조건을 개정할 때에는 새 구매에 적용하는 내용과 기존 주문에 적용하는 내용을 구분하고, 단순한 페이지 수정이 과거의 약속까지 바꾸는 것처럼 보이지 않게 한다.

목차 ↑

062 / 100 · 쇼핑과 Pi 결제

쇼핑 경험의 품질을 측정하기

Commerce Quality Measures

쇼핑의 성장 목표는 버튼 클릭 수만으로 평가할 수 없다. 구매자가 내용을 이해하고, 서버가 같은 요청을 정확히 처리하며, 문제가 생겼을 때 원래 주문을 복구할 수 있는지를 함께 측정해야 한다.

준비 단계의 지표

상품 등록 준비 중에는 등록 초안의 설명 완결성, 필수 항목 누락, 선택지의 모호함, 안내 링크의 오류를 점검할 수 있다. 판매가 시작되지 않았는데 매출이나 구매 전환율을 가정해 표시해서는 안 된다. 합성 검증에서 관측한 결과는 테스트 사례의 수와 조건을 함께 적는다. 예를 들어 여러 옵션을 바꿔 보았다는 사실과 실제 재고 경쟁을 안전하게 처리했다는 사실은 서로 다른 검증 범위다.

거래 단계의 지표

향후 판매가 시작되면 견적 확인에서 승인, 서버 확인, 제공으로 이어지는 각 단계의 이탈과 지연을 구분할 수 있다. 결제 확인 시간이 길어지는 경우에는 회원의 승인 대기와 서버 응답 지연을 같은 수치로 묶지 않는다. 주문 복구 성공 여부도 원래 주문을 찾았는지, 금액이 확인됐는지, 제공 상태를 확인했는지에 따라 나누어 본다. 이 구분이 있어야 개선할 원인을 좁힐 수 있다.

품질과 판매량의 균형

상품을 늘리거나 홍보를 확대하기 전에 현재 제공 범위를 안정적으로 운영할 수 있는지 확인한다. 문의가 급증하는 이유가 수요 증가인지 설명 부족인지에 따라 조치가 달라진다. 안내가 불분명해 생긴 문의를 회원의 사용 미숙으로 처리하지 않는다. 반복적인 결제 재시도를 줄이고 상품 상태를 정확히 표시하는 개선은 단기 클릭 수를 늘리는 것보다 장기적인 신뢰에 도움이 될 수 있다.

확대의 판단 기록

새 상품군이나 새로운 제공 방식을 추가할 때에는 기존 품질 지표와 다른 위험을 별도로 적는다. 상품마다 필요한 운영 조건이 다르므로 첫 상품의 성공만으로 모든 상품을 준비 완료로 표시하지 않는다. 확대를 제안한 이유, 확인한 증거, 남은 과제, 담당 역할을 공통 기록으로 남기는 방법을 권장한다. 백서의 쇼핑 설계는 이러한 판단을 위한 기준이며 현재 판매 실적이나 가맹점 확보를 대신하는 자료가 아니다. 지표를 공개할 때에도 측정 기간과 대상 요청을 함께 제시하면 작은 검증의 결과를 전체 상거래 성능이나 판매 완료 실적으로 오해하는 일을 줄일 수 있다.

목차 ↑

063 / 100 · 공지와 커뮤니티

공지사항을 서비스의 기준점으로

Notices as a Reference

공지는 새로운 소식을 빠르게 알리는 공간인 동시에 회원이 서비스의 현재 상태를 확인하는 기준점이다. 비전, 개발 진행, 실제 배포, 이용 조건을 같은 종류의 소식처럼 나열하지 않고 각 안내가 무엇을 뜻하는지 드러내야 한다.

회원이 먼저 찾는 정보

회원은 자신의 이용에 영향이 있는 변경을 먼저 알고 싶어 한다. 어떤 화면이 달라졌는지, 언제 적용됐는지, 기존 기록은 어떻게 되는지, 직접 해야 할 일이 있는지를 공지 앞부분에 제시한다. 개발 내부의 파일 이름만 나열하면 회원이 행동을 결정하기 어렵다. 반대로 좋은 점만 설명하고 적용 조건을 생략하면 이미 모든 기능이 열린 것으로 읽힐 수 있다. 변경 내용과 이용 가능한 범위를 함께 쓰는 것이 기본이다.

비전 공지와 운영 공지

GCV의 장기 목표와 세계적 서비스로 성장하려는 방향은 비전 공지에서 설명할 수 있다. 상품 등록 준비나 특정 화면의 오류 수정은 운영 공지에 가깝다. 두 종류의 글이 같은 공간에 있더라도 제목과 날짜, 상태 표시로 성격을 구분하면 혼동을 줄일 수 있다. 포부를 말하는 문장을 현재 성능이나 계약 성과처럼 표현하지 않고, 실제 배포를 알리는 글에는 확인한 범위를 구체적으로 적는다.

앱과 홈페이지의 연결

앱 공지는 짧게 읽고 관련 화면으로 이동하기 쉬워야 한다. 홈페이지 공지는 더 긴 설명과 백서, 이용 가이드로 연결할 수 있다. 두 곳이 같은 내용을 안내할 때에는 날짜와 수량, 이용 조건이 일치해야 한다. 한쪽만 수정하면 회원이 다른 정보를 보게 되므로 공통 문구를 점검하는 절차가 필요하다. 앱의 대화상자와 홈페이지의 공지 목록이 서로 다른 형태라는 점도 가독성 검토에 반영한다.

오래된 글의 보존

예전 공지를 지우는 것만으로 현재 설명을 명확하게 만들 수는 없다. 과거에 어떤 조건을 안내했는지 확인해야 하는 회원도 있기 때문이다. 대체된 공지는 이력으로 남기고 최신 안내로 이동할 수 있게 표시하는 방식을 권장한다. 수정 전 문구를 현재 상태처럼 검색 결과에 노출시키지 않도록 제목과 개정 표시도 검토한다. 공지의 신뢰는 항상 새 글이 많다는 사실보다 정보 사이의 우선순위를 알 수 있다는 데서 나온다. 중요한 공지의 제목에는 적용 대상이 드러나도록 하고, 회원이 백서 개정 소식을 읽으면서 기존 활동의 재실행을 요구받는 것으로 이해하지 않게 한다.

목차 ↑

064 / 100 · 공지와 커뮤니티

정책의 개정과 적용 시점

Policy Versions

정책은 내용을 바꾸는 일만큼 어느 시점부터 무엇에 적용되는지 설명하는 일이 중요하다. 현재 정책을 과거 기록에 소급해서 읽거나, 오래된 문서를 새 실행 근거로 사용하는 혼동을 줄여야 한다.

결정과 시행의 구분

정책 방향을 결정한 날, 코드를 개발한 날, 검증을 마친 날, 실제 배포한 날은 다를 수 있다. 공지에는 이 날짜들이 같은 사건인지 구분하여 적어야 한다. 문서가 갱신됐다는 이유로 서버 설정이 이미 바뀌었다고 추정하지 않는다. 반대로 실제 배포가 완료된 뒤에도 이전 대기 문구가 남아 있다면 현재 안내를 갱신하되, 과거 검증 기록 자체를 지우거나 성공 기록으로 바꾸지 않는다.

회원 기록에 미치는 영향

규칙을 개정할 때에는 기존 기록과 새 기록의 경계를 설명한다. 기존 QR의 발급 당시 조건을 유지하면서 새 QR의 유효기간 기준을 달리하는 사례처럼, 같은 이름의 기능에도 시점에 따른 조건이 있을 수 있다. 사용자는 자신이 가진 기록이 어느 조건에 해당하는지 알아야 한다. 개정 공지에 단순히 새 숫자만 표시하기보다 기존 기록을 확인하는 방법과 변경되지 않는 부분을 함께 설명하는 것이 바람직하다.

정책 간 충돌을 다루기

앱 문구, 백서, 이용 가이드가 서로 다르면 가장 유리한 숫자를 골라 적용하는 방식은 적절하지 않다. 최신 직접 결정과 실행 계약, 해당 요청에 대한 서버 확인 결과를 순서대로 대조해야 한다. 확인되지 않은 부분은 임의로 합치지 않고 미확정 항목으로 표시한다. 운영자는 충돌 문구와 수정 이유를 기록하고 관련 화면을 함께 점검한다. 이렇게 해야 다음 개정에서도 같은 혼동을 반복하지 않을 수 있다. 시점이 다른 기록을 비교할 때에는 현재 정책으로 과거 결과를 다시 계산하기 전에 당시의 승인 기준과 보존해야 할 원천을 먼저 확인하는 것이 원칙이다.

목차 ↑

065 / 100 · 공지와 커뮤니티

배포 소식을 정확하게 전달하기

Release Communication

배포 공지는 개발팀이 작업을 끝냈다고 말하는 기록을 넘어 회원이 새 동작을 이해하는 설명이어야 한다. 검증된 결과와 아직 확인하지 못한 환경을 함께 구분하면 지나친 기대와 불필요한 재시도를 줄일 수 있다.

변경의 실제 결과

좋은 배포 공지는 수정 파일 수보다 회원에게 달라진 동작을 먼저 설명한다. 예를 들어 언어 선택 후 안내가 바뀌지 않던 문제가 해결되었다면 어떤 화면과 어떤 상황을 고쳤는지 적는다. 화면 표시 개선을 서버 보상 정책 변경처럼 설명하지 않고, 반대로 정책 변경을 단순한 디자인 변경으로 축소하지 않는다. 회원의 기존 데이터나 요청 상태에 영향이 있는지도 함께 확인한다.

검증 결과의 범위

자동 검사 통과, 로컬 브라우저 확인, 공개 파일 대조, 휴대폰 Pi Browser 확인은 서로 다른 증거다. 각각 무엇을 확인했는지 구분해야 배포 상태를 정확히 이해할 수 있다. 합성 계정의 검사 결과를 실제 회원 거래의 성공으로 쓰지 않는다. 모든 기능이 완료됐다는 표현보다 해당 배포에서 검증한 화면과 경로를 명시하는 편이 후속 장애를 진단할 때에도 유용하다.

재방문 회원의 안내

배포 뒤 회원이 이전 화면을 보고 있다면 새로고침이 도움이 될 수 있지만, 진행 중인 주문이나 활동 요청이 있다면 원래 결과를 먼저 확인해야 할 수도 있다. 따라서 무조건 다시 시작하라는 안내는 피하고 기능의 상태에 맞게 설명한다. 업데이트를 받기 위해 로그아웃이나 기록 삭제를 요구하는 경우에도 실제 필요와 영향을 확인해야 한다. 정상 기록을 보존하는 방향이 기본이며 복구 절차는 별도로 안내한다.

문제 발견 이후의 연결

배포 후 새로운 문제가 보고되면 최초 공지와 후속 안내를 연결한다. 어떤 증상이 영향을 받는지, 현재 가능한 우회 경로가 있는지, 추가 확인 중인 내용을 설명할 수 있다. 확인되지 않은 원인을 즉시 단정하기보다 재현 조건을 모으고 수정 결과를 구분한다. 이전 배포를 복구하는 경우에도 데이터까지 이전 상태로 돌아간다고 추정하지 않으며, 실제로 되돌린 코드와 유지한 기록을 구체적으로 남긴다. 공개 파일의 게시를 확인한 시점과 회원 기기에서 새 화면을 확인한 시점을 따로 남기면, 배포 자체의 문제와 기기에 남은 이전 화면을 구분하는 데 도움이 된다.

목차 ↑

066 / 100 · 공지와 커뮤니티

서비스 장애와 점검 안내

Incident Notices

서비스가 원활하지 않을 때 회원은 문제가 자신의 행동 때문인지, 기다려야 하는지, 같은 요청을 다시 확인해야 하는지 알고 싶어 한다. 장애 안내는 원인을 설명하는 글이면서 추가 피해를 줄이는 사용 안내이기도 하다.

확인된 증상부터 알리기

아직 원인을 모르더라도 확인된 증상은 설명할 수 있다. 특정 화면의 조회가 지연되는지, 여러 기능에 영향이 있는지, 이미 저장된 기록을 볼 수 없는 상태인지를 구분한다. 잔액을 조회하지 못한다는 사실을 잔액이 사라졌다는 의미로 전달하지 않는다. 운영자는 관측한 시각과 대상 경로를 기록하고 추측과 사실을 구분하여 공지를 작성한다. 모르는 내용을 채우는 것보다 확인 중인 범위를 명확히 하는 편이 낫다.

회원에게 필요한 행동

결과가 불명확한 요청에는 새 요청을 반복하지 말고 원래 결과를 확인하도록 안내한다. 단순한 읽기 오류라면 잠시 뒤 다시 조회하는 경로를 제시할 수 있다. 그러나 기능마다 복구 기준이 다르므로 모든 오류에 같은 새로고침 문구를 쓰지는 않는다. 로그아웃이나 저장소 초기화가 필요한지 확인하지 않은 상태에서 이를 권하지 않는다. 오류 화면에 나온 고정 문구와 발생 시각을 알려 주면 진단에 도움이 된다.

점검 범위와 시간

점검을 계획할 때에는 중단될 기능과 계속 사용할 수 있는 기능을 구분한다. 종료 시각을 확정할 근거가 없으면 약속한 시간처럼 쓰지 않고 다음 안내 기준을 적는 방법이 있다. 점검이 길어지는 경우에는 이전 공지를 조용히 수정하기보다 변경 사실을 추가로 알린다. 운영 자료에 접근하는 내부 절차와 회원에게 공개할 정보는 다르므로 접속 정보나 계정의 비밀 내용을 공지에 포함하지 않는다.

복구 후 확인할 것

응답이 다시 온다는 사실만으로 모든 기록이 정상이라고 단정하지 않는다. 조회와 쓰기, 원래 요청의 복구, 여러 계정의 표시 경계를 필요한 범위에서 확인한다. 복구 공지에는 무엇을 회복했고 무엇을 계속 확인 중인지 적는다. 같은 장애의 반복을 줄이려면 관측에서 조치까지의 흐름을 사후 검토하고 안내가 혼란을 만들었던 부분도 함께 고친다. 장애 기록은 책임을 회피하기 위한 문서가 아니라 운영 품질을 높이는 자료다. 복구 직후 회원이 원래 요청을 찾을 수 있는지를 점검하고, 확인 대기 기록을 새 요청으로 바꾸라는 안내가 섞이지 않았는지 공지의 표현까지 함께 검토한다.

목차 ↑

067 / 100 · 공지와 커뮤니티

회원 제안을 제품 개선으로

Feedback into Product Work

회원 의견은 불편을 발견하는 중요한 출발점이다. 그러나 모든 요청을 즉시 기능으로 추가하기보다 어떤 상황에서 무엇이 어려웠는지 파악하고, 기존 규칙과 함께 검토하여 해결하는 절차가 필요하다.

문제와 제안을 함께 듣기

회원이 원하는 버튼을 말할 때 그 배경에는 찾기 어려운 정보나 반복되는 작업이 있을 수 있다. 제안한 모양만 구현하면 원래 문제가 남을 수 있으므로 사용한 화면, 기대한 결과, 실제 결과를 함께 확인한다. 예를 들어 다시하기 버튼을 더 크게 해 달라는 요청은 버튼 위치 문제일 수도 있고 완료 상태가 불명확한 문제일 수도 있다. 재현 가능한 상황을 이해하면 더 작은 변경으로 같은 불편을 해결할 수 있다.

수집할 정보의 범위

문의에는 발생 시각과 화면 이름, 고정 오류 문구, 사용한 언어 정도가 도움이 된다. 계정 비밀번호나 지갑 복구 문구는 문제 설명에 필요하지 않다. 스크린샷을 받을 경우에도 개인 정보와 민감한 식별 값이 포함되어 있는지 안내해야 한다. 공개 커뮤니티에서 개인 주문이나 지급 상태를 해결하려고 하면 노출 위험이 커지므로 해당 기록은 적절한 비공개 확인 경로로 분리하는 것이 바람직하다.

우선순위의 결정

오류의 영향, 재현 가능성, 회원이 우회할 수 있는지, 기존 데이터에 위험이 있는지를 기준으로 우선순위를 정한다. 요청한 사람의 목소리가 크다는 이유만으로 중요한 복구 작업을 뒤로 미루지 않는다. 새로운 기능을 추가하는 대신 문구나 순서를 고치는 것으로 충분한 경우도 있다. 아직 정책이 정해지지 않은 요구는 구현으로 먼저 확정하지 않고 필요한 결정과 가능한 준비 작업을 나누어 기록한다.

결과를 돌려주는 방식

제안이 반영되었다면 어떤 상황이 어떻게 달라졌는지 설명한다. 반영하지 않거나 더 검토하는 경우에는 이유와 남은 질문을 적는다. 모든 제안에 실현 시점을 약속할 필요는 없지만 접수와 검토 상태를 구분하면 회원이 같은 내용을 반복해서 보내는 부담을 줄일 수 있다. 수정 후에는 처음 불편을 겪었던 조건으로 다시 확인하고, 다른 언어나 화면 크기에서 새로운 문제가 생기지 않았는지도 필요한 범위에서 점검한다. 같은 제안을 여러 회원이 보내면 중복 건수만 세기보다 서로 공통으로 겪는 단계와 환경을 비교하여 한 번의 수정으로 해결할 수 있는 원인을 찾는다.

목차 ↑

068 / 100 · 공지와 커뮤니티

신뢰를 지키는 커뮤니티

Community Trust

커뮤니티는 참여자가 경험을 나누고 서로 배우는 공간이다. GCV의 신뢰를 높이려면 활동을 장려하는 것과 확인되지 않은 보상·가격·상장 정보를 공식 사실처럼 퍼뜨리는 일을 구분해야 한다.

경험 공유와 공식 안내

회원의 경험담은 특정 시점과 환경의 관측이다. 공식 정책이나 모든 회원에게 적용되는 결과와 같지 않을 수 있다. 운영 공지와 개인 의견을 명확히 구분하면 도움이 되는 경험을 보존하면서 과장된 일반화를 줄일 수 있다. 예를 들어 한 기기에서 정상 동작했다는 글은 유용하지만 모든 기기 검증 완료를 뜻하지 않는다. 개인이 정리한 사용법도 최신 정책과 차이가 있으면 수정 안내로 연결할 수 있어야 한다.

금액을 말할 때의 맥락

GCV 내부 적립과 Testnet 토큰, Pi 수익은 다른 기준으로 해석해야 한다. 커뮤니티에서 숫자를 공유할 때에는 어떤 자산과 어떤 기록을 말하는지 밝히는 것이 좋다. 화면의 적립액을 현금 수익이나 고정 교환 가치로 설명하면 오해가 생긴다. 특별한 수익을 약속하며 가입이나 지갑 행동을 요구하는 메시지는 공식 안내로 인정하지 않고, 확인할 수 있는 정책과 공개 기록을 기준으로 판단한다.

사칭과 개인 정보 요청

운영자나 지원 담당자를 자처하는 계정이 비밀번호, 개인키, 복구 문구를 요구하더라도 그런 정보는 문제 해결에 제공하지 않는다. 공식 연락처와 현재 공지를 직접 확인하는 습관을 안내한다. 프로젝트 이름이나 로고를 사용하는 것만으로 권한이 증명되는 것은 아니다. 향후 커뮤니티 운영에서는 신고 경로와 검토 절차를 분명히 하고, 신고한 사람의 정보를 불필요하게 공개하지 않는 방법을 검토한다.

비판과 개선의 공간

제품의 문제점을 지적하는 의견은 서비스 품질을 높일 수 있다. 단순히 부정적인 표현이라는 이유로 기술적 문제 제기를 지우면 오류를 찾기 어려워진다. 반면 타인의 개인 정보를 공개하거나 반복적인 사칭을 하는 행동은 다른 문제다. 운영 기준은 내용의 찬반보다 행위와 피해를 중심으로 설명하는 편이 일관성을 높인다. 실제 운영 정책을 확정할 때에는 적용 범위와 이의 제기 방법을 함께 안내한다. 정책을 설명하는 구성원은 개인적인 해석임을 밝히고 공식 문서의 관련 위치를 연결하면, 유용한 토론을 유지하면서 확인되지 않은 주장과 구분할 수 있다.

목차 ↑

069 / 100 · 공지와 커뮤니티

여러 언어로 같은 뜻을 전달하기

Consistent Global Messages

글로벌 서비스에서 언어 지원은 선택 목록의 수보다 중요한 안내를 같은 뜻으로 전달하는 능력에 가깝다. 보상 조건, 거래 상태, 오류 복구처럼 행동에 영향을 주는 문구는 번역 이후에도 원래 계약을 유지해야 한다.

원문과 번역의 연결

번역 문구는 어떤 원문을 옮겼는지 알 수 있어야 한다. 원문이 바뀌었는데 옛 번역이 남으면 회원은 언어에 따라 다른 조건을 읽을 수 있다. 공지 개정 시에는 한국어와 영어의 수량·날짜·적용 범위를 함께 검토하고 다른 언어의 지원 상태를 표시한다. 아직 번역을 확인하지 못한 본문을 완전 번역이라고 소개하지 않는다. 현재 백서는 한국어 100쪽 판이며 영문 짧은 제목과 웹 요약은 본문 전체 번역과 구분한다.

번역하지 말아야 할 값

주문 식별자, 자산 기호, 거래 해시, 계정에서 확인한 값은 일반 문장처럼 바꾸지 않는다. 수량의 쉼표나 소수점 표시는 읽기 쉬운 형태로 보여 줄 수 있지만 의미가 달라져서는 안 된다. 날짜는 어떤 시간 기준인지 함께 표시하고, UTC-5 회계일과 회원 기기의 달력 날짜를 혼동하지 않게 한다. 번역이 숫자의 계산이나 권한 판정에 관여하지 않도록 표시 계층과 실제 상태 처리를 분리한다.

짧은 화면과 긴 문서

휴대폰의 버튼은 긴 설명을 담기 어렵지만 중요한 조건을 완전히 생략해서는 안 된다. 짧은 동작 이름과 가까운 설명을 조합하고 상세 문서로 연결한다. 홈페이지의 긴 본문에서는 목차와 소제목으로 내용을 찾기 쉽게 구성한다. 같은 뜻이라도 언어에 따라 길이가 달라지므로 좁은 화면에서 잘림과 줄바꿈을 확인해야 한다. 읽기 방향이 다른 언어에서도 숫자와 주소를 알아볼 수 있도록 배치한다.

글로벌 검토의 단계

자동 번역이나 용어 사전은 초안을 만드는 데 도움이 될 수 있지만 실제 이해를 확인하는 절차를 대신하지 않는다. 중요한 공지는 원어민 검토나 대상 독자의 피드백을 단계적으로 확보하는 것이 바람직하다. 아직 검토하지 않은 나라에서 운영 중이라고 발표하지 않고 언어 제공과 사업 운영을 분리한다. 언어별 문의의 반복 원인을 보면 문구 자체의 문제인지 제품 흐름의 문제인지 찾는 데 도움이 된다. 원문 개정과 번역 개정을 같은 점검 목록에 두면 한국어에서는 바뀐 상품 상태가 다른 언어에서는 계속 판매 중으로 표시되는 불일치를 예방할 수 있다.

목차 ↑

070 / 100 · 공지와 커뮤니티

공지와 백서, 가이드의 연결

A Connected Knowledge Base

백서 한 권으로 모든 실시간 상황을 설명할 수는 없다. 백서는 구조와 원칙을 설명하고, 가이드는 실제 이용 순서를 안내하며, 공지는 새로 바뀐 상태를 알려 주는 역할을 나누는 것이 효과적이다.

문서마다 답하는 질문

백서는 GCV가 어떤 문제를 해결하려고 하며 기록·자산·역할을 어떻게 구분하는지 설명한다. 이용 가이드는 회원이 지금 어느 버튼을 눌러 어떤 결과를 확인하는지 안내한다. 운영 공지는 적용 시점과 변경 범위를 알린다. 같은 문장을 여러 문서에 복사하면 수정 누락이 생기기 쉬우므로 핵심 정책의 원본을 정하고 필요한 문서에서 그 기준을 참조하는 방식을 권장한다.

깊은 링크의 지속성

회원이 저장하거나 공유한 링크는 문서 개정 뒤에도 도움이 되어야 한다. 기존 백서의 채굴 정책, 수익·보상 정책, 체인 상태와 같은 주요 앵커를 유지하면 과거 안내에서 현재 설명으로 연결할 수 있다. 새 장을 추가할 때에도 제목만 바꾸고 링크를 없애기보다 기존 위치와 새 위치의 관계를 검토한다. PDF와 웹 문서는 표현 방식이 달라도 같은 판의 수량과 조건을 사용해야 한다.

문서를 찾는 경험

회원이 궁금한 것은 문서의 이름보다 자신의 질문인 경우가 많다. 채굴이 멈춘 이유, 추천 보너스가 달라진 이유, 주문을 다시 확인하는 방법처럼 실제 질문에서 관련 장으로 이동할 수 있도록 구성한다. 공지에서 긴 백서 전체를 읽으라고만 안내하기보다 필요한 절과 짧은 설명을 연결한다. 링크를 열었다는 사실로 계정 행동을 시작하지 않으며 공개 정보와 인증된 운영 화면의 경계를 유지한다.

정기적인 내용 점검

문서의 품질은 발행일의 완성도만으로 유지되지 않는다. 화면 이름이 바뀌거나 기능이 배포되면 오래된 문구를 찾아 현재 상태와 비교해야 한다. 그러나 아직 확인하지 않은 운영 결과를 문서 정리 과정에서 완료로 바꾸어서는 안 된다. 수정 요청, 검토한 근거, 적용한 범위를 개정 이력에 남기면 다음 담당자가 내용을 이어받기 쉬워진다. 문서는 개발 결과를 과장하는 홍보물이 아니라 이해와 검증을 돕는 공통 자료다. 새 판을 게시할 때에는 앱 메뉴에서 실제 문서까지의 이동을 확인하고, 웹의 목차와 PDF의 페이지가 같은 주제를 가리키는지도 함께 점검한다.

목차 ↑

071 / 100 · 기술과 신뢰

화면, 서버, 원장의 역할

Clear System Boundaries

GCV의 기술 구조를 이해하는 가장 쉬운 방법은 화면이 설명하는 것과 서버가 확인하는 것, 원장에 남는 것을 나누어 보는 것이다. 이 경계가 분명해야 편리한 화면 개선이 보상이나 거래의 의미를 바꾸지 않는다.

화면은 행동을 설명한다

앱 화면은 회원에게 현재 상태와 가능한 행동을 보여 준다. 선택한 언어, 화면 크기, 게임 효과음과 같은 경험은 사용자 기기에서 처리할 수 있다. 그러나 화면에 보이는 숫자나 버튼 상태만으로 보상 자격을 확정하지 않는다. 브라우저의 임시 계산은 서버에서 확인한 값과 다른 역할을 가진다. 연결이 끊기거나 오래된 화면이 남아 있을 때에도 그 숫자를 새로운 원장 기록으로 복사하지 않는 것이 중요하다.

서버는 계약을 검증한다

서버는 요청의 소유자와 기능의 상태, 입력의 형식, 한도와 중복 여부를 확인한다. 회원이 실제로 선택한 내용과 서버가 처리할 내용이 일치해야 한다. 클라이언트가 보낸 임의 시각이나 금액을 그대로 확정값으로 취급하지 않는다. 오류가 발생하면 내부 사정을 무제한으로 노출하기보다 회원이 다음 행동을 정할 수 있는 고정 오류와 상태를 제공한다. 권한 판단은 화면의 직함 표시가 아닌 현재 서버의 기준에 따른다.

원장은 확인된 사건을 남긴다

적립이나 거래의 결과는 나중에 같은 기준으로 설명할 수 있어야 한다. 어떤 사건과 어떤 규칙으로 기록했는지 구분하면 잔액을 확인하거나 오류를 조사할 때 유용하다. 게임의 기기 점수와 회원의 서버 적립을 같은 기록으로 합치지 않는 이유도 여기에 있다. 기록이 존재한다는 사실, 정산되었다는 사실, 외부 지갑으로 지급되었다는 사실은 각각 다른 상태이며 이를 표현하는 화면도 구분해야 한다.

경계가 만드는 확장성

역할을 나누면 새로운 화면이나 언어를 추가할 때 전체 계산을 다시 만들 필요가 줄어든다. 같은 서버 계약을 여러 화면에서 사용하더라도 각 화면은 자신의 표시와 입력만 책임진다. 반대로 공유 파일 하나에 모든 처리를 몰아넣으면 작은 변경의 영향 범위를 파악하기 어렵다. GCV의 유지보수 방향은 기능별 책임을 나누고 기존 계약을 보존하면서 통합하는 것이다. 구조의 단순함은 파일 수보다 책임이 명확한지로 평가한다. 계층을 나누는 기준은 기술 이름이 아니라 책임이다. 어떤 값이 설명용인지 실제 처리의 입력인지 구별할 수 있어야 새 기능을 안전하게 연결할 수 있다.

목차 ↑

072 / 100 · 기술과 신뢰

시간을 신뢰할 수 있게 다루기

Time and Accounting

활동 보상과 하루 한도에는 시간 기준이 필요하다. 회원의 기기 시각, 서버의 사건 시각, UTC-5 회계일이 같은 용도로 쓰이는 것은 아니므로 각각 어떤 판단에 사용하는지 분명히 해야 한다.

기기 시각의 한계

휴대폰은 지역 설정이나 수동 변경, 일시적인 오차로 서로 다른 시각을 표시할 수 있다. 기기의 시계가 빠르다는 이유로 보상 시간을 늘리거나 느리다는 이유로 과거 기록을 새 사건으로 만들지 않는다. 화면에서는 남은 시간을 이해하기 쉽게 보여 줄 수 있지만 실제 유효 구간과 경과시간은 서버의 확인을 기준으로 한다. 기기 시각에 관한 오류 안내가 나온 경우에도 원인과 적용 경로를 구분하여 진단해야 한다.

24시간 구간과 하루 한도

채굴은 시작 후 24시간이 지나면 종료되며 회원이 직접 다시 시작한다. 반면 UTC-5는 일일 한도와 회계 날짜를 구분하는 기준이다. 채굴을 다시 시작했다고 같은 회계일의 부스트나 선물 횟수가 초기화되는 것은 아니다. 한 채굴 구간이 날짜 경계를 지나더라도 서버가 확인한 유효 구간을 기준으로 계산한다. 두 종류의 시간을 분리해야 회원에게 불필요한 매일 정각 접속 의무가 있는 것처럼 설명하지 않을 수 있다.

시각을 함께 읽는 방법

상태를 표시할 때에는 값이 어느 시점에 확인되었는지도 필요하다. 예를 들어 누적 기록과 예상액을 서로 다른 시점에서 가져와 한 합계로 더하면 정확하지 않을 수 있다. 같은 원장 기준시각의 값인지 확인하고, 오래된 응답이 뒤늦게 도착하면 새 화면을 덮어쓰지 않도록 처리한다. 회원에게 보여 주는 날짜는 현지 표기로 바꿀 수 있지만 회계일의 의미와 원래 사건 시각은 보존해야 한다.

시간 관련 검증 사례

자정 부근의 활동, 전날 시작해 오늘까지 이어지는 채굴, 화면을 오래 숨겼다가 돌아오는 상황, 기기 시각이 뒤로 바뀌는 상황을 검토한다. 중요한 것은 가능한 사건을 모두 정상 처리하는 동시에 존재하지 않은 유효 시간을 만들어 내지 않는 것이다. 이미 확인된 기록을 시계 변화 때문에 지우거나 과거 원천을 추정해 채워 넣지 않는다. 각 검증 결과는 사용한 시계와 합성 조건을 함께 기록하여 실제 운영 결과와 구분한다. 시간 안내를 번역할 때에도 하루와 24시간을 서로 바꾸어 쓰지 않는다. 달력 경계와 개인 채굴 구간의 차이가 유지되는지 예시를 통해 확인한다.

목차 ↑

073 / 100 · 기술과 신뢰

한 번의 행동을 한 번의 기록으로

One Action, One Record

모바일 환경에서는 같은 버튼이 여러 번 눌리거나 응답이 늦게 도착하기 쉽다. 회원의 한 번의 의도를 같은 원래 요청으로 묶어 처리하는 것은 보상과 주문 모두에서 중요한 신뢰 조건이다.

버튼 잠금만으로 부족한 이유

화면에서 버튼을 잠시 비활성화하면 반복 클릭을 줄일 수 있다. 그러나 페이지를 다시 열거나 통신이 재시도되는 상황까지 해결하지는 못한다. 서버도 같은 요청을 구분할 수 있어야 한다. 요청의 의미를 식별자와 확인된 입력에 결합하고 이미 처리한 결과를 다시 확인하는 방식이 필요하다. 새로고침할 때마다 새로운 행동으로 바꾸면 회원은 한 번 선택했는데 여러 기록이 생길 수 있다.

같은 요청의 범위

동일한 요청으로 인정할 조건은 기능별 계약에 따라 정한다. 소유자나 중요한 입력이 다른 요청을 같은 것으로 합쳐서는 안 된다. 반대로 응답만 유실된 동일 요청을 새 시도로 취급해서도 안 된다. 게임 종료의 원래 결과나 운동 완료의 원래 확인처럼 사건의 의미를 유지해야 한다. 재시도 과정에서 점수나 금액을 임의로 바꾸지 않고 기존 요청의 결과를 조회하거나 허용된 동일 요청을 다시 확인한다.

순서가 엇갈리는 응답

오래된 조회가 늦게 도착한 뒤 새로운 요청의 화면을 덮어쓰는 상황도 검토해야 한다. 요청을 시작한 계정과 화면이 아직 현재의 소유자인지 확인하면 이런 오염을 줄일 수 있다. 처리 결과가 늦게 도착했다고 원장 기록을 지우지는 않지만 현재 화면에 그 결과를 보여 줄 수 있는지는 별도로 판단한다. 데이터의 지속성과 화면의 생명주기를 분리해야 안전한 복구와 자연스러운 탐색을 함께 제공할 수 있다.

반복과 새 행동의 구분

운동의 같은 활동 다시하기처럼 회원이 명시적으로 새로운 행동을 선택하는 기능은 정상적인 새 시도다. 이전 완료 기록을 보존하면서 새 확인을 요구하는 이유는 중복 클릭과 새 활동을 구분하기 위해서다. 서버 보상 한도에 도달한 이후에도 기기 활동을 계속할 수 있는 경우에는 이 둘의 차이를 설명한다. 반복 횟수가 늘었다는 사실만으로 이전 완료를 추가 지급하거나 기존 기록을 과거 날짜로 바꾸지 않는다. 같은 요청을 복구하는 버튼은 새로운 활동을 시작하는 버튼과 구분하여 배치하면, 회원이 중복 방지 규칙 때문에 모든 이용이 막혔다고 느끼는 일을 줄일 수 있다.

목차 ↑

074 / 100 · 기술과 신뢰

계정이 바뀌면 화면의 소유자도

Session Ownership

개인 기록을 안전하게 보여 주려면 로그인 여부만 확인해서는 부족하다. 요청을 보낸 계정과 결과를 받는 시점의 계정이 같은지, 해당 화면이 여전히 그 결과를 표시할 권한이 있는지를 확인해야 한다.

늦은 응답의 문제

회원 A가 조회를 시작한 뒤 로그아웃하고 회원 B가 로그인하는 상황을 생각할 수 있다. A의 응답이 나중에 도착했을 때 B의 화면에 표시된다면 데이터가 서버에서 정확했어도 사용자 경험은 잘못된다. 따라서 개인 정보를 표시하는 작업은 요청 당시의 세션과 현재 세션을 대조해야 한다. 단순히 응답이 성공했다는 이유로 화면에 적용하지 않고, 세션 변경 시 진행 중 표시 작업의 소유권을 무효화하는 원칙이 필요하다.

조회와 원래 요청의 보존

로그아웃은 현재 개인 화면을 숨기는 행동이지만 이미 서버에서 처리한 요청이 없어진다는 뜻은 아니다. 완료 여부가 불명확한 요청은 원래 소유자와 함께 복구할 수 있어야 한다. 다른 계정으로 바뀌었다고 해당 요청을 새 계정에 붙이거나 결과를 새 계정의 잔액으로 합산하지 않는다. 기록의 소유와 브라우저 탭의 현재 상태를 분리하면 개인정보 보호와 데이터 보존을 동시에 설명할 수 있다.

공개 탐색의 유지

백서나 공지, 상품 등록 준비 안내는 개인 기록과 다르게 공개 정보를 다룬다. 계정이 바뀌어도 공개 화면을 불필요하게 초기화하거나 다시 로그인하라고 요구할 이유가 적다. 공개 탐색과 인증된 동작의 경계를 명확히 하면 회원은 안내를 먼저 읽고 필요한 시점에만 인증할 수 있다. 화면 디자인에서 공개 글과 개인 잔액이 가까이 배치되어 있더라도 데이터 소유 기준은 각각 유지해야 한다.

권한을 표시와 분리하기

운영자나 연합회 같은 역할 이름이 화면에 보인다는 사실만으로 관리 작업을 허용하지 않는다. 현재 서버에서 검증한 권한과 작업 범위에 따라 판단해야 한다. 오래된 탭이나 캐시에 남은 역할 정보가 새로운 권한을 만들지 않도록 검토한다. 계정 변경, 세션 만료, 접근 거절, 정상 재로그인이라는 여러 상황에서 어떤 정보를 지우고 어떤 원래 요청을 보존하는지 회귀 검증을 수행하는 것이 중요하다. 개인 정보가 숨겨진 뒤에는 접근성 안내나 보이지 않는 상세 영역에도 이전 계정의 내용이 남아 있지 않은지 확인하여 시각적인 숨김만으로 처리를 끝내지 않는다.

목차 ↑

075 / 100 · 기술과 신뢰

조회 실패를 숫자 0으로 바꾸지 않기

Honest Read States

회원은 화면의 숫자를 현재 상태로 받아들이기 쉽다. 그래서 데이터를 읽지 못한 경우와 실제 값이 0인 경우를 구분하는 표시가 필요하다. 정직한 빈 상태는 화려한 숫자보다 정확한 판단에 도움이 된다.

상태의 구분

조회 전, 조회 중, 정상 결과, 결과 없음, 연결 오류, 권한 없음은 서로 다른 상태다. 예를 들어 활동 목록이 비어 있다는 정상 응답과 목록을 불러오지 못했다는 오류는 같은 화면이 되어서는 안 된다. 잔액을 알 수 없을 때 0을 보여 주면 회원은 기록이 사라졌다고 생각할 수 있다. 확인되지 않은 값은 확인 불가로 표시하고, 이전에 확인한 값을 보존한다면 그것이 오래된 값임을 함께 알려야 한다.

여러 요약을 함께 읽을 때

홈 화면에 여러 기능의 현황이 함께 있더라도 모두 같은 원천을 갖는 것은 아니다. 기기의 게임 최고 점수, 서버의 하루 보상 횟수, 미정산 적립과 확정 잔액을 무작정 더하지 않는다. 값마다 단위와 기준시각을 확인해야 한다. 한 기능의 조회가 늦어진다고 다른 정상 요약까지 모두 실패로 처리하는 것이 적절한지도 검토한다. 독립적인 조회와 일관된 합계의 조건을 구분하는 설계가 필요하다.

다시 확인하는 행동

조회 오류에서 제공하는 다시 확인 버튼은 무엇을 다시 하는지 분명해야 한다. 단순한 GET 조회를 반복하는 것과 원래 쓰기 요청의 결과를 확인하는 것은 다른 행동이다. 회원에게 같은 버튼 이름으로 두 가지를 혼동시키지 않는다. 통신이 계속 실패하면 기다릴 수 있는 상태를 보여 주고 불필요한 자동 요청을 늘리지 않는다. 정상 응답 이후에도 현재 계정과 화면의 소유자가 맞는지 확인한 뒤 값을 표시한다.

검증할 표현과 사례

합성 검증에는 정상적인 0, 목록이 없는 응답, 지연된 응답, 서버 오류, 세션 만료를 각각 포함한다. 숫자의 형식이 잘못되거나 필수 필드가 없는 응답도 정상 데이터처럼 보이지 않게 한다. 이런 검증은 회원이 데이터를 과소평가하거나 과대평가하는 위험을 줄인다. 실제 운영에서는 오류 빈도와 복구 경로를 관측하되 개인 잔액이나 인증 정보를 로그에 무분별하게 남기지 않는 방식이 필요하다. 요약 숫자 옆의 단위와 상태 설명도 번역 대상에 포함하면 다른 언어에서 값만 남고 확인 조건이 사라지는 문제를 줄일 수 있다.

목차 ↑

076 / 100 · 기술과 신뢰

계약을 지키는 검증

Contract Based Validation

검증의 목적은 많은 통과 숫자를 만드는 것이 아니라 변경 이후에도 중요한 약속이 유지되는지 확인하는 것이다. 정상 사용뿐 아니라 중복, 지연, 잘못된 입력, 오래된 환경에서도 계약을 지키는지 살펴야 한다.

계약을 먼저 정의하기

무엇을 입력으로 받으며 어떤 결과를 반환하는지, 어떤 조건에서 거절하는지 정하면 검증할 대상을 분명히 할 수 있다. 문구만 바꾸는 작업이라면 보상 계산과 서버 호출이 달라지지 않아야 한다. 저장 처리 변경이라면 기존 기록의 보존과 중복 방지, 복구를 확인해야 한다. 검사 항목은 구현한 코드를 그대로 따라 쓰기보다 사용자가 관측하는 결과와 지켜야 할 경계에서 도출하는 편이 좋다.

실패를 먼저 재현하기

재현 가능한 오류는 수정 전의 입력과 결과를 남기면 검토가 쉬워진다. 예를 들어 특정 브라우저 기능이 없을 때 초기 화면이 열리지 않는다면 그 조건을 격리하여 실패를 확인한다. 수정 후 같은 조건에서 정상 흐름이 이어지는지 비교하고, 정상 환경의 동작도 보존했는지 확인한다. 오류 메시지를 숨겨 통과시키거나 실제 검사를 건너뛰어 숫자만 늘리는 방식은 문제 해결로 볼 수 없다.

단계별 증거의 연결

작은 단위 검사와 화면 통합 검사, 전체 로컬 검사, 정확한 배포 후보의 자동 검사, 공개 배포 확인은 역할이 다르다. 집중 검사는 변경 원인을 빠르게 찾고, 통합 검사는 다른 기능과의 연결을 확인한다. 배포 파일이 검사한 소스와 같은지 확인하는 단계도 필요하다. 검사 중 실패한 이력은 수정 후 성공 결과와 함께 기록하여 무엇을 고쳤는지 알 수 있도록 한다.

검증하지 못한 범위

로컬 합성 계정은 실제 회원의 동의나 외부 지갑 행동을 대신하지 못한다. 선택적으로 실행하는 데이터베이스 검사를 건너뛰었다면 그 사실을 분명히 적어야 한다. 네트워크나 기기 환경 때문에 확인하지 못한 항목을 추정으로 통과 처리하지 않는다. 검증 범위의 한계를 적는 것은 개발을 중단한다는 뜻이 아니라 다음에 필요한 증거를 정확히 지정하는 일이다. 이미 통과한 동일 검사를 이유 없이 반복하는 일도 줄일 수 있다. 보존 검사는 새 변경의 정확한 범위를 허용하면서 관련 없는 본문이나 계산 규칙의 변화는 계속 발견할 수 있어야 하며, 오래된 기대값을 일괄 삭제하지 않는다.

목차 ↑

077 / 100 · 기술과 신뢰

검사한 코드와 배포한 파일

Release Provenance

검증된 코드를 배포했다고 말하려면 검사한 상태와 실제 게시한 파일이 연결되어야 한다. 여러 작업이 동시에 진행되는 프로젝트에서는 원본 변경을 보존하고 배포 후보를 분리하는 과정이 특히 중요하다.

원본을 보존하는 시작

작업을 시작할 때 현재 브랜치와 커밋, 미커밋 변경, 실행 중인 다른 작업을 확인한다. 기존 파일을 초기화하거나 덮어쓰면 어떤 변경이 누구의 작업인지 판단하기 어려워진다. 별도 작업 공간을 사용하면 이미 진행 중인 수정과 새 배포 후보를 분리할 수 있다. 이때 복사한 파일이 실제 정본인지, 과거의 작은 체크아웃인지도 확인해야 한다. 폴더 이름만 보고 최신 소스라고 가정하지 않는다.

후보의 범위 고정

배포 후보를 만들 때에는 포함할 변경과 제외할 운영 영역을 명확히 정한다. 앱의 표시 개선이 서버 설정이나 데이터베이스 변경까지 포함하는 것은 아니다. 검사 이후 제품 파일이 바뀌면 어떤 검증을 다시 해야 하는지 판단할 수 있어야 한다. 파일 해시나 커밋 식별자는 이 연결을 설명하는 데 도움이 되지만 그 자체가 기능의 정확성을 증명하지는 않는다. 내용 검사와 출처 확인을 함께 수행한다.

정적 배포의 확인

앱과 홈페이지는 서로 다른 정적 산출물과 목적지를 사용할 수 있다. 각각의 공개 주소에서 필요한 파일이 게시됐는지, 링크와 보안 헤더가 의도대로인지 확인한다. 백서 PDF를 새로 추가했다면 빌더가 해당 파일을 포함하는지도 검토해야 한다. 파일을 로컬에서 만들었다는 사실만으로 다운로드 링크가 공개 환경에서 열리는 것은 아니다. 실제 게시한 묶음과 이전 복구 가능한 묶음을 구분하여 남긴다.

되돌리기의 범위

배포를 되돌릴 때에는 무엇을 되돌리는지 설명해야 한다. 정적 파일을 이전 버전으로 바꾸는 일은 이미 생성된 서버 기록을 삭제하거나 과거 상태로 복원하는 일과 다르다. 데이터와 코드의 관계를 확인하지 않은 채 일괄 초기화하는 방식은 피한다. 변경 범위와 복구 방법을 미리 기록하면 오류 발견 후 판단이 쉬워진다. 배포 기록에는 성공 결과뿐 아니라 필요한 경우의 중단과 복구 판단도 포함한다. 배포 문서에는 어느 도메인의 어느 산출물을 확인했는지 적어, 앱만 게시된 상태를 홈페이지 문서와 모든 서버까지 함께 배포한 것으로 오해하지 않게 한다.

목차 ↑

078 / 100 · 기술과 신뢰

문제를 찾을 수 있는 관측

Useful Observability

서비스를 안정적으로 운영하려면 문제가 생겼다는 사실뿐 아니라 어느 단계에서 어떤 조건으로 발생했는지 알 수 있어야 한다. 관측 정보는 개인 정보를 많이 모으는 일이 아니라 필요한 질문에 답하는 기록이어야 한다.

사용자 경험과 시스템 지표

서버가 응답한다는 사실과 회원이 원하는 화면을 정상적으로 사용한다는 사실은 다를 수 있다. 조회 지연, 화면 오류, 원래 요청 복구 실패처럼 사용자 경험에 가까운 신호를 함께 살펴야 한다. 동시에 각 지표의 측정 조건을 기록한다. 특정 합성 요청의 응답시간을 전체 회원의 체감 속도로 일반화하지 않고, 실제 표본과 관측 구간을 구분하는 것이 성능 논의를 정확하게 만든다.

요청을 따라가는 정보

문제를 조사할 때에는 같은 요청이 어느 단계까지 도달했는지 알 수 있는 식별 정보가 도움이 된다. 그러나 인증 토큰이나 비밀 연결 정보를 그대로 로그에 남길 필요는 없다. 공개 가능한 오류 코드, 요청의 단계, 처리 시각과 결과를 중심으로 기록하는 설계를 권장한다. 여러 시스템의 시각이 다를 수 있으므로 사건 순서와 기준시각을 함께 확인하며, 단순한 문장 검색만으로 거래 완료를 판정하지 않는다.

알림의 기준

모든 일시적 지연을 같은 긴급도로 알리면 중요한 문제를 놓치기 쉽다. 영향을 받는 기능과 반복 정도, 데이터 보존과 복구 가능성을 기준으로 대응 수준을 정한다. 새로운 문제가 생겼는지, 이미 알려진 상태가 계속되는지 구분하는 것도 필요하다. 알림은 운영자가 다음 행동을 선택할 수 있는 정보여야 하며 단순히 상태가 같다는 사실을 과도하게 반복하는 방식은 피한다.

사후 검토와 개선

오류가 해결된 뒤에는 발견부터 확인, 조치, 복구 검증까지의 흐름을 살펴본다. 어떤 관측이 도움이 됐고 어떤 정보가 부족했는지 기록하면 다음 대응이 빨라진다. 회원에게 전달한 안내가 실제 상태와 맞았는지도 함께 검토한다. 관측 체계의 개선은 장애가 전혀 없을 것이라는 약속이 아니라 문제를 더 빨리 이해하고 같은 실수를 줄이기 위한 노력이다. 측정 결과를 근거 없는 무장애 주장으로 바꾸지 않는다. 관측 지표가 개선되었다면 측정 방식이 바뀐 영향인지 실제 문제가 줄어든 결과인지 확인하고, 두 변화가 함께 있었을 경우에는 각각의 범위를 설명한다.

목차 ↑

079 / 100 · 운영 체계

작은 조직에서도 분명한 책임

Accountable Operations

GCV는 작은 운영 조직에서 출발하더라도 회원 규모가 커질 때 필요한 책임을 미리 구분하려고 한다. 한 사람이 여러 역할을 맡는 것과 모든 권한을 한 번에 행사하는 것은 같은 뜻이 아니다.

공개 운영 정보

현재 승인된 공개 사업 정보는 상호 드림해피, 운영자 이상재, 사업자등록번호 217-26-65881, 통신판매업 신고번호 제2026-경북경주-0436호다. 연락 창구는 gcv314159pi@gmail.com이다. 이 정보는 누구에게 문의할지 알려 주는 자료이며 특정 상품의 판매 개시나 외부 기관의 기술 승인을 뜻하지 않는다. 실제 상품의 제공 조건이나 반품 주소는 별도 확인이 필요한 항목으로 다룬다.

역할에 따른 결정

기획은 어떤 문제를 해결할지 정하고, 개발은 계약에 맞는 동작을 구현하며, 검증은 그 결과를 확인한다. 운영은 실제 상태와 회원 문의를 관측하고 배포나 복구를 판단한다. 같은 사람이 여러 역할을 맡더라도 기록에서는 어떤 역할로 결정했는지 구분하면 도움이 된다. 예를 들어 안내 문구를 고친 승인과 실제 결제 기능을 여는 승인을 같은 것으로 취급하지 않는다.

위임할 수 있는 범위

반복적인 읽기 점검이나 문서 정리는 범위를 정해 위임할 수 있다. 반면 실제 자산 이동, 개인키 사용, 운영 데이터 변경처럼 영향이 큰 일은 대상과 조건을 명확히 해야 한다. 도구를 사용할 수 있다는 이유만으로 모든 작업을 실행할 권한이 생기지는 않는다. 향후 조직이 커져도 역할별 허용 범위와 실제 승인 내용을 연결하고, 담당자가 바뀔 때 기존 작업 상태를 먼저 확인하는 원칙을 유지한다.

책임 기록의 실용성

복잡한 보고 체계를 만드는 것보다 중요한 결정의 이유와 대상, 결과를 찾을 수 있게 하는 것이 우선이다. 어떤 변경을 누가 검토했고 무엇이 확인되지 않았는지 알 수 있으면 다음 담당자가 같은 질문을 반복하지 않는다. 오류가 발생했을 때에도 사람의 기억보다 기록을 기준으로 원인을 확인할 수 있다. 책임을 분명히 하는 목적은 책임 전가가 아니라 안전하게 일을 나누고 결과를 이어가기 위한 것이다. 운영자 이름이 공개되어 있다는 사실은 모든 문의를 공개 게시판에서 처리하라는 뜻이 아니다. 개인 주문과 계정 문제는 공개 사업 안내와 분리하여 다룬다.

목차 ↑

080 / 100 · 운영 체계

변경의 권한과 영향 범위

Scoped Change Control

개발을 계속하라는 요청은 유용한 개선을 진행하라는 뜻이지만 모든 운영 영역을 무제한으로 바꾸라는 의미는 아니다. 실제 작업에서는 무엇을 바꿀 권한이 있는지와 그 변경이 어디까지 영향을 주는지 함께 확인해야 한다.

일상적인 개선

문구, 접근성, 화면 진입 오류, 기존 계약의 미완성 연결은 비교적 좁은 변경으로 해결할 수 있다. 기존 데이터를 보존하고 관련 검증을 수행하면 빠르게 개선할 여지가 있다. 이 경우에도 다른 작업이 같은 파일을 수정하는지 확인하고 한 번에 검토할 수 있는 범위로 묶는다. 작은 개선을 위해 관련 없는 기능의 설정이나 데이터를 바꾸지 않는 것이 결과를 이해하기 쉽게 만든다.

별도 판단이 필요한 작업

운영 데이터베이스 구조 변경, 계정 이전, 새 유료 자원, 실제 외부 지급과 발행은 화면 개선과 영향이 다르다. 이런 작업은 정확한 대상과 실행 조건을 확인해야 하며 이전의 포괄적인 개발 요청을 임의로 확대하지 않는다. GCV의 Testnet 증거도 Mainnet 실행이나 모든 회원 지급을 승인하는 근거가 아니다. 권한 범위를 분리하면 필요한 개발을 계속하면서도 다른 영역의 위험을 만들지 않을 수 있다.

검토 가능한 결과 만들기

승인 전에 가능한 준비를 마쳐야 검토자가 무엇을 판단하는지 알 수 있다. 변경할 파일과 동작, 테스트 결과, 게시할 산출물, 남은 위험을 구체적으로 제시하는 방법이 좋다. 아직 결과물이 없는 상태에서 막연한 일괄 승인을 반복해서 요청하면 판단의 질이 낮아진다. 반대로 이미 명확히 승인된 범위의 가역적인 준비를 이유 없이 멈추는 것도 효율적이지 않다. 작업의 영향에 맞는 판단 단위를 사용한다.

변경 후의 확인

실행 권한을 받았다는 사실과 실행이 성공했다는 사실은 다르다. 변경 후에는 대상의 실제 상태와 기대한 결과를 확인하고, 예상 밖의 영향이 있으면 범위를 좁혀 보고한다. 일부 단계가 실패했을 때 다른 단계의 성공으로 전체 완료를 표시하지 않는다. 운영 절차에는 중단 기준과 복구 가능한 범위를 함께 남겨 다음 담당자가 같은 실행을 중복하지 않도록 한다. 승인 기록은 반복 실행의 허가증이 아니라 해당 작업의 근거다. 작업이 승인 범위를 벗어나는지 판단할 때에는 사용하는 도구 이름보다 실제로 바뀌는 대상과 되돌릴 수 있는 범위를 기준으로 검토한다.

목차 ↑

081 / 100 · 운영 체계

기록 보존과 복구 준비

Preservation and Recovery

회원이 축적한 기록은 화면을 새로 만드는 과정에서도 이어져야 한다. 보존은 아무것도 바꾸지 않는다는 뜻이 아니라 변경 전후에 무엇이 유지되었는지 확인할 수 있게 관리하는 일이다.

보존할 대상의 구분

회원 계정과 추천 관계, 적립 원천, 미정산 내역, 확정 잔액, 주문과 처리 이력은 각각 다른 기록이다. 하나를 복사하거나 복구했다고 나머지도 일치한다고 가정해서는 안 된다. 원본과 파생 요약, 화면의 임시 상태를 구분하면 복구 과정에서 잘못된 값을 정본으로 삼는 위험을 줄일 수 있다. 과거 자료가 불분명한 경우에는 확인되지 않은 잔액을 만들어 채우기보다 원본을 보존하고 검증 범위를 표시한다.

백업의 의미

백업 파일이 있다는 사실만으로 복구가 검증된 것은 아니다. 무엇을 어느 시점에 저장했는지, 어떤 환경에서 다시 읽을 수 있는지, 접근 권한은 누가 갖는지 확인해야 한다. 운영 데이터가 포함된 자료는 공개 문서나 소스 저장소에 넣지 않는다. 이 백서는 특정 백업 주기나 실제 복구 시간을 임의로 약속하지 않으며, 운영 환경에 맞는 보존 정책과 격리된 복구 검증을 마련하는 방향을 제안한다.

복구 검증의 순서

복구를 검토할 때에는 먼저 원본을 변경하지 않는 읽기 점검으로 상태를 파악한다. 이후 필요한 경우 승인된 격리 환경에서 자료의 구조와 연결 관계를 확인한다. 수량만 같다고 동일한 기록으로 판단하지 않고 소유자와 사건의 관계, 중복 여부를 함께 검토해야 한다. 실제 운영 자료에 쓰는 단계는 별도의 대상 확인과 절차가 필요하다. 합성 자료의 복구 성공을 운영 자료의 복구 완료로 바꾸어 발표하지 않는다.

이력과 현재 상태의 연결

옛 기록을 보존하면서 새 구조로 전환할 경우에는 두 기록의 관계를 알 수 있어야 한다. 새 화면이 옛 잔액을 중복 합산하거나 과거 사건을 새로운 보상으로 다시 만들지 않도록 검토한다. 복구 이후에도 회원이 자신의 원래 기록을 이해할 수 있는 조회 경로가 필요하다. 무엇이 복구되었고 어떤 부분은 확인 대기인지 정확히 표시하면 문제 해결 과정에서 불필요한 오해와 반복 문의를 줄일 수 있다. 복구 검토에서 발견한 불일치는 그 원인을 확인하기 전까지 자료를 삭제해 맞추지 않는다. 원본과 관측 결과를 함께 보존해야 이후의 대사가 가능하다.

목차 ↑

082 / 100 · 운영 체계

병행 개발과 안전한 인계

Parallel Work and Handoffs

여러 작업을 병행하면 독립적인 문제를 빠르게 해결할 수 있다. 하지만 같은 파일이나 운영 자원을 동시에 바꾸면 속도보다 혼란이 커질 수 있으므로 소유 범위와 통합 시점을 정하는 것이 중요하다.

독립적인 작업 나누기

문구와 번역, 화면 회귀, 빌드 검증처럼 서로 다른 책임은 나누어 진행할 수 있다. 이때 누가 어떤 파일을 수정하는지 분명히 정한다. 파일 이름이 다르더라도 같은 정책이나 공통 상태를 바꾸는 작업은 연결 관계를 확인해야 한다. 읽기 전용 검토와 실제 편집의 권한도 구분한다. 병행 작업의 목적은 같은 일을 여러 번 하는 것이 아니라 서로 독립적인 증거와 구현을 효율적으로 모으는 데 있다.

시작할 때 확인할 것

기존 저장소의 미커밋 변경과 별도 작업폴더, 실행 중인 검증이나 배포를 먼저 확인한다. 작업자가 바뀌었다는 이유로 폴더를 초기화하거나 진행 중인 프로세스를 중단하지 않는다. 이전 기록에 있는 경로가 현재도 존재하는지 확인하고, 사라진 작업폴더를 최신 상태라고 가정하지 않는다. 어떤 소스가 실제 기준인지 확인한 뒤 새 변경을 시작해야 이후의 통합과 배포 결과를 설명할 수 있다.

통합 시점의 검토

각 담당자가 집중 검증을 마쳤다고 전체가 자동으로 맞물리는 것은 아니다. 공통 문구나 데이터 계약의 충돌을 확인하고, 동결된 같은 소스에서 통합 검사를 수행한다. 이미 통과한 검사를 이유 없이 반복하기보다 새 변경이나 실패가 어떤 재검증을 필요로 하는지 판단한다. 담당 작업을 반환할 때에는 수정 파일과 테스트 결과, 최초 실패, 미확인 범위를 함께 알리는 것이 다음 단계의 효율을 높인다.

인계 기록의 내용

인계에는 현재 기준 커밋, 수정된 파일, 수행한 검증, 배포된 대상, 남은 작업과 담당 경계를 적는다. 완료했다는 한 문장만으로는 다음 작업자가 중복 실행을 피하기 어렵다. 특히 운영 설치와 데이터 복구, 실제 지급은 같은 프로젝트 안에서도 별도 작업일 수 있다. 인계받은 사람은 기존 결과를 보존하면서 새로운 증거가 필요한 부분만 확인한다. 읽기 점검에서 시작하는 습관이 안전한 지속 개발의 기반이다. 병행 작업 중 새로운 사용자 결정이 들어오면 공통 계약을 갱신하고 관련 담당자에게 전달하되, 이미 실행 중인 다른 작업에 자동 반영됐다고 가정하지 않는다.

목차 ↑

083 / 100 · 운영 체계

자원과 비용을 함께 관리하기

Capacity and Cost Decisions

서비스가 성장하면 처리량뿐 아니라 비용과 운영 복잡성도 함께 증가한다. 자원을 늘리기 전에 어떤 부하가 생겼고 어떤 개선이 필요한지 확인하면 안정성과 지속 가능성을 함께 검토할 수 있다.

등록 회원과 실제 부하

등록 회원 수는 사업 규모를 설명하지만 서버 부하를 직접 나타내지는 않는다. 같은 회원 수라도 동시 접속, 활동 빈도, 조회 간격, 처리해야 할 기록의 양에 따라 요구 자원이 달라진다. GCV의 300만 회원 목표를 곧바로 검증된 동시 처리 능력으로 읽지 않는다. 자원 계획에는 회원 규모와 함께 어떤 사용 패턴을 가정했는지 기록해야 하며, 관측되지 않은 수치를 운영 실적으로 발표하지 않는다.

불필요한 작업 줄이기

비용을 줄이는 첫 방법은 필요한 결과를 더 적은 중복 작업으로 제공하는 것이다. 같은 상태를 지나치게 자주 조회하거나 이미 확정된 결과를 반복 계산하면 자원을 낭비할 수 있다. 다만 요청 수를 줄인다는 이유로 오래된 정보를 최신처럼 보여 주어서는 안 된다. 조회의 갱신 조건과 캐시의 의미를 명확히 하고, 활동 상태가 바뀌었을 때 필요한 부분을 다시 확인하는 방식으로 효율과 정확성을 함께 검토한다.

확장의 근거 만들기

새 자원을 도입할 때에는 해결하려는 병목과 기대 효과를 설명한다. 저장 공간이 부족한지, 요청 처리 시간이 늘어나는지, 운영자의 복구 절차가 느린지에 따라 선택이 달라진다. 유료 전환이나 새 계정, 권한 확대는 별도 판단이 필요한 운영 행동이며 개발 편의를 이유로 임의 실행하지 않는다. 작은 규모의 합성 실험을 통해 후보를 비교할 수 있지만 운영 도입 전에는 실제 환경의 조건을 다시 확인한다.

사업 판단과 기술 판단

비용이 낮다는 이유만으로 회원 기록의 보존이나 복구 가능성을 희생해서는 안 된다. 반대로 모든 장래 목표를 즉시 감당하는 자원을 먼저 확보할 필요도 없다. 현재 제공 범위와 측정한 수요에 맞추어 단계적으로 확장하고, 각 선택의 비용과 제한을 기록한다. GCV의 성장 전략은 큰 숫자를 약속하는 것보다 실제 사용을 관측하고 근거에 따라 다음 투자를 결정하는 방향을 지향한다. 자원을 늘린 뒤에도 원래 병목이 실제로 개선됐는지 확인해야 한다. 비용 증가만 있고 사용자 경험이 달라지지 않았다면 측정과 설계를 다시 검토한다.

목차 ↑

084 / 100 · 운영 체계

반복 가능한 운영 절차

Operational Playbooks

운영 절차는 담당자가 바뀌어도 같은 기준으로 판단할 수 있게 하는 자료다. 정상 처리 순서뿐 아니라 중단해야 할 조건과 결과가 불명확할 때의 확인 방법을 포함해야 실무에서 도움이 된다.

절차의 시작 조건

운영 문서는 어떤 환경과 어떤 상태에서 사용하는지 먼저 밝힌다. 이미 완료된 설치를 다시 실행하거나 과거의 배포 명령을 현재 상황에 그대로 적용하는 일을 줄이기 위해서다. 대상 프로젝트와 자원, 현재 접근 계정, 필요한 권한을 확인한 뒤 작업을 시작한다. 이름이 비슷하다는 이유만으로 다른 프로젝트를 열거나 변경하지 않는다. 절차에 적힌 예시가 실제 운영 대상을 대신하지 않는다는 점도 명확히 한다.

예상 결과와 중단 조건

각 단계에는 다음으로 진행할 수 있는 결과와 멈춰 확인할 결과가 필요하다. 성공 메시지가 없거나 응답이 유실된 경우에는 같은 작업을 즉시 반복하지 않고 원래 결과를 조회하는 경로를 사용한다. 데이터 변경이 포함된 절차라면 실행 전후의 확인 범위도 정한다. 단순한 화면 캡처와 서버가 확인한 상태를 혼동하지 않으며, 관측할 수 없는 단계는 미확인으로 남겨 다음 판단자가 알 수 있게 한다.

정상 이력의 재사용

이전에 통과한 검사와 완료된 설치 기록은 다음 작업의 출발점으로 활용할 수 있다. 그러나 시간이 지남에 따라 달라질 수 있는 사실은 필요한 범위에서 다시 확인한다. 정책이나 실행 대상이 바뀌지 않았다면 같은 작업을 무조건 반복하지 않는다. 어떤 근거를 재사용했고 어떤 근거를 새로 확인했는지 구분하면 검증 비용을 줄이면서도 결과의 신뢰를 유지할 수 있다.

문서와 실제 경험의 순환

운영 중 절차에 없는 상황을 만났다면 원래 기록을 보존하고 추가로 확인한 내용을 남긴다. 나중에 절차를 개정할 때에는 그 사례가 일반적인 규칙인지 특정 환경의 예외인지 검토한다. 예외 처리만 계속 쌓여 실제 흐름을 이해하기 어려워지면 책임과 단계를 다시 정리한다. 운영 문서의 완성도는 분량이 아니라 현재 담당자가 안전하게 시작하고 멈추고 인계할 수 있는지로 평가할 수 있다. 새 담당자는 절차의 마지막 실행 기록과 현재 상태를 비교한 뒤 필요한 지점에서 이어 가며, 처음부터 다시 실행하는 것이 안전하다고 일률적으로 판단하지 않는다. 실행 대상이 바뀌었다면 이전 절차의 시작 조건부터 다시 대조한다.

목차 ↑

085 / 100 · 글로벌 성장

세계적 목표를 품질 과제로 바꾸기

Ambition into Quality Goals

세계적인 GCV를 지향한다는 말은 현재의 순위나 가치를 선언하는 문장이 아니라 매일의 품질 과제로 바뀌어야 한다. 회원이 믿고 사용하는 작은 경험의 반복이 장기적인 브랜드를 만드는 기반이다.

목표를 관측 가능한 질문으로

좋은 서비스라는 목표는 회원이 어떤 경험을 하는지 질문할 때 구체적이 된다. 처음 방문한 사람이 현재 가능한 기능을 이해하는가, 활동 결과가 왜 그렇게 계산됐는지 확인할 수 있는가, 오류 뒤 원래 요청을 되찾을 수 있는가를 살펴볼 수 있다. 이런 질문은 순위나 가격을 예측하는 것보다 제품 개선으로 연결하기 쉽다. GCV는 야심찬 목표와 현재 검증한 사실을 함께 제시하되 두 가지를 혼동하지 않는다.

핵심 경험의 일관성

처음 로그인한 회원과 오래 사용한 회원, 다른 언어를 선택한 회원이 같은 정책을 읽어야 한다. 같은 행동의 결과가 기기나 화면에 따라 다르게 설명되면 신뢰가 줄어든다. 새로운 기능을 많이 보여 주는 것보다 채굴·활동·조회·복구의 기본 흐름을 일관되게 만드는 것이 우선이다. 장기 목표를 이루기 위한 첫 경쟁력은 과장된 문구가 아니라 회원이 다시 방문해도 설명이 맞는다는 경험이다.

작은 개선의 축적

버튼의 의미를 분명히 하거나 오류 상태를 구분하는 작은 변경도 반복 문의를 줄이고 이용을 돕는다. 다만 변화가 있었다는 사실만으로 개선 효과를 단정하지 않고 실제 관측과 회원 의견을 확인한다. 변경 전후의 혼동 사례와 처리 경로를 비교하면 다음 작업을 선택하기 쉬워진다. 성공한 변경의 이유를 기록하고 다른 화면에 적용할 때에는 그 화면의 계약이 같은지 다시 검토한다.

브랜드 약속의 범위

GCV의 브랜드는 참여와 신뢰, 실생활 활용을 지향한다. 그 약속을 특정 토큰 가격이나 수익률로 바꾸면 제품의 실제 품질을 평가하기 어렵다. 세계적 성장과 거래소 상장, 외부 기관의 승인도 각각 다른 목표와 조건을 가진다. 기술과 운영의 준비를 쌓아 가되 확인되지 않은 성과를 앞당겨 발표하지 않는 태도가 장기적인 신뢰를 지킨다. 큰 목표일수록 현재 단계의 설명은 더 정확해야 한다. 품질 목표에는 오류를 발견했을 때 설명하고 수정하는 태도도 포함된다. 문제를 감추는 것보다 확인된 범위와 해결 과정을 일관되게 공개하는 것이 중요하다.

목차 ↑

086 / 100 · 글로벌 성장

가입보다 먼저 이해시키기

Understanding Before Signup

건강한 회원 성장은 많은 사람이 가입 버튼을 누르는 데서 끝나지 않는다. 어떤 서비스에 참여하는지 이해하고 본인의 계정으로 필요한 절차를 마친 뒤 첫 경험을 이어갈 수 있어야 한다.

첫 방문의 정보 순서

처음 방문한 사람에게는 GCV가 제공하는 활동과 현재의 서비스 범위, Pi Browser에서 이용하는 방법을 먼저 설명한다. 백서 전체를 읽지 않아도 핵심 경계를 알 수 있도록 짧은 안내에서 상세 자료로 연결한다. 가입을 유도하기 위해 실제로 제공하지 않는 상품이나 지급 결과를 보여 주지 않는다. 현재 가능한 경험을 정확히 설명하면 가입 후 기대와 실제 동작이 어긋나는 일을 줄일 수 있다.

가입 이후의 첫 행동

가입을 마친 회원은 다음에 무엇을 할 수 있는지 안내받아야 한다. 채굴 시작이 필요한지, 활동의 기록과 보상이 어떻게 다른지, 상태를 어디서 확인하는지를 작은 단계로 설명한다. 화면의 성공 표시가 계정 연결인지 활동 기록인지 서로 구분하면 도움이 된다. 첫 행동을 마친 뒤 서버가 확인한 결과를 보여 주고, 조회가 안 되는 경우에는 잔액이 없다고 단정하는 대신 확인 경로를 안내한다.

성장 경로의 검토

향후 가입 경로를 측정할 때에는 단순 방문, 절차 시작, 인증 완료, 계정 생성, 첫 유효 활동을 구분하는 것이 좋다. 동일인의 반복 방문이나 실패한 인증을 새로운 회원 수로 더하지 않는다. 특정 홍보 경로가 많은 방문을 만들더라도 오해를 유발하거나 반복 문의를 늘린다면 내용을 개선해야 한다. 성장의 평가는 유입량과 함께 이해도, 자발적 참여, 정상적인 첫 경험을 살펴보는 방향이 바람직하다. 가입 안내의 효과를 검토할 때에는 추천 경로와 무관하게 본인의 선택과 확인이 유지되는지 확인하고, 기존 회원을 새로운 가입자로 중복 집계하지 않는다.

목차 ↑

087 / 100 · 글로벌 성장

반복 방문의 이유를 만들기

Meaningful Return Visits

회원이 다시 찾아오는 이유는 숫자를 매일 확인하는 것만으로 만들어지지 않는다. 활동을 이해하고 자신의 기록을 확인하며 새로운 안내와 개선을 경험하는 과정이 장기적인 이용의 기반이 된다.

강제 접속과 자발적 이용

GCV의 24시간 채굴 종료 이후에는 회원이 직접 새 구간을 시작해야 하지만 이것을 매일 정각에 접속해야 하는 의무로 설명하지 않는다. 종료와 재시작 사이에는 적립이 없다는 조건을 명확히 안내하고, 기존 기록은 유지한다. 회원이 생활 리듬에 맞추어 서비스를 이해하고 선택할 수 있도록 해야 한다. 빈번한 접속 자체를 유효 채굴이나 실제 활동의 증거로 바꾸지 않는 점도 중요하다.

기록을 읽는 경험

활동 기록은 회원이 무엇을 했고 어떤 결과를 확인했는지 돌아보는 자료다. 운동의 기기 완료 횟수와 서버 보상 횟수, 게임 점수와 GCV 적립을 구분하면 자신의 경험을 오해하지 않는다. 오늘의 기록이 날짜 기준에 따라 새로 시작하더라도 과거 원본을 임의로 없애거나 새로운 보상으로 다시 연결하지 않는다. 좋은 기록 화면은 더 큰 숫자를 보여 주는 것보다 각 숫자의 의미를 설명할 수 있어야 한다.

콘텐츠와 기능의 연결

새 공지는 기능을 홍보하는 것뿐 아니라 사용 중 생긴 질문을 해결할 수 있다. 예를 들어 추천 계산이나 주문 복구를 설명하는 짧은 글이 관련 화면으로 이어지면 회원은 필요한 순간에 도움을 받는다. 상품이 등록되지 않은 현재 쇼핑에서는 준비 상태와 이용 방법을 안내하고, 실제 제공할 내용이 확정되면 그 정보를 추가한다. 비어 있는 공간을 가짜 이벤트나 상품으로 채우는 방식은 반복 방문의 신뢰를 해칠 수 있다.

지속성의 측정

향후 재방문을 분석할 때에는 단순 접속과 의미 있는 이용을 구분한다. 같은 오류 때문에 여러 번 돌아온 행동을 만족도 높은 재방문으로 해석하지 않는다. 회원이 어느 지점에서 도움을 찾고 어떤 상태에서 이용을 멈추는지 살펴볼 수 있다. 개인의 과도한 사용을 유도하는 대신 원하는 활동과 확인을 편리하게 마칠 수 있는지를 개선한다. 지속성은 무조건 오래 머무는 시간보다 안정적으로 목적을 달성하는 경험과 연결된다. 이용을 마친 회원에게는 무엇이 저장되었고 무엇이 확인 중인지 알 수 있는 상태를 남겨, 다음 방문 때 처음부터 같은 행동을 반복하지 않도록 돕는다.

목차 ↑

088 / 100 · 글로벌 성장

파트너십을 준비하는 기준

Partnership Readiness

글로벌 생태계는 이름을 많이 나열한다고 만들어지지 않는다. 실제로 함께 제공할 가치와 역할, 데이터와 거래의 경계를 확인할 수 있어야 의미 있는 협력이 된다. 현재 확인되지 않은 파트너나 계약은 성과로 발표하지 않는다.

협력의 목적

협력을 검토할 때에는 회원에게 어떤 도움이 생기는지 먼저 정의한다. 상품 제공, 콘텐츠 제작, 지역 안내, 기술 연동은 서로 다른 목적이며 요구되는 준비도 다르다. 로고를 함께 게시하는 것만으로 서비스가 연결되었다고 설명하지 않는다. 제안 단계와 합의 단계, 개발 연동, 실제 운영을 구분해 기록하면 외부 관계를 과장하지 않으면서도 준비를 진행할 수 있다.

역할과 책임의 확인

누가 상품이나 콘텐츠를 제공하고 누가 문의에 답하는지, 문제가 생겼을 때 어떤 기록으로 확인하는지 정해야 한다. 회원에게 보이는 브랜드와 실제 책임자가 다르다면 그 관계를 설명할 필요가 있다. 아직 확정되지 않은 조건은 협력 제안서의 검토 항목으로 남긴다. 거래 조건이나 수익 배분을 백서에서 임의로 만들지 않으며 기존 GCV 보상과 Pi 수익 정책에 미치는 영향도 별도로 검토한다.

데이터와 권한의 경계

외부 연동이 필요하더라도 회원의 모든 정보를 공유할 이유는 없다. 어떤 목적에 어떤 정보가 필요한지 정하고 접근 범위를 최소화하는 설계를 검토한다. 상대 조직의 이름이 익숙하다는 이유로 운영 권한이나 자산 이동을 허용하지 않는다. 기술 연동을 시험할 때에는 합성 자료와 격리 환경을 우선 활용하고, 실제 환경으로 넘어갈 때 대상과 조건을 다시 확인한다.

성과를 설명하는 방식

협력 관련 소식은 확인된 단계에 맞는 동사를 사용한다. 논의했다, 제안했다, 검토 중이다, 합의했다, 실제 제공을 시작했다는 말은 다른 상태다. 가능한 경우 관련 범위와 확인 시점을 함께 제시한다. 외부 기관의 제품을 사용한다는 사실을 공식 후원이나 인증으로 표현하지 않는다. 신뢰할 수 있는 협력은 발표의 크기보다 회원에게 제공되는 경험과 문제가 생겼을 때의 책임 구조에서 확인된다. 협력 종료나 범위 변경이 생길 경우에도 이미 발생한 주문과 회원 기록을 어떻게 조회할지 검토해야 하며, 새 발표로 과거의 책임 관계를 지우지 않는다.

목차 ↑

089 / 100 · 글로벌 성장

수익과 회원 가치를 함께 보기

Value and Sustainability

서비스의 지속 가능성을 위해 수익 모델을 검토할 수 있지만 회원 경험과 자산의 구분을 잃어서는 안 된다. GCV 내부 보상, Pi 수익, 향후 쇼핑 거래는 서로 다른 기록과 운영 조건을 가진다.

활동 보상과 수익의 구분

회원과 크리에이터의 활동 보상은 GCV 기준으로 설명한다. 광고·수수료 등 Pi 수익의 정책과 같은 숫자로 합산하지 않는다. Pi 수익은 본사·코어팀 최종 90%, 연합회 실지급 10%라는 기준을 유지하되 실제 입금이나 분배 완료 여부는 별도로 확인한다. 수익 정책을 적었다는 사실만으로 광고사가 어떤 자산을 지급하는지 또는 모든 운영 비용을 충당했는지 확정할 수는 없다.

광고 경험의 품질

광고는 제공 가능 여부와 기기 환경, 외부 플랫폼의 조건에 영향을 받는다. 광고가 없거나 확인이 실패했을 때 활동 기록을 어떻게 보존하는지 설명해야 한다. 광고를 닫았다는 이벤트만으로 서버 보상이 확정되었다고 표시하지 않는다. 회원에게 과도한 반복 시청을 유도하기보다 기존 한도와 요청의 결과를 정확히 확인하는 경험이 중요하다. 실제 광고 노출과 수익화 승인은 기술 연결과 별도의 증거다.

쇼핑이 추가하는 가치

향후 쇼핑은 회원이 실제로 필요한 상품이나 서비스를 탐색하고 Pi로 결제하는 활용을 지향한다. 현재는 상품 등록 준비 중이므로 거래량이나 수수료 수입을 사업 실적으로 계산하지 않는다. 일반 판매가 시작되면 결제 전환뿐 아니라 제공 품질, 취소와 문의 비용도 함께 검토할 필요가 있다. 매출만 보고 운영 책임을 과소평가하면 회원에게 약속한 경험을 유지하기 어려워질 수 있다.

지속 가능성의 평가

성장 판단에는 실제 확인한 수입과 지출, 제공 가능한 운영 역량, 회원이 얻는 가치를 함께 살펴야 한다. 내부 적립 수량이 늘었다는 이유로 회사 수익이 늘었다고 해석하지 않는다. 토큰 공급 배정도 사업 현금흐름과 다른 개념이다. 경제 모델의 변경을 제안할 때에는 자산별 기준과 기존 기록에 미치는 영향을 검토하고, 미확정 수익을 전제로 회원에게 이익을 보장하는 표현을 사용하지 않는다. 향후 사업 검토에서는 수익의 발생 시점과 실제 수령 시점을 구분하고, 예상 수입을 이미 확보한 운영 자금이나 회원에게 지급한 보상으로 표시하지 않는다.

목차 ↑

090 / 100 · 글로벌 성장

단계적으로 넓히는 서비스

Evidence Led Expansion

GCV의 1차 300만 회원 목표는 큰 방향을 제시한다. 이 목표를 실제 운영으로 연결하려면 기능의 완성도와 사용량, 복구 능력, 운영 책임을 단계적으로 확인하며 범위를 넓혀야 한다.

확대의 출발점

현재 제공하는 핵심 기능의 정확한 상태를 파악하는 것이 첫 단계다. 정상적인 활동과 기록 조회가 가능한지, 오류 뒤 원래 요청을 복구할 수 있는지, 안내 문구가 최신 정책과 맞는지 확인한다. 새로운 화면을 추가하기 전에 기존 사용자가 겪는 반복 문제를 해결하는 것도 성장 준비다. 완료한 설치나 정상 검사를 반복하는 대신 재현 가능한 결함과 확정된 계약의 미완성 연결을 우선한다.

단계별로 필요한 증거

사용 범위를 넓힐 때에는 어떤 조건이 새로 생기는지 적는다. 회원 수 증가라면 동시 요청과 저장량, 지역 확대라면 언어와 문의 운영, 상품 확대라면 제공과 취소 절차가 달라질 수 있다. 하나의 검사 결과로 모든 확장을 승인하지 않는다. 각 단계의 검증 조건과 실제 관측 결과를 기록하고 다음 단계에서 추가로 확인할 항목을 지정하는 방식이 유용하다.

확대와 보존의 균형

새 구조를 도입하더라도 기존 회원의 기록과 추천 관계, 원래 요청을 보존해야 한다. 빠른 성장을 이유로 불명확한 데이터를 새 원장으로 복사하거나 과거 보상을 추정해서 만들어서는 안 된다. 변경 전후를 비교할 수 있는 기준과 필요한 경우의 복구 절차를 마련한다. 이전 버전의 화면이나 문서를 사용하던 회원이 새 안내를 이해할 수 있도록 개정 내용과 연결 경로도 함께 검토한다.

목표를 갱신하는 판단

실제 관측이 처음의 가정과 다르면 일정이나 범위를 조정할 수 있어야 한다. 계획을 바꾼 사실을 실패로 감추기보다 어떤 근거로 우선순위를 바꾸었는지 설명하는 것이 장기적인 신뢰에 도움이 된다. 세계적 서비스라는 목표는 유지하더라도 그 과정은 단계별 증거에 따라 발전한다. 검증된 회원 수나 처리량이 없는 상태에서 목표 숫자를 현재 성능으로 발표하지 않는 태도가 이 과정의 기본이다. 확대 단계별로 미리 확인할 질문을 남기면 실제 수요가 늘었을 때 무엇부터 점검할지 결정하기 쉽다. 근거가 부족한 목표는 숫자를 부풀리기보다 필요한 측정 조건을 보완한다. 단계의 이름보다 그 단계에서 확보한 근거가 실제 확대 판단을 설명해야 한다.

목차 ↑

091 / 100 · 평가와 위험

기술 위험을 기능별로 살피기

Technical Risk Review

기술 위험을 단순히 안전 또는 위험이라는 말로 나누면 구체적인 개선을 선택하기 어렵다. 어떤 기능이 어떤 상황에서 실패할 수 있으며, 그 실패가 회원의 기록과 행동에 어떤 영향을 주는지 나누어 살펴야 한다.

표시 오류와 처리 오류

문구가 잘못 번역되는 문제와 서버가 중복 적립하는 문제는 영향이 다르다. 표시 오류도 사용자의 잘못된 행동으로 이어질 수 있으므로 중요하지만, 원장 처리 오류는 별도의 검증과 복구가 필요하다. 기능별로 입력, 처리, 저장, 표시의 경계를 그려 보면 어디에서 문제가 생기는지 좁힐 수 있다. 수정할 때에는 실패를 발생시킨 가장 작은 조건을 재현하고 관련 없는 영역의 변경을 줄인다.

환경 차이

데스크톱 브라우저와 휴대폰 Pi Browser는 지원 기능과 화면 크기, 백그라운드 동작이 다를 수 있다. 한 환경에서 정상이라는 결과를 모든 환경에 적용하지 않는다. 오래된 브라우저에서 지원하지 않는 함수가 호출되면 화면 전체가 중단될 수 있으므로 필요한 기능의 호환성을 확인한다. 실제 기기 검증이 아직 없다면 합성 환경의 결과와 구분하고, 확인할 화면과 행동을 구체적으로 지정한다.

실패의 영향 제한

선택적인 효과음이나 광고 제공 실패가 핵심 기록을 지우거나 이미 확인된 상태를 바꾸지 않도록 설계한다. 외부 기능이 응답하지 않을 때에는 제한된 대기와 명확한 안내가 필요하다. 그러나 오류를 무조건 무시하여 성공처럼 처리하는 것도 적절하지 않다. 핵심 동작과 부가 동작을 구분하고 각 기능의 실패가 어디까지 전파될 수 있는지 검토하면 사용 경험과 데이터 보존을 함께 개선할 수 있다.

남은 위험의 기록

수정 이후에도 모든 위험이 없어졌다고 말하지 않는다. 검증한 조건과 미확인 환경, 필요한 후속 조치를 남기면 다음 개발의 우선순위를 정할 수 있다. 위험 목록은 막연한 우려를 길게 나열하는 자료보다 재현 조건과 대응 방법을 연결하는 자료가 되어야 한다. 발견된 문제가 실제 운영에서 발생했는지, 합성 검증에서만 확인됐는지도 구분하여 제품 상태를 정확하게 설명한다. 같은 기술 위험도 개인 정보 노출, 잘못된 기록, 단순한 표시 불편처럼 영향이 달라질 수 있으므로 대응의 우선순위를 기능 이름만으로 정하지 않는다.

목차 ↑

092 / 100 · 평가와 위험

외부 플랫폼에 의존하는 경계

External Dependencies

GCV는 Pi Browser와 SDK, 광고 제공 환경, 공개 배포 기반 등 외부 요소와 연결된다. 외부 서비스의 지원 여부와 상태는 GCV 코드만으로 결정할 수 없으므로 연결의 경계를 분명히 해야 한다.

지원과 승인

SDK 호출이 가능한 환경이라는 사실과 특정 앱의 사용 범위가 승인되었다는 사실은 다르다. 기술 문서를 읽고 기능을 연결해도 실제 운영 조건은 별도로 확인해야 한다. Pi 네트워크 자체의 상태와 GCV 토큰이나 앱의 상태도 혼동하지 않는다. 공식 플랫폼의 로고나 이름을 사용한다는 이유로 GCV에 대한 후원이나 보증을 주장하지 않으며 확인된 관계와 기능 범위만 설명한다.

광고가 없는 상황

광고는 회원이 버튼을 눌렀다고 항상 제공되는 것이 아니다. 재고, 지원 환경, 준비 상태, 연결 문제에 따라 제공되지 않을 수 있다. 회원은 광고 미제공이 자신의 활동 기록에 어떤 영향을 주는지 알아야 한다. 광고 관련 이벤트와 서버의 보상 확인을 분리하면 잘못된 성공 표시를 줄일 수 있다. 실제 광고 수익이 들어왔는지와 그 수익이 분배됐는지는 또 다른 원천을 통해 확인해야 한다.

결제 연결의 변화

외부 결제 환경의 정책이나 기술 계약이 바뀌면 기존 연결이 그대로 유효한지 확인해야 한다. 문서에 적힌 과거 설명만으로 최신 동작을 보장하지 않는다. 실제 상품을 판매하려는 단계에서는 서버 승인 흐름과 사용자 승인 화면, 결과 확인 경로를 해당 조건에 맞추어 검토한다. 바뀐 외부 조건을 피하려고 비공식 경로로 권한이나 검증을 우회하지 않는다.

대기와 대체 안내

외부 요소를 사용할 수 없을 때에는 서비스 전체를 무조건 정상이라고 표시하기보다 현재 가능한 범위를 안내한다. 공개 문서 열기나 기존 기록 조회처럼 독립적인 기능을 유지할 수 있는지도 검토한다. 다만 대체 경로가 원래 요청의 의미를 바꾸거나 새로운 결제를 만드는 방식이어서는 안 된다. 외부 상태가 회복된 뒤에도 원래 결과를 확인하고 필요한 범위만 재개하는 것이 사용자에게 예측 가능한 경험을 제공한다. 외부 문서가 바뀌면 적용되는 버전과 현재 구현을 비교하고, 관련 없는 기능까지 한꺼번에 다시 설정하는 대신 영향이 있는 경로를 먼저 검토한다. 재확인한 공식 자료의 날짜와 영향을 받는 연결을 함께 남긴다.

목차 ↑

093 / 100 · 평가와 위험

경제 설명에서 생기는 오해

Economic Interpretation Risks

큰 수량과 여러 자산이 등장하는 서비스에서는 단위와 상태를 빠뜨리는 것만으로도 의미가 달라질 수 있다. 경제 설명의 위험을 줄이려면 어떤 원장과 어떤 단계의 숫자인지 끝까지 유지해야 한다.

설계량과 발행량

전체 설계 공급량 314,159,000,000 GCV와 1차 발행량 31,415,900,000 GCV는 서로 다른 수량이다. 두 숫자를 바꾸어 쓰거나 합쳐 새로운 공급량을 만들지 않는다. 전체 설계 배분표는 현재 모든 지갑에 배분된 결과를 뜻하지 않는다. 1차 수량과 관련된 Pi Testnet 거래 증거는 해당 네트워크와 사건의 증거로 설명하며 Mainnet 발행이나 회원별 지급 완료로 확대하지 않는다.

내부 기록과 외부 자산

앱에서 보여 주는 내부 적립은 서버가 관리하는 활동 기록이다. 외부 체인에서 확인되는 토큰과 언제나 같은 상태라고 가정할 수 없다. 미정산, 확정, 신청, 예약, 서명, 제출, 확인이라는 단계가 있다면 각각 구분해서 읽어야 한다. 특정 단계가 끝났다는 이유로 다음 단계가 자동 완료됐다고 설명하지 않는다. 회원이 숫자를 비교할 때에는 원천과 기준시각을 먼저 확인하도록 돕는다.

교환 가치의 추정

GCV 수량을 Pi나 현금 수익으로 바꾸어 계산하려면 실제로 확인된 거래 조건이 필요하다. 백서의 활동 예시나 정책 비율은 시장 가격이나 고정 환율을 제공하지 않는다. Pi 수익 배분 90 대 10과 GCV 공급 배분의 비율도 같은 계산표로 합치지 않는다. 과거 USDT 기록을 Pi 금액으로 이름만 바꾸거나, 서로 다른 자산의 잔액을 합쳐 회원에게 새로운 수익으로 표시하지 않는다.

예시를 읽는 기준

계산 예시는 정해진 입력에서 규칙이 어떻게 작동하는지 설명하기 위한 자료다. 실제 회원이 같은 시간 동안 활동했고 해당 보상을 받았다는 증거가 아니다. 기본률에 반감이 이미 반영되었는지, 오늘 유효한 추천 수가 무엇인지, 일일 한도와 서버 확인 조건이 무엇인지 함께 읽어야 한다. 수량을 정확하게 적는 것뿐 아니라 예시가 사용한 가정을 공개하는 것이 경제 설명의 신뢰를 높인다. 배분표를 인용하는 공지에서는 표의 기준 수량을 함께 적고, 전체 설계 배분 비율을 1차 지갑 지급이 이미 끝난 비율처럼 읽히지 않도록 한다. 같은 단위의 숫자라도 기록의 목적과 적용 범위를 먼저 비교한다.

목차 ↑

094 / 100 · 평가와 위험

오용과 허위 기록을 줄이기

Abuse Resistant Participation

참여를 쉽게 만드는 것과 검증되지 않은 기록을 인정하는 것은 다르다. GCV는 회원의 정상 이용을 돕되 소유자, 원래 요청, 유효한 사건과 한도의 경계를 유지하는 방향으로 기능을 개발해야 한다.

확인되지 않은 활동

가입이나 로그인은 계정 이용의 사건이며 그 자체로 유효 채굴 구간을 증명하지 않는다. 오늘 채굴 추천회원은 서버가 확인한 유효 구간이 해당 UTC-5 날짜와 겹치는 기준으로 판단한다. 화면에서 숫자를 늘리거나 과거 활동을 주장하는 것만으로 새로운 보상 원천을 만들지 않는다. 이미 존재하는 기록은 보존하되 확인되지 않은 과거 시간과 잔액을 추정해 생성하는 방식은 피한다.

정상 이용자를 보호하기

오용 방지 장치는 정상적인 재시도나 기기 변경을 무조건 부정행위로 취급해서는 안 된다. 불명확한 결과는 원래 요청을 복구할 수 있게 하고, 확정된 거절은 이유를 이해할 수 있는 문구로 설명한다. 오류에 대한 문의를 할 때 필요한 정보와 개인 비밀 정보를 구분한다. 회원이 자신에게 어떤 상태가 적용됐는지 확인할 수 있으면 단순한 금지보다 혼란을 줄일 수 있다.

검증과 운영 판단

입력 형식과 중복 여부를 자동으로 검사하는 것과 복잡한 상황을 운영자가 판단하는 것은 다른 역할이다. 자동 검사에서 발견한 신호를 사실로 단정하기 전에 필요한 근거를 확인해야 한다. 운영 판단이 데이터에 영향을 줄 경우에는 대상과 이유, 승인 범위를 남긴다. 특정 위험을 막기 위해 관련 없는 회원의 기록을 일괄 삭제하거나 기존 잔액을 임의로 바꾸는 방식은 사용하지 않는다. 거절된 요청을 안내할 때에는 회원이 바로잡을 수 있는 입력 오류와 이미 확정된 제한을 구분하여, 불필요한 반복 시도를 유발하지 않도록 표현한다.

목차 ↑

095 / 100 · 평가와 위험

준비 상태를 평가하는 표준

Readiness Evidence

개발 중, 검사 완료, 배포 완료, 실제 사용 확인은 서로 다른 준비 단계다. 현재 상태를 정확히 설명하려면 기능별로 어떤 증거가 있고 어떤 입력이 더 필요한지 구분하는 공통 기준이 필요하다.

기능 단위로 평가하기

앱 전체를 하나의 완료 비율로 표현하면 중요한 차이가 사라질 수 있다. 공개 문서가 배포되었어도 일반 상품이 등록된 것은 아니며, 활동 화면이 정상이어도 실제 외부 지급이 검증된 것은 아니다. 기능별로 구현, 집중 검사, 통합 검사, 게시, 실제 사용 확인을 구분해 기록한다. 단계가 많다는 이유로 모두를 완료해야만 작은 개선을 배포할 수 있는 것은 아니지만 배포 범위의 설명은 정확해야 한다.

증거의 최신성

오래된 검증 기록은 참고 자료가 될 수 있지만 현재 소스와 같은지 확인해야 한다. 코드나 설정, 실행 환경이 바뀌었다면 어떤 근거가 여전히 유효한지 검토한다. 공개 주소에 응답이 있다는 사실만으로 최신 파일이 배포됐다고 단정하지 않는다. 반대로 변경이 없는 정상 검사를 매번 처음부터 반복할 필요도 없다. 재사용한 증거와 새로 확인한 증거를 구분하면 상태 판단의 비용과 정확성을 함께 관리할 수 있다.

실제 입력이 필요한 항목

회원의 Pi Browser 승인이나 지갑 서명처럼 사용자가 직접 해야 하는 행동은 합성 검사로 대신할 수 없다. 필요한 조건을 준비하고 정확히 무엇을 확인해야 하는지 안내한 뒤 실제 결과를 구분해서 기록한다. 사용자가 화면이 정상이라고 확인한 결과는 그 화면의 관측으로 남긴다. 그 한 번의 확인을 모든 기능과 네트워크의 완료로 확대하지 않는 것이 이후 보고의 신뢰를 유지한다.

공개 설명의 개선

준비 표시는 지나치게 기술적인 용어만으로 구성하지 않는다. 회원에게는 지금 사용할 수 있는 기능과 직접 해야 할 행동, 확인 중인 조건을 간결하게 알려 주는 것이 중요하다. 내부 기록에는 정확한 소스와 검사 근거를 남기되 일반 이용 흐름에 불필요한 세부 정보를 쏟아 넣지 않는다. 같은 상태를 제품 화면과 공지, 백서에서 일관되게 설명하는지가 최종적인 점검 항목이다. 준비 상태를 갱신할 때에는 이전 기록을 삭제해 새 상태만 남기기보다 무엇이 새로 확인되었는지 적어, 같은 항목을 다음 검토에서 중복 실행하지 않게 한다.

목차 ↑

096 / 100 · 평가와 위험

다음 개발을 선택하는 원칙

Choosing the Next Work

백서가 장기 방향을 설명하더라도 다음 작업은 실제로 확인한 문제와 준비 조건에서 선택해야 한다. 재현 가능한 결함과 확정된 계약의 미완성 연결을 우선하면 개발 결과를 검증하고 안전하게 배포하기 쉽다.

문제가 있는 경로부터

현재 사용자가 겪는 오류와 연결되지 않은 흐름을 확인한다. 같은 정상 검사를 반복하거나 이미 배포된 기능을 다시 만드는 작업은 피한다. 재현한 문제에는 입력과 이벤트, 기대한 결과, 실제 결과를 기록한다. 그러면 필요한 변경 범위를 좁히고 관련 회귀를 선택할 수 있다. 단순히 오래된 작업표에 남아 있다는 이유로 현재도 미완료라고 가정하지 않고 최신 소스와 실행 증거를 확인한다.

정책이 없는 기능

상품 가격이나 제공 조건, 새로운 보상 규칙이 정해지지 않았다면 개발자가 임의로 채워 기능을 열지 않는다. 대신 화면 구조와 검토 질문, 안전한 준비 상태처럼 독립적으로 할 수 있는 일을 진행한다. 현재 쇼핑의 상품 등록 준비 중 표시는 이런 판단의 예다. 확정된 입력이 도착하면 어떤 파일과 검증이 필요한지 정리해 두면 불필요한 반복 없이 후속 작업을 이어 갈 수 있다.

독립 묶음의 완료

하나의 변경 묶음은 사용자가 관측하는 문제를 해결하고 관련 검증과 배포 확인까지 연결할 수 있는 크기로 정한다. 너무 작은 코드 조각만 만들고 연결을 남겨 두면 실제 경험은 개선되지 않을 수 있다. 반대로 여러 운영 영역을 한꺼번에 바꾸면 실패의 원인을 찾기 어렵다. 독립적인 작업은 병행하되 통합 시점에는 같은 소스와 같은 계약을 기준으로 결과를 확인한다.

로드맵의 갱신

다음 단계는 고정된 출시일 약속보다 확인할 조건과 필요한 증거로 표현한다. 일반 상품 등록, Pi 결제의 정확한 운영 범위, 제공과 문의 절차, 규모 확장 검증 등은 각각 다른 준비가 필요하다. 조건이 충족되면 진행 상태를 업데이트하고 미확정 사항을 새로운 완료 항목으로 바꾸지 않는다. GCV의 장기 목표는 계속 유지하면서 실제 개발 순서는 사용자의 결정과 관측된 문제에 따라 조정한다. 다음 작업의 완료 조건에는 사용자가 실제로 접근할 수 있는 연결을 포함하고, 독립적인 준비가 끝났더라도 필요한 실제 입력이 없으면 그 경계를 명확히 남긴다.

목차 ↑

097 / 100 · 부록

핵심 용어를 구분해 읽기

Working Glossary

같은 숫자가 여러 화면에 나타나더라도 그 숫자가 속한 상태와 원천은 다를 수 있다. 이 용어집은 특히 혼동하기 쉬운 기록, 자산, 검증의 의미를 구분하여 본문을 다시 찾아 읽도록 돕는다.

기록의 상태

원천은 기록을 만들게 된 확인 가능한 사건이다. 적립은 승인된 규칙에 따라 내부 원장에 반영하는 과정이며, 정산은 해당 기록을 정해진 기준으로 계산하고 확정하는 과정이다. 미정산과 확정 잔액을 같은 값으로 취급하지 않는다. 신청이나 예약이 있다는 사실도 외부 자산이 전달됐다는 뜻은 아니다. 각 화면에서는 어떤 상태를 보여 주는지 함께 읽어야 한다.

자산과 설계

GCV 전체 설계 공급량은 장기 배분을 설명하는 기준이고, 1차 발행량은 특정 차수의 수량이다. 내부 채굴 풀은 보상 계산의 기준이며 전체 설계 공급량에 추가하는 새로운 수량이 아니다. Pi 수익은 별도 자산의 수입과 배분을 뜻한다. Testnet의 공개 거래와 Mainnet의 거래는 네트워크가 다르므로 같은 완료 표시로 묶지 않는다.

활동과 시간

유효 채굴 구간은 서버가 확인한 시작과 종료 사이의 적용 가능한 시간이다. 오늘 채굴 추천회원은 그 유효 구간이 해당 UTC-5 회계일과 겹치는 추천회원이다. 가입이나 로그인만으로 같은 의미가 되지는 않는다. 기기 활동 기록은 브라우저에서 확인한 경험을 나타내며 서버의 보상 횟수나 지갑 지급을 대신하지 않는다.

검증과 결과

집중 검사는 특정 변경과 관련된 계약을 확인하고 통합 검사는 연결된 기능의 동작을 살핀다. 공개 배포 확인은 게시한 파일과 목적지를 확인하는 과정이며 실제 회원의 동의나 결제를 대신하지 않는다. 같은 요청 복구는 불명확한 원래 결과를 찾는 행동으로, 새로운 활동이나 구매를 자동으로 만드는 재시작과 구분한다.

용어	읽을 때 확인할 점
전체 설계 공급량	314,159,000,000 GCV의 배분 설계
1차 발행량	31,415,900,000 GCV; 네트워크와 증거를 함께 확인
첫 내부 풀	채굴·회원 배정 안에 포함된 31,415,900,000 GCV
오늘 채굴 추천	서버 유효 구간과 UTC-5 날짜의 겹침
견적	상품·옵션·수량·Pi 금액·네트워크의 확인 정보
결제 확인	서버가 원래 주문과 결제 결과를 대조한 상태
상품 제공 완료	결제와 별개로 약속된 제공을 확인한 상태
준비 중	필요한 조건이 아직 충족되지 않은 상태

목차 ↑

098 / 100 · 부록

정책을 이해하는 계산 예시

Worked Policy Examples

아래 계산은 입력과 규칙의 관계를 설명하기 위한 예시다. 특정 회원의 활동이나 지급 실적이 아니다. 실제 계산에서는 유효 구간, 적용 사건, 서버가 확인한 입력과 해당 시점의 정책을 함께 사용한다.

채굴률의 입력

b는 반감이 이미 반영된 현재 기본률이다. B와 G는 각각 승인된 활성 부스트와 선물의 적용 수이며 범위는 0부터 5까지다. N은 오늘 유효한 추천회원 수다. 식은 b × (1 + 0.6B + 0.4G + 0.2 × min(N, 314))이다. 추천을 저장한 총수와 오늘 계산에 쓰는 N을 구분한다. b에 반감이 들어 있으므로 추천 증가분에 반감을 한 번 더 적용하지 않는다.

구간 계산의 전제

표의 수치는 한 시간당 적용률을 보여 준다. 이를 시간에 곱하는 예시는 해당 시간 동안 본인의 채굴이 유효하고 모든 입력이 그대로 유지된 경우에만 단순하게 설명할 수 있다. 실제 구간 도중 효과나 정책이 바뀌면 사건 시점을 기준으로 나누어 계산해야 한다. 채굴 종료부터 명시적 재시작 전까지의 빈 시간에 표의 수치를 계속 곱하지 않는다.

첫 풀과 반감 기준

첫 내부 풀 31,415,900,000 GCV의 70%는 21,991,130,000 GCV다. 이 기준에 따른 첫 반감은 보상률을 50% 줄이는 규칙이다. 전체 설계 공급량을 절반으로 바꾸거나 이미 기록된 수량을 임의로 줄이는 계산이 아니다. 첫 풀은 50%인 채굴·회원 배정 157,079,500,000 GCV 안에 포함되므로 남은 배정 계산은 125,663,600,000 GCV다.

서로 다른 한도의 예

N이 314보다 크더라도 채굴률 식에는 314를 넣는다. 이것은 신규가입 QR 발급자 보상의 총 314회 제한과 별개의 규칙이다. 게임 전체 하루 5회, 운동 하루 5회, 회원 QR 스캐너 하루 2회도 각각 해당 기능의 서버 조건과 함께 적용한다. 숫자가 우연히 같다는 이유로 다른 활동의 제한이나 원천을 합치지 않는다.

입력	계산한 시간당 GCV
b=0.5, B=0, G=0, N=0	0.5 × 1 = 0.5
b=0.5, B=0, G=0, N=5	0.5 × (1 + 1) = 1.0
b=0.5, B=2, G=1, N=5	0.5 × (1 + 1.2 + 0.4 + 1) = 1.8
b=0.5, B=5, G=5, N=314 이상	0.5 × (1 + 3 + 2 + 62.8) = 34.4
b=0.25, B=0, G=0, N=1	0.25 × 1.2 = 0.30; 추천 증가분 0.05

목차 ↑

099 / 100 · 부록

출처와 정책 버전을 읽는 방법

Sources and Policy Versions

본문의 짧은 참조 식별자는 서로 다른 종류의 근거를 구분하기 위한 표시다. 사용자 결정, 제품 계약, 공식 외부 문서, 공개 거래 기록, 향후 제안은 같은 권위나 같은 최신성을 갖는 자료가 아니다.

제품 결정의 우선순위

최신 직접 결정이 이전 설명을 대체하면 최신 결정을 따른다. PROJECT_CONTEXT·정책 이력·준비 상태 원본은 비공개 내부 기록이며, 공개 링크는 검토한 정책의 백서 요약으로 연결된다. 본 판의 수량과 쇼핑 범위는 2026-10-09 사용자 결정이 기준이다. 오래된 미확정 문장을 현재 실행 결과로 읽지 않는다.

공식 외부 자료의 범위

PI_SDK와 PI_PAYMENTS는 Pi 공식 개발 자료의 인증·결제 연결을 이해하기 위한 참조다. 공식 자료에 기능이 설명되어 있다는 사실만으로 GCV의 일반 판매나 해당 계정의 운영 승인이 입증되지는 않는다. 외부 자료는 변경될 수 있으므로 실제 연동이나 개정 시점에 원문과 적용 범위를 다시 확인한다. 제3자의 홍보 문구를 공식 승인 근거로 사용하지 않는다.

체인 증거의 해석

CHAIN_RECEIPT는 2026-10-05 11:55:25 UTC, ledger 27008124의 Pi Testnet 거래 기록을 가리킨다. 전체 거래 식별자는 본 판의 발행 관련 기록과 연결하여 확인한다. 이 근거는 해당 네트워크의 특정 사건을 설명하며 회원별 분배나 Mainnet 발행, 거래소 상장 상태까지 증명하지 않는다. 수량과 거래 결과를 설명할 때에는 시각과 네트워크를 함께 유지한다.

제안과 사실의 구분

ROADMAP_PROPOSAL은 아직 실행 실적으로 확인되지 않은 설계와 개선 방향을 나타낸다. 다음 단계의 기준을 이해하는 데 사용할 수 있지만 현재 운영 국가나 계약 상대, 확정 출시일을 만들어 내는 근거는 아니다. 출처를 읽을 때에는 문서의 발행일뿐 아니라 무엇을 증명하는지 확인한다. 이 구분을 유지해야 장기 목표와 현재의 사실을 함께 설명할 수 있다.

참조 식별자	본문에서의 용도
PROJECT_CONTEXT	현재 결정·역사 우선순위·검증 범위
MINING24H / REFERRAL24H	24시간 채굴과 신규 추천 유예의 승인 기준
ECONOMIC_POLICY / QR_POLICY	배분·률·활동·QR 수량과 적용 경계
PI_SDK / PI_PAYMENTS	Pi 공식 연결·결제 절차의 검토 자료
CHAIN_RECEIPT	Pi Testnet의 날짜가 명시된 발행 사건
USER_20261009	1차 수량 유지·Pi 쇼핑·상품 등록 준비 결정
ROADMAP_PROPOSAL	향후 기술·운영·성장 제안

목차 ↑

100 / 100 · 부록

이 판의 변경과 다음 검토

Edition Record and Next Review

이 판은 GCV의 세계적 성장 비전과 제품·경제·운영 구조를 한국어 A4 100쪽으로 정리한다. 영어 짧은 제목과 웹 요약은 탐색을 돕는 보조 자료이며 본문 전체의 다국어 번역 완료를 뜻하지 않는다.

이번 판에서 정리한 내용

공개 설명의 범위를 비전과 회원 경험, 참여 역할, 채굴·활동·추천, 발행·경제, 쇼핑, 공지, 기술, 운영, 성장과 위험으로 나누었다. 상품 등록 준비 중인 현재 상태와 Pi Browser의 직접 승인 흐름을 함께 설명하고, 결제 확인과 상품 제공을 분리했다. 앱과 홈페이지에서 같은 정책을 읽을 수 있도록 수량과 용어의 기준을 제시했다. 새 문서가 실제 자산 이동이나 운영 설정을 실행하는 것은 아니다.

유지한 핵심 수량과 규칙

1차 발행량은 31,415,900,000 GCV, 전체 설계 공급량은 314,159,000,000 GCV를 유지한다. 전체 배분은 코어 20%, 개발 5%, 유동성 15%, 연합회 5%, 채굴·회원 50%, 마케팅 5%다. 채굴 시작 후 24시간 종료와 직접 재시작, 오늘 유효 추천의 최대 314명 계산, Pi 수익과 GCV 보상의 분리를 그대로 설명한다. 기존 기록과 과거 QR의 조건을 새 문서 때문에 다시 쓰지 않는다.

다음 검토를 시작할 조건

실제 상품 등록 내용이 확정되거나 Pi 결제의 운영 범위가 바뀌면 쇼핑 관련 장을 검토한다. 새로운 보상 정책이 직접 승인되거나 적용 방식이 변경되면 계산 예시와 관련 안내를 함께 확인한다. 실제 회원 규모나 성능 검증 결과가 추가되면 목표와 실적의 구분을 유지하면서 근거를 보완한다. 확인되지 않은 항목을 채우기 위해 예정일이나 제휴 실적을 임의로 추가하지 않는다.

개정과 독자 의견

개정 시에는 바뀐 장과 이유, 적용 대상, 기존 안내와의 관계를 기록한다. 독자는 잘못된 설명이나 이해하기 어려운 부분을 문의할 수 있으며, 개인키나 비밀번호 없이 문서의 페이지와 문장을 알려 주면 된다. 공개 배포 여부와 파일의 정확한 판은 별도 게시 기록에서 확인한다. 이 문서의 마지막 페이지는 사업의 끝이 아니라 다음 검토가 같은 근거에서 이어지도록 하는 출발점이다.

판 기준	기록
편집 기준일	2026-10-09
형식	한국어 A4 100쪽; 영문 제목·웹 요약 별도
쇼핑 상태	상품 등록 준비 중; 일반 판매 완료로 표현하지 않음
수량 표시	1차 31,415,900,000 / 전체 설계 314,159,000,000 GCV
후속 검토	정책 결정·상품 등록·실제 검증 증거가 추가될 때

목차 ↑