비트코인 OP_RETURN 설명: 데이터 캐리어, nulldata, 그리고 쓸 수 없는 출력

비트코인 거래 출력에는 금액과 잠금 스크립트인 scriptPubKey가 들어갑니다. nulldata라고도 분류되는 OP_RETURN 출력은 OP_RETURN opcode로 시작하고, 그 뒤에 짧은 바이트열을 push할 수 있습니다. 데이터는 거래 출력의 일부이므로 거래가 블록에 포함되면 공개적으로 기록됩니다. 개념적으로 OP_RETURN <pushed data> 형태로 나타낼 수 있습니다. 꺾쇠괄호 안의 표현은 설명용이며 실제 스크립트 문법이 아닙니다.

이 패턴으로 커밋먼트, 프로토콜 식별자, 애플리케이션별 바이트를 담을 수 있습니다. 별도 데이터 계층이나 토큰 잔고, 비공개 메시지를 만드는 것은 아닙니다. 특정 형식을 알아보는 파서는 있을 수 있지만, 일반 비트코인 노드는 거래 및 스크립트 규칙을 적용할 뿐입니다. 거래를 볼 수 있는 사람과 소프트웨어는 payload를 확인할 수 있으므로 비밀, 비밀번호, 개인정보를 넣지 마세요.

스크립트에 바이트가 들어 있다고 해서 그 바이트가 결제 조건이나 비트코인 소유권을 뜻하지는 않습니다. 프로토콜이 특정 접두어나 형식에 의미를 부여할 수는 있지만, 그 규칙은 OP_RETURN 자체가 아니라 해당 애플리케이션에서 옵니다. 파서가 형식을 알아보지 못해도 거래는 비트코인 거래로 검증될 수 있습니다. 반대로 애플리케이션 파서가 데이터를 읽었다고 별도의 자산이 생기는 것도 아닙니다. 이 구분은 블록 탐색기가 표시하는 해석과 합의 상태를 혼동하지 않게 해줍니다.

OP_RETURN은 실행 흐름이 도달하면 실패하는 opcode입니다. 잠금 스크립트가 이 opcode로 시작하는 출력을 사용하려는 거래는 스크립트를 만족할 수 없습니다. 그래서 Bitcoin Core는 해당 스크립트를 쓸 수 없는 것으로 분류합니다. Core의 CScript::IsUnspendable()은 첫 바이트가 OP_RETURN인지 직접 확인하며, 다시는 쓸 수 없는 코인을 UTXO 집합에 보관하는 대신 바로 제외할 수 있습니다.

‘쓸 수 없음’은 그 출력을 설명하는 말이지, 그 출력을 만든 거래가 무효라는 뜻은 아닙니다. 합의 규칙을 만족하는 거래에도 OP_RETURN 출력이 들어갈 수 있습니다. 노드는 거래를 mempool로 중계할지 결정할 때 로컬 정책도 적용합니다. 두 판단은 서로 다른 질문에 답합니다. 합의 검증은 블록과 거래가 유효한지 확인하고, 표준성 정책은 노드가 현재 설정으로 중계하거나 채굴할 의사가 있는지 정합니다. 자세한 구현은 Bitcoin Core 31.1의 script.h와 거래 기본 검사를 참고하세요.

노드가 데이터 캐리어 한도를 적용하더라도, 한도는 애플리케이션 데이터 바이트 수와 같지 않습니다. 원시 출력 스크립트에는 OP_RETURN opcode, push 명령과 길이 인코딩, payload가 모두 들어갑니다. payload가 75바이트를 넘으면 push 인코딩에도 바이트가 추가됩니다. 그래서 과거 정책에서 자주 언급된 payload 80바이트는 스크립트 83바이트와 연결됩니다. OP_RETURN 1바이트, 80바이트를 push하기 위한 OP_PUSHDATA1 헤더 2바이트, payload 80바이트를 합한 값입니다.

이 차이를 알면 오래된 지갑 안내를 해석하기 쉽습니다. ‘80바이트’가 이전 정책 예시의 payload를 뜻할 수 있지만, 최신 Bitcoin Core 설정은 완전한 원시 scriptPubKey의 크기를 설명합니다. 거래에 다른 출력, 입력, witness 데이터가 있으면 payload가 스크립트 한도보다 작아야 할 수도 있습니다. 문서에 적힌 숫자만 믿기보다 직렬화된 스크립트와 전체 거래 크기를 계산하세요.

Bitcoin Core 31.1에서는 -datacarrier가 기본적으로 켜져 있습니다. -datacarriersize의 기본값은 100,000바이트이며, 도움말은 측정 대상을 여러 출력의 크기를 합친 원시 데이터 캐리어 scriptPubKey라고 설명합니다. IsStandardTx()는 NULL_DATA로 분류된 각 출력에서 스크립트 전체 크기를 거래의 남은 한도에서 차감합니다. OP_RETURN 뒤에 있는 데이터만 세지 않습니다. 이 버전별 기본값은 Core init.cpp, policy.h, policy.cpp에 정의되어 있습니다.

이 변경은 Bitcoin Core 30.0에서 이뤄졌습니다. 기본 데이터 캐리어 허용량이 이전의 스크립트 크기 83바이트에서 원시 스크립트 합계 100,000바이트로 커졌고, 표준 거래에서 여러 데이터 출력도 허용됐습니다. Core 31.1도 이 정책을 유지합니다. 운영자는 -datacarriersize=83처럼 작은 값을 지정해 이전에 익숙했던 크기 제한을 적용할 수 있지만, 여러 출력이 허용되는 새로운 정책까지 예전 동작으로 되돌리지는 않습니다. 변경 내역은 릴리스 노트에 나와 있습니다.

버전 번호를 함께 확인해야 하는 이유는 지갑 안내와 검색 결과에 과거 규칙이 계속 남아 있기 때문입니다. “OP_RETURN은 80바이트만 가능하다”는 말은 예전 기본 relay 정책에서 payload에 적용되던 관례를 설명할 수 있지만, 현재 합의 규칙이나 모든 비트코인 노드의 설정을 요약하지는 않습니다. 오래된 수치를 현재 거래에 적용하기 전에 그 값이 payload 바이트인지 원시 출력 스크립트 바이트인지, 어떤 Core 버전을 전제로 하는지, 여러 출력의 합계를 다루는지 살펴보세요. 정책 기본값은 특정 소프트웨어 버전과 로컬 설정에 속하며 네트워크 전체가 공유하는 보장은 아닙니다.

각 노드는 표준 데이터 캐리어 거래를 중계할지, 어느 크기까지 허용할지 선택할 수 있습니다. -datacarrier=0이나 더 낮은 크기 한도로 실행된 노드, 또는 다른 버전의 소프트웨어는 mempool에서 거래를 거부할 수 있습니다. 다른 노드는 같은 거래를 받아들일 수 있습니다. 따라서 거부는 ‘이 노드의 정책이 중계를 허용하지 않는다’는 의미일 수 있으며, ‘비트코인 합의가 금지한다’는 뜻은 아닙니다. 네트워크 전체에 중계가 보장되지는 않습니다.

노드는 블록을 검증할 때 합의 규칙을 확인합니다. Core의 기본 거래 검사는 음수 출력 금액이나 합의 크기 한도 초과처럼 합의 위반을 검사합니다. 정책 전용 IsStandardTx() 검사는 mempool 수락 전에 별도로 데이터 캐리어 허용량을 적용합니다. 채굴자는 비표준 거래라도 거래와 블록이 합의 규칙을 만족하면 블록에 넣을 수 있습니다. 이 경우 전체 노드는 그 거래를 먼저 중계하지 않았더라도 유효한 블록을 받아들일 수 있습니다. 그렇다고 채굴자가 포함하거나 노드가 저장·전달한다고 보장되는 것은 아닙니다. See Bitcoin Core 31.1 mempool standardness implementation.

OP_RETURN 출력에 금액을 넣을 수는 있지만, 유효한 지출로 되찾을 수 없으므로 해당 금액은 영구히 쓸 수 없게 됩니다. 지갑은 보통 데이터 출력 금액을 0으로 둡니다. 1,000 sat을 출력에 지정했다면 그 sat은 소각되며 자동으로 채굴자 수수료에 더해지지 않습니다. 거래 수수료는 입력 금액 합계에서 모든 출력 금액 합계를 뺀 값입니다. 입력 10,000 sat에 출력 전체가 9,000 sat이면, 그 출력들이 지불용 출력과 0원 데이터 출력으로 이뤄졌든, 1,000 sat짜리 쓸 수 없는 출력이 포함되든 수수료는 1,000 sat입니다.

데이터도 거래 공간을 차지하므로 BIP 141의 무게와 가상 크기에 포함됩니다. 출력 금액이 0이어도 스크립트 바이트가 늘면 특정 sat/vB에서 필요한 수수료가 증가할 수 있습니다. 쓸 수 없는 출력에 금액을 배정한 경우에는 수수료와 별도로 그 금액도 잃습니다. 크기와 수수료율의 관계는 비트코인 거래 수수료 안내에서 다룹니다.

예를 들어 입력 합계가 10,000 sat이고 받는 사람에게 8,000 sat을 보내며 OP_RETURN 출력에 1,000 sat을 배정했다고 가정해 보겠습니다. 다른 출력이 없다면 남은 1,000 sat이 거래 수수료이고, 데이터 출력의 1,000 sat은 출력으로 지출됐지만 누구도 회수할 수 없는 금액입니다. 반대로 OP_RETURN 출력의 값이 0이면 8,000 sat을 보낸 뒤 남은 2,000 sat이 수수료가 됩니다. 소각되는 금액과 채굴자에게 주는 수수료가 우연히 같을 수는 있지만, 거래 산식에서는 서로 다른 항목입니다.

Bitcoin Core 31.1은 표준 NULL_DATA 출력을 여러 개 허용하지만, 원시 스크립트 크기는 거래당 허용량을 함께 사용합니다. payload를 여러 출력으로 나눠도 기본 크기 한도가 늘어나는 것은 아닙니다. 출력이 추가되면 거래 데이터가 늘고 블록 무게와 수수료에도 영향을 줄 수 있습니다. 각 출력은 OP_RETURN으로 시작하고 그 자체로 쓸 수 없습니다. 데이터를 여러 조각으로 나눠도 나중에 회수할 수 있는 저장 조각으로 바뀌지 않습니다.

로컬 크기 한도는 수락 조건 중 하나일 뿐입니다. 거래는 표준 거래 무게와 다른 표준성 및 수수료 정책도 만족해야 합니다. 다른 노드나 채굴자는 다른 설정을 쓸 수 있습니다. 지갑 미리보기가 성공하거나 특정 탐색기에서 중계되거나 한 노드의 mempool에 들어갔다는 사실이 같은 데이터가 모든 곳에 전파된다는 보장은 아닙니다.

중계되지 않았다는 화면만 보고 거래가 합의상 무효라고 결론 내리지는 마세요. 가능하면 거부가 어느 단계에서 발생했는지 구분해야 합니다. 지갑이 형식이나 크기를 미리 거부했는지, 노드가 로컬 표준성 검사에서 거부했는지, 블록 검증에서 합의 규칙 위반을 찾았는지는 서로 다른 문제입니다. 반대로 한 노드가 수락해도 채굴자가 거래를 선택할지, 연결된 노드들이 다시 중계할지는 별개입니다. 정책은 전파 가능성을 설명하고 합의는 블록에 포함된 거래의 유효성을 설명합니다.

OP_RETURN 데이터는 거래가 만들어질 때 출력의 scriptPubKey에 들어갑니다. SegWit witness 데이터는 각 입력에 별도로 직렬화됩니다. BIP 141은 입력별 witness 필드가 스택 데이터이고 그 자체가 Script는 아니라고 설명합니다. BIP 341의 Taproot 스크립트 경로 지출에서는 스크립트와 제어 블록이 입력 witness에 공개될 수 있습니다. Ordinals 소프트웨어는 공개된 스크립트 안의 특정 envelope 형식을 인스크립션으로 해석할 수 있지만, 이는 nulldata 출력과 같은 방식이 아닙니다.

실무상 차이도 있습니다. OP_RETURN 출력은 다시 쓸 수 없고 Core가 UTXO 집합에서 제외할 수 있지만, witness 인스크립션은 지출 거래의 입력 witness 데이터에 있습니다. 둘 다 공개 거래 데이터이며 유한한 블록 무게를 사용하지만, 위치와 검증 경로, 애플리케이션 규칙이 다릅니다. sat 번호와 witness 인스크립션을 따로 설명하는 [비트코인 Ordinals와 인스크립션 안내](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained)를 참고하세요.

거래를 만들기 전에 의존하려는 Bitcoin Core 버전과 로컬 설정을 확인하세요. 수신 서비스나 프로토콜이 특정 데이터 형식을 요구하는지도 확인해야 합니다. 합의 규칙은 임의의 payload 바이트에 의미를 부여하지 않습니다. 직렬화된 출력 스크립트 크기, 전체 거래 무게, 쓸 수 없는 출력에 배정한 금액, 채굴자 수수료를 각각 계산하세요. 넓은 중계 범위가 중요하다면 노드와 채굴자가 서로 다른 정책을 사용할 수 있다는 점을 고려해야 합니다.

블록체인에 기록하는 데이터는 공개되며, 보관 노드에는 오래 남을 수 있다고 간주하세요. 일부 노드는 검증 후 오래된 블록 파일을 프루닝하지만, 이는 로컬 저장 공간을 바꾸는 것이지 거래의 체인 이력을 지우는 것은 아닙니다. OP_RETURN은 비공개 메모, 복구 가능한 파일 시스템, 지갑 백업의 대안이 아닙니다. 거래 출력과 거스름돈의 가치 구조는 비트코인 UTXO와 코인 컨트롤 안내에서, 다른 거래 영역에 담기는 witness 인스크립션은 앞의 Ordinals 안내에서 확인하세요.

작은 커밋먼트만 기록하려는 경우에도 먼저 공개 범위를 생각하세요. 해시나 식별자 자체가 문서 내용을 바로 보여주지 않더라도 나중에 원본 후보가 공개되면 누구나 값을 대조할 수 있고, 거래 시점과 입력·출력의 연결도 관찰할 수 있습니다. 외부 저장소의 원본 파일을 잃으면 온체인 데이터만으로 파일을 복원할 수는 없습니다. 반대로 원본을 계속 공개해 두면 해시 대조가 가능할 수 있습니다. 데이터가 필요하지 않다면 출력을 만들지 않는 편이 스크립트 바이트, 거래 무게, 비용, 공개 흔적을 모두 줄입니다.