실시간 시세·기술적분석 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코인 캐시).
실시간 시세·기술적분석 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(요청 과다)로 죽었다 — 설계는 정상과 저하를 둘 다 견딘다. 그게 회고의 핵심이다.
| 지표 | 실측값 |
|---|---|
| 수집 코인(crypto MCP) | 716 개 |
| 데이터 소스 | 3 개 |
- 표본
- 실측 지표 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로 메운다. 그래서 게이트웨이가 통화·필드를 정규화해 호출자에게 빈칸을 안 넘긴다.
| 소스 | 코인 수 | 우리 운영 |
|---|---|---|
| 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로 확인하라(여기 수치는 출발점). 투자 조언 아님. 데이터·소스는 빠르게 바뀌니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.