DAO 재단의 트레저리는 배포 전에 받은 코드 감사만으로는 충분히 보호되지 않습니다. 배포 후에는 온체인감사로 권한 구조, 자금 흐름, 거버넌스 실행 기록을 주기적으로 대조해야 하며, 이상 징후가 나타났을 때 따를 대응 절차도 미리 문서로 정해 두어야 합니다. 이 글에서는 점검 항목과 우선순위, 대응 순서, 규제 측면에서 참고할 기준을 정리합니다.
온체인감사는 배포 전 코드 감사와 무엇이 다릅니까?
블록체인감사는 흔히 두 단계로 나눕니다. 첫 번째 단계는 배포 전에 스마트컨트랙트 소스 코드의 취약점을 찾는 블록체인보안감사이고, 두 번째 단계는 배포 후 체인에 기록된 실제 상태와 거래를 검증하는 온체인감사입니다. 코드 감사는 "코드가 의도대로 작성되었는가"를 확인하고, 온체인감사는 "실제로 배포된 컨트랙트와 그 운영이 의도대로 이루어지고 있는가"를 확인한다는 점에서 목적이 다릅니다.
이 차이는 블록체인의 구조에서 비롯됩니다. 미국 국립표준기술연구소(NIST)는 보고서 NISTIR 8202에서 블록체인을 변조를 탐지하고 저항하도록 설계되어 분산 방식으로 구현된 디지털 원장으로 설명합니다. 원장에 남은 기록은 누구나 조회할 수 있으므로 재단은 외부 감사인과 같은 데이터를 기준으로 자금 흐름을 검증할 수 있습니다. 반대로 공격자도 같은 데이터를 볼 수 있으므로 권한 설정의 빈틈은 빠르게 악용될 수 있습니다.
실무에서 자주 놓치는 부분은 감사받은 코드와 배포된 코드가 같은지 확인하는 일입니다. 감사 이후 수정된 버전이 배포되었거나 프록시 컨트랙트의 구현 주소가 바뀌었다면 기존 감사 보고서의 효력은 제한됩니다. 따라서 온체인감사는 블록 탐색기에 공개된 바이트코드와 감사 대상 커밋을 대조하는 작업부터 시작하는 것이 바람직합니다.
트레저리 점검은 어떤 항목부터 봐야 합니까?
점검 항목은 피해 규모와 발생 가능성을 기준으로 우선순위를 정합니다. 자금을 직접 옮길 수 있는 권한을 가장 먼저 확인하고, 그다음 거버넌스 실행 경로와 외부 의존성을 차례로 확인하는 방식이 일반적입니다. 아래 표는 DAO 트레저리에서 주로 쓰는 점검 기준을 정리한 것입니다.
| 점검 영역 | 확인 내용 | 이상 징후 예시 | 권장 주기 |
|---|---|---|---|
| 관리자 권한 | owner·admin 주소, 멀티시그 서명자 목록과 서명 기준 | 서명자 교체, 서명 기준 하향, 단일 주소로 권한 이전 | 변경 발생 시 즉시, 정기 점검은 주 1회 |
| 업그레이드 구조 | 프록시 구현 주소, 업그레이드 권한 보유자, 타임락 설정 | 타임락 없이 구현 주소 변경, 미검증 코드로 교체 | 변경 발생 시 즉시 |
| 자금 흐름 | 트레저리 지갑 입출금, 승인(approve) 한도, 예산 집행 내역 | 무제한 승인, 승인된 제안과 맞지 않는 출금 | 일 단위 자동 모니터링 |
| 거버넌스 실행 | 통과된 제안과 실제 실행된 트랜잭션의 일치 여부 | 짧은 기간에 집중된 투표권 이동, 제안 내용과 다른 calldata | 제안 실행 시마다 |
| 외부 의존성 | 오라클 가격, 브리지·유동성 풀 등 연동 컨트랙트 상태 | 가격 급변, 연동 컨트랙트 일시 정지 또는 업그레이드 | 실시간 알림 설정 |
표의 항목 가운데 승인 한도는 특히 주의해야 합니다. 과거 운영 편의를 위해 외부 컨트랙트에 무제한 승인을 해 두었다면, 그 컨트랙트가 공격받을 때 트레저리 자산도 함께 빠져나갈 수 있습니다. 승인 목록은 분기마다 전수 조회하여 쓰지 않는 승인은 회수하는 것이 좋습니다.
이상 징후를 발견하면 어떤 순서로 대응합니까?
대응 속도는 사전 준비 수준에 따라 크게 달라집니다. 사고가 난 뒤에 절차를 정하면 서명자 소집과 의사결정에 시간이 걸려 피해가 커질 수 있습니다. 다음은 온체인감사 중 이상 징후를 발견했을 때 따를 수 있는 일반적인 순서입니다.
- 사실 확인: 알림이 오탐인지 확인하기 위해 트랜잭션 해시, 호출 함수, 관련 주소를 블록 탐색기에서 직접 조회합니다.
- 영향 범위 산정: 영향을 받을 수 있는 자산 규모와 연동 컨트랙트를 파악하고 추가 피해 가능성을 판단합니다.
- 긴급 조치: 일시 정지(pause) 기능, 승인 회수, 멀티시그를 통한 자산 이동 등 미리 정한 조치를 실행합니다.
- 기록 보존: 관련 트랜잭션, 내부 커뮤니케이션, 조치 시각을 시간순으로 정리하여 이후 분석과 신고에 대비합니다.
- 공지와 외부 협조: 커뮤니티에 사실 위주로 공지하고, 필요하면 거래소와 수사기관에 자금 추적 협조를 요청합니다.
- 원인 분석과 재감사: 근본 원인을 분석한 뒤 수정 코드는 다시 블록체인보안감사를 받고 배포합니다.
긴급 조치 권한은 누가, 몇 명의 서명으로, 어떤 조건에서 행사하는지 거버넌스 문서에 명시해 두어야 합니다. 권한이 지나치게 집중되면 중앙화 위험이 생기고, 지나치게 분산되면 대응이 늦어지므로 두 위험의 균형을 고려해 기준을 정합니다.
규제 측면에서 무엇을 참고해야 합니까?
DAO 재단이 직접 규제 대상인지는 사업 구조와 국가별 법령에 따라 다르지만, 거래소·수탁업체 등 협력 사업자에게 적용되는 기준을 이해해 두면 온체인감사 범위를 정하는 데 도움이 됩니다. 국제자금세탁방지기구(FATF) 지침에 따르면 거래에 관여한 양쪽 가상자산사업자는 관련 정보를 보관하고, 요청이 있으면 수사기관에 제공해야 합니다.
국내에서는 「특정 금융거래정보의 보고 및 이용 등에 관한 법률」에 따라 가상자산사업을 하려는 자가 금융정보분석원(FIU)에 미리 신고해야 합니다. 재단이 거래소를 통해 자금을 옮기거나 현금화하면 이 제도에 따른 확인 절차를 거칠 수 있으므로, 트레저리 출금 내역과 집행 근거를 미리 정리해 두는 것이 실무상 유리합니다.
또한 금융위원회 소관 「가상자산 이용자 보호 등에 관한 법률」은 가상자산사업자가 이용자의 가상자산 중 70% 이상의 범위에서 금융위원회가 정하는 비율(현재 80%) 이상을 인터넷과 분리하여 보관하도록 규정합니다. 이 기준은 재단에 직접 적용되지 않더라도 콜드월렛과 핫월렛의 비율, 출금 승인 절차를 설계할 때 참고할 수 있는 기준이 됩니다. 구체적인 적용 여부는 사업 구조에 따라 달라지므로 가상자산 분야에 경험이 있는 법률 전문가와 상담하는 것을 권합니다.
자주 묻는 질문
코드 감사를 이미 받았다면 온체인감사를 따로 해야 합니까?
코드 감사는 특정 시점의 소스 코드를 대상으로 하므로 배포 후 권한 변경이나 업그레이드, 운영 실수는 다루지 않습니다. 트레저리 규모가 크거나 업그레이드 가능한 구조라면 온체인감사를 별도로 주기적으로 실시하는 것이 바람직합니다.
온체인감사는 내부 인력으로 진행해도 되나요?
일상적인 모니터링과 승인 목록 점검은 내부 인력이 자동화 도구로 수행할 수 있습니다. 다만 권한 구조 재설계나 사고 이후 원인 분석처럼 이해관계가 걸린 판단은 독립성을 위해 외부 블록체인감사 전문 인력에게 검토를 맡기는 편이 신뢰도를 높입니다.
점검 결과를 커뮤니티에 공개해야 하나요?
공개 의무는 관할과 재단 정관에 따라 다르지만, 트레저리 현황과 권한 구조를 정기적으로 공개하면 거버넌스 참여자의 신뢰를 얻는 데 도움이 됩니다. 다만 아직 조치하지 않은 취약점은 수정이 끝난 뒤 공개하는 것이 일반적인 관행입니다.