Web3 스마트 컨트랙트의 신뢰할 수 있는 감사 (Audit)와 단일 신경망의 사각지대를 제거하기 위해, 로컬 다중 에이전트 AI 컨실리엄(Consilium)인 Egregor 시스템이 적용됩니다. SovereignBankWeb3 은행의 컨트랙트를 테스트할 때, 단일 모델들 (Gemini, DeepSeek, ChatGPT, Grok, Claude)은 13번의 수동 반복 과정 동안 4개의 치명적인 취약점 (DoS 벡터, 취약한 스테이블코인 검증 및 재진입 (Reentrancy) 위험 포함)을 놓쳤습니다. 역할 분담(사실 교차 검증 알고리즘 및 "집단 사고" 제거 포함)을 갖춘 5개 모델의 컨실리엄을 통한 구조화된 실행은 OpenRouter API를 통해 단 0.40달러의 비용으로 단 한 번의 실행 만에 이러한 오류들을 찾아냈습니다.

스마트 컨트랙트 감사 접근 방식 비교 (단일 AI vs Egregor 컨실리엄):

다음은 이 감사가 정확히 어떻게 수행되었는지, 왜 모델을 수동으로 하나씩 검토하는 방식이 더 이상 작동하지 않는지, 그리고 코드 검증을 위해 신경망 간의 효과적인 상호작용을 어떻게 설정하는지에 대한 상세한 케이스 스터디 (Case-study)입니다.

이 기사에서는 AI의 집단 지성을 사용하여 어떻게 Web3 은행의 스마트 컨트랙트 감사를 수행했는지 설명하고, 스마트 컨트랙트 감사 수행의 세부 사항을 공개하겠습니다. EGREGOR 프로그램의 작동 원리와 기능에 대해서는 다음 기사에서 다룰 예정이며, 제 잘못된 생각이었을 수도 있지만 이 프로그램이 Mythos 및 Gemini Ultra보다 나은 점이 무엇인지도 설명하겠습니다.

저는 몇 주 동안 제 Web3 뱅킹인 SovereignBank Web3의 스마트 컨트랙트들을 오늘날 거의 모든 사람이 하는 방식대로, 즉 한 번에 하나의 모델씩 사용하여 검사해 왔습니다. 이것은 실제 수동 프로세스가 어떻게 진행되었는지, 그리고 구조화된 실행이 무엇을 다르게 만들었는지에 대한 메커니즘을 포함한 전체 이야기입니다.

13번의 수동 감사

대상은 모듈형 컨트랙트 세트였습니다: 부모 컨트랙트인 SovereignBankPro.sol과 자식 컨트랙트인 SovereignAutoPay.sol, SovereignCashback.sol, SovereignMath.sol, SovereignTimelock.sol, SovereignVaults.sol, 그리고 83개의 모든 테스트를 100% 통과하는 테스트 폴더 전체와 깨끗한 컴파일 결과물입니다.

모든 모델이 아카이브(archive) 파일을 수용하는 것은 아니었기에, 저는 모든 것을 하나의 텍스트 문서로 모았습니다. 문서 상단에는 폴더 및 파일 구조와 기술 스택(tech stack)을 배치했고, 그다음 모든 컨트랙트(contract)의 소스 코드를, 마지막으로 테스트 코드를 배치했습니다. 각 감사(audit)를 시작하기 전, 저는 먼저 모델에게 한 가지를 물었습니다. "이 컨트랙트에 대한 정보를 이해했습니까?" 그리고 확인을 받은 후에만 작업을 시작했습니다.

각 개별 감사에는 정확히 하나의 프롬프트(prompt)만을 사용했으며, 다섯 가지 모델 모두에게 동일한 프롬프트를 사용했습니다. 대략 다음과 같았습니다. "이것은 SovereignBankWeb3 은행의 스마트 컨트랙트(smart contract)입니다. 여기 폴더/파일 구조와 기술 스택이 있습니다. 감사를 수행하여 오류와 취약점(vulnerability)을 찾아내고, 수정 지침을 작성하며 개선 사항을 제안하십시오." 단 하나의 프롬프트였습니다. 사용된 다섯 가지 모델은 Gemini Pro, DeepSeek, ChatGPT, Grok, 그리고 Claude Opus였습니다.

그 후 통합(consolidation) 작업은 수동으로 진행했습니다. 저는 다섯 가지 감사를 엄격하게 구조화된 별도의 텍스트 문서로 모았습니다. 어떤 모델이 무엇을 말했는지 정리하다 보니 약 4,000~6,000줄에 달하는 방대한 양이 되었습니다. 저는 이 문서를 Gemini Pro와 Claude에게 각각 전달했고, 각 모델은 통합된 보고서를 출력했습니다. 이제 저에게는 두 개의 요약본이 생겼습니다. 그런 다음 저는 교차 검증(cross-check)을 위해 Claude의 보고서를 Gemini에, Gemini의 보고서를 Claude에 보내며 단 하나의 최종 판결이 나올 때까지 반복했습니다. 즉, 오류, 취약점, 그리고 수정 권장 사항이 포함된 단일 통합 감사 결과가 나올 때까지 말입니다.

그 작업이 끝나면 저는 코드로 돌아가 수정 사항을 반영하고 다시 시작했습니다. 다섯 개의 새로운 감사, 수동 통합, 교차 검증, 하나의 판결. 이 과정을 13번 반복했습니다.

저를 짜증 나게 했던 점은 모델들이 단 한 번의 과정으로 모든 것을 찾아내지 못했다는 것입니다. 매 라운드마다 새로운 것이 떠올랐습니다. 회차가 거듭될수록 발견되는 오류의 수는 줄어들었고, 대략 10번째 감사쯤 되었을 때 다섯 모델 중 세 모델이 저에게 컨트랙트가 깨끗하다고 말했습니다. "심각한 취약점이 없습니다", "구조가 좋습니다", "프로덕션(production) 준비가 되었습니다". 지구상 최고의 AI 다섯 개가 의견을 같이한 것입니다.

그들은 틀렸습니다. 그리고 저는 그들을 개별적으로 질문하는 것을 그만두고 나서야 그 사실을 알게 되었습니다.

이 방식이 작동은 했지만, 왜 잘못된 도구였을까요?

실제로 이 과정이 어떠했는지 보십시오. 저는 마치 위원회를 지휘하는 중재자 역할을 수동으로 수행하고 있었습니다. 복사해서 붙여넣기, 구조화, Gemini와 Claude 사이의 교차 검증 — 저는 13번이나 컨베이어 벨트이자 손 역할을 했습니다. 하나의 프롬프트에 5개의 모델을 곱하고, 여기에 13번의 라운드를 곱한 셈입니다. 서류상으로는 거의 우스운 수준입니다.

이것이 바로 도구가 해결해 주었어야 할 갈증입니다.

구조화된 실행(Structured run)이 무엇을 다르게 만드는가

여러 모델이 개별적으로 답변하는 것이 아니라 구조화된 위원회처럼 함께 작동하게 만드는 로컬 데스크톱 애플리케이션인 Egregor를 구축한 후, 저는 동일한 컨트랙트를 이를 통해 다시 실행해 보았습니다.

'코드 리뷰 (Code-review)' 모드에서의 스마트 컨트랙트 감사(Audit)는 절약 모드에서도 최소 10개의 프롬프트를 사용합니다. 그 메커니즘은 다음과 같습니다. '코드 리뷰' 모드는 5개의 모델이 각각 자신의 역할을 맡도록 프리셋을 로드하며, 이는 시작을 위한 5개의 프롬프트를 의미합니다. 여기서 '역할 (Role)'은 고유한 프롬프트를 가진 샌드박스(Sandbox)입니다. 역할이 부여된 모델은 해당 프롬프트에 따라 작동하며, 압축, 절약 또는 '순차적 (Turn-based)' 모드와 같은 기능을 활성화하면 프롬프트가 변경될 수 있습니다. 역할은 프리셋에 의해 자동으로 할당될 수도 있고, 사용자가 필요한 역할에 모델을 직접 드래그하여 배치할 수도 있습니다. '안티-그룹싱크 (Anti-Groupthink)'를 활성화하면 2개의 프롬프트가 추가되고 모델들이 역할을 교대합니다. 이는 단순히 병렬로 연결된 요청이 아닌 진정한 협업입니다. '레드 팀 (Red Team)'을 활성화하면 역할 교대와 함께 또 다른 합의(Consensus) 라운드가 추가됩니다. 그러면 당신은 이미 5개의 모델이 5개의 역할을 수행하는 상황에서 10개가 넘는 프롬프트를 사용하게 됩니다. 여기서 더 나아갈 수도 있습니다. 최대 12개의 역할까지 확장할 수 있으며, 각 역할은 고유한 프롬프트를 가지고 하나의 역할에 여러 모델을 배치할 수도 있습니다. 5~6개의 모델로 감사를 수행하기에 충분하며, 그 후 모델들의 역할을 바꾸어 두 번째 실행을 진행할 수 있습니다.

이 역할 프롬프트 (role prompts)의 내용은 공개하지 않겠습니다. 이는 도구의 지적 재산이기 때문입니다. 하지만 가장 많은 노력이 필요했던 부분, 즉 모델들이 실제로 비판적인 태도를 갖도록 만드는 과정에 대해 설명하겠습니다. 모든 대규모 모델 (large models)은 예의 바르게 동의하고 칭찬하도록 학습되었습니다. 오직 Grok만이 무례하게 굴 수 있는 여유가 있었습니다. 따라서 역할 프롬프트에는 두 가지 규칙이 내장되었습니다. 첫째, 상대방이 사실과 증거를 제시할 때까지 다른 참여자에게 동의하지 말 것. 둘째, 직접 가서 그 사실을 확인할 것. 두 번째 규칙이 중요한 이유는 — 이 실행 과정에서의 실제 사례처럼 — Gemini가 때때로 아예 존재하지 않는 사실을 제공하기도 했기 때문입니다.

실행 과정은 실시간으로 확인할 수 있습니다. Egregor에 컨트랙트가 포함된 폴더나 압축 파일을 추가하고 (Egregor는 모든 내용을 모델이 이해할 수 있게 만듭니다), 감사를 설정한 뒤 시작을 누르면 됩니다 — 일반적인 채팅창과 같습니다. 즉시 참여 모델 목록이 나타나며, 모델들이 생각하고 답변을 준비하는 동안 목록이 깜빡입니다. 라운드가 종료되면 각 모델의 답변은 카드로 그룹화되어, 클릭하여 전체 내용을 읽고, 복사하고, 저장할 수 있습니다. 그 후 다음 라운드가 이어지며, 라운드 횟수는 설정 및 활성화된 모드에 따라 달라집니다. 마지막으로 모더레이터 (moderator)가 최종 판결을 내립니다.

무엇을 찾아냈는가, 고장 난 부분을 포함하여

이 실행에서 정확히 어떤 일이 일어났는지에 대해 솔직하게 말씀드리겠습니다. 왜냐하면 여기서 솔직함이야말로 핵심이기 때문입니다.

이 컨실리움 (consilium, 협의체)은 의도적으로 소박하게 구성되었으며, 5개 모델 중 3개는 무료 모델이었습니다 — 비싼 구성이 아니었습니다. 파이프라인 (pipeline)은 5단계로 이루어져 있습니다. 1단계인 심층 아키텍처 분석 (deep architectural analysis)은 완료되지 않았습니다: fetch 오류와 함께 중단되었습니다. 이 오류는 도구가 아닌 OpenRouter 측의 문제였습니다; Egregor는 이를 숨기는 대신 단순히 공백을 기록하고 최종 판결에 이를 보고했습니다. 실행은 2~5단계로 계속 진행되었습니다.

그럼에도 불구하고 — 첫 번째 단계가 실패하고 주로 무료 모델을 사용했음에도 불구하고 — 이 과정은 단일 모델이 13번째 수동 반복 (manual iteration) 단계에서 이미 인지하지 못하게 된 4개의 치명적인 문제를 찾아냈습니다.

첫 번째 — executeAutoPay 함수에서의 재진입 (reentrancy) 위험입니다. nonReentrant 수정자 (modifier)가 있음에도 불구하고, 외부 토큰 전송이 상태 변경 (state changes)과 인접해 있어 발생했습니다. 해결책: 모든 상태 변경을 외부 호출 (external call) 이전에 수행하고, 이후에 잔액 불변량 (balance invariant)을 확인합니다.

두 번째 — createStandingOrder에서의 입력 검증 (input validation) 부재입니다. 금액, 간격, 수취인에 대한 어떠한 검사도 없었으며, 이는 서비스 거부 (DoS, Denial of Service) 공격 벡터를 열어주고 작동하지 않는 주문을 생성할 수 있게 했습니다.

세 번째 — initialize 함수에서의 스테이블코인 (stablecoin) 검증 취약성입니다. try/catch 구문이 비표준 토큰을 거부하는 대신 토큰 호환성 오류를 조용히 삼켜버렸습니다.

네 번째 — 배포자 (deployer)의 영구적인 권한 문제입니다. 관리자 역할 (admin roles)이 타임락 (timelock)에 위임되지 않아 배포자가 지속적인 통제권을 갖게 되었습니다. 이는 단순한 오타가 아닌 아키텍처적 위험 (architectural risk)입니다. 단일 모델이 정확히 놓치는 부분입니다.

발견된 사항들의 구체적인 예시를 보여주기 위한 검증 포함 수정 예시입니다:

진정으로 나의 신뢰를 얻은 것

컨실리엄 (Consilium)은 단순히 발견 목록만을 제공한 것이 아니었습니다. 그들은 스스로 확인하지 않은 부분들을 직접 선언하기도 했습니다. 몇몇 함수(emergencyWithdrawFull, claimInheritance, finalizeRecovery)를

여러 모델이 하나의 코드를 분석한 뒤, 서로의 결론을 읽고 공격하기 시작하면 빈틈이 일치하지 않게 됩니다. 한 모델이 놓친 것을 다른 모델이 잡아냅니다. 한 모델이 지어낸 것을 다른 모델이 거부합니다. 특히 모델들에게 동의하기 전에 사실 관계를 확인하도록 강제했을 때 더욱 그렇습니다. 13번의 단독 실행(single pass)이 모두 거짓된 "모두 깨끗함"이라는 결론에 도달했던 이유는, 각 모델이 개별적으로는 순응적이고 확신에 차 있었기 때문입니다. 구조화된 실행(structured run)은 — 비록 단계가 깨지거나 주로 무료 모델을 사용하더라도 — 그런 결론에 도달하지 않았습니다.

비용은 얼마나 들었나

전체 감사(audit) 비용은 API 토큰 기준으로 약 40센트 정도 들었습니다. 5개 모델 중 3개는 무료이며, 유료 모델이 소비한 양에 대해서만 비용을 지불하기 때문입니다. 비용은 중간 매개체 없이 사용자의 API 키에서 직접 차감됩니다. 전문 업체는 이와 유사한 검증에 수천 달러를 요구합니다. Egregor가 5,000만 달러 규모 프로토콜을 위한 완전한 인간 감사(human audit)를 대체할 수는 없지만, 인디 개발자, 해커톤, 학습 및 사전 검증을 위해서는 게임의 판도를 완전히 바꿔놓습니다.

친구들이여, EGREGOR를 단순히 감사자(auditor)로만 간주해서는 안 됩니다. 그 활용 범위는 훨씬 더 넓습니다. 몇 가지 예시는 다음과 같습니다: 정치적 예측, 드라이버 개발, 출력 및 주조를 위한 3D 모델 개발, 건강기능식품(БАД)용 공식 개발(이후 인증 필요), 책 및 기사 집필, 텍스트 및 기술 문서의 정밀 번역, 법률 상담 및 토론, 트레이딩, 비즈니스 분석, 심리학 등. 이 모든 과정은 토론을 시작하기 전에 사용자가 직접 선택한 여러 AI 모델을 거치게 됩니다. 한 개의 머리도 좋지만, 한 개의 머리에 여러 최첨단 모델의 조언이 더해지면 훨씬 더 좋습니다.

누가 이 뒤에 있는가

저는 솔로 파운더(solo-founder)인 Vladislav Shter입니다. 저는 '주권(sovereignty)'이라는 하나의 아이디어를 중심으로 작은 도구 생태계를 구축하고 있습니다. 즉, 기업이 아닌 여러분이 자신의 데이터, 돈, 그리고 AI를 통제해야 한다는 것입니다. Egregor는 앞선 글에서 언급한 바로 그 멀티 AI 컨실리엄(multi-AI concilium)입니다. 코드 리뷰(code review) 외에도 28개의 전문가 프리셋(expert presets)을 갖추고 있습니다. 또한 여러분이 방금 분석한 컨트랙트의 주인공인 비수탁형 뱅킹(non-custodial banking) 서비스 SovereignBank Web3, 블록체인을 통해 도메인을 허용하는 DNS 없는 브라우저 SovereignWeb3 Browser, 그리고 스마트폰을 위한 OS 수준의 데이터 격리 기술인 Sovereign도 있습니다.

Egregor는 여러분의 로컬 머신에서 작동하며, OpenRouter를 통해 무료 및 유료 모델을 지원합니다. 그리고 단 하나의 신념을 바탕으로 구축되었습니다. AI의 다음 도약은 더 큰 모델이 아니라, 더 똑똑한 아키텍처(architecture)라는 것입니다. 이미 보유하고 있는 모델들이 서로 협력하게 만드십시오. 그러면 개별 모델이 단독으로는 절대 없다고 장담했을 법한 오류를 잡아낼 것입니다.

전체 감사(audit) 내용은 제 GitHub의 EGREGOR 리포지토리(repo)에서 확인하실 수 있습니다.

단일 AI는 컨트랙트가 깨끗하다고 말합니다. 하지만 컨실리엄은 컨트랙트가 실제로 어디가 깨끗하지 않은지, 그리고 어디를 살펴보지 못했는지를 말해줍니다.

다음 글에서는 제 개인적인 견해로 EGREGOR가 Mythos와 Gemini Ultra보다 강력하다고 주장하는 대담함을 발휘해 볼 것이며, 그 이유도 설명하겠습니다.

상세 정보: https://gitverse.ru/wadyas/Egregor/content/master

GitHub: https://github.com/VladislavShter/Egregor

데모 영상:

개발자: https://github.com/VladislavShter/VladislavShter