다시 검사할 수 있게 탐지 설정을 남기는 법

같은 보고서를 이틀 뒤에 다시 넣었더니 숫자가 7포인트 달랐다는 문의가 온 적이 있어요. 열어 보니 첫날은 표와 각주를 포함했고, 둘째 날은 본문만 복사한 상태였습니다. 모델이 변한 게 아니었어요. 질문이 변한 거였죠.

재검사가 의미 있으려면 첫 검사와 같은 조건을 복원할 수 있어야 합니다. 점수가 남은 메모장에는 그게 거의 없었어요. “72%”만 적혀 있고 도구 이름도 없었습니다.

네 칸만 고정해요

도구와 화면 버전, 검사 시각(시간대 포함), 정규화 후 글자 수, 넣은 범위. 범위에는 제목·표·인용·각주 포함 여부를 체크합니다. 이 네 칸이 같으면 숫자 비교를 시도해도 됩니다. 하나라도 빠지면 “달라 보인다”는 문장을 쓰지 않아요.

원문 전체를 보관할 필요는 없습니다. 이름, 학번, 고객 문장이 들어 있으면 오히려 위험해요. 문서 제목과 버전, 필요하면 해시 정도만 남깁니다. 우리 API도 원문을 저장하지 않고 해시로 캐시합니다. 운영하면서 그 선택이 맞았다고 보는 지점이 바로 이런 재검사 분쟁이에요.

나쁜 로그, 쓸 수 있는 로그

나쁜 예: “AI 높음. 다시 넣으니 낮아짐.” 쓸 수 있는 예: “2026-09-10 14:12 KST, AI 판독기, 1,780자, 본문만, 표 제외. 재검사 9-11 09:04, 같은 파일 v3, 1,776자.” 글자 수가 4자 줄었으면 공백 정규화 차이일 수 있어요. 그 정도를 모델 업데이트로 해석하지 않습니다.

시간이 지나 도구 안내 문구가 바뀌면 과거 숫자와 새 숫자를 바로 비교하지 마세요. 화면 문구도 조건의 일부입니다. 측정 체계가 바뀌면 시계열을 끊는 게 정직한 기록이에요.

팀에 공유할 때

슬랙에 점수만 올리지 말고 네 칸을 같이 올립니다. 스크린샷은 네 칸을 대체하지 못해요. 잘린 화면에 글자 수가 없으면 다음 사람이 같은 입력을 못 만듭니다. 기록 습관은 탐지 정확도 이야기가 아니라 재현 이야기입니다. NIST도 측정값을 맥락과 함께 문서화하라고 말합니다. NIST AI RMF 자료를 기준으로 칸을 유지하면 나중에 논쟁이 짧아져요.

제가 내부에서 쓰는 한 줄 템플릿은 이렇습니다. 날짜 / 도구 / 글자 수 / 범위 / 점수 / 하이라이트 위치. 하이라이트까지 적으면 “어디가 걸렸다”는 대화가 숫자 싸움으로 안 내려갑니다. 재검사 전에 이 줄을 복사해 두고, 바뀐 칸이 있으면 비교를 포기하세요.

브라우저 번역으로 결과를 다시 읽은 뒤 점수가 달라 보인다는 제보도 있었습니다. 화면 언어가 바뀐 거지 검사가 다시 된 게 아니었어요. 그래서 로그에 화면 언어도 적기 시작했습니다. 사소한 칸처럼 보여도, 나중에 “왜 숫자가 다르지?”라는 질문을 한 번에 닫아 줍니다.

모델이나 프롬프트를 우리가 바꾸면 그 주부터 로그에 별표를 칩니다. 별표가 있는 주는 이전 주와 평균을 비교하지 않아요. 제품 변경과 사용자 문서 변경을 한 그래프에 넣으면 운영자가 자기 배포를 외부 신호로 착각합니다. 재검사 규칙과 배포 규칙이 같은 이유예요. 조건이 바뀌면 시계열을 끊습니다.

기록은 예쁘지 않아도 됩니다. 메모장 한 줄이면 충분해요. 예쁜 시트에 칸이 스무 개면 아무도 안 채웁니다. 네 칸을 채우는 팀이 스무 칸을 설계한 팀보다 분쟁을 빨리 끝냅니다.

재검사 요청이 밤에 오면 다음 날 아침 조건부터 되묻습니다. 같은 파일인지, 표를 뺐는지, 브라우저 번역을 켰는지. 세 질문이면 대부분의 “점수가 변했다”는 제보가 닫힙니다. 남은 소수만 실제 재검사로 넘깁니다. 그 필터가 없으면 운영이 새로고침 기계가 됩니다. 새로고침 기계는 조건을 남기지 않아요. 조건이 없는 재검사는 신호가 아니라 소음입니다. 소음을 줄이는 게 정확도를 올리는 일보다 먼저입니다.