자동매매 운영자는 코드를 다 아는 사람이 아니라, AI와 함께 검증 가능한 질문을 만드는 사람이다
요약
분할익절이 실행되지 않는 문제를 발견한 것은 코드 전문가가 아니었다. 운영자 관점에서 실거래 로그를 보다가 수익률이 임계값을 넘었는데도 분할익절이 발생하지 않는다는 이상 징후를 포착했다. 이후 전문가 AI와 함께 실행 경로를 따라가며 문제 지점을 좁혔다. 코드를 전부 이해하지 않아도, 올바른 질문과 검증 루프가 있으면 문제를 찾을 수 있었다.
이상 징후를 먼저 발견했다
분할익절 조건은 설정되어 있었고, 전략 로직도 구현되어 있었다. 그런데 로그를 보면 조건이 충족될 만한 수익률에서도 PARTIAL_SELL이 한 번도 발생하지 않았다. 설정 파일을 확인했고, 수치도 이상 없었다.
이 시점에서 스스로 코드 전체를 뒤지는 대신 AI에게 실행 경로를 따라가달라고 요청했다. 조건식 자체가 아니라, 그 조건식이 올바른 인자를 받고 있는지 먼저 확인하자는 것이었다.
문제 지점은 조건식 안에 없었다
AI와 함께 실행 경로를 추적한 결과, 문제는 rule_engine의 로직이 아니었다. scheduler.py의 장중 5분 매도 루프에서 check_sell_signal을 호출할 때 실제 보유수량(total_qty)과 partial_sold 상태를 넘기지 않고 있었다. total_qty=0이 전달되면 PARTIAL_SELL 분기는 구조적으로 진입할 수 없다.
이 사실을 확인한 뒤에야 수정 방향이 분명해졌다. 조건식을 건드리는 게 아니라, 호출 경로에서 필요한 값을 연결하는 것이었다.
여기서 중요한 점이 있다. AI가 대신 분석해서 정답을 준 게 아니다. 운영자가 “왜 실행되지 않지?”라는 질문을 구체적으로 만들고, AI가 그 경로를 따라가며 가설을 검증하는 과정이었다. 질문의 방향을 운영자가 잡았다.
수정 완료의 기준을 다시 정의했다
코드를 수정하고 저장하면 끝난다고 생각할 수 있다. 그런데 이미 실행 중인 Python 프로세스는 코드 변경을 인식하지 못한다. 수정 사항이 실제 루프에 반영되려면 프로세스를 재시작해야 한다.
그리고 재시작만으로도 충분하지 않다. 재시작 후 실제 루프에서 PARTIAL_SELL이 반환되는지, partial_sold=True가 저장되는지, 다음 루프에서 재조회되는지, 잔여수량이 트레일링스탑으로 이어지는지를 순서대로 확인해야 했다.
수정 완료의 기준은 파일 저장 시점이 아니라, 다음 스케줄러 루프에서 상태 저장과 재조회가 실제로 확인된 시점이다.
AI 협업에서 운영자의 역할
이번 경험을 통해 정리한 것이 있다.
자동매매 운영자는 코드 전체를 이해하는 사람일 필요가 없다. 하지만 아래 세 가지는 운영자의 역할이다.
- 로그와 결과에서 이상 징후를 발견하는 것
- 이상 징후를 검증 가능한 질문으로 좁히는 것
- AI가 제시한 경로와 결과를 운영 관점에서 판단하는 것
AI는 경로를 따라가는 데 능하다. 코드를 읽고, 패턴을 찾고, 가설을 검증하는 작업을 빠르게 처리한다. 하지만 어느 경로를 먼저 볼지, 결과가 운영 목적에 맞는지 판단하는 건 운영자의 몫이다.
AI 협업의 핵심은 대행이 아니라, 운영자가 스스로 판단할 수 있는 검증 루프를 만드는 것이다.
관련 Log: 자동매매 분할익절 실거래 검증 — 상태값이 다음 루프까지 이어지는지 확인했다
관련 Log: 분할익절이 실행되지 않은 이유 — scheduler 실행 경로와 로그 보안 정리