리플(XRP) Ledger 운영사들은 목요일에 익숙한 종류의 "마감일 위기"에 직면하고 있습니다. 한 커뮤니티 추적기가 XRPL 서버 상당수가 곧 수정이 차단되어 업그레이드될 때까지 사실상 서비스가 중단될 것이라고 경고했기 때문입니다.
X 사용자 Krippenreiter는 "약 10시간 후 999개의 XRPL 서버 중 418개(!!)가 수정 차단으로 인해 다운될 것입니다!"라고 썼으며, 수정 차단된 리플 서버는 "원장의 유효성을 판단"하거나, "거래를 제출"하거나, "거래를 처리"하거나, " 합의 과정에 참여"할 수 없다고 덧붙였습니다.
이것이 리플(XRP) 원장에 영향을 미칠까요?
XRPL 거버넌스가 어떻게 작동하는지 직접 보지 않았다면 재앙처럼 들릴 수도 있습니다. 하지만 중요한 차이점은 이름에 그대로 드러나 있습니다. 수정 차단은 네트워크 장애 모드가 아니라 안전 장치입니다. 새로운 프로토콜 규칙이 활성화되면 기존 소프트웨어는 더 이상 원장을 안정적으로 해석할 수 없으므로, 네트워크는 해당 서버들이 추측하도록 내버려두는 대신 참여하지 않는 상태로 강제 전환합니다.
그렇다면 활동량이 급증할 경우 "서버의 거의 절반"이 수정 차단되는 것이 문제가 될까요? 크리펜라이터는 한 사용자에게 "전혀 그렇지 않습니다."라고 답했습니다. "모든 dUNL 검증자는 안전하므로 모든 '신뢰할 수 있는' 검증자는 예상대로 계속 검증을 수행할 것입니다. (그리고 부하가 걸린 상태에서도 정상적으로 작동합니다.) 그 외의 모든 경우에는 '수수료 인상(FeeEscalation)'이 적용됩니다." 그가 강조하는 요점은 합의 신뢰할 수 있는 검증자 집합에서 이루어지며, 수수료 인상은 원장이 바빠짐에 따라 거래 비용을 높여 스팸 및 과부하 시도를 차단하도록 설계되었다는 것입니다.
XRPL을 지켜보는 다른 사람들은 대부분 이를 심각한 문제가 아닌 일상적인 유지보수로 여겼습니다. 한 사용자는 "이게 특이하거나 위험한가요? 아니요. 거의 모든 수정 주기마다 발생하는 일입니다."라고 쓰면서 이전 변경 기간들을 나열하고, 지연된 노드는 일반적으로 나중에 업그레이드된다고 지적했습니다. XRPL 수정 프로세스 자체는 긴 준비 기간을 전제로 합니다. 수정 사항이 적용되려면 2주 동안 신뢰할 수 있는 검증자들로부터 지속적인 과반수 지지를 받아야 합니다.
하지만 시각적인 측면도 무시할 수 없습니다. 수백 개의 공용 서버가 동시에 다운되는 것은 지갑, 탐색기, 그리고 타사 인프라에 의존하는 기업들에게 실질적인 불편을 초래할 수 있습니다. 합의 원활하더라도 최신 노드 수가 줄어들면 엣지에서의 안정성이 떨어지고, 공용 엔드포인트가 더 취약해지며, 지원 요청이 늘어나고, "내 거래가 왜 처리되지 않나요?"라는 문의 글이 더 많이 올라올 수 있습니다.
그리고 구체적인 업그레이드 경로가 있습니다. XRPL.org의 rippled 2.6.2 릴리스 노트에는 새로운 fixDirectoryLimit 수정 사항과 중요한 버그 수정 사항이 설명되어 있습니다. 프로덕션 인프라를 운영하는 경우라면 이러한 수정 사항을 미루지 않고 처리해야 합니다.
숏 말해서, XRPL이 "서비스 종료"되는 것은 아닙니다. 하지만 2025년 말에도 여전히 구형 리플(ripple) 버전을 사용하고 있다면, 네트워크는 곧 업그레이드가 선택 사항이 아니라는 사실을 알려줄 것입니다.
보도 시점 현재 리플(XRP) 전반적인 시장 분위기와 함께 지난 24시간 동안 -1.5% 하락했습니다.
