TL;DR: 블록체인 리오그(reorg, 재구성(reorganization)의 약자)는 네트워크의 표준 체인이 변경되어, 이전에 메인 체인의 일부로 간주되던 블록들이 다른 블록 집합으로 대체될 때 발생합니다. 이로 인해 확정된 거래가 사라지거나, 거래 순서가 바뀌거나, 애플리케이션 상태가 일관성을 잃을 수 있습니다. 리오그는 네트워크 지연 및 동시 블록 생성으로 인해 대부분의 블록체인에서 자연스럽게 발생하지만, 심각한 리오그는 공격이나 소프트웨어 버그로 인해 발생할 수도 있습니다. 리오그를 이해하는 것은 확정된 블록체인 데이터에 의존하는 애플리케이션을 구축하는 모든 개발자에게 매우 중요합니다. 리오그를 고려하지 않을 경우 이중 지출 취약점, 팬텀 트랜잭션, 데이터베이스 손상이 발생할 수 있기 때문입니다.
간단한 설명
블록체인을 숲 속의 하나의 길로 생각해 보세요. 여기서 한 걸음 한 걸음이 바로 ‘블록’입니다. 정상적인 상황에서는 모두가 같은 길을 따릅니다. 하지만 가끔 두 명의 개척자가 동시에 서로 다른 길을 발견하기도 하는데, 이 경우 잠시 동안 두 개의 유효한 길이 동시에 존재하게 됩니다. 결국 네트워크는 어느 길이 올바른지 결정하고(대개 더 멀리 뻗어 있는 쪽이 선택됩니다), 모두가 그 길로 전환합니다. 다른 길을 따라가던 사람들은 되돌아가서 그 길로 갈아타야 합니다.
이러한 전환이 발생하면, 이를 ‘재구성(reorg)’이라고 합니다. 버려진 경로의 블록들은 폐기되고, 승리한 경로의 블록들이 표준 체인이 됩니다. 버려진 블록에 포함되어 있던 거래들은 승리한 체인의 블록에 나타날 수도 있고 나타나지 않을 수도 있습니다. 일부 거래는 두 경로 모두의 동일한 위치에 포함될 수도 있습니다. 다른 거래들은 한쪽 경로에는 나타나지만 다른 쪽 경로에는 나타나지 않을 수도 있습니다. 승리한 체인의 거래와 충돌하는 경우, 극소수의 거래는 완전히 삭제될 수도 있습니다.
대부분의 최종 사용자에게는 얕은 재구성(1~2블록 깊이)이 빈번하게 발생하지만, 이를 눈치채지 못합니다. 지갑에서는 거래가 잠시 ‘확인됨’으로 표시되었다가, 새로운 표준 블록에서 재확인되기 전까지 몇 초 동안 다시 ‘보류 중’으로 표시될 수 있습니다. 사용자는 이를 눈치채지 못할 가능성이 높습니다. 하지만 대규모로 블록체인 데이터를 처리하는 애플리케이션의 경우, 단 한 블록의 재구성만으로도 기존 블록을 기반으로 데이터베이스에 이미 기록된 레코드가 이제 부정확해져 수정해야 할 상황이 발생합니다.
리오그의 가장 흔한 원인은 자연스러운 네트워크 지연입니다. 두 검증자가 거의 동시에(동일한 슬롯 내에서 또는 동일한 블록 높이에서) 유효한 블록을 생성할 경우, 네트워크의 서로 다른 부분에서 일시적으로 서로 다른 블록을 채택할 수 있습니다. 노드 A는 블록 X를 먼저 확인하고 이를 표준 블록으로 간주하는 반면, 노드 B는 블록 Y를 먼저 확인할 수 있습니다. 두 블록 모두 합의 규칙에 따라 유효하지만, 궁극적으로 메인 체인에 포함될 수 있는 것은 하나뿐입니다.
네트워크는 포크 선택 규칙을 통해 이러한 모호성을 해결합니다. Ethereum 에서는 포크 선택 규칙(LMD-GHOST)이 가장 많은 검증자의 인증을 받은 체인을 선택합니다. Bitcoin 에서는 가장 긴 체인(작업 증명(PoW)이 가장 많이 누적된 체인)이 승리합니다. 구체적인 규칙에 관계없이 결과는 동일합니다. 즉, 하나의 포크가 표준으로 채택되고 다른 하나는 폐기됩니다. 폐기된 포크를 따르던 노드들은 이러한 전환을 감지하고, 고아 블록을 롤백한 뒤 승리한 체인을 채택합니다.
Bitcoin 와 같은 작업 증명(Proof of Work) 체인에서는 채굴 과정이 본질적으로 확률적이기 때문에 리오르그(reorg)가 비교적 흔하게 발생합니다. 두 명의 채굴자가 거의 동시에 유효한 블록을 발견하면 일시적인 포크가 발생하지만, 이는 한두 개의 블록 내에 해결됩니다. Bitcoin 에서는 한 블록 규모의 재구성이 정기적으로 발생하며, 이는 네트워크 운영의 정상적인 부분으로 간주됩니다. 정직한 환경에서는 더 깊은 재구성이 드물지만, 공격자가 네트워크 해시 파워의 상당 부분을 장악할 경우(51% 공격의 근거) 가능해집니다.
Ethereum 의 지분 증명(Proof of Stake) 시스템에서, 슬롯 기반 블록 생성 모델은 각 슬롯에 지정된 제안자가 있기 때문에 자연적인 재구성(reorg)의 발생 빈도를 줄여줍니다. 하지만 (네트워크 지연으로 인해) 제안자의 블록이 늦게 도착하고, 다음 제안자가 대신 이전의 정식 블록을 기반으로 블록을 생성할 경우 재구성이 여전히 발생할 수 있습니다. 지정된 제안자가 블록을 생성하지 못하는 ‘슬롯 누락’ 상황에서도, 여러 검증자가 서로 다른 체인 뷰를 기반으로 블록을 생성할 경우 짧은 리오르그가 발생할 수 있는 조건이 조성될 수 있습니다.
재편 유형
얕은 리오그는 1~3블록 깊이로 발생하며, 대부분의 블록체인에서 자연스럽게 나타납니다. 이는 분산형 합의의 정상적인 결과이며, 몇 초 이내에 저절로 해결됩니다. 대부분의 애플리케이션은 데이터를 최종적인 것으로 간주하기 전에 블록 확인을 몇 번 더 기다림으로써 얕은 리오그를 처리할 수 있습니다.
심층 리오그는 3블록 이상 깊이로 발생하며, 대개 의도적인 공격, 합의 버그, 또는 심각한 네트워크 분할과 같은 비정상적인 현상의 징후입니다. 주요 체인에서 발생하는 심층 리오그는 사용자와 애플리케이션이 이미 확정된 것으로 간주했던 거래를 되돌릴 수 있기 때문에 심각한 사건입니다. 보안 수준이 낮은(해시 파워나 스테이킹된 가치가 낮은) 소규모 체인에서 발생하는 심층 리오그는 더 흔하며, 이중 지출 공격을 수행하는 데 이용되기도 했습니다.
51% 공격(또는 일부 PoS 체인의 경우 34% 공격)은 의도적으로 대규모 재구성(deep reorg)을 유발하는 행위입니다. 과반수 합의 권한을 가진 공격자는 공개 체인과는 다른 사설 체인을 채굴하거나 검증한 뒤, 이를 네트워크에 공개합니다. 공격자의 체인이 더 길거나(또는 더 많은 인증을 받았기 때문에) 네트워크는 이를 표준 체인으로 채택하고, 공개 체인의 최근 블록들을 고아 블록(orphaned blocks)으로 만듭니다. 이를 통해 공격자는 버려진 체인에서 거래를 되돌릴 수 있으며, 이전에 전송되고 확인된 자금을 이중 지출할 가능성이 생깁니다.
애플리케이션에 미치는 영향
블록체인 데이터를 처리하는 애플리케이션의 경우, 재구성(reorg)은 데이터 일관성 문제를 야기합니다. 애플리케이션이 트랜잭션 기록이 블록에 등장하는 즉시 데이터베이스에 기록하는 경우, 재구성이 발생하면 해당 기록 중 일부는 더 이상 존재하지 않는 블록을 기반으로 하게 됩니다. 이러한 트랜잭션은 새로운 표준 블록에 여전히 나타날 수도 있지만(단, 위치가 다르거나 블록 번호가 다를 수 있음), 아예 누락될 수도 있습니다.
DeFi 애플리케이션은 특히 취약합니다. DEX 애그리게이터가 스왑이 확정된 것으로 표시하고 사용자의 포트폴리오를 업데이트했지만, 리오그(reorg)로 인해 해당 스왑이 정식 체인에서 제거되면 포트폴리오 정보가 부정확해집니다. 브리지가 소스 체인에서 입금을 감지하고 대상 체인에서 자금을 지급했지만, 리오그로 인해 입금 내역이 제거되면 브리지는 더 이상 존재하지 않는 거래를 기반으로 자금을 지급한 것이 됩니다. 이는 크로스체인 브리지를 겨냥한 주요 공격 경로 중 하나입니다.
인덱서와 데이터 파이프라인은 재구성을 감지하고, 어떤 블록이 폐기되었는지 파악하며, 해당 블록에서 파생된 모든 레코드를 롤백한 뒤, 올바른 표준 블록을 다시 처리해야 합니다. 이러한 로직이 없다면, 인덱싱된 데이터베이스에는 고아 블록에서 비롯된 유령 레코드가 누적되어 시간이 지남에 따라 불일치가 커지고, 이로 인해 하류 분석 결과, 잔액 및 거래 내역이 손상될 수 있습니다.
조직 개편에 대처하는 방법
리오그에 대비하는 가장 간단한 방법은 데이터가 확정된 것으로 간주하기 전에 최종 확정(finality)이 이루어질 때까지 기다리는 것입니다. Ethereum 에서는 2개의 에포크(약 12~13분)가 지나면 최종 확정(finality)이 발생하며, 이 시점 이후에는 전체 스테이킹된 ETH의 최소 1/3을 소각하지 않고서는 블록을 되돌릴 수 없습니다. Bitcoin 에서는 6회의 확인(약 60분)이 경제적 최종 확정을 위한 널리 인정되는 표준입니다. Solana 에서는 싱글 슬롯 최종 확정(single-slot finality)을 통해 확인된 거래가 약 400밀리초 이내에 사실상 최종 확정됩니다.
(사용자가 더 빠른 피드백을 기대하기 때문에) 완전한 최종성을 기다릴 여유가 없는 애플리케이션의 경우, 충분한 확인 횟수가 충족될 때까지 데이터를 “미확인” 또는 “보류 중”으로 표시하고, 최근에 확인된 트랜잭션이 재구성(reorg)으로 인해 되돌려지는 상황을 원활하게 처리할 수 있는 롤백 로직을 구현하는 것이 모범 사례입니다.
데이터 파이프라인은 가능한 한 블록을 최종 확정 순서대로 처리해야 합니다. 블록이 체인 끝부분에 나타나는 즉시 이를 가져오는 것(이는 나중에 고아 블록이 될 수 있는 블록을 처리할 위험이 있음) 대신, 파이프라인은 최근 블록을 버퍼에 저장해 두었다가 안전한 확인 깊이에 도달한 후에야 처리해야 합니다. 버퍼링이 허용되지 않는 실시간 사용 사례의 경우, 파이프라인에는 명시적인 재구성 감지 및 롤백 메커니즘이 포함되어야 합니다.
리오그와 포크의 차이점은 무엇인가요?
리오그와 포크는 관련이 있지만 같은 개념은 아닙니다. 포크란 체인이 두 개의 경쟁하는 분기로 갈라지는 모든 지점을 말하며, 이는 일시적일 수도 있고(동일한 높이에 두 개의 유효한 블록이 존재하는 경우), 영구적일 수도 있습니다(새로운 체인을 생성하는 프로토콜 업그레이드). 리오그는 특히 일시적인 포크가 해결된 후 노드들이 한 분기를 포기하고 다른 분기로 전환할 때 발생하는 현상을 말합니다. 다시 말해, 일시적인 포크가 원인이고, 리오그는 패배한 분기를 지지했던 노드들에게 미치는 결과입니다.
양상
조직 개편
포크
정의
노드들은 표준 블록을 경쟁 분기의 블록으로 대체합니다
사슬이 두 개 이상의 가지로 갈라진다
트리거
임시 포크는 다른 브랜치를 우선하여 해결됩니다.
동시 실행 블록, 버그, 아니면 프로토콜 업그레이드
영속성
항상 임시적이며, 한 개의 분기가 제거됩니다.
일시적이거나 영구적일 수 있습니다
데이터에 미치는 영향
확인된 거래 내역이 이동하거나 사라질 수 있습니다
별도의 지속적인 체인을 생성할 수 있습니다
다양한 분할 유형에 대해 더 자세히 알아보려면 체인 포크가 무엇인지 확인해 보세요. 리오그(Reorg) 역시 트랜잭션 순서와 밀접한 관련이 있는데, 이는 표준 브랜치가 바뀌면 트랜잭션의 순서가 바뀔 수 있기 때문입니다.
재구성(reorg)을 방지하려면 몇 번의 확인이 필요한가요?
안전한 확인 횟수는 체인의 합의 설계 방식과 걸려 있는 가치의 규모에 따라 달라집니다. 확인 횟수가 많을수록 거래를 되돌리려면 더 심층적인 재구성(reorg)이 필요하게 되며, 이로 인해 공격자가 부담해야 할 비용은 기하급수적으로 증가합니다. 아래 표는 데이터를 최종 확정된 것으로 간주하기 위한 일반적인 지침을 요약한 것입니다.
체인
공통 최종성 기준치
대략적인 실제 소요 시간
Bitcoin
6건의 확인
약 60분
Ethereum
2 에포크 (완료됨)
약 12~13분
Solana
단일 슬롯 최종성
약 400 밀리초
규모가 더 작은 PoW 체인
더 많은 확인 사례
상황에 따라 다르며, 구조조정 위험이 더 높음
블록체인의 최종 확정성을 기다리는 것이 가장 강력한 보호 수단인 반면, 규모가 작거나 보안 수준이 낮은 네트워크는 리오그(reorg) 위험이 더 높기 때문에 더 깊은 확인 깊이가 필요합니다. 이 경우 신뢰할 수 있는 인프라도 중요합니다. 일관된 리오그 대응 데이터를 위해 노드 신뢰성이 왜 중요한지 확인해 보세요.
블록체인 재구성(reorg)이 공격이 될 수 있나요?
대부분의 리오그는 무해하며 한두 블록 이내에 해결되지만, 의도적으로 설계된 심층 리오그는 공격에 해당합니다. 충분한 합의 권한을 가진 공격자는 경쟁 체인을 비공개로 구축한 후 이를 공개함으로써, 최근 블록들을 고아 블록으로 만들고 이미 확정된 것처럼 보였던 거래를 되돌릴 수 있으며, 이것이 바로 이중 지출 및 51% 공격의 배경이 되는 메커니즘입니다. 리오그는 수익 추출 전략과도 중첩되므로, MEV가 무엇인지 이해하고일반적인 블록체인 오류 유형을 검토하면, 팀은 리오그가 자연적인 현상이 아닌 악의적인 경우 안전하게 실패하도록 시스템을 설계하는 데 도움이 됩니다.
자주 묻는 질문
블록체인 재구성(reorg)은 흔한 일인가요?
1~3블록 규모의 얕은 리오그는 분산 합의 과정에서 흔히 발생하는 정상적인 현상이며, 특히 작업 증명(PoW) 체인에서 빈번하게 일어납니다. 이러한 리오그는 대개 몇 초 내에 해결되며, 대부분의 사용자는 이를 전혀 눈치채지 못합니다. 반면, 깊은 리오그는 비정상적인 현상이며, 종종 공격이나 버그를 의미합니다.
재구성(reorg) 중에 확정된 거래 내역이 사라지나요?
가능합니다. 고아 블록에 포함된 트랜잭션은 새로운 표준 체인에서 다른 위치에 다시 나타날 수도 있고, 승리한 분기와 충돌할 경우 완전히 제외될 수도 있습니다. 그렇기 때문에 애플리케이션은 트랜잭션을 최종 확정된 것으로 간주하기 전에 충분한 확인 횟수가 쌓일 때까지 기다려야 합니다.
어떤 블록체인에서 리오그가 가장 많이 발생하나요?
작업 증명(Proof of Work) 방식의 체인이나 해시 파워가 낮거나 스테이킹된 가치가 적은 소규모 네트워크에서는 리오르그가 더 빈번하게 발생합니다. 이더리움( Bitcoin )에서는 가끔 한 블록 규모의 리오르그가 발생하는 반면, 보안 수준이 낮은 체인은 더 광범위하고 잠재적으로 악의적인 리오르그에 더 취약합니다.
인덱서는 리오그를 어떻게 처리하나요?
리오그를 인식하는 인덱서는 포크를 감지하고, 어떤 블록이 폐기되었는지 식별한 뒤, 해당 블록에서 파생된 모든 레코드를 롤백하고 새로운 표준 블록을 다시 처리합니다. 이러한 로직이 없다면, 데이터베이스에는 시간이 지남에 따라 잔액과 분석 결과를 왜곡하는 팬텀 레코드가 누적됩니다.
최종 확정까지 기다리는 것이 재구성 문제를 방지할 수 있을까요?
네. 블록이 최종 확정되면 막대한 경제적 비용을 치르지 않고서는 되돌릴 수 없기 때문에, 최종 확정된 블록에 연결된 데이터는 리오거나이제이션으로부터 안전합니다. 그 대가로 지연 시간이 발생하는데, 이것이 바로 일부 애플리케이션이 미확정 데이터를 표시하면서도 되돌릴 수 없는 작업은 최종 확정된 데이터에 대해서만 수행하는 이유입니다.
Quicknode 의 리오그 처리 방식
Quicknode Streams 이 서비스는 핵심 아키텍처에 리오그(reorg) 처리 기능이 내장되도록 설계되었습니다. Streams 는 블록체인 데이터를 최종 확정 순서대로 전달하며, 이는 블록이 네트워크상에서 안전한 확인 깊이에 도달한 후에만 처리 및 전달된다는 것을 의미합니다. 리오그가 발생하면 Streams 가 포크를 자동으로 감지하고, 전달된 블록 중 더 이상 표준 블록이 아닌 것을 식별한 뒤, 데이터가 체인의 실제 상태와 일관성을 유지할 수 있도록 수정 페이로드를 수신처로 전송합니다.
이 내장된 재구성 처리 기능은 블록체인 데이터 처리에서 가장 복잡한 엔지니어링 과제 중 하나를 해결해 줍니다. 파이프라인에 맞춤형 재구성 감지, 롤백 로직, 블록 조정 기능을 직접 구축할 필요 없이, 스트림(Stream)을 구성하기만 하면 ‘ Quicknode ’가 나머지 작업을 처리합니다. 인덱서, 분석 플랫폼, 실시간 모니터링 시스템 등 어떤 시스템을 구축하든, ‘ Streams ’는 네트워크 재구성 중에도 대상 시스템의 데이터가 표준 체인(canonical chain)과 일치하도록 보장합니다.
Quicknode'의 Core API는 지원되는 네트워크 전반에 걸쳐 최신 블록 데이터와 확정된 블록 데이터를 모두 조회할 수 있도록 지원하므로, 애플리케이션에서 각 사용 사례에 적합한 확인 수준을 선택할 수 있습니다. 즉각적인 피드백을 원하는 사용자에게는 최신 블록을 표시하되, 금융 관련 결정이나 되돌릴 수 없는 조치가 포함된 로직의 경우 확정된 블록 데이터를 기반으로 처리하십시오.