DeFi 이벤트 파이프라인이 필요한 이유
DeFi 프로토콜의 이벤트를 단순히 구독하는 것과, 실제 서비스에서 신뢰할 수 있게 처리하는 것은 완전히 다른 문제다. Uniswap V3 Swap 이벤트와 Aave 청산 이벤트를 예시로 프로덕션 수준의 DeFi 이벤트 파이프라인을 설계하는 방법을 설명한다.
AMM 기초: Uniswap의 가격 결정 원리
전통 거래소는 호가창(Order Book)으로 매수/매도 주문을 매칭한다. Uniswap은 수학 공식으로 가격을 자동 결정한다.
Uniswap V2의 기본 공식: x × y = k (constant product formula)
- x = 토큰 A 풀 잔액
- y = 토큰 B 풀 잔액
- k = 상수
예: ETH 10개, USDC 30,000개 풀 (k=300,000)에서 1 ETH 구매 시:
새 x = 9, 새 y = 333,333, 내가 지불한 USDC = 3,333 (시장가 3,000 대비 비쌈 → “슬리피지”)
Uniswap V3는 V2의 유동성 비효율을 해결했다. 공급자가 “특정 가격 범위”에만 유동성을 공급할 수 있어 자본 효율이 크게 향상됐다.
Uniswap V3 Swap 이벤트 구조
event Swap(
address indexed sender, // 스왑 시작자 (보통 Router 주소)
address indexed recipient, // 토큰 수령자 (실제 사용자)
int256 amount0, // 토큰0 변화량 (음수=풀에서 나감, 양수=풀로 들어옴)
int256 amount1, // 토큰1 변화량
uint160 sqrtPriceX96, // 스왑 후 가격 (인코딩됨)
uint128 liquidity, // 현재 활성 유동성
int24 tick // 현재 가격 틱
);sqrtPriceX96 디코딩
Uniswap V3는 가격을 sqrtPriceX96 = sqrt(price) × 2^96으로 인코딩한다. 실제 가격 계산:
price = (sqrtPriceX96 / 2^96)^2- Token 쌍의 decimals 보정:
adjustedPrice = price × 10^(decimals0 - decimals1)
WETH/USDC 풀의 경우: adjustedPrice = price × 10^(18 - 6) = price × 10^12 → ETH 가격 in USDC
Aave 청산 메커니즘 이해
Aave는 담보를 맡기고 다른 자산을 빌리는 분산 대출 프로토콜이다.
Health Factor 계산:
HF = (담보 가치 × 청산 임계값) / 부채 가치
- HF > 1.0 → 안전
- HF < 1.0 → 청산 가능 (누구든 청산 실행 가능)
- HF < 1.1 → 경고 (가격 변동으로 곧 청산될 수 있음)
HF가 1.0 미만으로 떨어지면 누구든 liquidationCall()을 호출해 대출자의 부채 일부를 대신 상환하고 담보를 청산 보너스(5~10%)와 함께 받을 수 있다. 청산 봇들이 24/7 모니터링하며 경쟁한다.
실제 사건: 2022년 6월 ETH 가격 급락 시 Aave에서 하루 동안 $125M 이상의 포지션이 청산됐다. 청산 봇들이 경쟁적으로 청산 tx를 제출하면서 gas 전쟁이 발생했다. Flashbots를 사용한 봇이 MEV 경매에서 승리해 대부분의 청산을 처리했다.
Aave 청산 이벤트 구조
event LiquidationCall(
address indexed collateralAsset,
address indexed debtAsset,
address indexed user, // 청산 당한 사람
uint256 debtToCover, // 상환된 부채
uint256 liquidatedCollateralAmount, // 청산된 담보
address liquidator, // 청산한 봇
bool receiveAToken
);DeFi 이벤트 파이프라인 설계
Uniswap V3 Swap Producer
블록이 생성될 때마다 HTTP getLogs로 Swap 이벤트를 조회하고, sqrtPriceX96를 디코딩해서 Redis Streams의 defi_prices 큐에 적재한다.
Aave Health Factor 모니터링 Consumer
주기적으로 감시 대상 주소들의 getUserAccountData()를 조회하고, Health Factor가 임계치 이하이면 liquidation_alerts 큐에 알림을 적재한다:
- HF < 1.0 → CRITICAL 알림 + 청산 봇 큐에 전달
- HF < 1.1 → WARNING 알림
유동성 공급자의 비영구적 손실(Impermanent Loss)
DeFi 이벤트를 모니터링할 때 반드시 알아야 할 개념이다.
ETH 10개, USDC 30,000개 예치 후 ETH가 $6,000으로 상승하면:
- 차익거래자가 ETH를 사가고 USDC를 채움
- LP 포지션: ETH 7.07개, USDC 42,426 USDC가 됨
- 그냥 보유(HODL)했으면: ETH 10개 × $6,000 = $60,000
- LP 포지션 가치: $42,426 + 7.07×$6,000 = $84,846
LP가 더 많은 절대적 수익을 얻었지만, HODL이 상대적으로 더 수익적이었다. 이것이 비영구적 손실이다. 모니터링 시스템에서 LP 포지션의 실제 가치를 계산할 때 이 개념이 필요하다.
실전 Q&A
Q: Redis가 다운되면 파이프라인이 완전히 멈추지 않나요?
A: 맞다. Redis는 단일 실패 지점(SPOF)이다. Redis Sentinel(고가용성, 자동 failover), Redis Cluster(수평 확장)으로 해결한다. 더 근본적으로는 Kafka로 전환하면 브로커 장애에도 내구성이 있지만 운용 복잡도가 크게 올라간다.
Q: 실제 청산 봇을 만들 수 있나요?
A: 기술적으로 가능하지만 청산 시장은 극도로 경쟁적이다. Flashbots MEV-Share로 private mempool에 청산 tx를 제출하고, Flash Loan으로 무자본 청산하며, 지연시간을 최적화(co-location, 최적화된 RPC)해야 한다. 단순히 HF를 모니터링하는 것으로는 수익화가 어렵다.
Q: Kafka vs Redis Streams, 언제 Kafka를 선택하나요?
A: Redis Streams는 일일 처리량 100만 건 이하, 팀이 작고 운용 부담을 최소화하고 싶을 때. Kafka는 일일 처리량 1000만 건 이상, 메시지 영구 보존 필요, 여러 Consumer Group이 같은 데이터를 독립적으로 소비할 때.
핵심 요약
- Uniswap V3 sqrtPriceX96는
price = (sqrtPriceX96 / 2^96)^2로 디코딩한다 - Aave Health Factor가 1.0 미만이면 청산 가능 상태다
- 동일한 Producer-Consumer 파이프라인 패턴이 가격 피드, 청산 모니터링, 입출금 처리에 모두 적용된다
- DLQ 모니터링은 DeFi 서비스의 핵심 건강 지표다
- 실제 청산 봇 운영은 MEV 경쟁이 심각하다. 모니터링과 봇 구현은 별개로 접근해야 한다
About the Author
