이더리움 네트워크에서 Geth 노드(Go-Ethereum)를 실행하세요.
Infura 엔드포인트를 통한 지갑 트래픽 전송을 더 이상 신뢰하지 않기로 결정했을 수도 있습니다. 친구가 32 ETH 스테이킹 방법을 알려주겠다고 했을 수도 있고, dApp 출시 당일에 트래픽 제한에 걸릴 위험이 있을 수도 있습니다. 이유가 무엇이든, 다음에 나오는 말은 항상 같습니다. Geth 노드를 실행해야 한다는 것입니다.
그 문장은 실제보다 더 무겁게 들릴 수 있습니다. Geth는 go-ethereum의 줄임말로, 2014년 제프리 윌케와 전 세계 오픈 소스 팀이 Go 프로그래밍 언어로 작성한 최초의 이더리움 실행 클라이언트입니다. 넉넉한 SSD가 장착된 최신 노트북이라면 충분히 실행할 수 있습니다. 월 30달러짜리 헤츠너(Hetzner) 공유기도 문제없습니다. 사람들이 어려워하는 부분은 설치 명령어가 아니라 그 주변의 선택 사항들입니다. 어떤 동기화 모드를 선택할지, Geth와 어떤 합의 클라이언트를 함께 사용할지, 병합(Merge) 이후에는 어떤 일이 일어날지, 새벽 2시에 디스크 용량이 꽉 찼을 때 노드를 어떻게 유지할지 등을 고민해야 합니다.
이 가이드는 하드웨어 구매부터 설치, 스냅 동기화, 병합 후 합의 클라이언트와의 페어링, JavaScript 콘솔, 계정 및 Clef, 유효성 검사기 설정, 일반적인 오류 해결까지 전체 과정을 안내합니다. 이 가이드를 마치면 흰색 로그가 표시될 때 시스템에서 어떤 작업이 수행되는지, 그리고 로그가 중단될 때 어떻게 해야 하는지 정확히 알게 될 것입니다.
Geth 노드란 무엇이며 오늘날 왜 중요한가
Geth 노드는 go-ethereum 클라이언트를 실행하고 이더리움의 P2P 네트워크에 연결된 컴퓨터입니다. 이 시스템은 블록을 다운로드하고, 모든 거래를 검증하며, 이더리움 가상 머신(EVM)에서 스마트 계약을 실행합니다. 또한 블록체인 데이터의 동기화된 사본을 유지합니다. 외부에서 보면 몇 개의 포트에서 조용히 실행되는 프로세스처럼 보이지만, 내부적으로는 다른 사람의 말을 그대로 받아들이지 않는 고집스러운 회계 담당자와 같습니다. Geth 노드는 블록체인 데이터의 자체 사본을 보관하고, 사용자의 지갑이 계좌 잔액을 확인하거나 블록체인에 거래를 제출할 수 있도록 하며, dApp이 다른 사람의 API를 통하지 않고 블록체인과 직접 상호 작용할 수 있도록 합니다.
2026년에 이 모든 것이 왜 중요할까요? 바로 집중도 때문입니다. 이더리움의 대부분의 공개 dApp 트래픽은 Infura, Alchemy, QuickNode 및 몇몇 소규모 업체와 같은 소수의 호스팅 RPC 제공업체를 통해 흐릅니다. Infura만 해도 작년에 6천억 건 이상의 블록체인 요청을 처리했습니다. 이들은 대체로 안정적이지만, 단일 장애 지점이기도 합니다. 한 지역의 제공업체가 다운되면 해당 엔드포인트를 가리키는 지갑의 절반이 문제가 해결될 때까지 잔액이 유지되지 않고 거래가 중단되는 현상이 발생합니다. 자체 Geth 노드를 운영하면 이러한 유형의 장애 문제를 완전히 해결할 수 있습니다.
이것은 또한 숫자의 싸움입니다. 이더스캔의 노드 추적기에 따르면 2026년 4월 현재 전 세계적으로 약 13,678개의 활성 이더리움 노드가 있습니다. 미국이 그중 37.55%인 약 5,171개의 노드를 보유하고 있으며, 독일이 16.05%, 중국이 12.06%를 차지합니다. 노드 하나를 더 만드는 것은 영웅적인 행동이 아닙니다. 단지 유용한 일일 뿐이며, 네트워크는 사람들이 그렇게 해주기를 조용히 기대하고 있습니다.
더 근본적인 이유도 있습니다. 이더리움이 이더리움으로 남아 있는 이유는 누구나 허가 없이 검증할 수 있기 때문입니다. Geth는 이러한 검증을 수행하는 가장 인기 있는 클라이언트입니다. 독립적인 운영자가 새로운 Geth 노드를 온라인에 추가할 때마다 체인 장악은 더욱 어려워집니다. 이러한 논리는 병합 이전부터 존재해 왔으며 그 이후로 약화되지 않았습니다.
Geth, Go Ethereum 및 이더리움 프로토콜
세 개의 이름, 하나의 프로젝트. 사람들은 대화에서 이들을 뒤섞어 부르지만 아무 문제도 발생하지 않습니다. 하지만 실제 구분은 다음과 같습니다.
이더리움 프로토콜은 코드가 아닙니다. 노란색 종이와 수많은 EIP(이더리움 통합 계획)에 명시된 사양이며, 누구나 이를 기반으로 클라이언트를 작성할 수 있습니다. Go Ethereum(go-ethereum이라고도 함)은 이더리움 프로토콜의 Go 언어 구현체입니다. Geth는 Go Ethereum 내부에 있는 명령줄 프로그램으로, 명령줄에서 실행하고 플래그를 사용하여 구성한 다음 이더리움 네트워크와 상호 작용하는 데 사용합니다. 저장소의 나머지 모든 것은 Geth를 감싸는 라이브러리와 도우미 함수입니다. "Geth 노드"는 Geth를 시작하고 `chaindata` 디렉토리를 지정한 다음 이더리움 메인넷과 통신하도록 설정한 가상 머신을 의미합니다.
동일한 프로토콜을 사용하는 다양한 클라이언트가 존재합니다. Nethermind는 C#으로, Besu는 Java로, Erigon과 Reth는 둘 다 Rust로 작성되었습니다. 동일한 와이어 형식을 사용하지만, 코드, 성능, 그리고 개발 역사는 모두 다릅니다.
Geth는 그중 가장 오래된 프로젝트입니다. 400명이 넘는 사람들이 기여했으며, Péter Szilágyi가 수년간 개발을 주도해 왔습니다. Geth는 이더리움 재단에서 운영하며, 소스 코드는 GitHub의 ethereum/go-ethereum에서 확인할 수 있습니다. 라이선스는 바이너리의 경우 GPL-3.0, 라이브러리 코드의 경우 LGPL-3.0입니다. 현재 안정 버전은 2026년 3월 30일에 출시된 코드명 "EMF Suppressor"인 v1.17.2입니다. 이 버전은 세 가지 CVE 취약점(CVE-2026-26313, -26314, -26315)을 패치하고, 프라하 이전 기록이 삭제된 체인에 대해 클라이언트가 동기화하는 방법을 추가했습니다.
Geth와 함께 제공되는 몇 가지 유사 도구가 있습니다. Clef는 개인 키를 노드 자체와 분리하여 관리하는 별도의 서명 도구입니다. Abigen은 Solidity ABI를 실제로 사용할 수 있는 Go 바인딩으로 변환해 줍니다. `evm` 도구는 특정 부분을 디버깅해야 할 때 바이트코드를 격리된 환경에서 실행할 수 있도록 해줍니다. 이러한 도구들은 필수적인 것은 아니지만, 일주일 안에 적어도 하나는 사용하게 될 것입니다.
노드를 실행해야 하는 이유: 개인정보 보호, 속도, 주권
대부분의 사람들이 Geth 노드를 직접 운영하는 이유는 세 가지 중 하나입니다. 첫째, 개인정보 보호가 가장 중요합니다. 지갑이 호스팅된 RPC와 통신할 때, 해당 제공업체는 모든 주소, 모든 컨트랙트 호출, 모든 견적 요청을 볼 수 있습니다. 하지만 자체 호스팅 노드는 이러한 연결을 끊습니다. 제공업체가 존재하지 않기 때문입니다. 지갑이 컴퓨터에 요청하고, 컴퓨터가 네트워크에 요청하며, 오직 컴퓨터만이 패턴을 볼 수 있습니다.
두 번째 이유는 성능입니다. 호스팅된 RPC는 처리량에 제한이 있습니다. Infura의 무료 티어는 하루 10만 건의 요청으로 제한되며, 팀 티어는 월 225달러로 하루 7,500만 건의 요청을 처리할 수 있습니다. 로컬 노드는 메모리 속도로 트래픽을 처리하며 호출당 비용이 발생하지 않습니다. 페이지 로드 시마다 상태를 가져오는 dApp의 경우 지연 시간 차이가 확연히 드러납니다. 멤풀을 스캔하는 차익거래 봇의 경우, 거래를 성사시키느냐 아니면 그냥 지나쳐 버리느냐의 차이를 만들어냅니다. 메인넷 자체는 2026년 1분기에 약 2억 40만 건의 트랜잭션을 처리했으며, 1월 16일에는 288만 건으로 정점을 찍었습니다. 따라서 네트워크 속도를 따라잡을 수 있는 노드는 상당한 작업을 수행하고 있는 것입니다.
세 번째는 주권입니다. 이더리움에 스테이킹을 하면 네트워크는 검증자가 차례가 되면 블록을 발행할 것으로 기대합니다. 공유 RPC에 발행을 위탁하는 것은 기술적으로 허용되지만 운영상 불안정합니다. 자체 실행 레이어 클라이언트를 운영하면 블록 발행 슬롯을 직접 제어할 수 있습니다. 이는 진지한 dApp 개발자, 온체인 분석가, MEV 검색자, 그리고 이더리움 사용에 사업이 의존하는 모든 사람에게도 마찬가지입니다.
합병 후: Geth와 합의 클라이언트
2022년 9월 이전에는 단일 Geth 프로세스가 모든 작업을 수행했습니다. 네트워크와 피어링하고, EVM을 실행하며, 작업증명 채굴을 통해 경쟁하는 블록 중에서 최종 승자를 결정했습니다. 병합(Merge)으로 인해 이러한 작업이 절반으로 나뉘었습니다. Geth는 여전히 EVM을 실행하고 상태를 유지합니다. 두 번째 프로그램인 합의 클라이언트는 이제 지분증명(PoS)을 처리합니다. 지분증명 클라이언트는 검증자들 간에 블록 정보를 공유하고, 어떤 블록이 유효한지 투표하며, Geth에 어떤 포크가 정식 포크인지 알려줍니다.
최신 Geth 설정은 단일 프로세스가 아니라 두 프로세스가 한 쌍으로 구성됩니다. 함께 실행할 합의 클라이언트를 선택하세요. Lighthouse(Rust), Prysm(Go), Teku(Java), Nimbus(Nim), Lodestar(TypeScript) 등이 있습니다. 두 프로세스는 Engine API라는 비공개 채널을 통해 통신하며, 이 채널은 한 번 생성하여 `--authrpc.jwtsecret` 옵션을 사용하여 양쪽에 전달하는 JWT 비밀 키로 보호됩니다.
합의 클라이언트 없이 Geth만 단독으로 실행하면 로그에 "병합 후 네트워크이지만 비콘 클라이언트가 감지되지 않았습니다. 체인을 추적하려면 비콘 클라이언트를 실행하세요!"와 같은 메시지가 표시됩니다. 노드는 아무런 도움도 주지 않고 가만히 있을 것입니다. Geth 단독으로는 더 이상 완전한 이더리움 노드가 아닙니다. Geth와 Geth를 함께 사용하는 것이 핵심입니다.
클라이언트 다양성은 여기서 중요한 요소입니다. 이더리움 커뮤니티는 운영자들이 스플릿 양쪽의 다양한 구현체를 활용하도록 권장하는데, 이는 검증자의 3분의 2 이상이 동일한 버그가 있는 클라이언트를 사용하게 될 경우, 문제가 발생했을 때 해당 검증자는 32 ETH의 슬래싱 페널티를 받게 되기 때문입니다. clientdiversity.org의 최신 자료에 따르면 2026년에는 Geth가 전체 실행 클라이언트의 약 41%를 차지할 것으로 예상되며, Stake.fish의 2026년 보고서에서는 50%에 더 가깝다고 합니다. 어느 쪽이든 2023년의 86% 이상에서 감소한 수치이지만, 커뮤니티에서 이상적이라고 여기는 안전 임계값인 33%보다는 여전히 높습니다. 이러한 이유로 일부 신규 운영자들은 Geth가 첫 단계로 더 쉽더라도 의도적으로 Nethermind, Besu 또는 Reth를 선택하기도 합니다.
2025년 5월 7일에 활성화된 프라하 + 일렉트라 업그레이드인 펙트라(Pectra)는 운영자의 일상적인 업무 방식을 혁신적으로 변화시켰습니다. EIP-7251은 검증자당 최대 유효 잔액을 32 ETH에서 2,048 ETH로 상향 조정했습니다. 기존에 1,000개의 개별 검증자를 관리하던 스테이킹 운영자는 이제 이들을 16개의 대규모 검증자로 통합 관리할 수 있게 되었습니다. EIP-6110은 예치 후 활성화까지 걸리는 시간을 약 12시간에서 13분으로 단축했습니다. EIP-7002는 검증자가 최초 예치 서명자에게 출금을 요청하는 대신 직접 출금을 요청할 수 있도록 했습니다. 2026년의 Geth 기반 검증자 스택 운영은 2024년보다 훨씬 간편해졌습니다.
하드웨어: Geth 노드용 CPU, RAM 및 SSD
2026년의 실제 하드웨어 요구 사항은 공식 문서에서 인정하는 것보다 훨씬 높습니다. 향후 3년이 아닌, 앞으로 3년을 내다보고 계획을 세우세요.
| 요소 | Geth 공식 문서(2023년 기준, 현재까지도 유효함) | 운영자급 현실 (Cherry Servers, Chainstack, 2026) | 아카이브 노드(경로 기반, v1.16 이상) |
|---|---|---|---|
| CPU | 쿼드 코어 | 8코어/16스레드 최신 AMD 또는 인텔 프로세서 | 8개 이상의 코어, 높은 싱글 스레드 성능 |
| 숫양 | 16GB | 최소 32GB, 64GB 이상일 경우 더욱 원활한 작동을 보장합니다. | 64GB 이상 |
| 저장 | 2TB SSD | 4~8TB NVMe SSD | 4TB NVMe (경로 기반, 약 2TB 사용) |
| 회로망 | 25Mbps | 완전한 RPC의 경우 300~500Mbps | 300Mbps 이상 |
| 힘 | UPS 추천 | UPS를 강력 추천합니다. | UPS 필수 |
스토리지 용량은 새로운 운영자들이 가장 놀라는 부분입니다. 스냅 동기화 및 정리가 완료된 Geth 풀 노드는 현재 약 650GB의 용량을 차지합니다. Geth 자체 문서에 따르면 매주 약 14GB의 용량이 추가됩니다. 여기에 컨센서스 클라이언트를 추가하고, 몇 달간의 성장 여유 공간을 고려하고, 처리해야 할 L2 RPC 트래픽까지 더하면 순식간에 4TB에서 8TB에 이르는 NVMe 스토리지가 필요하게 됩니다.
디스크 종류에 대해 말씀드리겠습니다. SATA SSD는 기술적으로는 작동하지만, 부하가 걸리면 동기화가 멈추고 인증에 실패하는 문제가 있습니다. 2026년에는 NVMe가 필수 불가결한 요소가 되었습니다. 회전식 하드 디스크는 이미 오래전부터 실용성이 떨어졌습니다. 만약 제공업체에서 저렴한 요금제에만 SATA를 제공한다면, 더 비싼 요금제를 선택하는 것이 좋습니다. 계산해 보면 알 수 있듯이, SATA 디스크가 멈추면 매 에포크마다 검증자 보상을 받지 못하게 됩니다.
두 번째 함정은 RAM입니다. 2023년에 마지막으로 업데이트된 Geth 공식 하드웨어 페이지에는 여전히 16GB라고 나와 있습니다. 하지만 2026년이 되면 Cherry Servers, Chainstack, bacloud 모두 최소 요구 용량을 32GB로, 최대 용량을 64GB로 정할 것입니다. Geth는 상태 정보를 메모리에 상당 부분 캐시합니다. 합의 클라이언트도 그 공간을 필요로 합니다. 여기에 Prometheus, Grafana 등 실제로 사용하는 다른 프로그램들을 추가하면 16GB는 금방 부족해집니다.
CPU는 세 가지 중 가장 쉽습니다. 최신 데스크톱 칩은 Geth가 활용할 수 있는 여유 공간이 충분합니다. 클럭 속도는 그다지 중요한 문제가 아닙니다. 코어 수와 최신 명령어 세트가 더 중요합니다. AVX2는 서명 검증 속도를 높여주고, 8개의 코어는 동기화 요청 급증 시 시스템이 멈추는 것을 방지합니다. 앞으로 블록 가스 한도는 2024년 중반부터 2025년 11월 사이에 3천만 건에서 4천5백만 건, 그리고 6천만 건으로 증가했습니다. 이더리움 재단은 2026년까지 1억 건 이상을 목표로 하고 있다고 밝혔습니다. 따라서 작년의 부하가 아니라 이러한 추세를 기준으로 시스템 규모를 조정해야 합니다.
이더리움 블록체인용 Geth 동기화 모드
동기화 모드는 Geth를 처음 사용하는 사람이 조절해야 하는 가장 중요한 요소입니다. 잘못 선택하면 실제로 필요하지 않은 데이터를 다운로드하는 데 일주일을 허비하게 될 수 있습니다.
| 방법 | 저장하는 내용 | 2026년의 디스크 | 동기화 시간 | 사용 사례 |
|---|---|---|---|---|
| 스냅(기본값) | 최근 현황 + 최근 영수증 | 약 650GB, 매주 14GB 추가 | 1~3일 소요 (NVMe 사용 시 더 빠름) | dApp, 지갑, 검증자 |
| 가득한 | 최근 상태 + 모든 헤더를 제네시스로 되돌리기 | 약 1TB | 3~5일 | 제네시스부터 모든 블록을 검증합니다. |
| 아카이브(경로 기반, v1.16 이상) | 역차이를 통한 과거 상태 | 1.9~2.0TB | 1~2주 | 대부분의 아카이브 사용 사례 |
| 아카이브(기존 해시 기반) | 모든 역사적 상태, 모든 영수증, 모든 시도 | 12~20TB | 4~8주 | eth_getProof가 필요한 DeFi 인덱서 |
Snap은 기본 설정이며 거의 항상 올바른 선택입니다. Snap은 피어로부터 최근 상태 스냅샷을 가져온 다음, 헤더와 영수증을 조용히 채워 넣습니다. 괜찮은 하드웨어라면 며칠 안에 Geth 노드를 정상적으로 운영할 수 있습니다. 지갑, dApp, 검증자 모두 문제없이 작동합니다. 다만 "2017년 10월 7일 Vitalik의 잔액은 얼마였을까?"와 같은 과거 데이터를 확인할 수는 없습니다. 만약 이러한 정보가 중요하지 않다면 동기화 모드는 고려할 필요가 없습니다.
전체 동기화 기능은 여전히 제공됩니다. 하지만 대부분의 사용자에게는 필요하지 않습니다. 전체 모드는 모든 블록을 제네시스 블록까지 거슬러 올라가 모든 트랜잭션을 다시 실행하므로 클라이언트는 스냅 스냅샷에 의존하지 않고 블록체인 전체를 검증할 수 있습니다. 스냅 스냅샷에 대해 극도로 민감하거나, 삭제된 이력 아카이브를 초기화하는 경우에 유용합니다. 일반적인 운영에는 필요하지 않습니다.
아카이브는 용량이 큰 부분이며, 아카이브 노드가 변경된 것은 2025년입니다. v1.16 릴리스 이전에는 아카이브 노드를 구성하려면 12~20TB의 고속 SSD, 즉 소형 서버가 필요했습니다. v1.16에서는 역방향 차이점을 통해 과거 상태를 저장하는 경로 기반 아카이브 모드가 도입되어 메인넷에서 필요한 디스크 용량을 약 1.9~2.0TB로 줄였습니다. 이로써 Geth의 디스크 사용량은 Erigon(약 1.77TB)과 거의 비슷해졌습니다. 초기에는 경로 기반 아카이브가 과거 머클 증명(`eth_getProof`를 사용하여 이전 블록 가져오기)을 지원하지 않는다는 단점이 있었습니다. DeFi 인덱서 및 기타 증명 기반 워크로드는 여전히 기존의 해시 기반 아카이브를 필요로 했습니다. 2026년 2월에 출시된 v1.17.0에서는 일부 구성에서 경로 기반 모드에 증명 지원 기능이 추가되었습니다. 정확한 버전은 릴리스 노트를 참조하십시오. 일반적인 아카이브 운영자는 블록 탐색기, 포렌식 팀 및 전문 분석 회사입니다. 이 가이드를 읽는 대부분의 사람들은 아카이브가 필요하지 않을 것입니다.
참고로, 기존의 `--syncmode "light"` 플래그였던 라이트 클라이언트 모드는 더 이상 사용되지 않으며 메인넷에서 유지 관리되지 않습니다. 2026년도 튜토리얼에서 Geth를 라이트 모드로 시작하라고 안내하는 경우, 해당 튜토리얼은 오래된 정보입니다.
Ubuntu, macOS 및 Windows에 Geth를 설치하세요
설치 과정은 간단합니다. 노트북에 설치된 플랫폼이 아닌, 실제로 실행할 플랫폼을 선택하세요.
리눅스/우분투(주력 운영체제)
대부분의 Geth 운영 노드는 Ubuntu에서 실행됩니다. 이더리움 팀은 PPA를 관리하며, Ubuntu 패키지 관리자를 통해 세 가지 명령어를 입력하면 작동하는 바이너리를 설치할 수 있습니다.
```
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get 업데이트
sudo apt-get install ethereum
```
`geth version` 명령어를 실행하여 버전을 확인하세요. PPA는 최신 안정 버전을 추적합니다. 프로덕션 환경에서는 일반적으로 `apt-get install ethereum=1.17.2-...`와 같이 검증된 빌드를 고정하고, "apt가 마음대로 할 때마다"가 아니라 좀 더 여유로운 일정으로 업그레이드하는 것이 좋습니다.
macOS (개발자 친화적)
macOS에서는 Homebrew가 모든 작업을 처리합니다. 단 두 줄만 입력하면 됩니다.
```
브루탭 이더리움/이더리움
brew install ethereum
```
맥은 테스트넷 실험과 dApp 개발에 아주 적합합니다. 하지만 메인넷 검증 서버를 맥에서 운영하는 사람은 거의 없습니다. 맥의 전원 관리 기능이 너무 강력해서 macOS가 원치 않는 순간에 비콘 노드를 절전 모드로 전환해 버리기 때문입니다.
윈도우
geth.ethereum.org와 프로젝트의 GitHub 릴리스 페이지에서 `.exe` 설치 프로그램과 `.zip` 압축 파일을 찾을 수 있습니다. 설치 프로그램을 실행하고 PATH 환경 변수가 수정되도록 허용한 다음, 명령 프롬프트 또는 PowerShell을 열고 `geth version` 명령을 실행하세요. 그러면 응답이 나타날 것입니다.
Windows Server는 완벽하게 작동하는 독립형 Geth 노드를 호스팅할 수 있습니다. 검증기 스택은 합의 클라이언트가 Linux 우선으로 제공되기 때문에 Linux 기반인 경우가 많지만, 원한다면 다른 운영체제와 혼합하여 사용할 수도 있습니다. 이 가이드의 나머지 부분에서는 명령어를 Linux 셸 스타일로 작성했습니다. PowerShell로 변환하는 것은 주로 경로 구분 기호와 줄 바꿈 방식의 차이만 있으면 됩니다.
도커
`docker pull ethereum/client-go:stable` 명령어를 사용하면 깔끔한 컨테이너를 얻을 수 있습니다. Docker는 호스트 시스템에 문제를 일으키지 않고 새로운 Geth 릴리스를 테스트하는 가장 쉬운 방법입니다. 또한, 팀이 이미 컨테이너 환경에 익숙하다면 프로덕션 환경에 배포하기에도 적합합니다. 단, 한 가지 주의할 점은 `chaindata`를 저장하는 Docker 볼륨은 NVMe에 있어야 한다는 것입니다. 일반 EBS 볼륨, HDD 데이터스토어 또는 Mac의 Docker Desktop 볼륨에 저장하면 Reddit에서 흔히 발생하는 "동기화 멈춤" 문제가 재현됩니다.
소스 코드에서 빌드
소스 빌드를 하려면 Go 1.23 이상 버전과 C 컴파일러가 필요합니다. `make geth`는 노드만 빌드하고, `make all`은 geth, clef, abigen, evm, devp2p, rlpdump를 포함한 전체 유틸리티 모음을 빌드합니다. 아직 패키징되지 않은 릴리스를 원하거나, 포크로 유지 관리하고 싶지 않은 개인 패치가 있는 경우 소스 빌드를 사용하세요.
Geth 실행: 첫 번째 동기화 및 JSON-RPC 콘솔
바이너리 설치 완료, JWT 비밀 키 생성 완료, 컨센서스 클라이언트 준비 완료. 메인넷 서버에서 실행하는 첫 번째 명령어는 대략 다음과 같습니다.
```
geth \
--메인넷 \
--datadir /var/lib/geth \
--syncmode snap \
--http \
--http.addr 127.0.0.1 \
--http.port 8545 \
--http.api eth,net,web3 \
--authrpc.addr 127.0.0.1 \
--authrpc.port 8551 \
--authrpc.jwtsecret /etc/geth/jwt.hex \
--authrpc.vhosts 로컬호스트
```
여기서는 세 개의 포트가 핵심적인 역할을 합니다. TCP 및 UDP를 사용하는 30303 포트는 이더리움 네트워크와의 P2P 연결을 담당합니다. 8545 포트는 지갑과 스크립트가 접속하는 HTTP-RPC 포트입니다. 8551 포트는 엔진 API로, 합의 클라이언트만 접근할 수 있으며 JWT 비밀 키로 인증됩니다.
실행 중인 노드를 확인하려면 Geth 콘솔을 연결하세요. (Geth 콘솔은 노드의 API에 연결된 JavaScript 콘솔입니다.) 두 번째 셸을 엽니다.
```
geth attach http://127.0.0.1:8545
```
이제 모든 JSON-RPC 메서드는 JavaScript 호출입니다. `eth.blockNumber`, `net.peerCount` (메인넷에서는 30 정도가 정상입니다). `eth.syncing`은 노드가 동기화되면 `false`를 반환합니다. 잔액을 확인하고 싶으면 `web3.fromWei(eth.getBalance('0x...'), 'ether')`를 사용하면 됩니다. 이것이 전체 상호 작용 인터페이스입니다.
다음으로 로그 파일을 확인해 보세요. 'Imported new chain segment'라는 줄이 보이면 Geth가 블록체인 네트워크에서 전송되는 새로운 트랜잭션 목록을 모두 처리하고 있다는 뜻입니다. 로그에 'Looking for peers'만 표시되고 다른 내용이 없다면 방화벽에서 P2P 연결을 차단하고 있는 것입니다. TCP와 UDP 포트 30303을 열고 Geth를 재시작한 후 다시 시도해 보세요. 대부분의 경우 이 방법으로 문제가 해결됩니다.
자동화를 위해 사용할 만한 모든 이더리움 라이브러리는 HTTP를 통한 JSON-RPC 또는 `--ws` 옵션을 사용하면 WebSocket을 통해 통신합니다. ethers.js, web3.js, viem, Go 클라이언트, Python 클라이언트 모두 로컬 Geth 노드를 Infura와 똑같이 취급합니다. `http://127.0.0.1:8545`를 지정하고 실행을 중지하면 됩니다. 코드는 그대로 유지됩니다. 달라진 것은 호출에 응답하는 주체뿐입니다.
Geth 사용법: 계정, Clef 및 거래
Geth는 여전히 계정 관리자를 제공하지만, 최근에는 Clef를 실행하여 서명 기능을 노드에서 분리하는 것이 좋습니다. Clef는 키를 저장하고 키를 사용하려는 모든 시도마다 명시적인 확인을 요청하는 작은 별도 프로그램입니다.
Clef를 통해 계정을 만드는 과정은 다음과 같습니다.
```
clef newaccount --keystore /var/lib/geth/keystore
```
Clef는 최소 10자 이상의 비밀번호를 요구합니다. 비밀번호를 입력하면 암호화된 키 저장소 파일을 생성하고 주소를 반환합니다. 이 주소는 외부 소유 계정(EOA)으로, 하드웨어 지갑이나 MetaMask에서 생성하는 것과 같은 유형입니다. 특별한 것은 없습니다.
Geth에서 Clef를 사용하려면 노드가 Clef의 IPC 소켓을 가리키도록 설정해야 합니다. `--signer=/path/to/clef.ipc`와 같이 설정하면 됩니다. 이후부터 Geth 콘솔에서 발생하는 요청이든 JSON-RPC API를 사용하는 dApp에서 발생하는 요청이든 모든 거래 요청은 Clef 터미널에서 승인을 받아야 합니다. 이것이 Geth 팀이 2026년에 권장하는 모델입니다. 키는 노드 외부에 저장되며, 노드 자체는 어떠한 웨이(wei)도 사용할 수 없습니다.
콘솔에서 전송하는 방법은 다음과 같습니다.
```
eth.sendTransaction({
from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',
to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',
value: web3.toWei(0.1, 'ether')
});
```
Clef가 팝업되고, 사용자가 확인합니다. 거래가 멤풀에 들어가고 몇 초 후 블록에 포함됩니다. 이 한 줄의 코드 뒤에서 Geth는 논스 조회, 수수료 추정, Clef로의 서명 전달, 브로드캐스트, 포함 여부 확인 등의 작업을 수행합니다. 이와 동일한 과정이 모든 dApp에서 실행됩니다.
보다 복잡한 작업을 위해서는 동일한 JSON-RPC 엔드포인트를 통해 트랜잭션 제출, 이벤트 구독, 뷰 함수 호출 및 추적을 수행할 수 있습니다. 라이브러리 관점에서 볼 때 로컬 Geth 인스턴스는 호스팅된 노드와 구별할 수 없지만, 더 빠르고 호출당 비용이 무료이며 직접 관리할 수 있다는 장점이 있습니다.
검증자 설정: 이더를 스테이킹하고 보상을 받으세요
Geth 노드가 동기화되고 합의 클라이언트와 연결되면, 검증자 추가는 대부분 설정 작업으로 완료됩니다. 새로운 노드를 설치할 필요가 없습니다. 실행 계층(Geth)은 기존 작업을 계속 수행합니다. 합의 클라이언트는 검증자 역할을 맡아 매 에포크마다 증명서에 서명하고, 프로토콜이 검증자를 선택하면 Geth에 블록 내용을 생성하도록 요청합니다.
Geth를 활성화하려면 세 가지 핵심 요소가 필요합니다. 첫 번째는 32이더를 예치하는 것입니다. 공식 예치 CLI를 사용하여 검증자 키를 생성하고, 메인넷의 컨트랙트로 예치 트랜잭션을 전송한 후 활성화될 때까지 기다립니다. 두 번째는 검증자 클라이언트 프로세스입니다. 이 클라이언트는 비콘 노드와 함께 실행되며, 서명 키를 관리하고 정해진 일정에 따라 검증 문서에 서명합니다. 세 번째는 기본 보상 외에 트랜잭션 순서에 따른 추가 보상을 받으려면 MEV-Boost 또는 릴레이 설정을 활용해야 합니다. Geth 자체는 검증자를 실행하지 않습니다. 검증자 실행은 합의 클라이언트가 담당합니다. Geth는 검증자 슬롯이 활성화되면 실제 블록 페이로드를 생성하는 실행 엔드포인트입니다.
검증자는 일상적으로 세 가지 수치에 주목합니다. 바로 인증 실패, 동기화 가동 시간, 그리고 디스크 부하입니다. 인증 실패는 거의 항상 상위 노드보다 뒤처진 노드에서 발생하며, 이는 결국 디스크 I/O 또는 피어 연결 끊김으로 귀결됩니다. Geth 환경에서 디스크 부하는 대표적인 원인입니다. 권장 NVMe 사양보다 디스크 부하가 낮아지면 인증 효율성이 떨어지고, 그에 따라 보상도 감소합니다.
대부분의 개인 스테이킹 참여자는 인텔 NUC, 비링크(Beelink) 또는 맞춤형 라이젠(Ryzen) PC와 같은 전용 미니 PC를 사용합니다. 하드웨어 구매 비용은 일회성으로 800달러에서 2,000달러 사이이며, 전력 및 인터넷 사용료로 매달 10달러에서 20달러가 추가됩니다. 코인 뷰로(Coin Bureau)의 2026년 분석에 따르면, 전문 헤츠너(Hetzner) 검증자는 월 30달러에서 40달러, AWS 기본 풀 노드는 100달러 미만, AWS 아카이브 노드는 약 1,500달러가 소요될 것으로 예상됩니다. 개인 스테이킹은 기본 보상에 대해 연 4% 정도의 수익률을 제공하며, MEV-Boost를 사용하면 5~6%까지 상승합니다. 개인용 하드웨어를 사용할 경우, 현재 이더리움 가격 기준으로 약 4~6개월 만에 투자금을 회수할 수 있습니다. 2025년 말 기준, 네트워크에는 약 106만 명의 활성 검증자가 있으며, 3,500만~3,700만 ETH(전체 공급량의 29~31%)를 보유하고 있습니다. 리도(Lido)가 전체 스테이킹량의 27.7%를 차지하고 있으며, 코인베이스(Coinbase)는 8.4%를 차지합니다. 독립적인 검증자가 한 명씩 추가될 때마다 그 집중도가 조용히 반대 방향으로 기울어지는데, 이것이 바로 사람들이 여전히 솔로 스테이킹을 하는 이유 중 하나입니다.
테스트넷 vs 메인넷: 이더리움 노드를 실행할 위치는 어디일까요?
메인넷에서 시작하지 마세요. 테스트넷에서는 실수를 해도 큰 손해를 보지 않습니다. Geth는 지원되는 모든 네트워크를 하나의 플래그로 처리합니다.
2026년에 주목해야 할 이더리움 테스트넷은 검증자 중심의 장기 운영 테스트넷인 Holesky와 애플리케이션 중심의 경량 테스트넷인 Sepolia 두 가지입니다. Sepolia Geth 노드를 실행하려면 `--mainnet`을 `--sepolia`로 바꾸세요. Holesky 테스트넷을 실행하려면 `--holesky`를 사용하세요. 데이터 디렉토리는 메인넷의 `chaindata` 디렉토리와 별도의 경로에 있어야 합니다. 같은 폴더를 재사용하면 체인 ID가 일치하지 않아 Geth가 시작되지 않습니다. 이 오류는 해결하는 데 30초밖에 걸리지 않지만, 원인을 찾는 데는 한 시간이 걸릴 수 있습니다.
테스트넷 이더는 무료입니다. Paradigm Multifaucet이나 faucet.sepolia.dev에 있는 Sepolia faucet 같은 곳에서 Sepolia ETH를 충분히 받을 수 있으니, 컨트랙트 배포, 통합 테스트 실행, 수천 건의 트랜잭션 전송에 필요한 양을 확보하세요. 여기서 "이더"는 가상 화폐입니다. 하지만 그 외 모든 것은 실제와 같습니다. EVM 동작 방식, JSON-RPC API, 합의 클라이언트와의 연동 방식, 운영상의 어려움까지 모두 동일합니다. 메인넷에 배포하기 전에 Sepolia에서 일주일 동안 테스트해 보세요.
기존 테스트넷은 더 이상 사용되지 않습니다. Ropsten, Rinkeby, Kovan, Goerli 모두 서비스가 종료되었습니다. 만약 튜토리얼에서 여전히 Geth를 `--ropsten` 옵션으로 시작하라고 안내한다면, 이는 병합 이전 버전이므로 탭을 닫으시는 것이 좋습니다.
진정한 프라이빗 환경을 구축하려면 자체 네트워크를 운영하세요. Geth의 `--dev` 모드는 단일 노드 체인을 몇 초 만에 부팅할 수 있어 단위 테스트에 매우 유용합니다. 여러 대의 머신으로 구성된 프라이빗 네트워크의 경우, 사용자 지정 `genesis.json` 파일을 작성하여 모든 머신에서 공유하고, 각 Geth 프로세스를 `--datadir` 옵션을 사용하여 새로운 체인 데이터 폴더를 지정하며 시작하세요. Kurtosis 프레임워크는 이러한 모든 과정을 하나의 명령으로 처리할 수 있도록 지원하므로, 직접 연결하는 번거로움을 줄일 수 있습니다.
Geth 노드에서 흔히 발생하는 문제 및 해결 방법
대부분의 Geth 관련 문제는 몇 가지 패턴으로 요약됩니다. 패턴을 파악하면 해결은 대개 빠릅니다.
동기화가 몇 퍼센트에서 멈췄습니다. Geth 노드는 온라인 상태이지만 동기화가 진행되지 않고 있습니다. 피어 수가 너무 적거나, 대역폭이 포화되었거나, 디스크 속도가 부족한 경우일 수 있습니다. 콘솔에서 `net.peerCount`를 확인하세요. 값이 15 미만이면 인바운드 P2P 포트가 방화벽에 의해 차단된 것입니다. TCP 및 UDP 포트 30303을 열어주세요. 포트가 정상이라면 동기화 중에 Linux에서 `iostat -xm 5` 명령을 실행하세요. SSD 사용률이 100%에 도달하면 I/O 병목 현상이 발생하고 있으므로 더 빠른 스토리지가 필요합니다. 버전 관련 참고 사항: Geth v1.17.1(2026년 3월 3일)은 v1.17.0의 스냅 동기화 오류를 수정하기 위해 특별히 출시되었습니다. 해당 버전을 사용 중인 경우 업그레이드하는 것이 해결책입니다.
"병합 후 네트워크는 확인되었지만 비콘 클라이언트가 감지되지 않았습니다." 컨센서스 클라이언트가 실행 중이 아니거나, JWT 비밀 키가 일치하지 않거나, 컨센서스 클라이언트가 잘못된 AuthRPC 포트를 가리키고 있습니다. JWT 경로, 포트 8551, 그리고 두 프로세스가 동일한 비밀 키 파일로 시작되었는지 확인하십시오.
디스크 용량이 하룻밤 사이에 가득 찰 수 있습니다. 스냅 동기화는 초기 상태 복구 단계에서 디스크 사용량을 급증시킬 수 있습니다. 이후에는 자동으로 정리 작업이 실행됩니다. 1TB SSD에서 시작했다면 결국 디스크 용량 한계에 도달할 것입니다. Geth의 정리 기능은 이미 최적화되어 있으므로, 더 적극적인 정리 작업보다는 공간을 확보하는 것이 해결책입니다. 체인 데이터를 더 큰 NVMe 드라이브로 옮긴 후 rsync를 사용하여 동기화하세요.
Geth가 시작되지 않습니다. "이 버전의 Geth와 호환되는 데이터베이스를 찾을 수 없습니다." 이전 실행 시 다른 체인 ID, 이전 Geth 버전 또는 손상된 상태를 사용했을 수 있습니다. `chaindata` 폴더가 일치하지 않습니다. 새 데이터 디렉터리로 다시 동기화하거나 이전 Geth 릴리스로 롤백하십시오.
검증자가 증명을 누락했습니다. Geth 노드가 모든 새 블록을 정확하게 읽고 있는데도 검증자가 증명을 누락하는 경우, 디스크 부하를 먼저 확인하고, 그다음 네트워크, 마지막으로 CPU를 확인하십시오. Netdata와 같은 모니터링 도구에서 나타나는 패턴은 명확합니다. 증명 처리 시간 동안 디스크 사용률이 30% 이상일 때 PSI(압력 정체 정보)가 표시됩니다.
RPC 요청 속도가 느립니다. `eth_getLogs` 또는 `debug_traceTransaction`을 과도하게 호출하는 무거운 dApp 클라이언트는 Geth의 CPU를 포화 상태로 만들 수 있습니다. 해당 트래픽을 별도의 노드로 이동하거나, `--rpc.gascap` 및 `--rpc.txfeecap` 옵션을 사용하여 비용이 많이 드는 호출을 제한하십시오.
마지막으로 습관을 하나 더 들이세요. 첫 주 동안은 로그를 지속적으로 확인하여 Geth가 실제 부하 상태에서도 안정적으로 작동하는지 확인하세요. Netdata, Prometheus + Grafana와 같은 도구나 간단히 `journalctl -fu geth` 명령어를 사용하면 초기 오류 발생 가능성을 쉽게 파악할 수 있습니다. 2주 차부터는 인증 누락 및 디스크 사용량 증가에 대한 알림만으로도 충분합니다.
Geth와 다른 이더리움 클라이언트의 장단점 비교
Geth는 기본적으로 가장 먼저 고려해야 할 도구입니다. 하지만 유일한 선택지는 아니며, "Geth로 전환해야 할까요?"라는 질문에 대한 답은 사용자의 필요에 따라 다릅니다.
| 고객 | 언어 | 2026년 지분 (clientdiversity.org / Stake.fish 범위) | 강점 | 다음과 같은 경우에 사용하세요... |
|---|---|---|---|---|
| 게스 | 가다 | 41~50% | 안정성, 대규모 커뮤니티, 공식 기본값 | 가장 안전한 첫 번째 노드를 원합니다. |
| 네더마인드 | 기음# | 25~38% | 빠른 스냅 동기화, 플러그인 호환성, 하이퍼레저 | Go 언어가 아닌 실행 클라이언트를 원하시는군요. |
| 베수 | 자바 | 10~16% | 엔터프라이즈 기능, 권한 기반 체인, 하이퍼레저 | 당신은 허가형 체인을 운영합니다. |
| 레스 | 녹 | 2~8% | 모듈형, 최신 코드베이스, 빠른 동기화 | 최고의 Rust 클라이언트를 원하시나요? |
| 에리곤 | 러스트/고 | 3~7% | 용량이 작은 아카이브(약 1.77TB), 빠른 기록 조회 기능 | 작은 아카이브 노드가 필요합니다. |
Geth 이외의 클라이언트를 선택해야 하는 커뮤니티의 주장은 클라이언트 다양성입니다. 만약 단일 실행 클라이언트가 메인넷에서 3분의 2 이상의 초다수표를 확보하고 버그가 있는 업그레이드를 배포한다면, 해당 클라이언트의 검증자들은 슬래싱(slashing) 위험에 처하게 됩니다. 검증자 플릿을 두 개의 클라이언트로 분산하면 이러한 위험을 절반으로 줄일 수 있습니다. 단일 홈 스테이커의 경우, 계산은 더 간단합니다. 안정적으로 운영할 수 있는 클라이언트를 선택하고, 잘 관리하다가 특별한 이유가 있을 때만 교체하면 됩니다. 노드 아키텍처는 모든 클라이언트에서 유사하므로 나중에 교체하는 것도 생각보다 쉽습니다. 특히 Erigon과 Reth는 이제 단순한 호기심의 대상이 아니라 주력 클라이언트로 사용하기에 충분히 성숙했습니다.
