[Xangle RWA Series] 상호운용성 인프라

목차

1. RWA 사업자가 브릿지를 활용하는 세 가지 경우

2. 브릿지 도입의 핵심 고려사항

3. 활용 목적에 따른 브릿지·상호운용 인프라

4. RWA 발행사와 금융기관의 도입 사례

5. 마무리: RWA의 유통과 활용을 넓히는 연결 인프라

 

 

1. RWA 사업자가 브릿지를 활용하는 세 가지 경우

RWA 상품이 여러 체인에서 유통되면, 고객이 자산을 보유한 체인과 이용하려는 서비스의 체인이 서로 다른 상황이 생긴다. RWA 사업자는 고객 자산을 원하는 체인으로 보내거나, 자체 발행 토큰의 유통 범위를 넓히거나, 자사 서비스에서 여러 체인의 전송·스왑을 지원하기 위해 브릿지와 상호운용 인프라를 활용한다. 어떤 서비스를 제공하려는지에 따라 필요한 기능과 사업자가 맡을 역할도 달라진다.

첫째, 고객과 기관이 보유한 자산을 다른 체인으로 이전하는 경우다. 이용자가 보유한 자산을 다른 블록체인의 서비스에서 사용하거나, 원하는 체인으로 출금할 수 있도록 지원하는 것이 목적이다. 이 경우에는 목적지에서 고객이 어떤 자산을 받는지, 그 자산을 누가 지급하는지가 중요한 선택 기준이 된다.

둘째, 사업자가 직접 발행한 토큰의 유통 범위를 여러 체인으로 넓히는 경우다. 발행자는 같은 상품을 여러 블록체인의 이용자에게 제공하기 위해 체인별 토큰을 연결하고 이동을 지원한다. 이 과정에서 전체 공급량을 유지하고, 투자자 자격과 전송 제한 등 상품의 관리 기준도 각 체인에서 일관되게 적용해야 한다.

셋째, 자사 서비스에 멀티체인 전송·스왑 기능을 통합해 제공하는 경우다. 사업자는 여러 브릿지와 스왑 서비스를 연결해 고객이 자사 서비스 안에서 자산을 이전하거나 교환할 수 있도록 한다. 고객이 원하는 체인과 자산을 선택하면, 서비스는 연결된 인프라를 통해 이용 가능한 경로를 찾고 전송과 교환을 진행한다. 고객은 필요한 기능을 이용하기 위해 체인마다 별도의 서비스를 찾아다니는 번거로움을 줄일 수 있다.

이처럼 브릿지와 상호운용 인프라는 활용 목적에 따라 필요한 기능과 처리 방식이 달라진다. 이하에서는 브릿지 도입 시 고려할 공통 기준을 먼저 살펴본 뒤, 세 가지 활용 목적에 따른 주요 전송 방식과 서비스를 소개한다.

 

2. 브릿지 도입의 핵심 고려사항

브릿지를 선택할 때는 원하는 체인과 자산을 지원하는지뿐 아니라, 실제 서비스 운영에 필요한 조건을 충족하는지도 확인해야 한다. 전송 성능과 안정성, 유동성과 수령 토큰의 특성, 기술 지원과 사고 대응 체계, 규제 준수와 자산 통제를 중심으로 도입 전 검토할 사항을 살펴본다. 원하는 체인과 자산을 지원하더라도 고객이 필요한 시점에 자산을 받고, 문제가 생겼을 때 대응할 수 있어야 한다. 이 장에서는 전송 성능과 안정성, 유동성과 수령 자산, 기술 지원과 사고 대응, 규제 준수와 자산 통제를 기준으로 주요 검토 사항을 정리한다.

2-1. 전송 성능과 안정성

브릿지의 전송 성능은 고객이 자산을 보내는 순간부터 다른 체인에서 받아 사용할 수 있을 때까지 걸리는 시간을 기준으로 평가해야 한다. 예를 들어 Base에서 USDC의 출금 처리가 끝났더라도 고객이 Ethereum에서 받아 사용하기까지는 시간이 더 걸릴 수 있다. 따라서 출발 체인의 처리 표시와 목적지의 실제 수령 시점을 구분해야 한다. 이용하는 체인과 자산, 전송 금액에 따라 완료 시간과 비용이 달라질 수 있으므로, 자사 서비스에서 사용할 조건에 맞춰 비교하는 것이 중요하다.

전송 속도와 함께 자산이 안전하게 전달되는지도 살펴봐야 한다. 전송 내역을 검증하는 주체와 목적지에서 고객에게 자산을 지급하는 주체가 다를 수 있으므로, 두 과정에서 각각 어떤 보호 장치가 작동하는지 이해할 필요가 있다. 보안 감사와 과거 사고 이력은 이를 판단하는 근거가 된다. 문제가 생겼을 때 전송을 멈추거나 자산을 돌려받을 수 있는 조건도 함께 검토해야 한다.

2-2. 유동성과 수령 자산 종류

전송 경로가 지원되더라도, 고객이 보내려는 금액을 목적지에서 바로 지급할 수 있는지는 별개의 문제다. 특히 목적지에 미리 확보한 자산으로 지급하는 방식인 유동성 기반형은 준비된 자산의 규모가 중요하다. 자산이 부족하면 지급이 지연되거나 전송 비용이 높아질 수 있고, 한 번에 보낼 수 있는 금액도 제한될 수 있다.

예를 들어 고객이 100만 달러 상당의 USDC를 다른 체인으로 보내려 한다고 가정하자. 목적지에서 브릿지가 바로 지급할 수 있는 USDC가 30만 달러뿐이라면, 고객은 부족한 USDC가 확보되기를 기다리거나 다른 경로를 이용해야 한다. 소액 전송이 원활한 경로라도 기관의 큰 주문을 같은 조건으로 처리할 수 있는 것은 아니므로, 예상 주문 규모에 맞는 유동성이 필요하다.

필요한 금액을 지급할 수 있는지와 함께, 고객이 최종적으로 어떤 토큰을 받는지도 중요하다. Circle이 직접 발행한 USDC와, 브릿지가 USDC를 보관한 뒤 다른 체인에 대신 발행한 토큰은 구분된다. 브릿지가 발행한 토큰으로 원래 자산을 돌려받으려면 보관된 USDC가 정상적으로 반환되어야 하므로, 브릿지에 문제가 생기면 회수가 어려워질 수 있다. 또한 거래소나 서비스가 두 토큰을 모두 지원하는 것은 아니어서, 고객이 받은 토큰의 사용처가 제한될 수도 있다.

2-3. 기술 지원과 사고 대응 체계

브릿지를 서비스에 연결한 뒤에도 전송 지연이나 장애의 원인을 파악할 수 있는 지원 체계가 필요하다. 연동 과정에서 어떤 기술 지원을 받을 수 있는지, 운영 중 문제가 생기면 누구에게 연락해야 하는지가 여기에 해당한다. 지원 시간과 대응 범위를 미리 알아두고, 특정 체인이나 전송 경로의 지원이 바뀔 때 충분한 안내를 받을 수 있는지도 살펴봐야 한다.

문제의 원인을 파악한 뒤 누가 어떤 조치를 취할지도 미리 정해두어야 한다. 브릿지 제공자가 복구할 부분과 사업자가 직접 처리할 부분을 나누고, 고객 안내와 환불의 담당자를 명확히 해야 한다. 장애가 길어지면 신규 전송을 잠시 멈추거나 다른 경로로 전환하는 조치가 필요할 수 있다. 이러한 판단과 실행을 누가 맡는지 정해두어야 대응이 늦어지는 일을 줄일 수 있다.

2-4. 규제 준수와 RWA 자산 통제

자산 전송 기능을 연결할 때는 고객 확인과 거래 관리의 역할도 함께 나눠야 한다. 고객확인(KYC)과 자금세탁방지(AML) 의무는 사업자가 제공하는 서비스와 운영 국가에 따라 달라진다. 브릿지가 자산을 전송해 준다고 해서 사업자에게 적용되는 의무까지 대신 이행해 주는 것은 아니다. 고객 자격 확인과 거래 점검을 누가 담당할지, 브릿지 제공자와 사업자의 역할을 미리 정해야 하는 이유다.

예를 들어 적격 투자자만 보유할 수 있는 토큰화 펀드를 다른 체인으로 보내는 경우다. 목적지 지갑이 기술적으로 토큰을 받을 수 있더라도, 그 지갑을 사용하는 투자자가 상품의 가입 요건을 충족하는지는 별도로 확인해야 한다. 전송 전에 수령인의 자격과 발행자의 허용 여부를 확인해야 하며, 체인을 옮기더라도 상품에 정해진 투자자 제한은 유지되어야 한다.

수령인의 자격을 확인한 뒤에도 목적지 체인에서 상품의 관리 기준을 계속 적용할 수 있어야 한다. 다른 체인으로 옮겼다는 이유로 투자자 제한이 풀리거나 보유자 정보를 확인할 수 없게 되어서는 안 된다. 동결이나 보유자 변경 기능이 필요한 상품이라면 목적지 체인에서도 해당 기능을 사용할 수 있어야 한다.

 

3. 활용 목적에 따른 브릿지·상호운용 인프라

앞서 살펴본 기준을 바탕으로 주요 서비스를 비교하려면, 각 서비스가 전송 과정의 어느 부분을 담당하는지 구분할 필요가 있다. 여러 서비스가 하나의 거래에 함께 쓰이기도 한다. 예를 들어 고객이 다른 체인으로 자산을 보낼 때 라우팅 서비스가 경로를 찾고, 실제 자산 이동은 선택된 브릿지가 처리할 수 있다.

이 장에서는 자산의 이전, 자체 발행 토큰의 유통·관리, 자사 서비스의 전송·스왑 통합 순으로 주요 방식과 서비스를 비교한다. 각 절에서는 먼저 공통적인 처리 방식을 설명하고, 해당 방식을 제공하는 서비스의 차이와 활용 조건을 살펴본다.

3-1. 자산의 체인 간 이전

고객과 기관의 자산을 다른 체인으로 보내는 주요 처리 방식은 번앤민트형, 락앤민트형, 유동성 기반형과 기관 계정·수탁형으로 나눠 살펴볼 수 있다. 한 서비스가 여러 방식을 함께 제공하기도 하므로, 실제 이용하는 경로를 기준으로 차이를 이해해야 한다.

번앤민트형은 출발 체인에서 토큰을 소각하고 목적지에서 같은 발행자의 토큰을 새로 발행한다. 락앤민트형도 목적지에서 토큰을 발행하지만, 원본을 소각하는 대신 출발 체인에 보관하고 이를 나타내는 토큰을 지급한다. 유동성 기반형은 새 토큰을 발행하는 대신 목적지의 풀이나 릴레이어가 미리 보유한 자산으로 고객에게 지급한다. 기관 계정·수탁형을 이용하면 사업자는 이러한 전송 과정을 직접 연결하는 대신, 서비스 계정에 자산을 입금하고 받을 체인을 지정해 출금할 수 있다.

각 방식을 비교할 때는 고객이 받는 토큰의 형태와 지급 주체, 사업자가 직접 운영해야 하는 범위를 함께 살펴볼 필요가 있다.

1) 번앤민트형

번앤민트형은 출발 체인에서 토큰을 소각하고 목적지 체인에서 같은 수량을 새로 발행하는 방식이다. 발행자가 체인별 소각과 발행을 연결하므로, 고객은 목적지에서도 발행자가 직접 발행한 토큰을 받을 수 있다. 목적지에 지급용 자산을 미리 확보할 부담은 작지만, 이용 가능한 자산과 체인은 발행자가 지원하는 범위로 제한된다.

Circle CCTP

Circle CCTP는 USDC의 체인 간 전송을 지원하는 번앤민트 프로토콜이다. 예를 들어 Base의 USDC를 Ethereum으로 보내면 Circle이 Base에서 소각이 이루어졌는지 확인하고, 이를 근거로 Ethereum에서 USDC를 새로 발행한다. 고객은 목적지에서도 Circle이 직접 발행한 USDC를 받는다.

일반 전송은 출발 체인의 거래가 충분히 확정될 때까지 기다린다. 빠른 전송은 완전한 거래 확정에 앞서 Circle의 가용 한도 안에서 목적지에 USDC를 발행해 대기 시간을 줄인다. 실제 전송 속도는 이용하는 체인과 가용 한도의 영향을 받는다. 사업자가 이러한 전송을 자사 서비스에 넣을 수 있도록 통합 개발 도구를 제공하며, 전송 후 예치 같은 작업도 연결할 수 있다.

2) 락앤민트형

락앤민트형은 원본 토큰을 출발 체인의 보관 컨트랙트에 잠그고, 목적지에서 이를 나타내는 래핑 토큰을 발행하는 방식이다. 원래 체인으로 돌아올 때는 래핑 토큰을 소각하고 보관된 원본을 돌려받는다. 발행자가 목적지에서 직접 토큰을 발행하지 않아도 자산을 연결할 수 있지만, 고객이 받는 토큰은 원본과 별도로 취급될 수 있다. 원본의 보관과 반환은 브릿지에 의존한다.

Wormhole Wrapped Token Transfers·Portal (WTT)

Wormhole의 WTT(Wrapped Token Transfers)는 락앤민트 방식으로 여러 체인 사이의 자산 이전을 지원하는 전송 프로토콜이다. 이용자는 Portal 화면에서 이 기능을 사용할 수 있다. 예를 들어 Ethereum의 자산을 다른 체인으로 보내면 원본은 보관 컨트랙트에 잠기고, 수령인은 그 자산을 나타내는 래핑 토큰을 받는 방식으로 작동한다. Guardian이라 부르는 검증 참여자들이 전송 내역을 확인하며, 이를 근거로 목적지 체인에서 래핑 토큰이 발행된다. 전송과 함께 목적지에서 수행할 작업 정보도 보낼 수 있다.

WTT는 30개가 넘는 체인과 여러 토큰 형식을 지원해, 발행자가 목적지 체인에 직접 토큰을 발행하지 않아도 다양한 자산을 연결하기 쉽다. 다만 목적지에서 받는 래핑 토큰은 원본 자산과 별도의 토큰으로 취급될 수 있다. 같은 자산도 브릿지마다 서로 다른 래핑 토큰으로 유통되면 거래와 유동성이 여러 토큰으로 나뉘는 파편화가 발생할 수 있다. 원본 자산을 지원하는 거래소·DeFi라도 모든 래핑 토큰을 지원하는 것은 아니므로, 고객이 받은 토큰의 사용처가 제한될 수 있다.

체인 공식 브릿지

체인이 제공하는 공식 입출금 경로를 이용하는 방법도 있다. Ethereum 기반 롤업에서는 Ethereum에 자산을 보관하고 L2에서 그에 해당하는 토큰을 발행하거나, 반대로 출금할 때 보관된 자산을 돌려준다. 이 과정은 Ethereum의 검증·정산 체계에 기반한다. 따라서 Wormhole의 Guardian처럼 별도의 브릿지 검증 집단을 추가로 신뢰해야 하는 부담을 줄일 수 있다. 목적지에서 먼저 지급할 자산을 따로 마련하지 않아도 된다.

다만 지원 경로가 특정 체인에 한정되고, 출금 속도도 그 체인의 검증 절차를 따른다. 낙관적 롤업은 거래 결과를 먼저 받아들인 뒤 잘못된 결과에 이의를 제기할 시간을 두므로, L2에서 Ethereum으로 출금하려면 이 기간이 지나야 한다. 예를 들어 Ethereum에서 Arbitrum One으로 입금할 때는 보통 15–30분이 걸리지만, 공식 경로로 다시 Ethereum에 출금할 때는 약 일주일을 기다린다. 즉시 출금이 필요한 서비스에서는 이 대기 시간이 제약이 된다. 이러한 대기 시간을 줄이려는 서비스에서는 목적지에 준비된 자산으로 먼저 지급하는 방식을 활용할 수 있다.

3) 유동성 기반형

유동성 기반형은 목적지 체인에 미리 확보한 자산을 고객에게 지급하는 방식이다. 유동성 풀이나 릴레이어(자신의 자산으로 먼저 지급하고 나중에 정산받는 참여자)가 보유한 자산을 활용하므로, 고객은 다른 체인에서의 정산이 끝날 때까지 기다리지 않고 자산을 받을 수 있다. 빠른 지급에 유리하지만 전송 규모가 크거나 특정 체인으로 수요가 몰리면 준비된 자산이 부족해질 수 있다. 이 경우 이용 가능한 금액이 제한되거나 전송 비용이 높아질 수 있다.

Across

Across는 릴레이어(relayer)가 목적지 체인에서 고객에게 자산을 먼저 지급하고 나중에 정산받는 전송 서비스다. 고객이 출발 체인에 자산을 입금하면 릴레이어는 입금 내역과 수령 조건을 확인한 뒤, 자신이 보유한 목적지 체인의 자산을 지급한다. 예를 들어 Ethereum의 USDC를 Base로 보낼 때는 릴레이어가 보유한 Base의 USDC를 먼저 보내준다. 릴레이어는 전송을 처리한 대가로 수수료를 받고, 입금과 지급 내역이 검증되면 먼저 지급한 금액을 돌려받는다. 고객은 이 정산을 기다리지 않고 받은 자산을 사용할 수 있다.

빠른 지급이 가능하려면 릴레이어가 목적지 체인에 충분한 자산을 확보하고 있어야 한다. 큰 주문이 들어오거나 특정 체인으로 전송이 몰리면 전송 가능한 금액이 제한되거나 수수료가 높아질 수 있다. 사업자가 Across의 전송 기능을 자사 서비스에 통합할 때는 개발 도구인 Swap API를 활용할 수 있다. 이를 이용하면 체인 간 전송에 자산 교환이나 목적지 예치까지 연결해, 고객이 여러 서비스를 옮겨 다니지 않고 필요한 작업을 처리하도록 구성할 수 있다. 전송 대상이 투자자 자격을 제한하는 RWA 토큰이라면 추가 조건도 생긴다. 릴레이어 역시 해당 토큰의 보유·전송 요건을 충족해야 하므로, 참여할 수 있는 릴레이어와 전송 경로가 제한된다.

Stargate

Stargate는 여러 체인의 자산과 전송 방식을 하나의 서비스로 연결한다. Across가 릴레이어의 보유 자산으로 먼저 지급한다면, Stargate의 풀 기반 경로는 유동성 공급자들이 체인별 풀에 모아 둔 자산을 활용한다. 고객이 출발 체인의 풀에 자산을 입금하면 LayerZero를 통해 입금 정보가 전달되고, 목적지 체인의 풀에서 고객에게 자산을 지급한다.

Stargate는 풀 기반 전송 외에 발행자가 체인별 토큰 컨트랙트를 연결하는 OFT 경로와, Circle이 USDC를 소각·발행하는 CCTP 경로도 제공한다. 고객은 같은 화면에서 체인과 자산을 선택해 전송할 수 있어, 전송 방식마다 별도의 서비스를 이용하는 번거로움을 줄일 수 있다. 다만 풀 기반 경로는 목적지에 확보된 자산이 부족하면 한 번에 보낼 수 있는 금액이 제한된다. OFT 경로는 연결된 토큰 컨트랙트의 전송 규칙을, CCTP 경로는 Circle의 소각 확인과 발행 절차를 따른다. 따라서 같은 화면에서 주문하더라도 선택된 경로의 유동성과 발행 절차에 따라 수령 시간과 비용이 달라진다.

4) 기관 계정·수탁형

기관 계정·수탁형은 사업자가 전송 프로토콜을 직접 연동하는 대신, 발행사나 수탁기관의 계정에 자산을 입금한 뒤 목적지 체인을 지정해 출금하는 방식이다. 해당 기관이 제공하는 계정 잔액과 입출금 기능을 이용하며, 수탁 서비스를 이용하면 자산 보관과 승인 절차도 함께 맡길 수 있다. 이용 가능한 자산·체인과 출금 조건은 각 기관의 정책을 따른다.

Circle Mint

Circle Mint는 기관이 USDC·EURC를 발행·상환하고 지원 체인으로 입출금할 수 있는 계정·API 서비스다. CCTP가 토큰의 소각과 발행을 직접 연결하는 전송 프로토콜이라면, Mint는 기관이 계정 잔액을 기준으로 입출금과 법정화폐 전환을 관리하는 서비스다. 예를 들어 Base에서 받은 USDC를 Mint 계정에 입금한 뒤 Ethereum을 지정해 출금할 수 있다. 고객 출금과 기업 자금관리를 같은 계정 체계에서 운영하려는 경우에 활용할 수 있다.

주요 이용 대상은 거래소·은행·기관 트레이더처럼 USDC·EURC를 대규모로 취급하는 기관이다. 발행사인 Circle과 직접 연결해 스테이블코인 입출금과 법정화폐 전환을 한 계정에서 처리할 수 있다는 점이 강점이다. 담당자별 권한과 거래의 이중 승인을 설정해 기관 내부의 자금 집행 절차를 계정 운영에 반영할 수 있다. Circle 자체 재무팀 역시 이러한 기능을 기업 간 USDC 정산에 활용했다. 다만 기관 계정 개설과 이용 자격 심사를 거쳐야 하며, 입출금할 수 있는 자산과 체인도 Circle이 지원하는 범위로 제한된다.

Coinbase Prime

Coinbase Prime은 기관용 디지털 자산 수탁 서비스에 거래와 여러 네트워크의 입출금 기능을 결합한 플랫폼이다. 예를 들어 Prime Trading Balance에 Ethereum과 Base를 통해 입금된 USDC는 하나의 USDC 잔액으로 합산되며, 출금할 때는 자산을 받을 네트워크를 지정한다. Circle Mint가 발행자의 USDC·EURC 계정 서비스라면, Prime은 USDC·ETH·BTC 등 여러 지원 자산의 거래와 수탁을 함께 운영하는 계정이라는 차이가 있다.

거래·보관·출금을 한곳에서 처리하면 체인별 지갑과 잔액을 따로 관리하는 부담을 줄일 수 있다. 다만 계정에 잔액이 반영된 시점과 목적지 체인에서 자산을 사용할 수 있는 시점은 구분해야 한다. 여러 네트워크의 입출금과 잔액 합산은 지갑 유형에 따라 다르게 적용되며, 출금에는 지원 자산·네트워크의 범위와 승인 절차, 한도가 적용된다. 네트워크 상황에 따라 처리도 지연될 수 있다.

Anchorage Digital

Anchorage Digital은 미국 통화감독청(OCC)의 인가를 받은 Anchorage Digital Bank를 중심으로 기관 수탁과 거래·결제, 스테이블코인 발행 서비스를 제공한다. Coinbase Prime처럼 기관의 자산을 보관하고 외부 주소로 이체·출금하는 기능을 제공한다. 기관은 화면이나 API에서 출금할 자산과 수령 주소를 지정하고, 내부 정책에 맞춘 승인 절차를 적용할 수 있다. 이를 통해 자산 보관과 내부 승인, 입출금을 하나의 체계에서 운영할 수 있다.

일반 수탁 자산의 출금 외에, 지원 스테이블코인의 발행·상환과 체인 간 전환 기능도 제공한다. 체인 간 전환을 요청하면 출발 체인에서 토큰을 소각하고, 같은 준비금을 바탕으로 목적지 체인에서 동일한 수량을 새로 발행한다. 이를 통해 기관은 별도의 브릿지를 직접 연결하지 않고 지원 스테이블코인을 다른 체인으로 옮길 수 있다. 다만 이 소각·발행 방식은 Anchorage가 전환 기능을 지원하는 토큰·체인 조합에 한정되며, 일반 수탁 자산의 출금과는 구분된다.

3-2. 자체 발행 토큰의 공급 관리

자체 스테이블코인이나 토큰화 펀드를 발행하는 사업자는 체인 간 전송뿐 아니라 각 체인의 발행량도 함께 관리해야 한다. 같은 상품을 여러 체인에서 제공하려면 체인별 토큰을 배포하고 서로 이동할 수 있도록 연결하면서, 각 체인에서 유통되는 수량을 합산해 전체 공급량을 유지해야 한다.

예를 들어 Ethereum에 있는 토큰 100개 중 20개를 소각·발행 방식으로 Base로 옮기면, Ethereum에서 20개를 소각하고 Base에서 20개를 새로 발행한다. 전송 후에는 Ethereum에 80개, Base에 20개가 유통되므로 전체 공급량은 100개로 유지된다. 발행자는 공급량과 함께 상품의 보유·전송 조건도 유지해야 한다. 특정 투자자만 보유할 수 있는 상품이라면 Base로 옮긴 뒤에도 같은 자격 요건을 적용하는 식이다. LayerZero OFT와 Wormhole NTT 같은 토큰 프레임워크는 체인별 토큰을 연결하고 이러한 공급 관리 구조를 구현하는 데 사용하는 도구다.

LayerZero OFT

LayerZero OFT는 같은 토큰을 여러 체인에서 유통하면서 전체 공급량을 관리할 수 있도록 하는 토큰 표준이다. LayerZero의 메시지 전달 기능으로 체인별 토큰 컨트랙트를 연결해, 출발 체인에서 토큰을 소각하거나 잠그면 목적지 체인에서 같은 수량을 발행하거나 해제한다. 신규 토큰에는 OFT 기능을 처음부터 포함할 수 있다. 기존 토큰은 원래 컨트랙트를 유지한 채 별도의 어댑터 컨트랙트를 추가해 체인 간 전송을 지원할 수 있다.

발행자는 전송 메시지를 검증하는 분산 검증 네트워크(DVN)와 목적지에서 거래를 실행하는 실행자(Executor)를 선택한다. 이를 통해 상품의 보안 정책에 맞는 검증 조합을 구성하고, 여러 체인의 토큰을 같은 기준으로 연결할 수 있다. 다만 체인을 추가할 때마다 토큰 컨트랙트와 연결 대상, 검증 설정을 함께 운영해야 한다. 설정 오류나 관리자 권한의 오용이 전송에 영향을 줄 수 있으므로, 검증 구성을 직접 선택하는 발행자는 체인별 설정과 관리자 권한을 관리하는 책임도 함께 부담한다.

Wormhole NTT

Wormhole NTT(Native Token Transfers)는 발행자가 직접 관리하는 토큰을 여러 체인에서 연결하는 프레임워크다. 앞서 소개한 WTT가 브릿지의 래핑 토큰을 발행하는 방식이라면, NTT에서는 발행자가 토큰 컨트랙트의 관리·업그레이드 권한을 유지한다. 각 체인에 전송을 담당하는 스마트컨트랙트(NTT Manager)를 배포해 토큰의 소각·발행이나 잠금·해제를 처리한다. 소각·발행 방식에서는 이 컨트랙트에 토큰을 소각하거나 발행할 수 있는 권한을 부여한다.

NTT는 체인별 전송 한도와 긴급 중단 기능을 제공해 발행자가 자산 이동을 통제할 수 있도록 한다. 예를 들어 특정 체인으로 짧은 시간에 많은 토큰이 이동하면 한도를 넘는 전송을 대기시키고, 이상이 발생하면 전송을 중단할 수 있다. 이를 통해 토큰 관리 권한을 유지하면서 체인 간 이동에도 위험관리 정책을 적용할 수 있다. 다만 한도를 낮게 설정하면 정상적인 전송 요청도 대기열에 쌓여 처리가 지연될 수 있다. 전송 한도는 이상 거래를 제한하는 수단이지만, 평상시 주문의 처리량과 대기 시간에도 영향을 준다.

Chainlink CCT·CCIP

Chainlink CCIP는 체인 간에 메시지와 토큰을 전달하는 서비스이며, CCT(Cross-Chain Token)는 발행자의 토큰을 CCIP에 연결하는 표준이다. 발행자는 각 체인에 토큰의 발행·소각 또는 보관·해제를 담당하는 토큰 풀(Token Pool) 컨트랙트를 배포하고, 해당 체인의 토큰과 연결한다. 예를 들어 출발 체인의 토큰 풀이 토큰을 소각하면 CCIP가 그 정보를 전달하고, 목적지 체인의 토큰 풀이 같은 수량을 발행한다. 기존 토큰도 필요한 권한을 토큰 풀에 부여해 연결할 수 있다.

토큰과 함께 목적지에서 수행할 작업을 전달할 수 있어, 자산 전송 후 예치나 상품 대금 지급을 이어서 처리하는 서비스에 활용할 수 있다. 예를 들어 Ethereum의 결제용 토큰을 Base로 보내면서 펀드 청약 요청을 함께 전달하고, Base의 청약 컨트랙트가 도착한 토큰으로 신청을 처리하도록 구성할 수 있다. 고객은 자산을 옮긴 뒤 청약을 위해 별도의 거래를 제출하는 과정을 줄일 수 있다. 다만 이용 범위는 CCIP가 지원하는 체인과 연결 경로에 한정되며, 필요한 권한을 부여한 토큰 풀의 관리자 설정도 중요하다. 전송이나 목적지 컨트랙트 실행이 지연되면 이어서 진행할 펀드 청약도 늦어질 수 있다.

Axelar ITS

Axelar ITS(Interchain Token Service)는 신규 토큰과 기존 토큰의 체인 간 전송을 지원하는 서비스다. Token Manager는 토큰 컨트랙트와 별도로 배포되어, 전송에 필요한 소각·발행이나 잠금·해제를 처리하는 스마트컨트랙트다. 발행자는 기존 토큰의 구조에 맞는 관리 방식을 선택하고, Axelar의 메시지 전달 기능으로 각 체인의 Token Manager가 수행하는 처리를 연결한다.

ITS를 이용하면 토큰의 구조에 맞는 전송 방식을 선택하고, 전송에 목적지 컨트랙트 실행을 연결할 수 있다. 토큰별·체인별 전송량 한도를 설정해 짧은 시간에 과도한 자산이 이동하는 것도 제한할 수 있다. 다만 소각·발행형 관리 컨트랙트에는 토큰의 발행·소각 권한을 부여해야 하고, 잠금형 컨트랙트에는 원본 자산이 보관된다. 발행자는 선택한 방식에 맞춰 컨트랙트에 부여한 권한과 보관 자산을 지속적으로 관리해야 한다.

3-3. 여러 체인의 전송·스왑 통합

라우팅 서비스는 여러 브릿지와 탈중앙화 거래소(DEX)를 연결해, 고객이 원하는 체인과 자산에 맞는 전송·교환 경로를 찾아주는 서비스다. 예를 들어 Base의 USDC를 Ethereum의 ETH로 바꾸려면 체인 간 전송과 자산 교환이 모두 필요하다. 라우팅 서비스는 이용 가능한 경로의 수수료와 예상 수령액, 처리 시간을 비교하고 필요한 단계를 연결해 고객이 한 화면에서 주문할 수 있도록 한다.

사업자는 브릿지와 DEX를 하나씩 연동하는 부담을 줄이고, 고객은 여러 서비스를 옮겨 다니지 않고 자산을 전송하거나 교환할 수 있다. 다만 실제 처리는 선택된 브릿지와 DEX가 담당하므로, 해당 경로의 장애나 유동성 부족은 주문에도 영향을 준다. 전송 후 교환이 실패하면 원하는 자산 대신 중간 단계의 자산을 받을 수도 있다. 이 절에서는 여러 경로를 비교해 연결하는 LI.FI·Socket, Across의 전송에 교환과 후속 작업을 결합하는 Swap API를 살펴본다.

LI.FI

LI.FI는 여러 브릿지와 DEX, 릴레이어가 제공하는 전송·스왑 경로를 비교해 연결하는 서비스다. 사업자는 API와 SDK로 자사 서비스의 주문 과정을 구성하거나, 위젯을 넣어 전송·스왑 화면을 제공할 수 있다. 고객이 출발·목적지 체인과 자산을 지정하면 예상 수령액과 수수료, 처리 시간이 포함된 경로를 제시한다. 지원 경로에서는 목적지의 예치나 스테이킹 같은 후속 작업도 연결할 수 있다.

사업자는 수령액이 많은 경로나 처리 시간이 짧은 경로를 우선하고, 사용할 브릿지와 거래소를 허용하거나 제외할 수 있다. 이를 통해 자사 서비스의 기준에 맞는 경로를 고객에게 제공한다. 다만 제시되는 견적은 각 경로의 유동성과 수수료를 반영하며, 실제 전송의 안전성과 완료 시간도 선택된 브릿지의 영향을 받는다. 주문이 멈췄을 때는 LI.FI의 화면에 표시된 상태와 함께 실제로 사용한 브릿지와 교환 단계를 구분해야 지연 원인을 파악하고 대응할 수 있다.

Socket

Socket 역시 여러 브릿지와 DEX의 전송·스왑 경로를 API와 위젯으로 연결하는 서비스다. 출발 자산과 받을 자산, 수량을 입력하면 이용 가능한 경로와 실행에 필요한 거래 데이터를 제공한다. 사업자는 빠른 경로나 수령액이 많은 경로 등을 선택해 고객 지갑에서 거래를 실행하고, 주문 상태를 조회할 수 있다. 자체 화면을 개발하는 대신 Socket 위젯을 넣어 지갑이나 거래 앱 안에서 전송·스왑 기능을 제공할 수도 있다.

여러 경로를 한 화면에 연결하면 고객이 브릿지와 DEX를 직접 찾아다니는 번거로움을 줄일 수 있다. 다만 이러한 라우팅 서비스에서는 가장 빠른 경로와 가장 많은 자산을 받는 경로가 다를 수 있다. 사업자는 고객이 무엇을 우선할지 선택하도록 하거나, 자사 서비스의 기준에 맞춰 경로를 제시할 수 있다. 견적을 받은 뒤 가격이 움직이거나 이용 가능한 유동성이 줄면 처음 제시한 조건으로 주문하기 어려울 수 있으므로, 실행 전에 견적을 갱신하거나 다른 경로를 제시하는 과정도 필요하다.

Across Swap API

Across Swap API는 Across의 체인 간 전송에 자산 교환과 목적지 컨트랙트 실행을 연결하는 개발 도구다. 예를 들어 고객이 Base의 USDC로 Ethereum에서 제공되는 예치 서비스를 이용한다면, 체인 간 전송과 필요한 자산 교환, 목적지의 예치를 하나의 주문으로 구성할 수 있다. 전송은 Across 릴레이어가 목적지에서 자산을 먼저 지급하는 방식을 사용한다. API는 견적·수수료와 함께 토큰 사용 승인과 주문 실행에 필요한 거래 데이터를 제공한다.

여러 브릿지의 견적을 비교하는 LI.FI·Socket과 달리, Across Swap API는 Across가 지원하는 전송 경로를 중심으로 주문을 구성한다. 이를 통해 사업자는 Across 전송을 자사 서비스에 넣고, 고객이 자산을 받은 뒤 예치나 구매까지 이어지는 과정을 간소화할 수 있다. 다만 이용 가능한 금액과 비용은 릴레이어가 목적지에 보유한 자산과 교환에 사용하는 DEX의 유동성에 영향을 받는다.

 

4. RWA 발행사와 금융기관의 도입 사례

실제 도입 사례에서는 체인을 연결하는 기술과 함께, 상품 관리와 기존 업무를 누가 맡는지가 중요하다. Ondo와 Securitize는 자체 상품의 관리 체계를 유지하면서 외부 인프라로 유통 범위를 넓힌다. Swift·ANZ·DTCC는 금융기관이 사용하던 메시징·결제·수탁 체계를 블록체인과 연결하는 방식을 검증한다. 각 사례가 해결하려는 문제와 외부 인프라에 맡긴 역할을 중심으로 살펴본다.

4-1. Ondo: 토큰 통제를 유지한 체인 간 전송

Ondo는 토큰화 상품인 USDY와 토큰화 주식·ETF를 여러 체인에서 이용할 수 있도록 LayerZero를 활용한다. USDY는 OFT를 기반으로 체인 간 이동을 지원하며, 이용자는 Ondo Bridge나 Stargate 화면에서 출발·목적지 체인을 선택하여 전송할 수 있다. 토큰화 주식·ETF인 Ondo Stocks도 Ethereum과 BNB Chain 사이의 전송을 지원한다. 이를 통해 고객은 보유한 상품을 다른 상품으로 바꾸지 않고도 이용할 체인을 옮길 수 있다.

이 과정에서 토큰의 발행과 공급량 관리는 Ondo가 맡고, LayerZero는 체인 간 전송 메시지를 전달한다. Ondo는 서로 다른 검증망이 전송 내역을 확인하도록 구성하고, 컨트랙트에 체인별 전송 한도와 긴급 중단 기능을 둔다. 발행자용 토큰 표준을 바탕으로 검증 방식과 전송 조건을 자체 정책에 맞춰 운영한다. 이를 통해 외부 메시징 인프라를 사용하면서도 자산별 전송 정책을 적용하고, 이상이 발생하면 전송을 제한하거나 중단할 수 있다.

4-2. Securitize: 펀드의 멀티체인 유통

Securitize는 금융기관과 기업의 자산 토큰화, 디지털 증권의 발행·관리·거래를 지원하는 금융 인프라 기업이다. 자산운용사의 펀드를 여러 체인에서 유통할 수 있도록 Wormhole의 메시지 전달 기능과 자체 스마트컨트랙트를 결합한 멀티체인 서비스를 제공한다. Wormhole은 체인 간 전송 정보를 전달하고, Securitize는 자체 시스템과 컨트랙트에서 상품별 투자자 자격과 이전 제한을 관리한다.

대표적인 사례인 VanEck의 토큰화 국채 펀드 VBILL은 Avalanche, BNB Chain, Ethereum과 Solana에서 제공되며, Wormhole이 지원 체인 사이의 연결을 담당한다. 투자자는 지원 체인 사이에서 토큰을 옮길 수 있으며, 전송 후에도 상품의 투자자 자격 요건과 이전 제한이 적용된다. 이를 통해 자산운용사는 투자자 관리 체계를 유지하면서 펀드의 유통 범위를 넓힐 수 있다.

4-3. 기존 금융 시스템과 블록체인의 연결

국제 금융 메시징 네트워크인 Swift는 은행이 사용하던 메시징 시스템을 통해 여러 블록체인의 자산을 이전할 수 있는지 실험했다. Chainlink로 Swift 네트워크와 블록체인을 연결하고, CCIP를 통해 퍼블릭 체인 간 또는 퍼블릭·프라이빗 체인 간에 모의 토큰을 옮겼다. 이를 통해 금융기관이 기존 Swift 접점으로 여러 체인에 접근하는 방식을 검증했다. 이러한 연결이 가능하면 금융기관이 체인마다 별도로 시스템을 연동해야 하는 부담을 줄일 수 있다.

호주·뉴질랜드계 은행인 ANZ는 테스트넷에서 체인 간 자산 구매와 대금 지급을 연결하는 방식을 시연했다. 모의 자산과 스테이블코인을 사용해, 고객이 은행의 서비스 화면에서 구매를 요청하면 CCIP를 통해 다른 체인으로 결제용 토큰을 보내고 대금 지급과 자산 인도가 함께 이루어지도록 구성했다. 이를 통해 고객의 구매 요청에서 체인 간 결제까지 이어지는 처리 과정을 검증했다.

미국의 증권 청산·결제 인프라 기업인 DTCC는 기존 수탁 증권을 토큰화해 실제 거래에 사용하는 방식을 선보였다. 2026년 7월 산하 증권예탁기관인 DTC의 수탁 증권을 LFDT Besu와 Canton 등 블록체인에서 토큰화하고, 담보 제공과 증권·대금 결제에 활용했다. 이 구조에서는 수탁 증권을 바탕으로 발행한 토큰을 참가자 지갑에 지급하고, 필요하면 기존의 보유 형태로 되돌릴 수 있다. 기존 수탁 체계의 권리관계를 유지하면서 증권을 블록체인 시장에서 활용하도록 연결한 사례다.

 

5. 마무리: RWA의 유통과 활용을 넓히는 연결 인프라

RWA 상품이 여러 체인에서 발행·유통되면서, 체인 간 연결은 상품의 접근성과 활용 범위를 결정하는 요소가 되고 있다. 같은 상품이라도 어느 체인에서 이용할 수 있는지에 따라 접근 가능한 투자자와 서비스가 달라지기 때문이다. 브릿지와 상호운용 인프라는 여러 체인에 분산된 이용자와 자산을 연결하고, 토큰화한 자산의 거래와 활용 범위를 넓히도록 돕는다.

이러한 확장에는 체인 간 전송 기능뿐 아니라 상품을 관리하고 기존 업무를 이어갈 수 있는 구조가 필요하다. Ondo와 Securitize는 외부 인프라를 사용하면서도 토큰의 발행이나 투자자 관리 등 각자의 역할을 유지한다. 금융기관 역시 기존 메시징·결제·수탁 체계를 블록체인과 연결하는 방식을 검증하고 있다. 연결 범위를 넓히는 과정에서도 상품에 대한 통제와 업무의 연속성을 유지하려는 접근이다.

RWA 사업자도 자사의 사업 구조와 각 연결 방식의 특성을 함께 이해한 뒤 도입 방향을 정할 필요가 있다. 고객 자산의 이전을 지원하는 사업과 자체 상품을 여러 체인에서 유통하는 사업은 필요한 기능과 책임 범위가 다르다. 각 방식의 장점과 제약을 자사의 운영 비용과 책임 범위, 고객의 이용 방식에 비춰 판단해야 적합한 인프라와 파트너를 선택할 수 있다. 앞으로 RWA 상품이 더 많은 체인과 금융 서비스에서 활용될수록, 이를 안정적으로 연결하는 브릿지와 상호운용 인프라의 역할도 더욱 중요해질 것으로 보인다.