자동매매를 24시간 무인으로 돌리며 겪은 것 — 모니터링과 장애 대응

사람이 안 봐도 도는 시스템이라는 착각

모의투자 단계를 충분히 돌리고, 리스크 관리 규칙과 승인 절차까지 갖춘 뒤 시스템을 무인으로 운영하기 시작했을 때 가장 먼저 든 생각은 "이제 손이 덜 갈 것"이라는 착각이었다. 실제로는 정반대였다. 사람이 계속 화면을 보고 있지 않다는 것 자체가 새로운 종류의 부담이었다. 문제가 생겨도 누군가 바로 알아차린다는 보장이 없는 상태로 시스템을 돌린다는 뜻이었기 때문이다. 이번 글은 그 무인 운영 기간 동안 실제로 겪은 모니터링과 장애 대응 이야기를 실적 수치 없이, 겪은 것 위주로 정리한다.

첫 장애 — 무엇이 문제였고 무엇을 배웠나

무인 운영을 시작하고 얼마 지나지 않아 첫 장애를 겪었다. 구체적인 서버 구성이나 내부 시스템 상세는 이 글에서 다루지 않는다. 다만 핵심만 남기면, 데이터 수신 경로 한쪽이 일시적으로 끊긴 상황에서 시스템이 "끊겼다"는 사실을 곧바로 알아차리지 못하고 한동안 조용히 대기 상태로 남아있었다.

돌이켜보면 이건 앞서 011번 글에서 다룬 "결측치를 명시적으로 표시해야 한다"는 원칙, 그리고 003번 글에서 다룬 "데이터 끊김에 대한 방어 부재" 문제와 정확히 같은 종류였다. 모의투자 단계에서 이미 발견하고 고쳤다고 생각했던 유형의 문제가, 실전에 가까운 무인 운영 환경에서 조금 다른 형태로 다시 나타난 것이다. 이 경험에서 얻은 가장 중요한 교훈은 "한 번 고쳤다고 완전히 사라지는 문제는 없다"는 것이었다. 같은 범주의 문제가 다른 경로로 다시 발생할 수 있다는 전제를 갖고 운영해야 한다.

알림 설계 — 무엇을, 어떤 기준으로 알릴 것인가

무인 운영에서 가장 먼저 정리해야 했던 건 "무엇이 일어나면 사람에게 알려야 하는가"였다. 처음에는 알림을 너무 촘촘하게 설계해서, 정상적인 상황에서도 알림이 계속 울리는 문제가 있었다. 알림이 너무 잦으면 정작 중요한 알림을 무시하게 되는 역효과가 생긴다는 걸 직접 겪고 나서야 체감했다.

결국 알림 기준을 대략 세 층위로 나누어 정리했다.

즉시 대응 필요: 데이터 수신 중단, 승인 절차 우회 가능성이 있는 코드 경로 진입, 리스크 한도 도달 같은 상황.
확인은 필요하지만 즉시 대응은 아닌 것: 예상보다 느린 응답 시간, 반복되지만 자동 복구되는 일시적 오류.
로그로만 남기고 알리지 않는 것: 정상 범위 내의 변동, 예상된 재시도.

이 구분을 명확히 하고 나서야 알림이 "진짜 신호"로 기능하기 시작했다. 알림 설계는 시스템을 처음 만들 때보다, 실제로 돌려보면서 반복적으로 조정해야 하는 영역이라는 걸 배웠다.

장애 대응 원칙 — 자동 복구와 사람 개입의 경계

무인 운영이라고 해서 모든 것을 자동으로 복구하도록 만드는 게 항상 정답은 아니었다. 오히려 우리는 "자동으로 복구해도 되는 것"과 "반드시 사람이 확인해야 하는 것"을 미리 나눠두는 게 더 중요하다는 결론에 이르렀다. 예를 들어 일시적인 네트워크 오류로 인한 재시도는 자동으로 처리해도 괜찮지만, 리스크 한도에 걸리거나 승인 절차와 관련된 이상 상황은 시스템이 스스로 판단해서 넘어가지 않고 반드시 정지 후 사람의 확인을 기다리도록 만들었다. 이 경계를 명확히 긋지 않으면, 시스템이 "알아서 잘 넘어갔다"고 착각하는 사이 문제가 누적될 수 있다는 게 우리 판단이었다.

로그 없이는 아무것도 알 수 없다

무인 운영 기간 동안 가장 값어치를 한 건 화려한 대시보드가 아니라 지루할 정도로 꾸준히 쌓인 로그였다. 알림은 "지금 무슨 일이 일어났다"는 것만 알려주지만, 그 일이 왜 일어났는지, 그 앞뒤로 시스템이 어떤 상태였는지는 로그를 뒤져야만 알 수 있었다. 장애 대응을 몇 차례 겪으며 확인한 건, 로그가 부족했던 순간마다 원인 파악에 훨씬 오랜 시간이 걸렸다는 사실이다. 이후로는 "이 정보가 나중에 장애 원인을 추적할 때 필요할까"를 기준으로 로그 항목을 계속 추가해나갔다.

오늘의 정리

무인 운영은 손이 덜 가는 상태가 아니라, 사람이 즉시 알아차리지 못한다는 전제를 깔고 대비해야 하는 상태다.
한 번 고친 문제라도 다른 경로로 다시 나타날 수 있다는 전제를 두고 운영해야 한다.
알림은 즉시 대응·확인 필요·기록만이라는 층위로 나눠야 진짜 신호로 기능한다.
모든 것을 자동 복구하기보다, 반드시 사람이 확인해야 하는 경계(리스크 한도, 승인 절차)를 미리 명확히 그어둬야 한다.
화려한 도구보다 꾸준히 쌓인 로그가 장애 원인 파악에 가장 크게 기여했다.

다음 글에서는 지금까지 쌓아온 리스크 관리·모니터링 경험을 하나의 운영 체크리스트로 정리해본다.

이 글은 자동매매 시스템 운영 경험을 익명화해 정리한 것으로, 실제 수익률·손실률·방문자 수 등의 수치는 다루지 않습니다. 서버 구성, 내부 시스템 상세, 계좌 정보 등은 보안상 공개하지 않습니다. 이 글은 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 투자 손실에 대한 책임은 투자자 본인에게 있습니다.