스마트 컨트랙트 감사하는 법: 단계별 보안 점검 가이드

스마트 컨트랙트 감사는 온체인 코드를 배포하기 전에 보안 취약점, 논리 오류, 가스 비효율을 체계적으로 찾아내는 과정입니다. 제대로 된 감사는 네 겹으로 이루어집니다. 컨트랙트가 의도한 동작의 범위를 정하고, 한 줄씩 수동으로 검토하고, Slither나 MythX 같은 도구로 정적·동적 분석을 돌리고, 퍼징을 포함한 테스트를 충분히 거칩니다. 한 번 배포된 스마트 컨트랙트 코드는 바꿀 수 없기 때문에, 감사는 사용자 자금을 털어 갈 수 있는 버그를 잡을 수 있는 사실상 마지막 기회입니다.

스마트 컨트랙트 감사는 실제로 무엇을 검증하나

블록체인 위에서 돌아가는 스마트 컨트랙트는 조건이 전부 체인 위에 기록된, 스스로 실행되는 코드입니다. 이 불변성은 장점이자 위험입니다. 배포 뒤에는 고객센터도, 되돌리기도, 버그를 고쳐 줄 중앙 주체도 없습니다. 그래서 감사는 세 가지를 동시에 확인합니다. 명세가 정한 일을 하는지, 해서는 안 되는 일을 하지 않는지, 외부 공격자가 컨트랙트를 의도하지 않은 상태로 몰아갈 수 있는지입니다.

이 구분은 디파이(DeFi)에서 특히 중요합니다. 웹 서비스의 버그는 몇 분 만에 고칠 수 있지만, 대출 풀의 버그는 트랜잭션 한 번으로 풀 전체가 비워질 수 있습니다. 대표적인 두 사건이 위험의 크기를 보여 줍니다. 2016년 The DAO 재진입 공격으로 약 6,000만 달러어치 이더리움(ETH)이 빠져나갔고, 2021년 Poly Network 크로스체인 해킹에서는 자금이 반환되기 전까지 6억 달러가 넘는 금액이 이동했습니다. 두 사건 모두 평범한 검토는 통과했지만 공격자의 관점에서는 무너지는 논리에서 비롯됐습니다.

2024년 해킹 데이터가 말해 주는 것

독립 블록체인 보안 연구자들이 집계한 자료에 따르면 2024년 한 해 디파이 프로토콜을 노린 공격의 피해는 모두 합쳐 15억 달러를 넘었습니다. 그중 60% 이상이 이미 감사를 받은 컨트랙트에서 나왔습니다. 감사 이후의 코드 수정이 새로운 구멍을 만들었거나, 어떤 정적 분석기도 모델링할 수 없는 경제 설계의 허점이 악용된 경우입니다. 이 숫자만 봐도 "감사 완료" 배지는 안전의 보증이 아니라 출발점이라는 점이 분명합니다.

스마트 컨트랙트 감사의 5단계 흐름

전문 감사는 한 번 훑고 끝나는 작업이 아닙니다. 각 단계가 다음 단계의 탐색 범위를 좁혀 주는, 반복 가능한 과정입니다.

1단계: 범위 설정과 위협 모델링

코드를 한 줄도 읽기 전에 감사인은 컨트랙트가 무엇을 해야 하는지, 그리고 이를 깨뜨려서 이득을 보는 사람이 누구인지부터 정리합니다. 토큰인지, DAO 금고인지, 자동화 마켓메이커인지, 브리지인지에 따라 공격 표면이 다릅니다. 대출 시장은 가격 오라클 조작을, 볼트는 재진입을, 거버넌스 컨트랙트는 플래시론을 이용한 투표 장악을 끌어들입니다. 위협 모델을 문서로 남겨 두면 초보 감사에서 가장 흔한 실패, 즉 코드에 없는 버그를 찾느라 있는 버그를 놓치는 일을 막을 수 있습니다.

2단계: 한 줄씩 수동 검토

사람의 판단이 빠질 수 없는 단계입니다. 감사인은 함수마다 세 가지를 묻습니다. 어떤 상태를 바꾸는가, 호출자가 무엇을 통제할 수 있는가, 극단적인 값에서는 어떻게 되는가. 0 전송, 정수 경계값, 빈 배열, 토큰 콜백을 통한 예상치 못한 재진입 같은 경계 조건에서 실제 해킹 대부분이 일어납니다. 알려진 패턴의 체크리스트가 검토의 뼈대가 되고, 두 번째 검토자(네 눈 원칙)는 첫 번째 검토자가 익숙해져 지나친 부분을 꾸준히 잡아냅니다.

3단계: 자동 정적·동적 분석

도구는 기계의 속도로 넓은 범위를 훑습니다. 정적 분석기는 코드를 실행하지 않고 구조를 분석하고, 퍼징 도구와 심볼릭 실행기는 자동 생성한 수천 개의 입력으로 코드를 돌려 봅니다. 쉽게 잡히는 문제를 찾는 데는 탁월하지만 오탐이 생기고 맥락에 따라 달라지는 문제는 놓칩니다. 그래서 2단계를 보완할 뿐 대신하지 못합니다.

4단계: 테스트 스위트와 퍼징

컨트랙트는 단위 테스트(함수 하나씩), 통합 테스트(함수 간 상호작용), 퍼즈 테스트(무작위·악의적 입력)를 갖춘 상태로 넘겨져야 합니다. 탄탄한 프로젝트는 불변성 테스트도 돌립니다. "총공급량은 상한을 넘지 않는다", "사용자 잔고의 합은 항상 컨트랙트의 토큰 잔고와 같다"처럼 어떤 상황에서도 지켜져야 하는 성질을 확인하는 테스트입니다. 2024년에는 이런 테스트가 주요 프로토콜에서 기능을 망가뜨릴 수 있는 버그 몇 건을 메인넷에 올라가기 전에 잡아냈습니다.

5단계: 취약점 점수 매기기와 보고

모든 발견 사항에 순위를 매기고 수정 방안을 제시해 보고서를 개선 로드맵으로 만듭니다. 결과물은 개발자가 바로 조치할 수 있어야 쓸모가 있습니다. "검토를 고려하십시오" 같은 모호한 메모는 아무에게도 도움이 되지 않습니다.

수동 검토와 자동 도구 비교

어느 한쪽만으로는 충분하지 않습니다. 아래 표를 보면 두 방식을 섞는 하이브리드 흐름이 업계 표준이 된 이유를 알 수 있습니다.

실무적으로는 자동 도구로 코드베이스를 먼저 분류하고 의심 구역을 표시한 다음, 도구가 손을 드는 바로 그 지점에 비싼 전문가 시간을 집중하는 것이 효율적입니다.

취약점 점수 매기기: 숫자로 보는 예

전문 감사는 문제마다 영향도(악용되면 얼마나 심각한가)와 가능성(얼마나 쉽게 악용되는가)이라는 두 축으로 분류하고, 이를 심각도 점수로 바꿉니다. 간단한 모델은 두 값을 곱합니다.

• 영향도: 치명 = 5, 높음 = 4, 중간 = 3, 낮음 = 2, 정보 = 1
• 가능성: 거의 확실 = 5, 높음 = 4, 가능 = 3, 낮음 = 2, 드묾 = 1

예를 들어 출금 함수의 재진입 버그는 자금이 빠져나갈 수 있으니 영향도 5, 공격 기법이 잘 알려져 있고 구현이 쉬우니 가능성 4입니다. 점수는 5 × 4 = 20으로 치명 구간(16~25)에 들어가며, 고치기 전까지 배포를 막아야 합니다. 반면 쓰이지 않는 상태 변수는 영향도 1, 가능성 1, 점수 1로 정보 등급이며 여유 있을 때 정리하면 됩니다. 이런 숫자 틀이 있으면 팀이 겉모양 경고를 자금 탈취 결함만큼 급하게 다루는 일을 막을 수 있습니다.

감사 효과를 높이는 사전 준비

감사의 질은 감사인이 받는 자료의 질을 넘지 못합니다. 두 가지 준비만으로 비용도 줄고 놓치는 발견 사항도 줄어듭니다.

문서화: 이해할 수 없는 코드를 만난 감사인은 의도한 동작을 역으로 추적하느라 청구 시간을 쓰거나, 더 나쁘게는 잘못 짐작합니다. 명확한 NatSpec 주석, 기대 동작을 적은 명세서, 외부 연동마다의 설명이 있으면 추측 게임이 검증 작업으로 바뀝니다.

명확한 목표: "안전하게 만들어 주십시오"는 범위가 아닙니다. "대출 풀이 가격 오라클 조작과 재진입에 견디는지 확인하고, 관리자 함수의 접근 제어를 검증한다"가 범위입니다. 널리 쓰이는 OpenZeppelin 라이브러리 패턴 같은 기준에 미리 합의해 두면 양쪽이 "올바름"의 모습을 같은 기준으로 판단할 수 있습니다.

감사인이 살펴보는 대표 취약점 유형

해킹 대부분은 반복되는 몇 가지 유형에 몰려 있습니다. 이 유형을 알면 수동 검토와 도구 설정이 모두 날카로워집니다. 자세한 내용은 자주 일어나는 스마트 컨트랙트 공격 가이드에서 볼 수 있습니다.

• 재진입(Reentrancy): 외부 호출이 상태 갱신이 끝나기 전에 공격자가 다시 들어오도록 허용합니다.
• 정수 오버플로·언더플로: 산술 연산이 조용히 한 바퀴 돕니다. 최신 컴파일러의 검사로 상당 부분 줄었지만 unchecked 블록에서는 여전히 위험합니다.
• 접근 제어 누락: 소유자나 역할 제한이 없는 권한 함수입니다.
• 오라클·가격 조작: 플래시론으로 컨트랙트에 왜곡된 가격을 먹입니다.
• 선행 매매와 MEV: 가치를 빼내기 위해 트랜잭션 순서를 바꿉니다.
• 검사하지 않은 외부 호출: 반환값을 무시해 컨트랙트가 잘못된 상태에 머뭅니다.
• 러그풀을 가능하게 하는 로직: 숨겨진 발행 함수나 무제한 관리자 출금 권한입니다.

마지막 항목은 기술 문제이면서 신뢰의 신호이기도 합니다. 코드가 완벽해도 뒷문 같은 관리자 함수가 있다면 사용자에게는 안전하지 않습니다. 그래서 디앱(dApp)을 감사한다는 것은 점점 더 메모리 안전성뿐 아니라 경제 설계와 거버넌스 설계까지 확인한다는 뜻이 되고 있습니다.

위험과 함정: 감사를 보증으로 여기는 것

가장 위험한 착각은 "감사 완료"를 "안전"과 같은 말로 여기는 것입니다. 감사는 특정 버전의 코드를 특정 가정 아래에서 찍은 스냅숏일 뿐입니다. 팀이 자주 걸려 넘어지는 함정은 다음과 같습니다.

범위 밖 사각지대: 감사 범위 밖에 의존성이나 업그레이드 프록시가 있으면 공격은 감사받지 않은 문으로 들어옵니다.

감사 후 수정: 감사 뒤에 한 줄만 고쳐도 그 함수에 대한 감사 결과는 효력을 잃습니다.

경제적 공격: 상당수 자금 탈취에는 코드 버그가 없습니다. 감사에서 한 번도 모델링하지 않은 인센티브 설계를 파고듭니다.

도구 과신: 싸게 제공되는 자동 도구 전용 "감사"는 가장 중요한 고위험 논리 오류를 바로 그 지점에서 놓칩니다.

단일 감사인 편향: 한 업체의 사각지대가 그대로 운영 사고가 될 수 있습니다. 고가치 컨트랙트에는 보통 독립된 감사 두 건과 버그 바운티 프로그램이 필요합니다.

재감사 시점: 언제 다시 감사를 받아야 하나

보안은 이정표가 아니라 과정입니다. 지난 분기에 깨끗했던 컨트랙트도 업그레이드 뒤에는 그렇지 않을 수 있습니다. 새 감사를 받을 만한 계기는 다음과 같습니다.

• 중요한 코드 변경이나 새 기능을 추가한 뒤
• 대규모 메인넷 배포나 마이그레이션 전
• 고가치·핵심 컨트랙트라면 정기적으로(예: 1년마다)
• 관련된 새로운 공격 유형이 공개됐을 때. 새 기법이 나오기 전에 안전했던 코드가 그 뒤에도 안전하다는 보장은 없습니다.

재감사는 실패를 인정하는 일이 아니라 브리지를 주기적으로 다시 점검하듯 하는 정기 정비로 여기는 것이 좋습니다. 블록체인 보안 감사를 더 넓은 관점에서 보려면 블록체인 보안 감사 가이드를 참고하십시오.

COINOTAG의 관점

COINOTAG가 시장 전반의 온체인 사건을 지켜보며 반복해서 보는 패턴이 있습니다. 가장 큰 손실은 거의 언제나 처음 보는 기이한 버그에서 나오지 않습니다. "작은" 업그레이드 뒤에 건너뛴 재감사, 영구적인 인증 도장처럼 취급된 단 한 번의 감사, 그리고 어떤 정적 분석기도 잡도록 만들어지지 않은 경제 설계에서 나옵니다.

사용자에게 주는 실질적인 교훈은 이렇습니다. "OO 감사 완료" 배지만 보고 끝내지 말고, 어느 버전이 감사를 받았는지, 무엇이 범위에 들어갔는지, 보고서의 치명·높음 발견 사항이 실제로 해결됐는지, 활성 버그 바운티가 있는지를 확인하십시오. 배지는 마케팅이고, 공개되어 해결까지 확인된 보고서가 증거입니다.

개발팀이라면 지속적인 테스트와 독립 검토 두 건에 예산을 쓰는 편이 아홉 자리 금액이 걸린 해킹 한 번보다 훨씬 쌉니다. 보안 문화는 기술 관행이 아니라 전략적 투자입니다.

맺음말

스마트 컨트랙트 감사는 여러 겹으로 이루어진 작업입니다. 먼저 범위와 위협 모델을 정하고, 모든 줄을 사람이 읽고, 도구로 넓은 범위를 훑고, 집요하게 테스트와 퍼징을 하고, 마지막으로 모든 발견 사항을 심각도에 따라 점수 매겨 고칩니다. 체인 위의 코드는 나중에 패치할 수 없기 때문에 이런 엄격함은 선택 사항이 아니라 탈중앙화 애플리케이션이 신뢰를 얻는 토대입니다. 철저한 첫 감사에 꾸준한 재감사와 지속적인 테스트를 더하면, 바꿀 수 없는 코드는 약점이 아니라 진짜 보안상의 강점이 됩니다.