본문 바로가기
EverChain(BlockChain)/EtherEver

[EtherEver] ⛓️ 격세지감의 이더리움 개발 스택 PART2

by EverChain 2026. 9. 12.
⚠️ **블로그 컨셉상 반어체가 들어가니 양해바랍니다
**


ETH SEOUL : 2025년 8월 6일 수요일

📌 이전 편: 격세지감의 이더리움 개발 스택 PART1 — 서버맨의 라떼 시절 스택 총정리

🏆 저번 포스팅에서는 서버맨의 라떼시절에 쓰던 이더리움 개발 스택에 대해 알아보았었다.
오늘은 2026년 현시점에 주력으로 쓰이는 차세대 이더리움 개발 스택에 대해 알아보겠다.

🗺️ 2026년 이더리움 개발 스택 전체 지도

🗂️ 프로젝트
↓
🔨 Foundry
↓
Solidity 테스트
fuzz / invariant
🦺 Hardhat
↓
TypeScript
deployment
↓
⛓️ Ethereum

🦺 Hardhat — JS/TS 진영의 대장

Hardhat3

 

하드햇(안전모)는 JS/TS 중심 Ethereum 개발 프레임워크이다.

 

하드햇에는 저번에 소개한 Truffle처럼 컴파일, 테스트, 스크립트, 배포, 로컬 개발 네트워크를 모두 지원한다.
2023년에 Consensys가 Truffle을 sunset(개발 종료/지원 종료 방향)하기로 발표하면서 사실상 남은 후보는 Hardhat과 Foundry 이다.

 

자바스크립트와 타입스크립트가 주력인 프레임워크라서 대부분의 많은 EVM 개발 회사에서 (혹은 SI업체)에서 당당한 현역의 자리를 차지하고 있다.

🟢 Hardhat이 딱인 프로젝트 구조

Next.js TypeScript React wagmi viem Node.js backend
↓
🦺 Hardhat
↓
📄 Solidity
💡 정리: 프론트엔드/백엔드 개발자가 Ethereum을 붙이는 느낌이면 Hardhat이 좋고, Solidity/EVM 프로토콜 개발자가 애플리케이션을 만드는 느낌이면 다음에 설명할 Foundry가 좋다고 생각하면 된다.

🟡 Hardhat v2 → v3, 파이썬 2 → 3의 향기 ☕

⚠️ 주의: 서버맨은 졸업할때 즈음에 하드햇v2를 쓰다가 이후에 개인적으로 개발할 때 v3가 등장해서, 졸업 이후 개발하는 프로젝트들은 또다시 코드들을 뒤엎어야하는 상황이 발생했다. 완벽한 비유는 아니지만 하드햇 v2와 v3는 파이썬 2.X대와 파이썬 3.X대의 차이 정도라고 봐도 될 거 같다.

 

하드햇의 재밌는 점은 TS 파일로도 테스트할 수 있고 Solidity 파일로도 테스트할 수 있다는 것이다.

 

개발스택 변천사를 알아보는 거니 간단하게만 사용법을 알아보면:

설치:
npm init -y

npm install --save-dev hardhat

 

컴파일:
npx hardhat compile

 

테스트:
npx hardhat test

 

배포 (Ignition 이용):
npx hardhat ignition deploy ignition/modules/Counter.ts --network sepolia

※ .env에 RPC_URL 등록 필수


🔨 Foundry — Rust의 힘을 등에 업은 스택

파운드리

 

파운드리 중심의 Ethereum 개발 스택은 대략 다음과 같다:

📄 Solidity
+ OpenZeppelin
↓
🔨 Foundry
⚙️ Forge
compile · test · fuzz · deploy
🔩 Anvil
local EVM
📡 Cast
RPC · contract interaction
🔭 Tenderly
(선택적)
↓
🌐 viem
+
🎣 wagmi
↓
🖥️ Frontend

🟢 Foundry의 강점들

✅ 속도: Rust 기반이라서 컴파일에 있어서 압도적인 속도를 낸다.
✅ 의존성 지옥 탈출: 하드햇은 node_modules, npm, package.json 같은 의존성 디펜던시가 필요한데, 파운드리는 순수 Rust 바이너리(forge, cast, anvil)만으로 동작한다. npm의 의존성 지옥이나 어제까지 잘 쓰다가 다음날 npm 업데이트로 멀쩡한 코드가 실행이 안 되는 대참사를 겪어본 노드맨들은 이게 무슨 뜻인지 제대로 알 거다. 😂
✅ Fuzz 테스트 내장: forge에서 내장함수 파라미터를 랜덤하게 넣어보는 퍼즈 테스트가 기본 내장되어 있어서 하드햇보다 테스트가 편리하다.
✅ Anvil 치트코드: vm.prank, vm.warp, vm.roll, vm.deal, vm.expectRevert, vm.mockCall, vm.createFork() 등 다양한 치트코드 사용 시 hardhat 테스트넷 대비 오버헤드가 적다.

🌐 viem & wagmi — 현대 프론트엔드의 이더리움 연결고리

시대가 React / Vue / Vite의 시대라서 현대의 웹 사이트들은 거의다 react 기반이다.

(요샌 서버맨처럼 허접하게 html에서 ethersjs, web3js만 쪼물딱하지 않는다ㅜㅜ)

 

그러다 보니 기존의 RPC 호출을 대체하는 레이어와 React용 상태관리/훅 레이어가 필요하다.


🔵 viem — ethers.js의 후계자

viem

 

viem은 ethers.js를 대체하는 포지션이다. RPC 호출, 컨트랙트 read/write, 트랜잭션 인코딩/디코딩, ABI 파싱 등을 담당한다.

특징 설명
타입 안정성 ABI를 넘기면 TypeScript가 함수 이름, 파라미터 타입, 리턴 타입까지 자동으로 추론한다. contract.read.balanceOf(['0x...']) 같은 호출에서 잘못된 함수명이나 타입을 넣으면 컴파일 타임에 바로 에러가 난다. ethers.js는 이 부분이 약해서 런타임에야 오류를 알게 되는 경우가 많았다.
번들 사이즈 트리셰이킹이 잘 되도록 설계되어 있어 필요한 함수만 가져다 쓰면 번들이 가볍다. ethers.js는 상대적으로 무겁다.
속도 내부적으로 저수준 최적화(불필요한 추상화 제거)가 되어 있어 인코딩/디코딩 성능이 ethers.js보다 빠르다.
모던 API 처음부터 TypeScript와 최신 JS 문법(예: native BigInt)을 기준으로 설계되어 있어, ethers.js처럼 과거 버전과의 호환성 부담이 없다.

🟠 wagmi — React 훅으로 이더리움 상태관리

WAGMI : We're All Gonna Make It

 

🤔 WAGMI = "We're All Gonna Make It" (우리는 모두 성공할 거야) 🎉

 

wagmi는 viem 위에 React 훅을 얹은 라이브러리다. viem만으로도 컨트랙트 호출은 가능하지만, 프론트엔드에서는 지갑 연결 상태, 로딩/에러 상태, 캐싱, 리렌더링 같은 걸 직접 다 관리해야 해서 번거롭다.

기능 설명
지갑 연결 관리 useConnect, useAccount, useDisconnect 등으로 MetaMask, WalletConnect, Coinbase Wallet 등 여러 지갑 연동을 통일된 인터페이스로 처리한다.
데이터 페칭 + 캐싱 내부적으로 TanStack Query(구 react-query)를 기반으로 동작해서, useReadContract 한 줄로 로딩 상태, 에러 상태, 캐싱, 자동 리페치까지 다 따라온다.
트랜잭션 라이프사이클 useWriteContract, useWaitForTransactionReceipt 등으로 "전송 → 대기 → confirm" 흐름을 선언적으로 다룬다.
체인 전환/멀티체인 useSwitchChain 등으로 사용자가 여러 체인을 오갈 때의 UX를 표준화된 방식으로 처리한다.
🏆 한 줄 정리:
viem = "이더리움과 어떻게 통신할 것인가" → 코어 레이어 (프레임워크 무관)
wagmi = "그 통신을 React 컴포넌트 안에서 어떻게 상태로 관리할 것인가" → React 레이어

🌌 Cosmos SDK — 앱체인의 세계로

코스모스SDK

 

🟡 언제 Foundry/Hardhat을 쓰고, 언제 Cosmos SDK를 쓰나?

상황 선택지
빠르게 디앱을 개발해서 출시하고 싶고, 이더리움 생태계의 풍부한 자본과 유동성을 그대로 활용하고 싶을 때 Foundry / Hardhat
앱의 규모가 너무 커져서 이더리움의 느린 속도와 비싼 수수료를 감당할 수 없을 때. DEX나 블록체인 게임처럼 압도적인 처리량과 독자적인 인프라(메인넷)가 필요할 때 Cosmos SDK / CometBFT
🤔 대표 사례 — dYdX의 대이주: 유명 탈중앙화 거래소인 dYdX는 원래 이더리움 위에 있다가, 이더리움의 한계를 느끼고 Cosmos SDK를 이용해 자신들만의 독립적인 블록체인(dYdX Chain)을 만들어 이사 간 대표적인 사례다.

🟢 코스모스 SDK를 써야 하는 이유

1. 앱체인(App-specific chain) 아키텍처
코스모스SDK는 "하나의 범용 체인 위에서 모든 앱이 경쟁하는" 모델이 아니라, 애플리케이션 하나당 체인 하나를 만드는 걸 전제로 설계되어 있다. 즉 자체 검증인 세트, 자체 가스비 정책, 자체 거버넌스를 가진 독립 체인을 처음부터 빠르게 찍어낼 수 있다.

 

2. 모듈러 구조
x/bank, x/staking, x/gov, x/ibc 같은 모듈을 레고 블록처럼 조합해서 체인을 구성한다. Geth를 포크해서 EVM 내부를 직접 뜯어고치는 것과 달리, 필요한 모듈만 붙이거나 커스텀 모듈을 새로 짜서 끼우는 방식이라 개발 자유도가 훨씬 높다.

 

3. IBC (Inter-Blockchain Communication)
코스모스 생태계의 핵심 차별점. 각 체인이 독립적인 합의를 유지하면서도 IBC 프로토콜로 토큰/메시지를 신뢰 없이(trustless) 주고받을 수 있다. 브릿지를 별도로 만들 필요 없이 프로토콜 레벨에서 상호운용성이 보장된다.

 

4. CometBFT (구 Tendermint) 합의
BFT 기반 즉시 파이널리티(instant finality) 합의를 기본 제공한다. PoW처럼 확률적 파이널리티가 아니라, 블록이 커밋되는 순간 되돌릴 수 없다는 게 보장된다. 이더리움 계열이 finality를 얻기까지 여러 블록/에폭을 기다려야 하는 것과 대조적이다.

 

5. 거버넌스가 프로토콜에 내장
온체인 파라미터 변경, 업그레이드 등을 x/gov 모듈로 코드 레벨에서 표준화해서 제공한다.


⚡ 서버맨의 선택 — 이더에버 (EtherEver)

근데 알다시피(?) 서버맨은 이더리움 1,919,999블록에서 하드포크하여 커스텀 EVM L1체인인 이더에버를 개발 및 운영하고 있다.

  • 메타마스크를 포크 → 이더에버마스크 (이더에버 전용 지갑)
  • 블록스카우트를 포크 → 이더에버스카우트 (온체인 트랜잭션 탐색기)
  • 아비트럼 니트로를 포크 → 아비에버 (이더에버 전용 커스텀 L2 AnyTrust 체인)
🤔 그러면 코스모스SDK 같은 툴체인으로 딸깍해서 체인 만들고 할 수 있는데 뭣하러 커스텀 체인을 만들었을까? 🤷

🟠 이더에버 vs 코스모스SDK — 뭐가 더 유리한가?

비교 항목 이더에버 (EVM 포크) 코스모스 SDK
EVM 생태계 호환 ✅ 완전 호환 (Core-Geth 포크) ⚠️ evmos/ethermint 모듈 필요, 완전 1:1 호환 아님
보안 모델 PoW — 해시파워 경쟁으로 보안 담보, 검증인 담합 리스크 없음 PoS — 초기 검증인 분포, 스테이킹 집중도에 따라 탈중앙성이 설계 단계에서 좌우됨
L2 확장 ArbiEver (Arbitrum Nitro AnyTrust 포크) — 검증된 스택 재사용 별도 L2 스택 구축 또는 롤업 프레임워크 신규 통합 필요
상호운용성 이더리움 생태계 내 ✅ IBC 프로토콜로 체인 간 trustless 통신
러닝커브 기존 Geth/Nitro 지식 재사용 가능 CosmosSDK + CometBFT + IBC 신규 학습 필요
🏆 결론: 상호운용성과 체인 설계 자유도가 중요하다면 코스모스SDK, 이더리움 생태계 호환성과 기존에 쌓아온 EVM/L2 스택 재사용이 중요하다면 이더에버 방식(EVM 포크)이 유리하다.

💡 막간 — 이더리움 클라이언트의 세계

ERIGON

 

이왕 개발스택 포스팅을 한 김에 막간을 이용해 다양한 이더리움의 클라이언트 종류에 대해 정리하겠다.

⚙️ EL (실행 레이어) 클라이언트

클라이언트 개발 언어 주요 특징 점유율 (2026)
Nethermind 🥇 C# 엔터프라이즈 친화적. 플러그인 아키텍처, MEV 최적화, 동기화 속도 최강. 2026년 기준 점유율 1위로 올라섰다. ~45% 🥇
Geth Go 이더리움 공식 레퍼런스 구현체. 생태계 표준. 가장 오래 검증된 클라이언트. 한때 절대 1위였지만 Nethermind에 왕좌를 내줬다. ~33%
Besu Java Hyperledger 재단 지원. 프라이빗/퍼미션드 네트워크에서도 사용 가능한 엔터프라이즈 클라이언트. ~15%
Core-Geth Go Geth에서 파생. ETC(이더리움 클래식) 등 멀티체인 지원. 서버맨의 이더에버 기반이기도 하다. 소규모 (포크 체인 위주)
Erigon Go Geth 포크에서 출발, 아키텍처를 근본적으로 재설계. 디스크 사용량 대폭 절감, 아카이브 노드 운용에 강점. ~5%
Reth Rust Paradigm이 개발한 차세대 클라이언트. 압도적인 동기화 속도와 낮은 메모리 사용량. 빠르게 점유율 상승 중. ↑ 급상승 중

⚙️ CL (합의 레이어) 클라이언트

클라이언트 개발 언어 주요 특징 점유율 (2026)
Lighthouse 🥇 Rust Sigma Prime 개발. Rust 특유의 성능과 메모리 안전성. 2024년 이후 점유율이 꾸준히 상승해 2026년 기준 압도적 1위로 자리잡았다. ~38% 🥇
Nimbus Nim Status 개발. 경량 설계로 라즈베리파이 같은 저사양 하드웨어에서도 실행 가능. 임베디드 환경 특화. 2026년 들어 2위로 치고 올라왔다. ~21%
Prysm Go Prysmatic Labs 개발. 한때 압도적 1위였으나 2025년 Fusaka 업그레이드 직후 v7.0.0 리소스 소진 버그로 대량 이탈이 발생해 3위로 내려앉았다. ~19%
Teku Java ConsenSys 개발. 엔터프라이즈/기관 투자자 운용 친화적. Besu와 함께 쓰는 경우가 많다. ~12%
Lodestar TypeScript ChainSafe 개발. 유일한 TypeScript/JS 구현체. 연구/프로토타이핑 용도로 많이 활용된다. ~5%
🚨 Prysm 몰락의 트리거 — 2025년 12월 Fusaka 사건: 2025년 12월 Fusaka 하드포크 직후 Prysm v7.0.0에서 리소스 소진 버그가 터졌다. Prysm 노드들이 줄줄이 뻗으면서 이더리움 전체 네트워크 참여율이 74.7%까지 폭락했고, 이게 Prysm 대탈출의 계기 중 하나가 됐다. 근데 이 사건이 역설적으로 비탈릭 철학의 정당성을 완벽하게 증명해버렸다. Lighthouse, Nimbus, Teku 같은 다른 언어 클라이언트들이 멀쩡하게 버텨줬기 때문에 체인은 계속 돌아갔다. 만약 Prysm이 90% 점유율을 차지하고 있었다면..? 🤯

 

일단 이 정도를 봤을 때 보통의 사람이라면 이런 생각이 들어야 한다 🤯

🚨 "도대체 다양함을 넘어서서 왜 이렇게 많은 거야??? 이게 말이 돼? 언제 다 공부해?"

 

사람인 이상 다 공부할 수 없다. 다 알 수도 없다.

하지만 중요한 건, 비트코인은 90% 이상이 비트코인 코어로 돌아가는 반면,

 

이더리움이 이렇게까지 다양한 이유는 비탈릭의 의도된 철학 때문이다.

🤔 비탈릭의 의도: 클라이언트들을 언어적으로 다양하게 만들고 균형된 분포로 운영되게 해서, 한쪽의 언어 클라이언트에서 치명적인 오류와 해킹이 일어나도 합의 구조상 나머지 다른 언어들이 버텨준다면 전체 네트워크에는 그 어떠한 피해도 없게 만들려는 의도다. 위에서 본 Fusaka 사건이 바로 그 살아있는 실례다.

맨날 AI를 이용한 해킹이 빈번이 일어나는 요즘 시대에 몇 수 앞을 내다본거 같은 정말 대단한 사람이 아닐 수 없다.. 💪


🃏 그래서 이더리움은 이걸로 끝인가?

더 알면 다쳐

⚠️ 스포: 아직 끝이 아니다. 그리고 계속 새로운 것들이 개발 중이다.😂

📋 2026년 기준 이더리움 개발 스택 총정리

분야 대표 툴
언어 Solidity
IDE Remix
개발 프레임워크 Hardhat / Foundry
컴파일러 solc
로컬 노드 Anvil / Hardhat Network
컨트랙트 라이브러리 OpenZeppelin
JS RPC ethers.js / viem
React 연동 wagmi
지갑 MetaMask / Rabby
RPC Infura / Alchemy / QuickNode
탐색기 Etherscan / Blockscout
디버깅 Tenderly
인덱싱 The Graph / Subsquid / Ponder
보안 Slither / Echidna / Mythril / Certora
Execution Client Geth / Nethermind / Erigon / Besu / Reth
Consensus Client Lighthouse / Prysm / Teku / Nimbus / Lodestar

 

지난 PART1까지 합치면 얼추 언급은 대부분 한 거 같다. 그리고 토 나올 정도로 많다.

 

하지만 결국 언급 정도만 한 것이고 인덱싱, 보안, 지갑 이런 건 포스팅에서 다루지도 않았으며,

각각에 대해 세부적으로 파고들어가려면 블로그 포스팅으로는 한계가 있다.


🧰 그래서 서버맨이 실제로 쓰는 조합은?

서버맨은 하드햇이 편한데 리믹스도 다른 의미로 편함

 

지금까지의 장황한 이론은 이쯤 하고, 그래서 서버맨 본인은 실전에서 뭘 쓰냐고 물어보면 답은 의외로 심플하다. 😎

🏆 서버맨의 실전 조합: 메인은 Hardhat + 이더에버, 그리고 간단한 컴파일/배포는 그냥 Remix IDE에서 뚝딱 해치운다. 🛠️
💡 왜 Hardhat인가: 이더에버는 Core-Geth 포크라서 EVM 완전 호환이고, 네트워크 설정도 hardhat.config.ts에 RPC_URL이랑 체인 ID만 커스텀 네트워크로 등록하면 끝이다. 배포 스크립트, 테스트, Ignition 모듈까지 그대로 재사용되니 굳이 Foundry로 갈아탈 이유가 없었다. 이더에버마스크(포크한 메타마스크)랑 연동도 결국 JS 생태계라서 궁합이 잘 맞는다.
⚠️ 근데 왜 Remix도 같이 쓰냐면: 컨트랙트 하나 뚝딱 짜서 이더에버스카우트(블록스카우트 포크)에 Verify까지 빠르게 걸어야 할 때는 프로젝트 폴더 만들고 npm install 돌리는 것 자체가 오버스펙이다. 이럴 땐 그냥 브라우저 열고 Remix에서 컨트랙트 하나 붙여넣고 커스텀 네트워크(이더에버 RPC)로 바로 배포해버리는 게 훨씬 빠르다. PART1에서 얘기했듯이 요즘 Remix는 밀키트 수준으로 진화해서, OpenZeppelin 라이브러리 자동 import에 flattened 파일까지 원클릭으로 뽑아주니 Verify 작업도 순식간이다.
✅ 정리하면: 규모 있는 프로젝트(테스트 스위트, CI, 반복 배포)는 Hardhat, 빠르게 찍먹하고 검증만 하면 되는 소규모 컨트랙트는 Remix. Foundry의 Rust 속도가 매력적이긴 한데, 이더에버 생태계 전체가 이미 JS/TS 기반 도구(이더에버마스크 연동 스크립트, 이더에버스카우트 API 등)로 짜여 있다 보니 굳이 새로 배울 이유가 없어서 아직은 Hardhat 진영에 머물러 있다. 😅

📝 마무리

🏆 PART1 + PART2 총정리

PART1에서는 서버맨의 라떼 시절(Truffle, Ganache, web3.js, ethers.js 등)의 스택을 살펴봤고, PART2에서는 2026년 현시점의 Hardhat v3와 Foundry를 중심으로, 프론트엔드 쪽의 viem + wagmi 조합, 체인 레벨에서의 Cosmos SDK vs EVM 포크(이더에버)의 선택 기준, 그리고 이더리움 클라이언트의 다양성이 단순한 혼잡이 아니라 비탈릭의 의도된 보안 철학임을 알아보았다.

트렌드 정도만 훑은 거지만, 이 정도면 현시점 이더리움 생태계의 지형도는 머릿속에 그려졌을 거다. 🎯

 

이 포스팅을 읽다가 다들 뒤로가기 눌렀을 거라고 확신한다.

쓰면서도 토 나올 정도로 많고 요약이 불가능한 이더리움 생태계와 개발 현실이다.

 

AI 생태계도 발전이 빠르고 따라갈 수 없을 정도이지만, 

현업자가 아닌 사람들은 블록체인 씬도 만만치 않게 바쁘게 움직이고 있다 라고만 기억해두면 될거 같다

 

각 분야를 깊게 파고드는 건 앞으로의 포스팅에서 천천히 다뤄보겠다.

질문은 언제나 환영 🙌


 

🛰️ 서버맨의 공간들

 

  🐱 GitHub      🗂️ 포트폴리오   🔗 에버체인 포털

728x90