이 블로그는 글을 자동으로 생성하고 scripts/auto_post.py의 결정적 게이트로 거릅니다. 규칙을 넣거나 뺄 때마다 판별력을 쟀습니다.
판별력 = (발행본 통과율) − (반려 초안 통과율)0이면 두 집단을 전혀 가르지 못하는 규칙, 1.00이면 완벽히 가르는 규칙. 이 숫자로 규칙 여덟 개를 고쳤고, 프롬프트에서 규칙 넷을 지웠습니다.
그런데 “반려 초안”이라고 부른 138편이 반려된 적이 없었습니다.
정답지를 확인해 보니
content/_archive/에 138편이 있고 전부 draft: true라 반려된 초안이라고 믿었습니다. git 이력을 보니 그게 아니었습니다.
| 확인한 것 | 값 |
|---|---|
| 이 디렉터리를 만든 커밋 | 2건, 둘 다 사람이 손으로 |
| 그중 순수 이름변경(내용 0바이트 변경) | 138 / 138 (R100 132편 + 6편) |
reviewed: true | 112편 |
quality_score 기록됨 | 22편, 값은 92~100 |
게이트와 AI 검수를 전부 통과해서 파일로 쓰인 글이었습니다. 예약 실행이 항상 AUTO_POST_DRAFT=true라 초안으로 저장됐고, 어느 날 공개 범위를 “엔지니어링 주제만”으로 좁히면서 통째로 옮긴 것이었습니다.
0.00이 뜻한 것
두 규칙이 판별력 0.00이었습니다. 반려 초안 138편이 전부 통과했으니 아무것도 못 거른다고 읽었습니다.
거꾸로였습니다. 그 138편은 그 게이트를 통과했기 때문에 파일로 존재합니다. 통과율 138/138은 측정 결과가 아니라 선택 편향의 정의입니다. 규칙이 무력하다는 증거가 아니라 반려 집단을 한 번도 관측한 적이 없다는 뜻이었습니다.
하마터면 멀쩡한 규칙 둘을 “죽었다”며 지울 뻔했습니다.
1.00도 절반은 다른 것을 재고 있었다
높은 쪽도 다시 봐야 했습니다. 138편은 지금 게이트가 생기기 전 프롬프트로 생성된 글입니다. 그래서 판별력 1.00은 “나쁜 글을 가른다”가 아니라 상당 부분 **“옛 생성기 산출물을 가른다”**입니다.
목표로서는 여전히 맞습니다. 이 게이트가 근사해야 할 것은 사람의 발행 판단이고, 두 집단은 실제로 사람이 나눈 것이니까요. 다만 이름과 해석이 틀렸습니다. 재고 있던 것은 이쪽입니다.
- 믿은 것: 게이트 통과 vs 게이트 반려
- 실제: 사람이 발행 vs 사람이 내림
같은 착각인지 점검하는 절차
같은 착각을 하고 있는지 30초면 확인됩니다.
git log --oneline -- content/_archive/
git show --name-status --find-renames=100% <커밋> | grep -c "^R100"
grep -l "reviewed: true" content/_archive/*.md | wc -l판정 기준은 셋입니다.
- 그 디렉터리를 만든 커밋이 사람 손이면 자동 반려가 아닙니다
R100(내용 무변경 이름변경) 비율이 높으면 이동이지 판정이 아닙니다- 프론트매터에 검수 통과 흔적(
reviewed,quality_score)이 있으면 통과한 글입니다
셋 중 하나라도 걸리면 그 코퍼스로 잰 판별력은 라벨이 틀린 값입니다.
당시 남긴 것과 이후 바뀐 것
이 글을 처음 쓴 2026-09-16에는 저장소에 반려 본문이 0건이었습니다. 반려 본문은 지역변수에만 있다가 다음 시도에서 덮여 사라졌고, 사유는 stdout 한 줄이 전부였습니다. 그래서 scripts/rejections.jsonl에 사유, 시도 회차, 주제, 본문 길이, 본문 해시를 한 줄씩 기록하도록 바꿨습니다. 당시에는 같은 본문이 반복됐는지 확인할 해시까지만 남기고 본문은 저장하지 않았습니다.
그 방식만으로는 다음 수정 시도가 직전 실패문을 읽을 수 없었습니다. 2026-09-18부터는 scripts/rejected_drafts/에도 반려 본문을 저장합니다. 이 디렉터리는 장기 코퍼스가 아니라 진단용 순환 보관함입니다. 하루 최대 네 번의 시도를 기준으로 최근 12개, 즉 약 사흘치만 남기고 오래된 파일은 지웁니다. 구조화 로그는 집계용이고, 최근 본문은 실패 원인을 재현하고 수정 프롬프트에 되먹이는 용도입니다.
두 기록 장치가 발행을 막으면 본말이 뒤집히므로 쓰기 실패는 위로 던지지 않습니다. 그리고 4회 전부 실패한 날에도 커밋되도록 워크플로 푸시 단계에 if: always()를 달았습니다. 그런 날이 기록이 가장 필요한 날입니다.
이 이야기가 통하지 않는 경우
이건 관측된 집단이 통과자뿐일 때 생기는 문제입니다. 반려를 처음부터 기록해 왔다면 해당되지 않습니다.
규칙 하나가 “실질 무발동”이라고 말하려면, 그 규칙이 실제로 평가된 회차가 60회는 있어야 합니다. 0회 관측일 때 참 발동률의 95% 상한이 3/N이기 때문입니다. 게이트가 순서대로 호출되고 먼저 걸리면 뒤는 평가조차 되지 않으므로, 뒤쪽 게이트의 “발동 0건”은 안전하다는 뜻이 아니라 평가된 적이 적다는 뜻일 수 있습니다.
여기 적은 숫자는 이 저장소 하나에서 나온 값이고, 코퍼스 크기도 작습니다. 일반화할 만한 표본이 아닙니다.