마루(Maroo)

한국 원화 경제를 위한 규제 친화적 개방형 기반 블록체인(Layer 1)

2026년 1월

해시드오픈파이낸스(Hashed Open Finance)
해시드(Hashed)
샤드랩(ShardLab)
딜라이트 랩스(Delight Labs)

개요
문제 정의
관련 프로젝트 및 비교
마루 설계 원칙
플랫폼 아키텍처
- 5.1 핵심 구성요소
- 5.2 네트워크 및 합의
- 5.3 실행 환경
- 5.4 노드 역할
- 5.5 신원 및 계정 모델
- 5.6 거래 모델 및 규제 준수
- 5.7 프라이버시 설계
결론
참고 자료

부록: 다이어그램 목록

1. 개요

1.1 비전과 미션

마루(Maroo)는 한국 원화(KRW) 경제를 위해 설계한 규제 친화적 Sovereign Layer 1 블록체인이다. 오늘날 한국의 디지털 경제는 이미 온라인과 모바일을 중심으로 빠르게 성장하고 있지만, 정작 개인이나 회사가 실생활에서 사용할 수 있는 온체인 KRW 기반 금융 인프라는 존재하지 않는다. 현재 주요 블록체인 인프라들은 고객 경험, 개인정보 및 규제 준수 측면에서 새로운 온체인 기반 금융 환경에 적합하게 설계되지 않았으며, 이로 인해 금융 규제·감사·소비자 보호 측면에서뿐만 아니라 개발자와 기업 입장에서도 한계가 있다.

마루의 비전은 명확하다. “한국 원화 경제를 위한 개방적이고 신뢰할 수 있으며 지속 가능한 블록체인 기반 인프라를 구축한다.” 이를 위해 마루는 규제 친화적이면서도 개방적인 블록체인 인프라를 설계하여, 혁신과 규제가 공존할 수 있는 새로운 패러다임을 제시한다.

1.2 핵심 가치

마루는 다섯 가지 핵심 메커니즘을 통해 기존 블록체인의 한계를 극복하고자 한다.

KRW 네이티브 블록체인(KRW Native Blockchain): 마루에서 모든 가스비는 원화 스테이블코인(가칭 OKRW)으로 지불된다. 이를 통해 사용자와 개발자는 ETH나 다른 변동성 토큰이 아닌, 원화 기반의 안정적인 단위로 수수료를 예측하고 관리할 수 있다. 변동성 토큰을 가스비로 사용할 경우 발생하는 이중 변동성(가스 단가 변동 + 토큰 가격 변동)이 제거되어, 기업 재무팀은 별도의 암호화폐 자산을 보유하지 않고도 인프라 비용을 원화 기준으로 예산에 반영할 수 있다. 또한 마루 생태계가 성장하고 더 많은 트랜잭션이 발생할수록, 가스비 지불을 위한 원화 스테이블코인의 수요와 유통량이 자연스럽게 증가하는 구조를 갖는다. 이는 단순한 결제 수단을 넘어, 블록체인 활동과 원화 기반 디지털 경제가 함께 성장하는 선순환을 만들어낸다.

개방적이되 규제를 준수(Public, but Regulated): 누구나 지갑을 생성하고 트랜잭션을 전송할 수 있는 퍼블릭 체인이지만, 거래 상대방의 신원 상태, 거래 금액, 자산 유형 등 현행법 기준에 따라 Regulated Path와 Open Path를 구분해 처리한다. Regulated Path는 사전 승인과 컴플라이언스 검증을 거치는 트랜잭션 경로이고, Open Path는 별도의 사전 승인 없이 전송되는 일반 트랜잭션 경로다. 이를 통해 혁신·실험이 필요한 영역과 강한 규제가 필요한 영역이 동일한 인프라 위에서 공존할 수 있다.

프로그램 가능한 규제 준수 계층(Programmable Compliance Layer, PCL): 금액·국가·KYC/KYB/KYA 상태·제재 리스트·Travel Rule 등을 기반으로, 트랜잭션 레벨에서 프로그램 가능한 컴플라이언스 로직(programmable compliance)을 평가·적용하는 레이어를 제공한다. 규제 파라미터는 Legal Oracle이 공급하고, PCL은 이를 기반으로 Regulated Path 트랜잭션을 허용·거절한다.

검증 가능한 프라이버시(Verifiable Privacy): 송·수신자, 금액, 토큰 타입 등의 공개 범위를 상황에 따라 선택 가능하게 설계한다. 규제기관은 관찰자 노드(Observer Node)를 통해, PCL이 제공하는 실정법 기준에 맞는 범위 내에서 제한된 감사를 수행할 수 있어, 프라이버시와 규제 요구 사이의 균형을 맞춘다.

AI 에이전트 친화적 설계(AI Agent Oriented Design): AI 에이전트의 확산에 대응하여, KYA(Know Your Agent)를 통한 에이전트 검증 체계와 거래 모듈을 제공함으로써 AI의 온체인 경제 활동을 지원한다. 동시에 사용자의 프라이버시를 보호하기 위한 접근 권한 및 위임 범위를 명확히 설계하여, AI가 자율적으로 실행하는 경제 활동에 대한 책임소재와 한도를 함께 정의한다.

2. 문제 정의

2008년 10월 사토시 나카모토(Satoshi Nakamoto)가 비트코인 화이트페이퍼를 발표한 이후, 지난 17년 동안 블록체인과 디지털 자산은 빠르게 성장해 왔다. 특히 스테이블코인 시장은 2020년 약 280억 달러에서 2025년 약 3,000억 달러로 10배 이상 성장했다(Citi, 2025). 그러나 이러한 성장에도 불구하고, 스테이블코인 및 디지털 자산의 실물 금융 내 활용도는 여전히 낮다. IMF(2025)에 따르면, 스테이블코인 거래의 약 80%는 봇과 자동화 시스템에 의한 차익거래 및 리밸런싱 목적으로 수행되며, 대부분 암호화폐 거래의 유동성 수단으로만 활용되고 있다. 더욱이 미국 달러를 제외한 다른 법정화폐의 경우, 스테이블코인 시장은 규모 측면에서나 사용성 측면에서나 더욱 준비가 되지 않았다. TRM Labs(2025)에 따르면, 현재 법정화폐 기반 스테이블코인의 90% 이상이 USD에 페깅되어 있다. 왜 실제 경제에서의 활용은 제한적일까. 여러 이유가 있을 수 있겠지만, 가장 큰 이유 중 하나는 개인·기업·정부가 실생활에서 사용할 수 있는 스테이블코인 기반 인프라가 아직 부족하기 때문이다. 지금부터 디지털 자산이 실물 경제에서 널리 활용되기 위해 블록체인 인프라가 해결해야 하는 한계점들을 제시해 보겠다.

2.1 기존 개방형 블록체인의 한계

퍼블릭 블록체인은 전 세계 누구나 계정을 만들고, 자산을 전송하고, 스마트 컨트랙트를 배포할 수 있는 개방형 금융 OS다. 전통 금융 인프라에서는 은행·카드사 등 중개 기관만이 제공하던 상품과 기능을, 퍼블릭 블록체인 인프라에서는 누구나 코드로 구현해 배포할 수 있다. 또한, 블록체인의 특성인 오픈소스(Open Source), 상호호환성(Interoperability), 조합성(Composability)을 활용해, 완전히 새로운 형태의 금융·비금융 서비스가 빠르게 시장에 등장했다. 이더리움·EVM 생태계를 기준으로 보면, 온체인 자산 거래, 디파이 대출·파생상품, NFT·게임, 실세계자산(RWA) 토큰화 등은 모두 이러한 개방성을 바탕으로 성장해 왔다. 하지만, “한국 원화 실물경제를 위한 인프라”의 관점에서 보면 차세대 금융 인프라인 블록체인도 다음과 같은 한계를 가진다:

프라이버시 부재: 모든 금융 활동 주체의 활동이 모두에게 공개되어, 개인적·사업적 프라이버시가 침해된다. 개인의 민감한 사생활이나 회사들의 사업 기밀인 비용구조 등이 모두 공개될 수 있는 상황에서 금융 활동 주체들이 블록체인을 사용할 유인이 없다.
실시간 규제 반영의 어려움: 익명성으로 인해, 특정 트랜잭션의 법적 관할이 어느 국가인지, 어떤 규정이 적용되는지 등을 실시간으로 판단하기 어렵다. 그로 인해 후행적인 AML, 제재 및 단속 중심의 규제가 일어날 수밖에 없다.
본인인증·자금세탁방지 연계의 구조적 제약: 주소가 곧 신원을 의미하지 않기 때문에, KYC/AML 요구사항을 네트워크 기본 규칙으로 일관되게 적용하기 어렵다. 특히 자동화된 거래 주체(AI 에이전트)가 등장할 경우, 소유자-에이전트 관계, 권한, 지출 한도 같은 통제 신호를 거래 단위로 함께 다루기는 더욱 어려워질 것이다.
규제 집행의 파편화: 특정 국가의 면허/허가, 한도·금지 대상, 의무 정보 전달(예: Travel Rule) 같은 로컬 규칙을 체인 공통 규칙으로 강제하기 어렵고, 결과적으로 앱/사업자별 구현에 의존해 집행이 파편화될 수 있다.

결국 기존 퍼블릭 체인은 실질 경제를 위한 금융 인프라의 기반이 되기에는 규제·책임 측면에서 한계가 분명하다.

2.2 기존 금융 인프라의 한계

반대로 기존 금융 인프라는 규제·감사·소비자 보호 측면에서 이미 견고한 프레임을 가지고 있으나, 프로그래머블 머니, 글로벌 상호운용성 측면에서는 제약이 크다. 은행 계좌·증권 계좌·카드망은 API를 통해 일정 수준 호환되지만 각각 별도의 원장으로 운영되어, 복잡한 케이스, 예를 들어 해외 송금·국경 간 결제는 높은 비용, 긴 처리 시간, 여러 단계의 중개 구조를 갖는다. 가장 단적인 예시는 카드·PG 기반 온라인 결제 구조다. 한국은 전 세계적으로 카드·간편결제 보급률이 매우 높은 나라지만, 그 대가로 가맹점이 부담하는 결제 수수료와 정산 지연이 발생한다. 가맹점 규모와 채널에 따라 결제 수수료는 0.4%에서 최대 3.5%까지 분포하고, 결제 후 실제 정산까지는 통상 3영업일이 소요되며, 환불 처리 비용 등이 더해지면서 소액·고빈도·국경 간 거래에는 구조적으로 잘 맞지 않는 형태다. 이에 대해 금융당국은 영세·중소가맹점 우대수수료율과 카드대금 지급주기(정산) 개선 등과 관련한 제도 개선을 발표·추진해 왔다. 이러한 구조와 더불어, 향후 자동화된 결제 주체(AI 에이전트 등)가 실시간으로 조건을 평가해 실행하는 고빈도·소액·조건부 트랜잭션 수요가 커질 경우, 현재 인프라의 수수료·정산 구조가 마찰 요인이 될 수 있다. 예컨대 소액 결제가 빈번하게 발생하는 자동화 시나리오에서는, PG 기반 구조에서 비용·정산 조건이 서비스 설계의 제약으로 작용할 가능성이 있다.

2.3 소결: 혁신과 규제를 동시에 만족하는 인프라

현재의 선택지는 이분법적으로 주어진다.

옵션 1: 규제를 완전히 수용하여 은행·중앙기관의 통제 하에서만 동작하는 인프라를 구축하고, 개방성·조합성·글로벌 개발자 생태계와 단절되는 방식
옵션 2: 혁신과 개방성에 올인하고 누구나 무엇이든 배포할 수 있는 퍼블릭 체인을 출시하되, 규제·감사·법적 책임과의 정합성을 희생하는 방식 결국 문제는 둘 중 하나를 선택하면 다른 쪽을 희생하게 된다는 점이며, 마루가 풀고자 하는 핵심 문제가 이것이다: “과연 규제와 혁신을 동시에 만족하는 인프라가 가능한가?“

2.4 프라이버시와 투명성의 딜레마

블록체인은 태생적으로 투명한 원장이다. 그러나 실제 금융·상거래·개인 자산 환경에서는 개인별 자산·소비 패턴의 프라이버시 보호, 기업의 영업기밀·거래 관계 보호, 규제기관의 감사·조사 권한이 모두 중요하다. 완전 투명 체인에서 모든 거래 내역이 모두에게 공개된다면 프라이버시·경쟁·보안 측면의 문제가 발생하고, 반대로 규제기관조차 내용을 볼 수 없는 완전 비공개 체인은 자금세탁·불법행위·소비자 보호 측면에서 심각한 리스크를 낳는다. 마루가 지향하는 것은 이 사이에서 일반 사용자는 자신의 생활·자산에 대해 충분한 프라이버시 보호를 누리되, 상위 레벨의 기관·발행사·공공 주체로 갈수록 더 큰 수준의 투명성과 책임을 요구하는 위계적 투명성 모델이다. 개인정보는 기본적으로 누구도 열람할 수 없도록 설계하되, 주관적 판단이 아닌 체인 거버넌스에서 사전에 합의된 객관적 기준에 따라서만—미리 정의된 주체에게, 정의된 범위 내에서—제한적으로 공개되는 구조라면, 오히려 법 집행 과정의 객관성과 투명성을 극대화할 수 있다. 나아가 이러한 규칙이 스마트 컨트랙트로 구현되어 trustless하게 작동한다면, 기술적으로도 그 객관성과 투명성을 담보할 수 있다.

2.5 AI 에이전트 시대, 금융 인프라의 새로운 요건

마루가 “미래를 위한 금융 인프라”로 설계되는 또 하나의 축은 AI 에이전트의 등장을 전제로 한다. 이미 글로벌 빅테크와 핀테크 회사들은 에이전트가 사용자를 대신해 상품을 탐색·비교·구매까지 수행하는 구조를 본격적으로 도입하고 있다. OpenAI는 2025년 9월 Stripe와 협력해 ChatGPT 내 결제를 지원하는 ‘Instant Checkout’을 출시했고, Google은 Mastercard·PayPal 등과 함께 Agent Payments Protocol(AP2)을 발표했다. Amazon은 자체 ‘Buy For Me’ 기능을 테스트 중이며, Visa와 Mastercard는 AI 에이전트 전용 결제 인프라를 구축해 2026년 상용화를 준비하고 있다. 한편 Coinbase는 Cloudflare와 함께 HTTP 402 상태 코드를 활용한 x402 프로토콜을 공개해, AI 에이전트가 스테이블코인으로 API·콘텐츠 비용을 자율 결제할 수 있는 인프라를 제시했다. 전통 자산이 온체인 자산·프로토콜과 결합되어, AI가 직접 자산을 보유·운용하며 경제 주체로 참여하는 시나리오가 빠르게 현실화되고 있다. 이처럼 AI가 결제 등 금융 활동의 주체가 되면서, 사람 중심으로 설계된 기존 인프라는 기능적 한계에 다다르고 있다. 첫째, Agent Identity 검증(KYA, Know Your Agent)이다. 이 에이전트는 누가 만들었고, 누구를 대신해 행동하는가? 기존 KYC가 ‘고객 신원 확인’에 집중했다면, 에이전트 시대에는 에이전트 자체의 신원, 개발자/운영 주체, 그리고 위임 관계까지 검증 가능해야 한다. 이를 통해 에이전트 행동에 대한 법적·재정적 책임 귀속이 명확해진다. 둘째, 권한 위임과 최소 권한 원칙(Scoped Delegation)이다. 에이전트는 사용자의 신원 정보, 결제 수단, 금융 자산에 접근할 수 있다. 그러나 특정 작업에 필요한 최소한의 정보·자산·권한만 위임하고, 금액 한도·거래 대상·유효 시간 등을 사전에 정의해 통제할 수 있어야 한다. 위임 범위를 벗어난 행동은 기술적으로 차단되어야 한다. 셋째, 실시간 모니터링과 즉시 제재(Real-time Revocation)이다. 에이전트의 비정상 행동을 실시간으로 탐지하고, 악성 에이전트나 탈취된 에이전트의 권한을 즉시 철회·차단할 수 있는 메커니즘이 필요하다. 넷째, 감사 추적과 투명성(Audit Trail)이다. 에이전트가 수행한 모든 거래에 대해 ‘누가, 누구를 대신해, 어떤 권한으로, 무엇을 했는지’를 투명하게 기록해, 사후 검증과 분쟁 해결, 규제 준수가 가능해야 한다. 그러나 기존 블록체인의 계정 구조는 ‘하나의 개인키가 하나의 계정을 전적으로 통제’하는 방식이다. 이 구조에서는 AI 에이전트에게 제한된 권한만 위임하거나, 소유자-에이전트 관계를 온체인에서 명시적으로 표현하기 어렵다. 또한 기존 퍼블릭 체인은 에이전트의 신원을 검증하거나, 위임 범위를 벗어난 행동을 기술적으로 차단하거나, 비정상 행동 시 권한을 즉시 철회하는 메커니즘을 프로토콜 수준에서 제공하지 않는다. 결국 KYA, Scoped Delegation, 실시간 제재, 감사 추적 같은 통제 장치를 계정·프로토콜 수준에서 유연하게 적용하기에는 구조적 한계가 있다.

3. 관련 프로젝트 및 비교

글로벌 블록체인 인프라 플레이어들은 “규제·프라이버시·개방성을 동시에 만족하는 디지털 인프라”를 각자 다른 방식으로 정의하고 있다. 2024-2025년을 기점으로 스테이블코인 전용 체인, 규제 친화적 기반/확장 블록체인(L1/L2), 결제 최적화 네트워크 등이 빠르게 등장하고 있다. 이들은 공통적으로 “기존 개방형 블록체인의 한계를 어떻게 극복할 것인가”라는 질문에 답하고 있다.

접근 방식은 크게 세 가지로 나뉜다. 첫째, 결제에 쓰이는 자산 유형과 수수료 단위, 정산 규칙, 규제 준수 정책 등 결제 인프라의 핵심 요소를 개별 앱이 각자 구현하게 두지 않고 프로토콜 레벨에서 표준화해 일관성을 확보하는 방식이다. 둘째, 거래 실행 단계에서 규제 검증을 한 묶음으로 처리(원자적 집행)하여 조건 미충족 시 거래 자체를 자동 취소(revert)하는 방식이다. 셋째, 별도의 네이티브 토큰 경제를 운영하면서 결제 최적화 기능을 함께 제공하는 혼합형 방식이다.

3.1 비교 프레임워크

마루는 여섯 개 비교 축을 제안하고, 각 축별 선택이 만드는 상충 관계를 비교한다.

(1) 체인 아키텍처와 거버넌스: 최종 결제와 정책 집행이 체인 내부에서 독립적으로 결정되는지, 외부 체인에 의존하는지. 합의·업그레이드·규제 준수 파라미터 변경에 누가 참여할 수 있는지.
(2) 네트워크 경제 구조: 수수료 정책, 검증자(밸리데이터) 인센티브, 네트워크 지속 가능성 모델.
(3) 규제 준수·신원 통합 방식: 규제 준수를 앱이 자율적으로 구현하도록 할지, 프로토콜에서 강제할지.
(4) 프라이버시 설계: 완전 익명 vs 규제/감사와 양립 가능한 선택적 솔루션.
(5) AI·에이전트 대응: 에이전트가 결제에 참여할 때의 통제와 책임 설계.
(6) 개발자 경험·인프라 성숙도: 이더리움 가상머신(EVM) 호환성, 개발 도구, 문서화 수준.

3.2 축별 상충 관계 분석

(1) 체인 아키텍처와 거버넌스

결제/정산 인프라에서 가장 먼저 갈리는 지점은 최종 결제와 정책 집행이 체인 내부에서 독립적으로 결정되는지, 외부 기반 체인에 의존하는지다.

독립적인 기반 블록체인(레이어 1)을 택하는 진영은 빠른 거래 확정(finality)과 예측 가능한 결제 레일을 강조한다. 이더리움 위에 구축되는 확장 블록체인(L2)은 기반 체인의 보안을 물려받지만, 합의 규칙·업그레이드·규제 준수 파라미터 변경 등 핵심 정책 결정에서 구조적 제약을 받을 수 있다.

국가 단위 가치 연동 코인(스테이블코인) 인프라를 목표로 할 경우, 규제기관·은행 컨소시엄·기술 운영사 등 다양한 이해관계자가 거버넌스에 직접 참여해야 한다. 외부 체인 규칙에 종속되는 확장 블록체인(L2) 구조보다, 독립적인 거버넌스 설계가 가능한 기반 블록체인(Layer 1)이 더 적합할 수 있다.

(2) 네트워크 경제 구조

두 번째 분기점은 수수료·정산·회계의 단위를 무엇으로 통일하는가, 그리고 네트워크가 가격 변동성이 큰 토큰에 얼마나 의존하는가다.

Arc는 USDC를 수수료 단위로 둬서 비용 인지를 안정 단위로 정렬하는 설계를 전면에 내세운다. Codex는 수수료 단위가 ETH라서 가격 변동 부담을 사용자에게 전가한다. Stable이나 Plasma처럼 “사용자 경로는 가치 연동 단위로 단순화”하되 네트워크 보안·거버넌스는 별도 토큰 경제와 결합하는 혼합형도 있다.

마루는 KRW 단일 단위로 비용 인지가 완결되는 구조를 지향한다. 수수료는 네트워크 혼잡에 따라 급변하기보다 예측 가능하게 운영되어야 한다.

(3) 규제 준수·신원 통합

Codex는 입출금과 검증을 거래·실행 규칙으로 묶어 실행 단계에서 한 묶음으로 처리(원자적 집행)(실패 시 자동 취소)하는 방식을 쓴다. Tempo는 정책 저장소와 토큰 표준을 통해 전송 단계에서 정책 강제를 표준화하고 있다. Arc/Stable은 발행사·기관 친화 규제 준수/보고 방향성이 강하지만, 표준 기본 요소가 어떻게 노출되는지에 따라 앱 재사용성이 크게 달라진다.

마루는 규제 경로에서 신원·정책 검증이 일관되게 집행되고, 앱들이 공통 인터페이스로 재사용할 수 있는 프로토콜 레벨의 규제 준수 모듈(PCL)을 제공한다.

(4) 프라이버시 설계

프라이버시는 “완전 익명”보다 규제/감사와 양립 가능한 선택적 솔루션으로 재정의되는 흐름이 강하다.

Stable은 비공개 전송(confidential transfers)을 프로토콜 레벨 기능으로 포함한다고 명시한다. Plasma는 선택적·감사 가능한 비공개 결제(Confidential Payments) 모듈을 내세운다. Tempo와 Arc도 선택적 공개(감사 가능성)와 결합된 선택적 프라이버시 도입 계획을 제시한다.

마루가 원하는 프라이버시는 공개 여부의 이분법이 아니다. 결제/정산 같은 민감 흐름에서 선택적 비공개 + 선택적 공개가 함께 성립하고, 앞으로 발전할 프라이버시 기술을 기민하게 지원하는 것이다.

(5) AI·에이전트 대응

에이전트가 결제 시스템에 참여하면 핵심 과제는 자동화 자체보다 통제와 책임이 된다.

Tempo는 수수료 대납(sponsorship)·일괄 처리(batching)·예약 실행(scheduling)·위임키/한도 같은 기능을 거래 계층에 가깝게 끌어올려 “자동화 기본기”를 신속하게 제공한다. 하지만 대부분의 프로젝트는 에이전트 방향성을 언급하더라도 책임·신원(KYA)까지 체계화하진 않는다.

마루는 실사용 결제에 필요한 세션/위임키·지출 한도·정책 기반 승인 등을 표준화하면서, 규제 경로에서 책임을 다루기 위한 에이전트 신원 검증(KYA, Know Your Agent)과 감사 가능한 증빙까지 함께 설계한다.

(6) 개발자 경험 & 인프라

결제 체인은 “이더리움 가상머신(EVM) 호환”만으로 끝나지 않는다. 개발자 경험(DX)이 완성도를 좌우한다.

Codex는 OP Stack 기반으로 기존 개발 도구의 재사용성을 내세운다. Arc는 EVM differences 형태로 체인 스펙과 표준 EVM 간 차이를 문서화해 개발자가 “어디가 다른지” 신속하게 이해하도록 돕는다. Tempo는 “네이티브 토큰 없음” 같은 실무 함정을 가이드로 다룬다.

마루는 KRW 중심(KRW-first) EVM을 기본으로 개발 도구가 최대한 그대로 동작하게 한다. KRW 수수료·규제 준수·프라이버시·에이전트 기능처럼 달라지는 지점은 문서/SDK로 명확히 노출한다. 테스트넷·탐색기(Explorer)·인덱싱·모니터링 같은 인프라와 규제/감사를 위한 관측 가능성(observability)을 초기부터 제공하는 것이 목표다.

3.3 비교 요약표

비교 축	Maroo	Tempo	Arc	Codex	Plasma	Stable
(1) 체인 아키텍처와 거버넌스	Strong	Strong	Strong	Partial	Strong	Strong
(2) 네트워크 경제 구조	StrongOKRW Native	StrongStablecoin Gas	StrongUSDC Gas	WeakETH Gas	Partial	Partial
(3) 규제 준수·신원 통합	StrongDual Track + PCL	Partial	Partial	Strong	Weak	Partial
(4) 프라이버시 설계	StrongVerifiable Privacy	Partial	Partial	Weak	Partial	Partial
(5) AI·에이전트 대응	StrongKYA + Agent Verification	Strong	Partial	Weak	Weak	Weak
(6) 개발자 경험 & 인프라	StrongKRW-first EVM	Partial	Strong	Partial	Partial	Partial

Strong 강점 Partial 부분적 Weak 미비

4. 마루 설계 원칙

4.1 설계 목표와 원칙

마루의 목표는 한 문장으로 요약된다.

“한국 원화 경제를 위한, 규제 친화적이면서도 개방형인 기반 블록체인(Layer 1) 인프라”

마루는 다음 원칙으로 설계하였다.

KRW 네이티브 블록체인

마루에서는 모든 수수료를 원화 가치 연동 코인(OKRW)으로 지불한다. 이중 가격 변동 위험을 없애고 원화 기반 디지털 경제의 선순환을 만든다.

요구사항 1. 단일 네이티브 자산

체인의 네이티브 자산은 OKRW 하나다.
모든 수수료는 OKRW로 지불하고, 별도의 거버넌스/유틸리티 토큰은 없다.

요구사항 2. 원화 기반 안정적 수수료 구조

사용자와 개발자는 모든 블록체인 비용을 KRW 단위로 인식할 수 있어야 한다.
가격 변동성이 큰 토큰 가격에 의존하지 않는, 원화 기반의 안정적이고 예측 가능한 수수료 구조를 제공한다.

요구사항 3. 생태계 연동 성장

마루 생태계의 거래 증가가 OKRW 수요 및 유통량 증가로 자연스럽게 이어지는 구조다.
블록체인 활동과 원화 기반 디지털 경제가 함께 성장하는 선순환을 설계한다.

개방적이되 규제를 준수(Public, but Regulated)

마루는 누구나 지갑을 만들고 거래를 보낼 수 있는 개방형 블록체인이다. 다만 규제 경로(Regulated Path)와 개방 경로(Open Path)를 나눠 처리한다.

요구사항 4. 퍼블릭 접근성

누구나 지갑을 만들고 거래를 보낼 수 있는 개방형 블록체인으로 운영한다.
지갑 생성·사용에 사전 허가를 요구하지 않는다.

요구사항 5. 듀얼 트랙 거래 경로

규제 경로(Regulated Path)는 사전 승인과 규제 준수 검증을 거치는 거래 경로다.
개방 경로(Open Path)는 별도 사전 승인 없이 전송되는 일반 거래 경로다.
두 경로는 체인 레벨에서 명시적으로 태깅돼 구분된다.

요구사항 6. 독립적 거버넌스

주요 참여사 및 생태계가 합의·업그레이드·규제 준수 로직에 직접 참여할 수 있는 구조다.
법령 및 규제가 체인 레벨에서 기술적으로 적용될 수 있게 한다.

프로그램 가능한 규제 준수 계층(Programmable Compliance Layer, PCL)

마루는 금액·국가·본인인증 상태(KYC/KYB/KYA)·제재 리스트·국제 송금 정보 공유 규정(Travel Rule) 등을 기반으로, 거래 단위에서 코드로 작성된 규제 준수 로직을 평가·적용한다.

요구사항 7. 동적 규제 파라미터

금액·국가·본인인증 상태(KYC/KYB/KYA)·제재 리스트·Travel Rule 등 규제 요건을 코드로 정의한다.
규제 파라미터는 실제 법률 및 규제 요건이 반영된 법률 오라클(Legal Oracle)을 통해 블록체인에 공급되며, 법·정책 변화에 따라 동적으로 업데이트된다.

요구사항 8. 거래 단위 평가

PCL은 규제 경로(Regulated Path) 거래를 실행 단계에서 평가해 허용·거절을 결정한다.
정적인 블랙리스트·화이트리스트를 넘어, 복합 조건을 실시간으로 검증한다.

요구사항 9. 개발자 재사용성

PCL이 참조하는 파라미터 구조와 조회 인터페이스를 SDK로 제공한다.
개별 서비스가 복잡한 규정을 직접 파싱하지 않고도 규제 준수 로직을 구현할 수 있어야 한다.

검증 가능한 프라이버시(Verifiable Privacy)

마루는 보내는 사람·받는 사람, 금액, 자산 종류 등의 공개 범위를 상황에 따라 선택할 수 있도록 설계해, 프라이버시와 규제 요구 사이의 균형을 맞춘다.

요구사항 10. 선택적 비공개

보내는 사람·받는 사람, 금액, 자산 종류 등의 공개 범위를 상황에 따라 선택할 수 있도록 설계한다.
완전 공개와 완전 비공개 사이에서 필요에 맞는 프라이버시 수준을 적용할 수 있다.

요구사항 11. 검증 가능한 규제 준수

영지식 증명(ZKP, 민감 정보를 공개하지 않고도 특정 조건을 만족함을 수학적으로 증명하는 기술) 등을 활용해, 민감 정보를 공개하지 않고도 규제 요건을 만족한다는 사실을 검증 가능하게 만든다.

요구사항 12. 통제된 열람 경로

규제기관·감시용 노드(Observer Node)는 사전 정의된 절차와 범위 제한 하에서 필요한 데이터를 열람할 수 있다.
일반 사용자끼리의 거래는 과도하게 노출되지 않도록 설계한다.

AI 에이전트 친화적 설계

마루는 에이전트 신원 검증(KYA, Know Your Agent)을 통한 에이전트 검증 체계를 제공한다. AI가 자율적으로 실행하는 경제 활동에 대한 책임소재와 한도를 함께 정의한다.

요구사항 13. 에이전트 신원 검증(KYA)

AI 에이전트의 신원, 소유자(Owner), 권한 범위를 블록체인에서 검증 가능하게 한다.
에이전트–소유자 관계를 명시적으로 기록해 법적 책임 귀속을 명확히 한다.

요구사항 14. 위임 및 한도 관리

접근 권한 및 위임 범위를 명확히 설계해, 에이전트가 수행할 수 있는 작업 범위를 제한한다.
지출 한도(Spending Limit), 세션 키, 정책 기반 승인 등 다층적 한도 시스템을 제공한다.

요구사항 15. 제재 메커니즘

악의적 에이전트나 탈취된 에이전트의 권한을 즉시 철회·차단할 수 있는 메커니즘을 제공한다.
에이전트 레벨 제재와 소유자 레벨 일괄 제재를 모두 지원한다.

4.2 기반 블록체인(Layer 1) vs. 확장 블록체인(Layer 2)

블록체인 인프라를 설계할 때, 독립적인 기반 블록체인(Layer 1)으로 구축할지 기존 기반 블록체인 위에 확장 블록체인(Layer 2)으로 구축할지는 초기에 결정해야 하는 핵심 아키텍처 선택이다. 이 결정은 거버넌스 구조, 규제 적용 방식, 개발 환경에 직접 영향을 미친다.

독립적 거버넌스와 규제 적용

일반적인 이더리움 확장 블록체인(L2)은 데이터 가용성(DA)과 최종 결제(final settlement)를 이더리움에 위임한다. 대신 거래 순서 결정·블록 생산(시퀀서, Sequencer)과 수수료 정책 등은 개별 운영자 권한에 의존하는 구조가 많다. 이더리움의 보안성을 활용할 수 있지만, 주요 참여사와 생태계가 합의·파라미터·업그레이드에 직접 참여하는 구조를 설계하기엔 제약이 있다.

마루는 “어떤 주체가 검증자(밸리데이터) 역할을 맡을지”, “누가 법률 오라클(Legal Oracle)과 PCL 파라미터를 업데이트할지”, “이상 거래 발생 시 누가 어떤 절차로 개입할지” 같은 의사결정을 체인 레벨에서 일관된 거버넌스 아래 설계해야 한다. 외부 체인 규칙에 종속되지 않는 독립적인 기반 블록체인(Layer 1) 구조를 채택한 이유다.

이더리움 가상머신(EVM) 호환성과 개발자 경험

독립적인 기반 블록체인(Layer 1)을 선택하더라도 이더리움 가상머신(EVM) 호환 실행 환경을 채택하면, 확장 블록체인(Layer 2)이 제공하는 주요 장점을 유지할 수 있다. 마루는 솔리디티(Solidity) 기반 스마트 컨트랙트를 배포·실행할 수 있다. OKRW는 EVM의 네이티브 토큰과 유사하게 수수료 토큰으로 쓰여서 기존 EVM 개발 패턴을 그대로 적용할 수 있다. Hardhat, Foundry 등 기존 이더리움 생태계의 개발 도구와 라이브러리를 활용할 수 있어, 개발자는 익숙한 환경에서 마루 체인 위에 애플리케이션을 구축하거나 기존 컨트랙트를 옮겨올 수 있다. Identity, PCL, Privacy Layer 등 마루의 핵심 모듈은 블록체인 기본 내장 기능(Precompile) 형태로 제공돼, 표준 EVM 개발 방식을 유지하면서도 마루의 규제 친화적 기능을 활용할 수 있다.

요약하면, 마루는 이더리움이 제공하는 글로벌 보안 모델을 부정하는 것이 아니다. 주요 참여사와 생태계가 합의와 규제 준수 로직에 직접 참여해야 한다는 요구와, EVM 호환성을 통한 개발자 경험을 함께 확보하기 위해 독립적인 기반 블록체인(Layer 1) 구조를 선택하였다.

5. 플랫폼 아키텍처

5.1 핵심 구성요소

앞서 정의한 설계 원칙을 실현하기 위해, 마루는 다섯 가지 핵심 모듈을 중심으로 플랫폼을 구성한다. 마루 코어(합의·실행·OKRW), 신원·인증 계층, 규제 준수 계층, 프라이버시 계층이 유기적으로 작동하며, 이를 지원하는 노드 인프라가 네트워크를 구성한다. 아래 다이어그램과 표는 이 구성요소들이 어떻게 연결되어 최종 사용자, 기관, AI 에이전트에게 서비스를 제공하는지 보여준다.

%%{init: {"theme": "base"} }%%
flowchart TB
    subgraph Users["End Users & Institutions"]
        U1["Individuals / Merchants"]
        U2["Banks / Financial Institutions"]
        U3["AI Agents"]
    end

    subgraph Access["Access Layer"]
        Apps["Wallets / Apps / Banking Apps"]
        API["SDK / API"]
    end

    subgraph Maroo["Maroo Core"]
        Cons["Consensus & Execution<br/>(BFT + EVM + OKRW)"]
        subgraph Modules["Core Protocol Modules"]
            ID["Identity & Authentication"]
            Compliance["Compliance Layer<br/>(PCL + Legal Oracle)"]
            PRIV["Privacy Layer"]
        end
    end

    subgraph Nodes["Node Roles"]
        Val["Validator Nodes"]
        Full["Full / RPC Nodes"]
        Obs["Observer Nodes"]
    end

    U1 --> Apps
    U2 --> Apps
    U3 --> Apps
    Apps --> API
    API --> Cons
    API --> ID
    API --> Compliance
    API --> PRIV
    Cons --> Val
    Cons --> Full
    Cons --> Obs

    style U1 fill:#64748B,stroke:#64748B,color:#fff
    style U2 fill:#64748B,stroke:#64748B,color:#fff
    style U3 fill:#64748B,stroke:#64748B,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff
    style API fill:#64748B,stroke:#64748B,color:#fff
    style Cons fill:#0096AA,stroke:#0096AA,color:#fff
    style ID fill:#0096AA,stroke:#0096AA,color:#fff
    style Compliance fill:#FF8C50,stroke:#FF8C50,color:#fff
    style PRIV fill:#0096AA,stroke:#0096AA,color:#fff
    style Val fill:#0096AA,stroke:#0096AA,color:#fff
    style Full fill:#0096AA,stroke:#0096AA,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff

구성요소	설명
마루 코어	BFT 합의(참여자 다수가 동의해야 블록이 확정되는 방식), EVM 실행 환경, OKRW 네이티브 통화
노드 역할	검증자 노드, 감시용 노드, 풀/RPC 노드로 구성된 네트워크 인프라
신원 & 인증 계층	본인인증(KYC/KYB/KYA) 정보와 관련된 인증 정보 저장·조회 인터페이스
규제 준수 계층	듀얼 트랙 거래 모델, PCL(프로그램 가능한 규제 준수 계층), 법률 오라클
프라이버시 계층	거래 필드별 공개 범위 설정 및 영지식 증명(ZKP) 등 암호학적 보호 메커니즘

5.2 마루 코어

마루 코어는 네트워크의 합의, 실행 환경, 네이티브 통화를 포괄하는 기반 계층이다.

5.2.1 네트워크 및 합의

마루는 금융 인프라 특성상 즉각적인 거래 확정(instant finality)을 요구한다. 오랜 시간 검증된 BFT 계열 합의 알고리즘(참여자 다수가 동의해야 블록이 확정되는 방식, 예: Tendermint/CometBFT 등)을 기반으로 한다. 네트워크는 기록이 갈라지는 일(fork)이 없고, 거래가 확정되면 번복되지 않는 특성을 갖게 된다.

국가 인프라임을 감안해, 최대 수십 개 수준의 검증자(Validator) 세트를 가정한다. 전원 한국 리전 온쇼어 배치가 기본 전제다.

성능 목표:

95% 이상의 케이스에서 거래 전송부터 확인까지 1초 이내
월간 수천만 건 거래 처리
피크 시 이론적 10,000 TPS(초당 거래 수) 급 트래픽 처리
비공개 거래 포함 비율에 따라 1,000-5,000 TPS 정도의 성능 보장

5.2.2 실행 환경

마루는 개발자 경험을 위해 이더리움 가상머신(EVM) 호환 실행 환경을 목표로 한다. 솔리디티(Solidity) 기반 스마트 컨트랙트를 배포·실행할 수 있다. OKRW는 EVM의 네이티브 토큰(ETH)과 유사한 감각으로 수수료 토큰으로 쓰인다.

블록체인 기본 내장 기능(Precompile) / 코어 모듈

Identity, PCL, Privacy, Legal Oracle 등은 EVM 컨트랙트에서 호출 가능한 형태로 노출한다. 성능·보안 상 필요한 경우 코어 레벨(블록체인 기본 내장 기능 또는 모듈) 구현을 고려한다.

개발자 도구 호환성

Hardhat, Foundry 등 기존 이더리움 생태계의 개발 도구와 라이브러리를 활용할 수 있어, 개발자는 익숙한 환경에서 마루 체인 위에 애플리케이션을 구축하거나 기존 컨트랙트를 옮겨올 수 있다.

병렬 실행

추후 거래 간 의존성 분석을 통해 병렬 실행이 가능한 실행 엔진으로 교체하는 옵션을 열어 둔다.

5.3 노드 역할

네트워크를 실제로 작동시키는 노드는 크게 세 가지 유형으로 나뉜다.

검증자 노드(Validator Node)

블록 제안·검증 및 합의 참여를 담당한다. 프로토콜 업그레이드·파라미터 변경 투표 주체가 된다.

감시용 노드(Observer Node, 규제기관용)

합의에는 참여하지 않는다. 규제기관·감독기구의 뷰에서 전체 거래 흐름에 접근하는 노드로, 데이터 조회용 대시보드·규제기관 전용 탐색기(Explorer) 등에 연결된다. 비공개 거래 여부와 관계없이, 사전 정의된 절차를 통해 필요한 정보를 복호화·열람할 수 있다.

풀/RPC 노드

일반 사용자·서비스·개발자를 위한 RPC·쿼리 인터페이스를 제공한다. 읽기 위주 요청이 많으면 풀/RPC 노드를 수평 확장해 트래픽을 분산시킨다.

5.4 신원 및 계정 모델

5.4.1 미인증 계정 vs 인증 계정

마루는 기본적으로 개방형 블록체인이다. 다만 경제 활동에 참여하는 주체 특성에 따라 계정을 두 가지 타입으로 구분한다. 실제 경제 활동에 참여할 수 있는 계정은 1차적으로 미인증 계정(Unknown)과 인증 계정(Known)으로 나뉜다.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Wallets["Accounts on Maroo"]
        Addr("Wallet Address<br/>(ECDSA / AA etc.)")
        Unknown("Unknown Account<br/>(No KYC/KYB/KYA)")
        KnownInd("Verified Individual<br/>(KYC Level N)")
        KnownCorp("Verified Corporation<br/>(KYB Level N)")
        KnownAgent("AI Agent Account<br/>(Linked to Owner)")
    end

    subgraph IdentityOff["Off-chain Identity Providers"]
        KYCProv("KYC Provider")
        KYBProv("KYB Provider")
        KYAProv("KYA / Agent Provider")
    end

    subgraph IdentityOn["On-chain Identity Layer"]
        IdContract("Identity & Auth<br/>Smart Contract")
    end

    Apps("Apps / Banks /<br/>Public Services")

    Addr -->|"Create Wallet"| Unknown
    Unknown -->|"1. KYC Request"| KYCProv
    KYCProv -->|"2. KYC Verification<br/>(On-chain)"| IdContract
    IdContract -->|"3. Status: KYC Done"| KnownInd
    Unknown -->|"1. KYB Request"| KYBProv
    KYBProv -->|"2. KYB Verification"| IdContract
    IdContract -->|"3. Status: KYB Done"| KnownCorp
    KnownInd -->|"Agent Registration"| KYAProv
    KYAProv -->|"Agent Verification"| IdContract
    IdContract -->|"Owner ↔ Agent Link"| KnownAgent
    Apps -->|"Query Identity/Level"| IdContract
    IdContract -->|"isVerified,<br/>expirationDate etc."| Apps

    style Addr fill:#64748B,stroke:#64748B,color:#fff
    style Unknown fill:#64748B,stroke:#64748B,color:#fff
    style KnownInd fill:#64748B,stroke:#64748B,color:#fff
    style KnownCorp fill:#64748B,stroke:#64748B,color:#fff
    style KnownAgent fill:#64748B,stroke:#64748B,color:#fff
    style KYCProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style KYBProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style KYAProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style IdContract fill:#0096AA,stroke:#0096AA,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff

미인증 계정

본인인증(KYC/KYB/KYA)을 하지 않은 일반 지갑이다. OKRW 수수료 사용, 거래 전송, 컨트랙트 배포 모두 가능하다.
다만 듀얼 트랙 구조에 따라 규제 경로(Regulated Path)나 특정 금융·공공 서비스 사용 시 개별 서비스 정책에 따라 추가 인증이 필요할 수 있다.

인증 계정

본인인증(KYC/KYB/KYA)을 통해 신원이 검증된 계정이다. 실제 정책·서비스에 따라 다음과 같은 하위 타입으로 구분될 수 있다.
- 개인(Individual) 계정
- 법인(Corporate) 계정
- 특수 목적 계정(예: AI 에이전트, 봇 등)

이 모델을 통해 체인 자체는 지갑 생성·사용을 제한하지 않는 비허가형을 유지하면서, 규제·금융 서비스는 인증 계정을 전제로 동작하게 했다.

5.4.2 KYC/KYB/KYA 체계

KYC (Know Your Customer, 고객 신원 확인): 개인 신원 검증
KYB (Know Your Business, 기업 신원 확인): 법인·기관 신원 검증
KYA (Know Your Agent, 에이전트 신원 확인): AI 에이전트 및 자동화된 계정(봇) 검증. 인증된 자동화 주체의 공개 등록부 역할

먼저 오프체인에서 공인된 신원인증 서비스·기관이 검증을 수행한다. 이후 온체인에는 “이 주소는 레벨-2 KYC, 만료일 YYYY-MM-DD”와 같은 인증 정보(Verifiable Credential) 형태의 결과만 저장된다. 생성(Create), 업데이트(Update), 폐기(Delete) 등의 주요 액션은 다중 서명(Multi-sig) 또는 별도 거버넌스 정책 하에 관리한다.

5.4.3 AI 에이전트 계정 모델

AI 에이전트의 온체인 정의는 이더리움 커뮤니티에서 제안된 ERC-8004(AI Agent Registry)와 유사한 방향성을 참고하되, 마루의 규제·은행 컨소시엄 구조와 정합성을 맞추는 게 목표다. 단순한 “에이전트 등록부 + 소유자 주소” 모델로 시작하며, 표준·레퍼런스가 성숙해지는 시점에 맞춰 호환성을 확보한다.

소유자 주소(Owner Address)

각 에이전트는 반드시 사람(개인) 혹은 법인 계정을 소유자로 가져야 한다.

에이전트 등록부(Agent Registry)

온체인 등록부를 둬서 에이전트 주소, 소유자 주소, 권한·한도(지출 한도 등), 적용되는 KYA 레벨 등을 조회할 수 있게 한다.

제재 메커니즘

특정 에이전트가 악의적 행위를 하면 해당 에이전트만 정지하거나, 소유자 수준에서 해당 소유자가 소유한 모든 에이전트를 일괄 정지하는 정책 등 선택지를 제공한다.

5.4.4 온체인 신원 인터페이스

온체인 신원 모듈은 추후 다음과 같은 형태의 인터페이스를 제공할 수 있다.

입력: (type, address)

type = 0 → 개인(Individual)
type = 1 → 법인(Corporate)
type = 2 → AI 에이전트 등

출력: (isVerified, expirationDate)

isVerified는 현재 시점에서 해당 주소가 요구되는 수준의 본인인증(KYC/KYB/KYA)을 충족하는지 여부
expirationDate는 재인증·갱신이 필요해지는 시점

예시로, 어떤 금융 앱이 “인증 후 6개월이 지난 계정은 100만 원 이상 거래 전에 재인증을 요구”하는 UX를 구현하고 싶다면, 앱은 거래 직전에 신원 인터페이스를 조회해 expirationDate를 확인한다. 만료된 경우 앱 레벨에서 추가 인증 플로우를 띄운 뒤 규제 경로(Regulated Path) 거래를 생성할 수 있다. 이렇게 하면 체인 레벨 신원과 서비스 레벨 UX를 느슨하게 결합하면서도, 규제 요구사항을 충족하는 지갑 서명 기반 인증(예: Sign-In with Ethereum) 등의 패턴을 구현할 수 있다.

5.5 거래 모델 및 규제 준수

5.5.1 듀얼 트랙 거래 모델

마루의 거래 모델은 규제·감사 요구와 개방성을 동시에 다루기 위해 두 가지 경로로 설계했다.

%%{init: {"theme": "base", "themeVariables": {"actorBkg": "#64748B", "actorTextColor": "#fff", "actorBorder": "#64748B"}} }%%
sequenceDiagram
    participant U as User
    participant App as Maroo App
    participant PCL as PCL
    participant Chain as Maroo L1
    participant Obs as Observer

    rect rgba(255,140,80,0.15)
        Note over U,Chain: Regulated Path
        U->>App: 1) Payment Request (with Identity)
        App->>PCL: 2) Pre-screening (KYC status, limits)
        PCL-->>App: 3) Approval + Auth ID
        App->>Chain: 4) Tx + Auth ID (Tag: Regulated)
        Chain-->>Obs: 5) Metadata (Regulated Stream)
    end

    rect rgba(100,116,139,0.15)
        Note over U,Chain: Open Path
        U->>App: 1') General Tx Request
        App->>Chain: 2') Tx (Tag: Open)
        Chain-->>Obs: 3') Metadata (Open Stream)
    end

규제 경로(Regulated Path)

사전에 PCL/규제 준수 엔진을 통과한 거래만 허용된다.
승인 증명(인증·proof)을 거래 데이터에 포함한다.
체인 레벨에서 명시적으로 Regulated 플래그를 부여받는다.

개방 경로(Open Path)

별도 신고·승인 없이 전송 가능한 일반 거래다.
체인 레벨에서 Open / 미신고 흐름으로 태깅된다.
감시자/분석 시스템에서 모니터링 및 사후 제재 대상이 된다.

이 구조의 실질적인 장점은 두 가지다.

(1) 실험과 혁신의 공간 확보 스타트업·개발자는 개방 경로(Open Path) 위에서 비교적 자유롭게 새로운 금융·비금융 서비스를 실험할 수 있다. 점차 규제 요건을 충족해 나가면서 규제 경로(Regulated Path)로 이동하는 경로를 택할 수 있다.

(2) 규제·제도권의 명확한 기준 제공 은행·증권사·공공기관 등은 “규제 경로로 처리된 거래만 공식 기록으로 인정한다”고 내부·대외 정책을 정의할 수 있다. 개방 경로에서 발생한 거래가 문제가 될 경우, 감시자·분석 인프라와 결합해 사후 추적·제재·회수를 수행할 수 있다.

결과적으로 마루는 “모든 활동을 본인인증/허가 구조 내에서만 허용하는 폐쇄형 인프라”와 “아무 제약이 없는 완전 개방형 블록체인” 사이에서, 두 계층을 동시에 제공하는 구조를 선택했다.

5.5.2 프로그램 가능한 규제 준수 계층(PCL)

PCL은 자체적으로 모든 규칙을 내장한 “거대한 스마트 컨트랙트”라기보다, 법률 오라클(Legal Oracle)이 공급하는 규제 파라미터를 읽어들여 실행되는 정책 엔진에 가깝다. 예를 들어 법률 오라클이 다음과 같은 값을 블록체인에 게시한다고 하자.

일반 사용자 일일 전송 한도: 1,000만 KRW
특정 국가·산업에 대한 송금 금지 목록
제재 리스트에 포함된 주소·법인 목록
특정 기간 동안만 유효한 임시 규정 등

PCL은 규제 경로(Regulated Path) 거래를 검증할 때 이 값을 참고해, 해당 거래가 허용 가능한지 여부를 결정한다. 규제가 바뀌어 파라미터가 변경되더라도, PCL의 기본 로직은 그대로 유지되며 법률 오라클 계층에서만 업데이트가 이뤄진다. “규제 파라미터 공급(오라클) – 정책 평가(PCL)“를 분리해서, 법·정책의 변화는 오라클 계층에서 빠르게 반영하면서도 체인의 공통 로직은 안정적으로 유지할 수 있다.

개발자와 서비스 사업자를 위해 다음과 같은 도구를 제공한다.

PCL이 참조하는 파라미터 구조를 명세한 SDK/라이브러리
“현재 Travel Rule 의무 금액”, “제한 국가·산업 리스트” 등을 조회할 수 있는 표준화된 조회 인터페이스

개별 서비스가 복잡한 규정을 직접 파싱하지 않고도, 마루의 규제 계층 위에서 애플리케이션 로직을 구현할 수 있게 한다.

5.5.3 법률 오라클(Legal Oracle)

법률 오라클은 법·규정의 변화를 블록체인으로 가져오는 인터페이스로, PCL이 참고하는 각종 규제 파라미터를 게시·갱신하는 역할을 한다.

입력 데이터 예시:

1회·1일·1개월 전송 한도
금지/제한 국가·산업 리스트
특정 기간 동안만 유효한 임시 규정(예: 특정 사태 발생 시 한시적 규제)
국제 송금 정보 공유 규정(Travel Rule) 적용 기준 금액 등

운영 주체: 법률 오라클 관리자로 지정된 엔티티들이다. 금융당국·은행 컨소시엄·지정 법률기관 등이 다중 서명(Multi-sig) 또는 별도 거버넌스 절차를 통해 참여하는 구성을 상정한다. 일정 수 이상의 서명이 모였을 때만 새로운 규제 파라미터가 블록체인에 반영되도록 설계해, 단일 기관의 임의 변경을 방지한다.

PCL은 항상 법률 오라클이 제공하는 최신 파라미터를 참조해 규제 경로(Regulated Path) 거래를 평가한다. 예를 들어 “현재 Travel Rule 의무 금액이 X KRW 이상으로 설정되어 있다”는 정보는 법률 오라클이 게시하고, PCL은 해당 기준을 만족하지 못한 거래를 자동으로 거절(revert)할 수 있다.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Gov["Off-chain Oracle Governance"]
        Reg("Regulators")
        FIs("Banks / Financial Institutions")
        Legal("Legal & Compliance Experts")
        Committee("Oracle Committee (Multi-sig)")
    end

    subgraph PolicyData["On-chain Policy Data"]
        Oracle("Legal Oracle Contract")
        Identity("Identity & Auth")
    end

    subgraph Enforcement["On-chain Enforcement & Usage"]
        PCL("Programmable Compliance Layer")
        Apps("Regulated Apps / Banks")
        Obs("Observer Nodes / Dashboard")
    end

    Reg -->|"1) High-level Rules"| Committee
    FIs -->|"2) Risk Limits"| Committee
    Legal -->|"3) Policy Draft / Interpretation"| Committee
    Committee -->|"4) Signed Parameter Update Tx"| Oracle
    Oracle -->|"5) Limits / Lists / Flags"| PCL
    Identity -->|"6) KYC / KYB / KYA Status"| PCL
    Apps -->|"7) Regulated Tx + Proof"| PCL
    PCL -->|"8) Allow / Reject / Tag"| Apps
    PCL -->|"9) Tx Classification / Risk Signal"| Obs
    Obs -->|"10) Supervisory Report"| Reg

    style Reg fill:#64748B,stroke:#64748B,color:#fff
    style FIs fill:#64748B,stroke:#64748B,color:#fff
    style Legal fill:#64748B,stroke:#64748B,color:#fff
    style Committee fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Oracle fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Identity fill:#0096AA,stroke:#0096AA,color:#fff
    style PCL fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff

법률 오라클과 PCL이 상호작용하는 방식(파라미터 포맷, 버전 관리, 조회 방식 등)에 대해 SDK와 예제 코드를 제공하여, 규제기관·은행·서비스 사업자가 동일한 규제 계층 위에서 애플리케이션을 구현할 수 있도록 지원한다.

5.5.4 이상 거래 대응 및 회수

마루는 해킹·피싱·명백한 불법 자금 흐름처럼, 현실 세계에서 사후 구제가 요구되는 상황을 완전히 외면하지 않는다. 다만 전체 체인을 되돌리는 롤백보다, 사전에 정의된 절차에 따라 제한된 범위에서 상태를 교정하는 프로토콜을 제공하는 방식에 가깝다.

가능한 조치는 상황에 따라 자산 동결(freeze), 불법 자산 소각(burn), 피해 구제를 위한 재발행(mint) 등으로 구성될 수 있다. 이 기능은 “상시 개입 장치”가 아니라, 법적 근거와 절차가 갖춰진 경우에만 작동하도록 설계한다. 모든 집행은 감사 가능하게 기록해 남용을 최소화한다.

기술적으로는 “과거를 지우는” 체인 롤백 대신, 새로운 거래를 통해 기존 상태의 효력을 제한/무효화하는 접근을 우선한다. 블록체인의 불변성을 가능한 한 유지하면서도, 결제 인프라가 현실의 법적 요구를 수용하기 위한 실용적인 절충안이다.

5.6 프라이버시 설계

마루는 KRW 기반 결제 인프라를 “블록체인 위에 올린다”는 전제를 갖는다. 일상 결제·급여·복지·P2P·AI 에이전트 결제처럼 현실 금융에서 민감도가 높은 흐름이 기본 사용 케이스다. 따라서 마루가 지향하는 프라이버시는 “모든 것을 숨기는 익명 체인”이 아니다. 열람 주체에 따라 원장의 가시성 수준이 달라지는 모델이다. 기본은 공개 흐름을 유지하되, 필요할 때는 일부 필드를 보호하고, 그 상태에서도 시스템이 정당하게 동작한다는 사실은 검증 가능해야 한다.

5.6.1 주체별 프라이버시

마루는 단일 원장을 “모든 참여자에게 동일하게 공개”하는 대신, 일반 대중 / 당사자 / 운영자 / 규제기관(감시자)이라는 네 종류의 시야를 전제로 설계한다.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Pub["General Public"]
        P["Minimal Metadata<br/>(Tx Hash, Block/Time,<br/>Raw/Regulated Tag)"]
    end

    subgraph Party["Transaction Parties / Operators"]
        T["Parties: Own Tx Details<br/>Operators: Delegated/Policy Scope<br/>Partial or Aggregated"]
    end

    subgraph Obs["Observers / Regulators"]
        O["Procedure & Scope Limited<br/>Sensitive Field Access<br/>+ Audit Trail"]
    end

    Pub -->|"Auth/Policy"| Party
    Party -->|"Legal Procedure<br/>+ Scope Limit"| Obs

    style P fill:#64748B,stroke:#64748B,color:#fff
    style T fill:#0096AA,stroke:#0096AA,color:#fff
    style O fill:#FF8C50,stroke:#FF8C50,color:#fff

일반 대중: 대중에게는 최소한의 메타 정보만 남겨 네트워크의 투명성을 유지한다.
당사자: 본인 거래의 상세를 확인할 수 있어야 한다.
운영자: 많은 결제 흐름이 서비스(지갑·PG·급여/정산 SaaS 등)를 통해 발생한다. 운영자는 당사자의 위임 또는 정책 범위 내에서만 부분 데이터 또는 집계 데이터에 접근할 수 있다.
규제기관/감사(감시자): 필요 시 상세 열람이 가능하다. 하지만 “상시 열람”이 아니라 프로토콜이 정의한 절차와 범위 제한 하에서 이뤄져야 한다.

5.6.2 통제된 열람·키 관리·규제 준수 연계

마루에서 규제기관/감사 주체의 열람 권한은 “무제한 권한”이 아니다. 절차 기반의 통제된 열람 경로로 설계한다. 사용자 동의 여부와 독립적으로 열람이 가능할 수는 있으나, 반드시 법적 근거·승인 절차·열람 범위 최소화가 전제되어야 한다. 요청과 승인, 열람은 모두 감사 가능하게 기록되어야 한다. 단일 기관이 임의로 열람을 결정하지 못하도록 다중 승인(임계/분산) + 역할 분리를 기본 원칙으로 둔다.

프라이버시 기능은 마루의 프로그램 가능한 규제 준수 계층(PCL)과 결부되어 작동한다. 보호 모드 거래라도, 정책에 따라 민감 정보 노출을 최소화한 형태로 “규제 요건을 만족한다”는 사실이 검증 가능해야 한다. 필요 시에는 열람 경로를 통해 사실관계를 확인할 수 있어야 하며, 이 과정에서도 범위 제한이 함께 작동해야 한다. 보호 모드에서도 최소한 이중지불 방지·잔고 규칙·정책 준수는 일관되게 보장되어야 한다.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    U("User / Service")

    subgraph Core["Maroo Core"]
        C["EVM / Execution"]
        S["Encrypted Storage<br/>(Optional)"]
    end

    D["PCL<br/>(Policy Evaluation)"]

    R("Observer")
    P["Legal Procedure / Policy"]
    K["Controlled Keys<br/>(Threshold/Approval)"]

    U -->|"1) Submit Tx<br/>(Public/Protected)"| D
    D -->|"2) Rule/Policy Verification<br/>(Minimize Sensitive Data)"| C
    C -->|"3) (Optional) Encrypted Commit<br/>(Protected Mode)"| S

    R -->|"4) Access Request<br/>(Case/Period/Target/Field)"| P
    P -->|"5) Approval/Scope Confirm"| K
    K -->|"6) Auth/Decryption Shard"| R
    R -->|"7) Scoped Query"| S

    style U fill:#64748B,stroke:#64748B,color:#fff
    style C fill:#0096AA,stroke:#0096AA,color:#fff
    style S fill:#0096AA,stroke:#0096AA,color:#fff
    style D fill:#FF8C50,stroke:#FF8C50,color:#fff
    style R fill:#FF8C50,stroke:#FF8C50,color:#fff
    style P fill:#FF8C50,stroke:#FF8C50,color:#fff
    style K fill:#FF8C50,stroke:#FF8C50,color:#fff

5.6.3 프라이버시 구현 방식

위 목표를 만족시키기 위한 구현 경로로, 마루는 두 가지 중첩 가능한 방안을 채택한다. 두 접근은 “프라이버시를 어디에서 강제하느냐”가 다르다. 그 차이는 보안 가정, 기관 온보딩 난이도, 사용자 경험, 처리량의 트레이드오프로 이어진다.

(A) 게이트웨이 기반 접근통제

민감 데이터 접근 경로를 인증된 게이트웨이로 통제하고, 역할/권한에 따라 조회 응답을 마스킹·필터링하는 방식이다. 공개 레벨 데이터는 개방하되 민감 필드는 정책에 따라 제한된 해상도로 제공해, 신속하게 “차등적 가시성”을 구현할 수 있다. 규제기관/감사(감시자)는 절차·범위 제한 하에서 필요한 경우, 마스킹 없는 열람 권한으로 상세내용을 확인할 수 있다.

또한 네트워크는 투명성과 신뢰를 보강하기 위한 공시(disclosures)를 함께 제공한다. 예를 들어 상태 루트, 집계 통계, 정책 집행 로그의 요약 등 검증 가능한 형태의 최소 정보를 퍼블릭 레이어에 주기적으로 공개해, 제3자가 원장의 정합성과 운영의 일관성을 확인할 수 있게 한다.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    subgraph External["External (Public Internet)"]
        U["User / Wallet"]
        P["Service Operator"]
        O["Observer"]
    end

    subgraph Gateway["Authenticated Gateway"]
        G["Gateway<br/>(Auth + Policy + Masking)"]
    end

    subgraph Net["Validator Network"]
        S["Sentry / RPC Edge"]
        V["Validator / Consensus"]
        DB["Chain State"]
    end

    subgraph Disclose["Public Disclosure"]
        D["Disclosure<br/>(State Root / Auth / Summary)"]
    end

    U --> G
    P --> G
    O --> G

    G --> S --> V --> DB
    DB --> V --> S --> G

    DB -->|"Publish"| D
    D -->|"Verification/Audit Basis"| External

    style U fill:#64748B,stroke:#64748B,color:#fff
    style P fill:#64748B,stroke:#64748B,color:#fff
    style O fill:#FF8C50,stroke:#FF8C50,color:#fff
    style G fill:#FF8C50,stroke:#FF8C50,color:#fff
    style S fill:#0096AA,stroke:#0096AA,color:#fff
    style V fill:#0096AA,stroke:#0096AA,color:#fff
    style DB fill:#0096AA,stroke:#0096AA,color:#fff
    style D fill:#64748B,stroke:#64748B,color:#fff

장점: 기관 입장에서 새로운 지갑(노트 관리), 증명 생성(Prover), 신규 키관리 체계(영지식 증명용 뷰 키 등)에 대한 이해가 필요 없거나 최소화되어 기관 온보딩이 빠르다. 초기 제품화(서비스 론칭) 속도가 빠르고 기술적 불확실성은 낮다.

제약/리스크: 운영 통제에 대한 의존도가 높아 인적 오류에 의한 공격 벡터가 여전히 존재한다. 조회/시뮬레이션 경로에서 우회·누출 공격면이 늘어난다. 운영·감사·통제가 보안의 핵심이 된다.

(B) 영지식 증명(ZKP) 기반의 비공개 풀 방식

암호화된 노트와 영지식 증명(민감 정보를 공개하지 않고도 특정 조건을 만족함을 수학적으로 증명하는 기술)을 이용한 비공개 장부(Shielded Pool)를 프로토콜 수준에서 제공하는 방식이다. 사용자는 민감 필드를 공개하지 않고도 정당한 소유/이중지불 방지 등을 증명하며 전송할 수 있다. 규제/감사와의 접점은 선택적 공개·통제된 열람 설계로 연결된다. (Zcash, Aztec, Railgun 등 유사 계열의 시도가 존재하나 상용 수준의 사용자 경험·처리량·정책 결합은 여전히 도전 과제다.)

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    subgraph Client["Client / Wallet"]
        W["Wallet (Proof Generation)"]
    end

    subgraph Chain["Maroo Core"]
        Bank["Public Balance<br/>(Account-based)"]
        Pool["Shielded Pool<br/>(Notes + Merkle Tree)"]
        Verify["ZK Verification<br/>(On-chain)"]
        Null["Nullifier Set<br/>(Double-spend Prevention)"]
    end

    subgraph Audit["Authorized Audit"]
        Obs["Observer"]
        Keys["Controlled Keys<br/>(Threshold/Approval)"]
    end

    W -->|"Deposit"| Bank -->|"Move to Pool"| Pool
    W -->|"Withdraw: Proof + Nullifier"| Verify -->|"If Valid"| Pool
    Verify --> Null

    Obs -->|"Request (Scoped)"| Keys -->|"Approval"| Obs
    Obs -->|"Read (Scoped, Controlled Access)"| Pool

    style W fill:#64748B,stroke:#64748B,color:#fff
    style Bank fill:#0096AA,stroke:#0096AA,color:#fff
    style Pool fill:#0096AA,stroke:#0096AA,color:#fff
    style Verify fill:#0096AA,stroke:#0096AA,color:#fff
    style Null fill:#0096AA,stroke:#0096AA,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Keys fill:#FF8C50,stroke:#FF8C50,color:#fff

장점: 접근통제에만 의존하지 않는 “신뢰 최소화”에 가까운 프라이버시를 제공할 수 있다.

제약/리스크: 최신/실험적 접근에 가깝고, 증명 오버헤드로 처리량/비용 제약이 생길 수 있다. 지갑/SDK의 증명·노트 관리로 사용자 경험 부담이 커질 수 있어 PoC(개념 증명)로 현실성 검증이 필요하다.

5.6.4 구현 방향 및 향후 계획

마루는 위 두 방향을 “양자택일의 문제”가 아니라, 병행 가능하지만 어떤 시나리오를 어떤 신뢰 가정으로 먼저 우선할지의 문제로 본다. PoC(개념 증명)에서는 다음을 우선 검증한다:

차등적 열람 사용자 경험이 실제로 가능한지
규제기관 열람이 남용되지 않도록 절차·통제가 작동하는지
보호 모드에서도 규제 준수(PCL) 검증이 자연스럽게 연결되는지

PoC 결과와 정책·법적 요건에 따라 구체화하며, 기술적 상세는 별도 기술 문서에서 정리한다. 세부 암호학 스택/키 관리/감사 절차/성능 벤치마크 결과는 별도 기술 문서에서 다룬다.

6. 결론

대한민국의 실물 경제는 이미 KRW를 기준으로 디지털화되어 있다. 급여, 세금, 공공요금, 상거래, 투자에 이르기까지 모든 경제 활동이 원화 단위로 이루어지고 있다. 간편결제와 모바일 뱅킹 보급으로 대부분의 거래가 이미 디지털 형태로 처리되고 있다.

그러나 이 디지털 경제가 본격적으로 블록체인 위로 올라오려면 기존 개방형 블록체인이 갖지 못한 요소들이 필요하다. 규제기관이 신뢰할 수 있는 규제 준수 체계, 개인과 기업의 프라이버시를 보호하면서도 필요시 감사가 가능한 투명성 구조, 그리고 AI 에이전트가 경제 주체로 참여하는 시대를 대비한 책임·권한 설계가 그것이다.

마루는 이러한 요구를 해결하기 위해 설계한 한국 원화 경제를 위한 규제 친화적 개방형 기반 블록체인(Layer 1)이다. OKRW를 네이티브 통화로 사용해 수수료·정산·회계를 KRW 단위로 일관되게 인식할 수 있게 한다. 듀얼 트랙 구조를 통해 개방성과 규제 정합성을 동시에 추구한다. 프로그램 가능한 규제 준수 계층(PCL)을 통해 변화하는 법·정책을 유연하게 반영한다. 검증 가능한 프라이버시를 통해 프라이버시와 규제 요구 사이의 균형을 맞춘다. 에이전트 신원 검증(KYA) 기반의 AI 에이전트 계정 모델을 통해 자동화된 경제 주체의 책임과 한도를 명확히 정의한다.

실물 경제의 블록체인 전환은 더 이상 먼 미래의 이야기가 아니다. 글로벌 가치 연동 코인(스테이블코인) 시장이 급성장하고 있다. 주요 국가들이 중앙은행 디지털 화폐(CBDC)와 토큰화 자산 인프라를 준비하고 있다. AI가 금융 거래의 주체로 부상하고 있다. 이러한 전환기에 한국이 자국 통화 기반의 견고한 블록체인 인프라를 갖추는 것은 디지털 경제 시대의 경쟁력을 좌우할 핵심 요소가 될 것이다.

본 라이트페이퍼는 문제 정의와 설계 방향에 대한 첫 번째 초안이다. 정부 당국 및 규제기관, 금융 및 테크기업, 기술 커뮤니티, 스타트업, 연구자들과의 대화를 시작하기 위한 문서다. 마루는 다양한 외부 연구자 및 기술 기여자들과 함께 한국 원화 경제를 위한 새로운 디지털 인프라를 제안·구축하고, 대한민국이 글로벌 디지털 경제 선도국으로 도약하는 여정에서 의미 있는 역할을 하고자 한다.

7. 참고 자료

[R01] BIS — Annual Economic Report 2023
[R02] Ethereum Yellow Paper
[R03] FATF — Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (Oct 2021)
[R04] FATF Recommendations (2012; updated June 2025)
[R05] CometBFT Documentation
[R06] W3C Verifiable Credentials Data Model 1.1
[R07] EIP-4361: Sign-In with Ethereum
[R08] Safe{Wallet}/Safe — Multisig Documentation
[R09] BIS — CBDC information security and operational resilience
[R10] Adi Shamir — How to Share a Secret (1979)
[R11] Zcash Protocol Specification
[R12] Tempo Documentation
[R13] Circle Pressroom (Arc 관련 공지 포함)
[R14] Codex Documentation
[R15] 금융위원회 — 2025년 카드수수료 개편방안(보도자료)
[R16] Trulioo Documentation
[R17] CyberArk — Conjur Open Source Suite (Docs)
[R18] Anthropic — Constitutional AI: Harmlessness from AI Feedback (arXiv)
[R19] Oxford Martin AIGI — Verification for International AI Governance (PDF)
[R20] PYMNTS — Will the stablecoin industry’s compliance dilemma be solved?

부록: 다이어그램 목록

마루의 5대 핵심 메커니즘 개요도
문제 정의 및 마루 해결 방향도
비교 프레임워크 6개 축
마루 플랫폼 전체 아키텍처
노드 유형별 역할과 데이터 흐름
미인증 vs 인증 계정 모델
규제 경로 vs 개방 경로
법률 오라클 - PCL - 앱 흐름
주체별 데이터 가시성 모델
프라이버시 설계 구현 접근법

마루(Maroo)

한국 원화 경제를 위한 규제 친화적 개방형 기반 블록체인(Layer 1)

목차

1. 개요

1.1 비전과 미션

1.2 핵심 가치

2. 문제 정의

2.1 기존 개방형 블록체인의 한계

2.2 기존 금융 인프라의 한계

2.3 소결: 혁신과 규제를 동시에 만족하는 인프라

2.4 프라이버시와 투명성의 딜레마

2.5 AI 에이전트 시대, 금융 인프라의 새로운 요건

3. 관련 프로젝트 및 비교

3.1 비교 프레임워크

3.2 축별 상충 관계 분석

(1) 체인 아키텍처와 거버넌스

(2) 네트워크 경제 구조

(3) 규제 준수·신원 통합

(4) 프라이버시 설계

(5) AI·에이전트 대응

(6) 개발자 경험 & 인프라

3.3 비교 요약표

4. 마루 설계 원칙

4.1 설계 목표와 원칙

KRW 네이티브 블록체인

개방적이되 규제를 준수(Public, but Regulated)

프로그램 가능한 규제 준수 계층(Programmable Compliance Layer, PCL)

검증 가능한 프라이버시(Verifiable Privacy)

AI 에이전트 친화적 설계

4.2 기반 블록체인(Layer 1) vs. 확장 블록체인(Layer 2)

독립적 거버넌스와 규제 적용

이더리움 가상머신(EVM) 호환성과 개발자 경험

5. 플랫폼 아키텍처

5.1 핵심 구성요소

5.2 마루 코어

5.2.1 네트워크 및 합의

5.2.2 실행 환경

5.3 노드 역할

5.4 신원 및 계정 모델

5.4.1 미인증 계정 vs 인증 계정

5.4.2 KYC/KYB/KYA 체계

5.4.3 AI 에이전트 계정 모델

5.4.4 온체인 신원 인터페이스

5.5 거래 모델 및 규제 준수

5.5.1 듀얼 트랙 거래 모델

5.5.2 프로그램 가능한 규제 준수 계층(PCL)

5.5.3 법률 오라클(Legal Oracle)

5.5.4 이상 거래 대응 및 회수

5.6 프라이버시 설계

5.6.1 주체별 프라이버시

5.6.2 통제된 열람·키 관리·규제 준수 연계

5.6.3 프라이버시 구현 방식

(A) 게이트웨이 기반 접근통제

(B) 영지식 증명(ZKP) 기반의 비공개 풀 방식

5.6.4 구현 방향 및 향후 계획

6. 결론

7. 참고 자료

부록: 다이어그램 목록