ethereum-package로 기본 네트워크 실행 가이드

Kurtosis의 ethereum-package를 사용하여 로컬에서 이더리움 네트워크를 실행하는 방법을 알아봅니다. 다양한 클라이언트 조합과 기본 명령어부터 모니터링까지 단계별로 설명합니다.

---

목차

1. ethpandaops/ethereum-package 소개
2. 지원 클라이언트: Geth, Nethermind, Besu, Erigon
3. 기본 명령어로 네트워크 실행
4. 실행 결과 확인하기
5. 서비스 상태 모니터링
6. 네트워크 종료 및 정리

---

1. ethpandaops/ethereum-package 소개

김개발 씨는 블록체인 스타트업에 입사한 지 한 달이 지났습니다. 오늘 팀장님이 다가와 말했습니다.

"개발 씨, 이번 프로젝트에서 이더리움 테스트 네트워크가 필요한데, 직접 구축해 볼 수 있겠어요?" 김개발 씨는 당황했습니다. 이더리움 노드를 하나 돌리는 것도 복잡한데, 전체 네트워크를 구축하라니요.

ethereum-package는 Kurtosis 플랫폼 위에서 동작하는 이더리움 네트워크 배포 도구입니다. 마치 레고 블록을 조립하듯이 여러 클라이언트를 조합하여 완전한 이더리움 네트워크를 몇 분 만에 구축할 수 있습니다.

테스트넷, 개발 환경, 연구 목적 등 다양한 상황에서 유용하게 활용됩니다.

다음 코드를 살펴봅시다.

# Kurtosis 설치 (macOS)
brew install kurtosis-tech/tap/kurtosis-cli

# Kurtosis 엔진 시작
kurtosis engine start

# ethereum-package 저장소 확인
# GitHub: https://github.com/ethpandaops/ethereum-package

# 가장 간단한 네트워크 실행
kurtosis run github.com/ethpandaops/ethereum-package

# 특정 버전으로 실행
kurtosis run github.com/ethpandaops/ethereum-package@main

김개발 씨는 막막한 마음으로 인터넷 검색을 시작했습니다. 이더리움 노드 구축, 합의 클라이언트 설정, 실행 클라이언트 연결...

문서를 읽을수록 머리가 복잡해졌습니다. 그때 옆자리의 박시니어 씨가 말을 건넸습니다.

"혹시 ethereum-package 써봤어요? 요즘 대부분 그걸로 테스트 네트워크 구축하는데." ethereum-package란 무엇일까요?

쉽게 비유하자면, 이것은 마치 조립식 가구 키트와 같습니다. IKEA에서 가구를 사면 모든 부품과 설명서가 들어있어서 누구나 조립할 수 있잖아요?

ethereum-package도 마찬가지입니다. 이더리움 네트워크에 필요한 모든 구성 요소가 패키지로 묶여 있어서, 복잡한 설정 없이도 완전한 네트워크를 구축할 수 있습니다.

이 프로젝트는 ethPandaOps 팀에서 관리합니다. 이더리움 재단의 DevOps 팀으로, 실제 이더리움 테스트넷 운영 경험을 바탕으로 이 도구를 만들었습니다.

ethereum-package가 없던 시절에는 어땠을까요? 개발자들은 각 클라이언트를 일일이 설치하고, 제네시스 블록을 생성하고, 노드 간 피어링을 설정해야 했습니다.

Docker Compose 파일을 작성하고, 네트워크 설정을 조율하고, 버전 호환성을 맞추는 데만 며칠이 걸리기도 했습니다. 더 큰 문제는 재현성이었습니다.

"내 컴퓨터에서는 되는데?"라는 말이 개발팀 회의에서 자주 등장했습니다. 환경마다 미묘하게 다른 설정 때문에 같은 테스트도 결과가 달랐습니다.

바로 이런 문제를 해결하기 위해 ethereum-package가 등장했습니다. 이 도구는 Kurtosis라는 플랫폼 위에서 동작합니다.

Kurtosis는 분산 시스템을 패키징하고 배포하는 도구인데요, 컨테이너 오케스트레이션을 추상화하여 복잡한 인프라를 간단한 명령어로 관리할 수 있게 해줍니다. ethereum-package를 사용하면 몇 가지 큰 장점이 있습니다.

첫째, 일관성입니다. 누가 어디서 실행하든 동일한 네트워크가 구축됩니다.

둘째, 유연성입니다. 다양한 클라이언트 조합을 자유롭게 선택할 수 있습니다.

셋째, 편의성입니다. 명령어 한 줄로 전체 네트워크가 실행됩니다.

설치는 간단합니다. macOS에서는 Homebrew로 Kurtosis CLI를 설치하고, 엔진을 시작하면 준비 완료입니다.

박시니어 씨의 조언을 들은 김개발 씨는 바로 설치를 시작했습니다. 생각보다 훨씬 간단했습니다.

"이렇게 쉬운 거였어요?" 김개발 씨의 눈이 반짝였습니다.

실전 팁

💡 - Kurtosis는 Docker를 기반으로 동작하므로 Docker Desktop이 먼저 설치되어 있어야 합니다

• 최신 기능을 사용하려면 @main 태그를 붙여 실행하세요

---

2. 지원 클라이언트: Geth, Nethermind, Besu, Erigon

김개발 씨가 ethereum-package 문서를 읽다가 궁금한 점이 생겼습니다. "실행 클라이언트가 여러 개 있는데, 이게 다 뭐예요?" 박시니어 씨가 커피를 한 모금 마시며 설명을 시작했습니다.

"이더리움의 철학 중 하나가 바로 클라이언트 다양성이야. 하나의 소프트웨어에 의존하면 위험하거든."

이더리움은 클라이언트 다양성을 중요하게 생각합니다. ethereum-package는 Geth, Nethermind, Besu, Erigon 등 다양한 실행 클라이언트와 Lighthouse, Prysm, Teku 등의 합의 클라이언트를 지원합니다.

이를 통해 실제 메인넷과 유사한 다양한 환경을 테스트할 수 있습니다.

다음 코드를 살펴봅시다.

# 실행 클라이언트 (Execution Layer)
# - geth: Go로 작성된 공식 클라이언트
# - nethermind: C#/.NET 기반, 엔터프라이즈에 강함
# - besu: Java 기반, Hyperledger 프로젝트
# - erigon: 효율성에 초점을 맞춘 Go 클라이언트
# - reth: Rust로 작성된 최신 클라이언트

# 합의 클라이언트 (Consensus Layer)
# - lighthouse: Rust 기반
# - prysm: Go 기반
# - teku: Java 기반
# - lodestar: TypeScript 기반
# - nimbus: Nim 기반

# 특정 클라이언트 조합으로 실행 (YAML 설정)
participants:
  - el_type: geth
    cl_type: lighthouse
  - el_type: nethermind
    cl_type: prysm

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "이더리움 노드는 크게 두 부분으로 나뉘어.

실행 계층과 합의 계층." 이것을 레스토랑에 비유해 보겠습니다. 실행 클라이언트는 주방장과 같습니다.

주문(트랜잭션)을 받아서 실제로 요리(실행)하고, 결과물을 만들어냅니다. 스마트 컨트랙트를 실행하고, 상태를 관리하는 역할을 합니다.

합의 클라이언트는 매니저와 같습니다. 여러 주방장들이 같은 메뉴를 만들고 있는지 확인하고, 어떤 요리가 정식 메뉴인지 합의합니다.

블록을 제안하고 검증하며, 네트워크의 합의를 이끌어냅니다. 주요 실행 클라이언트를 살펴보겠습니다.

Geth는 이더리움 재단이 관리하는 공식 클라이언트입니다. Go 언어로 작성되었고, 가장 오래되고 검증된 구현체입니다.

대부분의 노드가 Geth를 사용하는데, 이것이 오히려 문제가 되기도 합니다. 특정 클라이언트에 버그가 있으면 네트워크 전체가 위험해질 수 있거든요.

Nethermind는 C#과 .NET으로 작성되었습니다. 엔터프라이즈 환경에 최적화되어 있고, 플러그인 시스템이 잘 갖춰져 있습니다.

성능도 우수해서 점점 점유율이 높아지고 있습니다. Besu는 Java로 작성된 클라이언트입니다.

Hyperledger 프로젝트의 일부로, 기업용 기능이 풍부합니다. 프라이빗 네트워크 구축에 특히 강점이 있습니다.

Erigon은 효율성에 초점을 맞춘 클라이언트입니다. 원래 Turbo-Geth라는 이름이었는데, 독립 프로젝트가 되면서 이름이 바뀌었습니다.

디스크 사용량이 적고 동기화 속도가 빠릅니다. 최근에는 Reth라는 새로운 클라이언트도 주목받고 있습니다.

Rust로 작성되어 안정성과 성능을 동시에 추구합니다. 합의 클라이언트도 여러 종류가 있습니다.

Lighthouse(Rust), Prysm(Go), Teku(Java), Lodestar(TypeScript), Nimbus(Nim) 등 다양한 언어로 구현되어 있습니다. "왜 이렇게 많은 클라이언트가 필요해요?" 김개발 씨가 물었습니다.

박시니어 씨가 대답했습니다. "2016년 상하이 공격을 기억해?

당시 Geth에만 있던 버그 때문에 네트워크가 위험해졌어. 그때 다른 클라이언트들이 없었다면 상황이 더 심각했을 거야." 클라이언트 다양성은 네트워크의 회복력을 높여줍니다.

한 클라이언트에 문제가 생겨도 다른 클라이언트들이 네트워크를 유지할 수 있습니다. ethereum-package를 사용하면 이런 다양한 클라이언트 조합을 쉽게 테스트할 수 있습니다.

실제 메인넷처럼 여러 클라이언트가 섞인 환경을 로컬에서 재현할 수 있는 것입니다.

실전 팁

💡 - 프로덕션 환경에서는 점유율이 낮은 클라이언트를 선택하는 것이 네트워크에 기여하는 방법입니다

• 각 클라이언트마다 장단점이 다르므로 용도에 맞게 선택하세요

---

3. 기본 명령어로 네트워크 실행

드디어 실습 시간입니다. 김개발 씨는 터미널을 열고 손가락을 키보드 위에 올렸습니다.

"자, 이제 진짜로 네트워크를 띄워볼까?" 박시니어 씨가 옆에서 지켜보며 말했습니다. "기본 명령어부터 시작해보자.

놀랍도록 간단해."

ethereum-package의 기본 실행은 kurtosis run 명령어 하나로 시작됩니다. 별도의 설정 파일 없이도 기본값으로 완전한 네트워크가 구축됩니다.

커스텀 설정이 필요하면 YAML 파일을 인자로 전달할 수 있습니다.

다음 코드를 살펴봅시다.

# 가장 기본적인 실행 (기본 설정 사용)
kurtosis run github.com/ethpandaops/ethereum-package

# 설정 파일을 사용한 실행
kurtosis run github.com/ethpandaops/ethereum-package \
  --args-file network_params.yaml

# network_params.yaml 예시
participants:
  - el_type: geth
    cl_type: lighthouse
    count: 2
  - el_type: nethermind
    cl_type: prysm
    count: 1

network_params:
  network_id: "3151908"
  seconds_per_slot: 12

김개발 씨가 터미널에 명령어를 입력했습니다. kurtosis run github.com/ethpandaops/ethereum-package 화면에 로그가 쏟아지기 시작했습니다.

Docker 이미지를 다운로드하고, 컨테이너를 생성하고, 네트워크를 구성하는 과정이 눈앞에서 펼쳐졌습니다. "와, 이게 다 자동으로 되는 거예요?" 김개발 씨가 놀라며 물었습니다.

박시니어 씨가 고개를 끄덕였습니다. "기본 설정으로 실행하면 Geth와 Lighthouse 조합으로 네트워크가 구축돼.

간단하지?" 하지만 실무에서는 보통 커스텀 설정이 필요합니다. 이때 사용하는 것이 YAML 설정 파일입니다.

설정 파일의 구조를 살펴보겠습니다. participants 섹션은 네트워크에 참여할 노드들을 정의합니다.

각 참여자마다 실행 클라이언트(el_type)와 합의 클라이언트(cl_type)를 지정하고, count로 해당 조합의 노드 수를 설정합니다. 예를 들어 위의 설정은 Geth+Lighthouse 노드 2개와 Nethermind+Prysm 노드 1개로 구성된 네트워크를 만듭니다.

network_params 섹션은 네트워크 자체의 설정을 담당합니다. network_id는 체인 ID를 지정하고, seconds_per_slot은 블록 생성 간격을 설정합니다.

기본값은 12초인데, 테스트 목적으로 더 짧게 설정할 수도 있습니다. "그럼 이 설정 파일은 어디에 만들어요?" 김개발 씨가 물었습니다.

"아무 디렉토리에나 만들면 돼. 중요한 건 --args-file 옵션으로 경로를 지정하는 거야." 설정 파일을 만들어 실행해 보겠습니다.

먼저 network_params.yaml 파일을 생성합니다. 그리고 원하는 설정을 작성한 뒤, kurtosis run 명령어에 --args-file 옵션을 추가합니다.

명령어가 실행되면 Kurtosis는 먼저 enclave라는 격리된 환경을 생성합니다. enclave는 마치 가상의 데이터센터와 같아서, 이 안에서 모든 컨테이너가 동작합니다.

다음으로 각 노드의 컨테이너가 순차적으로 생성됩니다. 실행 클라이언트가 먼저 뜨고, 그 다음 합의 클라이언트가 연결됩니다.

노드 간 피어링도 자동으로 설정됩니다. "여기서 잠깐!" 박시니어 씨가 중요한 점을 짚었습니다.

"처음 실행할 때는 Docker 이미지를 다운로드해야 해서 시간이 좀 걸려. 하지만 두 번째부터는 캐시된 이미지를 사용하니까 훨씬 빨라질 거야." 김개발 씨는 명령어를 실행하고 결과를 기다렸습니다.

약 3분 후, 화면에 성공 메시지가 나타났습니다.

실전 팁

💡 - 처음 실행 시 이미지 다운로드로 5-10분 정도 소요될 수 있습니다

• 설정 파일은 버전 관리하여 팀원들과 동일한 환경을 공유하세요

---

4. 실행 결과 확인하기

명령어 실행이 완료되었습니다. 터미널에는 알 수 없는 출력들이 가득했습니다.

"이게 성공한 건가요?" 김개발 씨가 조심스럽게 물었습니다. 박시니어 씨가 웃으며 대답했습니다.

"이제 결과를 확인하는 방법을 알려줄게. 생각보다 직관적이야."

네트워크 실행이 완료되면 Kurtosis는 enclave 정보와 서비스 목록을 출력합니다. kurtosis enclave inspect 명령어로 상세 정보를 확인할 수 있고, 각 서비스의 포트 정보를 통해 RPC 엔드포인트에 접근할 수 있습니다.

다음 코드를 살펴봅시다.

# 실행 중인 enclave 목록 확인
kurtosis enclave ls

# 특정 enclave 상세 정보 확인
kurtosis enclave inspect my-testnet

# 출력 예시:
# Name: my-testnet
# Status: RUNNING
# Services:
#   el-1-geth-lighthouse    RUNNING    8545/tcp -> 127.0.0.1:32845
#   cl-1-lighthouse-geth    RUNNING    4000/tcp -> 127.0.0.1:32846
#   validator-1             RUNNING

# 특정 서비스의 로그 확인
kurtosis service logs my-testnet el-1-geth-lighthouse

# RPC 엔드포인트 테스트
curl -X POST http://127.0.0.1:32845 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

김개발 씨는 터미널에 표시된 출력을 유심히 살펴보았습니다. 처음 보는 용어들이 많았지만, 박시니어 씨의 설명과 함께 하나씩 이해해 나갔습니다.

먼저 enclave라는 개념부터 알아봅시다. Kurtosis에서 enclave는 격리된 테스트 환경을 의미합니다.

마치 실험실의 무균실과 같습니다. 외부와 격리되어 있어서 다른 테스트에 영향을 주거나 받지 않습니다.

여러 enclave를 동시에 실행할 수 있어서, 다양한 설정의 네트워크를 병렬로 테스트할 수 있습니다. kurtosis enclave ls 명령어를 실행하면 현재 실행 중인 모든 enclave 목록이 나타납니다.

"여기 보이는 이 이름은 뭐예요?" 김개발 씨가 화면을 가리키며 물었습니다. "enclave 이름이야.

기본값으로 랜덤하게 생성되는데, 실행할 때 직접 지정할 수도 있어." 이름을 지정하려면 --enclave 옵션을 사용합니다. kurtosis run github.com/ethpandaops/ethereum-package --enclave my-testnet 이제 kurtosis enclave inspect 명령어로 상세 정보를 확인해 보겠습니다.

출력에서 가장 중요한 것은 서비스 목록과 포트 매핑입니다. 서비스 이름은 규칙이 있습니다.

el-1-geth-lighthouse는 "실행 클라이언트 1번, Geth 사용, Lighthouse와 페어"라는 의미입니다. cl-1-lighthouse-geth는 그 반대로 "합의 클라이언트 1번"을 나타냅니다.

포트 매핑을 보면 8545/tcp -> 127.0.0.1:32845 같은 형식이 보입니다. 8545는 Geth의 기본 RPC 포트이고, 32845는 호스트에서 접근할 수 있는 실제 포트입니다.

"그럼 이 포트로 RPC 요청을 보낼 수 있는 거죠?" 김개발 씨가 물었습니다. "맞아!

curl로 간단히 테스트해볼 수 있어." 박시니어 씨가 예제 명령어를 보여주었습니다. eth_blockNumber 메서드를 호출하면 현재 블록 높이를 확인할 수 있습니다.

응답이 돌아왔습니다. result 필드에 16진수 값이 보입니다.

0x5라면 5번 블록까지 생성되었다는 의미입니다. "블록이 계속 생성되고 있네요!" 김개발 씨가 신기해하며 말했습니다.

로그를 확인하고 싶다면 kurtosis service logs 명령어를 사용합니다. 실시간으로 로그를 보려면 -f 옵션을 추가하면 됩니다.

이제 김개발 씨는 자신이 구축한 네트워크가 정상적으로 동작하고 있음을 확인할 수 있었습니다.

실전 팁

💡 - 포트 번호는 매번 달라질 수 있으니 inspect 명령어로 확인 후 사용하세요

• 여러 enclave를 동시에 실행할 때는 이름을 명확하게 지정하면 관리가 편합니다

---

5. 서비스 상태 모니터링

네트워크가 실행되고 있다는 것을 확인했습니다. 하지만 김개발 씨는 궁금했습니다.

"노드들이 제대로 동기화되고 있는지, 검증자가 잘 동작하는지 어떻게 알 수 있어요?" 박시니어 씨가 대답했습니다. "좋은 질문이야.

ethereum-package는 모니터링 도구도 함께 제공해."

ethereum-package는 선택적으로 Grafana, Prometheus 같은 모니터링 도구를 함께 배포할 수 있습니다. 설정 파일에서 활성화하면 대시보드를 통해 네트워크 상태, 노드 동기화 현황, 검증자 성능 등을 시각적으로 확인할 수 있습니다.

다음 코드를 살펴봅시다.

# 모니터링 도구가 포함된 설정 파일
participants:
  - el_type: geth
    cl_type: lighthouse
    count: 2

additional_services:
  - prometheus_grafana
  - dora
  - tx_spammer

# 실행 후 Grafana 포트 확인
kurtosis enclave inspect my-testnet | grep grafana

# Dora 블록 탐색기 접속
# 출력된 포트로 브라우저에서 접속
# http://localhost:포트번호

# Prometheus 메트릭 직접 조회
curl http://localhost:프로메테우스포트/api/v1/query?query=ethereum_beacon_head_slot

박시니어 씨가 새로운 설정 파일을 작성하기 시작했습니다. "실제 운영 환경에서는 모니터링이 필수야.

다행히 ethereum-package가 이것도 지원해." additional_services 섹션을 추가하면 다양한 보조 서비스를 함께 배포할 수 있습니다. 먼저 prometheus_grafana를 살펴보겠습니다.

Prometheus는 메트릭 수집 도구입니다. 각 노드의 CPU 사용량, 메모리, 블록 동기화 상태 등의 데이터를 주기적으로 수집합니다.

Grafana는 이 데이터를 시각화하는 대시보드입니다. 이 둘을 활성화하면 마치 자동차 계기판처럼 네트워크 상태를 한눈에 볼 수 있습니다.

"Grafana에 접속하려면 어떻게 해요?" 김개발 씨가 물었습니다. inspect 명령어의 출력에서 grafana 서비스를 찾으면 됩니다.

포트 번호를 확인한 뒤 브라우저에서 http://localhost:포트번호로 접속합니다. 기본 계정은 보통 admin/admin입니다.

로그인하면 미리 구성된 대시보드가 나타납니다. 블록 생성 현황, 검증자 성능, 네트워크 대역폭 등을 실시간으로 확인할 수 있습니다.

다음으로 Dora입니다. Dora는 이더리움 비콘 체인용 블록 탐색기입니다.

Etherscan처럼 블록과 트랜잭션을 조회할 수 있지만, 로컬 테스트넷 전용입니다. Dora를 통해 생성된 블록 목록, 검증자 상태, 에폭 정보 등을 웹 인터페이스로 확인할 수 있습니다.

특히 합의 계층의 동작을 디버깅할 때 유용합니다. tx_spammer도 흥미로운 서비스입니다.

이름 그대로 테스트 트랜잭션을 자동으로 생성합니다. 빈 블록만 생성되면 재미없잖아요?

tx_spammer를 활성화하면 네트워크에 지속적으로 트랜잭션이 발생하여 더 현실적인 테스트 환경을 만들 수 있습니다. "이거 진짜 유용하네요!" 김개발 씨가 Grafana 대시보드를 보며 감탄했습니다.

박시니어 씨가 덧붙였습니다. "프로젝트에서 성능 테스트할 때 이 환경이 정말 도움이 돼.

실제 메인넷 배포 전에 여기서 충분히 검증할 수 있거든." 모니터링 도구를 통해 김개발 씨는 네트워크의 건강 상태를 실시간으로 파악할 수 있게 되었습니다. 블록이 정상적으로 생성되고 있는지, 모든 노드가 동기화되어 있는지, 검증자들이 제 역할을 하고 있는지를 한눈에 확인할 수 있었습니다.

실전 팁

💡 - Grafana 대시보드는 커스터마이징할 수 있으니 프로젝트에 맞게 수정해서 사용하세요

• tx_spammer는 테스트 목적으로만 사용하고, 실제 서비스에는 포함하지 마세요

---

6. 네트워크 종료 및 정리

테스트가 끝났습니다. 김개발 씨는 터미널을 정리하려고 했습니다.

"이제 이 네트워크를 어떻게 끄죠? 그냥 터미널을 닫으면 되나요?" 박시니어 씨가 고개를 저었습니다.

"아니, 제대로 정리하는 방법이 있어. 안 그러면 Docker 리소스가 계속 남아있을 수 있거든."

Kurtosis에서 네트워크를 종료하려면 kurtosis enclave stop과 kurtosis enclave rm 명령어를 사용합니다. 또는 kurtosis clean으로 모든 리소스를 한 번에 정리할 수 있습니다.

사용하지 않는 enclave를 정리하면 디스크 공간을 확보하고 시스템 리소스를 절약할 수 있습니다.

다음 코드를 살펴봅시다.

# 특정 enclave 중지 (컨테이너 정지, 데이터 유지)
kurtosis enclave stop my-testnet

# 특정 enclave 삭제 (데이터까지 완전 삭제)
kurtosis enclave rm my-testnet

# 중지 후 삭제 (한 번에)
kurtosis enclave rm my-testnet --force

# 모든 enclave 정리 (전체 초기화)
kurtosis clean --all

# 엔진 상태 확인
kurtosis engine status

# 엔진 완전 종료 (필요한 경우)
kurtosis engine stop

# Docker 리소스 직접 확인
docker ps -a | grep kurtosis
docker volume ls | grep kurtosis

김개발 씨가 고개를 끄덕였습니다. "그러고 보니 Docker를 쓰니까 컨테이너가 계속 돌아가고 있겠네요." "맞아.

Kurtosis가 관리해주긴 하지만, 정리는 직접 해줘야 해." 네트워크 정리에는 단계가 있습니다. 첫 번째 단계는 enclave 중지입니다.

kurtosis enclave stop 명령어를 실행하면 모든 컨테이너가 정지됩니다. 하지만 데이터는 유지되므로 나중에 다시 시작할 수 있습니다.

"다시 시작하려면 어떻게 해요?" 안타깝게도 Kurtosis는 enclave 재시작 기능을 직접 제공하지 않습니다. 중지된 enclave를 다시 쓰려면 새로 만들어야 합니다.

따라서 보통은 중지와 삭제를 함께 합니다. 두 번째 단계는 enclave 삭제입니다.

kurtosis enclave rm 명령어로 enclave를 완전히 삭제합니다. 이때 관련된 모든 컨테이너, 볼륨, 네트워크가 함께 제거됩니다.

실행 중인 enclave를 바로 삭제하려면 --force 옵션을 추가합니다. 중지와 삭제를 한 번에 처리할 수 있어 편리합니다.

세 번째는 전체 정리입니다. kurtosis clean --all 명령어는 모든 enclave를 한꺼번에 정리합니다.

테스트를 마치고 완전히 초기화하고 싶을 때 유용합니다. "이거 실수로 실행하면 안 되겠네요." 김개발 씨가 조심스럽게 말했습니다.

박시니어 씨가 웃었습니다. "맞아, 중요한 테스트 중에는 조심해야 해.

하지만 로컬 개발 환경에서는 자주 쓰게 될 거야." 가끔은 Kurtosis가 제대로 정리하지 못한 리소스가 남아있을 수 있습니다. 그럴 때는 Docker 명령어로 직접 확인하고 정리해야 합니다.

docker ps -a | grep kurtosis로 Kurtosis 관련 컨테이너를 확인하고, docker volume ls | grep kurtosis로 볼륨을 확인합니다. 필요하면 docker rm이나 docker volume rm으로 직접 삭제할 수 있습니다.

마지막으로, Kurtosis 엔진 자체를 종료하려면 kurtosis engine stop을 사용합니다. 엔진이 종료되면 새로운 enclave를 만들 수 없으니, 다시 사용할 때는 kurtosis engine start로 시작해야 합니다.

김개발 씨는 테스트 네트워크를 깔끔하게 정리했습니다. 터미널에 "Enclave removed" 메시지가 표시되자 뿌듯한 미소가 번졌습니다.

"오늘 정말 많이 배웠어요. 이더리움 네트워크를 직접 구축하고 모니터링하고 정리하는 것까지!" 박시니어 씨가 어깨를 두드렸습니다.

"이제 기초는 다 익혔어. 다음에는 커스텀 제네시스 설정이나 포크 테스트도 해보자." 김개발 씨의 블록체인 개발 여정은 이제 막 시작되었습니다.

실전 팁

💡 - 퇴근 전에 kurtosis clean --all을 실행하는 습관을 들이면 다음 날 깔끔한 환경에서 시작할 수 있습니다

• 중요한 테스트 데이터는 enclave 삭제 전에 내보내기 해두세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!