스마트 계약 보안이 일반 소프트웨어 보안과 다른 이유는 무엇입니까?
스마트 계약 보안은 코드가 공개되어 있고, 자금을 직접 보관하는 경우가 많으며, 대개 배포 후에는 변경할 수 없다는 점에서 다릅니다. 웹 앱의 버그는 하룻밤 사이에 수정할 수 있지만, 스마트 계약의 버그는 코드를 읽는 누구나 발견할 수 있고 팀이 잠에서 깨기도 전에 악용될 수 있습니다. Ethereum.org는 스마트 계약 결함으로 인한 손실을 10억 달러 이상으로 추산하며, 초기 사례로 2016년 DAO 해킹을 제시합니다.
네 명으로 구성된 가상 개발 스튜디오인 라크스퍼 랩스를 예로 들어 보겠습니다. 이곳은 회원들이 자금을 입금하고 자신의 지분을 인출하는 간단한 공동 저축 시스템을 개발합니다. 개발자인 코피는 배포 전 검토 메모를 남깁니다. 'withdraw는 자금을 전송한 뒤 잔액을 0으로 설정함. setFee는 공개 상태이며 나중에 제한할 예정. 튜토리얼의 오래된 컴파일러 버전을 사용 중. 보상 토큰 가격을 소규모 거래소 풀 하나에서 읽어 옴. 테스트: 입금 + 출금을 수동으로 한 번 시도했으며 작동함'. 각 항목은 이미 알려진 취약점 유형에 해당합니다.
스마트 계약에서 가장 흔한 취약점은 무엇입니까?
가장 흔한 스마트 계약 취약점은 접근 제어 결함, 가격 오라클 조작, 논리 오류, 입력값 검증 누락, 재진입 공격이며, 이들은 2025년 OWASP Smart Contract Top 10에서 상위에 올라 있습니다. Ethereum.org도 같은 핵심 유형을 다룹니다.
재진입
계약이 자체 기록을 갱신하기 전에 자금을 보내거나 다른 계약을 호출합니다. 악의적인 수신자는 이전 잔액이 그대로 표시되는 동안 다시 호출해 재차 출금합니다. 잔액을 0으로 설정하기 전에 자금을 지급하는 Kofi의 withdraw 함수가 전형적인 사례입니다. 일반적인 해결책은 먼저 상태를 갱신하고 다른 계약과의 상호작용은 마지막에 수행하는 것으로, 흔히 검사, 상태 변경, 상호작용 순서라고 합니다.
접근 제어
누구나 호출할 수 있는 민감한 함수입니다. 코피의 공개 setFee 함수는 외부인 누구나 수수료를 변경할 수 있게 합니다. Ethereum.org는 소유자 역할, 역할 기반 접근 제어, 다중 서명 승인 등의 방식을 설명합니다.
정수 오버플로와 언더플로
연산 결과가 한계를 넘으면 값이 순환하여, 잔액이 0보다 작아지면 거대한 숫자로 바뀌는 현상입니다. Ethereum.org에 따르면 Solidity 0.8.0 이상에서는 기본적으로 이런 연산을 거부하지만, 이전 코드는 명시적인 검사가 필요합니다. 코피가 사용하는 오래된 컴파일러가 중요한 이유입니다.
오라클 조작
공격자가 가격을 움직일 수 있는 거래량이 적은 단일 시장에서 가격을 읽어 오는 방식입니다. 공격에는 하나의 거래 안에서 빌리고 갚는 대출인 플래시 론이 자주 사용됩니다. 견고한 설계는 탈중앙화 오라클이나 시간 평균 가격을 사용합니다.
논리 및 유효성 검증 오류
의도한 설계와 맞지 않는 규칙이나 금액이 0인 경우 또는 예상치 못한 주소처럼 검증을 전혀 하지 않는 입력값.
팀에서는 스마트 계약을 어떻게 테스트하고 감사합니까?
어느 한 가지 방법으로는 모든 문제를 찾아낼 수 없으므로, 팀은 스마트 계약을 여러 단계로 테스트하고 점검합니다. 자동화 테스트, 분석 도구, 테스트 네트워크 배포, 독립적인 검토를 진행하며, 상당한 가치의 자산을 보관하는 계약에는 외부 감사와 버그 포상 제도도 활용합니다.
1. 단위 테스트 및 속성 기반 테스트
호출한 함수를 다시 호출하는 수신 객체와 같은 공격적 상황을 포함하여 모든 함수의 테스트를 작성합니다. 퍼징은 수천 개의 무작위 입력을 자동으로 시험합니다.
2. 정적 분석
Ethereum.org는 코드에서 알려진 위험 패턴을 탐지하는 Slither, Mythril, Aderyn 등의 도구를 소개합니다.
3. 네트워크를 테스트합니다
메인넷에 배포하기 전에 공개 테스트넷에 배포합니다. Ethereum.org는 애플리케이션과 스마트 계약 개발에 Sepolia를 권장합니다. 테스트넷 이더는 실제 가치를 갖지 않도록 설계되어 있으므로 실수해도 비용이 들지 않습니다.
4. 동료 검토 및 감사를 거친 라이브러리
접근 제어를 처음부터 직접 작성하기보다 버전 관리, 모든 변경 사항에 대한 독립적인 검토, OpenZeppelin Contracts처럼 충분히 검토된 라이브러리를 사용합니다.
5. 감사, 포상금 및 모니터링
독립 감사는 검토를 강화하지만, ethereum.org에서 설명하듯 모든 버그를 찾아내지는 못합니다. 버그 포상금, 긴급 일시 중지 기능, 이벤트 모니터링으로 나머지 위험에 대응합니다.
미흡한 보안 검토와 개선된 보안 검토는 어떻게 다릅니까?
미흡한 검토: '입금과 출금을 수동으로 테스트했으며 정상 작동합니다. 배포 준비가 완료되었습니다.' 정상 경로 테스트는 정직한 사용자가 사용할 때 컨트랙트가 작동한다는 점을 보여 줍니다. 하지만 공격자는 정직한 사용자가 아닙니다.
개선한 검토: 재진입: withdraw는 이제 송금 전에 잔액을 0으로 설정하며, 테스트에서는 악의적인 수신자 계약으로 재호출을 시도합니다. 접근 제어: 감사를 받은 라이브러리의 소유자 역할만 setFee를 실행하도록 제한하고, 권한이 없는 사용자의 호출이 실패하는지 테스트합니다. 컴파일러: 오버플로 검사가 활성화되도록 최신 0.8 버전으로 업그레이드했습니다. 오라클: 단일 풀 가격을 탈중앙화된 가격 피드로 대체하고, 급격한 변동에 대한 타당성 한도를 추가했습니다. 테스트: 단위 테스트, 퍼징 실행, 정적 분석을 수행하고 모든 발견 사항을 설명한 뒤, Sepolia에서 2주 동안 동료가 취약점을 찾아 공격을 시도하도록 했습니다. 실제 자금을 받기 전에 외부 감사를 받도록 일정을 잡았습니다.
스마트 계약 보안에서 흔히 하는 실수는 무엇입니까?
가장 흔한 실수는 모든 호출자가 정직하다고 가정하고 정상적인 실행 경로만 테스트하는 것입니다. 그 밖에도 나중에 제한하겠다며 관리자 기능을 열어 두거나, 오래된 컴파일러를 사용하는 튜토리얼 코드를 복사하거나, 가격 출처 하나만 신뢰하거나, 감사를 보증으로 여기거나, 테스트넷 단계를 건너뛰거나, 일시 중지 또는 업그레이드 계획 없이 배포하는 실수가 있습니다.
Tosheo.ai에서 이 수업은 어디에 해당합니까?
이 수업은 블록체인 범주와 블록체인 과정에 속하는 코드 수업입니다. 이 무료 페이지에서는 각 단계를 글로 설명합니다. 실제 계약 코드를 검토하고 수정하며 테스트 네트워크에서 시험하는 전체 실습 버전은 가입 후 선택할 수 있는 코드 트랙에 포함되어 있습니다. 기초가 낯설다면 스마트 계약 설명부터 시작하면 됩니다. Tosheo.ai는 전일제 집중 교육 과정도, 전문 감사 자격 과정도 아니며, 여기에 있는 어떤 내용도 투자 조언이 아닙니다. 실제 자산을 보유하는 계약에는 전문가의 감사가 필요합니다.
출처와 범위
ethereum.org, 스마트 계약 보안 (확인일: 19 October 2026) ↗