자동매매 실전 투입 전 점검 — 운영 체크리스트로 정리하기

왜 체크리스트가 필요했나

지금까지 이 시리즈에서는 안전장치, 리스크 관리 규칙, 모의투자 환경, 무인 운영과 장애 대응을 각각 따로 다뤘다. 문제는 이 지식들이 머릿속에 흩어져 있으면 실제로 실전 투입을 앞둔 순간 무엇을 빼먹었는지 확인할 방법이 없다는 것이었다. 사람은 급할 때, 혹은 "이번엔 그냥 되겠지"라는 낙관 속에서 점검 항목을 건너뛰기 쉽다. 그래서 지금까지의 경험을 하나의 실행 가능한 체크리스트로 정리해두기로 했다. 이 글은 그 체크리스트 자체와, 각 항목을 왜 넣었는지에 대한 맥락을 담는다.

체크리스트를 만들 때 지킨 원칙

체크리스트를 만들면서 두 가지 원칙을 정했다. 첫째, 각 항목은 "예/아니오"로 명확히 답할 수 있어야 한다. "리스크 관리가 잘 되어 있는가" 같은 모호한 항목은 체크리스트로서 기능하지 못한다. "포지션당 최대 손실 한도가 코드로 강제되어 있고, 이 한도를 우회할 수 있는 경로가 없는가"처럼 구체적이어야 실제로 확인이 가능하다. 둘째, 항목 하나하나가 과거에 실제로 문제가 됐거나, 문제가 될 뻔했던 지점에서 나와야 한다. 이론적으로 있으면 좋을 것 같은 항목을 늘리기 시작하면 체크리스트가 끝없이 길어지고, 결국 아무도 끝까지 확인하지 않게 된다.

체크리스트 — 5개 영역

1. 인증·키 관리

[ ] API 키·토큰이 코드에 하드코딩되어 있지 않고 환경변수 또는 별도 설정 파일로 분리되어 있는가
[ ] 그 설정 파일이 .gitignore에 등록되어 있고, 실제로 커밋 이력에 남아있지 않은지 확인했는가
[ ] 토큰 만료·재발급 로직이 있고, 장시간 실행 중 토큰이 만료돼도 조용히 실패하지 않고 재시도하는가

2. 리스크 관리

[ ] 포지션당 최대 손실 한도, 일일 최대 손실 한도가 코드로 강제되어 있는가 (사람이 지키기로 "약속"만 한 규칙이 아닌가)
[ ] 한도에 도달했을 때 시스템이 스스로 판단해 넘어가지 않고 반드시 정지 후 사람의 확인을 기다리는가
[ ] 전략 신호 생성 로직과 손절·리스크 판단 로직이 분리되어 있어, 한쪽에 버그가 나도 다른 쪽이 같이 무력화되지 않는가

3. 데이터·전략 검증

[ ] 실전에 쓰는 전략이 백테스팅과 모의투자(페이퍼 트레이딩) 단계를 모두 거쳤는가
[ ] 결측치·이상치가 발생했을 때 시스템이 이를 명시적으로 감지하고 표시하는가, 아니면 조용히 넘어가는가
[ ] 모의투자 환경과 실전 환경의 API 엔드포인트(base URL)가 코드 레벨에서 명확히 분리되어 있어 혼동될 여지가 없는가

4. 모니터링·알림

[ ] "즉시 대응 필요 / 확인 필요 / 기록만" 세 층위로 알림 기준이 나뉘어 있는가
[ ] 데이터 수신이 끊기거나 지연되는 상황을 시스템이 스스로 감지해 알리는가 (사람이 화면을 봐야만 아는 구조는 아닌가)
[ ] 장애 원인 추적에 필요한 로그(주문 요청·응답, 판단 근거, 시각)가 충분히 남는가

5. 승인·개입 절차

[ ] 특정 조건(리스크 한도 도달, 예상 밖 오류) 발생 시 시스템이 자동으로 계속 진행하지 않고 반드시 정지하는 경로가 있는가
[ ] 그 정지 상태에서 사람이 확인하고 재개하는 절차가 명확히 정의되어 있는가
[ ] 이 승인 절차 자체를 우회할 수 있는 코드 경로가 남아있지 않은가 (임시로 넣었다가 지우는 걸 잊은 디버그용 우회 로직 등)

체크리스트를 쓰면서 발견한 함정

이 체크리스트를 실제로 적용해보면서 알게 된 게 있다. 항목 자체는 다 맞는 말인데, "체크했다"는 표시를 남기는 것과 "실제로 그 항목이 지켜지고 있는지 코드를 열어서 확인하는 것" 사이에 큰 차이가 있었다는 점이다. 예를 들어 "리스크 한도가 코드로 강제되어 있는가"라는 항목에 체크를 하려면, 실제로 그 한도 값을 우회할 수 있는 다른 진입 경로가 없는지 코드를 추적해봐야 한다. 단순히 "그런 로직을 짰다"는 기억만으로 체크하면 체크리스트가 형식적인 서류로 전락한다. 그래서 우리는 각 항목에 "확인 방법"을 같이 적어두는 방식으로 바꿨다. 예를 들어 "손실 한도 우회 경로 없음"이라는 항목 옆에는 "리스크 판단 함수를 호출하지 않고 주문 함수에 직접 접근하는 코드 경로가 있는지 grep으로 확인"처럼 구체적인 확인 방법을 남겼다.

체크리스트는 한 번 쓰고 끝나는 게 아니다

또 하나 배운 건, 이 체크리스트가 "실전 투입 시점에 한 번 확인하고 끝"이 아니라는 것이다. 코드가 바뀔 때마다, 특히 리스크 관리나 인증 관련 로직을 건드릴 때마다 이 체크리스트를 다시 훑어보는 습관이 필요했다. 무인 운영 경험에서 배웠듯, 한 번 고친 문제도 다른 경로로 다시 나타날 수 있기 때문이다. 체크리스트는 정적인 문서가 아니라, 시스템이 바뀔 때마다 같이 갱신하고 재확인하는 살아있는 절차로 다뤄야 한다는 결론에 이르렀다.

오늘의 정리

체크리스트의 각 항목은 "예/아니오"로 답할 수 있을 만큼 구체적이어야 하고, 실제 경험에서 나온 것이어야 한다.
인증·키 관리, 리스크 관리, 데이터·전략 검증, 모니터링·알림, 승인·개입 절차 다섯 영역으로 나눠 정리했다.
"체크했다"는 표시와 "실제로 지켜지는지 코드로 확인했다"는 다르다 — 항목마다 구체적인 확인 방법을 같이 적어야 형식화를 막을 수 있다.
체크리스트는 실전 투입 시점 한 번이 아니라, 코드가 바뀔 때마다 다시 훑어봐야 하는 살아있는 절차다.

다음 글에서는 이 체크리스트를 지키기 쉽게 만들어주는 기초 작업, 즉 파이썬 자동매매 프로젝트를 처음부터 어떻게 구조화하는지를 다룬다.

이 체크리스트는 익명화된 실제 운영 경험을 바탕으로 일반화한 것이며, 특정 시스템의 실제 구성·수치·설정값을 포함하지 않습니다. 이 글은 투자 조언이 아니며 특정 종목이나 매매기법을 추천하지 않습니다. 수익을 보장하지 않으며, 투자 손실에 대한 책임은 투자자 본인에게 있습니다.