원본 출처: Beosin
최근 몇 년 동안 GPT-4, Claude, Gemini와 같은 대규모 언어 모델들이 뛰어난 코드 이해 능력을 보여주며, Solidity, Rust, Go와 같은 스마트 계약 언어를 효과적으로 읽어내고 재진입 공격이나 정수 오버플로와 같이 코드 특성이 뚜렷한 고전적인 취약점을 식별해냈습니다. 이러한 성과를 바탕으로 업계에서는 대규모 모델을 활용하여 수동 계약 감사 지원하거나 심지어 대체할 수 있을지에 대한 논의가 활발해지고 있습니다.
범용 모델은 특정 프로젝트의 업무 로직에 대한 이해가 부족하기 때문에 복잡한 DeFi 프로토콜을 대면 때 오탐률이 높고, 계약 간 상호 작용이나 경제 모델을 통해 탐지해야 하는 취약점을 놓치는 경향이 있습니다. 이에 업계에서는 범용 모델에 스마트 계약 보안에 필요한 전문 지식 기반, 탐지 규칙, 업무 맥락을 주입하는 "스킬" 메커니즘을 추가하는 방안을 제안했습니다. 이 메커니즘은 일반적인 기능에만 의존하여 코드의 문제점을 판단하는 대신, 감사 과정에서 더 명확한 판단 기준을 제공합니다.
AI 감사 스킬 향상에도 불구하고 여전히 적용 범위가 명확하게 정의되어 있습니다. 알려진 취약점 패턴을 스캔하고 코드 스타일을 검사하는 데는 탁월하지만, 전체 프로토콜 설계, 계약 간 상호 작용 로직 또는 경제 모델에 대한 심층적인 이해가 필요한 복잡한 취약점을 효과적으로 처리하는 데는 현재 어려움을 겪고 있습니다 . 이러한 유형의 문제는 여전히 경험이 풍부한 감사 전문가가 필요하며, 복잡한 계산 로직이 포함된 시나리오에서는 더 강력한 안전장치를 제공하기 위해 형식 검증이 필요합니다. 이러한 배경에서 Beosin은 스킬 향상 AI 기반 기본 검사 + 심층적인 인간 감사+ 형식 검증의 3단계 감사 모델을 구축했습니다. 각 구성 요소는 고유한 초점을 가지고 있으며 서로를 보완합니다.
I. 일반 인공지능 모델의 감사 능력 한계: 통제된 비교 테스트 및 사례 분석
이 글에서는 수동 감사 이미 거친 프로젝트 라이브러리에서 테스트 케이스로 활용될 두 가지 유형의 계약을 선정합니다. 첫 번째 유형은 상대적으로 독립적인 로직과 명확한 기능적 경계를 가진 단순 계약입니다. 이러한 프로젝트는 일반적으로 AI 감사 도구가 가장 풍부한 학습 데이터를 확보할 수 있고 이론적으로 가장 유리한 시나리오입니다. 두 번째 유형은 다중 계약 상호 작용, 복잡한 상태 머신 또는 프로토콜 간 종속성을 포함하는 복잡 계약입니다. 이는 또한 업계에서 AI가 수동 감사 대체할 수 있는지에 대한 논의에서 가장 자주 언급되는 리스크 시나리오이기도 합니다.
이번 비교에서는 동일한 코드베이스를 사용했으며, 먼저 AI가 독립적으로 감사 실행하여 보고서를 생성한 다음, 이를 사람이 감사 보고서와 한 줄씩 대조했습니다. 두 보고서의 생성 과정은 완전히 독립적이었습니다. 즉, 사람 감사 보고서를 작성할 때 AI의 결과를 전혀 알지 못했으므로 상호 영향을 방지할 수 있었습니다. 마지막으로, 다음 네 가지 측면에서 결과를 분석할 것입니다.
사례 A: 표준 토큰 계약(BSC-USDT / BEP20USDT.sol)
첫 번째 테스트 세트에서는 Solidity 0.5.16으로 작성된 표준 BEP-20 토큰 계약을 선택했습니다. 이 계약의 로직은 비교적 독립적이고 기능적 경계가 명확하며, 다른 계약과의 상호 작용이 없습니다. 주요 보안 리스크 몇 가지 일반적이고 알려진 취약점 패턴에 집중되어 있습니다. 이론적으로 이러한 유형의 계약은 현재 AI 감사 에 가장 유리한 시나리오입니다. 학습 데이터에는 이러한 표준 토큰 계약이 많고, 규칙 기반 취약점 특성이 매우 명확하기 때문입니다.
AI는 6개의 경고(고위험 2개, 중위험 1개, 저위험/제안 3개)를 생성했는데, 이는 상당한 수입니다. 저위험 및 제안 경고는 일반적으로 정확했으며, 오래된 Solidity 버전이나 부적절한 상태 변수 노출과 같은 일반적인 코딩 스타일 문제를 다루어 참고 가치가 있습니다. 그러나 AI가 생성한 두 개의 "고위험" 경고는 모두 오판이었습니다. AI는 소유자의 발행 권한과 중앙 집중식 권한을 고위험 취약점으로 태그, 실제로는 USDT와 같은 중앙 집중식 스테이블코인의 경우 소유자의 발행 권한은 예상되는 설계 특징이며, 리스크 평가는 다중 서명 제어, 권한 관리 메커니즘, 계약 업그레이드 전략 등을 종합적으로 고려한 판단에 기반해야 합니다. 이러한 권한 구조의 합리성은 코드 자체보다는 프로젝트의 업무 모델에 근본적으로 달려 있습니다 . AI는 이러한 맥락을 고려하지 않고 단순히 패턴 매칭에만 의존하여 판단을 내렸습니다.
이 테스트 사례는 AI가 권한 구조는 인식할 수 있지만, 업무 맥락과 고려했을 때 권한이 합리적인지 판단할 수는 없다는 것을 보여줍니다. 따라서 AI는 USDT 유형 계약 소유자의 발행 권한을 "고위험 취약점"으로 직접 태그. 이는 실제 업무 로직과 동떨어진 전형적인 오판입니다. 이러한 오경보는 프로젝트 팀이 실제 리스크 판단하는 데 방해가 될 수 있습니다.
사례 B: 복잡한 업무 계약 (IPC 프로토콜 / 2025-02-리콜)
두 번째 테스트 세트에서는 Code4rena 플랫폼의 공개 보고서(보고서 링크: code4rena.com/reports/2025-02-recall)에 포함된 IPC 프로토콜 프로젝트를 선택했습니다. 이 프로젝트는 게이트웨이, 서브넷 액터, 다이아몬드 프록시 패턴과 같은 여러 상호 의존적인 핵심 구성 요소를 포함합니다. 이 프로젝트의 보안은 전체 프로토콜 아키텍처와 구성 요소 간 상호 작용 논리에 대한 심층적인 이해에 크게 의존하며, 이는 DeFi 생태계에서 고가치 공격에 대한 전형적인 시나리오를 나타냅니다. 아래는 AI 감사 결과입니다.
복잡한 계약의 경우, AI 감사 3건의 고위험 경고와 6건의 중간 위험 경고를 생성하여 양호한 수준의 결과를 보여주었습니다. 그러나 이 중 상당수는 감사 오경보로 판단했습니다. AI가 맥락이 부족한 코드 조각에 대해 잘못된 리스크 평가를 내렸기 때문입니다. 한편, 감사 확인한 9건의 고위험 취약점 중 AI는 1건만 완벽하게 탐지했고, 2건은 발견되었으나 위험 등급이 크게 낮아졌으며(실제로는 고위험이었지만 AI는 중간 위험으로 보고), 나머지 6건은 전혀 탐지하지 못했습니다. 4건의 중간 위험 취약점 중 AI는 1건을 탐지했고, 3건은 완전히 누락되었습니다.
이러한 취약점들은 공통적인 특징을 공유합니다. 즉, 단일 함수의 패턴 매칭이 아닌 프로토콜의 구성 요소 간 상태 전환 경로에 대한 포괄적인 추론에 의존한다는 것입니다. 수동 감사 보고서의 H-01(서명 재생)을 예로 들면, 공격 경로는 다중 서명 검증의 설계 의도, 공격자가 중복 서명 세트를 구성하는 방법, 그리고 이러한 동작이 가중치 임계값을 우회하는 방법을 이해하는 것을 요구합니다. H-06(leave() 함수 재진입 공격)도 유사합니다. 이 취약점은 서브넷 부트스트랩의 중요 상태에만 존재하므로 스테이킹 흐름, 부트스트랩 트리거 조건, 외부 호출 시점 간의 상호 의존성을 이해해야 합니다. 이와 유사한 심층 논리 취약점은 AI의 경고 목록에 기록되지 않습니다.
연구 결과는 복잡한 계약을 감사 때 AI의 감사 능력은 로컬 코드의 패턴 인식에 기반하는 반면, 프로토콜 수준의 취약점은 전체 업무 로직에 대한 오해에서 비롯될 수 있음을 보여줍니다. 취약점 발생 조건이 여러 계약, 여러 상태, 여러 호출 수준에 걸쳐 있는 경우, 현재 AI의 추론 능력으로는 이를 효과적으로 탐지하기에 불충분합니다.
요약하자면, 두 사례 모두 AI 감사 가치가 없는 것은 아니라는 점을 보여줍니다. AI 감사 는 알려진 취약점 패턴, 코드 스타일 검사, 그리고 몇 가지 독립적인 관점 발견에 상당한 기여를 합니다 . 그러나 그 가치의 한계는 매우 분명합니다. AI 감사는 기본 검사로는 활용될 수 있지만, 보안 결론으로 직접 사용할 수는 없습니다. 복잡한 프로토콜의 경우, 보안 판단을 내릴 때 AI 보고서에만 의존하면 리스크 취약점을 놓칠 뿐만 아니라, 품질이 낮은 경고가 대량 으로 발생하여 팀의 검토 시간을 대량 낭비하게 됩니다. 바로 이러한 이유로 Beosin은 전용 Skill 지식 기반을 구축하고 감사 프로세스에 3단계 감사 모델 메커니즘을 도입했습니다.
II. 전문 기술 지식 기반: AI 기준선 검사를 강화하기 위한 엔지니어링 경로
AI 기반 감사 기본 감사 프로세스에 통합하려면 실제 DeFi 프로토콜을 감사 때 발생하는 높은 오탐률과 오분류율 문제를 해결하는 것이 중요합니다. 접근 제어, AMM 유동성 메커니즘, 크로스체인 브리지 메시지 검증, 대출 프로토콜의 청산 로직 등 어떤 분야든 AI는 현재 표면적인 코드 특징에 기반한 단순 일치 여부 판단에만 그치고 있습니다. 특정 업무 시나리오 및 공격/방어 로직과 이러한 특징을 결합하여 코드에 문제가 있는지 여부를 판단하는 데 어려움을 겪습니다. 이 문제를 해결하는 핵심은 감사 전문가의 축적된 경험을 체계적인 방식으로 AI의 판단 과정에 접목하여 일정 수준의 업무 이해도를 부여하는 것입니다.
하지만 AI 역량 강화에도 불구하고 감사 에서 AI의 역할은 변하지 않는다는 점을 분명히 해야 합니다. 여러 계약이 얽혀 있는 복잡한 문제, 경제 모델 분석, 새로운 공격 방식 등에 있어서는 인간의 감사 여전히 필수적입니다 . AI 역량 강화의 목적은 AI의 능력 범위 내에서 (일반적인 취약점 패턴 식별 및 제한적인 업무 이해 등) 초기 스캔의 품질을 실질적으로 유용한 수준으로 끌어올려, 반복적인 검토가 필요한 무의미한 경고를 대량으로 생성하는 대신 인간 감사 에 더욱 가치 있는 초기 결과를 제공하는 것입니다.
2.1 감사 실무에서 추출한 내용: 기술 규칙의 구성 메커니즘
Beosin의 스킬 지식 기반은 수동 감사 거친 4,000개 이상의 스마트 계약 프로젝트에서 비롯되었습니다. 감사 전문가들은 이러한 규칙들을 대량 요약하고 다듬었으며, 하나하나 검증하고 체계화했습니다. 각 규칙은 취약점 발견부터 규칙 구현에 이르는 전체 과정을 거쳐 생성됩니다. 실제 프로젝트에서 보안 문제를 발견한 후, 감사 공격 경로를 완벽하게 재구성하고, 근본 원인을 심층적으로 분석하며, 해결 방안의 효과를 검증합니다. 그리고 최종적으로 이러한 공격 및 방어 관련 지식을 상황별 판단 조건을 포함한 규칙 항목으로 정리하여 후속 감사 위해 스킬 라이브러리에 통합합니다.
다음은 스킬 라이브러리의 샘플 규칙으로, 취약점 패턴, 공격 경로, 근본 원인 및 해결 권장 사항이라는 네 가지 차원에 걸쳐 구조를 가지고 있습니다 .
[Beosin-AMM_Skill-1] 이체 주문을 통한 유동성 감지 우회 기능 추가
취약점 패턴: 계약은 페어의 WBNB 잔액 준비금을 초과하는지(balanceOf >= reserve + required) 확인하여 유동성 추가 작업이 발생하는지 여부를 판단합니다. 이 감지 방식은 WBNB가 토큰보다 먼저 페어에 도착한다는 가정에 기반하지만, 라우터의 addLiquidityETH 함수는 항상 ERC-20 토큰을 먼저 전송한 후 WETH를 전송하며, addLiquidity 함수의 전송 순서는 매개변수 order에 따라 결정됩니다.
공격 경로: 공격자는 `addLiquidityETH` (토큰이 먼저 전송됨)를 사용하거나 `addLiquidity(Token, WBNB, ...)`를 호출하여 WBNB보다 먼저 토큰을 해당 페어로 전송하기만 하면 됩니다. 공격이 발생하면 WBNB가 아직 도착하지 않았고, `balanceOf == reserve`이므로 탐지 함수가 false를 반환하여 "유동성 추가 금지" 제한을 완전히 우회할 수 있습니다.
근본적인 원인은 페어 잔액 스냅샷 기반의 탐지 방식이 설계 단계에서 스왑과 유동성 추가 작업을 확실하게 구분할 수 없다는 점입니다. 이는 구현상의 버그가 아니라 아키텍처상의 결함입니다.
권장 해결책: 화이트리스트에 등록되지 않은 주소가 Pair로 직접 자금을 이체하는 것을 금지하도록 시스템을 변경하십시오. 모든 거래는 계약의 내장 함수를 통해 완료되어야 하며, 이를 통해 아키텍처 수준에서 잔액 스냅샷 감지의 근본적인 결함을 해결할 수 있습니다.
이 규칙은 단순히 특정 코드 패턴에 라벨을 붙이는 것이 아니라, 공격 유형에 대한 체계적인 분석을 담고 있습니다. 즉, 공격 조건이 어떻게 형성되는지, 공격자가 탐지를 우회하기 위해 어떤 경로를 거치는지, 탐지 메커니즘에 구조적 결함이 있는 단계는 어디인지, 그리고 수정이 필요한 단계는 어디인지 등을 분석합니다.
2.2 지식 기반의 범위
Beosin은 Solidity, Rust, Motoko, FunC, Go, ZK 등 주요 Web3 기술 스택을 포괄하는 전문 기술 취약점 데이터베이스를 개발했습니다. 핵심 콘텐츠는 내부용으로만 사용되며 공개되지 않습니다. 디렉토리 구조는 다음과 같습니다.
각 전문 저장소 내의 스킬은 취약점 유형에 따라 별도로 관리됩니다. 각 규칙에는 번호, 트리거 조건, 공격 경로 재구성, 상황 판단 논리 및 해결 방안이 포함됩니다. 전체 스킬 저장소는 새로운 공격 이벤트 발생 및 감사 사례 누적에 따라 지속적으로 업데이트되어 온체인 실제 위협 환경과 항상 동기화됩니다.
2.3 스킬 개입 후 기준선 검사 품질 비교
Skill 라이브러리가 기본 스캔 품질에 미치는 실제 영향을 정량화하기 위해 2장의 두 가지 테스트 사례를 벤치마크로 사용하고, 동일한 코드베이스에서 일반 AI와 Skill로 강화된 AI를 각각 실행한 후 항목별로 결과를 비교했습니다.
사례 A: 표준 토큰 계약(BEP-20) 비교 결과
사례 B: 복잡한 업무 계약 비교 결과 (IPC 프로토콜)
비교 결과, Skill 도입으로 두 가지 유형의 계약 모두에서 취약점 탐지 품질이 크게 향상되었음을 알 수 있습니다. 표준 토큰 계약 시나리오에서는 업무 컨텍스트 판단 기능 추가로 위험도가 높은 오탐이 완전히 제거되었습니다. 복잡한 업무 계약 시나리오에서는 알려진 취약점 패턴 탐지율이 11%에서 44%로 증가했고, 오탐률은 약 55%에서 약 30%로 감소했으며, 심각도 수준 판단 정확도 또한 크게 향상되었습니다. 이 보고서는 기준선 점검 자료로 활용되어 프로젝트 팀이 코드의 잠재적 결함을 사전에 파악하는 데 도움을 줄 수 있습니다. 이러한 문제들이 단기적으로 직접적인 금전적 손실을 초래하지는 않더라도, 향후 프로젝트 유지 관리 및 업그레이드에 중요한 긍정적인 영향을 미칩니다.
하지만 데이터는 AI 기능의 본질적인 한계도 명확히 보여줍니다. 스킬 향상 기능을 도입했음에도 불구하고 복잡한 계약에서 심각한 취약점을 탐지하는 데는 44%밖에 미치지 못합니다 . 계약 간 상태 경로 추론, 경제적 인센티브 모델 분석 또는 특정 시간 조건 충족이 필요한 심층적인 취약점은 AI 기본 스캐닝으로는 여전히 탐지하기 어렵습니다. 이것이 바로 스킬 향상 기능을 도입한 후에도 감사 워크플로에서 완전한 수동 감사 프로세스를 유지하는 근본적인 이유입니다.
2.4 백서 감사 입력 자료로 활용: 코드 구현과 설계 의도 간의 일관성 검증
취약점 시그니처 데이터베이스 외에도, 저희는 감사 프로세스에 중요한 기능을 추가했습니다. 바로 프로젝트 백서 추가 입력 자료로 활용하여 AI가 코드 구현과 백서 디자인 간의 일관성을 검증할 수 있도록 하는 것입니다.
구체적으로, 코드 감사 시작 전에 AI는 프로젝트의 백서 , 기술 사양 및 요구 사항 문서를 체계적으로 분석하여 역할 및 권한 모델, 핵심 업무 프로세스, 신뢰 경계 정의 및 예상되는 행동 제약 조건을 클레임 구조화된 프로젝트 컨텍스트 요약을 생성합니다. 이후 코드 감사 프로세스 전반에 걸쳐 AI는 비교를 위해 이 컨텍스트를 지속적으로 상호 참조합니다. 이 메커니즘은 실제 사용에서 두 가지 중요한 결과를 가져왔습니다.
첫째, 코드에서 리스크 내포하는 것으로 보이는 권한 구조의 경우, 백서 설계 의도와 제약 조건이 명확하게 설명되어 있다면 AI는 그에 따라 판단을 조정하여 오경보를 효과적으로 줄일 수 있습니다.
둘째, 코드 구현과 백서 의 약속 사이에 상당한 불일치가 있는 경우, 예를 들어 문서에 명시된 지연 방지 메커니즘이 코드에 구현되지 않았거나 거버넌스 프로세스의 시간 제약 조건이 제대로 실행되지 않은 경우, AI가 경고를 발생시킵니다. 이러한 코드-문서 불일치는 일상적인 코드 검사 과정에서 쉽게 간과될 수 있지만, 잠재적인 보안 취약점이 될 수 있습니다. 또한, 이는 프로젝트 팀이 실제 배포 후 예상과 다른 동작이 나타나는 상황을 방지하는 데 도움이 됩니다.
III. 삼중 감사 모델: 스마트 계약을 위한 완벽한 보안 보장 구축을 위한 협력적 접근
스마트 계약이 블록체인에 배포되면 취약점으로 인한 결과는 종종 되돌릴 수 없게 됩니다. Beosin은 심층적인 인간 감사 와 형식 검증을 결합하여 계약 감사 수행하며, 잠재적으로 재정적 손실이나 비정상적인 논리 작동으로 이어질 수 있는 문제를 식별하고 보고하는 데 중점을 둡니다. 동시에, 전용 스킬 지식 기반을 활용한 향상된 AI 기준선 검사 기능을 도입하여 고객이 현재는 단순한 결함이지만 아직 실제 피해를 발생시키지는 않은 코드 문제를 발견할 수 있도록 지원합니다. 이를 바탕으로 Beosin은 심층적인 인간 감사, 형식 검증, 향상된 AI 기준선 검사의 3단계 감사 모델을 구축했습니다. 이 세 가지 요소의 계층적 협업을 통해 더욱 포괄적인 보안 시스템을 구현합니다 .
3.1 심층적인 수동 감사 및 형식적 검증: 보안 보장의 핵심 요소
수동 감사 의 핵심 장점은 전체 프로토콜 설계에 대한 심층적인 이해와 공격자 관점에서 잠재적 리스크 사전에 분석할 수 있다는 점입니다 . 숙련된 감사 전문가가 프로젝트의 프로토콜 수준에 대한 포괄적인 감사 수행하며, 여기에는 계약 간 상호 작용 로직 검증, 펀드 보안 공격 표면 분석, 극한 시장 상황에서의 프로토콜 논리 분석, 새로운 공격 방법 식별 및 평가 등이 포함됩니다. 이러한 프로토콜 수준의 공격 및 방어에 대한 이해는 웹3 생태계에서 장기간 축적된 실무 경험에 크게 의존하며, 현재로서는 도구 수준에서 독립적으로 달성하기 어렵습니다.
이러한 기반 위에 Beosin은 자체 툴체인을 활용하여 수동 감사 의 판단을 정량화 가능한 수학적 보증으로 변환합니다. 자금 흐름 및 가격 계산과 같은 가장 리스크 높은 핵심 경로와 같이 감사 전문가가 확인한 핵심 업무 로직의 경우, Beosin은 LLM 기반 정형 명세 생성 기능을 자체 검증 툴체인에 심층적으로 통합하여 "AI 명세 생성 → 정형적 전수 검증 → 반례 기반 정제"의 폐쇄 루프 엔진을 구축합니다. 이 툴체인은 먼저 Beosin이 축적한 감사 코퍼스를 지식 기반으로 사용하여 수동으로 확인된 리스크 경로의 공격 표면을 모델링하고, 초기 후보 정형 불변식 및 보안 속성 명세 세트를 생성하는 데 도움을 줍니다. 그 후, 자동 정형 검증 엔진은 계약의 전체 상태 전이 공간을 철저하게 검증합니다. 검증 엔진이 반례를 발견하면 시스템은 자동으로 두 가지 시나리오를 구분합니다. 반례가 명세 정의와 업무 의미론 간의 차이에서 비롯된 경우, 반례 컨텍스트는 명세 정제를 위해 AI 모듈 로 피드백되어 다음 반복을 진행합니다. 반례가 계약 코드에서 실제로 악용 가능한 경로에 해당하는 경우, 해당 경로는 취약점 증거로 직접 출력되며, 완전한 공격 경로 재현 정보가 함께 제공되어 감사 전문가가 확인하고 시정 조치를 취할 수 있습니다. 두 경로는 함께 작동하여 모든 가능한 입력에 대해 목표 속성이 성립한다는 것이 수학적으로 확인될 때까지 폐쇄 루프 수렴을 유도합니다. 이 폐쇄 루프 메커니즘으로 검증된 핵심 경로는 전체 계약 보안 시스템에서 가장 결정론적인 방어 체계를 구성하며, 공격 표면을 극히 좁은 범위로 압축합니다.
3.2 향상된 AI 기본 점검: 개발자를 위한 지속적인 리스크 경고 서비스
한편, Beosin은 Skill 지식 기반을 활용한 향상된 AI 기준선 검사 서비스를 독립형 서비스로 제공합니다 . 고위험 취약점 발견에 초점을 맞춘 심층적인 인적 감사와 달리, 이 서비스는 개발팀을 위한 코드 상태 보고서와 같은 역할을 합니다. AI 기준선 감사는 계약 코드 전체를 체계적으로 분석하여 현재 직접적인 경제적 손실을 초래하지는 않지만 향후 프로젝트 유지 관리 및 반복 작업 시 개발자의 주의가 필요한 잠재적 문제를 식별합니다. 예를 들어, 오래된 종속 라이브러리 사용, 중요 이벤트 선언 누락, 모범 사례에 부합하지 않는 상태 변수 노출 방식, 최적화가 가능한 Gas 사용 패턴 등이 있습니다. 이러한 문제들은 현재 업무 로직에서는 공격자가 직접 악용하지 않지만, 프로토콜 기능이 확장되거나 코드가 리팩토링되거나 외부 종속성이 업데이트됨에 따라 점차 실제 보안 취약점으로 발전할 수 있습니다. 각기 다른 초점을 가지고 단계적으로 발전하는 이 세 가지 계층은 Web3 프로젝트를 위한 완벽한 보안 보호 시스템을 구축합니다.
