외주 개발사에서 스마트컨트랙트를 넘겨받은 운영팀은 세 가지를 차례로 확인해야 합니다. 첫째, 넘겨받은 소스가 실제 배포된 바이트코드와 같은지 봅니다. 둘째, 스마트컨트랙트코드리뷰가 어떤 범위로 수행되었는지 확인합니다. 셋째, 스마트컨트랙트증명 자료가 그 범위를 뒷받침하는지 대조합니다. 이 세 가지 중 하나라도 확인되지 않으면 인수 완료로 보지 않고 보완을 요청하는 것이 안전합니다.
외주 개발사가 넘긴 스마트컨트랙트 코드는 인수 전에 무엇부터 확인해야 합니까?
가장 먼저 인수 대상의 경계를 정합니다. 외주 계약으로 개발된 스마트컨트랙트코드는 대개 여러 컨트랙트와 외부 라이브러리, 배포 스크립트, 설정 파일로 이루어집니다. 운영팀이 받은 저장소에 어떤 파일이 들어 있고 어떤 커밋이 최종본인지 명확하지 않으면, 이후의 리뷰와 증명은 모두 근거가 약해집니다.
미국 국립표준기술연구소(NIST)는 블록체인 기술 개요 보고서(NISTIR 8202)에서 블록체인을 분산 방식으로 구현되어 변조를 드러내고 막는 디지털 원장으로 설명합니다. 따라서 운영팀은 저장소 소스뿐 아니라 체인에 배포된 코드와 상태를 인수 대상으로 보아야 합니다. 인수 첫 단계에서 확인할 항목은 다음과 같습니다.
- 최종 커밋 해시: 개발사가 최종본이라고 지정한 커밋과 태그를 문서로 받아 둡니다.
- 컴파일 환경: 컴파일러 버전, 최적화 옵션과 실행 횟수, 의존 라이브러리 버전을 고정된 값으로 받습니다.
- 배포 주소 목록: 네트워크별 컨트랙트 주소, 프록시와 구현 컨트랙트의 관계, 배포 트랜잭션 해시를 정리합니다.
- 권한 구조: 소유자·관리자·일시정지 권한을 가진 주소와 그 키를 누가 보관하는지, 다중서명 구성이 어떻게 되어 있는지 확인합니다.
권한 키가 아직 개발사 측에 남아 있다면 코드 품질과 상관없이 운영 위험이 남습니다. 인수 절차에는 권한 이전 트랜잭션을 실행하고 그 결과를 확인하는 단계가 반드시 포함되어야 합니다.
스마트컨트랙트코드리뷰는 어떤 범위와 순서로 진행해야 합니까?
스마트컨트랙트코드리뷰는 사람이 읽는 수동 검토와 도구를 활용한 분석을 함께 진행하는 것이 일반적입니다. 일반적인 보안 소프트웨어 개발 실무에서도 사람이 읽을 수 있는 코드를 검토하거나 분석해 취약점을 찾는 활동과 실행 가능한 코드를 테스트하는 활동을 구분해 다룹니다. 스마트컨트랙트에도 같은 구분을 적용할 수 있습니다.
운영팀이 직접 리뷰하든 제3의 감사 기관에 맡기든, 다음 순서를 따르면 누락을 줄일 수 있습니다.
- 명세 대조: 기획서나 백서에 적힌 토큰 발행량, 수수료율, 출금 제한 같은 비즈니스 규칙이 코드에 그대로 구현되었는지 확인합니다.
- 권한·접근 제어 검토: 관리자 함수마다 호출 제한이 있는지, 업그레이드 함수가 보호되는지 확인합니다.
- 자금 흐름 검토: 입금·출금·정산 경로에서 재진입, 정밀도 손실, 외부 호출 순서 문제를 점검합니다.
- 외부 의존성 검토: 가격 오라클, 브리지, 외부 토큰 컨트랙트에 대한 가정을 목록으로 만들어 실패 상황을 검토합니다.
- 정적 분석과 테스트: 정적 분석 도구 결과를 분류하고, 단위 테스트와 퍼징 결과의 커버리지를 확인합니다.
국내에서도 공공 정보화사업을 중심으로 소프트웨어 개발보안(시큐어코딩)이 강조되고 있으며, 관련 보안약점 진단 가이드와 개발보안 가이드가 공개되어 있습니다. 이 자료들은 스마트컨트랙트 전용 문서는 아닙니다. 다만 입력값 검증, 오류 처리, 권한 관리 같은 보안약점 분류 체계는 리뷰 체크리스트를 만들 때 참고할 수 있습니다.
스마트컨트랙트증명 자료는 무엇을 갖춰야 검수를 통과했다고 볼 수 있습니까?
스마트컨트랙트증명은 하나의 문서가 아닙니다. 리뷰가 실제로 수행되었고 그 결과가 배포된 코드에 반영되었음을 보여 주는 자료 묶음입니다. 감사 보고서 한 부만 있고 대상 커밋이 적혀 있지 않다면 증명력이 약하다고 판단합니다. 검수 기준은 아래 표처럼 정리할 수 있습니다.
| 검수 항목 | 요청할 자료 | 통과 기준 |
|---|---|---|
| 리뷰 대상 특정 | 감사·리뷰 보고서의 범위 절 | 커밋 해시와 파일 목록이 명시되고 인수받은 최종본과 일치함 |
| 발견 사항 조치 | 이슈별 조치 내역과 수정 커밋 | 심각도 높음·중간 항목이 모두 수정되었거나, 수용 사유가 문서화됨 |
| 재검토 여부 | 수정 후 재검토 확인서 | 수정 커밋을 리뷰어가 다시 확인했다는 기록이 있음 |
| 소스 검증 | 블록 탐색기 소스 검증 결과, 재컴파일 결과 | 동일 컴파일 설정으로 재컴파일한 바이트코드가 온체인 코드와 일치함 |
| 테스트 근거 | 테스트 실행 로그, 커버리지 보고서 | 핵심 자금 흐름 함수가 테스트에 포함되고 운영팀 환경에서 재현됨 |
| 형식 검증(해당 시) | 검증한 속성 목록과 도구 설정 | 증명된 속성과 가정이 문서화되고, 증명 범위 밖 함수가 구분됨 |
형식 검증 결과를 받았다면 증명된 속성이 무엇인지부터 봅니다. "총 공급량은 발행 함수 외에는 증가하지 않는다"처럼 구체적인 속성이 명시되어야 합니다. 동시에 그 증명이 어떤 가정 위에서 성립하는지도 확인해야 합니다. 가정이 실제 운영 환경과 다르면 증명은 그 범위 안에서만 의미가 있습니다.
리뷰 결과와 실제 배포 상태가 일치하는지 어떻게 대조합니까?
보고서가 충실해도 배포된 코드가 다르면 의미가 없습니다. 운영팀은 다음 절차로 직접 대조하는 것이 바람직합니다.
- 재컴파일 대조: 인수받은 최종 커밋을 개발사가 제공한 컴파일 설정으로 직접 빌드합니다. 생성된 런타임 바이트코드를 온체인 코드와 비교하되, 메타데이터 해시 차이는 따로 구분해 판단합니다.
- 프록시 구조 확인: 업그레이드 가능한 구조라면 현재 프록시가 가리키는 구현 주소를 읽어, 리뷰 대상 구현 컨트랙트와 같은지 확인합니다.
- 초기화 상태 확인: 초기화 함수가 이미 호출되었는지, 수수료율이나 관리자 주소 같은 초기값이 명세와 같은지 읽기 호출로 확인합니다.
- 배포 이후 변경 이력 확인: 리뷰 이후에 업그레이드나 파라미터 변경 트랜잭션이 있었는지 확인하고, 있었다면 그 변경분이 리뷰 범위에 들어갔는지 따집니다.
미국 사이버보안·인프라보안청(CISA)은 보안 중심 설계(Secure by Design) 원칙에서 고객의 보안 결과에 책임을 지고 철저한 투명성과 책임성을 갖출 것을 원칙으로 제시합니다. 인수 단계에서 이 원칙을 적용하면, 개발사에 대조 결과를 재현할 수 있는 자료를 요구하는 것은 정당한 검수 절차가 됩니다. 대조 과정에서 불일치가 나오면 원인을 기록하고, 해당 컨트랙트는 재리뷰 대상으로 분류합니다.
하자 보수 범위, 검수 기간, 보안 사고 발생 시 책임 분담 같은 계약 조건은 계약서 문구에 따라 해석이 달라질 수 있습니다. 인수 거절이나 보완 요청이 분쟁으로 이어질 가능성이 있다면 법률 전문가와 상담한 뒤 진행하는 것을 권합니다.
자주 묻는 질문
외주 개발사가 이미 감사 보고서를 제출했다면 별도의 코드리뷰가 필요 없지 않습니까?
감사 보고서는 특정 시점, 특정 커밋에 대한 결과입니다. 이후 수정이나 재배포가 있었다면 그 변경분은 보고서 범위에 들어 있지 않습니다. 따라서 보고서의 대상 커밋과 인수받은 최종본, 온체인 코드가 일치하는지 확인하는 최소한의 리뷰는 필요합니다.
블록 탐색기에서 소스 검증이 완료되었으면 증명이 끝난 것입니까?
소스 검증은 공개된 소스가 해당 주소의 바이트코드와 일치한다는 사실만 보여 줍니다. 그 코드가 안전하다는 의미는 아닙니다. 리뷰 보고서, 조치 내역, 테스트 근거와 함께 보아야 스마트컨트랙트증명 자료로서 의미가 있습니다.
운영팀에 보안 전문 인력이 없으면 어디까지 직접 확인할 수 있습니까?
최종 커밋 고정, 배포 주소와 권한 주소 정리, 재컴파일 대조, 초기 설정값 확인은 개발 경험이 있는 인력이라면 절차서를 따라 수행할 수 있습니다. 자금 흐름이나 외부 의존성에 대한 심층 리뷰는 독립된 외부 리뷰어에게 맡기고, 운영팀은 범위 정의와 결과 대조에 집중하는 방식이 현실적입니다.