2분간의 프라그마 오라클 오류, Vesu에서 300만 달러 청산으로 번진 과정

2026년 9월 4일, 단 2분간의 가격 데이터 오류가 Starknet 기반 대출 프로토콜 Vesu에서 약 300만 달러 규모의 비정상 청산으로 이어졌다. 프라그마(Pragma)의 상위 가격 피드가 04:08~04:10 UTC에 잘못된 가격을 제공했고, 여러 Vesu 풀의 차입 포지션 47개가 청산 가능한 상태로 판정됐다. 32

핵심은 이것이 Vesu 스마트계약의 취약점이 아니라 오라클 입력값 오류였다는 점이다. 계약은 주어진 가격을 기준으로 설계된 규칙을 실행했지만, 그 판단의 출발점인 가격 자체가 잘못됐다. 32

2분 동안 무슨 일이 있었나

디파이(DeFi) 대출 시장은 담보 가치와 부채 가치를 계속 비교한다. 담보비율이 프로토콜이 정한 기준 아래로 떨어지면, 청산자는 통상적인 청산 기능을 실행해 담보를 가져갈 수 있다.

이번 사례에서는 잘못된 프라그마 가격이 47개 포지션을 실제와 달리 담보 부족으로 보이게 했다. 자동 청산이 이어지면서 가격 피드가 정상화되기 전 약 300만 달러의 담보가 청산됐다. 2032

따라서 ‘스마트계약이 설계대로 작동했다’는 설명은 ‘경제적으로 올바른 결과가 나왔다’는 뜻이 아니다. 스마트계약은 온체인에 제공된 데이터를 검증하고 실행할 수는 있어도, 오라클 가격이 실제 시장을 제대로 반영하는지 스스로 판별하지는 못한다.

잘못된 가격이 정상 포지션을 청산시키는 이유

대출 프로토콜의 청산 로직은 의도적으로 기계적이고 신속하게 움직인다. 실제 담보 가격이 급락했을 때 대응이 늦으면 대출자 측에 부실채권 위험이 생길 수 있기 때문이다. 그러나 이 자동성은 잘못된 가격도 실제 급락과 똑같이 청산 기준을 넘길 수 있다는 뜻이기도 하다.

흐름은 간단하다.

1. 오라클이 대출 시장에서 쓰이는 가격을 게시한다.
2. 프로토콜은 그 가격으로 담보와 부채의 건전성을 다시 계산한다.
3. 포지션이 담보 기준을 밑돈 것으로 표시된다.
4. 청산자가 정상 청산 절차를 실행한다.

Vesu 사태에서는 1단계의 가격 입력이 틀렸을 뿐, 청산 경로가 우회되거나 스마트계약이 공격당한 것은 아니라는 것이 Vesu의 설명이다. Vesu는 프로토콜 측 계약 수정이 필요하지 않았다고 밝혔다. 32

Vesu의 대응: 풀 일시 중단, 자금 회수 시도, 이용자 안내

Vesu에 따르면 프라그마와 관련 당사자들은 근본 원인에 대한 수정책을 배포했으며, 가격 피드는 사고 발생 2분 안에 자체 정상화됐다. Vesu는 완화 조치 이후 풀 큐레이터들이 영향을 받은 풀의 일시 중단을 해제할 것으로 예상했다. 32

또한 Vesu는 프라그마, StarkWare, Starknet Foundation, 풀 큐레이터들과 함께 피해 이용자의 자금 회수를 추진하고 있다고 밝혔다. 다만 이는 회수 노력의 개시를 의미하며, 모든 이용자에 대한 상환이 완료됐다는 확정 발표는 아니다. 2432

영향을 받은 이용자에게 공개된 안내는 다음과 같다.

• Earn 포지션을 유지할 것. 출금하면 회수 절차의 자격에 영향을 줄 수 있다.
• 이번 사고로 청산됐다면 Vesu Discord를 통해 지원 티켓을 제출할 것. 2734

풀별 상태는 큐레이터의 조치에 따라 달라질 수 있다. 따라서 모든 시장이 영향을 받았다고 단정하거나 모든 풀이 같은 상태라고 보기보다, Vesu의 최신 공식 사고 공지와 지원 안내를 확인하는 것이 필요하다.

수정책과 기술 보고서: 알려진 것과 아직 모르는 것

공개된 정보로 확인된 사실은 비교적 명확하다. 문제의 원인은 상위 프라그마 가격 피드였고, 오류는 약 2분 지속됐으며, 피드는 자체 정상화됐다. 관련 당사자들은 근본 원인에 대한 수정책을 배포했다. 2332

반면 잘못된 가격값이 생성된 정확한 기술적 메커니즘과 최종 보상 체계는 아직 공개되지 않았다. Vesu는 상세 기술 보고서를 내놓겠다고 예고했다. 보고서가 나오기 전까지는 구체적 소프트웨어 결함, 공개된 상위 피드 문제를 넘어선 책임 소재, 최종 자금 회수 결과에 관한 주장을 확정된 사실로 볼 수 없다. 27

반복되는 오라클 리스크: Aave와 Switchboard 사례

Vesu 사례는 ‘코드가 정확해도 데이터가 틀리면 금융 결과도 틀릴 수 있다’는 오라클 문제를 보여준다.

Aave의 2026년 3월 wstETH 가격 불일치

2026년 3월 10일 Aave의 이더리움 Core 및 Prime 시장에서는 CAPO 리스크 오라클 사고로 유효 wstETH/stETH 환율이 약 2.85% 낮게 반영됐다. 이 잘못된 가치 산정은 약 2,660만 달러의 청산 규모로 이어졌다. Aave 사후 분석은 광범위한 시장 붕괴가 아니라 스냅샷 비율과 스냅샷 타임스탬프 간 불일치를 원인으로 지목했다. 1011

Vesu와 마찬가지로 청산 규칙이 멈춘 것이 문제가 아니었다. 잘못된 가치 평가에 그 규칙이 적용됐다는 점이 핵심이었다.

Switchboard의 Move 환경 보안 침해 의혹

별도의 더 심각한 오라클 위험 유형도 있다. Switchboard는 Move 기반 배포 환경의 잠재적 보안 침해 보고 이후 Aptos, Sui, IOTA, Movement에서 오라클 운영을 중단했다. 이 조치는 예방적 중단이었으며, 해당 체인들의 블록 생산 자체가 멈춘 것은 아니다. 34

보도에서는 조작된 IOTA 가격 데이터, 비정상적인 VUSD 발행, 청산이 이 사건과 연결됐다고 전했다. 다만 명확한 조사 결과가 나오기 전까지 이 사안은 어디까지나 보안 침해 의혹으로 규정하는 것이 타당하다. 25

더 강한 오라클 안전장치는 어떤 모습인가

단일 장치만으로 모든 잘못된 가격 입력을 막을 수는 없다. 현실적인 목표는 짧은 가격 이상이 곧바로 되돌리기 어려운 손실로 이어질 가능성을 낮추는 것이다. 일반적으로 거론되는 방안은 다음과 같다.

• 하나의 입력 경로에 의존하지 않는 독립적 복수 가격 소스 사용
• 비정상적으로 큰 가격 변동을 거부하거나 중단시키는 편차 한도
• 오래된 데이터를 현재 가격으로 사용하지 않도록 하는 갱신 지연 검사
• 서킷브레이커와 풀 단위 비상 중단 기능
• 영향이 큰 오라클 설정 변경에 대한 지연 또는 검토 절차
• 변동성이 크거나 구조가 복잡한 자산에 대한 보수적 담보 파라미터

대신 절충점도 존재한다. 안전장치를 강하게 하면 실제 시장 급변에 대한 대응이 느려질 수 있고, 느슨하게 하면 잘못된 데이터에 자동 청산이 반응할 가능성이 커진다. Vesu의 2분 사고는 이 균형이 왜 디파이 리스크 설계의 핵심인지를 보여준다.

차입자 입장에서는 청산 위험이 시장 변동성이나 스마트계약 해킹에만 국한되지 않는다. 자신의 포지션 건전성을 결정하는 오라클의 데이터 무결성, 설정, 운영 회복력 역시 위험 요인이다.