1. 서론: 멀티체인 유동성 문제
퍼블릭 블록체인 생태계는 이제 단일 체인이 아니라 L1, L2, 롤업, 앱체인이 공존하는 멀티체인 환경을 전제로 한다.
사용자는 하나의 네트워크 안에서 자산을 운용하기보다, 여러 체인 사이를 오가며 자산을 배치·이동·교환한다. 이 과정에서 유동성과 사용자 경험은 체인 단위로 쪼개지고, 서비스 사업자 역시 체인별 인프라를 따로 통합해야 하는 상황에 직면한다.
1.1 체인·유동성 단편화와 사용자 경험
현재 Web3 시장의 유동성은 L1, L2, 롤업, 앱체인 증가로 인해 체인별 DEX·브릿지·토큰 표준을 중심으로 분산되어 있다. 동일한 자산이라도 체인마다 래핑 방식과 유통 경로가 달라지고, 사용자는 어떤 체인에서 어떤 형태로 보유하고 있는지를 확인해야 하는 불편함을 겪는다.
이 문제는 실제 서비스 이용 단계에서 더욱 구체적으로 드러난다. 온보딩 과정에서 브릿지, CEX, DEX 스왑, 가스 토큰 확보를 연속적으로 수행해야 하고, 단계마다 상이한 UI와 보안 모델이 적용되며 운영 전반의 복잡성이 증가한다. 서비스 사업자 입장에서는 사용자가 어느 체인에서 들어오든 대응하기 위해, 온보딩·결제·출금 플로우를 체인별로 반복 설계해야 하는 부담이 생긴다.
1.2 브릿지·CEX 중심 멀티체인 UX의 한계
이러한 멀티체인 환경에서 발생하는 유동성 파편화 문제에 대한 대응으로, 브릿지나 CEX 활용이 주된 방식으로 자리 잡아 왔다. 브릿지는 체인 간 토큰을 재현하는 기능을 제공하지만, 구현과 보안 모델이 제각각이며, 사용자는 브릿지 선택과 이에 따른 리스크를 직접 판단해야 할 뿐만 아니라, 체인 전환 이후에도 별도의 스왑과 가스 토큰 확보 단계를 반복적으로 수행해야 하는 불편함을 겪게 된다.
CEX를 경유하는 방식은 단기적으로 단순해 보이나, 계정·KYC·출금 정책에 대한 의존도가 높고, 규제·정책 변화에 취약하다. 무엇보다 이 두 방식 모두 토큰 이동에는 초점을 맞추지만, 온보딩·결제·추가 컨트랙트 호출까지 하나의 흐름으로 묶어 주지는 못한다.
결국 문제는 “어떻게 토큰을 옮길 것인가”가 아니라, “어떻게 멀티체인 실행 흐름을 단일화할 것인가”로 수렴된다. Squid는 이 문제에 대응하기 위해 설계된 크로스체인 유동성 라우터다.
2. 크로스체인 레벨 구분: Infra와 Application
멀티체인 환경에서 상호운용성은 인프라 레이어와 어플리케이션 레이어로 구분된다.
인프라 레이어가 체인 간 메시지·토큰 전달을 담당한다면, 어플리케이션 레이어는 그 위에서 실제 스왑과 실행 흐름을 구성한다. Squid의 역할을 명확히 이해하기 위해서는, 각 레이어가 해결하는 문제의 범위를 구분할 필요가 있다.
2.1 Infra 레벨: 메시징·브릿지(Axelar, Wormhole, LayerZero)
인프라 레이어는 체인 간 전달을 담당한다. 즉, 서로 다른 체인에서 메시지(호출 정보)와 토큰(가치)이 오갈 수 있는 공통 패턴을 제공한다. 대표적으로 Axelar, Wormhole, LayerZero 같은 프로토콜들이 이 레벨에서 상호운용성의 기반을 만든다.
Squid를 이해하기 위해 인프라 레벨에서 짚고 넘어가야 할 포인트는 두 가지다.
인프라 레이어는 체인 간 메시징·토큰 이동의 공통적인 패턴을 제공한다.
그 공통 패턴 위에서 무슨 토큰을 어떤 경로로 스왑하고, 가스를 어떻게 처리하며, 어느 컨트랙트까지 실행할지는 별도의 어플리케이션이 설계한다.
다시 말해 인프라는 체인 사이에 도로를 깔아 두는 역할에 가깝다. 그리고 그 도로 위에서 실제 사용 시나리오(스왑·가스·컨트랙트 호출)를 조합해 UX로 제공하는 어플리케이션 레이어가 필요하다.
2.2 Application 레벨: 라우팅(Squid)
인프라가 ‘전달’을 가능하게 한다면, Squid는 그 위에서 ‘실행’ 흐름을 설계하는 라우팅 레이어다.
이 두 레이어의 관계는 도로망과 교통 서비스의 관계에 가깝다.
Infra(예: Axelar/Wormhole/LayerZero) = 도로망
여러 도시(체인)를 연결하는 고속도로·국도에 해당한다.
길이 어디까지 뚫려 있는지, 차가 어느 방향으로 움직일 수 있는지는 이 레벨에서 결정된다.
Squid = 교통 서비스(내비게이션·톨게이트)
사용자가 A 도시에서 B 도시로 갈 때, 어떤 경로를 통해 이동하고, 중간에 어디서 환승·정차할지를 설계한다.
유동성 풀, DEX, 가스 토큰, 추가 컨트랙트 호출을 조합해 실제 이동 경험을 만든다.
인프라 레이어가 체인 간 전달 가능성을 정의하는 데 집중한다면, 어플리케이션 레이어인 Squid는 Axelar의 GMP를 기반으로 실제 실행 흐름을 구성하는 역할을 맡는다.
3. Squid: 멀티체인 유동성·결제 라우터
멀티체인에서 ‘연결’이 가능해졌다면, Squid는 그 연결을 ‘결제와 실행’으로 완성한다.
핵심 과제는, 체인과 자산이 제각각인 환경에서 유저와 서비스를 위한 하나의 일관된 진입점을 어떻게 설계할 것인가이다.
3.1 Squid가 겨냥하는 크로스체인 UX·유동성 문제
멀티체인 환경에서 사용자가 겪는 어려움은 단순한 체인 관리의 복잡성을 넘어선다. 하나의 체인에서 자산을 보유한 상태로 다른 체인의 DeFi, NFT 마켓, 게임 등으로 이동하려 할 경우, 자산 이동과 실행을 위한 절차는 여러 단계로 분절된다.
소스 체인에서 토큰을 스테이블코인 등으로 스왑
브릿지를 통해 목적 체인으로 이동
목적 체인에서 다시 원하는 토큰으로 스왑
필요한 경우, 추가로 가스 토큰을 구입하고, 최종 어플리케이션 컨트랙트 호출
각 단계마다 별도 인터페이스, 별도 서명, 별도 수수료가 필요하고, 중간에 실수를 하거나 리스크를 떠안아야 하는 지점도 많다. 체인과 토큰 조합이 조금만 복잡해지면, 사용자는 CEX를 거쳐 우회하는 쪽을 더 선호하게 된다.
서비스 사업자·개발자 관점에서의 트레이드오프도 명확하다. 특정 체인에만 유동성을 두고 서비스하면 온보딩은 단순하지만, 멀티체인 유저를 포기해야 한다. 반대로, 여러 브릿지·DEX를 직접 연동해 크로스체인 UX를 구현하려 하면 다음과 같은 부담이 커진다.
체인·토큰·브릿지별 조합에 따른 예외 케이스 관리
가스 토큰 수급, 실패 시 롤백, 수수료 구조 설계 등 운영 복잡도 증가
서비스 공급자는 멀티체인 환경에서도 일관된 사용자 진입 구조를 유지하고자 하며, 사용자는 복잡한 절차 없이 직관적인 사용 경험을 기대한다. Squid는 이러한 상반된 요구를 조정하기 위한 크로스체인 유동성·결제 라우터다.
3.2 Squid의 역할: 크로스체인 유동성·결제 라우팅
Squid가 멀티체인 UX·유동성 문제를 해결하는 방식은 아래 두 가지로 구분된다.
유동성 라우팅:
여러 체인·DEX에 흩어진 유동성을 연결해, 토큰 X → 토큰 Y(다른 체인)의 경로 중 비용·경로 측면에서 최적의 조합을 찾고 실행한다. 이 과정에서 브릿지와 스왑을 하나의 플로우로 묶어 처리한다.
결제·온보딩 라우팅 + 추가 컨트랙트 호출:
단순 스왑을 넘어, 목적 체인의 특정 컨트랙트까지 한 번에 호출할 수 있도록 설계되어 있다. 예를 들어 체인 A의 자산으로 체인 B의 NFT 구매, 체인 A 토큰으로 체인 C의 DeFi 포지션 진입과 같은 플로우를 한 트랜잭션 흐름 안에서 처리할 수 있다.
유저는 “어떤 체인의 A 토큰 → 다른 체인의 B 토큰 + (필요시) 특정 컨트랙트 호출”을 한 번에 요청하고, Squid는 그 뒤에서 브릿지 경로·스왑 경로·추가 호출 순서를 조합해 실행한다.
서비스 공급자 입장에서 보면, Squid는 멀티체인 유동성·결제 인프라를 직접 설계하는 대신, 하나의 라우터에 위임하는 방법을 제공한다.
개발자는 Squid SDK/API를 통해 사용자가 최종적으로 도달해야 할 체인·토큰·컨트랙트만 정의하면 되고, 그 사이의 브릿지·스왑·가스 처리·메시지 전달은 Squid가 담당한다.
이를 통해 Squid는 CEX 수준의 UX를 제공함과 동시에 탈중앙화된 크로스체인 위에서 작동한다.
4. Squid 기술 구조: 아키텍처와 트랜잭션 플로우
기술 구조 관점에서는 Squid를 다음의 세 가지 축으로 나누어 살펴볼 수 있다.
각 체인 위 DEX·유동성을 어떻게 묶어 경로를 찾는지
Axelar GMP를 통해 크로스체인 스왑·컨트랙트 호출을 어떻게 실행하는지
개발자가 실제 서비스에 Squid를 연동할 때 어떤 패턴으로 통합할 수 있는지
4.1 Liquidity Routing: 체인·DEX 연결 방식
Squid가 다루는 기본 단위는 토큰 A ↔ 토큰 B 스왑 경로다. 여기서 A와 B는 같은 체인의 토큰일 수도 있고, 서로 다른 체인의 토큰일 수도 있다. Squid는 각 체인에 분산된 DEX·유동성 풀을 통합해, 사용자가 요청한 출발 자산/체인과 도착 자산/체인 조합에 대해 실행 가능한 스왑 경로를 먼저 구성한다.
구조를 단순화하면 다음과 같다.
Squid 라우터는 각 체인에 연동된 DEX·풀을 조합해 소스 자산 → 브릿지용 중간 자산 → 목적 자산의 흐름을 만든다.
동일 체인 내 스왑은 해당 체인의 DEX에서 처리하고, 체인 간 이동이 필요한 구간만 Axelar를 통해 처리한다.
서비스 개발자는 체인·DEX별 유동성을 직접 관리하거나 브릿지·스왑 조합을 설계할 필요가 없다. 사용자가 들고 있는 자산/체인과 서비스가 받고 싶은 자산/체인만 정의하면, 그 사이의 경로 탐색과 실행은 Squid 라우팅 로직이 담당하는 구조다.
4.2 Squid의 크로스체인 스왑·호출 플로우
Squid의 크로스체인 스왑·컨트랙트 호출 플로우는 Axelar의 General Message Passing(GMP)을 기반으로 동작한다. 개념적으로는 다음과 같은 흐름을 따른다.
소스 체인에서 Squid 컨트랙트 호출
사용자는 소스 체인에서 SquidRouter 컨트랙트를 호출해 지금 들고 있는 토큰 → 목적 체인의 특정 토큰(+선택적으로 특정 컨트랙트 호출)을 요청한다. 필요할 경우, 소스 체인에서 먼저 DEX 스왑을 수행해 브릿지에 적합한 형태의 자산으로 바꾼다.
Axelar를 통한 메시지 전달 및 체인 간 이동
SquidRouter 컨트랙트는 Axelar Gateway를 통해 도착 체인에서 어떤 컨트랙트를 어떤 파라미터로 호출해야 하는지를 포함한 메시지를 생성한다. Axelar 검증자 집합은 소스 체인 이벤트를 합의하고, 목적지 체인으로 메시지를 릴레이한다.
도착 체인에서 스왑·컨트랙트 실행
목적지 체인의 Axelar Gateway를 통해 SquidRouter 컨트랙트가 메시지를 수신하여, 필요한 경우 DEX 스왑을 수행하고, 최종적으로 지정된 컨트랙트(예: DeFi 프로토콜, NFT 마켓, 게임 컨트랙트 등)를 호출한다. 사용자는 소스 체인에서 한 번 트랜잭션을 보냈을 뿐인데, 목적지 체인에서 토큰 전환과 컨트랙트 실행까지 완료된 상태를 보게 된다.
이 구조 덕분에 사용자는 브릿지 → 스왑 → 가스 토큰 확보 → 컨트랙트 호출을 개별적으로 수행하지 않아도 된다. 인프라 레이어는 체인 간 메시지·상태 전파를, Squid는 자산 전환과 컨트랙트 호출 순서를 조합하는 역할을 맡는다.
4.3 개발자 경험: SDK·API·위젯 통합 패턴
서비스 개발자 입장에서 Squid는 크로스체인 기능을 위한 백엔드 인프라라기보다, 프론트·백엔드 모두 쉽게 통합할 수 있는 어플리케이션 레벨의 도구에 가깝다.
Squid는 유연한 개발자 경험을 위해 두 가지 통합 방식을 지원한다.
Cross-chain Widgets 통합 방식
별도 복잡한 로직 구현 없이, Squid가 제공하는 UI 위젯을 서비스 화면에 임베드하는 방식이다. 사용자는 위젯에서 소스/도착 체인과 토큰을 선택하고, 서비스는 결과만 받아 최종 컨트랙트와 연동할 수 있다.
API·SDK 통합 방식
더 세밀한 제어가 필요할 경우, JS SDK나 REST API를 통해 직접 라우팅 요청을 만들고, 트랜잭션 생성·서명·상태 조회를 어플리케이션 로직 안에서 제어할 수 있다.
이 패턴에서는 어떤 체인에서 어떤 자산을 받아, 어떤 체인의 어떤 컨트랙트까지 연결할지를 코드로 정의하고, Squid는 그 정의에 맞는 크로스체인 경로를 찾아 실행한다.
이러한 통합 패턴 덕분에 서비스 사업자는 멀티체인 온보딩·결제·인입 플로우를 처음부터 설계하는 일을 피하고, Squid를 통해 크로스체인 UX를 빠르게 구성한 다음 비즈니스 로직 자체에 더 많은 시간을 쓸 수 있다. 특히 기존 앱/슈퍼앱에 모듈처럼 붙여 단계적으로 확장하는 전략(위젯 → SDK/API 고도화)에도 매우 적합하다.
추가로 Squid는 CORAL/CORAL V2 같은 실행 옵션을 제공해, 단순 라우팅을 넘어 더 확장된 실행 플로우를 구성하는 방향도 제시한다.
5. 파트너사·생태계 관점: 멀티체인 스테이블코인·RWA 레일로서의 Squid
멀티체인 환경에서 서비스를 운영하는 팀이 실제로 고민하는 지점은 어떤 브릿지를 쓰느냐보다, 여러 체인에 흩어진 유저와 유동성을 어떻게 하나의 온보딩·결제 플로우로 수렴시킬 것인가에 가깝다.
Squid는 이 분산된 진입 지점을 하나의 유동성·결제 라우팅 레이어로 흡수해, 서비스와 유저 모두에게 단일 진입점에 가까운 경험을 제공한다.
5.1 실서비스(DeFi·게임·인프라)의 공통 이점
멀티체인으로 확장하려는 프로젝트들은 보통 다음 두 선택지 사이에서 고민한다.
단일 체인에 집중해 온보딩을 단순화하되, 다른 체인 유저·유동성은 상당 부분 포기하는 방식
여러 체인을 지원하되, 브릿지·DEX·가스 온보딩을 체인별로 따로 설계하면서 복잡한 온보딩 플로우를 감수하는 방식
후자를 선택하면 유저 풀과 활용 범위는 넓어지지만, 온보딩 경로가 복잡해지고 전환율이 떨어지기 쉽다. 특히 체인별로 서로 다른 브릿지와 스왑 경로를 관리해야 한다는 점이 지속적인 운영 부담으로 남는다.
Squid는 이 지점을 하나의 라우터를 통한 멀티체인 진입점으로 단순화한다. 서비스는 다음 두 가지만 정의하면 된다.
유저가 어떤 체인/토큰으로 들어올 수 있는지(소스 체인/토큰 집합)
서비스가 최종적으로 어떤 체인/토큰을 받고 싶은지(목적 체인/토큰 집합)
그 사이의 브릿지·DEX 조합, 가스 토큰 확보, 필요 시 추가 컨트랙트 호출 순서는 Squid 라우팅 로직이 맡는다. 결과적으로 서비스는 체인별로 다른 온보딩 플로우를 설계할 필요 없이, 하나의 진입 화면에서 다양한 체인의 유저를 수용하는 구성을 만들 수 있다.
UX 측면에서는 체인리스(chainless)에 가까운 온보딩이 가능해진다. 사용자는 자신이 어느 체인에 있는지, 어떤 브릿지를 거쳐야 하는지 직접 신경 쓰지 않고 내 지갑에 있는 자산으로 이 서비스에 들어간다는 관점만 유지하면 된다. DeFi, 게임, 인프라 프로젝트는 이 구조 위에서 어디서 들어와도 동일한 UX로 시작하는 멀티체인 서비스를 설계할 수 있고, 온보딩 단계에서의 이탈률을 줄이면서도 대응 가능한 체인 범위를 넓힐 수 있다.
5.2 스테이블코인·RWA/STO 프로젝트 도입 시 효과
스테이블코인·RWA/STO 프로젝트는 규제·회계·리스크 관리에 적합한 허브 체인에서 발행·상환·정산을 관리하면서, 실제 투자·결제·트레이딩 수요가 있는 여러 주변 체인으로 토큰을 유통·회수해야 한다. 기존의 접근법은 다음과 같은 요소들로 구성되어왔다.
주요 CEX 상장 및 거래쌍 확보
체인별 커스텀 브릿지 구축
체인마다 다른 온·오프램프 및 정산 로직 설계
이 방식은 초기에는 유연해 보이지만, 체인·브릿지 수가 늘어날수록 정산·리스크·모니터링 체계를 각각 유지해야 한다는 점에서 기술·운영 복잡도와 비용이 빠르게 증가한다.
Squid는 이 문제를 공통 멀티체인 유통 레일 관점에서 재구성한다. 허브 체인에서 발행된 스테이블코인·RWA 토큰의 체인 간 유통 상태와 물량 흐름을 일관되게 관리하면서, 실제 투자·결제 트래픽이 발생하는 주변 체인으로의 유입·회수는 Squid 라우팅으로 처리하는 구조를 설계할 수 있다.
발행사·금융기관은 허브 체인을 기준으로 발행·상환·유통량·리스크를 관리하면서도, 다음과 같은 목표를 동시에 달성할 수 있다.
사용자에게는 어느 체인에서든 동일한 자산을 사용하는 경험 제공
발행사 입장에서는 CEX·개별 브릿지 의존도와 멀티체인 운영 비용 축소
이때 Squid는 토큰 발행 주체가 아니라, 이미 발행된 자산이 어느 체인에서 어떻게 쓰이고 회수되는지를 설계·실행하는 유동성·결제 라우터 역할을 맡는다. 허브 체인에서 회계·규제 정합성 관리, 주변 체인에서 투자·결제 유통이라는 구조를 보다 일관된 패턴으로 유지할 수 있다는 점에서도 규제·감사 대응 측면에서 이점이 있다.
6. 결론: 멀티체인 스테이블코인·RWA 레일로서 Squid의 전략적 위치
스테이블코인·RWA를 둘러싼 논의는 그동안 주로 어떤 체인·브릿지가 더 안전하고 빠른가에 맞춰져 있었다. 그러나 안전성과 속도만으로는 충분하지 않다. UX 관점에서 볼 때, 멀티체인 환경에서 추가되는 질문은 다음과 같다.
“서로 다른 체인과 자산을, 하나의 온보딩·결제·정산 플로우 안에서 일관되게 다룰 수 있는가?”
인프라 레벨의 해답을 제공하는 상호운용성 솔루션 위에서, Squid는 유동성 라우팅과 결제 플로우를 하나의 어플리케이션으로 묶어 내는 역할을 맡는다.
개별 브릿지·체인마다 다른 규칙과 UX를 해석하는 대신, “인프라 + Squid 라우터” 조합 위에서 멀티체인 온보딩·유통·회수를 공통 패턴으로 구현할 수 있게 만드는 것이다.
현재 Squid는 EVM, BTC, Solana, XRPL, Hedera, Cosmos를 포함한 100개 이상 체인을 대상으로 위젯과 API·SDK 통합을 제공하며, 지금까지 300만 건이 넘는 트랜잭션과 50억 달러 이상 규모의 크로스체인 거래를 안전하게 처리해 왔다. 또한 MetaMask, PancakeSwap, Trust Wallet, dYdX, Circle 등 주요 지갑·DEX·스왑·인프라 프로토콜과의 통합도 이미 이루어진 상태다.
이처럼 이미 의미 있는 사용량을 확보한 공통 레일을 활용하면, 프로젝트는 규제·회계·리스크 프레임을 자신이 선택한 허브 체인에 집중시키면서도, 주변 체인으로의 유통·결제 확장을 비교적 가벼운 통합 작업으로 구현할 수 있다.
따라서 Squid는 단순한 크로스체인 스왑 툴이 아니라, 멀티체인 환경에서 스테이블코인, RWA와 같은 자산에 최적화된 어플리케이션으로 나아가고 있다.
서비스 입장에서는 어디서 들어와도 한 번에 온보딩되는 멀티체인 진입 레일
발행사·금융기관 입장에서는 허브 체인 기준으로 관리되는 멀티체인 유통·회수 레일
이러한 역할을 바탕으로, Squid는 멀티체인 스테이블코인·RWA가 ‘인프라’에서 ‘실사용’으로 넘어가는 국면에서 가장 앞선 자리에서 움직이고 있다. 사용자에게는 한 번의 요청으로 스왑·브릿지·가스·컨트랙트 호출까지 끝내는 엔드투엔드 UX를 제공하고, 서비스 및 발행사에게는 멀티체인 환경에서 발생하는 운영·정산·유동성 복잡도를 라우터 레이어에 위임할 수 있는 대안을 제시한다.
그 결과 Squid는 멀티체인 자산을 사용자에게 단일체인처럼 사용할 수 있게 만드는, 크로스체인 유동성 라우터의 기준점으로 자리잡고 있다.
아티클 핵심 정보 출처
Squid Is Cross-Chain Liquidity for Everyone - Axelar Blog
Squid: Single Click Cross-Chain Swaps and Messaging
기타 참고 자료
The State of Cross-Chain Messaging: Squid Router x Axelar Core
Squid Router and the Future of Interchain Liquidity
Introducing Cross-Chain Swaps with Axelar on our DEX Aggregator (Use-Case)
면책 조항
본 보고서의 내용은 단순 정보 제공을 목적으로 하며, 어떠한 경우에도 법률, 비즈니스, 투자 및 세무 자문을 위한 권고나 근거로 사용될 수 없습니다. 본문에 언급된 특정 자산이나 증권은 정보 전달만을 위한 것으로, 해당 자산에 대한 매수·매도 제안이나 투자 권유를 의미하지 않습니다. 모든 투자 결정에 따른 책임은 투자자 본인에게 있으며, 본 보고서는 회계나 법률적 판단의 지침이 될 수 없습니다.
필자는 리서치 및 집필 과정에서 인지한 미공개 정보를 이용하여 관련 자산을 거래하지 않음을 원칙으로 하고 있습니다. 본 리포트의 저자 및 카탈라이즈는 보고서에서 다루는 자산 또는 토큰에 대해 개인적·경제적 이해관계를 가질 수 있으며, 특정 네트워크의 전략적 파트너일 수 있습니다.
본 보고서에 기술된 분석 및 의견은 저자 개인의 견해로, 카탈라이즈 또는 관련 기관의 공식 입장을 대변하지 않습니다. 또한, 모든 내용은 리포트 작성 시점을 기준으로 하며 시장 상황 및 신규 정보에 따라 사전 통보 없이 변경될 수 있습니다.