> ## 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.
# 라우팅 개요
> AMM 라우팅 프로그램이 하는 일, 왜 별도의 프로그램으로 존재하는지, 그리고 클라이언트 측 명령어 조합 대신 언제 사용해야 하는지 알아봅니다.
**이 페이지는 AI 자동 번역입니다. 모든 내용은 영문판을 기준으로 합니다.**
[영문판 보기 →](/products/routing/overview)
## 한 문단 요약
AMM 라우팅 프로그램은 다중 홉 스왑을 풀 간 유동성을 연결하는 단일 온체인 트랜잭션으로 번들링합니다. 경로(풀과 중간 민트의 목록)와 슬리피지 매개변수가 포함된 하나의 명령어를 제공하면, 라우터가 N개의 홉을 순서대로 실행하여 한 풀의 출력을 다음 풀의 입력으로 이동시킵니다. 가격 계산을 위한 별도의 온체인 라우터 로직이 필요하지 않습니다. 각 홉의 수수료와 곡선은 CPI를 통해 자체 풀 프로그램에서 처리되지만, 라우터는 계정 전달과 토큰 이동을 조정합니다.
## 왜 별도의 라우터 프로그램인가?
Raydium 클라이언트와 애그리게이터는 라우터를 사용하지 않고 클라이언트에서 다중 홉 스왑을 항상 함께 조합할 수 있습니다. 각 풀마다 하나씩 N개의 스왑 명령어를 만들어 단일 트랜잭션으로 제출하면 됩니다. 그렇다면 왜 전담 라우터 프로그램을 따로 두고 있을까요?
### 라우터를 사용하는 이유
1. **다른 프로그램에서의 CPI.** 자신의 프로그램이 더 큰 트랜잭션의 일부로 경로를 호출해야 하는 경우(예: 수수료를 대상 토큰으로 스왑하는 유동성 관리자), 라우터로 CPI하는 것이 계약 내에서 N개의 자식 CPI를 번들링하고 모든 계정을 관리하는 것보다 깔끔합니다.
2. **원자적 계정 상태.** 모든 홉의 계정 목록이 하나의 명령어 컨텍스트에서 검증됩니다. 중간 풀의 상태가 손상되었거나 한계 가격 어설션이 실패하면 전체 경로가 부분 정산 없이 원자적으로 실패합니다.
3. **단일 명령어 구성.** SDK와 프론트엔드는 다중 홉 경로를 N개의 별도 명령어가 아닌 하나의 논리적 작업으로 나타낼 수 있습니다.
### 클라이언트 측 조합이 여전히 기본값
대부분의 애플리케이션에서 각 풀에 대해 별도의 `Swap` 명령어를 만들고 순서대로 제출하는 것이 더 간단하고 조합 가능하며 동등하게 유효합니다. Raydium SDK의 `Trade.makeSwapTransaction`과 유사한 흐름들은 대부분의 경로에서 정확히 이를 수행합니다.
라우터는 대체품이 아니라 대안입니다. 다음의 경우 사용하세요:
* 더 큰 원자적 작업의 일부로 라우팅이 필요한 프로그램을 구현 중인 경우.
* 단일 "이 경로를 제출하세요" 작업을 원하는 애그리게이터를 구축 중인 경우.
## 작동 방식
라우터 명령어는 다음을 전달합니다:
* **스왑 인수**: 정확한 입력(`amount_in`, `minimum_amount_out`) 또는 정확한 출력(`maximum_amount_in`, `amount_out`).
* **경로 사양**: 순서대로 각 홉마다 `program_id` + 자식 프로그램 계정의 목록. 라우터는 각 홉 그룹의 첫 번째 계정을 읽어 호출할 프로그램을 결정합니다.
* **한계 가격**(CLMM의 경우): `sqrt_price_x64` 범위의 `VecDeque`. CLMM 풀로의 홉에만 사용되며, 빈 deque는 구형 명령어 변형의 경우 오류입니다.
그런 다음 라우터는:
1. **첫 번째 홉 실행**: `amount_in`(또는 정확한 출력을 위해 필요한 입력 계산)을 첫 번째 풀의 입력 보관소로 이전하고, 해당 풀의 스왑을 호출하며, 출력을 수집합니다.
2. **후속 홉 연결**: 각 홉 N마다 홉 N−1의 출력을 홉 N의 입력으로 사용합니다.
3. **슬리피지 강제**: 각 CLMM 홉에서 `sqrt_price`를 해당 `limit_price`와 비교하고, 최종 홉에서 전체 출력을 전역 `minimum_amount_out`과 비교합니다.
중간 토큰은 **사용자 제어 ATA**(홉마다 하나, 느리지만 투명함) 또는 **공유 PDA 파생 계정**(모든 홉에 대한 하나의 주소, 더 빠르지만 불투명함)을 통해 흐를 수 있습니다.
## 가격 책정 및 수수료 위임
라우터는 **자체적으로 가격을 계산하지 않습니다**. 각 홉은 자식 프로그램의 곡선으로 위임합니다:
* **AMM v4**: OpenBook 하이브리드 가격 책정을 포함한 상수 곱 공식을 사용합니다.
* **CPMM**: 구성된 수수료 티어를 포함한 상수 곱 공식을 사용합니다.
* **CLMM**: 틱 기반 가격 책정을 포함한 집중 유동성 수학을 사용합니다.
* **Stable**: 유사한 토큰에 대해 안정적인 스왑 곡선을 사용합니다.
수수료는 각 풀이 자체 구성에 따라 청구됩니다. 라우터는 자체 수수료를 취하지 않습니다.
## 라우터를 피해야 할 때
* **낮은 홉 수(1–2 홉).** 계정 전달 오버헤드는 최소한이므로, 두 개의 별도 스왑 명령어를 사용하면 됩니다.
* **비Raydium 풀.** 라우터는 네 가지 Raydium 풀 유형만 알고 있습니다. 외부 프로그램을 건너는 경로의 경우 클라이언트에서 명령어를 조합하세요.
* **조건부 라우팅.** 경로 도중에 가격이나 풀 상태를 기반으로 분기해야 하는 경우, 온체인 라우팅은 클라이언트 측 구성보다 덜 유연합니다.
## 정신 모델
라우터를 **트랜잭션 압축 유틸리티**로 생각하세요. 경로 사양을 가져와 하나의 명령어, 하나의 트랜잭션, 하나의 컴퓨팅 예산으로 압축합니다. 각 홉은 내부적으로 자신의 풀 프로그램으로 CPI하고 거기서 곡선 수학을 처리합니다. 라우터의 역할은 계정을 올바르게 전달하고, 홉 간에 토큰을 이동하며, 슬리피지를 확인하는 것입니다.
## 다음 단계
* [`products/routing/accounts`](/ko/products/routing/accounts) — 경로 권한 PDA와 공유 계정 패턴.
* [`products/routing/instructions`](/ko/products/routing/instructions) — 전체 명령어 API(모든 10가지 변형).
* [`products/routing/code-demos`](/ko/products/routing/code-demos) — TypeScript와 순수 Rust에서 경로를 구축하는 예제.
* [`integration-guides/routing-and-mev`](/ko/integration-guides/routing-and-mev) — 다중 홉 라우팅을 위한 광범위한 전략.