‘감사 완료’ 배지는 무엇을 보증할까
DeFi 서비스 홈페이지에는 ‘○○ 보안업체 감사 완료’라는 배지가 자주 붙어 있습니다. 감사를 받았다는 사실은 분명 긍정적인 신호지만, 그것이 ‘이 서비스에서는 자금을 잃지 않는다’는 보증은 아닙니다. 감사를 받은 서비스에서도 대규모 해킹이 여러 차례 일어났습니다.
이 글은 스마트계약 감사가 실제로 무엇을 확인하는지, 범위와 버전이 왜 중요한지, 감사가 놓칠 수 있는 오류와 코드 밖의 위험은 무엇인지 설명합니다. 사용자가 감사 보고서를 직접 열었을 때 읽어야 할 항목도 순서대로 정리합니다.
감사가 하는 일
스마트계약 감사는 보안 전문가가 특정 시점의 코드를 검토해 알려진 유형의 취약점, 논리 오류, 권한 설정 문제를 찾는 작업입니다. Ethereum.org의 보안 도구 안내는 정적 분석 도구, 퍼징(무작위 입력 시험), 형식 검증 같은 방법을 소개하고, 감사인은 이런 도구와 사람의 검토를 함께 사용합니다.
OWASP의 스마트계약 보안 표준처럼 점검 항목을 체계화한 기준도 있습니다. 하지만 어떤 방법을 쓰든 감사는 ‘찾은 문제’를 보고하는 것이지, ‘문제가 없다’를 증명하는 것이 아닙니다. 보고서에 문제가 적게 나왔다는 것은 감사인이 그 범위 안에서 더 찾지 못했다는 뜻입니다.
감사가 다루는 것과 다루지 않는 것
감사 보고서를 볼 때는 무엇이 범위 안에 있었는지와 범위 밖에 남은 것이 무엇인지를 나눠 보는 것이 출발점입니다.
| 구분 | 보통 감사 범위 안 | 보통 감사 범위 밖 |
|---|---|---|
| 코드 | 보고서에 명시된 계약과 커밋 버전 | 이후 수정·업그레이드된 코드, 범위에서 뺀 계약 |
| 외부 의존 | 오라클 호출 방식의 안전성 | 오라클 데이터 자체의 정확성, 다른 프로토콜의 오류 |
| 운영 | 관리자 함수의 존재와 권한 구조 | 실제 키 관리, 운영진의 판단, 내부자 위험 |
| 경제 설계 | 일부 감사에서 제한적으로 검토 | 시장 급변 시 인센티브 붕괴, 대규모 자금 공격 |
| 사용자 화면 | 대부분 포함되지 않음 | 프런트엔드 변조, 피싱 사이트 |
범위는 감사마다 다릅니다. 보고서 첫머리의 ‘범위(scope)’와 ‘커밋 해시’ 항목을 먼저 확인하세요.
버전과 수정 여부
감사는 특정 커밋(코드의 특정 버전)을 대상으로 합니다. 가상의 예로 3월에 v1 코드를 감사받고, 6월에 새 기능을 넣은 v2를 배포했다면, v2에서 바뀐 부분은 감사를 받지 않은 상태입니다. 배포된 계약의 코드가 감사받은 커밋과 같은지는 블록 탐색기에서 검증된 소스와 보고서의 커밋 해시를 비교해 확인할 수 있습니다.
보고서에 나온 문제가 어떻게 처리됐는지도 중요합니다. 감사인은 보통 문제를 심각도별로 나누고, 개발팀이 ‘수정함’, ‘부분 수정’, ‘위험 수용’으로 답한 내용을 함께 적습니다. 심각한 문제를 ‘위험 수용’으로 남겼다면 그 이유를 확인해야 합니다.
코드 밖의 위험
많은 사고는 코드의 단순한 실수가 아니라 코드 밖에서 시작됩니다. 관리자 키가 유출되거나, 외부 가격 정보가 조작되거나, 연결된 다른 프로토콜이 무너지면 감사받은 코드도 피해를 입을 수 있습니다. Ethereum.org의 보안 문서도 접근 제어와 외부 의존을 주요 위험으로 다룹니다.
경제적 설계의 문제도 있습니다. 코드는 의도대로 작동하는데, 시장이 급변하거나 누군가 대규모 자금을 빌려 순간적으로 가격을 움직이면 설계가 예상하지 못한 방식으로 손실이 생길 수 있습니다. 이런 위험은 코드 리뷰만으로 찾기 어렵습니다.
자주 하는 오해
‘유명 업체가 감사했으니 안전하다’는 판단은 감사의 범위와 시점을 건너뜁니다. 같은 업체라도 감사 기간, 투입 인원, 범위에 따라 결과의 깊이가 다릅니다.
‘감사를 여러 번 받았으니 더 안전하다’도 조건부로만 맞습니다. 여러 감사가 같은 버전을 서로 다른 시각으로 봤다면 도움이 되지만, 각각 다른 버전의 일부만 봤다면 현재 배포된 코드 전체를 본 감사는 하나도 없을 수 있습니다.
사용자가 감사 보고서에서 읽을 항목
감사 보고서는 기술 문서지만, 아래 항목은 개발자가 아니어도 확인할 수 있습니다.
- 보고서 날짜와 감사 대상 계약 목록, 커밋 해시를 확인합니다.
- 배포된 계약 주소의 검증된 소스가 감사받은 커밋과 같은 버전인지 블록 탐색기에서 대조합니다.
- 심각도 ‘높음’ 이상 문제의 개수와 각각의 처리 상태(수정·부분 수정·위험 수용)를 봅니다.
- 보고서가 범위 밖으로 명시한 항목(오라클, 관리자 키, 경제 설계 등)을 적어두고 따로 확인합니다.
- 감사 이후 업그레이드가 있었는지, 그 변경에 대한 추가 감사가 있는지 확인합니다.
감사 이후에도 남는 것
감사는 위험을 줄이는 과정의 일부일 뿐, 위험을 없애지 않습니다. 버그 바운티 프로그램, 단계적 배포, 예치 한도, 긴급 정지 장치 같은 추가 안전장치가 함께 있는지도 서비스의 보안 수준을 가늠하는 단서입니다.
이 글의 버전 사례는 가상의 예시입니다. 실제 서비스를 쓸 때는 최신 감사 보고서와 공식 문서를 기준 시점과 함께 확인하고, 감사 여부와 관계없이 잃어도 감당할 수 있는 범위에서 사용하는 것이 현실적입니다.