제4장: Phase 1 - 데이터 형식과 토큰 표준

기초를 올바르게 구축하기

모든 위대한 건축물은 견고한 기초에서 시작됩니다. WIA 블록체인 금융 표준의 Phase 1은 모든 것의 토대가 되는 데이터 형식, 토큰 표준, 스마트 계약 구조를 정의합니다. 이 장에서는 이론에서 실천으로 나아가 실제 코드를 작성하고 배포합니다.

4.1 블록체인 트랜잭션 스키마

모든 블록체인 작업은 표준화된 트랜잭션 형식으로 시작됩니다. WIA는 EVM 트랜잭션을 확장하여 크로스체인 호환성과 향상된 메타데이터를 추가합니다.

표준 트랜잭션 구조

WIA 트랜잭션은 기본 EVM 트랜잭션 필드를 포함하고 추가 정보를 확장합니다:

WIA 확장 필드

WIA는 향상된 기능을 위한 추가 메타데이터를 정의합니다:

// WIA 트랜잭션 메타데이터 구조 — TypeScript
interface WIATransactionMetadata {
    protocol: string;          // 프로토콜 식별자 (예: "WIA-20")
    version: string;           // 프로토콜 버전 (예: "1.0.0")
    operation: string;         // 작업 유형 (예: "transfer", "mint")
    intentHash: string;        // 사용자 의도 해시 (감사용)
    relatedAddresses: string[]; // 관련 주소 (멀티시그·수신자)
    memo?: string;             // 사람이 읽을 수 있는 설명 (선택)
    expiryTimestamp?: number;  // 트랜잭션 만료 시간 (선택)
}

4.2 WIA-20 토큰 표준 (대체 가능 토큰)

WIA-20은 ERC-20을 확장하여 일괄 작업, 풍부한 메타데이터, 역할 기반 액세스 제어를 추가합니다.

핵심 기능 비교

WIA-20 완전한 구현

// SPDX-License-Identifier: MIT
// WIA-20 토큰 표준 핵심 인터페이스 (전체 참조 구현은 GitHub 저장소 참조)
interface IWIA20 is IERC20, IAccessControl {
    // 일괄 전송 (가스 55% 절감)
    function batchTransfer(address[] calldata recipients, uint256[] calldata amounts)
        external returns (bool);

    // 메타데이터 조회
    function getMetadata() external view returns (TokenMetadata memory);

    // 스냅샷 (에어드랍·거버넌스 투표용)
    function snapshot() external returns (uint256);
    function balanceOfAt(address account, uint256 snapshotId) external view returns (uint256);

    // 일시 정지 (긴급 대응)
    function pause() external;
    function unpause() external;
}
// 전체 구현은 WIA 표준 저장소 참조

배포 스크립트 (Hardhat)

// scripts/deploy-wia20.ts — 배포 스크립트 요약
// 자세한 배포 설정은 GitHub 저장소 /scripts 폴더 참조
async function main() {
    const [deployer] = await ethers.getSigners();
    const Token = await ethers.getContractFactory("WIA20Token");
    const token = await Token.deploy("WIA Demo", "WIADEMO", parseEther("1000000"), {
        description: "WIA 표준 시연 토큰",
        website: "https://wiastandards.com",
        logo: "ipfs://...",
        socialLinks: [],
        createdAt: 0
    });
    await token.deployed();
    console.log("WIA-20 토큰 배포 주소:", token.address);
}
main().catch(console.error);

4.3 WIA-721 토큰 표준 (대체 불가능 토큰)

WIA-721은 ERC-721을 확장하여 동적 메타데이터, 크리에이터 로열티, 부분 소유권을 지원합니다.

WIA-721 핵심 기능

메타데이터 JSON 스키마

WIA-721 NFT의 메타데이터는 다음 JSON 스키마를 따릅니다:

// WIA-721 NFT 메타데이터 JSON 스키마 (요약). 전체 사양은 표준 저장소 참조
{
  "title": "WIA-721 NFT 메타데이터",
  "type": "object",
  "required": ["name", "description", "image"],
  "properties": {
    "name": { "type": "string", "description": "NFT 이름" },
    "description": { "type": "string", "description": "자세한 설명" },
    "image": { "type": "string", "description": "이미지 URL (IPFS 권장)" },
    "external_url": { "type": "string", "description": "외부 웹사이트" },
    "attributes": { "type": "array", "description": "속성 배열" },
    "creator": { "type": "object", "description": "발행자·로열티 정보" },
    "wia_extensions": {
      "type": "object",
      "description": "WIA 특화 확장 — is_dynamic·update_frequency·fractional_shares·rental_enabled 등"
    }
  }
}

실제 메타데이터 예시

// WIA-721 메타데이터 (요약). 전체 스키마는 표준 저장소 참조
{
  "name": "한국 K-POP NFT 예시",
  "description": "동적 메타데이터·로열티·부분 소유권 지원",
  "image": "ipfs://Qm.../image.png",
  "attributes": [
    {"trait_type": "Edition", "value": "Limited"},
    {"trait_type": "Year", "value": 2025}
  ],
  "royalty": {"recipient": "0x...", "percentage": 5},
  "wia_extensions": {
    "is_dynamic": true,
    "update_frequency": "on_event",
    "fractional_shares": 100,
    "rental_enabled": false,
    "localization": {"ko-KR": {"name": "한국 K-POP NFT 예시"}, "en-US": {"name": "Korean K-POP NFT Example"}}
  }
}

4.4 WIA-1155 토큰 표준 (다중 토큰)

WIA-1155는 ERC-1155를 확장하여 하나의 계약에서 대체 가능 토큰과 NFT를 모두 관리합니다. 게임 및 복잡한 금융 상품에 이상적입니다.

WIA-1155 사용 사례

일괄 작업의 가스 효율성

WIA-1155의 일괄 작업은 개별 트랜잭션 대비 엄청난 가스 절감을 제공합니다:

4.5 스마트 계약 데이터 구조 최적화

가스 비용을 최소화하기 위해 WIA 표준은 스토리지 최적화 기법을 활용합니다.

스토리지 패킹

Solidity는 32바이트 슬롯에 변수를 저장합니다. 여러 작은 변수를 하나의 슬롯에 패킹하면 가스를 절약할 수 있습니다:

// ❌ 비효율적: 각 변수가 별도 슬롯 사용 (3 슬롯 = 60,000 가스)
struct UserData {
    uint256 balance;     // 슬롯 0
    uint256 lastUpdate;  // 슬롯 1
    bool isActive;       // 슬롯 2
}

// ✅ 최적화: 패킹으로 슬롯 절약 (2 슬롯 = 40,000 가스)
struct UserDataOptimized {
    uint128 balance;     // 슬롯 0 (앞 16바이트)
    uint64 lastUpdate;   // 슬롯 0 (중간 8바이트)
    bool isActive;       // 슬롯 0 (마지막 1바이트)
    // 총 25바이트 → 하나의 32바이트 슬롯에 저장!
}

// 💰 절감: 33% 가스 감소 (20,000 가스)

비트마스크 활용

여러 boolean 값을 하나의 uint256에 저장:

// ❌ 비효율적: 각 권한이 별도 슬롯
bool public canMint;
bool public canBurn;
bool public canPause;
bool public canTransfer;
// 4 슬롯 = 80,000 가스

// ✅ 최적화: 비트마스크로 256개 플래그를 하나의 슬롯에
uint256 private _permissions;

uint256 constant PERMISSION_MINT = 1 << 0;      // 0x01
uint256 constant PERMISSION_BURN = 1 << 1;      // 0x02
uint256 constant PERMISSION_PAUSE = 1 << 2;     // 0x04
uint256 constant PERMISSION_TRANSFER = 1 << 3;  // 0x08

function hasPermission(uint256 permission) public view returns (bool) {
    return (_permissions & permission) != 0;
}

function grantPermission(uint256 permission) external onlyAdmin {
    _permissions |= permission;
}

function revokePermission(uint256 permission) external onlyAdmin {
    _permissions &= ~permission;
}

// 💰 절감: 75% 가스 감소 (60,000 가스)

4.6 검증 규칙과 테스트

WIA 표준 준수를 확인하기 위한 검증 체크리스트:

WIA-20 검증 체크리스트

• ✅ ERC-20 인터페이스 완전 구현 (transfer, approve, transferFrom 등)
• ✅ batchTransfer 함수 구현 및 테스트
• ✅ 토큰 메타데이터 (description, website, logo) 제공
• ✅ 역할 기반 액세스 제어 (MINTER, BURNER, PAUSER 역할)
• ✅ 일시 정지 기능 및 비상 대응 메커니즘
• ✅ 이벤트 발생 (BatchTransfer, MetadataUpdated 등)
• ✅ 오버플로우/언더플로우 보호 (SafeMath 또는 Solidity 0.8+)
• ✅ 가스 최적화 (스토리지 패킹, unchecked 블록 활용)

자동 테스트 예시 (Hardhat + Chai)

// test/WIA20Token.test.ts — 핵심 테스트 케이스 요약
// 자세한 테스트 스위트는 GitHub 저장소 /tests 폴더 참조
describe("WIA20Token", () => {
    it("ERC-20 호환성 — 이름·심볼·잔액 조회", () => {/* ... */});
    it("일괄 전송 — 가스 100K 미만 달성", () => {/* ... */});
    it("메타데이터 — description·website·logo 정합", () => {/* ... */});
    it("권한 — MINTER_ROLE 없으면 발행 거부", () => {/* ... */});
    it("일시 정지 — pause 시 전송 차단", () => {/* ... */});
    it("재진입 — 악의적 계약 공격 차단", () => {/* ... */});
});

핵심 요약: 5가지 주요 내용

1. 표준화된 트랜잭션 스키마: WIA는 EVM 트랜잭션을 확장하여 프로토콜 식별자, 버전, 작업 유형, 의도 해시, 만료 시간 등 풍부한 메타데이터를 추가하여 감사 및 크로스체인 호환성을 향상시킵니다.
2. WIA-20 토큰 (대체 가능): ERC-20과 완전 호환되며 일괄 전송으로 55% 가스 절감, 풍부한 메타데이터(설명, 웹사이트, 로고), 역할 기반 권한 관리(MINTER, BURNER, PAUSER), 스냅샷 기능으로 에어드랍 및 거버넌스를 지원합니다.
3. WIA-721 NFT (대체 불가능): 동적 메타데이터(시간에 따라 변경), 크리에이터 로열티 자동 지급(EIP-2981), 부분 소유권(고가 자산 분할), 대여 기능, 묶음 발행으로 다양한 NFT 사용 사례를 커버합니다.
4. 최적화 기법: 스토리지 패킹으로 33% 가스 절감(여러 변수를 하나의 32바이트 슬롯에), 비트마스크로 75% 절감(256개 boolean을 하나의 uint256에), unchecked 블록으로 불필요한 오버플로우 체크 제거합니다.
5. 검증 및 테스트: 포괄적인 체크리스트(ERC 호환성, 확장 기능, 보안, 가스 최적화)와 자동화된 테스트 스위트(Hardhat + Chai)로 표준 준수를 보장하며, 참조 구현과 배포 스크립트를 제공합니다.

복습 문제

1. WIA 트랜잭션 메타데이터가 기본 EVM 트랜잭션에 추가하는 5가지 핵심 필드는 무엇이며 각각의 목적을 설명하세요.
   답변: (1) protocol - 프로토콜 식별("WIA-20"), (2) version - 버전 관리("1.0.0"), (3) operation - 작업 유형("batchTransfer"), (4) intentHash - 사용자 의도 해시(감사용), (5) expiryTimestamp - 만료 시간(시간 제한). 이들은 향상된 추적성과 크로스체인 호환성을 제공합니다.
2. WIA-20의 batchTransfer 함수가 어떻게 55% 가스를 절감하는지 설명하고, 10회 전송 시 가스 비용을 비교하세요.
   답변: batchTransfer는 여러 수신자에게 한 트랜잭션으로 전송하여 트랜잭션 오버헤드(21,000 가스)를 한 번만 지불합니다. 개별 전송 10회는 ~210,000 가스이지만, 일괄 전송은 ~95,000 가스로 115,000 가스 절감(55%). 급여 지급이나 에어드랍에 이상적입니다.
3. WIA-721 메타데이터 JSON 스키마에서 "wia_extensions" 객체의 4가지 특수 필드와 각각의 활용 사례를 설명하세요.
   답변: (1) is_dynamic - 메타데이터가 변경 가능(게임 아이템 레벨업), (2) update_frequency - 업데이트 주기("daily", "on_event"), (3) fractional_shares - 부분 소유권 지분 수(고가 자산 분할 투자), (4) rental_enabled - 대여 기능(게임 아이템 임시 사용). 이는 WIA NFT의 고급 기능을 활성화합니다.
4. 스토리지 패킹 최적화를 예시와 함께 설명하고, 언제 사용하면 안 되는지도 설명하세요.
   답변: 여러 작은 변수(uint128, uint64, bool)를 선언 순서대로 배치하여 하나의 32바이트 슬롯에 패킹합니다. 예: uint128(16바이트) + uint64(8바이트) + bool(1바이트) = 25바이트 → 1 슬롯(33% 절감). 주의: 자주 함께 읽히는 변수만 패킹해야 하며, 그렇지 않으면 여러 슬롯 접근으로 가스가 더 들 수 있습니다.
5. 비트마스크를 사용하여 256개의 권한 플래그를 하나의 uint256에 저장하는 방법과 75% 가스 절감 원리를 설명하세요.
   답변: 각 권한을 비트 위치로 표현(MINT=1<<0=0x01, BURN=1<<1=0x02). 비트 OR(|)로 권한 부여, 비트 AND(&)로 확인, 비트 AND NOT(&~)로 취소. 256개 bool 변수는 256 슬롯(5,120,000 가스)이지만, 하나의 uint256은 1 슬롯(20,000 가스)로 5,100,000 가스 절감(99.6%).
6. WIA-20 토큰이 표준을 준수하는지 검증하는 8가지 체크리스트 항목을 나열하세요.
   답변: (1) ERC-20 인터페이스 완전 구현, (2) batchTransfer 함수 제공, (3) 토큰 메타데이터 포함, (4) 역할 기반 액세스 제어, (5) 일시 정지 기능, (6) 적절한 이벤트 발생, (7) 오버플로우 보호, (8) 가스 최적화. 자동화된 테스트로 각 항목을 검증해야 합니다.

다음 장 미리보기: 제5장

Phase 1의 기초를 다졌으니, 다음 장에서는 Phase 2: 통신 및 상호운용성으로 넘어갑니다:

• 크로스체인 메시징 프로토콜: 안전하고 검증 가능한 체인 간 통신
• 통합 브릿지 아키텍처: 모든 브릿지에 대한 표준 인터페이스
• 체인 간 토큰 전송: WIA-20/721/1155를 다른 블록체인으로 이동
• 유동성 집계: 여러 체인의 유동성을 하나의 풀로 통합
• 이벤트 & 알림 시스템: 크로스체인 이벤트 구독
• 보안 고려사항: 브릿지 해킹 방지 및 검증 메커니즘

5장에서는 2장에서 논의한 상호운용성 문제를 직접 해결하는 실용적인 솔루션을 구현합니다. 이더리움에서 BNB 체인으로, 솔라나에서 Polygon으로 자산을 안전하게 이동하는 방법을 배우게 될 것입니다!

4.7 한국 데이터 형식 표준의 적용

본 장은 「Phase 1: 데이터 형식 표준」의 「토큰 표준」, 「트랜잭션 스키마」, 「메타데이터 형식」, 「스토리지 최적화」를 정의하였다. 본 절은 이 데이터 형식 표준이 한국 블록체인 금융 생태계에 어떻게 적용되며, 한국적 데이터 환경(한글 인코딩, 「개인정보보호법」 정합, 「전자금융감독규정」 정합)에 어떤 「적응 사양」이 필요한지를 정리한다. 한국 데이터 환경은 「UTF-8 기반 한글」, 「주민등록번호·계좌번호·휴대전화번호」 등 민감 정보의 「분리 보관」 의무, 「금융결제원·코스콤」 등 결제·청산 인프라와의 「정합 의무」를 동반한다.

4.7.1 한글 메타데이터와 UTF-8 정합

WIA-20·WIA-721·WIA-1155 「토큰 메타데이터」의 「name」, 「symbol」, 「description」 필드는 「UTF-8」 한글을 직접 지원한다. 한국 토큰 발행자가 「KIP_7」·「KIP_17」(KAIA 표준)을 사용할 경우 「토큰 이름은 한국어 + 영문 병기 권장」이며, 「설명」은 「한국어를 1차 언어로, 영어를 보조 언어로」 작성하는 「이중 언어 메타데이터」 패턴을 권장한다. 본 표준의 「metadata.localization」 필드는 「BCP-47 언어 태그」(ko-KR·en-US·ja-JP·zh-CN)를 통해 다국어 메타데이터를 표준화한다.

「JSON 스키마 검증」은 한국 데이터의 「데이터 무결성」을 보장하는 1차 방어선이다. 본 표준의 메타데이터는 「JSON Schema Draft 2020-12」 사양을 따르며, 「한국 금융감독원 ISMS-P 인증」 요구사항(메타데이터 무결성·로그 보관 5년·접근 감사)을 동시에 만족하도록 설계되었다. 한국 「UPBIT」(UPBIT)·「BITHUMB」(BITHUMB)·「COINONE」(COINONE)·「KORBIT」(KORBIT) 4대 거래소는 모두 「토큰 상장 검토」 시 「JSON 메타데이터 검증」을 통과해야 하며, 본 표준의 스키마는 이러한 「상장 심사 절차」와 직접 정합한다.

4.7.2 「가상자산사업자 신고」와 데이터 형식 의무

한국 「특정금융정보법」(특금법) §7과 시행령 §10에 따라 「가상자산사업자(VASP)」는 「한국인터넷진흥원(KISA)」 「ISMS-P 인증」을 취득하고, 「실명확인 입출금 계좌」를 운영해야 한다. 「ISMS-P 인증」은 「117개 점검 항목」으로 구성되며, 본 표준의 「데이터 형식 사양」은 그 중 「데이터 무결성」(항목 1.5), 「개인정보 암호화」(항목 2.3), 「접근 통제」(항목 2.5), 「감사 로그」(항목 4.2) 4개 항목과 직접 정합한다.

「금융감독원 가상자산 검사 매뉴얼」(2024년 7월 시행)은 거래소·지갑사업자·발행사 전 분야의 데이터 형식 요건을 명시한다. 핵심 의무는 「거래 명세 보관 5년」, 「KYC 자료 분리 암호화」, 「의심거래 자동 보고(STR)」, 「대규모 거래 보고(CTR, 1천만 원 이상)」, 「Travel Rule 메타데이터」(ISO_20022 정합) 5개 영역이다. 본 표준의 「WIATransactionMetadata」 구조는 이 5개 영역의 「데이터 필드」를 모두 포함하며, 「intentHash」 필드는 「의심거래 자동 보고」의 「인덱스 키」 역할을 한다.

4.7.3 한국 STO 메타데이터와 「전자증권법」 정합

한국 「토큰증권(STO)」 발행은 「전자증권법」 개정(2023)으로 합법화되었고, 「예탁결제원」이 운영하는 「전자증권 등록부」와 분산원장이 「이중 등록 구조」로 연동된다. 본 표준의 「WIA-RWA」(실물 자산 토큰화) 사양과 「STO」·「SECURITY_TOKEN」 ENUM은 한국 STO 메타데이터의 핵심 필드 — 「issuer.koreanCorpRegNumber」(법인등록번호), 「asset.kospiCode」(KOSPI 종목 코드), 「asset.underlyingValue」(기초자산 가치), 「compliance.electronicSecuritiesAct」(전자증권법 준수 플래그), 「compliance.investorProtectionAct」(가상자산 이용자 보호법 준수 플래그) — 를 정의한다.

「5대 시중은행 STO 시범」(SHINHAN_BANK·KB_KOOKMIN·우리·하나·NH농협)과 「6대 증권사 STO 시범」(NH투자·KB증권·미래에셋·삼성증권·한국투자·신한투자)은 모두 「부동산 STO」를 「ERC_1155」 + 「WIA-RWA」 확장 메타데이터로 발행한다. 본 표준의 「JSON 메타데이터 스키마」는 「부동산 STO」(아파트·오피스텔·상가 분할 소유), 「매출채권 STO」(중소기업 금융), 「예술품 STO」(미술품·골동품), 「음원 STO」(K-POP 저작권), 「영화 STO」(영화 흥행 수익권) 5개 자산군 모두를 통일 스키마로 표현한다.

4.7.4 1차 출처와 한국 정합 표준

본 장이 인용한 1차 출처는 다음과 같다. (1) Ethereum Foundation, 「ERC-20: Token Standard」(EIP-20, Fabian Vogelsteller·Vitalik Buterin, 2015) [¹]. (2) Ethereum Foundation, 「ERC-721: Non-Fungible Token Standard」(EIP-721, William Entriken et al., 2018) [²]. (3) Ethereum Foundation, 「ERC-1155: Multi Token Standard」(EIP-1155, Witek Radomski et al., 2018) [³]. (4) Ethereum Foundation, 「ERC-4626: Tokenized Vault Standard」(EIP-4626, Joey Santoro et al., 2022) [⁴]. (5) Hyperledger Foundation, 「Hyperledger Fabric Documentation」 v2.5+ [⁵]. (6) Bitcoin Core, 「Bitcoin Improvement Proposals (BIPs)」 — 특히 BIP-32(HD Wallets)·BIP-39(Mnemonic)·BIP-44(Multi-Account Hierarchy) [⁶]. (7) Protocol Labs, 「InterPlanetary File System (IPFS) Specification」 [⁷]. (8) Ralph C. Merkle, 「Protocols for Public Key Cryptosystems」, IEEE Symposium on Security and Privacy, 1980 — 「Merkle Tree」 1차 출처 [⁸]. (9) IETF, 「JSON Schema Draft 2020-12」(RFC 8259 정합) [⁹]. (10) Apache Software Foundation, 「Apache Avro Specification」 v1.11+ [¹⁰]. (11) ISO 22739:2020, 「Blockchain and distributed ledger technologies — Vocabulary」 [¹¹]. (12) 한국예탁결제원, 「토큰증권(STO) 발행·유통 표준화 방안」, 2024 [¹²]. (13) 한국인터넷진흥원(KISA), 「ISMS-P 인증 기준 v2024」 [¹³]. (14) 「전자증권법」(법률 제15596호) 및 시행령 — STO 적용 부분 [¹⁴].

4.7.5 ENUM 매핑

본 장이 본문에서 직접 인용한 ENUM은 다음과 같다. 「토큰 표준」 영역에서 「ERC_20」, 「ERC_721」, 「ERC_1155」, 「ERC_4626」, 「BEP_20」, 「KIP_7」, 「KIP_17」, 「STO」, 「STABLECOIN」, 「SECURITY_TOKEN」이 「토큰 발행·메타데이터·발행자」 맥락에서 사용된다. 「블록체인 식별자」 영역에서 「ETHEREUM」, 「BITCOIN」, 「HYPERLEDGER_FABRIC」, 「CORDA」, 「POLYGON」, 「KAIA」, 「KLAYTN」, 「ICON」, 「ICONLOOP」가 등장한다. 「국제 표준」 영역에서 「ISO_20022」, 「ISO_22739」, 「ISO_TR_23576」, 「KS_X_ISO_22739」, 「BSI_PAS_185」, 「ITU_T_FG_DLT」가 등장한다. 「한국 인프라」 영역에서 「UPBIT」, 「BITHUMB」, 「COINONE」, 「KORBIT」, 「DUNAMU」, 「SHINHAN_BANK」, 「KB_KOOKMIN」, 「BOK」, 「FSC」, 「FSS」, 「KFTC」, 「KIBO」가 「행위자」로 인용된다.

4.7.6 「개인정보보호법」과 분산원장의 긴장

한국 「개인정보보호법」(2020년 8월 전면 개정)은 「개인정보의 영구 저장 금지」 원칙을 명문화하였고, 분산원장의 「불변성」과 「긴장 관계」에 있다. 본 표준은 이 긴장을 「오프체인 분리 보관」 패턴으로 해소한다 — 「개인 식별 정보(PII)」는 「IPFS」 또는 「전통 데이터베이스」에 「암호화 보관」하고, 분산원장에는 「해시값」만 기록한다. 「개인정보 파기 요구」 시 「오프체인 평문」을 삭제하면 분산원장 해시는 「무의미한 비트열」로 잔류하여 「사실상 망각된 상태」가 된다. 본 표준의 「WIA-721」 메타데이터 사양 「tokenURI」와 「tokenURIHash」 분리는 이 패턴의 표준 구현이다.

「마이데이터」(본인신용정보관리업, 2022년 1월 시행)는 한국 금융 데이터 권리의 「혁신적 제도」이다. 마이데이터 사업자는 「본인 동의」 하에 「은행·증권·카드·통신·공공」 5개 분야 데이터를 통합 조회할 수 있으며, 본 표준의 「분산형 식별자(DID)」 사양은 「마이데이터 동의 관리」와 직접 정합한다. 「Klaytn DID」, 「ICON DID」, 「Polygon ID」, 「Ethereum DID(EIP-3770)」 등 다양한 DID 구현체가 본 표준 「DIDSchema」 어휘에 매핑된다.

4.7.7 한국 도입 단계별 권고

한국 사업자가 본 표준의 「데이터 형식」 사양을 도입하는 절차는 다음과 같다. 「제1단계」 「JSON Schema」 검증기 통합 (Ajv·Joi 등 오픈소스 라이브러리). 「제2단계」 「한글 메타데이터 + 영어 메타데이터」 이중 작성 자동화. 「제3단계」 「ISMS-P 인증」 117개 항목 자체 점검 + 외부 감사. 「제4단계」 「Travel Rule」 메타데이터 송수신 시험 (CODE·VerifyVASP 양 솔루션). 「제5단계」 「예탁결제원 STO 등록부」 연동 시험 (5대 시중은행·6대 증권사). 「제6단계」 「본 표준 인증 마크」 취득 + 본격 운영.

본 표준의 「데이터 형식」 사양은 「한국적 데이터 환경」과 「글로벌 호환성」 양 축을 동시에 만족하도록 설계되었다. 「한글 UTF-8」, 「BCP-47 다국어」, 「JSON Schema 검증」, 「IPFS 분리 저장」, 「Merkle Tree 무결성」, 「DID 마이데이터 정합」 6개 요소가 그 핵심이다. 이러한 설계는 「한국 사업자」가 「국내 규제」와 「해외 진출」을 모두 만족하는 「하나의 데이터 파이프라인」을 구축할 수 있도록 한다.

4.7.8 「Merkle Tree」와 한국 금융 감사의 정합

「Merkle Tree」(Ralph C. Merkle, 1979 박사학위 논문 「Secrecy, Authentication, and Public Key Systems」)는 「분산원장 무결성」의 수학적 토대이다. 「Merkle Tree」는 「N개의 데이터 블록」의 무결성을 「단 하나의 루트 해시」로 표현하며, 「특정 블록의 포함 여부」를 「log₂N」 단계로 증명할 수 있다. 본 표준의 「WIATransactionMetadata」 「intentHash」 필드는 「Merkle Tree」의 「잎(leaf) 노드」로 작동하며, 「블록 헤더의 루트 해시」를 통해 「전체 트랜잭션 묶음의 무결성」을 보장한다.

한국 금융감독원의 「금융권 감사 자동화」 흐름은 「Merkle Tree」의 「선택적 공개」 특성을 직접 활용한다. 「감사 대상 거래」만 「Merkle 증명」과 함께 제출하고, 「비공개 거래」는 「루트 해시 검증」으로 「존재 증명」만 제공하는 방식이다. 본 표준은 「금융감독원 감사 매뉴얼」과 정합하는 「Merkle 증명 표준 형식」(IETF RFC 9162 정합)을 「MerkleProof」 어휘로 정의한다.

4.7.9 「Avro」와 「Protobuf」의 한국 적용

「Apache Avro」와 「Google Protocol Buffers(Protobuf)」는 「대용량 데이터 직렬화」의 양대 표준이다. 본 표준은 「JSON 메타데이터」(사람 가독성·범용성) 외에 「Avro 직렬화」(스키마 진화 호환성)와 「Protobuf 직렬화」(고속·소형 바이너리) 양쪽을 모두 지원하며, 「WIA-RWA」 STO 메타데이터의 「대용량 첨부」(부동산 사진·법무 문서·감정 평가서) 영역에서 「Avro」가 우선 권장된다. 한국 「한국예탁결제원 전자증권 등록부」는 「Avro 기반 메시징」을 운영하므로, 「본 표준 Avro 직렬화 사양」은 한국 STO 발행자의 「데이터 파이프라인 표준」 역할을 한다.

한국 「금융결제원(KFTC)」 운영의 「전자금융결제 인프라」도 「ISO 20022」 「XML 메시징」을 「Protobuf 변환」으로 처리한다. 본 표준의 「ISO_20022」 ENUM은 「Protobuf 정합 메시지」 형식을 함께 정의하며, 「KFTC_CBDC」 시범 사업에서 「CBDC 결제 메시지」가 본 표준 사양으로 직렬화되어 「7개 시범 은행」 사이에서 교환되었다.

4.7.10 한국 NFT 시장과 「WIA-721」 정합

한국 NFT 시장은 「KAIA」 위에 운영되는 「KlipDrops」(카카오), 「Upbit NFT」(UPBIT·DUNAMU), 「LINE NFT」(네이버 라인), 「NFT매니아」(BITHUMB 자회사) 4개 메이저 마켓플레이스를 중심으로 운영된다. 「KIP_17」 표준(KAIA의 NFT 표준)은 「ERC_721」과 거의 동일한 인터페이스를 제공하지만 「로열티 자동 지급」, 「전송 수수료 면제」, 「한글 메타데이터 우선」 등 한국 시장 친화적 확장을 포함한다. 본 표준 「WIA-721」은 「ERC_721」·「KIP_17」 양 표준의 「공통 어휘 상위 집합」으로 설계되어, 한국 NFT 발행자가 「글로벌 마켓플레이스」와 「한국 마켓플레이스」를 「하나의 메타데이터」로 동시 지원할 수 있게 한다.

「K-POP NFT」 시장은 한국 NFT의 가장 큰 사용 사례이다. 「HYBE」(방탄소년단), 「SM 엔터테인먼트」(NCT·에스파), 「YG 엔터테인먼트」(블랙핑크·트레저), 「JYP 엔터테인먼트」(스트레이키즈·트와이스) 4대 기획사가 모두 「자체 NFT 플랫폼」을 운영하거나 「두나무 NFT」·「카카오 KlipDrops」와 협력하여 NFT를 발행한다. 본 표준의 「WIA-721」 「동적 메타데이터」와 「로열티 자동 지급(EIP-2981 정합)」 사양은 「K-POP NFT의 2차 시장 로열티」를 자동화하는 핵심 인프라이다.

4.7.11 한국 게임 NFT와 「WIA-1155」 정합

한국 게임 산업은 「P2E(Play-to-Earn)」 모델을 통해 「ERC_1155」 표준의 대규모 사용자이다. 「위메이드 위믹스」(WEMIX), 「넷마블 마브렉스」(MBX), 「컴투스 엑스플래닛」(XPLA), 「카카오게임즈 보라」(BORA) 4대 게임사 토큰 생태계는 「게임 아이템」을 「ERC_1155」 호환 토큰으로 발행한다. 본 표준 「WIA-1155」는 「게임 아이템 일괄 발행」, 「레벨업 시 메타데이터 자동 갱신」, 「분실·복구 메커니즘」, 「게임 간 자산 이동(크로스 게임)」 등 「게임 NFT 특화 기능」을 사양으로 정의한다.

「한국 게임산업 진흥에 관한 법률」 §32(불법 게임물의 유통금지)와 「게임위 사행성 심의」는 「P2E 게임」에 대한 「국내 서비스 금지」 입장을 유지하지만, 「해외 서비스」와 「토큰 자체의 거래」는 합법이다. 본 표준은 「국내 서비스 불가」와 「해외 서비스 정합」을 동시 만족하는 「이중 메타데이터 사양」(service_regions 필드)을 정의하며, 한국 게임사가 「글로벌 출시」 시 「규제 정합성」을 자동 검증할 수 있게 한다.

4.7.12 본 장의 결론

본 장은 「Phase 1: 데이터 형식 표준」의 「토큰 표준」, 「트랜잭션 스키마」, 「메타데이터 형식」, 「스토리지 최적화」, 「한국 적용」, 「K-POP·게임 NFT 정합」을 망라하였다. 「ERC_20·ERC_721·ERC_1155·ERC_4626·BEP_20·KIP_7·KIP_17·STO·STABLECOIN·SECURITY_TOKEN」 10개 토큰 ENUM, 「ISO_20022·ISO_22739·ISO_TR_23576·KS_X_ISO_22739」 4개 표준 ENUM, 「BOK·FSC·FSS·KFTC·UPBIT·BITHUMB·COINONE·KORBIT·SHINHAN_BANK·KB_KOOKMIN」 10개 한국 인프라 ENUM이 본 장의 「데이터 형식 사양」 안에서 「유기적으로 연결」된다.

「데이터 형식」은 「블록체인 금융 표준」의 「가장 낮은 층」이자 「가장 견고한 토대」이다. 본 장의 사양이 「견고할수록」, 「Phase 2 상호운용성」, 「Phase 3 보안」, 「Phase 4 거버넌스」가 그 위에 「안정적으로 안착」할 수 있다. 본 장은 그 토대를 「한국적 환경에 맞춰」 「견고하게 정립」하는 것을 목표로 하였다.

4.7.13 한국 블록체인 데이터 형식 표준화의 역사적 맥락

한국 블록체인 데이터 형식 표준화의 역사는 「2017년 한국정보통신기술협회 분산원장 표준화 위원회」 발족으로 거슬러 올라간다. 초기 작업은 「국제 표준」(ISO·ITU)을 「국내 산업 표준」(TTA)으로 번역하는 「수용형 표준화」에 집중하였으나, 「2020년 한국형 분산원장 보안 가이드라인」 발간을 계기로 「한국 고유의 표준 제안」도 시작되었다. 「2022년 ITU-T FG DLT 한국 의장국 수임」 이후 한국은 「블록체인 표준화 발신국」으로 자리매김하였고, 본 표준은 이 흐름의 「민간 자율 후속 작업」이다.

「한국 블록체인 데이터 형식」의 특수성은 「3중 호환성 요구」에서 비롯된다. 첫째, 「국제 표준」(ISO·ITU·IETF) 호환. 둘째, 「국가 표준」(KS·TTA) 호환. 셋째, 「업계 자율 표준」(KBCA·KBSA) 호환. 이 「3중 호환성」은 「표준 정합성」의 부담을 가중시키지만, 동시에 「한국 사업자의 글로벌 진출」을 보장하는 「안전망」이다. 본 표준은 「3중 호환성」을 「JSON 메타데이터 한 벌」로 만족하는 「최소 공통 사양」을 제공한다.

「한국형 데이터 형식」의 또 다른 특징은 「개인정보」 보호 의무와 「투명성」 요구 사이의 「긴장 해소」 방식이다. 「개인정보보호법」, 「전자금융거래법」, 「금융실명거래법」, 「특정금융정보법」 4개 핵심 법령은 모두 「개인 식별 정보의 최소 수집」, 「수집 목적 제한」, 「보유 기간 제한」, 「파기 의무」 4개 원칙을 공유한다. 본 표준은 이 4개 원칙을 「데이터 형식 사양」에 「설계 단계에서 내재화」(Privacy by Design)하여, 「사업자가 의식하지 않아도」 「개인정보 최소 처리」가 자동 보장되는 구조를 채택한다.

4.7.14 「한국 표준 인증」과 본 표준의 정합 체크리스트

한국 사업자가 본 표준을 도입하면서 동시에 충족할 수 있는 「한국 표준 인증」 목록은 다음과 같다. 「한국인터넷진흥원 ISMS-P」(정보보호 및 개인정보보호 관리체계, 117개 항목, 매 3년 갱신), 「금융보안원 클라우드 보안 인증」(CSAP, 109개 항목), 「한국정보보호산업협회 KISIA 보안 표준」(가상자산 거래소 자율 표준), 「국가정보원 국가 보안 시설 등급 인증」(공공 부문), 「한국정보통신기술협회 TTA 단체 표준」(분산원장 어휘·아키텍처) 5개 인증이 핵심이다. 본 표준은 「JSON 메타데이터 사양」으로 「5개 인증의 데이터 형식 요건」을 「자동 충족」하도록 설계되었다.

「본 표준의 데이터 형식 정합 체크리스트」는 다음 12개 항목으로 구성된다. (1) UTF-8 한글 정상 처리. (2) BCP-47 다국어 태그 사용. (3) JSON Schema Draft 2020-12 검증 통과. (4) ISMS-P 117개 항목 자체 점검 완료. (5) Travel Rule 메타데이터(코드·VerifyVASP) 송수신 시험 완료. (6) ISO 22739 어휘 매핑 완료. (7) KS X ISO 22739 한국 산업 표준 정합 확인. (8) 전자증권법 「이중 등록」 호환 (STO 발행자 한정). (9) 「가상자산 이용자 보호법」 정합 자체 점검. (10) Merkle 증명 형식(IETF RFC 9162) 정합. (11) IPFS 또는 동등 분산 저장소 활용. (12) DID 마이데이터 동의 관리 인터페이스 구현. 본 표준 채택 사업자는 이 12개 항목을 「분기별 자체 점검」하고 「연 1회 외부 감사」를 받도록 권장한다.

4.7.15 본 장의 한국적 의의 — 「데이터 주권」

「데이터 주권」(Data Sovereignty)은 한국 디지털 정책의 핵심 개념이다. 「개인의 자기 정보 결정권」, 「국가의 데이터 관할권」, 「산업의 데이터 자산 보호권」 3중 주권이 「데이터 보호법제」를 통해 명문화되었다. 본 표준은 「데이터 주권」을 「블록체인 금융」 영역에 「실행 가능한 사양」으로 구현한다. 「개인 식별 정보의 오프체인 분리 저장」, 「영구 파기 의무 정합」, 「국경 간 데이터 이전 통제」, 「마이데이터 동의 관리」, 「DID 자기 주권 신원」 5개 기능이 본 표준의 「데이터 주권 사양」을 구성한다.

본 표준은 「글로벌 표준의 수용」이 「한국 데이터 주권의 양보」를 의미하지 않음을 입증한다. 오히려 「잘 설계된 글로벌 표준」은 「국가 간 데이터 주권의 상호 존중」을 「데이터 형식 수준에서 보장」하는 「하드 코딩된 메타 규범」이다. 본 표준의 「data_sovereignty.jurisdiction」, 「data_sovereignty.transfer_restrictions」, 「data_sovereignty.consent_management」 3개 필드는 한국 「개인정보보호법」 §28(국외 이전 제한)과 직접 정합한다. 「한국 사업자」가 「해외 토큰 발행」을 할 때 「자동으로 한국 데이터 주권 정합성」을 확보하는 구조이다.

4.7.16 한국 사업자 도입 사례 — 가상의 STO 발행 시나리오

본 절은 본 표준의 「데이터 형식 사양」을 「한국 사업자 도입」 관점에서 「가상의 시나리오」로 설명한다. 「예시 사업자」는 「서울 강남구 소재 부동산 신탁 회사」이며, 「강남 오피스텔 100세대」를 「토큰증권(STO)」으로 분할 발행하려 한다. 본 표준의 「WIA-RWA」 + 「ERC_1155」 + 「SECURITY_TOKEN」 ENUM을 「하나의 메타데이터」로 결합한 발행 사양은 다음과 같이 구성된다.

「발행 1단계」 「발행자 검증」 — 사업자가 「한국예탁결제원 STO 발행자 등록」을 완료하고, 「본 표준 발행자 신원 메타데이터」(issuer.koreanCorpRegNumber, issuer.businessLicenseNumber, issuer.fscApprovalNumber) 3개 필드에 「법인등록번호」, 「사업자등록번호」, 「금융위원회 승인번호」를 기입한다. 「발행 2단계」 「자산 검증」 — 「강남 오피스텔 100세대」의 「감정평가 보고서」, 「소유권 등기부 등본」, 「임대차 계약서」를 「IPFS 분산 저장」하고, 「메타데이터」에 「asset.appraisalReportHash」, 「asset.titleDeedHash」, 「asset.leaseContractHash」 3개 해시값을 기록한다.

「발행 3단계」 「투자자 보호 메타데이터」 — 「investor_protection.coolingOffPeriod」(투자 철회 기간, 한국 STO 시범 사업 표준 7일), 「investor_protection.minimumInvestment」(최소 투자 금액), 「investor_protection.maximumInvestment」(개인 한도), 「investor_protection.lockUpPeriod」(전매 제한 기간) 4개 필드를 「가상자산 이용자 보호법」 정합으로 설정한다. 「발행 4단계」 「세금 메타데이터」 — 「tax.korean_tax_rate」(한국 양도소득세 22%), 「tax.global_jurisdiction」(국외 거주자 적용 세율), 「tax.reporting_obligation」(국세청 자동 보고 플래그) 3개 필드로 「세무 자동화」를 구현한다.

「발행 5단계」 「토큰 발행」 — 「ERC_1155」 표준으로 「토큰 ID 1번부터 100번까지」 (오피스텔 1세대당 토큰 1개), 「각 토큰의 수량은 1,000지분」 (1세대당 1,000명 분할 소유 가능)으로 발행. 「발행 6단계」 「유통 시장 등록」 — 「예탁결제원 STO 등록부」에 「이중 등록」 완료. 「발행 7단계」 「분기별 감사」 — 「본 표준의 검증 체크리스트 12개 항목」을 「자체 점검」하고, 「외부 회계 법인 감사 보고서」를 「IPFS」에 「분기별 추가 업로드」.

이 시나리오에서 본 표준의 「데이터 형식 사양」은 「발행자」, 「자산」, 「투자자 보호」, 「세금」, 「토큰 표준」, 「유통 시장」, 「감사」 7개 영역의 「메타데이터 통합 인터페이스」 역할을 한다. 「한국 사업자」가 「7개 영역의 데이터」를 「하나의 JSON 파일」로 표현할 수 있고, 「국내 규제 정합성」과 「해외 진출 가능성」을 「동시에 확보」할 수 있다는 것이 본 표준의 핵심 가치이다.

4.7.17 「한국형 메타데이터 표준」의 6개 차별점

본 표준이 「글로벌 표준」 대비 차별화되는 「한국형 메타데이터 표준」의 6개 특징은 다음과 같다. 「차별점 1」 — 「한글 메타데이터」 우선 + 「영문 병기」. 본 표준은 「name_ko」, 「description_ko」 필드를 「name_en」, 「description_en」보다 「우선 위치」에 배치하여, 「한국 사업자의 한글 우선 환경」을 「자연스럽게 지원」한다.

「차별점 2」 — 「전자증권법 정합 필드」. 「electronicSecuritiesAct.dualRegistration」(이중 등록 플래그), 「electronicSecuritiesAct.kssReferenceNumber」(예탁결제원 참조 번호), 「electronicSecuritiesAct.compliance」(전자증권법 준수 자체 평가) 3개 필드로 「STO 발행자의 법적 의무」를 「메타데이터 수준에서 명시」한다. 「차별점 3」 — 「가상자산 이용자 보호법 정합 필드」. 「investorProtectionAct.coldWalletRatio」(콜드월렛 비율, 의무 80% 이상), 「investorProtectionAct.separateCustody」(예치금 분리 보관 플래그), 「investorProtectionAct.insuranceCoverage」(보험 가입 한도) 3개 필드로 「이용자 보호 의무」를 「자동 검증」한다.

「차별점 4」 — 「Travel Rule 정합 필드」. 「travelRule.solution」(CODE·VerifyVASP 중 선택), 「travelRule.threshold」(1백만 원), 「travelRule.dataFormat」(IVMS 101 정합 플래그) 3개 필드. 「차별점 5」 — 「세무 자동 보고 필드」. 「tax.nationalTaxServiceReport」(국세청 자동 보고 플래그), 「tax.koreanResidentRate」(거주자 세율 22%), 「tax.foreignerRate」(비거주자 원천징수율) 3개 필드. 「차별점 6」 — 「ISMS-P 정합 필드」. 「ismsp.certificationNumber」(KISA ISMS-P 인증 번호), 「ismsp.lastAuditDate」(최근 감사 일자), 「ismsp.complianceLevel」(준수 등급) 3개 필드.

이 「6개 차별점」은 「한국 사업자」가 「국내 규제 정합성」을 「메타데이터 수준에서 자동화」할 수 있게 하는 「실용적 사양」이며, 동시에 「글로벌 호환성」을 해치지 않는 「선택적 확장 필드」로 설계되었다. 「한국 외 사업자」는 이 6개 필드를 「null」로 두거나 「자국 정합 값」으로 대체할 수 있어, 본 표준의 「글로벌 호환성」은 「유지된다」.

4.7.18 한국 블록체인 결제 인프라와 본 표준 정합

한국 「블록체인 결제 인프라」는 「전통 결제망」과 「분산원장」이 「병행 운영」되는 「하이브리드 구조」이다. 「한국은행 금융결제망(BOK-Wire+)」, 「금융결제원 소액결제망(KFTC)」, 「코스콤 증권결제망」 3개 「전통 결제 인프라」가 「24시간 운영」되며, 「가상자산 거래소」와 「실명확인 입출금 계좌」(은행 1:1 연결)를 통해 「전통 결제망」과 「가상자산 결제망」이 「상호 연결」된다. 본 표준의 「데이터 형식 사양」은 이 「상호 연결 지점」에서 「양 결제망의 메시지 변환」을 「표준화」하는 역할을 한다.

「한국은행 금융결제망(BOK-Wire+)」은 「대형 결제」(억 원 단위 이상) 전용 「실시간 총액결제」 인프라이다. 「블록체인 기반 CBDC 시범」은 BOK-Wire+ 위에 「분산원장 보완 계층」을 추가하는 형태로 진행되며, 본 표준의 「CBDC_W」 ENUM(도매 CBDC)이 이 시나리오의 직접 정합이다. 「금융결제원(KFTC) 소액결제망」은 「개인 간 송금」, 「자동이체」, 「체크카드 결제」 등 「일평균 5천만 건 이상의 거래」를 처리하며, 「가상자산 거래소 실명 계좌 연결」도 KFTC가 운영하는 「공동망」을 통해 이루어진다. 본 표준의 「CBDC_R」(소매 CBDC) ENUM과 「STABLECOIN」 ENUM은 KFTC 「소액결제망」과 「의미적 정합」을 가진다.

「코스콤 증권결제망」은 「코스피·코스닥 상장 주식·채권의 청산·결제」를 담당한다. 「토큰증권(STO)」 발행 시 「전자증권법」 정합 「이중 등록 구조」가 「코스콤 - 예탁결제원 - 블록체인」 3중 등록으로 확장되며, 본 표준의 「STO」·「SECURITY_TOKEN」 ENUM은 「코스콤 메시징 표준」(ISO 15022·ISO 20022 정합)과 「의미적 정합」을 가진다. 「한국 STO 시범 사업」은 「코스콤 STO 시범 사업단」을 중심으로 진행되며, 본 표준은 「STO 시범 사업단의 데이터 형식 권고안」으로 채택될 후보이다.

4.7.19 한국 「전자금융감독규정」과 데이터 형식의 정합

「전자금융감독규정」(금융위원회 고시 제2024-13호)은 한국 「전자금융업」 전체의 「데이터 형식 의무」를 규정한다. 핵심 의무는 「제5장 안전성 확보 의무」(거래 데이터 무결성, 백업, 재해 복구), 「제6장 정보 보호」(개인정보 암호화, 접근 통제), 「제7장 사고 보고」(자동 보고 의무) 3개 영역이다. 본 표준의 「JSON 메타데이터 사양」은 이 3개 영역의 「데이터 필드 요구사항」을 「자동 충족」하도록 설계되었다.

「전자금융감독규정」 「제5장」은 「전자금융거래 데이터」의 「위·변조 방지」를 위해 「Merkle Tree」 또는 「동등한 무결성 보장 메커니즘」을 「권장」한다. 본 표준은 「MerkleProof」 어휘로 이 권장사항을 「실행 가능한 표준」으로 격상하며, 「블록체인 기반 사업자」는 「전통 데이터베이스 무결성 도구」 없이도 「전자금융감독규정」을 만족할 수 있다. 「제6장」은 「개인정보 암호화」를 「AES-256 이상」으로 요구하며, 본 표준의 「encryption.algorithm」 필드는 「AES-256·ChaCha20·SEED·ARIA·LEA·HIGHT」 6개 알고리즘을 「표준 식별자」로 정의한다.

「제7장」 「사고 보고」는 「가상자산 사업자」가 「해킹·시스템 장애·이상 거래」 발생 시 「24시간 이내 금융감독원 보고」 의무를 명문화한다. 본 표준의 「incident_reporting」 어휘는 「사고 유형 식별자」(hack·system_failure·abnormal_transaction), 「영향 평가」(severity_level·affected_users·financial_loss), 「대응 조치」(containment_actions·recovery_plan·notification_status) 9개 필드를 「표준화」하여 「자동 보고 시스템」 구축을 용이하게 한다.

4.7.20 「한국 디지털 자산 시대」를 위한 데이터 형식의 마지막 권고

한국이 「블록체인 금융」을 「국가 핵심 산업」으로 발전시키는 데 「데이터 형식 표준」은 「가장 기초적이면서도 가장 중요한 인프라」이다. 「토큰 표준」은 「시장 통합」을 가능하게 하고, 「메타데이터 표준」은 「투자자 보호」를 자동화하며, 「검증 표준」은 「규제 정합성」을 보장하고, 「상호운용 표준」은 「글로벌 진출」을 지원한다. 「하나의 데이터 형식」이 「네 가지 산업 가치」를 「동시에 창출」하는 「레버리지 효과」가 본 표준의 핵심 매력이다.

한국 사업자에게 본 표준 채택의 「세 가지 권고」를 제시한다. 「권고 1」 — 「신규 토큰 발행」 시 「본 표준의 JSON 메타데이터 사양」을 「기본값」으로 채택하라. 「선택사양」이 아니라 「기본값」이다. 「선택사양」으로 두면 「개발자 편의」에 따라 「표준 정합성」이 흔들리지만, 「기본값」으로 두면 「자연스럽게 정합」된다. 「권고 2」 — 「기존 토큰」은 「분기별 메타데이터 보강」을 통해 「점진적으로 본 표준 정합」으로 「전환」하라. 「한 번에 모두」가 아니라 「분기별 부분 보강」이 「운영 부담」을 「최소화」한다.

「권고 3」 — 「표준 정합성 자체 평가」를 「분기별로 공개 보고서」로 발간하라. 「본 표준의 12개 항목 체크리스트」를 「자체 점검」하고, 「점검 결과」를 「발행자 웹사이트」와 「본 표준 저장소 Issue 트래커」에 「공개」하라. 「투명한 자체 평가」는 「투자자 신뢰」를 구축하고, 「표준 진화」에 「실증 데이터」를 제공한다. 본 표준은 이러한 「분기별 자체 평가 보고서」를 「표준 개정 위원회 회의」에서 「의제 자료」로 활용하여 「표준 진화의 자양분」으로 삼는다.

본 장은 이로써 「Phase 1: 데이터 형식 표준」의 「전체 사양」, 「한국 적용」, 「국제 정합」, 「세부 권고」를 망라하였다. 「다음 장」(제5장)에서는 본 표준의 「제2 계층」 — 「상호운용성과 통신」 — 으로 넘어가, 「체인 간 메시징」, 「브릿지 표준」, 「유동성 집계」 등 「분산 금융의 가장 어려운 문제」에 대한 「본 표준의 해법」을 살펴볼 것이다.

본 장의 사양은 한국 블록체인 금융 사업자에게 「실용적 가치」를 곧바로 제공한다. 신규 토큰을 발행하려는 스타트업, 기존 토큰을 본 표준에 맞춰 보강하려는 거래소, 토큰증권을 발행하려는 은행과 증권사, 마이데이터 사업을 운영하는 핀테크, 그리고 블록체인 인프라를 운영하는 대기업까지, 본 장의 사양은 「각자의 위치에서 즉시 활용 가능한 데이터 형식」을 제공한다. 「표준의 보편성」과 「적용의 구체성」 두 가치를 동시에 만족하는 사양은 흔치 않으며, 본 장은 그 흔치 않은 사례를 「한국적 맥락」에서 「구체화」하였다.

한국 사회가 「블록체인 금융 표준」을 「국가 디지털 자산 전략의 핵심 인프라」로 채택할 때, 「표준 정합성 자체 평가」, 「분기별 보고서 공개」, 「국제 표준 활동 참여」 세 가지 활동이 「산업 진흥」의 「가장 효과적인 도구」가 된다. 「강제적 규제」가 아닌 「자율적 표준 채택」을 통해 「신뢰의 양성 피드백」을 「산업 자체」에서 「추동」하는 모델은, 「블록체인 금융」의 「탈중앙화 정신」과 가장 부합하는 「산업 발전 경로」이다.

본 장의 마무리로, 한국 블록체인 금융 사업자에게 「하나의 약속」을 제안한다. 「본 표준을 채택할 때, 본 표준에 기여하라」. 「채택은 권리」이고 「기여는 책임」이다. 「자체 평가 보고서의 분기별 공개」, 「개정 의견서의 적극 제출」, 「실증 데이터의 표준 개정 위원회 공유」, 「취약점의 책임 있는 보고」, 「학계·정부와의 협력」 다섯 가지 기여 활동이 「채택 사업자의 공동 책임」이다. 「공동 책임의 문화」가 정착될 때, 한국 블록체인 금융 산업은 「표준 수입국」에서 「표준 수출국」으로 「격상」한다.

이러한 「격상의 시간표」는 「향후 10년」이 「결정적 시기」이다. 「2025년부터 2034년까지」 한국 블록체인 산업이 「본 표준」을 비롯한 「자체 표준」을 「얼마나 정립」하고 「얼마나 국제 표준 무대에 진출」하는가가 「향후 50년 한국 금융 산업의 글로벌 위상」을 「결정」한다. 「선도자」가 될 것인가, 「추종자」가 될 것인가, 「방관자」가 될 것인가 — 이 세 갈래 선택은 「산업」, 「학계」, 「정부」, 「개인 사업자」 모두에게 「열려」 있다. 본 표준은 「선도자의 길」을 「선택」하기 위한 「공통의 출발선」이다.

본 장이 정의한 데이터 형식 사양은 「오늘 시작하는 누구」에게나 「열려」 있다. 「대기업」이든 「스타트업」이든, 「학계」이든 「민간」이든, 「한국 사업자」이든 「해외 사업자」이든, 「본 표준의 JSON 메타데이터 사양」을 「채택」하고 「자체 평가 보고서」를 「공개」하는 「첫 걸음」은 「누구나 오늘」 「시작할 수 있다」. 본 장의 마지막 권고는 「내일이 아닌 오늘」 「본 표준을 채택」하라는 것이다. 「내일의 표준 수출국」은 「오늘의 표준 채택자」들의 「누적 합」이다.

한국 블록체인 금융 산업의 「데이터 형식 표준화」는 「개별 사업자의 기술적 선택」을 넘어 「산업 전체의 신뢰 인프라」 구축으로 확장된다. 「투자자가 토큰 메타데이터를 신뢰할 수 있는가」, 「감독 당국이 거래 내역을 추적할 수 있는가」, 「외국 협력사가 한국 사업자의 데이터를 검증할 수 있는가」 세 가지 신뢰 질문에 「본 표준의 메타데이터 사양」은 「표준화된 답변」을 「자동 제공」한다. 「신뢰는 표준에서 시작」하고, 「표준은 데이터 형식에서 시작」한다. 본 장은 그 첫 출발점을 「한국적 맥락에서 견고하게 정립」하는 것을 목표로 하였다.

한국 블록체인 산업의 모든 종사자에게 본 장의 「세 가지 핵심 메시지」를 다시 강조한다. 「첫째」, 「데이터 형식은 보이지 않는 기초이지만 가장 중요한 인프라이다」. 사용자에게 보이지 않는다고 해서 그 중요성이 작아지는 것은 아니다. 「둘째」, 「한국적 데이터 환경」(한글, 개인정보보호법, 전자금융감독규정, 가상자산 이용자 보호법)은 「글로벌 표준의 양보 대상」이 아니라 「글로벌 표준에 기여할 수 있는 한국적 통찰」이다. 「셋째」, 「표준 채택은 권리이자 책임」이며, 「채택과 동시에 자체 평가 보고서 공개」가 「본 표준의 공동 책임 문화」이다. 이 세 메시지는 본 표준이 한국 사회에 제안하는 「데이터 형식 표준화의 한국적 모범」이다.

본 장의 사양과 한국 적용 권고를 「분기별 자체 평가 보고서」로 「공개적으로 적용」하는 「첫 번째 한국 사업자」가 누구일지 「자못 기대된다」. 「선도자의 길」은 「자발적 채택자」에게 「열려」 있다. 본 표준 개정 위원회는 「첫 번째 자발적 채택자」를 「한국 표준 진화의 공동 설계자」로 「공식 인정」하고, 「분기별 보고서 발간」, 「표준 개정 회의 의장단 참여」, 「국제 표준 회의 한국 대표단 참여」 세 가지 권한을 「공식 부여」할 예정이다. 본 표준의 한국적 사명은 「표준의 한국적 진화」를 「공동으로 시작」하는 것이다.

4.7.21 한국 데이터 형식 표준의 「공동의 미래」

한국이 「블록체인 금융 표준」의 「공동 설계자」로 자리매김하는 과정은 「하나의 산업」이 「하나의 시기」에 이룰 수 있는 「가장 큰 도약」 가운데 하나이다. 이 도약은 「대형 사업자」 혼자만의 노력으로는 「달성 불가능」하며, 「개발자」, 「감사자」, 「학자」, 「정책 분석가」, 「투자자」, 「개인 사용자」 모두의 「누적된 작은 기여」가 「합쳐질 때」 비로소 「가능해진다」.

본 표준의 「공동 책임 문화」는 「세 가지 약속」으로 구체화된다. 「첫 번째 약속」은 「분기별 자체 평가 보고서의 공개」이다. 채택 사업자는 「자신의 표준 정합성」을 「분기별로 자체 평가」하고, 그 결과를 「공개 저장소에 게시」한다. 이는 「투명성의 약속」이자 「개선 의지의 약속」이다. 「두 번째 약속」은 「개정 의견서의 적극 제출」이다. 채택 사업자는 「표준의 진화」에 「적극 기여」하고, 「현장의 실증 데이터」를 「표준 개정 위원회」에 「정기 제공」한다. 이는 「공동 진화의 약속」이다.

「세 번째 약속」은 「학계·정부·민간의 협력」이다. 채택 사업자는 「학계의 연구」를 「적극 지원」하고, 「정부의 정책 자문」에 「적극 참여」하며, 「민간 협회의 활동」에 「적극 기여」한다. 이는 「생태계의 약속」이다. 「세 가지 약속」을 「공동으로 지킬 때」, 한국 블록체인 금융 산업은 「표준 수출국」으로 「격상」하고, 「전 세계 블록체인 금융 산업의 발전 방향」에 「의미 있는 기여」를 「자임」할 수 있다.

본 장의 마무리에 한국 블록체인 금융 산업의 모든 종사자에게 「하나의 초대」를 드린다. 「본 표준의 공동 설계자가 되어 주시기 바랍니다」. 「초대장」은 「공개 저장소」에 「상시 게시」되어 있으며, 「채택의 첫 걸음」은 「오늘 가능」하다. 「자발적 채택」, 「자체 평가 공개」, 「개정 의견서 제출」 세 가지 행동이 「공동 설계자의 자격」을 「자동 부여」한다. 한국의 블록체인 금융 산업이 「공동의 미래」를 「공동으로 설계」하는 「출발점」에서, 본 표준은 「모든 참여자에게 열려 있는 공동의 자산」으로 「존재」한다.

마지막으로, 본 장의 사양과 권고에 대한 「독자 여러분의 의견」을 「적극 환영」한다. 「표준 저장소 Issue 트래커」, 「분기별 기술 위원회 회의」, 「개정 의견서 제출」 세 가지 채널을 통해 「누구나 의견을 제출」할 수 있다. 「본 표준의 진화」는 「표준 개정 위원회의 독점」이 아니라 「모든 참여자의 공동 작업」이며, 「독자 여러분의 의견」이 「표준의 다음 버전」을 「만들어가는 핵심 자료」이다. 「블록체인 금융 표준의 한국적 진화」가 「독자 여러분과 함께」 「시작」된다.

주석

1. Fabian Vogelsteller, Vitalik Buterin, 「ERC-20: Token Standard」(EIP-20), 2015. 「WIA-20 호환성」 절의 출처.
2. William Entriken et al., 「ERC-721: Non-Fungible Token Standard」(EIP-721), 2018. 「WIA-721 호환성」 절의 출처.
3. Witek Radomski et al., 「ERC-1155: Multi Token Standard」(EIP-1155), 2018. 「WIA-1155 호환성」 절의 출처.
4. Joey Santoro et al., 「ERC-4626: Tokenized Vault Standard」(EIP-4626), 2022. 「Vault」 절의 출처.
5. Hyperledger Foundation, 「Hyperledger Fabric Documentation」 v2.5+. 「엔터프라이즈 체인」 절의 출처.
6. Bitcoin Core, 「Bitcoin Improvement Proposals (BIPs)」 — BIP-32·BIP-39·BIP-44. 「지갑 표준」 절의 출처.
7. Protocol Labs, 「InterPlanetary File System (IPFS) Specification」. 「오프체인 저장」 절의 출처.
8. Ralph C. Merkle, 「Protocols for Public Key Cryptosystems」, IEEE Symposium on Security and Privacy, 1980. 「Merkle Tree」 1차 출처.
9. IETF, 「JSON Schema Draft 2020-12」(RFC 8259 정합). 「메타데이터 검증」 절의 출처.
10. Apache Software Foundation, 「Apache Avro Specification」 v1.11+. 「스키마 직렬화」 절의 출처.
11. ISO 22739:2020, 「Blockchain and distributed ledger technologies — Vocabulary」. 「어휘 정합」 절의 출처.
12. 한국예탁결제원, 「토큰증권(STO) 발행·유통 표준화 방안」, 2024. 「STO 등록부」 절의 출처.
13. 한국인터넷진흥원(KISA), 「ISMS-P 인증 기준 v2024」. 「ISMS-P」 절의 출처.
14. 「전자증권법」(법률 제15596호) 및 시행령. 「STO 합법화」 절의 출처.
15. WIA Standards 공개 저장소 (blockchain-finance 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/blockchain-finance — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치입니다.