MEV와 블록체인 거래 순서의 의미

내 거래 앞뒤에 누가 끼어드는 걸까

탈중앙화 거래소에서 큰 금액을 교환했더니 예상보다 적게 받았고, 블록 탐색기를 보니 내 거래 바로 앞과 뒤에 같은 토큰을 사고판 거래가 붙어 있는 경우가 있습니다. 이는 우연이 아니라 거래 순서를 이용해 이익을 얻는 MEV(최대 추출 가능 가치)의 한 형태일 수 있습니다.

이 글은 블록 안에서 거래 순서가 왜 가치를 만드는지, 그 가치가 어떻게 사용자의 비용으로 전가되는지를 가상의 숫자로 계산해 보여줍니다. 보호 기능이 무엇을 막고 무엇을 막지 못하는지, 거래 전에 확인할 조건도 함께 정리합니다.

거래 순서가 만드는 가치

Ethereum.org는 MEV를 블록 생성 과정에서 거래를 포함하거나 제외하고 순서를 바꿔 얻을 수 있는, 일반적인 블록 보상과 수수료를 넘어서는 가치로 설명합니다. 이 기회를 찾아내는 참여자를 ‘서처(searcher)’라고 부르며, 이들은 자동화된 프로그램으로 대기 중인 거래를 분석합니다.

MEV가 모두 해로운 것은 아닙니다. 거래소 간 가격 차이를 맞추는 차익거래나, 담보가 부족한 대출을 제때 청산하는 거래는 시장이 제대로 작동하도록 돕기도 합니다. 문제가 되는 것은 특정 사용자의 거래를 이용해 그 사용자에게 손해를 입히는 유형입니다.

블록 포함 순서는 어떻게 정해지나

이더리움에서 사용자가 보낸 거래는 대부분 공개된 대기 공간(멤풀)에 머물다가 블록에 포함됩니다. 지분증명 이후에는 블록을 직접 조립하는 ‘빌더’와 블록을 제안하는 검증자가 나뉘는 구조(제안자-빌더 분리)가 널리 쓰이고 있으며, 빌더는 수익이 가장 큰 순서로 거래를 배치하려고 합니다.

그래서 높은 우선 수수료를 내거나 빌더에게 직접 대가를 지불하는 거래가 앞자리를 차지할 수 있습니다. 대기 중인 거래가 공개돼 있다는 점은 투명성을 주지만, 동시에 누군가 내 거래를 보고 먼저 움직일 기회도 줍니다.

얕은 풀의 가상 샌드위치

Ethereum.org는 샌드위치를 대표적인 MEV 유형으로 소개합니다. 서처가 멤풀에서 큰 스왑을 발견하면 그 앞에 같은 방향으로 사서 가격을 올리고, 사용자의 거래가 체결된 직후 되팔아 차익을 얻습니다. 아래는 100 ETH와 300,000 USDC가 든 가상의 풀에서 사용자가 30,000 USDC로 ETH를 사는 경우입니다(수수료 제외).

사용자에게 전가되는 비용

위 예시에서 사용자는 약 0.39 ETH를 덜 받았고, 그 대부분이 공격자의 이익으로 옮겨갔습니다. 사용자 입장에서는 화면에 표시된 슬리피지 범위 안의 결과라 실패 없이 체결됐기 때문에 공격을 당했다는 사실조차 모를 수 있습니다.

이런 비용은 풀이 얕을수록, 거래 규모가 클수록, 슬리피지 허용 범위가 넓을수록 커집니다. Uniswap 문서가 가격 영향과 슬리피지를 따로 확인하라고 안내하는 것도, 허용 범위가 곧 ‘누군가 가져갈 수 있는 최대 폭’이 되기 때문입니다.

보호 기능의 한계

일부 지갑과 서비스는 거래를 공개 멤풀에 올리지 않고 빌더에게 직접 전달하는 비공개 전송 기능을 제공합니다. 이 방식은 샌드위치 위험을 줄일 수 있지만, 전달받는 쪽을 신뢰해야 하고 블록 포함이 늦어지거나 실패할 수 있습니다.

보호 기능이 있다고 해서 가격 영향 자체가 사라지지는 않습니다. 얕은 풀에서 큰 거래를 하면 공격자가 없어도 불리한 가격에 체결됩니다. 보호 기능은 슬리피지 허용 범위를 좁게 설정하고 거래 규모를 나누는 기본 습관을 대신하지 못합니다.

거래 전 확인할 조건

DEX에서 큰 금액을 교환하기 전에 아래 순서로 확인해 보세요.

1. 거래 규모를 풀 전체 유동성과 비교해 가격 영향을 확인하고, 크다면 거래를 나눕니다.
2. 슬리피지 허용 범위를 필요한 만큼만 좁게 직접 설정합니다.
3. 지갑이나 서비스가 비공개 전송이나 MEV 보호 기능을 제공하는지, 그 방식과 한계를 문서에서 확인합니다.
4. 체결 후 블록 탐색기에서 내 거래 바로 앞뒤에 같은 풀을 이용한 거래가 있었는지 확인합니다.
5. 반복적으로 큰 거래를 한다면 유동성이 더 깊은 시장이나 지정가 방식의 주문을 검토합니다.

MEV가 남기는 질문

MEV는 블록체인이 거래 순서를 정하는 방식에서 생기는 구조적인 현상이라 개인이 완전히 피하기는 어렵습니다. 프로토콜 차원의 개선이 계속 논의되고 있지만, 사용자 입장에서는 노출을 줄이는 습관이 가장 현실적인 대응입니다.

이 글의 계산은 가상의 풀과 수수료를 제외한 단순 예시입니다. 실제 거래에서는 서비스의 최신 문서와 화면을 기준 시점과 함께 확인하고, 허용 범위와 거래 규모를 스스로 정하는 것이 좋습니다.