> ## 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.

# node 스택 선택

> node의 용도에 따라 검토 날짜가 명시된 지원 정보를 바탕으로 OP Stack node의 consensus 클라이언트와 execution 클라이언트를 선택합니다.

이 가이드는 OP Stack node를 실행하려는 운영자를 위해 "어떤 클라이언트
소프트웨어를 써야 하는가?"라는 질문을 순서가 있는 의사 결정으로 바꿉니다.
먼저 두 클라이언트 구조를 확정하고, 지원이 종료된 소프트웨어를 배제한 다음,
execution 클라이언트와 consensus 클라이언트를 선택하고, 그 조합을 node가
수행하는 역할에 맞춥니다. 이 가이드는 Optimism이 유지 관리하는 소프트웨어를
중심으로 다룹니다. consensus 레이어의 `op-node`와 `kona-node`, execution
레이어의 `op-reth`, 그리고 특수 목적의 `op-supernode`와 레거시 Geth입니다.
지원 상태는 시간이 지나면서 변경됩니다. 이 페이지의 정보는 위의
`last-reviewed` 날짜 기준이며, 각 외부 링크에서 이를 다시 확인할 수 있습니다.

## 이 가이드가 적합한 대상

다음과 같은 경우 이 가이드를 사용하십시오.

* OP Stack 체인(OP
  Mainnet, 다른 OP Stack 체인 또는 자체 체인)의 새 node에 사용할 소프트웨어를 선택하거나, op-geth 지원 종료 이후 기존 node를
  재평가하는 경우.
* 설정 명령보다는 선택 근거를 알고 싶은 경우.

이미 스택을 정했고 바로 실행하려면
[Docker node 튜토리얼](https://docs.optimism.io/ko/node-operators/tutorials/node-from-docker.md) 또는
[소스 빌드 튜토리얼](https://docs.optimism.io/ko/node-operators/tutorials/run-node-from-source.md)로 바로
이동하십시오. sequencer를 포함하여 체인 출시 전체를 위한 인프라를 선택하는
경우에는
[결함 증명과 HA sequencing을 갖춘 체인 출시](https://docs.optimism.io/ko/use-cases/launch-a-chain-with-fault-proofs-and-ha-sequencing.md)를
참조하십시오.
node가 실행되지만 제대로 동작하지 않는다면
[문제 해결 가이드](https://docs.optimism.io/ko/node-operators/guides/troubleshooting.md)를 사용하십시오.

## 시작하기 전에

다음 사항을 미리 알고 있어야 합니다.

* node가 서비스하는 네트워크와 그 네트워크가
  [superchain-registry](https://docs.optimism.io/ko/op-stack/protocol/superchain-registry.md)에 등록되어 있는지 여부(레지스트리
  체인은 두 consensus 클라이언트 모두에서 이름으로 선택할 수 있으며, 사용자 지정 체인은
  자체 구성을 제공합니다).
* node가 수행하는 역할: 공개 RPC, 개인 검증자(verifier), sequencer,
  결함 증명(fault proof) 인프라 또는 아카이브/분석. 5단계는 이를 기준으로 합니다.
* 하드웨어 사양 범위.
  [시스템 요구 사항](https://docs.optimism.io/ko/node-operators/overview.md#system-requirements)을 읽고,
  OP Mainnet의 기본 사양이 16 GB RAM이라는 점과 아카이브 node는
  수 테라바이트의 NVMe가 필요하며 full node보다 훨씬 빠르게 증가한다는 점을 파악하십시오.

## 1단계: 구조 확정: consensus 클라이언트 하나, execution 클라이언트 하나

모든 OP Stack node는 두 개의 프로세스로 구성됩니다. 정식 체인을 파생하고
전달하는 consensus 클라이언트(rollup node)와 EVM을 실행하고 상태를 보관하는
execution 클라이언트이며, 이 둘은 인증된 Engine API를 통해 1:1로 연결됩니다.
[node 아키텍처 개요](https://docs.optimism.io/ko/node-operators/reference/architecture.md)를 읽고 다음을
파악하십시오.

* 두 클라이언트의 분리 구조와 각 RPC가 어느 쪽에 있는지. 여러분은 하나가 아니라
  두 가지 클라이언트를 선택해야 합니다.
* 1:1 규칙: 하나의 consensus 클라이언트 뒤에 여러 execution 클라이언트를 두거나
  그 반대로 구성해서는 절대 안 됩니다. 두 클라이언트 구성 가이드(3단계와
  4단계에서 읽을 문서) 모두 이 경고로 시작합니다.

## 2단계: 지원이 종료된 소프트웨어 배제

> [!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)를 참조하십시오.

[지원 종료 공지](https://docs.optimism.io/ko/notices/archive/op-geth-deprecation)를 읽고
2026-07-21 기준으로 다음을 파악하십시오.

* **op-geth는 어떤 새 node에도 후보가 될 수 없습니다.** 위의 경고를 참조하십시오.
* **op-program 역시 지원이 종료되었으며**, 결함 증명에서는 kona-client로
  대체되었습니다. 이는 일반적인 node 선택이 아니라 5단계의 결함 증명 행에
  영향을 줍니다.
* **op-node는 지원 중단(deprecated)되지 않았으며**, kona-node는 어떤 용도에도
  필수가 아닙니다. kona-client로의 결함 증명 마이그레이션은 일반 op-node와 함께
  작동합니다.

해당 공지 외에도 지원 종료된 소프트웨어가 하나 더 있습니다. **서드파티
execution 클라이언트인 op-erigon도 유지 관리자에 의해 지원 중단되었습니다.**
[서비스 종료 공지](https://www.sunnyside.io/blogs/sunsetting-op-erigon)를
참조하십시오. 이 역시 어떤 새 node에도 후보가 될 수 없습니다.

## 3단계: execution 클라이언트 선택

[execution 클라이언트 구성 가이드](https://docs.optimism.io/ko/node-operators/guides/configuration/execution-clients.md)를
읽고 각 클라이언트의 최소 구성과 전체 레퍼런스의 위치를 파악하십시오. 선택 로직은
다음과 같습니다.

| 조건 | 선택 | 이유 |
| - | - | - |
| node 역할과 관계없이 기본값을 원하는 경우 | op-reth | 주요 지원 execution 클라이언트이자 Optimism이 유지 관리하는 구현체입니다. 하드포크 지원을 포함한 새로운 OP Stack 기능 개발이 op-reth에서 이루어집니다. 2026-07-21 기준. |
| 기존 op-geth 배포인 경우 | op-reth로 마이그레이션 | op-geth는 지원이 종료되었습니다. [공지](https://docs.optimism.io/ko/notices/archive/op-geth-deprecation)에 마이그레이션 계획이 있습니다. |

Nethermind처럼 Optimism 외부에서 유지 관리되는 서드파티 execution 클라이언트도
있습니다. 이러한 클라이언트는 이 문서가 아니라 각자의 문서를 통해 구성되고
지원됩니다.

동기화 이후가 아니라 지금 결정해야 할 op-reth 후속 사항이 두 가지 있습니다.

* **아카이브 또는 full**: op-reth는 기본적으로 아카이브 node입니다. pruning된 full node를
  원하면 `--full`을 전달하십시오. body pruning은 지원되지 않습니다.
  [op-reth pruning](https://docs.optimism.io/ko/node-operators/guides/management/archive-node.md#pruning-op-reth)을 참조하십시오.
* **과거 증명(historical proofs)**: 무허가형(permissionless) 결함 증명 체인에서
  출금 증명을 제공하는 인프라에는 historical-proofs 저장소가 필요합니다
  (op-reth v2.2.3 이상).
  [과거 증명 튜토리얼](https://docs.optimism.io/ko/node-operators/tutorials/reth-historical-proofs.md)을 따르십시오.
  이 저장소는 활성화한 시점부터 앞으로만 채워지므로, 늦게 활성화한 node는
  그만큼의 기간 동안 실행될 때까지 전체 보존 기간을 제공할 수 없습니다.
  5단계에서 node 역할별로 결정하십시오.

## 4단계: consensus 클라이언트 선택

[consensus 클라이언트 구성 가이드](https://docs.optimism.io/ko/node-operators/guides/configuration/consensus-clients.md)를
읽고 각 클라이언트의 최소 플래그와 sequencer용 추가 설정을 파악하십시오. 선택
로직은 다음과 같습니다.

| 조건 | 선택 | 이유 |
| - | - | - |
| node 역할과 관계없이 기본값을 원하는 경우 | op-node | 레퍼런스 구현이며, 명시적으로 지원 중단되지 않았고, 기본 engine kind(`--l2.enginekind=reth`)가 이미 3단계의 기본값과 일치합니다. |
| 개발 중인 Rust consensus node를 사용해 보려는 경우 | kona-node | 태그된 릴리스, superchain-registry 지원, sequencer/conductor 통합을 제공하지만 아직 프로덕션 준비가 되지 않았습니다. 문서에서 실험적이며 활발히 개발 중이라고 명시하고 있으므로, 이를 감수할 수 있는 역할에 사용하십시오. 2026-07-21 기준. |
| node가 interop dependency set의 모든 체인을 따라가야 하는 경우 | op-supernode | 하나의 프로세스에서 체인별로 가상 op-node를 호스팅하고 크로스체인 메시지 검증을 추가합니다. v1.0.0부터 안정 릴리스를 제공하고 있으며, 현재 버전은 v1.0.4입니다. 2026-10-15 기준. |

조합에 관한 참고 사항: op-node의 `--l2.enginekind` 플래그는 Engine API 동작을
execution 클라이언트에 맞게 조정하며, 기본값이 `reth`이므로 3단계의 기본값에는
추가 플래그가 필요하지 않습니다. 다른 값은
[consensus 클라이언트 가이드](https://docs.optimism.io/ko/node-operators/guides/configuration/consensus-clients.md#l2-enginekind)에서
다룹니다.

## 5단계: 조합을 node의 역할에 맞추기

node 역할별로 두 선택을 연결하는 로직은 다음과 같습니다.

| node 유형 | 선택 | 이유 |
| - | - | - |
| 공개 RPC 또는 분석 node | op-node + op-reth 아카이브(기본값, pruning 플래그 없음) | 과거 상태 조회에는 아카이브 데이터가 필요하며, op-reth는 기본적으로 아카이브입니다. [네트워크 설계 예시](https://docs.optimism.io/ko/chain-operators/guides/management/network-architecture.md#public-rpc)에 따라 앞단을 구성하십시오. |
| 개인 검증자 또는 앱 팀 node | `--full`을 사용한 op-node + op-reth | pruning된 full node는 테라바이트가 아닌 수백 기가바이트 규모이며, 신뢰 없는(trustless) 검증에는 과거 상태가 필요하지 않습니다. |
| sequencer | op-node + op-reth, 고가용성을 위한 op-conductor 포함 | sequencer 플래그와 conductor 통합이 문서화된 프로덕션 경로입니다. 토폴로지는 [출시 가이드](https://docs.optimism.io/ko/use-cases/launch-a-chain-with-fault-proofs-and-ha-sequencing.md)에서 다룹니다. |
| 결함 증명 인프라(op-challenger 지원) | SafeDB를 사용하는 op-node + 과거 증명을 포함한 op-reth 아카이브 | challenger에는 SafeDB가 활성화된 rollup node와 proofs 저장소가 시드된 아카이브 execution 클라이언트가 필요합니다. 네 가지 엔드포인트에 대한 자세한 내용은 [challenger 가이드](https://docs.optimism.io/ko/use-cases/run-a-fault-proof-challenger.md#step-4-provision-the-four-endpoints)를 참조하십시오. |
| Bedrock 이전 데이터를 포함한 완전한 OP Mainnet 아카이브 | 3/4단계 조합 + [레거시 Geth](https://docs.optimism.io/ko/node-operators/guides/configuration/legacy-geth.md) | OP Mainnet의 Bedrock 이전(2023) 과거 조회는 별도의 레거시 node가 제공합니다. 그 외에는 필요하지 않습니다. |
| interop dependency set을 따라가는 경우 | op-supernode + 체인당 하나의 execution 클라이언트 | 하나의 프로세스가 체인별 op-node를 대체하며 L1 클라이언트와 beacon 연결을 공유합니다. [supernode 가이드](https://docs.optimism.io/ko/node-operators/guides/configuration/supernode.md)를 참조하십시오. |

## 6단계: 배포 및 선택 검증

[Docker node 튜토리얼](https://docs.optimism.io/ko/node-operators/tutorials/node-from-docker.md)(op-reth +
op-node를 하나의 compose 파일로 구성) 또는
[소스 빌드 튜토리얼](https://docs.optimism.io/ko/node-operators/tutorials/run-node-from-source.md)로 조합을
구동한 다음, 선택한 행에 맞게 동작하는지 확인하십시오.

* **버전**: 실행 중인 버전이
  [릴리스 페이지](https://docs.optimism.io/ko/releases.md)의 최신 안정 릴리스와 일치하는지 확인합니다. 이 페이지는 릴리스
  피드에서 다시 생성되므로, 이 가이드의 날짜가 명시된 내용이 최신인지 확인하는 기준이 됩니다.
* **동기화**: consensus 클라이언트의 `optimism_syncStatus`(
  [op-node JSON-RPC 레퍼런스](https://docs.optimism.io/ko/node-operators/reference/op-node-json-rpc.md#optimism_syncstatus) 참조)가
  공개 익스플로러에서 보이는 체인 헤드를 unsafe head가 따라가고 있음을 보여 주고,
  execution 클라이언트가 동기화 완료를 보고하는지 확인합니다.
* **디스크 사용 형태**: 아카이브 node의 디스크는 아카이브 node답게 증가합니다.
  full node로 실행하려 했는데 datadir가 테라바이트 규모로 커지고 있다면, 디스크가
  가득 차기 전에 3단계의 pruning 플래그를 다시 검토하십시오.
* **역할 확인**: 5단계에서 어떤 행을 선택했든, 그 핵심 기능을 한 번 실행해
  보십시오. 아카이브 node에서는 과거 상태 조회, challenger 인프라에서는
  `debug` 네임스페이스 증명 호출, supernode에서는 크로스체인 메시지 확인입니다.

## 다음 단계

* [op-node 구성 레퍼런스](https://docs.optimism.io/ko/node-operators/reference/op-node-config.md):
  페이지에 명시된 릴리스 태그의 op-node 플래그 정의에서 생성된 전체 플래그
  목록이며, 새로운 최종 릴리스가 게시되면 다시 생성됩니다.
* [op-reth 구성 레퍼런스](https://docs.optimism.io/ko/node-operators/reference/op-reth-config.md):
  가져온 op-reth CLI 레퍼런스(op-reth 소스 트리와 함께 버전 관리됨)와
  historical-proofs 구성 페이지로 안내합니다.
* [kona-node 문서](https://docs.optimism.io/ko/node-operators/kona-node/install/overview.md): 이 문서의
  노드 운영자 섹션에 있는 Rust consensus 클라이언트의 설치 및 실행 가이드입니다.
* [consensus 레이어 동기화](https://docs.optimism.io/ko/node-operators/reference/consensus-layer-sync.md):
  두 클라이언트의 동기화 방식을 조정할 때, execution 레이어(snap) 동기화가 권장
  모드인 이유와 consensus 레이어 동기화의 용도를 설명합니다.
* [reth.rs OP Stack 챕터](https://reth.rs/run/opstack): 업스트림
  op-reth 운영 문서입니다. reth 릴리스와 함께 유지 관리되는 외부 문서이며,
  2026-07-21 기준입니다.