코인 자동매매 봇이 알아서 오류를 복구하게 만들었습니다 — 안정성 개선 11가지의 실전 기록

코인 자동매매 봇을 AWS Lightsail 서버에 올려놓고 24시간 돌리기 시작했더니, 생각보다 훨씬 자주 봇이 “조용히 죽어 있는” 상황을 마주했습니다. 처음엔 매번 직접 들어가서 다시 켰는데, 이런 식으로는 운영 자체가 불가능하다는 걸 깨달았어요. 그래서 한 달에 걸쳐 11가지 안정성 문제를 잡고, 봇이 알아서 복구하도록 만들었습니다. 이 글은 그 과정의 운영자 시점 기록이에요.

자동매매 봇 안정성이란 예상치 못한 오류가 발생해도 봇이 스스로 복구하고 계속 거래할 수 있는 능력이에요.

자동매매 봇을 24시간 돌리면 무엇이 깨질까?

사건은 단순했어요. 어느 날 봇이 매수 신호를 놓쳤습니다. 백테스트에서는 분명 진입 신호가 잡혀 있었는데, 같은 시간 실서버 봇은 아무 행동도 하지 않았어요. 원인을 추적해보니 전날 새벽에 서버가 자동 보안 업데이트로 재시작됐는데, 봇이 다시 켜지지 않은 채 하루 넘게 멈춰 있었던 거였습니다.

이 사건이 도화선이었어요. 24시간 운영을 가정하지 않고 만든 부분이 어디어디 있는지 파고들어 봤더니, 비슷한 잠재 문제가 줄줄이 나오기 시작했습니다. 데이터 연결이 잠깐씩 끊기는 구간, 끊긴 뒤 다시 잇지 않는 구간, 알림이 매매 로직을 잠깐씩 막는 구간, 사람이 직접 보지 않으면 절대 모르는 구간이 곳곳에 있었어요.

정리해 보니 총 11가지 안정성 문제였습니다. 하나씩 보면 자잘해 보여도, 24시간 시스템에서는 어느 하나만 무너져도 봇 전체가 “조용히 죽어 있는 상태”가 돼요. 이 글에서는 11가지를 성격이 비슷한 것끼리 5가지 영역으로 묶어 정리해볼게요.

11가지 안정성 개선, 5가지 영역으로 정리

영역 ① 죽어도 다시 살아나는 봇 만들기

첫 번째 영역은 처음 사건의 직접적인 해결책이에요. 기존엔 봇 설정이 메모리에만 남아 있어서, 서버가 한 번 재시작되면 봇이 사라져 버렸습니다. 그래서 봇 설정을 DB와 로컬 파일 두 군데에 동시에 저장해두고, 서버가 부팅될 때 자동으로 불러와 다시 봇을 켜도록 만들었어요. DB가 응답하지 않는 상황에도 로컬 파일이 백업으로 작동합니다.

여기에 더해 “봇이 살아 있긴 한데 사실상 일을 못하고 있는” 상태도 잡았어요. 봇 사이클이 연속으로 실패하기 시작하면 카운터가 올라가고, 일정 임계값을 넘으면 일반 에러 알림이 아니라 “봇 비정상” 경고로 바뀝니다. 실전에서는 “안 죽었지만 멍 때리고 있는” 상태가 가장 위험해요. 그걸 표면으로 끌어올리는 게 이 영역의 핵심이었습니다.

영역 ② 끊어진 데이터를 다시 잇는 안전망

두 번째 영역은 “데이터가 잠깐 끊겨도 봇이 잘못된 판단을 하지 않게 한다”가 목표였어요. 24시간 운영해 보니 데이터 연결은 생각보다 자주 끊깁니다. 특히 클라우드 DB는 일정 시간 안 쓰면 유휴 연결을 끊어버려서, 가격 데이터 저장이 하루에 몇 번씩 실패했어요. 이게 누적되면 봇이 참고하는 지표 계산에 빈 구간이 생기고, 결과적으로 이상한 신호를 내게 됩니다.

대응은 3단계예요. (1) 끊어진 연결이 감지되면 자동으로 폐기하고 새 연결로 즉시 재시도합니다. (2) 그래도 실패한 데이터는 메모리 버퍼에 잠시 보관해두었다가, 다음 저장이 성공할 때 한꺼번에 다시 올려요. (3) 거래소와 연결되는 실시간 데이터 채널이 끊겼다 다시 붙으면, 끊겼던 사이의 빠진 가격 데이터를 거래소에서 직접 가져와 채워 넣습니다.

이 3단계 안전망 덕분에 데이터 누락으로 인한 신호 오작동이 거의 사라졌어요. “끊김이 일어나지 않게 한다”가 아니라 “끊겨도 봇이 그걸 인지하고 스스로 복구한다”가 핵심이라는 걸 이때 확실히 배웠습니다.

영역 ③ 조용히 일하는 알림 시스템

알림이 너무 많으면 결국 안 보게 되고, 너무 적으면 중요한 순간을 놓쳐요. 처음 봇을 돌릴 때는 30초마다 “포지션 없음” 같은 무의미한 로그가 하루 수천 건씩 쌓여서, 정작 중요한 에러가 그 안에 묻혀버렸습니다. 그래서 “평상시엔 조용하고, 상태가 바뀔 때만 한 번 울리는” 패턴으로 알림 체계를 다시 짰어요.

예를 들어 데이터 채널 끊김은 발생할 때 한 번, 복구될 때 한 번만 알립니다. DB 장애도 같은 식이고요. “끊김 → 복구 → 끊김 → 복구”의 상태 전환만 알림으로 받으니 슬랙 채널이 훨씬 깨끗해졌고, 에러를 놓치는 빈도가 오히려 줄었어요.

두 번째 변화는 알림 자체가 매매 로직을 막지 않게 만든 것입니다. 기존엔 슬랙 호출이 동기 방식이라, 슬랙이 느린 날에는 진입·청산 로직이 잠깐씩 멈추는 부작용이 있었어요. 알림은 부수 작업이지 매매의 본업이 아니잖아요. 알림 전송을 별도 백그라운드 작업으로 분리해서 매매 로직과 완전히 떨어뜨렸고, 동시에 같은 알림이 두 번 발송되는 경쟁 상태도 잠금으로 막았습니다.

영역 ④ 코드 리뷰가 잡아준 숨은 버그

실전 운영을 들어가기 직전에 코드를 한 번 더 훑어봤는데, 거기서 잡힌 버그 몇 개가 있었어요. 혼자 만들면 무조건 놓치는 종류의 함정이라는 게 인상적이었습니다.

대표적인 게 “특정 조건에서만 실행되는 가지에서, 변수가 정의되기 전에 사용되고 있던” 케이스였어요. 평소엔 안 들어가는 가지라 테스트에서도 안 잡히고, 실전에서 신호가 발생하는 그 순간에야 에러로 터지는 종류의 버그입니다. 또 하나는 데이터 보충 작업이 비동기로 돌아가는 도중에 또다시 연결이 끊어지면, 이전 보충 작업이 완료될 때 잘못된 “복구 알림”이 발송되는 경쟁 상태였어요. 두 작업이 시간 순서에 어떻게 얽히는지 머리로만 시뮬레이션하면 절대 안 보이는 결함이었습니다.

이 영역에서 배운 건 단순했어요. “실전 직전의 마지막 코드 리뷰는 시간 낭비가 아니라 그물망”이라는 거예요. 특히 비동기·동시성·예외 경로 같은 영역은 사람이 한 번 더 머리를 굴려야 잡히는 지점이 분명히 존재합니다.

영역 ⑤ 거래 로직 자체의 문제 (3가지) — 별도 글로

마지막 영역은 운영 인프라가 아니라 매매 로직 자체의 결함이었어요. 주문 수량 계산, 손절 주문 체결 감지, 일괄 취소 후 잔류 주문 검증 — 이렇게 3가지입니다. 이 3가지는 첫 실전 거래를 통해 발견·수정한 내용이라 따로 글로 정리해뒀어요. 자세한 이야기는 코인 자동매매 봇 첫 실전 거래 결과 — 손절 성공, 실전에서 배운 3가지에서 다루고 있으니 함께 보시면 안정성 개선의 큰 그림이 잡힐 거예요.

개선 전 vs 개선 후, 운영이 이렇게 달라졌습니다

한 줄로 요약하면, 예전에는 “봇이 죽었는지 살았는지도 몰랐던” 상태에서 지금은 “오류가 나면 알아서 고치고, 못 고치면 알려주는” 상태가 됐습니다. 매일 사람이 들여다보지 않아도 슬랙 알림 1~2개로 봇 상태가 한눈에 들어와요.

운영하면서 깨달은 핵심 원칙 3가지

첫째, 자동매매의 본질은 “전략”이 아니라 “죽지 않는 시스템”이다. 처음엔 좋은 매매 전략을 만드는 게 가장 중요하다고 생각했어요. 막상 24시간 돌려보니 전략의 우위는 봇이 살아 있어야 의미가 있더라고요. 봇이 8시간 멈춰 있던 날과 24시간 돌아간 날을 비교하면, 같은 전략이어도 결과가 전혀 다릅니다. 운영의 안정성이 전략의 기댓값을 결정하는 토대였어요.

둘째, 알림은 “더 보내기”가 아니라 “노이즈 빼기” 게임이다. 처음엔 알림을 늘릴수록 안전해진다고 생각했어요. 그런데 오히려 알림이 많아질수록 사람이 그걸 무시하게 되고, 결과적으로 가장 중요한 알림을 놓치는 역효과가 났습니다. “상태가 바뀌었을 때만 한 번 말한다”가 더 안전했어요. 이 원칙은 다른 자동화 프로젝트에도 그대로 적용하고 있습니다.

셋째, 코드 리뷰는 실전 직전의 마지막 그물망이다. 혼자 만들고 혼자 운영하는 사이드 프로젝트에서는 코드 리뷰를 건너뛰기 쉬워요. 그런데 비동기·동시성·예외 경로 같은 영역에서는 한 번 더 머리를 굴려야 잡히는 결함이 분명히 존재합니다. 짧은 시간이라도 “실전 직전에 다시 한 번 본다”가 운영 사고를 줄이는 가장 싼 방법이에요.

자주 묻는 질문

Q. 11가지 안정성 문제를 다 잡는 데 얼마나 걸렸나요?

A. 전체적으로 약 한 달 정도 걸렸어요. 한 번에 다 잡은 건 아니고, 운영 중 문제를 발견할 때마다 1~2개씩 추가로 처리하는 식이었습니다. 처음 사건(서버 재시작 후 봇 미복구)을 잡고 나서, 그 옆에 비슷한 잠재 결함이 보이면 같이 정리하는 흐름이었어요. 처음부터 11가지를 한꺼번에 설계하려고 했다면 오히려 늦어졌을 거라고 생각합니다.

Q. 어떤 영역이 가장 효과가 컸나요?

A. 체감으로는 영역 ①(서버 재시작 자동 복구)과 영역 ③(상태 전환 알림)이 가장 컸어요. ①은 “잠자는 동안 봇이 죽어 있는 시나리오”를 통째로 없애줬고, ③은 “알림 채널을 다시 보고 싶게” 만들어줬습니다. 알림을 신뢰할 수 있게 되니, 봇 상태에 대한 불안 자체가 줄었어요.

Q. 자동매매를 시작하려는 사람에게 가장 먼저 권하고 싶은 건 뭔가요?

A. “전략 설계 전에 운영 환경부터 만들어 보세요”라고 말하고 싶어요. 봇이 어떻게 동작하는지 보기 전에, 봇이 어떻게 살아남고 어떻게 죽는지를 먼저 경험해 보면 전략 설계의 우선순위가 완전히 바뀝니다. 슬랙 알림 채널 하나 연결해보는 것부터 시작해도 충분해요.

Q. 안정성 개선 후에도 새로운 문제가 또 생기나요?

A. 네, 계속 생겨요. 운영 환경·거래소 정책·네트워크 상황은 끊임없이 바뀌니까요. 다만 이제는 새 문제가 생겨도 슬랙 알림으로 즉시 알게 되고, 영향 범위가 작은 동안 잡을 수 있게 됐습니다. “문제를 없애는 운영”이 아니라 “문제를 빠르게 알아채는 운영”으로 시각이 바뀐 거예요.

* 이 글은 개인적인 프로젝트 운영 경험을 공유하는 것이며, 투자 추천이 아닙니다. 가상화폐 선물 거래는 원금 손실 위험이 크며, 모든 투자 판단과 책임은 본인에게 있습니다.