자동매매 봇이 멈추는 순간 — 장애·복구 플레이북

"VPS에 봇을 올려뒀으니 이제 24시간 알아서 돌겠지." 많은 분들이 여기서 안심합니다. 하지만 실제로 운영을 시작하면 곧 깨닫게 됩니다. 항상 켜두는 것과 안 깨지게 운영하는 것은 전혀 다른 문제라는 걸요. 이 글은 코드 설명이 아니라, "내 봇이 새벽에 멈추면 무슨 일이 벌어지고, 무엇이 그걸 안전하게 처리해 주는가"를 비개발자도 판단할 수 있게 풀어쓴 운영 플레이북입니다. 봇을 직접 만들든 맡기든, 이 글의 질문들에 답할 수 있어야 밤에 발 뻗고 잘 수 있습니다.

1. 진짜 위험은 '꺼진 봇'이 아니라 '반쯤 죽은 봇'

장애를 떠올리면 대부분 "봇이 꺼져서 매매를 못 한 것"을 걱정합니다. 물론 기회를 놓치는 손실은 있습니다. 하지만 운영을 오래 한 사람들이 진짜로 무서워하는 건 따로 있습니다. 봇이 완전히 꺼지지 않고, 일부 기능만 죽은 채로 계속 켜져 있는 상태입니다.

비유하자면 이렇습니다. 자동차 시동이 아예 꺼지면 차는 그냥 멈춰 섭니다 — 위험하지만 예측 가능합니다. 그런데 브레이크만 고장 난 채로 엔진은 계속 돌아간다면? 그게 훨씬 더 무섭습니다. 봇도 똑같습니다. 매수는 되는데 손절 로직만 죽으면, 포지션은 들고 있는데 가격이 반대로 가도 아무도 빠져나오지 않습니다.

그래서 무중단 운영의 목표를 정확히 다시 쓰면 이렇습니다. "절대 안 멈추게"가 아니라 — 그건 불가능합니다 — "멈춰도 안전한 상태로 멈추고, 빨리 알아채고, 깨끗하게 되살아나게" 만드는 것입니다. 이 셋이 핵심 키워드입니다. 이 글의 나머지는 전부 이 세 가지를 어떻게 확보하느냐에 대한 이야기입니다.

참고로 "봇을 어디에 올려 항상 켜둘 것인가"(VPS·systemd·도커 같은 토대)는 이 글의 범위가 아닙니다. 그 부분은 → VPS 24시간 운영 가이드에서 따로 다룹니다. 이 글은 그렇게 켜둔 봇이 깨지는 순간에 집중합니다. 둘은 짝을 이루는 글입니다.

2. 봇이 깨지는 8가지 순간 (장애 지도)

막연히 "멈출 수도 있지"보다, 실제로 어떤 순간에 깨지는지를 알아야 대비가 됩니다. 자동매매 운영에서 반복적으로 마주치는 장애는 크게 8가지로 정리됩니다. 거래소나 증권사가 코인이든 국내주식이든 본질은 비슷합니다.

이 목록을 보면 한 가지가 분명해집니다. 대부분의 장애는 "봇 코드의 버그"가 아니라 "봇 바깥 세상(네트워크·거래소·서버)의 변화"라는 점입니다. 그래서 매수·매도 로직을 아무리 잘 짜도, 바깥 세상의 변화에 어떻게 반응할지를 설계하지 않으면 운영은 불안정합니다. 초보가 만든 봇과 실전용 봇의 진짜 차이가 바로 여기서 갈립니다.

3. "그냥 재시작" 이 위험한 이유 — 중복 주문과 유령 포지션

"봇이 죽으면 자동으로 다시 켜면 되잖아?" 맞는 말이지만, 절반만 맞습니다. 자동 재시작은 반드시 필요한 장치입니다. 하지만 아무 생각 없이 그냥 재시작하면 더 큰 사고가 납니다. 왜 그런지 두 가지 대표 사고로 설명하겠습니다.

사고 ①: 중복 주문 (같은 걸 두 번 산다)

봇이 "BTC 매수" 주문을 거래소에 보냈습니다. 그런데 거래소가 "접수했어요" 응답을 보내주기 직전에 봇이 죽었습니다. 봇 입장에서는 "내가 주문을 냈는지 안 냈는지 모르는 상태"입니다. 이때 멍청하게 재시작한 봇이 "아직 매수 안 했네, 사자!" 하고 같은 주문을 또 내면 — 의도한 양의 두 배를 사게 됩니다. 변동성 큰 시장에서 이건 그대로 손실로 직결됩니다.

사고 ②: 유령 포지션 (있는 줄 모르는 포지션)

반대 경우도 있습니다. 봇이 멈춰 있는 동안 이미 걸어둔 주문이 체결돼 포지션이 생겼는데, 재시작한 봇은 자기 기억(메모리)에만 의존해 "난 아무것도 안 들고 있어"라고 착각합니다. 그럼 손절·익절 관리가 안 되는 유령 포지션이 방치됩니다. 위에서 말한 '브레이크 빠진 차'가 바로 이 상태입니다.

이 두 사고를 막는 원리는 사실 단순합니다. 봇이 다시 깨어날 때, 자기 기억을 믿지 말고 거래소에 직접 물어보면 됩니다. "지금 내 미체결 주문이 뭐가 있지? 내 포지션이 뭐지?"를 거래소에 조회해서 실제 상태로 자기 인식을 다시 맞추는 것 — 이것을 상태 복원(state reconciliation)이라고 합니다. 그리고 같은 신호로 주문을 두 번 내지 않도록 주문마다 고유 표식을 붙이는 장치를 멱등성(idempotency)이라고 부릅니다. 용어는 어렵지만 개념은 일상적입니다.

제작을 맡길 때 이 한 가지만 물어봐도 상대의 실력이 드러납니다. "봇이 주문 보내고 응답 받기 직전에 죽으면, 재시작했을 때 중복 주문을 어떻게 막나요?" 명확히 답하지 못한다면 운영 안정화 경험이 부족한 것입니다.

4. 장애 복구 플레이북 — 감지 → 자동복구 → 사람 호출

장애가 터졌을 때 우왕좌왕하지 않으려면, 미리 정해둔 흐름(플레이북)이 있어야 합니다. 좋은 봇은 이 흐름을 사람 대신 스스로 밟습니다. 핵심은 3단계 사다리입니다 — 먼저 스스로 고쳐보고(자동), 안 되면 안전하게 멈추고, 그래도 안 되면 사람을 부른다.

이 흐름을 말로 풀면 이렇습니다.

• ① 감지 — 무언가 잘못됐음을 알아챈다. 하트비트(살아있다 신호)가 끊겼거나, 에러가 반복되거나, 봇이 아는 상태와 거래소 실제 상태가 어긋났을 때.
• ② 자동 복구 — 가벼운 장애(잠깐 끊김, 일시적 거부)는 사람 개입 없이 스스로 해결한다. 잠시 기다렸다가 다시 접속하고, 횟수를 정해 재시도하며, 깨어날 때 상태를 복원한다.
• ③ 안전 정지 — 자동 복구를 정해진 횟수만큼 시도해도 안 되면, 무리하게 매매를 이어가지 않고 신규 진입을 멈추고 포지션을 동결한다. 손해를 키우지 않는 쪽으로 멈추는 게 핵심이다.
• ④ 사람 호출 — 사람이 결정해야 하는 상황(키 만료, 거래소 장기 장애, 원인 불명)이면 즉시 알림을 보내 사람을 부른다. 이때 "그냥 죽었어요"가 아니라 "지금 포지션 X, 미체결 Y, 마지막 에러 Z"처럼 현재 상태를 요약해 줘야 사람이 빨리 판단한다.

5. 증상별 대응표 — 무엇이 자동이고 무엇이 사람 몫인가

위 8가지 장애를 플레이북에 대입하면, 무엇이 자동으로 처리되고 무엇이 사람을 부를 일인지 한눈에 정리됩니다. 제작을 맡길 때 "각 항목을 어떻게 처리하나요?"라고 이 표를 그대로 물어봐도 좋습니다.

표에서 분명해지는 사실 하나. 완전 자동으로 해결되는 건 가벼운 장애뿐이고, 키 만료·잔고 부족처럼 현실 세계의 조치가 필요한 일은 결국 사람이 해야 합니다. 그래서 "100% 무인 운영"은 환상에 가깝고, 현실적인 목표는 "자동이 90%를 막고, 나머지 10%를 사람이 늦지 않게 받는 체계"입니다. 다음 장이 그 '10%를 받는 체계'에 대한 이야기입니다.

6. 무중단을 만드는 설계 5원칙

지금까지가 "무슨 일이 일어나는가"였다면, 이제는 "그래서 봇을 어떻게 만들어야 하는가"입니다. 코드 없이, 의뢰자가 알아야 할 다섯 가지 설계 원칙으로 정리합니다.

원칙 ① 멈춰도 안전한 상태로 멈춘다 (페일세이프)

봇은 언젠가 반드시 멈춥니다. 그러니 "안 멈추게"가 아니라 "멈추는 방향을 안전하게" 설계합니다. 의심스러우면 새로 사는 쪽이 아니라 멈추는 쪽으로 기울게 만드는 것 — 이것이 페일세이프입니다. 애매할 때 공격적으로 진입하는 봇은 운영하면 할수록 사고가 쌓입니다.

원칙 ② 봇의 기억보다 거래소의 사실을 믿는다 (상태 복원)

3장에서 다룬 그 원리입니다. 봇이 재시작하거나 헷갈릴 때, 자기 메모리가 아니라 거래소에 실제 포지션·미체결을 물어 자기 인식을 맞춥니다. 이 한 가지가 중복 주문과 유령 포지션을 동시에 막습니다. 실전 봇과 장난감 봇을 가르는 가장 중요한 선입니다.

원칙 ③ 같은 일을 두 번 하지 않는다 (멱등성)

"이미 처리한 신호인가?"를 표식으로 구분해, 네트워크가 꼬여 같은 명령이 두 번 들어와도 한 번만 실행되게 합니다. 사람으로 치면 "아까 이미 보낸 메시지인지 확인하고 보내는" 습관입니다. 이게 없으면 재시도 로직 자체가 사고의 원인이 됩니다.

원칙 ④ 밖에서 지켜보는 눈을 둔다 (외부 감시)

봇이 스스로 "나 죽었어요"라고 알리는 데는 한계가 있습니다 — 죽은 사람은 부고를 못 씁니다. 그래서 봇과 별개로 도는 감시자가 "이 봇이 일정 시간 살아있다 신호를 안 보냈다"를 보고 알람을 울려야 합니다. 단일 실패점(한 군데 죽으면 전체가 죽는 구조)을 없애는 일입니다.

원칙 ⑤ 모든 것을 기록한다 (관측 가능성)

장애가 터졌을 때 "왜 그랬지?"에 답하려면 그 순간의 기록이 있어야 합니다. 주문·체결·에러·상태 변화를 시간순으로 남겨두면, 사고 후 원인 추적은 물론 세금 정리에도 쓰입니다. 기록 없는 봇은 사고가 나면 영영 원인을 모른 채 같은 사고를 반복합니다.

7. 그래도 사람은 자야 한다 — 알림·당직 체계

자동 복구가 아무리 좋아도 5장에서 봤듯 일부는 사람 몫입니다. 그런데 사람은 24시간 화면을 볼 수 없습니다. 그래서 필요한 게 "중요한 일만 깨우는" 알림 체계입니다. 핵심은 모든 걸 알리는 게 아니라, 사람이 행동해야 할 것만 골라 알리는 것입니다.

알림이 너무 많으면 어떻게 될까요? "알림 피로"가 생깁니다. 하루에 사소한 알림이 30번 울리면, 정작 새벽에 진짜 중요한 알림이 와도 무시하고 자게 됩니다. 그래서 알림에도 등급이 필요합니다.

실전에서는 보통 텔레그램 같은 메신저로 알림을 받습니다. 긴급 알림은 별도 채널·소리로, 참고 알림은 조용한 채널로 분리합니다. 여기에 봇이 일정 주기로 "정상 가동 중" 요약(예: 하루 한 번 또는 매시 상태)을 보내주면, "소식이 없는 게 좋은 소식"이 아니라 "정상이라는 능동적 확인"을 받게 되어 훨씬 안심됩니다.

이 모든 것의 토대(VPS에 항상 켜두기, 자동 재시작 설정, 텔레그램 봇 토큰 발급 같은 기초 세팅)는 → VPS 24시간 운영 가이드에 단계별로 정리돼 있으니 함께 보면 그림이 완성됩니다.

8. 직접 할까, 맡길까 — 그리고 비용

여기까지 읽고 "생각보다 운영이 복잡하네"라고 느끼셨다면 정상입니다. 그게 핵심입니다. 자동매매에서 진짜 어려운 부분은 매수·매도 신호가 아니라, 그 봇을 안 깨지게 운영하는 일이기 때문입니다. 그래서 선택지를 솔직하게 정리하면:

알고랩에 오시는 분의 상당수는 매수·매도 로직은 직접 만들었지만 "운영 중에 자꾸 깨지고, 원인을 모르겠다"는 단계에서 찾아오십니다. 그만큼 운영 안정화는 따로 떼어내 보강할 수 있는 영역이기도 합니다. 비용은 전략 복잡도와 안전장치 범위에 따라 달라집니다(아래는 대략적인 기준이며 상세 산정은 → 제작 비용·견적 가이드 참고).

자주 묻는 질문