스마트 컨트랙트 감사 보고서를 평가하는 방법

스마트 컨트랙트 감사 보고서를 평가하려면 보고서가 진짜이며 감사 기관이 직접 공개한 것인지 확인하고, 범위가 실제 배포된 컨트랙트를 포함하는지 점검하고, 치명적·높음 심각도의 발견 사항과 각각의 수정 여부를 읽고, 감사가 명시적으로 다루지 않은 부분을 기록하세요. 감사는 특정 코드의 스냅샷일 뿐, 프로젝트가 안전하거나 정직하다는 보증이 아닙니다.

프로젝트들은 흔히 ‘감사 완료’를 신뢰의 배지처럼 홍보합니다. 철저하고 의미 있는 감사도 있지만, 범위가 좁거나 오래되었거나 가짜인 감사도 있습니다. 보고서 읽는 법을 알면 약 15분 만에 그 차이를 구분할 수 있습니다.

스마트 컨트랙트 감사란

스마트 컨트랙트 감사는 전문가들이 프로젝트의 코드를 읽고 테스트하며 재진입(reentrancy), 접근 제어 실수, 계산 오류, 논리 결함 같은 취약점을 찾는 보안 검토입니다. 이후 발견한 내용, 각 문제의 심각도, 팀의 대응을 정리한 보고서를 공개합니다. 관련 글: 스마트 컨트랙트 익스플로잇.

스마트 컨트랙트는 배포 후 변경하기 어렵고 큰 금액을 보관하는 경우가 많기 때문에 감사는 가치가 있습니다. 하지만 감사 기관은 제한된 시간 안에 작업하고, 제공받은 것만 검토하며, 미묘한 문제를 놓칠 수 있습니다. 공격당한 프로토콜 중 상당수가 감사를 받은 상태였습니다.

일반적인 감사 보고서의 구성

단계별 가이드: 보고서 평가 방법

1. 보고서가 진짜인지 확인하기

가짜 감사는 잘 알려진 사기 수법입니다. 직접 찾아 들어간 감사 기관의 공식 웹사이트나 GitHub에서 보고서를 확인하세요. 감사 기관이 해당 프로젝트를 모르거나 보고서가 프로젝트 사이트의 PDF로만 존재한다면 검증되지 않은 것으로 취급하세요. 흔한 수법은 가짜 감사 가이드에 정리되어 있습니다.

2. 범위를 배포된 것과 대조하기

보고서에는 코드 커밋이나 컨트랙트 주소가 명시되어야 합니다. 블록 탐색기에서 배포된 컨트랙트가 일치하는지 확인하세요. 흔한 공백:

• 감사는 이전 버전을 대상으로 했고, 이후 코드가 변경되었다.
• 토큰 컨트랙트만 감사했고, 사용자 자금을 보관하는 스테이킹, 볼트, 브리지 컨트랙트는 감사하지 않았다.
• 컨트랙트가 업그레이드 가능해서 나중에 코드가 교체될 수 있다.

3. 심각한 발견 사항부터 읽기

치명적·높음 등급의 문제로 바로 가세요. 각각에 대해 다음을 물어보세요.

• 해결됨으로 표시되어 있고, 감사 기관이 수정을 검증했는가?
• 수정 대신 ‘인지함’으로 처리되었다면, 팀은 어떤 근거를 제시하는가?
• 토큰 발행, 전송 일시 중지, 자금 인출 같은 관리자 권한과 관련이 있는가?

인지 처리된 중앙화 문제는 투자자에게 코드 버그보다 더 중요한 경우가 많습니다. 토큰을 무제한 발행할 수 있는 소유자는 코드가 완벽하게 작동하더라도 위험 요소입니다.

4. 날짜 확인하기

감사가 언제 수행되었는지 기록하고 배포일 및 이후 업그레이드와 비교하세요. 자주 업그레이드되는 프로토콜의 오래된 감사는 현재 코드에 대해 거의 알려 주지 않습니다.

5. 감사 기관 평가하기

공개된 실적, 상세하게 공개된 보고서, 이름이 밝혀진 보안 연구원을 갖춘 감사 기관을 찾으세요. 한 달에 수백 개의 토큰을 감사하는 업체가 낸, 세부 내용 없는 한 페이지짜리 보고서는 신뢰도가 떨어집니다.

6. 면책 조항과 한계 읽기

면책 조항에는 보통 감사가 경제 설계, 오프체인 구성 요소, 오라클, 프런트엔드 코드, 향후 변경 사항을 다루지 않는다고 적혀 있습니다. 바로 이런 영역에서 실제 손실이 많이 발생합니다.

심각도 등급 이해하기

회사마다 정의는 다르지만, 대부분의 감사 기관은 비슷한 척도를 사용합니다.

발견 사항이 많은 보고서가 반드시 나쁜 소식은 아닙니다. 감사 기관이 철저했고 팀이 출시 전에 문제를 수정했다는 뜻일 수 있습니다. 중요한 것은 미해결로 남은 부분의 심각도와 팀의 대응 방식입니다. 모든 발견 사항에 이의를 제기하거나 심각한 문제를 조용히 무시하는 팀은 자신들의 보안 문화에 대해 무언가를 드러냅니다.

감사 보고서의 위험 신호

• 범위 세부 정보, 커밋 해시, 컨트랙트 주소가 없다.
• 치명적 문제가 수정 없이 ‘인지함’으로 표시되어 있다.
• 프로젝트가 소유자 권한에 관한 발견 사항을 축소한다.
• 보고서가 프로젝트 측에만 게시되어 있다.
• ‘100% 안전’이나 ‘감사로 완벽하게 보호됨’ 같은 마케팅 문구.
• 주요 코드 변경보다 훨씬 이전 날짜의 감사.

감사로는 알 수 없는 것

훌륭한 감사라도 다음 질문에는 답하지 않습니다.

• 팀이 실재하고 신뢰할 만한지: 암호화폐 팀이 진짜인지 확인하는 방법을 참고하세요.
• 유동성이 잠겨 있는지, 빼낼 수 있는지.
• 토큰의 공급량과 언락이 공정한지.
• 프로토콜의 경제 설계가 스트레스 상황에서 무너질 수 있는지.

감사를 공개 버그 바운티 프로그램, 여러 차례의 독립 감사, 사고 없는 운영 기간, 투명한 관리자 권한 같은 다른 점검과 함께 활용하세요.

결론

감사 보고서는 진짜이고, 최신이며, 실제로 사용하는 컨트랙트를 다룰 때에만 유용한 증거가 됩니다. 출처를 검증하고, 범위를 대조하고, 심각한 발견 사항과 해결 방식을 읽고, 무엇이 빠졌는지 주의 깊게 살피세요. 감사는 조사의 한 요소로 활용하되, 프로젝트가 안전하다는 증거로 삼지는 마세요.