비트코인 체인 재구성과 누적 작업량: 확인 수의 의미

채굴자는 자신이 알고 있는 체인 팁을 기준으로 다음 블록을 찾습니다. 서로 다른 채굴자가 비슷한 시각에 같은 부모 블록을 가리키는 유효한 블록을 만들면 각 노드는 먼저 전달받은 가지를 임시로 따라갈 수 있습니다. 그래서 두 블록이 같은 높이에 있고도 서로 다른 해시와 거래를 포함할 수 있습니다. 이런 짧은 차이는 각 블록이 잘못됐다는 뜻은 아닙니다.

블록 높이는 제네시스 블록 다음 순서에서의 위치이지 블록을 고유하게 식별하는 값이 아닙니다. 같은 높이의 경쟁 블록은 서로 다른 헤더 해시를 가집니다. 비트코인 개발자 블록체인 안내서는 동시에 만들어진 블록, 포크, 오래된 가지를 설명합니다. 짧은 포크는 블록 전파 지연 때문에 생길 수 있으며, 네트워크가 영구 분할됐다는 증거로 보아서는 안 됩니다. 두 가지의 누적 작업량이 아직 같을 때 노드는 먼저 전달받은 블록을 활성 팁으로 잠시 유지할 수 있습니다. 채굴자도 자신이 보고 있는 팁을 기준으로 다음 블록을 만들기 때문에, 이후 한쪽 가지에 유효한 블록이 더해지면 노드들의 선택이 정리됩니다. 이 과정은 각 노드가 동일한 블록을 같은 순간에 받지 않는다는 뜻이지, 어느 한쪽이 규칙을 무시한다는 뜻은 아닙니다. 서비스가 서로 다른 블록 해시를 표시한다면 높이 숫자만으로 오류라고 판단하지 말고 어느 블록을 가리키는지 확인해야 합니다.

후보 블록은 작업 증명 목표를 만족하고 적용되는 합의 규칙을 모두 통과해야 합니다. 유효한 블록마다 그 목표값에 따른 작업량이 더해집니다. 체인의 누적 작업량은 각 블록의 작업을 합친 값이므로, 블록의 난이도 목표가 다른 가지를 단순히 블록 개수로만 비교하면 잘못된 결론을 낼 수 있습니다. 작업량은 블록에 들어 있는 거래 개수를 세거나 채굴자의 실제 전력 사용량을 계량하는 값이 아닙니다. 해당 블록의 목표 난이도에서 예상되는 해시 작업을 반영하는 합의상의 수치입니다. 같은 높이여도 난이도 조정 시점이나 블록이 쌓인 경로가 다르면 작업량이 달라질 수 있습니다. 반대로 블록 수가 더 많은 가지가 반드시 더 강한 것도 아닙니다. 그래서 지갑이나 탐색기의 높이만 비교하는 방법으로는 경쟁 체인 중 어느 쪽을 노드가 택할지 알 수 없습니다.

두 가지가 같은 부모에서 갈라져 같은 높이까지 왔더라도 누적 작업량은 같지 않을 수 있습니다. 한 가지에 유효한 작업이 더 쌓여 가장 강한 후보가 되면 노드가 그 가지로 전환할 수 있습니다. Bitcoin Core의 getblockchaininfo는 현재 활성 체인의 총 작업량을 chainwork로 제공합니다. 높이 번호만 보지 말고 블록 해시와 작업량 맥락을 함께 비교해야 합니다. 같은 높이에 있는 두 블록은 같은 블록이 아니므로 거래가 포함된 정확한 블록 해시가 필요합니다. 또한 두 노드의 값을 비교할 때는 같은 네트워크의 상태인지, 두 노드 모두 충분히 동기화됐는지 확인해야 합니다. 뒤처진 노드의 높이가 낮다는 사실만으로 합의 규칙이 달라졌다고 결론 내릴 수는 없으며, 현재 어떤 가지를 검증하고 있는지와 해당 노드가 알고 있는 경쟁 팁을 함께 살펴야 합니다.

작업 증명은 잘못된 블록을 유효하게 만들지 않습니다. 전체 노드는 후보 블록을 자신의 합의 규칙으로 확인하고 통과한 가지의 작업량을 비교합니다. 뒤에 해시가 더 많이 붙었다는 이유만으로 잘못된 거래, 유효하지 않은 서명, 과도하게 생성된 코인이 해당 노드에서 유효해지지는 않습니다.

“가장 많은 작업이 있는 체인”이라는 표현은 노드가 얻은 정보 범위에도 한정됩니다. 노드는 피어에게서 헤더와 블록을 받아 서로 다른 가지를 알게 되므로 네트워크 지연 동안 서로 다른 상태를 보일 수 있습니다. 연결이 끊겼거나 동기화되지 않았거나 오래된 합의 소프트웨어를 쓰는 노드는 최신 노드가 아는 유효한 가지를 모를 수 있습니다. 비트코인 P2P 네트워크 안내서는 피어가 블록을 알리고 전달하는 방식을 설명합니다. 노드의 검증과 네트워크에서 정보를 얻는 일은 별개의 문제입니다.

더 강한 유효한 가지를 알게 되면 노드는 두 가지가 갈라진 공통 조상을 찾습니다. 그 조상 뒤에 있던 활성 체인의 블록을 연결 해제한 다음 선택된 가지의 블록을 검증하고 연결합니다. 한 블록 재구성은 팁 하나를 바꾸고, 더 깊은 재구성은 더 긴 블록 묶음을 교체합니다. 작업량이 선택 기준이므로 새 가지 높이가 이전과 같을 수도, 다를 수도 있습니다.

이는 해당 노드가 보는 활성 체인의 변화입니다. 지갑, 탐색기, 결제처, 모든 노드가 한순간에 동시에 바뀐다는 뜻은 아닙니다. 전파 중에는 한 서비스가 새 팁을 표시하고 다른 서비스는 이전 가지를 보여줄 수 있습니다. 선택되지 않은 가지의 블록은 활성 체인에서 오래된 블록이 되지만, 조사 목적으로 노드의 로컬 저장소에 블록 데이터가 남아 있을 수도 있습니다. 재구성은 거래소 계정의 입금 기록을 자동으로 취소하거나 모든 지갑의 화면을 한꺼번에 바꾸는 절차가 아닙니다. 합의에 따라 연결된 블록과 UTXO 상태가 그 노드에서 바뀌고, 각 지갑과 서비스는 새 블록을 확인한 뒤 자체 상태를 갱신합니다. 따라서 온체인 포함 상태와 수신처의 회계상 반영은 별도로 확인해야 합니다. 로컬 데이터가 남아 있더라도 그 블록이 현재 활성 체인에 속한다는 의미는 아닙니다.

공통 조상 뒤에서 두 유효한 가지가 갈라졌다고 가정해 봅시다. 먼저 보인 가지의 블록에 입금 거래가 들어 있고, 다른 가지에는 별도의 유효한 블록이 이어집니다. 나중에 다른 가지의 누적 작업량이 커지면 이를 검증한 노드는 기존 블록을 연결 해제하고 새 가지를 연결합니다. 이때 입금은 해당 노드의 활성 체인에서 블록 확인을 잃으며, 표시 높이가 같더라도 블록 해시는 달라집니다. 선택된 가지에서 입력이 이미 다른 거래에 사용됐는지에 따라 원래 입금의 유효성이 달라지고, 유효하더라도 멤풀에 자동으로 돌아오거나 다시 채굴된다고 단정할 수 없습니다. 서비스마다 새 체인을 확인하는 시점이 달라 잠시 다른 결과가 보일 수 있으므로 거래 ID, 이전 포함 블록 해시, 노드가 보는 현재 활성 체인을 함께 대조하세요.

블록이 연결 해제되면 그 안에 들어 있던 거래는 해당 노드의 활성 체인에서 그 블록이 주던 확인을 잃습니다. 거래가 여전히 유효하고, 선택된 가지의 거래와 충돌하지 않으며, 노드의 릴레이·멤풀 정책을 충족하면 해당 노드의 멤풀에 다시 들어갈 수 있습니다. 멤풀은 노드마다 다른 로컬 목록이며 거래가 다시 채굴된다는 보장은 아닙니다. Bitcoin Core의 처리 흐름에서는 기존 활성 가지를 팁부터 되돌리며 연결 해제된 블록의 거래를 멤풀 후보로 다시 살펴본 뒤, 새 가지의 블록을 공통 조상부터 연결하면서 그 블록에 포함된 거래를 멤풀에서 제거합니다. 이는 해당 구현이 새 체인 상태에 맞춰 로컬 후보 목록을 정리하는 과정입니다. 충돌 거래가 새 가지에서 이미 입력을 사용했거나 거래가 그 노드의 정책을 충족하지 못하면 원래 거래는 돌아오지 않을 수 있습니다. 다른 노드의 멤풀에 같은 거래가 있는지도 보장할 수 없으므로 멤풀 조회 결과를 네트워크 전체의 거래 상태로 해석해서는 안 됩니다.

선택된 가지에 같은 입력을 사용하는 충돌 거래가 있으면 기존 거래는 현재 UTXO 상태에서 유효하지 않을 수 있습니다. 다른 경우에는 나중에 다시 채굴되거나 미확인 상태로 남거나 특정 노드의 멤풀에서 사라질 수 있습니다. 따라서 지갑과 서비스는 이전 알림을 영구 상태로 간주하지 말고 재구성 후 거래의 블록 연결과 확인 수를 갱신해야 합니다. Bitcoin Core의 getchaintips는 해당 노드가 아는 활성 팁과 경쟁 팁을 보여주지만, 그 노드의 블록 트리만 보고합니다.

활성 블록에 포함된 거래는 보통 포함 블록을 확인 1회로 셉니다. 이후 블록이 더해질 때마다 확인 수가 하나 늘어납니다. 이 수는 거래 블록 위에 활성 체인의 블록이 몇 개 쌓였는지 편리하게 나타냅니다. 난이도 목표가 다른 블록의 작업량까지 일정한 숫자로 환산해 보장하는 값도 아니며, 앞으로 재구성이 불가능하다는 선언도 아닙니다. 예를 들어 거래가 들어 있는 블록과 그 뒤의 블록 두 개가 활성 체인에 있으면 흔히 확인 3회로 셉니다. 그 포함 블록이 재구성으로 빠지고 거래가 새 가지에 들어 있지 않다면, 해당 노드에서는 이전 세 번의 확인을 그대로 이어 세지 않습니다. 거래가 새 가지의 블록에 다시 포함됐다면 새 포함 블록을 기준으로 확인 수를 다시 계산합니다. 실제 서비스는 이와 별도로 필요한 확인 수를 정할 수 있으므로, 사용자가 보는 숫자가 프로토콜의 블록 수인지 서비스 내부의 처리 단계인지 구분해야 합니다.

거래가 포함된 뒤 누적 작업량이 늘어나면 그 블록을 밀어내려는 가지에는 일반적으로 더 많은 작업이 필요합니다. 실제 위험은 경쟁 가지, 네트워크 상태, 공격이 있다면 공격자의 자원, 노드가 적용하는 검증 규칙에 달려 있습니다. 모든 결제와 서비스에 안전을 보장하는 공통 확인 수는 없습니다. 비트코인 결제 처리 안내서는 판매자가 결제 상황과 위험에 맞춰 확인 정책을 선택하는 이유를 설명합니다.

서로 다른 채굴자가 짧은 시간 간격으로 블록을 찾으면 전파 후 한 가지가 먼저 다음 블록을 얻어 우세해질 수 있습니다. 다른 가지는 종종 한 블록 뒤에 오래된 가지가 됩니다. 이 일반적인 경쟁은 노드별 확인 수를 잠시 다르게 보이게 하고, 패한 가지에 있던 거래를 다시 계산하게 만들 수 있습니다. 오래된 블록은 부모를 알고 있고 당시 합의 규칙에 맞았지만 현재 선택된 가지에 포함되지 않은 블록입니다. 반면 고아 블록이라는 말은 원래 부모 블록을 모르는 채 도착한 블록을 가리킵니다. 두 용어는 과거 자료나 일상 대화에서 섞여 쓰이기도 하지만 상태가 다릅니다. 노드가 빠진 부모 블록을 받아 검증을 마칠 수 있고, 유효한 블록이라도 누적 작업량이 더 큰 가지에서 밀려나면 오래된 블록이 될 수 있습니다.

더 깊은 재구성은 네트워크 장애, 유효 블록 전달 지연, 소프트웨어나 합의 조정 문제, 과거 기록을 바꾸려는 시도 등으로 생길 수 있습니다. 원인과 심각도는 경우마다 다릅니다. “51% 공격”은 정직한 작업량을 앞서려는 시도를 가리키는 흔한 표현이지만, 작업량으로 노드의 합의 규칙을 위반한 블록을 강제로 받아들이게 할 수는 없습니다. 반대로 정직한 피어와 단절된 노드는 불완전한 정보만 받을 수 있으므로 원격 탐색기 하나만 확인해서 네트워크 전체를 진단할 수도 없습니다.

Bitcoin Core 31.0 노드의 getblockchaininfo는 네트워크 이름, 검증된 블록 높이, 헤더 수, 최고 블록 해시, 활성 체인의 chainwork, 동기화 관련 필드를 제공합니다. 여기서 blocks는 가장 많은 작업량을 가진 완전히 검증된 체인의 높이이고 headers는 노드가 확인한 헤더 수입니다. chainwork는 활성 체인 전체의 작업량을 16진수로 나타냅니다. 이 숫자들은 서로 다른 질문에 답하므로 headers가 더 크다는 이유로 그만큼의 블록이 완전히 검증됐다고 간주하면 안 됩니다. getchaintips는 해당 노드가 알고 있는 블록 트리의 팁을 나열합니다. valid-fork는 완전히 검증됐지만 활성 체인이 아닌 가지이며, valid-headers는 블록 데이터가 있지만 아직 전체 검증이 끝나지 않은 가지입니다. headers-only는 유효한 헤더만 있고 블록 일부를 아직 받지 못한 상태이고, invalid는 무효 블록이 포함된 가지입니다. 팁의 높이와 상태는 그 노드의 현재 지식을 보여줄 뿐 다른 피어가 같은 정보를 알고 있는지 증명하지 않습니다. 동기화가 진행 중이라면 값이 달라질 수 있으므로, 명령을 다시 확인해 최신 스냅샷을 비교하세요.

RPC 결과는 한 컴퓨터의 현재 스냅샷이지 네트워크 전체의 선언이 아닙니다. 초기 동기화 중이거나 연결이 나쁘면 노드가 뒤처지거나 블록 트리 일부만 알 수 있습니다. 체인 이름, 최신 블록 해시, 검증·동기화 상태, 관찰된 팁의 활성 여부를 확인하세요. Bitcoin Core 31.0 RPC 문서는 특정 버전 기준이므로 실행 중인 Core 버전에 맞는 명령과 필드를 확인해야 합니다.

서비스가 재구성을 알리면 거래 ID와 이전에 거래를 포함했던 블록 해시를 확인합니다. 신뢰하는 노드에서 현재 활성 팁을 조회하고 이전 블록이 해당 노드의 활성 체인에 남아 있는지 살펴보세요. 그 뒤 거래가 새 활성 블록에 포함됐는지, 미확인인지, 다른 지출과 충돌하는지 확인합니다. 탐색기의 색상이나 상태 문구는 제공자의 시각이지 합의 규칙은 아닙니다.

입금의 프로토콜 확인 수와 수신처가 계정에 반영하는 정책은 서로 다릅니다. 입금 확인 안내서는 거래소 반영과 지원 자산 확인을 다루고, 이 글은 그 표시 아래에서 비트코인이 가지를 선택하는 방식을 설명합니다. 노드 검증과 가지치기의 범위는 [비트코인 풀 노드 안내서](/ko/learn/bitcoin-full-node-pruning-archive-storage-validation-wallet-trust-explained)를 참고하세요. 화면이 바뀌었다는 이유만으로 재전송하지 말고, 먼저 현재 거래 상태와 서비스 지침을 확인하세요.