이중 안전장치처럼 보였다
봇이 종목을 살지 말지 정할 때 언어 모델을 두 번 부르는 구간이 있었다.
- 첫 번째 호출이 "산다 / 안 산다"와 확신도를 낸다.
- 두 번째 호출이 그 결과를 받아 "승인 / 거부"와 위험 점수를 낸다.
설명하기 좋은 구조다. 한쪽이 잘못 판단해도 다른 쪽이 잡아준다는 이야기가 되니까. 나는 이 구간을 안전장치로 세어두고 있었다.
88건을 전수로 뜯어봤다
이 구간이 실제로 무엇을 했는지 한 번도 센 적이 없다는 것을 깨닫고, 남아 있는 호출 기록 88건을 전부 펼쳤다. 확인하려던 것은 하나다. 두 번째 판단이 첫 번째와 다른 말을 한 적이 있는가.
위험 점수와 확신도의 불일치가 0건이었다. 88건 전부에서 두 값이 같았다.
처음에는 두 판단이 잘 맞는다는 뜻으로 읽고 싶었다. 그러나 두 모델이 독립적으로 판단해서 88번 연속으로 소수점까지 일치할 확률은 사실상 없다. 일치가 아니라 복사다.
이유는 내가 적어둔 한 줄이었다
두 번째 호출에 주는 지시문을 열어봤다. 거기에 "앞 단계의 확신도와 같은 의미로 그대로 옮겨 적으라"고 적혀 있었다. 내가 쓴 문장이다.
두 번째 모델은 검증하라는 요구를 받은 적이 없었다. 받아 적으라는 요구를 받았고, 정확히 그것을 했다. 이중 안전장치라고 부르던 구간은 사실 값 하나를 복사하는 데 호출 한 번과 비용을 쓰고 있었다.
더 결정적인 것은 따로 있었다
지시문이 그렇더라도, 모델이 자기 판단으로 한 번쯤 어긋났다면 이야기가 달라진다. 그래서 두 가지를 따로 셌다.
- 확신도가 기준선을 넘었는데 두 번째가 거부한 사례: 0건
- 확신도가 기준선에 미달인데 두 번째가 승인한 사례: 4건
방향이 한쪽으로만 났다. 이 구간이 독자적 판단을 더한 적은 한 번도 없고, 대신 틀린 쪽으로 어긋난 적은 네 번 있었다. 그 네 번은 뒤에 있던 코드의 임계 검사가 잡아서 실제 주문으로는 나가지 않았다.
정리하면 이 호출이 시스템에 기여한 것은 오류뿐이었다. 보호는 한 건도 하지 않았고, 없었으면 생기지 않았을 잘못된 승인을 네 번 만들었다.
폐지하니 결과가 전부 같았다
두 번째 호출을 빼고 같은 88건을 다시 태웠다. 매수 여부가 바뀐 건이 하나도 없었다.
당연한 결과다. 두 번째가 내놓는 값이 첫 번째의 복사본이면, 그 값으로 하는 판정은 첫 번째로 하는 판정과 같은 판정이다. 검증이 아니라 같은 질문을 두 번 한 것이었다.
💡 두 판단이 100% 일치하면 그것은 검증이 통과한 것이 아니라 검증이 없다는 뜻이다. 독립적인 두 판단은 반드시 어느 정도 갈린다. 갈리지 않는다면 둘 중 하나는 다른 하나를 보고 있다.
아무 일도 안 하게 된 설정이 기동을 붙잡고 있었다
폐지하려고 호출 주변을 따라가다 별개의 것을 하나 발견했다. 이 두 번째 호출에 쓰던 모델 설정이, 이제 아무 일도 하지 않게 된 뒤에도 여전히 프로그램 기동의 필수 조건으로 남아 있었다.
구조가 이랬다. 시작할 때 모델 설정을 조회하고, 조회가 비면 자동매매 전체를 비활성화한다. 쓰지 않는 값인데 없으면 전체가 멈춘다.
실제 위험은 이렇게 생긴다. 화면에서 사용 모델을 다른 것으로 바꾸면 그 이름의 설정이 조회되지 않고, 그러면 자동매매가 조용히 꺼진다. 에러 화면도, 경고도 없다. 그냥 그날 한 건도 사지 않는다.
쓰지 않게 된 것을 지우지 않으면, 그것이 여전히 무언가를 붙잡고 있다.
남은 것
두 번째 의견은 첫 번째를 모르는 상태에서 물어야 의견이다. 앞 단계의 결론과 점수를 그대로 넘겨주면 뒤 단계는 그것을 정답으로 읽는다. 검증을 원하면 판단 근거가 되는 원자료를 주고, 앞의 결론은 빼야 한다.
합의율은 검증의 품질 지표가 아니다. 100%는 최고점이 아니라 경고다. 나는 이 구간을 몇 달 동안 안전장치로 세어두고 있었는데, 그동안 세어본 것은 "존재한다"뿐이고 "무엇을 했다"는 한 번도 세지 않았다.
안전장치는 반대 방향 사례로 센다. "막아준 적이 몇 번인가"와 "잘못 통과시킨 적이 몇 번인가"를 나란히 놓으면 순기여가 바로 보인다. 앞이 0이고 뒤가 4면 그것은 안전장치가 아니라 위험 요인이다.