스마트 컨트랙트 해킹은 블록체인에 배포된 코드의 결함을 악용해 자산을 빼가는 공격이다.
지금 주목할 점은 패치도 공격의 단서가 될 수 있다는 것이다.
KCBCA Signals가 인용한 Anthropic의 Firefox 익스플로잇 재현 차트에서는 작동하는 개념증명(PoC) 코드가 10분 안에, 완전히 작동하는 익스플로잇이 1시간 안에 나왔다.
Anthropic의 2026년 5월 SCONE 평가에서는 Mythos Preview가 실제로 악용됐던 스마트 컨트랙트 취약점 12개를 모두 익스플로잇해 모의 수익 약 3,500만 달러를 냈다(p.26).
따라서 영향이 큰 패치는 공개 전에 AI를 활용해 비공개로 적대적 시험을 하고, 원래 공격 시연만 막았는지 근본 원인까지 해결했는지 확인해야 한다(p.27).
이 글은 KCBCA Signals Vol.1 Issue 1에 실린 연구 기고 한 편(p.26–27)을 바탕으로 한다.
일요일, 패치 공개 20분 뒤 (논문 속 가상 사례)
논문이 독자에게 상상해 보라고 제시한 가상 사례이다.
한 블록체인 스타트업 개발자가 AI로 취약점을 찾는다.
고객이 수백만 달러를 잃을 수 있는 결함이다.
팀은 작은 신생 프로젝트를 주시하는 공격자보다 먼저 고치려 한다.
일요일, 문서화된 배포 절차에 따라 패치를 공개 테스트넷에 올린다.
평소 30분 걸리는 테스트가 20분째일 때 메인넷 경보가 울린다.
컨트랙트 잔액이 20% 넘게 줄었고, 확인했을 때는 전부 사라졌다(p.26).
논문 속 가상 사례가 보여 주는 스마트 컨트랙트 해킹의 시간표이다.
패치 역분석과 악용은 이미 쓰이던 방식이다.
논문은 "새로운 일은 아니다. 모든 게 더 빨라졌을 뿐이다"라고 짚는다.
공격자가 변경을 감시하고 익스플로잇을 처음부터 끝까지 만드는 에이전트를 갖췄다고 가정해야 한다.
테스트넷에서 수정 사항이 발견되면 며칠씩 대응할 시간이 남는다고 기대할 수 없다(p.26).
앞서 소개한 SCONE의 12개 취약점은 모델 학습 시점 이후 보고됐으며, 결과는 대상별 8회 시도 중 최고치를 기준으로 했다(p.26).
조기 공개와 불완전한 수정, 두 가지 위험
가상 사례의 실패는 공개 테스트넷에서 패치를 먼저 드러낸 '조기 공개'이다.
비공개로 시험하고 메인넷을 먼저 고쳤더라도, AI 모의 해킹을 포함한 검증이 충분했을까?
다른 경로로 같은 버그에 닿는다면 '불완전한 수정'이라는 독립된 위험이 남는다(p.26–27).
스마트 컨트랙트 해킹 대응에서는 공개 시점과 수정 범위를 함께 따져야 한다.
두 위험은 따로 온다 (p.26 그림 3 재구성)
| 구분 | 비밀 유지 | 이미 공개됨 |
|---|---|---|
| 근본 원인 해결 | 통제된 후보 이 배포본 그대로 검증 | 공개 노출 공격자가 역분석할 수 있음 |
| 근본 원인 미해결 | 불완전한 수정 다른 경로가 남을 수 있음 | 복합 노출 두 위험 모두 대응 필요 |
이 표는 위험 점수가 아닌 개념 검토용이다.
비밀을 지켜도 불완전한 수정은 해결되지 않는다(p.26).
공격 시연이 막혀도 근본 원인은 남을 수 있다
구글 프로젝트 제로는 패치가 원래 개념증명(PoC)만 막아 공격자가 다른 경로로 같은 취약점에 도달한 사례를 기록했다(p.27).
스마트 컨트랙트 해킹에서도 기존 공격 코드가 실패한다는 사실만으로 수정이 끝났다고 판단할 수 없다.
배포 전 확인할 질문 5가지
논문은 영향이 큰 배포의 승인 절차에 AI를 활용한 비공개 적대적 시험을 넣으라고 권한다.
근본 원인과 다른 공격 경로, 수정이 새로 만든 약점을 살피고 재현 가능한 결과를 독립적으로 검증해야 한다(p.27).
스마트 컨트랙트 해킹 위험을 점검할 때 다음을 묻는다.
| # | 배포 전 질문 |
|---|---|
| 1 | 비상 상황 전에 운영 환경과 비슷한 비공개 시험 경로를 마련하고, 예산과 연습까지 마쳤나? |
| 2 | 영향이 큰 변경에는 AI 적대적 시험을 배포 기준으로 요구하나? |
| 3 | 약점을 없앴나, 아니면 원래 공격 시연만 막았나? |
| 4 | 바로 이 배포본을 승인할 근거는 무엇이고, 남은 불확실성은 누가 받아들이나? |
| 5 | 검증 중에 안전하게 할 수 있는 일은 무엇인가? |
"우리 패치가 다른 누군가의 공격 지도가 되기 전에, AI로 먼저 패치를 공격해 보고 위험이 줄었다는 증거를 요구해야 한다." — KCBCA Signals Vol.1 p.27
보안시험 AI도 관리해야 한다
논문은 허깅페이스 사고를 예로 들며, 다음 큰 사고가 프로젝트의 AI 보안시험 에이전트에서 시작된다면 어떨지 묻는다(p.27).
시험 환경을 격리하고 외부 통신을 제한하며 실제 서명 키를 그 환경에 두지 않아야 한다.
에이전트가 비공개 수정 내용을 임의의 포럼에 공개하지 않도록 하기 위해서이다(p.27).
자주 묻는 질문
Q1. 테스트넷에서 시험하면 안전하지 않나?
공개 테스트넷에는 패치 내용이 드러난다.
가상 사례의 문제도 조기 공개였다.
변경 감시 에이전트를 가정하면 수정 내용이 공격의 단서가 될 수 있다(p.26).
Q2. 보안 감사를 받으면 끝인가?
논문은 감사를 별도로 다루지 않는다.
비공개 시험과 AI 모의 해킹을 거쳐도 다른 공격 경로가 남을 수 있는지 묻는다(p.26–27).
이 배포본의 승인 근거와 남은 불확실성의 책임자를 확인해야 한다(p.27).
Q3. 작은 프로젝트도 노려지나?
가상 사례의 팀은 작은 신생 프로젝트를 주시하는 공격자와 경쟁한다(p.26).
규모가 작아도 스마트 컨트랙트 해킹에 대응할 시간을 넉넉히 기대할 수는 없다.
한눈에 정리
- 공개된 패치는 버그의 단서가 될 수 있다
- 조기 공개와 불완전한 수정은 별개이다
- 공격 시연보다 근본 원인이 해결됐는지 확인한다
- 보안시험 AI를 격리하고 실제 서명 키를 두지 않는다
스마트 컨트랙트 해킹은 몇 분, 몇 시간 단위로 진행될 수 있다.
다음 배포 전, 위 다섯 질문을 팀 회의에 올린다.
같은 가상 사례는 내일 인스타그램 @kcbca_korea에서 40초 영상으로도 소개한다.
KCBCA Signals Vol.1 Issue 1 원문 읽기 (p.26)
참고: KCBCA Signals Vol.1 Issue 1 Anton Kaiser, "When the Patch Becomes a Roadmap: Rethinking Smart-Contract Security in the AI Era" p.26-27 원문이 인용한 자료: Anthropic(n-days, exploit-evals), Google Project Zero
