David Schwartz, 속도 저하 이후 레저 전체를 멈출 수 있는 시나리오 2가지 제시

속도 저하 뒤에 정지는 없었다

XRP 레저는 거래 처리 속도가 느려졌지만 네트워크 정지로 이어지지 않았다. 지난 24시간 동안 거래가 평소보다 눈에 띄게 느리게 처리됐고, 레저는 평소 리듬에서 상당히 벗어난 상태로 계속 마감과 검증을 반복했다. XRP 레저 운영팀이 이례 현상을 처음 기록했고, 레저 마감이 정상 속도보다 뚜렷하게 늦어지면서 엔지니어들이 지연 원인 추적에 나섰다. 이번 사태는 커뮤니티 안에서 분산 구조의 스트레스 내성에 대한 의문을 낳았다. Ripple의 전 최고기술책임자이자 시스템 개발자 중 한 명인 David Schwartz가 사건 이후 공개 평가로 이 질문에 답했다. 그는 XRPL 소프트웨어가 다층 보안 구조로 보호돼 있으며 네트워크 전체를 멈출 수 있는 시나리오는 두 가지뿐이라고 말했다. 첫째는 전 세계 검증인 서버의 대규모 동시 장애인데, 그는 이를 규모의 전례 없는 자연재해가 발생했을 때만 상상 가능한 그림으로 묘사했다. 둘째는 합의 알고리즘 내부에 결함이 생기거나 프로토콜 핵심 기능의 코드 수준 손상이 발생하는 경우다. 이번 사건에서는 어느 쪽도 발생하지 않았다. 그의 판단으로 실제 일어난 일은 기술 안전마진의 축소였고, 이번에 기록된 라운드 지연은 표적 공격이거나 코드 안쪽에서 작동한 숨은 버그를 가리킬 수 있다고 그는 밝혔다. Schwartz는 또한 네트워크가 단일 노드나 중심에 의존한다는 주장도 일축했다. XRPL은 완전히 분산된 구조로 운영되며, 자신의 노드를 포함한 주요 센터가 중단되거나 과부하에 걸려도 네트워크 전체 운영에 직접적인 영향을 주지 않는다는 것이다. 이 블록체인의 합의 절차는 다른 일부 네트워크가 채택한 위임 지분 증명 모델을 따르지 않으면서도 폭넓은 검증인 합의 위에 놓여 있다. XRP 네트워크는 Ripple과 독립된 오픈소스 메인넷에서 결제와 DeFi 활동을 처리하며, Ripple은 이 생태계를 위해 결제 인프라와 블록체인 기반 금융 솔루션을 구축하고 있다. 이 분야는 지금 payfi로 불린다.

가장 중요한 순간에 진단이 멈췄다

이번 사태에서 가장 구체적인 피해는 레저가 아니라 진단 체계에서 나왔다. 합의 라운드가 느려지자 검증인들이 일제히 최대 부하 상태로 전환됐다. Schwartz 본인의 노드는 요청 트래픽을 견디지 못했고, 소프트웨어가 원격 시스템에 데이터를 요청하거나 명령을 실행하는 통로인 로컬 RPC 연결은 CLOSE_WAIT 상태에 갇혔다. 이 상태는 상대방이 보낸 종료 신호를 연결이 받아들였지만 로컬 프로세스가 아직 끝내지 못한 경우를 말한다. 이런 상태의 연결은 로컬 쪽에서 소켓을 계속 점유하며, 트래픽 폭증 시 충분히 쌓이면 노드가 새 요청에 응답하는 데 필요한 자원을 고갈시킬 수 있다. 이 잠김 때문에 그의 내부 모니터링 시스템은 가장 중요한 시점에 진단 데이터를 기록하거나 전송하지 못했다. 엔지니어는 결함의 정확한 원인을 확정하지 못한 채 서버를 재시작해야 했고, 그는 사건 회고에서 이를 솔직하게 밝혔다. 점검 과정에서 별도의 사실도 드러났다. 레저 개발자 중 한 명이 운영하는 센터가 자신의 로그 기록을 XRP Ledger Foundation의 낡은 테스트 호스트로 보내고 있었던 것이다. 이 라우팅은 사건 기간의 기록이 운영 경로 밖으로 빠지게 만들어 완전한 데이터 수집을 더욱 어렵게 했다. 엔지니어링 인력과 커뮤니티 운영자들은 지금 남은 로그를 수작업으로 훑으며 오류를 분리해내고 있다. Schwartz가 정리한 현재 상황은 이렇다. 안전마진은 일시적으로 좁아졌고, 팀은 상황을 통제 범위 안에 두었으며, 네트워크 아키텍처에는 계속 운영할 만한 기술적 여력이 충분하다. 그러나 여기서 확정된 사실은 없다. 확인된 코드 결함이 지목된 바 없고, 정지는 발생하지 않았으며, 반복되는 속도 저하도 기록에 없다. 종료된 지연, 멈춘 진단, 아직 수작업으로 분리 중인 원인. 부재의 목록이 이 사건의 현재 모습이다.

합의 전에 관측 기능이 먼저 무너졌다

합의는 버텼고 관측 기능은 버티지 못했다. Schwartz의 회고에서 남길 가치가 있는 결론은 이 분리다. 근거는 1차 기록에 있다. 그의 노드 로그와 로그가 담지 못한 것들이다. 네트워크는 설계 의도대로 움직였다. 검증인을 최대 부하까지 밀어올린 스트레스 정점을 흡수하면서도 정지하지 않았고, 그 상황을 지켜보도록 만들어진 계층이 먼저 무너졌다. 이 사건이 단순한 에피소드에서 사건으로 바뀌는 조건은 구체적이다. 합의 코드의 확인된 결함, 또는 정상 작동하는 진단 데이터와 비교할 수 있는 두 번째 속도 저하다. 둘 다 아직 기록에 없다. 시장 반응은 이 이야기의 밖에 있다. 시장 쪽은 XRP 기술적 분석이 다룬다. 수작업 로그 검토가 원인을 밝혀내기 전까지, 좁아진 마진은 관측된 사실로 남고 아직 설명된 상태는 아니다.