감사는 보증서가 아니다
스마트계약 감사는 독립된 검토자가 정해진 범위의 코드에서 결함과 설계 위험을 찾는 과정입니다. 출시 전 품질을 높이는 중요한 절차지만 모든 버그가 없다는 보증이나 향후 손실 보상 약속은 아닙니다. Ethereum.org의 보안 안내도 감사를 만능 해결책으로 취급하지 말라고 설명합니다.
범위와 버전 확인
보고서 첫 장에서 감사 대상 저장소, 커밋 해시, 계약 주소, 검토 날짜, 제외 범위를 확인하세요. 웹사이트가 감사받았다고 표시해도 현재 배포된 코드가 당시 버전과 다를 수 있습니다. 오라클·브리지·관리자 스크립트·프런트엔드가 범위 밖이었다면 전체 서비스가 감사된 것은 아닙니다.
발견되지 않은 오류
감사는 제한된 시간과 가정 아래 사람이 도구와 테스트를 사용해 수행합니다. 정적 분석, 퍼징, 수동 검토, 형식 검증은 서로 다른 오류를 찾지만 어느 한 방법도 모든 실행 경로와 경제적 공격을 완전히 다루지 못합니다. ‘중대한 발견 없음’은 ‘위험 없음’과 같은 문장이 아닙니다.
코드 밖의 위험
코드가 의도대로 작동해도 관리자 키 탈취, 잘못된 가격 데이터, 토큰 디페깅, 거버넌스 장악, 유동성 부족으로 손실이 생길 수 있습니다. 여러 계약을 결합한 서비스에서는 개별 계약의 안전성과 전체 시스템의 안전성이 다릅니다. 운영과 시장 위험을 별도 목록으로 관리해야 합니다.
수정과 재검토
보고서에서 발견된 항목이 수정됐는지, 수정 버전이 재검토됐는지 확인합니다. ‘확인됨’, ‘완화됨’, ‘수용됨’은 같은 상태가 아니며 프로젝트가 위험을 받아들이고 남겨둘 수도 있습니다. 감사 뒤 업그레이드가 있었다면 변경 부분에 대한 추가 검토와 온체인 배포 기록을 찾아야 합니다.
사용자가 읽을 항목
사용자는 감사 회사의 이름보다 범위, 버전, 중대한 발견, 미해결 항목, 관리자 권한, 버그바운티와 실시간 모니터링 여부를 확인하는 편이 낫습니다. 소액으로 입출금을 시험하고 한 프로토콜에 감당하기 어려운 금액을 집중하지 마세요. 감사는 위험 관리의 한 층이지 최종 결론이 아닙니다.