“인플레보다 금리가 더 높다!” 블랙록 CIO의 강력한 경고: 연준, 지금 당장 금리 인하해야
블랙록 최고투자책임자(CIO)가 연준을 향해 금리 인하를 촉구하는 강력한 메시지를 발표했다. '인플레이션보다 금리가 훨씬 높다'는 그의 주장은 시장에 충격파를 던졌다.
금리 인하 압박이 거세지는 가운데, 연준의 다음 행보에 모든 이목이 집중되고 있다. 과연 중앙은행은 블랙록의 경고를 받아들일 것인가?
한편 월가의 전문가들은 "이번 주장은 분명히 정치적인 압력"이라며 냉소적인 반응을 보이고 있다. 언제나 그렇듯, 금융권의 '조언'에는 항상 숨은 의도가 있는 법이니까.
블록체인 불변성
블록체인 기술의 이론적 토대는 불변성이라는 이상에 깊이 뿌리내리고 있다. 블록체인은 모든 블록(또는 레저)이 암호학적으로 이전 블록을 참조하여 시간 순서대로 연결된, 공개적으로 감사 가능한 원장(장부)이라는 개념이다.
이 구조는 과거 데이터를 소급하여 변경하는 것을 불가능하게 만들어, 신뢰가 없는(trustless) 환경에서 신뢰를 구축하는 힘의 원천이 된다.
그러나 xrp 레저(XRPL)의 초기 역사에서 발생한 한 사건은 이러한 이상에 대한 중대한 의문을 제기한다. 바로 XRPL의 첫 3만2569개 레저, 즉 약 10일간의 거래 기록이 영구적으로 손실된 사건이다.
이 사건은 XRP 역사에서 아직도 논란이 되고 있다. 블록체인이라는 분산 시스템에서의 감사 가능성, 신뢰, 그리고 ‘제네시스(genesis)’의 본질에 대한 근본적인 질문을 제기한다.
XRPL 사건과 유사한 일이 비트코인과 이더리움에서도 있었다. 블록체인 커뮤니티에서 해당 사건을 어떻게 인식하는 지, 사건 발생 후 해결 과정, 이후 평가 등을 집중 분석했다.
또한, 블록체인 초기 개발 상황에서 개발자들이 직면하는 근본적인 딜레마를 살펴봤다. 이 문제는 단순한 해명을 넘어 블록체인 거버넌스와 철학에 대한 깊이 있는 통찰과 관련이 있다.
1. XRP 레저의 사라진 역사(레저 1~3만2569 번)
XRP 레저가 가동된 직후 10일 간의 기록이 없다. 손실된 것은 단순히 거래 기록 자체가 아니라, 첫 3만2569 개 레저의 헤더(header)였다. 레저 헤더는 한 레저를 다음 레저와 연결하는 결정적인 암호학적 해시값(parent_ledger_hash)을 포함한다.
헤더의 연결이 사슬처럼 이어지기 때문에 이 기술을 블록 ‘체인’이라고 부르는 것이다. ‘헤더의 체인’이 없으면, 해당 기간 발생한 534 개의 거래를 암호학적으로 검증하거나 정확한 순서로 배치할 수 없다.
데이터 손실은 XRPL이 2012년 6월에 출시된 후 그해 연말 사이에 발생했다. 공개적으로 검증 가능한 최초의 레저는 2013년 1월 1일 자로 기록된 3만2570 번이다. 다시 말해 XRPL의 제네시즈 블록은 0번이 아니라 3만2570 번이다.
리플 개발자들은 이후 이 레저를 “제네시스 레저”로 재명명했다. 최초의 기록이 없어졌기 때문에 사후적으로 제네시스 레저를 재정의한 것이다.
데이터는 영구적으로 복구 불가능한 것으로 보인다. 리플 CTO이 슈와츠도 이 점을 여러 차례 시인했다. 최초 10일 간의 기록을 되살릴 수 없다는 것.
2013년에 백업 데이터를 기반으로 역사를 재구성하려는 시도가 있었지만, 개발자들은 후속 레저들의 암호학적 증명과 완벽하게 일치하도록 재조립하는 데 실패했다. 유일하게 남은 흔적은 검증 가능한 레저 3만2570 번 헤더에 포함된 레저 3만2569 번의 해시값뿐이다.
리플(ripple)의 최고 기술 책임자(CTO) 데이비드 슈워츠(David Schwartz)가 제시한 설명은 이렇다. 리플 블록체인이 세상에 나올 때 개발 과정은 상당히 혼란스럽고, 파편적인 실험들의 연속이었다.
가장 널리 알려진 원인은 당시 네트워크를 운영하던 소수의 서버에서 “레저 헤더가 제대로 저장되지 않도록 하는 소프트웨어 버그”가 있었다는 것이다.
슈워츠는 “소프트웨어 버그로 인해 약 10일 분량의 레저가 손실되었다”고 확인했다.
초기 XRP 블록체인은 동시 다발적으로 데이터를 생산하고 있었다. 슈워츠는 이것이 단일하고 안정적인 운영 환경이 아니었다고 실토했다.
We created many ledger streams in the process of testing and develOPing the software. In one of many streams, a software bug caused some ledgers (about ten days) to be lost. All but the first 32k or so were recovered. We expected the next ledger reset to make the issue…
— David 'JoelKatz' SchwARtz (@JoelKatz) May 5, 2025
“개발팀은 소프트웨어를 테스트하고 개발하는 과정에서 많은 레저 스트림을 생성했으며, 데이터 손실은 이 스트림 중 하나에서 발생했는데, 불행히도 이것이 메인 체인이 되었습니다.”
슈워츠는 초기 개발 환경이 혼란스럽고, 지저분한 커밋 트리(cOMmit tree)를 공유했다고 밝혔다. 그와 공동 개발자 아서 브리토(Arthur Britto)는 작업을 조율하기 위해 “컴파일이 되지 않더라도” 코드를 자주 푸시했다고 언급했다.
이는 꼼꼼한 기록 보관보다는 속도와 반복을 우선시하는 개발 배경을 보여준다. 데이터 손실과 같은 사고는 용납되지는 않는다. 그러나 당시 개발 환경과 문화로 볼 때 어느 정도 이해되는 측면도 있다.
그렇다면 왜 리플 개발자들은 불완전한 레저를 유지하기로 결정했을까? 주된 이유 중 하나는 또 다른 “레저 리셋”이 곧 있을 것으로 예상했기 때문일 수 있다. 그러나 이 계획된 리셋은 결코 일어나지 않았다.
“깔끔함”을 위해 왜 처음부터 다시 시작하지 않았냐는 비판에 대한 슈워츠는 이렇게 말했다.
“손실된 정보를 복원하기 위해 우리가 할 수 있는 일은 아무것도 없었다. 처음부터 다시 하라는 말은 복구된 블록마저 버려서 더 많은 정보를 버려야 했었다고 말하는 것이다.”
슈와츠는 ‘실용적인 이유’로 손실된 데이터를 지니고 있는 XRP 레저를 그대로 가져간 것이라고 말한다. 이 같은 결정을 “결함의 수용이 아닌 데이터 보존 행위”로 규정한다. 즉, 완전한 무(無)의 역사보다는 부분적인 역사를 선택했다는 것이다.
개발팀은 복구 노력이 실패했음을 인정했다. 원시 거래 데이터는 살아남았지만 “어떤 거래가 어떤 레저에 들어갔는지에 대한 정보 없이 다른 거래들과 섞여 있었다”는 것.
이러한 기술적 장벽은 완벽한 재구성을 불가능하게 만들었고, 기존 작업을 살리려면 ‘실수를 품은 채’ 지속하는 것만이 유일한 길이었다는 해명이다.
이 부분에서 논란과 음모론이 싹튼다. 초기에 무슨 일이 있었는지 모르기 때문에 어떤 거래가 있었는지 감사할 수 없고, 그래서 사전 채굴(pre-mine) 문제가 나온다.
XRPL은 비트코인처럼 채굴되지 않았다. 1000억 개의 XRP 토큰은 2012년 6월 탄생과 동시에 “프리마인”되었다. 이 토큰들의 초기 분배는 레저가 손실된 기간 동안 발생했다.
따라서, 실제 제네시스 블록을 감사할 수 없다. 이것은 “대중이 네트워크 역사상 가장 중요한 거래(초기 코인 분배 등)와 관련된 데이터를 재구성할 수 없다”는 뜻이다. “누가 얼마나 많은 xrp 코인을 가져갔는지 모른다”는 음모론을 낳았다.
블록체인 상에 기록이 없기 때문에 XRPL 초기 상태에 대해서는 창립자들과 초기 운영자들의 진술에 의존해야만 한다. 그들의 말을 ‘신뢰’ 해야만 한다면 이는 블록체인 철학과 배치된다. 블록체인의 정신, 즉 “신뢰가 필요 없는 신뢰”를 정면으로 위반한다.
이 사건은 XRPL이 진정으로 탈중앙화되지 않았다는 주장의 근거로써 두고두고 논란을 일으키고 있다.
비평가들은 사라진 역사, 리플 랩스의 대규모 XRP 보유, 검증인 네트워크(UNL)의 과도한 영향력을 거론하며 “XRP가 탈중앙화된 커뮤니티 자산이라기보다는 핀테크 회사 리플 랩스사의 토큰에 불과하다”고 주장한다.
XRP에만 이같은 문제가 있는 것은 아니다. 비트코인과 이더리움에도 블록체인 불변성을 위협하는 유사한 사건들이 있었다.
시리즈 기사 2편에서는 이 문제들을 다룬다.
XRP 블록체인 3만2천 개 블록 사라졌다…리플 CTO, “개발 초기 소프트웨어 버그 있었다”
