“솔라나가 또 멈췄다”는 소식에서 실제 장애를 가려내는 법

“솔라나가 또 멈췄다”는 신호가 나온 뒤에도 슬롯이 계속 생성되는 경우와, 슬롯 생성 자체가 멈춘 경우는 구분해야 한다. 지갑 화면이 멎거나 거래가 실패한 상태와 실제 원장 중단은 서로 다른 사건이다. 이 글은 가격 전망이 아니라 확인 순서와 그 한계를 다룬다.

지갑 앱의 정지와 솔라나 원장의 정지는 다른 사건이다

지갑 잔고가 안 보이거나 거래 한 건이 실패했다는 사실만으로는 원장이 멈췄다고 판정할 수 없다. 먼저 슬롯이 계속 올라가는지 보고, 장애가 한 서비스에 머무는지 여러 검증인에 걸쳐 나타나는지를 확인해야 한다.

장애는 앱 표시 오류, RPC 사업자 장애, 네트워크 성능 저하, 원장 전면 중단으로 나눌 수 있다. 슬롯이 계속 생성되는지, 거래가 원장에 포함되는지, 공식 상태 기록이 있는지가 판단 기준이며, 캡처만으로 알 수 없는 내용은 추정할 수 없다.

핵심은 주어다. 지갑 앱이 멈춘 것과 솔라나 원장이 멈춘 것은 서로 다른 사건이다. 거래 지연도 별개다.

확인에는 세 질문이 남는다. 공식 기록으로 확정됐는가, 합의나 거래 처리 구조에 영향을 줬는가, 시작과 종료 시각이 있는가. “곧 복구”나 “또 장애”에는 판정할 시간이 없다.

잔고가 안 보일 때 어디까지 고장 난 것인가

사용자가 보는 화면과 원장은 한 덩어리가 아니다. 지갑 앱은 특정 RPC 사업자에게 잔액과 거래 기록을 요청하고, 그 사업자는 검증인들이 공유하는 원장 데이터를 읽어 돌려준다. 중간 응답이 늦으면 화면은 멎을 수 있다.

원장은 살아 있을 수 있다.

장애 범위는 네 층으로 나눌 수 있다. 앱의 표시 오류는 해당 화면에서만 나타나고, RPC 장애는 같은 접속 경로를 쓰는 여러 사용자에게 번진다. 성능 저하에서는 슬롯이 진행돼도 일부 거래가 지연되거나 실패한다. 전면 중단은 슬롯 생성 자체가 멈추고 검증인들의 재시작 협의가 필요한 사건이다.

따라서 캡처는 출발점일 뿐이다. 어느 앱인지, 어느 RPC를 쓰는지, 같은 시각 다른 탐색기에서도 현상이 반복되는지 확인하지 않으면 고장 난 층을 특정할 수 없다.

‘솔라나’라는 이름의 주체도 갈라야 한다. 재단의 공지, 개발 조직의 설명, 검증인들의 원장 상태, SOL 가격은 같은 사실을 말하지 않는다. 어느 주체가 무엇을 발표했는지가 빠진 문장은 범위가 지나치게 넓다.

슬롯 번호는 왜 첫 번째 확인값인가

솔라나 원장은 거래를 일정한 순서로 묶어 기록한다. 탐색기의 최신 슬롯 번호가 몇 차례 새로고침 뒤에도 계속 증가한다면 적어도 새 원장 기록이 만들어지고 있다는 사실은 확인할 수 있다. 시계부터 본다.

다만 슬롯 상승은 모든 거래의 성공을 보장하지 않는다. 사용자가 낸 수수료, 거래 유효기간, 계정 잠금 충돌, 혼잡 상태에 따라 개별 거래는 실패할 수 있다. 원장의 생존과 내 거래의 성공은 다른 판정이다.

반대 상황도 조심해야 한다. 탐색기 자체가 늦게 갱신되면 실제 원장은 진행되는데 화면의 슬롯이 잠시 고정돼 보일 수 있다. 탐색기 하나만 보면 오판한다.

그래서 두 곳 이상을 대조한다. 공식 상태 페이지의 사건 기록과 서로 다른 접속 경로를 쓰는 탐색기에서 슬롯 진행을 함께 확인하면 단일 사업자의 장애를 원장 중단으로 확대할 가능성이 줄어든다. 그래도 완전한 증명은 아니다.

온체인 기록으로 확인할 수 있는 것은 슬롯과 거래 포함 여부다. 운영자가 왜 응답하지 않았는지, 어느 서버가 먼저 고장 났는지, 복구 예상 시각이 맞는지는 원장 데이터만으로 알 수 없다.

과거 중단 기록은 어떤 기준으로 세야 하나

솔라나 메인넷이 실제로 멈춘 적은 있다. 2020년 12월부터 2024년 2월 6일까지 공식 사건 기록과 헬리우스 정리에서 슬롯 생성 중단 뒤 검증인 재시작이 필요했던 사례를 같은 기준으로 세면 표본은 7건이다. 집계별 지속 시간에는 차이가 있다.

짧지 않았다. 기록상 중단 시간은 약 4시간 반에서 19시간 사이였으며 시작과 복구 시각을 어느 지점으로 잡느냐에 따라 수치가 달라진다. 단일 RPC 장애와 혼잡만 있었던 날은 이 표본에서 뺐다.

같은 판정 기준으로 2024년 2월 7일부터 2026년 9월 7일까지 공식 상태 기록을 확인하면 새 전면 중단 항목은 없었다. 관찰 기간은 약 2년 7개월이고 표본은 공식 사건 기록 전체다. 그렇다고 위험이 사라진 것은 아니다.

그 기간에도 거래 실패율이 높아진 혼잡과 특정 지갑·RPC·거래소의 장애는 있었다. 이것이 실패 사례다. “사용할 수 없었다”는 이용자의 경험은 사실일 수 있지만, 그 사실이 곧 “원장이 정지했다”는 판정으로 이어지지는 않는다.

슬롯이 오르는데 거래가 실패하면 정상인가

정상이라는 한 단어로 묶기 어렵다. 합의는 이어졌지만 거래 처리 품질이 나빠졌을 수 있다. 원장 중단은 아니어도 사용자에게는 실제 손실과 불편이 생긴다.

구분은 책임을 흐리기 위한 것이 아니다. 복구 방법이 달라진다. 앱 오류라면 화면과 캐시를 확인하고, RPC 장애라면 다른 접속 경로와 사업자 상태를 살핀다. 혼잡이라면 실패 거래 비율과 원장 포함 시간을 본다. 전면 중단이라면 공식 사건 기록과 검증인 재시작 여부가 기준이다.

여기에도 한계가 있다. 슬롯이 오른다는 사실은 네트워크의 일부 기능이 작동한다는 근거지만 처리량과 사용자 체감이 평소 수준이라는 증거는 아니다. “살아 있다”와 “원활하다” 사이에는 넓은 구간이 있다.

사후 정보도 섞지 않아야 한다. 장애가 의심된 순간에 알 수 있는 것은 당시 슬롯 진행과 공개된 상태 공지뿐이다. 정확한 원인과 영향 범위는 복구 뒤 나온 분석에서 확인된다.

‘또 멈췄다’는 문장을 어디까지 줄여 써야 하나

뉴스를 읽고 남길 문장은 사건의 층과 판정 시점을 담아야 한다. “오전 9시부터 특정 지갑의 RPC 응답이 지연됐지만 두 탐색기에서는 슬롯 생성이 이어졌고, 공식 상태 페이지에는 전면 중단이 기록되지 않았다”처럼 쓰면 확인한 사실의 경계가 보인다.

확인되지 않은 원인은 뺀다. 검증인 문제인지 공격인지 단순한 사업자 장애인지 자료가 나오지 않았다면 그대로 남겨 둔다. 모른다는 것도 결론이다.

최종 분류는 네 가지면 충분하다. 앱 표시 오류, RPC 사업자 장애, 원장이 진행되는 성능 저하, 슬롯이 멈춘 전면 중단이다. 이 분류는 SOL의 다음 가격을 알려주지 않는다. 다만 캡처 한 장이 네트워크 전체의 사실로 커지는 일을 막아 준다.

장애가 원장 바깥에서 시작된 뒤 검증인 운영과 네트워크 구조에 어디까지 영향을 미치는지는 별도 점검이 필요하다. 공식 기록과 루머의 시점을 맞추는 방법은 『솔라나의 모든것』 9장 ‘뉴스와 소음’에서 이어서 확인할 수 있다.