감사 (Audit)

감사(audit)는 조직의 기록이나 시스템을 공식적으로 검사해, 그것이 실제로 이루어진 거래와 상태를 공정하고 정확하게 반영하는지 확인하는 절차입니다. 전통적으로는 회계 기록을 검사하는 회계 감사를 뜻하며 일반적으로 독립적인 기관이 수행하고, 조직의 직원이 직접 수행하면 내부 감사라고 합니다. 암호화폐 분야에서 감사는 주로 스마트 컨트랙트의 소스 코드를 검토해 오류와 문서화되지 않은 기능을 찾는 스마트 컨트랙트 감사를 가리키며, 결과에 따라 위험을 줄이고 제거하기 위한 권장 사항이 담긴 보고서가 작성됩니다.

감사의 유형

• 외부(재무) 감사: 독립된 회계 법인이 재무 기록을 검토해 의견을 냅니다. 이해 상충을 피하기 위해 외부 기관이 맡습니다.
• 내부 감사: 조직 내 직원이 내부 통제, 위험 관리, 운영 효율성을 점검합니다.
• 스마트 컨트랙트 감사: 보안 전문 업체가 컨트랙트 코드의 보안 결함과 취약점을 찾습니다.
• 준비금 증명(proof of reserves): 거래소나 수탁 업체가 고객 자산을 실제로 보유하고 있는지 확인합니다.

스마트 컨트랙트 감사

스마트 컨트랙트는 정해진 조건에 따라 트랜잭션을 자동으로 실행하는 코드입니다. 배포된 뒤에는 고치기 어렵고 큰 자산을 직접 다루는 경우가 많아, 출시 전에 외부 감사를 받는 것이 일반적입니다. 감사는 보통 다음 순서로 진행됩니다.

1. 범위 확정: 감사할 컨트랙트와 코드 버전(커밋)을 정합니다.
2. 자동 분석: 정적 분석 도구와 퍼징(무작위 입력 테스트)으로 알려진 유형의 결함을 찾습니다.
3. 수동 검토: 재진입, 권한 관리, 산술 오류, 가격 오라클 조작 같은 취약점과 비즈니스 로직의 허점을 전문가가 직접 검토합니다. 공개되지 않았거나 의도하지 않은 숨은 기능도 찾습니다.
4. 보고서: 발견 사항을 심각도별로 정리하고 권장 조치를 적습니다.
5. 수정 확인: 개발팀이 고친 코드를 다시 검토하고 최종 보고서를 공개합니다.

감사는 특정 시점, 특정 코드 버전에 대한 검토일 뿐 안전을 보증하지 않습니다. 감사를 받은 프로토콜에서도 해킹이 일어났으며, 감사 후 코드가 바뀌었거나 범위 밖의 컨트랙트에서 문제가 생기는 경우가 많습니다. 감사 보고서를 볼 때는 감사한 코드 버전과 실제 배포된 컨트랙트가 같은지, 높은 심각도의 문제가 해결되었는지 확인해야 합니다.

준비금 증명

거래소의 준비금 증명은 보통 두 부분으로 이루어집니다. 고객 잔고(부채)를 머클 트리로 묶어 각 고객이 자기 잔고가 포함되었는지 확인할 수 있게 하고, 거래소가 그 이상의 자산을 보유한 주소를 서명 등으로 증명합니다. 다만 특정 시점의 스냅숏이고 부채가 빠짐없이 포함되었는지는 외부에서 확인하기 어려워, 회계 감사를 대신하지는 못합니다.

감사의 장점과 한계

• 투명성과 신뢰: 객관적인 평가로 투자자와 이해 관계자의 신뢰를 높입니다.
• 위험 완화: 취약점을 미리 찾아 보안 조치를 마련하게 합니다.
• 규정 준수: 규정과 산업 표준을 지키는지 확인합니다.
• 비용과 시간: 크고 복잡한 시스템일수록 비용이 많이 들고 일정이 늦어질 수 있습니다.
• 제한된 범위: 감사 시점의 상태만 보여 주므로 나중에 생기는 취약점은 포착하지 못합니다.