> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 라우팅 및 MEV

> Raydium 상품 간 분할 라우팅, 샌드위치 공격 저항 패턴, Jito 번들 통합, 그리고 비공개 및 공개 멤풀 제출 경로 간 트레이드오프.

<Info>
  **이 페이지는 AI 자동 번역입니다. 모든 내용은 영문판을 기준으로 합니다.**

  [영문판 보기 →](/integration-guides/routing-and-mev)
</Info>

<Info>
  Solana의 "MEV"는 이더리움의 멤풀 기반 MEV와 동일하지 않습니다. 블록 리더는 트랜잭션 패킷을 순서가 정해진 멤풀이 아니라 도착하는 그대로 봅니다. 프론트러닝은 리더 측 재정렬이나 공동배치된 서처를 통해 발생하고, 샌드위치 공격은 풀 상태를 감시하고 더 높은 수수료로 당신의 트랜잭션과 경쟁하는 봇에 의해 실행됩니다. 완화 방법도 이에 따라 다릅니다.
</Info>

## 분할 라우팅 입문

"분할 라우팅"은 하나의 논리적 스왑을 여러 풀에 걸쳐 나누어 한계 가격을 균등하게 만드는 것을 의미합니다. 즉, 각 조각을 자신의 풀 가격으로 거래한 것과 동일한 산출량을 얻습니다. 이는 단일 풀이 거래 규모에 비해 얕을 때 효과적인 가격 영향을 줄입니다.

문제 정의: 입력 `x`를 산출 `f_i(x)`에 매핑하는 함수 `f_i`를 가진 풀 `P_1, ..., P_n`이 주어졌을 때, `Σ f_i(x_i)`를 최대화하는 분할 `x_1 + ... + x_n = X`를 찾습니다. 각 `f_i`가 오목 함수이므로, 최적값은 `f'_1(x_1) = f'_2(x_2) = ... = f'_n(x_n)` (한계 가격 균등)을 만족합니다.

### 탐욕 알고리즘 구현

실무에서 최적값의 \~1% 이내의 결과를 얻는 단순한 접근법입니다:

```
remaining = X
routes    = []
step      = X / 1000     // 슬라이스 크기
while remaining > 0:
    best_pool = argmax over i of f'_i(current_x_i + step)
    x_i += step
    routes.append((best_pool, step))
    remaining -= step
```

더 작은 `step` → 최적값에 더 가깝지만 반복이 더 많아집니다. 실무에서 100–500개 슬라이스는 합리적인 기준입니다.

### 볼록 최적화 구현

프로덕션급 애그리게이터의 경우 최적화를 직접 풉니다. 각 풀은 닫힌 형태의 `f'_i(x)`를 가집니다:

* **Constant-product (CPMM / AMM v4)**: `f'(x) = y * R_y / (R_x + x)^2` 여기서 `R_x, R_y`는 예비자산이고 `y = R_x * R_y / (R_x + x) - R_y`입니다 ... (더 간단한 유도: 한계 가격은 `R_y / (R_x + x)`이므로, 한계 가격을 균등하게 하기 위한 분할은 1D 탐색입니다).
* **CLMM**: 구간별 매끄러움 — 한 틱 내에서 `f'(x)`는 `sqrt_price`의 유리 함수입니다. 틱 전환 시 이산적으로 변합니다. 작은 스텝 솔버로 분할하거나 각 연속 틱을 자신의 "풀"로 취급합니다.

분할 라우팅의 산출값은 `[(pool_1, x_1), (pool_2, x_2), ...]` 벡터로, 당신의 트랜잭션 조립 단계에서 스왑 지시문의 시퀀스로 변환합니다.

### 분할 라우팅이 도움이 되는 경우

| TVL 대비 거래 규모 | 분할 도움?          |
| ------------ | --------------- |
| `<0.1%`      | 아니요 — 단일 풀이 지배적 |
| 0.1–1%       | 미미              |
| 1–5%         | 예, 10–50 bps 개선 |
| `>5%`        | 예, 큰 개선         |

소매 사용자가 깊은 풀에서 `<$10k` 거래를 하는 지갑의 인앱 스왑을 실행 중이면 분할은 불필요합니다. 가스 오버헤드가 개선보다 큽니다. 기관 거래를 견적하는 애그리게이터의 경우 항상 분할하세요.

## 멀티홉 라우트

직접 풀이 없거나 직접 풀의 영향이 클 때 중간을 통해 홉합니다:

```
tokenA → tokenHub → tokenB
```

일반적인 허브: USDC, SOL, RAY. 각 홉은:

* 자신의 슬리피지 한계를 가집니다 (직접 홉에서는 낮음; 멀티홉에서는 홉별).
* 자신의 수수료를 지불합니다.
* 자신의 가격 영향을 가집니다.

총 영향은 합성됩니다: `(1 - impact_1) * (1 - impact_2)`. 1% 영향 홉을 두 번 하면 전체 1.99%이지 2%가 아닙니다.

**같은 풀을 두 번 홉하지 마세요.** `A → B → A → B`로 같은 CLMM을 거치면 그냥 수수료와 슬리피지를 소모합니다. 애그리게이터는 이러한 경로를 생성 단계에서 필터링해야 합니다. (참고: 이것은 같은 페어를 순환하는 것이지, 멀티홉 일반이 아닙니다. `A → USDC → B`를 다른 풀을 통해 라우팅하는 것은 위에서 권장하는 표준적이고 유용한 패턴입니다.)

**홉별 대 전체 최소값.** CPI 구성([ `integration-guides/cpi-integration`](/ko/integration-guides/cpi-integration))을 사용하면 각 홉의 `minimum_amount_out`을 0으로 설정하고 프록시에서 단일 전체 최소값을 적용할 수 있습니다. CPI 없이는 각 홉이 자신의 최소값을 적용하므로 합리적인 중간 한계를 계산해야 합니다. 일반적으로 홉별로 `quote_i * (1 - slippage_bps/10000)`입니다.

## 샌드위치 공격

### 메커니즘

봇은 트랜잭션 가십 스트림을 감시합니다. 당신의 스왑을 보면:

1. 프론트런: 봇이 당신보다 먼저 같은 토큰을 사서 풀 가격을 올립니다.
2. 피해자 트랜잭션: 당신은 더 나쁜 가격에 스왑합니다.
3. 백런: 봇이 올라간 가격에 팔아서 스프레드를 포착합니다.

봇은 두 거래 모두에 우선순위 수수료를 지불합니다. 이익은 샌드위치 델타에서 두 배의 우선순위 수수료를 뺀 것입니다. 당신의 거래가 풀 가격을 의미 있게 움직이는 풀에서만 수익성이 있습니다.

### 완화

**타이트한 슬리피지.** 당신의 최소 산출값이 견적보다 0.5% 낮으면, 0.5% 이상 가격을 움직이는 샌드위치는 당신의 거래를 되돌리지만 봇의 선행 거래는 여전히 당신의 이전 가격에 실행됩니다. 그들은 손실을 입습니다. 샌드위치 봇은 넓은 슬리피지(≥1–2%)를 목표로 합니다. 0.3% 미만의 슬리피지는 대부분 면역입니다.

**비공개 멤풀 제출 (Jito).** 당신의 트랜잭션을 Jito 번들의 일부로 제출합니다. 번들은 공개 가십 스트림에 나타나지 않으므로 봇은 운송 중인 거래를 볼 수 없고 프론트런할 수 없습니다. 트레이드오프: 번들은 밸리데이터 측 팁을 요구하며, 모든 리더가 Jito 지원을 하는 것은 아닙니다 (대부분은 하지만).

**더 작은 거래 규모.** 거래를 여러 트랜잭션에 걸쳐 분할하여 어떤 단일 트랜잭션도 가격을 충분히 움직여 수익성 있는 샌드위치 목표가 되지 않도록 합니다. 총 가스 비용을 증가시킵니다.

**시간 무작위화.** 가능하면 낮은 거래량 시간에 제출합니다. 상호작용 사용자 스왑에는 사용할 수 없지만 예약된 봇 거래에는 실행 가능합니다.

Raydium의 CLMM 풀은 일반적으로 CPMM보다 샌드위치 활동이 적습니다. 단일 틱 유동성 구조는 작은 거래가 가격을 움직이지 않는다는 의미입니다 (틱 내에 머무릅니다). 깊은 CLMM 풀은 본질적으로 최고의 샌드위치 저항 장소입니다.

## Jito 번들

Jito는 **번들** — 원자적으로 내려지는 정렬된 트랜잭션 그룹을 허용하는 수정된 Solana 밸리데이터 클라이언트입니다. 봇은 Jito를 MEV 추출에 사용합니다. 일반 사용자는 같은 봇으로부터 보호하기 위해 Jito를 사용합니다.

### 번들 작동 방식

* Jito 블록 엔진 엔드포인트(예: `https://mainnet.block-engine.jito.wtf`)에 연결합니다.
* 1–5개 트랜잭션 및 Jito의 팁 계정 중 하나에 대한 팁이 포함된 번들을 제출합니다.
* 현재 리더가 Jito를 실행 중이면 당신의 번들이 고려됩니다. 이 슬롯의 경매 우승자 (최고 팁 대 CU)가 내려갑니다. 다른 것들은 떨어집니다.

### 팁 규모 지정

팁 규모는 최근 번들 분포를 따릅니다. Jito는 실시간 백분위수를 게시합니다:

```ts theme={null}
const tipRes = await fetch("https://worker.jito.wtf/api/v1/bundles/tip_floor");
const tips   = await tipRes.json();
// { ema_landed_tips_25th_percentile, 50th, 75th, 95th, 99th }

// 일반적인 날의 사용자 대면 스왑 — 50번째 백분위수가 괜찮습니다.
const tipSol = tips.ema_landed_tips_50th_percentile_lamports / 1e9;

// 정체 중 시간에 민감한 봇 거래 — 75–95번째 백분위수.
```

일반적인 범위: 긴급하지 않은 사용자 스왑의 경우 0.0001–0.001 SOL; 높은 우선순위 봇의 경우 정체 중 0.01–0.1 SOL.

### 번들 구성

```ts theme={null}
import { SearcherClient } from "jito-ts";

const client = new SearcherClient("https://mainnet.block-engine.jito.wtf");

const tipIx = SystemProgram.transfer({
  fromPubkey: user.publicKey,
  toPubkey:   JITO_TIP_ACCOUNTS[Math.floor(Math.random() * 8)],  // 8 팁 계정
  lamports:   tipLamports,
});

const tx1 = new VersionedTransaction(...);  // 스왑
tx1.sign([user]);

const bundleUuid = await client.sendBundle([tx1], tipLamports);
// 선택사항: await confirmation via client.getBundleStatuses([bundleUuid])
```

함정:

* **팁은 번들 내부여야 합니다.** Jito 팁 계정에 대한 `SystemProgram.transfer`를 번들의 트랜잭션 중 하나 내에 지시문으로 포함합니다 (일반적으로 마지막 것). 번들의 일부가 아닌 별도의 팁 거래는 무시됩니다.
* **리더가 Jito 지원이 아닙니다.** \~75%의 리더는 Jito를 실행합니다. \~25%는 실행하지 않습니다. 비Jito 리더가 슬롯을 보유할 때 제출된 번들은 떨어집니다. 클라이언트는 자동으로 재시도합니다.
* **만료.** 번들은 일반 트랜잭션과 동일한 블록해시 만료 모델을 사용합니다. 빠르게 조립하고 제출합니다. \~60초 윈도우.

### 번들 대 우선순위 수수료

우선순위 수수료는 리더에게 당신의 거래를 더 빨리 포함하도록 뇌물을 줍니다. Jito 번들은 추가로 공개 멤풀에서 거래를 숨깁니다. 긴급함을 위해 우선순위 수수료를 사용하세요. 샌드위치 보호를 위해 번들을 사용하세요. 높은 가치 사용자 스왑에서 둘 다 사용합니다.

우선순위 수수료 규모 지정은 [`integration-guides/priority-fee-tuning`](/ko/integration-guides/priority-fee-tuning)을 참조하세요.

## MEV-share / 리버트 보호 RPC

일부 RPC 제공자는 내부적으로 당신의 트랜잭션을 Jito 번들 또는 동등한 비공개 경로를 통해 라우팅하는 "MEV-share" 또는 "리버트 보호" 엔드포인트를 제공합니다:

* **Helius** — 번들 지원이 있는 스테이킹된 연결.
* **QuickNode** — "Revert Protect" 엔드포인트; 제출된 트랜잭션 주위의 번들을 자동으로 형성합니다.
* **Triton** — 비공개 흐름 계층.

이 중 하나를 사용하는 것이 번들 로직을 직접 관리하지 않으려는 프로젝트를 위한 가장 간단한 경로입니다. 트레이드오프: 불투명한 내부; 당신은 제공자의 번들 구성을 신뢰합니다.

## 정체 처리

높은 거래량 기간(메인넷 출시, 주요 상장, 지속적인 랠리) 동안 리더 패킷 큐가 가득 찹니다. 증상:

* 트랜잭션이 60초 이상 미확인 상태로 있다가 "blockhash not found"로 만료됩니다.
* 어제 작동한 우선순위 수수료는 오늘 불충분합니다.
* 시뮬레이션은 성공하지만 실행은 착지하지 않습니다.

전략:

1. **만료 시 공격적인 재시도.** `TransactionExpiredBlockheightExceeded`에서 새로운 블록해시로 다시 빌드하고 재제출합니다. 리버트에서는 재시도하지 마세요. 리버트는 결정적입니다.
2. **멀티 RPC 브로드캐스트.** 동일한 트랜잭션을 여러 RPC에 병렬로 제출합니다. 리더에 가장 먼저 도달하는 것이 이깁니다.
3. **우선순위 수수료 증가.** 50번째 백분위수로 시작하세요. 첫 번째 시도가 만료되면 75번째, 그 다음 95번째에서 재시도합니다.
4. **Jito 번들을 폴백으로.** Jito 리더는 블록 엔진이 번들을 팁 대 CU로 정렬하므로 덜 정체되는 경향이 있습니다. 높은 팁 번들이 우선순위를 얻습니다.
5. **덜 시뮬레이션합니다.** 정체 중에 앞에서 한 번 시뮬레이션하세요. 재시도에서는 재시뮬레이션하지 마세요. 풀 상태가 어쨌든 변했을 것입니다. 정체 중 재시뮬레이션은 거짓 양성으로 실패하는 경우가 많습니다.

## 상품별 MEV 고려사항

**CPMM.** 낮은 TVL 풀에서 매우 샌드위치하기 쉽습니다. 상수 곱 곡선은 작은 봇 선행 거래도 증폭합니다. 풀 TVL의 0.5% 이상의 CPMM 거래에 대해 Jito 번들을 권장합니다.

**CLMM.** 틱 내 거래가 가격을 움직이지 않기 때문에 깊은 풀에서는 덜 샌드위치하기 쉽습니다. 하지만 틱 교차 거래는 확실히 그렇습니다. 틱 교차를 목표로 하는 샌드위치는 알려진 패턴입니다. 타이트한 슬리피지 (`<0.3%`)는 최고의 방어입니다.

**AMM v4 + OpenBook.** OpenBook 오더북 채우기는 동일한 트랜잭션을 통해 실행되므로 오더북 상태를 모르는 샌드위치 봇은 가격 영향을 과소평가하고 종종 실패합니다. 이 때문에 본질적으로 낮은 MEV 장소입니다.

**LaunchLab.** 초기 본딩 곡선 단계에서 핫한 출시에서는 프론트러닝이 횡행합니다. 곡선이 빠르게 움직이고 슬리피지는 넓습니다. Jito 번들이 강력히 권장됩니다. 졸업 후, 결과 CPMM은 일반 CPMM 역학을 따릅니다.

**Farms.** 수확 및 스테이크 작업은 스왑이 아니며 샌드위치할 수 없습니다. 특별한 처리가 필요하지 않습니다.

## 체크리스트

프로덕션 애그리게이터 / 지갑 스왑 UI의 경우:

* [ ] 슬리피지 기본값은 일반 페어에서 ≤0.5%. 사용자가 재정의할 수 있습니다.
* [ ] Jito 번들 제출은 >\$1k USD 가치의 스왑에 기본적으로 활성화됩니다.
* [ ] 우선순위 수수료는 하드코딩된 것이 아닌 라이브 견적에서 소싱합니다.
* [ ] 재시도 로직은 리버트(재시도하지 않음)와 만료(새 블록해시로 재시도)를 구분합니다.
* [ ] 멀티홉 경로는 전체가 아닌 홉별 최소값을 설정합니다.
* [ ] 분할 라우팅은 모든 단일 풀의 TVL의 1% 이상인 거래에 활성화됩니다.
* [ ] 풀 신선도: 제출 직전에 상태를 다시 가져옵니다. 구식이면 재견적합니다.
* [ ] 얕은 풀에서 샌드위치 저항: Jito 전용 또는 슬리피지 >1%이면 거부합니다.

## 포인터

* [`integration-guides/aggregator`](/ko/integration-guides/aggregator) — 풀 발견, 견적, 트랜잭션 조립.
* [`integration-guides/priority-fee-tuning`](/ko/integration-guides/priority-fee-tuning) — CU 및 우선순위 수수료 규모 지정.
* [`integration-guides/cpi-integration`](/ko/integration-guides/cpi-integration) — 단일 슬리피지 게이트 멀티홉 구성.
* [`algorithms/slippage-and-price-impact`](/ko/algorithms/slippage-and-price-impact) — 공식 정의.

출처:

* [Jito docs](https://docs.jito.wtf)
* [Solana validator docs on priority fees](https://docs.solana.com/transaction_fees)
* [jito-ts](https://github.com/jito-labs/jito-ts) — TypeScript 번들 클라이언트.