Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

스마트 컨트랙트 감사는 정해진 범위 안에서 코드와 아키텍처를 독립적으로 검토하는 절차입니다. 취약점, 구현 오류 및 의도한 동작과 실제 동작 사이의 불일치를 찾는 것이 목적입니다.

감사는 불확실성을 줄일 수 있지만 컨트랙트의 위험을 없애 주지는 않습니다. Ethereum 공식 보안 지침은 감사를 모든 버그를 잡는 만능 해결책이 아니라 추가 검토 절차로 설명합니다.

이 글은 교육 목적으로만 제공됩니다. 감사는 보안, 자금 복구 또는 수익을 보장하지 않습니다.

범위를 먼저 확인하세요

유용한 보고서는 검토 대상을 정확히 명시합니다:

저장소 및 커밋 해시;
파일 및 컨트랙트;
컴파일러 버전 및 빌드 설정;
의존성;
아키텍처 및 특권 역할;
브랜치 또는 릴리스;
제외 사항, 제한 사항 및 가정;
검토 날짜.

실제 감사라도 이전 버전, 다른 배포 또는 더 큰 시스템의 일부만 다룰 수 있기 때문에 이 확인이 중요합니다.

감사 기관이 일반적으로 검토하는 사항

1. 의도된 동작과 불변 조건

감사자는 코드와 명세를 비교합니다:

각 함수를 호출할 수 있는 주체;
금액과 수수료 계산 방식;
상태 변경이 발생하는 시점;
항상 참으로 유지되어야 하는 속성;
예외 상황과 실패 처리 방식.

명세에서 중요한 요구 사항이 누락되면 기술적으로 올바른 코드도 안전하지 않거나 원하지 않는 설계를 구현할 수 있습니다.

2. 접근 제어

검토자는 소유자, 관리자, 운영자 및 기타 특권 역할과 다음 권한을 확인합니다:

권한 부여 또는 취소;
시스템 일시 중지;
수수료 및 한도 변경;
토큰 발행;
자산 출금;
구현 업그레이드.

또한 하나의 키로 중대한 변경을 수행할 수 있는지, 다중 서명이나 타임록 같은 통제 수단이 설계에 포함되어 있는지도 검토합니다.

3. 외부 호출과 재진입

컨트랙트는 실행 중 다른 컨트랙트에 제어권을 넘길 수 있습니다. 이때 원래 상태 전환이 끝나기 전에 외부 컨트랙트가 다시 호출하는 재진입이 발생할 수 있습니다. Solidity 공식 지침은 필요한 경우 검사, 상태 변경, 외부 상호작용의 순서를 신중하게 구성할 것을 권장합니다.

4. 계산과 단위

감사자는 다음을 찾습니다:

반올림 및 정밀도 손실;
일치하지 않는 토큰 소수점 자릿수;
잘못된 작업 순서;
경곗값;
0으로 나누기;
unsafe unchecked arithmetic;
내부 단위와 표시 단위 간 차이.

5. 서비스 거부와 가스

끝이 없는 반복문, 계속 커지는 배열, 실패한 외부 호출 또는 비용이 큰 작업은 함수 실행을 비현실적으로 만들 수 있습니다. 검토자는 데이터가 증가하거나 비정상 입력이 들어와도 설계를 계속 사용할 수 있는지 테스트합니다.

6. 프록시와 업그레이드

업그레이드 가능한 시스템의 검토 범위에는 다음이 포함되어야 합니다:

프록시 및 구현 컨트랙트;
upgrader 또는 admin 권한;
초기화;
스토리지 레이아웃 호환성;
무단 업그레이드 경로;
감사 후 로직 변경의 영향.

프록시는 사용자에게 보이는 주소를 그대로 유지하면서 새로운 로직에 처리를 위임할 수 있습니다. 따라서 "컨트랙트는 변경될 수 없다"는 주장은 실제 아키텍처를 기준으로 확인해야 합니다.

7. 연동

컨트랙트는 토큰, 가격 오라클, 브리지, DEX, 서명 또는 다른 컨트랙트에 의존할 수 있습니다. 감사자는 이러한 의존성에 대한 가정, 오래된 데이터, 비정상적인 토큰 동작 및 외부 장애 유형을 검토합니다.

8. 이벤트와 모니터링

검토자는 이벤트가 역할 변경, 업그레이드, 일시 중지 및 전송 같은 주요 작업을 정확히 공개하는지 확인할 수 있습니다. 이벤트는 모니터링을 돕지만 상태 검사를 대신하지는 않습니다.

감사에 사용되는 방법

일반적인 검토에는 다음 항목이 함께 포함됩니다:

수동 코드 및 아키텍처 분석;
단위 및 통합 테스트;
정적 및 동적 분석;
생성된 입력값을 이용한 퍼징;
속성 기반 테스트;
알려진 취약점 유형 검사;
빌드 및 배포 검토;
경우에 따라 선택한 속성에 대한 정형 검증.

하나의 방법으로 모든 것을 확인할 수는 없습니다. 형식 검증은 코드가 형식 명세를 충족한다는 사실을 증명할 수 있지만 명세에 표현되지 않은 속성까지 증명하지는 못합니다.

사용자가 감사 보고서를 읽는 방법

1. 검토된 버전과 일치하는지 확인

커밋 해시를 찾아 다음을 확인하세요:

현재 구현이 해당 코드로 빌드되었는지;
보고서 날짜 이후 업그레이드가 있었는지;
체인과 배포 주소가 일치하는지;
핵심 의존성이 검토 범위에 포함되었는지.

이를 입증할 수 없다면 보고서는 실제 배포에 관한 제한적인 증거만 제공합니다.

2. 요약뿐 아니라 발견 사항도 읽기

각 발견 사항에서 다음을 검토하세요:

심각도 및 시나리오;
영향을 받는 코드;
권고 사항;
개발자 대응;
현재 상태;
감사 기관이 수정 사항을 다시 테스트했는지.

Fixed or Resolved is meaningful only when tied to a specific corrected version.

3. 제한 사항 읽기

보고서에서 제외될 수 있는 항목:

프런트엔드 및 백엔드 시스템;
키 관리;
경제 구조;
제3자 컨트랙트;
배포 인프라;
운영 환경 설정;
법률 및 운영 문제.

사용자는 Solidity 파일뿐 아니라 전체 시스템과 상호작용합니다.

4. 관리 권한 위험 검토

확인할 질문:

업그레이드를 통제하는 주체;
작업을 일시 중지할 수 있는지;
수수료 또는 연결 주소를 변경할 수 있는지;
타임록이 존재하는지;
다중 서명이 사용되는지;
사용자에게 변경 사항을 알리는 방식.

코드에서 취약점이 발견되지 않았더라도 이는 거버넌스와 신뢰에 관한 질문입니다.

5. 감사 이후의 보안도 확인

지속적으로 확인할 유용한 지표는 다음과 같습니다:

모든 릴리스 테스트;
중대한 업그레이드 검토;
버그 바운티 프로그램;
역할 및 구현 모니터링;
사고 대응 절차;
위험에 노출되는 자산 규모 제한.

What an audit does not guarantee

감사가 다음을 보장하지는 않습니다:

모든 버그의 부재;
검토 후 변경된 코드의 안전성;
웹사이트, 지갑, DNS 또는 서버의 안전성;
특권 키의 보안;
외부 토큰, 오라클 및 브리지의 정확성;
모든 경제적 공격에 대한 저항성;
팀의 신뢰성;
법률 준수;
토큰 유동성;
자금 반환;
고정 수익 또는 기타 수익.

신중한 사용자가 확인할 질문

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

보고서 체크리스트

감사 기관에서 보고서를 확인할 수 있습니다.
저장소와 커밋 해시가 명시되어 있습니다.
핵심 컨트랙트와 의존성이 감사 범위에 포함됩니다.
검토된 버전이 현재 운영 중인 배포 버전과 일치합니다.
프록시, 구현 및 관리자 권한이 범위에 포함됩니다.
발견 사항의 상태와 재검사 내용이 문서화되어 있습니다.
가정과 제외 사항을 읽었습니다.
코드 외부의 위험은 별도로 평가했습니다.

출처 및 추가 자료

Ethereum.org — 스마트 컨트랙트 보안
Ethereum.org — 스마트 컨트랙트 테스트
Ethereum.org — 스마트 컨트랙트의 형식 검증
Solidity Documentation — 보안 고려 사항
OpenZeppelin Docs — 프록시 업그레이드 패턴