비트코인 스크립트 언어란 무엇인가요?

비트코인 스크립트는 비트코인 네트워크상의 모든 거래를 제어하는 프로그래밍 언어입니다. 이는 비트코인을 사용할 수 있는 정확한 조건을 정의하는 간단한 스택 기반 언어이며, 네트워크상의 모든 풀 노드는 거래가 검증될 때마다 이 언어를 실행합니다. 이 언어가 없다면, 비트코인은 누가 무엇을 소유하는지 확인할 수 있는 메커니즘이 전혀 없는 단순한 숫자 장부에 불과할 것입니다.

대부분의 사용자는 비트코인 스크립트 언어를 직접 접할 일이 없습니다. 지갑이 이를 사용자에게 보이지 않게 처리해 주기 때문입니다. 하지만 BTC를 보내거나 받을 때마다, 수천 대의 컴퓨터에서 두 개의 작은 프로그램이 동시에 실행되며 지출 조건이 충족되었는지 확인합니다. 이 작동 원리를 이해하면 비트코인이 왜 현재의 구조를 갖게 되었는지, 그리고 이더리움과 같은 플랫폼과 비교했을 때 비트코인이 무엇을 할 수 있고 무엇을 할 수 없는지에 대해 많은 것을 설명해 줍니다.

이 글에서는 비트코인 스크립트의 작동 원리를 다루고, 이를 통해 구현 가능한 주요 거래 유형을 단계별로 살펴보며, 2021년에 스크립팅 계층을 현대화한 탭루트(Taproot) 업그레이드를 설명하고, 2026년 6월 현재 코버넌트(covenant) 오프코드 논쟁의 현황을 다룹니다.

자가 보관 기능을 통해 비트코인을 안전하게 관리하세요 Bitcoin.com 지갑 앱.

주요 내용

• 비트코인 스크립트는 비트코인 프로토콜에 내장된 스택 기반 프로그래밍 언어로, 비트코인 출력을 사용할 수 있는 조건을 정의합니다.
• 모든 비트코인 거래에는 수취인이 설정한 잠금 스크립트(ScriptPubKey)와 지출자가 제공한 잠금 해제 스크립트(ScriptSig)라는 두 가지 스크립트가 포함됩니다. 거래가 유효하려면 이 두 스크립트가 모두 성공적으로 실행되어야 합니다.
• 비트코인 스크립트는 의도적으로 튜링 완전하지 않습니다. 루프가 없고, 실행 간에 지속되는 상태가 없으며, 스크립트 크기에 엄격한 제한이 있습니다. 이로 인해 모든 스크립트는 반드시 종료되며, 이는 제한이 아니라 보안 기능입니다.
• 이 스크립트 언어는 P2PK, P2PKH, P2SH, SegWit(P2WPKH/P2WSH), Taproot(P2TR) 등 다섯 가지 주요 형식을 거쳐 발전해 왔으며, 각 형식은 하위 호환성을 유지하면서 구현 가능한 기능을 확장해 왔습니다.
• Taproot(2021년 11월)는 슈노르 서명, 개인정보 보호를 위한 MAST 기반 지출 경로, 그리고 향후 업그레이드를 보다 원활하게 진행할 수 있는 메커니즘이 내장된 개선된 스크립팅 언어인 Tapscript를 도입했습니다.
• 비트코인 스크립트를 기반으로 구축된 실제 활용 사례로는 다중 서명 지갑, 시간 잠금 거래, 해시 시간 잠금 계약(라이트닝의 기반), 에스크로, 그리고 디스크리트 로그 계약 등이 있습니다.
• 이더리움의 스마트 계약과 달리, 비트코인 스크립트는 상태 비저장형입니다. 즉, 각 스크립트는 다른 거래에 대한 정보를 전혀 알지 못한 채 완전히 독립적으로 실행됩니다. 이는 의도적으로 채택된 아키텍처적 선택입니다.
• 2026년 비트코인 스크립트 개발 분야에서 가장 활발한 분야는 코버넌트 오프코드, 특히 OP_CTV(BIP-119)와 OP_CAT(BIP-347)으로, 이를 통해 스크립트가 지출 거래의 형식을 제한할 수 있게 됩니다. 두 오프코드 모두 아직 메인넷에서 활성화되지 않았습니다.

비트코인 스크립트란 무엇인가요?

비트코인 스크립트는 비트코인 프로토콜에 내장된 스택 기반의 무상태 스크립팅 언어입니다. 비트코인 네트워크의 모든 거래 출력에는 자금을 사용하기 위한 조건을 명시하는 잠금 스크립트(ScriptPubKey라고 함)가 포함되어 있습니다. 해당 자금을 사용하고자 하는 사람은 누구나 이러한 조건을 충족하는 잠금 해제 스크립트(ScriptSig라고 하며, SegWit 및 Taproot 거래의 경우 위트니스 데이터라고도 함)를 제공해야 합니다.

이 언어는 1960년대에 개발된 미니멀리즘적인 스택 기반 프로그래밍 언어인 포스(Forth)에서 구조를 차용했습니다. Forth와 마찬가지로, 비트코인 스크립트는 왼쪽에서 오른쪽으로 읽히며, 스택이라고 하는 데이터 구조를 기반으로 작동하고, 연산자가 피연산자 앞에 오는 것이 아니라 뒤에 오는 역폴란드 표기법(RPN)을 사용합니다. 이 언어는 한 번에 하나의 명령어만 실행하며, 루프가 없고, 실행 사이에 영구적인 메모리를 유지하지 않습니다.

프로토콜 수준에서 설명되는 비트코인 스크립트를 배울 때 대부분의 사람들이 가장 먼저 접하게 되는 점이 바로 이 마지막 사항입니다. 이 언어는 의도적으로 튜링 완전하지 않습니다. 튜링 완전한 언어는 충분한 시간과 자원이 주어지면 어떤 계산이든 수행할 수 있습니다. 반면 비트코인 스크립트는 설계상 그렇게 할 수 없으며, 이러한 선택의 이유는 네트워크가 작동하는 방식에 매우 큰 영향을 미칩니다.

비트코인 스크립트의 작동 원리: 스택 모델

비트코인 스크립트가 어떻게 작동하는지 이해하려면 스택을 알아야 합니다. 스택은 후입선출(LIFO) 방식으로 작동하는 데이터 구조입니다. 접시 더미를 상상해 보세요. 접시는 맨 위쪽에서만 추가하거나 제거할 수 있습니다. 비트코인 스크립트에서도 데이터는 스택에 푸시되며, 오프코드(연산 코드)는 스택의 맨 위에 있는 항목을 조작합니다.

비트코인 노드가 거래를 검증할 때, 다음 두 스크립트를 순차적으로 실행합니다:

1. 잠금 해제 스크립트 (ScriptSig 또는 위트니스) 동전을 사용하는 사람이 제공합니다. 이렇게 하면 데이터(일반적으로 디지털 서명과 공개 키)가 스택에 밀어 넣게 됩니다.
2. 잠금 스크립트 (ScriptPubKey) 지출되는 출력에 연결됩니다. 여기에는 스택 데이터를 처리하고 지출 조건이 충족되는지 확인하는 오프코드가 포함되어 있습니다.

스크립트가 오류 없이 실행되고 마지막에 스택에 0이 아닌 값(TRUE)을 남긴다면, 해당 트랜잭션은 유효한 것입니다. 실패하거나 FALSE를 남긴다면, 해당 트랜잭션은 노드에 의해 거부되며 블록에 포함되지 않습니다.

이 실행 과정은 완전히 상태 비저장 방식입니다. 스크립트는 이전 트랜잭션에 대한 정보를 전혀 가지고 있지 않으며, 현재 잔액에 대한 인식도 없고, 스크립트 실행이 끝난 후에도 유지되는 메모리도 없습니다. 모든 스크립트는 매번 처음부터 독립적으로 실행됩니다.

단계별 안내: 표준 P2PKH 거래

Pay-to-Public-Key-Hash(P2PKH)는 2009년부터 사용되어 온 비트코인의 초기 거래 유형입니다. P2PKH 주소는 “1.”로 시작합니다. 실제 ScriptPubKey와 ScriptSig는 다음과 같습니다:

스크립트 잠금 해제 (ScriptSig):

<서명> <공개 키>

잠금 스크립트 (ScriptPubKey):

OP_DUP OP_HASH160 <공개 키 해시> OP_EQUALVERIFY OP_CHECKSIG

노드가 두 개를 연결하여 함께 실행할 때, 스택 연산은 단계별로 진행됩니다:

• ScriptSig의 서명과 공개 키가 스택에 밀어 넣어집니다.
• OP_DUP 스택 맨 위에 있는 공개 키를 복사합니다
• OP_HASH160 중복 항목에 대해 해시 연산을 수행(SHA-256에 이어 RIPEMD-160)하여 20바이트 길이의 해시 값을 생성합니다.
• 잠금 스크립트의 공개 키 해시가 스택에 밀어 넣어집니다.
• OP_EQUALVERIFY 두 해시가 일치하는지 확인합니다. 일치하지 않으면 실행이 중단되고 트랜잭션이 실패합니다.
• OP_CHECKSIG 해당 서명이 공개 키에 대해 유효한지 확인합니다

모든 단계가 정상적으로 완료되면 스택은 TRUE로 종료되고 자금이 해제됩니다. 이 전체 과정은 밀리초 단위로 소요되며, 네트워크 내 모든 노드에서 동일하게 실행됩니다.

비트코인 오프코드 해설

비트코인 오프코드(opcode)는 스크립트를 구성하는 개별 명령어입니다. 각 오프코드는 1바이트로 이루어져 있어, 총 256개의 오프코드 슬롯이 가능합니다. 이 중 현재 메인넷에서 활성화된 것은 약 80개입니다. 나머지는 예약되어 있거나 비활성화되었거나, Tapscript와 함께 도입된 OP_SUCCESS 전방 호환성 메커니즘에 할당되어 있습니다.

오퍼코드(Opcodes)는 다음과 같은 여러 범주로 나뉩니다:

• 데이터 푸시 오퍼코드 공개 키, 서명, 해시 등의 값을 스택에 밀어 넣는다
• 산술 명령어 코드 더하기, 빼기, 비교 연산을 수행합니다. 특히, 곱셈과 나눗셈은 사용할 수 없습니다.
• 암호화 오프코드 해싱을 위한 OP_SHA256, OP_HASH160, OP_SHA1 및 서명 검증을 위한 OP_CHECKSIG를 포함합니다
• 흐름 제어 오퍼코드 조건부 논리 활성화: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• 스택 조작 오퍼코드 여기에는 OP_DUP(맨 위 항목 복제), OP_DROP(맨 위 항목 제거), OP_SWAP(맨 위 두 항목의 순서 바꾸기) 등이 포함됩니다.

2010년, 사토시 나카모토는 원래 구현 방식에서 취약점이 발견된 후 여러 오퍼코드(opcode)를 비활성화했습니다. 여기에는 OP_CAT(스택 항목 두 개 연결), OP_MUL(곱셈), OP_DIV(나눗셈) 등이 포함됩니다. 이들 오퍼코드의 부재는 비트코인 스크립트가 표현할 수 있는 범위에 지속적인 영향을 미쳤으며, 2026년에 가장 활발히 논의되고 있는 비트코인 업그레이드 제안 중 상당수는 이들 중 일부를 다시 활성화할지 여부를 다루고 있습니다.

16진수 값과 설명을 포함한 전체 오프코드 참조는 다음에서 확인할 수 있습니다. 비트코인 위키 스크립트 페이지 이것이 권위 있는 출처입니다.

‘비튜링 완전성’이 왜 장점인가

일반적으로 알려진 설명에 따르면, 비트코인 스크립트에는 루프가 없기 때문에 스크립트가 반드시 종료되며, 이로 인해 네트워크가 무한 실행으로부터 보호된다고 합니다. 이는 사실이지만, 핵심을 충분히 설명하지는 못합니다.

더 근본적인 논점은 공격 표면에 관한 것입니다. 튜링 완전한 언어는 임의의 계산을 표현할 수 있습니다. 이러한 표현력은 동시에 버그가 서식하는 공간이기도 합니다. 이더리움의 솔리디티(Solidity)는 역사상 가장 막대한 손실을 초래한 소프트웨어 취약점 중 일부를 낳았습니다. 2016년 DAO 해킹 사건은 스마트 계약의 재진입(reentrancy) 결함을 악용하여 당시 시가로 약 6,000만 달러의 손실을 초래했으며, 결국 이더리움 네트워크의 논란이 된 하드 포크로 이어졌습니다. 더 넓은 디파이(DeFi) 생태계에서는 수년에 걸쳐 스마트 계약 악용을 통해 수억 달러가 유출되었습니다.

비트코인 스크립트는 이러한 유형의 공격을 구조적으로 불가능하게 만듭니다. 다른 스크립트를 호출하거나, 조건이 바뀔 때까지 반복하거나, 트랜잭션 사이에 상태를 저장하는 비트코인 스크립트를 작성할 수 없습니다. 모든 스크립트는 경계가 명확하고, 종료되며, 검증 가능한 프로그램입니다. 스크립트의 최대 크기는 10,000바이트입니다. 스크립트당 'push'가 아닌 오퍼코드(opcode)의 최대 개수는 201개입니다. 검증자는 스크립트를 실행하기 전에 항상 최악의 경우를 가정했을 때의 실행 비용을 계산할 수 있습니다.

수천억 달러 규모의 가치를 지닌 네트워크의 경우, 그러한 예측 가능성은 포기해야 하는 유연성보다 더 큰 가치를 지닙니다. 이더리움은 가스 한도를 통해 무제한 계산 문제를 해결하며, 실행된 각 오프코드에 대해 사용자에게 요금을 부과하고 예산이 소진된 스크립트는 중단시킵니다. 이 방식은 효과적이지만, 그 자체로 복잡성과 오류 발생 가능성을 초래합니다. 비트코인은 설계상 이 문제를 완전히 회피합니다.

그렇다고 해도 “튜링 완전하지 않다”는 것이 “복잡한 논리를 처리할 수 없다”는 뜻은 아닙니다. 비트코인 스크립트는 다자간 지출 조건, 시간 기반 조건, 해시 프리이미지 공개, 그리고 이 모든 요소의 조합을 지원합니다. 하루에 수백만 건의 결제를 처리하는 라이트닝 네트워크는 전적으로 비트코인 스크립트의 기본 요소들을 기반으로 구축되었습니다.

스크립트 유형: P2PKH에서 Taproot로의 진화

비트코인의 스크립트 계층은 2009년 이후 크게 발전해 왔으며, 각 업그레이드마다 새로운 거래 형식을 도입하면서도 이전 버전의 모든 내용과 하위 호환성을 유지해 왔습니다.

P2PK (Pay-to-Public-Key, 2009)

블록 170에서 사토시가 할 핀니에게 지급한 거래를 비롯한 초기 비트코인 거래에 사용되었던 원래의 형식입니다. 자금은 해시 값이 아닌 전체 공개 키에 직접 연동되어 잠겨 있었습니다. 현재 새로운 거래에서는 거의 사용되지 않는데, 이는 자금을 지출하기 전에 체인 상에 공개 키가 노출되기 때문이며, 이는 키를 먼저 해시 처리하는 것보다 보안성이 취약한 방식으로 간주되기 때문이다.

P2PKH (Pay-to-Public-Key-Hash, 2009)

10년 넘게 사용되어 온 표준 형식입니다. P2PKH는 공개 키 자체가 아닌 공개 키의 해시에 자금을 연동함으로써, 지출이 이루어지는 순간까지 공개 키를 비공개로 유지하며, 20바이트라는 더 짧은 주소를 생성하고, “1”로 시작하는 모든 주소의 기초를 형성합니다. Unchained의 온체인 데이터(2026년 4월 기준)에 따르면, P2PKH 주소는 현재 채굴된 비트코인 공급량의 약 43%를 보유하고 있습니다.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

2012년 4월 1일 소프트 포크를 통해 도입된 P2SH는 복잡한 지출 스크립트의 부담을 송금인에서 수취인으로 전환했습니다. P2SH는 출력에 전체 잠금 스크립트를 포함하는 대신, “리딤 스크립트”의 20바이트 해시에 대한 커밋을 출력합니다. 전체 스크립트는 코인이 지출될 때만 공개됩니다. 이로 인해 일반 사용자들도 멀티시그를 실용적으로 사용할 수 있게 되었습니다. 즉, 2-of-3 멀티시그 설정의 경우, 결제 시점에 발신자가 세 개의 공개 키를 모두 볼 필요가 없어졌습니다. P2SH 주소는 "3."으로 시작합니다.

프로토콜 수준에서 P2SH 유효성 검증이 어떻게 이루어지는지에 대한 자세한 설명은, developer.bitcoin.org의 거래 가이드 리딤 스크립트 메커니즘을 단계별로 자세히 설명합니다.

P2WPKH 및 P2WSH (네이티브 세그윗, 2017년, BIP 141)

2017년 8월 481,824번째 블록에서 활성화된 세그위트(Segregated Witness)는 서명 데이터를 메인 트랜잭션 본문 밖으로 분리하여 별도의 위트니스 구조로 옮겼습니다. 위트니스 데이터는 가중치가 75% 할인되므로, 세그위트 트랜잭션은 비용 면에서 상당히 저렴해집니다. 에 따르면, 표준 단일 입력·2개 출력의 P2WPKH 거래의 가중치는 약 141 가상 바이트인 반면, 이에 상응하는 P2PKH 거래의 가중치는 226 vbyte입니다. 스파크의 비트코인 주소 유형 분석 2026년 3월부터. 또한 SegWit은 라이트닝 네트워크 구축의 전제 조건이었던 거래 가변성(transaction malleability) 문제를 해결했습니다. 네이티브 SegWit 주소는 “bc1q.”로 시작합니다.

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

탭루트(Taproot)는 2021년 11월 709,632블록에서 활성화되었으며, 세그윗(SegWit) 이후 비트코인의 스크립팅 계층에 이루어진 가장 중요한 업그레이드입니다. 이 업그레이드를 통해 슈노르(Schnorr) 서명, MAST를 지원하는 새로운 출력 유형, 그리고 개선된 스크립팅 언어인 탭스크립트(Tapscript)가 도입되었습니다. 탭루트 주소는 "bc1p."로 시작합니다.

Taproot와 Tapscript: 2021년 비트코인 스크립트 언어가 어떻게 변화했는가

탭루트는 단일 변경 사항이 아닙니다. 이는 함께 설계되어 동시에 활성화된 세 가지 비트코인 개선 제안(BIP)입니다.

BIP 340: 슈노르 서명

비트코인은 원래 ECDSA(타원곡선 디지털 서명 알고리즘)를 사용했습니다. 사토시가 이 알고리즘을 선택한 이유 중 하나는 당시 슈노르 서명이 특허로 보호받고 있었기 때문입니다. 해당 특허는 2008년에 만료되었으며, 탭루트(Taproot)를 통해 마침내 슈노르 서명이 프로토콜에 도입되었습니다.

슈노르(Schnorr) 서명은 64바이트로, ECDSA의 71~73바이트에 비해 더 작습니다. 더 중요한 점은, 슈노르 서명이 MuSig2라는 방식을 통해 키 집계 기능을 지원한다는 것입니다. 키 집계를 통해 여러 서명자는 각자의 개별 키와 서명을 하나의 집계된 키와 서명으로 결합할 수 있으며, 이는 온체인상에서 일반적인 단일 서명 결제와 구별할 수 없습니다. Taproot의 협력형 키 경로를 통해 지출하는 2-of-3 멀티시그 지갑은 블록체인상에서 표준 결제와 동일하게 보입니다. 이는 복잡한 보관 구조 하에서 비트코인을 보유한 모든 사용자에게 실질적인 프라이버시 이점을 제공합니다.

BIP 341: Pay-to-Taproot 및 MAST

P2TR은 두 가지 지출 경로를 가진 새로운 출력 유형을 도입합니다:

• A 키 경로 모든 당사자가 동의하고 가장 간단하고 저렴한 방식을 원할 때 사용되는 슈노르(Schnorr) 서명을 사용하여 지출합니다.
• A 스크립트 경로 MAST(Merkelized Abstract Syntax Tree, 이 개념의 Taproot 구현체)를 사용하여 지출하기

MAST는 단일 출력이 머클 루트(Merkle root)를 통해 여러 지출 스크립트로 구성된 트리에 할당될 수 있도록 합니다. 지출 시, 실제로 사용된 특정 조건만 온체인에 공개됩니다. 트리 내의 다른 모든 가능한 지출 경로는 영구적으로 숨겨집니다. "일반적으로 지출할 수 있다, 6개월 후 3명의 수탁자 중 2명이 지출할 수 있다, 2년 후 복구 키로 지출할 수 있다"와 같이 복잡한 지출 정책을 설정한 사용자의 경우, 실제로 실행된 경로만이 블록체인에 기록됩니다.

2024년 기준, 비트코인 거래에서 탭루트(Taproot)가 차지하는 비중은 약 42%로 증가했는데, 이는 2026년 3월 스파크(Spark)가 인용한 글래스노드(Glassnode) 데이터에 따르면 주로 오디널(Ordinals) 및 BRC-20 인스크립션 활동에 힘입은 결과였다. 그 이후 해당 비중은 시장 상황에 따라 등락을 거듭해 왔으나, 현재 이 인프라는 주요 지갑과 거래소에서 표준으로 자리 잡았다. 비트코인 옵테크의 탭루트 주제 페이지 Taproot와 관련된 진행 중인 프로토콜 개발 현황을 추적합니다.

BIP 342: Tapscript

Tapscript는 Taproot 내에서 스크립트 경로 지출에 사용되는 업데이트된 스크립트 언어입니다. 이 언어는 기존 비트코인 스크립트와 대부분의 오프코드를 공유하지만, 몇 가지 중요한 변경 사항이 있습니다:

• OP_CHECKMULTISIG 그리고 OP_CHECKMULTISIGVERIFY 사용이 권장되지 않습니다. 기존의 멀티시그 오프코드에는 해결책으로 스택에 더미 요소를 푸시해야 하는 특이한 점이 있었습니다. Tapscript는 이를 제거하고 다음으로 대체합니다. OP_CHECKSIGADD, 이는 슈노르 서명을 하나씩 검증하고 카운트를 누적합니다. 이를 통해 임계값 다중 서명 방식의 구현이 더 간결해지고 비용도 절감됩니다.
• MAST 리프당 스크립트 크기 제한이 해제되었습니다. Taproot 브랜치 내의 개별 스크립트는 크기에 제한 없이 작성할 수 있습니다.
• OP_SUCCESS 오프코드 이는 가장 미래 지향적인 변화입니다. 기존 스크립트에서는 정의되지 않은 오프코드가 발견되면 스크립트가 실패합니다. 반면 탭스크립트에서는 OP_SUCCESS 범위에 속하는 오프코드가 있을 경우 스크립트가 무조건 성공합니다. 향후 소프트 포크를 통해, 새로운 스크립트 버전이나 생태계 전반에 걸친 전면적인 재배포 주기 없이도, 이러한 오프코드가 성공하는 시점에 대한 제약 조건을 추가함으로써 실제 동작을 할당할 수 있습니다. 비트코인의 스크립팅 계층에 새로운 기능을 추가하는 과정이 프로토콜 역사상 그 어느 때보다 깔끔하게 이루어질 수 있습니다.

미니스크립트

Tapscript와 함께, Miniscript라는 관련 프로젝트가 개발자들에게 점점 더 중요해지고 있습니다. Miniscript는 분석이 가능하고, 조합이 가능하며, 범용적으로 서명할 수 있는 비트코인 스크립트의 하위 집합을 구조화된 방식으로 작성하는 방법입니다. 일반 스크립트는 수동으로 작성해야 하고 감사하기 어려운 반면, 미니스크립트 스크립트는 정확성을 자동으로 검증할 수 있으며 더 큰 규모의 정책으로 결합할 수 있습니다. 이는 스크립트의 기능을 확장하는 것은 아니지만, 지갑 및 보관 도구를 개발하는 개발자들이 스크립트의 기존 기능을 훨씬 더 쉽게 활용할 수 있도록 해줍니다.

비트코인 스크립트가 가능하게 하는 것: 실제 활용 사례

현재 비트코인 메인넷에서는 다음과 같은 거래 유형이 활성화되어 있으며, 이들 모두는 비트코인 스크립트 기본 요소를 기반으로 구축되었습니다:

다중 서명(멀티시그) 지갑 지출을 승인하려면 M-of-N 개의 개인 키가 필요합니다. 기업의 재무 부서에서는 인출 시 5명 중 3명의 승인을 요구할 수 있습니다. 부부는 공동 저축 계좌에 대해 2명 중 2명의 승인을 적용할 수 있습니다. Taproot와 Schnorr 키 집계 기술을 통해, 협력형 다중 서명 지출은 이제 온체인상에서 표준 단일 서명 거래와 구별할 수 없게 되었습니다.

시간 잠금 거래 OP_CHECKLOCKTIMEVERIFY(CheckLockTimeVerify, 또는 CLTV) 및 OP_CHECKSEQUENCEVERIFY(CheckSequenceVerify, 또는 CSV)를 사용하여 특정 블록 높이 또는 경과 시간 이전에 자금이 이동되는 것을 방지할 수 있습니다. 이 기능은 상속 계획, 직원 토큰 베스팅 일정, 강제 저축 메커니즘, 라이트닝 네트워크 채널 내에서 사용되는 페널티 거래 등에 활용됩니다.

해시 타임락 계약(HTLC) 해시 원상값 요구 사항과 타임록을 결합합니다. 지출 조건은 다음과 같이 작동합니다. 지정된 블록 높이 이전에 이 해시의 원상값을 공개하지 않으면 자금은 발신자에게 반환됩니다. HTLC는 라이트닝 네트워크의 핵심 기본 요소로, 직접적인 관계가 없는 당사자들 간의 채널 체인을 통해 신뢰가 필요 없는 결제 라우팅을 가능하게 합니다.

에스크로 이러한 방식은 자금을 P2SH 또는 Taproot 스크립트에 잠그며, 자금을 해제하기 위해서는 여러 당사자의 동의가 필요하며, 일반적으로 제3자 중재자가 결정권을 가진 키를 보유합니다.

비공개 로그 계약(DLC) 오라클 기반 슈노르 어댑터 서명을 사용하여, 오라클이 자금을 보관할 필요 없이 가격 피드나 이벤트 결과와 같은 실제 데이터를 기반으로 금융 계약의 결제를 처리할 수 있습니다. DLC는 비트코인 메인넷에서 운영 중이며, 비트코인으로 결제되는 옵션 및 선물 상품에 활용되고 있습니다.

비트코인 스크립트 대 이더리움 스마트 계약

비트코인의 스크립트와 이더리움의 솔리디티는 모두 자금이 이동할 수 있는 조건을 정의하지만, 근본적으로 서로 다른 아키텍처적 선택을 반영합니다. 이러한 차이점은 각 네트워크가 수용한 장단점을 상당 부분 설명해 주기 때문에, 두 기술을 직접 비교해 볼 가치가 있습니다.

근본적인 차이점은 ‘상태 유지(statefulness)’ 여부입니다. 이더리움 계약은 트랜잭션 간에 지속되는 데이터를 저장하고 수정하므로, 대출 프로토콜, 탈중앙화 거래소, 온체인 거버넌스, 토큰 표준 등을 가능하게 합니다. 비트코인 스크립트에는 이에 상응하는 기능이 없습니다. 각 스크립트는 다른 트랜잭션에 대한 정보 없이 고립된 상태에서 실행됩니다.

이는 채워야 할 공백이 아니라 의도된 아키텍처적 선택입니다. 비트코인의 스크립팅 계층은 단 하나의 구체적인 목적을 위해 설계되었습니다. 바로 대규모 환경에서 비트코인을 예측 가능하고 안전하게 지출하기 위한 조건을 강제하는 것입니다. 이러한 임무를 수행하는 데 있어 ‘상태 비존재(statelessness)’는 강점입니다. 공격 표면이 더 작고, 수백만 개의 독립적인 검증자 전반에 걸쳐 실행이 결정론적이며, 프로토콜 수준에서는 상태를 유지하는 계약이 존재하지 않기 때문에 프로토콜 수준에서 스마트 계약 악용의 여지가 전혀 없습니다.

비트코인 위에 더 높은 수준의 프로그래밍 기능을 추가하고자 하는 프로젝트들은 이를 계층 구조로 구축합니다. 라이트닝 네트워크(Lightning Network)는 결제를 처리하고, DLC 프로토콜은 외부 데이터를 참조하는 금융 계약을 처리합니다. 아크(Ark)나 리퀴드 네트워크(Liquid Network)와 같은 레이어 2 시스템은 각기 다른 확장성 요구 사항을 해결합니다. 이 모든 것은 기본 계층의 스크립팅 모델을 수정할 필요가 없습니다.

‘코버넌트’ 논쟁: 비트코인 스크립트에서 무엇이 바뀔 수 있을까

비트코인 스크립트의 진화는 항상 느리고 보수적인 양상을 보여왔습니다. 현재 가장 활발하게 개발되고 있는 분야는 ‘코버넌트(covenant) 오프코드’로, 이는 스크립트가 출력을 지출할 수 있는 주체를 제한할 뿐만 아니라, 그 결과로 생성되는 거래가 어떤 형태를 띠어야 하는지도 규정할 수 있게 해주는 제안들입니다. 이는 스크립트의 표현력을 의미 있게 확장하는 것입니다.

2026년 6월 현재 주요 제안은 다음과 같습니다:

• OP_CTV (BIP-119, CheckTemplateVerify)제레미 루빈(Jeremy Rubin)이 작성한 이 제안은, UTXO를 거래의 버전, 잠금 시간(locktime), 입력 개수, 시퀀스, 출력 개수 및 출력을 포함하는 특정 사전 정의된 지출 템플릿에 고정시키는 단일 오프코드를 추가합니다. 이 제안은 설계상 재귀적이지 않으며, 가장 보수적인 주요 제안으로 간주되며, 주로 볼트, 혼잡 제어 및 특정 라이트닝 개선 사항을 목표로 합니다. 2026년 4월 현재, OP_CTV는 ‘스피디 트라이얼(Speedy Trial)’ 신호 전송 기간을 명시하는 구체적인 배포 매개변수가 논의되고 있으나, 활성화에 필요한 광범위한 커뮤니티 합의에는 아직 도달하지 못했습니다. BlockEden의 2026년 4월 약정 분석.
• OP_CAT (BIP-347), 에단 헤일만(Ethan Heilman)과 아르민 사부리(Armin Sabouri)가 제안한 이 제안은 사토시가 2010년에 비활성화했던 오프코드를 다시 활성화할 것입니다. OP_CAT은 두 개의 스택 항목을 연결하는 기능으로, 설명은 간단하지만 그 파급 효과는 광범위합니다. 슈노르(Schnorr) 서명과 결합될 경우, 코버넌트(covenant)와 유사한 거래 내역 조사가 가능해집니다. 2024년 말 sCrypt의 온체인 분석에 따르면, 비트코인 시그넷(Signet) 테스트 네트워크에서 OP_CAT은 APO나 CTV보다 훨씬 더 많은 개발자 트랜잭션을 생성한 것으로 나타났습니다. OP_CAT은 이미 리퀴드 네트워크(Liquid Network)와 프랙탈 비트코인(Fractal Bitcoin)에서 활성화되어 있으며, 이로 인한 악용 사례는 보고된 바 없습니다. BIP-347은 공식 제안 번호를 보유하고 있으며 활발한 연구가 진행 중이지만, 메인넷 활성화에는 아직 형성되지 않은 커뮤니티의 합의가 필요합니다.
• LNHANCE OP_CTV를 OP_CHECKSIGFROMSTACK(CSFS) 및 OP_INTERNALKEY와 결합하여, 비상호작용형 채널 개설 및 보다 효율적인 다자간 채널 관리를 포함한 라이트닝 네트워크 채널 구축의 구체적인 개선 사항을 목표로 합니다.

2026년 6월 현재, 이들 중 어느 것도 비트코인 메인넷에서 활성화되지 않았다. 이들 간의 기술적 이견은 대체로 해결 가능한 수준이다. 더 어려운 문제는 활성화 방식입니다. 비트코인의 소프트 포크 과정에는 광범위한 합의가 필요하며, 코버넌트 논쟁에는 과거 논란이 되었던 업그레이드들로부터 비롯된 잔여 긴장이 남아 있습니다. 이 논쟁을 통해 분명한 점은 비트코인의 스크립팅 계층이 보수적인 프레임워크 내에서 성장할 여지가 충분히 있다는 것입니다. 현재 논의되고 있는 핵심은 순서와 커뮤니티의 합의이지, 스크립팅 언어의 미래 여부가 아닙니다.

결론

비트코인 스크립트는 네트워크상의 모든 거래 이면에 숨겨진 보이지 않는 기반 구조입니다. 대부분의 사용자는 이를 직접 접할 일이 없습니다. 지갑은 유효한 스크립트를 생성하고 서명하며, 그 내부 작동 원리를 드러내지 않은 채 이를 네트워크에 전송합니다. 하지만 모든 결제, 모든 라이트닝 채널, 모든 타임락 플랜, 모든 다중 서명 금고는 2009년 프로토콜과 함께 출시된 동일한 스택 기반 비트코인 스크립팅 언어를 통해 처리됩니다.

그 이후 스크립팅 계층은 상당히 발전해 왔는데, P2SH를 통해 복잡한 지출이 현실화되었고, SegWit은 수수료를 절감하고 라이트닝 네트워크를 가능하게 했으며, Taproot는 슈노르 서명, MAST 기반의 프라이버시 기능, 그리고 Tapscript의 향후 호환성을 고려한 오프코드 설계를 도입했습니다. 현재 활발히 논의되고 있는 코버넌트 제안들은 향후 전개될 잠재적인 다음 장을 예고하고 있습니다. 2026년 중반 현재로서는 어떤 제안이 활성화될지, 그리고 그 시기가 언제일지는 여전히 불확실한 상태입니다.

스크립트를 이해하는 데 개발자일 필요는 없습니다. 다만 비트코인의 보수성, 의도적인 제한, 느린 업그레이드 주기, 튜링 완전성 결여 등이 결함이 아니라는 점을 인식해야 합니다. 비트코인 스크립트를 예측 가능하게 만드는 바로 그 특성들이, 지난 16년 동안 합의 계층을 깨끗하게 유지해 온 원동력이기도 합니다.