여덟 번 기록했는데도 합산할 수 없었습니다
글쓰기 규칙을 만들면서 파일럿을 여러 번 돌렸습니다. 원고를 쓰고, 무엇을 고쳤는지 남기고, QA 결과도 기록했습니다. 사례 여덟 편과 그에 대응하는 실행 기록 열두 회차가 쌓였을 때는 이제 어떤 규칙이 실제로 효과가 있었는지 비교할 수 있을 것 같았습니다.
다시 확인해보니 아니었습니다. 여덟 건 가운데 합산에 바로 쓸 수 있는 사례는 한 건도 없었습니다.
문제가 기록의 양은 아니었습니다. 사례 기록 여덟 편과 대응 실행 열두 회차의 QA 파일은 남아 있었습니다. 그런데 나중에 “이 규칙 때문에 이 문장이 이렇게 바뀌었고, 그 결과가 같은 버전에서 검증됐다”고 추적하려고 하자 연결이 끊겼습니다.
기록은 있었지만 같은 사건을 가리키지 않았습니다
가장 먼저 걸린 것은 버전이었습니다. 어떤 사례는 원고가 이동하거나 제목이 바뀌면서 당시 기록의 경로가 낡았습니다. 다른 사례는 편집 뒤 새 버전이 생겼지만, 기존 QA가 이전 버전을 검사한 것인지 새 버전을 검사한 것인지 한눈에 확인하기 어려웠습니다.
역할 기록도 고르지 않았습니다. 열두 실행 회차 모두 QA 파일은 있었지만, Editor 기록은 두 회차, Final 기록은 한 회차에만 남아 있었습니다. 사례 여덟 편 가운데 파일명이나 보관 위치가 달라져 현재 경로로 원고를 찾을 수 없는 것도 세 편이었습니다. QA가 있었다는 사실만으로는 어떤 버전의 어떤 변경을 검증했는지 충분하지 않았습니다.
숫자도 그대로 더할 수 없었습니다. 여섯 사례는 같은 보강 작업을 내용 점검과 의미 차이 점검에서 각각 다시 셌습니다. 확인된 이중 계상만 최소 열두 건이었습니다. 규칙을 “적용해 바꾼 것”과 “확인했지만 바꾸지 않은 것”도 같은 목록 안에 섞여 있었습니다. 이런 상태에서 횟수를 합치면 숫자는 나오지만, 그 숫자가 무엇을 세었는지는 흐려집니다.
그래서 기존 여덟 건의 수치를 합산하지 않기로 했습니다. 실패한 실험이라서 버린 것이 아니라, 정량 근거로 쓸 수 있는 상태가 아니기 때문입니다. 지금은 사례별 시행착오를 보여주는 정성 자료로만 남겨두기로 했습니다.
규칙 파일에 링크가 있다고 읽었다는 뜻은 아니었습니다
한 가지 문제가 더 있었습니다. 작업 지침에는 글쓰기 표준을 읽으라는 경로가 들어 있었습니다. 실제 원고에도 특정 규칙을 적용했다고 적힌 경우가 있었습니다. 처음에는 이것만으로 규칙이 사용됐다고 볼 수 있을 것 같았습니다.
하지만 나중에 증명하려면 부족했습니다. 작업이 시작될 때 어떤 버전의 표준을 읽었는지, 어느 부분을 적용했는지, 그 결과를 어떻게 확인했는지가 이어져야 했습니다. 현재 파일의 해시를 나중에 확인한다고 해서 당시 작업자가 그 버전을 읽었다는 증거가 되지는 않습니다.
이번 점검에서는 규칙이 실제로 소비됐다고 말하려면 최소한 다음 흐름이 이어져야 한다고 정리했습니다.
적용할 규칙을 정한다
→ 실행 시점의 규칙을 읽는다
→ 결과물에 적용한다
→ 같은 결과물을 검증한다
→ 예외나 수정 필요사항을 다시 남긴다경로를 적어둔 것과 실제로 읽은 것은 다르고, 읽은 것과 적용한 것도 다릅니다. 적용한 것과 같은 버전에서 검증한 것도 다시 다른 문제였습니다.
다음 실험부터는 변경 하나를 하나의 증거로 남기기로 했습니다
과거 기록을 억지로 보정하지는 않기로 했습니다. 지금 와서 당시 읽었던 규칙 버전을 추정해 채워 넣으면 기록은 깔끔해지지만 증거는 더 약해집니다.
대신 다음 파일럿부터 기록 방식을 바꾸는 쪽을 택했습니다. 변경 하나마다 고유한 식별자를 두고, 어떤 원본 해시에서 시작했는지, 어떤 규칙과 연결되는지, Writer·Editor·QA·Final 가운데 누가 어떤 결과를 남겼는지 이어서 기록합니다. 마지막 QA도 다른 파일이 아니라 그 변경이 반영된 결과물 해시를 확인해야 합니다. 규칙을 읽었다면 실행 시점의 표준 버전과 해시도 함께 남깁니다. 이후 원고가 바뀌면 이전 PASS는 합산에서 자동으로 빠지고 재검수 대상으로 돌아갑니다.
이렇게 하면 나중에 “좋아졌다”는 인상보다 더 작은 단위로 확인할 수 있습니다. 어떤 규칙이 실제 수정으로 이어졌는지, 검사는 했지만 변경하지 않은 규칙은 무엇인지, 같은 수정을 두 번 세지는 않았는지 다시 계산할 수 있습니다.
여덟 번의 파일럿이 쓸모없었던 것은 아닙니다. 오히려 기록을 많이 남기는 것과 나중에 검증할 수 있는 증거를 남기는 것이 다르다는 점을 보여줬습니다.
AI와 오래 일할수록 로그는 빠르게 늘어납니다. 작업 수, 수정 횟수, QA 통과 수 같은 숫자도 쉽게 만들 수 있습니다. 이번에는 그 숫자를 먼저 더하지 않는 쪽을 택했습니다. 무엇을 셌는지 다시 설명할 수 있을 때만 합산하기로 했습니다.