블록체인은 거래내역을 여러 참여자가 검증하고 기록하기 때문에 일반적으로 위변조가 어렵다고 알려져 있습니다.

그런데 뉴스에서는 종종

“디파이 프로토콜 해킹”

“스마트컨트랙트 취약점으로 수백억원 피해”

같은 소식을 접하게 됩니다.

여기에서 한 가지 의문이 생깁니다.

블록체인이 안전하다면 스마트컨트랙트는 어떻게 해킹되는 걸까요?

핵심은 블록체인 자체와 블록체인 위에서 실행되는 프로그램을 구분하는 것입니다.

스마트컨트랙트는 블록체인 위에서 자동으로 실행되는 프로그램입니다. 프로그램인 만큼 코드 작성이나 설계 과정에서 실수가 발생할 수 있고, 공격자는 그 허점을 이용할 수 있습니다.

특히 스마트컨트랙트는 한 번 배포하면 수정이 어렵거나 업그레이드 구조가 복잡할 수 있고, 실제 암호화폐 자산을 직접 관리하는 경우가 많기 때문에 작은 코드 오류도 큰 금융피해로 이어질 수 있습니다. Ethereum 공식 보안 가이드 역시 스마트컨트랙트가 큰 규모의 자산을 통제하며, 배포 이후 결함 수정이 쉽지 않고 탈취된 자산을 회수하기도 어렵다는 점을 강조합니다.

이번 글에서는 스마트컨트랙트 해킹이 어떤 구조로 발생하는지와 함께 대표적인 공격방식 7가지를 쉽게 알아보겠습니다.

대표적으로 알아둘 7가지

1. 접근제어 취약점
2. 재진입 공격
3. 가격 오라클 조작
4. 플래시론을 이용한 공격
5. 비즈니스 로직 오류
6. 외부 호출 검증 실패
7. 업그레이드·프록시 취약점

스마트컨트랙트는 무엇일까?

스마트컨트랙트는 일정한 조건이 충족되면 자동으로 실행되는 블록체인 프로그램입니다.

예를 들어 간단한 대출 프로토콜을 생각해보겠습니다.

사용자가 1 ETH를 담보로 맡깁니다.

스마트컨트랙트는 ETH 가격을 확인합니다.

담보가 충분하다면 일정 금액의 스테이블코인을 빌려줍니다.

모든 과정이 코드에 의해 자동으로 실행될 수 있습니다.

은행 직원이 직접 승인하지 않아도 미리 작성된 프로그램이 조건을 확인하고 거래를 처리하는 것입니다.

그렇다면 스마트컨트랙트 해킹이란 무엇일까?

스마트컨트랙트 해킹이라고 해서 항상 블록체인 자체를 뚫는 것은 아닙니다.

많은 경우 공격자는 스마트컨트랙트가 원래 의도하지 않았던 방식으로 작동하도록 코드나 경제구조의 허점을 이용합니다.

예를 들어 개발자는

“한 사람은 자신의 잔액만 한 번 출금할 수 있다.”

라고 생각하고 코드를 작성했을 수 있습니다.

하지만 실제 코드 실행순서에 문제가 있어 잔액이 차감되기 전에 출금함수를 여러 번 호출할 수 있다면 공격자는 같은 돈을 반복해서 꺼낼 수 있습니다.

블록체인은 이 거래를 거부하지 않습니다.

코드상 허용된 거래이기 때문입니다.

이것이 스마트컨트랙트 보안의 중요한 특징입니다.

1. 접근제어 취약점

첫 번째는 Access Control, 접근제어 취약점입니다.

스마트컨트랙트에는 일반 사용자에게 허용해서는 안 되는 기능이 있을 수 있습니다.

예를 들어

• 새로운 토큰 발행
• 프로토콜 수수료 변경
• 관리자 변경
• 사용자 자금 이동
• 스마트컨트랙트 업그레이드
• 긴급 정지

등입니다.

이런 기능은 관리자나 특정 권한을 가진 주소만 실행할 수 있어야 합니다.

그런데 코드가 권한을 제대로 확인하지 않으면 일반 사용자가 관리자 기능을 호출할 수 있습니다.

OWASP Smart Contract Top 10 2026에서도 접근제어 취약점을 가장 중요한 위험 범주 중 하나로 분류하고 있습니다. Ethereum 역시 민감한 함수에는 소유자 또는 역할 기반의 접근제어를 적용해야 한다고 설명합니다.

실제 상황으로 생각하면

어떤 토큰 스마트컨트랙트에

mint()

라는 함수가 있다고 가정하겠습니다.

이 함수는 원래 관리자만 사용할 수 있어야 합니다.

하지만 권한검사가 누락되어 누구나 호출할 수 있다면 공격자가

100만 개,

1억 개,

10억 개

의 토큰을 마음대로 발행할 수도 있습니다.

시장에 엄청난 토큰이 풀리면 기존 보유자의 자산가치가 크게 훼손될 수 있습니다.

왜 위험할까?

접근제어 취약점은 단순한 오류 하나로 프로토콜 전체의 통제권이 넘어갈 수 있다는 점에서 매우 위험합니다.

특히 관리자 권한이나 업그레이드 권한이 탈취되면 공격자가 스마트컨트랙트 자체의 작동방식을 변경할 수도 있습니다.

2. 재진입 공격

두 번째는 유명한 Reentrancy Attack, 재진입 공격입니다.

재진입 공격은 스마트컨트랙트가 외부 주소로 자산을 보내는 과정에서 내부 상태를 완전히 업데이트하기 전에 상대방이 다시 같은 함수를 호출하면서 발생할 수 있습니다.

Ethereum 공식 보안 가이드는 재진입을 외부 컨트랙트에 제어권이 넘어간 사이 취약한 함수를 다시 호출하는 공격으로 설명합니다.

간단한 예

사용자 A의 예치금이

1 ETH

라고 가정하겠습니다.

정상적인 출금 과정은 다음과 같아야 합니다.

1. 사용자의 잔액 확인
2. 사용자의 잔액을 0으로 변경
3. 1 ETH 전송

그런데 개발자가 순서를 잘못 작성해

1. 잔액 확인
2. 1 ETH 전송
3. 잔액을 0으로 변경

하도록 만들었다고 가정해보겠습니다.

2번과 3번 사이에 공격자의 스마트컨트랙트가 다시 출금함수를 호출할 수 있다면 어떻게 될까요?

잔액은 아직 1 ETH로 기록되어 있습니다.

따라서 다시 1 ETH를 인출할 수 있습니다.

이 과정을 반복하면 공격자가 실제 예치금보다 훨씬 많은 자산을 가져갈 수 있습니다.

어떻게 방지할까?

대표적인 방어방법 중 하나가

Checks → Effects → Interactions

패턴입니다.

즉,

먼저 조건을 확인하고,

그다음 내부 상태를 변경한 뒤,

마지막으로 외부 컨트랙트와 상호작용하는 방식입니다.

재진입 방지용 잠금장치를 사용하는 방법도 있습니다. Ethereum은 이러한 방식을 대표적인 재진입 완화책으로 소개합니다.

3. 가격 오라클 조작

세 번째는 Price Oracle Manipulation, 가격 오라클 조작입니다.

블록체인은 기본적으로 외부 세계의 정보를 직접 알지 못합니다.

예를 들어 스마트컨트랙트가

ETH가 현재 얼마인지,

BTC가 얼마인지,

금 가격이 얼마인지

알기 위해서는 외부 가격정보가 필요합니다.

이 정보를 전달하는 시스템을 **오라클(Oracle)**이라고 합니다.

왜 문제가 발생할까?

어떤 대출 프로토콜이 특정 DEX 한 곳의 순간가격만 이용한다고 가정해보겠습니다.

공격자가 대량으로 해당 토큰을 사고팔아 짧은 시간 동안 가격을 왜곡할 수 있다면 스마트컨트랙트가 잘못된 가격을 정상가격으로 받아들일 수 있습니다.

예를 들어 실제 시장가격은

1 토큰 = $100

인데 공격자가 특정 유동성 풀에서 잠시

$200

으로 만든다고 가정해보겠습니다.

대출 프로토콜이 이 가격을 그대로 사용한다면 공격자는 실제 가치보다 훨씬 높은 담보가치를 인정받아 과도한 대출을 받을 수 있습니다.

가격이 정상화되면 프로토콜에는 부실이 남을 수 있습니다.

OWASP의 2026 스마트컨트랙트 위험 목록에서도 가격 오라클 조작은 주요 공격 범주로 분류됩니다.

4. 플래시론을 이용한 공격

네 번째는 Flash Loan–Facilitated Attack입니다.

플래시론은 하나의 블록체인 거래 안에서

담보 없이 대출 → 사용 → 상환

을 모두 완료하는 구조입니다.

거래 마지막에 대출금을 갚지 못하면 전체 거래가 취소됩니다.

플래시론 자체는 공격기법이 아닙니다.

정상적인 차익거래나 자본효율을 높이는 데 사용할 수도 있습니다.

문제는 공격자가 플래시론으로 매우 큰 자금을 순간적으로 확보해 다른 취약점을 확대할 수 있다는 점입니다.

OWASP는 2026 분류에서 플래시론이 가격·로직·산술 취약점 등을 대규모 손실로 확대하는 수단이 될 수 있다고 설명합니다.

실제 구조를 단순화하면

공격자가 순간적으로

1억 달러

상당의 자금을 빌렸다고 가정해보겠습니다.

그 돈으로 특정 DEX의 토큰가격을 크게 움직입니다.

가격 오라클이 조작된 가격을 읽습니다.

공격자는 비정상적으로 높은 담보가치를 이용해 다른 프로토콜에서 자금을 빌립니다.

마지막으로 플래시론을 상환하고 차익을 남깁니다.

모든 과정이 단 하나의 거래 안에서 발생할 수도 있습니다.

핵심은 플래시론 자체가 아니다

중요한 점은

플래시론 = 해킹

이 아니라는 것입니다.

플래시론은 공격자가 큰 자본을 일시적으로 확보할 수 있게 해주는 도구입니다.

실제 원인은 가격 오라클 취약점이나 비즈니스 로직 오류 등 다른 문제인 경우가 많습니다.

5. 비즈니스 로직 오류

다섯 번째는 Business Logic Vulnerability, 비즈니스 로직 취약점입니다.

이것은 코드 문법이 틀린 것이 아니라 프로토콜의 경제적 규칙이나 설계 자체에 허점이 있는 경우입니다.

예를 들어 개발자는

사용자가 담보 100달러를 맡기면

최대 70달러까지만 대출받을 수 있도록 설계했다고 가정하겠습니다.

그런데 여러 기능을 조합하면 실제로는 120달러까지 대출할 수 있는 경로가 존재할 수도 있습니다.

각 함수는 정상적으로 작동하지만 전체 시스템을 조합하면 예상하지 못한 결과가 만들어지는 것입니다.

OWASP의 2026 목록에서는 비즈니스 로직 취약점을 별도의 주요 위험으로 분류하고 있습니다.

왜 발견하기 어려울까?

단순 코드 오류는 자동화된 보안도구로 찾을 수 있는 경우가 있습니다.

하지만 비즈니스 로직 취약점은

“이 프로토콜이 원래 어떤 경제적 규칙으로 작동해야 하는가?”

를 이해해야 발견할 수 있습니다.

따라서 코드 감사만으로 모든 문제가 발견되는 것은 아닙니다.

6. 외부 호출 검증 실패

여섯 번째는 Unchecked External Calls, 외부 호출 검증 실패입니다.

스마트컨트랙트는 다른 스마트컨트랙트를 호출할 수 있습니다.

예를 들어

A 컨트랙트가 B 컨트랙트에 토큰을 보내고,

B 컨트랙트의 결과에 따라 내부 상태를 변경할 수 있습니다.

그런데 외부 호출이 실제로 성공했는지 확인하지 않고 다음 로직을 계속 실행하면 문제가 발생할 수 있습니다.

OWASP 역시 외부 호출의 성공 여부를 확인하지 않는 것이 계약의 상태와 자산처리에 문제를 일으킬 수 있다고 분류합니다.

간단한 사례

스마트컨트랙트가

“사용자에게 100 USDC를 보냈다”

고 내부 장부에 기록했다고 가정해보겠습니다.

그런데 실제 외부 토큰전송은 실패했습니다.

컨트랙트가 실패 여부를 확인하지 않았다면 내부 장부에는

지급 완료

로 표시되지만 실제 사용자는 돈을 받지 못합니다.

반대 방향으로 악용되면 자산손실로 이어질 수도 있습니다.

7. 업그레이드·프록시 취약점

일곱 번째는 Proxy & Upgradeability Vulnerability입니다.

스마트컨트랙트는 한 번 배포하면 코드를 직접 변경하기 어렵습니다.

그래서 많은 디파이 프로토콜에서는 프록시(Proxy) 구조를 사용합니다.

사용자는 프록시 컨트랙트와 상호작용하고 실제 로직은 별도의 구현 컨트랙트에 존재합니다.

관리자가 구현 컨트랙트를 새 버전으로 바꾸면 서비스 기능을 업그레이드할 수 있습니다.

편리한 구조이지만 위험도 존재합니다.

OWASP Smart Contract Top 10 2026에는 프록시·업그레이드 취약점이 새 주요 범주로 포함되어 있습니다.

어떤 문제가 생길 수 있을까?

예를 들어 업그레이드 권한이 한 개인지갑에만 있다고 가정해보겠습니다.

그 지갑의 개인키가 탈취되면 공격자가 악성 스마트컨트랙트로 구현 코드를 교체할 수 있습니다.

사용자는 평소와 같은 주소에 접속하지만 뒤에서 실행되는 로직은 공격자가 만든 코드일 수 있습니다.

또 업그레이드 과정에서 저장공간 구조를 잘못 변경하면 기존 사용자 잔액이나 권한정보가 손상될 수도 있습니다.

스마트컨트랙트 해킹은 하나의 취약점만 사용하는 것이 아니다

실제 공격은 여러 취약점을 동시에 조합하는 경우가 많습니다.

예를 들어

플래시론으로 대규모 자금 확보

↓

DEX 가격 조작

↓

오라클이 잘못된 가격 반영

↓

대출 프로토콜의 비즈니스 로직 악용

↓

과도한 자금 인출

과 같은 구조입니다.

따라서 뉴스에서

“플래시론 공격으로 해킹됐다”

라고 표현되더라도 실제 근본 원인은 오라클이나 비즈니스 로직의 취약점일 수 있습니다.

7가지 공격을 한눈에 비교

공격 유형	핵심 문제	가능한 결과
접근제어 취약점	권한검사 실패	관리자 기능 탈취
재진입 공격	상태 변경 전 재호출	반복 출금
오라클 조작	잘못된 가격정보	과대 대출·잘못된 청산
플래시론 연계 공격	대규모 자금으로 취약점 확대	대규모 자금 유출
비즈니스 로직 오류	경제적 설계 허점	의도하지 않은 자금 이동
외부 호출 검증 실패	호출 성공 여부 미확인	장부와 실제 상태 불일치
업그레이드 취약점	프록시·관리권한 문제	전체 로직 장악

스마트컨트랙트 감사(Audit)를 받으면 안전할까?

스마트컨트랙트 프로젝트에서는 외부 보안회사의 코드 감사를 받는 경우가 많습니다.

감사는 중요한 보안절차입니다.

하지만

Audit 완료 = 절대 해킹되지 않음

을 의미하지는 않습니다.

보안감사는 특정 시점의 특정 코드에 대해 수행됩니다.

그 이후 코드가 변경되거나 새로운 기능이 추가되면 새로운 취약점이 생길 수 있습니다.

또 경제적 구조의 취약점이나 외부 서비스 문제는 감사에서 완전히 발견되지 않을 수도 있습니다.

여러 감사회사가 확인했다면 더 안전할까?

여러 독립적인 보안팀의 감사를 받으면 취약점을 발견할 가능성을 높이는 데 도움이 될 수 있습니다.

하지만 감사회사 수만으로 안전성을 판단하는 것은 어렵습니다.

확인할 것은

• 실제 감사보고서가 공개되어 있는가
• 어떤 버전의 코드를 감사했는가
• 발견된 취약점이 수정됐는가
• 수정된 코드가 다시 검증됐는가
• 이후 추가 업그레이드가 있었는가

등입니다.

버그바운티는 왜 중요할까?

버그바운티는 외부 보안연구자가 취약점을 발견해 프로젝트에 신고하면 보상을 지급하는 제도입니다.

공격자가 실제로 취약점을 악용해 수익을 얻는 대신 프로젝트에 신고하도록 경제적 인센티브를 제공하는 것입니다.

높은 규모의 자산을 관리하는 프로토콜에서는 감사와 함께 버그바운티 프로그램을 운영하는 경우가 있습니다.

하지만 버그바운티 역시 모든 공격을 막을 수 있는 보장은 아닙니다.

TVL이 크면 안전한 프로토콜일까?

TVL은 Total Value Locked의 약자로 디파이 프로토콜에 예치된 자산규모를 의미합니다.

TVL이 크다는 것은 많은 자산이 이용되고 있다는 의미일 수 있습니다.

하지만

TVL이 크다 = 해킹될 수 없다

는 뜻은 아닙니다.

오히려 큰 자산을 보유한 프로토콜은 공격자에게 더 매력적인 목표가 될 수도 있습니다.

따라서 TVL은 여러 평가요소 가운데 하나로 보는 것이 적절합니다.

스마트컨트랙트가 오픈소스면 안전할까?

코드가 공개되어 있으면 누구나 검토할 수 있다는 장점이 있습니다.

보안연구자들이 취약점을 발견할 가능성도 높아질 수 있습니다.

하지만 공격자 역시 코드를 볼 수 있습니다.

따라서

코드 공개 자체가 보안을 자동으로 보장하는 것은 아닙니다.

오픈소스 여부보다 얼마나 많은 검토와 테스트가 있었고 문제가 발견되었을 때 어떻게 대응하는지를 함께 봐야 합니다.

사용자가 스마트컨트랙트 위험을 확인하는 방법

일반 투자자가 스마트컨트랙트 코드를 직접 분석하기는 어렵습니다.

하지만 몇 가지 항목은 확인할 수 있습니다.

감사보고서가 있는가?

공식 웹사이트에서 실제 감사회사와 보고서를 확인합니다.

업그레이드 가능한 계약인가?

관리자가 코드 변경권한을 가지고 있는지 확인할 수 있습니다.

관리자 권한은 어떻게 관리되는가?

한 명의 개인지갑인지, 멀티시그인지 확인합니다.

오라클은 어떤 방식을 사용하는가?

가격정보를 한 곳에서만 받는지 여러 데이터소스를 사용하는지 확인합니다.

과거 보안사고가 있었는가?

사고가 있었다면 원인과 후속조치를 확인합니다.

멀티시그가 중요한 이유

스마트컨트랙트 관리자 권한을 한 지갑이 가지고 있다고 가정해보겠습니다.

해당 개인키 하나만 유출되어도 프로토콜 전체가 위험해질 수 있습니다.

멀티시그를 사용하면 예를 들어

5명 중 3명의 승인

이 있어야 중요한 관리자 작업을 실행하도록 만들 수 있습니다.

하나의 키가 탈취되더라도 즉시 전체 권한을 장악하기 어렵게 만드는 방식입니다.

Ethereum 보안 가이드도 민감한 관리자 작업에서 멀티시그를 추가적인 보호수단으로 활용할 수 있다고 설명합니다.

‘코드는 법이다’라는 말을 그대로 믿으면 안 되는 이유

블록체인에서는

Code is Law

이라는 표현이 종종 사용됩니다.

스마트컨트랙트에 작성된 코드가 자동으로 실행된다는 의미입니다.

하지만 코드가 자동으로 실행된다는 것은 오히려 코드 오류의 영향도 자동으로 발생할 수 있다는 뜻입니다.

스마트컨트랙트가 잘못 작성되어 있다면 블록체인은

“이 결과는 개발자의 의도와 다르다.”

고 판단해 거래를 취소하지 않습니다.

정해진 코드를 그대로 실행합니다.

그래서 스마트컨트랙트에서는 코드 작성 전 설계와 검증이 매우 중요합니다.

스마트컨트랙트 해킹 피해를 줄이려면

사용자 입장에서는 다음과 같은 기본적인 원칙을 생각해볼 수 있습니다.

1. 출처가 불분명한 디파이 서비스에 큰 금액을 예치하지 않는다.
2. 감사보고서와 보안정보를 확인한다.
3. 지나치게 높은 수익률만 보고 결정하지 않는다.
4. Token Approval을 확인한다.
5. 장기보관 지갑과 디파이용 지갑을 분리한다.
6. 한 프로토콜에 모든 자산을 집중하지 않는다.
7. 업그레이드·관리자 권한 구조를 확인한다.
8. 공식 사이트와 스마트컨트랙트 주소를 확인한다.

스마트컨트랙트 위험을 완전히 제거할 수는 없지만 한 번의 사고가 전체 자산으로 확대되지 않도록 관리하는 것은 가능합니다.

결론: 스마트컨트랙트 해킹은 대부분 ‘블록체인 해킹’과 다르다

스마트컨트랙트에서 자산이 탈취되었다고 해서 항상 Ethereum이나 다른 블록체인 자체가 해킹된 것은 아닙니다.

많은 경우 문제는 블록체인 위에 작성된 프로그램의

코드 오류

권한설계 문제

가격정보 문제

경제적 로직 문제

에서 발생합니다.

대표적으로는

1. 접근제어 취약점
2. 재진입 공격
3. 가격 오라클 조작
4. 플래시론 연계 공격
5. 비즈니스 로직 오류
6. 외부 호출 검증 실패
7. 업그레이드·프록시 취약점

등이 있습니다.

특히 실제 공격에서는 이 중 하나만 사용하는 것이 아니라 여러 취약점을 조합할 수 있습니다.

예를 들어 플래시론으로 큰 자금을 확보한 뒤 오라클을 조작하고, 프로토콜의 대출 로직을 악용하는 식입니다.

따라서

“이 프로젝트는 감사를 받았으니 안전하다.”

또는

“TVL이 크니까 안전하다.”

처럼 하나의 지표만으로 스마트컨트랙트의 위험을 판단하는 것은 적절하지 않습니다.

스마트컨트랙트는 금융거래를 자동화하는 매우 강력한 기술이지만 코드에 작성된 규칙을 그대로 실행한다는 특성 때문에 설계상의 작은 허점도 실제 자산손실로 직접 이어질 수 있습니다.

결국 스마트컨트랙트 보안에서 가장 중요한 것은 공격자가 얼마나 똑똑한가만이 아니라 공격자가 악용할 수 있는 작은 허점까지 배포 전에 얼마나 철저하게 제거했는가입니다.

※ 본 글은 스마트컨트랙트 보안구조와 대표적인 취약점을 일반 사용자가 이해할 수 있도록 설명하기 위한 정보입니다. 특정 프로토콜이나 암호화폐의 안전성을 보장하거나 투자를 권유하는 내용이 아닙니다. 디파이와 스마트컨트랙트 서비스에는 코드 오류, 해킹 및 원금 손실 위험이 존재합니다.