Road to Web3 (17) 오라클과 가격 피드: 체인 밖 진실을 체인 안으로 넣는 방법

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

이번 편의 목표는 한 문장입니다.

• 외부 데이터가 들어오는 순간, 블록체인은 더 이상 닫힌 세계가 아니며 신뢰 설계가 급격히 어려워진다

 

제가 처음 디파이와 온체인 결제를 볼 때 했던 오해는 이렇습니다.

• 체인 위에서 돌아가니까 가격도 체인 위에 있을 것이다
• 가격이 틀리면 그냥 데이터 오류다
• 오라클은 API 한 번 호출하는 것과 비슷하다

현실은 이렇습니다.

• 체인은 외부 세계를 모른다
• 가격은 외부에서 넣어야 하고, 그 순간 신뢰 경계가 생긴다
• 오라클 문제는 데이터 정확도보다 조작 가능성과 가용성 실패가 더 위험하다

---

 

1) 오라클이란 무엇인가

오라클은 체인 밖 정보를 체인 안에 반입하는 메커니즘입니다.

• 자산 가격
• 환율
• 금리
• 날씨 경기 결과 같은 이벤트
• KYC나 신용 점수 같은 오프체인 판정 결과

오라클이 없으면 체인 앱은

• 체인 내부 상태만으로 계산 가능한 것만

할 수 있습니다.

---

 

2) 가격 피드는 왜 가장 흔한 오라클인가

가격은 체인 서비스의 핵심 의존성입니다.

• 대출 담보 청산
• 스테이블코인 페그 유지
• 파생상품 정산
• 결제 금액 환산
• 수수료 계산

가격이 틀리면 돈이 새거나, 청산이 잘못되거나, 누군가가 공짜로 이익을 가져갑니다.
따라서 가격 피드는 기능이 아니라 보안 요소에 가깝습니다.

---

 

3) 오라클 파이프라인: 어디서 신뢰가 깨질 수 있나

대략적인 흐름은 이렇습니다.

1) 데이터 소스 거래소, 시장 데이터 제공자
2) 집계와 정제 여러 소스 평균, 이상치 제거
3) 게시자 노드 네트워크 또는 운영 주체
4) 온체인 피드 컨트랙트가 최신 값을 저장
5) 앱 컨트랙트가 값을 읽어 로직을 수행

이 흐름에서 위험은 각 단계마다 존재합니다.

• 소스가 오염될 수 있다
• 집계가 편향될 수 있다
• 게시자가 멈출 수 있다
• 온체인 값이 오래될 수 있다

---

 

4) 두 가지 대표 모델: 푸시형 피드 vs 풀형 검증

4.1 푸시형 push feed

게시자가 주기적으로 온체인에 값을 업데이트합니다.

• 장점: 컨트랙트는 읽기만 하면 된다
• 단점: 업데이트가 멈추면 값이 오래된다
• 운영 포인트: 하트비트와 staleness 체크가 필수

4.2 풀형 pull with proof

컨트랙트가 실행될 때 외부 데이터와 증명을 함께 가져와 검증합니다.

• 장점: 최신성을 확보하기 쉽다
• 단점: 트랜잭션이 무거워지고 통합이 복잡해진다
• 운영 포인트: 증명 검증 비용과 장애 시 대체 경로

두 모델 모두 본질은 같습니다.

• 체인 밖의 어떤 주체를 일정 부분 믿는다

---

 

5) 왜 신뢰 설계가 어려워지나: 3대 리스크

5.1 조작 가능성

정확도 오류가 아니라 경제적 공격을 상정해야 합니다.

5.2 최신성

값이 맞더라도 너무 늦으면 사고가 납니다.

• 급락장에서 오래된 가격을 쓰면 청산이 늦어져 부실이 쌓인다
• 급등장에서 오래된 가격을 쓰면 누군가 싸게 매수할 수 있다

그래서 피드에는 보통

• updatedAt 또는 roundId 같은 메타데이터
• maxDelay 같은 정책

이 따라옵니다.

5.3 가용성

오라클이 멈추면 프로토콜이 멈춥니다.
web2로 치면 결제 PG가 멈춘 순간 매출이 멈추는 것과 같습니다.

---

 

6) 공격 시나리오: 가격 조작은 어떻게 일어나나

가장 유명한 패턴은 조작 가능한 가격을 잠깐 만들어서

• 담보 가치를 부풀리고 대출을 최대한 땡긴 뒤
• 가격을 원복시키고
• 남는 차익을 들고 튀는

종류입니다.

대표 공격 벡터

1) 유동성 얕은 DEX 풀을 조작
2) 단일 소스 또는 약한 피드가 그 가격을 따라감
3) 컨트랙트가 그 값을 신뢰해 대출이나 정산을 실행
4) 공격자는 한 블록 안에서 수익 실현

그래서 가격 피드 설계에서 자주 나오는 방어가

• DEX 스팟 가격을 그대로 믿지 말기
• 시간 가중 평균 TWAP 같은 지연 필터
• 여러 소스 집계
• staleness 체크와 회로 차단기

입니다.

---

 

7) web2 비유: 오라클은 외부 기준값 공급 시스템이다

결제 서비스에서 금액과 환율은 종종 외부 기준을 씁니다.

• 카드사 고시 환율
• 은행 고시 환율
• PG 정산 수수료
• 특정 시점 기준 금리

이 기준이 느리거나, 틀리거나, 멈추면 정산과 회계가 붕괴합니다.
오라클도 똑같습니다.

• 체인 앱의 외부 기준값을 공급하는 시스템

그래서 엔지니어링 포인트도 web2와 닮습니다.

• 소스 다중화
• 지표와 알람
• 장애 시 degrade 모드
• 정책 문서화

---

 

8) 제품 의사결정 프레임: 어떤 오라클을 언제 쓰나

오라클 선택은 트레이드오프입니다.

• 빠름 vs 보수적
• 최신 vs 안정
• 단순 통합 vs 복잡하지만 강한 검증

예시

• 결제 환산처럼 금액이 작은 경우: 보수적 가격도 괜찮다
• 담보 청산처럼 리스크가 큰 경우: 조작 저항이 최우선이다
• 트레이딩처럼 UX가 중요한 경우: 빠른 업데이트가 중요하다

---

 

9) 체크리스트

1) 피드 최신성 메타데이터를 확인한다
2) maxDelay 정책을 코드에 넣는다
3) 값이 비정상일 때 회로 차단기 동작을 정의한다
4) 단일 소스 오라클을 피한다
5) DEX 스팟 가격을 직접 신뢰하지 않는다
6) 가능한 경우 TWAP 또는 집계 피드를 쓴다
7) 가격 단위와 소수점 체계를 명확히 한다
8) 오라클 주소 변경과 업그레이드 리스크를 문서화한다
9) 오라클 장애 시 서비스 동작을 정의한다 정지 또는 보수적 모드
10) 모니터링 지표를 만든다 최신성, 결측, 급변, 게시 지연
11) 알람은 업데이트 지연과 값 급변을 분리한다
12) 테스트넷과 메인넷 피드는 다르다 환경별로 검증한다
13) 가격 읽기 로직을 한 곳에 모아 재사용한다
14) 오라클 입력을 신뢰 경계로 보고 보안 리뷰한다
15) 외부 공시 기준이 필요한 경우 기준을 고정한다
16) 책임 소재와 보상 정책을 제품 문서로 남긴다

---

결론

• 오라클은 체인 밖 사실을 체인 안에 넣는 다리다
• 다리가 생기는 순간 신뢰 경계와 공격 면적이 커진다
• 성공 조건은 정확도보다 조작 저항, 최신성, 가용성의 균형이다