1. 🧊 시작은 '얼어붙은 세계'라는 비유에서

블록체인을 처음 배우는 사람들이 가장 자주 하는 질문이 있다.

"스마트 컨트랙트가 자동으로 실행되는 계약이라면, 그냥 컨트랙트 안에서 달러 환율을 가져와서 정산하면 되는 거 아닌가요? API 호출 한 줄이면 되는데요?"

아주 자연스러운 질문이다. 그리고 이 질문에 대한 답이 곧 오라클(Oracle)의 존재 이유다.

결론부터 말하면 불가능하다. 이더리움 가상머신(EVM) 안에서는 `fetch()`도, `curl`도, 소켓 통신도 존재하지 않는다. 솔리디티(Solidity) 표준 라이브러리를 아무리 뒤져도 HTTP 클라이언트는 없다. 이건 개발자들이 게을러서 안 만든 게 아니라, 만들면 블록체인이 부서지기 때문이다.

결정론(Determinism)이라는 신성한 계약

블록체인의 본질은 "전 세계 수천 대의 노드가 같은 입력에 대해 반드시 같은 결과를 내놓는다"는 합의다. 이걸 결정론적 실행(deterministic execution)이라고 부른다.

그런데 만약 컨트랙트가 `https://api.exchange.com/usd-krw`를 호출할 수 있다면?

그래서 블록체인은 의도적으로 외부와 단절된 샌드박스로 설계되었다. 체인은 자기 안에 기록된 데이터(잔고, 블록 해시, 타임스탬프, 이전 트랜잭션)만 알 수 있다. 이 구조적 고립을 두고 업계에서는 "오라클 문제(The Oracle Problem)"라 부른다.

2. 🌉 오라클의 정의: 예언자가 아니라 '검증된 배달부'

먼저 오해 하나를 정리하자. 여기서 말하는 오라클은 데이터베이스 회사 Oracle Corporation과 아무 관련이 없다. 어원은 고대 그리스 델포이의 신탁(oracle)이다. "인간이 알 수 없는 것을 알려주는 존재"라는 뜻.

블록체인에서 오라클의 기술적 정의는 이렇다.

핵심은 "트랜잭션 형태로"라는 부분이다. 오라클은 컨트랙트가 밖으로 나가서 데이터를 가져오게 만드는 게 아니라, 외부에서 데이터를 체인 안으로 밀어 넣는다(push). 즉 방향이 반대다. 컨트랙트는 여전히 체인 내부에 기록된 값만 읽는다. 결정론은 깨지지 않는다.

오라클의 5가지 분류 축

이 분류를 머리에 넣어두면, 뒤에서 다룰 한계가 어느 축에서 터지는지 훨씬 명확하게 보인다.

3. ⚙️ 내부 동작: 데이터가 체인에 도달하는 4단계 파이프라인

가장 널리 쓰이는 체인링크(Chainlink) Data Feed를 기준으로 실제 경로를 따라가 보자.

① 소스 집계 (Source Aggregation)

단일 거래소 API를 믿으면 안 된다. 그 거래소에서 순간적으로 유동성이 말라 가격이 튀면 그대로 반영된다. 그래서 오라클 노드 하나하나가 여러 데이터 애그리게이터(Coinmarketcap, Kaiko, BraveNewCoin, Amberdata 등)를 참조하고, 그 애그리게이터들은 다시 수십 개 거래소의 거래량 가중 평균가(VWAP)를 계산한다.

② 노드 단위 독립 조회

DON을 구성하는 각 오퍼레이터(예: LinkPool, Figment, T-Systems MMS 등 기관급 운영자)는 서로 통신하지 않고 독립적으로 값을 조회한다. 서로 베끼지 않는 것이 중요하다. 이걸 상관관계 제거(decorrelation)라 부른다.

③ 오프체인 리포팅(OCR)과 중앙값 집계

초기 체인링크는 노드가 각각 온체인 트랜잭션을 보냈다. 노드 21개면 트랜잭션 21건, 가스비 21배. 비효율의 극치였다.

그래서 등장한 것이 OCR(Off-Chain Reporting)이다. 노드들이 P2P 네트워크에서 각자 관측값에 서명하고, 리더 노드가 이를 모아 단일 보고서(report)로 압축한다. 온체인에는 트랜잭션 1건만 올라간다. 가스비가 90% 이상 절감됐다.

④ 임계치(Deviation Threshold) & 하트비트

가격을 1초마다 올리면 가스비로 파산한다. 그래서 두 가지 트리거를 쓴다.

• 편차 임계치: 마지막 기록값 대비 0.5%(ETH/USD 메인넷 기준) 이상 변동 시 갱신
• 하트비트: 변동이 없어도 최대 1시간(3600초)마다 강제 갱신

// Chainlink Data Feed 소비 예시 (Solidity)
import "@chainlink/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol";

contract PriceConsumer {
    AggregatorV3Interface internal feed;

    constructor() {
        // Ethereum Mainnet ETH/USD
        feed = AggregatorV3Interface(0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419);
    }

    function getSafePrice() public view returns (int256) {
        (
            uint80 roundId,
            int256 answer,
            ,
            uint256 updatedAt,
            uint80 answeredInRound
        ) = feed.latestRoundData();

        // ✅ 반드시 해야 하는 3종 방어
        require(answer > 0, "Invalid price");
        require(block.timestamp - updatedAt < 3 hours, "Stale price"); // 신선도
        require(answeredInRound >= roundId, "Round not complete");

        return answer; // decimals()는 보통 8
    }
}

실제 해킹 사고의 상당수는 위 세 줄의 require를 빼먹어서 발생했다. `latestRoundData()`의 반환값을 검증 없이 그대로 쓰는 건, 신원 확인 없이 현금을 내주는 것과 같다.

4. 🎯 오라클이 실제로 떠받치는 것들 — 역할 지도

"오라클 = 가격 피드"라고만 알고 있다면 절반만 아는 것이다. Web3 산업에서 오라클은 이미 인프라 레벨의 OS 서비스에 가깝다.

① DeFi — 청산 엔진의 심장

Aave, Compound, MakerDAO 같은 대출 프로토콜은 담보비율(LTV)을 계산해야 한다. "ETH 10개를 담보로 15,000 USDC를 빌렸는데, ETH 가격이 얼마면 청산인가?" 이 판단 전체가 오라클 값 하나에 달려 있다.

2024~2025년 기준 DeFi TVL의 절대다수가 오라클 값에 직접 의존한다. 오라클이 틀리면 프로토콜은 즉시 파산하거나, 반대로 공격자에게 무이자 무담보 대출을 내준다.

② VRF — '진짜 랜덤'이라는 난제

NFT 민팅 순서, 게임 아이템 뽑기, 화이트리스트 추첨. 여기서 블록체인은 또 한 번 무력하다. `block.timestamp`나 `blockhash`로 난수를 만들면 검증자가 자기 이익에 맞는 블록을 선택할 수 있다. 실제로 이 방식으로 NFT 희귀 아이템을 독식한 사례가 다수 보고됐다.

그래서 VRF(Verifiable Random Function)가 쓰인다. 오라클이 비밀키로 난수를 생성하고, 그 난수가 조작되지 않았음을 증명하는 암호학적 증명(proof)을 함께 제출한다. 컨트랙트는 공개키로 그 증명을 온체인 검증한다. 오라클도 결과를 미리 알고 골라낼 수 없는 구조다.

③ Keeper / Automation — 체인은 스스로 깨어나지 않는다

또 하나의 흔한 오해: "컨트랙트에 `if (시간 == 3시) 실행`을 써두면 3시에 자동 실행되나요?" → 아니다. 블록체인에는 cron이 없다. 누군가 트랜잭션을 보내서 깨워야 한다.

이 '깨우는 역할'도 오라클 네트워크가 담당한다. Chainlink Automation, Gelato 같은 서비스가 조건을 오프체인에서 감시하다가 충족되면 `performUpkeep()`을 호출한다. 이것도 넓은 의미의 오라클이다.

④ RWA와 Proof of Reserve — 신뢰의 회계 감사

토큰화된 국채, 금, 부동산. 이 모든 RWA(Real World Asset)의 핵심 질문은 하나다. "정말 금고에 있나?" 오라클은 커스터디언의 회계 데이터·감사 보고서를 온체인에 주기적으로 게시한다. 스테이블코인의 준비금 증명(PoR)도 동일한 구조다.

⑤ 크로스체인 — 다른 체인은 '외부 세계'다

아주 중요한 통찰: 이더리움 입장에서 솔라나는 '오프체인'이다. 따라서 브릿지는 본질적으로 오라클이다. "저쪽 체인에서 토큰이 정말 락업됐다"는 사실을 이쪽 체인에 알려주는 존재. 그래서 브릿지 해킹의 대부분은 사실 오라클 신뢰 모델 붕괴 사고다.

5. 🕳️ 한계 ①: 신뢰 최소화의 역설 — "트러스트리스라더니?"

여기서부터가 진짜다. 블록체인은 "제3자를 믿지 않아도 되는 시스템"을 팔았다. 그런데 오라클을 끼우는 순간, 우리는 다시 누군가를 믿어야 한다.

보안은 가장 약한 고리의 크기다

이걸 업계에서는 "신뢰의 최소 공통분모(Weakest Link Principle)"라 부른다. 이더리움 L1의 보안 예산이 수십조 원 규모라 해도, 그 위의 프로토콜이 노드 3개 중 2개 서명으로 움직이는 오라클을 쓴다면, 그 프로토콜의 실질 보안은 '노드 2개를 매수하는 비용'이다.

많은 프로젝트가 "우리는 이더리움 위에 있으니 안전하다"고 홍보하지만, 실제 공격자는 L1을 공격하지 않는다. 가장 싼 고리인 오라클을 친다.

6. 💣 한계 ②: 가격 조작과 플래시론 — 교과서가 된 사고들

오라클 한계의 가장 극적인 실현은 가격 조작 공격(price manipulation attack)이다. 특히 컨트랙트가 오라클 없이 "DEX 풀의 현재 비율을 그냥 읽는" 방식(spot price oracle)을 쓸 때 치명적이다.

플래시론이 바꾼 게임의 규칙

플래시론은 같은 트랜잭션 안에서 빌리고 갚으면 담보가 필요 없는 대출이다. 즉 공격자는 자본이 없어도 순간적으로 수천억 원을 손에 쥘 수 있다. 그 돈으로 유동성 얕은 AMM 풀을 한쪽으로 밀어버리면, 그 풀의 가격은 몇 배로 왜곡된다.

[ 전형적인 오라클 조작 시나리오 ]

1. 플래시론으로 USDC 5,000만 달러 차입
2. 유동성 얕은 DEX 풀에서 토큰 X를 대량 매수  → X 가격 8배 폭등
3. 대출 프로토콜에 X를 담보로 예치
     (프로토콜은 그 DEX 풀을 오라클로 사용 중)
   → 담보 평가액이 8배로 계산됨
4. 실제 가치의 8배에 해당하는 USDC/ETH를 차입
5. DEX에서 포지션 되돌리고 플래시론 상환
6. 차액 수령 후 종료 — 전 과정이 단일 트랜잭션, 약 13초

→ 프로토콜에는 가치 없는 담보와 거대한 부실채권만 남는다

역사에 남은 케이스들

여기서 도출되는 교훈은 명확하다.

✅ 가격은 '유동성 가중'되어야 한다. 조작 비용이 공격 이익보다 커야 한다.
✅ TWAP(시간가중평균가)을 병용하라. 30분 TWAP을 밀려면 30분간 자본을 노출해야 하고, 그 사이 차익거래자들이 달려든다.
✅ Uniswap V3의 built-in TWAP 오라클은 단일 블록 조작에 강하지만, 대신 급락장에서 실가격을 늦게 따라간다. 트레이드오프.

7. ⏱️ 한계 ③: 지연(Latency)과 오래된 데이터(Staleness)

앞서 편차 임계치와 하트비트를 설명했다. 그 구조가 낳는 부작용을 정면으로 보자.

계단형 가격의 세 가지 부작용

1) 오라클 프론트러닝(Oracle Front-running)
중앙화 거래소는 밀리초 단위로 움직인다. 온체인은 12초(이더리움 슬롯) 단위다. 이 격차를 아는 트레이더는 "오라클이 곧 올릴 값"을 미리 알고 포지션을 잡는다. 특히 오래된 온체인 파생상품 프로토콜은 이 공격에 조직적으로 털렸다.

2) 부당 청산 / 청산 실패
급락장에서 오라클이 0.5% 임계치를 채우기 전이라면 청산이 늦게 발동한다. 그 사이 담보 가치가 부채 밑으로 내려가면 프로토콜에 악성 부채(bad debt)가 쌓인다. 2021년 5월, 2022년 5월(LUNA), 2025년 급락 국면에서 반복적으로 관측된 패턴이다.

3) 체인 혼잡 시 완전 마비
가장 무서운 시나리오. 2020년 3월 12일, 이른바 'Black Thursday'. ETH가 하루에 50% 가까이 폭락하며 이더리움 가스비가 폭등했다. MakerDAO의 청산 봇들은 가스비 경쟁에서 밀려 트랜잭션을 밀어 넣지 못했고, 일부 청산 경매가 0 DAI 입찰로 낙찰되는 사태가 벌어졌다. 약 400만 달러 규모의 담보가 사실상 공짜로 넘어갔고, MKR 추가 발행으로 손실을 메워야 했다.

대응 흐름: Push에서 Pull로

그래서 최근 오라클 설계는 Pull 모델로 이동 중이다. Pyth Network, Chainlink Data Streams, RedStone 등이 대표적이다.

원리는 이렇다. 오라클 노드들은 고빈도(수백 ms 단위)로 서명된 가격 데이터를 오프체인에 게시한다. 사용자는 거래를 실행할 때 그 서명 데이터를 자기 트랜잭션의 calldata에 첨부한다. 컨트랙트는 서명을 검증하고 즉시 사용한다.

흥미로운 점은, Pull 모델도 새 문제를 만든다는 것이다. 사용자가 여러 서명 중 자기에게 유리한 것을 고르면 어떻게 할까? 그래서 Pull 방식 컨트랙트는 "제출된 데이터의 타임스탬프가 현재 블록에 충분히 가까울 것"을 강제해야 한다. 한계는 사라지지 않고 위치를 옮긴다.

8. 🧩 한계 ④: 주관적 사실과 '판정 불가' 영역

가격은 그래도 쉬운 편이다. 숫자고, 시장이 있고, 집계가 가능하다. 문제는 숫자가 아닌 사실이다.

예를 들어 예측시장에서 이런 질문을 걸었다고 하자.

여기에는 참조할 API가 존재하지 않는다. '휴전'의 정의, '표절'의 기준, '천재지변'의 범위는 모두 해석의 문제다. 이런 데이터를 오라클은 어떻게 다룰까?

낙관적 오라클(Optimistic Oracle)

UMA가 개척한 방식이다. 논리는 법정과 비슷하다.

① 누군가 "이 질문의 답은 YES"라고 주장(assert)하며 보증금을 걸고 제출한다.
② 일정 기간(예: 2시간~48시간) 동안 아무도 반박하지 않으면 그대로 확정된다.
③ 반박이 들어오면 토큰 홀더 투표(DVM)로 넘어가고, 틀린 쪽의 보증금이 이긴 쪽에게 넘어간다.

즉 "정직이 경제적으로 이득"이 되게 게임을 설계한다. 낙관적 오라클은 주관적 데이터를 다룰 수 있는 거의 유일한 실용적 수단이지만, 명백한 한계가 있다.

🔻 느리다. 분쟁 기간이 필수라 실시간 DeFi에는 쓸 수 없다.
🔻 거버넌스 공격에 노출된다. 판정에 걸린 금액이 투표 토큰 시가총액보다 커지면, 토큰을 매집해 판정을 뒤집는 것이 수익성 있는 전략이 된다. 이를 "Oracle Extractable Value(OEV)" 혹은 거버넌스 51% 공격이라 부른다.
🔻 질문 문구(resolution criteria)의 모호함이 그대로 분쟁이 된다. 실제 예측시장 역사에서 "질문 해석 논란"으로 커뮤니티가 갈라진 사례는 수없이 많다.

9. 💰 한계 ⑤: 비용, 인센티브, 그리고 '누가 돈을 내는가'

기술 문서에서 잘 다루지 않지만 실무에서 가장 먼저 부딪히는 한계다.

오라클은 비싸다

가격 피드 하나를 유지하려면 온체인 트랜잭션 비용이 계속 발생한다. 이더리움 메인넷에서 ETH/USD 피드 하나의 연간 가스 비용은 수만~수십만 달러 수준이 될 수 있다. 롤업에서는 훨씬 저렴해졌지만 공짜는 아니다.

그래서 현실은 이렇다.

• 메이저 자산(ETH, BTC, 주요 스테이블코인): 여러 오라클이 경쟁적으로 고품질 피드를 제공한다. 좋다.
• 롱테일 자산(신규 토큰, LP 토큰, 유동성 스테이킹 파생상품): 피드가 없거나, 있어도 노드 수가 적고 소스가 부실하다. 여기가 바로 공격자들의 사냥터다.

실제로 2021년 이후 발생한 대형 DeFi 오라클 사고의 압도적 다수는 롱테일 자산 또는 자체 제작 오라클에서 터졌다. 메이저 피드는 견고했다. 문제는 "우리 토큰은 피드가 없으니 Uniswap 풀을 읽자"는 결정이었다.

인센티브 정합성(Incentive Alignment)의 난제

오라클 노드가 거짓 데이터를 보고할 때 얻는 이익이, 잃을 것(스테이킹된 담보 + 평판 + 미래 수익)보다 크면 노드는 배신한다. 이건 도덕이 아니라 산수다.

공격 실행 조건:
  (조작으로 탈취 가능한 TVL) > (담합 비용 + 슬래싱 손실 + 평판 가치)

방어 설계 목표:
  오라클이 보호하는 가치  <  오라클을 깨는 비용

이 문제를 해결하려는 시도로 암호경제적 보안(Crypto-economic Security), 스테이킹 기반 슬래싱, 재담보(restaking, EigenLayer 계열 AVS), ZK 증명 기반 오라클(TLSNotary, zkTLS) 등이 연구·상용화되고 있다. 특히 zkTLS는 흥미롭다. "이 데이터가 실제로 특정 HTTPS 서버에서 왔다"는 것을 서버 협조 없이 증명하는 방식으로, 데이터 출처의 진위 문제를 암호학으로 끌어내린다. 다만 이것도 "그 서버가 진실을 말했는가"는 해결하지 못한다. 출처 증명 ≠ 진실 증명.

10. 🧷 한계 ⑥ : 잘 언급되지 않는 실무적 함정들

① 서킷 브레이커 / min-max 답변

대부분의 집계 컨트랙트에는 `minAnswer`, `maxAnswer` 범위가 설정되어 있다. 시장가가 이 범위를 벗어나면 오라클은 경계값에 고정된다. 2022년 LUNA 붕괴 당시, 어떤 프로토콜은 LUNA가 0.1달러 아래로 폭락했는데도 오라클이 하한값을 계속 보고해 거대한 차익 거래 기회를 만들었다. "오라클이 멈춘 게 아니라, 거짓말을 하고 있었다."

② decimals 혼동

USD 피드는 보통 8 decimals, ETH 기준 피드는 18 decimals다. 이 둘을 섞어 계산하면 10^10배 오차가 난다. 감사 리포트에 단골로 등장하는 실수다.

③ L2에서의 시퀀서 다운

Arbitrum, Optimism 등에서 시퀀서가 멈추면 사용자는 트랜잭션을 보낼 수 없다. 그런데 시퀀서가 복구된 직후, 그동안 변동한 가격이 한 번에 반영된다. 이 순간 대량 청산이 터진다. 그래서 L2에서는 Sequencer Uptime Feed를 함께 확인해 "다운 직후 일정 시간은 청산 금지" 로직을 넣는 것이 권장된다. 이걸 아는 팀이 놀랍도록 적다.

④ 파생 자산의 가격 계산 오류

스테이킹 파생 토큰(예: LST)이나 볼트 지분 토큰의 가치를 계산할 때 내부 함수 `getPricePerShare()`를 그대로 신뢰하면, 그 함수 자체가 조작 가능하다. 토큰의 "공정 가치"와 "순간 교환 비율"은 다르다. Rari, Cream, Beanstalk 등 다수 사고의 공통 뿌리다.

⑤ 오라클 종료·마이그레이션 리스크

오라클 제공자가 특정 피드를 deprecated 처리하면 컨트랙트는 갱신되지 않는 값을 계속 읽는다. 불변(immutable)하게 하드코딩된 피드 주소는 이 경우 프로토콜 사망 선고가 된다. 그래서 업그레이드 가능한 프록시 + 폴백 오라클이 필수 패턴이 되었다.

11. 🛠️ 실무 체크리스트: 개발자를 위한 방어 설계

여기까지 읽고 "그럼 오라클 쓰지 말아야 하나"라고 생각하면 곤란하다. 오라클은 필수 인프라다. 문제는 쓰는 방법이다. 아래는 실제 감사 기관들이 공통적으로 요구하는 항목을 정리한 것이다.

// 이중 오라클 + 편차 검사 패턴 (개념 코드)
function getPrice(address asset) internal view returns (uint256) {
    uint256 primary   = _read(primaryFeed[asset]);
    uint256 secondary = _read(fallbackFeed[asset]);

    uint256 diff = primary > secondary
        ? primary - secondary
        : secondary - primary;

    // 두 오라클 편차가 2% 초과 → 신뢰 불가로 판단하고 revert
    require(diff * 10_000 / primary <= 200, "ORACLE_DIVERGENCE");

    // 담보 평가는 보수적으로 (낮은 값), 부채 평가는 높은 값
    return primary < secondary ? primary : secondary;
}

마지막 줄의 비대칭 보수주의는 실무에서 대단히 중요하다. 담보는 낮게, 부채는 높게 평가하면 오라클 오차가 생겨도 손실이 프로토콜이 아니라 사용자 여유분에서 흡수된다.

12. 🔭 오라클의 미래: 한계를 '옮기는' 기술들

① TEE(신뢰 실행 환경) 기반 오라클

Intel SGX 같은 하드웨어 격리 영역에서 데이터를 처리하고 원격 증명(remote attestation)을 제공하는 방식. 실행 무결성을 하드웨어로 보증한다. 다만 하드웨어 제조사를 신뢰해야 하고, SGX는 다수의 사이드채널 취약점이 학계에서 반복 보고됐다. 신뢰의 대상이 노드에서 칩 벤더로 이동한 것이다.

② zkTLS / 웹 증명(Web Proof)

내가 은행 웹사이트에 로그인해서 본 잔액이 진짜라는 것을, 은행의 협조 없이 증명한다. HTTPS 세션의 무결성을 MPC와 영지식증명으로 포장하는 기법이다. 개인 데이터를 온체인으로 가져오는(Proof of Personhood, 신용 점수, 항공 마일리지 등) 길을 열지만, 여전히 원본 서버가 거짓을 말하면 거짓이 증명된다.

③ AI 오라클과 새로운 유형의 불확실성

최근 등장한 흥미로운 흐름은 LLM을 판정자로 쓰는 오라클이다. "이 이미지가 규정을 위반했는가?"를 여러 모델에 물어 합의를 내는 방식이다. 하지만 이건 결정론과 정면 충돌한다. 동일 프롬프트에 동일 답을 보장할 수 없는 시스템을, 동일 결과를 요구하는 시스템에 연결하는 일이다. 온도(temperature) 0 고정, 시드 고정, 다수 모델 투표 같은 기법이 시도되지만, 근본적 긴장은 남는다.

④ 재담보(Restaking) 기반 경제적 보안

이더리움에 이미 스테이킹된 자본을 오라클 서비스의 담보로 재활용해, 공격 비용 부등식의 우변을 키우는 접근이다. 자본 효율은 좋아지지만 상관된 실패(correlated slashing) 리스크라는 새로운 시스템 리스크를 만든다.

13. 📚 학습 로드맵 & 마무리

오라클을 제대로 다루려면 세 종류의 근육이 필요하다.

🔧 엔지니어링 Solidity 인터페이스, 가스 최적화, 프록시 업그레이드 패턴
📈 금융공학 유동성·슬리피지·TWAP·청산 메커니즘 이해
🎲 게임이론 인센티브 설계, 담합 비용 계산, 슬래싱 파라미터 튜닝

이 세 가지가 교차하는 지점이 오라클 설계다. 그래서 오라클은 블록체인 개발에서 가장 학제적이고, 가장 사고가 잦으며, 가장 저평가된 영역이다.

실제로 스마트 컨트랙트 보안 감사 수요에서 오라클 관련 이슈는 꾸준히 상위권을 차지한다. 재능넷의 '지식인의 숲'에 이런 심화 주제를 정리해두는 이유도 여기에 있다. 코드 한 줄을 배우는 것보다, "내 프로토콜이 무엇을 신뢰하고 있는가"를 스스로 목록화할 수 있는 능력이 훨씬 오래 남는다.

한 문장 요약 8개

오라클을 이해하면 Web3의 절반이 보인다. 나머지 절반은 "그 데이터를 믿고 무엇을 할 것인가"라는, 훨씬 인간적인 질문이다. 🌱