가치 저장에서 가치 창조로: 비트코인 프로그래밍의 진화

Key Takeaways

비트코인이 디지털 금을 넘어 탈중앙화 금융(DeFi)의 핵심 인프라로 발전하기 위해서는 프로그래밍 가능성의 확장이 필수적입니다.
비트코인의 프로그래밍 가능성을 "비트코인 L1의 스크립트 시스템과 UTXO 모델 위에서 직접 구현되거나 밀접하게 연동되는 스마트 컨트랙트 기술"로 정의하고, Bitcoin Covenants, Simplicity, BitVM, RGB 프로토콜 등의 주요 기술을 중심으로 포괄적으로 분석합니다.
각 기술은 온체인 프로그래밍 강화, 오프체인 연산 검증, 프라이버시 보호 등 서로 다른 방식으로 비트코인의 활용성을 넓혀가고 있으며, 이러한 기술의 결합은 비트코인이 단순한 가치 저장 수단을 넘어 보다 풍부한 금융 애플리케이션을 가능하게 하는 기반이 될 것입니다.

1. Introduction

비트코인은 디지털 금으로서 주로 가치 저장 수단으로 인식되어 왔습니다. 그러나 최근 비트코인을 보다 적극적으로 금융적으로 활용하려는 움직임이 나타나고 있습니다. 2024년 말 기준으로 전체 비트코인 공급량 중 약 0.79%만이 DeFi에 사용되고 있으며, 이는 비트코인의 상당 부분이 활용되지 않은 채 장기적으로 보유되고 있음을 의미합니다. 실제로 전체 비트코인의 60% 이상이 1년 이상 움직이지 않고 있습니다. 비트코인의 제한적인 활용성으로 인해 큰 잠재력이 미개척된 상태이며, 이는 이더리움 등 더 발전된 생태계와 뚜렷한 차이를 보입니다(그림 1 참조).

비트코인의 전체 시가총액 대비 DeFi에 잠긴 가치(TVL)의 비율은 1% 미만(약 0.5%)으로, 비트코인의 금융적 활용이 다른 주요 블록체인 생태계에 비해 상당히 뒤쳐져 있음을 나타냅니다(그림 2 참조). 이더리움은 전체 시가총액 대비 TVL 비율이 48.6%, 솔라나는 23.8%에 이르는 등 높은 비율을 보이고 있습니다.

이러한 현상은 비트코인의 기본 구조가 튜링 완전한 스마트 컨트랙트를 지원하지 않기 때문이며, 이는 DeFi와 같은 복잡한 금융 애플리케이션 구축을 어렵게 만드는 요인입니다. 하지만 최근 비트코인의 프로그래밍 능력을 개선하려는 다양한 기술적 접근이 활발히 연구되고 있습니다. 본 리서치에서는 이러한 기술적, 생태적 변화를 중심으로 비트코인이 단순한 가치 저장소에서 프로그래밍 가능한 자산 네트워크로 발전할 수 있는지 그 가능성과 한계를 2025년 현재 시점에서 깊이 있게 분석하고자 합니다.

2. '비트코인 프로그래밍'의 정의

기술을 살펴 보기 앞서 먼저 '비트코인 프로그래밍'이란 용어 정리가 필요합니다. 직관적으로는 비트코인 블록체인 상에서 어떤 형태로든 프로그래밍 가능한 논리를 구현하는 것을 뜻할 것입니다. 다만 범위를 너무 넓게 잡으면 이더리움에서 래핑된 WBTC나, 별도 사이드체인 등에 페깅, 브릿지된 BTC를 다루는 것까지 모두 포함될 수 있습니다. 본 리서치에서는 범위를 좀 더 좁혀서, 비트코인 L1의 스크립트 시스템과 UTXO 모델 위에서 직접 구현되거나 밀접하게 연동되는 스마트 컨트랙트 기술들에 초점을 맞추겠습니다.

비트코인 자체도 스크립트(script)라는 간단한 스크립팅 언어를 가지고 있어 일부 스마트 컨트랙트의 원시적 형태를 지원합니다. 예컨대 멀티시그나 시간 지연락(time lock) 같은 조건부 거래는 현재도 비트코인 L1에서 구현 가능합니다. 하지만 Bitcoin Script는 튜링 불완전하며 루프나 임의 연산을 지원하지 않고, 출력 결과(UTXO)의 사용처를 세밀히 제한하는 등의 기능도 부족합니다. 따라서 여기서 말하는 '비트코인 프로그래밍'은 Bitcoin Script/UTXO의 한계를 확장하여 보다 복잡한 조건부 거래나 스마트 컨트랙트를 가능케 하는 기술들을 의미합니다. 구체적으로는 비트코인 L1에서 직접 구현되거나, 최소한 그 스크립트 시스템과 UTXO 구조를 적극 활용하는 방식에 초점을 두었습니다. 이는 비트코인에 새로운 스크립트 기능을 추가하는 제안들과, L1을 변경하지 않으면서 오프체인 혹은 세컨드레이어에서 스마트 컨트랙트를 구현하는 접근 모두를 포함합니다. 이들은 모두 비트코인의 합의 규칙과 구조 안에서 설계되어 있다는 점에서 공통적인 특징을 가집니다.

반면, Rootstock이나 Stacks처럼 비트코인과 연계는 되어 있지만 독립적인 실행 환경을 중심으로 동작하는 프로젝트들은 본 리서치의 정의에서는 다소 벗어나는 사례입니다. 이들 시스템은 BTC를 연동하여 사용하긴 하지만, 스마트 컨트랙트가 실행되는 구조나 논리가 비트코인의 스크립트 시스템 바깥에 위치해 있으며, 비트코인 L1의 계산적 제약을 직접 다루거나 확장하려는 접근은 아닙니다. 기술적, 철학적으로 모두 의미 있는 시도이지만, 본 리서치에서는 비트코인 본연의 기능적 확장을 목표로 하는 프로그래밍 기술들에 초점을 맞추고자 했습니다.

필자로서도 "어디까지를 비트코인 프로그래밍으로 볼 것인가?"를 고민하며 이 주제를 정의했고, 결과적으로는 비트코인 네트워크 내부의 실행 가능성과 활용도를 확장하려는 기술들을 중심으로 리서치 방향을 설정했습니다. 이는 결국 비트코인이라는 네트워크 자체의 진화를 바라보는 논의에 보다 직접적으로 연결된 주제라 판단했기 때문입니다.

3. 비트코인의 언어적 실행 환경을 직접 확장하지 않는 접근

비트코인의 기능적 한계를 넘어서기 위한 한 가지 접근 방식은, 별도의 네트워크를 구성하여 비트코인의 가치를 외부에서 활용하는 것입니다. 대표적인 예로 루트스탁(Rootstock)과 스택스(Stacks)가 있습니다.

이들 프로젝트는 "비트코인에서 스마트 컨트랙트를 구현한다"는 메시지를 중심에 두고 있지만, 비트코인의 스크립트 시스템이나 UTXO 모델을 직접 확장하는 방식은 아니며, 별도의 실행 환경에서 스마트 컨트랙트를 구동합니다. 그럼에도 불구하고, 비트코인 생태계의 기능적 확장이라는 측면에서 중요한 흐름이라는 점에서 간단히 살펴보고자 합니다.

루트스탁 (Rootstock):
스택스 (Stacks):

두 사례 모두 비트코인 자산을 기반으로 더 풍부한 기능을 실현하고 있다는 점에서 충분히 의미 있는 기술입니다. 루트스탁은 EVM 호환성을 통해 이더리움 기반 디앱을 손쉽게 이식할 수 있고, Sovryn과 같은 DeFi 프로젝트가 실제로 운영되며 활발한 실험이 이루어지고 있습니다. 스택스 또한 Clarity 언어 기반의 스마트 컨트랙트를 바탕으로 NFT 및 디앱 생태계를 구축해왔고, 비트코인과의 연계성을 강조하며 "비트코인 위의 스마트 컨트랙트 플랫폼"이라는 정체성을 분명히 해왔습니다.

다만 본 리서치에서는 ‘비트코인 프로그래밍’의 범위를 비트코인 L1의 스크립트 시스템과 UTXO 구조를 직접 활용하거나, 이를 확장하는 방향의 기술로 한정했기 때문에, 이들 프로젝트는 그 범주에는 포함되지 않습니다. 루트스탁과 스택스는 모두 비트코인 자체의 실행 환경을 확장한다기보다는, 비트코인을 별도의 체인으로 연동해 그 위에서 독립적으로 스마트 컨트랙트를 실행하는 구조를 취하고 있습니다. 즉, 이들은 비트코인을 자산적 가치의 앵커로 삼고, 비트코인 외부에서 프로그래밍 가능한 환경을 구성하는 방식인 셈입니다.

이러한 접근은 기능 확장 면에서 실용적인 장점이 있으며, 비트코인 생태계 확장의 하나의 축으로 평가받을 수 있습니다. 그러나 비트코인의 L1 구조 내에서 계산 능력을 넓히거나, 그 프로토콜 자체의 한계를 기술적으로 극복하려는 시도는 아니기에, 비트코인 네트워크 내부의 프로그래밍 가능성을 다루는 본 리서치의 주요 분석 대상에서는 제외하였습니다.

요약하자면, Rootstock과 Stacks는 “비트코인을 활용한 외부의 스마트 컨트랙트 실행 환경”이라 할 수 있습니다. 이는 비트코인 자산의 활용 범위를 넓히려는 중요한 시도임에는 분명하지만, 본고에서 중점적으로 다루고자 하는 Bitcoin L1 또는 이에 밀접하게 연계된 구조 내에서의 프로그래밍 확장 기술들과는 분석 범주가 다르다고 판단하였습니다. 이후 살펴볼 기술들은 모두, 비트코인의 보수적인 L1 철학을 유지하면서도 그 기능적 한계를 넓히려는 접근이라는 공통점을 지니고 있습니다.

4. 비트코인 언어적 실행 환경의 확장을 시도하는 기술

앞서 비트코인의 기능 확장을 시도하는 다양한 접근들 가운데, 비트코인 L1의 스크립트 시스템과 직접적인 연동 없이 별도 실행 환경을 구성하는 방식들을 간단히 살펴보았습니다.

이제부터는 본격적으로, 그 ‘비트코인 프로그래밍’의 정의에 부합하는 주요 기술들을 살펴보고자 합니다. 이들 기술은 비트코인의 보수적인 합의 구조와 제한적인 스크립트 언어라는 제약 조건 아래에서도, 계산 능력을 확장하거나 더 복잡한 계약 구조를 가능하게 하기 위한 다양한 설계적 시도들입니다. 그리고 공통적으로, 단순히 스마트 컨트랙트를 ‘가능하게’ 하는 것을 넘어서, 비트코인의 보안성과 검열 저항성을 유지한 채로 확장 가능한 실행 환경을 구축하려는 철학적 목적을 내포하고 있다는 점에서 주목할 만합니다.

이 장에서는 대표적으로 다음의 네 가지 기술을 중심으로 분석합니다:

(1) Bitcoin Covenants, (2) Simplicity, (3) BitVM, (4) RGB 프로토콜.

각 기술은 서로 다른 방식으로 비트코인의 계산 모델을 확장하고 있으며, 기술적 구조와 철학, 그리고 실용성과 한계점에 이르기까지 각기 다른 트레이드오프를 가지고 있습니다. 오늘날 ‘비트코인 프로그래밍’이 어디까지 확장되었는지, 또 이 기술들이 향후 어떤 방향으로 진화할 수 있을지를 면밀히 살펴보겠습니다.

4.1 Bitcoin Covenants (OP_CTV와 OP_VAULT 등) – L1에 복잡한 조건부 거래 넣기

(1) 개요 및 배경:

커버넌트(covenant)는 비트코인 L1 스크립트 자체를 개선하여 프로그래밍성을 높이려는 시도입니다. 2023~2024년 사이 비트코인 개발자 커뮤니티에서 가장 뜨겁던 주제 중 하나가 바로 커버넌트였습니다. 커버넌트란 원래 "계약"을 뜻하는 단어인데, 비트코인 맥락에서는 “특정 코인이 이후에 어디로 또는 어떻게 쓰일지를 제약하는 기술”을 가리킵니다. 쉽게 말해, 비트코인 스크립트에 “이 코인은 반드시 다음번에 주소 X로만 써야 한다” 또는 “다음 트랜잭션 출력에 이 금액 이상을 포함해야 한다” 같은 규칙을 넣을 수 있게 하는 것입니다. 현재 비트코인 스크립트로는 이런걸 직접 표현하기 어렵습니다. 그래서 여러 개발자들이 다양한 커버넌트 기능 추가 제안을 내놓았고, 그 중 2022년에는 OP_CHECKTEMPLATEVERIFY (OP_CTV)라는 제안이 큰 주목을 받았습니다.

2023년 들어 다시 OP_CAT이란 opcode의 부활이 화제가 되었는데, OP_CAT은 “Concatenate”의 약자로, 스택의 두 값을 연결하여 하나로 만드는 연산자입니다. 사실 비트코인 초기(2010년 전후)에는 이미 존재했지만 사토시 나카모토가 비활성화시킨 opcode 중 하나입니다. 그 이유는 과거 구현에서 메모리 문제와 버그 우려가 있었기 때문이었죠. 이후 줄곧 잠들어 있던 OP_CAT이 다시 주목받은 이유는, 이것이 커버넌트를 구현하는 열쇠가 될 수 있기 때문입니다. 이는 단독으로 커버넌트를 구현하는 연산자는 아니지만, 다양한 커버넌트 구현 방식의 기반이 될 수 있는 범용 도구(opcode)로 간주됩니다. 다시 말해, OP_CTV와 OP_VAULT는 커버넌트를 직접 정의하는 제안이고, OP_CAT은 커버넌트 구현을 가능하게 하는 저수준 구성 요소로 기능합니다.

(2) 기술적 해결 방법:

현재 논의되는 커버넌트 구현안들은 새로운 스크립트 연산자(OP 코드)를 추가하는 방식을 취합니다.

OP_CTV (BIP-119) 는 출금 거래의 출력 구조에 대한 해시(commitment hash)를 미리 고정함으로써, 해당 UTXO를 사용할 때 그 출력이 특정한 템플릿을 따르도록 강제합니다. 예를 들어 Alice가 자신의 코인을 Bob과 Charlie에게 보낼 때, OP_CTV를 사용하면 “0.4 BTC는 Bob에게, 0.4 BTC는 Charlie에게, 잔여 0.2 BTC는 10년간 봉인되는 본인 금고로”와 같은 출력 형태와 조건을 미리 정해 둘 수 있습니다.
OP_VAULT (BIP-345) 는 보안 강화를 목적으로 제안된 코비넌트로, 코인을 인출하기 위해 2단계의 거래를 요구합니다. 먼저 금고에서 임시 인출 후 일정 시간 지연이 발생하고, 그 사이 사용자는 별도 복구 키를 이용해 코인을 안전한 주소로 회수할 수 있습니다. 이로써 해킹 등의 위험으로부터 자금을 방어하는 구조입니다.
OP_CAT (BIP-347) 은 스택의 두 요소를 연결(concatenate)하는 단순한 연산자입니다. 하지만 이 연산자는 Schnorr 서명 체계와 결합될 때, 특정 거래의 형태를 검증하거나 출력 조건을 제한하는 등, 제한적이지만 유용한 커버넌트 기능을 구현할 수 있게 해줍니다. 예를 들어 거래의 일부 필드와 미리 정해둔 데이터를 결합한 뒤 해시를 비교해 특정한 출력만 허용하는 스크립트를 작성할 수 있습니다. 실제로 "Purrfect Vault" 같은 프로젝트는 OP_CAT을 활용해 1회성 커버넌트를 구현한 예시로 자주 인용됩니다.

case OP_CAT:
{
  // 스택에 최소 두 개의 요소가 있어야 함. 부족하면 에러 반환
  if (stack.size() < 2)
    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

  // 스택의 두 번째 요소 (아래에 있는 값)를 참조 → x1
  valtype& vch1 = stacktop(-2);

  // 스택의 최상단 요소 (위에 있는 값)를 참조 → x2
  valtype& vch2 = stacktop(-1);

  // 두 요소를 붙인 결과가 520바이트 초과이면 에러 반환 (Bitcoin의 스크립트 요소 최대 길이 제한)
  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);

  // x2의 내용을 x1의 뒤에 붙여서 연결 (x1 = x1 || x2)
  vch1.insert(vch1.end(), vch2.begin(), vch2.end());

  // x2는 이제 필요 없으므로 스택에서 제거
  stack.pop_back();
}
break;


>>> 실행 결과

Before:
[ ... x1, x2 ]   // x2가 스택 맨 위


After OP_CAT:
[ ... x1 || x2 ] // x1과 x2가 붙어서 하나의 값이 됨

위 코드는 OP_CAT 코드로 실행 흐름을 요약하자면, 아래와 같습니다.

스택 위에 최소 2개의 값이 있어야 한다.
위에서 두 번째 값(x1)과 최상단 값(x2)을 연결한다.
연결된 결과가 520바이트를 초과하면 실패한다.
x1에 x2를 붙인 뒤, x2는 스택에서 제거하고, 새 연결 값이 스택 위에 남는다.

OP_CAT 자체는 매우 간단한 연산입니다. 스택에서 두 요소를 팝하여 붙이고 다시 푸시, 끝. 하지만 이것이 유용하려면 다른 연산들과 조합되어야 합니다. 특히 Schnorr 서명 도입으로 가능해진 트릭이 중요합니다. Schnorr 서명은 ECDSA와 달리 선형성을 활용한 다양한 컨스트럭션이 가능합니다. 그중 하나가 OP_CHECKSIGFROMSTACK (OP_CSFS)라는 미제안 상태의 opcode 아이디어인데, Schnorr 서명을 사용하면 OP_CAT 없이도 유사 기능을 달성하거나, OP_CAT과 결합하면 강력한 introspection(거래 내부정보 검증)이 가능합니다. 예를 들어 Schnorr 서명이 임의의 메시지에 대해 검증될 수 있다는 점을 이용해, 스크립트 내에서 “이 서명이 가리키는 메시지가 X인지 확인” 같은 동작을 하게 하는 것이죠. OP_CAT은 그런 메시지를 구성하는데 쓰이게 됩니다. 조금 어려운 내용이지만 핵심은 OP_CAT이 단독으로는 거래 내부 데이터를 직접 읽지는 못하지만, 거래 해시 등과 결합하여 제한적인 형태로 원하는 제약을 거는 게 가능하다는 것입니다. 이렇게 하면 특정 UTXO의 사용 조건을 다음 거래의 형태에 묶어둘 수 있으니, 일종의 일회성 커버넌트가 구현됩니다.

요약하자면, OP_CTV와 OP_VAULT는 비교적 명확한 사용 목적과 제약 조건을 가진 완성형 커버넌트 제안인 반면, OP_CAT은 그 자체로는 단순한 조작 연산자이지만, 다른 연산자 및 Schnorr 서명 체계와 결합될 때 커버넌트를 구성할 수 있는 중요한 기반 연산으로 기능합니다. 이러한 연산 조합은 비트코인 스크립트의 표현력을 넓히는 동시에, 사용자가 제한적인 조건 아래에서 자신의 UTXO를 어떻게 사용할지를 더 정밀하게 정의할 수 있도록 해줍니다.

(3) 한계 및 발전 가능성:

Bitcoin Covenants 제안들은 각기 다른 방식으로 비트코인의 조건부 거래 기능을 확장하려 하지만, 기술적 제약과 커뮤니티 내 철학적 우려 속에서 현실적인 한계에 직면하고 있습니다.

우선 OP_CHECKTEMPLATEVERIFY(OP_CTV)는 비순환적(non-recursive) 커버넌트만을 허용하며, 출력 구조를 단순한 해시 템플릿 형태로 제한하는 만큼, 복잡한 조건 논리를 구현하는 데 제약이 있습니다. 응용 가능성은 넓지만, 그 표현력은 제한적입니다.

OP_VAULT는 특정 보안 목적(해킹 대응)을 위해 설계된 전용 커버넌트이기 때문에, 그 구조 자체가 일반화되기 어렵습니다. 유연성보다 보안성에 초점이 맞춰져 있어 다른 종류의 조건부 로직에는 적합하지 않습니다.

OP_CAT은 스택 내 값을 연결하는 단순한 조작 명령이기 때문에, 단독으로는 커버넌트를 구현할 수 없습니다. 또한, 현재 논의되는 OP_CAT 기반 구조는 재귀적 커버넌트(recursive covenant)를 허용하지 않으며, 트랜잭션의 내부 구조나 상태를 직접 참조할 수 없기 때문에, 일반 목적 스마트 컨트랙트에 필요한 복잡한 로직을 구성하는 데에는 분명한 한계가 존재합니다. 현재 비트코인 스크립트 구조에서는 거래 내 정보를 조건문에 직접 반영하는 것이 어려워, 보다 강력한 introspection(opcode-level 메시지 분석) 없이는 기능 확장에도 제약이 따릅니다.

무엇보다 중요한 한계는 기술 자체보다 비트코인의 철학적 가치와 충돌 가능성입니다. 커버넌트는 본질적으로 UTXO의 사용 조건을 제한하는 것이며, 이는 자산의 자유로운 이동, 익명성, 대체가능성(fungibility)과 같은 비트코인의 핵심 가치와 긴장 관계를 형성합니다. 커뮤니티 내 일부에서는, 커버넌트가 향후 규제 기관에 의해 남용될 가능성까지도 우려하고 있습니다. 물론 이는 기술 자체의 문제라기보다, 그 사회적 적용 방식에 대한 우려이지만, 비트코인 커뮤니티의 보수적 특성상 도입 논의는 신중할 수밖에 없습니다.

이러한 제약에도 불구하고, 세 가지 제안은 각기 다른 방향에서 L1 기능 확장 가능성을 제시하고 있습니다.

OP_CTV는 단순하지만 실용적인 커버넌트 도입 사례로, Vault, Payment Channel Factory, UTXO 관리 자동화 등 여러 응용이 가능하며, 테스트넷에서도 지속적으로 검증이 이뤄지고 있습니다. OP_VAULT는 실질적인 자산 보호 기능을 제공하며, 향후 하드웨어 지갑, 콜드스토리지 설계와 결합될 경우 유의미한 보안성을 확보할 수 있는 수단이 될 수 있습니다.

OP_CAT은 앞선 두 제안과 달리, 범용적인 연산 기반으로서 조건부 로직을 조립할 수 있는 저수준 도구로 기능합니다. 특히 Schnorr 서명과의 조합을 통해, 특정 출력 조건이 충족되지 않으면 트랜잭션이 실패하도록 구성할 수 있어, 제한적이나마 “일회성 커버넌트”를 구성할 수 있습니다. 현재는 완전한 커버넌트를 구현하기엔 부족하지만, OP_CHECKSIGFROMSTACK(OP_CSFS), OP_TX와 같은 보다 강력한 introspection opcode와 함께 논의될 경우, 점진적으로 범용 커버넌트 구조로 확장될 수 있는 발판이 될 수 있습니다.

또한 실제 응용 실험도 진행 중입니다. 예를 들어 Purrfect Vault 같은 테스트 프로젝트는 Signet 환경에서 OP_CAT을 활용한 제한적 커버넌트를 구현했고, Taproot Wizards의 Quantum Cats NFT 시리즈는 OP_CAT 지지를 널리 알리며 개발자 커뮤니티의 관심을 끌었습니다. 이러한 실험적 흐름은 단순한 이론 제안에 그치지 않고, 실제 적용을 위한 공감대 형성 단계로 이어지고 있습니다.

결국 Bitcoin Covenants는 단일 제안의 채택 여부를 넘어서, L1 프로그래밍 확장을 둘러싼 철학, 기술, 거버넌스 간의 균형점을 어디에 둘 것인가라는 장기적 과제를 담고 있습니다. 향후 커뮤니티의 합의에 따라, 각 제안은 개별적으로 또는 상호 보완적으로 채택되어, 보다 유연한 비트코인 네트워크의 발전에 기여할 수 있을 것입니다.

4.2 Simplicity - 형식 검증과 표현력을 강화한 새로운 스마트 컨트랙트 언어

(1) 개요 및 배경:

Simplicity는 비트코인 스크립트를 대체 또는 보완하기 위해 고안된 신규 스마트 컨트랙트 언어입니다. 2017년 Blockstream의 러셀 오코너가 처음 발표한 이 언어는 티셔츠에 인쇄할 수 있을 정도로 단순한 블록체인 프로그래밍 언어를 표방하면서도 기존 비트코인 스크립트와 이더리움 EVM의 한계를 동시에 극복하려는 목적으로 개발되었습니다. 비트코인 스크립트는 고의적으로 튜링 불완전하게 만들어졌기 때문에 복잡한 루프나 조건 처리가 어렵고, 제공되는 연산도 제한적이어서 디지털 서명 검증 등 정형화된 용도 외에는 활용이 제한되어 왔습니다. 반면 이더리움의 EVM은 튜링 완전성을 갖춰 임의의 복잡한 프로그램을 실행할 수 있지만, 정적 분석으로 자원 소모를 예측하기 어려워 가스 한도에 걸리면 중간에 실패하는 등, 즉 실행 도중 중단되는 비결정성과 비용 문제가 있습니다.

Simplicity는 이 둘의 중간점에서 새로운 설계 철학을 제시합니다. 튜링 완전성은 포기하되, 표현력은 최대한 넓히고, 수학적으로 프로그램의 성질인 안전성과 자원 소모를 검증 가능하게 만들자는 것입니다. 이를 통해 개발자는 더 복잡하고 다양한 스마트 컨트랙트를 작성할 수 있지만, 실행 전에 그 비용과 효과를 예측하여 위험을 제어할 수 있습니다. Simplicity의 언어적 특징은 정형 수학에 기반한 저수준 함수형 언어라는 점입니다. 루프나 재귀 호출이 없어 반드시 종료하는 프로그램만 표현할 수 있으며, 각 프로그램은 논리적으로 아홉 개의 기본 연산자로 구성된 추상 구문 트리 형태로 나타납니다. 이러한 구성은 Coq 같은 형식 검증 도구로 프로그램의 정확성 증명을 가능케 한다는 이점이 있습니다. Simplicity는 머클라이즈드 추상 구문 트리 구조도 채택하고 있어서, 큰 프로그램을 여러 부분으로 쪼개 필요 시 부분적으로 포함시키거나 증명할 수 있습니다.

이는 Taproot 이후 비트코인에서 도입된 MAST 개념의 일반화로 볼 수 있는데, Simplicity에서는 언어 차원에서 프로그램 조각 각각의 해시를 계산해 놓고 증명이나 검증 시 필요한 부분만 공개함으로써 프라이버시와 효율을 높일 수 있습니다. 한마디로, Simplicity는 비트코인 스크립트보다 훨씬 유연하고 강력한 언어적 캔버스를 제공하려는 시도입니다. 배경에는 2015년에서 2016년경부터 Blockstream 연구진이 비트코인에 고신뢰성 스마트 컨트랙트를 도입하는 방법을 모색해온 흐름이 있으며, Simplicity는 그 총합으로 등장한 언어라고 할 수 있습니다.

(2) 기술적 해결 방법:

Simplicity는 새로운 고급 언어이지만, 실제 구동 방식은 비트코인 컨센서스에 통합 가능한 저수준 실행환경을 정의하는 것입니다. 따라서 Simplicity를 활용하려면 결국 비트코인 프로토콜에 이 언어를 이해하고 처리하는 해석기 또는 검증 로직이 추가되어야 합니다. 이는 대규모 변경이므로, Simplicity 도입은 소프트포크 형태로 제안될 예정입니다.

기술적으로 Simplicity의 해석기는 다음 특징을 갖습니다.

Combinator 기반 표현: Simplicity 프로그램은 몇 가지 기본 조립 규칙, 예를 들어 함수 합성, 페어링, 선택 등을 통해 구성됩니다. 예를 들어 두 값을 더하는 Simplicity 프로그램을 만든다고 할 때, 덧셈이라는 연산은 기본 조합자로 표현되지 않고, 더 기본적인 비트 단위 연산들을 조합하여 정의됩니다. Simplicity의 기본 연산자는 9개뿐이므로, 어떤 고급 기능도 결국 이들을 조합하여 표현해야 합니다. 이는 EVM처럼 수십 개의 명령어를 미리 내장하는 방식과 대조됩니다. Simplicity의 핵심 연산들로는 unit, pair, take, drop, comp, case 등이 있으며, 이들을 이용해 논리연산부터 해시, 서명검증까지 모두 구현할 수 있습니다. 코드 예시를 들면, 두 256비트 해시값을 비교하는 프로그램을 만들려면 Simplicity에서는 hash1 drop hash2 drop eq 와 같이 drop과, 만약 eq가 기본 제공되지 않았다면 XOR, NOT 등의 조합으로 정의해야 하는 방식입니다. 매우 저수준이라 프로그램이 장황해지지만, 이 모든 것을 조합으로 표현하는 접근은 형식 검증의 기반을 제공합니다. 덕분에 특정 Simplicity 프로그램이 수행하는 바를 수학적으로 증명하고 분석하는 것이 용이해집니다.
정적 분석과 자원 예측: Simplicity의 설계 목표 중 하나는 프로그램 실행 비용을 사전에 정확히 계산할 수 있게 하는 것입니다. 각 기본 연산자들은 실행에 필요한 최악의 경우 연산량을 정해진 콤비네이터 연산 비용 모델에 따라 갖고 있으며, 프로그램을 구성하는 연산자들의 비용을 합산하여 전체 비용, 예를 들어 실행 스텝 수를 산출할 수 있습니다. 이는 곧 노드 운영자가 Simplicity로 작성된 스크립트가 들어간 거래를 검증하기 전에 그 스크립트가 소모할 연산 리소스를 파악할 수 있음을 의미합니다. 비트코인 스크립트도 튜링 불완전 덕분에 이론상 최대 실행 크기를 계산할 수 있었지만, Simplicity는 훨씬 복잡한 스크립트도 여전히 안전하게 분석되도록 설계되었습니다. 이로써 블록 가스 리미트 같은 개념 없이도 노드 과부하를 막을 수 있고, 스마트 컨트랙트로 인한 예기치 못한 자원 고갈 위험을 회피할 수 있다는 것이 큰 장점입니다.
Jets: Simplicity의 단점은 위와 같이 모든 것을 저수준으로 표현하다 보면 실제 프로그램이 매우 커지고 느려질 수 있다는 점입니다. 이를 해결하기 위해 자주 쓰이는 유용한 함수들을 특수 처리하는 Jets 메커니즘이 도입되었습니다. Jets란 미리 지정된 고급 기능의 식별자로, 만약 해당 기능에 대응하는 순수 Simplicity 코드 조각이 스크립트에 포함되어 있으면 이를 해석기가 알아채고, 곧바로 C나 Rust로 구현된 최적화된 네이티브 코드로 실행해주는 기능입니다. 예를 들어 SHA256 해시 계산이나 secp256k1 서명 검증 같은 작업은 순수 Simplicity로 표현하면 수만 개의 기본 연산 조합이 될 수 있지만, 이것을 하나의 Jet으로 간주하여 곧바로 비트코인의 기존 C++ 구현 함수를 호출해 검증해버리는 것입니다. 이렇게 하면 Simplicity 언어 자체는 새로운 명령어 추가 없이도 어떤 복잡한 연산이든 표현할 수 있고, 동시에 성능 문제도 Jet로 해결할 수 있습니다. 현재 Blockstream이 구현한 Simplicity에는 수십 개의 표준 Jet, 예를 들어 기본 산술, 해시, ECDSA, BLS 등이 정의되어 있으며, 향후 필요한 새로운 연산이 생기면 Jet 목록을 업그레이드하는 방식으로 대응할 수 있습니다. 이는 의미심장한데, 비트코인에 별도 소프트포크 없이도 Simplicity 스크립트를 통해 ANYPREVOUT과 같은 새로운 기능을 Jet로 최적화하여 도입할 수 있을 것으로 기대됩니다. 달리 말하면, Simplicity와 Jets 체계는 비트코인의 실행 환경을 장기적으로 유연하게 확장하는 메타 플랫폼 역할을 할 수 있습니다.

Simplicity의 실질적인 활용을 이해하기 위해, 2-of-3 멀티시그 조건을 Simplicity로 구현한 예시를 살펴보겠습니다. 비트코인 스크립트에서는 OP_CHECKMULTISIG로 간단히 처리되지만, Simplicity에서는 기본 조합자와 Jets를 조합해 구성해야 합니다. 아래는 이를 표현한 의사코드입니다.

lua

-- 입력: 3개의 공개키(pubKey1, pubKey2, pubKey3)와 2개의 서명(sig1, sig2)
-- 출력: 2개의 서명이 유효하면 true, 그렇지 않으면 false

prog = pair (pair pubKey1 pubKey2) pubKey3  -- 입력 데이터를 페어링
    |> take (pair sig1 sig2)                -- 서명 2개를 가져옴
    |> case (
        comp (checkSig pubKey1 sig1)        -- 첫 번째 서명 검증
             (comp (checkSig pubKey2 sig2)  -- 두 번째 서명 검증
                   (eq 2))                  -- 참인 개수가 2인지 확인
       ) 
       (drop (false))                       -- 조건 미충족 시 false 반환

이 코드는 세 개의 공개키와 두 개의 서명을 입력으로 받아, 두 개의 서명이 유효하면 true를 반환합니다. pair로 데이터를 구조화하고, take와 drop으로 필요한 부분을 선택하며, checkSig Jet으로 서명을 검증합니다. eq 2는 두 개의 참 결과가 나왔는지 확인하는 논리입니다. 실제로는 Haskell 기반 Simplicity에서 다음과 같이 작성될 수 있습니다.

haskell

-- 2-of-3 멀티시그 Simplicity 프로그램
multiSig2of3 :: Term (PubKey, PubKey, PubKey, Sig, Sig) Bit
multiSig2of3 = comp 
    (pair (take (pair (jet "checkSig") (drop (jet "checkSig"))))  -- sig1과 pubKey1, sig2와 pubKey2 검증
          (drop (drop (unit))))                                   -- pubKey3 무시 (2개만 확인)
    (jet "eq2")                                                  -- 참인 결과가 2인지 확인

여기서 checkSig는 비트코인의 secp256k1 서명 검증을 호출하는 Jet이며, eq2는 두 개의 참 값을 확인하는 최적화된 연산입니다. 이 프로그램은 실행 비용이 사전에 계산 가능하며, Jets 덕분에 성능도 최적화됩니다. 이런 접근은 Simplicity가 비트코인 L1의 스크립트 시스템을 확장하면서도 보안성과 효율성을 유지할 수 있음을 보여줍니다.

(3) 한계 및 발전 가능성:

Simplicity는 여러 가능성을 제시함과 동시에 분명한 한계도 존재합니다.
첫째, 복잡성의 이전 문제가 있습니다. Simplicity 자체는 튜링 불완전하지만, 매우 복잡한 프로그램을 작성하는 것은 여전히 가능하기 때문에 개발자나 감사자가 스크립트를 이해하기 어려울 수 있습니다. 형식 검증을 통해 안전성을 보장한다 하더라도, 그 증명 과정 자체가 복잡하여 개발 생태계의 진입 장벽이 높아질 우려가 있습니다. 결국 개발자 경험과 검증의 현실성 문제가 남습니다.

둘째, 실행 성능과 블록 용량에 대한 우려가 있습니다. Jets를 통해 핵심 연산은 최적화되지만, 대형 Simplicity 프로그램을 온체인에 포함시킬 경우 해당 프로그램의 해시와 일부 증명 데이터들이 거래에 실려야 하며, 해석 과정에서도 많은 연산 자원이 필요합니다. 이는 비트코인 노드의 검증 부하를 증가시킬 수 있습니다. MAST 구조를 활용하여 실행되지 않은 분기 코드는 공개하지 않아도 되지만, 최악의 경우 하나의 계약에 수킬로바이트에서 수십킬로바이트에 이르는 코드 데이터가 포함될 가능성도 있습니다.

셋째, 커뮤니티 컨센서스의 형성이 어렵다는 점입니다. Simplicity 도입은 사실상 비트코인에 새로운 가상머신을 도입하는 것과 유사한 수준의 변화이기 때문에, 이를 둘러싼 합의를 얻기까지 많은 시간이 소요될 것으로 보입니다. 지금까지의 비트코인 발전 방향은 필요한 최소 기능만을 점진적으로 추가해온 방식이기 때문에, OP_CTV와 같은 작고 구체적인 변화들이 더 선호될 수 있습니다. Simplicity의 철학은 미래 기능을 포괄할 수 있는 일반적 플랫폼을 구축하자는 데에 있지만, 이와 대조되는 기존 커뮤니티의 보수적 접근과의 충돌 가능성도 존재합니다.

그럼에도 불구하고, Simplicity는 여러 면에서 비트코인의 스마트 컨트랙트 기능을 비약적으로 향상시킬 수 있는 발전 가능성을 지니고 있습니다. 현재까지는 시험적 구현과 연구 단계에 머물러 있지만, Blockstream은 Elements 사이드체인에 Simplicity를 적용하여 테스트를 진행해 왔으며, 2021년에는 Taproot 스크립트 내에 Simplicity를 도입하는 방안도 논의된 바 있습니다. 공식적인 BIP 제안은 아직 없지만, 관련 기능 개발은 지속되고 있으며, 2023년 기준으로는 Haskell과 Coq 기반 라이브러리로 구현되어 있고 C 기반 해석기 프로토타입도 존재합니다.

Simplicity의 가장 큰 강점은 이론적 완결성입니다. 비트코인 스크립트보다 훨씬 복잡한 논리를 안전하게 담아낼 수 있으며, 형식 검증과 정적 분석을 통해 코드 신뢰성을 확보할 수 있습니다. 이를 통해 비트코인에서도 디파이나 복잡한 계약이 가능해지며, 이더리움이 겪는 무제한 복잡성과 자원 낭비 문제로부터는 자유로울 수 있다는 미래상을 제시합니다.

또한 Jets 메커니즘을 통해 개발자는 임의의 연산을 고성능 네이티브 코드로 구현하여 추가할 수 있는 유연성을 확보할 수 있습니다. 예를 들어 새로운 암호학적 프리미티브나 서명체계, STARKs 검증 등도 Jet으로 구현하면 Simplicity 스크립트에서 바로 활용할 수 있습니다. 이러한 구조는 향후 별도 소프트포크 없이도 새로운 기능을 Simplicity 스크립트에 추가하는 유연한 경로를 제공합니다.

현재로서는 Simplicity가 곧바로 비트코인 메인넷에 적용될 조짐은 없지만, Liquid와 같은 사이드체인을 통해 실용성과 안정성을 입증하고 점차 신뢰를 쌓아가는 전략이 유력합니다. 요약하면, Simplicity는 비트코인의 언어적 한계를 근본적으로 재설계하려는 시도로서 의미가 크며, 동시에 매우 신중하게 접근되고 있는 잠재적 혁신이라 할 수 있습니다. 향후 그 성패는 실제 활용 사례와 보안 검증 결과, 그리고 커뮤니티 내 철학적 합의에 달려 있을 것입니다.

4.3 BitVM – 비트코인을 위한 가상 머신 개념

(1) 개요 및 배경:

BitVM(Bitcoin Virtual Machine)은 2023년 하반기, Robin Linus의 백서 공개와 함께 등장한 개념으로, 프로토콜 변경 없이도 비트코인 위에서 튜링 완전한 계산을 구현할 수 있다는 주장을 내세우며 커뮤니티의 큰 관심을 받았습니다. 기존의 비트코인 스크립트는 루프도 없고, 상태도 유지하지 않으며, 복잡한 계산을 온체인에서 실행할 수 없는 구조입니다. BitVM은 이러한 구조적 한계를 우회하여 “오프체인 계산 + 온체인 검증”이라는 방식으로 복잡한 로직을 구현하고자 하였습니다. 이 개념은 이더리움의 롤업(rollup)이나 fraud proof와 유사하게, 대부분의 연산을 오프체인에서 처리한 후, 필요한 경우에만 온체인으로 검증을 진행하는 방식입니다.

BitVM은 엄밀히 말해 가상 머신이 비트코인 네트워크 전체에서 작동하는 구조는 아니며, 두 참여자 간의 대결 게임 구조를 활용한 시뮬레이션에 가깝습니다. 이를 통해 비트코인에 튜링 완전한 연산을 억지로 삽입하려는 것이 아니라, 제한된 환경 내에서 가능한 최대한의 표현력을 확보하려는 시도로 이해할 수 있습니다.

(2) 기술적 해결 방법:

BitVM은 두 당사자 간 상호작용에 기반한 구조로 작동합니다. 프로그램 실행을 주장하는 프로버(Prover)와, 그 주장의 진위를 검증하는 베리파이어(Verifier)가 등장하며, 이 둘은 일정 금액을 예치한 상태에서 오프체인 기반의 질의응답 과정을 통해 프로그램의 정확성을 검증합니다. 이 구조는 전체적으로 Challenge-Response Game, 즉 도전과 응답의 게임 형태를 취하며, 문제가 발생하지 않는다면 온체인 자원은 거의 사용되지 않고, 필요할 때만 최소한의 정보만 체인에 기록되도록 설계되어 있습니다.

BitVM의 기술 구현은 다음과 같은 순서로 구성됩니다.

프로그램 변환 및 커밋

프로버는 자신이 주장하는 프로그램과 입력, 출력 데이터를 준비합니다. 이후 해당 프로그램을 NAND 게이트 기반의 논리 회로로 변환합니다. 모든 논리 연산은 NAND만으로 표현할 수 있기 때문에, 복잡한 계산도 NAND 게이트로 분해 가능합니다. BitVM에서는 각 NAND 연산을 Taproot의 개별 Tapleaf에 대응시켜 저장합니다. 전체 회로는 Taproot 트리로 구성되며, 해당 주소에 커밋됩니다.

그림 4. NAND 게이트로 구성된 간단한 회로 [출처: BitVM Whitepaper]

예치 및 HTLC 기반 계약 생성

프로버와 베리파이어는 각자 동일한 금액을 예치하고, 이 금액은 HTLC(Hash Time-Locked Contract) 방식으로 잠깁니다. 이때 사용되는 Taproot 주소는 양측 공동 제어 구조로 설정됩니다. 만약 게임이 정상적으로 마무리되지 않거나, 한 쪽이 응답을 중단하는 경우, 설정된 시간 이후 자동으로 정산이 이뤄지도록 설계됩니다.

Challenge-Response 방식 검증

프로버는 “내 프로그램 P에 입력 X를 넣으면 출력은 Y다”라는 주장을 시작으로 게임을 엽니다. 이에 대해 베리파이어는 NAND 회로 내 중간 결과 중 의심되는 부분을 선택하여 도전(Challenge)을 제기할 수 있습니다. 예를 들어, “이 게이트의 입력값 A, B를 보여달라”고 요구하는 식입니다. 프로버는 이에 응답(Response)하여 해당 입력 및 출력값에 대한 증거를 제출합니다.

그림 5. 미리 서명된 거래를 활용한 Challenge-Response 구조 [출처: BitVM Whitepaper]

이 상호작용은 사전에 서명된 트랜잭션 집합을 통해 이뤄집니다. 거래는 순차적으로 구성되어 있으며, 게임이 오프체인에서 순조롭게 진행되는 한 실제 블록체인 상에서 실행되지 않습니다. 그러나 응답이 없거나 문제가 발생하면 거래가 온체인으로 제출되어 정산 절차가 진행됩니다.

Fraud Proof 제출

어느 시점에서든 프로버가 올바른 응답을 제공하지 않거나 회피할 경우, 베리파이어는 **Fraud Proof(사기 증명)**를 온체인에 제출할 수 있습니다. 이 증명은 프로버가 동일한 비트에 대해 서로 모순되는 값을 제시했거나, 요구된 값을 제출하지 못했음을 입증합니다. 성공적인 Fraud Proof가 제출되면 베리파이어는 프로버의 예치금을 회수하게 됩니다.

Bit Commitment 방식과 NAND 구성

BitVM에서는 각 비트를 표현할 때 두 개의 해시값을 사용합니다. 프로버는 이 중 하나의 preimage를 제출함으로써 비트의 값을 ‘0’ 또는 ‘1’로 고정하게 됩니다. 이를 bit commitment라고 하며, 만약 두 preimage를 모두 제시할 경우에는 ‘이중 주장’(equivocation)으로 간주되어 페널티가 부과됩니다.

이러한 비트 커밋 방식을 활용하여 각 NAND 연산은 A, B, C에 대한 bit commitment로 구성됩니다. Tapleaf에는 이와 관련된 스크립트가 포함되며, 이 스크립트를 통해 A NAND B = C 구조가 유효한지를 검증할 수 있습니다.

오프체인 중심의 효율성 확보

전체 구조는 가능한 모든 연산을 오프체인에서 처리하고, 온체인에는 최소한의 정보만 기록하는 방식으로 구성됩니다. Taproot를 이용해 수십억 개의 게이트가 포함된 회로도 효율적으로 커밋할 수 있으며, 실제 체인에 기록되는 데이터는 분쟁 발생 시 필요한 일부 트랜잭션뿐입니다.

이러한 구조 덕분에 BitVM은 기존의 비트코인 프로토콜을 변경하지 않으면서도, 복잡한 계산 검증이 가능한 새로운 모델을 제시합니다. 기술적으로는 옵티미스틱 롤업과 유사한 개념이지만, 이를 비트코인의 제한된 스크립트 환경에서 구현한 점에서 차별성을 갖습니다.

(3) 한계 및 발전 가능성:

BitVM은 비트코인의 기존 기능만으로 복잡한 계산의 검증을 가능하게 만든 참신한 구조이지만, 구조적 한계 역시 명확하게 존재합니다. 먼저 가장 큰 제약은 참여자가 오직 두 명으로 고정된다는 점입니다. 현재의 BitVM 설계는 프로버(Prover)와 베리파이어(Verifier)가 사전에 합의된 규칙과 예치금을 바탕으로 오프체인 상호작용을 수행하는 구조이기 때문에, 불특정 다수가 참여하는 형태의 스마트 계약, 예컨대 탈중앙화 거래소(DEX)나 공개 입찰 시스템처럼 다자간 합의가 필요한 시스템에는 적합하지 않습니다. 향후 n-of-n 또는 1-to-n 채널 구조로의 확장 가능성이 논의되고 있지만, 현재 단계에서는 단일 쌍 간 검증 모델로만 동작합니다.

또한 BitVM은 오프체인 상호작용을 기반으로 하기 때문에, 프로버와 베리파이어 모두 장시간 온라인 상태를 유지해야 하며, 지속적으로 메시지를 주고받아야 합니다. 이는 실시간 반응이 필요한 응용 프로그램에는 적용이 어렵고, 사용자의 부주의나 네트워크 문제로 인해 검증 게임이 중단될 경우 타임락으로 인해 일방적으로 자금을 상실할 위험도 존재합니다. 이러한 구조는 기술적으로 라이트닝 네트워크의 채널 관리와 유사하지만, 일반 사용자에게는 여전히 진입 장벽이 높은 방식입니다.

기술적으로도 BitVM은 저수준 회로 표현을 기반으로 하기 때문에, 고수준 언어나 SDK, 툴체인이 부재한 상태에서는 실용적 응용이 어렵습니다. 프로그래머가 원하는 계산을 표현하기 위해 직접 NAND 회로를 구성하고, 그에 맞춘 Taproot 트리 구조와 사전 서명 트랜잭션을 모두 준비해야 하며, 이는 매우 번거롭고 에러에 취약한 과정입니다. 따라서 향후에는 Tree++와 같은 고수준 언어, 컴파일러, 디버깅 도구가 함께 발전해야 실제 개발에 적용될 수 있을 것으로 보입니다.

그럼에도 불구하고 BitVM이 제시한 방식은 여러 방향으로 발전 가능성을 갖습니다. 첫 번째로, 기존 롤업 기술과의 연계입니다. 비트코인 생태계에서도 다양한 형태의 L2 솔루션이 시도되고 있으며, BitVM은 옵티미스틱 롤업과 매우 유사한 구조를 갖고 있기 때문에 롤업 내 fraud proof 모듈로 사용될 여지가 있습니다. 또한 DLC(Discrete Log Contracts)와 같은 오프체인 계약 기술과 결합하면, 조건부 지불이나 베팅과 같은 로직을 좀 더 정교하게 표현할 수 있을 것으로 예상됩니다.

무엇보다도 BitVM은 비트코인 위에서 새로운 형태의 실행 모델을 실험했다는 점에서 의의가 큽니다. 네트워크의 합의 규칙을 변경하지 않으면서도, 고차원의 연산 검증을 가능하게 했다는 점은 다른 오프체인 기술에도 시사점을 줄 수 있습니다. 향후에는 다자간 구조, 상태 저장(Stateful execution), 보안 추론(Zero-Knowledge Proof 통합) 등으로 확장되어, 보다 실용적이고 일반화된 형태로 진화할 가능성이 있습니다.

4.4 RGB 프로토콜 – UTXO 기반 오프체인 스마트 컨트랙트와 자산 발행

(1) 개요 및 배경:

RGB는 비트코인 위에서 토큰 발행이나 스마트 컨트랙트를 구현하기 위한 오프체인 프로토콜입니다. 2016년 Giacomo Zucco 등이 제창한 개념을 바탕으로 2019년부터 LNP/BP(Standard Association)가 개발을 이끌고 있으며, 2020년대 들어 구현이 성숙되어 일부 자산 발행에 활용되기 시작했습니다. RGB의 이름은 “Really Good for Bitcoin”의 약자로, 본래는 컬러드 코인(colored coin) 개념을 발전시킨 자산 토큰화 프로토콜로 출발했습니다. 그러나 설계 철학이 매우 독특하여 결과적으로 프라이버시가 뛰어나고 범용성이 있는 비트코인 레이어2 플랫폼으로 자리매김하고 있습니다.

RGB가 해결하려는 핵심 과제는, 비트코인의 제한적인 스크립트 기능으로 인해 토큰이나 디앱(탈중앙화 애플리케이션)을 직접 구현하기 어렵다는 점이었습니다. RGB는 이더리움처럼 레이어1을 복잡하게 확장하는 방식을 따르지 않고, 코드와 상태를 체인 밖으로 내보내고, 체인에는 최소한의 증거만 기록하는 접근을 택했습니다. 이를 통해 블록체인 본연의 간결성과 보안을 유지하면서도, 복잡한 기능들을 확장할 수 있는 유연성을 확보하고자 했습니다.

(2) 기술적 해결 방법:

RGB 프로토콜은 이러한 목표를 달성하기 위해 핵심 메커니즘으로 클라이언트-사이드 벨리데이션(client-side validation)과 싱글-유즈 실(single-use seal)를 채택하였습니다. 클라이언트-사이드 벨리데이션이란, 거래의 유효성을 네트워크의 모든 노드가 아니라 관련된 당사자(client)들만 검증한다는 뜻으로, 2012년 피터 토드(Peter Todd)가 제안한 아이디어입니다. 예를 들어 어떤 사용자가 특정 토큰을 받았다면, 그 사용자는 과거 해당 토큰의 발행부터 현재까지의 전체 이력을 스스로 검증해야 합니다. 그러나 그 토큰과 무관한 다른 사용자는 그 데이터를 전혀 알 필요가 없습니다. 이렇게 하면 모든 데이터와 코드가 굳이 블록체인에 올라갈 필요가 없어 온체인 부담이 크게 줄어듭니다. 대신 각 사용자들은 자신의 자산/계약에 대해서는 풀노드 역할을 수행해야 하는 셈입니다.

싱글-유즈 실은 이러한 클라이언트-사이드 검증을 비트코인 UTXO 모델과 연결해주는 개념입니다. 쉽게 말해, 비트코인의 UTXO를 일종의 상태 저장소 슬롯으로 활용하는 것입니다. 하나의 UTXO에 특정 RGB 상태(예: 토큰 발행 내역 X)와 관련된 커밋을 기록하고 그것을 봉인(seal)합니다. 그 UTXO가 실제 비트코인에서 소비되면 봉인이 한 번 열린 것이 되고, 더 이상 같은 상태를 둘이 쓸 수 없게 합니다. 그 대신 새로운 UTXO로 상태가 옮겨가면서 (예: 토큰이 A에서 B에게 전송되면서) 새로운 봉인이 생성됩니다. 이러한 UTXO의 일회성 특성을 이용해, 비트코인 체인이 일종의 논리적 시계 역할을 하도록 만드는 것입니다. 요컨대 RGB는 비트코인 거래 출력이 바뀔 때만 오프체인 상태전이가 일어났다고 간주하고, 그 이전의 모든 검증은 해당 자산 소유자들이 알아서 책임지는 구조입니다.

RGB 프로토콜은 세 가지 계층으로 구성됩니다.

비트코인 L1 (싱글-유즈 실):
오프체인 데이터층:
검증 및 VM:

RGB의 작동 방식을 더 구체적으로 이해하기 위해, Alice가 Bob에게 30 TOKEN을 전송하는 과정을 코드로 살펴보겠습니다. 아래는 RGB 트랜잭션 생성과 검증의 핵심 단계를 보여주는 의사코드입니다.

plain

# Alice가 Bob에게 30 TOKEN을 전송하는 RGB 트랜잭션 생성
1. Alice의 현재 상태:
   - UTXO_U: { owner: Alice, asset: TOKEN, amount: 30 }
2. RGB 전이 생성:
   - Input: UTXO_U (30 TOKEN)
   - Output: UTXO_V (owner: Bob, amount: 30)
   - Commit Hash: h = hash(UTXO_U | UTXO_V | asset_id | amount)
3. 비트코인 트랜잭션 생성:
   - Spend UTXO_U
   - Create UTXO_V with Taproot key: bob_pubkey + tweak(h)
4. 오프체인 데이터:
   - RGB Transition: { prev_state: UTXO_U, new_state: UTXO_V, asset_id: TOKEN, amount: 30 }
5. Bob에게 전송:
   - Send RGB Transition via P2P
6. Bob 검증:
   - Verify UTXO_U history
   - Check h matches UTXO_V tweak

실제로는 Rust로 구현된 rgb-core 라이브러리를 사용하며, 아래는 간단한 예시 코드입니다.

rust

use rgb_core::{ContractId, Transition, SealDefinition}; // RGB 핵심 모듈
use bitcoin::{OutPoint, PublicKey};                     // 비트코인 구조체
use sha2::{Sha256, Digest};                             // 해시 계산용

// 1. Alice의 현재 상태 정의
let asset_id = ContractId::from_hex("token1234").unwrap(); // 자산 ID: TOKEN
let utxo_u = OutPoint { txid: "abc123".parse().unwrap(), vout: 0 }; // UTXO_U: Alice 소유

// 2. RGB 전이 생성
let utxo_v = OutPoint { txid: "def456".parse().unwrap(), vout: 0 }; // UTXO_V: Bob에게 전달
let transition = Transition::builder()
    .add_input(SealDefinition::new(utxo_u, 30))  // 입력: UTXO_U에서 30 TOKEN
    .add_output(SealDefinition::new(utxo_v, 30)) // 출력: UTXO_V로 30 TOKEN
    .set_asset(asset_id)                         // 자산 ID 설정
    .build();                                    // 전이 객체 완성
let commit_hash = Sha256::hash(&transition.serialize()); // Commit Hash 계산

// 3. 비트코인 트랜잭션 (Taproot 키 생성)
let bob_pubkey = PublicKey::from_str("02...").unwrap(); // Bob의 기본 공개키
let tweaked_key = bob_pubkey.tweak(&commit_hash[..]).unwrap(); // Taproot 키: bob_pubkey + tweak(h)

// 4. 오프체인 데이터 준비 (RGB Transition)
let rgb_data = transition.serialize(); // { prev_state: UTXO_U, new_state: UTXO_V, asset_id, amount }

// 5. Bob에게 전송 (가정)
send_to_bob(rgb_data); // P2P로 RGB 데이터 전송

// 6. Bob의 검증 (간단한 예시 함수)
fn verify_rgb_transition(transition: Transition, tweaked_key: PublicKey, commit_hash: [u8; 32]) -> bool {
    let computed_hash = Sha256::hash(&transition.serialize()); // 전이 데이터로 해시 재계산
    tweaked_key.verify_tweak(&computed_hash) // tweaked_key와 해시 일치 여부 확인
}

이 예시에서 알 수 있듯, 모든 RGB의 실제 상태값은 오프체인에 있고, 온체인에는 UTXO 식별자와 해시 커밋만 남습니다. 또한 계약/자산별로 프라이버시가 보장되는데, Bob과 Charlie는 Token에 대한 정보만 주고받고 제3자는 이를 알 수 없습니다. 이는 비트코인의 UTXO 모델을 활용한 익명성과도 통합니다.

(3) 한계 및 발전 가능성:

RGB 프로토콜은 비트코인 프로그래밍의 확장 관점에서 보면 독특한 포지션을 차지합니다. 그러나 그만큼 해결해야 할 과제도 분명히 존재합니다.

첫째는 데이터 가용성(Data Availability) 문제입니다. RGB의 상태 데이터는 블록체인에 저장되지 않기 때문에, 만약 어떤 자산의 이력을 누구도 보관하고 있지 않으면, 나중에 새로 참여한 사람은 그 자산을 검증할 방법이 없습니다. 이를 극복하려면 모든 참가자가 자신의 관련 데이터를 잘 백업하고, 필요시 상호 간 데이터를 전달해줄 수 있는 분산 저장 네트워크가 필요합니다. 현재 RGB 노드 소프트웨어는 필요한 데이터만 교환하도록 최적화되어 있지만, 노드를 장기간 꺼두면 그 사이 발생한 상태 업데이트 자료를 받지 못하는 등의 이슈가 생길 수 있습니다.

둘째는 사용자 경험(UX) 측면의 제약입니다. RGB 자산을 사용하려면 일반 비트코인 지갑으로는 불가능하고, 별도의 RGB 지원 지갑을 사용해야 합니다. 호환 표준이 아직 완전히 자리잡지 않았기 때문에, 초기 사용자는 불편함을 겪을 수 있습니다.

셋째는 신뢰 모델의 문제입니다. RGB는 기본적으로 투명하고 무허가 방식이지만, 오프체인 검증이기 때문에 해당 계약에 참여하지 않은 제3자는 그 거래가 무엇을 의미하는지 파악할 수 없습니다. 이는 규제가 필요한 상황(예: 증권형 토큰)에서는 오히려 장점이 될 수 있지만, 공개적이고 검증 가능한 구조를 선호하는 일부 커뮤니티 철학과는 상충될 수 있습니다. 다만 이 구조는 비트코인의 합의나 보안에는 아무런 영향을 미치지 않으므로, 해당 철학 차이는 사회적 합의의 영역으로 넘길 수 있습니다.

이러한 한계에도 불구하고, RGB는 비트코인 언어적 실행 환경을 획기적으로 확장하는 플랫폼으로 높은 평가를 받고 있습니다. 앞서 본 코버넌트나 Simplicity, BitVM은 모두 어떤 형태로든 비트코인 L1의 스크립트 실행에 변화를 주거나 활용도를 높이는 방법이었습니다. 반면 RGB는 비트코인 L1에는 최소한만 의존하고, 거의 모든 논리를 체인 밖으로 밀어냈습니다. 그럼에도 RGB가 이 범주에 포함되는 이유는, 결국 비트코인의 UTXO 구조와 거래가 일종의 언어 역할을 수행하도록 만들었기 때문입니다. RGB에서 비트코인 거래 순서는 곧 상태전이 언어의 구문(syntax)과 같은 구실을 합니다. 즉, RGB의 프로그램은 “만약 UTXO_X가 소비되고 Y가 생성되면, 상태 Z를 적용하라”는 식이며, 이는 곧 비트코인 트랜잭션이라는 문장이 있어야만 실행되는 셈입니다.

이처럼 비트코인의 기본 동작원리를 활용하여 높은 수준의 기능을 달성했다는 점에서, RGB는 비트코인 언어적 실행 환경을 확장하는 매우 창의적인 기술로 평가됩니다. RGB의 발전사를 보면 2020년대 초반 몇 차례의 버전 업이 있었고, 2023년에는 RGB 0.10 버전이 출시되면서 안정화 단계에 진입했습니다. 특히 AluVM 도입과 글로벌 상태(Global State) 지원이 추가되면서, 단순 자산 발행을 넘어 디지털 아이덴티티, DeFi, NFT 등에도 응용할 수 있는 플랫폼으로 확장되었습니다.

실제로 RGB를 이용해 달러 연동 스테이블코인이나 주식 연계 토큰을 발행하려는 움직임도 있으며, Lightning Network와 결합하여 즉각적인 L2 결제도 가능하다는 점에서 주목받고 있습니다. Lightning 채널의 정산에 RGB 증명을 실어, LN을 통해 토큰 전송을 하는 실험도 진행 중입니다. 이러한 발전은 비트코인 생태계의 확장성 측면에서 RGB가 갖는 실용적 잠재력을 잘 보여줍니다.

철학적으로 보면, RGB는 비트코인의 레이어드 접근(layered approach)을 극한까지 활용한 사례라 할 수 있습니다. 메인체인은 단순하고 안정적인 토대로 남겨두고, 혁신은 그 위에 겹을 쌓아 올리는 전략입니다. 이는 보수적인 비트코인 개발자들의 철학과 정합적이며, 동시에 사용자에게는 필요한 기능을 제공하는 실용적 타협점으로 기능합니다. 확장성과 프라이버시 측면에서도 큰 장점이 있어, L1에 스마트 컨트랙트를 직접 올리는 이더리움의 방식과는 전혀 다른 비트코인만의 경로를 제시합니다.

요약하자면, RGB는 비트코인 자체는 그대로 두면서도, 사실상 비트코인을 프로그래밍 플랫폼으로 만드는 독자적인 길을 개척했고, 이는 충분히 비트코인 프로그래밍의 한 범주로 인정될 만합니다.

5. 맺으며

본 리서치에서는 비트코인의 제한적 활용성을 극복하고 보다 풍부한 프로그래밍 가능성을 열기 위한 다양한 기술적 접근을 포괄적으로 분석했습니다. 특히 '비트코인 프로그래밍'을 "비트코인 L1의 스크립트 시스템과 UTXO 모델 위에서 직접 구현되거나 밀접하게 연동되는 스마트 컨트랙트 기술"로 명확히 정의하고, 이 정의에 부합하는 기술들을 중심으로 분석을 진행했습니다. 이러한 관점에서 다음과 같은 네 가지 기술을 살펴보았습니다.

첫째, Bitcoin Covenants는 L1 스크립트의 연산 능력을 미세하게 확장하여 복잡한 조건부 거래를 가능하게 하는 미시적 접근입니다. 이는 비트코인의 철학과 프로토콜의 보수성을 유지하면서도 사용자가 더 세밀한 자산 관리 규칙을 만들 수 있는 실용적 기능을 제공합니다.

둘째, Simplicity는 완전히 새로운 스크립팅 언어로, 비트코인의 튜링 불완전성을 유지하면서도 형식적 검증과 정적 분석을 통해 복잡한 스마트 컨트랙트를 안전하게 구현할 수 있는 가능성을 제시하는 거시적 개혁에 가깝습니다.

셋째, BitVM은 비트코인의 합의 규칙 변경 없이 온체인에서 최소한의 검증만으로 튜링 완전한 계산을 오프체인에서 수행하는 극단적인 레이어2 전략입니다.

마지막으로 RGB 프로토콜은 비트코인의 UTXO 구조를 창의적으로 활용하여 오프체인에서 스마트 컨트랙트와 자산 발행을 처리하는 독특한 병렬 확장 방식을 제시합니다.

이 외에도 루트스탁(Rootstock)과 스택스(Stacks)와 같은 접근들이 존재합니다. 이들은 비트코인의 견고한 보안성을 기반으로 하면서도 별도의 실행 환경에서 스마트 컨트랙트를 구동하는 방식입니다. 비록 본 리서치의 비트코인 프로그래밍 정의에서는 벗어나 있지만, 이러한 외부적 접근 또한 비트코인의 자산 가치를 효과적으로 활용하면서 생태계를 풍성하게 만드는 중요한 역할을 담당할 수 있습니다. 특히 비트코인 L1의 프로그래밍 기능 확장과 결합될 경우, 보다 강력한 상호 보완적 시너지를 발휘할 가능성이 있습니다. 예를 들어 Rootstock이나 Stacks의 사이드체인과 RGB나 BitVM 같은 레이어2 기술이 통합된다면, 비트코인의 보안성을 최대한 유지하면서 다양한 금융 및 프로그래밍 애플리케이션을 구축할 수 있을 것입니다.

이러한 기술들은 비트코인의 근본 원칙인 탈중앙성, 보안성, 안정성을 존중하면서 프로그래밍 기능을 확장하려는 공통된 목표를 지니고 있습니다. 그러나 각 기술이 선택한 방식과 철학적 강조점은 명확히 구분됩니다. 본 리서치를 통해 이러한 기술들의 특성을 다음과 같은 세 가지 분류 체계로 재정립할 수 있었습니다.

프로토콜 내부 개선형 (Covenants, Simplicity): 비트코인 L1의 스크립트 언어를 직접 확장하여 표현력을 높이는 접근
프로토콜 활용 최적화형 (BitVM): 기존 프로토콜을 변경하지 않고 창의적 해석과 게임 이론적 구조를 통해 한계를 우회하는 접근
프로토콜 경계 재정의형 (RGB): 비트코인의 UTXO를 상태 저장소로 재해석하고 핵심 로직을 오프체인으로 이동시키는 접근

흥미로운 점은 이렇게 분류를 하고 보니, 단순히 기술적 특성이 아닌 비트코인 생태계의 철학적 관점을 반영한다는 것입니다. 내부 개선형은 "비트코인 개선이 필요하다"는 개혁주의적 시각을, 활용 최적화형은 "비트코인은 이미 완벽하니 그 위에 구축하자"는 보수주의적 접근을, 경계 재정의형은 "비트코인은 기초 레이어일 뿐"이라는 실용주의적 관점을 나타냅니다.

2025년 현재의 관점에서 볼 때, 이 접근법들은 서로 상호 배타적이기보다는 상보적 관계에 있습니다. 예를 들어 Covenants나 Simplicity가 도입된다면 BitVM의 효율성이 크게 향상될 수 있고, RGB 프로토콜은 다른 기술들의 보안 모델을 보완할 수 있습니다. 또한, 루트스탁과 스택스 같은 외부 플랫폼이 비트코인 프로그래밍 기술과 연계될 경우 더욱 폭넓은 애플리케이션을 구현할 수 있을 것입니다. 이러한 시너지는 비트코인 프로그래밍의 미래가 단일 기술에 의해 결정되기보다는 여러 기술이 상호 보완적으로 발전하며 함께 성장해 나가는 모습임을 보여줍니다.

결론적으로, 비트코인의 프로그래밍 가능성 확장은 아직 초기 단계에 있지만, 이는 단순한 기능 추가를 넘어 탈중앙화 기술이 지닌 근본적인 가치와 사회적 의미를 재검토하는 과정이라고 볼 수 있습니다. 앞으로도 기술적 혁신과 철학적 고민이 상호작용하며 발전해 나갈 것이며, 이 과정에서 비트코인은 단순한 가치 저장소를 넘어 다양한 응용을 포괄하는 디지털 자산 네트워크로서 더욱 중요해질 가능성이 큽니다. 이러한 발전은 디지털 경제의 구조와 미래를 결정짓는 데 중대한 역할을 할 것입니다.