솔라나 코인 시세 전망 지분 29%가 30분간 오프라인: 네트워크는 왜 멈추지 않았나

2026년 8월 12일 솔라나에서 보기 드문 인프라 사고가 발생했다. 가장 큰 호스팅 인프라 제공업체인 Teraswitch의 라우팅 오류로 전체 스테이킹 지분의 약 29%를 대표하는 검증인들이 동시에 네트워크 연결을 잃었다.

그런데 솔라나 블록체인은 완전히 정지하지 않았다. 블록은 계속 만들어졌고 이용자가 보낸 거래도 네트워크에 들어갔다. 공식 기록상 가동률도 100%로 유지됐다. 겉으로 보면 “장애가 있었지만 아무 문제도 없었다”는 결론을 내리기 쉽다.

실제 상황은 그보다 복잡했다. 독립 분석업체 Metrika의 관측에 따르면 약 30분 동안 새로 만들어진 블록이 최종 확정 단계에 도달하지 못했고, 투표 거래를 제외한 실제 처리량은 평소 초당 1,100~1,300건 수준에서 300건 미만으로 떨어졌다. 블록 생성은 이어졌지만 금융 거래에서 중요한 최종성은 크게 지연된 것이다.

이번 사고는 솔라나가 단일 인프라 장애를 견뎠다는 회복력과, 많은 검증인이 같은 호스팅·네트워크 경로를 공유할 때 생기는 집중 위험을 동시에 보여준다.

이 글은 2026년 9월 16일까지 공개된 Solana Foundation, Metrika 및 Teraswitch 사고 자료를 바탕으로 작성고 장애 당시의 지분과 성능 수치는 관측 방식에 따라 소폭 달라질 수 있습니다.

핵심 내용 먼저 보기

항목	장애 당시 관측	의미
오프라인 지분	28.83%	검증인 개수가 아닌 해당 검증인들이 대표한 스테이킹 지분 비율
영향을 받은 검증인	약 90개	동일 인프라 경로의 장애가 여러 지역으로 확산
최종성 중단 기준	33.34% 오프라인	3분의 1 이상 투표 지분이 빠지면 정상적인 최종 확정이 멈출 수 있음
남은 완충 폭	약 4.51%포인트	Metrika 추산 약 2,000만 스테이킹 SOL
전체 복구	약 33분	Teraswitch 알림부터 전체 서비스 복구까지의 보고 시간
블록 생성	계속 진행	체인 전체가 멈춘 전면 장애는 아니었음
새 블록 최종 확정	약 30분 공백	거래가 보여도 되돌릴 수 없는 상태로 확정되기까지 지연

8월 12일 솔라나에서 무슨 일이 발생했나

Metrika는 사고가 8월 12일 약 03시 43분(UTC)에 시작된 것으로 분석했다. Teraswitch의 마이애미 데이터센터에서 잘못된 인터넷 경로가 전파됐고, 영향은 런던·암스테르담·프랑크푸르트·싱가포르·도쿄의 검증인 인프라까지 퍼졌다.

약 90개 검증인이 연결을 잃었으며, 이들이 대표한 스테이킹 지분은 전체의 약 28.83%였다. 여기서 29%는 전체 검증인 노드 가운데 29%가 꺼졌다는 뜻이 아니다. 지분증명 네트워크에서는 검증인마다 위임받은 SOL 수량이 다르므로 노드 수보다 빠져나간 투표 지분의 비율이 합의 안정성에 더 중요하다.

Teraswitch의 사고 보고서는 전송사업자 유지보수 과정에서 마이애미 에지 라우터에 남아 있던 기본 경로와 잘못 적용된 경로 정책을 원인으로 설명했다. 쉽게 말하면 인터넷 트래픽이 가야 할 길을 알려주는 안내표가 잘못 전파되면서 여러 지역의 검증인들이 솔라나 네트워크와 정상적으로 통신하지 못한 것이다.

문제가 진단된 뒤 라우팅 오류 자체는 비교적 빠르게 수정됐고, 04시 16분경 트래픽이 다시 흐르기 시작했다. 다만 모든 검증인이 동시에 돌아온 것은 아니었다. Metrika에 따르면 영향을 받은 검증인들은 이후 약 40분 동안 순차적으로 회복했고 최종성 지표도 뒤이어 정상 범위로 돌아왔다.

왜 29% 오프라인이 위험한 숫자인가

솔라나에서 블록이 최종 확정되려면 전체 스테이킹 지분의 3분의 2를 넘는 투표가 필요하다. 반대로 3분의 1 이상이 투표하지 못하면 새로운 블록을 정상적으로 최종 확정하기 어려워진다.

이번 사고에서는 약 28.83%가 오프라인이 됐으므로 약 71.17%가 온라인에 남았다. 수학적으로는 3분의 2보다 많아 합의를 계속할 수 있는 범위였다. 그러나 최종성 중단 기준인 33.34%와의 차이는 약 4.51%포인트에 불과했다. Metrika는 이를 당시 약 2,000만 스테이킹 SOL 규모로 계산했다.

만약 같은 시간에 중간 규모 검증인 사업자 한 곳이 추가로 연결을 잃었거나 다른 클라우드·네트워크 장애가 겹쳤다면 최종성이 네트워크 전체에서 멈췄을 가능성이 있다. 이 경우 단순히 라우터를 고치는 것만으로 끝나지 않고 운영자 사이의 조정된 복구 절차가 필요했을 수 있다.

29%라는 수치를 해석할 때 주의할 점

잘못된 해석	정확한 의미
솔라나 서버의 29%가 고장 났다	오프라인 검증인들이 전체 스테이킹 지분의 약 29%를 대표했다
거래의 29%가 사라졌다	거래가 사라진 것이 아니라 투표와 처리 성능이 감소했다
29%가 빠지면 무조건 체인이 멈춘다	3분의 2가 넘는 지분이 투표하면 블록 생성과 합의는 이어질 수 있다
체인이 멈추지 않았으니 영향이 없었다	최종성·처리량·건너뛴 슬롯 등 품질 지표는 크게 악화됐다

블록은 계속 만들어졌는데 왜 최종 확정은 지연됐나

블록 생성과 최종성은 같은 개념이 아니다. 예정된 리더 검증인은 거래를 묶어 블록을 만들 수 있다. 그러나 그 블록이 되돌릴 수 없는 확정 상태에 도달하려면 충분한 지분을 가진 검증인들의 투표가 쌓여야 한다.

이번 사고에서도 온라인 상태인 검증인들은 계속 블록을 만들었다. 사용자의 거래도 블록에 포함됐다. 하지만 대규모 투표 지분이 한꺼번에 사라지면서 투표가 누적되는 속도가 느려졌다. Metrika는 평소 블록당 약 680건이던 투표가 최저 약 569건까지 줄었다고 집계했다.

최종 확정 시간은 평소 약 13초 수준에서 크게 늘었다. 약 30분 동안에는 새로 생성된 블록이 최종성에 도달한 관측값 자체가 나타나지 않았고, 연결이 복구된 후 밀린 블록이 한꺼번에 확정되면서 생산부터 최종성까지 걸린 시간이 평균 약 1,600초로 뛰었다.

따라서 이용자의 지갑이나 블록 탐색기에는 거래가 성공한 것처럼 보이더라도, 거래소·브리지·대출 프로토콜처럼 finalized 상태를 결제 기준으로 삼는 서비스는 더 오래 기다려야 했을 수 있다.

성능 지표는 얼마나 떨어졌나

Metrika가 공개한 지표를 보면 사고가 단순한 네트워크 경고 수준은 아니었다.

• 건너뛴 슬롯 비율은 평소 1% 미만에서 32% 이상으로 급등했다.
• 블록당 실제 거래는 일반적인 800~1,000건에서 약 190건까지 감소했다.
• 약 190건 가운데 성공한 거래는 약 151건으로 관측됐다.
• 투표 거래를 제외한 실제 TPS는 평소 약 1,100~1,300에서 300 미만으로 떨어졌다.
• 새 블록 최종성은 약 30분간 공백을 보였다.
• 그럼에도 블록은 계속 생성돼 가동률 지표는 100%를 유지했다.

지표	평상시 수준	장애 구간	변화의 의미
블록당 투표	약 680건	최저 약 569건	온라인 투표 지분 감소
건너뛴 슬롯	1% 미만	32% 초과	예정된 리더가 블록을 만들지 못한 비율 증가
실제 거래/블록	약 800~1,000건	약 190건	사용자 처리량 감소
실제 TPS	약 1,100~1,300	300 미만	네트워크 체감 성능 하락
최종 확정	약 13초	약 30분 공백	결제 확정 불확실성 증가
네트워크 가동률	100%	100%	블록 생성 여부만 보면 장애가 드러나지 않음

가동률 100%가 정상 운영을 뜻하지 않는 이유

Solana Foundation은 사고 중에도 블록과 거래가 계속 처리됐다는 점을 회복력의 증거로 평가했다. 이 평가는 틀리지 않다. 29%에 가까운 투표 지분을 잃고도 체인이 전면 중단되지 않았기 때문이다.

하지만 Metrika의 분석처럼 가동률만 보면 중요한 위험을 놓칠 수 있다. 블록이 하나라도 계속 만들어지면 가동률은 100%로 기록될 수 있다. 반면 금융 서비스에 중요한 질문은 “체인이 켜져 있는가?”보다 “내 거래가 언제 되돌릴 수 없는 상태가 되는가?”에 가깝다.

확인 대상	블록 생성만 확인	최종성까지 확인
일반 지갑 사용자	거래가 화면에 보이는지 확인	확정 단계와 지연 여부 확인
중앙화 거래소	입금 감지는 가능	최종 확정 전까지 출금·잔액 반영을 보류할 수 있음
브리지	출발 체인 거래 관측	충분한 최종성 이전 민팅은 이중사용 위험 증가
대출 프로토콜	담보 이동 요청 확인	청산·상환의 확정 시점이 중요
기관 결제	메시지 수신 가능	회계상 결제 완료는 최종성이 기준이 될 수 있음

이 때문에 기관이나 대규모 프로토콜은 가동률, TPS, 슬롯 누락률, 투표율, 최종성 시간을 함께 감시해야 한다.

검증인 수가 많아도 인프라가 겹치면 분산됐다고 보기 어렵다

이번 사고에서 가장 중요한 문제는 검증인 소프트웨어가 아니라 검증인들이 의존한 인터넷 인프라였다. 서로 다른 검증인 운영자가 노드를 운영하더라도 같은 데이터센터, 같은 호스팅 업체, 같은 자율시스템, 같은 상위 통신경로를 이용하면 하나의 라우팅 오류에 동시에 영향을 받을 수 있다.

Solana Foundation은 2025년 Teraswitch에 호스팅된 지분이 38%에 달하는 것을 확인하고 이를 30% 미만으로 낮추는 작업을 진행했다고 밝혔다. 실제 사고 당시 비율이 29% 아래였기 때문에 최종성 중단 기준을 넘지 않았다. 사전 분산 조치가 더 큰 장애를 막은 셈이다.

동시에 한 사업자에 29% 가까운 지분이 남아 있었다는 점은 분산화 평가에 새로운 기준이 필요하다는 뜻이기도 하다. 단순히 검증인 개수와 운영자 이름만 세는 것으로는 부족하다.

솔라나 인프라 분산성을 볼 때 필요한 기준

1. 검증인 운영 주체가 서로 다른가?
2. 호스팅·클라우드 제공업체가 분산돼 있는가?
3. 데이터센터의 국가와 도시가 분산돼 있는가?
4. 인터넷 자율시스템과 상위 통신사가 겹치지 않는가?
5. 주 서버 장애 시 백업 검증인이 자동으로 전환되는가?
6. 특정 사업자의 지분이 3분의 1에 가까워지지 않는가?

백업 시스템은 왜 즉시 작동하지 않았나

Metrika는 많은 영향을 받은 검증인의 백업 시스템이 전환되지 않았다고 지적했다. 백업 서버를 다른 도시에 두더라도 같은 호스팅 사업자의 네트워크 정책이나 같은 라우팅 경로를 공유한다면 주 서버와 동시에 연결이 끊길 수 있다.

진정한 장애 대비 구조를 만들려면 서버 위치만 바꾸는 것이 아니라 호스팅 제공업체, 통신사, 자율시스템, 관리계정, 전원 공급망까지 분리해야 한다. 자동 전환 기능도 실제 라우팅 장애를 가정해 정기적으로 시험해야 한다.

이번 사고 뒤 확인해야 할 사항은 다음과 같다.

• Teraswitch가 잘못된 경로를 차단하는 정책을 적용했는가?
• 경로 변경 시 검증과 승인 절차가 추가됐는가?
• 오프라인 지분이 임계치에 접근할 때 더 빠른 경보가 울리는가?
• 검증인 운영자들이 다른 제공업체의 백업 경로를 확보했는가?
• 액체 스테이킹 프로토콜이 위임 지분을 인프라별로 분산하는가?

투자자에게 이번 사고가 의미하는 것

이 사건만으로 SOL의 장기 가격 방향을 판단할 수는 없다. 네트워크가 전면 중단을 피했다는 점은 긍정적이지만, 최종성이 약 30분간 지연되고 처리량이 크게 줄었다는 점은 무시할 수 없다.

투자자와 디파이 이용자는 네트워크 장애 뉴스를 볼 때 “중단됐는가, 아니면 살아 있었는가”라는 두 가지 선택지만 보지 않는 것이 좋다. 다음처럼 단계별로 확인해야 한다.

단계	확인 질문
연결	검증인과 RPC가 정상적으로 통신하는가?
생산	예정된 슬롯에서 블록이 계속 생성되는가?
처리	사용자의 실제 거래 처리량이 유지되는가?
합의	충분한 지분의 투표가 쌓이고 있는가?
최종성	거래가 평소 시간 안에 되돌릴 수 없는 상태가 되는가?

특히 브리지, 대출, 스테이블코인 상환처럼 짧은 시간 안에 큰 금액을 확정해야 하는 서비스는 최종성 지연을 별도의 장애로 취급할 필요가 있다.

자주 묻는 질문

솔라나 네트워크가 30분 동안 완전히 멈춘 것인가요?

아니다. 블록 생성과 거래 유입은 계속됐다. 다만 Metrika 관측에서는 약 30분 동안 새로 생산된 블록이 최종 확정되지 않았고 실제 TPS와 슬롯 처리 성능도 크게 떨어졌다.

29%의 검증인이 오프라인이 된 것인가요?

정확히는 영향을 받은 검증인들이 대표한 스테이킹 지분이 약 28.83%였다. 영향을 받은 검증인은 약 90개로 집계됐지만 검증인마다 위임받은 지분이 다르므로 두 수치는 같은 의미가 아니다.

왜 33.34%가 중요한가요?

전체 지분의 3분의 2를 넘는 투표가 있어야 블록이 정상적으로 최종 확정된다. 따라서 3분의 1 이상이 투표하지 못하면 최종성이 멈출 수 있다.

거래가 성공으로 표시됐다면 안전한 것 아닌가요?

거래가 블록에 포함된 것과 최종 확정된 것은 다르다. 금액이 크거나 브리지·거래소 입금처럼 되돌림 위험이 중요한 거래는 finalized 상태를 확인해야 한다.

이번 사고는 솔라나 프로그램의 버그였나요?

공개된 자료가 지목한 직접 원인은 호스팅 제공업체의 인터넷 라우팅 오류다. 솔라나 합의 코드가 직접 멈춘 사고와는 구분해야 한다.

헬퓨경제의 의견

이번 사고는 솔라나의 성공과 경고를 동시에 보여준 사례라고 생각한다. 네트워크 지분의 약 29%가 한꺼번에 연결을 잃었는데도 블록 생성이 계속됐다는 것은 분명한 회복력이다. 2025년 38%였던 특정 제공업체 의존도를 30% 아래로 낮춘 조치가 없었다면 결과가 달라졌을 가능성도 있다.

하지만 “체인이 멈추지 않았다”는 표현만으로 사건을 정리하면 중요한 절반을 놓친다. 거래 처리량은 급격히 줄었고 약 30분 동안 최종성이 불확실해졌다. 평범한 소액 전송에서는 차이를 느끼지 못했을 수 있지만 거래소 입금, 브리지, 담보 청산, 기관 결제에서는 30분의 최종성 지연이 실질적인 장애가 될 수 있다.

또한 블록체인의 분산화는 검증인 숫자만으로 판단하기 어렵다. 서로 다른 회사가 운영하는 검증인 100대가 같은 데이터센터와 같은 인터넷 경로를 사용한다면 한 번의 설정 오류로 함께 사라질 수 있다. 앞으로는 운영자별 지분뿐 아니라 호스팅 업체, 국가, 데이터센터, 자율시스템별 지분 분포도 공개돼야 한다.

결국 이번 사고의 교훈은 가동률보다 최종성, 노드 개수보다 인프라 의존관계를 봐야 한다는 것이다. 솔라나는 전면 중단을 피했지만, 다음번에도 같은 여유가 남는다는 보장은 없다. 이번 일을 단순한 무중단 성공담보다 인프라 집중도를 더 낮추기 위한 조기 경보로 받아들이는 편이 합리적이다.

본 글은 공개된 기술 자료를 바탕으로 작성한 정보 제공용 콘텐츠이며 투자 권유가 아니다. 암호화폐와 스테이킹에는 가격 변동, 네트워크, 검증인 및 인프라 운영 위험이 존재한다.

출처

• Solana Foundation — Solana: Building, Proving and Earning Trust in Public
• Metrika — Close Mortem: The Near-Miss on Solana on August 12, 2026
• Teraswitch Status — 2026년 8월 12일 라우팅 사고 보고서
• Solana 공식 문서 — Transaction Confirmation & Expiration