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

# archive node 실행하기

> archive node를 구성하고 실행하는 방법을 알아봅니다.

이 가이드는 node를 archive node로 실행하도록 구성하는 방법을 보여 줍니다. archive node는 모든 과거 상태를 포함한 블록체인의 전체 기록을 저장합니다.

## 개요

archive node는 블록체인의 전체 상태 기록을 유지하므로, 모든 블록 높이에서 과거 상태를 조회할 수 있습니다. 이는 다음과 같은 경우에 유용합니다.

* 과거 데이터를 제공해야 하는 블록 탐색기
* 분석 및 데이터 분석 애플리케이션
* 과거 상태를 조회해야 하는 서비스
* 디버깅 및 감사 목적

archive node는 실행 레이어 동기화(execution-layer sync)를 사용하지만, 실행 클라이언트가 과거 상태 데이터를 프루닝하지 않고 모두 보존하도록 구성합니다.

> [!NOTE]
>
> 과거 블록에서 암호학적 상태 증명(`eth_getProof`)만 필요한 경우, 과거 증명(historical proofs)은 전체 archive node보다 가벼운 대안입니다. 일반적인 사례는 출금 증명 및 결함 증명(fault proof) 워크로드입니다. 과거 실행(`eth_call`, `debug_trace*`)이나 임의의 과거 상태 조회가 필요한 경우에는 여전히 전체 archive node가 필요합니다. [과거 증명 구성](https://docs.optimism.io/ko/node-operators/reference/op-reth-historical-proof-config.md)을 참조하십시오.

## 요구 사항

* **OP Mainnet**: [bedrock datadir](https://docs.optimism.io/ko/op-mainnet/network-information/snapshots.md)가 필요합니다
* **기타 OP Stack 네트워크**: datadir가 필요하지 않습니다
* **스토리지**: archive node는 일반 node보다 훨씬 많은 디스크 공간이 필요합니다(OP Mainnet의 경우 수 테라바이트)
* **동기화 시간**: 실행 레이어 모드를 사용한 archive 동기화는 블록 단위로 전체를 실행하는 방식보다 빠릅니다

## 구성

아래 각 섹션은 archive node로 실행하기 위해 `op-node`와 선택한 실행 클라이언트 모두에 필요한 전체 플래그를 보여 줍니다. `op-node` 플래그 `--syncmode=execution-layer`는 모든 경우에 필수이며 기본값이 아니므로 반드시 명시적으로 구성해야 합니다.

### op-reth

op-reth는 프루닝 플래그 없이 실행하면 전체 상태를 보존하므로, 표준 op-node + op-reth 구성만으로도 archive node가 됩니다.

`op-node`에 설정합니다.

```shell theme={null}
--syncmode=execution-layer
```

완전한 archive node를 위해서는 op-reth에 `--prune.*` 플래그를 전달하지 마십시오. 전체 기록이 필요하지 않고 디스크 공간을 확보하려면 아래의 [op-reth 프루닝](#pruning-op-reth)을 참조하십시오.

### Nethermind

`op-node`에 설정합니다.

```shell theme={null}
--syncmode=execution-layer
```

archive 네트워크 구성을 사용하여 Nethermind에서 archive 모드를 활성화합니다.

```shell theme={null}
--config op-mainnet_archive
```

> [!NOTE]
>
> `op-mainnet_archive`를 네트워크에 맞는 archive 구성으로 바꾸십시오(예: OP Sepolia의 경우 `op-sepolia_archive`).

### op-geth

> [!WARNING]
>
> **op-geth는 지원이 종료되었으며(2026-05-31) 현재 활성화된 Karst 하드포크를 지원하지 않으므로, op-geth node는 더 이상 정식(canonical) 체인을 따라갈 수 없습니다.** 주요 지원 실행 클라이언트인 op-reth로 마이그레이션하십시오. 전체 마이그레이션 계획은 [op-geth 지원 중단 공지](https://docs.optimism.io/ko/notices/archive/op-geth-deprecation)를 참조하십시오.

`op-node`에 설정합니다.

```shell theme={null}
--syncmode=execution-layer
```

`op-geth`에 설정합니다.

```shell theme={null}
--syncmode=full
--gcmode=archive
```

> [!NOTE]
>
> 두 플래그 모두 기본 설정이 아니므로 명시적으로 구성해야 합니다. `--syncmode=full` 플래그는 모든 블록이 실행되도록 보장하며, `--gcmode=archive`는 상태 프루닝을 비활성화합니다.

## Pruning op-reth

완전한 archive node가 필요하지 않다면 op-reth를 프루닝하여 디스크 공간을 확보할 수 있습니다. 권장 방식은 모든 블록 본문을 유지하면서 state와 receipt를 프루닝하는 것입니다.

### 권장: state와 receipt를 프루닝하고 블록 본문은 유지

state 및 receipt 세그먼트를 프루닝하고 블록 본문은 그대로 유지합니다. 각 항목에 동일한 깊이를 설정하십시오.

```shell theme={null}
--prune.minimum-distance=<depth>
--prune.receipts.distance=<depth>
--prune.account-history.distance=<depth>
--prune.storage-history.distance=<depth>
```

프로덕션 환경에 맞춘 권장 `<depth>`(블록 단위)는 다음과 같습니다.

* sequencer 측 node의 경우 **`22000`** — 12시간의 시퀀싱 윈도우(2초 블록 시간 기준 약 21,600 블록)를 포함합니다.
* 더 많은 기록이 필요한 node의 경우 **`1296000`**(2초 기준 약 30일).

### 블록 본문 프루닝(지원되지 않음)

op-node의 safe 도출(derivation)은 tip에서 [`--syncmode.offset-el-safe`](https://docs.optimism.io/ko/node-operators/reference/op-node-config#syncmode-offset-el-safe)만큼 뒤에 위치한 head의 블록 본문에서 L1-info 입금(디파짓) 트랜잭션(모든 블록의 첫 번째 트랜잭션)을 읽으며, safedb를 복원하는 경우에는 그보다 더 뒤에서 읽을 수도 있습니다. 해당 본문이 프루닝된 경우 EL 동기화는 `l2 block is missing L1 info deposit tx` 오류와 함께 실패합니다.

따라서 본문 프루닝은 **지원되지 않으며, 사용하지 않을 것을 권고합니다**. 사용할 경우 보장 없이 본인의 책임하에 실행하게 됩니다. 무엇을 하는지 잘 알고 있다면 작동하게 만들 수 있지만, 한 가지 엄격한 요구 사항이 있습니다. 보존되는 본문 윈도우가 항상 `--syncmode.offset-el-safe` 범위를 포함해야 합니다. 구체적으로, [`--prune.bodies.distance`](https://docs.optimism.io/ko/node-operators/op-reth/cli/op-reth/node)(블록 단위)를 블록으로 환산한 offset(기본값 `12h`는 2초 블록 시간 기준 약 21,600)보다 충분히 **크게** 설정하고, 실제로 사용하는 블록 시간과 offset에 맞게 여유를 두십시오. 또한 safedb를 복원하는 경우 해당 head까지의 최대 거리도 고려해야 합니다.

op-reth는 시작 시 `--minimal`을 거부합니다. 이 옵션은 본문을 고정된 10,064 블록 윈도우로 프루닝하는데, 이는 기본 offset보다 작으며 독립적으로 늘릴 수 없습니다.

> [!WARNING]
>
> 본문 프루닝은 지원되지 않습니다. 그럼에도 활성화하는 경우, `--prune.bodies.distance`는 항상 `--syncmode.offset-el-safe`(블록 단위)보다 커야 하며, 추가로 복원 중인 safedb의 head까지의 거리보다도 커야 합니다. 그렇지 않으면 실행 레이어 동기화가 `l2 block is missing L1 info deposit tx` 오류와 함께 실패합니다. 위의 state 및 receipt 세그먼트만 프루닝하는 방식을 권장합니다.

## archive 동기화의 작동 방식

실행 레이어 동기화 모드가 활성화되면 다음과 같이 동작합니다.

1. **초기 동기화**: node가 P2P 네트워크를 통해 블록 헤더와 데이터를 다운로드합니다
2. **블록 실행**: node가 체인의 모든 블록을 실행하여 전체 상태 기록을 구축합니다
3. **상태 보존**: 일반 node와 달리 archive node는 과거 상태 데이터를 절대 프루닝하지 않습니다
4. **레거시보다 빠름**: 여전히 모든 블록을 실행하지만, 블록 데이터를 L1에서 도출하는 대신 P2P를 통해 가져오므로 레거시 합의 레이어 동기화보다 빠릅니다

## 스토리지 고려 사항

archive node에는 상당한 스토리지가 필요합니다.

* **OP Mainnet**: 수 테라바이트이며 계속 증가합니다
* **기타 네트워크**: 네트워크의 운영 기간과 활동량에 따라 다릅니다
* **증가율**: 새 블록이 추가됨에 따라 스토리지 요구량이 지속적으로 증가합니다
* **권장 사항**: 최적의 성능을 위해 빠른 SSD 스토리지를 사용하십시오

## 다음 단계

* archive가 아닌 node의 동기화 구성은 [동기화 모드 레퍼런스](https://docs.optimism.io/ko/node-operators/reference/consensus-layer-sync.md)를 참조하십시오
* 추가 설명이나 사용자 지정은 [합의 클라이언트 구성](https://docs.optimism.io/ko/node-operators/guides/configuration/consensus-clients.md) 및 [실행 클라이언트 구성](https://docs.optimism.io/ko/node-operators/guides/configuration/execution-clients.md) 가이드를 참조하십시오
* bedrock datadir 다운로드에 대한 정보는 [스냅샷 가이드](https://docs.optimism.io/ko/op-mainnet/network-information/snapshots.md)를 참조하십시오
* 이 과정의 어느 단계에서든 어려움이 있으면 [개발자 지원](https://github.com/ethereum-optimism/developers/discussions)에 문의하십시오