원문: YQ
Yuliya, PANews가 편집
10월 20일, 아마존 웹 서비스(AWS)에서 또 다른 대규모 정전이 발생하여 암호화폐 인프라에 심각한 영향을 미쳤습니다. 베이징 시간 기준 오후 4시경부터 US-EAST-1 지역(버지니아 북부 데이터 센터)의 AWS에 문제가 발생하여 코인베이스를 비롯한 수십 개의 주요 암호화폐 플랫폼(로빈후드, 인퓨라, 베이스, 솔라나 등)이 다운타임을 겪었습니다.
AWS는 수천 개의 기업이 의존하는 핵심 데이터베이스 및 컴퓨팅 서비스인 Amazon DynamoDB와 EC2의 "오류율 증가"를 인정했습니다. 이 실시간 장애는 이 글의 핵심 주장, 즉 암호화 인프라가 중앙 집중식 클라우드 서비스 제공업체에 의존함으로써 시스템적 취약성이 발생하고, 이러한 취약성은 압박 속에서 반복적으로 노출된다는 사실을 직접적으로 명백하게 보여줍니다.
타이밍이 매우 위험합니다. 193억 달러 규모의 연쇄 청산으로 거래소 차원의 인프라 장애가 드러난 지 불과 10일 만에 AWS 서비스 중단 사태는 문제가 개별 플랫폼을 넘어 기반 클라우드 인프라로 확산되었음을 보여주었습니다. AWS에 장애가 발생하면 그 여파는 중앙 집중형 거래소, 여전히 중앙 집중형 구성 요소에 의존하는 분산형 플랫폼, 그리고 이러한 구성 요소에 의존하는 수많은 서비스에 영향을 미칩니다.
이는 단발적인 사건이 아니라 오랜 패턴의 연장선입니다. 2025년 4월, 2021년 12월, 그리고 2017년 3월에도 유사한 AWS 장애가 발생하여 주요 암호화폐 서비스를 마비시켰습니다. 이제 문제는 "이런 일이 다시 발생할지 여부"가 아니라 "언제" 그리고 "무엇이 이런 일을 일으킬 것인가"입니다.
청산은 2025년 10월 10-11일에 이루어집니다.
2025년 10월 10일과 11일에 발생한 청산 연쇄 사건은 인프라 실패 메커니즘을 보여주는 대표적인 사례입니다. 10월 10일 오후 8시(UTC, 베이징 시간 10월 11일 오전 4시), 주요 지정학적 발표로 광범위한 시장 매도세가 촉발되었습니다. 단 한 시간 만에 청산액이 60억 달러에 달했습니다. 아시아 시장이 개장할 당시 레버리지 포지션 손실액은 총 193억 달러에 달했으며, 160만 개의 트레이더 계좌에 영향을 미쳤습니다.

그림 1: 청산 폭포수 타임라인, 2025년 10월(UTC)
주요 전환점으로는 API 속도 제한, 마켓 메이커 퇴장, 주문장 유동성의 급격한 감소 등이 있습니다.
- 20:00-21:00: 초기 영향 – 60억 달러 청산(적색 구역)
- 21:00-22:00: 청산 정점 - 42억 달러, API가 제한을 시작합니다.
- 22:00-04:00: 지속적인 악화 - 91억 달러, 매우 얇은 시장 깊이

그림 2: 과거 청산 사건 비교
이번 사건의 규모는 이전의 어떤 암호화폐 시장 사건보다 최소 10배 이상 큽니다. 수직적 비교를 통해 이번 사건의 도약적 성격을 확인할 수 있습니다.
- 2020년 3월(팬데믹 기간): 12억 달러
- 2021년 5월(시장 붕괴): 16억 달러
- 2022년 11월(FTX 폭락): 16억 달러
- 2025년 10월: 193억 달러, 이전 기록의 16배
그러나 청산 데이터는 피상적일 뿐입니다. 더 중요한 질문은 메커니즘적 차원에 있습니다. 외부 시장 사건이 어떻게 그러한 특정 실패 모드를 촉발할 수 있을까요? 그 답은 중앙화 거래소 아키텍처와 블록체인 프로토콜 설계의 시스템적 취약점을 드러냅니다.
오프체인 실패: 중앙 집중형 거래소의 아키텍처 문제
인프라 과부하 및 속도 제한
거래소 API는 일반적으로 남용을 방지하고 안정적인 서버 부하를 유지하기 위해 비율 제한을 적용합니다. 일반적인 상황에서는 이러한 제한이 공격을 방지하고 원활한 거래를 보장합니다. 그러나 변동성이 극심한 시기에 수천 명의 트레이더가 동시에 포지션을 조정하려고 시도하면 이러한 제한이 병목 현상을 일으킬 수 있습니다.
이 기간 동안 중앙화 거래소(CEX)는 시스템이 수천 건의 청산을 처리해야 함에도 불구하고 청산 알림을 초당 한 건으로 제한했습니다. 이로 인해 투명성이 크게 저하되어 사용자는 연쇄 청산 규모를 실시간으로 파악할 수 없었습니다. 타사 모니터링 도구는 분당 수백 건의 청산을 표시했지만, 공식 데이터는 훨씬 적은 수를 나타냈습니다.
API 속도 제한으로 인해 트레이더들은 중요한 첫 한 시간 동안 포지션을 조정할 수 없었습니다. 연결 요청 시간 초과, 주문 실패, 미실행 손절매 주문, 그리고 지연된 포지션 데이터 업데이트는 모두 시장 상황을 운영 위기로 몰아넣었습니다.
기존 거래소는 일반적으로 "정상 부하 + 안전 마진"에 자원을 할당하지만, 정상 부하와 극심한 부하 사이의 격차가 상당합니다. 일일 평균 거래량은 극심한 압박 속에서 최대 수요를 예측하기에 충분하지 않습니다. 연쇄 청산 기간 동안 거래량은 100배, 포지션 문의는 1,000배 급증할 수 있습니다. 모든 사용자가 동시에 계좌를 확인하게 되면 시스템은 거의 마비될 수 있습니다.

그림 4.5: 암호화 서비스에 영향을 미치는 AWS 중단
클라우드 인프라의 자동 확장은 도움이 될 수 있지만, 즉각적인 효과는 없습니다. 추가 데이터베이스 복제본을 생성하는 데는 몇 분밖에 걸리지 않으며, 새로운 API 게이트웨이 인스턴스를 생성하는 데도 몇 분이 걸립니다. 이 기간 동안 마진 시스템은 주문장 혼잡으로 인해 왜곡된 가격 데이터를 기반으로 정산 포지션을 계속 표시합니다.
Oracle 조작 및 가격 책정 취약점
10월 청산 사건은 증거금 시스템의 중대한 설계 결함을 드러냈습니다. 일부 거래소는 외부 오라클 가격이 아닌 내부 현물 가격을 기반으로 담보 가치를 계산했습니다. 정상적인 시장 상황에서는 차익거래자들이 거래소 간 가격 일관성을 유지할 수 있었지만, 인프라에 문제가 생기면 이러한 연계 메커니즘이 제대로 작동하지 않았습니다.

그림 3: Oracle 조작 흐름도
공격 경로는 5단계로 나눌 수 있습니다.
- 초기 매도: USDe에 6,000만 달러 매도 압력
- 가격 조작: USDe가 단일 거래소에서 $1.00에서 $0.65로 폭락
- Oracle 오류 : 마진 시스템이 조작된 내부 가격을 사용합니다.
- 트리거 체인 : 담보가 저평가되어 강제 청산이 발생
- 증폭 효과: 193억 달러의 청산(322배 증폭)
이 공격은 바이낸스가 현물 시장 가격을 활용하여 래핑된 합성 담보의 가격을 책정하는 방식을 악용했습니다. 공격자가 6천만 달러 상당의 USDe를 비교적 빈약한 주문장에 투입하자, 현물 가격은 1달러에서 0.65달러로 폭락했습니다. 담보를 현물 가격으로 매기도록 설정된 마진 시스템은 모든 USDe 담보 포지션의 가치를 35% 감소시켰습니다. 이로 인해 마진 콜이 발생하고 수천 개의 계좌가 강제 청산되었습니다.
이러한 청산으로 인해 유동성이 낮은 동일한 시장에 더 많은 매도 주문이 유입되었고, 이는 가격을 더욱 하락시켰습니다. 증거금 시스템은 이러한 하락세를 감지하고 더 많은 포지션을 청산했습니다. 이러한 피드백 루프는 6천만 달러에 달하는 매도 압력을 322배 증폭시켰고, 궁극적으로 193억 달러의 강제 청산으로 이어졌습니다.

그림 4: 청산 폭포 피드백 루프
이 피드백 루프 다이어그램은 폭포수형의 자체 강화 특성을 보여줍니다.
가격 하락 → 청산 유발 → 강제 매도 → 가격 추가 하락 → [주기 반복]
제대로 설계된 오라클 시스템이 있었다면 이 메커니즘은 작동하지 않았을 것입니다. 바이낸스가 여러 거래소에서 시간 가중 평균 가격(TWAP)을 사용했다면 즉각적인 가격 조작이 담보 가치 평가에 영향을 미치지 않았을 것입니다. 체인링크나 다른 여러 출처의 오라클에서 집계된 가격 피드를 사용했다면 공격은 실패했을 것입니다.
며칠 전 wBETH 사건에서도 유사한 문제가 드러났습니다. 래핑된 바이낸스 ETH(wBETH)는 ETH와 1:1 환율을 유지해야 했습니다. 그러나 워터폴(폭락) 기간 동안 유동성이 고갈되어 wBETH/ETH 현물 시장에서 20%의 할인이 발생했습니다. 이후 마진 시스템은 wBETH 담보를 감액했고, 사실상 기초 ETH로 완전히 담보된 포지션에 대한 청산이 시작되었습니다.
자동 부채 해소(ADL) 메커니즘
현재 시장가로 청산이 실행될 수 없는 경우, 거래소는 수익을 창출하는 거래자들 사이에서 손실을 공유하기 위해 자동 청산(ADL) 메커니즘을 구현합니다. ADL은 청산된 포지션의 손실을 상쇄하기 위해 수익이 있는 포지션을 현재 가격으로 청산하도록 강제합니다.
2019년 10월 폭락 당시 바이낸스는 여러 거래쌍에 대해 자동이체(ADL)를 실행했습니다. 수익성 있는 롱 포지션을 보유한 트레이더들은 자신의 위험 관리 실패가 아니라 다른 트레이더들의 포지션이 부실화되면서 강제 청산을 당했습니다.
ADL은 중앙화된 파생상품 거래의 기본적인 아키텍처 선택을 반영합니다. 거래소는 손실에 대한 보장을 스스로 제공하므로 손실은 다음과 같은 방식으로 부담해야 합니다.
- 보험 기금(거래소가 청산 손실을 충당하기 위해 보유하는 자본)
- ADL(수익성 있는 거래자의 강제 청산)
- 사회화된 손실(모든 사용자에게 손실을 분산)
보험 기금 규모와 미결제약정의 비율이 자동자산할인(ADL) 빈도를 결정합니다. 2025년 10월 바이낸스의 보험 기금은 약 20억 달러였습니다. 이는 BTC, ETH, BNB 무기한 계약의 미결제약정 40억 달러 대비 50%를 보장했습니다. 그러나 10월 폭락장 기간 동안 모든 거래쌍의 미결제약정 총액은 200억 달러를 초과했고, 보험 기금은 부족분을 충당하지 못했습니다.
2018년 10월 폭락 이후, 바이낸스는 BTC, ETH, BNB의 U-마진 무기한 계약 미결제약정 총액이 40억 달러 미만으로 떨어질 경우 자동이체(ADL)에 대한 보장을 제공하겠다고 발표했습니다. 이러한 정책은 신뢰를 강화하지만, 동시에 구조적 모순을 드러냅니다. 거래소가 자동이체(ADL)를 완전히 피하려면 더 큰 규모의 보험 기금을 유지해야 하는데, 이는 수익성 있게 활용될 수 있는 자금을 다른 곳으로 돌리는 결과를 초래합니다.
온체인 실패: 블록체인 프로토콜의 한계

그림 5: 주요 네트워크 중단 - 기간 분석
- 솔라나(2024년 2월): 5시간 - 투표 처리량 병목 현상
- Polygon(2024년 3월): 11시간 - 검증기 버전 불일치
- 낙관주의(2024년 6월): 2.5시간 - 시퀀서 과부하(공수)
- 솔라나(2024년 9월): 4.5시간 - 스팸 공격
- Arbitrum(2024년 12월): 1.5시간 - RPC 공급자 오류
솔라나: 합의 병목 현상
솔라나는 2024년과 2025년 사이에 여러 차례 서비스 중단을 경험했습니다. 2024년 2월의 서비스 중단은 약 5시간 동안 지속되었고, 9월의 서비스 중단은 4~5시간 동안 지속되었습니다. 이러한 서비스 중단은 모두 유사한 근본 원인에서 비롯되었습니다. 스팸 공격이나 과도한 활동으로 인해 네트워크가 거래량을 감당하지 못했던 것입니다.
솔라나의 아키텍처는 높은 처리량에 최적화되어 있습니다. 이상적인 조건에서 네트워크는 초당 3,000~5,000건의 트랜잭션을 1초 미만의 확정성으로 처리할 수 있습니다. 이 성능은 이더리움보다 훨씬 뛰어납니다. 그러나 스트레스 상황에서는 이러한 최적화가 취약점을 유발할 수 있습니다.
2024년 9월 서비스 중단은 검증자 투표 메커니즘을 과부하시킨 대량의 불필요한 거래로 인해 발생했습니다. 솔라나의 검증자는 합의에 도달하기 위해 블록에 대해 투표해야 합니다. 일반적인 운영 환경에서 검증자는 합의를 보장하기 위해 투표 거래의 우선순위를 정합니다. 그러나 이전 프로토콜은 수수료 시장에서 투표 거래를 일반 거래와 동일하게 처리했습니다.
거래 메모리풀이 수백만 개의 불필요한 거래로 가득 차면 검증자는 투표 거래를 브로드캐스트하는 데 어려움을 겪습니다. 충분한 투표가 없으면 블록을 확정할 수 없습니다. 확정된 블록이 없으면 체인이 정지됩니다. 사용자의 보류 중인 거래는 메모리풀에 갇혀 새로운 거래가 제출되지 못하게 됩니다.
서드파티 모니터링 도구 StatusGator는 2024년과 2025년에 여러 차례 Solana 서비스 중단을 기록했지만, Solana 관계자는 공식적인 설명을 내놓지 않았습니다. 이로 인해 정보 비대칭이 발생하여 사용자가 개인적인 연결 문제와 전반적인 네트워크 문제를 구분하기 어렵게 됩니다. 서드파티 서비스가 감독 기능을 제공하지만, 플랫폼 자체적으로 투명성을 확보하기 위해 포괄적인 상태 페이지를 유지해야 합니다.
이더리움: 가스비 폭등
이더리움은 2021년 DeFi 붐 당시 가스비가 급등했습니다. 간단한 송금 수수료는 100달러를 넘었고, 복잡한 스마트 컨트랙트 상호작용 수수료는 500~1,000달러에 달했습니다. 이로 인해 네트워크는 소규모 거래에 거의 사용할 수 없게 되었고, 또 다른 공격 경로인 MEV(최대 추출 가능 가치) 추출이 발생했습니다.

그림 7: 네트워크 스트레스 하의 거래 비용
- 이더리움: $5(정상) → $450(혼잡이 가장 심할 때) - 90배 증가
- Arbitrum: $0.50 → $15 – 30배 증가
- 낙관론: $0.30 → $12 – 40배 성장
높은 가스 수수료 환경에서 MEV는 검증인에게 중요한 수익원이 됩니다. MEV는 검증인이 거래를 재주문, 포함 또는 제외함으로써 얻는 추가 수익을 의미합니다. 이러한 환경에서 차익거래자들은 대형 DEX에서 선불 거래를 위해 경쟁하고, 청산 봇들은 담보가 부족한 포지션을 가장 먼저 청산하기 위해 경쟁합니다. 이러한 경쟁은 가스 수수료 입찰 경쟁을 심화시키고, 저렴한 레이어 2 솔루션조차도 높은 수요로 인해 수수료가 크게 인상되는 상황을 초래합니다. 높은 가스 수수료 환경은 MEV 수익 기회를 더욱 확대하여 관련 활동의 빈도와 규모를 증가시킵니다.
혼잡 기간에는 거래 내역을 확보하려는 사용자가 MEV 봇보다 높은 가격을 제시해야 합니다. 이로 인해 거래 수수료가 거래 금액 자체를 초과하는 상황이 발생합니다. $100 에어드랍을 받으시겠습니까? 가스비로 $150를 지불하세요. 청산을 피하기 위해 담보를 추가해야 합니까? 우선 순위에 $500를 지불하는 봇과 경쟁하세요.
이더리움의 가스 한도는 블록당 수행할 수 있는 총 연산량을 나타냅니다. 혼잡 기간에는 사용자들이 부족한 블록 공간에 입찰합니다. 수수료 시장은 설계된 대로 운영됩니다. 최고 입찰자가 승리합니다. 그러나 이러한 설계는 사용자들이 가장 많이 접속해야 하는 최대 사용 시간대에 네트워크 비용을 증가시킵니다.
2계층: 분류기 병목 현상
레이어 2 솔루션은 주기적인 결제를 통해 이더리움의 보안을 계승하면서 연산을 오프체인으로 이동시킴으로써 이 문제를 해결하고자 합니다. Optimism, Arbitrum 및 기타 Rollup은 수천 건의 거래를 오프체인에서 처리한 후 압축된 증명을 이더리움에 제출합니다. 이 아키텍처는 정상 운영 중 개별 거래 비용을 효과적으로 절감합니다.
하지만 레이어 2 솔루션은 새로운 병목 현상을 야기합니다. 2024년 6월, Optimism은 25만 개의 주소가 동시에 에어드랍을 신청하면서 서비스 중단을 경험했습니다. 이더리움에 거래를 제출하기 전에 거래를 분류하는 구성 요소인 정렬기가 과부하 상태에 빠졌습니다. 사용자들은 몇 시간 동안 거래를 제출할 수 없었습니다.
이번 서비스 중단은 연산을 오프체인으로 이동하더라도 인프라의 필요성이 사라지지 않는다는 것을 보여주었습니다. 콜레이터는 수신되는 거래를 처리하고, 정렬하고, 실행하고, 이더리움 결제를 위해 사기 방지 또는 영지식 증명을 생성해야 합니다. 과도한 트래픽 상황에서 콜레이터는 독립형 블록체인과 동일한 확장성 문제에 직면합니다.
여러 RPC 공급자를 사용할 수 있어야 합니다. 기본 공급자에 장애가 발생하더라도 사용자는 백업 공급자로 원활하게 전환할 수 있어야 합니다. Optimism 서비스 중단 기간 동안 일부 RPC 공급자는 작동 상태를 유지했지만, 다른 공급자는 장애가 발생했습니다. 지갑이 장애가 발생한 공급자로 기본 설정된 사용자는 체인 자체는 작동 중이더라도 체인과 상호 작용할 수 없었습니다.
AWS 서비스 중단은 암호화 생태계의 중앙 집중식 인프라의 위험을 반복적으로 노출시킵니다.
- 2025년 10월 20일: US-EAST-1 리전에서 서비스 중단이 발생하여 Coinbase, Venmo, Robinhood, Chime 등에 영향을 미쳤습니다. AWS는 DynamoDB 및 EC2 서비스의 오류율 증가를 인정했습니다.
- 2025년 4월: 지역별 서비스 중단으로 바이낸스, 쿠코인, MEXC 및 기타 거래소가 같은 날 동시에 서비스를 중단했습니다. 주요 거래소의 AWS 호스팅 구성 요소에 장애가 발생했습니다.
- 2021년 12월: US-EAST-1 서비스 중단으로 인해 Coinbase, Binance.US, "분산형" 거래소 dYdX가 8~9시간 동안 다운되었으며, Amazon의 자체 창고와 주요 스트리밍 서비스에도 영향을 미쳤습니다.
- 2017년 3월: S3(Simple Storage Service) 장애로 인해 사용자가 5시간 동안 Coinbase와 GDAX에 접속하지 못하면서 광범위한 인터넷 중단이 발생했습니다.
이러한 거래소는 AWS 인프라의 핵심 구성 요소를 호스팅합니다. AWS에 지역별 장애가 발생하면 여러 주요 거래소와 서비스를 동시에 이용할 수 없게 됩니다. 장애 발생 시(특히 시장 변동성이 즉각적인 조치를 필요로 할 때) 사용자는 자금 접근, 거래 실행 또는 포지션 수정이 불가능합니다.
폴리곤: 합의 버전 불일치
2024년 3월, Polygon은 검증자 버전 불일치로 인해 11시간 동안 시스템 중단을 경험했습니다. 이는 주요 블록체인 네트워크 중 분석된 가장 긴 시스템 중단으로, 합의 실패의 심각성을 여실히 드러냈습니다. 근본 원인은 일부 검증자가 이전 버전의 소프트웨어를 사용하는 반면, 다른 검증자는 최신 버전으로 업그레이드했기 때문입니다. 두 버전의 상태 전이 계산 방식이 달랐기 때문에 검증자들이 정확한 상태에 대해 의견 차이를 보였고, 이는 합의 실패로 이어졌습니다.
검증자들이 블록의 유효성에 동의하지 않아 체인이 새 블록을 생성할 수 없었습니다. 이로 인해 교착 상태가 발생했습니다. 이전 소프트웨어를 실행하는 검증자들은 새 소프트웨어를 실행하는 검증자들의 블록을 거부했고, 새 소프트웨어를 실행하는 검증자들은 이전 소프트웨어의 블록을 거부했습니다.
이 솔루션을 위해서는 검증자 업그레이드 조정이 필요합니다. 하지만 시스템 중단 시 업그레이드 조정에는 시간이 걸립니다. 모든 검증자 운영자에게 연락하고, 올바른 소프트웨어 버전을 배포하고, 검증자를 재시작해야 합니다. 수백 개의 독립적인 검증자가 있는 분산 네트워크에서는 이러한 조정에 몇 시간 또는 며칠이 걸릴 수 있습니다.
하드 포크는 일반적으로 블록 높이를 트리거로 사용합니다. 모든 검증자는 동시 활성화를 보장하기 위해 특정 블록 높이만큼 업그레이드를 완료합니다. 그러나 이를 위해서는 사전 조율이 필요합니다. 검증자가 새 버전을 점진적으로 적용하는 점진적 업그레이드는 Polygon 서비스 중단에서 볼 수 있듯이 버전 불일치의 위험을 수반합니다.
건축적 균형

그림 6: 블록체인 트릴레마 - 분산화 대 성능
"블록체인 트릴레마"는 다음 시스템을 반영합니다.
- 비트코인: 높은 분산화, 낮은 성능
- 이더리움: 높은 분산화, 적당한 성능
- 솔라나: 적당히 분산화, 고성능
- 바이낸스(CEX): 최소 분산화, 최대 성능
- Arbitrum/Optimism: 중간에서 높은 수준의 분산화, 중간 수준의 성과
핵심 통찰: 어떤 시스템도 최대의 분산화와 최고의 성능을 동시에 달성할 수는 없습니다. 각 설계는 다양한 사용 사례에 맞춰 의도적으로 균형을 유지합니다.
중앙 집중형 거래소는 아키텍처의 단순성을 통해 낮은 지연 시간을 달성합니다. 매칭 엔진은 마이크로초 단위로 주문을 처리하고, 상태는 중앙 집중형 데이터베이스에 저장되며, 합의 프로토콜 오버헤드도 없습니다. 그러나 이러한 단순성은 단일 장애 지점을 발생시킵니다. 인프라에 부하가 걸리면 연쇄적인 장애가 밀접하게 결합된 시스템을 통해 확산될 수 있습니다.
탈중앙화 프로토콜은 검증자 간에 상태를 분산하여 단일 장애 지점을 제거합니다. 처리량이 높은 체인은 장애 발생 시에도 이러한 특성을 유지합니다(자금은 손실되지 않고, 활성 상태만 일시적으로 손상됩니다). 그러나 분산된 검증자 간의 합의에 도달하면 연산 오버헤드가 발생합니다. 검증자는 상태 전환을 완료하기 전에 합의에 도달해야 합니다. 검증자가 호환되지 않는 버전을 실행하거나 과도한 트래픽에 직면하면 합의 프로세스가 일시적으로 중단될 수 있습니다.
복제본을 추가하면 내결함성은 향상되지만 조정 비용은 증가합니다. 비잔틴 내결함성 시스템에서는 검증자가 추가될 때마다 통신 오버헤드가 증가합니다. 고처리량 아키텍처는 최적화된 검증자 통신을 통해 이러한 오버헤드를 최소화하여 우수한 성능을 달성하지만 특정 공격 패턴에 취약하게 만듭니다. 보안 중심 아키텍처는 검증자 다양성과 합의 견고성을 우선시하여 기본 계층 처리량을 제한하는 동시에 복원력을 극대화합니다.
레이어 2 솔루션은 계층화된 설계를 통해 이러한 두 가지 특성을 모두 제공하려고 합니다. 레이어 1 결제를 통해 이더리움의 보안 특성을 계승하는 동시에 오프체인 연산을 통해 높은 처리량을 제공합니다. 그러나 정렬 및 RPC 계층에서 새로운 병목 현상이 발생하여, 구조적 복잡성이 일부 문제를 해결하지만 새로운 장애 모드를 발생시킨다는 것을 보여줍니다.
확장성은 여전히 근본적인 문제입니다.
이러한 사고는 반복적인 패턴을 보여줍니다. 블록체인과 거래 시스템은 일반적인 부하에서는 잘 작동하지만 극심한 스트레스에서는 종종 고장이 납니다.
- 솔라나는 일일 트래픽을 효과적으로 처리했지만 거래량이 10,000% 증가하자 붕괴되었습니다.
- DeFi 애플리케이션이 인기를 얻기 전까지 이더리움 의 가스 요금은 적정 수준이었지만, 혼잡으로 인해 급격히 상승했습니다.
- Optimism 의 인프라는 평소에는 원활하게 작동했지만, 25만 개의 주소가 동시에 에어드랍을 신청하면서 문제가 발생했습니다.
- 바이낸스 의 API는 정상적인 거래 중에는 정상적으로 작동했지만, 청산 기간 동안 트래픽 급증으로 인해 제약을 받았습니다. 특히 2025년 10월 사건 당시, 정상적인 거래 중에는 충분했던 바이낸스의 API 속도 제한과 데이터베이스 연결은 청산 기간 동안 트레이더들이 동시에 포지션을 조정하면서 병목 현상이 발생했습니다. 더욱이, 거래소를 보호하기 위해 설계된 강제 청산 메커니즘은 위기 상황에서 오히려 문제를 악화시켜, 많은 사용자가 최악의 순간에 포지션을 매도하게 만들었습니다.
자동 확장은 갑작스러운 부하 급증에는 적합하지 않습니다. 새로운 서버가 가동되기까지 몇 분이 걸리기 때문입니다. 이 시간 동안 마진 시스템은 유동성이 부족한 주문장에서 생성된 잘못된 가격 데이터를 기반으로 포지션을 표시할 수 있습니다. 새로운 서버가 가동될 때쯤이면 이미 청산의 연쇄 반응이 확산된 상태입니다.
드물게 발생하는 스트레스 상황을 처리하기 위한 과도한 프로비저닝은 일일 운영 비용을 증가시키므로, 거래소들은 일반적으로 일반적인 부하에 맞춰 시스템을 최적화하고 간헐적인 장애를 경제적으로 건전한 선택으로 받아들입니다. 그러나 이러한 선택은 다운타임으로 인한 비용을 사용자에게 전가하여, 심각한 시장 변동 시 청산 문제, 거래 정지 또는 자금 접근 차단 등의 문제에 직면하게 됩니다.
인프라 개선

그림 8: 인프라 장애 모드 분포(2024-2025)
2024~2025년 인프라 실패의 주요 원인은 다음과 같습니다.
- 인프라 과부하: 35%(가장 흔함)
- 네트워크 혼잡도: 20%
- 합의 실패: 18%
- 오라클 조작: 12%
- 검증자 문제: 10%
- 스마트 계약 취약점: 5%
여러 가지 아키텍처 개선을 통해 실패 빈도와 심각성을 줄일 수 있지만, 각 개선에는 다음과 같은 상충 관계가 있습니다.
1. 별도의 가격 책정 및 청산 시스템
10월 사건은 부분적으로 증거금 결제를 현물 시장 가격에 연동한 데서 비롯되었습니다. 현물 가격 대신 래핑된 자산 환율을 사용했다면 wBETH 가치 평가의 왜곡을 피할 수 있었을 것입니다. 더 나아가, 주요 위험 관리 시스템은 조작 가능성이 있는 시장 데이터에 의존해서는 안 됩니다. 독립적인 오라클, 다중 소스 집계, 그리고 TWAP 계산을 사용하면 더욱 신뢰할 수 있는 가격을 제공할 수 있습니다.
2. 과도한 프로비저닝 및 중복 인프라
2025년 4월 바이낸스, 쿠코인, MEXC에 영향을 미친 AWS 서비스 중단은 중앙 집중식 인프라 종속성의 위험성을 보여주었습니다. 여러 클라우드 제공업체에 걸쳐 중요 구성 요소를 실행하면 운영 복잡성과 비용이 증가하지만 종속성 장애는 발생하지 않습니다. 레이어 2 네트워크는 자동 장애 조치를 통해 여러 RPC 제공업체를 유지할 수 있습니다. 일반적인 운영 상황에서는 추가 오버헤드가 낭비처럼 보일 수 있지만, 최대 수요 발생 시 몇 시간의 다운타임을 방지할 수 있습니다.
3. 스트레스 테스트 및 용량 계획 강화
시스템의 "고장 나기 전까지는 잘 작동"하는 패턴은 스트레스 테스트가 부적절함을 나타냅니다. 정상 부하의 100배를 시뮬레이션하는 것이 표준 관행이 되어야 합니다. 개발 단계에서 병목 현상을 파악하는 것은 실제 장애 발생 시 병목 현상을 발견하는 것보다 훨씬 저렴합니다. 그러나 현실적인 부하 테스트는 여전히 어렵습니다. 운영 트래픽은 합성 테스트로는 완전히 포착할 수 없는 패턴을 보입니다. 실제 장애 발생 시 사용자 행동은 테스트 시와 다릅니다.
앞으로 나아갈 길
블록체인 시스템은 상당한 기술적 발전을 이루었지만, 스트레스 테스트 측면에서는 여전히 상당한 단점을 안고 있습니다. 현재 시스템은 기존 영업 시간에 맞춰 설계된 인프라에 의존하는 반면, 암호화폐 시장은 전 세계적으로 끊임없이 운영됩니다. 즉, 정상적인 영업 시간 외에 스트레스 상황이 발생하면 팀은 문제를 시급히 해결해야 하며, 사용자는 상당한 손실을 입을 수 있습니다. 기존 시장은 스트레스 상황에서 거래를 중단하는 반면, 암호화폐 시장은 단순히 서킷 브레이커를 구현합니다. 이것이 시스템 기능인지 결함인지는 각자의 관점과 관점에 따라 달라집니다.
과잉 공급은 이 문제에 대한 확실한 해결책이지만, 경제적 유인과 상충됩니다. 초과 용량 유지는 비용이 많이 들고 드문 경우에만 적용됩니다. 치명적인 고장으로 인한 비용이 충분히 높지 않으면 업계가 사전 조치를 취하지 않을 수 있습니다.
규제 압력은 99.9% 가동 시간 요구나 허용 가능한 다운타임 제한과 같은 변화의 원동력이 될 수 있습니다. 그러나 규제는 종종 재난 발생 후에 등장하는데, 2014년 마운트곡스(Mt. Gox) 사태로 인해 일본이 암호화폐 거래소를 공식적으로 규제하게 되었습니다. 2025년 10월의 연쇄 반응은 유사한 규제 대응을 촉발할 것으로 예상되지만, 이러한 대응이 최대 허용 다운타임, 청산 중 최대 슬리피지(slippage)와 같은 결과나 특정 오라클 제공업체, 서킷 브레이커 임계값과 같은 구현 방식을 강제할지는 아직 불확실합니다.
업계는 강세장 동안 성장보다 시스템 견고성을 우선시해야 합니다. 시장 호황기에는 다운타임 문제가 간과되는 경우가 많지만, 다음 주기의 스트레스 테스트를 통해 새로운 취약점을 발견할 수 있습니다. 업계가 2025년 10월의 사건에서 교훈을 얻을지, 아니면 같은 실수를 반복할지는 여전히 미지수입니다. 과거 사례를 보면 업계는 시스템을 적극적으로 개선하기보다는 수십억 달러 규모의 실패를 통해 심각한 취약점을 발견하는 경우가 많습니다. 블록체인 시스템이 압박 속에서도 안정성을 유지하려면 프로토타입 아키텍처에서 프로덕션급 인프라로 전환해야 하며, 이를 위해서는 자금 지원뿐만 아니라 개발 속도와 견고성 간의 균형도 필요합니다.
