---
title: "하드포크와 소프트포크: 규칙 호환성, 활성화, 체인 분리"
description: "하드포크와 소프트포크는 이전 및 신규 합의 규칙 사이의 서로 다른 호환 관계를 뜻한다. 유효 블록 집합, 활성화, 노드의 규칙 집행, 채굴자 또는 검증자 행동, 애플리케이션 준비, 재생 위험과 실제 체인 분리를 각각 분석한다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 하드포크와 소프트포크: 규칙 호환성, 활성화, 체인 분리
> 프로토콜 교육을 위한 분석일 뿐 투자 조언이 아닙니다. 제안되었거나 활성화된 포크는 검증, 입출금, 수탁, 계약, 가격, 유동성, 세무 처리와 운영 보안을 방해할 수 있으며, 지속 가능한 두 번째 자산의 생성을 보장하지 않습니다.
## 핵심 답변
하드포크와 소프트포크는 업그레이드한 노드와 하지 않은 노드가 블록을 어떻게 판단하는지에 따라 합의 규칙 변경을 분류한다. 이전 규칙이 허용하는 블록 집합을 `V_old`, 새 규칙이 허용하는 집합을 `V_new`라고 하자. 소프트포크는 유효 범위를 제한해 `V_new subset V_old`가 되게 한다. 즉, 새 규칙에서 유효한 모든 블록은 이전 규칙에서도 유효하지만 이전 노드는 추가 제약을 집행하지 않는다. 하드포크는 이전 노드가 거부하는 새 규칙 유효 블록을 하나 이상 허용한다: `exists b: b in V_new and b not in V_old`. 하드포크 규칙 집합은 확장일 수도, 서로 포함되지 않을 수도 있으며, '하드'가 단순히 더 큰 블록이나 더 급진적인 기능을 뜻하지는 않는다.
호환성은 비대칭이다. 소프트포크가 성공하면 미업그레이드 노드는 업그레이드한 채굴자나 검증자가 만든 블록을 받아들이므로 같은 체인에 남을 수 있다. 그러나 업그레이드 노드가 거부하는 대상을 유효하다고 볼 수 있어 보증 수준이 낮다. 하드포크에서는 업그레이드한 생산자가 이전 유효 집합 밖의 블록을 만드는 순간 이전 노드가 이를 따라갈 수 없다. 경제적으로 중요한 참여자가 두 규칙 집합을 계속 지원하면 두 개의 지속적인 네트워크가 생길 수 있지만, 한쪽에 실질적 지원이 없다면 두 자산이 오래 남는 것은 아니다.
이 용어들은 규칙을 설명할 뿐 거버넌스의 정당성, 안전성, 경제적 지지나 활성화 방식을 말하지 않는다. 제안은 활성화 전에도 하드포크라 부를 수 있고, 활성화된 변경이 영구적 분리를 만들지 않을 수도 있다. 의도하지 않은 구현 비호환성이 거버넌스 투표 없이 체인을 분리할 수도 있다. 채굴자나 검증자 신호는 준비 상태를 조율할 수 있지만, 자체 규칙으로 무효인 블록을 풀 노드가 받아들이게 만들 수는 없다.
합의 포크를 동일 규칙 아래의 일시적 포크, 체인 재구성, 소프트웨어 저장소 포크, 애플리케이션 업그레이드와 혼동하면 안 된다. 운영상 핵심 질문은 각 노드, 지갑, 거래소, 수탁자, 오라클과 계약이 정확히 어느 네트워크, 규칙 집합, 활성화 조건과 체인 이력을 인정하는가이다.
## 프로토콜 포크 분석 방법
1. **식별 정보와 범위를 고정한다.** `chain`, `network`, `client version`, 활성화 제안, 제네시스 또는 최종 확정 체크포인트, 현재 블록 해시와 영향받는 계층을 기록한다. 같은 이름이라도 테스트넷, 메인넷, 실행 계층, 합의 계층 또는 애플리케이션에서 다른 규칙을 뜻할 수 있다.
2. **합의 유효성을 비교한다.** 변경된 블록, 거래, 서명, 상태 전이, 가스, 타임스탬프, 최종성 또는 포크 선택 규칙을 모두 열거한다. 대표 객체를 두 버전에서 각각 `valid`, `invalid`, `unknown`으로 분류하고 릴리스 노트만으로 호환성을 추정하지 않는다.
3. **집합 관계를 입증한다.** 새 규칙에서 유효한 모든 객체가 이전 규칙에서도 유효한지 검사한다. 그렇다면 소프트포크 호환이 가능하다. 새 규칙 유효·이전 규칙 무효인 블록이 하나라도 있으면 해당 노드에는 하드포크 전환이 필요하다. 이전 규칙 유효·새 규칙 무효인 객체도 검사한다.
4. **활성화를 재현한다.** 배포된 사양과 코드에서 높이, 에포크, 중간값 시간, 신호 임계값, 잠금 지연, 총 난이도 조건 또는 거버넌스 트리거를 확인한다. 신호, 잠금, 활성화와 집행은 서로 다른 상태다.
5. **참여자 행동을 대응시킨다.** 업그레이드한 블록 생산 가중치를 측정하고 각 진영의 풀 노드, 릴레이, 지갑, 거래소, 수탁자, 브리지, 스테이블코인 발행자, 오라클과 계약을 식별한다. 해시레이트나 지분만으로 경제적 수용을 결정할 수 없다.
6. **분리와 거래 처리를 추적한다.** 두 규칙 집합에서 부모 해시와 유효성을 따라간다. 확인 정책, 멤풀 차이, 재생 방지, 주소 형식, 체인 식별자, 서명 도메인, 출금 경로와 거래가 두 분기 모두에서 실행될 수 있는지 확인한다.
7. **운영 통제를 설정한다.** 조상 관계가 불명확하면 결제를 중지하거나 연장하고, 계획적으로 업그레이드와 백업을 수행한다. 분기별 잔액과 부채를 대조하고 서명 및 복구를 오프라인에서 시험하며, 명시한 체인·노드·거래상대방·최종성 기준을 충족한 뒤 재개한다.
이 방법은 흔히 '포크' 한 단어로 묶는 네 사건, 즉 규칙 제안, 활성화 조건, 관측된 체인 분기, 이후 한 개 이상 분기의 경제적 생존을 분리한다. 어느 단계도 다음 단계를 자동으로 입증하지 않는다.
## 계산 예시
### 1. 유효 집합 호환성
이전 규칙이 `100`가지 후보 블록 형식을 허용하고 새 규칙은 그중 `80`가지만 허용한다고 하자. 그 `80`가지가 모두 이전 집합 안에 있으면 이 변경은 소프트포크 관계를 가지며, 나머지 `20`가지 이전 규칙 유효 형식은 업그레이드 노드가 거부한다. 이 숫자는 집합을 설명할 뿐 확률이나 투표 임계값이 아니다.
이제 새 규칙이 모든 이전 노드가 거부하는 블록 형식을 허용한다고 하자. 다른 대부분의 블록이 두 규칙에서 모두 유효하더라도 이 반례 하나면 하위 호환 수용 관계가 깨져 하드포크 비호환 전환이 된다. 실제 네트워크 분리가 지속되는지는 해당 블록 이후의 생산자, 사용자와 경제 인프라에 달려 있다.
### 2. BIP 34 활성화는 정의가 아니다
`BIP 34`는 코인베이스 거래에 블록 높이를 넣도록 하고 순환 준비 메커니즘을 사용했다. 직전 1,000개 블록 가운데 `750 of 1,000`개가 버전 2 이상이면 무효한 버전 2 블록을 거부했고, `950 of 1,000`개에 도달하면 버전 1 블록을 거부했다. 이 BIP는 블록 `227,835`를 마지막 버전 1 블록으로 기록한다.
이 임계값은 배포를 조율했지만 변경을 소프트포크로 정의한 것은 아니다. 호환성은 업그레이드 노드가 수용 범위를 줄이는 동시에 이전 클라이언트가 새 규칙 준수 블록을 계속 받아들인 데서 왔다. 이후 `BIP 9`는 분리된 배포 상태와 버전 비트를 규정해 규칙 관계와 활성화 장치가 다른 문제임을 다시 보여 주었다.
### 3. Segregated Witness의 소프트포크 설계
`BIP 141`은 `witness` 데이터를 도입하고 코인베이스 거래를 통해 그 트리를 기존 블록 커밋 구조에 포함했다. 이 설계로 이전 노드는 새 witness 규칙을 이해하거나 검증하지 않아도 준수 블록을 받아들였고, 업그레이드 노드는 새 규칙을 집행했다.
이는 하위 호환 수용이지 동일한 검증이 아니다. 이전 노드는 새 규칙이 지배하는 출력을 업그레이드 노드보다 덜 제한적으로 볼 수 있으므로, 새 보안 속성에 의존하는 사용자는 업그레이드된 검증을 사용해야 한다. '이전 소프트웨어가 계속 실행된다'는 말만으로는 위험 분석이 충분하지 않다.
### 4. 이더리움 DAO Fork
EIP-779는 메인넷 블록 `1,920,000`의 DAO Fork를 기록한다. 이는 지정 계정 목록 `L`의 잔액을 `WithdrawDAO` 계약으로 옮긴 비정규 상태 변경이며 EVM 연산 코드, 거래 형식과 블록 구조는 그대로 두었다.
이 상태 전이를 적용한 노드와 거부한 노드는 경계 뒤에 서로 다른 상태를 계산했다. 이 사례는 하드포크에 블록 확대나 연산 코드 추가가 필요하지 않고, 일회성 상태 전이 규칙도 비호환성을 만들며, 두 이력에 대한 지원이 지속되면 별도 네트워크가 존속할 수 있음을 보여 준다.
## 위험과 검토 오류
### 분류 및 사양 오류
- 모든 노드가 같은 규칙을 쓰고 일반 포크 선택으로 해소되는 일시적 경쟁 체인 끝까지 하드포크라고 부른다.
- 실제 유효 블록 집합을 검사하지 않고 모든 규칙 완화를 하드포크, 모든 제한을 소프트포크로 정의한다.
- 하위 호환 수용을 완전한 하위 호환 보안으로 본다. 이전 노드는 새 소프트포크 제약을 집행하지 않는다.
- 배포 코드와 체인 매개변수가 아니라 브랜드명, 로드맵, 릴리스 노트나 저장소 분기에서 합의 행동을 추론한다.
- 메인넷, 테스트넷, 실행 계층, 합의 계층, 브리지, 롤업과 애플리케이션 계층 업그레이드를 혼합한다.
- 제안, 클라이언트 릴리스, 신호 임계값, 잠금과 활성화를 같은 사건으로 본다.
- 채굴자나 검증자 신호를 사용자, 거래소, 수탁자 또는 풀 노드를 구속하는 투표로 본다.
### 분리 및 거래 위험
- 활성화가 반드시 분리를 만들거나 분리가 반드시 유동성과 지속성이 있는 두 자산을 만든다고 가정한다.
- 같은 높이의 분기에 다른 블록이 있을 수 있는데 높이만 사용하고 해시와 조상 관계를 검증하지 않는다.
- 재생 방지, 체인 식별자, 서명 도메인과 분기 전용 거래 구성을 확인하지 않고 분리 중 송금한다.
- 한 분기의 입금을 인정하면서 다른 분기에서 부채나 출금을 결제한다.
- 제공자가 다른 규칙을 따르거나 전환에 뒤처질 수 있는데 단일 탐색기, RPC 엔드포인트나 수탁 표시만 믿는다.
- 재구성, 최종성 중단, 피어 분할, 소수 채굴, 검증자 이중 투표나 데이터 비가용성을 무시한다.
- 토큰 기호, 계약 주소, 스테이블코인 잔액, 오라클 가격이나 브리지 청구권이 두 분기에서 같은 발행자 보장을 받는다고 가정한다.
### 거버넌스 및 운영 위험
- 프로토콜 호환성을 변경의 정당성, 탈중앙성, 안전성 또는 경제적 지지의 증거로 설명한다.
- 재현 가능한 바이너리, 백업, 롤백 한계, 데이터베이스 이전 시험과 독립 해시 확인 없이 운영 노드를 업그레이드한다.
- 새 상태 데이터, 지갑 형식이나 슬래싱 조건 도입 뒤에도 다운그레이드가 항상 안전하다고 본다.
- 비밀을 노출하거나 서명을 재생할 수 있는 검증되지 않은 소프트웨어로 개인 키를 옮기거나 '포크 코인을 청구'한다.
- 만기, 잠금, 계약 상태와 수탁 정책을 확인하지 않고 스냅샷 잔액을 즉시 쓸 수 있다고 본다.
- 분기 소유권, 통제, 유동성과 현지 규칙이 확정되기 전에 세무, 회계나 가치평가 결론을 낸다.
## 흔한 오해
- **하드포크는 항상 새 코인을 만든다.** 두 번째 자산이 지속되려면 계속되는 블록 생산, 사용자, 인프라와 시장이 필요하며 많은 업그레이드는 하나의 인정된 이력으로 수렴한다.
- **이전 노드가 작동하므로 소프트포크는 무위험이다.** 체인을 따를 수는 있지만 추가 규칙을 집행하지 않아 검증 보장이 약해질 수 있다.
- **과반 해시레이트나 지분만으로 어떤 규칙이든 바꿀 수 있다.** 풀 노드는 자체 규칙에서 무효인 블록을 거부하고 생산 가중치는 수용한 블록 사이에서만 작용한다.
- **하드는 논쟁적이고 소프트는 만장일치라는 뜻이다.** 이 용어는 호환성을 분류할 뿐 사회적 합의, 거버넌스 품질이나 논쟁 여부를 나타내지 않는다.
- **탐색기에 보이는 모든 포크가 프로토콜 업그레이드다.** 동일 규칙의 경쟁 블록과 체인 재구성은 합의 규칙 변경 없이도 발생한다.
## 관련 주제
- [합의 메커니즘](/ko/crypto/consensus-mechanism/)
- [풀 노드](/ko/crypto/full-node/)
- [포크 선택 규칙](/ko/crypto/fork-choice-rule/)
- [체인 재구성](/ko/crypto/chain-reorg/)
- [비트코인](/ko/crypto/bitcoin/)
## 출처
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (접근일: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (접근일: 2026-08-19)
- [BIP 34: Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) - Bitcoin BIPs (접근일: 2026-08-19)
- [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) - Bitcoin BIPs (접근일: 2026-08-19)
- [BIP 9: Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - Bitcoin BIPs (접근일: 2026-08-19)
- [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin BIPs (접근일: 2026-08-19)
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) - Bitcoin BIPs (접근일: 2026-08-19)
- [EIP-779: Hardfork Meta: DAO Fork](https://eips.ethereum.org/EIPS/eip-779) - Ethereum Improvement Proposals (접근일: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/hard-fork-soft-fork/index.mdx