데이터를 소비하는 것이 스마트컨트랙트일 때

체인 위의 데이터 — 3부작 중 2편 · ChainLab

1편에서 우리는 하나의 재정의에 도달했습니다. 블록체인은 데이터 저장을 파는 게 아니라 검증 가능성과 접근권을 판다는 것. 이제 한 가지만 바꿔봅시다. 구매자를 사람이 아니라 다른 스마트컨트랙트로 — 예를 들어 담보를 평가하려고 부동산 가격이 필요한 대출 프로토콜로. 설계의 모든 것이 달라지는데, 그 이유는 단 하나의 강한 제약입니다.

컨트랙트가 그냥 API를 못 부르는 이유

스마트컨트랙트는 HTTP 요청을 날릴 수 없습니다. 이건 빠진 기능이 아니라 의도된 설계이고, 그 뿌리는 결정론입니다.

블록체인은 수천 개 노드가 각자 같은 코드를 재실행해서 같은 결과에 도달해야 합의가 됩니다. 이제 컨트랙트가 실행 중에 https://api.example.com을 호출한다고 해봅시다. 도쿄 노드와 뉴욕 노드가 미묘하게 다른 순간에 호출해 다른 응답을 받습니다. 한쪽에서는 서버가 잠깐 멈추고 다른 쪽에서는 안 멈춥니다. 한 노드는 타임아웃되고 다른 노드는 성공합니다. 이제 노드들의 결과가 어긋나고 합의가 깨집니다. 그래서 EVM에는 네트워크로 나가는 opcode 자체가 없습니다. 컨트랙트는 이미 온체인에 올라온 state만 읽을 수 있고, 그건 모든 노드가 동일하게 갖고 있으니 결정론이 유지됩니다.

바로 이 제약이 오라클이 존재하는 이유입니다. 컨트랙트가 외부 데이터를 못 당기니까, 누군가 먼저 트랜잭션 안에서 그걸 온체인으로 밀어넣어야 합니다. 오라클이 그 다리이고, 유일한 다리입니다.

오프체인 접근이 막힌 건 컨트랙트 실행 구간뿐입니다. 그 주변 — 리포터 스크립트, 프런트엔드, 체인을 읽는 인덱서 — 은 전부 인터넷에 자유롭게 접근합니다. 벽은 한 방향이고, 그 벽을 통과하는 유일한 문이 트랜잭션입니다.

여기서 블록체인이 주는 것

컴포저빌리티. 가격이 일단 온체인에 오르면, 임의의 컨트랙트가 트랜잭션 안에서 그 값을 원자적으로 읽어 그 자리에서 로직을 실행합니다. 대출 프로토콜이 토큰화된 부동산 담보를 평가하고 같은 블록 안에서 청산까지 끝낼 수 있습니다. 오프체인 API는 온체인 원자적 트랜잭션에 결코 참여할 수 없습니다. 이게 오라클이 존재하는 이유 전부이자 가장 큰 장점입니다.

신뢰 최소화된 검증 가능한 출처. 누가 값을 보고했는지, 얼마나 자주 갱신되는지, 어떤 편차 임계치에서 푸시되는지 — 전부 온체인에 보입니다. 피드를 연동하는 프로토콜이 “이 값은 M-of-N 리포터가 서명했고 조작 흔적이 없다”를 스스로 검증할 수 있습니다. 블랙박스 API를 믿는 것과 근본적으로 다릅니다.

변조 불가능한 감사 추적. 모든 라운드가 영구히 남습니다. RWA나 규제 대상 담보에서는 “블록 N에서 오라클이 가격 P를 이 리포터들의 서명으로 보고했다”를 증명할 수 있다는 게 분쟁·정산에서 법적·운영적 무게를 갖습니다.

읽기 경로에 카운터파티 없음. 청산이 일어나는 순간 당신의 서버가 살아있을 필요가 없습니다. 값이 이미 state에 있으니까요. 소비자 컨트랙트는 당신 인프라의 가동 여부에 의존하지 않습니다.

아키텍처, 쉬운 말로

1. 오프체인 소스·모델. 원시 신고를 그대로 오라클에 넣으면 안 됩니다. 특정 단지는 이번 달 거래가 0건일 수 있어서 “최근 체결가”라는 개념 자체가 없을 때가 많죠. 그래서 오프체인에서 모델 출력을 만듭니다 — 비교거래 기반 시세 인덱스, hedonic 회귀, 감정가 블렌드. 오라클은 원시 거래가 아니라 이 산출값을 보고합니다. 여기가 실질적 부가가치이자 동시에 조작 표면입니다.

2. 리포터·서명 계층. 누가 값을 온체인에 증언하느냐가 신뢰 최소화의 핵심입니다. 단일 리포터는 간단하지만 신뢰를 한 곳에 몰아 취지를 무너뜨립니다. 제대로 하려면 — Chainlink의 OCR처럼 — 여러 독립 리포터가 각자 값을 EIP-712로 오프체인 서명하고, 값들을 오프체인에서 집계(예: 중앙값)한 뒤, 집계값과 N개 서명을 트랜잭션 하나로 제출합니다. 컨트랙트는 M-of-N 서명 쿼럼을 검증한 뒤에야 값을 받아들이므로, 어느 리포터도 단독으로 나쁜 값을 밀어넣을 수 없습니다.

3. 온체인 애그리게이터 컨트랙트. 현재값과 메타데이터를 저장하고, 기존 DeFi 통합과 호환되도록 latestRoundData() 형태로 노출합니다. 핵심 설계 요소: 소비자가 오래된 값을 거르도록 하는 staleness/heartbeat(updatedAt) — 부동산은 갱신이 느려 heartbeat가 일/주 단위일 테니 소비자가 그에 맞춰 임계치를 잡아야 합니다 — 그리고 값이 X% 이상 움직일 때만 푸시해 가스를 아끼는 deviation threshold, heartbeat를 하한으로.

4. 소비자 인터페이스. 대출·파생·RWA 컨트랙트가 애그리게이터를 읽으면서 통상의 latestRoundData() 안전장치를 적용합니다 — answer가 0보다 큰지, updatedAt이 너무 오래되지 않았는지, 라운드가 완결됐는지. 소비자 쪽이 마지막 방어선을 칩니다.

[ 오프체인: 인터넷 접근 자유 ]
  공공 API → 리포터 → 값 계산 + EIP-712 서명
                        │
                        ▼ 트랜잭션으로 밀어넣기
[ 온체인: 오직 체인 state, 외부 접근 불가 ]
  오라클 컨트랙트(값 저장) ──읽기──> 소비자 컨트랙트
                        ▲
  프런트엔드 / 인덱서 ──읽기─┘  (서버가 체인 읽는 건 언제나 자유)

부동산 오라클의 정직한 한계

장점만 부각하면 위험합니다. 부동산은 연속적인 스팟 시장이 없어서 크립토 자산보다 오라클 문제가 더 고약합니다. “진짜 가격”이 없고 모델 추정치뿐이라, 오라클은 오프체인 모델 품질만큼만 정확합니다. 블록체인은 소스 데이터의 질을 고쳐주지 못합니다(garbage in, garbage out). 또 갱신이 드물고 유동성이 없어서, 이 피드를 고빈도 레버리지의 청산 트리거로 쓰는 건 위험합니다. RWA 밸류에이션, 인덱스 상품, 장기 만기 정산처럼 천천히 움직이는 용도에 훨씬 맞습니다. 조작 표면은 체인이 아니라 오프체인 모델과 리포터 집합임을 기억하세요. 그래서 진짜 보안 작업은 리포터 탈중앙화와 방법론 투명화에 있습니다.

블록체인이 주는 것은 이것입니다. 부동산 가격을, 다른 컨트랙트가 원자적으로·검증 가능하게·당신을 신뢰하지 않고 소비할 수 있는 프로그래머블 프리미티브로 바꿔주는 것. 그 대가로 당신은 소스 데이터의 근본적 희소성과 모델 의존성을 그대로 떠안습니다. 3편은 이 모든 것 아래 깔린 질문으로 갑니다 — 무언가를 못 고친다는 사실이 언제 돈이 되는가?