청산이 많았다는 사실만으로 프로토콜 사고는 아니다. 가격이 정상적으로 하락해 health factor가 임계값 아래로 내려가 계약 규칙대로 실행됐다면 위험 관리 기능이 작동한 것이다. 반대로 잘못된 오라클·파라미터·코드가 건강한 계정을 청산했다면 결함 피해다. 사고 시점의 담보·부채·가격·threshold·bonus·close factor와 LiquidationCall을 재현해 두 경우를 나눈다.
청산은 기능이지만 잘못된 입력은 사고를 만든다
담보대출 프로토콜은 담보가치가 부채 대비 기준 아래로 내려가면 제3자가 부채를 갚고 담보를 가져가게 한다. 급락장에서 청산이 늘어나는 것은 설계된 동작일 수 있다. 손실 규모가 크다는 이유만으로 해킹이나 오류라고 부르면 안 된다.
사고 여부는 계약이 의도한 입력과 규칙을 사용했는지에서 갈린다. 오라클 가격이 실제보다 낮았거나 snapshot 설정이 어긋났거나 health check가 빠졌다면 규칙 실행 거래 자체는 성공해도 결과가 잘못될 수 있다. ‘정상 실행’과 ‘정상 입력’을 각각 검증한다.
청산 거래가 코드대로 성공했다는 사실은 그 코드가 받은 가격과 설정이 옳았다는 보장이 아니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 청산은 기능이지만 잘못된 입력은 사고를 만든다
담보대출 프로토콜은 담보가치가 부채 대비 기준 아래로 내려가면 제3자가 부채를 갚고 담보를 가져가게 한다.
- 계정 단위로 사건 전 상태를 복원한다
사건 직전 블록에서 담보 수량·가격, 부채 수량·가격, 각 자산 liquidation threshold, eMode·isolation 설정과 이자 누적을 조회한다.
- 2026년 wstETH 사례는 구성 사고였다
2026년 3월 10일 Chaos Labs가 Aave 포럼에 게시한 사후 보고서는 wstETH oracle의 snapshotRatio와 snapshotTimestamp 불일치로 유효 환율이 약 2.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
계정 단위로 사건 전 상태를 복원한다
사건 직전 블록에서 담보 수량·가격, 부채 수량·가격, 각 자산 liquidation threshold, eMode·isolation 설정과 이자 누적을 조회한다. 그 값으로 health factor를 계산하고 청산 거래가 읽은 실제 oracle round를 연결한다. 사건 후 화면의 현재값을 과거 거래에 적용하지 않는다.
Aave V3 설명에서 health factor가 1 아래면 청산 대상이 되고, close factor와 bonus에 따라 상환 부채와 압류 담보가 정해진다. 프로토콜 버전이 바뀌면 V4처럼 target health factor와 동적 bonus를 쓸 수 있으므로 현재 문서를 과거 사건에 소급하지 않는다.
| 항목 | 사건 시점 근거 | 검산 결과 |
|---|---|---|
| 담보·부채 | 계정 reserve 상태와 이자 index | base currency 가치 |
| 가격 | 실제 oracle round·decimals | 독립 기준과 편차 |
| 위험 파라미터 | threshold·eMode·close factor | 청산 적격 여부 |
| 거래 | LiquidationCall calldata·event | 상환·압류·bonus |
| 잔여 상태 | 거래 후 position | bad debt·남은 담보 |
2026년 wstETH 사례는 구성 사고였다
2026년 3월 10일 Chaos Labs가 Aave 포럼에 게시한 사후 보고서는 wstETH oracle의 snapshotRatio와 snapshotTimestamp 불일치로 유효 환율이 약 2.85% 낮아졌고 34개 계정에서 약 10,938 wstETH가 청산됐다고 밝혔다. 작성자는 이를 onchain configuration misalignment로 설명했다. 이는 보고 주체의 원인 분석이며, 책임 범위에 관한 포럼의 후속 논의와 구분해서 읽어야 한다.
같은 보고서는 약 2,600만 달러 청산 규모, liquidator가 얻은 bonus·profit, protocol fee, bad debt 없음과 회수액을 나눴다. ‘2,600만 달러 피해’라고 한 숫자로 쓰면 청산 명목액과 최종 이용자 손실·회수·보상을 혼동하게 된다.
완화·복구·보상은 서로 다른 결론이다
사례에서 즉시 조치로 영향 시장의 wstETH borrow cap을 1로 낮추고 snapshot 파라미터를 다시 맞췄다. 가격을 정상화하고 추가 노출을 막은 것은 완화다. 이미 실행된 청산에서 회수 가능한 bonus를 돌려받고 DAO 재원으로 차액을 보상하는 것은 별도 거버넌스 단계다.
보상 공지는 대상 주소, 기준 거래, 정상 가격 가정, bonus·수수료 포함 여부, 회수액, 지급 자산과 실행 거래를 제시해야 한다. ‘보상 예정’과 지급 완료를 구분한다. 제안 총액도 추가 회수에 따라 바뀔 수 있으므로 기준일을 붙인다.
- 사건 직전 블록의 계정 상태와 oracle round를 저장한다
- 프로토콜 버전별 liquidation 공식과 단위를 재현한다
- 청산 명목액·이용자 손실·bonus·fee·bad debt를 분리한다
- 완화·가격 복구·보상 제안·지급 완료를 따로 기록한다
- 정상 시장 청산과 잘못된 입력 청산의 계정을 구분한다
큰 청산량이 곧 프로토콜 손실은 아니다
정상 청산에서 liquidator는 부채를 상환하고 담보와 bonus를 받는다. 프로토콜은 bad debt를 막고 수수료를 받을 수 있다. 반면 담보가 너무 빠르게 하락하거나 유동성이 부족하면 청산 뒤에도 부채가 남아 bad debt가 생길 수 있다. 압류 담보 명목액 전체를 프로토콜 손실로 잡지 않는다.
시장 변동 사건 보고서는 청산이 적시에 실행됐는지, bonus가 충분했는지, DEX 유동성과 MEV가 결과에 어떤 영향을 줬는지 평가한다. 결함 사건은 정상 가격이었으면 발생하지 않았을 거래를 식별한다. 두 분석의 질문과 보상 논리는 다르다.
재발 방지는 숫자 하나가 아니라 배포 과정에 있다
구성 불일치가 원인이면 파라미터 pair의 불변조건, fork simulation, payload state diff, 독립 reviewer sign-off와 실행 후 모니터링을 강화해야 한다. cap을 보수적으로 낮추는 것은 단기 완화이며 동일 배포 오류를 막는 장기 조치는 아니다.
사후 보고서의 원인·영향·조치가 온체인 기록과 맞는지 검증하고 미해결 질문을 남긴다. 보상 결정은 기술팀 단독 약속이 아니라 DAO 절차와 재원 권한을 따라야 한다. 독자는 공지 댓글의 추정치를 최종 결론으로 인용하지 않는다.
자주 묻는 질문
청산되면 모두 프로토콜 사고인가요?
아니다. 정상 가격과 설정에서 health factor가 임계값 아래가 되면 설계된 청산이다.
청산 규모가 곧 이용자 손실액인가요?
아니다. 상환 부채·압류 담보·bonus·fee·남은 자산·회수·보상을 분리해야 한다.
잘못된 청산은 자동 취소되나요?
완료된 온체인 거래는 보통 자동 취소되지 않는다. 별도 회수와 DAO 보상 실행이 필요할 수 있다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
