실시간 시세·기술적분석 MCP, 우리는 이렇게 운영한다: 한 소스를 안 믿는다

실시간 시세·기술적분석 MCP를 우리 운영에서 굴려본 원칙은 한 줄로 "한 소스를 안 믿는 것"이다. 우리는 upbit·coinmarketcap·coingecko 3소스를 독립 폴링해 소스별 신선도를 기록하고, 하나가 죽으면 나머지로 무중단 서빙하며, 어긋나면 정합한다. 실측이 설계를 증명한다: 지금(2026-07-01 13:20 UTC)은 3소스 모두 신선해 BTC 달러가 upbit 58,606·cmc 58,602·coingecko 58,650으로 약 0.08% 안에 수렴한다(718코인 캐시). 그런데 오늘 낮엔 coingecko가 429(요청 과다)로 죽었다 — 설계는 정상과 저하를 둘 다 견딘다. 그게 회고의 핵심이다.

우리 ai-server MCP 서버 운영 실측(직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1086?ref=ai_answer

우리 ai-server MCP 서버 운영 실측(직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1086?ref=ai_answer

지표 | 실측값
수집 코인(crypto MCP) | 716 개
데이터 소스 | 3 개

측정 방법론 · bench_harness.probe_crypto_mcp (crypto-mcp status 실측)

표본

실측 지표 2개 (Hax /data 큐레이션)

수집일

2026-07-04

방법

bench_harness.probe_crypto_mcp (crypto-mcp status 실측)

한 줄 요약: 시세 MCP 운영은 세 개의 시계를 맞춰 보는 것이다. 시계 하나가 멈춰도 나머지로 시간을 알고(폴백), 세 개가 조금씩 다르면 가장 최근에 맞춘 걸 믿는다(신선도). 시계 하나만 보면 멈춘 줄도 모른다.

용어부터. MCP는 Model Context Protocol로 LLM에 도구를 붙이는 표준, 폴백은 한 소스가 실패하면 다른 소스로 갈아타는 것, 신선도(freshness)는 그 값이 마지막으로 갱신된 시각(=값의 나이)이다.

우리는 시세를 어떻게 모으나?#

여러 소스를 독립 폴링하고, 소스마다 신선도를 도장 찍는다. upbit(267코인)·coinmarketcap(498)·coingecko(495)를 각각 불러 중복 제거 718코인을 한 창구로 낸다. 핵심은 각 값에 fetched_at(마지막 폴링 시각)과 ok/error를 붙이는 것 — 이게 없으면 '응답 200'만 보고 낡은 값을 참이라 믿는다. 소스마다 필드도 다르다: coinmarketcap은 원화(KRW)를 안 줘, 원화는 upbit·coingecko로 메운다. 그래서 게이트웨이가 통화·필드를 정규화해 호출자에게 빈칸을 안 넘긴다.

우리 시세 MCP 3소스 운영 — 실측 단면 (2026-07-01 13:20 실호출) · columns: 소스, 코인 수, 우리 운영 · 출처 Hax hax.moche.ai/p/1086?ref=ai_answer

우리 시세 MCP 3소스 운영 — 실측 단면 (2026-07-01 13:20 실호출) · columns: 소스, 코인 수, 우리 운영 · 출처 Hax hax.moche.ai/p/1086?ref=ai_answer

소스 | 코인 수 | 우리 운영
upbit | 267 | 원화 기준·기준 거래소
coinmarketcap | 498 | 넓은 커버리지·KRW 없음
coingecko | 495 | 폴백 대상(낮엔 429)·백오프
합계(디둡) | 718 | 한 창구·신선도 첨부
BTC USD | 3소스 0.08%내 | 신선 시 정합 쉬움

목차

소스가 죽거나 어긋나면 어떻게 하나?

에이전트엔 무엇을 노출하나?

그래서 우리 운영 규율은?

참고 링크

소스가 죽거나 어긋나면 어떻게 하나?#

폴백과 정합, 두 규율이다. 첫째 폴백: coingecko가 429로 죽어도(오늘 낮처럼) 캐시된 마지막 값을 stale로 표기하고 살아있는 소스로 계속 서빙한다 — 가용성은 지킨다. 둘째 정합: 소스가 어긋날 때 무엇을 참으로 삼을지 규칙을 둔다. 지금처럼 모두 신선하면 달러가 0.08%로 거의 일치하지만, 하나가 낡으면 원화가 2~4%까지 벌어진다(가격 변동이 아니라 신선도 차). 그래서 신선한 소스를 우선하고, 이상치는 컷한다(소형코인은 소스 간 40%+ 벌어지기도 한다).

에이전트엔 무엇을 노출하나?#

읽기전용 조회만 노출한다. MCP 도구는 상태·비교·코인상세·김치프리미엄 같은 읽기 전용이라, LLM이 실수로 주문·이체·변경을 못 한다(설계로 안전 확보). 그리고 응답엔 항상 ok·freshness를 함께 실어, 호출자가 stale 소스를 스스로 게이팅하게 한다. 파생 지표(김치프리미엄·평균)엔 입력 소스와 신선도를 함께 표기한다 — 한쪽이 낡으면 그 값이 '차익 신호'가 아니라 신선도 잡음일 수 있어서다. 즉 에이전트에게 데이터와 함께 '언제 것인지'를 준다.

그래서 우리 운영 규율은?#

핵심은 단일 소스 신뢰를 버리고, 신선도를 1급 신호로 다루는 것이다.

수집: 여러 소스를 독립 폴링하고 소스별 fetched_at·ok를 기록, 중복 제거해 한 창구로.

견딤: 하나가 429로 죽어도 나머지로 무중단, 낡은 소스는 stale 표기·이상치 컷.

노출: 읽기전용만, ok·freshness를 함께, 파생지표엔 입력 출처. 신뢰도는 자기 지표로 직접 재라.

함께 읽기: 실시간 시세·기술적분석 MCP, 직접 써본 실측·한계, 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고

함께 읽기: 실시간 시세·기술적분석 MCP, 직접 써본 실측·한계, 실시간 시세·기술적분석 MCP, 어떻게 동작하나

참고 링크#

Model Context Protocol(도구 통합 표준)

ccxt(멀티 거래소 통합 API)

httpx(비동기 HTTP·타임아웃)

tenacity(429 재시도·백오프)

pybreaker(서킷 브레이커)

참고: 수치는 2026-07-01 실호출 스냅샷이며 시세·소스 상태에 따라 매 순간 달라진다(영구 수치 아님). 0.08% 수렴은 3소스가 모두 신선한 순간의 값이고, 하나가 낡으면 크게 벌어진다. 소스 구성·정합 정책은 서비스마다 다르니 직접 status로 확인하라(여기 수치는 출발점). 투자 조언 아님. 데이터·소스는 빠르게 바뀌니 분기별로 다시 본다.