요약Naly는 Polymarket의 Gamma API를 예측 시장 워크플로우 전반에 대해 결정론적 발견·가격 산출 기반으로 사용하며, 임시 뉴스 스크랩 대신 구조화된 시장 엔티티로 교체합니다. 각 주기마다 실시간 이벤트와 시장을 기사용 신호로 변환해 가격 왜곡 라운드업, KBO 프리뷰, 인용 묶음, 이후 결과 검증에 활용하므로 기사 생성은 추론된 의견이 아니라 공개적으로 관측 가능한 확률과 시장 구조에서 항상 시작됩니다.
초록
Naly는 예측 시장 데이터를 오버레이가 아니라 인프라로 취급하므로, 편집 산출물이 나중에 감사할 수 있는 외부 시장 상태에 직접 연결됩니다. Gamma API는 지갑 키 없이 이벤트, 시장, 태그, 가격을 읽을 수 있는 경로를 제공합니다. 설계 과제는 이 수집 계층을 안정성과 신뢰성 측면에서 엄격하게 유지하면서도 콘텐츠 팀의 빠른 주제 탐색 필요에 맞게 유연하게 만드는 것입니다.
Naly에서의 위치
Polymarket Gamma 수집은 원시 시장 프리미티브와 게시 가능한 편집 자산 사이의 상류 경계에 놓입니다. 더 넓은 파이프라인의 첫 단계입니다.
- 입력 레이어: Gamma에서 이벤트, 시장, 태그, 시장 상태를 가져옵니다.
- 해석 레이어: Naly의 내부 스키마로 정규화합니다 (
event_id,market_id, 토큰 ID, 결과, 확률, 타임스탬프, 활성/종료 플래그). - 서사 레이어: 정규화된 입력을 mispricing roundup 및 KBO 예측 초안 작성 흐름으로 전달합니다.
- 검증 레이어: 향후 기사 사실 확인 및 회고 스코어카드를 위해 해결되었거나 종료된 시장 상태를 유지합니다.
2026년 6월 10일 기준으로, 이는 신뢰 가능한 예측 근거를 필요로 하는 진행 중인 전술과 특히 일치합니다. 여기에는 예측 보정 가시성, 반복 가능한 콘텐츠 소싱, 이후 검증 워크플로우가 포함됩니다.
기술 메커니즘
Polymarket는 세 가지 API를 정의하며 Gamma를 이벤트/시장 탐색 및 메타데이터용 공개 디스커버리 플레인으로 두고, 주문장/거래형 데이터는 CLOB로, 사용자/포지션 데이터는 Data API로 제공합니다 (문서). Polymarket 문서에 따르면 Gamma와 Data는 공개 API이고, CLOB는 주문 조작에 인증이 필요한 비공개/트레이딩 표면을 보유합니다.
Naly는 공개 엔드포인트만으로도 견고한 일일 흐름을 구현할 수 있습니다.
- 활성 후보 시장 검색 를 통해
GET /events와active=true,closed=false, 페이지네이션 (limit,offset), 및 선택적 정렬 필터를 지원합니다. - 구성 시장 확장 이벤트 레벨 페이로드를 사용하며, 이벤트가 연계 시장을 포함하므로 개별 시장 조회 대비 API 호출을 줄일 수 있습니다.
- 정확한 대상 지정 알려진 이벤트 또는 시장이 이미 식별된 경우 슬러그 기반 호출을 사용합니다.
- 가격 정규화 다음을 매핑하여
outcomes와outcomePrices배열을 인덱스별로 이름이 붙은 확률로 매핑합니다. - 감사 산출물 보존 각 기사가 출처별 수치를 추적할 수 있도록 정규화된 행과 원본 스냅샷을 모두 저장합니다.
- 하류 생성 게이팅 신선도 + 스키마 검사에 따라 수행합니다. 오래되었거나 불완전한 스냅샷은 사용 전에 갱신 대상으로 표시됩니다.
Gamma 문서에는 바로 이러한 운영 형태가 설명되어 있습니다. 이벤트 탐색을 위한 공개 엔드포인트로는 /events, /markets, /public-search, /tags가 있으며, 페이지네이션과 필터링은 /series 를 통해 지원됩니다. 또한 관련 필터가 지원됩니다. limit/offset, tag_id가 제공됩니다. 또한 세 가지 직접 조회 패턴(슬러그 조회, 태그 기반 탐색, 넓은 범위 스캔을 위한 이벤트 열거)을 권장합니다. Naly의 경우 대량의 일일 후보군을 구성할 때 이벤트 우선 패턴이 가장 비용 효율적이며, 각 이벤트가 다수의 시장 레코드를 한꺼번에 노출할 수 있기 때문입니다.
실무적으로 Naly의 최소 진실 원본 레코드는 다음을 포함해야 합니다.
- 이벤트 및 시장 ID
- 시장
question clobTokenIds(필요 시 CLOB로 하류 가격 정합성 처리용)outcomes및outcomePricesenableOrderBookactive,closed와 시간 필드(시작/종료 타임스탬프)- 조회 시각 및 소스 URL
Gamma만으로도 강한 확률적 베이스라인을 제공할 수 있지만, 두 번째 정제 경로는 선택 사항입니다. Naly가 분 단위 단기 갱신을 필요로 할 때는 /price, /prices, 또는 /book 와 같은 CLOB 엔드포인트를 나중에 병합할 수 있습니다.
연구 동향
예측 시장에 대한 연구는 이러한 데이터 우선 접근을 지지하지만, 해석에 대한 가드레일을 추가합니다.
- 예측 시장의 시장 데이터 모델은 보정(calibration)과 올바른 해석이 보장될 때만 유효합니다. 가격은 맥락 없이 보편적 확률이 아닙니다. 2026년 연구에서 Polymarket와 Kalshi는 도메인 및 예측 지평별로 체계적인 보정 패턴이 있으며 일부 영역에서 측정 가능한 과소확신이 존재함을 보여줍니다.
- 또 다른 2026년 라이프사이클 중심 연구는 의미 있는 시장 분석에는 시장 메타데이터, 거래 이벤트, 정산 신호의 동기화된 다층 데이터 엔지니어링이 필요하며, 이를 위해 명시적 연동과 주기적 일관성 검사가 필요하다고 강조합니다.
- 이전의 시장 미시구조 연구는 연속 경매 형태의 흐름에서 시장 가격이 거래자 정보를 전달한다는 점을 보여줍니다. 따라서 Naly는 시장 가격을 집단 예측 신호로 사용할 수 있지만, 결과 검증은 시간축 상에서 지속해야 합니다.
- 시장 가격을 다른 방법(예: 설문 기반 예측)과 비교한 예측 문헌은, 결과 검증과 모델 규율이 유지될 때 예측 시장이 매우 강력하게 예측력을 가질 수 있다고 보여줍니다.
Naly에 대한 실무적 결론은 분명합니다. 근거가 있는 데이터는 모두 수집하고, 단일 가격 스냅샷을 최종 진실로 취급하지 않으며, readiness (데이터 최신성 + 무결성) story quality 을(를)
(편집적 구성)에서 분리합니다.
설계 트레이드오프
- Naly는 의도적으로 수집에서 속도보다 신뢰성을 우선 최적화합니다. Gamma 전용 vs Gamma+CLOB:
- Gamma는 안정적인 탐색과 공개 컨텍스트를 빠르게 제공하지만, CLOB를 추가하면 미시구조 정보가 풍부해지는 대신 인증 및 엔드포인트 복잡성이 증가합니다. 일일 스냅샷 vs 실시간 스트리밍:
- 결정론적 스케줄 풀은 실시간 스트리밍보다 감사와 재현이 쉽지만, 분 단위 미만의 국면 변화를 놓칠 수 있습니다. 이벤트 우선 풀 vs 시장 우선 풀:
- 이벤트 우선 방식은 중복 호출을 줄이고 맥락 커버리지를 개선합니다. 시장 우선은 좁은 작업에서 페이로드 크기가 약간 더 작습니다. 넓은 스키마 vs 엄격한 스키마:
- 넓은 JSON 우선 스키마는 통합이 빠르지만 스키마 드리프트 위험이 증가하며, 엄격한 정규화는 드리프트를 더 빨리 포착하지만 마이그레이션 오버헤드가 커집니다. 일반 필드 vs 도메인 특화 필드:
공유 필드를 사용하면 기사 전반의 재사용성이 향상되지만, 도메인 특화 확장(예: 스포츠별 신뢰도 창)을 추가하면 장기 유지보수에서 분절 위험이 커집니다.
즉시적인 선택은
Naly의 사용자 신뢰와 리텐션 목표를 고려할 때, 즉각적인 지연 최적화보다 엄격한 재현성 및 인용 품질이 우선해야 한다.
- 실패 모드 가장 큰 실패 모드는 알고리즘적이라기보다 운영적입니다.
limit페이지네이션 버그로 인한 데이터 누락:offset만약 - 와
closed=false윈도우가 폴링 간에 변경되면 중복 또는 누락이 발생할 수 있습니다. 완화: 페이지네이션 커서를 체크포인트 처리하고 멱등 업서트(idempotent upsert)를 강제합니다. 기본값closed=true과거 맥락 누락: - 오픈 마켓 조회는 이 명시적으로 요청되지 않는 한 해결된 항목을 제외합니다. 완화: 검증 작업을 위한 전용 과거 데이터 백필 경로를 실행합니다.
- 슬러그 불안정성:
outcomes상품 URL과 사람이 읽는 슬러그는 변경될 수 있습니다. 완화: 내부에서는 기본 ID를 우선 사용하고 슬러그는 보조 키로 보관합니다.outcomePrices의미 체계 필드 드리프트: - / 해석은 배열 순서 가정이 틀리면 깨질 수 있습니다. 완화: 수집 단계에서 배열 정렬 및 길이 검증을 강제합니다.
- 일시적 API 가용성 저하 또는 쓰로틀링: 공개 엔드포인트가 실패하거나 일부 페이로드만 반환할 수 있습니다. 완화: 지수적 백오프 재시도, 반복 실패 시 poison-queue 처리, 이전 스냅샷 유지.
지연 정산과 오래된 내러티브:
검증 기사는 정산이 완전히 완료되기 전에 작성될 수 있습니다. 완화: 게시 상태의 일부로 정산 상태를 저장하고, 불변 수정 로그로 사후 업데이트합니다.
Naly의 신뢰 우선 전략을 감안할 때 파이프라인은 닫힌 실패 모드로 동작해야 합니다. 검증 불가능한 시장 상태로 게시하는 것보다 기사를 지연 배포하는 것이 더 낫습니다.
- 구현 노트
next@16.0.7명시된 런타임 스택을 사용하면 실무적 구현은 여전히 직접적입니다. - Next.js 서버 핸들러(
drizzle-orm@^0.44.7)를 사용해 수집 엔드포인트와 스케줄 작업을 호스팅합니다.@neondatabase/serverless@^1.0.2정규화된 행을 Neon에 저장할 때 - 과
@vercel/blob@^2.0.0를 사용해 시장 식별자에 대한 명시적 고유 제약 조건을 둡니다. - 원본 페이로드 스냅샷은 감사 가능성과 사후 분석용 diff를 위해 Vercel Blob(
marked@^17.0.1)에 저장합니다.ai@6.0.0-beta.105마크다운 소스 생성과 기사 조립은 수집 핵심부 밖에서 수행하고, 안전한 변환은@anthropic-ai/claude-agent-sdk@^0.2.15와 - 을 거친 뒤 데이터 무결성 검사가 통과될 때만 진행합니다.
tsx@^4.21.0히스토리컬 구간을 백필할 때 재현 가능한 일회성 재실행을 위해typescript@^5.9.3를 사용합니다.
2026년 6월 10일 기준, 아키텍처는 다음 세 가지 결과물을 우선해야 합니다. 원본 스냅샷 불변성, 내부 스키마로의 결정론적 투영, 소스 API URL에서 최종 기사 인용까지 이어지는 검증 지향 감사 추적입니다.