파이썬 트레이딩 봇 개발 프로세스: 기획부터 실전 배포까지의 핵심 가이드

제가 처음 파이썬 트레이딩 봇을 만들기 시작한 날은 2024년 3월 18일이었습니다. 당시에는 이동평균선 두 개가 교차하면 매수하고, 반대 방향으로 교차하면 매도하는 단순한 전략이면 충분하다고 생각했어요. 주말 동안 작성한 코드가 백테스트에서 1년 수익률 27%를 보여주자 곧바로 실전에 넣고 싶어졌습니다. 하지만 실제 계좌에 30만 원을 연결한 첫날부터 예상과 다른 문제가 나타났습니다. 수수료와 슬리피지를 반영하지 않은 결과였고, 주문 응답이 늦어 같은 신호에 두 번 진입하기도 했습니다. 그때부터 봇 개발은 매매 조건을 적는 작업보다 실패 상황을 먼저 기록하는 과정에 가깝다는 생각을 하게 됐습니다.

1. 전략보다 먼저 거래 규칙을 글로 적었다

처음에는 코드부터 열었지만, 한 달 뒤에는 전략 문서를 먼저 작성했습니다. 제가 사용한 규칙은 15분봉 기준으로 20일 지수이동평균선이 60일선을 상향 돌파할 때 진입하고, 손절 폭은 진입가에서 1.2%, 하루 누적 손실이 2%에 도달하면 거래를 멈추는 방식이었습니다. 예전에는 ‘상승 흐름이 보이면 매수’처럼 해석의 여지가 있는 문장을 썼는데, 이런 표현은 코드로 옮기는 순간 사람마다 다른 조건이 됐습니다. 진입 시점, 주문 가격, 부분 청산 여부, 재진입 대기 시간까지 표로 적으니 제가 머릿속으로만 알고 있던 빈틈이 드러났습니다.
2024년 4월에는 과거 3년치 분봉 자료를 내려받아 백테스트를 다시 했습니다. 처음 결과는 수익률 31%였지만, 거래소 수수료 0.05%와 예상 슬리피지 0.08%를 넣자 6% 수준까지 떨어졌습니다. 특히 거래량이 적은 시간대의 진입 가격이 실제 체결 가격과 크게 달랐어요. 저는 이때 백테스트 숫자를 믿기 전에 어떤 비용과 지연을 넣었는지부터 확인해야 한다는 교훈을 얻었습니다. 이후에는 학습 구간과 검증 구간을 나누고, 2021년부터 2023년까지로 규칙을 조정한 뒤 2024년 상반기 구간에서 따로 확인했습니다.

2. 개발 환경을 나눴다가 다시 단순화했다

개발 초기에는 윈도우 노트북에 아나콘다를 설치하고, 운영 서버에는 우분투와 별도 파이썬을 구성했습니다. 그런데 2024년 5월 7일 배포 직후 노트북에서는 정상 작동하던 날짜 처리 코드가 서버에서 오류를 냈습니다. 로컬 환경은 파이썬 3.11, 서버는 3.10이었고, 판다스 버전도 달랐습니다. 그날 새벽 두 시간 동안 원인을 찾은 뒤 requirements.txt를 고정하고, 도커 이미지 안에서 테스트한 결과를 그대로 서버에 올리는 방식으로 바꿨습니다. 거창한 자동 배포보다 먼저 ‘어떤 버전에서 실행됐는지 남기는 습관’이 제 작업 시간을 크게 줄여 줬습니다.
API 키를 코드 파일에 직접 적었던 실수도 있었습니다. 테스트용 저장소를 비공개로 설정했다고 안심했지만, 실수로 키가 포함된 커밋을 남겼고 20분 뒤 해당 키를 폐기했습니다. 이후에는 .env 파일을 로컬에만 두고 서버에서는 환경 변수로 주입했으며, 거래 권한만 켜고 출금 권한은 껐습니다. 깃 로그에 민감한 값이 남았는지 검사하는 스크립트도 추가했어요. 개발 환경을 복잡하게 꾸미는 것보다, 재현 가능한 버전과 접근 권한을 먼저 관리하는 편이 제게 훨씬 현실적인 선택이었습니다.

3. 시세 수집에서 겪은 누락과 중복

처음 만든 수집기는 1분마다 REST API를 호출해 최근 캔들을 가져왔습니다. 호출량이 많지 않아 괜찮다고 판단했지만, 2024년 6월 2일 거래소 API가 약 40초 동안 지연되면서 같은 캔들을 세 번 저장했습니다. 봇은 새 캔들이 들어왔다고 착각해 동일한 조건을 반복 평가했고, 주문 중복 방지 장치가 없었다면 실제 매수도 반복됐을 상황이었어요. 이후 캔들 시간과 종목을 조합한 고유 키를 저장하고, 이미 처리한 캔들은 건너뛰도록 수정했습니다. 웹소켓을 추가한 뒤에도 연결이 끊기면 마지막 수신 시각을 확인하고 REST 방식으로 빈 구간을 채우는 절차를 넣었습니다.
제가 특히 오래 붙잡았던 문제는 데이터가 없는 경우와 가격이 0으로 들어오는 경우를 구분하는 일이었습니다. 처음에는 결측값을 모두 직전 가격으로 채웠는데, 거래 중단 구간까지 정상 거래처럼 만들어 버렸습니다. 그 뒤에는 결측 구간의 길이를 기록하고, 3개 캔들 이상 비어 있으면 신호 계산을 멈추게 했습니다. 로그에는 수집 시각, 거래소 서버 시각, 로컬 시각, 마지막 캔들 시간을 함께 남겼습니다. 이 기록 덕분에 나중에 수익률이 나빠진 원인이 전략인지, 시세 지연인지 분리해서 확인할 수 있었고, 막연한 추측으로 조건을 바꾸는 일도 줄었습니다.

4. 주문 엔진과 리스크 제한을 따로 만들었다

주문 함수 안에 진입 조건과 손절 조건을 모두 넣었던 시절에는 수정할 때마다 다른 부분이 깨졌습니다. 2024년 7월에는 신호 생성, 포지션 조회, 주문 제출, 체결 확인, 손절 감시를 각각 모듈로 분리했습니다. 주문을 보낸 뒤 5초 안에 체결 확인이 오지 않으면 무조건 재주문하지 않고, 먼저 거래소의 미체결 주문 목록을 조회하도록 바꿨습니다. 예전에는 네트워크 지연을 오류로 오해해 같은 주문을 두 번 제출했고, 한 번에 예정 수량의 두 배를 보유한 적도 있었습니다. 그 뒤부터는 주문마다 고유 ID를 만들고, 현재 포지션과 미체결 수량을 확인한 뒤에만 다음 행동을 실행했습니다.
리스크 제한은 전략 코드와 분리해 봇이 어떤 신호를 내더라도 마지막에 한 번 더 검증하도록 구성했습니다. 제 테스트 계좌의 평가금액은 100만 원으로 두고, 한 번의 거래에서 잃을 금액을 7천 원 이하로 제한했습니다. 하루 손실이 2만 원에 닿으면 신규 주문을 막고, 서버가 재시작돼도 이 값이 초기화되지 않도록 파일과 데이터베이스에 함께 기록했습니다. 2024년 8월 14일에는 손절 주문이 거래소에서 거절되는 상황을 가정해 모의 장애 테스트를 했고, 재시도 횟수가 세 번을 넘으면 알림과 함께 신규 진입을 차단하도록 수정했습니다. 수익을 늘리는 코드보다 손실이 커지는 경로를 닫는 코드가 더 오래 남는다는 걸 이 과정에서 체감했습니다.

5. 소액 운영과 모니터링으로 배포를 확인했다

2024년 9월 1일부터는 실계좌에 10만 원만 연결해 2주간 운영했습니다. 매매 알림만 받으면 충분하다고 생각했지만, 하루가 지나자 알림이 너무 많아 진짜 장애를 놓치기 쉬웠습니다. 그래서 주문 체결, API 연결 끊김, 일일 손실 제한 도달, 프로세스 재시작만 즉시 알리고 일반 로그는 파일에 저장했습니다. 텔레그램 메시지에는 신호 가격과 실제 체결 가격, 수수료, 주문 ID를 함께 표시했습니다. 어느 날에는 봇이 살아 있었지만 시세가 18분 동안 갱신되지 않았고, 마지막 수신 시각을 알림에 넣은 덕분에 거래를 중단할 수 있었습니다.
배포 뒤에도 코드를 방치하지 않고 매일 오전 전날 거래를 직접 대조했습니다. 거래소 체결 내역과 로컬 기록의 주문 수, 평균 체결가, 수수료 합계를 비교하고 차이가 있으면 원인을 찾은 뒤에만 다시 실행했습니다. 2024년 10월에는 서버 재부팅 후 포지션을 복원하지 못하는 버그를 발견해, 시작 시 거래소 잔고와 보유 수량을 먼저 읽고 상태를 맞추는 절차를 추가했습니다. 제가 얻은 실전 교훈은 봇을 켜는 날보다 멈춰야 할 조건을 정하는 날이 더 중요하다는 점입니다. 자동화는 감시를 없애는 기술이 아니라, 사람이 확인해야 할 신호를 줄이고 기록을 남기는 도구에 가까웠습니다.
제가 지금 새 봇을 만든다면 첫 주에는 수익률을 계산하지 않고 규칙 문서와 장애 목록부터 작성할 겁니다. 그다음 과거 자료에 수수료와 지연을 넣어 검증하고, 실계좌가 아닌 모의 환경에서 중복 주문과 연결 끊김을 반복해서 재현하겠습니다. 배포 단계에서는 감당 가능한 소액만 사용하고, 손실 한도와 강제 중단 방법을 가족이나 동료에게 설명할 정도로 명확히 남기겠습니다. 독자분도 전략 코드를 먼저 늘리기보다 한 번의 오류가 얼마를 잃게 만드는지 계산하고, 로그를 통해 실제 체결을 확인하는 순서로 시작하길 권합니다. 자동매매는 수익을 약속하는 장치가 아니므로, 중단 기준을 지키는 습관이 장기 운영의 출발점이 됩니다.