자동매매를 처음 VPS에 올리고 나서 가장 위험한 시기는 시스템이 잘 돌아가는 것처럼 보이는 때입니다. 저도 초기에 비슷한 실수를 했습니다. 화면상 프로세스는 살아 있는데, 실제로는 주문이 한 건도 나가지 않고 있었던 경험이 있습니다. 봇이 ‘실행 중’이라는 상태와 봇이 ‘제대로 작동 중’이라는 상태는 완전히 다른 개념입니다. 이 차이를 구분하지 못하면 시장이 움직이는 동안 봇만 멈춰 있는 상황을 반복하게 됩니다. 이번 칼럼에서는 제가 실제로 운영하면서 구축한 모니터링 레이어를 단계별로 정리해 보겠습니다.
프로세스 생존과 봇 작동은 다르다 — 진짜 장애를 정의하는 법
Ubuntu VPS에서 Jesse 프레임워크로 봇을 돌릴 때 가장 흔한 착각은 ps aux나 htop에서 프로세스가 보이면 봇이 정상이라고 생각하는 겁니다. 저도 초기에 이 함정에 빠졌습니다. 프로세스는 살아있어도 내부적으로 API 연결이 끊기거나, 웹훅 수신 실패 상태가 지속되거나, 주문 큐가 막혀있는 경우가 실제로 발생합니다. 제가 정의한 진짜 장애 기준은 세 가지입니다. 첫째, 마지막 웹훅 수신 시각이 4시간봉 기준 2캔들 이상 초과된 경우. 둘째, 바이낸스 포지션 상태와 봇 내부 상태가 불일치하는 경우. 셋째, 로그 파일에 신규 항목이 특정 시간 이상 추가되지 않는 경우입니다. 이 세 가지 기준을 잡고 나서야 모니터링 로직을 설계할 수 있었습니다. 막연하게 ‘봇이 살아있나’를 보는 것이 아니라, 봇이 제 역할을 하고 있는지를 측정 가능한 지표로 바꾸는 것이 핵심입니다. 특히 Jesse는 실행 로그를 logs/ 디렉토리 아래에 날짜별로 쌓기 때문에 최신 로그 파일의 마지막 수정 시각을 추적하는 것만으로도 기초 헬스체크가 됩니다. find /home/user/jesse-bot/logs -name ‘*.log’ -newer /tmp/heartbeat_check 이런 식으로 cron에서 파일 갱신 여부를 체크하는 것을 시작으로 모니터링 레이어를 쌓았습니다.
텔레그램 알림 3단계 구조 — 무음 장애를 없애는 실전 설정
모니터링은 결국 알림이 제때 오느냐로 완성됩니다. 저는 텔레그램 알림을 세 단계로 나눠서 운영합니다. 1단계는 정상 확인 메시지입니다. 매 4시간마다 봇이 살아있음을 스스로 알려주는 하트비트 메시지를 텔레그램으로 보냅니다. 이 메시지가 오지 않으면 그 자체가 이상 신호입니다. 구현 방법은 간단합니다. Jesse 전략 내부 on_candle_close 훅에 텔레그램 메시지 함수를 넣거나, 별도 Python 스크립트를 cron으로 돌려 /4 시마다 실행하도록 하면 됩니다. 2단계는 예외 상황 알림입니다. API 타임아웃, 웹훅 파싱 오류, 포지션 불일치 감지 시 즉시 텔레그램으로 에러 내용과 타임스탬프를 함께 전송합니다. 에러 메시지만 보내면 나중에 원인 파악이 어려워서 저는 항상 에러 코드 + 마지막 정상 수신 시각 + 현재 포지션 요약을 한 번에 보내도록 포맷을 짜뒀습니다. 3단계는 일일 요약입니다. 매일 오전 9시 KST에 전날 주문 횟수, 오류 발생 횟수, 봇 가동 시간을 정리해서 보냅니다. 이 세 단계가 갖춰지면 본업 중에도 폰만 보면 봇 상태를 파악할 수 있습니다. 텔레그램 봇 토큰과 chat_id 설정은 BotFather로 5분 안에 완료되고, Python requests 라이브러리로 메시지 전송은 10줄이면 충분합니다.
cron + 자동 재시작까지 — 무인 운영을 위한 마지막 레이어
알림을 받는다고 끝이 아닙니다. 새벽 3시에 알림을 받아도 제가 즉시 VPS에 접속해서 재시작할 수 없는 상황이 실제로 많습니다. 그래서 저는 가능한 범위에서 자동 복구 레이어를 추가했습니다. 핵심은 watchdog 스크립트입니다. 5분마다 cron으로 실행되는 Python 스크립트가 봇 프로세스를 확인하고, 죽어있으면 자동으로 재시작하고 텔레그램으로 ‘재시작 완료’ 메시지를 보냅니다. crontab -e 에서 작성 방법은 간단합니다. /5 라는 분 표현으로 5분마다 watchdog.py를 실행하도록 등록합니다. 단, 자동 재시작에는 주의사항이 있습니다. 봇이 예상치 못한 포지션 상태에서 재시작되면 중복 주문이나 반대 방향 진입 같은 더 큰 문제가 생길 수 있습니다. 그래서 저는 재시작 전에 바이낸스 API로 현재 오픈 포지션을 조회하고, 포지션이 있는 경우에는 자동 재시작을 막고 알림만 보내도록 분기 처리를 해뒀습니다. 또 하나 놓치기 쉬운 부분이 로그 로테이션입니다. VPS 디스크가 꽉 차서 봇이 멈추는 사례도 실제로 있었습니다. logrotate 설정을 통해 일별 로그를 7일치만 보관하도록 하고, df -h 결과도 일일 요약 메시지에 포함시켜서 디스크 사용률을 자동으로 확인합니다. 이 모든 레이어를 갖추고 나서야 비로소 본업 중에도 봇을 신뢰할 수 있게 됐습니다.
💬 운영자 한마디
저는 아직도 모니터링 시스템을 개선하고 있는 중입니다. 완벽한 무인 운영이라는 목표는 있지만, 실제로는 예상치 못한 예외 상황이 계속 나옵니다. 중요한 건 장애가 날 때 얼마나 빠르게 인지하고 대응하느냐입니다. 그 속도를 줄이는 것이 모니터링의 본질이라고 생각합니다.
— J_River · autoprofit 운영자
✅ 이번 주 체크리스트
- Jesse 로그 파일 마지막 갱신 시각을 cron으로 15분마다 체크하는 스크립트 작성
- 텔레그램 하트비트 메시지를 4시간마다 자동 전송하도록 설정
- API 예외 발생 시 에러 코드 + 타임스탬프 포함 텔레그램 알림 구현
- watchdog 스크립트에 포지션 체크 분기 추가 (포지션 있을 때 자동 재시작 차단)
- logrotate로 봇 로그를 7일치만 보관하도록 설정
- 매일 오전 9시 KST에 주문 횟수 + 오류 횟수 + 디스크 사용률 일일 요약 전송
- crontab -e 에서 watchdog.py를 5분 간격으로 등록하고 실제 재시작 테스트 1회 실시
봇 모니터링은 한 번 설정하면 끝이 아닙니다. 시스템이 바뀔 때마다 모니터링 레이어도 함께 점검해야 합니다. 이번 주 한 가지라도 직접 구현해 보시길 권합니다.
※ 본 콘텐츠는 운영자 개인의 경험과 연구를 바탕으로 한 정보 제공 목적이며, 특정 종목에 대한 투자 권유나 매매 시그널이 아닙니다. 암호화폐 및 자동매매는 원금 손실 가능성이 있는 고위험 활동이며, 모든 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.