자동매매 분할익절 실거래 검증 — 상태값이 다음 루프까지 이어지는지 확인했다
이전 기록에서 분할익절이 실행되지 않은 원인을 찾았다. 장중 5분 매도 루프(job_intraday_sell)가 check_sell_signal을 호출할 때 실제 보유수량(total_qty)과 partial_sold 상태를 전달하지 않고 있었다. 수정은 어렵지 않았다. 실제 보유수량을 읽어 넘기고, order_log.json의 BUY 항목에서 partial_sold 상태를 읽어 함께 전달하면 됐다.
그런데 코드를 수정하고 저장했다고 해서 끝난 게 아니었다. Python 프로세스는 이미 실행 중이었다. 수정한 코드가 실제 루프에 반영되려면 프로세스를 재시작해야 했다.
이번 기록은 재시작 이후 실제 장중 스케줄러 경로에서 수정 사항이 정상 작동하는지 단계별로 확인한 내용이다.
확인한 상태 흐름
검증은 순서가 있었다. 로직 하나가 작동한다고 해서 전체 흐름이 연결된다고 볼 수 없다. 아래 체크포인트를 하나씩 따라갔다.
1. PARTIAL_SELL 반환 여부
수익률이 임계값을 넘었을 때 check_sell_signal이 PARTIAL_SELL을 반환하는지 확인했다. 수정 전에는 total_qty=0이 전달되어 이 분기에 진입 자체가 불가능했다. 수정 후에는 실제 보유수량이 전달되었고 조건 충족 시 PARTIAL_SELL이 반환되었다.
2. partial_sold=True 저장 여부
분할익절이 실행된 뒤 order_log.json의 BUY 항목에 partial_sold=True가 기록되는지 확인했다. 이 값이 저장되지 않으면 다음 루프에서 재분할익절이 방지되지 않는다.
3. 다음 루프에서 재분할익절 방지 여부
5분 뒤 다음 루프 진입 시 partial_sold=True가 재조회되는지 확인했다. 재조회되면 PARTIAL_SELL 분기에 진입하지 않는다. 잔여수량 전체가 트레일링스탑 대상이 된다.
4. 잔여수량 트레일링스탑 연속성 확인
분할익절 이후 잔여수량이 다음 루프에서도 트레일링스탑 대상으로 계속 관리되는지 확인했다. peak_price 갱신이 이어지고, 고점 대비 낙폭이 기준에 도달하면 트레일링 매도가 발동하는 구조다.
peak_price 복원 구조 확인
분할익절 후 잔여수량이 트레일링스탑으로 관리되려면 peak_price가 재시작 후에도 유지되어야 한다.
확인 결과, peak_price는 logs/trailing_stop.json에 저장된다. 파일 기반 저장이라 프로세스가 재시작되어도 기존 고점이 그대로 남는다. 별도의 복원 로직 없이 다음 루프에서 파일을 읽으면 고점이 자동으로 복원되는 구조다.
한 가지 확인한 점은, 일일 로그 초기화(reset_daily_logs)의 대상에 trailing_stop.json이 포함되지 않는다는 것이다. 고점은 매도 완료(remove_trailing_peak) 전까지 날짜가 바뀌어도 파일에 유지된다. 이월 보유 종목의 고점이 다음 날에도 연속으로 관리되는 구조가 의도된 설계라는 점도 함께 확인했다.
프로세스 재시작과 수정 반영
코드를 수정하고 저장해도 이미 실행 중인 Python 프로세스에는 즉시 반영되지 않는다. 수정 사항이 실제 루프에 적용되려면 프로세스를 재시작해야 한다.
이번 검증에서 얻은 판단 기준이다.
자동매매 수정의 완료 기준은 코드를 저장한 시점이 아니라, 프로세스 재시작 후 다음 스케줄러 루프에서 의도한 상태 저장과 재조회가 실제로 확인된 시점이다.
로그 보안 관찰
이번 검증 과정에서 로그에 텔레그램 토큰이나 계좌 식별자가 남지 않는지도 함께 관찰했다.
이전에 적용한 마스킹 필터(_RedactingFilter)가 logging 핸들러를 통과하는 경우를 처리하고, httpx 로그 레벨을 WARNING으로 조정해 HTTP 요청 URL이 로그에 출력되지 않도록 한 조치가 유지되고 있는지 확인했다. print() 직접 출력 경로에서도 계좌 식별자가 마스킹 형태(44****00)로 출력되는지 확인했다.
오늘의 판단
분할익절 수정이 실제 스케줄러 경로에서 작동하는지는 코드 리뷰만으로 확인되지 않는다. 프로세스 재시작 이후 실제 루프에서 상태가 저장되고, 다음 루프에서 그 상태가 재조회되는 흐름이 확인되어야 수정이 완료됐다고 할 수 있다.
이번 검증을 통해 확인한 것은 단순히 “분할익절이 됐다”가 아니다. 상태값이 루프 경계를 넘어 이어진다는 것, 그 연결이 끊기지 않는다는 것이다.
→ 분할익절이 실행되지 않은 이유 — scheduler 실행 경로와 로그 보안 정리
→ 자동매매 운영자는 코드를 다 아는 사람이 아니다
→ 자동매매 프로젝트 전체 기록
※ 이 글은 투자 권유가 아니라, 자동매매 프로그램을 운영하면서 AI와 함께 실행 경로·상태 저장·로그 보안을 점검한 운영 기록입니다.
투자의 판단과 책임은 본인에게 있습니다.