1. 들어가며
델타를 하나 또는 두 개의 단어로 표현해야 하는 경우, 사용하는 몇 가지 선택지가 있다. 인터넷 호환 자산 레이어, 담백한 블록체인, 평양냉면 블록체인, 자산 백엔드 등 여러 가지 표현들을 맥락에 따라 사용하곤 한다. 오늘은 그중에서도 ‘델타 = 검증가능한 가드레일(Verifiable Guardrail)’의 관점에 대해 얘기하려고 한다.
2. 검증가능한 가드레일은 언제 필요한가?
먼저 용어 정리부터 하고 넘어가자.
내가 생각하는 ‘검증가능함’, 그리고 ‘가드레일’은 다음과 같다:
- 검증가능함: 제3자가 내부 시스템을 믿지 않고도, 결과가 규칙을 지켰는지 독립적으로 확인할 수 있는 성질. 사람이 아닌, 기계가 즉시 검사 가능한 증거와 증명을 말함.
- 가드레일: 소프트웨어, 시스템, 에이전트가 위반하지 못하도록 미리 설정한 안전 조건과 한계. 결과값을 제한하는 규칙의 집합.
나는 모든 시스템이 검증가능한 가드레일을 필요로 한다고 생각하지 않는다. 전체를 크게 세 가지 시나리오로 나눌 수 있다: (1) 가드레일이 아예 필요 없는 경우, (2) 가드레일은 필요하지만 굳이 검증가능할 필요는 없는 경우, (3) 검증가능한 가드레일이 필요한 경우.
2.1 가드레일이 필요 없는 경우
이 경우에 해당하는 전형적인 상황은 다음과 같다:
내부 전용 및 저위험 환경
한 회사 내부에서만 쓰는 단순 보고용 대시보드, 혹은 시스템이 안전 조건을 만족하지 않아도 금전적·법적 리스크가 없는 경우.
사람의 개입이 항상 있는 경우
자동화 부분이 적고, 최종 결정을 사람이 내리는 워크플로우의 경우. 안전 조건을 만족하지 않더라도 사람이 항상 걸러낼 수 있다.
2.2 가드레일 O, 검증가능성 X 경우
먼저 검증가능하지 않은 가드레일에 대해 정의해보자.
- 검증하지 않는 가드레일: 시스템 내부에서만 적용되는 안전 규칙으로, 외부인이 독립적으로 확인하거나 증명할 수는 없지만 내부 로직이나 절차상에서만 작동하는 형태.
가장 대표적인 것이 바로 코드 레벨 제약이다.
예를 들어, if(order.loss > 5%) reject();와 같은 내부 프로그램은 조건 위반 시 실행을 거부하는 코드다. 테스트 코드, 에러 핸들링, 권한 체크 등이 모두 여기에 해당한다.
하지만 외부에서는 해당 시스템의 겉면(인터페이스)만 볼 수 있기 때문에 어떤 가드레일이 돌아가고 있는지 알 수 없다. 그렇기에 “저 시스템은 규칙을 잘 지킬 거야”라는 믿음과 계약서, 사후 감사에 의존할 수밖에 없다.
예를 들어, 은행 내부에는 거래 한도를 체크하는 수많은 규칙과 시스템이 있지만, 내가 은행과 거래하는 시점에 그 규칙이 확실히 지켜지고 있다는 걸 실시간으로 검증할 방법은 없다.
그럼에도 불구하고 이 경우에 해당하는 전형적인 상황은 다음과 같다:
직접적 금전 리스크, 하지만 저빈도 트랜잭션
결제 시스템, 거래소, 투자 알고리즘처럼 한 번 잘못 실행되면 금전 손실로 직결되는 경우 가드레일은 필요하다. 하지만 해당 거래가 월 1회 배치 처리하는 내부 정산처럼 저빈도로 일어난다면, 수작업 검증이나 사후 감사만으로도 충분히 커버할 수 있다.
사용자 신뢰가 핵심인 서비스, 하지만 폐쇄적·소규모 신뢰 네트워크
의료 데이터 처리 앱, 금융 로보어드바이저처럼 신뢰 없이는 서비스 자체가 불가능한 경우. 다만 두세 개 회사가 합작 프로젝트를 맺었거나, 서로가 계약과 법적 구속력으로 충분히 보장받고 있다면 검증가능성의 가치는 크지 않을 수 있다.
2.3 검증가능한 가드레일이 필요한 경우
일반적인 소프트웨어에는 겉으로 드러나는, 기계적으로 검증 가능한 안전장치가 없다. 따라서 ‘검증가능한 가드레일’이란, 결과가 특정 규칙을 따랐다는 사실을 외부인이 기계적으로 실시간 확인할 수 있는 장치를 말한다.
이 경우에 해당하는 전형적인 상황은 다음과 같다:
개방형·불특정 다수 참여 시스템
누구나 참여하는 거래소나 글로벌 자산 네트워크처럼 특정 주체의 말을 곧이곧대로 신뢰할 수 없는 경우.
고빈도, 실시간 자동화 실행
AI 투자 에이전트가 24/7 거래하는 상황처럼 사람이 실시간으로 검증할 수 없고, 배치로 모아 사후 감사를 하기에도 어려운 경우. 각 트랜잭션이 규칙을 따랐음을 증명하는 장치가 필요하다.
규모가 크고 리스크가 높은 시장
국제 채권 거래, 대형 기관 투자자 자산 운용처럼 한 번의 위반이 수억 달러 손실·제재로 이어질 수 있는 경우. 검증가능한 가드레일을 추가하는 것이 리스크를 줄이는 데 효과적이다.
상호 불신이 구조적
서로 신뢰하지 못하는 AI 에이전트 간 상호작용이나, 경쟁사끼리 공유하는 결제 네트워크처럼 상대방을 신뢰하지 않아도 시스템적으로 검증할 수 있는 장치가 필요한 경우.
3. 왜 AI 에이전트에게는 검증가능성이 없는 가드레일은 불충분한가?
AI 에이전트는 기존 소프트웨어와 달리 자율성, 속도, 불투명성을 동시에 가지기 때문에 내부에만 존재하는 가드레일로는 안전성을 보장하기 어렵다.
자율성 + 속도
AI 에이전트는 24/7 자동 실행하며 초 단위로 결정을 내린다. 사람이 개입하거나 로그를 사후 점검하는 방식은 이미 피해가 발생한 뒤 확인하는 꼴이 된다.
불신 환경
금융·거래·공급망 등에서 에이전트가 다른 에이전트·조직과 직접 상호작용할 때 상대방은 에이전트 내부 규칙을 신뢰할 이유가 없다. 특히 경쟁자·투자자·규제기관처럼 이해관계가 충돌하는 상황에서는 외부에서 독립적으로 검증할 수 있어야 신뢰가 형성된다.
AI 특유의 불투명성
AI 모델은 블랙박스라 내부 의사결정 과정을 사람이 설명하기 어렵다. “우리가 알아서 가드레일 걸어놨어요”라는 말만으로는 외부 이해관계자가 확인할 수 없다.
4. 3가지 예시 상황들
4.1 AI 에이전트가 회사채(Company Bond) 거래를 수행
AI가 회사채 매매를 돕거나 직접 실행하는 경우를 가정해 보자. 리서치 단계부터 글로벌 자동 운용까지 상황별로 요구되는 가드레일 수준이 달라진다.

4.2 AI가 환자 심전도(ECG) 데이터를 분석하는 서비스
의료 데이터 활용 맥락에서는 연구용, 보조용, 자동 모니터링 단계에 따라 검증 필요성이 크게 달라진다.

4.3 AI/시스템이 글로벌 물류에서 화물 이동을 추적·관리
물류에서는 내부 재고 관리 수준과 전 세계 무역 네트워크 수준의 차이가 크며, 이에 따라 검증가능한 가드레일 필요성이 달라진다.

5. 델타는 어떻게 검증가능한 가드레일을 제공하는가?

델타의 구조는 두 층으로 나뉜다. 도메인은 각 기관이 운영하는 독립 실행 환경이고, 베이스 레이어는 모든 자산과 계좌를 보관하는 전역 원장이다. 도메인은 사용자의 트랜잭션을 처리한 뒤 결과를 State Diff List(SDL)로 요약하고, 그 결과가 정해진 규칙을 준수했음을 증명해야만 베이스 레이어에 정산(settlement)할 수 있다.
이때 규칙(= 가드레일)은 세 가지 층위로 나뉜다.
Global Laws
네트워크 전역에 항상 적용되는 최소한의 안전 규칙. 예: 모든 트랜잭션은 서명돼야 한다, 잔고 부족 시 지출 불가, 이중 지출 금지.
→ 이 규칙들은 zk 서킷에 들어가지 않고, 베이스 레이어 검증자가 SDL을 받을 때 직접 체크한다. 말 그대로 네트워크 공통 필터 역할을 한다.
Local Laws
각 도메인이 원하는 방식으로 정의하는 규칙. 예: 특정 KYC 명단에만 거래 허용, 거래 금액 상한선, 특정 시간대만 거래 가능.
→ 도메인 운영자가 이 조건을 Delta SDK를 통해 RISC-V zkVM 서킷으로 변환하고, SDL이 이 규칙을 지켰다는 zk 증명을 생성한다.
Token Laws
토큰 발행자가 설정하는 규칙. 예: 144A 채권은 QIB만 보유 가능.
→ 토큰이 어떤 도메인에서 거래되든 동일하게 적용되며, Local Laws와 마찬가지로 zk 서킷에 포함돼 증명된다.
5.1 트랜젝션 처리 흐름
트랜잭션 처리 흐름은 다음과 같다:
- 사용자가 트랜잭션을 제출하면 도메인에서 먼저 실행되고, 결과가 SDL로 요약된다.
- Delta SDK가 SDL과 실행 컨텍스트, Local/Token Law 프로그램을 zkVM에 넣어 zk 증명을 만든다.
- SDL과 proof가 베이스 레이어 검증자에게 제출된다.
- 검증자는 zk 증명을 검증해 Local/Token Laws가 준수됐음을 확인하고, 동시에 Global Laws를 직접 체크한다.
- 모든 검증을 통과한 SDL만 네트워크에 가십(gossip)되고 최종 글로벌 상태에 반영된다.
이 구조 덕분에 델타는 전체 실행 과정을 재현하지 않고도 결과가 규칙을 준수했음을 증명한다. 다시 말해 델타는 결과 기반 검증(outcome-verifiable) 방식을 취한다. 덕분에 도메인 내부에서는 복잡하거나 비결정적인 연산(예: 대규모 AI 모델, 외부 API 호출, 이벤트 기반 로직)을 자유롭게 실행할 수 있고, 네트워크는 오직 결과가 가드레일을 충족했는지만 확인한다.
6. 왜 기존 블록체인은 이러한 역할을 하기 어려울까?
블록체인은 본래 “모든 참여자가 동일한 실행을 반복하여 상태를 검증한다”는 구조로 설계되었다. 이 방식은 특정 연산의 정합성을 보장하는 데는 효과적이지만, 정산(settlement) 자체를 조건부로 차단하거나 복잡한 규칙을 강제하는 검증가능한 가드레일로 기능하기에는 근본적인 제약이 있다.
첫째, 블록체인은 용량과 처리 성능의 한계가 크다. 모든 노드가 같은 연산을 반복해야 하므로 대규모 모델이나 고빈도 이벤트를 실시간으로 처리하기 어렵다. 복잡한 조건을 정산 단계에서 직접 강제하는 구조를 구현하기에는 지나치게 무겁고 느리다.
둘째, 블록체인은 표현력의 제약이 있다. 스마트 계약은 반드시 결정적 로직만 허용하기 때문에 난수, 샘플링, 외부 이벤트 같은 비결정적 데이터를 다룰 수 없다. 또한 KYC 여부, 제재 명단, 은행 API 응답과 같은 현실 데이터는 온체인에 존재하지 않으므로 결국 오라클을 거쳐야 한다. 그러나 오라클은 느리고 비용이 크며, 신뢰도 외부에 위임해야 한다는 점에서 실시간 강제 장치라기보다 보조 수단에 가깝다.
셋째, 블록체인은 자율적 차단 메커니즘이 부재하다. 스마트 계약은 스스로 이벤트를 감지하거나 조건을 평가해 실행을 멈추지 못한다. 항상 외부에서 트랜잭션이 제출돼야만 동작하기 때문에, “조건을 충족하지 않으면 정산을 막는다”는 가드레일을 만들려면 keeper 같은 외부 봇에 의존해야 한다. 이는 본질적인 강제라기보다 사후 관리에 더 가깝다.
이러한 구조적 한계는 실제 사례에서도 드러난다. 예컨대 구글의 AP2 프로토콜은 블록체인을 활용해 “에이전트가 특정 조건에서 결제 의도를 기록”할 수 있게 하지만, 이는 어디까지나 사후 분쟁 시 확인용 로그일 뿐이다. 거래 조건을 위반했을 때 정산 자체를 차단하거나 조건을 강제로 집행하지는 못한다. 결국 기존 블록체인은 현대적 AI 에이전트나 복잡한 금융 워크플로우에 필요한 검증가능한 가드레일이 아니라, 단순한 기록 장치로 머무를 수밖에 없는 구조다.
7. 마무리하며
AI 에이전트와 복잡한 디지털 워크플로우가 확산되는 시대에는 내부 규칙만으로는 부족하다. 외부에서도 독립적으로 확인 가능한 검증가능한 가드레일이 반드시 필요하다. 기존 블록체인은 성능·표현력·자율성의 제약으로 이 역할을 수행하기 어렵지만, 델타는 도메인의 안전 규칙들을 ZK 증명을 통해 네트워크 차원에서 강제함으로써 이를 가능하게 한다.
의견을 남겨주세요