로그는 있었는데, 로그가 답하지 못했다

봇은 처음부터 로그를 남기고 있었다. 매수했을 때, 매도했을 때, 가격과 시각과 사유 코드까지. coin_trades 테이블만 열어봐도 "언제 얼마에 샀고 언제 얼마에 팔았는지"는 완벽하게 나온다. 그래서 처음 손실이 이상하다는 걸 느꼈을 때도 별 걱정을 안 했다. "로그 보면 금방 나오겠지." 그런데 정작 열어보니 로그에 없는 게 문제였다. 트레일링 스탑이 "발동했다"는 기록은 있는데, "발동해야 했는데 안 됐다"는 기록은 아예 존재하지 않았다. 봇 입장에서는 그 조건을 평가했고, 조건이 거짓으로 나왔고, 그래서 아무 일도 일어나지 않은 거다. 아무 일도 안 일어난 건 로그에 남지 않는다. 이게 핵심이었다. 나는 "무슨 일이 일어났는지"는 기록하고 있었지만, "무슨 일이 일어날 뻔했다가 막혔는지"는 하나도 기록하지 않고 있었다.

처음엔 이게 로그 설계 문제라고만 생각했다. 그런데 곰곰이 따져보니 더 근본적인 문제였다. 매매 로그는 "결과"를 남기는 구조였지 "판단 과정"을 남기는 구조가 아니었다. check_risk()가 호출될 때마다 peak_pct, peak_drop, trigger1 세 값을 비교하는데, 그 비교 결과는 함수 안에서만 잠깐 존재하다가 사라진다. None을 리턴하고 끝나면 그 판단 자체가 흔적도 없이 증발한다. 몇 달 동안 하루에도 수십 번씩 이 함수가 조용히 트레일링 스탑을 막고 있었는데, 나는 그걸 볼 방법이 아예 없었다. 있는 줄도 몰랐던 게 아니라, 볼 수 있는 구조 자체가 없었던 거다.

이 버릇은 코드 밖에서도 똑같았다

⑨편을 쓰면서 알게 된 사실 하나도 결이 같다. 그 편은 falette.org가 아니라 코인랩에 발행돼 있었다. 몇 주 동안 falette.org 게시판에서 ⑨편이 안 보인다는 걸 눈치도 못 챘다. 발행 버튼을 누른 기록은 어딘가에 있었을 텐데, "이 글이 어느 사이트에 최종적으로 올라갔는지"를 확인하는 절차가 따로 없었다. 봇의 트레일링 스탑이나, 글 발행 사이트나 — 결국 같은 구멍이었다. "실행했다"와 "실행한 결과가 내가 원하는 곳에 정확히 반영됐다" 사이에 확인 단계가 하나 빠져 있었던 거다. falette.org와 코인랩이 완전히 별개 사이트라는 걸 이미 알고 있었는데도 이런 일이 생겼다는 게, 계측 부재라는 게 특정 코드 한 줄의 문제가 아니라 운영 습관 전체의 문제라는 걸 다시 확인시켜줬다.

돌이켜보면 crontab suid 비트가 재부팅마다 풀리는 문제도 비슷한 결이었다. 매번 "왜 워치독이 안 도는거지" 하고 한참 헤매다가 결국 chmod u+s를 다시 걸어주는 식으로 넘어갔는데, 정작 "재부팅 후 suid 비트가 풀렸는지"를 확인하는 절차를 만들어둔 적은 없다. 매번 사람이 감으로 눈치채고 수동으로 고쳤다. NAS 하나 운영하면서 이런 식으로 감에 의존해 넘어간 지점이 한둘이 아니었다는 걸, 이번 편을 쓰려고 지난 기록들을 쭉 훑어보면서 새삼 깨달았다.

다음 편 — 그래서 뭘 버릴 것인가

⑫편에서는 반대 얘기를 하려고 한다. 계측을 더 붙이는 얘기 말고, 지금 있는 것 중에 뭘 버릴지에 대한 얘기. 다섯 개 매수 관문, 3단 손절, 국면 분류, 웹 명령 인터페이스 — 여기까지 열두 편 가까이 쌓아온 구조 중에서, 실제로 승패에 영향을 준 건 몇 개나 되고 그냥 안심하려고 넣어둔 건 몇 개나 되는지. 이번 편에서 다룬 "계측"이 바로 그 판단의 재료가 될 거다. 재는 게 없으면 버릴 것도 못 정하니까.