비트코인 UTXO와 SegWit: 스크립트 검증부터 수수료 최적화까지

잔고 대신 UTXO 집합을 검증하는 구조

비트코인에서 개별 트랜잭션 출력은 독립적으로 소유할 수 있는 코인 단위다. 아직 사용되지 않은 출력만 UTXO(Unspent Transaction Output)로 남으며, 새 트랜잭션의 입력은 이전 트랜잭션에 있던 UTXO를 참조한다. 따라서 잔액은 계정 필드가 아니라 보유한 UTXO 집합의 합으로 계산된다.

입력을 처리할 때 노드는 참조 대상 UTXO가 존재하는지, 이미 소비되지 않았는지, 금액 합산이 맞는지를 확인한다. 검증이 통과하면 해당 입력은 소비되고 새로운 출력이 UTXO 세트에 추가된다. 블록에 포함되는 시점에는 이 갱신이 원자적으로 처리된다.

소유권 검증에는 스택 기반이며 튜링 불완전하고 결정적으로 실행되는 Bitcoin Script가 쓰인다. 잠금 조건은 ScriptPubKey에, 이를 해제하는 데이터는 Legacy 형식에서는 ScriptSig에, SegWit 형식에서는 Witness에 담긴다. 표준 스크립트 유형은 주소 형식과 지불 정책을 표현하는 기준이기도 하다.

트랜잭션이 멤풀과 블록으로 이어지는 과정

⤢✕

UTXO가 없거나 이중 지불이 감지되거나 스크립트 실행이 실패하면 트랜잭션은 즉시 거절된다. 수수료가 부족한 경우에는 RBF(Replace-By-Fee) 또는 CPFP(Child-Pays-For-Parent)를 이용해 수수료를 조정할 수 있다. 블록에 포함될 때는 트랜잭션 단위의 원자성이 보장된다.

서명 범위는 SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, ANYONECANPAY로 제어한다. SegWit에서는 분리된 Witness 필드를 사용해 서명 범위를 계산하며, 이 과정이 트랜잭션 가변성 문제를 완화한다. 서명 검증에 실패하면 트랜잭션 전체가 거절된다.

주소 형식에 따른 선택지

구분	Legacy P2PKH	P2SH-P2WPKH (호환 세그윗)	P2WPKH (네이티브)
성능(수수료/크기)	불리	중간	유리
확장성(블록 효율)	낮음	중간	높음
일관성(가변성 이슈)	존재	완화	해소
안정성(정책/표준성)	높음	높음	높음
운영 편의(호환성)	최고	높음	일부 구형 호환성 이슈

Legacy P2PKH는 ScriptSig에 서명과 공개키를 담고, ScriptPubKey가 해시 기반의 소유권 조건을 선언한다. P2SH-P2WPKH와 P2SH-P2WSH는 세그윗으로 옮겨가는 과정에서 호환성을 제공한다. P2WPKH와 P2WSH 같은 네이티브 세그윗 형식은 Witness에 해제 데이터를 두고 ScriptSig를 최소화한다.

신규 지갑이나 서비스는 bech32 기반 P2WPKH를 우선할 수 있다. 레거시 결제망과의 상호운용이 필요하다면 P2SH 래핑 방식을 보조로 제공하는 구성이 가능하다.

가중치가 수수료를 바꾸는 방식

SegWit은 서명 관련 증명 데이터를 트랜잭션 본문에서 분리한다. 그 결과 가변성 이슈를 완화하고, 가중치 기반 수수료 산정과 블록 수용량 증가를 함께 다룬다.

가중치는 Weight = base_size*4 + witness_size로 계산하며, vsize = ceil(weight/4), 수수료는 feerate(sat/vB) × vsize로 산정한다.

Witness가 분리되면 같은 기능을 수행하는 트랜잭션도 더 작은 vsize를 달성할 수 있다. Legacy 대비 P2WPKH 사용 시 vsize는 약 25~~40% 감소하며, 멀티시그에 P2WSH를 적용하면 시나리오에 따라 절감 폭이 30~~60%까지 확대된다.

블록 가중치 도입은 트랜잭션 믹스에 따라 실효 처리량을 약 1.2~1.8배 개선한다. 혼잡한 구간에서는 동일 수수료로 더 높은 포함 확률을 확보할 수 있다.

지갑과 채널을 운영할 때의 판단

낮은 네트워크 혼잡 구간에는 소액 UTXO를 병합(consolidation)할 수 있다. 코인 셀렉션은 가중치와 입력 수를 함께 고려해야 하며, Branch and Bound나 Knapsack 변형을 적용할 수 있다.

키 관리가 필요한 경우 P2WSH 기반 2-of-3 멀티시그를 사용해 키를 분산하고 사고 대응력을 높일 수 있다. 하드웨어 지갑과 PSBT(Partially Signed Bitcoin Transaction) 표준을 조합하면 서명 과정을 분리해 운영할 수 있다.

라이트닝 채널의 오픈·클로즈 트랜잭션에도 세그윗을 적용할 수 있다. 온체인 수수료가 급등하는 구간에는 CPFP로 컨펌 시간의 안정화를 시도한다.

멤풀에서는 이중 지불 경쟁이 생길 수 있고, 정책에 따라 우선순위가 적용된다. 컨펌 전 자금 가시성은 잠정 상태로 다뤄야 한다. 스크립트 실행 실패는 재시도할 수 없으므로 새 트랜잭션을 작성해야 하며, 수수료 부족은 RBF 플래그 설정을 전제로 수수료를 올려 브로드캐스트하거나 CPFP로 보완한다.

Bitcoin Core에서 P2WPKH 트랜잭션 만들기

Bitcoin Core v24 이상과 로컬 regtest 모드, bitcoind 및 bitcoin-cli 사용을 가정한다. 새 데이터 디렉터리를 사용하는 편이 좋다.

노드를 시작한다.

bitcoind -regtest -daemon

지갑을 만들고 채굴 자금을 확보한다.

bitcoin-cli -regtest createwallet w1
A=$(bitcoin-cli -regtest -rpcwallet=w1 getnewaddress "" bech32)
bitcoin-cli -regtest generatetoaddress 101 "$A"

수신에 사용할 세그윗 주소를 생성한다.

R=$(bitcoin-cli -regtest -rpcwallet=w1 getnewaddress recv bech32)

PSBT를 만들고, 자금을 할당한 뒤 서명과 브로드캐스트를 진행한다.

PSBT=$(bitcoin-cli -regtest -rpcwallet=w1 walletcreatefundedpsbt '[]' '[{"'"$R"'":0.5}]' 0 '{"subtractFeeFromOutputs":[0]}' true)
PSBT_SIGNED=$(bitcoin-cli -regtest -rpcwallet=w1 walletprocesspsbt "$(echo $PSBT | jq -r .psbt)" | jq -r .psbt)
RAW=$(bitcoin-cli -regtest finalizepsbt "$PSBT_SIGNED" | jq -r .hex)
TXID=$(bitcoin-cli -regtest sendrawtransaction "$RAW"); echo $TXID

결과를 확인한다.

bitcoin-cli -regtest gettransaction "$TXID"
bitcoin-cli -regtest decoderawtransaction "$RAW"

walletcreatefundedpsbt는 UTXO 선택, 수수료 산정, 거스름돈 생성을 자동화한다. bech32 주소를 지정하면 P2WPKH 출력이 만들어지고, Witness 데이터는 서명 과정에서 PSBT에 포함된다. decoderawtransaction 결과에서는 vsize와 weight를 확인할 수 있다.

jq가 필요하면 사전에 설치해야 한다. 외부 네트워크를 쓸 경우에는 -paytxfee 또는 conf estimator를 통해 수수료율 설정을 바꿔야 한다.

비용 절감과 운영 복잡도 사이

네이티브 세그윗을 기본으로 두고, 입력 수를 줄이며, 배치 결제(batch payout)를 적용하는 방식이 일반적인 운영 선택지다. 주소 재사용을 피하면 프라이버시와 분석 저항성을 높일 수 있다. PSBT 표준을 따르고 HSM 또는 하드웨어 지갑을 연계하는 구성도 고려할 수 있다.

반면 UTXO 세트가 커지면 데이터베이스 부담이 늘어날 수 있다. UTXO를 병합하면 수수료 최적화에는 유리하지만 링크성이 증가해 프라이버시와 충돌한다. 멀티시그와 스마트 스크립트는 운영 복잡도를 높이므로 키 관리와 백업 체계를 강화해야 한다.

UTXO는 단순하면서 병렬 처리에 친화적인 상태 머신으로, 검증과 확장성에 유리하다. Bitcoin Script는 소유권과 지불 정책을 최소 충분한 표준으로 표현하며, SegWit은 가변성 완화와 수수료·확장성 개선을 함께 제공한다. 신규 시스템에서는 네이티브 세그윗, PSBT 기반 서명 분리, UTXO 라이프사이클 관리 자동화를 조합해 안정적인 운영을 설계할 수 있다.