보안 토큰 프로토콜에서 상호운용성의 필요성 – Thought Leaders

A Short History of Tokens

비트코인이 처음으로 블록체인 기술을 세상에 소개한 지 10년이 넘었습니다. 그동안 분산 원장의 잠재적 사용 사례 목록은 디지털 화폐에서 공급망, 신원 관리에 이르기까지 급속히 확대되었습니다.

이러한 진화는 자연스럽게 “토큰”이라는 개념을 탄생시켰습니다—블록체인 상에서 소유 및 이전이 가능한 디지털 자산입니다. 토큰은 본질적으로 디지털 자산을 나타내는 것과 실제 세계 자산을 나타내는 두 가지 주요 범주로 나뉩니다. 이 새로운 패러다임을 활용하여 이더리움만으로도 이미 수십만 개의 다양한 토큰이 생성되었으며, 작성 시점의 총 시장 가치는 150억 달러가 넘습니다.

토큰의 가장 유망한 적용 사례 중 하나는 온체인에서 실제 세계 증권을 표현하는 것으로, 이는 상업용 부동산과 같은 전통적으로 유동성이 낮은 자산을 분할하고 피어투피어 방식으로 이전할 수 있게 합니다. 이러한 “토큰화” 과정은 기존 자본 시장의 여러 고충을 완화할 잠재력 때문에 기존 기관과 신생 스타트업 모두의 큰 관심을 받고 있습니다.

Regulatory Compliance

블록체인은 기술적인 측면에서 소유권 이전을 용이하게 할 수 있지만, 보안 토큰은 여전히 전통 증권과 동일한 법률 및 규제의 적용을 받습니다. 보안 토큰이 규정을 준수하도록 보장하는 것은 모든 토큰화 시도에 필수적이며, 지금까지 채택을 가로막는 장벽이 되어 왔습니다. 아래 차트에서 볼 수 있듯이, 규제 불확실성은 블록체인 채택에 가장 큰 장벽으로 널리 인식되고 있습니다.

블록체인 분야에서는 수많은 프로젝트가 등장하여 보안 토큰의 규제, 거래 및 관리 방식을 단순화하고 표준화하려는 프로토콜을 설계하고 있습니다. 이더리움만 보아도 Securitize, Harbor, Polymath 등 이 문제를 다루는 표준을 발표한 프로젝트가 있습니다. 그러나 궁극적으로 현재 설계된 프로토콜에 수정이 없으면 투자자와 거래소는 토큰화된 증권을 매매할 때 상당한 마찰을 겪게 됩니다. 그 이유는 무엇일까요? 상호운용성입니다.

Interoperability is Crucial

상호운용성은 토큰화의 가장 중요한 이점 중 하나입니다. 이는 공통 소프트웨어 표준을 공유함으로써 자본 시장 애플리케이션 및 제품 전체 생태계가 서로 통합될 수 있게 합니다. 그러나 애플리케이션 및 제품 수준에서 상호운용성을 구현하려면 가장 낮은 수준인 토큰 자체부터 시작해야 합니다. 보안 토큰 분야에서 상호운용성은 두 핵심 당사자, 즉 거래소와 투자자에게 필수적입니다.

거래소 입장에서는 투자자가 구매할 자격이 있는 모든 보안 토큰을 승인할 수 있기를 원합니다—토큰을 만든 회사와 무관하게 말이죠. 이는 각 보안 토큰마다 맞춤형 통합을 하는 것이 아니라, 모든 보안 토큰에 대해 일관된 단순하고 일반적인 통합을 의미합니다.

투자자 입장에서는 온보딩 과정을 가능한 한 간단하고 마찰 없이 진행하고 싶습니다. 현재 투자자가 여러 곳에서 주식을 구매하려면 매번 개인 정보를 제공해야 하는 ‘고객 알기(KYC)’ 절차를 반복해야 합니다. 블록체인은 이 정보를 온체인에 영구적으로 저장함으로써 모든 보안 토큰이 참조할 수 있게 함으로써 이 과정을 혁신할 잠재력이 있습니다. 이는 새로운 토큰을 구매할 때마다 동일한 개인 정보를 반복 제공할 필요가 없으며, 최초 등록 후에는 보완적이거나 업데이트된 정보만 제공하면 됩니다. 그러나 이러한 프로세스는 보안 토큰 간의 상호운용성이 시스템을 관리하는 표준에 설계되어 있을 때만 가능해집니다.

The Protocols

이더리움의 주요 보안 토큰 프로토콜 세 가지는 Securitize, Harbor, Polymath가 발표했습니다. 이 세 프로토콜 모두 이더리움의 ERC-20 토큰 표준을 기반으로 하며, 이를 확장하여 보안 토큰 거래에 규제 준수를 적용합니다. 이는 거래가 발생할 때마다 두 번째 계약을 조회하여 각 거래의 합법성을 확인함으로써 이루어집니다.

프로토콜마다 명칭은 다르지만, 두 번째 계약을 사용하는 방식은 세 프로토콜 모두에서 일관되며, 동일한 결과—비규제 거래 방지—를 달성합니다. 이 두 번째 ‘Regulator’ 계약은 오프체인 서비스에 의해 사용자의 KYC 및 인증 정보를 최신 상태로 유지합니다—예를 들어 거래소나 토큰 발행자가 해당 서비스를 권한을 가지고 있을 경우.

이 세 구성 요소만으로 보안 토큰을 규제하는 데 필요한 모든 것이 갖춰진 것처럼 보일 수 있지만(가장 단순한 형태에서는 실제로 그렇습니다), 구성 요소가 프로그래밍되는 방식이 바로 상호운용성을 결정합니다. 안타깝게도 이 프로토콜들은 두 가지 핵심 영역에서 상호운용성이 부족하여, 기술 채택에 마찰을 일으키고 채택 속도를 늦추고 있습니다.

1. 권한이 부여된 당사자는 사용자에 대한 온체인 정보를 어떻게 업데이트합니까?

Harbor

Harbor는 백서에서 현재는 사용자 정보를 온체인에 업데이트할 수 있는 유일한 당사자는 자신들뿐이라고 선언합니다. 이 역할의 중앙집중화는 거래소가 Regulator가 참조하는 데이터를 업데이트하지 못하게 하며, 따라서 새로운 토큰 수령자를 승인할 수 없어 Harbor 플랫폼 외부에서 토큰을 쉽게 거래할 수 없게 됩니다.

Securitize

Securitize는 이미 여러 당사자가 권한을 부여받을 수 있는 시스템을 구현했으며, 이를 통해 투자자는 여러 곳에 자신의 규제 정보를 등록할 수 있고 Securitize 자체를 거칠 필요가 없습니다. 온체인 데이터는 권한이 부여된 당사자에 의해 직접 업데이트되며, Securitize의 모든 토큰이 이를 조회할 수 있습니다. 또한 투자자가 정보를 여러 번 제공해야 하는 번거로움을 줄이기 위해, Securitize는 권한이 부여된 당사자가 오프체인에 저장된 투자자 개인 정보를 액세스할 수 있는 API를 설계하여, 개인이 규제 준수 여부를 쉽게 판단하거나 추가 정보가 필요한지를 확인할 수 있게 했습니다.

Polymath

Polymath는 플랫폼 전반에서 다양한 작업을 수행하기 위해 필요한 POLY라는 네이티브 디지털 유틸리티 토큰을 보유하고 있습니다. 개인이 KYC를 진행하려면 먼저 POLY 토큰을 구매해야 하는데, POLY와 직접 연결된 유동성 있는 법정-대-POLY 시장이 없기 때문에, 먼저 이더리움의 “ether”(ETH)를 법정 화폐로 구매한 뒤 이를 POLY로 교환해야 합니다. 그런 다음 토큰을 Polymath의 KYC 마켓플레이스에서 사용해 KYC 제공자에게 입찰할 수 있습니다. KYC 제공자가 제안을 승인하면, 해당 개인에 대한 KYC 검증을 수행하는 대가로 POLY 토큰으로 지급받게 됩니다. 이 과정은 Polymath 플랫폼에 상당한 온보딩 마찰을 야기하며, 프로세스를 불필요하게 복잡하게 만듭니다.

2. 사용자에 대한 이 정보는 이후 온체인에서 어떻게 저장되고 접근합니까?

Harbor

Harbor의 백서와 GitHub에 공개된 스마트 계약을 살펴보면, 기술적으로 Harbor의 많은 토큰이 하나의 공통 Regulator 계약과 하나의 공통 사용자 데이터 소스를 공유할 수 있습니다. 그러나 이는 토큰마다 규제 요건이 다르기 때문에 현실적으로는 어려울 것으로 보입니다. 현재 이더리움에 실시간으로 존재하는 Harbor 토큰이 없기 때문에, 이러한 설계가 의도된 것인지, 각 토큰이 자체 Regulator와 함께 배포될 것인지 명확히 알 수 없습니다.

Securitize

Securitize 프로토콜은 Regulator 계약이 사용자 정보를 저장하는 세 번째 스마트 계약을 조회하도록 설계되었습니다. 이를 통해 각 토큰은 자체 Regulator에 고유한 규제를 인코딩하면서도, 세 번째 계약에 저장된 공통 사용자 데이터 소스를 공유할 수 있습니다. 따라서 사용자가 하나의 Securitize 토큰에 대해 KYC를 수행하면, 그 정보가 저장되어 향후 다른 토큰을 구매할 때도 바로 활용될 수 있습니다.

Polymath

Polymath 백서에는 온체인에 저장된 중앙 규제 데이터 소스가 존재하고 각 Regulator가 이를 활용하는지, 혹은 토큰마다 자체 로컬 정보를 갖는지 명시되어 있지 않습니다. 그러나 Polymath의 샘플 계약을 보면 각 토큰이 로컬 정보를 사용하며, 이는 토큰 간에 공유되지 않습니다. 이러한 설계는 장점이 있을 수 있지만, 데이터 중복 및 일관성 문제를 야기할 위험이 있습니다.

예를 들어, Bob이 Polymath 보안 토큰 두 개인 ABC와 DEF에 관심을 보였고, 각각에 대해 투자자로 승인받았다고 가정해 보겠습니다. 이 정보는 각각의 토큰에 대한 Regulator 계약에 전달됩니다. 한 달 후, Bob이 추가로 DEF 토큰을 구매하려고 시도했지만, 그는 더 이상 인증된 투자자가 아니라고 판단됩니다. 이 정보는 DEF의 Regulator에 전달되어 Bob의 투자자 상태를 비인증으로 업데이트합니다. 이제 온체인에는 상충되는 정보가 존재합니다—ABC는 Bob을 인증된 투자자로 간주하지만, DEF는 그렇지 않습니다. 중앙 정보 소스가 있다면 이러한 불일치를 방지할 수 있음을 쉽게 알 수 있습니다.

Interoperability of the Protocols

앞서 논의한 바와 같이, 보안 토큰의 발행 및 교환에 관여하는 주요 당사자는 두 가지이며, 이들에게 상호운용성은 매우 중요합니다—거래소와 투자자. 이 두 당사자는 서로 다른 보안 토큰과 상호작용할 때 원활한 경험을 원합니다. 따라서 프로토콜을 그대로 사용할 경우, 거래소와 사용자가 어떻게 영향을 받을지 살펴보겠습니다.

Exchanges

거래소 입장에서는 전송 목적의 프로토콜 통합이 쉽습니다—모든 토큰이 ERC-20 표준을 사용하므로 전송, 승인 및 잔액 조회를 위한 일관된 인터페이스를 제공합니다. 그러나 각 프로토콜의 규제 측면을 통합하는 것은 훨씬 복잡합니다. 현재는 신뢰할 수 있는 당사자가 Harbor 프로토콜에 권한을 부여받는 것이 불가능하므로, 사용자를 Harbor에 직접 KYC하도록 유도해야 합니다. Securitize 프로토콜과 통합하려면, 신뢰당사자는 Securitize에 의해 권한을 부여받아야 하며, 이를 통해 오프체인 API를 통해 투자자 KYC 데이터를 접근하고 온체인 데이터 저장소에 정보를 업데이트할 수 있습니다.

Polymath 프로토콜과 통합하는 것이 가장 복잡할 것으로 보입니다. 신뢰당사자는 Polymath의 KYC 마켓플레이스에 KYC 제공자로 등록하고, KYC 서비스를 제공한 대가로 POLY 토큰을 입찰받을 수 있도록 설정해야 합니다. 투자자에게 KYC 서비스를 제공하면서, 각 보안 토큰의 Regulator④에 저장된 중복된 온체인 데이터가 일관성을 유지하도록 관리하는 방안을 마련해야 합니다.

프로토콜마다 통합해야 할 인터페이스가 다를 뿐만 아니라, 각 프로토콜은 거래소에 오류 보고를 제공하는 방식도 다릅니다. 인터페이스를 구축할 때 발생하는 오류를 사용자에게 이해하기 쉬운 형태로 전달할 수 있어야 합니다. 예를 들어, 사용자가 토큰을 구매할 수 없는 경우, 이는 보안의 보유 기간이 아직 충족되지 않았거나 허용 가능한 보유자 수를 초과했기 때문일 수 있습니다. 이러한 메시지를 사용자에게 전달하려면, 거래소는 각 프로토콜별로 다른 오류 보고 방식을 통합해야 합니다.

Investors 

현재 프로토콜에서 설계된 투자자 온보딩 방식이 서로 다르기 때문에, 투자자는 여러 플랫폼에 개인 정보를 여러 번 제공해야 할 가능성이 높습니다. 이는 Harbor가 다른 당사자에게 권한을 부여하지 않았고, Polymath가 투자자가 POLY 토큰을 사용해 KYC 절차에 입찰하도록 요구하기 때문입니다. 이러한 규제 방식의 마찰은 투자자가 원래 구매하려던 증권을 구매하지 못하거나 구매 의지를 잃게 만들 수 있습니다.

이러한 프로토콜로 인한 마찰 규모는 거래소가 각 프로토콜을 통합하는 방식에 따라 다소 완화될 수 있습니다. 예를 들어, 투자자가 Polymath 토큰을 구매하기 위해 거래소에서 KYC를 수행한다면, 해당 거래소가 권한을 가지고 있다면 동시에 Securitize의 데이터 저장소를 업데이트하도록 선택할 수 있습니다. 이는 투자자의 정보가 향후 필요할 경우를 대비해 온체인에 저장된다는 의미입니다. 그러나 현재 프로토콜 설계에 변화가 없으면, 증권 등록 및 구매 과정은 여전히 부담스럽게 남을 것입니다.

Solutions

이 문제에 대한 해결책은 반드시 복잡할 필요는 없습니다. 실제로 이미 이더리움에 존재하는 토큰을 변경하지 않고도 특정 솔루션을 도입할 수 있습니다. 거래소와 투자자 모두에게 최소한의 마찰을 제공하고, 다양한 규제 데이터 소스로 인한 데이터 불일치를 방지하는 이상적인 해결책은 Securitize의 중앙화된 온체인 데이터 저장소와 유사할 것입니다—하지만 이러한 설정은 업계 전반에 걸쳐 채택되어야 합니다.

온체인에 중앙 정보 소스를 두면 데이터 불일치 위험이 사라지고, 투자자는 하나의 규제 검증만으로 다양한 증권을 구매할 수 있게 됩니다. 이 중앙 계약은 모든 보안 토큰에 대한 전송이 규제에 부합하는지 검증하고, 전송을 계속하거나 되돌릴지를 결정합니다. 모든 권한이 부여된 거래소가 접근할 수 있는 오프체인 API를 통해 투자자 규제 정보를 거래소에 전달함으로써 투자자가 데이터를 제공해야 하는 횟수를 줄일 수 있습니다. 이러한 요소들은 거래소가 수행해야 할 통합 작업량을 크게 감소시킵니다.

이와 같은 새로운 시스템을 도입하면 몇 가지 복잡성이 발생하며, 해결해야 할 문제도 남아 있습니다. 예를 들어, 각 거래소가 어떻게 권한을 부여받을지 설계할 때—누가 거래소를 신뢰할 수 있다고 판단할 것인가?—합의를 도출할 수 있는 시스템을 설계하는 데 시간이 필요합니다.

Conclusion

증권 토큰화는 아직 초기 개발 및 채택 단계에 있으며, 이는 규제 준수의 복잡성 때문입니다. 프로토콜이 발표됨으로써 많은 규제를 각 전송 실행 시 강제함으로써 규제 준수를 단순화했지만, 원활한 프로세스가 되기까지는 아직 갈 길이 멉니다. 프로토콜 간에 투자자 정보가 온체인 및 오프체인에서 어떻게 저장·업데이트될지에 대한 합의가 이루어지지 않는 한, 모든 관련 당사자에게 등록 및 투자 과정에서 상당한 마찰이 지속될 것입니다.