WebSocket으로 실시간 체결 데이터를 받는 것만으로는 자동매매 시스템이 완성되지 않는다. 프로그램을 종료해도 과거 데이터를 다시 조회할 수 있어야 하고, 같은 조건으로 전략을 반복 검증하려면 수집한 데이터를 일정한 구조로 저장해야 한다. 데이터가 쌓이는 속도뿐 아니라 나중에 꺼내 쓰는 속도까지 고려해야 했다. 이번 글에서는 업비트 실시간 체결 데이터를 PostgreSQL에 저장하기 위해 어떤 테이블을 만들었고, 왜 날짜별 파티션과 […]
앞선 글에서는 업비트 WebSocket을 연결해 실시간 체결 데이터를 수집했다. 이 과정에서 사용한 시세 정보는 누구나 조회할 수 있는 공개 데이터라서 별도의 인증 정보가 필요하지 않았다. 하지만 보유 자산을 조회하거나 주문을 전송하려면 이야기가 달라진다. 내 업비트 계정에 접근하는 요청이라는 사실을 확인하기 위해 API 키가 필요하다. 이번 글에서는 자동매매 프로그램과 업비트 계정을 연결하기 위한 API 키를 발급받고,
자동매매 시스템에서 전략보다 먼저 필요한 것은 시장 데이터를 안정적으로 수집하는 일이다. 완성된 캔들 데이터는 일정 시간 동안의 시가·고가·저가·종가와 거래량을 보여준다. 하지만 그 구간 안에서 가격이 어떤 순서로 움직였는지, 순간적으로 거래량이 얼마나 증가했는지까지는 확인하기 어렵다. 특히 짧은 시간의 가격 변화와 체결 흐름을 이용하는 전략에서는 이러한 차이가 진입과 청산 결과를 크게 바꿀 수 있다. 따라서 체결이 발생한
자동매매 시스템을 다시 만들기로 결심한 뒤 가장 먼저 한 일은 매매 전략을 작성하는 것이 아니었다. 먼저 개발 환경부터 다시 정리했다. 이전 버전을 운영하면서 데이터베이스 용량 문제, 복잡해진 구조, 흩어진 문서 때문에 유지보수가 점점 어려워졌기 때문이다. 이번에는 단순히 ‘당장 동작하는 프로그램’이 아니라, 장기간 운영하면서 끊임없이 개선할 수 있는 단단한 구조를 만드는 데 집중하기로 했다. 현재 구축한
언젠가는 나만의 자동매매 시스템을 만들어 보고 싶다는 생각만 계속 하고 있었다. 하지만 항상 생각뿐이었다.‘나중에 해야지.’‘시간 나면 해야지.’핑계를 대며 미루다 보니 어느새 몇 년이라는 시간이 흘러버렸다. 이번에는 정말 끝까지 만들어 보기로 결심했다. 그 다짐을 잊지 않기 위해, 그리고 나와 같은 고민을 하는 개발자들과 기록을 나누기 위해 이 글을 첫 기록으로 남긴다. 수동 매매의 한계: 원칙을 무너뜨리는
