🔒 HashSphere Tech. Part 2: 네트워크 격리와 Sovereign Perimeter

기관급 프라이빗 인프라의 기반이 되는 독립 네트워크 설계

HashSphere의 독립 네트워크 설계가 어떻게 데이터 주권, 규제 준수, 인프라 통제력을 제공하는지 설명하는 기술 리포트입니다.

이번 리포트는 공개 네트워크 위에 프라이버시 기능을 추가하는 방식과 HashSphere처럼 기관이 직접 네트워크 경계를 통제하는 방식의 차이를 다룹니다. 거래 내용을 암호화하는 것만으로는 충분하지 않을 수 있으며, 실제로 중요한 것은 데이터가 어디에서 처리되고 저장되는지, 누가 네트워크를 운영하는지, 그리고 기관이 그 과정을 얼마나 직접 통제할 수 있는지입니다.

📝 핵심 요약

HashSphere는 단순히 거래 내용을 숨기는 프라이빗 네트워크가 아닙니다. 기관이 직접 정의한 네트워크 경계 안에서 거래를 처리하고 데이터를 저장하며, 검증자와 운영 방식을 선택할 수 있도록 설계된 독립형 네트워크입니다.

핵심 내용은 다음과 같습니다:

• 거래 데이터가 기관이 정한 환경을 벗어나지 않도록 설계

• 공개 네트워크의 서브넷이 아닌 독립적인 네트워크 구조

• 중앙 조정자 없이 hashgraph 합의 알고리즘으로 거래 순서 확정

• 기관의 필요에 따라 관리형, 자체 운영형, 컨소시엄 방식 선택

• 오픈소스 기반을 통해 특정 공급업체에 대한 종속 최소화

• 필요한 기간만 데이터를 보관하고 이후에는 프루닝 가능

• CLPR을 통해 필요할 때 공개·프라이빗 네트워크와 연결

• 프라이버시와 상호운용성을 동시에 추구

1️ 독립 네트워크 설계는 설정 옵션이 아니라 경계 자체입니다

앞선 Part 1에서는 HashSphere의 거래 프라이버시가 zkSNARK와 암호화된 잔액을 통해 암호학적으로 보호된다는 점을 설명했습니다. 하지만 거래 내용이 암호화되어 있다고 해서 네트워크 전체가 기관의 통제 아래 있는 것은 아닙니다. 공개 네트워크 위에 프라이버시 기능을 추가하면 거래 내용을 숨길 수는 있지만, 데이터가 기관이 통제하지 않는 인프라를 통과할 가능성은 여전히 남아 있습니다.

규제 대상 금융기관에게는 거래 내용 자체뿐 아니라 데이터가 처리되고 저장되는 위치, 네트워크 인프라에 접근할 수 있는 주체, 그리고 기관이 이러한 통제 상태를 규제기관에 입증할 수 있는지가 중요합니다.

• 데이터가 실제로 어느 지역에 저장되는가

• 누가 네트워크 인프라에 접근할 수 있는가

• 기관이 규제기관에 통제 상태를 입증할 수 있는가

GDPR, MiFID II, Basel SCO60 및 각국의 데이터 주권 규정은 단순한 암호화뿐 아니라 데이터의 처리 위치와 접근 권한까지 요구할 수 있습니다. 또한 국부펀드, 연기금, 기업 재무부서와 같은 기관 고객은 거래 활동과 거래 상대방 정보가 제3자가 접근할 수 있는 인프라에 노출되지 않기를 기대합니다.

이러한 요구는 계약만으로 해결하기 어렵습니다. 운영자가 데이터를 오용하지 않겠다고 약속하는 것과, 애초에 운영자가 해당 데이터를 볼 수 없도록 설계하는 것은 다르기 때문입니다. 결국 네트워크 구조 자체가 기관의 통제 아래 있어야 합니다.

HashSphere는 공개 네트워크의 서브넷이 아니라, 기관이 직접 정의하는 Sovereign Perimeter, 즉 주권적 네트워크 경계를 제공합니다.

2️ 독립 네트워크 설계를 구성하는 네 가지 핵심 요소

HashSphere는 거래 기밀성, 독립 네트워크 설계, 유연한 거버넌스, 공정한 거래 순서 지정이 서로 결합되어 작동하도록 설계됐습니다. 이 중 하나라도 빠지면 나머지 요소가 제공하는 보장도 약해질 수 있습니다.

1. 거래 기밀성 — 정책이 아니라 암호학적으로 강제되는 프라이버시

2. 독립 네트워크 설계 — 공개 네트워크의 서브넷이 아닌 Sovereign Perimeter

3. 유연한 검증자 및 거버넌스 모델 — 제3자에게 일괄 위임되지 않는 운영 구조

4. 수학적으로 보장되는 공정한 순서 지정 — hashgraph 합의 알고리즘을 통한 거래 정렬

Part 1에서는 거래 기밀성에 초점을 맞췄다면, 이번 Part 2에서는 거래를 담는 네트워크 자체가 얼마나 독립적이고 통제 가능한지를 다룹니다. 향후 리포트에서는 검증자와 거버넌스 모델, 그리고 공개·프라이빗 네트워크 사이의 연결을 가능하게 하는 CLPR을 다룰 예정입니다.

3️ 공유 인프라를 사용할 때 발생하는 문제

기관이 프라이빗 블록체인을 검토할 때 흔히 선택하는 방식은 기존 공개 네트워크 위에 별도의 프라이빗 환경을 구축하는 것입니다. 대표적으로 서브넷, 앱체인, 공유 기반 인프라 위의 허가형 레이어, 거래 당사자에게만 일부 데이터를 보여주는 구조 등이 있습니다.

• 서브넷

• 앱체인

• 공유 기반 인프라 위의 허가형 레이어

• 거래 당사자에게만 일부 데이터를 보여주는 구조

이러한 방식은 일정 수준의 프라이버시를 제공하지만, 기관이 네트워크 전체를 통제하는 독립적인 경계를 제공하지는 않습니다. 일부 프라이빗 네트워크는 중앙 조정자가 합의를 관리하고 데이터 접근 권한을 제한하는 방식으로 운영되기도 합니다.

이 경우 데이터가 수학적으로 읽을 수 없도록 보호되는 것이 아니라, 운영자가 데이터를 보지 않겠다는 약속에 의존하게 됩니다. 즉, 통제된 네트워크일 수는 있지만 진정한 의미의 독립적인 프라이빗 네트워크라고 보기는 어렵습니다.

3️-1️ 서브넷이 제공하는 실제 격리 수준

서브넷이나 앱체인은 외부와 분리된 것처럼 보일 수 있습니다. 하지만 이를 운영하는 검증자들은 여전히 공개 네트워크나 인터넷을 통해 통신할 수 있으며, 그 과정에서 데이터가 기관이 직접 선택하지 않은 인프라나 규제 경계 밖의 환경을 통과할 가능성이 있습니다.

• 기관이 직접 선택하지 않은 검증자

• 기관이 지정하지 못하는 지역의 인프라

• 기관의 규제 경계 밖에 있는 네트워크

거래 내용이 암호화되어 있어도 메타데이터는 노출될 수 있습니다. 누가 거래했는지, 언제 거래했는지, 거래가 얼마나 자주 발생했는지, 거래 규모가 어느 정도인지와 같은 정보는 거래 패턴을 분석하는 데 활용될 수 있습니다.

예를 들어 대형 은행이 대규모 채권을 거래할 때 금액 자체는 암호화되어 있더라도, 거래 시점과 규모를 통해 시장 참여자가 해당 활동을 추론할 수 있습니다. 따라서 데이터 주권이 중요한 기관에게는 단순히 거래 내용을 암호화하는 것만으로 충분하지 않습니다.

3️-2️ 제약 없이 제공되는 EVM 호환성

프라이빗 EVM 네트워크를 선택하면 기관은 기반 네트워크의 제약도 함께 물려받는 경우가 많습니다. 고정된 검증자 집합, 공급업체와 결합된 거버넌스, 데이터 저장 지역에 대한 제한, 네트워크 경계를 직접 통제하기 어려운 구조 등이 대표적인 문제입니다.

• 고정된 검증자 집합

• 공급업체와 결합된 거버넌스

• 데이터 저장 지역에 대한 제한

• 네트워크 경계를 직접 통제하기 어려운 구조

HashSphere는 EVM과 완전히 호환되기 때문에 기관은 기존 Solidity 스마트 계약과 익숙한 개발 도구를 사용할 수 있습니다. 동시에 HashSphere는 일반적인 프라이빗 네트워크에서 발생할 수 있는 구조적 제약을 줄이기 위해 다음과 같은 독립적인 구조를 제공합니다.

• hashgraph 합의 알고리즘

• 수학적으로 보장되는 공정한 거래 순서

• 기관이 직접 정의하는 검증자 집합

• 기관이 통제하는 네트워크 경계

• Linux Foundation Decentralized Trust 기반의 오픈소스 구조

즉, EVM 호환성을 유지하면서도 네트워크 운영과 데이터 흐름에 대한 기관의 통제력을 강화하는 방식입니다.

3️-3️ 중앙 라우팅 주체의 문제

일부 프라이빗 네트워크는 중앙 조정자가 거래를 처리하고 순서를 정합니다. 이 조정자는 이중 지불 확인, 거래 순서 지정, 결제 처리, 공동 상태 유지, 거래 기록 관리 등을 담당하며, 그 과정에서 모든 거래 데이터를 확인해야 합니다. 프라이빗 거래 정보도 예외가 아닙니다.

• 이중 지불 확인

• 거래 순서 지정

• 결제 처리

• 공동 상태 유지

• 거래 기록 관리

이 모델의 프라이버시는 암호학적 보장이라기보다 계약상의 신뢰에 가깝습니다. 사용자는 운영자가 데이터를 오용하지 않을 것이라고 믿을 수 있지만, 운영자가 데이터를 볼 수 없는 것은 아닙니다.

또한 중앙 조정자는 단일 장애 지점이 될 수 있습니다.

• 운영자가 중단되면 네트워크도 중단될 수 있음

• 운영자가 침해되면 전체 데이터가 위험해질 수 있음

• 가격, 인수, 정책이 바뀌면 기관의 대응 수단이 제한될 수 있음

예를 들어 두 은행이 중앙 조정자를 통해 국경 간 채권 결제를 수행한다고 가정하면, 조정자는 자산 전달과 현금 지급 정보를 모두 확인하고 거래 순서를 정할 수 있습니다. 두 은행은 데이터가 오용되지 않을 것이라는 계약상 보장은 받을 수 있지만, 조정자가 해당 데이터를 암호학적으로 볼 수 없다는 보장은 받지 못합니다.

3️-4️ 양자 위협: 지금 수집하고 나중에 복호화하기

공개 인프라를 통과하는 암호화 데이터에는 장기적인 위험도 있습니다. 공격자가 오늘 암호화된 데이터를 수집한 뒤, 향후 충분히 강력한 양자컴퓨터가 등장하면 복호화할 수 있기 때문입니다. 이를 HNDL, Harvest Now, Decrypt Later 공격이라고 합니다.

기관의 거래 데이터가 네트워크 경계 밖으로 나가지 않는다면 이러한 공격의 대상이 되는 영역을 줄일 수 있습니다. 물론 네트워크 경계 자체가 침해되면 데이터가 노출될 수 있지만, 데이터가 지속적으로 공개 인프라를 통과하는 구조보다는 노출 가능성을 낮출 수 있습니다.

국채, 구조화 상품, 연기금 포지션처럼 장기간 민감하게 취급해야 하는 데이터의 경우, 오늘의 인프라 선택이 10년 뒤의 보안 위험에도 영향을 줄 수 있습니다.

4️ HashSphere: 기관이 직접 소유하고 운영할 수 있는 프라이빗 네트워크

HashSphere는 공개 네트워크의 서브넷이 아니라 완전히 독립된 프라이빗 네트워크입니다. 거래를 중앙 조정자를 통해 라우팅하지 않으며, 네트워크 경계는 기관이 직접 정의하고 통제합니다.

기관은 다음과 같은 환경 안에 HashSphere를 배포할 수 있습니다.

• 자체 데이터센터

• 기관이 선택한 클라우드

• Hashgraph가 운영하는 관리형 클라우드

• 여러 환경을 조합한 구조

4️-1️ 네트워크 아키텍처: Sovereign Perimeter

HashSphere의 하나의 네트워크를 Sphere라고 부릅니다. Sphere는 독립적으로 작동하는 자체 환경이며, 기관이 정의한 인프라 경계 안에 네트워크 구성요소가 포함됩니다.

주요 구성요소는 다음과 같습니다.

• 합의 노드 — 중앙 시퀀서 없이 hashgraph 합의를 통해 거래를 처리하고 확정합니다.

• 블록 노드 — 거래 데이터를 저장하며, 데이터는 기관이 정한 경계 안에 존재합니다.

• JSON-RPC Relay 및 WebSocket 서비스 — 애플리케이션 연결을 처리하며, 이 역시 네트워크 내부에서 작동합니다.

4️-2️ 기관의 환경을 벗어나지 않는 데이터

HashSphere의 독립 네트워크 설계에서 가장 중요한 점은 기관이 데이터 흐름을 직접 통제한다는 것입니다. 데이터는 기관이 외부 전송을 결정하지 않는 한 선택한 환경을 벗어나지 않습니다.

일부 프라이빗 네트워크는 최종성이나 상태 검증을 위해 공개 L1에 의존합니다. 이 경우 네트워크의 무결성이 기관이 통제하지 않는 외부 인프라와 연결됩니다.

반면 HashSphere에서는 데이터가 네트워크 내부에서 앵커링되고, 검증되고, 저장됩니다. 네트워크가 유효하고 일관된 상태를 유지하기 위해 공개 L1이나 외부 시스템에 의존하지 않습니다. 따라서 Sovereign Perimeter는 단순한 경계가 아니라 네트워크 전체의 운영 환경입니다.

예를 들어 호주 중앙은행이 모든 거래 데이터를 호주 내에서만 처리해야 한다고 가정해 보겠습니다. 서브넷 기반 구조에서는 해당 지역에 충분한 검증자가 있는지에 의존해야 하지만, HashSphere에서는 기관이 호주 내에 합의 노드를 배치하고 직접 네트워크 경계를 정의할 수 있습니다. 데이터는 그 경계 안에 머뭅니다.

4️-3️ 오픈소스 기반: 공급업체 종속 방지

HashSphere를 구동하는 Hedera 코드베이스는 Linux Foundation Decentralized Trust에 기여됐으며, Project Hiero로 운영되고 있습니다. 이는 HashSphere의 기반 소프트웨어가 오픈소스이며, 특정 공급업체에 종속되지 않는다는 의미입니다.

기관은 Hashgraph의 지원을 받을 수 있지만, 원한다면 오픈소스 코드와 도구를 사용해 독립적으로 네트워크를 운영할 수 있습니다. 이를 통해 다음과 같은 종속을 줄일 수 있습니다.

• 독점 인프라

• 독점 스마트 계약 언어

• 특정 공급업체와의 장기 계약

• 공급업체 변경 시 발생하는 운영 리스크

Hashgraph는 네트워크 운영과 기술 지원을 제공하지만, 고객이 관계를 종료하기로 결정하더라도 소프트웨어와 도구는 고객에게 남는 구조를 지향합니다.

5️ 거버넌스: 기관의 필요에 따라 설정하는 구조

기관마다 필요한 탈중앙화 수준은 다를 수 있습니다. Web3에서는 탈중앙화가 중요한 원칙이지만, 규제 대상 금융기관은 이념적 의미의 탈중앙화보다 실제 운영과 책임 구조를 더 중요하게 볼 수 있습니다.

• 누가 책임을 지는가

• 누가 네트워크를 운영하는가

• 감사가 가능한가

• 단일 장애 지점이 존재하는가

• 규제기관이 필요한 정보를 확인할 수 있는가

HashSphere는 기관의 위험 수용 수준과 운영 목적에 따라 네트워크를 필요한 만큼 탈중앙화할 수 있도록 설계됐습니다.

5️-1️ 세 가지 거버넌스 모델

1. Managed Service

Hashgraph가 기관을 대신해 네트워크를 배포하고 관리합니다. Hashgraph의 클라우드 또는 기관 자체 클라우드에서 운영할 수 있으며, 기관이 합의 노드를 직접 운영하지 않더라도 정의된 네트워크 경계 안에서 데이터 통제권을 유지할 수 있습니다.

이는 가장 빠르게 배포할 수 있는 방식이며, HashSphere를 처음 도입하는 기관에 적합한 모델입니다.

2. On-Prem

기관이 네트워크를 직접 배포하고 관리합니다. Hashgraph의 도구, 문서, 배포 가이드, 모니터링 엔드포인트를 사용하며, Hashgraph는 개발 지원과 SLA를 제공합니다.

다만 일상적인 운영은 기관이 담당합니다.

• 모니터링

• 백업

• 복구

• 고가용성 설정

• 운영 관리

3. Consortium Governance

여러 기관이 각각 자신의 합의 노드를 운영합니다. 각 기관은 네트워크 합의에 참여하고 자신의 노드를 관리하며, 어느 한 기관도 다른 참여자를 일방적으로 통제할 수 없습니다.

프라이버시는 컨소시엄 경계 안에서 유지되고, 각 기관은 자신의 데이터에 대한 통제권을 보유합니다.

세 모델의 공통점은 기관이 다음 사항을 직접 결정한다는 것입니다.

• 누가 네트워크에 참여할 수 있는가

• 누가 합의 노드를 운영하는가

• 어떤 데이터가 네트워크 밖으로 나갈 수 있는가

6️ 규제 준수와 데이터 주권

독립 네트워크 설계는 단순한 기술적 선택이 아닙니다. 많은 규제 대상 기관에게는 규제 준수를 위한 구조적 전제 조건입니다.

GDPR, MiFID II, Basel SCO60 및 각국의 데이터 주권 규정은 거래 데이터가 어디에서 처리되고 저장되며 누가 접근할 수 있는지에 대해 엄격한 조건을 요구합니다.

규제기관은 다음과 같은 사항을 확인할 수 있어야 합니다.

• 거래 데이터가 정해진 지역 안에서 처리되는가

• 데이터 접근이 승인된 참여자로 제한되는가

• 기관이 이러한 통제를 실제로 적용하고 있다는 사실을 입증할 수 있는가

서브넷 기반 설계는 검증자 인프라를 기관이 완전히 통제하지 못하기 때문에 데이터 저장 지역 요건을 충족하기 어려울 수 있습니다. 중앙 라우팅 모델은 조정자가 모든 데이터에 구조적으로 접근할 수 있기 때문에 데이터 접근 제한 요건을 충족하기 어렵습니다.

HashSphere는 네트워크 경계, 검증자, 데이터 저장 위치를 기관이 직접 정의하도록 설계됐습니다. 예를 들어 유럽의 자산운용사가 EU 내에서만 토큰화된 펀드 포지션을 결제해야 한다면, EU 관할권 안에 합의 노드를 배치하고 네트워크 경계를 규제 범위에 맞출 수 있습니다.

7️ 데이터 프루닝: 필요한 기간만 보관하기

금융기관은 거래 기록을 일정 기간 보관해야 합니다. 경우에 따라 그 기간은 7년일 수 있습니다. 하지만 보관 기간이 끝난 뒤에도 데이터를 계속 보관하는 것은 보안과 법적 책임 측면에서 부담이 될 수 있습니다. 더 이상 필요하지 않은 오래된 데이터는 잠재적인 침해 위험이 되기 때문입니다.

일반적인 블록체인은 과거 블록이 서로 암호학적으로 연결되어 있기 때문에, 중간 데이터를 삭제하면 이후 기록의 검증과 재생이 깨질 수 있습니다.

HashSphere의 데이터 구조는 이러한 문제를 줄이도록 설계됐습니다. 과거 데이터를 프루닝하더라도 이후 거래의 암호학적 검증에 영향을 주지 않도록 구성되어 있습니다.

따라서 기관은 다음과 같이 운영할 수 있습니다.

• 규제상 필요한 데이터는 보관

• 더 이상 필요하지 않은 데이터는 삭제

• 네트워크의 무결성은 유지

이는 데이터 보관 의무와 불필요한 데이터 부담을 함께 관리할 수 있는 구조입니다.

8️ 자산이 갇히지 않는 상호운용성: CLPR

프라이빗 네트워크가 외부 생태계와 연결되지 못하면 자산과 유동성이 해당 네트워크 안에 갇힐 수 있습니다. 이른바 ‘자산이 갇힌 섬’ 문제입니다.

HashSphere는 기본적으로 프라이빗하고 독립적이지만, 필요할 때 외부 네트워크와 연결할 수 있도록 설계됐습니다. Hashgraph가 개발 중인 CLPR, Cross-Ledger Protocol은 서로 다른 원장을 연결하는 브리지 없는 크로스레저 메시징 프로토콜입니다.

CLPR은 다음과 같은 구조를 목표로 합니다.

• 중앙 중개자 불필요

• 연결별 맞춤형 브리지 불필요

• 공동 유동성 풀 불필요

• 각 원장이 자체 증명 방식으로 상대 원장 상태를 검증

CLPR 기반 애플리케이션을 사용하면 다음과 같은 네트워크 사이에서 토큰, 데이터, 메시지를 이동할 수 있습니다.

• Sphere와 Sphere

• Sphere와 Hedera

• Sphere와 다른 공개 네트워크

이 과정에서 암호학적 상태 증명과 임계값 서명 방식인 TSS가 사용됩니다.

기관은 기본적으로 모든 데이터를 네트워크 안에 유지하면서도, 크로스네트워크 결제나 유동성 접근이 필요할 때만 외부와 연결할 수 있습니다. 즉, 외부 연결 여부는 기관이 직접 결정합니다.

9️ 실제 기관 활용 사례

HashSphere는 규제 준수, 결제, 데이터 통제 문제를 해결하기 위한 기관용 인프라로 활용되고 있습니다.

9️-1️ 다중 은행 토큰화 예금: 스페인 Cecabank

스페인의 ABANCA, Cecabank, Ibercaja, Kutxabank, Unicaja 등 다섯 금융기관은 Cecabank가 주도하고 Asseto가 HashSphere를 기반으로 지원한 다중 은행 토큰화 예금 개념검증을 완료했습니다.

이 실험은 규제 대상 상업은행의 예금을 토큰화하고, 서로 다른 은행 사이에서 즉시 전송하고 최종 결제할 수 있음을 보여줬습니다. 중요한 점은 암호화폐를 발행하지 않고도 기초 예금의 법적·회계적 성격을 유지할 수 있었다는 것입니다.

HashSphere는 다음과 같은 환경을 제공했습니다.

• 각 기관이 자체 발행과 고객 관계를 통제

• Cecabank의 계정 구조와 결제를 동기화

• 민감한 은행 간 데이터가 공개 인프라를 통과하지 않도록 설계

그 결과 기존 예금 체계 안에서 24시간 실시간 은행 간 결제가 가능해졌습니다.

9️-2️ 부동산 위험 데이터: Institutes RiskStream Collaborative

보험업계의 비영리 기술 컨소시엄인 The Institutes RiskStream Collaborative는 HashSphere 프라이빗 네트워크와 공개 Hedera 네트워크를 결합한 하이브리드 구조를 구축했습니다.

이 솔루션은 부동산 위험 데이터를 토큰화하고, 보험사, 브로커, 재보험사 사이에서 공유할 수 있는 기준 정보를 제공합니다.

HashSphere는 민감한 프라이빗 데이터를 보호합니다. 건물 구조, 사용 용도, 보호 설비, 노출 위험을 의미하는 COPE 데이터는 허가된 참여자만 접근할 수 있는 환경에서 관리됩니다. 동시에 공개 Hedera 토큰은 누구나 검증할 수 있는 부동산 식별자로 사용됩니다.

이 구조는 여러 조직이 동일한 부동산 데이터를 반복적으로 수집하고 검증해야 하는 문제를 줄이고, 분산된 기록을 하나의 신뢰 가능한 기준점으로 통합하는 것을 목표로 합니다.

두 사례 모두 같은 원칙을 공유합니다. 민감한 데이터는 기관의 경계 안에 유지하고, 더 넓은 연결이 필요할 때만 공개 네트워크와 연결하는 방식입니다.

🔟 배포 옵션: 운영 환경으로 전환하기

HashSphere는 기관의 기술 역량, 클라우드 환경, 도입 일정에 따라 여러 배포 방식을 제공합니다. 대부분의 기관에게 가장 빠른 운영 전환 방식은 Managed Service입니다.

🔟-1️ Managed Service

Hashgraph가 기관을 대신해 HashSphere 네트워크를 배포하고 관리합니다.

Hashgraph 인프라에서 운영

네트워크는 Hashgraph의 클라우드 인프라에 배포됩니다. Hashgraph가 배포, 모니터링, 백업, 복구, 고가용성 설정을 담당하므로 기관은 인프라 운영에 필요한 부담을 줄이면서 개념검증을 빠르게 시작할 수 있습니다.

기관 인프라에서 운영

네트워크는 기관 자체 클라우드에 배포되지만, Hashgraph가 운영을 관리합니다. 기관은 데이터 주권을 유지할 수 있으며, 데이터는 기관의 환경을 벗어나지 않습니다.

이 방식은 기존 클라우드 인프라와 데이터 저장 지역 요건을 갖춘 대형 기관에 적합합니다.

1️1️ On-Prem: 기관의 완전한 운영 통제

기관이 모든 운영을 직접 담당하기를 원한다면 자체 관리형 배포를 사용할 수 있습니다. 기관은 Hashgraph의 도구, 배포 가이드, 모니터링 엔드포인트를 활용해 네트워크를 직접 운영하고, Hashgraph는 필요할 때 대응형 지원을 제공합니다.

현재 클라우드 기반 배포 방식은 다음과 같습니다.

1️1️-1️ Managed Service — 현재 이용 가능

기관의 AWS 또는 GCP 계정에 네트워크를 배포하고 Hashgraph가 관리합니다. 기관은 데이터 통제권을 유지하면서 운영상의 복잡성을 줄일 수 있습니다.

1️1️-2️ On-Prem, Self-managed — Alpha, 2026년 4분기

기관의 AWS 또는 GCP 계정에 네트워크를 배포하고, 기관이 전체 운영을 담당합니다. Hashgraph의 도구와 모니터링 엔드포인트를 사용하며, 필요할 때 대응형 지원을 받을 수 있습니다.

다만 현재 다음과 같은 물리적 하드웨어 배포 방식은 로드맵에 포함되어 있지 않습니다.

• AWS Outpost

• Google Distributed Cloud

• 기관 자체 데이터센터의 베어메탈 서버

1️2️ HashSphere의 구조적 차이

프라이빗 엔터프라이즈 블록체인 시장에는 여러 가지 네트워크 설계 방식이 있습니다. 일부는 공개 네트워크 위에 프라이빗 환경을 만들고, 일부는 중앙 조정자를 통해 거래를 관리합니다.

그러나 이러한 방식은 다음과 같은 한계를 가질 수 있습니다.

• 데이터가 기관 외부 인프라를 통과할 수 있음

• 거래 메타데이터가 외부에 노출될 수 있음

• 중앙 운영자에 대한 신뢰가 필요함

• 특정 공급업체에 종속될 수 있음

• 외부 유동성에 접근하기 어려울 수 있음

HashSphere는 기관이 직접 네트워크 경계를 정의하고, 데이터를 통제하며, 운영 방식과 외부 연결 여부를 선택할 수 있도록 설계됐습니다.

🏁 결론: 프라이버시와 상호운용성은 함께 구현할 수 있습니다

금융기관이 원하는 것은 단순히 거래 내용을 숨기는 프라이빗 네트워크가 아닙니다. 기관이 실제로 통제할 수 있는 네트워크입니다.

이를 위해서는 다음과 같은 조건이 필요합니다.

• 데이터가 기관의 경계 안에 머무는가

• 규제 준수가 계약이 아니라 아키텍처로 보장되는가

• 누가 네트워크를 운영하는지 기관이 결정할 수 있는가

• 필요할 때 외부 네트워크와 연결할 수 있는가

• 특정 공급업체에 종속되지 않는가

• 보관 기간이 끝난 데이터를 삭제할 수 있는가

HashSphere의 핵심은 네트워크 경계가 실제로 존재한다는 점입니다. 데이터는 기관이 외부로 보내기로 결정하지 않는 한 경계를 벗어나지 않으며, hashgraph 합의 알고리즘은 그 경계 안에서 공정한 거래 순서를 제공합니다.

CLPR은 필요할 때 공개·프라이빗 네트워크와 연결할 수 있는 상호운용성을 제공하고, Linux Foundation Decentralized Trust의 오픈소스 기반은 공급업체 종속을 줄입니다. 또한 데이터 프루닝 기능은 기관이 필요한 기간만 데이터를 보관할 수 있도록 지원합니다.

결국 HashSphere는 프라이버시와 상호운용성이 반드시 서로 충돌하는 요소가 아니라는 전제를 바탕으로 설계됐습니다. 데이터 주권과 네트워크 개방성도 함께 구현할 수 있으며, HashSphere의 Sovereign Perimeter는 단순한 설정이 아니라 아키텍처 자체입니다.