커스텀 네트워크 설정 YAML 작성 완벽 가이드

이더리움 로컬 테스트넷을 구축할 때 필요한 YAML 설정 파일 작성법을 다룹니다. network_params.yaml의 구조부터 EL/CL 클라이언트 설정, 네트워크 파라미터 커스터마이징까지 초급 개발자도 쉽게 따라할 수 있도록 설명합니다.

---

목차

1. network_params.yaml 구조 이해
2. participants 설정 (EL/CL 클라이언트)
3. el_client_type과 cl_client_type 옵션
4. network_params 커스터마이징
5. network_id와 seconds_per_slot 설정
6. --args-file 옵션으로 실행하기

---

1. network params.yaml 구조 이해

어느 날 김개발 씨는 이더리움 로컬 테스트넷을 구축하라는 미션을 받았습니다. 선배가 건네준 파일은 network_params.yaml이라는 낯선 이름의 설정 파일이었습니다.

"이게 대체 뭐죠?" 김개발 씨는 고개를 갸웃거렸습니다.

network_params.yaml은 이더리움 로컬 테스트넷의 청사진입니다. 마치 건축가가 집을 짓기 전에 설계도를 그리듯, 이 파일에 네트워크의 모든 구성 요소를 정의합니다.

어떤 클라이언트를 사용할지, 네트워크 ID는 무엇인지, 블록 생성 주기는 얼마인지 모두 이 한 파일에 담깁니다.

다음 코드를 살펴봅시다.

# network_params.yaml 기본 구조
# 최상위 레벨에는 두 가지 핵심 섹션이 있습니다

participants:
  # 네트워크에 참여할 노드들을 정의합니다
  - el_client_type: geth
    cl_client_type: lighthouse
    count: 2

network_params:
  # 네트워크 전반의 설정을 정의합니다
  network_id: "3151908"
  seconds_per_slot: 12

additional_services:
  # 선택적으로 추가 서비스를 구성합니다
  - blockscout

김개발 씨는 입사 6개월 차 블록체인 개발자입니다. 회사에서 새로운 스마트 컨트랙트를 개발하게 되었는데, 테스트를 위해 로컬 이더리움 네트워크가 필요했습니다.

선배 박시니어 씨가 Kurtosis라는 도구를 추천해 주었습니다. "Kurtosis를 쓰면 로컬에서 완전한 이더리움 네트워크를 띄울 수 있어요.

근데 먼저 이 설정 파일을 이해해야 해요." 박시니어 씨가 화면에 YAML 파일을 띄웠습니다. 그렇다면 network_params.yaml이란 정확히 무엇일까요?

쉽게 비유하자면, 이 파일은 마치 요리 레시피와 같습니다. 레시피에 재료와 조리 순서가 적혀 있듯이, network_params.yaml에는 네트워크를 구성할 재료(클라이언트들)와 설정값들이 적혀 있습니다.

요리사가 레시피를 보고 요리를 만들듯, Kurtosis는 이 파일을 보고 네트워크를 구축합니다. YAML 파일의 최상위 구조는 크게 세 부분으로 나뉩니다.

첫 번째는 participants 섹션입니다. 여기에는 네트워크에 참여할 노드들을 정의합니다.

각 노드가 어떤 실행 계층(EL) 클라이언트와 합의 계층(CL) 클라이언트를 사용할지 명시합니다. 두 번째는 network_params 섹션입니다.

네트워크 전체에 적용되는 설정들이 들어갑니다. 네트워크 ID, 슬롯 당 시간, 제네시스 설정 등이 여기에 해당합니다.

세 번째는 additional_services 섹션입니다. 블록 익스플로러나 모니터링 도구 같은 부가 서비스를 추가할 때 사용합니다.

필수는 아니지만 개발 편의성을 높여줍니다. YAML 문법에서 주의할 점이 있습니다.

들여쓰기가 매우 중요합니다. 스페이스 두 칸이 기본 단위이며, 탭 문자를 사용하면 오류가 발생합니다.

또한 하이픈(-)은 리스트의 항목을 나타냅니다. participants 아래의 하이픈은 각각의 참여자 설정이 하나의 리스트 항목임을 의미합니다.

콜론(:) 뒤에는 반드시 공백이 와야 합니다. key:value가 아니라 key: value 형태로 작성해야 합니다.

박시니어 씨의 설명을 들은 김개발 씨는 이제 파일의 전체 그림이 그려지기 시작했습니다. "아, 그러니까 이 파일 하나로 전체 네트워크 구성을 컨트롤하는 거군요!" 맞습니다.

network_params.yaml을 잘 이해하면 원하는 대로 테스트 환경을 구성할 수 있습니다. 이제 각 섹션을 하나씩 자세히 살펴보겠습니다.

실전 팁

💡 - YAML 파일 작성 시 VS Code의 YAML 확장 프로그램을 설치하면 문법 오류를 쉽게 잡을 수 있습니다

• 들여쓰기는 항상 스페이스 2칸을 사용하고, 탭 문자는 피하세요

---

2. participants 설정 (EL/CL 클라이언트)

김개발 씨가 YAML 파일의 구조를 이해하자, 박시니어 씨가 다음 질문을 던졌습니다. "이더리움 노드가 왜 클라이언트를 두 개나 돌려야 하는지 알아요?" 김개발 씨는 머리를 긁적였습니다.

분명 예전에는 Geth 하나만 있으면 됐던 것 같은데 말이죠.

participants는 네트워크에 참여할 노드들의 명단입니다. 이더리움이 지분증명(PoS)으로 전환된 후, 각 노드는 반드시 실행 계층(EL) 클라이언트와 합의 계층(CL) 클라이언트를 함께 운영해야 합니다.

마치 자동차의 엔진과 변속기가 함께 작동해야 차가 움직이듯, 두 클라이언트가 협력해야 완전한 노드가 됩니다.

다음 코드를 살펴봅시다.

# participants 섹션 상세 설정
participants:
  # 첫 번째 참여자 그룹: Geth + Lighthouse 조합
  - el_client_type: geth
    cl_client_type: lighthouse
    count: 2  # 이 조합으로 2개 노드 생성

  # 두 번째 참여자 그룹: Nethermind + Prysm 조합
  - el_client_type: nethermind
    cl_client_type: prysm
    count: 1  # 이 조합으로 1개 노드 생성

  # 세 번째 참여자 그룹: 검증자 전용 설정
  - el_client_type: besu
    cl_client_type: teku
    count: 1
    validator_count: 64  # 이 노드가 관리할 검증자 수

"The Merge 알죠?" 박시니어 씨가 물었습니다. 김개발 씨는 고개를 끄덕였습니다.

2022년 9월, 이더리움이 작업증명에서 지분증명으로 전환한 그 역사적인 이벤트 말입니다. "그 이후로 이더리움 노드 구조가 완전히 바뀌었어요." 박시니어 씨가 설명을 이어갔습니다.

이전의 이더리움에서는 Geth 같은 클라이언트 하나만 실행하면 됐습니다. 하지만 지분증명 전환 이후, 노드는 두 개의 클라이언트를 반드시 함께 실행해야 합니다.

실행 계층(Execution Layer, EL) 클라이언트는 트랜잭션을 처리하고 스마트 컨트랙트를 실행합니다. 쉽게 말해 "무엇을 할지"를 담당합니다.

Geth, Nethermind, Besu, Erigon 등이 있습니다. 합의 계층(Consensus Layer, CL) 클라이언트는 블록의 유효성을 검증하고 네트워크의 합의를 이끌어냅니다.

"어떤 블록이 정당한지"를 결정합니다. Lighthouse, Prysm, Teku, Nimbus, Lodestar 등이 있습니다.

마치 회사에서 기획팀과 개발팀이 협업하는 것과 같습니다. 기획팀(CL)이 "이 기능을 만들자"고 결정하면, 개발팀(EL)이 실제로 구현합니다.

둘 다 없으면 제품이 나올 수 없듯이, 두 클라이언트가 함께해야 노드가 제대로 작동합니다. participants 섹션에서 각 항목은 하나의 참여자 그룹을 정의합니다.

el_client_type은 실행 계층 클라이언트를 지정합니다. geth, nethermind, besu, erigon, reth 중에서 선택할 수 있습니다.

cl_client_type은 합의 계층 클라이언트를 지정합니다. lighthouse, prysm, teku, nimbus, lodestar 중에서 선택할 수 있습니다.

count는 해당 조합으로 몇 개의 노드를 생성할지 결정합니다. count: 2라면 동일한 설정의 노드가 2개 만들어집니다.

validator_count는 선택적 설정으로, 해당 노드가 관리할 검증자 수를 지정합니다. 지정하지 않으면 기본값이 적용됩니다.

실무에서는 다양한 클라이언트 조합을 테스트하는 것이 좋습니다. 왜냐하면 특정 클라이언트에서만 발생하는 버그가 있을 수 있기 때문입니다.

위 예제처럼 여러 조합을 섞어 사용하면 더 견고한 테스트가 가능합니다. "그래서 저희 팀에서는 보통 Geth+Lighthouse와 Nethermind+Prysm 조합을 함께 사용해요." 박시니어 씨가 말했습니다.

"클라이언트 다양성은 네트워크 보안에도 중요하거든요." 김개발 씨는 고개를 끄덕이며 메모를 했습니다. 이제 왜 두 개의 클라이언트가 필요한지, 그리고 어떻게 조합하는지 이해가 됐습니다.

실전 팁

💡 - 로컬 테스트에서는 Geth + Lighthouse 조합이 가장 안정적이고 자료가 많습니다

• 다양한 클라이언트 조합을 테스트하면 특정 클라이언트 종속적인 버그를 미리 발견할 수 있습니다

---

3. el client type과 cl client type 옵션

"근데 선배, Geth랑 Lighthouse 말고 다른 것도 있잖아요. 뭘 써야 할지 어떻게 알죠?" 김개발 씨의 질문에 박시니어 씨가 미소를 지었습니다.

"좋은 질문이에요. 각 클라이언트마다 특징이 다르거든요."

이더리움 생태계에는 다양한 EL 클라이언트와 CL 클라이언트가 존재합니다. 각각 다른 프로그래밍 언어로 작성되었고, 성능 특성과 리소스 사용량이 다릅니다.

마치 같은 목적지를 향해 가는 다양한 교통수단처럼, 어떤 것을 선택하느냐에 따라 여정이 달라집니다.

다음 코드를 살펴봅시다.

# EL 클라이언트 옵션별 설정 예시
participants:
  # Geth: Go 언어, 가장 널리 사용됨
  - el_client_type: geth
    el_client_image: ethereum/client-go:latest
    cl_client_type: lighthouse

  # Nethermind: C# 언어, 엔터프라이즈 친화적
  - el_client_type: nethermind
    el_client_image: nethermind/nethermind:latest
    cl_client_type: prysm

  # Besu: Java 언어, 권한형 네트워크에 적합
  - el_client_type: besu
    el_client_image: hyperledger/besu:latest
    cl_client_type: teku

  # Reth: Rust 언어, 최신이며 고성능
  - el_client_type: reth
    cl_client_type: lighthouse

박시니어 씨가 화이트보드에 표를 그리기 시작했습니다. "클라이언트 선택은 생각보다 중요해요.

잘못 고르면 나중에 고생할 수 있거든요." 먼저 실행 계층(EL) 클라이언트들을 살펴보겠습니다. Geth는 Go 언어로 작성된 이더리움 재단의 공식 클라이언트입니다.

가장 오래되고 널리 사용되어 자료가 풍부합니다. 대부분의 개발자가 처음 접하는 클라이언트이기도 합니다.

안정성이 검증되었지만, 메모리 사용량이 다소 높은 편입니다. Nethermind는 C#으로 작성되었습니다.

엔터프라이즈 환경에서 인기가 많고, 모니터링과 분석 기능이 뛰어납니다. 동기화 속도가 빠르고 메모리 효율이 좋습니다.

Besu는 Java로 작성된 Hyperledger 프로젝트의 클라이언트입니다. 프라이빗 네트워크나 권한형 네트워크 구축에 특화되어 있습니다.

엔터프라이즈 기능이 풍부합니다. Reth는 Rust로 작성된 최신 클라이언트입니다.

성능과 안정성에 초점을 맞추고 있으며, 동기화 속도가 매우 빠릅니다. 아직 비교적 새롭지만 빠르게 성장하고 있습니다.

Erigon도 Go로 작성되었지만 Geth와는 다른 아키텍처를 가집니다. 디스크 공간을 효율적으로 사용하며, 아카이브 노드 운영에 적합합니다.

이번에는 합의 계층(CL) 클라이언트들입니다. Lighthouse는 Rust로 작성되었습니다.

보안과 성능에 중점을 두고 개발되었습니다. 메모리 사용량이 적고 안정적이어서 많은 개발자가 선호합니다.

Prysm은 Go로 작성된 가장 인기 있는 CL 클라이언트입니다. 사용하기 쉽고 문서화가 잘 되어 있습니다.

다만 점유율이 너무 높아 클라이언트 다양성 측면에서 우려가 있습니다. Teku는 Java로 작성되었습니다.

Besu와 함께 사용하면 Java 생태계 내에서 일관성을 유지할 수 있습니다. 엔터프라이즈 환경에 적합합니다.

Nimbus는 Nim 언어로 작성되었습니다. 리소스 사용량이 매우 적어 라즈베리 파이 같은 저사양 기기에서도 돌아갑니다.

Lodestar는 TypeScript로 작성되었습니다. 웹 개발자들에게 친숙한 언어이고, 코드를 분석하기 쉽습니다.

"저희 팀에서는 개발 환경에서는 Geth+Lighthouse를, 스테이징 환경에서는 다양한 조합을 테스트해요." 박시니어 씨가 말했습니다. 커스텀 Docker 이미지를 사용하고 싶다면 el_client_image나 cl_client_image 옵션으로 지정할 수 있습니다.

특정 버전을 고정하거나 수정된 이미지를 사용할 때 유용합니다. 김개발 씨는 자신의 상황에 맞는 클라이언트를 선택할 수 있게 되었습니다.

일단은 자료가 많은 Geth+Lighthouse로 시작하기로 했습니다.

실전 팁

💡 - 처음 시작한다면 Geth + Lighthouse 조합을 추천합니다. 커뮤니티 지원이 가장 풍부합니다

• 프로덕션 환경에서는 클라이언트 다양성을 위해 여러 조합을 운영하는 것이 좋습니다

---

4. network params 커스터마이징

참여자 설정을 마친 김개발 씨가 이번에는 network_params 섹션을 들여다봤습니다. "여기는 뭘 설정하는 거예요?" 박시니어 씨가 대답했습니다.

"네트워크의 규칙을 정하는 곳이에요. 게임의 난이도 설정 같은 거죠."

network_params는 네트워크 전체에 적용되는 규칙과 설정을 정의합니다. 네트워크 ID, 블록 생성 주기, 제네시스 설정 등 네트워크의 근본적인 특성을 결정합니다.

마치 보드게임을 시작하기 전에 규칙을 정하는 것과 같습니다. 한 번 정하면 게임 도중에 바꾸기 어렵습니다.

다음 코드를 살펴봅시다.

# network_params 상세 설정
network_params:
  # 네트워크 식별자 (체인 ID로도 사용됨)
  network_id: "3151908"

  # 슬롯 당 시간 (초 단위)
  seconds_per_slot: 12

  # 에폭 당 슬롯 수
  slots_per_epoch: 32

  # 사전 자금이 있는 계정들
  prefunded_accounts:
    - address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
      balance: "1000000000000000000000"

  # 최소 검증자 스테이킹 양 (Wei)
  min_validator_withdrawability_delay: 256

  # 추가 제네시스 설정
  genesis_delay: 20

박시니어 씨가 비유를 들어 설명했습니다. "축구 경기를 생각해 보세요.

경기 시간, 선수 수, 오프사이드 규칙 같은 것들이 있잖아요. network_params는 우리 네트워크의 그런 규칙들을 정하는 곳이에요." network_params에서 설정할 수 있는 주요 항목들을 살펴보겠습니다.

network_id는 네트워크를 구별하는 고유 식별자입니다. 이더리움 메인넷은 1, 세폴리아 테스트넷은 11155111입니다.

로컬 테스트넷에서는 다른 네트워크와 겹치지 않는 임의의 숫자를 사용합니다. MetaMask 같은 지갑에서 네트워크를 추가할 때 이 ID를 사용합니다.

seconds_per_slot은 슬롯 당 시간을 초 단위로 지정합니다. 이더리움 메인넷은 12초입니다.

테스트 환경에서는 더 짧게 설정하여 빠른 피드백을 얻을 수 있습니다. 예를 들어 2초로 설정하면 트랜잭션 확인이 6배 빨라집니다.

slots_per_epoch은 하나의 에폭에 포함되는 슬롯 수입니다. 메인넷은 32개입니다.

에폭은 검증자 셔플링과 보상 계산의 기준 단위입니다. prefunded_accounts는 제네시스 블록에서 미리 자금을 보유할 계정들을 지정합니다.

테스트할 때 매번 파우셋에서 ETH를 받을 필요 없이 바로 사용할 수 있어 편리합니다. Hardhat이나 Foundry의 기본 계정을 여기에 추가해 두면 개발이 한결 수월해집니다.

genesis_delay는 네트워크 시작까지의 지연 시간입니다. 모든 노드가 준비될 시간을 주기 위해 사용합니다.

너무 짧으면 일부 노드가 제네시스 블록을 놓칠 수 있습니다. 주의할 점이 있습니다.

일부 설정은 네트워크가 시작된 후에는 변경할 수 없습니다. network_id나 genesis 관련 설정이 그렇습니다.

설정을 변경하려면 네트워크를 처음부터 다시 구축해야 합니다. "실수로 메인넷 ID인 1을 쓰면 안 되겠죠?" 김개발 씨가 물었습니다.

"맞아요. 그리고 체인 ID가 겹치면 트랜잭션 리플레이 공격의 위험도 있어요." 박시니어 씨가 고개를 끄덕였습니다.

테스트 환경에서는 보통 큰 숫자를 사용합니다. 예제에서 사용한 3151908은 Kurtosis의 기본값으로, 다른 네트워크와 겹칠 가능성이 낮습니다.

김개발 씨는 자신만의 테스트 환경을 위해 network_id를 팀 이름의 숫자 조합으로 정하기로 했습니다. 이렇게 하면 나중에 여러 테스트넷을 운영할 때 구분하기 쉬울 것입니다.

실전 팁

💡 - prefunded_accounts에 Hardhat의 기본 계정을 추가해 두면 개발 시 편리합니다

• 테스트 속도를 높이려면 seconds_per_slot을 2~4초로 줄여보세요

---

5. network id와 seconds per slot 설정

김개발 씨가 테스트를 진행하다가 불만을 토로했습니다. "선배, 트랜잭션 하나 확인하는 데 12초나 걸려요.

테스트할 때마다 기다리기가 너무 답답합니다." 박시니어 씨가 웃으며 대답했습니다. "그럴 줄 알았어요.

설정 좀 바꿔볼까요?"

network_id와 seconds_per_slot은 네트워크의 정체성과 속도를 결정하는 핵심 설정입니다. network_id는 네트워크의 주민등록번호와 같고, seconds_per_slot은 네트워크의 심장 박동 속도와 같습니다.

이 두 값을 적절히 조절하면 개발 효율을 크게 높일 수 있습니다.

다음 코드를 살펴봅시다.

# 빠른 테스트를 위한 최적화된 설정
network_params:
  # 고유한 네트워크 ID 설정
  # 팁: 메인넷(1), 세폴리아(11155111) 등과 겹치지 않게
  network_id: "12345678"

  # 빠른 블록 생성: 2초 (메인넷은 12초)
  seconds_per_slot: 2

  # 에폭당 슬롯: 8개 (메인넷은 32개)
  slots_per_epoch: 8

  # 위 설정으로:
  # - 블록 생성: 2초마다
  # - 에폭 완료: 16초 (메인넷은 6.4분)
  # - 파이널리티: 약 32초 (메인넷은 약 13분)

# 사용 예시가 포함된 전체 설정
participants:
  - el_client_type: geth
    cl_client_type: lighthouse
    count: 4

이더리움의 시간 단위를 이해하면 설정을 더 잘 조절할 수 있습니다. **슬롯(Slot)**은 이더리움의 기본 시간 단위입니다.

각 슬롯에서 한 명의 검증자가 블록을 제안할 기회를 얻습니다. 메인넷에서 하나의 슬롯은 12초입니다.

**에폭(Epoch)**은 32개의 슬롯으로 구성됩니다. 에폭이 끝날 때마다 검증자 위원회가 재편성되고, 보상이 계산됩니다.

메인넷에서 하나의 에폭은 약 6.4분입니다. **파이널리티(Finality)**는 블록이 되돌릴 수 없게 확정되는 것을 의미합니다.

보통 2개의 에폭이 지나면 파이널리티가 달성됩니다. 메인넷에서는 약 13분이 걸립니다.

이제 왜 개발 환경에서 이 값들을 줄여야 하는지 명확해졌습니다. 메인넷 설정 그대로 테스트하면, 하나의 트랜잭션 결과를 확인하는 데 12초, 파이널리티까지 기다리면 13분이 걸립니다.

하루에 수십, 수백 번의 테스트를 해야 하는 개발자에게 이는 큰 부담입니다. seconds_per_slot을 2초로 줄이면 어떻게 될까요?

블록 생성이 6배 빨라집니다. 거기에 slots_per_epoch도 8로 줄이면, 에폭 완료 시간이 16초로 단축됩니다.

파이널리티도 약 32초면 달성됩니다. 개발 효율이 극적으로 향상됩니다.

하지만 주의할 점도 있습니다. 너무 짧게 설정하면 노드들이 제때 동기화되지 못할 수 있습니다.

네트워크 지연이나 CPU 성능에 따라 블록 생성이 불안정해질 수 있습니다. 보통 2초 이하로 내리는 것은 권장하지 않습니다.

network_id 설정도 중요합니다. 고유한 값을 사용해야 다른 네트워크와 혼동이 없습니다.

MetaMask에서 여러 네트워크를 전환하며 테스트할 때, ID가 같으면 의도치 않은 네트워크로 트랜잭션이 전송될 수 있습니다. 주요 네트워크의 ID를 기억해 두세요.

메인넷은 1, 세폴리아는 11155111, 홀스키는 17000입니다. 이 값들은 피해서 설정해야 합니다.

"저는 보통 회사 사번이나 생년월일 조합을 써요." 박시니어 씨가 말했습니다. "기억하기도 쉽고 겹칠 일도 없으니까요." 김개발 씨는 seconds_per_slot을 2초로 설정하고 테스트를 다시 진행했습니다.

체감되는 속도 차이에 감탄했습니다. "와, 이렇게 빠를 수가!"

실전 팁

💡 - 개발 환경에서는 seconds_per_slot: 2, slots_per_epoch: 8 조합을 추천합니다

• network_id는 반드시 알려진 네트워크와 겹치지 않는 값을 사용하세요

---

6. --args-file 옵션으로 실행하기

드디어 설정 파일 작성을 마친 김개발 씨. 이제 이 파일을 어떻게 사용하는지 배울 차례입니다.

박시니어 씨가 터미널을 열며 말했습니다. "자, 이제 우리가 만든 설정으로 네트워크를 띄워볼까요?"

설정 파일을 완성했다면 --args-file 옵션을 사용하여 Kurtosis에 전달합니다. 마치 요리사에게 레시피를 건네주는 것처럼, Kurtosis에게 우리의 설계도를 전달하면 그대로 네트워크를 구축해 줍니다.

한 번의 명령으로 복잡한 멀티노드 네트워크가 뚝딱 만들어집니다.

다음 코드를 살펴봅시다.

# 1. YAML 설정 파일 저장 (network_params.yaml)
# 앞서 작성한 모든 설정을 하나의 파일로 저장합니다

# 2. Kurtosis로 네트워크 실행
kurtosis run github.com/ethpandaops/ethereum-package \
  --args-file ./network_params.yaml

# 3. 실행 결과 확인
kurtosis enclave ls

# 4. 서비스 상태 확인
kurtosis enclave inspect my-testnet

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

# 6. 네트워크 정리 (테스트 완료 후)
kurtosis enclave stop my-testnet
kurtosis enclave rm my-testnet

모든 준비가 끝났습니다. 이제 실제로 네트워크를 실행해 보겠습니다.

먼저 작성한 YAML 파일을 저장합니다. 파일 이름은 자유롭게 정할 수 있지만, 관례적으로 network_params.yaml이나 config.yaml을 많이 사용합니다.

프로젝트 루트 디렉토리에 저장해 두면 관리하기 편합니다. Kurtosis가 설치되어 있다면, 터미널에서 다음 명령을 실행합니다.

kurtosis run 명령은 ethereum-package를 실행합니다. 이 패키지는 이더리움 네트워크 구축에 필요한 모든 것을 담고 있습니다.

--args-file 옵션 뒤에 설정 파일 경로를 지정합니다. 상대 경로도, 절대 경로도 가능합니다.

이 옵션이 핵심입니다. 우리가 공들여 작성한 설정이 바로 여기서 사용됩니다.

명령을 실행하면 Kurtosis가 Docker 컨테이너들을 순차적으로 생성합니다. 설정에 따라 몇 분 정도 걸릴 수 있습니다.

진행 상황이 터미널에 실시간으로 표시됩니다. "처음엔 좀 오래 걸려요.

Docker 이미지를 다운로드해야 하거든요." 박시니어 씨가 설명했습니다. "두 번째부터는 훨씬 빨라요." 네트워크가 성공적으로 시작되면, kurtosis enclave inspect 명령으로 상세 정보를 확인할 수 있습니다.

각 서비스의 포트 번호, 상태, 연결 정보 등이 표시됩니다. RPC 엔드포인트 주소를 찾아 MetaMask에 추가하면 바로 네트워크에 연결할 수 있습니다.

보통 http://localhost:8545 형태의 주소입니다. 문제가 발생했다면 kurtosis service logs 명령으로 특정 서비스의 로그를 확인합니다.

서비스 이름은 el-1-geth-lighthouse처럼 클라이언트 조합으로 자동 생성됩니다. 테스트가 끝나면 리소스를 정리하는 것이 좋습니다.

kurtosis enclave stop으로 네트워크를 중지하고, kurtosis enclave rm으로 완전히 제거합니다. "매번 파일 경로 치기 귀찮으면 npm script나 Makefile로 만들어 두면 편해요." 박시니어 씨가 팁을 알려줬습니다.

김개발 씨는 첫 번째 로컬 테스트넷을 성공적으로 띄웠습니다. 터미널에 초록색 성공 메시지가 뜨는 순간, 뿌듯함이 밀려왔습니다.

이제 자신만의 이더리움 네트워크에서 마음껏 실험할 수 있게 되었습니다. "축하해요.

이제 여기서 스마트 컨트랙트 테스트를 마음껏 해보세요." 박시니어 씨가 어깨를 두드렸습니다.

실전 팁

💡 - 자주 사용하는 설정은 별도의 파일로 분리해 두고, 상황에 따라 다른 파일을 적용하세요

• 네트워크 실행 후 kurtosis enclave inspect로 RPC 포트를 확인하여 MetaMask에 추가하세요

---

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