레이어제로 vs. 체인링크, CCIP vs. 웜홀: 크로스체인 상호운용성의 진정한 차이점은 무엇일까요?

Atlas Treasury라는 가상의 DeFi 애플리케이션을 상상해 보세요. 이 예시는 아키텍처를 더 쉽게 이해할 수 있도록 하기 위한 가상의 사례입니다. Atlas는 이더리움 블록체인에 담보를 보유하고, 다른 블록체인에서 전략 로직을 실행해야 하며, 때로는 메시지와 함께 토큰 표현을 전송해야 합니다. 개발자들은 널리 사용되는 세 가지 상호운용성 스택인 LayerZero, Chainlink CCIP, 그리고 Wormhole을 고려하고 있습니다.

언뜻 보면 세 프로토콜 모두 동일한 문제, 즉 한 블록체인에서 다른 블록체인으로 정보나 자산을 전송하는 문제를 해결하는 것처럼 보입니다. 하지만 실제로는 그 설명이 너무 피상적입니다. 크로스체인 프로토콜은 다음과 같은 여러 가지 질문에 답해야 합니다. 소스 체인을 누가 감시하는가? 메시지의 유효성을 목적지 체인이 확신하게 하는 증거는 무엇인가? 메시지 전달 및 실행 비용은 누가 부담하는가? 토큰 전송은 어떻게 표현되는가? 애플리케이션은 무엇을 구성할 수 있으며, 어떤 보안 가정이 필요한가?

프로토콜 이름이 아니라 문제부터 시작하세요.

Atlas Treasury의 경우 "다중 체인 지원"과 같은 요구 사항은 충분히 구체적이지 않습니다. 팀은 먼저 요구 사항을 최소 세 가지 범주(임의 메시징, 토큰 이동, 대상 체인 실행)로 분류해야 합니다.

임의 메시징은 이더리움 컨트랙트가 "계정 X의 대출 한도를 업데이트하세요"라는 지시를 보내는 것을 의미할 수 있습니다. 토큰 이동은 다릅니다. 토큰 가치는 여러 체인에 걸쳐 락업, 소각, 발행, 해제 또는 기타 방식으로 처리되어야 합니다. 실행에는 또 다른 계층이 추가되는데, 목적지 트랜잭션에는 가스, 순서 규칙, 오류 처리, 그리고 수신 컨트랙트를 호출할 수 있는 주체에 대한 명확한 규칙이 필요하기 때문입니다.

이러한 구분이 중요한 이유는 LayerZero, Chainlink CCIP 및 Wormhole이 단순히 서로 대체 가능한 브리지가 아니기 때문입니다. 각각은 서로 다른 검증 및 전달 아키텍처를 가진 보다 광범위한 상호 운용성 프레임워크입니다.

LayerZero: 애플리케이션에서 구성 가능한 검증 및 실행

LayerZero V2는 지원되는 체인에 배포된 불변 엔드포인트 계약을 중심으로 크로스체인 통신을 구성합니다. 애플리케이션은 소스 엔드포인트를 통해 메시지를 전송하고, 대상 엔드포인트는 최종적으로 검증된 메시지를 수신 애플리케이션에 전달합니다. LayerZero V2 프로토콜의 공식 개요에서는 송신자, 소스 엔드포인트 ID, 대상 엔드포인트 ID 및 수신자를 기준으로 채널을 설명합니다.

LayerZero의 독특한 설계 특징은 검증과 실행을 분리했다는 점입니다. LayerZero는 독립적인 검증 서비스를 분산형 검증 네트워크(DVN)라고 부릅니다. 애플리케이션은 임계값 규칙을 포함하여 필수 및 선택적 DVN을 구성할 수 있으며, 실행기는 메시지가 검증 요구 사항을 충족한 후 목적지로 전달하는 역할을 담당합니다. 공식 아키텍처 문서에서는 이를 플러그형 메시지 라이브러리, DVN 및 실행기를 갖춘 X-of-Y-of-N 검증 모델로 설명합니다.

그것이 아틀라스 재무부에 어떻게 적용될까요?

Atlas가 다양한 크로스체인 액션에 대해 서로 다른 보안 정책을 적용하고 싶다고 가정해 보겠습니다. 중요도가 낮은 상태 업데이트에는 하나의 구성이 사용될 수 있지만, 상당한 담보를 해제할 수 있는 메시지에는 여러 개의 독립적인 DVN이 필요할 수 있습니다. 이러한 유연성은 LayerZero의 핵심 특징입니다. 즉, 애플리케이션이 모든 경로에 대해 하나의 범용 검증자 세트를 상속받는 대신 자체적인 보안 스택을 선택할 수 있습니다.

유연성은 책임감을 수반합니다. LayerZero의 OApp 문서에 따르면, 프로덕션 배포 시에는 여러 독립 운영자의 필수 DVN을 사용해야 합니다. 단일 DVN 구성은 경로가 하나의 검증자에 의존하게 만들기 때문입니다. 따라서 Atlas는 프로토콜 통합을 일회성 API 결정으로 처리할 수 없습니다. DVN 선택, 피어, 메시지 라이브러리, 실행기 설정, 소유권 및 업그레이드 절차는 보안 설계의 일부가 됩니다. 관련 지침은 LayerZero OApp 문서 에서 확인할 수 있습니다 .

Atlas가 임의의 비즈니스 로직이 아닌 대체 가능한 토큰 이동만을 원한다면, LayerZero는 Omnichain Fungible Token(대체 가능 토큰) 표준도 제공합니다. 토큰 전송 의미론과 애플리케이션 메시징은 별개의 문제이므로, 일반적인 OApp 통합과는 별도로 평가해야 합니다.

Chainlink CCIP: 차선별 제어 기능을 갖춘 DON 기반 메시징

체인링크 CCIP는 다른 모델을 사용합니다. CCIP에서 "레인"은 한 블록체인에서 다른 블록체인으로 가는 단방향 경로를 의미합니다. 반대 방향은 별도의 레인이며, 레인별 특성은 다를 수 있습니다. 체인링크 CCIP의 핵심 개념은 최종성이 중요하다는 점을 설명하는데, 이는 목적지가 재구성될 가능성이 있는 출발지 이벤트에 대해 조치를 취해서는 안 되기 때문입니다.

현재 CCIP v1.6 아키텍처에 명시된 바와 같이, 역할 기반 분산형 오라클 네트워크(Role DON)는 두 개의 오프체인 보고 플러그인을 실행합니다. 커밋 OCR 프로세스는 소스 체인 메시지에 대한 합의를 도출하고 머클 루트를 대상 체인에 커밋합니다. 그런 다음 실행 OCR 프로세스는 보류 중인 실행을 검증하고 대상 체인에서 메시지를 실행합니다. 공식 CCIP 오프체인 아키텍처 페이지에서 이 흐름에 대한 자세한 설명을 확인할 수 있습니다.

2026년에 중요한 문서 변경 사항이 있는데, 이전 자료를 읽을 때 쉽게 간과할 수 있습니다. 체인링크는 현재 위험 관리 네트워크(RMN)의 자동화된 오프체인 역할이 현재 CCIP 배포 환경에서는 더 이상 활성화되어 있지 않으며, 향후 릴리스에서 선택적 검증 계층으로 다시 제공될 예정이라고 명시하고 있습니다. 온체인 RMN 계약은 특정 기능에 대한 비상 안전장치로 유지되며, 다른 제어 기능에는 구성 가능한 속도 제한, 토큰 증명 및 모니터링이 포함됩니다. 따라서 기존 오프체인 RMN을 항상 활성화된 독립 검증 네트워크로 설명하는 모든 문서는 현재 배포 환경에 맞지 않으므로 더 이상 유효하지 않습니다.

그것이 아틀라스 재무부에 어떻게 적용될까요?

Atlas는 지원되는 송신-수신 쌍 및 통합 방식에 따라 CCIP를 사용하여 임의의 데이터, 토큰 또는 프로그래밍 가능한 토큰 전송을 보낼 수 있습니다. Atlas는 자체 DVN 구성을 선택하는 대신, CCIP 계약 및 CCIP DON 아키텍처에서 제공하는 보안 모델과 통합한 다음, 신뢰할 수 있는 체인, 송신자, 라우터 및 메시지 처리에 대한 애플리케이션 수준 검사를 적용합니다.

이러한 검사는 선택 사항이 아닙니다. Chainlink의 CCIP EVM 모범 사례 문서에서는 전송 전 대상 체인 검증, 수신 시 소스 체인 및 발신자 검증, 필요한 경우 라우터 주소 확인, 메시지 수신과 핵심 비즈니스 로직 분리, 불리한 조건에서의 테스트, 비정상적인 동작 모니터링 등을 명시적으로 권장합니다.

토큰 발행자를 위해 CCIP는 토큰 풀 및 관리 규칙을 기반으로 하는 크로스체인 토큰 인프라도 제공합니다. 토큰 풀에 대한 속도 제한을 구성할 수 있으므로 Atlas는 하나의 구성이 두 가지 모두에 적합하다고 가정하는 대신 토큰 아키텍처를 일반적인 임의 메시징과 별도로 평가해야 합니다.

웜홀: Guardian 증명으로 휴대용 VAA 생성

웜홀의 메시징 설계는 가디언 네트워크와 검증 가능한 액션 승인(VAA)을 중심으로 이루어집니다. 소스 컨트랙트는 웜홀 코어 컨트랙트를 통해 메시지를 전송합니다. 가디언들은 이 메시지를 관찰하고 서명하며, 필요한 정족수가 충족되면 생성된 VAA를 검증을 위해 목적지 체인에 제출할 수 있습니다.

현재 웜홀 가디언 문서에는 19명의 가디언으로 구성된 표준 세트와 표준 13-of-19 다중 서명 VAA가 설명되어 있습니다. 일부 체인에서는 위임된 하위 집합이 직접 관찰을 수행하지만, 표준 가디언은 구성된 위임 쿼럼이 충족될 때까지 기다린 후 동일한 표준 13-of-19 VAA를 생성합니다.

전달과 유효성 검증은 의도적으로 분리되어 있습니다. 웜홀의 메시징 개요 에 따르면 VAA(가용성 보증서)는 목적지로 전송된 후 거기서 검증됩니다. 최신 Executor 프레임워크는 메시지 실행을 위한 권한 없는 요청-견적 모델을 제공합니다. 보안 문서에서는 중요한 차이점도 명시하고 있습니다. 릴레이어는 가용성이나 타이밍에는 영향을 줄 수 있지만, 가디언 서명에 의해 유효성이 보장되므로 VAA를 위조할 수는 없습니다.

그것이 아틀라스 재무부에 어떻게 적용될까요?

아틀라스는 이더리움 메시지를 발행하고 가디언 인증을 기다린 후, 릴레이어 또는 실행기를 통해 VAA(가상 인증 액세스)를 목적지 컨트랙트로 전달할 수 있습니다. 수신자는 메시지의 출처를 검증하고 재전송 공격에 안전한 애플리케이션 로직을 구현해야 합니다. 아틀라스가 메시지뿐 아니라 토큰도 필요로 하는 경우, 웜홀은 네이티브 토큰 전송(NTT)과 래핑 토큰 전송(WTT)을 구분합니다. 공식 토큰 전송 개요에 따르면 NTT와 WTT는 가디언 메시징 레이어를 공유하지만 토큰의 표현 방식과 발행 또는 발행 방식이 다릅니다.

웜홀 지원 여부는 제품별로 다르며 변경될 수 있습니다. 따라서 모든 웜홀 제품이 모든 웜홀 연결 체인에서 작동한다고 가정하기보다는 지원 ​​네트워크 관련 문서를 확인하는 것이 더 신뢰할 수 있습니다. 2026년 8월, 웜홀은 추가적인 네트워크 지원 중단을 발표하여, 라우트를 확정하기 전에 현재 지원 여부를 확인해야 할 필요성을 더욱 강조했습니다.

LayerZero, CCIP, Wormhole의 실질적인 차이점

이 표는 아키텍처 비교이지 보안 순위가 아닙니다. 각 프로토콜은 서로 다른 설정 옵션을 제공하고, 서로 다른 검증 가정을 사용하며, 발전 속도도 다릅니다. 설정 옵션이 더 많은 프로토콜이 자동으로 더 안전한 것은 아니며, 검증 스택이 더 강압적인 프로토콜이 자동으로 유연성이 떨어지는 것도 아닙니다. 중요한 것은 보안 모델이 승인하려는 작업에 적합한지 여부입니다.

아틀라스 사례가 보여주는 실제 통합 위험에 대한 통찰력은 무엇인가?

1. 크로스체인 보안은 두 체인 모두를 포함합니다.

이더리움이 정상적으로 파이널라이즈되더라도 대상 체인이 중단되거나 재구성되거나 예상치 못한 동작을 보일 경우, 아틀라스는 여전히 크로스체인 사고로 간주됩니다. 모든 프로토콜은 궁극적으로 연결하는 네트워크의 특성에 의존합니다. 체인링크는 개발자들에게 사용하는 네트워크의 보안 및 신뢰성을 평가하도록 명시적으로 권고하며, 레이어제로 및 웜홀 통합에도 동일한 원칙이 적용됩니다.

2. 유효한 메시지라도 안전하지 않은 애플리케이션 로직을 트리거할 수 있습니다.

상호운용성 프로토콜은 메시지가 예상 경로를 통해 전달되었음을 증명하거나 확인합니다. 하지만 이러한 프로토콜이 Atlas의 비즈니스 로직을 자동으로 올바르게 만드는 것은 아닙니다. 완벽하게 유효한 크로스체인 명령이라도 Atlas가 발신자, 목적지 컨텍스트, 금액, 논스, 리플레이 상태 또는 허용된 작업을 검증하지 못하면 수신 계약의 버그를 악용할 수 있습니다.

3. 토큰 이동에는 별도의 위협 모델이 필요합니다.

"앨리스가 100개의 유닛을 소유하고 있습니다"라는 메시지는 실제로 경제적으로 의미 있는 토큰 100개를 이동시키는 것과는 다릅니다. 아틀라스는 크로스체인 자산이 소각 및 발행되었는지, 락업 및 해제되었는지, 에스크로에 보관되었는지, 래핑되었는지, 또는 발행자가 자체적으로 관리하는지 여부를 문서화해야 합니다. 또한 발행 권한을 가진 사람, 거래량 제한을 관리하는 사람, 비상 일시 중지 기능의 작동 방식, 그리고 경로의 한쪽이 사용 불가능해질 경우 발생하는 상황도 명확히 설명해야 합니다.

4. 납품 실패가 회계상 실패로 이어져서는 안 됩니다.

크로스체인 시스템은 비동기식입니다. 가스 급증, 체인 혼잡, 최종성 지연, 릴레이어 문제 또는 목적지 되돌리기 등으로 인해 완료가 지연될 수 있습니다. Atlas는 소스 체인 트랜잭션을 목적지 작업 성공의 최종 증거로 취급하는 대신, "전송됨", "검증됨", "전달됨", "비즈니스 로직 완료됨"을 각각 별개의 상태로 모델링해야 합니다.

팀은 어떻게 그중에서 선택해야 할까요?

Atlas는 브랜드 수준의 기능 체크리스트에서 프로토콜을 선택하는 방식을 피해야 합니다. 더 나은 방법은 각 후보 프로토콜을 실제 메시지 경로 및 오류 발생 가능성에 대해 테스트하는 것입니다.

• 정확한 출발 및 도착 네트워크를 선택하십시오. 전체 생태계의 호환성을 가정하기보다는 프로토콜의 공식 디렉토리에서 현재 지원 여부를 확인하십시오.
• 경계를 넘는 것이 무엇인지 정의하십시오. Atlas가 임의의 바이트를 전송하는 것인지, 토큰을 전송하는 것인지, 토큰과 명령어를 함께 전송하는 것인지, 거버넌스 작업을 전송하는 것인지, 아니면 상태 동기화를 전송하는 것인지 명확히 정의하십시오.
• 검증 가정을 기록하십시오. LayerZero의 경우, 선택된 DVN과 임계값이 포함됩니다. CCIP의 경우, 현재 DON 아키텍처와 레인 동작이 포함됩니다. Wormhole의 경우, Guardian 쿼럼과 체인과 관련된 위임된 관찰 구성이 포함됩니다.
• 목적지 실행 모델을 별도로 구성하십시오. 누가 메시지를 전달할 수 있는지, 전달이 지연될 경우 어떻게 되는지, 가스 비용은 어떻게 충당되는지, 메시지를 순서대로 처리해야 하는지 여부를 파악하십시오.
• 애플리케이션 수준의 권한 부여를 감사합니다. 소스 체인, 송신자 계약, 수신자 계약, 특권 역할 및 토큰 관리를 제한합니다.
• 운영 변경 사항을 고려하십시오. 네트워크 지원, 프로토콜 버전, 서비스 제한 및 권장 구성은 변경될 수 있습니다. 따라서 운영 모니터링은 문서 업데이트 및 사용 중단 사항을 운영 이벤트로 간주해야 합니다.

가상의 아틀라스 재무부에 대한 최종 자체 점검

Atlas가 테스트넷 단계를 벗어나 실제 서비스에 적용되기 전에, 개발팀은 마케팅 용어에 의존하지 않고 다음 질문들에 답할 수 있어야 합니다.

• 현재 지원되는 정확한 출발지-도착지 경로는 무엇입니까?
• 누가 또는 무엇이 각 경로에 대한 소스 체인 이벤트를 검증합니까?
• 어떤 기준이나 합의 규칙이 메시지를 수용 가능하게 만드는가?
• 목적지 거래를 누가 전달하거나 실행할 수 있습니까?
• 배달 서비스 업체가 메시지를 검열하거나 지연시킬 수 있나요? 또는 메시지를 위조할 수 있나요?
• 목적지 측 검사에서 예상치 못한 체인, 발신자, 토큰 또는 액션을 거부하는 기준은 무엇입니까?
• 재시도, 중복 실행, 순서가 뒤바뀐 실행, 그리고 목적지 되돌리기는 어떻게 처리되나요?
• 토큰 이동 시, 발행, 소각, 잠금, 방출, 속도 제한 및 관리 측면에서 어떤 가정을 해야 할까요?
• 어떤 비상 통제 장치가 있으며, 누가 이를 통제합니까?
• 팀은 지원되는 네트워크 또는 프로토콜 구성의 변경 사항을 어떻게 감지할까요?

Atlas가 이러한 질문에 답할 수 없다면, 중요한 수준에서 상호 운용성 프로토콜을 제대로 비교하지 못한 것입니다. LayerZero, Chainlink CCIP, Wormhole은 모두 블록체인 간 활동을 조정하는 성숙한 방식을 제공하지만, 검증, 전달, 구성 및 운영 책임을 분담하는 방식은 서로 다릅니다. 따라서 실질적인 선택은 "어떤 크로스체인 프로토콜이 가장 좋은가?"가 아니라 "이 애플리케이션이 승인하고자 하는 정확한 크로스체인 작업에 가장 적합한 보안 및 실행 모델은 무엇인가?"입니다.