리플, XRPL 노드 장애 막는 패치 배포…‘새 GPG 키 신뢰’ 요구 논란

리플(Ripple)이 이번 주 XRP 레저(XRP Ledger) 네트워크의 핵심 서버 구현체인 ‘rippled’ 3.1.2 버전을 배포하며, 퍼블릭(외부 노출) 노드에서 발생할 수 있는 장애를 막기 위한 수정안을 내놨다. 다만 이번 패치 적용을 위해 노드 운영자가 리플의 새로운 GPG 서명 키를 ‘신뢰(trust)’로 등록해야 한다는 점이 함께 강조되면서, XRPL 운영 구조의 의존성이 다시 부각됐다.

XRP 레저 재단(XRP Ledger Foundation)은 공지에서 노드 운영자들에게 “가능한 한 빨리 업데이트하라”고 권고했다. 핵심은 단순 버전 업그레이드가 아니라 ‘새 키를 내려받아 신뢰’하는 절차다. 재단은 “리플이 rippled 패키지 서명에 사용하던 GPG 키를 교체했다”며 “기존 설치 사용자는 문제를 방지하기 위해 새 키를 다운로드하고 신뢰해야 한다”고 밝혔다.

문제는 노드가 새 키를 신뢰하지 않을 경우 특정 ‘엣지 케이스(edge case·극단적/예외적 상황)’에서 rippled가 XRP 레저의 일부 상태를 잘못 처리하면서, 내부 함수인 ‘LogicError’를 호출할 수 있다는 점이다. LogicError는 abort 명령을 실행하도록 설계돼 있어, 쉽게 말해 노드가 예외 상황을 복구 처리하는 대신 ‘자기 자신을 중단’시키는 형태로 종료될 수 있다. 이 버그 수정은 리플X 엔지니어 마유카 바다리(Mayukha Vadari)가 반영했다.

리플은 변경 사항을 “예외 처리를 개선하기 위한 ‘리팩터(refactor)’”로 표현했지만, 관련 풀 리퀘스트(PR) 설명에는 “엣지 케이스 발생 시 반환(return)하도록 하기 위한 목적”이 드러난다. LogicError로 인한 크래시는 서버 프로세스를 즉시 종료시키며, 재단도 “퍼블릭 노드에서 아웃티지(outage·가동 중단)를 유발할 수 있는 엣지 케이스”라고 지칭했다.

패치 적용의 전제 조건…‘리플 새 GPG 키 신뢰’가 핵심

대다수 노드 운영자가 리플이 제공하는 패키지를 쓰는 만큼, 운영자들은 리플이 최근 교체한 GPG 서명 키를 내려받아 신뢰 목록에 추가해야 한다. 이를 누락하면 자동 업그레이드가 ‘조용히 실패(silently fail)’할 수 있다는 게 공지의 요지다. 새로 교체된 키는 “TechOps Team at Ripple” 명의이며, 만료 시점은 2033년으로 설정돼 있다.

rippled가 사실상 XRPL에서 유일한 ‘프로덕션급(상용 수준)’ 서버 구현체라는 점도 이번 이슈의 파급력을 키운다. 결과적으로 거의 모든 운영자가 리플의 새로운 암호학적 신원(서명 키)을 신뢰해야만, 리플 코드에서 비롯된 버그 패치를 안정적으로 받을 수 있는 구조다.

이 대목은 브래드 갈링하우스(Brad Garlinghouse) 리플 CEO가 “리플은 XRP를 통제하지 않는다”고 강조해온 메시지와도 미묘한 긴장을 만든다. 토큰의 발행·보유와 별개로, 실무적으로는 네트워크 운영에서 핵심 소프트웨어 배포 체계가 중앙화된 서명 키 신뢰 모델 위에 서 있다는 지적이 반복될 여지를 남긴다.

XRPL 안정성 논란 재점화…잇단 버그 이력

XRPL의 노드 안정성 이슈는 이번이 처음이 아니다. 2024년 9월에는 SQLite 버그로 ‘풀 히스토리(full history) 노드’가 크래시를 겪었고, 그로부터 몇 달 뒤에는 악성 트랜잭션이 캐싱 버그를 악용해 노드를 다운시킬 수 있었던 사례도 언급됐다. 2025년 2월에는 네트워크가 약 1시간 동안 블록 생성을 멈춘 일도 있었다. 또 이번 패치 직전에는 AI 보안 도구가 또 다른 ‘치명적 결함’을 발견했다는 내용이 전해졌다.

이번 결함은 XRPL 커먼즈(XRPL Commons) 소속 3명이 발견해 악용 없이 책임 공개(responsible disclosure) 방식으로 공유했다. XRPL 커먼즈는 프랑스 파리에 기반을 둔 비영리 단체로, XRP 레저 교육과 개발을 지원한다. 릴리스 노트에는 전 헤지펀드 매니저 출신 개발자 뤽 보카우(Luc Bocahut), 공학도 로맹 테포(Romain Thépaut), XRPL 커먼즈 기술 파트너 토마스 위세네(Thomas Hussenet)의 기여가 반영됐다고 적시됐다.

재단의 기본 유니크 노드 리스트(UNL·합의에 참여하는 검증자 목록)에는 35개 밸리데이터가 포함돼 있으며, 이들이 원장을 계속 전진시키고 있다는 점도 함께 언급됐다. 다만 퍼블릭 노드 운영 환경에서 ‘엣지 케이스’가 실제 아웃티지로 이어질 수 있다는 경고가 나온 만큼, 이번 rippled 업데이트와 GPG 키 신뢰 절차는 단순 권고가 아니라 사실상의 필수 조치로 받아들여질 가능성이 크다.

기사요약 by TokenPost.ai

🔎 시장 해석

- 리플이 XRPL 핵심 서버 구현체 ‘rippled’ 3.1.2를 배포하며, 퍼블릭 노드에서 발생 가능한 크래시(가동 중단) 리스크를 낮추는 패치를 적용

- 다만 업데이트 성공의 전제 조건이 ‘리플의 새 GPG 서명 키 신뢰 등록’에 달려 있어, 소프트웨어 배포 신뢰 모델이 리플에 집중돼 있다는 구조적 의존성이 재부각

- “리플은 XRP를 통제하지 않는다”는 메시지와 달리, 운영 실무(코드 배포·서명 체계) 측면의 중앙화 논쟁이 다시 커질 여지

💡 전략 포인트

- 노드 운영자: rippled 3.1.2 업데이트와 함께 ‘TechOps Team at Ripple’ 신규 GPG 키를 다운로드 후 신뢰(trust)로 등록(미등록 시 자동 업그레이드가 조용히 실패할 수 있음)

- 거래소·인프라 사업자: 퍼블릭 노드 장애(outage)가 서비스 영향으로 직결될 수 있으므로, 업데이트 적용 여부 점검 + 장애 대응(프로세스 재시작/모니터링) 강화

- 커뮤니티/거버넌스 관점: 단일 프로덕션급 구현체(rippled)와 서명 키 교체 프로세스가 네트워크 운영 안정성에 미치는 영향(집중/분산)을 점검할 필요

📘 용어정리

- GPG 서명 키: 배포되는 패키지가 ‘진짜 제작자’가 서명한 것인지 검증하는 암호학적 신원(서명) 수단

- 퍼블릭 노드(public node): 외부에 공개되어 요청을 처리하는 노드(장애 시 사용자/서비스 영향이 큼)

- 엣지 케이스(edge case): 일반적이지 않은 극단적·예외적 입력/상황

- LogicError: 예외 상황에서 호출되는 내부 오류 처리(이번 이슈에선 abort로 이어져 프로세스가 종료될 수 있음)

- UNL(Unique Node List): XRPL 합의에 참여하는 검증자(밸리데이터) 목록

💡 자주 묻는 질문 (FAQ)

Q.

이번 rippled 3.1.2 업데이트에서 가장 중요한 조치는 무엇인가요?

단순 버전 업그레이드뿐 아니라, 리플이 새로 교체한 GPG 서명 키(“TechOps Team at Ripple”)를 내려받아 ‘신뢰(trust)’로 등록하는 절차가 핵심입니다. 이를 누락하면 자동 업데이트가 조용히 실패할 수 있습니다.

Q.

패치하지 않으면 어떤 문제가 생길 수 있나요?

특정 엣지 케이스에서 노드가 XRP 레저 상태를 잘못 처리하며 LogicError를 호출할 수 있고, 그 결과 abort로 프로세스가 종료(크래시)되어 퍼블릭 노드 가동 중단(outage)으로 이어질 수 있습니다.

Q.

‘리플이 XRP를 통제하지 않는다’는 말과 이번 이슈는 어떤 관련이 있나요?

XRP 토큰의 발행·보유와 별개로, XRPL에서 사실상 유일한 프로덕션급 서버 구현체(rippled)와 그 배포 서명 키를 다수가 신뢰해야 패치를 받을 수 있다는 점에서 운영 실무 측면의 의존성이 드러납니다. 이 때문에 네트워크 운영의 중앙화/분산화 논의가 다시 제기될 수 있습니다.

TP AI 유의사항

TokenPost.ai 기반 언어 모델을 사용하여 기사를 요약했습니다. 본문의 주요 내용이 제외되거나 사실과 다를 수 있습니다.