투자 실사를 앞둔 디파이 팀은 사내 코드리뷰로 결함을 먼저 걸러 낸 뒤, 자금 흐름과 권한 구조처럼 위험이 큰 범위만 외부 감사에 맡기는 편이 비용과 신뢰도 모두에서 유리합니다. 외부 감사는 제3자가 독립적으로 검증했다는 증빙이 되고, 사내 코드리뷰는 감사 전에 코드 품질을 끌어올리는 준비 단계입니다. 따라서 두 방식은 어느 하나를 고르는 문제가 아니며, 순서와 범위를 어떻게 나눌지가 핵심입니다.
감사 기관의 본사·계약 법인을 확인할 때 무엇을 먼저 보아야 합니까?
감사 기관의 본사·계약 법인을 확인하려는 실무자는 대개 본사 소재지, 계약 주체가 되는 법인, 공식 문의 창구를 확인하려는 목적을 가지고 있습니다. 투자자가 실사 과정에서 감사 보고서의 발행 주체와 계약서의 법인명이 일치하는지 묻는 경우가 있기 때문입니다. 본사 위치나 지역 법인 정보는 검색 결과의 요약문만 믿지 말고, 해당 기관의 공식 채널과 견적서·계약서에 적힌 법인 정보로 다시 확인해야 합니다.
보안 감사 업계에서는 유명 감사 기관을 사칭해 견적이나 보고서 발급을 미끼로 접근하는 사례가 꾸준히 보고됩니다. 메신저로 먼저 연락해 선입금을 요구하거나, 공식 도메인이 아닌 주소로 보고서를 보내는 경우에는 계약을 진행하기 전에 공식 창구로 진위를 확인하는 절차를 거쳐야 합니다. 확인할 항목은 다음과 같습니다.
- 견적서·계약서의 법인명과 서명 주체가 공식 채널에 공개된 정보와 일치하는지
- 보고서 고유 식별 정보와 감사 대상 커밋 해시가 공개 저장소의 코드와 일치하는지
- 결제 계좌나 지갑 주소가 공식 계약 절차를 통해 전달되었는지
- 담당 매니저의 연락처를 공식 문의 창구에서 다시 확인할 수 있는지
외부 감사 비용은 어떤 요소로 달라집니까?
외부 감사 비용은 고정된 정가표보다 프로젝트별 견적으로 정해지는 경우가 일반적이며, 공개된 단일 가격을 기준으로 예산을 잡으면 실제 견적과 차이가 크게 날 수 있습니다. 견적을 비교할 때는 총액보다 어떤 항목이 비용을 만들었는지를 분해해서 보는 것이 중요합니다. 아래 표는 견적에 영향을 주는 주요 요소와 팀이 사전에 줄일 수 있는 방법을 정리한 것입니다.
| 비용 요소 | 비용이 늘어나는 조건 | 사전에 줄이는 방법 |
|---|---|---|
| 코드 규모 | 주석·테스트를 제외한 실제 로직 줄 수가 많을 때 | 사용하지 않는 함수와 중복 코드를 정리하고 감사 범위 파일을 명시합니다 |
| 로직 복잡도 | 외부 프로토콜 연동, 오라클 의존, 업그레이드 프록시 구조가 있을 때 | 설계 문서와 호출 흐름도를 함께 제출해 분석 시간을 줄입니다 |
| 일정 | 투자 마감이나 출시일에 맞춘 긴급 일정을 요청할 때 | 코드 동결 시점을 미리 정하고 여유 있게 일정을 예약합니다 |
| 재감사 범위 | 지적 사항 수정 과정에서 코드가 크게 바뀔 때 | 수정 커밋을 지적 항목별로 분리하고 기능 추가를 섞지 않습니다 |
| 부가 서비스 | 포멀검증, 팀 신원 확인, 배포 후 모니터링을 함께 계약할 때 | 실사에 꼭 필요한 항목과 이후에 추가할 항목을 나눠 견적을 받습니다 |
견적을 받을 때는 최초 감사 비용에 재감사 1회가 포함되는지, 보고서 공개 범위를 팀이 정할 수 있는지, 수정 확인 기간이 얼마인지를 서면으로 확인해야 합니다. 같은 총액이라도 재감사가 별도로 청구되면 실제 지출은 크게 달라집니다. 비용 구조와 세무 처리 방식은 법인의 회계 기준에 따라 달라질 수 있으므로 회계·세무 전문가와 상의하는 것이 안전합니다.
외부 감사와 사내 코드리뷰는 무엇이 다르고 어떻게 나눠야 합니까?
외부 감사와 사내 코드리뷰의 차이를 비교할 때 가장 큰 차이는 독립성과 증빙력입니다. 사내 코드리뷰는 설계 의도를 잘 아는 사람이 빠르게 반복할 수 있다는 장점이 있지만, 같은 가정을 공유하는 팀원끼리는 설계 단계의 결함을 놓치기 쉽습니다. 외부 감사는 비용과 대기 시간이 들지만, 투자자와 이용자에게 제3자 검증 결과를 제시할 수 있습니다.
NIST의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)는 각 개발 생명주기에 통합할 수 있는 보안 개발 관행을 제시하며, 이를 따르면 배포 소프트웨어의 취약점을 줄이는 데 도움이 된다고 설명합니다. 이러한 취지에 비추어 보면, 사내 코드리뷰는 감사의 대체 수단이라기보다 개발 과정 전반에 포함되어야 하는 기본 통제로 보는 것이 타당하다고 판단합니다.
| 구분 | 사내 코드리뷰 | 외부 감사 |
|---|---|---|
| 목적 | 결함 조기 발견, 코드 품질 유지 | 독립 검증, 대외 신뢰 확보 |
| 수행 시점 | 모든 풀 리퀘스트 단위로 상시 진행 | 코드 동결 이후 특정 버전에 대해 진행 |
| 강점 | 설계 의도 이해, 빠른 반복, 낮은 추가 비용 | 다른 프로젝트 사고 사례 경험, 공격자 관점 분석 |
| 한계 | 같은 가정을 공유해 맹점이 생기기 쉬움 | 감사 시점 이후 변경된 코드는 보장하지 않음 |
| 실사 증빙력 | 리뷰 기록과 체크리스트로 개발 절차를 보여 줌 | 공개 보고서로 특정 버전의 검증 결과를 보여 줌 |
역할을 나누는 실무 기준은 위험의 크기입니다. 이용자 자산이 직접 이동하는 함수, 관리자 권한과 업그레이드 경로, 가격 산정과 청산 로직은 외부 감사의 핵심 범위로 지정합니다. 반면 조회용 함수, 프런트엔드 연동용 보조 컨트랙트, 단순한 이벤트 기록은 사내 코드리뷰와 정적 분석 도구로 충분히 관리할 수 있는 경우가 많습니다.
위협 모델링도 사내에서 먼저 끝내 두는 편이 좋습니다. 설계 단계에서 소프트웨어가 마주할 보안 위험을 미리 정리하고 그 결과물을 감사 기관에 함께 전달하면, 감사인이 팀의 가정을 빠르게 이해하고 검증 범위를 정확히 잡는 데 도움이 될 수 있습니다.
투자 실사 전 어떤 순서로 준비하면 비용과 기간을 줄일 수 있습니까?
감사 비용의 상당 부분은 감사인이 코드를 이해하는 데 드는 시간과 재감사에서 발생합니다. 사내 단계에서 기본적인 결함을 제거하고 문서를 갖춰 두면 감사인은 깊이 있는 논리 결함 분석에 시간을 쓸 수 있습니다. 권장 순서는 다음과 같습니다.
- 범위 확정: 실사에서 투자자가 요구하는 컨트랙트 목록을 확인하고 감사 대상 파일과 커밋을 고정합니다.
- 사내 코드리뷰 완료: 모든 변경 사항에 최소 2인 이상의 검토 기록을 남기고, 권한·자금 흐름 함수는 별도 체크리스트로 점검합니다.
- 자동 분석 수행: 정적 분석 도구와 테스트 커버리지 측정을 실행해 단순 결함을 먼저 수정합니다.
- 문서 준비: 설계 문서, 위협 모델, 알려진 제약 사항, 배포 스크립트를 정리해 감사 기관에 전달합니다.
- 외부 감사와 수정: 지적 사항별로 수정 커밋을 분리하고, 수용하지 않은 지적은 사유를 서면으로 남깁니다.
- 배포 버전 대조: 실제 배포한 바이트코드가 감사한 커밋과 일치하는지 확인하고 그 결과를 실사 자료에 포함합니다.
국내 공공 영역에서도 개발 단계 보안 활동은 제도로 정해져 있습니다. 행정안전부는 전자정부서비스 개발 단계에서 소프트웨어 보안약점을 제거하기 위해 신규 정보시스템에 소프트웨어 개발보안(시큐어코딩)을 의무화했습니다. 블록체인 프로젝트에 이 제도가 직접 적용되는 것은 아니지만, 설계 단계부터 보안 약점을 관리하는 원칙은 사내 코드리뷰 체계를 설계할 때 참고할 수 있습니다.
공공 분야에서 쓰이는 소프트웨어 보안약점 분류 체계는 입력값 검증, 보안 기능, 오류 처리 등 유형별로 보안 약점을 나누어 다룹니다. 스마트컨트랙트 고유의 재진입 공격이나 가격 조작 같은 항목은 별도 체크리스트가 필요하지만, 일반적인 보안 약점 분류 체계는 사내 리뷰 항목을 정리하는 출발점으로 활용할 수 있습니다.
배포 이후에도 점검은 계속되어야 합니다. 과학기술정보통신부와 KISA는 해킹에 악용될 수 있는 취약점을 사전에 조치하기 위해 소프트웨어 신규 취약점 신고포상제를 운영합니다. 필자는 이 제도처럼 외부 신고 경로를 열어 두는 방식이 감사 이후 새로 발견되는 결함에 대응하는 보완 수단이 될 수 있다고 봅니다. 프로젝트 차원에서는 버그바운티 정책과 긴급 대응 연락처를 함께 공개해 두는 것이 좋습니다.
자주 묻는 질문
외부 감사를 받으면 사내 코드리뷰를 생략해도 됩니까?
생략하지 않는 것이 바람직합니다. 외부 감사는 특정 시점의 특정 버전만 검증하므로, 그 이후의 변경 사항은 사내 코드리뷰로 계속 관리해야 합니다. 사내 리뷰 기록은 투자 실사에서 개발 절차의 성숙도를 보여 주는 자료로도 쓰입니다.
외부 감사 비용 견적을 비교할 때 가장 먼저 볼 항목은 무엇인가요?
총액보다 감사 범위, 재감사 포함 여부, 수정 확인 기간을 먼저 확인해야 합니다. 범위가 다른 견적끼리 금액만 비교하면 판단을 그르칠 수 있습니다. 부가 서비스가 기본 견적에 섞여 있다면 항목별로 분리해 다시 요청하는 것이 좋습니다.
감사 보고서가 있으면 투자자는 보안 위험이 없다고 판단하나요?
그렇지 않습니다. 감사 보고서는 감사 범위 안에서 발견된 위험과 그 조치 상태를 보여 줄 뿐이며, 모든 위험이 없다는 보증으로 해석되지 않습니다. 투자 계약이나 이용자 보호와 관련된 법적 판단이 필요하다면 법률·회계 전문가와 상담하는 것을 권합니다.