스마트 컨트랙트 보안 패턴은 충분한가
2025년 체계적 문헌고찰이 보여준 설계 단계의 보안 공백
블록체인 프로젝트에서 스마트 컨트랙트 보안은 흔히 감사(audit), 정적 분석, 테스트의 문제로 좁혀진다. 그러나 취약점은 코드가 작성된 뒤에만 생기는 것이 아니다. 어떤 외부 호출을 허용할지, 권한을 누가 가질지, 자금 인출을 어떤 흐름으로 처리할지 결정하는 설계 단계에서 이미 공격 표면이 정해진다.
2025년 Empirical Software Engineering에 게재된 Azimi, Golzari, Ivaki, Laranjeiro의 논문 “A systematic review on smart contracts security design patterns”는 이 문제를 다룬다. 연구진은 스마트 컨트랙트 설계 패턴을 체계적으로 정리한 뒤, 보안 패턴이 실제 취약점과 얼마나 직접 연결되는지를 OpenSCV 분류체계로 매핑했다. 논문의 결론은 단순하지만 중요하다. 보안 설계 패턴은 많이 제안되어 있지만, 알려진 취약점을 직접 겨냥하는 패턴은 매우 적다.
논문이 식별한 36개 보안 설계 패턴 가운데 OpenSCV의 특정 취약점을 직접 대상으로 삼은 것은 5개였고, 이들이 다룬 취약점은 94개 중 6개에 그쳤다.
이 결과는 “설계 패턴을 사용하면 스마트 컨트랙트가 안전해진다”는 식의 낙관론을 경계하게 한다. 패턴은 중요한 예방책이지만, 보안 전체를 대신하는 만능 해법은 아니다.
논문 기본 정보
연구진은 무엇을 조사했나
이 논문은 세 가지 연구 질문을 한다.
첫째, 문헌에는 어떤 스마트 컨트랙트 설계 패턴이 제안되어 있으며, 각 패턴의 목적과 특징은 무엇인가를 물었다. 둘째, 그중 어떤 패턴이 보안을 직접 목표로 하며, 보안 위협을 어떻게 줄이는지를 조사했다. 셋째, 보안 패턴이 알려진 스마트 컨트랙트 취약점 가운데 무엇을 실제로 다루는지를 확인했다.
검색은 2023년 2월에 수행되었다. 연구진은 Google Scholar를 중심으로 검색했으며, IEEE Xplore, ACM Digital Library, ScienceDirect 등에 수록된 연구도 검색 결과에 포함될 수 있도록 검색 범위를 구성했다. 검색어에는 blockchain, Ethereum, smart contract와 security patterns, software patterns, design patterns 등의 조합이 사용됐다.
초기 검색 결과는 977편이었다. 중복 제거 후 917편이 남았고, 제목·초록·전문을 차례로 검토한 끝에 58편을 최종 분석 대상으로 선정했다. 비영어 문헌과 동료평가를 거치지 않은 문헌은 제외했다. 최종 분석자료는 학술지 논문 7편, 학술대회 논문 35편, 워크숍 논문 9편, 학위논문 7편으로 구성됐다.
여기서 반드시 짚어야 할 시간적 한계가 있다. 검색 자체는 2023년에 끝났고, 논문은 2025년에 출판됐다. 따라서 2023년 2월 이후 등장한 새로운 공격기법이나 설계 패턴을 체계적으로 포괄한 연구로 읽어서는 안된다. 다만 연구진이 2025년에 분석 결과를 출판했고 보충자료를 공개했다는 점에서, 2025년 시점의 보안 설계 패턴 지형을 파악하는 기준점으로는 가치가 있다.
144개 패턴을 네 가지 큰 범주로 정리하다
연구진은 문헌에서 확인한 스마트 컨트랙트 설계 패턴을 통합하고 이름이 다른 유사 패턴을 정리해 총 144개의 패턴으로 분류했다. 이들은 네 가지 상위 범주로 묶였다.
가장 많은 패턴이 Control에 속한 것은 스마트 컨트랙트가 단순한 데이터 저장소가 아니라 상태와 거래 흐름을 통제하는 프로그램이기 때문이다. Performance에서는 가스 소비 최적화가 큰 비중을 차지했다. 반면 보안 범주에서는 접근통제가 가장 많은 패턴을 보유했고, 위험 완화와 안전한 외부 호출이 그 뒤를 이었다.
이 분류가 주는 첫 번째 시사점은 보안이 독립된 기능이 아니라 제어 흐름과 성능 설계에 얽힌 속성이라는 점이다. 예를 들어 외부 호출을 줄이면 가스 비용을 낮출 수 있지만, 동시에 재진입 공격의 노출 지점도 줄어들 수 있다. 반대로 가스 최적화만을 위해 호출과 상태 변경을 지나치게 압축하면 검증 가능성과 가독성이 떨어질 수 있다.
36개 보안 패턴, 그러나 직접 대응은 5개
144개 패턴 중 보안 설계 패턴으로 분류된 것은 36개였다. 연구진은 이들을 10개 하위 범주로 나누었습니다. 대표적인 범주는 접근통제, 위험 완화, 안전한 외부 호출, 무결성, 프라이버시, 흐름 제어, 안전한 산술 연산이다.
하지만 보안 패턴의 존재와 취약점 대응의 직접성은 서로 다른 문제다. 연구진은 OpenSCV라는 스마트 컨트랙트 취약점 분류체계를 기준으로 패턴과 취약점을 연결했다. OpenSCV는 94개 알려진 취약점을 8개 상위 범주로 정리한다. 여기에는 안전하지 않은 외부 호출, 잘못 처리된 이벤트, 가스 고갈, 잘못된 크레딧 전송, 프로그래밍 관행·언어 취약점, 잘못된 제어 흐름, 산술 문제, 부적절한 접근통제가 포함된다. 매핑 결과는 다음과 같다.
94개 중 6개는 약 6.4%다. 다만 이 숫자를 “나머지 88개 취약점은 보안 패턴으로 절대 대응할 수 없다”는 뜻으로 해석해서는 안된다. 논문은 패턴이 취약점의 특정 항목을 직접 대상으로 삼는지, 아니면 더 넓은 보안 범주와 관련되는지를 구분했다. 예를 들어 Pull Payment, Limit External Calls, Emergency Stop, Rate Limit, Multi-signature는 위험을 줄이는 데 유용하지만, 연구진의 매핑 기준에서 특정 OpenSCV 취약점 하나에 직접 연결되지는 않았다.
따라서 정확한 해석은 이렇다. 현재 문헌의 보안 패턴은 실무적으로 유용한 방어 전략을 제공하지만, 알려진 취약점 전체를 체계적으로 커버할 만큼 정교하게 정의되거나 검증되지는 않았다.
핵심 패턴을 쉽게 이해하기
1. Checks-Effects-Interactions: 외부 호출은 마지막에
재진입(reentrancy)은 외부 컨트랙트를 호출하는 동안 공격자가 원래 컨트랙트의 함수를 다시 호출해 상태가 완전히 갱신되기 전의 허점을 이용하는 공격이다.
Checks-Effects-Interactions 패턴은 함수의 순서를 고정한다. 먼저 입력값, 권한, 현재 상태를 확인한다. 다음으로 잔액이나 거래 상태 같은 내부 상태를 변경한다. 마지막으로 외부 컨트랙트 호출이나 자금 전송을 수행한다.
이 순서를 지키면 외부 호출이 발생할 때 내부 상태가 이미 일관된 상태에 도달해 재진입 공격의 가능성을 낮출 수 있다. 부동산 토큰화에서 투자자 환급이나 배당금을 전송하는 함수라면, 먼저 배당 가능 잔액과 청구 상태를 기록한 뒤 외부 토큰 전송을 실행하는 방식으로 적용할 수 있다.
2. Mutex: 실행 중인 함수에 다시 들어오지 못하게 하기
Mutex는 함수 실행 중 잠금 상태를 설정한다. 잠금이 설정된 동안 같은 흐름으로 함수가 다시 호출되면 거래를 중단한다. 이 방식은 재진입 방어에 직관적이지만, 잠금 변수를 잘못 관리하면 정상 거래까지 막거나 영구적으로 잠긴 상태를 만들 수 있다.
따라서 Mutex를 사용한다고 끝나는 것이 아니다. 잠금 설정과 해제의 모든 경로를 테스트해야 하며, 실패·예외 상황에서도 잠금이 적절히 해제되는지 검증해야 한다.
3. Pull Payment: 지급자가 보내지 말고 수령자가 청구하게 하기
Push Payment에서는 컨트랙트가 상대방에게 직접 자금을 보낸다. 이때 수신자 컨트랙트의 코드가 호출되면서 재진입이나 전송 실패 문제가 생길 수 있다.
Pull Payment에서는 지급 예정 금액을 먼저 기록하고, 수령자가 별도의 인출 함수를 호출해 자금을 가져간다. 논문은 이 패턴을 안전한 외부 호출 범주에 포함하지만, OpenSCV의 특정 취약점 하나에 직접 매핑하지는 않았다. 즉, 패턴의 실무적 가치와 취약점 분류체계상의 직접성은 구분해야 한다.
4. Randomness: 블록체인에서 난수는 생각보다 어렵다
블록체인 노드는 같은 입력에 대해 같은 결과를 계산해야 하므로, 일반적인 프로그램처럼 예측 불가능한 난수를 쉽게 만들 수 없다. 블록 해시나 타임스탬프를 단순히 난수처럼 사용하면 검증자나 공격자가 결과를 예측하거나 일부 조작할 수 있다.
논문은 오라클이나 별도의 난수 생성 메커니즘을 활용하는 Randomness 패턴을 설명한다. 추첨, 경매, 게임처럼 결과의 공정성이 중요한 서비스에서 특히 중요하다. 부동산 토큰화에서 무작위 배정이 사용된다면, 어떤 난수원이 사용됐고 누가 결과를 검증할 수 있는지까지 설계 문서에 남겨야 한다.
5. SafeMath: 산술 연산의 경계를 검사하기
정수 오버플로는 값이 표현 가능한 최대치를 넘어 다시 작은 값으로 돌아가는 현상이다. 언더플로는 반대로 최소값 아래로 내려가 큰 값처럼 처리되는 문제다. 토큰 잔액, 지분율, 수수료, 배당 계산에서 이런 오류가 발생하면 재무 상태가 손상될 수 있다.
SafeMath는 산술 연산 전후에 범위를 확인하고, 문제가 생기면 거래를 되돌리는 방식으로 이 위험을 줄인다. 최신 Solidity 컴파일러의 기본 검사 기능이 일부 상황에서 이 문제를 완화하더라도, 컴파일러 버전과 연산 맥락을 확인하지 않은 채 오래된 라이브러리 패턴을 복사해서는 안된다.
6. Ownership: 권한의 중심을 명시하기
Ownership은 관리자나 소유자만 실행할 수 있는 기능을 명확히 분리한다. 발행, 일시정지, 수수료 변경, 업그레이드 같은 기능을 특정 권한에 묶는 데 유용하다.
그러나 단일 소유자 계정은 또 다른 위험을 만들 수 있다. 개인키가 탈취되거나 운영자가 악의적으로 행동하면 강력한 권한이 한 번에 악용될 수 있기 때문이다. 따라서 고가 자산을 다루는 서비스에서는 멀티시그, 시간 지연, 역할 기반 권한, 비상 중지와 함께 설계해야 한다. 논문도 Ownership을 Owner Manipulation 취약점과 연결하지만, 실제 운영권한의 분산까지 자동으로 보장한다고 말하지는 않는다.
패턴의 한계: “사용했다”와 “검증됐다”는 다르다
이 논문의 가장 중요한 기여는 패턴 목록 자체보다 패턴과 취약점 사이의 연결이 약하다는 사실을 보여준 것이다.
첫째, 많은 패턴은 이름과 설명은 존재하지만, 어떤 취약점을 어느 조건에서 줄이는지 형식적으로 검증되지 않았다. 예를 들어 “접근을 제한한다”는 설명만으로는 권한 검사가 모든 민감 함수를 포괄하는지, 권한 변경 절차가 안전한지 알 수 없다.
둘째, 패턴 명칭이 문헌마다 달랐다. 동일한 아이디어가 서로 다른 이름으로 제안되거나, 같은 이름이 서로 다른 구현을 가리키는 문제가 있었다. 연구진은 이름을 통합하고 유사 개념을 정리했지만, 이 과정에는 연구자의 판단이 개입된다.
셋째, 패턴은 모든 종류의 보안을 다루지 않는다. 논문의 매핑에서는 OpenSCV의 “Mishandled Events”와 “Gas Depletion” 상위 범주가 어떤 패턴에도 직접 대응하지 않았다. 또한 오래된 컴파일러 버전처럼 패턴보다 빌드 설정과 개발 프로세스가 더 적합한 대응 수단인 문제도 있다.
넷째, 스마트 컨트랙트는 단독 코드가 아니다. 오라클, 브리지, 지갑, 프런트엔드, 키 관리, 중앙화된 관리 콘솔과 연결된다. 컨트랙트 내부에서 Checks-Effects-Interactions를 올바르게 사용해도, 잘못된 가격 오라클이나 탈취된 관리자 키가 있으면 시스템 전체가 안전해지지 않는다.
부동산 토큰화에 적용한다면
부동산 토큰화는 부동산의 소유권이나 수익권을 토큰으로 표현하고, 발행·양도·배당·환매 등의 과정을 스마트 컨트랙트와 연결하는 구조다. 따라서 일반적인 DeFi 서비스보다 법적 권리, 투자자 자격, 자산 평가, 현금흐름, 개인정보가 함께 얽힌다.
이 논문의 결과를 적용할 때는 다음과 같은 순서가 현실적이다.
먼저 토큰의 법적 권리와 스마트 컨트랙트의 상태를 분리해 정의해야 한다. 컨트랙트가 기록하는 토큰 잔액이 곧바로 등기부상 소유권이나 수익권의 완전한 이전을 의미하는 것은 아니다. 법적 문서와 온체인 상태 사이의 불일치를 어떻게 해결할지 별도로 설계해야 한다.
그다음 자금 흐름을 상태 머신으로 작성해야 한다. 예를 들어 “청약 가능 → 청약 완료 → 자금 예치 → 발행 → 배당 가능 → 배당 청구 → 환매” 같은 상태를 정의하고, 각 상태에서 실행 가능한 함수와 호출 주체를 제한해야 한다. Guard Check, Ownership, Checks-Effects-Interactions, Pull Payment를 이 흐름에 대응시킬 수 있다.
외부 의존성도 목록화해야 한다. 가격 오라클, 투자자 인증 시스템, 결제 시스템, 수탁기관, 브리지, 토큰 전송 컨트랙트가 각각 실패하거나 악용될 수 있다. 외부 호출을 최소화하고, 실패 시 거래를 되돌릴지 보류할지, 비상 중지를 발동할지 사전에 정해야 한다.
마지막으로 패턴을 보안 통제의 출발점으로만 사용해야 한다. 설계 패턴 적용 후에도 단위 테스트, 퍼즈 테스트, 정적·동적 분석, 형식 검증, 독립 보안감사, 키 관리, 모니터링과 사고 대응 절차가 필요하다. 논문이 보여주는 6/94라는 결과는 바로 이 점을 강조한다. 패턴 카탈로그는 보안 프로그램 전체가 아니라 보안 프로그램의 한 계층이다.
개발팀을 위한 실무 점검표
결론: 보안 패턴의 다음 과제는 “더 많은 목록”이 아니다
Azimi 등의 연구는 스마트 컨트랙트 보안 설계 패턴 연구가 양적으로는 성장했지만, 취약점 대응의 추적성과 검증 가능성은 아직 부족하다고 진단한다. 144개 설계 패턴과 36개 보안 패턴이 존재해도, 구체적인 OpenSCV 취약점에 직접 대응하는 패턴은 5개에 그쳤다.
따라서 앞으로 필요한 것은 패턴의 단순한 추가가 아니다. 각 패턴이 어떤 공격 조건을 가정하는지, 어떤 보안 속성을 보장하는지, 어떤 경우에는 작동하지 않는지, 실제 코드와 테스트에서 어떻게 검증되는지를 함께 기록해야 한다. 연구진은 취약점 탐지 도구와 설계 패턴의 연결, 취약점에 직접 대응하는 새로운 패턴의 개발, 연구자와 실무자가 공동으로 관리하는 최신 패턴 저장소를 후속 과제로 제안한다.
부동산 토큰화와 같은 고가 자산 분야에서는 이 결론이 특히 중요하다. “감사 완료” 또는 “보안 패턴 적용”이라는 문구만으로는 충분하지 않다. 자산의 법적 권리, 토큰 상태, 현금흐름, 권한, 외부 데이터, 운영 절차를 하나의 위협 모델로 연결하고, 각각의 통제가 어떤 위험을 줄이는지 증명할 수 있어야 한다.
스마트 컨트랙트 보안의 성숙도는 패턴을 몇 개 사용했는지가 아니라, 패턴과 위협·취약점·테스트·운영통제를 얼마나 정확히 연결했는지로 평가해야 한다.
