LLM이 만든 스마트 계약 보안 현황 분석

초록

본 논문은 ChatGPT, Gemini, Claude Sonnet 등 최신 대형 언어 모델(LLM)이 자동 생성한 Solidity 스마트 계약을 대상으로 알려진 취약점 집합을 적용해 체계적인 보안 평가를 수행한다. 실험 결과, 문법적으로는 정상이나 실제 배포 시 심각한 보안 결함이 빈번히 발견되었으며, 모델별·도메인별로 공통적인 취약 패턴이 도출된다. 논문은 이러한 위험을 완화하기 위한 위협 모델, 취약점 분류 체계, 그리고 실무 적용 가능한 방지·감시 가이드라인을 제시한다.

상세 분석

이 연구는 LLM이 생성한 스마트 계약의 보안성을 정량·정성적으로 평가하기 위해 다단계 실험 파이프라인을 설계하였다. 먼저, 개발자가 흔히 사용하는 자연어 프롬프트(예: ERC‑20 토큰, 거버넌스 투표, 마켓플레이스 등)를 5개~10개 도메인에 걸쳐 30여 개 정도 정의하고, 각 프롬프트를 세 모델에 동일하게 전달하였다. 모델은 블랙박스 형태로 호출되며, 반환된 Solidity 코드는 자동 컴파일 후 기본 기능 테스트를 통과하도록 최소한의 유닛 테스트를 적용한다. 이후, 기존 스마트 계약 취약점 데이터베이스(예: SWC‑ID, SmartCheck, Slither)와 최신 연구에서 제시된 30여 개의 대표적 취약점(재진입, 정수 오버플로, 권한 검증 누락, 프록시 업그레이드 오류, 타임스탬프 의존 등)을 매핑해 정적·동적 분석을 수행하였다.

분석 결과, 세 모델 모두 평균 85 % 이상의 코드가 컴파일 성공했지만, 평균 3.7개의 심각한 취약점이 포함되었다. 특히 재진입 취약은 68 %의 계약에서 발견되었으며, 이는 LLM이 call.value와 같은 저수준 함수 호출을 사용할 때 자동으로 checks‑effects‑interactions 패턴을 적용하지 못하는 경향에서 기인한다. 또 다른 빈번한 결함은 접근 제어 로직의 누락으로, onlyOwner와 같은 modifier가 정의되었지만 실제 함수에 적용되지 않거나, msg.sender 검증이 잘못된 형태로 삽입되는 경우가 다수였다. 오버플로와 언더플로는 Solidity 0.8.x에서 자동 체크가 활성화됨에도 불구하고, LLM이 버전 선언을 누락하거나 unchecked 블록을 부적절하게 삽입하면서 회피되는 사례가 관찰되었다.

모델별 차이를 살펴보면, GPT‑4.1 기반 ChatGPT는 코드 스타일이 가장 일관되고 최신 Solidity 표준을 따르는 편이었지만, 복잡한 로직(예: 다중 단계 경매)에서 논리적 오류가 자주 발생했다. Gemini‑2.5는 함수 이름과 변수 선언을 과도하게 중복시키는 경향이 있었으며, 이는 가스 비용 최적화와 보안 검증을 복잡하게 만든다. Claude Sonnet‑4.5는 프롬프트에 명시된 요구사항을 충실히 구현하려다 보니, 불필요한 require 문을 남발해 가스 소모를 증가시키고, 때때로 조건식이 역전되는 버그를 초래했다.

논문은 이러한 패턴을 ‘LLM‑Induced Vulnerability Taxonomy’라는 7계층 구조로 정리하였다: (1) 기본 구조 결함, (2) 접근 제어 누락, (3) 재진입 위험, (4) 수학 연산 오류, (5) 상태 변수 초기화 미비, (6) 외부 호출 관리 부재, (7) 가스 최적화 부실. 각 계층은 모델·프롬프트·도메인에 따라 발생 빈도가 달라지며, 특히 복합 비즈니스 로직을 요구하는 도메인(거버넌스, 마켓플레이스)에서 다중 계층 결함이 겹쳐 나타난다.

위협 모델에서는 ‘자동 생성 → 최소 테스트 통과 → 직접 배포’라는 흐름을 가정하고, 공격자는 계약 배포 직후 취약점을 악용해 자금 탈취, 권한 상승, 서비스 거부 등을 수행할 수 있음을 시나리오별로 제시한다. 이를 방지하기 위한 실무 가이드라인으로는 (1) LLM 출력 후 반드시 정적·동적 분석 도구와 수동 코드 리뷰를 병행, (2) 프롬프트에 보안 요구사항(예: nonReentrant modifier 명시)을 명시적으로 포함, (3) 최신 Solidity 버전과 컴파일러 옵션을 강제, (4) 자동화된 테스트 스위트를 확대하여 경계 조건을 검증, (5) 모델 별 취약점 패턴을 사전 학습해 프롬프트 설계에 반영, (6) 배포 전 테스트넷에서 포괄적인 펜테스팅 수행, (7) 계약 업그레이드 가능한 프록시 구조 사용 시 보안 검증 로직을 추가하는 것을 권고한다.

결론적으로, LLM이 제공하는 생산성 향상은 무시할 수 없지만, 현재 수준의 모델은 스마트 계약이라는 고위험 환경에 바로 적용하기엔 충분히 안전하지 않으며, 체계적인 보안 검증 파이프라인과 개발자 교육이 필수적이다.