AI 스마트 컨트랙트 리뷰: 발견 사항이 곧 감사는 아니다
요약
AI를 활용한 스마트 컨트랙트 리뷰 시 모델의 발견 사항을 즉각적인 감사 결과로 신뢰해서는 안 된다고 경고합니다. 모델은 취약점 패턴을 찾는 보조 도구(triage)로서 유용하지만, 실제 보안 리뷰를 위해서는 실행 경로와 경제적 조건 등 컨텍스트에 대한 인간의 검토가 필수적입니다.
핵심 포인트
- AI의 발견은 감사 결과가 아닌 검토를 위한 단서(lead)로 취급해야 함
- 모델은 비즈니스 로직이나 프로토콜 경제학 등 복잡한 컨텍스트를 놓칠 수 있음
- 효과적인 리뷰를 위해 도구 증거, 실행 경로, 인간 검토의 결합이 필요함
- LLM은 전통적인 보안 도구를 완전히 대체하기보다 보조 역할에 적합함
AI 스마트 컨트랙트 리뷰 (AI Smart Contract Review)
공개 사항: 소스 수집 및 편집 검토를 위해 AI 도구가 사용되었습니다. 이 기사는 인간 저자에 의해 작성되었으며, 저자가 사실 관계, 코드 및 결론을 확인했습니다.
암호화폐 위험 고지: 이 기사는 기술적인 설명이며 투자 조언이 아닙니다. 이는 어떠한 암호화폐 자산의 매수, 매도 또는 보유를 권장하는 것이 아닙니다.
AI 스마트 컨트랙트 리뷰 (AI Smart Contract Review)는 팀이 모델의 문장을 감사 결론으로 취급할 때 실패합니다. 유용한 버전의 AI 스마트 컨트랙트 리뷰는 더 좁은 범위를 가집니다. 즉, 모델은 의심스러운 코드를 지적할 수 있지만, 누군가가 이를 감사 결과라고 부르기 전에는 해당 발견 사항이 도구 증거 (tool evidence), 실행 경로 (execution path), 표준 요구 사항 (standard requirement), 그리고 인간의 검토 (human review)를 통과해야 합니다.
실질적인 함정은 모델이 항상 틀리다는 것이 아닙니다. GPTScan, iAudit, Smart-LLaMA와 같은 논문들은 모두 모델 보조의 가치를 지지합니다. 문제는 유용한 분류 (triage)가 완전한 보안 리뷰 (security review)와 동일한 주장이 아니라는 점입니다.
발견의 경계 (Finding Boundary)
AI 스마트 컨트랙트 리뷰의 첫 번째 경계는 "모델이 무언가를 알아차렸다"와 "컨트랙트에 악용 가능한 이슈가 있다" 사이에 존재합니다. 이 경계는 매우 중요한데, 모델은 익숙한 취약점 패턴을 설명할 수는 있지만, 해당 이슈를 실질적으로 만드는 배포 컨텍스트 (deployment context), 외부 호출 경로 (external call path), 스토리지 레이아웃 (storage layout), 또는 경제적 조건 (economic condition)을 놓칠 수 있기 때문입니다.
Ince 등의 2025년 조사는 좋은 시작점으로서의 제약 조건을 제공합니다. 왜냐하면 이 조사는 대규모 언어 모델 (Large Language Model, LLM)의 취약점 탐지를 유망하게 보면서도, 전통적인 도구를 대체할 준비는 되지 않았다고 다루기 때문입니다. AI 스마트 컨트랙트 리뷰는 그러한 주의를 계승해야 합니다. 모델의 발견은 단서 (lead)이지, 승인 (sign-off)이 아닙니다.
오탐 (False Positive) / 미탐 (False Negative)
유용한 버전의 AI 스마트 컨트랙트 리뷰는 발견 사항이 어떻게 실패했는지를 기록합니다. 아래의 결과물은 의도적으로 작게 구성되었습니다. 왜냐하면 감사 결정 (audit decision)에는 모델의 주장, 도구 증거, 놓친 컨텍스트, 그리고 인간의 검토를 분리할 수 있는 압축된 공간이 필요하기 때문입니다.
| 리뷰 보조 도구 | 포착 가능한 사항 | 오탐 (False positive) 형태 | 미탐 (False negative) 형태 | 인간 감사 결정 |
|---|---|---|---|---|
| LLM 리뷰 | 익숙한 취약점 패턴, 의심스러운 제어 흐름 (Control flow), 누락된 체크 설명 | 모델이 도달 불가능하거나 완화된 코드를 공격 가능한 것으로 라벨링함 | 모델이 비즈니스 로직, 프로토콜 경제학, 또는 숨겨진 상태 결합 (State coupling)을 놓침 | 발견 사항으로 취급하기 전에 공격 경로, 영향도 및 해결 방법을 확인 |
| ... |
이 표는 이 글의 핵심 결과물입니다. AI 스마트 컨트랙트 리뷰 (AI Smart Contract Review)는 이 표를 통해 모든 모델의 주장을 "확인됨", "오탐", "도구에 의해 누락됨", 또는 "수동 위협 모델링 리뷰 필요" 중 하나로 강제함으로써 리뷰 시간을 보호합니다.
하이브리드 증거 (Hybrid Evidence)
가장 강력한 AI 스마트 컨트랙트 리뷰 패턴은 모델을 단독으로 두지 않습니다. GPTScan은 하이브리드 아이디어를 지원합니다: 모델을 사용하여 발생 가능한 시나리오를 추론한 다음, 정적 분석 (Static analysis)을 사용하여 해당 주장을 확인하거나 필터링하는 데 도움을 주는 방식입니다.
이러한 하이브리드 설계가 유용한 이유는 바로 모델의 권위를 약화시키기 때문입니다. AI 스마트 컨트랙트 리뷰는 "모델이 계약을 감사했다"가 아니라, "모델이 이것을 제안했고, 정적 증거가 그 중 일부를 확인했다"라고 말해야 합니다.
이유 불일치 (Reason Mismatch)
두 번째 AI 스마트 컨트랙트 리뷰 경계는 올바른 라벨 (Label)과 올바른 이유 (Reason)를 구분합니다. iAudit는 이 지점에서 유용한데, 리뷰어의 연구 요약에 따르면 헤드라인 지표와 이유 일치도 사이에 격차가 있으며, 저자의 참조 값에 대한 이유 일치도가 낮다는 점이 언급되었기 때문입니다.
이러한 한계는 워크플로우를 변화시킵니다. AI 스마트 컨트랙트 리뷰는 모델이 제시한 이유가 리뷰어가 확인할 수 있는 코드 경로 (Code path), 공격자 역량 (Attacker capability), 상태 전제 조건 (State precondition), 그리고 자산 영향도 (Asset impact)를 명시하지 않는 한, 모델의 취약점 명칭을 그대로 수용해서는 안 됩니다.
model_claim:
label: reentrancy (재진입성)
reason: external call before balance update (잔액 업데이트 전 외부 호출)
...
이 기록은 의도적으로 지루하게 작성되었습니다. AI 스마트 컨트랙트 리뷰 (AI Smart Contract Review)는 확신에 찬 모델의 단락이 보안 결정이 되도록 방치하는 대신, 불확실성을 가시화해야 합니다.
도구의 경계 (Tool Boundary)
AI 스마트 컨트랙트 리뷰 내에서도 기존의 도구들은 여전히 중요합니다. Slither는 취약점 탐지기, 신뢰도/영향도 카테고리, CI 통합 및 체크리스트 출력을 갖춘 Solidity 및 Vyper를 위한 정적 분석 (static-analysis) 프레임워크라고 스스로를 정의합니다.
그렇기에 Slither는 유용한 증거일 뿐, 최종 판결은 아닙니다. AI 스마트 컨트랙트 리뷰는 Slither의 탐지 결과를 검사해야 할 구체적인 신호로 취급해야 합니다. 즉, 조건이 어디에 있는지, 해당 경로가 도달 가능한지, 어떤 값이 영향을 받는지, 그리고 모델이 동일한 내용을 설명했는지 아니면 단순히 취약점 이름만 일치시켰는지를 확인해야 합니다.
심볼릭 경계 (Symbolic Boundary)
심볼릭 실행 (Symbolic execution)은 AI 스마트 컨트랙트 리뷰에 또 다른 경계를 제공할 뿐, 마법 같은 증명은 아닙니다. Mythril은 심볼릭 실행을 통해 일반적인 EVM 취약점 클래스를 드러낼 수 있다는 점에서 가치가 있지만, 제한된 실행 (bounded execution)은 여전히 시간, 경로 깊이, 환경 및 상태 공간 (state space)에 대한 가정 내에서 작동합니다.
이러한 한계는 표를 작성할 때 유용합니다. 만약 Mythril이 모델이 놓친 경로를 찾아낸다면, 모델은 미탐 (false negative)을 발생시킨 것입니다. 만약 모델이 심볼릭 실행과 수동 검토로 재현할 수 없는 익스플로잇 (exploit)을 주장한다면, 모델은 감사 결과가 아닌 오탐 (false positive)을 발생시켰을 가능성이 높습니다.
업그레이드 경계 (Upgrade Boundary)
업그레이드 위험은 AI 스마트 컨트랙트 리뷰가 단순화하기 쉬운 영역인데, 왜냐하면 업그레이드 안전성은 단순히 "함수가 위험해 보이는가"의 문제가 아니기 때문입니다. OpenZeppelin Upgrades는 스토리지 레이아웃 (storage-layout) 호환성 및 업그레이드 안전성 검증과 같은 체크에 집중하며, 이는 프로젝트 구성 및 참조 컨트랙트 (reference contracts)에 따라 달라집니다.
그 경계는 왜 감사가 모델 리뷰 (model review)보다 더 광범위해야 하는지를 보여주는 좋은 예시입니다. AI 스마트 컨트랙트 리뷰 (AI Smart Contract Review)는 프록시 패턴 (proxy pattern)을 지적할 수 있지만, 팀이 업그레이드 위험을 판단하기 전에는 여전히 스토리지 차이 (storage diff), 초기화 함수 (initializer) 동작, 비활성화된 체크 (disabled checks), 그리고 배포 이력 (deployment history)에 대한 검토가 필요합니다.
표준 경계 (Standard Boundary)
표준은 마케팅용 증거가 아니라 AI 스마트 컨트랙트 리뷰의 목표입니다. OWASP SCSVS와 EEA EthTrust Security Levels는 진지한 리뷰가 무엇을 다루어야 하는지 프레임을 잡는 데 도움을 주며, SWC Registry는 레지스트리 자체에서 활발하게 유지 관리되지 않고, 불완전하며, 오류가 포함될 수 있다고 명시하고 있으므로 주의해서 다루어야 합니다.
그러한 분리는 흔한 지름길을 방지합니다. AI 스마트 컨트랙트 리뷰는 "모델이 SWC를 발견했으므로, 이것은 감사되었다"라고 말해서는 안 됩니다. 더 나은 기록 방식은 어떤 요구사항이나 취약점 카테고리가 관련이 있는지, 어떤 코드 증거가 이를 뒷받침하는지, 그리고 검토자가 여전히 확인해야 할 사항이 무엇인지를 명시하는 것입니다.
모델 출력 (Model Output)
모델 출력은 AI 스마트 컨트랙트 리뷰에 포함되지만, 반드시 라벨(label)이 있어야 합니다. LLM4Vuln은 모델의 추론 (model reasoning), 모델의 지식 (model knowledge), 제공된 컨텍스트 (supplied context), 그리고 프롬프팅 효과 (prompting effects) 사이의 유용한 구분을 지원합니다. 이러한 구분은 모델이 확신에 찬 어조로 말할 때 스마트 컨트랙트 팀에 정확히 필요한 요소입니다.
실질적인 규칙은 간단합니다. AI 스마트 컨트랙트 리뷰는 첫 번째 가설을 작성할 수 있습니다. 감사 기록에는 두 번째 계층이 필요합니다: 소스에 연결된 증거, 도구(tool)를 통한 확인 또는 모순, 그리고 취약성 (exploitability) 및 영향력 (impact)에 대한 인간의 결정입니다.
최종 분류 (Final Triage)
AI 스마트 컨트랙트 리뷰는 판결이 아니라 대기열 (queue)입니다. 모델은 코드 경로를 대기열로 이동시킬 수 있고, 정적 분석기 (static analyzer)는 의심을 강화하거나 약화시킬 수 있으며, 심볼릭 실행기 (symbolic executor)는 경로를 테스트할 수 있고, 표준은 리뷰 의무를 명시할 수 있습니다.
감사는 그러한 대기열(queue)이 생성된 이후에 시작됩니다. 이것이 위양성/위음성(false-positive/false-negative) 표가 존재하는 이유입니다. 이 표를 통해 팀들은 모델이 아직 보안 리뷰(security review)의 영역으로 남아 있는 부분을 이미 수행했다고 가장하지 않고도 모델을 사용할 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기