개발 인력이 적은 초기 팀은 사내 코드리뷰에서 테스트 보강, 불필요한 코드 정리, 설계 문서 작성까지 마친 뒤 외부 감사를 맡기는 것이 좋습니다. 그래야 감사 범위가 줄고 수정 후 재검토 횟수도 줄어 CertiK 감사 비용을 예측하기 쉬워집니다. 사내 리뷰가 외부 감사를 대신할 수는 없습니다. 다만 외부 감사인이 기본 오류를 찾느라 시간을 쓰지 않고 실제 위험을 검토하는 데 집중하게 만드는 준비 단계로는 효과가 큽니다.
CertiK 감사 비용은 어떤 요소로 정해집니까?
스마트컨트랙트 감사 견적은 정해진 가격표보다 검토할 작업량을 기준으로 산정되는 경우가 일반적입니다. 실제 금액은 프로젝트마다 다르므로 견적서를 받을 때 아래 항목이 어떻게 반영되었는지 확인해야 합니다.
- 코드 규모와 범위: 감사 대상 파일 수와 코드 라인 수, 외부 라이브러리를 범위에 넣는지에 따라 작업량이 달라집니다.
- 로직 복잡도: 단순 토큰 발행보다 스테이킹, 대출, 브리지, 오라클 연동처럼 상태 변화가 많고 외부 호출이 잦은 구조일수록 검토 시간이 늘어납니다.
- 언어와 체인: 사용 언어나 실행 환경에 따라 투입할 수 있는 감사 인력과 도구가 달라집니다.
- 일정: 출시일이 정해져 있어 짧은 기간에 끝내야 하면 투입 인력을 늘려야 하므로 조건이 바뀔 수 있습니다.
- 재검토 포함 여부: 지적 사항을 고친 뒤 다시 확인하는 절차가 견적에 포함되는지, 몇 번까지 포함되는지 확인해야 합니다.
서비스 범위와 진행 방식은 CertiK 스마트컨트랙트 감사 안내(certik감사비용)에서 먼저 확인할 수 있습니다. 그다음 자체 코드 규모와 일정을 정리해 상담을 요청하면 견적을 비교하기가 쉬워집니다.
사내 코드리뷰로 대신할 수 있는 부분과 없는 부분은 무엇입니까?
CertiK 감사와 사내 코드리뷰를 비교할 때 핵심은 두 방식 중 하나를 고르는 것이 아니라 역할을 나누는 것입니다. 미국 국립표준기술연구소(NIST)의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)는 개발 주기에 통합할 수 있는 핵심 보안 개발 실무를 제시합니다. 사내 리뷰는 이런 보안 실무를 개발 주기 안에서 꾸준히 수행하는 장치이고, 외부 감사는 출시 전에 제3자가 독립적으로 검증하는 장치입니다.
| 구분 | 사내 코드리뷰 | 외부 CertiK 감사 |
|---|---|---|
| 주요 목적 | 기능 오류, 코드 품질, 팀 규칙 준수 확인 | 공격 시나리오 기반 취약점 식별과 독립 검증 |
| 수행 시점 | 기능 개발과 병합 단계마다 반복 | 코드가 확정된 시점에 정해진 기간 동안 수행 |
| 강점 | 도메인 지식이 깊고 수정 속도가 빠름 | 다양한 사고 사례에서 쌓은 패턴 지식, 이해관계에서 독립적 |
| 한계 | 작성자와 같은 가정을 공유해 맹점이 생기기 쉬움 | 범위 밖 코드와 이후 변경분은 검토하지 않음 |
| 결과물 | 내부 리뷰 기록, 수정 커밋 | 심각도별 지적 사항과 조치 여부가 담긴 보고서 |
사내 리뷰만으로 충분하다고 판단하기 어려운 경우는 이용자 자산을 직접 보관하거나 이동시키는 컨트랙트, 권한 변경이나 업그레이드 기능이 있는 컨트랙트, 외부 가격 정보에 의존하는 컨트랙트입니다. 이런 구조는 작성자가 예상하지 못한 호출 순서나 경제적 공격에 노출될 수 있으므로 독립 검증의 가치가 큽니다.
감사를 맡기기 전 사내에서 끝낼 준비는 어떤 순서로 진행합니까?
인력이 적은 팀일수록 순서를 정해 두고 하나씩 처리해야 빠뜨리는 항목이 줄어듭니다. 아래 순서는 감사 범위를 확정하고 재검토 부담을 줄이는 데 초점을 맞춘 것입니다.
- 범위 확정: 배포할 컨트랙트만 감사 대상으로 정하고 실험용 코드, 사용하지 않는 함수, 테스트용 모의 컨트랙트는 분리합니다.
- 코드 동결: 감사 기간에 기능을 추가하지 않도록 기준 커밋을 정합니다. 감사 중 코드가 바뀌면 범위가 다시 정해지고 비용 조건도 달라질 수 있습니다.
- 설계 문서 작성: 역할별 권한, 자금 흐름, 상태 전이, 외부 의존성을 정리합니다. 감사인이 의도를 파악하는 시간이 줄어듭니다.
- 테스트 보강: 정상 흐름뿐 아니라 권한 없는 호출, 경계값, 재진입 상황을 다루는 테스트를 추가하고 커버리지를 확인합니다.
- 정적 분석 도구 실행: 자동 도구로 잡히는 경고를 먼저 처리하고, 처리하지 않은 경고에는 사유를 기록합니다.
- 교차 리뷰: 작성자가 아닌 팀원이 권한 관리, 외부 호출, 산술 연산 위주로 다시 읽습니다.
일반 소프트웨어 개발보안 분야에서도 같은 원칙이 적용됩니다. 소프트웨어 개발보안 관련 자료에서는 보안약점을 입력데이터 검증, 보안기능, 시간 및 상태, 에러처리, 코드오류, 캡슐화, API 오용 등의 유형으로 나누어 설명하는 경우가 많습니다. 스마트컨트랙트에 그대로 대응하지는 않지만, 사내 체크리스트를 만들 때 분류 틀로 참고할 수 있습니다.
감사 이후에도 비용이 추가로 생기는 지점은 어디입니까?
CertiK 감사 보고서를 받은 뒤에도 비용이 발생하는 지점이 있으므로 예산을 처음부터 감사비만으로 잡지 않는 것이 좋습니다. 가장 흔한 경우는 지적 사항을 수정한 뒤 다시 검토를 받는 과정입니다. 수정 범위가 넓으면 새로운 문제가 생길 수 있어 재검토 범위도 넓어집니다. 출시 후 컨트랙트를 업그레이드하거나 새 기능을 추가하면 변경분을 따로 감사해야 할 수 있습니다. 운영 단계에서는 모니터링, 키 관리, 사고 대응 체계를 갖추는 데에도 비용이 듭니다.
사고 대응 측면에서는 한국인터넷진흥원(KISA)이 보호나라를 통해 보안 공지를 제공하고 있습니다. 사내 대응 절차를 만들 때 참고할 만합니다. 국내 이용자를 대상으로 서비스하는 경우에는 금융위원회 소관의 「가상자산 이용자 보호 등에 관한 법률」이 이용자의 예치금 및 가상자산 보호, 시세조종 등 불공정거래행위 규제를 담고 있으므로, 서비스 구조가 이 법의 적용 대상인지 확인할 필요가 있습니다. 적용 여부와 구체적인 의무는 사업 구조에 따라 달라지므로 법률 전문가와 상담한 뒤 판단하는 것이 바람직합니다.
예산을 짤 때는 감사비, 재검토 비용, 출시 후 변경분 검토, 운영 보안 비용을 각각 나누어 잡아 두면 일정이 밀리거나 범위가 바뀌어도 대응하기 쉽습니다.
자주 묻는 질문
코드가 짧은 토큰 컨트랙트도 외부 감사가 필요합니까?
표준 구현을 거의 그대로 사용하고 별도 권한 기능이 없다면 사내 리뷰와 자동 분석으로 위험을 상당 부분 줄일 수 있습니다. 다만 발행 권한, 수수료 부과, 거래 제한 같은 기능을 추가했다면 이용자 신뢰와 위험 관리 측면에서 독립 검증을 받는 것이 좋습니다.
사내 리뷰를 충실히 하면 CertiK 감사 비용이 줄어듭니까?
감사 범위가 명확하고 코드가 정리되어 있으면 감사인이 기본 오류를 찾는 데 쓰는 시간과 수정 후 재검토 횟수가 줄어듭니다. 실제 금액은 견적 조건에 따라 달라지므로 범위와 재검토 포함 여부를 함께 비교하는 것이 좋습니다.
감사를 받은 컨트랙트는 안전하다고 볼 수 있습니까?
감사는 정해진 시점과 범위의 코드를 검토한 결과이므로 모든 위험이 없다는 뜻은 아닙니다. 범위 밖 코드, 이후 변경분, 운영상 키 관리 문제는 별도로 관리해야 하며, 보고서에 남은 미조치 항목도 함께 확인해야 합니다.