금융기관이 블록체인을 도입할 때 가장 먼저 맞닥뜨리는 질문은 기술 선택이 아닙니다. “어떻게 내부 시스템을 안전하게 연결할 것인가”입니다.
왜 DMZ가 필요한가
은행이나 보험사의 코어 시스템(원장, 자산 DB)은 인터넷과 직접 연결될 수 없습니다. 그런데 이더리움 메인넷은 퍼블릭 인터넷 위에 있습니다. 이 두 세계를 연결하려면 완충 구역이 필요합니다. 이것이 DMZ(Demilitarized Zone)입니다.
DMZ 없이 내부망에서 블록체인 RPC에 직접 접속하면:
- 내부 IP와 트랜잭션 패턴이 외부 서비스에 노출됩니다
- 퍼블릭 RPC 서비스(Infura, Alchemy)가 다운되면 전체 시스템이 멈춥니다
- 방화벽 정책이 복잡해지고 감사 추적이 어려워집니다
인터넷 (퍼블릭 블록체인) ←→ DMZ ←→ 내부망 (코어 시스템)
전체 아키텍처 구조
↕
↕
데이터 흐름 1: 블록체인 이벤트 수신 (외부 → 내부)
[이더리움 메인넷]
|
| 스마트컨트랙트 이벤트 발생
↓
[Webhook Receiver] <– DMZ 경계
|
| 수신 즉시 큐에 적재 (직접 처리 금지)
↓
[Redis Streams]
|
| Consumer가 메시지 꺼내서 처리
↓
[Core System] <– 내부망 경계
|
↓
[감사 로그 DB]
|
| 스마트컨트랙트 이벤트 발생
↓
[Webhook Receiver] <– DMZ 경계
|
| 수신 즉시 큐에 적재 (직접 처리 금지)
↓
[Redis Streams]
|
| Consumer가 메시지 꺼내서 처리
↓
[Core System] <– 내부망 경계
|
↓
[감사 로그 DB]
핵심 원칙: Webhook Receiver는 이벤트를 받는 즉시 Redis Streams에 적재하고 응답합니다. 처리 로직을 Receiver 안에서 실행하지 않습니다. 처리 중 오류가 나도 블록체인은 재전송을 보장하지 않기 때문입니다.
데이터 흐름 2: 트랜잭션 제출 (내부 → 블록체인)
[Core System] <– 내부망
|
| 트랜잭션 생성 + 승인 워크플로우 완료
↓
[MPC Key Management] → 서명
↓
[Redis Streams]
|
| Transaction Dispatcher가 꺼냄
↓
[Transaction Dispatcher] <– DMZ
|
↓
[Gateway Server]
|
| 유일한 외부 통신 채널
↓
[Private RPC Node]
↓
[이더리움 메인넷]
|
| 트랜잭션 생성 + 승인 워크플로우 완료
↓
[MPC Key Management] → 서명
↓
[Redis Streams]
|
| Transaction Dispatcher가 꺼냄
↓
[Transaction Dispatcher] <– DMZ
|
↓
[Gateway Server]
|
| 유일한 외부 통신 채널
↓
[Private RPC Node]
↓
[이더리움 메인넷]
구성요소 상세
Private RPC Node
퍼블릭 RPC(Infura, Alchemy)를 쓰지 않고 DMZ 안에 전용 노드를 운영합니다.
| 항목 | 퍼블릭 RPC | Private RPC Node |
|---|---|---|
| 트랜잭션 데이터 노출 | 외부 서비스에 노출 | 내부에서만 처리 |
| 서비스 의존성 | 장애 시 시스템 중단 | 자체 운영으로 독립 |
| SLA 보장 | 외부 정책에 종속 | 직접 관리 |
| 감사 추적 | 불가 | 모든 요청 로깅 |
Redis Streams (메시지 큐)
수신과 처리를 분리하는 핵심 컴포넌트입니다.
| 시나리오 | 큐 없이 직접 처리 | Redis Streams |
|---|---|---|
| Consumer 서버 재시작 | 이벤트 유실 | 재시작 후 이어서 처리 |
| 처리 실패 | 유실 | Dead Letter Queue 재처리 |
| 트래픽 폭증 | 처리 서버 과부하 | 큐가 완충 역할 |
| 감사 추적 | 처리 이력 없음 | 모든 메시지 이력 보관 |
멱등성(Idempotency) 설계
같은 메시지가 두 번 처리돼도 결과가 동일해야 합니다. 네트워크 오류로 중복 처리는 피할 수 없기 때문입니다.
메시지 수신
|
↓
[이미 처리된 txHash+logIndex 인가?]
|
Yes ──→ 스킵 (중복)
No ──→ 처리 진행 ──→ 완료 후 DB 기록
|
↓
[이미 처리된 txHash+logIndex 인가?]
|
Yes ──→ 스킵 (중복)
No ──→ 처리 진행 ──→ 완료 후 DB 기록
Transaction Dispatcher — Nonce 관리
이더리움 트랜잭션은 계정별 순서(Nonce)가 있습니다. 동시에 여러 트랜잭션을 제출할 때 Nonce 충돌이 발생하면:
- 같은 Nonce가 두 번 나오면 하나가 무시됩니다
- Nonce에 빈 구멍이 생기면 이후 트랜잭션이 전부 대기 상태에 빠집니다
해결: Dispatcher 내에서 Nonce를 직렬로 관리하고 트랜잭션 제출 전 Lock을 획득합니다.
SUBMITTED → PENDING(Mempool) → CONFIRMED(n blocks) → FINALIZED
|
↓
REORGED → 재제출
|
↓
REORGED → 재제출
장애 시나리오별 대응
| 장애 | 영향 범위 | 대응 |
|---|---|---|
| Private RPC Node 다운 | 트랜잭션 제출 불가 | Standby 노드 자동 전환 |
| Webhook Receiver 다운 | 이벤트 수신 중단 | 재시작 후 블록 커서부터 재수집 |
| Redis Streams 다운 | 전체 파이프라인 중단 | Redis Cluster / Sentinel 이중화 |
| Consumer 다운 | 처리 중단 (수신은 계속) | 재시작 후 미처리 메시지 자동 재개 |
| Transaction Dispatcher 다운 | 제출 중단 (승인은 계속) | 재시작 후 PENDING 트랜잭션 재제출 |
정리: DMZ 아키텍처 3대 원칙
1
단일 통신 경로
Gateway를 통하지 않는 블록체인 통신은 없다. 감사 추적과 접근 제어의 기반.
2
수신과 처리 분리
Receiver는 받기만 하고, Redis Streams가 완충. 이벤트 유실 방지의 기반.
3
멱등성 보장
같은 이벤트 두 번 처리돼도 안전. 분산 시스템 신뢰성의 기반.
이 세 원칙이 지켜진 시스템은 개별 구성요소가 장애를 겪어도 전체 데이터 정합성을 유지할 수 있습니다.
About the Author
