Naly 엔지니어링 노트: 재현 가능한 시장 스냅샷 계층으로서의 Polymarket Gamma

요약Polymarket Gamma 수집은 Naly에 예측시장 이벤트, 시장, 결과, 가격, 태그, 정산 메타데이터에 대한 공개적이고 구조화된 보기를 제공한다. Naly는 이 계층을 사용해 기사 후보를 선택하고, 오가격 라운드업의 근거를 세우며, KBO 예측 스토리를 지원하고, 출처 인용을 보존하며, 사후 검증을 위한 지속 가능한 시장 스냅샷을 만든다. 엔지니어링 주장은 단순하다. 편집 신뢰는 생성된 문장이 아니라 재현 가능한 시장 입력값에서 시작한다.

초록

Polymarket Gamma API는 거래 인터페이스가 아니라 Naly의 시장 발견 및 메타데이터 소스로 다뤄야 한다. 공식 Polymarket 문서는 Gamma를 Data 및 CLOB API와 구분한다. Gamma는 이벤트, 시장, 태그, 시리즈, 스포츠 메타데이터, 검색, 댓글, 공개 프로필을 다루는 반면, CLOB는 주문장, 가격, 스프레드, 인증된 거래 작업을 처리한다. Naly 기사에는 이 경계가 유용하다. 대부분의 편집 워크플로는 틱 단위 주문장 세부정보보다 먼저 질문 텍스트, 시장 식별자, 결과 라벨, 표시 확률, 카테고리 태그, 마감일, 정산 맥락을 필요로 한다.

이 노트의 논지는 Naly가 Gamma를 버전 관리되는 시장 스냅샷 계층으로 수집해야 한다는 것이다. 스냅샷은 진실이 아니다. 특정 시점에 관찰된 공개 시장 상태이며, 출처 URL에 연결되고 원시 페이로드가 보존된 것이다. 이를 통해 Naly는 다른 곳이 숨기는 것, 즉 시장 맥락, 신호의 한계, 기사가 생성될 때 사용된 정확한 증거를 공개할 수 있다.

Naly에서의 위치

Gamma 수집은 기사 생성 이전, 외부 출처 발견 이후에 위치한다. Naly의 게시 경로에서 이는 다음 네 가지 후속 용도를 위한 증거 묶음의 예측시장 측면을 제공한다.

오가격 라운드업에는 출처 기반 추론과 시장 내재 확률을 비교할 수 있을 만큼 충분한 메타데이터가 포함된 현재 이벤트 및 시장 후보가 필요하다.
KBO 예측 기사에는 직접 시장 맥락을 입력하지 않고도 렌더링할 수 있는 스포츠 시장, 팀 또는 이벤트 태그, 이벤트 마감일, 결과 라벨이 필요하다.
출처 인용에는 독자가 해당 기사가 특정 계약을 다룬 이유를 감사할 수 있도록 안정적인 시장 URL, 이벤트 슬러그, 시장 식별자가 필요하다.
예측 검증에는 나중의 정산을 Naly가 게시 시점에 실제로 본 확률과 비교해 채점할 수 있도록 과거 스냅샷이 필요하다.

로컬 런타임 사실은 새로움보다 구조에 더 중요하다. TypeScript 5.9와 tsx 는 수집 스크립트에 합리적으로 적합하고; drizzle-orm 와 함께 @neondatabase/serverless 는 정규화된 레코드와 원시 JSON을 저장할 수 있으며; Next.js 16과 React 19는 결과 기사 페이지를 렌더링할 수 있고; ai 및 Claude SDK 패키지는 수집이 시장 상태를 명시적으로 만든 뒤에야 준비된 증거 묶음을 사용할 수 있다.

기술적 메커니즘

견고한 Gamma 수집 루프에는 여섯 단계가 있다.

발견. Naly가 광범위한 활성 시장 발견이 필요할 때는 Gamma 이벤트를 사용하고, 기사가 알려진 Polymarket URL에 고정되어 있을 때는 시장 또는 이벤트 슬러그를 사용한다. Polymarket의 시장 데이터 가이드는 완전한 활성 발견에는 이벤트 사용을 권장한다. 이벤트가 관련 시장을 포함해 API 호출을 줄이기 때문이다. 스포츠 같은 카테고리 작업에서는 후보 순위를 매기기 전에 태그와 스포츠 메타데이터로 크롤링 범위를 좁혀야 한다.
페이지네이션. Gamma는 오프셋 방식 엔드포인트와 키셋 엔드포인트를 모두 지원한다. 대규모 또는 반복 크롤링에서는 키셋 페이지네이션이 더 안전하다. 그 이유는 next_cursor 가 continuation token이 되고 offset 는 키셋 markets 엔드포인트에서 명시적으로 거부되기 때문이다. 더 작은 타깃 기사 작업에서는 쿼리 범위가 좁고 출력이 즉시 스냅샷으로 저장된다면 오프셋 페이지네이션도 여전히 허용될 수 있다.
정규화. 핵심 정규화 규칙은 결과 라벨과 결과 가격을 위치 기준으로 매핑해야 한다는 것이다. Polymarket의 시장 데이터 개요는 outcomes 및 outcomePrices 배열을 일대일 배열로 문서화하므로 인덱스 규율이 중요하다. 배열이 뒤바뀌는 것은 외관상의 버그가 아니다. 기사의 시장 해석을 반대로 만든다.
스냅샷화. 정규화된 열과 원시 JSON을 모두 저장한다. 정규화된 열에는 제공자, 가져온 타임스탬프, 이벤트 id 또는 슬러그, 시장 id 또는 슬러그, 질문 텍스트, 존재할 경우 condition id, 존재할 경우 token 식별자, 결과 라벨, 결과 가격, 활성 및 종료 플래그, 종료 시각, 태그, 출처 URL, 페이로드 해시가 포함되어야 한다. 원시 JSON은 Naly를 스키마 드리프트로부터 보호하고, 검증이 정확한 수집 산출물을 재생할 수 있게 한다.
후보 채점. 기사 작업은 거래 실행 기준이 아니라 편집 기준으로 시장 순위를 매겨야 한다. 신선도, 사용 가능한 경우 거래량 또는 유동성, 정산 근접성, 출처 가용성, 카테고리 적합성, 독자에게 명확한 대비를 만들어낼 수 있는지 여부가 기준이다. 후보 채점은 시장 가격이 자동으로 틀렸다는 뜻을 절대 암시해서는 안 된다. 연구할 가치가 있는 시장으로 표시해야 한다.
게시 바인딩. 생성된 기사가 시장을 인용할 때, 기사는 저장된 스냅샷 id, Polymarket 출처 URL, 작성자가 사용한 외부 증거 세트에 연결되어야 한다. 이것이 시장이 62 percent였다고 말하는 페이지와 그 값이 언제, 어디서, 어떤 페이로드에서 나왔는지 증명할 수 있는 페이지의 차이다.

레이트 리밋은 메커니즘의 일부다. Polymarket은 Cloudflare가 적용하는 스로틀링과 다음에 대한 특정 Gamma 제한을 문서화한다. /events, /markets, /tags, 및 /public-search. Naly는 일일 게시를 위해 그 한도에 접근할 필요가 없으므로 올바른 태도는 보수적이어야 한다. 제한된 동시성, 지터를 포함한 재시도, 멱등성과 재생을 위한 페이로드 해시, 작업이 스로틀링되거나 비어 있거나 구조적으로 예상과 다른 응답을 받을 때의 알림이 필요하다.

문헌이 말하는 것

최근 arXiv 연구는 스냅샷 우선 설계를 뒷받침한다. Jia et al.은 탈중앙화 예측시장 데이터가 오프체인 메타데이터, 체결 수준 거래 기록, 오라클 정산 이벤트 전반에 파편화되어 있다고 설명한 뒤, 식별자 해석, 증분 업데이트, 일관성 메커니즘을 갖춘 통합 관계형 시스템을 주장한다. Naly의 더 작은 게시 시스템도 같은 종류의 문제를 갖고 있다. 나중에 가격, 기사 주장, 정산 결과와 조인할 수 없다면 시장 메타데이터만으로는 충분하지 않다.

Le의 보정 연구는 기사 언어와 직접 관련이 있다. 대규모 Kalshi 및 Polymarket 데이터셋을 사용한 이 논문은 보정이 도메인, 기간, 거래 규모 효과에 따라 달라지며, 가격을 액면 그대로의 확률로 받아들이는 소비자는 이를 체계적으로 오해할 수 있다고 주장한다. Naly에게 이는 기사가 진실이 아니라 시장 내재 확률, 관찰된 가격, 또는 공개 시장 신호라고 말해야 한다는 뜻이다. 기사는 원시 시장 관찰값을 Naly의 모델 또는 출처 기반 추론과 분리한 뒤에야 가능한 오가격을 논의할 수 있다.

Dubach의 Polymarket 미시구조 논문은 주로 주문장 데이터에 관한 것이지만, 수집 설계에 유용한 경고를 준다. 고빈도 시장 증거에는 출처별 오류 모드, 수집 지연, 중요한 조인이 있다. Gamma는 주문장 피드보다 덜 세분화되어 있지만 같은 원칙이 적용된다. 숫자의 출처는 보여야 한다. Gamma 스냅샷, CLOB 중간값, 온체인 거래 기록은 관련되어 있지만 서로 바꿔 쓸 수 없다.

Madrigal-Cianci, Monsalve Maya, and Breakey는 예측시장을 관찰된 확률과 거래량 이력이 잡음이 많고, 내생적이며, 이질적인 거래자 유형에 의해 형성되는 베이지안 역문제로 규정한다. 이는 Naly의 편집 입장을 강화한다. 수집된 시장 상태는 증거이지 판결이 아니다. 좋은 엔지니어링은 그 불확실성을 생성 과정에서 지워 버리지 않고 검사 가능하게 만든다.

설계 트레이드오프

Gamma와 CLOB의 선택이 첫 번째 트레이드오프다. Gamma는 Naly에 발견 가능성, 기사 맥락, 메타데이터를 제공한다. CLOB는 더 정밀한 가격 책정과 주문장 메커니즘을 제공한다. 일일 엔지니어링 기사와 예측시장 라운드업에서는 Gamma가 시장이 무엇에 관한 것인지 답해 주기 때문에 기본 입력값이어야 한다. 기사가 스프레드, 중간값, 가격 이력의 정밀성을 필요로 할 때 CLOB를 추가할 수 있다.

이벤트 우선 수집과 시장 우선 수집이 두 번째 트레이드오프다. 이벤트 우선은 하나의 이벤트가 여러 시장과 공유 메타데이터를 포함할 수 있어 광범위한 스캔에 더 저렴하다. 시장 우선은 최종 점수가 특정 이진 결과에 붙기 때문에 검증에는 더 깔끔하다. Naly는 두 형태를 모두 수집하되, 단일 결과를 평가할 때는 기사 링크가 시장 수준의 주장으로 향하게 해야 한다.

원시 JSON과 타입 지정 스키마가 세 번째 트레이드오프다. 원시 JSON만 저장하기는 쉽지만 안전하게 쿼리하기 어렵다. 타입 지정 열만 있으면 쿼리는 쉽지만 제공자 필드가 진화할 때 취약하다. 지속 가능한 패턴은 둘 다 갖추는 것이다. 순위 지정, 렌더링, 조인을 위한 타입 지정 필드와 감사, 재생, 마이그레이션을 위한 원시 페이로드가 필요하다.

실시간 렌더링과 고정 렌더링이 네 번째 트레이드오프다. 실시간 시장 위젯은 유용할 수 있지만, 기사 주장은 게시 시점 스냅샷에 바인딩되어야 한다. 그렇지 않으면 Polymarket이 시장을 움직이거나 닫거나 정산할 때 오래된 기사의 의미가 조용히 바뀔 수 있다. Naly의 신뢰 전략에서는 페이지가 날짜가 있는 주장을 할 때 신선도보다 고정된 증거가 낫다.

실패 모드

가장 위험한 실패는 결과-가격 불일치다. Yes 및 No 라벨이 가격과 별도로 파싱되면, 기사는 그럴듯해 보이면서도 신호를 반대로 뒤집을 수 있다.

두 번째 실패는 오래된 시장 재사용이다. 어떤 시장은 발견 시점에는 활성 상태였다가 게시 시점에는 종료될 수 있다. 각 기사 작업은 스냅샷을 바인딩하기 직전에 active, closed, archived, end-time 필드를 다시 검증해야 한다.

세 번째 실패는 다중 시장 모호성이다. 하나의 Polymarket 이벤트는 여러 거래 가능한 시장을 포함할 수 있다. 라운드업은 이벤트를 인용할 수 있지만, 검증 기록은 Naly가 평가한 특정 시장과 결과를 인용해야 한다.

네 번째 실패는 스키마 드리프트다. 공개 API는 필드명, 기본값, 중첩 관계를 바꾼다. 스냅샷 저장에는 드리프트가 관찰 가능하도록 페이로드 해시, 파서 버전, 제공자 URL, 검증 오류가 포함되어야 한다.

다섯 번째 실패는 보정을 과장하는 것이다. 시장 가격은 유용한 공개 신호지만, 문헌은 이를 모든 도메인과 기간에 걸친 깨끗한 확률로 다루지 말라고 경고한다. Naly의 문구는 시장 내재 확률, Naly 추정치, 실현 결과의 차이를 보존해야 한다.

여섯 번째 실패는 인용 손실이다. 기사가 렌더링된 마크다운만 저장한다면, 나중의 검증은 어떤 시장 페이지와 페이로드가 그 주장을 뒷받침했는지 증명할 수 없다. 기사-시장 조인은 내장된 산문이 아니라 일급 레코드여야 한다.

구현 노트

실용적인 Naly 구현은 수집 계약을 작게 유지할 수 있다.

provider: polymarket-gamma.
provider_url: 발견에 사용된 정확한 Gamma 엔드포인트 또는 공개 시장 URL.
fetched_at: UTC 기준 서버 타임스탬프.
event_key 및 market_key: 안정적인 제공자 식별자 또는 슬러그.
question: 표준 시장 질문 텍스트.
outcomes: 정렬된 라벨.
outcome_prices: 검증 후에만 숫자 값으로 정규화되는 정렬된 소수 문자열.
status: active, closed, archived, publishability 플래그.
raw_payload: 전체 제공자 응답.
payload_hash: 멱등성과 재생을 위한 결정적 해시.
parser_version: 페이로드를 해석한 코드 계약.

기사 생성기는 이를 느슨한 프롬프트 텍스트가 아니라 구조화된 증거로 받아야 한다. 그런 다음 기존 AI 스택을 통해 마크다운을 만들고, 사이트 파이프라인으로 렌더링하며, 인용을 출처 레코드에 연결된 상태로 유지할 수 있다. 검증 워커는 나중에 기사의 시장 스냅샷을 정산 데이터와 조인해 게시된 주장이 시간이 지나도 잘 유지됐는지 채점할 수 있다.

엔지니어링 원칙은 의도적으로 보수적이다. 수집하고, 정규화하고, 스냅샷으로 저장하고, 인용한 다음, 쓴다. 이 순서는 모델에게 시장 페이지를 탐색하고 요약하라고 요청하는 것보다 느리지만, Naly가 실제로 사용자 확보와 유지에 필요한 산출물을 만든다. 결과가 알려진 뒤에도 시장 증거를 재생할 수 있는 공개 기사다.