Road to Web3 (21) MEV 입문: 프런트런 샌드위치와 순서의 경제학

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

MEV는 한 문장으로 정리하면 이렇습니다.

• 같은 트랜잭션 집합이라도 어떤 순서로 실행하느냐에 따라 추가 이익이 생기고, 그 이익을 두고 경쟁이 벌어진다

web2 개발자에게는 이렇게 번역하는 편이 더 정확합니다.

• 전 세계가 공유하는 커밋 로그에서, 커밋 순서를 두고 생기는 경제적 경쟁

---

 

1) MEV가 왜 생기나: 락 대신 전역 직렬화의 부작용

EVM은 블록 안에서 트랜잭션을 순서대로 실행합니다.
이 순서는 가치에 영향을 줍니다.

• DEX 가격은 먼저 실행한 거래에 의해 바뀐다
• 청산 liquidation은 먼저 잡은 사람이 보상을 가져간다
• 아비트리지 arbitrage는 먼저 맞춘 사람이 수익을 가져간다

즉, 블록은 단순 저장이 아니라

• 상태를 바꾸는 실행 순서표

입니다. 이 순서표를 통제하거나 예측할 수 있으면 돈이 됩니다.

---

 

2) 용어 정리: MEV, 프런트런, 샌드위치

2.1 MEV

MEV는 Maximal Extractable Value의 약자로 쓰입니다.
원래는 Miner Extractable Value였는데, PoS로 넘어오며 표현이 바뀐 맥락이 있습니다.

• 블록에 어떤 트랜잭션을 넣고, 어떤 순서로 넣을지 선택할 수 있을 때 발생하는 추가 이익

여기서 주의할 점은

• MEV 자체는 현상이다
• 그중 일부가 공격이나 착취로 보일 수 있다

입니다.

2.2 프런트런 front run

누군가의 트랜잭션을 보고, 그보다 먼저 실행되도록 끼어드는 행위입니다.
가장 흔한 전개는

• 멤풀에서 대기 중인 대형 스왑을 보고
• 그보다 더 높은 수수료로 먼저 실행되게 올린다

2.3 샌드위치 sandwich

프런트런과 백런 back run을 결합한 형태입니다.

• 공격자가 먼저 매수하여 가격을 올리고
• 피해자의 스왑이 그 비싼 가격으로 체결되게 만든 뒤
• 공격자가 마지막에 매도하여 차익을 회수

피해자는 보통

• 슬리피지 허용치가 넓을수록 더 크게 당한다

---

 

3) 샌드위치가 어떻게 가능한가: 간단한 실행 흐름

DEX는 자동화된 시장 조성자 AMM 모델을 많이 씁니다.
여기서는 가격이 주문장이 아니라 풀의 비율로 결정됩니다.

따라서 순서가 바뀌면

• 피해자의 체결 가격이 바뀐다
• 공격자의 차익이 생긴다

 

web2 비유로는 이런 쪽에 가깝습니다.

• 거래소 주문장 기반 시장에서, 누군가의 큰 시장가 주문을 보고 먼저 선행 주문을 넣어 스프레드를 먹는 행위
• 또는 지연 시간 차이를 이용한 latency arbitrage

차이는 블록체인은

• 커밋 로그가 전 세계 공개로 공유되고
• 결제 취소나 차지백이 기본으로 없고
• 누가 먼저 들어가느냐가 수수료 경쟁으로 정해질 수 있다

입니다.

---

 

4) 누가 순서를 결정하나: MEV 공급망

많은 사람들이 MEV를

• 검증자가 마음대로 순서를 바꾸는 문제

로만 이해합니다.
하지만 현실은 분업되어 있습니다.

대략 이런 플레이어가 등장합니다.

• 사용자: 지갑에서 트랜잭션 생성
• RPC 노드: 네트워크로 브로드캐스트
• 멤풀: 각 노드의 대기열
• 서처 searcher: 멤풀을 보고 수익 기회를 찾는 봇
• 빌더 builder: 서처 번들을 모아 블록 후보를 조립
• 프로포저 proposer: 실제 블록 제안 권한을 가진 검증자 역할
• 릴레이 relay: 빌더와 프로포저 사이 중개

핵심은 이겁니다.

• 많은 MEV는 멤풀 가시성에서 시작되고
• 그 다음은 블록 구성 권한과의 협상 문제로 이어진다

---

 

5) 서비스에 어떤 문제가 생기나

5.1 사용자가 예상한 가격으로 체결되지 않는다

DEX 스왑 UX에서 가장 흔합니다.

• 사용자는 가격이 변할 수 있다는 사실을 알고도 진행하지만
• 공격이 끼면 변동이 구조적으로 확대된다

그래서 슬리피지는 단순 UX 옵션이 아니라 공격 표면이 됩니다.

5.2 결제형 트랜잭션의 순서 민감도가 올라간다

x402 같은 모델에서 온체인 결제로 증거를 삼는다면

• 결제 트랜잭션이 블록에 언제, 어떤 순서로 들어가느냐

가 제품 SLA에 영향을 줍니다.

5.3 청산, 경매, 배치 실행에서 순서 경쟁이 직접 비용이 된다

예를 들어

• 담보 청산 시스템은 레이스가 붙으면 가스비가 급등한다
• 경매는 봇 경쟁이 붙으면 참여 비용이 급등한다

web2로 바꾸면

• 동일한 이벤트를 처리하는데, 경쟁이 붙어서 네트워크 비용이 튀는 상황

입니다.

---

 

6) 방어 전략: 서비스는 어디를 단단하게 해야 하나

MEV를 완전히 없애는 건 어렵습니다.
대신 공격 표면을 줄이는 쪽으로 접근합니다.

6.1 슬리피지와 가격 보호

• 슬리피지 허용치를 최소화
• 가격 보호 기능과 미리보기 강제
• 대형 스왑은 분할 실행 또는 TWAP류 전략 고려

6.2 프라이빗 오더 플로우

멤풀에 공개되면 관찰당할 수 있습니다.
그래서

• 트랜잭션을 공개 멤풀로 보내지 않고
• 프라이빗 릴레이나 번들 채널로 전달

하는 방식이 등장합니다.

이때 제품적으로 중요한 점은

• 프라이빗 라우팅은 성공률과 검열 리스크 같은 새로운 실패 모드를 만든다

입니다.

6.3 커밋 리빌 commit reveal 패턴

값을 바로 공개하지 않고

• 커밋 단계에서는 해시만 올리고
• 리빌 단계에서 실제 내용을 공개

하는 방법입니다.

장점

• 멤풀 관찰 기반 프런트런을 줄인다

단점

• 2단계 UX와 타임아웃, 실패 처리 상태 머신이 필요하다

6.4 배치 경매 또는 순서 무력화 설계

어떤 서비스는 아예

• 같은 블록 안의 순서를 약화시키는 경매나 배치 방식

을 설계합니다.
web2로 말하면

• 연속 거래가 아니라 콜 옥션처럼 묶어서 체결하는 방식

에 가깝습니다.

 

---

 

7) 결론

• 블록체인은 전역 직렬화를 만들기 때문에, 순서 자체가 돈이 된다
• MEV는 채굴자나 검증자만의 문제가 아니라, 멤풀 가시성과 블록 구성 분업 구조에서 발생한다
• 서비스 관점에서는 슬리피지, 프라이빗 라우팅, 커밋 리빌, 배치 설계로 공격 표면을 줄여야 한다
• web2의 주문장 선행매매나 지연 시간 아비트리지와 닮았지만, 커밋 로그 공개성과 되돌리기 어려움 때문에 제품 리스크가 더 직접적이다