> ## 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 라우팅 프로그램에서 홉당 계정이 전달되는 방식: 모든 중간 토큰의 사용자 ATA, 그 다음 경로의 각 레그마다 풀별 계정 블록.

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

  [영문판 보기 →](/products/routing/accounts)
</Info>

## 계정 레이아웃: 처음부터 끝까지 사용자 ATA

모든 활성화된 스왑 변형은 **사용자 관리 ATA**를 통해 중간 토큰을 라우팅합니다. 사용자가 입력 ATA, 모든 중간 ATA, 최종 출력 ATA를 소유합니다. 활성 표면에는 공유된 라우터 소유 중간 토큰 계정이 없습니다.

속성:

* 사용자가 중간 토큰마다 하나의 ATA를 소유합니다.
* 사용자가 계정 목록의 모든 ATA를 제공합니다.
* 각 중간 ATA는 이미 존재해야 합니다 (라우팅 전에 wSOL의 경우 `CreateSyncNative`로 초기화하거나, 다른 민트의 경우 SPL Associated Token Account 프로그램을 통해).
* 라우터는 각 홉에서 한 ATA 밖으로 이전 풀의 금고로 전송합니다.
* 각 중간 ATA는 경로의 끝에 시작할 때와 같은 잔액으로 끝납니다 — 경로는 이전 홉이 생산한 것을 소비합니다.

경로 `USDC → SOL → STEP`의 예시 흐름:

```
Accounts list:
  [
    USDC_input_ata (user, signer),
    SOL_intermediate_ata (user),
    STEP_output_ata (user),
    token_program,

    amm_program_1, *amm1_accounts,    // hop 1: USDC → SOL
    amm_program_2, *amm2_accounts,    // hop 2: SOL → STEP
  ]

Hop 1: USDC_input_ata → AMM1 → SOL_intermediate_ata
Hop 2: SOL_intermediate_ata → AMM2 → STEP_output_ata
```

## 홉별 계정 레이아웃

각 홉의 계정들은 연속으로 전달됩니다. 라우터는 각 홉의 블록의 첫 번째 계정(프로그램 ID)을 읽어 자식 프로그램을 식별한 다음 올바른 핸들러로 전달합니다.

각 홉마다 라우터는 다음과 같이 그룹화된 계정들을 예상합니다:

```
[
  program_id,         // Identifies which pool program (AMM v4, CPMM, CLMM, Stable)
  *child_accounts,    // All accounts required by that pool's swap instruction
]
```

자식 계정은 풀 유형에 따라 다릅니다:

### AMM v4 홉

대략 18개 계정: 풀, 권한, 금고, 민트, OpenBook 마켓 계정(AMM v4의 OpenBook 통합이 더 이상 활성화되지 않았지만 하위 호환성을 위해 계정 목록에 유지됨), 토큰 프로그램. 전체 목록은 [`products/amm-v4/accounts`](/ko/products/amm-v4/accounts)를 참조하세요.

### CPMM 홉

대략 11–13개 계정: 풀 상태, 권한, 금고(2개), 민트(2개), 토큰 프로그램, 시스템 프로그램, 연결된 토큰 프로그램. [`products/cpmm/accounts`](/ko/products/cpmm/accounts)를 참조하세요.

### CLMM 홉

대략 15개 이상 계정: 풀, 틱 배열, 금고, 민트, 관찰 상태, 서명자, 토큰 프로그램. [`products/clmm/accounts`](/ko/products/clmm/accounts)를 참조하세요.

### Stable 홉

AMM v4와 유사합니다. [`products/stable/accounts`](/ko/products/stable/accounts)를 참조하세요.

## 토큰 흐름 및 ATA 소유권

* 호출자는 `user_input_ata`로 서명합니다.
* 호출자는 모든 입력, 중간 및 출력 ATA를 **소유해야 합니다**. 라우터는 어떤 중간 ATA의 소유자가 서명자가 아니면 트랜잭션을 거부합니다.
* 호출자의 `user_input_ata` 잔액은 첫 번째 홉의 입력(태그 0 / 8의 경우 `amount_in`, 태그 1 / 9의 경우 `maximum_amount_in`)에 충분해야 합니다.
* 각 중간 ATA는 이미 온체인에 존재해야 합니다. 존재하지 않으면 미리 생성하세요 — 보통 [SPL Associated Token Account 프로그램](https://spl.solana.com/associated-token-account)을 통해 또는 wSOL ATA의 경우 `CreateSyncNative`(태그 5)로.

## CreateSyncNative 지시

래핑된 SOL을 통해 라우팅해야 하고 수동으로 wSOL ATA를 생성하고 동기화하기를 원하지 않으면 [`CreateSyncNative`](/ko/products/routing/instructions#createsyncnative-tag-5)(태그 5)를 사용하세요:

```
CreateSyncNative(amount)
```

이것은 호출자의 지갑 아래에 wSOL ATA를 생성하고, System Program을 통해 `amount`의 SOL을 전송하며, 하나의 지시에서 동기화합니다. 라우팅 전에 새로운 wSOL ATA를 초기화하는 데 유용합니다.

## CloseTokenAccount 지시

경로가 완료된 후 중간 ATA — 가장 일반적으로 wSOL ATA — 를 닫아서 렌트를 회수할 수 있습니다. [`CloseTokenAccount`](/ko/products/routing/instructions#closetokenaccount-tag-6)(태그 6)를 사용하세요:

```
CloseTokenAccount
```

토큰 계정은 닫기 전에 0의 토큰 잔액을 가져야 합니다; 라우터는 자동으로 비우지 않습니다.

## 다음으로 볼 내용

* [`products/routing/instructions`](/ko/products/routing/instructions) — 지시별 인수 형태 및 계정 목록 순서.
* [`products/routing/code-demos`](/ko/products/routing/code-demos) — TypeScript에서 경로 구축하기.
* [`reference/program-addresses`](/ko/reference/program-addresses) — 자식 프로그램 ID.