블록체인 큰 그림 잡기: 코인·토큰·노드·RPC·DApp·EVM을 “실무 관점”으로 분리해서 이해하기

블록체인 글을 시리즈로 올리다 보면 이상하게 같은 질문을 반복해서 받습니다.

• “코인/토큰은 알겠는데, 막상 설명하려면 말이 꼬여요.”
• “노드랑 RPC는 뭐가 다른 거예요? 그냥 서버 아닌가요?”
• “DApp이면 서버 없어야 하는 거 아닌가요?”

이 글은 단어 정의를 길게 늘어놓는 대신, 실무에서 실제로 헷갈려서 사고가 나는 지점을 기준으로 개념을 “부품”처럼 분리해서 정리합니다.
여기서 큰 그림이 잡히면 이후에 어떤 주제를 파도(지갑, 배포, 합의, EVM, Solidity…) 훨씬 덜 헤매게 됩니다.

---

이 글에서 잡을 ‘한 장짜리 지도’

블록체인 시스템은 크게 아래 6개 부품으로 나눌 수 있습니다.

1. 자산(코인/토큰): 무엇을 거래/소유하는가
2. 장부(상태): 누가, 어떤 상태를 “정답”으로 보관하는가
3. 규칙(프로토콜 + 스마트 컨트랙트): 어떤 입력이 유효한가
4. 실행 환경(EVM 등): 규칙을 어떤 런타임이 실행하는가
5. 접근 방식(RPC): 앱이 장부/규칙에 어떻게 요청하는가
6. 앱(DApp): 사용자 경험(UI/서명/인덱싱)을 어떻게 묶는가

---

1) 코인 vs 토큰 — “상장 여부” 말고, 기술적 위치로 구분하기

코인(Coin)

• 자기 블록체인 네트워크의 기본 단위
• 보통 수수료(가스/채굴·검증 보상) 와 직접 연결됩니다.
• 예: BTC(비트코인 네트워크), ETH(이더리움 네트워크)

토큰(Token)

• 어떤 블록체인(플랫폼) 위에서 컨트랙트로 정의된 자산/권리
• 전송 외에도 규칙(락업, 권한, 민팅/버닝, 거버넌스 등)을 설계할 수 있습니다.
• 예: ERC-20, ERC-721

실무에서 자주 터지는 오해

• “거래소에 있으면 코인, 없으면 토큰” → 기술 구분이 아닙니다.
  자체 체인이 있으면 코인, 남의 체인 위 컨트랙트면 토큰입니다.

---

2) 블록체인 vs 분산원장 — “데이터 구조”와 “합의”를 분리하면 헷갈림이 사라진다

• 분산원장(Distributed Ledger): 장부를 여러 참여자가 동시에 갖고 동기화하는 개념(넓은 범주)
• 블록체인(Blockchain): 그중에서도 데이터를 블록 단위로 연결해 쌓는 구현 방식

여기서 핵심은 “블록”이 아니라 합의(consensus) 입니다.
블록만 연결해도, “어느 체인이 정답인가?”가 해결되지 않으면 장부는 하나로 수렴하지 않습니다.

실무에서 자주 터지는 오해

• “블록만 있으면 변조가 안 된다”
  → 변조 난이도는 검증 규칙 + 합의 구조 + 참여자 분포에 의해 결정됩니다.

---

3) 노드(Node) — 서버가 아니라 ‘규칙을 실행하고 검증하는 참여자’

노드는 단순 저장소가 아닙니다. 네트워크 규칙을 실행하고, 트랜잭션/블록을 검증하며, 데이터를 전파합니다.

노드가 하는 일을 실무 관점으로 보면:

• 읽기(조회): 상태/블록/트랜잭션 조회
• 쓰기(전송): 트랜잭션을 네트워크에 브로드캐스트
• 검증: 규칙 위반 트랜잭션/블록 거부
• 동기화: 다른 노드와 상태를 맞춤

실무에서 자주 터지는 오해

• “RPC 제공자가 곧 블록체인이다”
  → RPC 제공자는 “접근 창구”일 뿐이고, 블록체인은 다수 노드의 합의로 유지됩니다.

---

4) JSON-RPC — 앱이 노드와 대화하는 ‘요청 인터페이스’

DApp/백엔드가 체인에 요청을 보낼 때 가장 많이 마주치는 형태가 JSON-RPC입니다.

• eth_call: 상태 변경 없이 실행 결과를 시뮬레이션/조회
• eth_sendRawTransaction: 서명된 트랜잭션을 네트워크로 전송(상태 변경 가능)
• eth_getBalance: 잔고 조회

실무 실수 1: eth_call을 보내고 “왜 체인에 기록이 안 남지?”라고 묻는 경우

eth_call은 대부분 “미리 실행해보는 조회”라 기록이 남지 않습니다.
상태 변경은 서명된 트랜잭션 전송부터 시작이고, 여기서부터 수수료/대기/실패 케이스가 등장합니다.

실무 실수 2: RPC를 하나만 붙여두고 장애를 처음 겪는 경우

개발 단계에서는 잘 되다가, 특정 시간대에 RPC가 느려지면 서비스가 통째로 멈춘 것처럼 보입니다.
운영 단계에서는 최소한 아래가 필요합니다.

• fallback RPC(대체 엔드포인트)
• 간단한 재시도/타임아웃 정책
• 주요 RPC 호출 모니터링

---

5) DApp — “컨트랙트만”이 아니라 UI/지갑/인프라까지 묶인 제품

DApp은 보통 아래 조합입니다.

• 스마트 컨트랙트(온체인 규칙/상태)
• 프론트엔드(UI)
• 지갑(키 관리 + 서명)
• 백엔드(선택): 인덱싱, 캐시, 알림, 검색, 속도 개선

실무에서 자주 터지는 오해

• “DApp이면 서버가 없어야 한다”
  → 현실적으로 인덱싱/알림/캐시는 대부분 필요합니다.
  중요한 건 “핵심 규칙과 최종 상태가 온체인에 있는가”입니다.

---

6) EVM — 스마트 컨트랙트를 실행하는 런타임(그리고 비용 모델)

EVM은 컨트랙트 바이트코드를 실행하고 그 결과로 상태를 바꿉니다.
실무에서는 EVM을 “실행기”로만 보면 반쪽이고, 비용 모델(가스) 까지 포함해서 봐야 합니다.

• 같은 로직도 가스 최적화가 없으면 운영비가 커집니다.
• 이벤트 설계/오프체인 인덱싱과 같이 보지 않으면 제품이 느려집니다.

실무에서 자주 터지는 오해

• “EVM 호환이면 완전히 동일하게 동작한다”
  → 수수료 정책/프리컴파일/RPC 구현/체인 파라미터 차이로 비용과 동작이 달라질 수 있습니다.

---

7) 네트워크 비교를 할 때, 실무에서 바로 쓰는 5가지 질문

새 체인을 볼 때 아래 5개 질문만 던져도 정리가 됩니다.

1. 합의 방식은? (PoW/PoS/DPoS/BFT 계열)
2. 실행 환경은? (EVM/WASM/자체 VM)
3. 상태 모델은? (Account/UTXO)
4. 수수료 모델은? (가스/고정/기타)
5. 운영 관점에서 노드·검증자 구조는? (퍼블릭/퍼미션드/위임)

---

8) 운영 팁: “사이트 접근 여부”부터 먼저 확인하기

이 글을 포함해 시리즈 글을 공개할 때, 저는 내용만큼이나 접근성을 먼저 봅니다.
404/403/로그인 강제/레이아웃 붕괴/이미지 깨짐은 독자도 떠나게 하지만, 검색엔진 신뢰도에도 영향을 줍니다.

공개 접근 체크리스트(5분 점검)

• 시크릿 모드에서 열리는가?
• 모바일에서 제목/본문/코드블록이 깨지지 않는가?
• 이미지/다이어그램이 404가 아닌가?
• 리다이렉트/로그인 강제가 걸려 있지 않은가?
• 내부 링크(이전/다음/관련 글)가 정상 동작하는가?

---

FAQ

Q1. 블록체인은 비트코인부터 볼까, 이더리움부터 볼까?

원리 이해는 비트코인이 단순해서 좋고, 개발 실습은 이더리움(EVM)이 접근성이 좋습니다.
처음에는 “큰 그림(이 글) → EVM 기반 개발 흐름 → 비트코인 구조” 순서가 무난합니다.

Q2. DApp은 정말 탈중앙인가요?

핵심 로직/상태가 온체인에 있으면 탈중앙 성격이 강해지지만, UX를 위해 일부 중앙화 구성요소(인덱싱/알림)는 섞이는 경우가 많습니다.
중요한 건 “무엇을 온체인에 두었고, 왜 온체인인가”를 설명할 수 있는가입니다.

---

업데이트 로그

• 2026-01-22: 실무 실수(eth_call/RPC 장애) 사례 추가, 허브 운영 섹션 강화