[MEV] #1. Planning : 단일 체인, 다중 DEX Arbitrage 봇을 만들려면

2025. 7. 15. 21:24·Project/MEV

안녕 내가 또 왔다.

#0은 사실상 포부였다면 #1부터는 진짜 개발을 위한 얘기들을 할 생각이다.

개발에 앞선 설계가 더 정확한 표현 같다.

그래서 사실 #0 만들자마자 #1를 바로 연달아 쓰고 있다고 보면 된다ㅋㅋㅋㅋㅋ

(내가 또 왔어의 비하인드, 근데 나한테만 빠른거고 업로드는 느리게 될거라ㅋㅋ)

야야 이런말 하기엔 일러...

 

리서치(를 빙자한 탐독)과 설계

일단 대충 떠오르는 과제들이 몇개 있다. 잊어버릴까봐 그냥 서두에 적어둔다.

#0에서 말했듯, 모든 글은 나의 의식의 흐름이다..ㅋㅋㅋ

 

1. 차익 거래에 대한 이익을 얻기 위해서는 매수와 매도 행위가 거의 동시에 이뤄져야한다. (매우 짧은 시간 내로!)

차익거래를 하겠다고 판단했을 때의 가격와 실제 거래가 이뤄지는 가격에서 차이가 있다면,

이익이라고 생각해서 거래를 수락했는데 막상 까고보니 손해로 끝나는 상황이 발생할 수 있기 때문이다.

 

2. 1의 문제를 해결하기 위해서는 미지의 네트워크 시간(ex. 브릿징 시간 등) 을 예측하는게 중요해보인다. 다행히 회사에서 비슷한 로직을 짠 적이 있는데 그걸 좀 더 발전을 시켜야할 것 같다. 여기에 대한 아이디어는 구현할 때 설명하겠다.

 

3. 블록체인 네트워크 혼잡도는 시간에도 영향을 끼치지만 수익률에도 영향을 미친다. 물론 1에서 말한 문제처럼 시간차로 인한 가격 손실도 문제지만(비영구적 손실?) 가스비 또한 문제다. 가스비는 대체로 네트워크 혼잡도에 의해 유동적으로 바뀌기 때문에 혼잡한 시간은 피해서 거래를 하는게 좋지 않을까 싶기도 하다.

 

4. 그리고 보안에 관련한 고려다. 늘 염두를 해두겠지만 나도 이런 직접적인 돈 거래 시스템을 만들어보는게 처음이다보니 더더 검토에 검토가 필요하다. 코드 결함으로 외부 해커에 의해 돈이 털릴 수 있는 무법지대에 들어서는거기 때문에 많은 공격과 그리고 방어 기법에 대해 생각을 해봐야한다. 공격 포인트는 어디든 될 수 있기 때문에 나도 모든 이음새와 표면에 방패를 덕지덕지 붙여야한다.

 

(사실 내 설계 결함으로 돈을 시장에 잃는거면 모르겠는데 외부 해커가 내 서비스를 공격해서 돈을 가져가는거는 뭔가 더 불쾌하다! 어차피 돈을 뺏기는건 매한가지지만 그냥 기분의 문제다.)

대체 해킹을 왜하는거야^^^^^^ 확마


여담: 프로젝트명이 궁금해?

경제학자 아담 스미스가 말한 '보이지 않은 손'의 개념처럼 아비트라지는 시장의 불균형을 해소하는 역할을 한다.

개인의 이익을 추구하는 행위가 결과적으로는 시장 전체의 효율성을 증진시키기 떄문이다. (물론 단점도 존재한다. 모든건 늘 그림자가 존재하니까)

좋은게 좋은거지 안그래?

아무튼 이러한 긍정적인(!) 생각을 바탕으로 나의 봇의 이름은 평화유지군 즉, Peace Keepers로 정했다.

모든 시장 참여자들이 어느 거래소를 사용하던 모두 공평한(?!), 공정한, 건전한 가격에 거래할 수 있도록 시장 불균형을 해소하는, 뭐 그냥 대의가 있는 것마냥 갖다 붙였다ㅋㅋㅋㅋ

사실 의미는 부여하기 따름이고 이왕이면 좋은 취지로 만든 프로덕트가 더 정이 가는 법이 아니겠는가!ㅋㅅㅋ

또 사람도 이름따라 간다고, 프로덕트도 이름 따라서 이왕이면 좋은 곳에 많이많이 쓰였으면 하는 그런 부모의 마음도 들어있다.

 

아무튼 아비트라지의 원리를 새기자. 프로덕트를 만들다가 산으로 가는 경우가 왕왕 있기 때문에 늘 본질을 새기는 것은 중요하다.

모든 거래의 원리는 "싸게 사서 비싸게 판다"

매매란 시간을 x축으로 움직이므로 "쌀 때 사서 비쌀 때 판다"

아비트라지는 "싼 곳에서 사서 비싼 곳에 판다"


홉 스왑 경로와 계산

다시 본론으로 들어와서, 자 그러면 어떻게 아비트라징을 할지 계획을 짜보자. 모든 영화에서도 작전에 돌입하기 전에 탐색, 설계, 계획이 먼저다. 지금은 마인드맵만이 이리저리 펼쳐져 있는 상태이다. 이걸 좀 추려서 계획으로 다듬어보자.

 

나는 이 설계를 도와줄 전문가를 알고 있다. 1편에서도 말했던 이 블로그의 글이다. 이 글을 가이드라인 삼아 따라가보자.

n-홉스왑은 외환 시장에서의 n각 아비트라지와 같다.

n각 아비트라지를 설명할 겸, 이후 설계에 대해 알아야할 개념을 먼저 짚고 넘어가보자. (아씨 개발을 하고 싶은데 모르는 개념이 너무 많아서 걸리적거린다. 근데 너무 재밌다!)


N각 아비트라지

삼각 아비트라지를 예시로 들어보겠다.
USD/KRW 가 1,300원,
EUR/USD가 1.1달러,
EUR/KRW가 1,440원이라고 가정해보자.

이론적으로는
EUR/KRW = USD/KRW X EUR/USD = 1,300 x 1.1 = 1,430원
이어야 하는데 실제로 1,440원에 거래되고 있으므로 10원의 차익 기회가 생긴다.

이 경우 다음와 같은 순서로 거래가 가능하다.
1. 원화로 달러를 매수 (1,300원/달러)
2. 달러로 유로를 매수 (1.1달러/유로)
4. 유로를 원화로 매도 (1,440원/유로)


스프레드

외환 트레이딩에서 사용되는 언어다.

스프레드는 통화쌍의 사는 가격과 파는 가격 사이의 차이를 의미한다.

 

예시로, 외환시장에서 1 USD를 1,100KRW에 매수한다고 하면, 은행이 고시하는 매수 환율은 1,130원, 매도 환율은 1,070원이라고 고시하는데 이것이 외화 스프레드가 반영된 것이다.

 

즉 고객이 은행에서 달러를 현찰로 살 때는, 1,130원에 사야하고, 반대로 현찰 달러를 팔 때는 1,070원에 팔아야 한다.

은행에서는 아 30원의 차이를 수수료 대신 영업이익으로 취한다.

(흔히 금융기관에서 환전 우대율 80% 등의 혜택을 홍보하는데 이는 스프레드(수수료) 비용을 80% 할인해 준다는 뜻이다. 즉 여기서 수수료는 30원에서 6원으로 할인된다.)

 

스프레드가 좁을 수록 해당 자산의 유동성이 높고 거래 비용이 낮다는 것을 의미한다.

반대로 스프레드가 넓으면 유동성이 낮고 거래 비용이 높다는걸 의미한다.

 

참고로 스프레드에는 사실 아래와 같은 종류가 있다.

1. 매수/매도 스프레드(Bid-Ask Spread): 위에서 말한 예시에 해당된다. 주식, 외환, 채권 등 금융 자산에서 매수 호가(Bid price)와 매도 호가(Ask price) 간의 차이를 말한다.
2. 금리 스프레드 (Interest Rate Spread): 두 채권이나 대출 상품 간의 금리 차이
3. 수익률 스프레드 (Yield Spread): 두 자산간의 수익률 차이, 주로 동일한 만기를 가진 채권간의 수익률 차이 비교
4. 통화 스프레드 (Currency Spread): 두 통화 간의 환율 차이 또는 외한 거래 시 매수/매도 호가 간 차이
5. 크레딧 스프레드 (Credit Spread): 같은 만기를 가진 국채와 회사채간의 금리 차이. 신용 위험이 더 높은 회사채의 금리가 더 높기 때문에 그 차이를 말함

이익이 되는 거래라는 판단은 어떻게?

전문가는 이와 비슷하게 2홉 스왑경로를 제시해주고 있다.

 

예시로 ETH/USDT 쌍을 생각해보자.

USDT로 시작하여 ETH를 얻는 스왑 경로를 모두 생각해보면 다음과 같은 경로가 있다.

1. USDT -> ETH

2. USDT -> BTC(네이티브 코인) -> ETH

3. USDT -> USDC(스테이블 코인) -> ETH

 

자 그러면 각 경로 중에서 가장 나에게 수익을 가장 많이 가져다 줄 것인가? 그걸 판단해야 한다.

그러려면 각 경로의 스프레드를 계산해봐야하는데 공식은 아래와 같다.

출처: perplexity

  • price1: 구매(or 판매)하려는 DEX 가격
  • fee: 해당 거래의 수수료율
  • price2: 비교 대상 DEX의 가격 (만약 수수료가 있다면 마찬가지로 1-fee 곱하기)

여기서 주의해야할 점은 위 공식에는 가스 비용이나 슬리피지 비용이 반영이 되지 않았다는 사실이다.

다들 서로 다른 컨트랙트들을 사용하고 그 컨트랙트들의 가스비는 각각 다를 뿐더러, 각자가 보는 우위(edge)의 가스비는 다르기 때문이다.

즉, 같은 시장 상황에서도 서로 다른 수익 기회를 보게 되기 때문에 이는 제외한 기본적인 수식만 나와있다.

 

그렇다고 너무 어렵게 생각할 필요없이 가스비는 그 만큼 빼주면 될 것 같다.

문제는 슬리피지인데... 하.... 일단 정리해보자.

역시 돈버는건 쉽지 않다. 이걸 혼자하는 미친 수학천재 개발자들이 있다니 서글프군.


그래서 뭘 만들어야 할까?

등산 시작도 전에 안개낀 보이지도 않은 정상을 가진 산을 바라보는 느낌. 압도적.

1. 스프레드 모니터링 서버

우선 기회를 찾아야한다.

스프레드 모니터링 서버가 필요하다. 관련 DEX들의 풀, 가격을 모두 가져다가 일단 가격차이를 봐야할 것 같다.

물론 이걸 제공해주는 API가 있을 것 같은데 돈이 문제라서.. 나는 최대한 사비 안쓰고 사이드 프로젝트를 하고 싶다.

그리고 만들다가 막히거나 에러 생기면 속병날 것 같기 때문에 그냥 다 만드는게 속편할듯. (아니면 동료를 모으기..?ㅋㅋㅋ)

근데 하다가 지치면 걍 API 딸 수도 있고, 근데 사실 이거 만들면서 또 배우는게 많을 것 같기 때문에 직접 해보고 싶다.

 

2. 수익률이 높을 체인, 토큰, 풀 선택

여전히 기회를 탐색하는 과정이다.

체인은 연습을 위해 EVM으로 정했고, 토큰이나 풀은 어떤게 좋으려나...

 

차익거래는 거래량이 높은 토큰에서 더 유리할까 아니면 적은 토큰에서 유리할까 모르겠다.(부끄럽지만 진짜 솔직하게 말하는거다.)

거래량이 많으면 당연히 슬리피지가 적어서 좋기는 하겠다만, 그만큼 경쟁자가 득실득실 하다는 뜻이니 내가 기회를 잡을 수 있을지 걱정된다.

이거는 좀 더 리서치를 해서 나중에 보충하는 걸로 하겠다.

 

아무튼 이게 정해지면 1번 모니터링 서버도 일단 그 페어로만 구현을 하면 되어서, 좀 더 과제가 간단해질 것 같다.

확장은 나중에 하고 일단 전체 프로세스를 경험하는게 1순위 목표다.

 

3. 차익 거래를 위한 순환 경로 찾기

2번이랑 연관이 되어있을까 싶기도 한데, 아무튼.

해당 쌍을 그냥 1홉 스왑할지 2,3홉 스왑할지 그 경로를 찾아야한다.

이를 판단하기 위한 파라미터들이 있을 텐데 이 역시.. 리서치가 필요하다ㅠ

 

4. 전략 평가

슬리피지, 가스비, 수수료를 고려하여 이 모든 cost보다 높은 profit을 안겨줄 거래를 찾아야한다.

 

이를 최적화하기 위한 전문가의 팁을 적어보자면! 

1. 가스비: 동일한 우위를 차지하기 위해 경쟁하는 다른 경쟁자들을 분석하고, 그들을 이기기 위해 가스비를 조금 더 지불한다.
2. 가스 사용량: 어셈블리, Yul, Huff 같은 저수준 언어를 사용하여 스마트컨트랙트를 최대한 최적화하면 가스 사용량을 줄일 수 있다.
3. 가격 스프레드: 경쟁자보다 더 나은 매수/매도 가격을 얻으려면 더 많은 DEX, CEX를 모니터링 해야한다,
4. 슬리피지: 유동성이 높은 거래소/풀을 활용하여 슬리피지 비용을 낮춘다. TVL/유동성이 높을 수록 거래가 시장에 미치는 영향이 줄어든다.

 

5. 테스트

Foundry를 사용하여 시뮬레이션을 돌려봐야한다. QA 단계라고 보면 된다.

가격 영향 함수들을 포함해서 시뮬레이터를 만들어야하는데 으아ㅏㅏ 할거 짱 많은데 다 내가 하고싶었던 것들이라 너무 재밌을 것 같다.

우선 이 단계가 필요하다는 것만 인지할 예정.

 

6. 실전이다

이제 무법지대에 들어가는거다. 나는 한낱 공격성0의 지렁이인데 돈을 벌려고 달려드는 하이에나들 틈에서 살아남아야 한다.

이딴건 기대할 수 없다. 세상은 잔혹하다ㅜ

블록에 tx를 날리는 방법은 두가지가 있는데, public mempool을 통하거나, Flash bots, Blocknative 등 블록 빌더가 운영하는 private relay를 이용하는 방법이다. (Private relay에 대해서는 다른 글에서 자세하게 다뤄보려고 한다.)

 

대부분 프라이빗 멤풀을 보통 이용하는데, 모든 노드가 트랜잭션을 볼 수 있다면, 아비트라지 기회를 노출시키고 여러 위험을 유발할 수 있기 때문이다. public mempool은 그냥 나 잡아먹으쇼 하고 공개 처형장을 스스로 여는 꼴이기 때문에, 프라이빗 릴레이를 사용하는게 당연히 백번 낫다. 실전에서는 특정 거래가 불리하게 노출되지 않게 하는게 곧 수익으로 직결되기 때문이다.

 

아무튼 어떤 private relay를 선택할지도 알고리즘적으로 정해야할 것 같다.

여담: 개발과 리서치 분리

이 글을 적으면서 느낀 점은 내가 이 차익거래에 대한 배경 지식(도메인 지식이라고나 할까)이 부족하다는 것이다.

그래서 앞으로는 MEV 개발 글과 리서치 글을 분리하려고 한다.

 

아비트라징에 대해 파고들면 끝이 없어서 개발 본질에서 벗어나 산으로 가는 느낌이 싫다. 일단 목표에 집중하고 싶다.

그리고 도메인 지식을 그렇게 자세하게 몰라도 일단 개발은 할 수 있다. 아는 부분을 먼저 구현하면 되니까 말이다. 무엇보다 나는 얼른 코드를 짜고 싶어 근질거린다! 

 

다만, 도메인 지식을 폭넓게, 깊게 알고 있어야 더 안전하고 효율적인 봇을 만들 수 있다고 생각한다.

나는 내 봇이 유능했으면 좋겠기 때문에, 주인인 내가 솔선수범으로 먼저 유능해지려고 한다. (윗물이 맑아야 아랫물이 맑다.)

 

아무튼 둘이 의존성이 아예 없다고는 할 수 없지만, 다른 브랜치에서 진행을 해야 여러모로 글도 깔끔하고 내 스스로도 컨텍스트 스위칭가 잘 될 것 같기 때문에 앞으로는 분리할 예정이다. (개발머리와 상식(?)머리는 따로임!)

 

아비트라징 리서치는 음수로 연재해보려고 한다. 개발글은 양수로 연재가 될 예정이다.

참고로 어느 방향이든 절댓값이 높은 순이 최신순이다.

(약간 느낌이 음수는 좀 더 기반을 튼튼하게 하는 뿌리 느낌이고, 양수는 쭉쭉 하늘을 향해 뻗어나가는 줄기 느낌. 그런 것도 의도해봤다 후후 메타포 느낌~)

 

당분간은 리서치를 하면서 현재 글의 마지막 계획 부분을 보충해나갈 예정이다.

새로운 글의 업로드가 더 느려질 수는 있는데 다른 글을 꾸준히 올릴 수 있도록 하겠다! 바쁘다 바빠 개발자 인생!

 

참고 자료

  • https://blog.naver.com/datamaxiplus/223895436572
  • https://blog.naver.com/bkyang2011/223604032555

'Project > MEV' 카테고리의 다른 글

[MEV] #0. 사이드 프로젝트: MEV 봇 프로젝트 시작  (1) 2025.07.08
'Project/MEV' 카테고리의 다른 글
  • [MEV] #0. 사이드 프로젝트: MEV 봇 프로젝트 시작
빵빵0
빵빵0
(아직은) 공부하고 정리하는 블로그입니다.
  • 빵빵0
    Hack Your World
    빵빵0
  • 전체
    오늘
    어제
    • 분류 전체보기 (92)
      • Error Handling (7)
      • Project (5)
        • MEV (2)
      • Architecture (0)
        • API (0)
        • Cache (0)
        • 사소한 고민거리 (0)
      • Computer Science (4)
        • Data Structure (2)
        • Database (1)
        • Cloud (0)
        • OS (0)
        • Infra, Network (1)
        • AI (0)
      • Language (8)
        • Go (8)
        • Rust (0)
        • Python (0)
        • Java (0)
      • Algorithm (40)
        • BaekJoon (18)
        • Programmers (7)
        • LeetCode (6)
        • NeetCode (9)
      • SW Books (9)
        • gRPC Up & Running (1)
        • System Design Interview (2)
        • 스프링 입문을 위한 자바 객체지향의 원리와 이해 (6)
        • 블록체인 해설서 (0)
        • 후니의 쉽게 쓴 CISCO 네트워킹 (0)
      • BlockChain (4)
        • Issues (0)
        • Research (4)
        • Tech (0)
      • Own (8)
        • TIR(Today I Read) (3)
        • Personal (2)
        • Novel (0)
        • Memo (3)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    MongoDB
    blockchain
    스택
    Palindrome
    LeetCode
    프로그래머스
    KBW
    BaekJoon
    2024
    Hash Table
    ethereum
    MEV
    go
    BFS
    DP
    EVM
    context
    NeetCode
    블록체인
    goroutine
    chart
    BEAKJOON
    큐
    백준
    golang
    Python
    two pointer
    Greedy
    Programmers
    candlechart
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.4
빵빵0
[MEV] #1. Planning : 단일 체인, 다중 DEX Arbitrage 봇을 만들려면
상단으로

티스토리툴바