XRP 원장 버그 중앙집중화 논쟁, 리플 변호사의 반론

2026년 10월 13일 읽는 시간 약 9분

XRP Ledger 재단은 최근 발생한 보안 버그에 대한 자세한 설명을 발표했습니다. 이 버그는 추가 XRP가 생성될 수 있었는지, 그리고 문제 해결 방식이 네트워크의 탈중앙화를 훼손했는지에 대한 우려를 불러일으켰습니다.

재단 측은 추가적인 XRP가 생성되지 않았다고 밝혔습니다.

또한 해당 취약점은 버전 3.4.1에서 수정되었으며 현재 XRP 공급량은 약 999억 8,600만 개라고 밝혔습니다.

이 발표는 XRPL 보안 및 탈중앙화에 대한 광범위한 논쟁에 빠르게 불을 지폈으며, 리플을 지지하는 변호사 빌 모건은 문제 해결을 위한 비공개 협력이 중앙 집중화 우려를 불러일으킨다는 비판에 반박했습니다.

XRP 레저 재단은 새로운 XRP가 생성되지 않았다고 밝혔습니다.

재단 측은 XRP의 총 공급량이 원장 출시 당시 1000억 개로 고정되어 있었으며, 해당 버그로 인해 그 규칙을 우회할 수 있는 가능성이 생겼다고 밝혔습니다.하지만 실제로 추가

XRP가 발행된 것은 아니라고 강조했습니다.

XRPL 잔액은 공개되어 있으므로 새로 생성된 토큰은 온체인에 나타나며 탐색기 및 데이터 플랫폼에서 추적할 수 있습니다.

재단 측은 원장을 지속적으로 모니터링해 왔으며, 네트워크 역사 전반에 걸쳐 공급량이 그대로 유지되었음을 확인했다고 밝혔습니다.

최근 XRP Ledger 보안 수정으로 인해 많은 질문과 오해가 발생했습니다. 이를 명확히 해 보겠습니다. 1. XRP가 새로 생성되었나요? 아닙니다. XRP Ledger 출시 당시 XRP의 총 공급량은 1,000억 개로 고정되었으며, 어떤 거래도 그 이상을 생성할 수 없습니다. 이번 버그는 해당 규칙을 우회하는 방법이었으며, 2주 전 3.4.1 버전에서 수정되었습니다. 하지만 이 부분을 굳이 믿으실 필요는 없습니다. 모든 Ledger 데이터는 공개되어 있으며, 탐색기와 데이터 사이트에서 매일 데이터를 읽고 있습니다. 새로운 XRP가 생성되면 모든 계정 잔액에 표시되어 누구나 확인할 수 있습니다. XRP Ledger에는 XRP가 숨겨진 곳이 없으며, 모든 잔액이 공개되어 있습니다. 저희는 XRP Ledger를 24시간 내내 모니터링하고 있으며, Ledger의 모든 역사를 통해 공급량을 검증해 왔습니다. 커뮤니티의 다른 구성원들도 이를 검증했으며, 누구든 직접 확인할 수 있습니다. 거래 수수료는 소멸되므로 공급량은 감소합니다. 현재 약 999억 8,600만 개의 XRP가 존재합니다. 2. 어떻게 이 문제가 발견되지 않았을까요? 앞으로 어떻게 될까요? 일반적인 결제 방식으로는 이 취약점을 발견할 가능성이 전혀 없습니다. 수백 건의 의도적인 공격 시도가 필요했습니다. AI는 이러한 버그를 악의적인 사용자든 선의의 사용자든 더 빠르게 찾아낼 수 있도록 만듭니다. RippleX 및 커뮤니티와 함께 XRP Ledger가 이러한 취약점으로부터 보호되도록 최선을 다할 것입니다. 이를 위해 형식 검증(Formal Verification)과 AI 기반 공격자 테스트를 대폭 적용하고, 보안 연구원들과 긴밀히 협력하며, 버그 바운티 프로그램을 강화할 것입니다. 앞으로 이와 관련하여 더 자세한 내용을 알려드리겠습니다. 3. XRP Ledger의 탈중앙화가 이 문제의 핵심입니다. 공개된 수정 사항은 공격자에게 버그 위치를 알려주고, AI는 이를 매우 빠르게 만듭니다. 일반적인 수정 투표 방식이었다면 수정 사항이 적용되기까지 몇 주가 걸렸을 것이며, 이는 네트워크 보안에 위험을 초래했을 것입니다. 이에 대응하여 XRPL 커뮤니티는 XRP Ledger 재단, RippleX, 핵심 개발자 및 검증자들이 함께 모여 사회적 합의를 도출하고 수정 사항을 직접 배포하는 방식을 채택했습니다. 운영 중인 네트워크에 패치를 적용하는 것은 결코 간단한 일이 아니므로, 모든 참여자에게 미치는 영향을 최소화하도록 계획을 세웠습니다. 각 검증자가 xrp-ledger.toml 파일에 게시한 연락처 정보를 사용하여 기본 UNL 검증자들에게 빌드를 공유했습니다. 공개 바이너리는 같은 날인 9월 25일에 배포되었습니다. 어느 한 주체가 단독으로 이 결정을 내릴 수는 없었습니다. 모든 검증자와 노드 운영자는 어떤 소프트웨어를 사용할지 선택하며, 3.4.1 버전은 2주 동안 80% 이상의 검증자 지지를 얻은 일반적인 수정안 투표를 통해서만 필수 버전이 되었습니다. 프로토콜 변경은 여전히 수정안을 통해 이루어집니다. 이 문제를 발견하고 책임감 있게 보고해 주신 Cayden Liao와 Veria AI, 수정 사항을 빌드하고 테스트해 주신 XRPL 코어 개발자, 그리고 특히 검증자를 포함하여 신속하게 업그레이드해 주신 모든 노드 운영자에게 큰 감사를 드립니다.

2026년 10월 11일

또한 거래 수수료는 소각되므로 총 XRP 공급량은 시간이 지남에 따라 점차 감소한다고 지적했습니다 .

그 벌레 자체는 특이했다.

재단 측은 일반적인 지불로는 해당 조항이 발동될 가능성이 전혀 없다고 밝혔습니다. 착취가 발생하려면 수백 건의 의도적인 작전이 필요했을 것이라고 덧붙였습니다.

그것이 바로 그 문제가 오랫동안 눈에 띄지 않았던 이유 중 하나입니다.

왜 이 문제가 비공개로 처리되었는가?

이 이야기에서 더 논란이 되는 부분은 패치가 배포된 방식입니다.

재단 측은 수정 작업이 완료되기 전에 취약점을 공개하면 공격자들이 원장을 악용할 수 있다고 설명했습니다.

인공지능 덕분에 코드 분석과 취약점 파악이 쉬워짐에 따라, 너무 일찍 세부 정보를 공개하는 것은 상당한 위험을 수반하는 것으로 여겨졌습니다.

따라서 XRPL 재단, RippleX, 핵심 개발자 및 검증자들은 수정 사항을 공개하기 전에 비공개로 협의했습니다.

버전 3.4.1은 먼저 기본 UNL의 검증자들에게 공유되었고, 같은 날 나중에 공개 바이너리가 배포되었습니다.

재단은 어느 한쪽도 업그레이드를 강제할 수 없다고 강조했습니다.

해당 버전은 일반적인 수정 절차가 2주 동안 80% 이상의 검증자 지지를 얻은 후에야 필수 버전이 되었습니다.

XRPL은 앞으로 형식 검증, AI 적대적 테스트, 보안 연구 협력 및 버그 현상금 프로그램을 확장할 계획입니다.

빌 모건, 중앙집권화 주장에 반박

빌 모건은 훨씬 더 강경한 어조로 말했다.

그는 비평가들이 버그와 그 수정 방식을 XRPL이 중앙집권적이라는 증거로 사용하는 것에 지쳤다고 말했다.

저는 XRPL을 싫어하는 악의적인 사람들이 XRP 생성의 원인이 되었을 가능성이 있는 버그와 그 문제 해결 방식을 빌미로 XRPL이 중앙집중화되어 있다고 깎아내리는 이야기를 듣는 데 진절머리가 났습니다. 이는 XRP 커뮤니티 외부 사람들이 10년 넘게 XRPL의 탈중앙화 원칙을 공격해 온 맥락에서 볼 수 있습니다. 하지만 저는 이 비판자들이 정의하는 탈중앙화의 의미에 대해 다시 한번 묻고 싶습니다. 만약 탈중앙화란 커뮤니티 내 전문가들이 모여 심각한 버그를 비공개로 수정할 수 없다는 것을 의미한다면, 즉 문제가 해결되기 전에 공개되면 악의적인 사람들이 취약점을 악용할 기회를 주기 때문이라면, 그들이 정의하는 탈중앙화는 무엇일까요? 무정부 상태나 혼돈은 절대 아닙니다. 그런 상태로는 개인 투자자든 기관 투자자든 누구도 끌어들일 수 없습니다. 어쨌든, 제 생각에 문제 해결 방식은 탈중앙화 개념과는 무관합니다. 오히려 보안과 정보 공개의 문제입니다. 해결책은 구현된 후에 공개되었습니다. 그것은 위장된 것이 아니었습니다. 전문성을 갖춘 선의의 사람들이 악의적인 사람들이 악용하기 전에 문제를 해결했습니다. 문제가 무엇인가요?— 빌 모건

2026년 10월 12일

모건은 이러한 상황을 오히려 보안과 정보 공개의 문제로 봐야 한다고 주장했다.

그의 주장은 간단합니다. 분산된 커뮤니티의 지식 있는 구성원들이 공격자가 악용하기 전에 위험한 취약점을 해결하기 위해 비공개적으로 협력할 수 없다면, 현재 사용되고 있는 분산화의 정의는 비현실적이라는 것입니다.

그는 또한 해당 수정 사항이 배포 후 공개적으로 발표되었으며 영구적으로 숨겨진 것이 아니라고 강조했습니다.

그 차이점은 중요합니다.

긴급 보안 조치에 대한 비공개적인 협력이 특정 주체가 네트워크를 통제한다는 것을 의미하는 것은 아닙니다.

더 중요한 기준은 어느 한쪽 당사자가 독자적으로 의정서 변경을 강행할 수 있는지 여부입니다.

이 경우에도 검증기관은 해당 소프트웨어를 도입해야 했고, 수정 절차에는 80% 이상의 지지가 필요했습니다.