바이브코딩이 178만달러 해킹을 불렀다

cbETH 가격이 2,200달러에서 1달러로 떨어진 순간

매트릭스 스타일 코드 화면 — 오라클 하나의 설정 오류가 178만 달러를 증발시켰다

2026년 2월 15일 오후 6시 1분(UTC). DeFi 대출 프로토콜 Moonwell에서 거버넌스 제안 MIP-X43이 실행됐다. Chainlink OEV 래퍼 계약을 Base와 Optimism 네트워크의 핵심 시장에 활성화하는 작업이었다. 일상적인 인프라 업그레이드처럼 보였다.

몇 분 후, cbETH(Coinbase Wrapped Staked ETH)의 가격이 약 2,200달러에서 1.12달러로 표시되기 시작했다. 99.9% 폭락. 물론 실제 시장에서 cbETH 가격이 떨어진 건 아니다. Moonwell의 오라클이 잘못된 가격을 보고한 것이다.

청산 봇이 즉각 반응했다. 시스템이 cbETH를 1달러짜리로 인식하니, cbETH를 담보로 맡긴 모든 포지션이 청산 대상이 됐다. 청산자는 1달러 남짓한 채무를 갚고 2,200달러 가치의 cbETH를 가져갔다. 총 1,096.317 cbETH가 청산됐고, 프로토콜에는 1,779,044달러의 부실채권이 남았다.

여기까지는 DeFi에서 종종 발생하는 오라클 사고처럼 보인다. 하지만 이번 사건에는 전례 없는 꼬리표가 하나 붙었다. GitHub 커밋 기록에 **"Co-authored-by: Claude Opus 4.6"**이라는 문구가 찍혀 있었다. AI가 스마트 컨트랙트 코드를 공동 작성하고, 그 코드가 실제 자산 손실로 이어진 최초의 사례로 기록된 것이다.

곱셈 하나가 만든 178만 달러짜리 버그

블록체인 네트워크 시각화 — DeFi 프로토콜의 오라클은 가격 데이터의 생명줄이다

기술적으로 이 사고의 원인은 놀랍도록 단순하다. 오라클이 cbETH의 달러 가격을 계산할 때, cbETH/ETH 환율에 ETH/USD 가격을 곱해야 한다. cbETH는 ETH의 래핑 토큰이므로 cbETH/ETH 비율은 약 1.12다. 여기에 ETH/USD 가격(약 2,000달러)을 곱하면 cbETH의 실제 달러 가치가 나온다.

그런데 MIP-X43의 오라클 설정은 곱셈을 빠뜨렸다. cbETH/ETH 환율만 단독으로 USD 가격으로 사용했다. 그래서 cbETH가 1.12달러로 보고된 것이다. 블록체인 분석 기업 Anthias Labs가 확인한 바로는, 시스템이 "cbETH/ETH 피드에 ETH/USD 가격을 곱하지 않고, 원시 환율을 그대로 전달"했다.

이런 종류의 버그는 전통적인 소프트웨어에서 발생하면 에러 로그 한 줄로 끝난다. 그러나 스마트 컨트랙트에서는 다르다. 블록체인에 배포된 코드는 실행 즉시 효력을 가지고, 되돌리려면 별도의 거버넌스 투표가 필요하다. 코드가 곧 법이다. 그 법에 오탈자가 있었던 셈이다.

Moonwell의 위험 관리자는 이상을 감지한 뒤 cbETH 차용 한도와 공급 한도를 모두 0.01로 즉시 축소했다. 그러나 이미 늦었다. 청산 봇은 블록 단위로 움직인다. 인간이 대시보드를 열어 상황을 파악하는 몇 분 사이, 봇은 수십 건의 청산을 완료했다. 일부 기회주의자들은 한술 더 떠 최소 담보로 cbETH를 과도하게 빌린 뒤 추가 부실채권을 생성하기까지 했다.

결국 181명의 차용자가 피해를 입었고, 순 손실은 약 268만 달러에 달했다. Moonwell은 이후 복구 계획을 제안했지만, 돈이 돌아오는 것과 신뢰가 돌아오는 것은 다른 문제다.

"바이브 코딩된 솔리디티의 첫 번째 해킹"

사건 직후, 블록체인 보안 감사자 Pashov가 X(트위터)에 글을 올렸다. Moonwell의 GitHub 저장소에서 MIP-X43 관련 풀 리퀘스트(PR #578)를 분석한 결과, 여러 커밋이 Anthropic의 Claude Opus 4.6과 공동 작성된 것으로 표시돼 있었다. Pashov는 이 사건을 **"바이브 코딩된 솔리디티 코드의 첫 번째 익스플로잇"**이라 표현했다.

바이브 코딩(vibe coding)은 Andrej Karpathy가 만든 용어다. AI에게 코드 작성을 맡기고, 결과물의 분위기(vibe)만 확인하는 방식을 뜻한다. 웹사이트를 만들거나 간단한 앱을 프로토타이핑할 때는 효율적이다. 하지만 수백만 달러의 자산이 걸린 스마트 컨트랙트에서도 같은 방식이 통할까.

Pashov는 이후 자신의 발언을 보완했다. "이건 경험 많은 솔리디티 개발자도 할 수 있는 실수"라며, 문제의 핵심은 AI 자체가 아니라 **"충분히 엄격한 검사와 end-to-end 검증의 부족"**이라고 정리했다. Moonwell 팀이 별도의 PR에서 단위 테스트와 통합 테스트를 수행했고, 보안 감사 회사 Halborn에 감사를 의뢰한 사실도 확인됐다.

그런데 테스트와 감사를 했는데도 왜 이 버그를 잡지 못했을까. Trading Strategy의 Mikko Ohtamaa는 "가격 건전성에 대한 테스트 케이스가 없었다"고 지적했다. 단위 테스트는 개별 함수가 작동하는지 확인한다. 통합 테스트는 컴포넌트 간 연결을 확인한다. 하지만 **"이 오라클이 실제로 정확한 가격을 반환하는가"**라는 가장 기본적인 검증이 빠져 있었다.

AI가 작성한 코드든 인간이 작성한 코드든, 테스트가 없으면 버그는 살아남는다. 차이가 있다면, AI가 작성한 코드는 작성자가 코드를 완전히 이해하지 못할 가능성이 높다는 점이다. 바이브 코딩의 정의 자체가 "코드를 깊이 읽지 않는다"는 것이기 때문이다.

Moonwell의 반복되는 오라클 사고

이번 사건이 특히 뼈아픈 이유가 있다. Moonwell에게 오라클 오작동은 처음이 아니다. 지난 6개월간 세 번째다.

시기	원인	피해 규모
2025년 10월	오라클 오작동	170만 달러
2025년 11월	오라클 오작동	370만 달러
2026년 2월	cbETH 오라클 설정 오류	178만 달러

6개월간 누적 피해는 700만 달러를 초과한다. 같은 유형의 사고가 세 번 반복됐다는 건, 프로세스에 구조적 결함이 있다는 뜻이다. AI를 탓하기 전에 물어야 할 질문이 있다. 왜 오라클 설정 변경에 대한 자동화된 가격 검증 파이프라인이 없는가. 왜 메인넷 배포 전 포크 환경에서 실제 가격 피드와 대조하는 절차가 없는가.

Moonwell만의 문제도 아니다. 오라클 조작과 설정 오류는 DeFi의 고질적 취약점이다. 2022년에는 41건의 오라클 조작 공격으로 4억 330만 달러가 도난당했다. 2023년에는 오라클 관련 피해가 전체 가격 조작 손실의 49%를 차지했다. 2024년에도 37건, 5,200만 달러의 피해가 발생했다. 2025년 12월에는 Ribbon Finance가 오라클 소수점 불일치로 270만 달러를 잃었고, 2026년 1월에는 Makina Finance가 플래시 론 기반 오라클 조작으로 400만 달러를 탈취당했다.

오라클은 블록체인과 현실 세계를 잇는 다리다. 스마트 컨트랙트는 자체적으로 외부 데이터에 접근할 수 없다. 이더리움의 가격이 얼마인지, 금리가 몇 퍼센트인지, 특정 자산의 시세가 얼마인지 스마트 컨트랙트는 모른다. 오라클이 이 정보를 블록체인 안으로 가져온다. Chainlink, Pyth, Band Protocol 같은 오라클 네트워크가 수천 개의 데이터 소스에서 가격을 수집하고, 합의를 거쳐 온체인에 기록한다.

이 다리가 무너지면 그 위에 세워진 모든 금융 로직이 함께 무너진다. 대출, 청산, 파생상품, 스테이블코인 발행까지, DeFi의 거의 모든 기능이 정확한 가격 데이터에 의존한다. DeFi 프로토콜의 총 예치 자산(TVL)이 수십억 달러에 달하는 상황에서, 오라클의 정확성은 선택이 아니라 생존의 문제다. Moonwell 사건은 이 다리의 나사 하나가 잘못 끼워진 것이다. 그런데 그 나사를 끼운 건 AI였다.

OpenAI가 EVMbench를 꺼낸 타이밍

Moonwell 사건이 터진 지 3일 후인 2월 18일, OpenAI가 Paradigm과 함께 EVMbench를 공개했다. 스마트 컨트랙트의 보안 취약점을 AI가 탐지하고, 패치하고, 익스플로잇할 수 있는지를 측정하는 벤치마크다.

타이밍이 절묘하다. AI가 만든 코드가 178만 달러를 날린 직후, "AI가 보안도 지킬 수 있다"는 메시지를 던진 것이다. 의도적이든 아니든, 이 대비는 강렬하다.

EVMbench는 40개 감사에서 추출한 120개의 검증된 취약점을 다룬다. 대부분 Code4rena 같은 오픈 코드 감사 대회에서 가져온 실전 사례다. 세 가지 모드로 AI를 테스트한다. 탐지(detect), 패치(patch), 익스플로잇(exploit). Rust 기반 하네스가 격리된 환경에서 트랜잭션을 재현하므로 실제 블록체인에 영향을 주지 않는다.

결과는 인상적이다. GPT-5.3-Codex는 익스플로잇 모드에서 **72.2%**를 기록했다. 6개월 전 GPT-5의 31.9%에서 두 배 이상 뛰었다. Paradigm의 파트너 Alpin Yukseloglu는 "처음 작업을 시작했을 때 최고 모델이 Code4rena의 치명적 버그 중 20% 미만만 익스플로잇할 수 있었다"고 밝혔다.

하지만 이 숫자를 곧이곧대로 받아들이기는 어렵다. 벤치마크와 현실은 다르다. EVMbench의 취약점은 이미 발견되고 문서화된 것들이다. 실전에서 보안 감사자가 마주하는 건 아직 아무도 모르는 취약점이다. 기출문제를 잘 푸는 것과 새 문제를 푸는 것은 다르다. 그리고 아이러니하게도 Moonwell 사건의 버그는 EVMbench가 다루는 정교한 익스플로잇이 아니라, 단순한 산술 누락이었다. AI가 복잡한 취약점을 72% 찾아내도, 곱셈 하나를 빠뜨리면 소용없다.

OpenAI는 이와 함께 사이버 방어에 1,000만 달러의 API 크레딧을 약속했다. 오픈소스와 핵심 인프라 보안을 위한 투자라고 설명했다. AI가 만든 문제를 AI로 해결하겠다는 선언이다. 이것이 선순환의 시작인지, 자기 모순인지는 아직 판단하기 이르다.

스마트 컨트랙트에서 바이브 코딩이 위험한 이유

프로그래밍 화면 — 코드 리뷰 없는 바이브 코딩은 스마트 컨트랙트에서 치명적이다

바이브 코딩이 일반 소프트웨어에서도 논란이 되는 건 사실이다. 2024년 Uplevel 연구에 따르면 GitHub Copilot 사용자는 코드를 55% 빠르게 작성하지만 버그가 41% 더 많았다. 하지만 일반 소프트웨어의 버그는 패치로 고칠 수 있다. 스마트 컨트랙트의 버그는 배포 즉시 돈이 움직인다.

일반 웹 앱과 스마트 컨트랙트의 차이를 정리하면 이렇다.

항목	일반 웹 앱	스마트 컨트랙트
버그 수정	즉시 핫픽스 배포	거버넌스 투표 후 재배포
피해 범위	사용자 경험 저하	자산 손실 (비가역적)
롤백	가능	불가능 (블록체인 특성)
코드 실행 시점	서버 요청 시	트랜잭션 제출 즉시
공격 반응 시간	수 시간~수 일	수 초~수 분 (봇 자동화)

cheqd의 공동 창립자 겸 CEO Fraser Edwards는 이 사건에 대해 흥미로운 구분을 제시했다. AI 코딩에는 두 가지 맥락이 있다는 것이다.

첫 번째는 기술적 배경이 없는 창업자가 AI에게 스마트 컨트랙트를 통째로 맡기는 경우다. 생성된 코드를 검토할 능력이 없으니 결과물을 그대로 배포한다. 이건 명백한 위험이다.

두 번째는 경험 많은 개발자가 성숙한 엔지니어링 프로세스 안에서 AI를 보조 도구로 활용하는 경우다. 리팩토링을 가속화하거나 패턴을 탐색하는 데 쓴다. 이건 합리적이다.

문제는 두 경우를 외부에서 구별하기 어렵다는 점이다. GitHub 커밋에 "Co-authored-by: Claude"가 찍혀 있을 때, 그 코드가 첫 번째 맥락에서 나온 것인지 두 번째 맥락에서 나온 것인지 알 수 없다. Moonwell의 경우 테스트와 감사가 있었으니 두 번째에 가깝지만, 결과는 첫 번째와 다르지 않았다.

Edwards는 AI가 생성한 스마트 컨트랙트 코드를 **"신뢰할 수 없는 입력(untrusted input)"**으로 취급해야 한다고 주장했다. 웹 보안에서 사용자 입력을 절대 신뢰하지 않는 것처럼, AI의 출력도 같은 수준의 검증을 거쳐야 한다는 것이다.

Edwards가 제시한 구체적 권고사항은 다음과 같다. 첫째, 엄격한 버전 관리와 명확한 코드 소유권. AI가 어떤 코드를 생성했는지 추적 가능해야 한다. 둘째, 다중 인원 동료 검토. 한 사람이 AI 출력물을 확인하는 것으로는 부족하다. 셋째, 접근 제어, 오라클 로직, 업그레이드 메커니즘 등 고위험 영역에 대한 집중 테스트. 오라클 가격이 실제 시장 가격과 일치하는지 확인하는 테스트는 선택이 아니라 필수다.

"궁극적으로 책임감 있는 AI 통합은 거버넌스와 규율에 달려 있다"는 그의 결론은 단순하지만 핵심을 찌른다. 도구가 아무리 강력해도, 그 도구를 사용하는 프로세스가 취약하면 결과는 같다.

AI가 만든 문제, AI가 해결할 수 있나

Moonwell 사건과 EVMbench 출시는 같은 주에 벌어졌다. 하나는 AI 코딩의 위험을, 다른 하나는 AI 보안의 가능성을 보여줬다. 이 두 사건을 함께 놓으면, AI와 스마트 컨트랙트의 관계가 어디로 향하는지 윤곽이 드러난다.

비관적 시나리오는 이렇다. 바이브 코딩이 DeFi 개발에 확산되면서, 코드를 깊이 이해하지 못하는 개발자가 늘어나고, 오라클 설정 같은 기초적인 실수가 반복된다. AI 보안 도구가 발전해도 새로운 취약점 패턴이 더 빠르게 등장한다.

낙관적 시나리오도 있다. EVMbench 같은 벤치마크가 표준이 되면서, AI 에이전트가 배포 전 자동으로 스마트 컨트랙트를 검증하는 파이프라인이 일반화된다. 코드 작성과 코드 검증 양쪽에서 AI가 활용되면서, 인간 감사자가 놓치는 패턴까지 잡아낸다. CI/CD 파이프라인에 AI 보안 에이전트가 통합되어 PR이 올라올 때마다 자동으로 취약점을 스캔하고, 오라클 가격의 건전성까지 검증하는 미래가 올 수 있다.

현실은 아마 그 사이 어딘가에 있을 것이다. 분명한 건, 지금은 두 시나리오 중 비관적 쪽에 더 가깝다는 것이다. EVMbench의 72.2%라는 수치는 이미 알려진 취약점에 대한 성능이다. 그리고 Moonwell 사건의 버그는 AI가 아니라 기본적인 통합 테스트로도 잡을 수 있었다. 문제는 AI의 능력이 아니라, AI를 둘러싼 프로세스의 부재다.

Pashov의 말이 가장 정확하다. "AI 뒤에는 완성된 결과물을 검사하는 사람이 있고, 어쩌면 보안 감사자도 있다. 신경망만 탓하는 건 올바르지 않다." 그러나 그 "검사하는 사람"이 코드를 제대로 읽지 않았다면, AI가 작성했든 인간이 작성했든 결과는 같다.

바이브 코딩의 진짜 위험은 AI가 나쁜 코드를 만드는 데 있지 않다. 나쁜 코드가 만들어졌을 때, 그것을 발견할 사람이 줄어드는 데 있다. 코드를 쓰는 속도는 빨라졌지만, 코드를 읽는 사람은 줄었다.

GitHub의 PR #578을 다시 보자. 한 기여자가 지난 주간 1,000회 이상의 커밋을 수행한 것으로 나타났다. 인간이 하루에 수백 건의 커밋을 생산할 수 있는 건 AI 덕분이다. 문제는 그 수백 건의 커밋을 검토할 인간의 수는 그대로라는 것이다. 코드 생산량은 AI와 함께 폭발적으로 늘었지만, 코드를 읽고 검증하는 능력은 인간의 한계에 묶여 있다. 이 비대칭이 사고를 부른다.

스마트 컨트랙트처럼 한 줄의 실수가 수백만 달러를 움직이는 영역에서, 코드 생산과 코드 검증 사이의 이 불균형은 구조적 위험이다. 178만 달러는 시작일 수 있다. DeFi의 총 예치 자산이 커지고, 바이브 코딩을 채택하는 개발자가 늘어날수록 다음 사고의 규모는 더 커질 가능성이 높다. 2022년 Ronin 브릿지 해킹은 6억 달러를 넘겼다. 오라클 하나의 설정 오류가 프로토콜 전체를 무너뜨릴 수 있다는 건 이미 증명됐다.

결국 중요한 건 AI를 쓰느냐 안 쓰느냐가 아니다. AI가 작성한 코드를 누가, 어떻게, 얼마나 깊이 검증하느냐다. Moonwell의 178만 달러는 그 질문에 대한 답을 미루면 치러야 할 대가가 얼마인지 보여준 수업료다.

출처: