오라클 데이터 피드는 보통 이전 보고 가격에서 정해진 비율 이상 움직이는 deviation threshold 또는 최대 대기 시간인 heartbeat가 충족되면 새 라운드를 온체인에 전송합니다. 갱신이 없다는 사실이 가격이 틀렸다는 뜻은 아니지만 소비자는 updatedAt과 허용 지연을 비교하고 answer 범위와 decimals를 검증해야 합니다. heartbeat는 보장된 정확도나 정확한 주기 타이머가 아니라 갱신 정책의 상한 기준입니다.
두 조건 중 먼저 충족된 쪽이 갱신을 촉발한다
Chainlink 문서는 데이터 피드가 deviation threshold와 heartbeat라는 두 트리거를 사용한다고 설명합니다. 시장 가격이 마지막 온체인 answer에서 설정 비율 이상 움직이면 편차 조건이 작동하고, 움직임이 작아도 heartbeat 시간이 지나면 새 보고가 전송될 수 있습니다.
예를 들어 마지막 가격이 100이고 편차 기준이 1%라면 관측 가격이 약 101 또는 99 경계를 넘는 상황이 가격 트리거가 될 수 있습니다. 가격이 100.4 부근에서 머물러도 heartbeat가 1시간이라면 시간 조건으로 갱신을 기대합니다. 실제 파라미터는 피드·네트워크별 공식 목록에서 확인해야 합니다.
| 상황 | 편차 조건 | heartbeat 조건 | 해석 |
|---|---|---|---|
| 100→102, 1% 기준 | 충족 | 미도달 가능 | 편차 갱신 |
| 100→100.2, 1시간 경과 | 미충족 | 충족 | 시간 갱신 |
| 100→100.2, 10분 경과 | 미충족 | 미충족 | 기존 라운드 유지 가능 |
| 조건 충족 후 혼잡 | 충족 | 충족 가능 | 온체인 반영 지연 가능 |
heartbeat는 매초 정확히 실행되는 타이머가 아니다
heartbeat를 1시간이라고 해서 updatedAt 간격이 항상 정확히 3,600초라는 뜻은 아닙니다. 오프체인 관측, 보고 합의, 트랜잭션 제출과 블록 포함 과정이 있습니다. 반대로 편차 조건이 먼저 충족되면 heartbeat보다 빠르게 새 라운드가 생깁니다.
소비자 계약은 문서의 heartbeat 숫자를 그대로 신뢰하기보다 block.timestamp – updatedAt이 애플리케이션 허용 한도 안인지 검사합니다. 담보 청산처럼 민감한 기능과 단순 화면 표시는 필요한 신선도가 다릅니다. 허용 지연을 너무 짧게 두면 정상 혼잡에도 서비스가 멈추고 너무 길게 두면 오래된 가격을 사용합니다.
갱신 정책과 애플리케이션의 허용 지연은 같은 숫자일 필요가 없다.
JOBCOIN 해설
latestRoundData의 다섯 값을 함께 읽는다
AggregatorV3Interface의 latestRoundData는 roundId, answer, startedAt, updatedAt, answeredInRound를 반환합니다. answer는 decimals를 적용해 사람이 읽는 가격으로 바꾸고, updatedAt이 0이 아닌지와 현재 시각과의 차이를 확인합니다. 음수나 0이 허용되지 않는 가격 피드라면 answer 범위도 검사합니다.
과거 소비 코드에서는 answeredInRound가 roundId보다 작지 않은지 확인하는 패턴이 쓰였습니다. 프록시와 피드 버전에 따라 round 표현이 달라질 수 있으므로 공식 API 설명을 따릅니다. description과 decimals, feed contract 주소를 배포 시 고정하고 변경 절차를 관리합니다.
- 공식 주소 목록에서 체인·자산쌍·피드 주소를 확인한다.
- decimals로 answer 단위를 변환한다.
- updatedAt과 현재 시각의 차이를 허용 지연과 비교한다.
- 가격 범위·round 상태·fallback 동작을 함께 검사한다.
편차는 마지막 보고값을 기준으로 읽는다
편차 비율은 일반적으로 새로 관측한 가격과 마지막 온체인 보고값의 차이를 기준으로 판단합니다. 1%라는 숫자가 매 순간 실제 시장가와 1% 이내임을 보증하는 오차 한계는 아닙니다. 데이터 소스 집계, 시장 단절, 보고 지연이 별도로 존재합니다.
가격이 경계 근처에서 움직이면 여러 갱신이 발생할 수 있고, 가격이 급격히 뛰면 다음 라운드가 큰 간격으로 나타날 수 있습니다. 청산 로직은 단일 라운드 변화만 보고 안전하다고 가정하지 말고 circuit breaker, 최대 변화율, pause와 수동 복구 절차를 설계합니다.
피드마다 heartbeat와 편차가 다르다
거래량이 큰 주요 자산과 유동성이 낮은 자산, L1과 L2의 피드는 서로 다른 설정을 가질 수 있습니다. 같은 ETH/USD 이름이라도 체인별 proxy 주소와 aggregator가 다를 수 있습니다. 다른 블로그의 숫자를 복사하지 말고 Chainlink 공식 feed 페이지의 현재 설정을 배포 구성에 기록합니다.
프록시가 새 aggregator로 교체되면 파라미터와 라운드가 달라질 수 있습니다. FeedConfirmed나 프록시 소유자 이벤트를 감시하고 변경 뒤 decimals·description·heartbeat를 재확인합니다. 최신 설정은 시간에 따라 바뀔 수 있으므로 코드 상수와 운영 문서를 같이 갱신합니다.
오라클 장애 때 무엇을 멈출지 미리 정한다
stale price를 발견했을 때 청산만 막고 상환은 허용할지, 신규 대출과 인출을 모두 중단할지 프로토콜 위험에 맞춰 정합니다. fallback 피드를 쓰면 가격 기준·decimals·갱신 시각이 호환되는지 검증합니다. 임의의 DEX spot 가격을 즉시 대체값으로 쓰면 조작 위험이 커질 수 있습니다.
모니터링은 answer 변화뿐 아니라 updatedAt 지연, 트랜잭션 실패, feed 주소 변경을 감시합니다. 테스트에서는 편차 미달 장시간, 급격한 가격 이동, heartbeat 초과, 음수 answer, sequencer 중단을 각각 시뮬레이션합니다. 화면에는 마지막 갱신 시각과 데이터 출처를 함께 표시합니다.
자주 묻는 질문
heartbeat가 1시간이면 가격은 정확히 매시간 갱신되나요?
아닙니다. 편차 조건으로 더 빨리 갱신될 수 있고 보고·네트워크 과정으로 온체인 반영이 늦을 수 있습니다.
편차 기준 1%면 시장가와 항상 1% 이내인가요?
아닙니다. 마지막 보고값 대비 갱신 트리거이며 데이터 집계와 전송 지연까지 포함한 정확도 보장은 아닙니다.
answer만 읽으면 충분한가요?
decimals, updatedAt, round 상태, 허용 가격 범위와 공식 feed 주소를 함께 검증해야 합니다.
