Skip to content
Published on

Web3 & 스마트 컨트랙트 개발 2026 — Hardhat / Foundry / Solidity / Cairo (StarkNet) / Anchor (Solana) / viem / wagmi / OpenZeppelin / Slither / Tenderly 심층 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — "Web3는 죽었다"라는 주장과 2026년의 실상

2022년 크립토 윈터, 2023년 FTX 잔해, 2024년 SBF 종신형, 그리고 2025년 ETF 승인 이후 또 한 차례의 "이번엔 진짜다" 사이클 — Web3는 매년 죽었다고 선언되고, 매년 빌더 수가 더 늘었다. 2026년 봄, 정직하게 말하면 두 가지가 동시에 사실이다.

하나, 소비자 dApp 시장은 여전히 작다. NFT 호황은 끝났고, "DeFi 여름" 같은 광기는 더 이상 오지 않는다. 일반 사용자에게 가스비를 받는 모델은 L2에서도 마찰이 크다.

둘, 인프라와 개발자 도구는 그 어느 때보다 좋다. Foundry는 처음으로 "Web2 수준의 DX"를 줬고, viem과 wagmi가 클라이언트 측의 페인을 크게 줄였고, OpenZeppelin 5.x는 ERC 표준을 안전하게 가져다 쓸 수 있게 했고, Slither/Mythril/Echidna/Halmos가 정적 분석·심볼릭 실행·퍼즈 테스트를 일상화시켰다. RPC는 Alchemy·Infura·QuickNode가 격렬하게 경쟁해 가격이 내려갔다. L2는 Arbitrum·Optimism·Base가 자리를 잡았고, zkSync·Polygon zkEVM·StarkNet의 ZK 진영도 살아남았다.

이 글의 전제는 두 가지다. (1) 2026년에 진지하게 스마트 컨트랙트를 쓰려는 사람에게, 어떤 도구를 골라야 하는지 정직하게 정리한다. (2) 한 진영만 보지 않고 EVM·Solana·StarkNet·Stylus(Rust) 네 진영을 같은 축으로 비교한다.

모델은 점점 같아지고, 인프라가 차이를 만든다. Solidity 0.8.x는 5년째 비슷한데, Hardhat과 Foundry로 일하는 경험은 완전히 다르다.

가격·기능·성능 수치는 빠르게 바뀐다. 이 글의 모든 숫자는 2026년 5월 기준이며, 구조적 차이에 집중한다. 6개월 뒤 숫자가 바뀌어도 의사결정 프레임은 유효해야 한다.

1장 · 2026년 Web3 개발 지도 — EVM / Solana / StarkNet / Stylus 4 진영

먼저 큰 그림. 2026년의 스마트 컨트랙트는 네 개의 가상머신·언어 진영으로 갈린다.

진영 1 · EVM + Solidity/Vyper. Ethereum mainnet과 그 위의 L2들(Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll 등). 언어는 Solidity 0.8.x가 압도적이고 Vyper가 소수 대안. 도구는 Hardhat 또는 Foundry. 클라이언트는 ethers.js v6 또는 viem. 전 세계 스마트 컨트랙트 TVL의 절대다수가 여기 있다.

진영 2 · Solana + Rust(Anchor) / Move(Sealevel). Anchor 프레임워크가 Rust 위에 IDL과 보일러플레이트를 깔아 EVM에서 넘어온 개발자들에게도 친숙해졌다. Helius가 Solana 전용 RPC를 키웠고, Metaplex가 NFT/토큰 표준을 만들었다. 거래 비용이 낮고 TPS가 높아 게임·결제 시도가 많다.

진영 3 · StarkNet + Cairo. StarkWare가 만든 ZK-friendly 언어 Cairo. 2026년에는 Cairo 2.x가 일반적이고, Starknet Foundry가 Foundry-스타일 워크플로를 가져왔다. ZK 증명을 컨트랙트 레벨에서 자연스럽게 다룰 수 있는 거의 유일한 메인스트림 옵션.

진영 4 · Arbitrum Stylus + Rust/C/C++. Arbitrum이 WASM 기반 가상머신을 EVM 옆에 붙여, Rust로 짠 컨트랙트가 같은 체인에서 Solidity 컨트랙트와 함께 도는 구조를 만들었다. 2024년 베타, 2025년 mainnet, 2026년 본격 채택기. Solidity보다 10~100배 가스 효율, 그러나 생태계는 아직 초기.

진영 선택은 보통 "어느 체인에 배포할 것인가"가 먼저 결정한 다음 자동으로 따라온다. Ethereum mainnet이나 L2 → EVM/Solidity. Solana → Rust/Anchor. StarkNet → Cairo. Arbitrum이고 Rust 잘하면 Stylus. 이 글의 뒷부분은 각 진영의 핵심 도구를 같은 틀로 정리한다.

부가적으로 언어가 같아도 도구가 다르다는 점을 강조해두자. Solidity는 한 언어인데 Hardhat과 Foundry는 완전히 다른 개발 경험을 준다. Rust는 한 언어인데 Anchor(Solana)와 Stylus SDK(Arbitrum)는 다른 모델이다. 도구 선택이 종종 언어 선택보다 더 중요하다.

2장 · Hardhat (Nomic Foundation) — 클래식 Solidity 개발 환경

Hardhat은 Nomic Foundation이 만든, EVM 진영의 "기존 표준". JavaScript/TypeScript 위에서 컴파일·테스트·배포·디버깅을 일관되게 묶어준다. 2018년부터 있었고, 2026년에도 여전히 가장 큰 사용자 베이스를 가진다.

핵심 기능은 다음과 같다.

# 새 프로젝트
npx hardhat init

# 컴파일
npx hardhat compile

# 테스트 (Mocha + Chai + ethers/viem)
npx hardhat test

# 로컬 네트워크 (HardhatNetwork, fork도 가능)
npx hardhat node

# 배포 (Ignition)
npx hardhat ignition deploy ./ignition/modules/MyModule.ts

Hardhat의 진짜 매력은 플러그인 생태계다. @nomicfoundation/hardhat-toolbox만 깔아도 verify, gas-reporter, coverage, typechain이 한 번에 들어온다. TypeScript 1급 지원, Chai matcher(expect(tx).to.emit(...)), Mainnet fork(과거 블록 상태를 로컬에서 재현), console.log from Solidity — 이런 것들이 다 Hardhat 생태계에서 자라났다.

2026년 시점에서 Hardhat의 가장 큰 변화는 두 가지.

Hardhat 3 (Rust 재작성). 2025년 말부터 베타 단계로 공개된 Hardhat 3은 핵심을 Rust로 재작성해 빌드·테스트가 훨씬 빨라졌다. Foundry가 가져간 "속도" 축을 다시 찾아오려는 시도. 같은 프로젝트에서 Hardhat 2 대비 2~5배 빠른 컴파일·테스트가 보고된다.

Hardhat Ignition. 명령형 deploy 스크립트(deploy.ts에 if-else로 배포 순서 짜기)를 선언형 모듈로 바꿨다. "이 컨트랙트는 저 컨트랙트의 주소를 받아야 한다"를 의존성 그래프로 표현하면 Ignition이 알아서 순서를 풀고, 실패 지점부터 재개할 수 있다. 멀티스텝 배포(예: Proxy + Implementation + Initialize)에서 특히 빛난다.

import { buildModule } from '@nomicfoundation/hardhat-ignition/modules'

export default buildModule('LockModule', (m) => {
  const unlockTime = m.getParameter('unlockTime', 1893456000n)
  const lockedAmount = m.getParameter('lockedAmount', 1_000_000_000n)
  const lock = m.contract('Lock', [unlockTime], { value: lockedAmount })
  return { lock }
})

Hardhat의 단점도 정직하게 짚자. (1) Node.js/TypeScript 위에서 도는 만큼 CI에서 느리다 — 같은 Solidity 코드를 Foundry가 5초에 컴파일하면 Hardhat 2는 30초 걸리는 경우도 있다(Hardhat 3가 줄였지만 아직 Foundry보다는 느리다). (2) Solidity로 테스트를 못 쓰고 TS/JS로만 쓴다 — Foundry의 forge test가 Solidity로 직접 테스트를 쓰는 것과 결정적 차이. (3) fuzz 테스트가 약하다 — 기본 제공이 없고 플러그인을 깔아야 한다.

그래도 풍부한 플러그인, TypeScript 친화, 익숙한 Node.js 생태계라는 무기 때문에, 특히 "스마트 컨트랙트 + 프론트엔드 + 백엔드를 한 모노레포에서 다루는" 팀에는 여전히 강력한 선택이다.

3장 · Foundry (Paradigm) — Forge / Cast / Anvil / Chisel

Foundry는 Paradigm이 만든, 2026년 시점에서 사실상의 "새 표준". 처음부터 Rust로 작성해 속도가 매우 빠르고, Solidity로 테스트를 쓴다는 결정 하나로 개발 경험을 완전히 바꿨다.

Foundry는 네 개의 도구로 구성된다.

  • Forge — 컴파일·테스트·배포. Hardhat의 대체.
  • Cast — CLI에서 체인과 대화하는 도구. cast call, cast send, cast estimate. ethers/viem의 CLI 버전이라 생각하면 된다.
  • Anvil — 로컬 노드/포크. Hardhat Network의 대체.
  • Chisel — Solidity REPL. 한 줄씩 실행해보는 인터프리터.

설치는 한 줄.

curl -L https://foundry.paradigm.xyz | bash
foundryup

가장 결정적인 차이는 테스트가 Solidity라는 점이다.

// test/Counter.t.sol
import { Test } from "forge-std/Test.sol";
import { Counter } from "../src/Counter.sol";

contract CounterTest is Test {
    Counter public counter;

    function setUp() public {
        counter = new Counter();
    }

    function test_Increment() public {
        counter.increment();
        assertEq(counter.number(), 1);
    }

    // 퍼즈 테스트 — 입력을 forge가 자동 생성
    function testFuzz_SetNumber(uint256 x) public {
        counter.setNumber(x);
        assertEq(counter.number(), x);
    }
}

Solidity로 테스트를 쓰면 좋은 점이 세 가지. (1) 컨트랙트 코드와 같은 언어라 컨텍스트 전환 비용이 0. (2) vm.prank(alice) 같은 cheatcode로 호출자·시간·블록을 즉시 조작. (3) forge test가 모든 testFuzz_* 함수를 자동으로 퍼즈 테스트로 인식 — 기본 256번 무작위 입력 실행.

그리고 속도. 같은 100개 테스트 프로젝트에서 Hardhat이 3060초 걸리는 일을 Forge는 25초에 끝낸다. CI 비용이 큰 팀에서 결정적 차이.

Cast의 예.

# 컨트랙트 함수 호출
cast call 0xA0b8... "balanceOf(address)" 0xdeadbeef... --rpc-url $RPC

# 트랜잭션 전송
cast send 0xA0b8... "transfer(address,uint256)" 0x123... 1000 \
  --private-key $PK --rpc-url $RPC

# 트랜잭션 디코드
cast tx 0x4a3... --rpc-url $RPC

Anvil은 Hardhat Network와 거의 호환되는 로컬 노드인데, mainnet fork가 매우 빠르다. anvil --fork-url $MAINNET_RPC로 mainnet 상태를 끌어와 로컬에서 실험할 수 있다. forking은 모든 스마트 컨트랙트 개발의 핵심 워크플로.

Foundry의 단점도 정직하게. (1) JavaScript/TypeScript 생태계와 통합이 약하다 — 프론트엔드에 컨트랙트 타입을 자동 export 같은 게 Hardhat만큼 매끄럽지 않다. (2) 플러그인 생태계가 Hardhat보다 좁다. (3) Solidity로 테스트를 쓰는 만큼 비-EVM 로직(예: 외부 API 호출 흉내)을 짜기는 더 어렵다.

그래도 2026년에 새로 프로젝트를 시작한다면 Foundry가 기본값이다. Hardhat은 기존 프로젝트가 많거나 TS 생태계와 깊게 묶인 팀에서 남는다.

4장 · Solidity 0.8.x / Vyper — 언어 선택

EVM 진영에서 언어 선택지는 사실상 두 개다. Solidity와 Vyper.

Solidity 0.8.x는 2021년부터 안정 라인. 가장 큰 변화는 0.8.0에서 도입된 체크된 산술(checked arithmetic) — 오버플로/언더플로가 자동으로 revert. 그 이전 0.7.x까지는 SafeMath 라이브러리를 일일이 깔아야 했는데, 이제 디폴트로 안전하다. 0.8.20부터는 EVM 버전을 paris/shanghai/cancun/prague로 명시할 수 있어 L2별 호환성을 다루기 쉬워졌다.

2026년 시점에서 Solidity 0.8.x의 주요 추가 기능들.

  • unchecked { ... } — 산술 체크를 명시적으로 끄는 블록. 가스 절약용.
  • Custom errors — error Unauthorized(address caller); — revert string보다 가스가 훨씬 적게 든다.
  • using ... for ... — 라이브러리 함수를 타입에 attach. Solidity의 confidence-trick.
  • Transient storage(0.8.24+, Cancun) — tstore/tload. 트랜잭션 동안만 살아남는 storage. Reentrancy lock 같은 패턴에 가스 절약.
  • require with custom error(0.8.26+) — 기존엔 revert MyError()만 됐는데 이제 require(cond, MyError())도 된다.

Solidity 0.9가 언제 나올지는 2026년 5월 기준 아직 확정 안 됐다. 0.8.x가 5년째 호환성을 유지하며 점진적으로 성장 중.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract Vault {
    error InsufficientBalance(uint256 requested, uint256 available);

    mapping(address => uint256) public balances;

    function withdraw(uint256 amount) external {
        uint256 bal = balances[msg.sender];
        if (amount > bal) revert InsufficientBalance(amount, bal);
        unchecked { balances[msg.sender] = bal - amount; }
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "send failed");
    }
}

Vyper는 Python 문법을 빌린 EVM 언어. Vitalik이 초기에 미는 분위기를 주기도 했다. 2026년에는 Vyper 0.4.x가 안정 라인.

Vyper의 철학은 "단순하고, 명시적이고, 감사 가능". Solidity가 가진 function modifier, inheritance, inline assembly 같은 "강력하지만 복잡한" 기능을 의도적으로 제거했다. Curve Finance 같은 큰 DeFi 프로토콜이 Vyper로 쓰여 있다.

# Vyper 0.4 예
@external
@payable
def deposit():
    self.balances[msg.sender] += msg.value

@external
def withdraw(amount: uint256):
    assert self.balances[msg.sender] >= amount
    self.balances[msg.sender] -= amount
    send(msg.sender, amount)

언제 Vyper? 정직하게는 거의 안 쓴다. 1차 선택지로 Solidity가 압도적이고, Vyper는 (a) Curve 같은 특정 프로토콜과의 호환성, (b) 가능한 한 단순한 컨트랙트로 감사 표면을 좁히고 싶을 때 정도. 신규 프로젝트에서 Vyper로 시작하는 케이스는 드물다.

5장 · Cairo (StarkNet) — ZK-friendly 언어

Cairo는 StarkWare가 만든 ZK-friendly 언어. EVM 위에 ZK 증명을 얹는 게 아니라, 처음부터 ZK 증명 생성에 최적화된 가상머신(Cairo VM)을 만들고 그 위의 언어로 설계됐다. StarkNet은 Cairo VM 위에 도는 L2.

2026년의 Cairo는 Cairo 2.x가 표준. Cairo 1과 비교해 Rust-스러운 문법으로 바뀌었다(fn, let, traits, enums). 학습 곡선이 처음엔 가파르지만, Rust를 알면 비교적 익숙하다.

// 간단한 ERC20-라이크 컨트랙트
#[starknet::contract]
mod SimpleToken {
    use starknet::ContractAddress;
    use starknet::get_caller_address;

    #[storage]
    struct Storage {
        balances: LegacyMap<ContractAddress, u256>,
        total_supply: u256,
    }

    #[constructor]
    fn constructor(ref self: ContractState, initial_supply: u256) {
        let caller = get_caller_address();
        self.balances.write(caller, initial_supply);
        self.total_supply.write(initial_supply);
    }

    #[external(v0)]
    fn transfer(ref self: ContractState, to: ContractAddress, amount: u256) {
        let caller = get_caller_address();
        let sender_balance = self.balances.read(caller);
        assert(sender_balance >= amount, 'insufficient');
        self.balances.write(caller, sender_balance - amount);
        let recipient_balance = self.balances.read(to);
        self.balances.write(to, recipient_balance + amount);
    }
}

도구는 두 가지가 핵심.

Scarb — Cairo의 Cargo. 패키지 관리, 빌드. scarb build, scarb test. Rust 개발자에게 매우 친숙.

Starknet Foundry (snforge) — Foundry의 Cairo 버전. Solidity의 Foundry가 줬던 DX를 StarkNet에 가져왔다. snforge test가 빠르고 cheatcode도 제공한다.

scarb new my_starknet_project
cd my_starknet_project
scarb build
snforge test

StarkNet은 2026년 시점에서 다른 L2에 비해 TVL이 작지만, ZK 증명을 일급 시민으로 다루는 거의 유일한 메인스트림 옵션이라는 점에서 특정 사용 사례(프라이버시 어플, 게임 내 검증 가능 무작위, 오프체인 계산을 온체인 증명으로 가져오기)에서 강하다.

Cairo의 단점. (1) 생태계가 EVM보다 훨씬 작다 — OpenZeppelin Cairo도 존재하지만 라이브러리 깊이가 다르다. (2) 학습 곡선 가파르다 — felt252(field element)라는 특이한 기본 타입, low-level cairo와 Cairo 2.x 사이의 변천사가 있다. (3) 채용 시장이 좁다 — Cairo 잘 쓰는 사람은 손에 꼽힌다.

언제 Cairo? "ZK 증명을 통한 검증 가능 계산"이 핵심 요구사항일 때, 또는 StarkNet 생태계에 특화된 프로토콜(예: dYdX v4 이전, AVNU, JediSwap)을 빌드할 때.

6장 · Anchor (Solana) — Rust 프레임워크

Solana는 Rust로 컨트랙트(Solana에서는 "프로그램"이라 부른다)를 쓴다. 그런데 raw Rust로 직접 SBF(Solana BPF) 프로그램을 쓰면 보일러플레이트가 어마어마하다 — 계정 직렬화·역직렬화, 권한 체크, instruction 디스패치를 다 손으로.

Anchor가 이 문제를 푼다. EVM에서 Hardhat·Truffle이 한 일과 거의 같다 — 매크로로 보일러플레이트를 숨기고, IDL(Interface Definition Language)로 클라이언트 코드를 자동 생성한다.

use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod my_counter {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.count += 1;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}

#[account]
pub struct Counter {
    pub count: u64,
}

EVM에서 넘어온 사람에게 Solana의 핵심 모델 차이는 두 가지. (1) 계정 모델 — Solana는 모든 데이터가 계정(account)에 산다. 컨트랙트도 계정, 사용자도 계정, 토큰 잔액도 계정. 호출할 때 어떤 계정을 건드릴지 명시해야 한다. (2) stateless 프로그램 — 컨트랙트 코드와 데이터가 분리돼 있다. 한 프로그램이 여러 계정의 데이터를 다룬다.

Anchor 워크플로.

# 새 프로젝트
anchor init my-project
cd my-project

# 빌드 (Rust → SBF)
anchor build

# 로컬 테스트 (solana-test-validator를 띄움)
anchor test

# Devnet 배포
anchor deploy --provider.cluster devnet

테스트는 TypeScript로 쓴다(Mocha 베이스). Anchor가 IDL을 만들어주고, IDL을 읽어 TypeScript 타입과 클라이언트가 자동 생성된다.

import * as anchor from '@coral-xyz/anchor'
import { Program } from '@coral-xyz/anchor'
import { MyCounter } from '../target/types/my_counter'

describe('my-counter', () => {
  const provider = anchor.AnchorProvider.env()
  anchor.setProvider(provider)
  const program = anchor.workspace.MyCounter as Program<MyCounter>

  it('Increments', async () => {
    const counter = anchor.web3.Keypair.generate()
    await program.methods.initialize().accounts({ counter: counter.publicKey, user: provider.wallet.publicKey, systemProgram: anchor.web3.SystemProgram.programId }).signers([counter]).rpc()
    await program.methods.increment().accounts({ counter: counter.publicKey }).rpc()
    const account = await program.account.counter.fetch(counter.publicKey)
    console.log('count:', account.count.toString())
  })
})

Anchor의 단점. (1) 매크로가 많아 컴파일 에러 메시지가 모호하다. (2) Anchor 버전과 Solana CLI 버전의 호환성 매트릭스가 까다롭다 — 0.31, 0.30, 0.29의 차이를 알아둬야 한다. (3) IDL이 모든 동적 패턴을 표현하지 못한다.

그래도 2026년 Solana에서 진지하게 개발한다면 Anchor가 기본이다. raw Solana program을 쓰는 건 매우 특수한 경우(예: 극한의 가스 최적화).

7장 · ethers.js v6 vs viem — 클라이언트 라이브러리

스마트 컨트랙트는 체인에 배포되지만, 그것을 호출하는 코드(프론트엔드, 백엔드, 봇)는 JavaScript/TypeScript로 짠다. 그 가교가 클라이언트 라이브러리.

EVM 진영에서 2026년 시점의 두 강자.

ethers.js v6 — 클래식. 2017년부터 있었고, web3.js와의 대전에서 살아남아 사실상 표준이 됐다. v6는 v5의 큰 리팩토링판으로 2023년 출시. ES modules, ESM 친화, BigInt 네이티브 지원. 단점은 TypeScript 타입이 미묘하게 약하고, 트리쉐이킹이 어렵고, 번들 크기가 크다.

import { ethers } from 'ethers'

const provider = new ethers.JsonRpcProvider('https://eth-mainnet.alchemyapi.io/v2/KEY')
const signer = new ethers.Wallet(privateKey, provider)
const contract = new ethers.Contract(address, abi, signer)

const tx = await contract.transfer(to, ethers.parseEther('1.0'))
const receipt = await tx.wait()
console.log('Block:', receipt.blockNumber)

viem — wagmi 만든 팀(wevm)이 ethers.js를 뜯어고치고 싶다는 이유로 2022년 시작. 2026년 시점에서 2.x가 안정 라인. TypeScript-first(ABI 타입 자동 추론), 트리쉐이커블, 번들 크기 작고 빠름, RPC 호출 표준화. ethers의 모든 페인 포인트를 의식적으로 푼다.

import { createPublicClient, http, parseEther } from 'viem'
import { mainnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const client = createPublicClient({ chain: mainnet, transport: http('https://eth-mainnet.alchemyapi.io/v2/KEY') })
const account = privateKeyToAccount('0x...')

// ABI 추론으로 transfer의 인자·반환 타입이 자동
const hash = await client.writeContract({
  account,
  address: '0xA0b8...',
  abi: tokenAbi,
  functionName: 'transfer',
  args: ['0x123...', parseEther('1.0')],
})
const receipt = await client.waitForTransactionReceipt({ hash })

viem의 핵심 차이.

  • abitype — ABI를 TypeScript 타입으로 자동 추론. functionName: 'transfer'만 적어도 args: [Address, bigint]로 좁혀진다. 잘못된 인자를 컴파일 타임에 잡는다.
  • 트리쉐이킹 — parseEther만 import하면 그것만 들어간다. 번들이 작다(Lighthouse 점수에 직결).
  • 함수 단위 API — ethers는 클래스 기반, viem은 함수 기반. 코드 분할이 자연스럽다.
  • Action API — client.readContract, client.writeContract, client.simulateContract가 일관된 인터페이스.

2026년 시점에서 새 프로젝트는 viem이 기본이다. ethers는 기존 코드베이스가 많거나 v5에서 v6로 이미 마이그레이션한 팀이 유지 보수 모드로 남긴다.

web3.js는 2024년에 ConsenSys가 sunset(공식 단종)을 선언했다. 2026년에는 web3.js 4.x가 마지막이고, viem/ethers로 가라는 게 커뮤니티의 합의다.

8장 · wagmi v2 + ConnectKit / RainbowKit / Web3Modal(Reown)

위 클라이언트는 "JS에서 체인 부르기" 레벨인데, React/Next.js 앱을 만든다면 그 위에 한 층이 더 필요하다. 지갑 연결 UI, 계정 상태 관리, 캐싱, useEffect 추상화.

wagmi v2가 그 자리. wevm 팀(viem과 같은 팀)이 만든 React 훅 라이브러리. 2.x부터 viem 위에 빌드되고, 1.x의 ethers 의존을 끊었다.

import { createConfig, http, WagmiProvider } from 'wagmi'
import { mainnet, base } from 'wagmi/chains'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

const config = createConfig({
  chains: [mainnet, base],
  transports: { [mainnet.id]: http(), [base.id]: http() },
})
const queryClient = new QueryClient()

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <YourApp />
      </QueryClientProvider>
    </WagmiProvider>
  )
}

useAccount, useBalance, useReadContract, useWriteContract, useWaitForTransactionReceipt — 모든 게 React Query 위에서 캐싱·재시도·자동 무효화.

function Balance() {
  const { address } = useAccount()
  const { data: balance } = useBalance({ address })
  return <div>Balance: {balance?.formatted} {balance?.symbol}</div>
}

지갑 연결 UI는 wagmi 자체엔 없고, 세 가지 라이브러리 중 골라 깐다.

ConnectKit — Family.co(이전 ZORA의 일부)가 만든 깔끔한 UI. wagmi와 가장 깊게 통합. 미니멀한 디자인, 다크/라이트, 커스터마이즈 가능. 2026년 시점에서 ConnectKit 1.x.

RainbowKit — Rainbow Wallet 팀이 만든, 가장 화려한 UI. 트렌디한 NFT/DeFi 앱의 표준 룩 앤 필. 무지개 그라데이션 기본 테마가 특징. wagmi v2 호환은 RainbowKit 2.x.

Web3Modal → Reown — 이전 WalletConnect 회사가 만들었고, 2024년에 회사명을 Reown으로 바꾸며 Web3Modal도 AppKit으로 리네임. 멀티체인(EVM + Solana + Bitcoin) 지원이 가장 넓다. 가장 "백엔드"적 — 600+ 지갑 지원, 강력한 분석.

// ConnectKit 예
import { ConnectKitProvider, ConnectKitButton } from 'connectkit'

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <ConnectKitProvider>
          <ConnectKitButton />
          <YourApp />
        </ConnectKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  )
}

선택 기준.

  • ConnectKit — 미니멀 디자인, 다크모드 잘 됨, 빠른 로딩.
  • RainbowKit — NFT/DeFi 앱처럼 보이고 싶을 때. 무지개 톤.
  • Reown AppKit — Solana도 같이, 600+ 지갑이 필요할 때.

세 개 다 wagmi 위에서 돌기 때문에 underlying 로직은 같다 — 차이는 UI/UX와 멀티체인 지원 폭이다.

9장 · OpenZeppelin Contracts 5.x — 안전한 표준 구현

스마트 컨트랙트는 한 번 배포하면 수정이 어렵다(upgrade 패턴이 있지만 복잡함). 그래서 ERC20, ERC721, AccessControl, Pausable 같은 표준은 검증된 구현을 가져다 쓰는 게 거의 의무다.

OpenZeppelin Contracts가 그 자리. ConsenSys/OpenZeppelin Security가 메인테이너. 2024년에 5.x가 나왔다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyToken is ERC20, Ownable {
    constructor(address initialOwner) ERC20("MyToken", "MTK") Ownable(initialOwner) {
        _mint(initialOwner, 1000000 * 10 ** decimals());
    }
}

5.x의 주요 변경.

  • Custom errors 전면 도입 — revert "string" 대신 error Unauthorized();. 가스 효율 + 디코드 가능성.
  • AccessControl 강화 — 권한 모델을 모듈화. DEFAULT_ADMIN_ROLE, MINTER_ROLE 같은 흔한 패턴.
  • Ownable(initialOwner) — 생성자에서 owner를 명시. 이전엔 msg.sender로 자동.
  • SafeERC20 — 호환성 안 좋은 토큰(USDT 같은 non-standard return)을 안전하게 다루는 wrapper.
  • UUPSUpgradeable, TransparentUpgradeableProxy — 업그레이드 패턴.
  • ERC2771Context — meta-transaction (gasless) 지원.

설치는 npm/Hardhat/Foundry 어디서나 한 줄.

# Hardhat / npm
npm install @openzeppelin/contracts

# Foundry
forge install OpenZeppelin/openzeppelin-contracts

OpenZeppelin이 제공하지 않는 것도 짚자. (1) 비즈니스 로직 — DeFi의 lending, AMM, derivative는 직접 짜야 한다. (2) 가스 최솟값 추구 — OpenZeppelin은 안전성 우선, 가스는 차선. Solady(Vectorized) 같은 가스 최적화 라이브러리가 별도 존재.

Solana 진영에서는 anchor-spl(Solana Program Library의 Anchor 래퍼)이 비슷한 역할 — SPL Token, Associated Token Account 같은 표준 구현을 제공.

10장 · 보안 — Slither / Mythril / Echidna / Halmos symbolic

스마트 컨트랙트는 한 번의 버그가 수억 달러 손실을 부른다. 2016년 The DAO부터 2022년 Ronin, 2023년 Multichain까지 — 모든 큰 해킹은 더 나은 정적 분석으로 잡힐 수 있었던 것들이다. 2026년의 보안 툴체인은 네 가지.

Slither (Trail of Bits). 가장 유명한 정적 분석기. Python으로 짜여있고, Solidity AST를 분석해 알려진 취약점 패턴을 잡는다. Reentrancy, integer overflow, uninitialized storage, dangerous low-level call, naming convention 등 80+ 디텍터.

pip install slither-analyzer
slither contracts/

CI에 넣기 매우 쉽다. PR마다 자동으로 돌리는 게 표준.

Mythril (ConsenSys Diligence). 심볼릭 실행 기반. EVM 바이트코드를 심볼릭하게 실행해 "어떤 입력이 들어가면 이 assertion이 깨지는지" 자동으로 찾는다. Slither보다 느리지만 더 깊이 본다.

pip install mythril
myth analyze contracts/MyContract.sol

Echidna (Trail of Bits). 프로퍼티 기반 퍼즈 테스트. "이 invariant는 절대 깨지면 안 된다"고 선언하면 Echidna가 수천 번 무작위 입력을 시도해 깨는 입력을 찾는다.

// echidna 예
contract VaultTest is Vault {
    function echidna_balance_never_negative() public view returns (bool) {
        return balances[msg.sender] >= 0;  // 항상 참이어야 함
    }
}

echidna contracts/VaultTest.sol --contract VaultTest

Halmos (a16z crypto). 비교적 최신(2023~)인 심볼릭 실행 도구. Foundry 테스트 위에 바로 도는 게 핵심 차이 — forge test 대신 halmos를 부르면 같은 테스트 코드를 심볼릭하게 실행한다.

pip install halmos
halmos --contract VaultTest

Foundry forge fuzz. Foundry 내장 퍼저. testFuzz_* 함수는 자동으로 256번(기본) 무작위 입력으로 실행. 가장 가벼운 첫 방어선.

function testFuzz_TransferDoesNotLoseValue(uint256 amount) public {
    vm.assume(amount > 0 && amount <= token.balanceOf(alice));
    uint256 before = token.balanceOf(alice) + token.balanceOf(bob);
    vm.prank(alice);
    token.transfer(bob, amount);
    uint256 after = token.balanceOf(alice) + token.balanceOf(bob);
    assertEq(before, after);
}

Slang (Nomic Foundation). 2024년 Nomic이 발표한 Solidity 컴파일러 프론트엔드(Rust). 목표는 "Slither를 대체하는 차세대 분석 인프라". 2026년 시점에는 아직 베타지만, 향후 Hardhat 3와 깊이 통합될 예정.

실전 워크플로 추천.

  1. 모든 PR마다 Slither + Foundry forge fuzz.
  2. 메이저 릴리스마다 Echidna + Mythril.
  3. invariant가 중요한 컨트랙트 Halmos로 심볼릭 검증.
  4. mainnet 배포 전 외부 감사(Trail of Bits, OpenZeppelin Security, ConsenSys Diligence, Code4rena 같은 컨테스트).

자동 도구는 "감사를 대체"하지 않는다. "감사 들어가기 전 표면을 줄인다". 진지한 프로젝트는 둘 다 한다.

11장 · Tenderly — 모니터링 + 시뮬레이션 + 디버깅

배포된 컨트랙트를 운영하는 데는 별도 도구가 필요하다. Etherscan은 보기엔 좋은데, 트랜잭션이 왜 실패했는지 디버깅하기는 부족하다.

Tenderly가 이 자리에 산다. 2018년부터 EVM 트랜잭션 디버거로 시작해 이제는 종합 플랫폼.

핵심 기능들.

  • Transaction debugger — revert된 트랜잭션을 라인 단위로 추적. 어느 require가 실패했는지, 어떤 변수 값이었는지 다 보여준다.
  • Simulator — "이 트랜잭션을 보내면 무슨 일이 일어날까"를 mainnet fork 위에서 미리 실행. 가스 추정, 상태 변화, 이벤트.
  • Alerts — 컨트랙트 이벤트, 상태 변화, 에러를 Slack/이메일/웹훅으로 알림.
  • Web3 Actions — 트리거 기반 서버리스 함수. 특정 이벤트가 나면 자동으로 코드 실행.
  • War Rooms — 인시던트 발생 시 팀이 실시간으로 트랜잭션을 같이 디버깅.

API로도 부른다.

import { TenderlyConfiguration, Tenderly } from '@tenderly/sdk'

const tenderly = new Tenderly({ accountName: 'me', projectName: 'myproject', accessKey: process.env.TENDERLY_KEY })

const simulation = await tenderly.simulator.simulateTransaction({
  transaction: { from: '0xA...', to: '0xB...', input: '0xa9059cbb...', value: '0', gas: 100000, gasPrice: '0' },
  blockNumber: 'latest',
})
console.log(simulation)

dApp 프론트엔드에서 "트랜잭션 보내기 전에 미리 시뮬레이션" 패턴이 매우 흔하다. 사용자가 가스비 내고 실패하는 거 막는다.

대안. Phalcon (BlockSec) — 디버깅/모니터링 비슷한 영역. OpenZeppelin Defender — 좀 더 운영·자동화 쪽. Forta — 온체인 위협 디텍션.

Tenderly가 2026년 시점에서 종합 패키지로 가장 강하다. 가격은 무료 티어가 넉넉해서 사이드 프로젝트는 무료로 충분, 프로덕션은 월 50~500달러 범위.

12장 · Alchemy / Infura / QuickNode / Helius — RPC 제공자

스마트 컨트랙트와 대화하려면 누군가가 노드를 돌려줘야 한다. 자체 노드를 돌리는 건 비싸고 번거롭다 — Ethereum mainnet 노드 하나 동기화에 디스크 2TB·시간 며칠. 그래서 RPC 제공자 시장이 크다.

Alchemy. 미국 SF 본사. 2026년 시점에서 시장 점유율 1위에 가깝다. EVM 전부(Ethereum, Polygon, Arbitrum, Optimism, Base, zkSync, Polygon zkEVM, Starknet, Linea, Scroll) + Solana. Notify(이벤트 webhook), NFT API, Enhanced API(데이터 인덱싱). 무료 티어 월 300M compute unit.

Infura. ConsenSys 소유. 가장 오래된 RPC 제공자 중 하나. MetaMask가 기본으로 Infura를 부른다 — 그래서 거기 의존성이 사실상 표준. EVM 전부 + IPFS 게이트웨이. 무료 티어 일 100k 요청. 한 번 다운된 적 있어("Infura가 다운되면 web3가 다운된다"는 비판) 멀티 RPC 패턴이 권장된다.

QuickNode. 마이애미 본사. 30+ 체인 지원, EVM 외에도 Solana, Cosmos, Polkadot. Marketplace에 다양한 add-on. 가격은 사용량 기반.

Helius. Solana 전용 RPC. Solana는 트랜잭션 처리가 EVM과 매우 달라서(parallel execution, lamports, slot 등) Solana 특화 제공자가 의미가 있다. Helius가 Solana RPC 점유율에서 가장 크다. Webhook, DAS(Digital Asset Standard) API, enhanced parsing.

Public RPC. 무료 공개 RPC도 있다 — eth.llamarpc.com, cloudflare-eth.com, rpc.ankr.com/eth. 사이드 프로젝트에 충분하지만, 프로덕션에서는 SLA 없고 rate limit이 빡빡해 권장 X.

선택 가이드.

  • EVM 위주 + 풀 스택 Alchemy.
  • MetaMask 호환·간단함 Infura.
  • 여러 체인 동시에 QuickNode.
  • Solana 진지하게 Helius.
  • 사이드 프로젝트 무료 티어 어떤 거든.

멀티 RPC 패턴 — 프로덕션에서는 항상 두 개 이상 제공자를 두고 fallback. viem의 fallback transport, ethers의 FallbackProvider.

import { createPublicClient, http, fallback } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: fallback([http('https://eth-mainnet.g.alchemy.com/v2/KEY1'), http('https://mainnet.infura.io/v3/KEY2')]),
})

한 제공자가 다운돼도 자동으로 다음으로 넘어간다.

13장 · L2 — Arbitrum / Optimism / Base / zkSync / Polygon zkEVM / StarkNet

Ethereum mainnet은 비싸고 느리다. 그래서 L2가 존재한다. 2026년 시점에서 메인스트림 L2 여섯 개를 정리.

Arbitrum. Offchain Labs가 운영. Optimistic Rollup. L2 중 TVL 1위 — 2026년 기준 약 300~500억 달러 범위. EVM-equivalent(메인넷 Solidity 코드가 거의 그대로 돈다). Stylus가 옆에 붙어 Rust 컨트랙트도 가능.

Optimism. OP Labs가 운영. Optimistic Rollup. 2위. Superchain 비전 — OP Stack을 기반으로 한 네트워크의 연합. Base, Worldchain, Mode 등이 OP Stack 위에 돈다.

Base. Coinbase가 운영. OP Stack 위에 빌드. 2023년 런칭, 2026년에는 사용자 수에서 가장 큰 L2 중 하나. Coinbase 사용자 80M명에 직접 노출되는 게 강점. Onchain Summer 같은 마케팅으로 dApp 모객 적극.

zkSync Era. Matter Labs가 운영. ZK-Rollup. EVM-compatible(완전 equivalent는 아니지만 거의). 자체 컴파일러(zksolc). 가스가 싸고 확정성(finality)이 더 빠르다.

Polygon zkEVM. Polygon이 운영. ZK-Rollup이고 EVM-equivalent 정도 매우 높음. Polygon 생태계(Polygon PoS, CDK, Miden)의 일부.

StarkNet. StarkWare가 운영. Validity Rollup. Cairo 언어 사용. EVM과 호환되지 않음 — 별도 생태계.

선택 가이드.

  • TVL·생태계 깊이 Arbitrum.
  • OP Stack·Superchain Optimism / Base / OP Stack 파생 체인.
  • Coinbase 사용자 노출 Base.
  • EVM-compatible ZK zkSync Era / Polygon zkEVM.
  • ZK 일급 지원 StarkNet.

가스비는 모두 mainnet 대비 10~100배 싸다. 가스 vs 확정성 vs 생태계의 trade-off가 선택 기준.

Linea(ConsenSys), Scroll(자체), Mantle(BitDAO), Mode(OP Stack), Blast(yield-native) 같은 더 작은 L2들도 있다 — 각자의 특화 영역이 있고, "어디에 배포할 것인가"는 사용자가 어디 있는가에 달렸다.

14장 · Arbitrum Stylus — Rust 스마트 컨트랙트 (EVM과 같은 체인에서)

Stylus가 2025년 mainnet에 올라온 게 2026년 시점에서 본격 채택기에 들어간 가장 큰 변화 중 하나.

핵심 아이디어. EVM과 같은 Arbitrum 체인에서 WASM 기반 컨트랙트도 돈다. 즉 Rust로 짠 컨트랙트가 Solidity 컨트랙트와 한 체인 위에서 같이 살고, 서로 호출 가능하다.

// Stylus 컨트랙트 예
extern crate alloc;
use stylus_sdk::{prelude::*, alloy_primitives::U256};

#[storage]
#[entrypoint]
pub struct Counter {
    count: StorageU256,
}

#[public]
impl Counter {
    pub fn count(&self) -> U256 {
        self.count.get()
    }

    pub fn increment(&mut self) {
        let v = self.count.get();
        self.count.set(v + U256::from(1));
    }
}

배포 워크플로.

cargo install --force cargo-stylus
cargo stylus new my_counter
cd my_counter
cargo stylus check
cargo stylus deploy --private-key $PK --endpoint $RPC

장점.

  • 가스 효율 — WASM이 EVM보다 훨씬 효율적이라, 수학 계산 무거운 컨트랙트는 10~100배 가스 절약.
  • Rust 생태계 — 기존 Rust 크레이트(BLS, ZK 라이브러리, 큰 정수 라이브러리)를 가져다 쓸 수 있다.
  • C/C++도 — 이론적으로 WASM으로 컴파일되면 다 된다.

단점.

  • Solidity 생태계와 단절 — OpenZeppelin Contracts 같은 게 Stylus용으로 다시 짜여야 한다.
  • 감사 풀 — Solidity 감사는 익숙하지만 Stylus 감사는 새로운 영역.
  • Arbitrum에만 — 다른 L2로 옮기기 어렵다.

언제 Stylus? "수학 무거운 컨트랙트(ZK verifier, on-chain ML inference, 대규모 수치 계산)"에서. 일반 DeFi/NFT는 Solidity가 여전히 표준.

15장 · Metaplex — Solana NFT 표준

Solana NFT는 OpenSea가 한때 잠깐 발을 들였다가 빠졌지만, Magic Eden을 중심으로 자체 시장이 살아있다. 표준은 Metaplex가 정한다.

Metaplex Foundation은 Solana 위 NFT/토큰 표준을 만드는 비영리. 주요 표준 두 가지.

Token Metadata Program. Solana의 SPL Token 위에 메타데이터(이름, 심볼, URI, royalty)를 얹는 표준 프로그램. NFT는 본질적으로 supply=1인 SPL Token + Token Metadata.

Token Extensions (Token-2022). SPL Token의 다음 버전. transfer hook, confidential transfer, interest-bearing 등 확장 기능. NFT에서도 활용.

도구는 두 단계.

Sugar CLI — 캔디 머신(Candy Machine, Metaplex의 NFT 민팅 인프라)을 CLI로 다룬다. 컬렉션 업로드, 화이트리스트, 가격 설정.

sugar create-config
sugar upload
sugar deploy
sugar mint

Umi (Universal Metaplex Interface). JavaScript/TypeScript에서 Metaplex 프로그램들을 부르는 SDK. wagmi와 비슷한 위치.

import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'
import { createV1, mintV1, TokenStandard } from '@metaplex-foundation/mpl-token-metadata'

const umi = createUmi('https://api.devnet.solana.com')
const mint = generateSigner(umi)

await createV1(umi, {
  mint,
  authority: umi.identity,
  name: 'My NFT',
  uri: 'https://arweave.net/...',
  sellerFeeBasisPoints: percentAmount(5.5),
  tokenStandard: TokenStandard.NonFungible,
}).sendAndConfirm(umi)

NFT 시장이 2026년에 작아진 건 사실이지만, "온체인 자산을 표현하는 표준"으로서의 가치는 살아있다. Solana 게임, 멤버십, RWA(Real World Assets)에서 Metaplex 표준이 계속 쓰인다.

16장 · 한국 — 카카오 클레이튼 → PIO Network 통합, 람다256

한국 Web3는 20182021년 ICO·NFT 호황 때 큰 모멘텀이 있었고, 그 후 KYC 강화·트래블룰·LUNA 사태로 식었다가 20242026년 ETF 시대에 다시 정비되는 흐름.

클레이튼 → PIO Network. 카카오가 만든 EVM L1 클레이튼은 2024년에 Finschia(LINE의 체인)와 합병해 PIO Network(또는 Kaia)로 통합됐다. 카카오 + LINE의 합산 사용자가 일본·동남아·한국에 큰 잠재력. 2026년 시점에서 PIO/Kaia 위의 dApp 생태계가 다시 형성 중. KaiaScan(Etherscan 호환), Klaytn SDK가 Kaia SDK로.

// Kaia 호출 (viem 호환)
import { createPublicClient, http } from 'viem'
import { kaia } from 'viem/chains'

const client = createPublicClient({
  chain: kaia,
  transport: http('https://public-en.node.kaia.io'),
})

두나무 + 람다256. 두나무(업비트 운영사)의 블록체인 자회사가 람다256. Luniverse라는 BaaS 플랫폼을 운영했고, 2026년 시점에서는 기업용 토큰 발행·NFT·STO(Security Token Offering) 인프라를 제공한다.

한국 STO. 2026년 시점에서 토큰증권(Security Token) 제도가 점진적으로 도입되며, 기관 발행 시장이 형성 중. 두나무·핀고·신한·NH 등이 STO 인프라를 준비 중.

한국 dApp. OpenSea 한국, 클립(카카오), 메타마스크 + Kaiakas, 업비트 NFT(현재는 정리됨), 한국 게임사(위메이드의 위믹스, 컴투스의 XPLA, 넷마블의 MBX) — 게임 체인이 한국 Web3의 큰 축. P2E 규제 때문에 글로벌 시장 위주.

람다256·Klip·Kaia Wallet의 KYC·트래블룰 시스템이 2024년부터 매우 강화돼, 한국 사용자가 dApp을 쓰는 데 마찰이 있다. 글로벌 dApp을 만들 때는 한국 사용자 전용 가이드/대안 흐름을 두는 게 일반적.

17장 · 일본 — Astar Network (Sota Watanabe), Oasys

일본은 한국과 비슷하게 2018~2021년 큰 호황 후 정비기를 거쳤지만, 정부의 Web3 정책이 한국보다 친화적이라는 차이가 있다. 키시다 정부의 "Web3 White Paper", 자민당 Web3 PT(프로젝트팀), 디지털청의 NFT 가이드라인.

Astar Network. Sota Watanabe가 만든 Polkadot 파라체인. 2026년 시점에서 일본에서 가장 큰 Web3 프로젝트. ASTR 토큰. EVM과 Wasm을 둘 다 지원. Soneium(Sony Block Solutions Labs + Astar)이라는 L2도 2024년에 시작.

// Astar/Soneium (EVM)
import { createPublicClient, http } from 'viem'
import { astar, soneium } from 'viem/chains'

const client = createPublicClient({ chain: astar, transport: http() })

Oasys. 게이밍 특화 체인. 2022년 런칭. 검증자가 일본 게임사들(반다이남코, 스퀘어에닉스, 세가, 코나미, 그리, 더블점프토쿄 등)로 구성된 게 특이점. 게임 dApp의 가스를 0으로(verse-layer 구조).

JPYC. 일본 엔화 스테이블코인. 2021년부터 발행. 2026년 시점에서 일본 내 결제·송금에 일부 쓰임.

한국과의 차이. 일본은 (1) 정부가 Web3를 산업으로 키우려는 의지가 강함, (2) 라인·소니·반다이 같은 대기업이 직접 참여, (3) 세금 제도가 점진적으로 합리화됨(이전엔 미실현 익에도 세금 매기는 악조건이 있었으나 개선). 그래서 일본 빌더에게는 PIO Network보다 Astar/Soneium/Oasys가 더 큰 선택지.

18장 · 누가 무엇을 골라야 하나 — DeFi / NFT / L2 / ZK 결정 트리

마지막으로, 짧게 정직한 결정 트리.

Q1. 어느 체인에 배포할 것인가?

  • Ethereum mainnet 또는 EVM L2(Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll) → EVM/Solidity → 2장으로.
  • Solana → Anchor/Rust → 6장으로.
  • StarkNet → Cairo → 5장으로.
  • Arbitrum + 수학 무거운 컨트랙트 → Stylus/Rust → 14장으로.

Q2. EVM에서 Hardhat? Foundry?

  • 새 프로젝트 → Foundry. 빠르고, Solidity로 테스트.
  • 기존 프로젝트 또는 큰 모노레포(프론트·백·컨트랙트) → Hardhat (3). TS 생태계와 매끄럽다.
  • 둘 다 깔고 같이 쓰는 팀도 많다. Forge로 테스트하고 Hardhat Ignition으로 배포.

Q3. JS 클라이언트 ethers? viem?

  • 새 프로젝트 → viem. TypeScript-first, 작고 빠르다.
  • 기존 코드 ethers v6 → 유지. 마이그레이션 비용 굳이 안 들여도 된다.
  • web3.js는 새로 쓰지 마라. 단종됐다.

Q4. wagmi와 무슨 UI?

  • 미니멀하고 빠르게 → ConnectKit.
  • 디자인 화려하게 → RainbowKit.
  • Solana + EVM 같이, 600+ 지갑 → Reown AppKit.

Q5. 보안 도구는 어디까지?

  • 사이드 프로젝트 → Slither + Foundry forge fuzz.
  • 진지한 프로토콜 → 위 + Echidna + Mythril + Halmos.
  • mainnet 큰 자금 → 위 + 외부 감사 1~2회 + Code4rena 같은 컨테스트.

Q6. RPC는 어디서?

  • EVM → Alchemy 또는 Infura. 멀티 RPC fallback 필수.
  • Solana → Helius.

Q7. NFT를 한다면?

  • EVM → OpenZeppelin ERC721/ERC1155 + Magic Eden/OpenSea.
  • Solana → Metaplex + Magic Eden.
  • "NFT 시장이 죽었다는 말은 맞지만, NFT 표준은 여전히 쓰인다" — 멤버십, RWA, 게임에서 살아 있다.

Q8. 한국·일본 시장 타깃?

  • 한국 → 글로벌 EVM/L2 위에서 빌드하고 한국 사용자 가이드 별도. PIO Network는 카카오 사용자 노출이 필요할 때.
  • 일본 → Astar/Soneium/Oasys가 일본 시장에 더 가까움. 정부 친화적.

19장 · 참고 / References (Web3는 변동성이 크다)

주의 — Web3 프로젝트는 빠르게 피벗하거나 종료할 수 있다. 아래 링크는 2026년 5월 기준이며, 일부 프로젝트(특히 작은 L2나 SDK)는 이름이 바뀌거나 사라질 수 있다. 1차 출처를 항상 확인하라.

EVM 개발 도구

Solana / StarkNet / Stylus

클라이언트 / 프론트엔드

라이브러리·표준

보안 도구

모니터링·RPC

L2

한국·일본

같이 읽기

스마트 컨트랙트는 한 줄의 코드가 수억 달러를 움직인다. 도구가 그 자리에 어울리는지가 곧 안전이다. Hardhat 또는 Foundry, Solidity 또는 Cairo 또는 Rust, viem 또는 ethers, 어떤 RPC, 어떤 L2 — 이 결정들이 모여 한 프로토콜의 운명을 만든다. 2026년의 인프라는 어느 때보다 좋다. 그 도구들을 정직하게 알고 고르자.

Discuss on Twitter • View on GitHub