NFT 마켓플레이스 개발팀이 AI 감사 도구를 CI 파이프라인에 넣을 때는 세 가지를 먼저 정해야 합니다. 어느 단계에서 어떤 검사를 실행할지, 경고를 어떤 기준으로 차단·보류·기록으로 나눌지, 외부 수동 감사로 넘길 범위를 어디까지로 할지입니다. AI 기반 스마트컨트랙트 감사는 반복적으로 나오는 취약 패턴을 빠르게 걸러 내는 데 강점이 있습니다. 그러나 주문 서명, 로열티 정산, 경매 종료 같은 비즈니스 로직의 정합성은 사람이 검토해야 하므로, 자동 검사는 배포 전 최종 판정이 아니라 상시 1차 필터로 설계하는 것이 바람직합니다.
AI 감사 도구를 CI에 넣으면 무엇을 잡고 무엇을 놓칩니까?
AI 기반 스마트컨트랙트 감사 도구는 대체로 정적 분석 결과에 언어 모델의 해석을 덧붙이거나, 코드 문맥을 읽어 취약 가능성이 있는 구간을 설명하는 방식으로 작동합니다. 커밋 단위로 반복 실행할 수 있고 사람이 놓치기 쉬운 반복 패턴을 빠짐없이 짚어 준다는 점에서 CI와 잘 맞습니다.
NFT 마켓플레이스에서 자동 검사가 비교적 잘 잡아내는 항목은 다음과 같습니다.
- ERC-721·ERC-1155 수신 콜백(onERC721Received 등)을 통한 재진입 가능 구간
- 접근 제어 수정자가 빠진 관리자 함수, 초기화 함수의 중복 호출 가능성
- 외부 호출 반환값 미확인, 정수 연산 경계값, 사용되지 않는 상태 변수
- 서명 검증 시 nonce·만료 시각·체인 식별자를 확인하지 않는 패턴
반대로 자동 검사가 놓치기 쉬운 영역도 분명합니다. 주문 취소와 체결이 같은 블록에서 경합할 때의 처리 순서, 로열티와 플랫폼 수수료를 차감하는 순서에 따른 정산 오차, 컬렉션별 예외 정책이 겹칠 때의 권한 충돌은 코드만 보아서는 맞고 틀림을 판단하기 어렵습니다. 설계 의도와 비교해야 판단할 수 있기 때문입니다.
약점을 분류할 때는 공통 용어를 쓰는 것이 좋습니다. MITRE가 관리하는 CWE(Common Weakness Enumeration)는 소프트웨어와 하드웨어의 약점 유형을 식별 번호로 정리한 공개 목록입니다. AI 도구의 경고를 CWE 유형에 대응시켜 두면 도구를 바꾸더라도 이슈 이력을 일관되게 관리할 수 있습니다.
어느 단계에서 어떤 검사를 돌려야 합니까?
모든 검사를 커밋마다 실행하면 파이프라인이 느려지고 경고 피로가 쌓입니다. 실행 비용과 신뢰도에 따라 단계를 나누는 것이 실무적입니다. 아래 표는 NFT 마켓플레이스 저장소를 기준으로 정리한 배치 예시입니다.
| CI 단계 | 실행 검사 | 판정 방식 | 담당 |
|---|---|---|---|
| 풀 리퀘스트 생성 | 정적 분석, AI 요약 리뷰(변경 파일 한정) | 고위험 경고만 병합 차단, 나머지는 코멘트 | 작성자·리뷰어 |
| 메인 브랜치 병합 후 | 단위·불변식 테스트, 퍼징(짧은 실행) | 불변식 위반 시 즉시 이슈 생성 | 컨트랙트 개발 리드 |
| 야간 배치 | 전체 저장소 AI 감사, 장시간 퍼징 | 신규 경고만 집계해 다음 날 분류 | 보안 담당자 |
| 릴리스 후보 태그 | 전체 재검사, 배포 스크립트·업그레이드 저장 레이아웃 비교 | 미해결 고위험 0건이어야 진행 | 보안 담당자·외부 감사인 |
단계 설계의 근거로는 공공 프레임워크를 참고할 수 있습니다. 미국 국립표준기술연구소(NIST)의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)는 릴리스 취약점을 최소화한 안전한 소프트웨어 생산(PW)을 실무 그룹의 하나로 제시합니다. CI에 넣는 자동 검사는 이 영역에 해당하므로, 야간 배치와 이슈 관리 절차를 함께 문서화해 두면 내부 감사 시 설명이 수월해집니다.
AI가 낸 경고는 어떤 기준으로 차단·보류·기록으로 나눕니까?
AI 도구는 같은 코드에 대해서도 실행마다 설명이 달라질 수 있습니다. 따라서 경고 문장 자체가 아니라 위치와 유형을 기준으로 판정해야 합니다. 권장하는 분류 기준은 다음과 같습니다.
- 차단: 자산 이동 함수(체결, 정산, 출금)나 권한 변경 함수에서 나온 재진입·접근 제어·서명 재사용 경고. 재현 테스트를 작성해 반증하기 전까지 병합하지 않습니다.
- 보류: 조회 함수나 이벤트 처리 구간의 경고, 가스 최적화와 결합된 경고. 담당자 지정 후 다음 릴리스 전까지 결론을 기록합니다.
- 기록: 코딩 스타일, 주석 누락, 이미 반증된 유형의 반복 경고. 억제 목록에 사유와 함께 등록합니다.
억제 목록은 반드시 코드 리뷰를 거쳐 수정하도록 하고, 분기마다 전체를 다시 검토해야 합니다. 억제가 누적되면 실제 취약점이 같은 유형으로 묻히는 일이 생기기 때문입니다.
AI 도구 자체의 신뢰도도 관리 대상입니다. NIST의 AI 위험관리 프레임워크(AI RMF)는 AI 위험 관리를 거버넌스(Govern), 맥락 파악(Map), 측정(Measure), 관리(Manage)의 네 기능으로 구성합니다. 이 구조에 따라 도구의 오탐·미탐 비율을 내부 테스트 세트로 주기적으로 측정하고, 모델 버전이 바뀔 때 결과를 비교해 두는 절차를 마련하는 것이 좋습니다. 이미 알려진 취약 코드를 넣은 회귀 테스트 저장소를 별도로 두면 도구 업데이트 이후 탐지 성능이 떨어졌는지 바로 확인할 수 있습니다.
외부 수동 감사와는 어떻게 역할을 나눠야 합니까?
자동 검사가 정착하면 외부 스마트컨트랙트 감사의 범위를 좁히고 깊이를 늘릴 수 있습니다. 감사 업체에 AI 도구의 결과와 억제 목록, 반증 테스트를 함께 전달하면 감사인은 이미 걸러진 패턴 대신 설계 위험에 시간을 쓸 수 있습니다. 외부 스마트컨트랙트 감사를 받기 전에 준비할 자료는 다음과 같습니다.
- 주문 생성부터 체결·취소·정산까지의 상태 전이도와 각 단계의 불변식 목록
- 권한 보유 주체(관리자, 멀티시그, 타임락)와 함수별 권한 매핑표
- AI 감사 결과 중 차단·보류 항목과 처리 결론, 재현 테스트 코드
- 업그레이드 구조를 쓰는 경우 저장 레이아웃 변경 이력
책임 소재도 명확히 해야 합니다. 미국 사이버보안·인프라보안청(CISA)은 보안 중심 설계(Secure by Design) 원칙에서 기술 제공자가 경영진 차원에서 제품 보안에 대한 책임을 져야 한다고 강조합니다. 외부 감사 보고서가 있다는 사실만으로 운영 책임이 옮겨 가는 것은 아니므로, 감사 이후의 수정 검증과 배포 후 모니터링 담당자를 내부에 지정해 두어야 합니다.
국내 이용자를 대상으로 서비스한다면 규제 환경도 함께 살펴야 합니다. 금융위원회 소관의 「가상자산 이용자 보호 등에 관한 법률」은 가상자산사업자가 이용자 자산 보호를 위해 지켜야 할 제도적 장치를 담고 있습니다. NFT가 이 법상 가상자산에 해당하는지는 발행 형태와 실제 이용 방식에 따라 달라질 수 있으므로, 일반적인 판단에 기대기보다 법률 전문가의 검토를 받는 것이 안전합니다.
자주 묻는 질문
AI 감사 도구만으로 외부 감사를 대신할 수 있습니까?
현재로서는 대신하기 어렵습니다. 자동 검사는 알려진 패턴을 넓게 걸러 내는 데 유용하지만, 정산 순서나 주문 경합처럼 설계 의도와 비교해야 하는 위험은 사람이 검토해야 합니다. 자산 규모가 크거나 업그레이드 권한이 있는 컨트랙트라면 외부 감사를 병행하는 것이 일반적입니다.
풀 리퀘스트마다 전체 저장소를 검사해야 하나요?
반드시 그럴 필요는 없습니다. 풀 리퀘스트 단계에서는 변경 파일과 그 파일을 호출하는 함수로 범위를 한정하고, 전체 검사는 야간 배치와 릴리스 후보 단계에서 실행하는 편이 속도와 정확도의 균형이 좋습니다. 다만 상속 구조나 공용 라이브러리가 바뀐 경우에는 전체 검사를 즉시 실행하도록 규칙을 두는 것이 좋습니다.
오탐이 많아 개발자들이 경고를 무시하기 시작하면 어떻게 해야 하나요?
병합 차단 기준을 자산 이동·권한 변경 함수로 좁히고, 반복 오탐은 사유와 함께 억제 목록에 등록해 노출 빈도를 줄입니다. 동시에 분기별로 억제 목록과 도구의 탐지 성능을 재검토해 실제 취약점이 묻히지 않도록 관리합니다. 경고 수보다 차단 경고의 처리 기간을 지표로 삼으면 팀의 대응 품질을 더 정확히 볼 수 있습니다.