자동매매에서 신호를 만드는 것만으로는 결과를 확인할 수 없습니다.
그 신호가 실제로 어떤 결과를 냈는지 확인하려면, 신호를 본 시점과 결과를 읽은 시점이 정확히 연결되어야 합니다. 가격이 올랐는지 내렸는지만 보면 될 것 같지만, 어느 캔들을 결과로 볼지 어긋나면 계산 자체가 달라집니다. 시간 하나가 꽤 중요했습니다.
저장소에는 전략 신호 결과 추적 기능을 추가한 기록이 남아 있습니다. 신호가 발생한 뒤 일정 시점의 결과를 조회하고, 그 결과를 바탕으로 신호의 수익률을 계산하는 흐름입니다. 처음부터 완성된 형태라기보다는, 결과를 추적하는 기능을 만든 뒤 그 주변의 시간 처리와 조회 과정을 계속 보완해간 모양에 가깝습니다.
확인된 문제 중 하나는 Bithumb 결과 캔들의 시간대 처리였습니다. 결과 캔들의 시각이 기대한 시간대 기준으로 처리되지 않으면, 신호 이후의 어느 캔들을 확인해야 하는지 판단하기 어려워집니다. 수익률 계산식이 틀린 게 아니어도, 엉뚱한 시점의 가격을 가져오면 결과는 달라질 수 있습니다.
그래서 Bithumb outcome candle의 timezone 처리를 수정했습니다. 여기서 중요한 건 단순히 날짜 표시를 바꾸는 일이 아니었습니다. 신호를 관측한 시간과 결과 캔들의 시간이 같은 기준으로 비교되어야 했습니다. 시간대가 다르면 코드가 조용히 실행되더라도 결과 해석이 틀어질 수 있으니까요. 이런 종류의 문제는 에러 메시지보다 결과값으로 먼저 나타날 가능성이 있어 더 까다롭습니다.
결과 조회 과정의 timestamp와 retry handling도 별도로 수정됐습니다. 외부 데이터에서 결과를 가져오는 작업은 한 번 조회했다고 바로 끝나지 않을 수 있습니다. 아직 필요한 캔들이 준비되지 않았거나 조회가 기대대로 되지 않는 경우를 고려해야 합니다. 다만 제공된 기록만으로 정확히 어떤 조건에서 재시도가 발생했는지, 수정 전 영향 범위가 어디까지였는지는 확인할 수 없습니다. 여기서는 결과 시각 처리와 재시도 로직이 수정됐다는 사실까지만 말할 수 있습니다.
이후에는 신호 관측 timestamp 테스트가 추가됐습니다. 결과를 계산하는 코드만 고치는 것과, 신호를 언제 관측했는지 검증하는 테스트를 남기는 건 조금 다른 문제입니다. 전자는 동작을 수정하는 일이고, 후자는 시간 기준이 다시 흔들리지 않도록 확인 지점을 만드는 일에 가깝습니다.
성과 계산도 단순 가격 변화에서 멈추지 않았습니다. 이후에는 수수료를 반영한 신호 수익률 계산이 추가됐습니다. 수수료 반영이 전략 성과를 개선했다는 뜻은 아닙니다. 오히려 신호 결과를 볼 때 실제 거래에 가까운 조건을 하나 더 포함하게 된 것입니다. 숫자가 조금 더 현실적으로 보이게 됐다고 해서 전략이 좋아진 건 아니고요. 그건 별개의 문제입니다.
현재 확인되는 흐름은 이렇습니다. 전략 신호 결과 추적을 추가하고, Bithumb 캔들의 시간대 처리와 결과 timestamp를 보완했으며, 조회 재시도와 관측 시각을 테스트 대상으로 넣었습니다. 여기에 수수료 반영 계산까지 더해지면서, 신호 결과를 단순한 가격 차이가 아니라 시점이 맞는 데이터로 확인하려는 방향이 분명해졌습니다.
다음에는 거래를 막는 안전 규칙 자체보다, 막힌 이유를 운영자가 정확히 알아볼 수 있게 만드는 문제가 등장합니다. 차단은 됐는데 설명이 맞지 않으면, 그것도 꽤 곤란하니까요.