UTXO 체인 개발 방법: Bitcoin, Litecoin, Dogecoin, Bitcoin Cash
작성자: Uttam Singh
Bitcoin에는 계정 잔액이라는 개념이 없습니다. 예전에도 없었습니다. Litecoin, Dogecoin, Bitcoin Cash도 마찬가지입니다. 이 네 체인은 2009년에 설계된 UTXO 모델을 공유하는데, 이는 모든 Ethereum과 Solana 개발자가 당연하게 여기는 "주소당 한 행" 상태 머신을 대체하는 방식입니다. 이 모델은 프로토콜 계층에서는 잘 작동합니다. 문제는 애플리케이션 계층에서 발생하는데, 여기서는 앱에 필요한 기본적인 쿼리조차 존재하지 않거나 외부 인덱서가 재조립해야 합니다.
그래서 UTXO 체인에서 서비스를 운영하는 팀들은 수년간 인프라를 이어붙여 왔습니다. RPC는 한 제공자, 인덱싱된 읽기는 다른 제공자, 웹훅은 또 다른 제공자, 그리고 빈틈은 커스텀 코드로 메우는 식입니다. 저희의 UTXO 번들은 이를 네 체인 전체에 걸쳐 단일 플랫폼으로 통합하며, EVM과 Solana에서 사용하는 것과 동일한 대시보드, API 키, 계량 체계를 그대로 사용합니다.
UTXO 체인은 무엇이 다른가?
UTXO는 "unspent transaction output(미사용 트랜잭션 출력)"의 약자입니다. 모든 Bitcoin 트랜잭션은 하나 이상의 출력을 입력으로 소비하고 새로운 출력을 생성합니다. 지갑의 "잔액"은 체인 어디에도 저장되어 있지 않습니다. 이는 지갑이 통제하면서 아직 사용되지 않은 모든 출력을 합산하여 계산됩니다. Bitcoin 개발자 가이드는 이를 명확히 설명합니다. "Bitcoin 지갑이 10,000 사토시의 잔액이 있다고 알려줄 때, 이는 실제로 하나 이상의 UTXO에 10,000 사토시가 대기하고 있다는 의미입니다."
구체적인 예를 들어보겠습니다. Alice는 0.4 BTC, 0.3 BTC, 0.2 BTC 세 개의 UTXO를 보유하고 있습니다. Alice가 Bob에게 0.5 BTC를 보냅니다. 이 트랜잭션은 0.4 BTC와 0.3 BTC 출력을 전부 소비하고, Bob에게 보낼 0.5 BTC 출력을 생성하며, Alice가 통제하는 새 주소로 약 0.1999 BTC의 잔돈을 반환하고, 약 0.0001 BTC를 채굴자 수수료로 남깁니다. 0.2 BTC UTXO는 그대로 남습니다. UTXO는 원자적입니다. 하나를 부분적으로 사용할 수는 없습니다.
계정 기반 체인과의 대조는 뚜렷합니다:
Litecoin, Dogecoin, Bitcoin Cash 모두 이 모델을 그대로 물려받았습니다. 이들은 Bitcoin의 코드베이스를 포크하고 블록 시간과 몇 가지 파라미터를 조정한 뒤 출시했습니다. 네 체인 모두 동일한 사고 모델과 동일한 종류의 인프라를 필요로 합니다.
개발자들이 왜 신경 쓰는가?
이 차이는 철학적인 것이 아닙니다. 대부분의 팀이 작업량을 과소평가하는 구체적인 지점들에서 드러납니다.
노드에 주소의 잔액을 물어볼 수 없다
Bitcoin Core는 블록과 트랜잭션을 저장합니다. 주소에서 트랜잭션으로의 인덱스는 유지하지 않습니다. Core 개발자들은 이를 추가하는 데 명시적으로 반대해 왔는데, 한 메인테이너의 말을 빌리면 "주소 인덱스는 블록체인 크기에 비례해 선형으로 커지기 때문에 본질적으로 확장이 불가능하다"는 이유에서입니다. 이들의 입장은 주소 인덱싱이 외부 서비스의 영역이라는 것입니다. 그래서 잔액을 표시하거나, 사용자의 트랜잭션 목록을 보여주거나, 들어오는 결제를 감시해야 하는 모든 Bitcoin 앱은 인덱서 위에 올라가 있습니다. 인덱서란 체인을 감시하며 주소, 트랜잭션, UTXO를 조회 가능한 데이터베이스로 유지하는 서비스입니다. 남는 문제는 누가 그것을 운영하느냐입니다. 대부분의 팀은 직접 인프라를 구축하는 대신 호스팅형 블록체인 노드 제공자를 사용합니다.
지갑은 주소 하나가 아니라 수천 개를 갖는다
주소를 재사용하면 모든 입력과 출력이 하나의 신원 아래로 연결됩니다. 그래서 관례는 BIP 32에 정의된 계층적 결정성(HD) 키를 통해 하나의 시드로부터 수신할 때마다 새 주소를 파생시키는 것입니다. 하나의 기업용 xpub(확장 공개 키로, 이를 사용하는 개인 키를 노출하지 않고도 단일 루트로부터 수신 주소 트리 전체를 파생할 수 있음)을 보유한 거래소는 모든 고객에게 매번 새로 파생된 입금 주소를 보여줄 수 있습니다. 자체 수탁 지갑은 12단어 시드로부터 자신이 통제하는 모든 UTXO를 다시 계산할 수 있습니다. 문제는, 인덱서가 주소를 순차적으로 파생시키고 이를 전부 감시해야 하며, BIP 44의 20개 주소 갭 제한이 언제 멈출지를 결정한다는 점입니다. 20개 주소를 건너뛰면 인덱서는 끝났다고 판단하는데, 이는 "내 자금이 어디로 갔나"라는 문의 티켓이 실제로 발생하는 원인입니다.
수수료는 가치가 아니라 크기로 지불된다
단위는 satoshi per virtual byte입니다. 100개의 작은 UTXO를 하나의 출력으로 통합하는 지갑은 이동되는 가치와 무관하게 이 100개 입력에 비례하는 수수료를 지불합니다. 추정치는 멤풀 상태에 좌우되며 분 단위로 변동합니다. 막힌 트랜잭션은 replace-by-fee (BIP 125)나 child-pays-for-parent로 처리를 앞당길 수 있습니다. 이 중 개념적으로 어려운 것은 없지만, 전부 직접 작성하지 않으면 안 되는 실제 프로덕션 코드입니다.
파이널리티는 확률적이다
Bitcoin 블록은 경쟁하는 블록에 의해 체인에서 재구성(reorg)될 수 있습니다. 이런 일이 일어나면, 밀려난 블록에 있던 모든 트랜잭션은 다시 멤풀로 돌아갑니다. "사용된" 출력이 다시 미사용 상태가 됩니다. 인덱서는 이를 깔끔하게 되돌려야 하며, 그렇지 않으면 앱에 잘못된 잔액을 전달하게 됩니다. 앱은 확인 수(confirmation) 임계값으로 스스로를 보호합니다. 소액 결제는 1 확인, 역사적으로 표준은 6 확인, 대규모 거래소 입금은 30 확인 이상입니다. Litecoin과 Dogecoin은 블록 시간이 더 짧아서(LTC는 2.5분, DOGE는 1분) 동일한 확인 수로 얻는 실제 시간 기준 보안성은 더 낮습니다.
주소 형식이 계속 바뀐다
Bitcoin은 이전 형식을 폐기하지 않은 채 세 차례 주소 형식 업그레이드를 해왔습니다. 2012년 P2SH, 2017년 SegWit, 2021년 Taproot입니다. 오늘날 네트워크에는 네 가지 형식이 공존합니다: 레거시 P2PKH(1...), 네스티드 SegWit P2SH(3...), 네이티브 SegWit P2WPKH(bc1q...), Taproot P2TR(bc1p...). 1입력 2출력 P2WPKH 트랜잭션은 약 141 virtual bytes인 반면, 동등한 P2PKH 트랜잭션은 약 226 vB이므로 형식 선택은 직접적으로 수수료에 영향을 미칩니다. 프로덕션 지갑과 익스플로러는 네 가지 형식을 모두 지원해야 합니다.
Bitcoin 위에서 무언가를 구축하는 모든 팀은 첫 분기의 상당 부분을 이 목록에 소비합니다. 대부분은 실제로 그들이 만들고 있는 제품과는 아무 관련이 없습니다.
Alchemy는 UTXO 체인을 어떻게 지원하는가?
저희는 Bitcoin, Litecoin, Dogecoin, Bitcoin Cash를 Ethereum, Solana, 그리고 나머지 체인 디렉토리와 동일한 플랫폼에서 지원합니다. API 키도 같고, 대시보드도 같고, 계량 모델도 같고, 웹훅도 같습니다. 모든 기능은 모든 티어에서 제공됩니다.
출시 시점에 제공되는 것:
-txindex=1로 실행되는 풀 노드에 대한 원시 JSON-RPC 패스스루로, 모든 표준 Bitcoin Core 메서드(getblock,getrawtransaction,estimatesmartfee,sendrawtransaction등)를 지원합니다.- 주소 잔액, UTXO 조회, 페이지네이션된 트랜잭션 히스토리, 보강된 트랜잭션 상세정보, 사용 여부 등을 위한 인덱싱된 REST API. Bitcoin Core가 기본적으로 답할 수 없는 쿼리들을 밀리초 단위로 답합니다.
- 네 체인 모두에 대한 xpub 및 디스크립터 추적. 출력 디스크립터는 키로부터 주소를 파생하는 방법을 명시하며, 저희가 BIP 44, 49, 84, 86 트리와 표준 20개 주소 갭 제한에 걸친 파생을 처리합니다. 잔액, UTXO, 히스토리 쿼리는 제출한 첫 번째 주소만이 아니라 파생된 전체 주소 집합에 대해 실행됩니다.
- 확인된 트랜잭션, 주소 활동, 새 블록, reorg 알림을 위한 WebSocket 구독, 스트림별로 설정 가능한 확인 수 임계값을 제공합니다.
- 원시 브로드캐스트를 넘어서는 트랜잭션 연산: 빠름/보통/느림으로 단계화된 수수료 추정(멤풀 인지), 미서명 트랜잭션 구성, 컴파일, 검증, 브로드캐스트.
- Blockbook 방식
bb_*(QuickNode 형식)와 Blockdaemon 방식bd_*메서드 시그니처를 위한 호환성 래퍼로, 기존 통합은 HTTP 호출 변경만으로 마이그레이션할 수 있습니다.
코드로 보면 다음과 같습니다. 노드가 지원하는 모든 것에 대한 원시 JSON-RPC:
curl -X POST https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "1.0",
"id": "1",
"method": "estimatesmartfee",
"params": [6]
}'Bitcoin Core가 기본적으로 답할 수 없는 쿼리를 위한 REST:
# Address balance, tx history, and UTXOs
curl https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY/addresses/bc1q.../balance
# Watch an entire xpub or descriptor (no gap-limit logic to maintain)
curl https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY/accounts/zpub.../utxos실시간 업데이트를 위한 지속적 연결:
const ws = new WebSocket("wss://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY");
ws.send(JSON.stringify({
method: "subscribeAddressActivity",
params: { address: "bc1q...", confirmations: 6 },
}));모든 엔드포인트와 마이그레이션 래퍼 메서드 목록을 포함한 전체 레퍼런스는 저희 Bitcoin API 퀵스타트와 Bitcoin JSON-RPC 레퍼런스에 있습니다. UTXO 상태가 계정 상태와 어떻게 다른지 더 깊이 알고 싶다면, UTXO vs. 계정 모델 문서에서 프로토콜 계층의 메커니즘을 다룹니다.
기존 방식과 무엇이 다른가?
오늘날 Bitcoin 위에서 서비스를 제공하고 있다면, 아마 아래 세 제공자 중 하나를 사용하고 있을 것이며, 각각은 빈틈을 남깁니다:
빌더 입장에서 달라지는 것은 세 가지입니다.
벤더 하나, 통합 하나, 청구서 하나
이미 Ethereum, Base, Polygon, Solana에서 Alchemy를 사용하고 있다면, Bitcoin을 추가하는 것은 별도의 구매 프로세스가 아닙니다. 그냥 켜는 체인입니다. API 키도 동일하고, 계량 방식도 동일하고, 웹훅 전달 모델도 동일하고, 대시보드도 동일합니다. UTXO 체인에서 수년간 표준이었던 다중 벤더 구성이 단일 통합으로 축소됩니다.
네 체인 모두, 기능 세트는 하나
기존 제공자들은 각기 이 체인들과 기능들의 일부 조합만 다루며, 커버리지가 고르지 않습니다. QuickNode는 BTC, LTC, BCH에서 Blockbook 인덱싱 읽기와 xpub 추적을 제공하지만, Dogecoin Blockbook은 별도의 유료 애드온입니다. Blockcypher는 wallets/hd을 통해 BTC, LTC, DOGE에서 HD Wallets를 제공합니다. Blockdaemon의 Wallet Transact API는 네 체인 모두에서 트랜잭션 구성을 다룹니다. 팀들은 결국 필요한 특정 기능-체인 조합을 지원하는 제공자를 각 사용 사례마다 맞춰가며 찾아야 하고, 나머지는 커스텀 코드로 이어붙여야 합니다. 저희는 Bitcoin, Litecoin, Dogecoin, Bitcoin Cash 전체에 걸쳐 xpub 추적, 인덱싱된 읽기, 트랜잭션 연산, WebSocket 구독을 하나의 번들로 제공하며, 체인별 애드온이나 기능 분리가 없습니다.
마이그레이션은 재설계가 아니라 HTTP 호출 변경일 뿐
Blockbook 방식 bb_* 메서드(QuickNode 형식)와 Blockdaemon 방식 bd_* 메서드에 대한 호환성 래퍼는 기존 통합이 요청 형식을 그대로 유지한다는 뜻입니다. 호스트만 바꾸면 되고, 호출부를 다시 작성할 필요는 없습니다. Blockcypher의 레거시 REST 인터페이스를 사용하는 팀의 경우 요청 형식 자체는 달라지지만(저희는 다른 형태의 REST GET을 사용합니다), 기저의 데이터 모델은 동일합니다. 저희는 출시 시점에 Blockcypher, QuickNode Blockbook, Blockdaemon 각각의 섹션을 담은 통합 UTXO 마이그레이션 가이드를 제공합니다.
개발자 입장의 이점을 한 줄로 요약하면: 이어붙여야 할 인프라가 줄고, 관리해야 할 제공자가 줄고, "Bitcoin 지원이 필요하다"에서 실제 출시까지 가는 길이 빨라집니다.
Alchemy로 Bitcoin 위에 구축하기
Bitcoin, Litecoin, Dogecoin, Bitcoin Cash는 Ethereum, Solana, 그리고 100개 이상의 다른 체인들과 함께 Alchemy에서 이미 지원되고 있습니다. PAYG 개발자는 첫날부터 대시보드에서 체인을 추가할 수 있습니다. 계약도, 대기자 명단도, 최소 약정도 없습니다. 엔터프라이즈 고객은 기존 컴퓨트 유닛 할당량 내에서 UTXO 체인을 사용할 수 있습니다. 전체 기능 상세는 Bitcoin 지원 출시 발표에서 확인하세요.
Alchemy 대시보드에서 엔드포인트를 만들고 바로 쿼리를 시작하거나, 엔터프라이즈 통합 지원 및 맞춤 가격 문의는 영업팀에 문의하세요.
Alchemy 뉴스레터
출시 소식을 가장 먼저 받아보세요
뉴스레터 구독하기
Alchemy의 최신 제품 업데이트와 리소스 받기
이메일 주소를 입력하면 마케팅 커뮤니케이션 및 제품 업데이트 수신에 동의하게 됩니다. Alchemy는 저희 개인정보 처리방침에 따라 수집한 정보를 처리합니다. 언제든지 구독을 취소할 수 있습니다.
관련 아티클
Glamsterdam: Ethereum 개발자를 위한 완전 가이드
Glamsterdam이 Sepolia에서 가동 중입니다. 개발자에게 무엇을 의미하는지, 그리고 Alchemy가 네트워크 업그레이드에 어떻게 준비했는지를 담은 완전 가이드입니다.
트레이딩 팀이 저지연 RPC로 Alchemy를 선택하는 이유
트레이딩 팀이 Alchemy를 선택하는 이유는, 시장이 움직일 때의 저지연 읽기와 쓰기, 그리고 거래량이 정점에 달해도 자금이 정산될 때의 신뢰할 수 있는 기록 때문이다.
도쿄에서 구축한다면 어떤 RPC 제공업체를 선택해야 할까
도쿄를 서비스하는 RPC 제공업체 다섯 곳을 다섯 개 체인에서 벤치마크했습니다. 비교 결과와, 지연 시간에 민감한 팀에게 차이가 어디서 나는지 정리합니다.