"감사를 받으면 안전한 것이지요?"
이 질문에 정확히 답하면 이렇습니다.
감사를 받으면 보고서가 생깁니다.
안전해지는 것은 그 보고서의 지적 사항이 코드와 운영에 반영되고, 반영된 뒤에 다시 확인됐을 때입니다.
보고서와 안전 사이에는 간격이 있고, 그 간격은 감사기관이 아니라 프로젝트가 메웁니다.
감사는 검사이지 보증이 아닙니다
감사 보고서는 특정 시점의 특정 코드를 특정 범위에서 검토한 결과입니다.
그 범위 밖의 코드, 그 뒤에 바뀐 코드, 코드가 아닌 운영의 문제는 보고서에 없습니다.
그래서 감사 보고서가 있다는 것과 컨트랙트가 안전하다는 것은 다른 말입니다.
거래소와 파트너가 감사 보고서를 요구하는 이유도 보증을 원해서가 아닙니다. 프로젝트가 검토 과정을 거쳤는지, 지적된 것을 고쳤는지를 보려는 것입니다.
"감사 통과"라는 표현도 정확하지 않습니다. 감사는 시험이 아니라 검토라서 통과와 탈락이 없습니다.
지적 사항이 나오고, 그것을 어떻게 처리했는지가 남습니다.
확인 1 · 감사 범위에는 자산이 움직이는 경로가 전부 들어가야 합니다
감사 범위를 정하는 것은 프로젝트입니다.
토큰 컨트랙트만인지, 락업과 예치까지인지, 관리자 권한 구조까지인지.
범위를 좁게 잡으면 빠르고 싸지만, 빠진 부분은 검토되지 않습니다. 넓게 잡으면 시간이 걸리지만 놓치는 것이 줄어듭니다.
어느 쪽이 맞는지는 무엇이 자산과 직접 연결돼 있는지에서 나옵니다. 자산이 움직이는 경로는 전부 범위에 들어가야 합니다.
가장 흔한 실수는 토큰 컨트랙트만 감사받고 락업 컨트랙트는 빼는 것입니다. 물량이 실제로 묶여 있는 곳은 후자인데, 검토는 전자만 됐습니다.
범위와 함께 정할 것이 하나 더 있습니다. 감사기관에 무엇을 설명할 것인가입니다.
컨트랙트가 무엇을 해야 하는지 모르면 감사기관은 코드가 의도대로 동작하는지를 판단할 수 없습니다.
확인 2 · 코드가 정해졌는가
감사는 특정 시점의 코드를 봅니다. 감사 중에 코드가 바뀌면 보고서는 바뀌기 전 코드에 대한 것이 됩니다.
그래서 감사 의뢰는 코드가 정해진 뒤에 해야 합니다.
요구사항이 아직 바뀌고 있다면 감사는 이릅니다. 감사 뒤에 기능을 추가하면 추가된 부분은 다시 검토받아야 합니다.
배포 전에 되돌릴 수 없는 항목의 답이 정해져 있는지가 코드 결정의 기준입니다.
코드가 정해지기 전에 감사를 받는 것은 감사를 두 번 받는 것입니다.
확인 3 · 지적 사항을 고칠 사람이 정해져 있는가
감사 보고서에는 지적 사항이 나옵니다. 심각도별로 나뉘고, 각각에 대해 고칠지 받아들일지 판단해야 합니다.
이 판단과 수정을 누가 하는지가 의뢰 전에 정해져 있어야 합니다.
개발사가 고치는지, 자체 인력이 고치는지, 개발사 계약에 감사 대응이 들어 있는지.
이것이 정해져 있지 않으면 보고서는 나왔는데 고칠 사람이 없는 상태가 됩니다.
FD가 자주 보는 것이 이 상태입니다. 보고서는 있고, 지적 사항도 있고, 그중 무엇이 고쳐졌는지는 아무도 모릅니다.
개발사 계약은 감사 전에 끝났고, 보고서는 파일로만 남아 있습니다.
확인 4 · 반영 뒤에 다시 확인할 것인가
지적 사항을 고친 뒤에는 고친 것이 맞는지 다시 확인해야 합니다.
대부분의 감사기관은 재검토를 제공하지만, 그것이 의뢰 범위에 들어 있는지는 계약에 따릅니다.
재검토가 없으면 최종 보고서는 "지적 사항이 있었다"까지만 말합니다.
"고쳐졌다"는 재검토 보고서가 말합니다. 거래소와 파트너가 보는 것은 후자입니다.
재검토 보고서까지 받은 뒤에 배포 일정을 잡는 것이 순서입니다. 보고서를 기다리며 배포를 먼저 하면 감사는 배포 뒤의 서류가 됩니다.
확인 5 · 운영의 안전은 감사 보고서 밖에 있습니다
감사는 코드를 봅니다.
키를 어떻게 보관하는지, 관리자 권한을 누가 쓰는지, 배포를 누가 실행하는지는 코드가 아니라 운영입니다.
컨트랙트가 완벽해도 관리자 키 하나가 한 사람의 컴퓨터에 있으면 안전하지 않습니다.
이 부분은 감사 보고서에 나오지 않고, 프로젝트가 따로 정해야 합니다.
키 분산. 권한 축소 일정. 배포 절차.
이것을 감사와 같은 시점에 정리하면 보고서와 운영이 함께 갖춰집니다.
FD인터내셔널이 위험 구조설계를 따로 두는 이유입니다. 토큰 해제, 재단 자산, 거래상대방, 유동성, 운영에서 발생할 수 있는 위험은 코드 밖에 있습니다.
순서를 갖춘 감사는 파일이 아니라 이력이 됩니다
범위를 정하고, 코드를 정하고, 고칠 사람을 정하고, 재검토를 넣고, 운영 안전을 따로 정리합니다.
이 다섯 가지가 준비된 뒤에 감사를 의뢰하면 보고서는 파일이 아니라 이력이 됩니다.
감사를 받는 것은 실행입니다. 그 실행이 의미를 가지려면 그 앞의 판단과 그 뒤의 반영이 이어져 있어야 합니다.
자문은 실행으로 이어져야 하고, 감사도 마찬가지입니다. 보고서를 받는 데서 끝나는 감사는 검토가 아니라 서류입니다.
먼저 여쭙는 것은 지적 건수가 아니라 고친 건수입니다
감사 보고서를 보여주시면 FD가 먼저 여쭙는 것은 지적 사항이 몇 건이었는지가 아닙니다.
그중 몇 건이 고쳐졌고, 고친 것을 누가 확인했는가입니다.
이 질문에 답이 나오는 프로젝트는 감사를 이력으로 갖고 있는 것이고, 답이 없는 프로젝트는 보고서를 파일로 갖고 있는 것입니다.
두 번째로 여쭙는 것은 관리자 키가 지금 어디에 있는가입니다.
이 질문에서 대화가 멈추는 경우가 감사 보고서의 지적 사항보다 많습니다.