코인 과거 시세 데이터 소급 한계 — 창구마다 다른 첫 기록 날짜와 한 번에 받아지는 개수

altnara 자금흐름 데스크는 시장 데이터가 어느 창구에서 어떤 모양으로 나오는지를 점검합니다. 이번 노트의 주제는 코인 과거 시세 데이터입니다. 운영자 보유 가능성: 본 매체는 비트코인·주요 알트 및 스테이블코인 보유 가능성을 명시합니다.

지나간 시세를 얼마나 멀리까지 받아 볼 수 있는지는 부르는 쪽이 정하는 값이 아닙니다. 창구가 남겨 둔 만큼만 옵니다. 그런데 이 한계는 오류 메시지로 알려 주지 않는 경우가 더 많습니다. 요청은 성공으로 끝나고, 응답도 정상적으로 생겼고, 다만 줄 수가 부족할 뿐입니다.

이 노트는 여섯 계열 창구에 비트코인 하루 단위 캔들을 요청해 더 이상 되감기지 않을 때까지 페이지를 넘겨 봤고, 같은 자리에서 한 번에 받아지는 줄 수의 한도도 함께 쟀습니다. 호출은 2026년 8월 15일 23시 58분에서 8월 16일 0시 15분(KST) 사이에 인증 없이 했습니다. 협정세계시로는 8월 15일 14시 58분에서 15시 15분입니다. 아래 표의 시각 값은 응답이 준 그대로 협정세계시로 적었습니다.

결론부터 — 이번 조회에서 갈라진 것은 세 가지입니다

첫째, 같은 비트코인인데 첫 기록 날짜가 창구마다 7년 6개월 넘게 갈렸습니다. 가장 멀리 되감긴 곳은 빗썸이었고 응답의 candle_date_time_utc 가 2013-12-26T15:00:00 이었습니다. 가장 가까운 곳은 바이비트 현물로 2021년 7월 5일이었습니다. 두 값 사이가 7년 6개월입니다. 비트코인이라는 자산의 나이가 창구마다 다를 수는 없으므로, 이 날짜는 자산이 아니라 그 창구의 사정을 말합니다.

둘째, 한 번에 받아지는 줄 수는 200·300·1000 세 값으로 갈렸습니다. 바이낸스와 바이비트가 1,000, OKX 가 300, 업비트와 빗썸이 200 이었습니다. 그래서 전 이력을 끝까지 되감는 데 든 요청 횟수도 갈렸습니다. 바이낸스는 3,286줄을 받는 데 4회, 업비트는 3,247줄에 17회, 빗썸은 4,525줄에 23회였습니다. 세 숫자는 받은 줄 수가 서로 다르므로 같은 작업량끼리의 비교가 아닙니다. 한도만 놓고 계산하면 3,000줄을 모으는 데는 바이낸스가 3회, 업비트와 빗썸이 각각 15회입니다.

셋째, 한도를 넘겨 넣어도 오류가 아니라 조용히 잘려서 옵니다. 다섯 창구에 한도보다 큰 값을 넣어 봤고 다섯 곳 모두 HTTP 200 으로 정상 응답했습니다. 잘렸다는 사실은 응답 어디에도 적혀 있지 않았고, 줄 수를 세어야만 보였습니다.

이 노트가 재는 자리와 재지 않는 자리

이 노트가 다루지 않는 자리를 먼저 네 개 적어 둡니다. 같은 주제어로 묶이기 쉬운 자리들이라 앞에서 갈라 둡니다.

첫째, 거래소마다 지금 가격이 다르게 찍히는 문제는 여기서 다루지 않습니다. 이 노트가 세는 것은 지금 값이 아니라 지나간 값이 몇 줄까지 남아 있는지입니다. 둘째, 입출금이 막히거나 늦어지는 문제도 다루지 않습니다. 여기서 부른 창구는 자금을 옮기는 자리가 아니라 조회만 하는 자리입니다. 셋째, 계정에 연결하는 인증 수단을 만드는 절차와 그 권한 설정도 다루지 않습니다. 이번에 부른 여섯 계열 창구는 전부 인증 없이 열렸고, 인증을 붙였을 때 값이 어떻게 달라지는지는 이 노트의 범위 밖입니다. 넷째, 모은 데이터로 무엇을 할지도 다루지 않습니다. 재료가 어디까지 있는지까지만 봅니다.

첫 기록 날짜는 자산의 역사가 아니라 그 창구의 개시일입니다

각 창구에 가장 이른 줄을 달라고 요청하고, 더 이상 되감기지 않을 때까지 페이지를 넘긴 결과입니다. 마지막 열은 그 창구를 끝까지 되감는 데 든 요청 횟수입니다.

세 가지가 눈에 띕니다.

같은 거래소 안에서도 갈립니다. 바이비트는 현물과 선형 계약이 같은 이름의 창구를 쓰는데, category 한 글자를 바꾸면 첫 기록이 2021년 7월과 2020년 3월로 1년 3개월 벌어졌습니다. 현물 쪽이 더 짧습니다. category 를 확인하지 않고 "바이비트 비트코인은 2021년부터"라고 적으면 절반만 맞는 문장이 됩니다.

원화 창구가 달러 창구보다 멀리 갈 수도 있습니다. 이번 조회에서 가장 멀리 되감긴 곳은 국내 원화 창구인 빗썸이었고, 그 다음이 바이낸스였습니다. 창구의 규모나 지명도로 소급 범위를 짐작하면 순서가 어긋납니다.

줄 수와 달력 일수가 어긋난 곳이 하나 있었습니다. 이 대조는 하루 단위 캔들을 돌려준 위 표의 여섯 줄만 놓고 했습니다. 뒤에서 다룰 코인게코는 캔들이 아니라 점 목록을 주고 기간 상한이 따로 걸려 있어 이 대조에서 뺐습니다. 위 표의 여섯 줄 가운데 다섯은 첫 줄과 마지막 줄 사이의 달력 일수와 돌려받은 줄 수가 정확히 같았습니다. 바이낸스 3,286, 업비트 3,247, OKX 3,231, 바이비트 현물 1,868, 바이비트 선형 2,335 가 각각 자기 구간의 일수와 일치했습니다. 어긋난 곳은 빗썸으로, 2013-12-26T15:00:00 부터 마지막 줄까지의 달력 일수는 4,616 인데 받은 줄은 4,525 였습니다. 91줄이 비어 있습니다. 이 노트는 그 91일이 어느 날짜들인지, 왜 비었는지까지는 확인하지 않았습니다. 다만 줄 수를 날짜 수로 가정하고 계산에 넣으면 이 창구에서는 어긋난다는 점만 적어 둡니다.

한 번에 받아지는 개수가 창구마다 갈립니다

한 요청으로 몇 줄까지 오는지는 문서에 적힌 곳도 있고 이번에 확보하지 못한 곳도 있습니다. 문서에서 확인한 것과 응답으로 잰 것을 갈라 적습니다.

업비트는 문서에 개수 한도가 그대로 적혀 있습니다. 개발자 문서의 캔들 데이터 내려받기 안내에 위 인용문이 있고, 같은 문단이 사용자가 조회하려는 기간의 캔들 데이터가 200개를 초과할 경우 호출 기간을 계산해 캔들 API를 여러 번 호출하는 로직 추가가 필요합니다. 라고 이어집니다. 이번 응답에서 센 200과 같은 값입니다.

빗썸은 갈라 적어야 합니다. /v1/candles/days 의 개수 한도 원문은 이번에 확보하지 못했습니다. 이 문서 주소를 받아 왔을 때 파라미터 표가 HTML 안에 없었고 count 라는 문자열 자체가 한 번도 나오지 않았으며, 같은 도메인의 다른 문서 주소를 불러도 바이트 수까지 같은 HTML 이 왔습니다. 다만 개수 한도를 직접 적은 빗썸 공지가 하나 있습니다. 원문은 count 파라미터 입력 시 최대 200개까지 조회 가능합니다. 이고, 같은 공지에 count 를 넣지 않았을 때의 기본 응답 개수도 2026년 7월 21일부터 200개로 바뀐다고 적혀 있습니다. 다만 이 공지의 적용 대상은 /candlestick/ 으로 시작하는 옛 주소이지 /v1/candles/days 가 아닙니다. 그래서 위 표의 빗썸 줄은 응답에서 잰 값만 적었습니다.

기본값도 갈립니다. 바이낸스에 limit 없이 요청하면 500줄이 왔고, 문서의 Default: 500 과 같았습니다. 이때 온 500줄은 가장 이른 쪽이 아니라 가장 최근 쪽이었습니다. 바이낸스 문서는 이 동작을 If startTime and endTime are not sent, the most recent klines are returned. 라고 적어 두었습니다. 구간을 지정하지 않으면 과거가 아니라 현재 쪽이 온다는 뜻이고, 과거를 받으려면 시작 시각을 직접 넣어야 합니다.

바이비트 문서에는 기본값이 200 으로 적혀 있고, OKX 문서에는 The default is 100. 으로 적혀 있습니다. 같은 코드에 창구만 바꿔 끼우면 지정하지 않은 기본값 때문에 받은 줄 수가 조용히 달라집니다.

한도를 넘겨 넣어도 오류가 아니라 조용히 잘려서 옵니다

문서에 적힌 한도보다 큰 값을 넣으면 거절당할 것 같지만, 이번 조회에서는 그렇지 않았습니다. 다섯 창구 모두 정상 응답을 돌려주었고 줄 수만 줄어 있었습니다.

바이비트가 특히 헷갈리는 자리입니다. 이 창구는 HTTP 상태와 별개로 본문에 자체 결과 코드를 담는데, limit=1001 에서도 retCode 는 0 이었고 retMsg 는 OK 였습니다. 본문의 성공 코드를 확인하는 검사까지 통과하면서 잘립니다.

OKX 는 한 자리가 다릅니다. 기본값 100 과 최대 300 사이의 값인 101 을 넣으면 101줄이 그대로 왔고, 301 을 넣으면 300 으로 잘렸습니다. 즉 100 과 300 사이는 넣은 대로 오고 300 을 넘는 부분만 사라집니다.

이 동작이 위험한 이유는 중간이 비어도 티가 나지 않기 때문입니다. 1,500줄을 요청해 1,000줄을 받고, 받은 줄의 첫 시각과 끝 시각만 확인하고 넘어가면 구간은 그럴듯하게 이어져 보입니다. 줄 수를 세지 않으면 부족한 것을 모릅니다. 요청한 개수와 받은 개수를 매번 비교하는 한 줄이 이 자리의 유일한 방어입니다.

같은 거래소 안에서도 창구가 둘로 갈립니다

과거를 얼마나 받아 볼 수 있는지가 거래소 단위로 정해져 있다고 보면 틀립니다. 같은 거래소 안에서 엔드포인트를 바꾸는 것만으로 소급 범위가 달라진 곳이 두 곳 있었습니다.

OKX 는 두 창구의 깊이가 다릅니다. 최근 구간용 /api/v5/market/candles 는 문서에 This endpoint can retrieve the latest 1,440 data entries. 라고 적혀 있습니다. 실제로 limit=300 으로 부르면 300줄이 오지만 그중 가장 이른 줄은 2025-10-19 16:00 이었고, 2020년 9월에 해당하는 시각을 페이징 값으로 넣자 0줄이 왔습니다. 같은 종목을 /api/v5/market/history-candles 로 부르면 2017-10-10 까지 돌아갑니다. 이쪽 문서에는 Retrieve history candlestick charts from recent years(It is last 3 months supported for 1s candlestick). 라고 적혀 있습니다. 괄호 안의 단서는 1초 봉에만 걸리는 조건이라 이번에 부른 하루 단위 캔들에는 해당하지 않습니다. 엔드포인트 이름 한 곳 차이로 받을 수 있는 과거가 1,440줄과 3,231줄로 갈립니다.

빗썸도 두 창구가 있습니다. 흔히 인용되는 /public/candlestick/BTC_KRW/24h 는 이번 호출에서 200줄이 왔고 가장 이른 줄이 2026-01-28 15:00 이었습니다. 여기에 되감기용 to 를 붙여 보면 응답 본문의 status 가 5500, message 가 Unknown query parameter. 로 바뀌고 데이터는 0줄이 됩니다. 이 창구가 받는 질의는 개수용 count 이고, count 는 거절당하지 않는 대신 200에서 잘립니다. count=1000 과 count=5000 모두 status 는 0000 이었고 온 줄은 200이었습니다. 즉 개수를 키워도 되감기는 되지 않으므로, 이 창구만 보면 "빗썸은 200줄이 전부"라는 결론이 나옵니다.

그런데 같은 도메인의 /v1/candles/days 는 되감기용 to 를 받습니다. 그 창구로 페이지를 넘기니 23회 만에 2013-12-26 까지 갔습니다. 앞의 결론은 창구를 하나만 열어 본 결과였습니다.

파라미터 표기 한 글자가 자료 없음을 만듭니다

빗썸 /v1/candles/days 를 처음 되감을 때 두 번째 요청이 실패했습니다. 응답은 HTTP 200 이었지만 본문이 배열이 아니라 오류 객체였고, name 은 400, message 는 Invalid parameter. Check the given value! 였습니다. 이 상태로 반복문을 돌리면 배열이 아니라는 이유로 루프가 끝나므로, 코드는 조용히 "1페이지가 전부"라고 판정합니다.

원인은 되감기 값의 표기였습니다. 같은 시각을 세 가지 표기로 넣어 대조했습니다.

두 창구는 응답 필드 이름까지 같은 모양입니다. 그래서 업비트에서 쓰던 코드를 그대로 옮기기 쉬운데, 뒤에 붙는 시간대 표기 한 글자에서 한쪽만 거절합니다. 업비트는 세 표기를 다 받았습니다.

여기서 얻는 규칙은 좁습니다. "이 창구에는 더 거슬러 갈 방법이 없다"는 문장은 내가 무엇을 어떻게 넣어 봤는지의 함수입니다. 빗썸의 경우 첫 결론은 창구를 하나만 열었기 때문이었고, 두 번째 결론은 표기를 하나만 넣었기 때문이었습니다. 없다고 적기 전에 어느 엔드포인트를 어떤 표기로 불렀는지를 함께 적어 두면, 나중에 그 문장이 틀렸을 때 어디를 고쳐야 하는지가 남습니다.

시세 집계 창구는 한도가 문서와 응답에서 다르게 말했습니다

거래소가 아니라 여러 시장을 모아 보여 주는 집계 창구도 같이 재 봤습니다. 코인게코의 /api/v3/coins/bitcoin/market_chart 입니다. 여기는 문서 문구와 이번 응답을 갈라 읽어야 하는 자리입니다.

문서 쪽. 해당 문서에는 Historical data on the Basic plan is restricted to the past 2 years. 라고 적혀 있습니다. 이 문장은 유료 요금제 가운데 Basic 을 쓸 때의 규정입니다. 같은 문서에는 기간 파라미터 설명으로 You may use any integer or max for number of days. 가 적혀 있고, 간격이 자동으로 정해지는 규칙이 세 줄로 나와 있습니다. 1 day from current time = 5-minutely data, 2–90 days = hourly data, Above 90 days = daily data (00:00 UTC) 입니다.

응답 쪽. 이번에 키 없이 부른 결과는 문서의 2년과 다릅니다. days=365 는 366개 점이 하루 간격으로 정상적으로 왔지만, days=366 부터는 HTTP 401 이었습니다. 366·400·730·3650 과 max 를 각각 넣어 봤고 전부 같은 401 이었습니다. 응답 본문의 error_code 는 10012 였고 문구는 Your request exceeds the allowed time range. Public API users are limited to querying historical data within the past 365 days. 였습니다. 문서가 말하는 2년은 Basic 요금제 이야기이고, 키 없이 부르는 쪽에는 365일이라는 다른 선이 걸려 있습니다. 두 값을 한 문장에 묶으면 어느 쪽도 아닌 문장이 됩니다.

간격이 자동으로 정해지는 규칙도 응답과 맞았습니다. days=1 은 289개가 5분 간격, days=30 은 721개가 1시간 간격, days=365 는 366개가 하루 간격이었습니다. 간격을 내가 고르는 것이 아니라 요청한 기간이 간격을 정합니다. 30일치를 시간 간격으로 받고 싶지 않아도 그렇게 옵니다.

401 이 창구 전체의 문제가 아니라는 점도 대조해 두었습니다. 같은 시각 같은 조건에서 /api/v3/coins/list 는 HTTP 200 으로 18,414개 항목을 돌려줬고 /api/v3/coins/markets 도 200 이었습니다. 401 은 이 엔드포인트의 이 기간에서만 났습니다. 다만 짧은 간격으로 연달아 부르면 별개의 제한이 걸립니다. 위 대조를 처음 시도했을 때는 error_code 429 로 막혔고, 호출 간격을 벌린 뒤 200 이 나왔습니다. 429 와 401 은 다른 사건이고, 429 를 보고 기간 한계라고 적으면 틀립니다.

직접 부를 창구와 파라미터 이름

같은 값을 다시 재실 수 있게 이번에 쓴 주소와 파라미터를 그대로 옮깁니다. 전부 인증 없이 열렸습니다.

되감는 방향의 이름이 창구마다 다릅니다. 바이낸스는 시작 시각을 앞으로 밀면서 전진하고, 바이비트는 end 를 뒤로 당기고, OKX 는 after 를 씁니다. OKX 문서는 after 를 Pagination of data to return records earlier than the requested ts 로, before 를 Pagination of data to return records newer than the requested ts 로 적어 두었습니다. 이름만 보고 방향을 짐작하면 반대로 갈 수 있는 자리라 문서 문구를 확인하는 편이 안전합니다.

되돌려 넣을 커서 값은 그 창구가 준 값을 그대로 쓰는 편이 안전합니다. 응답의 시각 필드는 창구마다 서로 다른 시각으로 찍혀 오고, 밀리초 정수로 주는 곳과 문자열로 주는 곳이 섞여 있습니다. 바이낸스 문서는 이 값의 성격을 Klines are uniquely identified by their open time. 이라고 적어 두었습니다. 받은 값을 직접 계산해 새로 만들어 넣으면 한 칸이 겹치거나 빠지기 쉽습니다.

호출 간격도 문서에 적혀 있습니다. OKX 문서는 이 엔드포인트에 Rate Limit: 20 requests per 2 seconds 와 Rate limit rule: IP 를 적어 두었습니다. 이번에는 간격 없이 12회 연속으로 부른 뒤에도 12회 모두 HTTP 200 이었지만, 그것은 위 한도 안이었기 때문입니다. 페이지를 수십 번 넘기실 때는 요청 사이에 간격을 두시는 편이 안전합니다.

같은 방식으로 공개 응답을 열어 값을 대조하는 절차는 업비트 경보 지정 기준과 공개 창구 응답을 맞대 본 노트에 정리해 두었고, 응답을 유형별로 갈라 세는 방법은 바이낸스 종목 목록을 유형별로 갈라 센 노트에 있습니다.

이 글이 확인하지 못한 것

• 빗썸 /v1/candles/days 의 개수 한도 원문. 이 문서 주소를 받아 왔을 때 파라미터 표가 HTML 안에 없었습니다. 그래서 위 표의 빗썸 200 은 응답에서 센 값이고, 문서상 최대치가 200 이라고는 적지 않았습니다. 개수 한도를 적은 빗썸 공지는 있지만 그 공지의 적용 대상은 옛 /candlestick/ 주소라 이 창구의 근거로 쓰지 않았습니다. 업비트는 문서 원문을 확인해 표에 넣었습니다.
• 빗썸에서 비어 있는 91줄의 정체. 첫 줄과 마지막 줄 사이 달력 일수가 4,616 인데 4,525줄이 왔다는 사실까지만 확인했습니다. 어느 날짜가 비었는지, 그것이 거래가 없던 날인지 기록이 없는 날인지는 이 노트에서 판정하지 않았습니다.
• OKX 의 가장 이른 한 줄의 값. 2017-10-10 16:00 줄은 시가와 저가가 모두 1 로 적혀 있었고 고가와 종가는 4901 이었습니다. 그 다음 줄부터는 4901·4989 처럼 이어집니다. 이 1 이 실제 체결에서 나온 값인지 기록 방식의 문제인지는 확인하지 않았습니다. 가장 이른 한 줄을 그대로 계산에 넣기 전에 눈으로 보셔야 하는 이유로만 적어 둡니다.
• 종목별 차이. 이 표는 비트코인 하나를 기준으로 만들었습니다. 같은 창구라도 종목마다 상장 시점이 다르므로 첫 기록 날짜는 종목마다 다시 재야 합니다. 바이낸스에서 이더리움은 비트코인과 같은 2017-08-17, 리플은 2018-05-04, 도지코인은 2019-07-05, 솔라나는 2020-08-11 이었습니다.
• 인증을 붙였을 때의 값. 이번 호출은 전부 인증 없이 했습니다. 인증을 붙이면 한도나 소급 범위가 달라지는지는 이 노트의 범위 밖입니다.
• 값의 지속 여부. 첫 기록 날짜는 창구가 과거 기록을 새로 넣거나 지우지 않는 한 잘 바뀌지 않는 값이지만, 한 번에 받아지는 개수와 기간 제한은 운영 정책이라 언제든 바뀔 수 있습니다. 두 값을 같은 신뢰도로 두지 않는 편이 안전합니다.

과거 시세 데이터 자가 점검 7단계

1. 요청한 개수와 받은 개수를 세어 비교하셨습니까. 다섯 창구 모두 넘겨 넣어도 오류 없이 잘렸습니다.
2. 구간을 지정하지 않고 부르지는 않으셨습니까. 바이낸스 문서 기준으로 시작과 끝을 넣지 않으면 최근 쪽이 옵니다.
3. 같은 거래소에서 다른 엔드포인트를 확인하셨습니까. OKX 는 1,440줄과 3,231줄, 빗썸은 200줄과 4,525줄로 갈렸습니다.
4. 되감기 값의 표기를 그 창구가 받는 형태로 넣으셨습니까. 빗썸은 Z 가 붙으면 거절했고 업비트는 받았습니다.
5. 응답 본문의 자체 결과 코드만 보고 성공으로 넘기지 않으셨습니까. 바이비트는 잘린 응답에도 retCode 0 을 줍니다.
6. 줄 수를 날짜 수로 가정하지 않으셨습니까. 빗썸은 이번 조회에서 두 값이 91만큼 어긋났습니다.
7. 파생 계약과 현물을 섞지 않으셨습니까. 바이비트는 category 한 값 차이로 첫 기록이 1년 3개월 갈렸습니다.

FAQ

Q. 비트코인 과거 시세를 2013년부터 받고 싶으면 어디를 불러야 하나요? A. 이번 조회에서 2013년까지 되감긴 곳은 빗썸 /v1/candles/days 하나뿐이었습니다. 다만 이 창구는 한 번에 200줄이라 2013년까지 가려면 되감기 값을 넘기며 23회를 불러야 했고, 받은 줄 수가 달력 일수보다 91 적었습니다. 연속된 날짜가 필요한 작업이시라면 빈 날짜를 어떻게 처리할지 먼저 정하셔야 합니다.

Q. 문서에 최대 1000 이라고 적혀 있으면 1500 을 넣었을 때 오류가 나야 하는 것 아닌가요? A. 이번 조회에서는 나지 않았습니다. 바이낸스에 1001·1500·5000 을 각각 넣었고 세 번 모두 HTTP 200 에 1,000줄이 왔습니다. 바이비트도 1001·2000 에서 retCode 0 과 retMsg OK 로 정상 응답하며 1,000줄만 줬습니다. 오류로 알려 주는 동작을 기대하고 계셨다면 그 전제가 이 창구들에는 없습니다.

Q. 코인게코 문서에 2년이라고 적혀 있는데 왜 1년치만 오나요? A. 그 문구는 Basic 요금제에 적용되는 규정입니다. 키 없이 부르는 쪽에는 다른 선이 걸려 있고, 이번에 days=366 을 넣었을 때 온 401 응답이 그 선을 Public API users are limited to querying historical data within the past 365 days. 라고 직접 적어 줬습니다. 요금제 문구를 무인증 호출의 한계로 옮겨 적으면 어긋납니다.

Q. 코인게코에서 30일치를 하루 간격으로 받고 싶은데 되나요? A. 간격을 지정하지 않고 부르시면 되지 않습니다. 문서의 자동 간격 규칙이 2–90 days = hourly data 이고, 실제로 days=30 은 721개가 1시간 간격으로 왔습니다. 문서에는 interval 로 덮어쓸 수 있다고 적혀 있으나 그 값이 무인증 호출에서 어떻게 동작하는지는 이번에 확인하지 않았습니다.

Q. 바이비트에서 비트코인 과거 시세가 2021년부터만 나오는데 맞나요? A. 현물이시라면 이번 조회에서 그렇습니다. 다만 같은 창구에 category=linear 를 넣으면 2020-03-25 까지 옵니다. 두 값은 서로 다른 시장의 기록이므로 섞어서 한 줄로 이으면 안 됩니다. 어느 쪽이 필요하신지에 따라 category 를 먼저 정하셔야 합니다.

Q. 응답이 정상인데 데이터가 부족한지 어떻게 알 수 있나요? A. 요청한 개수와 받은 개수를 비교하는 방법이 이번 조회에서 유일하게 통했습니다. 다섯 창구 모두 잘렸다는 사실을 응답 어디에도 적지 않았고, HTTP 상태와 본문 결과 코드 모두 성공이었습니다. 받은 줄의 첫 시각과 끝 시각만 확인하시면 구간이 이어져 보이므로 부족을 발견하지 못합니다.

Q. 빗썸 되감기가 안 된다고 나오면 창구에 그 기능이 없는 것인가요? A. 이번 사례에서는 아니었습니다. 되감기 값에 Z 를 붙였을 때 본문에 Invalid parameter. Check the given value! 가 왔고, 같은 값에서 Z 만 떼자 200줄이 정상적으로 왔습니다. 기능이 없다고 판정하시기 전에 표기를 두세 가지로 바꿔 보시고, 그래도 안 되면 어떤 엔드포인트에 어떤 표기를 넣었는지를 함께 기록해 두시는 편이 낫습니다.

함께 보면 좋은 글

• 업비트 경보 지정 기준과 공개 창구 응답을 맞대 본 노트: 공식 문서의 기준표와 같은 시각 공개 응답을 나란히 놓고 읽는 절차를 정리했습니다.
• 바이낸스 종목 목록을 유형별로 갈라 센 노트: 한 응답 안에 섞여 있는 계약 유형을 갈라 세는 방법을 다룹니다.
• 변동성 지수 정의와 캔들 계산을 대조한 노트: 이 글이 재료의 범위를 쟀다면 그 글은 같은 캔들 응답을 계산에 넣어 확인처 값과 맞대 봅니다.

데이터·개념 출처

본 노트의 수치는 2026년 8월 15일 23시 58분에서 8월 16일 0시 15분(KST) 사이에 여섯 계열 공개 창구를 인증 없이 호출해 받은 응답을 직접 읽은 것입니다. 되감기 구간은 GET https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=1d(4회·3,286줄), GET https://api.bybit.com/v5/market/kline?category=spot&symbol=BTCUSDT&interval=D(2회·1,868줄)와 category=linear(3회·2,335줄), GET https://www.okx.com/api/v5/market/history-candles?instId=BTC-USDT&bar=1D(11회·3,231줄), GET https://api.upbit.com/v1/candles/days?market=KRW-BTC(17회·3,247줄), GET https://api.bithumb.com/v1/candles/days?market=KRW-BTC(23회·4,525줄)로 각각 더 이상 되감기지 않을 때까지 페이지를 넘겨 얻었습니다. 개수 한도는 같은 주소에 limit 또는 count 를 바꿔 넣어 응답 줄 수를 세어 확인했습니다. 코인게코는 GET https://api.coingecko.com/api/v3/coins/bitcoin/market_chart?vs_currency=usd 에 days 를 1·30·365·366·400·730·3650 과 max 로 바꿔 넣어 상태 코드와 점 개수를 확인했고, 같은 조건에서 GET /api/v3/coins/list(18,414개)와 GET /api/v3/coins/markets 가 200 인 것을 대조군으로 두었습니다. 빗썸 GET https://api.bithumb.com/public/candlestick/BTC_KRW/24h 는 200줄이 왔고, 되감기용 to 를 붙였을 때 status 5500 과 Unknown query parameter. 가 왔습니다. 같은 주소에 count=1000 과 count=5000 을 넣었을 때는 status 가 0000 이었고 줄 수는 200이었습니다.

문서 문구는 각 창구의 개발자 문서에서 축자로 확인했습니다. 바이낸스 현물 REST 문서의 Kline/Candlestick data 절에서 Default: 500; Maximum: 1000., If startTime and endTime are not sent, the most recent klines are returned., Klines are uniquely identified by their open time. 를, 바이비트 V5 Get Kline 문서에서 Limit for data size per page. [1, 1000]. Default: 200 과 Sort in reverse by startTime 을, OKX API v5 문서의 Candlesticks history 절에서 Number of results per request. The maximum is 300. The default is 100.·Rate Limit: 20 requests per 2 seconds·Rate limit rule: IP·Retrieve history candlestick charts from recent years(It is last 3 months supported for 1s candlestick).·after 와 before 설명을, Candlesticks 절에서 This endpoint can retrieve the latest 1,440 data entries. 를 옮겼습니다. 코인게코 Coin Historical Chart Data 문서에서는 You may use any integer or max for number of days., 자동 간격 규칙 세 줄, Historical data on the Basic plan is restricted to the past 2 years. 를 옮겼습니다. 업비트는 개발자 문서의 캔들 데이터 내려받기 안내(https://docs.upbit.com/kr/docs/how-to-download-candle-data)에서 업비트의 캔들 API는 호출 당 최대 200개의 캔들 데이터를 반환합니다. 와 그 뒤 문장을 옮겼습니다. 빗썸 /v1/candles/days 의 개수 한도는 문서 원문을 확보하지 못해 응답값만 근거로 썼고, 옛 /candlestick/ 주소의 개수 한도는 빗썸 공지(https://apidocs.bithumb.com/reference/candles-days 에 실려 있는 캔들스틱 API 응답 개수 정책 변경 공지)의 count 파라미터 입력 시 최대 200개까지 조회 가능합니다. 를 옮겼습니다.

이 글은 공개 API 응답과 개발자 문서를 정리한 정보 제공 목적의 자료이며 특정 종목이나 거래소의 이용 권유가 아닙니다. 본 노트는 진입가나 청산가를 제시하지 않고, 어떤 자산도 매수 또는 매도 대상으로 지목하지 않으며, 어느 창구가 더 낫다는 판단도 하지 않습니다. 가상자산은 원금 손실이 발생할 수 있습니다. 위 수치는 2026년 8월 16일 0시 전후 한 시각의 스냅샷이라 다시 호출하면 달라질 수 있고, 여기서 관측된 개수 한도와 기간 제한이 이후에도 같은 모양으로 유지되는지는 이 글에서 확인하지 않았습니다. 투자 판단과 그 결과는 전적으로 본인 책임입니다.