캔들 데이터 다운로더를 만들며 겪은 문제 유형

캔들 데이터 다운로더는 자동매매 시스템에서 가장 기초적이면서도 가장 많은 문제를 만들어내는 영역입니다. 단순히 데이터를 받아오는 작업처럼 보이지만, 실제로는 속도, 안정성, 데이터 무결성, API 제약까지 동시에 고려해야 하는 고난도 작업입니다. 이 글에서는 캔들 다운로더를 직접 제작하면서 실제로 겪었던 문제들과 그 과정에서 깨달은 핵심 포인트를 정리합니다.

1. 방대한 타임프레임 데이터로 인한 극심한 속도 문제

1분, 3분, 10분, 15분, 30분, 1시간, 4시간, 12시간, 1일과 같은 다양한 타임프레임(TF)의 데이터를 모두 다운로드하려면 데이터 양은 기하급수적으로 늘어납니다. 백테스트를 충분히 하기 위해서는 긴 기간의 데이터가 필요하지만, 이를 naive한 방식으로 수집하면 엄청난 시간이 소요됩니다.

처음에는 2년치 데이터를 받는 데 수십 분 이상이 걸렸지만, 병렬 처리와 구조 개선을 통해 현재는 커피 한 잔을 마실 시간도 걸리지 않을 정도로 단축되었습니다. 중요한 것은 느린 원인을 모르면, 그 시간 손실조차 인지하지 못한 채 개발을 진행하게 된다는 점입니다.

2. 거래소마다 다른 요청 방식에서 발생하는 미묘한 오류

같은 의미의 요청이라도 거래소마다 요구하는 파라미터 형식이 다릅니다. 예를 들어, 어떤 거래소는 24h 요청에 응답하지 않지만 1d 요청에는 정상적으로 응답합니다. 이런 차이를 모르면 원인을 알 수 없는 에러에 오랫동안 갇히게 됩니다.

프로그래밍에서는 아주 사소한 문자열 하나, 파라미터 하나가 전체 로직을 멈추게 만들 수 있다는 점을 반드시 염두에 두어야 합니다.

3. 매번 처음부터 다시 다운로드되는 구조적 문제

기존 데이터를 고려하지 않고 항상 처음부터 다시 다운로드하는 구조는 큰 비효율을 낳습니다. 이미 1년치 데이터를 받아놓았음에도, 2년치를 받기 위해 다시 전체 데이터를 요청하는 상황이 발생할 수 있습니다.

이를 해결하기 위해 다운로드가 중단되거나 프로그램이 종료되더라도, 마지막으로 저장된 지점부터 이어서 다운로드할 수 있도록 설계해야 합니다.

4. 이어받기 로직에서 발생하는 순서 설계 오류

이어받기 기능은 생각보다 구현이 까다롭습니다. 기존 데이터 존재 여부를 먼저 확인한 뒤 다운로드를 시작해야 하지만, 로직 순서가 잘못되면 이 검증 단계를 건너뛰고 바로 다운로드를 시작해버릴 수 있습니다.

초보자일수록 이런 로직 순서 문제를 원인으로 의심하지 못해 많은 시간을 허비하게 됩니다. 실제로는 단순한 순서 문제임에도 불구하고 말입니다.

5. 이어받기 과정에서 발생하는 데이터 결손

예를 들어 1월 3일 데이터를 받는 도중 프로그램이 종료되었고, 재실행 시 해당 날짜의 데이터가 “있다”고 판단되어 1월 4일부터 다운로드가 시작되면, 1월 3일 데이터에는 결손이 생깁니다.

이 문제를 방지하기 위해 저는 일정 구간(예: 하루 단위)을 의도적으로 덮어쓰는 방식으로 설계했습니다. 완전성을 보장하기 위한 안전장치입니다.

6. 요청 제한(Rate Limit)과 429 에러의 위험성

거래소는 초당 요청 가능한 횟수를 제한합니다. 예를 들어 빗썸의 경우 초당 과도한 요청이 발생하면 429 에러가 발생하며, 상황에 따라 IP 차단까지 이어질 수 있습니다.

429 에러가 발생했다는 것은 단순한 경고가 아니라, 일부 요청이 정상적으로 처리되지 않았을 가능성을 강하게 시사합니다. 따라서 작은 경고 로그라도 절대 무시해서는 안 됩니다.

중요한 점은, 이론적으로 허용된 요청 수 이하라 하더라도 무거운 요청을 연속적으로 보내면 제재가 발생할 수 있다는 점입니다. 저는 약 50개의 병렬 요청을 사용하고 있으며, 이는 충분히 빠르면서도 비교적 안정적인 수준이었습니다.

7. 동기식 구조에서 비동기 구조로의 전환

동기식 방식은 요청 후 응답을 받은 다음 다음 요청을 보내는 구조입니다. 반면 비동기 방식은 여러 요청을 동시에 던지고, 도착하는 순서대로 처리합니다.

다운로드 속도를 개선하기 위해 비동기 처리는 사실상 필수이며, 다만 그만큼 데이터 정합성과 에러 처리 로직이 더욱 중요해집니다.

8. CSV와 엑셀 파일의 한계

초보자들은 데이터를 확인하기 위해 CSV나 XLSX 형태로 저장하는 경우가 많습니다. 하지만 수백만 줄 이상의 캔들 데이터는 엑셀로 열리는 것 자체가 불가능에 가깝습니다.

Parquet 포맷은 저장 속도, 용량, 읽기 성능 모든 면에서 훨씬 효율적이며, 대규모 백테스트에도 적합한 포맷입니다.

9. Pandas 벡터화 연산과 파일 I/O 분리

파이썬 반복문은 느리지만, Pandas의 벡터화 연산을 사용하면 대량의 데이터도 매우 빠르게 검증할 수 있습니다. 이를 통해 데이터 결손이나 이상 여부를 자동으로 검사할 수 있습니다.

또한 대용량 파일 저장 시 발생하는 순간적인 블로킹을 방지하기 위해, 파일 읽기/쓰기 작업을 별도의 스레드로 분리하는 구조도 필요합니다.

10. 모든 최적화는 단계적으로 적용해야 한다

여러 최적화를 한꺼번에 적용하면 문제가 발생했을 때 원인을 추적하기 어렵습니다. 최적화는 반드시 하나씩 적용하고, 그 결과를 검증하면서 진행해야 합니다.

결론적으로, 캔들 데이터 다운로더는 단순한 수집기가 아니라, 시간 절약, 안정성 유지, 데이터 검증까지 모두 책임지는 핵심 시스템입니다. 모든 경우의 수를 가정하고 대비하는 것이 결국 전체 자동매매 시스템의 신뢰도를 결정합니다.