암호화폐에서 소프트 포크란 무엇을 의미하나요?

대부분의 코인 보유자에게 있어, 규제된 소프트 포크는 새로운 코인을 생성 하거나 지갑에서 즉각적인 조치를 요구하지 않습니다. 주요 위험은 조정 과정에 있습니다. 채굴자 , 검증자, 노드 운영자, 지갑, 거래소, 사용자 등 모든 관련 당사자가 더 엄격한 규칙을 시행하는 데 동의해야 합니다. 이러한 합의에 도달하지 못하면, 포크가 기술적으로 하위 호환성을 유지하더라도 네트워크 분열로 이어질 수 있습니다.

• 소프트 포크란 무엇인가요? 이는 기존 노드와의 호환성을 유지하면서 유효한 규칙의 범위를 좁히는 것을 목표로 하는 네트워크 업그레이드입니다.
• 무엇이 바뀌었나요? 이를 통해 네트워크는 모든 참여자가 동시에 업그레이드할 필요 없이 더 엄격한 규칙을 추가할 수 있습니다.
• 가장 큰 위험 요소. 논란이 되고 있는 소프트 포크는 실행 과정에서 적절한 조정이 이루어지지 않을 경우 블록 거부, 체인 재구성 위험 또는 심지어 분할로 이어질 수 있습니다.

비트코인 규칙을 커다란 원으로 상상해 보세요. 이 원 안에 있는 모든 블록은 유효한 것으로 간주됩니다.

소프트 포크는 자체 내부에 더 작은 원을 그립니다. 이제 업데이트된 노드는 이 작은 원 안에 있는 블록만 허용합니다. 하지만 핵심은 작은 원 안에 있는 모든 블록이 더 큰 원 안에도 포함된다는 것입니다. 따라서 기존 규칙을 사용하는 이전 노드는 업데이트된 블록을 인식하고 문제없이 수용합니다.

이것이 바로 하위 호환성의 개념입니다. 기존 소프트웨어는 규칙 변경이 발생했다는 사실조차 인지하지 못한 채 새로운 시리즈를 따라갈 수 있습니다.

업데이트된 블록이 여전히 기존 규칙을 충족하기 때문에 네트워크가 한 번에 완전히 전환할 필요는 없습니다. 채굴자, 검증 자, 거래소 및 지갑은 호환되지 않는 블록이 대량으로 축적되기 전에 블록 생성 과정이 더 엄격한 규칙을 준수하는 한 점진적으로 업그레이드할 수 있습니다.

규칙들 간의 관계는 다음과 같습니다.

• 기존 매듭은 분기 전의 더 넓은 규칙을 적용합니다.
• 업데이트된 노드는 새로운 제한 사항 외에도 기존 규칙을 적용합니다.
• 새로운 규칙을 준수하는 블록은 기존 규칙도 그대로 통과합니다.
• 호환되지 않는 블록은 업데이트된 노드에서 거부됩니다.
• 네트워크의 충분한 비율이 호환 가능한 블록을 생성하면 기존 노드는 아무런 변화도 느끼지 못한 채 동일한 체인에 남아 있게 됩니다.

핵심 단어는 '부분집합' 입니다 . 소프트 포크는 새로운 규칙을 기존 경계 내에서 유지합니다. 하드 포크는 기존 경계를 완전히 벗어납니다. 이런 일이 발생하면 기존 노드는 새로운 체인 블록을 검토하고 해당 블록이 기존 규칙을 위반한다고 판단하여 즉시 거부합니다. 결과적으로 두 가지 규칙 집합은 서로 다른 체인에 존재하게 됩니다.

기본 원장이 어떻게 상호 연결되어 있는지 더 자세히 알아보려면 '블록체인 초보자를 위한 설명' 가이드를 먼저 읽어보는 것이 좋습니다.

암호화폐 세계 에서 소프트 포크와 하드 포크의 근본적인 차이점을 이해하는 것은 한 문장으로 요약할 수 있습니다. 소프트 포크는 규칙을 강화하는 반면, 하드 포크는 규칙을 완전히 새로 쓰는 것입니다.

소프트 포크에서는 기존 노드들이 새로운 체인의 블록을 계속 검증할 수 있습니다. 새로운 규칙의 모든 세부 사항을 이해하지 못할 수도 있지만, 체인을 거부하지는 않습니다. 반면 하드 포크에서는 기존 노드들이 새로운 블록을 무효로 간주하고 자체적인 별도 체인을 유지합니다.

시장 차별화 또한 중요합니다. 비트코인 ​​캐시는 하드 포크 후에도 지속적인 성공을 거둔 가장 명확한 사례입니다. 별도의 네트워크, 별도의 디지털 자산, 그리고 별도의 커뮤니티를 유지하고 있습니다. 이더리움 역시 계획적인 하드 포크를 표준 ​​업그레이드 경로로 삼아 왔습니다. 하지만 2016년 이더리움 클래식 포크는 여전히 거버넌스 측면에서 가장 중요한 분열로 남아 있습니다.

이러한 기술적 차이는 암호화폐 거래 플랫폼에서도 분명하게 드러납니다. 소프트 포크가 원활하게 진행될 경우, 암호화폐 거래 플랫폼의 주요 과제는 입금, 출금 및 지갑 설정이 정상적으로 작동하도록 보장하는 것입니다. 하지만 하드 포크가 발생하면 플랫폼은 새로운 디지털 자산을 상장할지, 무시할지, 아니면 기존 코인 보유자에게 두 가지 통화를 모두 제공할지라는 더 어려운 결정을 내려야 합니다.

소프트 포크의 성공 여부는 어느 한 주체에 의해 좌우되는 것이 아니라, 관련된 모든 당사자의 협력이 필요합니다.

개발자는 코드를 작성하고 검토하며, 풀 노드 운영자는 프로그램이 적용할 규칙을 결정합니다. 채굴자는 새로운 규칙을 준수하는 블록과 그렇지 않은 블록을 생성합니다. 지갑과 거래소는 사용자에게 보이는 부분을 담당합니다. 전체 시스템은 네트워크의 충분한 부분이 강화된 규칙을 실제로 준수할 때만 제대로 작동합니다.

특히 비트코인의 경우, 채굴자 신호 전달이 주요 조정 도구였습니다. BIP-9 버전은 블록 헤더의 비트를 사용하여 약 2주(2,016 블록) 기간 동안 준비 상태를 추적합니다. 준비 기간 동안 충분한 채굴자가 지지 신호를 보내면 새로운 규칙이 적용되기 전 락인 기간이 시작됩니다.

활성화 과정에서 각 그룹이 실제로 하는 일은 다음과 같습니다.

• 개발자들은 규칙 변경을 제안하고, 테스트하고, 검토합니다.
• 전체 계약은 운영자가 수신하는 각 블록에 적용하는 규칙을 결정합니다.
• 채굴자 또는 검사자는 가장 엄격한 규칙에 따라 블록이 적합하거나 부적합한 경우에만 블록을 생성합니다.
• 운영자는 프로토콜의 사용자 인터페이스 부분에 영향을 미치는 변경 사항이 발생할 경우 서명 흐름, 주소 형식, 그래픽 도구 또는 표시 동작을 업데이트합니다.
• 거래소는 입금, 출금, 확인 횟수 및 고객 알림을 관리합니다.
• 일반 코인 보유자는 지갑 지원 여부를 확인하고, 논란이 되는 활성화 기간 동안에는 성급한 거래를 피하면서 기다립니다.

풀 노드는 규칙이 실제로 적용되는 곳입니다. 채굴자는 블록을 찾을 수 있지만, 해당 노드가 정한 규칙을 위반하면 노드는 이를 거부합니다. 이러한 분리는 채굴자의 신호와 노드의 실행 방향이 서로 다를 때 매우 중요합니다.

지갑은 다르지만 똑같이 중요한 역할을 합니다. 지갑은 블록체인의 모든 블록을 검증하는 것이 아니라 기존 규칙 집합을 기반으로 주소, 스크립트 및 서명을 생성합니다. 대부분의 사용자는 지갑 업데이트가 필요할 때까지 업데이트를 알아차리지 못합니다. 진짜 함정은 유명 인사들이 참여하는 업데이트 중에 나타나는 가짜 광고에 있습니다. 이러한 광고는 기존 규칙을 강화하는 것 외에는 아무것도 하지 않는 포크를 통해 무료 코인을 제공한다고 약속합니다.

비트코인 업데이트가 항상 순조로웠던 것은 아닙니다. 어떤 업데이트는 빠르고 조용하게 진행된 반면, 어떤 업데이트는 몇 년씩 걸리고 커뮤니티를 분열시킬 뻔하기도 했습니다. 하지만 모든 업데이트의 공통점은 동일한 합의 구조, 즉 기존 노드들이 계속해서 따를 수 있는 새로운 규칙들을 도입했다는 점입니다.

각 주요 업그레이드의 실제 변경 사항은 다음과 같습니다.

• P2SH (BIP-16, 2012): 이 기능 덕분에 사용자는 전체 스크립트를 거래 출력에 노출하는 대신 스크립트 해시값으로 자금을 보낼 수 있었습니다. 기존 노드에서는 P2SH 거래가 일반적인 "누구에게나 지불" 거래처럼 보였지만, 최신 노드에서는 더 복잡한 로직이 적용되었습니다. 결과적으로 멀티시그 주소가 더 간결해지고 관리하기 훨씬 쉬워졌습니다.
• 블록 및 테스트 계수(BIP-34, BIP-65, BIP-66): 세 차례의 개별 업그레이드를 통해 코인베이스 거래의 블록 높이, 시간 잠금 출력 및 서명 토큰화와 관련된 특정 규칙이 강화되었습니다. 각 업그레이드는 업데이트된 노드에서 더 엄격한 기준을 적용하도록 했으며, 기존 노드는 온체인에 그대로 유지되었습니다.
• SegWit (BIP-141, 2017): 역대 가장 정치적으로 논란이 많았던 비트코인 ​​업그레이드인 세그윗(SegWit)은 거래 서명을 별도의 데이터 구조로 옮겨 블록 크기 제한을 늘리지 않고도 블록 공간을 확보했습니다. 또한 거래 ID가 확인 전에 변경될 수 있었던 취약점인 거래 변조 문제를 해결했고, 라이트닝 네트워크와 같은 결제 채널을 처음으로 사용할 수 있게 했습니다. 기술적으로는 성공적인 업그레이드였지만, 정치적으로는 커뮤니티를 거의 분열시킬 뻔했고 결국 비트코인 ​​캐시 하드포크로 이어졌습니다.
• Taproot(BIP-341 및 BIP-342, 2021): 슈노르 서명, MAST 스타일 스크립트 개인정보 보호, 그리고 탭스크립트가 하나의 업그레이드로 통합되었습니다. 탭루트 호환 지갑을 사용하면 복잡한 다자간 거래를 단순한 단일 서명 온체인 거래처럼 보이게 할 수 있습니다. 이는 개인정보 보호와 효율성 측면에서 상당한 이점을 제공합니다. 탭루트는 순조롭게 구현되었지만, 지갑, 인프라 제공업체, 스크립트 개발자들이 모두 개별적으로 업데이트해야 했기 때문에 실제 도입은 더디게 진행되었습니다.
• 라이트코인 SegWit (2017): 라이트코인은 비트코인보다 몇 달 앞서 세그윗을 구현했는데, 이는 부분적으로 라이트코인 커뮤니티의 이해관계자가 더 적고 이해관계가 다양했기 때문입니다. 동일한 기술적 업그레이드였지만 정치적 환경이 달랐기에 더 빠른 결과를 얻을 수 있었습니다.

세그윗(SegWit)은 경고의 사례입니다. 프로토콜 수준에서는 하위 호환성을 유지했지만, 블록 크기, 채굴 수수료, 개발 통제권을 둘러싼 논란으로 인해 비트코인 ​​역사상 가장 논쟁적인 순간 중 하나가 되었습니다 . 반면 탭루트(Taproot)는 정반대의 사례를 보여줍니다. 폭넓은 지지, 원활한 활성화, 그리고 점진적인 도입이 이루어졌습니다. 소프트 포크의 기술적 정의만으로는 정책적 혼란의 심각성을 제대로 설명할 수 없습니다.

"하위 호환성"이라는 용어는 순전히 기술적인 설명일 뿐이며, 디지털 커뮤니티의 미래 행동 방식을 예측하는 것은 결코 아닙니다.

문제는 기존 노드들이 이전 규칙을 준수하는 블록을 수용한다는 점입니다. 하지만 기존 노드가 수용하는 모든 블록이 더 엄격해진 새로운 규칙을 준수하는 것은 아닙니다. 업데이트된 규칙을 따르는 채굴자와 그렇지 않은 채굴자가 동시에 충돌하는 블록을 생성하면 단기적인 포크가 발생합니다. 이는 2015년 비트코인 ​​BIP-66 구현 과정에서 발생했던 현상과 정확히 일치합니다. 채굴자들이 블록을 검증하지 않고 생성하는 검증 없는 채굴 방식은 채굴자들이 수정하기 전까지(비트코인 옵텍의 소프트 업데이트 구현 시점) 간헐적인 포크를 유발했습니다.

거의 모든 논란이 많은 활성화 과정에서 동일한 갈등이 발생합니다.

• 활성화 임계값: 설정값을 너무 낮게 설정하면 승격은 빠르게 진행되지만 상당한 경쟁자를 놓치게 됩니다. 반대로 설정값을 너무 높게 설정하면 상대방이 시간을 끌면서 승격은 무기한으로 지연됩니다.
• 채굴자 신호: 해당 신호는 준비 상태를 나타내는 것이지만, 채굴자들은 이를 전략적으로 이용하여 제안을 지연시키거나 양보를 얻어낼 수 있습니다. 신호 자체가 실행을 의미하는 것은 아닙니다.
• 사용자 강제 적용: 풀노드 운영자는 채굴자가 지지 의사를 표시하더라도 채굴자가 생성한 블록을 거부할 수 있습니다. 이것이 바로 사용자 주도 소프트 포크의 의미입니다. 채굴자가 아닌 사용자가 결정하는 것입니다.
• 경제적 가중치: 거래소, 거래자, 수탁자 및 포트폴리오는 사람들이 실제로 돈을 쓸 수 있는 블록체인을 결정합니다. 이러한 경제적 비중은 두 블록체인이 경쟁할 때 어느 블록체인이 살아남을지를 결정하는 경우가 많습니다.
• 범위 확장: 규칙을 바꾸면 한 가지 문제는 해결되지만, 동시에 미래의 디자인 선택지를 조용히 배제하게 될 수 있습니다. 비평가들은 종종 이 점을 지적하며, 때로는 그들의 말이 맞습니다.

BIP-110은 현재 대표적인 사례입니다. 이 초안은 특정 데이터 필드에 대한 임시 합의 수준 제한을 제안합니다. 첫 번째 오퍼코드가 OP_RETURN이 아닌 경우 새로운 출력 스크립트 공개 키(scriptPubKey)는 34바이트로 제한되며, OP_RETURN인 경우에는 최대 83바이트까지 유효하게 유지됩니다. 지지자들은 이것이 풀 노드 비용과 비트코인의 금융 집중을 보호하는 간단한 소프트 포크라고 주장합니다. 그러나 비판론자들은 논란이 되는 활성화가 소수 체인을 고립시키거나 아직 발명되지 않은 합법적인 사용 사례를 막을 수 있다고 주장합니다. 두 가지 주장 모두 동시에 사실일 수 있습니다. 어떤 제안이든 소프트 포크에 대한 모든 기술적 정의 기준을 충족하더라도, 활성화가 시작되기 전에 경제 참여자들이 서로 반대되는 입장에 서게 되면 실제 분열의 위험을 내포할 수 있습니다.

대부분의 암호화폐 보유자에게 있어 깔끔한 소프트 포크는 소유권에 아무런 변화를 가져오지 않습니다. 업데이트된 체인은 기존 규칙에 따라 유효하므로 코인 잔액은 변경되지 않으며 지갑에서 즉각적인 조치를 취할 필요도 없습니다. 하지만 논란이 되고 있는 활성화 과정에서는 상황이 다릅니다. 어떤 체인이 주도권을 잡을지에 대한 불확실성 때문에 거래가 예상대로 확인되지 않을 수 있습니다.

지갑 포크에 대한 헤드라인보다는 해당 지갑을 지원하는 것이 더 중요합니다. 왜냐하면 지갑마다 업그레이드에 대한 반응 속도가 다르기 때문입니다.

• 비트코인 지갑 옵션은 새로운 주소 유형 지원 속도, 서명 워크플로, 수수료 도구 및 업그레이드 알림 기능에서 차이가 있습니다.
• 독립형 지갑은 사용자에게 프로그램과 키에 대한 제어권을 부여하지만, 백업 및 업그레이드 검증에 대한 책임도 사용자에게 있습니다.
• 콜드 하드웨어 지갑은 일일 활성화 노이즈에 덜 민감하지만, 포크 이후의 거래 유형과 연동하려면 펌웨어 지원, 관련 애플리케이션 또는 주소 형식 지정이 여전히 필요합니다.

대부분의 사용자에게 소프트 포크 활성화 시 확인해야 할 체크리스트는 간단합니다.

• 업그레이드가 일반 제출물에 영향을 미치는지 아니면 고급 스크립트에만 영향을 미치는지 확인하십시오.
• 소셜 미디어에서 새로운 화폐를 제공한다고 주장한다고 해서 무조건 송금하지 마세요. 소프트 포크는 새로운 화폐를 만들어내는 것이 아닙니다.
• 큰 금액을 송금하기 전에 지갑과 거래소 알림을 확인하세요.
• 논란이 되고 있는 활성화 방식이 안정될 때까지 기다린 후, 확인율이 낮은 결제 방식에 의존하십시오.
• 시드 구문은 오프라인에 보관하고, 업그레이드의 일부라고 주장하는 어떤 사이트에도 절대 입력하지 마십시오.

소프트 포크는 기존 코인의 소유권을 변경하지 않고도 향후 거래 방식을 바꿀 수 있습니다. 단, 새로운 규칙에 의해 제한되는 동작에 의존하는 특수 프로그램이나 고급 스크립트는 예외입니다. 따라서 지갑 개발자와 애플리케이션 개발자는 일반 코인 보유자보다 더 철저한 검토가 필요합니다.

현재 활발히 논의되고 있는 비트코인 ​​네트워크 업그레이드 관련 질문들은 크게 세 가지로 요약됩니다. 합의 계층 수준에서 네트워크를 어떻게 제한해야 하는가, 어떤 새로운 기능을 추가해야 하는가, 그리고 더 엄격한 규칙을 시행하기 전에 실제로 어느 정도의 합의가 필요한가입니다.

BIP는 단지 제안일 뿐입니다. BIP 번호는 구속력 있는 규칙을 의미하지 않습니다.

• 데이터 사용량 제한: BIP-110은 이러한 논쟁의 일부입니다. 이 제안은 채굴자들이 비트 4를 사용하여 신호를 보내고, 2,016 블록 기간 동안 55%의 승인 임계값을 설정하며, 무조건적인 최대 활성화 높이를 2026년 9월 1일경으로 설정하는 것을 제안합니다. 여기서 핵심 논쟁은 비트코인 ​​합의 계층이 체인에 기록되는 데이터를 모니터링해야 하는지, 그리고 문제가 발생할 경우 누가 비용을 부담해야 하는지에 관한 것입니다.
• 양자 준비 상태: BIP-360은 새로운 유형의 스크립트 트리 출력인 Pay-to-Merkle-Root 메커니즘을 제안합니다. 목표는 이 출력 설계에서 Taproot의 개인 키 경로 지출을 제거하여 양자 공격에 대한 장기적인 취약성을 줄이는 것입니다. 이는 기존 위협에 대한 긴급 조치가 아니라, 양자 컴퓨팅이 진정으로 위험해지기 전에 비트코인이 보안을 유지할 기간에 대한 설계 결정입니다.
• 언약: 비트코인 계약은 비트코인이 향후 생성되는 코인의 사용 방식에 조건을 부과할 수 있도록 허용합니다. 지지자들은 이를 비트코인 ​​금고, 트래픽 혼잡 제어 및 새로운 확장 경로의 기반으로 보고 있습니다. 그러나 비판론자들은 계약 시행 후 의도치 않은 제한과 분쟁이 발생할 수 있다고 우려합니다.

이러한 제안들을 유효한 규칙으로 간주하기 전에 다음 세 가지 사항을 확인해야 합니다. 첫째, 해당 제안이 아직 초안 단계인지, 아니면 배포, 설치 또는 활성화 단계로 넘어갔는지 확인해야 합니다. 둘째, 일반 지갑 이체에 영향을 미치는지, 아니면 고급 스크립트에만 영향을 미치는지 확인해야 합니다. 셋째, 활성화 경로가 개발자 지원에만 의존하는 것이 아니라 거래소, 지갑, 주요 노드 운영자로부터 실질적인 경제적 지원을 받고 있는지 확인해야 합니다.