SPEAR: An Engineering Case Study of Multi-Agent Coordination for Smart Contract Auditing
이 논문은 스마트 계약 감사를 위해 위험 인식 휴리스틱, 계약 네트워크 프로토콜 기반 작업 할당, 그리고 프로그램 우선 복구 정책을 활용하는 다중 에이전트 조정 프레임워크인 SPEAR 를 제안하고, 이를 중앙 집중식 및 파이프라인 기반 대안과 비교 분석한 사례 연구를 제시합니다.
이 논문은 블록체인 세계의 **'디지털 금고'**인 스마트 계약을 해킹으로부터 지키기 위해, 어떻게 **스마트한 AI 팀 (다중 에이전트 시스템)**을 구성했는지 설명하는 기술 보고서입니다.
기존 방식이 혼자서 일하는 '고수'였다면, SPEAR 는 서로 대화하고 역할을 나누는 **'전문가 팀'**을 만들어 문제를 해결합니다.
🎬 비유: "거대한 건설 현장의 안전 점검"
스마트 계약 감사를 거대한 고층 빌딩을 짓는 현장이라고 상상해 보세요.
스마트 계약: 지어지는 빌딩 (수백억 원의 가치가 걸려 있음).
해커: 빌딩을 무너뜨리려는 악당들.
감사 (Audit): 빌딩이 무너지지 않도록 안전을 점검하는 작업.
❌ 기존 방식의 문제점 (혼자 일하는 고수)
지금까지의 감사는 한 명의 안전 관리자가 모든 것을 혼자 했습니다.
지연: 한 명은 천천히 일해서 빌딩이 완성되기 전에 감사가 끝나지 않았습니다. (2~4 주 소요)
취약성: 관리자가 실수하거나, 도구가 고장 나면 전체 공사가 멈췄습니다.
부서진 결과물: 자동화 도구가 만든 검사 보고서가 틀려서, 관리자가 다시 손으로 고쳐야 했습니다.
✅ SPEAR 의 해결책: "자율적인 안전 팀"
저자들은 SPEAR라는 시스템을 만들었습니다. 이는 혼자 일하는 관리자가 아니라, 각자 전문 분야를 가진 5 명의 로봇 팀원이 모여 일하는 방식입니다.
🤖 SPEAR 팀의 5 명의 멤버와 역할
이 팀은 서로 대화하며 (협상) 일을 합니다.
🧠 계획 담당 (Planning Agent): "현장 지휘관"
역할: "어떤 빌딩을 먼저 점검할까?"를 결정합니다.
특징: 위험도가 높은 곳 (예: 돈이 많이 오가는 곳) 을 먼저 체크합니다. 새로운 위험이 발견되면 계획을 즉시 수정합니다.
비유: 소방서 지휘관이 화재 위험이 높은 건물을 먼저 출동시키는 것과 같습니다.
⚙️ 실행 담당 (Execution Agent): "현장 작업자"
역할: 실제 감사를 수행합니다.
특징: "이건 내가 할게", "그건 너가 해"라고 팀원들과 **입찰 (Auction)**을 통해 일을 분배합니다.
비유: 여러 대의 크레인이 각자 맡은 부분을 효율적으로 들어 올리는 모습입니다.
🛠️ 수리 담당 (Repair Agent): "즉석 고수"
역할: 도구가 만든 검사 코드가 오류가 나면 스스로 고칩니다.
특징: "코드가 컴파일 안 돼?" -> "아, import 문이 빠졌네" -> 자동으로 고침.
핵심: 매번 AI 에게 "다시 만들어줘"라고 돈 들이지 않고, 간단한 실수는 규칙 (프로그래밍) 으로 바로 고칩니다. (PFIR 정책)
비유: 벽돌이 떨어지면 AI 가 다시 쌓아주는 게 아니라, "아, 시멘트가 부족했구나"라고 바로 시멘트를 발라주는 즉흥적인 수리공입니다.
🛡️ 안전 담당 (Command Execution Agent): "안전장비 관리자"
역할: 위험한 도구를 실행할 때 모래상자 (Sandbox) 안에서 실행합니다.
비유: 위험한 화학 물질을 다룰 때 방호복을 입고 격리된 공간에서 실행하는 것과 같습니다.
🤝 조정 담당 (Coordinator Agent): "중재자"
역할: 팀원들이 자원을 두고 싸우면 (예: AI 비용이 부족할 때) 공정하게 나눠줍니다.
비유: "너는 500 원, 나는 200 원이 필요해"라고 할 때, 누가 더 긴급하고 효율적인지 계산해서 돈을 줍니다.
🌟 SPEAR 가 특별한 이유 (세 가지 핵심 기술)
1. "실수해도 멈추지 않는 팀" (자율성과 복구)
상황: 팀원 중 한 명이 인터넷이 끊기거나 도구가 고장 났다고 가정해 보세요.
기존 방식: 지휘관 (중앙 서버) 이 연락이 안 되면 전체 작업이 멈춥니다.
SPEAR: 팀원들은 스스로 판단합니다. "아, 지휘관과 연락이 안 되네? 내가 아는 대로 수리 작업을 계속하자." 연결이 회복되면 다시 보고합니다. 작업이 멈추지 않습니다.
2. "돈을 아끼는 수리 전략" (PFIR)
상황: AI 가 만든 검사 코드가 틀렸을 때, 매번 비싼 AI 에게 다시 물어보면 비용이 폭탄입니다.
SPEAR: 먼저 간단한 규칙으로 고칩니다. (예: 오타 수정, 누락된 파일 추가). 그래도 안 되면 그때 비싼 AI 를 부릅니다.
결과:비용은 줄이고, 성공률은 높입니다. (실험 결과 94% 성공률)
3. "현장 감각을 가진 계획" (신뢰 기반 계획 수정)
상황: 감사를 하다가 "오! 이 빌딩에 큰 구멍이 발견됐다!"라는 소식이 들리면?
기존 방식: 원래 계획대로 끝까지 가거나, 모든 것을 다시 시작합니다.
SPEAR: "아, 그 빌딩이 가장 위험하구나!"라고 즉시 계획을 바꿉니다. 팀원들과 대화하며 우선순위를 바꿉니다.
📊 실험 결과: 얼마나 잘할까요?
저자들은 이 시스템을 **해킹 시뮬레이션 (Damn Vulnerable DeFi)**으로 테스트했습니다.
정확도: 기존 자동화 도구보다 더 많은 해킹 구멍을 찾아냈습니다.
속도: 중요한 위험을 발견하는 속도가 약 2 배 빨라졌습니다.
강건성 (Robustness): 시스템에 고장을 일부러 넣었을 때, SPEAR 팀은 3 배 더 빠르게 회복했습니다. (다른 팀은 멈췄지만 SPEAR 는 스스로 고쳐서 계속 일함)
💡 결론: 왜 이 논문이 중요할까요?
이 논문은 "AI 를 단순히 도구로 쓰는 것"을 넘어, AI 들이 서로 협력하는 '팀'으로 만드는 법을 보여줍니다.
단순한 자동화가 아니라, 스스로 생각하고, 실수를 고치고, 서로 대화하는 시스템을 만들었습니다.
이는 블록체인뿐만 아니라, 복잡하고 실패하기 쉬운 모든 자동화 작업 (예: 자율 주행, 의료 진단, 대규모 소프트웨어 개발) 에 적용할 수 있는 새로운 패러다임입니다.
한 줄 요약:
"혼자서 일하다 지치거나 실수하는 AI 대신, 서로 대화하며 실수를 스스로 고치는 똑똑한 AI 팀을 만들어 스마트 계약을 안전하게 지키자!"
1. 문제 정의 (Problem Statement)
현재 스마트 계약 (특히 DeFi 분야) 의 보안 감사는 다음과 같은 심각한 한계에 직면해 있습니다:
확장성 부족: 기존 감사는 전문가의 수동 분석에 의존하여 2~4 주 소요되며, 프로젝트당 5,00015,000 의 비용이 듭니다. Web3 의 빠른 개발 속도를 따라가지 못합니다.
기존 자동화 도구의 한계:
반응적 (Reactive) 성향: 알려진 패턴을 개별 파일에서 스캔할 뿐, 프로젝트 전체의 맥락을 이해하거나 전략적으로 분석을 지휘하지 못합니다.
취약한 생성 (Brittleness): 생성형 AI 를 활용한 테스트 코드 생성 시 컴파일 오류나 실행 실패가 빈번하며, 이를 자율적으로 복구하는 메커니즘이 부족합니다.
비조율성 (Uncoordinated): 정적 분석, 심볼릭 실행, 퍼징 (Fuzzing) 등 이질적인 도구들이 독립적으로 작동하며, 결과물을 통합하거나 리소스를 효율적으로 배분하지 못합니다.
복잡한 감사 미션: 단일 파일 스캔이 아닌, 상호 의존적인 모듈 간의 상태 재진입 (State-reentrancy) 및 접근 제어 취약점을 식별하고, 이를 검증하는 증거 (실행 추적, 테스트) 를 생성하는 과정은 동적이고 리소스 제약이 심합니다.
2. 방법론 (Methodology: SPEAR Framework)
저자들은 SPEAR (Strategic Planning, Execution, and Automated Repair) 라는 다중 에이전트 시스템 (MAS) 프레임워크를 제안합니다. 이는 고정된 파이프라인이 아닌, 에이전트 간의 상호작용을 통해 적응형 감사를 수행합니다.
2.1 시스템 아키텍처 및 에이전트 역할
SPEAR 는 5 가지 전문 에이전트로 구성되며, 명시적인 프로토콜 (Contract Net, 경매, 계획 협상) 을 통해 조율됩니다.
Planning Agent (AP):
역할: 리스크 인식 휴리스틱을 기반으로 감사 우선순위를 결정하고 계획을 수립합니다.
기능: 새로운 취약점 발견 시 AGM(Alchourrón, Gärdenfors, Makinson) 이론에 부합하는 신념 수정 (Belief Revision) 을 수행하여 계획을 동적으로 재조정합니다.
우선순위 산정: 복잡도, 의존성 리스크, 테스트 커버리지 리스크를 가중치 (α=0.5,β=0.3,γ=0.2) 를 두어 계산합니다.
Execution Agent (AE):
역할: 분석 도구 (Slither, Mythril, Echidna 등) 에 작업을 할당하고 실행을 관리합니다.
기능: Contract Net 프로토콜을 사용하여 작업 할당을 수행합니다.
Repair Agent (AR):
역할: 생성된 테스트 코드 등 취약한 아티팩트의 오류를 자율적으로 복구합니다.
전략:Programmatic-First Repair (PFIR) 정책을 사용합니다. 먼저 결정론적 템플릿 (import 누락, 잘못된 식별자 등) 으로 수정을 시도하고, 실패할 경우에만 비용이 많이 드는 생성형 (Generative) 복구를 호출합니다.
Command Execution Agent (AC):
역할: 샌드박스 (Docker 컨테이너 등) 환경에서 도구를 안전하게 실행하고 리소스 제한을 강제합니다.
Coordinator Agent (ACoord):
역할: 에이전트 간 충돌을 중재하고 공유 리소스 (LLM 토큰 예산 등) 를 할당합니다.
기능: 경매 (Auction) 프로토콜을 통해 효율성 (Benefit-Urgency/Cost) 이 가장 높은 에이전트에게 리소스를 할당합니다.
2.2 핵심 조율 메커니즘
신념 기반 계획 협상 (Belief-based Plan Negotiation): 에이전트들이 국소적 신념 (Local Beliefs) 을 공유하고, 새로운 정보가 들어오면 AGM 준수를 통해 신념을 수정한 후 계획을 협상합니다.
리소스 경매 (Resource Auction): LLM 토큰과 같은 희소 자원을 할당할 때, 에이전트들이 자발적으로 입찰 (urgency, benefit, cost) 을 하여 시스템 전체의 효율성을 극대화합니다.
자율적 복구 (Self-Healing): 네트워크 단절이나 도구 오류 발생 시, 중앙 컨트롤러의 개입 없이 로컬 신념을 유지하며 작업을 계속하거나 복구 전략을 변경합니다.
3. 주요 기여 (Key Contributions)
공학적 사례 연구: 스마트 계약 감사와 같은 복잡한 도메인에서 기존 MAS 조율 패턴 (Contract Net, 경매, 신념 수정) 을 적용하여 자율적 감사를 구현한 최초의 사례 중 하나입니다.
리스크 인식 계획 에이전트: 변화하는 정보에 따라 감사 우선순위를 동적으로 조정하는 에이전트 설계.
프로그램 우선 복구 정책 (PFIR): 생성형 AI 에 대한 의존도를 줄이고, 결정론적 수정을 우선시하여 아티팩트 복구 비용을 절감하는 정책.
자율 복구 및 리소스 중재 프레임워크: 실패 상황에서 중앙 집중식 재시작 없이 에이전트들이 자율적으로 복구하고 리소스를 배분하는 구조.
실증적 평가: 중앙 집중식 및 파이프라인 기반 대안과 비교하여 조율, 복구 행동, 리소스 사용 효율성을 검증했습니다.
4. 실험 결과 (Results)
Damn Vulnerable DeFi (DVD) 벤치마크 및 실제 DeFi 프로토콜을 대상으로 한 실험 결과는 다음과 같습니다.
감사 효과성 (RQ1): SPEAR 는 정적 분석만 사용하는 도구, 순차적 파이프라인, 심지어 동일한 로직을 가진 중앙 집중식 스케줄러보다 높은 정밀도 (Precision 0.89), 재현율 (Recall 0.85), F1-Score (0.87) 를 기록했습니다. 특히 오류가 주입된 상황에서도 더 안정적인 진행을 보였습니다.
PFIR 자기 치유 알고리즘 (RQ2): 생성된 아티팩트 오류에 대해 PFIR 은 94% 의 복구 성공률을 보였습니다. 이는 대부분 결정론적 수정으로 해결되어 LLM 호출 횟수를 64% 감소시켰습니다.
전략적 계획 에이전트의 효율성 (RQ3): 계획 에이전트가 활성화된 SPEAR 는 알파벳 순서로 분석하는 Ablated 버전보다 중요한 취약점을 발견하는 시간 (TFCV) 을 약 3 배 단축했습니다 (18 분 vs 54 분).
MAS 구성 요소의 기여도 (RQ4):
프로토콜: 복구 시간을 1.8 배 단축 (2.3 분 vs 4.1 분).
자율성: 복구 시간을 2.1 배 단축.
자기 치유: 복구 시간을 3.2 배 단축 (2.3 분 vs 7.4 분) 하고 LLM 호출을 31% 감소시켰습니다.
오버헤드: 전체 감사 시간 대비 조율 오버헤드는 약 4.2% 로 낮게 유지되었습니다.
5. 의의 및 결론 (Significance & Conclusion)
패러다임 전환: 스마트 계약 감사를 단순한 도구 실행이 아닌, 에이전트 간 협상과 조율을 통해 이루어지는 동적 미션 (Dynamic Mission) 으로 재정의했습니다.
강건성 (Robustness): 분산된 에이전트 구조와 자율 복구 메커니즘은 부분적 관측 가능성 (Partial Observability) 과 독립적인 실패 모드가 존재하는 현실적인 환경에서 시스템의 지속성을 보장합니다.
자원 효율성: 경매 메커니즘과 PFIR 전략을 통해 고비용의 LLM 호출을 최소화하면서도 감사 품질을 유지했습니다.
한계 및 향후 과제: 도구 (Tool) 의 완전성 가정이 강하고, 현재 중앙 조정 에이전트 (ACoord) 가 단일 장애점 (SPOF) 이 될 수 있습니다. 향후 강화학습 (RL) 을 통한 정책 학습과 중앙 조정자 없는 분산 조율로 확장할 계획입니다.
이 논문은 MAS 패턴이 실제 보안 공학 도메인에서 어떻게 적용되어 확장성, 적응성, 그리고 견고성을 동시에 달성할 수 있는지를 보여주는 중요한 사례 연구입니다.