9월 1일 새벽, humanizer 스킬을 이 블로그의 발행 전 게이트로 정했다.
31일 뒤인 10월 2일 저녁, 그 스킬 폴더를 백업 폴더로 옮겨 껐다.
끈 이유는 채택 글에 걸어 둔 재검토 트리거에는 없던 것이었다.
그 뒤에 만든 2단 윤문은 실제로 세 번 썼고 세 번 모두 게이트를 통과했다.
문제
채택 글은 문서 조사로 humanizer를 고르고 채택한 데까지만 썼다.
그 글이 걸어 둔 재검토 트리거는 "실측 변경률이 세 편 연속 30%를 넘으면"이었다.
실제로 끈 이유는 이 문장 안에 없다.
채택 직전에 남긴 기록에는 im-not-ai 쪽을 두고 "신뢰 낮음, 최후의 보루로만"이라고 적었다.
한 달 뒤에 남은 한국어 윤문 스킬은 바로 그 리포의 humanize-korean 하나였다.
9월 28일, 돌리지 않은 탐지기
짧은 문안 두 칸을 맡기며 "ai티 안나게 야무지게 깎아"라고 했다.
에이전트는 초안 두 칸을 냈는데, 보고에는 탐지나 윤문에 관한 이야기가 한 줄도 없었다.
내가 "ai 윤문 야무지게 한거야?"라고 묻자 2초 뒤에 답이 왔다.
"솔직히 말하면 아니에요. … 탐지기는 안 돌렸어요."
이때 에이전트가 이어서 부른 탐지기는 humanizer가 아니라 im-not-ai의 옛 탐지 에이전트였다.
로컬 설치본은 6월 커밋에 머물러 있었고, 원격 main보다 284커밋 뒤처져 있었다.
내가 "업데이트해"라고 하자 같은 세션이 im-not-ai를 최신으로 올렸다.
humanize-scan은 이 갱신으로 처음 로컬에 들어왔다.
갱신한 탐지기까지 돌린 뒤, 에이전트의 보고는 "처음엔 대충 한 게 맞았어요."로 시작했다.
에이전트 기록이 실제와 어긋난 사례를 모은 글은 따로 있다.
10월 2일, 두 룰북이 반대로 말했다
나흘 뒤, 지침 파일과 스킬 전체를 훑는 설정 감사 세션이 이 갱신이 남긴 여파를 찾아냈다.
보고의 둘째 항목은 "두 윤문 스킬이 반대로 지시합니다"였다.
humanizer는 번역투 "~통해"와 대명사 과다를 고쳐야 할 패턴으로 적어 둔다.
반면 humanize-scan에는 "이건 일부러 안 본다"는 목록이 있다.
그 목록은 ~를 통해에 "사람이 2배 더 쓴다. 기각된 규칙."이라고 적고 대명사 규칙에는 "자생 한국어 산문에서는 발동 조건 자체가 없다."라고 적는다.
같은 문장을 두고 한쪽은 고치라고 하고 다른 쪽은 고치지 말라고 하는 셈이다.
에이전트가 업스트림을 확인했다.
로컬 humanizer는 업스트림 v1.6.0과 바이트 단위로 같았고 스킬 내용이 마지막으로 바뀐 날은 2026-05-02였다.
10월 16일에 다시 확인한 그 리포의 마지막 커밋은 2026-05-05다.
에이전트의 판단은 "humanizer는 몇 달째 멈춰 있고 처방이 반대입니다."였다.
나는 "2. 너의의견대로."라고 답했고 18:05에 스킬 폴더가 백업 위치로 옮겨졌다.
결정 기록에 남은 재검토 조건은 im-not-ai의 158번 이슈가 머지되는 것이다. 이 이슈는 10월 16일에도 열려 있다.
블로그 문체 규범의 de-AI 게이트 절은 10월 16일까지도 발행 전에 모든 글이 humanizer를 통과한다고 적고 있었다.
| 날짜 | 일 | 계기 |
|---|---|---|
| 9월 1일 03:46 | humanizer를 발행 전 게이트로 채택 | 문서 조사 |
| 9월 28일 | im-not-ai 284커밋 갱신, humanize-scan 유입 | 옛 탐지기를 돌리지 않은 일 |
| 10월 2일 18:05 | humanizer 비활성 | 업스트림 정체, 반대 처방 |
10월 6일, 블라인드 비교 세 번
humanizer를 끈 뒤에 윤문 조합을 블라인드로 비교했다.
피험 글은 기발행 글 한 편이고, 1단 지침은 한국어 문장 규율 지침인 fluent-korean으로 고정했다.
내 지시는 "두번 진행할거야."였지만, 비교는 결국 세 번이 됐다.
1회전은 배포본으로 모델을 갈랐다.
X는 Opus 5.5 medium, Y는 Opus 4.6 max였고 나는 "x가 더나은데"라며 X를 골랐다.
정답을 공개하면서 에이전트는 이렇게 정리했다.
"계측으로는 덜 고친 4.6이 안전해 보였지만, 실제로 읽혔을 때는 더 과감하게 고친 5.5가 나았습니다."
여기서 말하는 계측은 바뀐 양을 보고 내린 에이전트의 해석이다.
또 모델과 effort를 한꺼번에 바꿨기 때문에, 어느 쪽의 효과인지도 가려지지 않는다.
| 1회전 계측 | Opus 5.5 medium | Opus 4.6 max |
|---|---|---|
| 원문에서 바뀐 줄 | 35줄 | 14줄 |
| 원문 문장을 그대로 둔 비율 | 35% | 77% |
| 소요 시간 | 43.7초 | 199초 |
| 비용 | $0.28 | $0.56 |
2a는 같은 배포본에서 humanize-korean을 켜고 끈 비교였다.
실행 3초 전에 에이전트가 진행 메시지를 먼저 썼다. "…금지 조건에 걸려 원문으로 되돌아가…"
실행 결과는 "되돌린 문장은 0건"이었고 에이전트는 다음 보고에서 "실행하기도 전에 잘못 쓴 문장이었습니다."라고 정정했다.
두 쪽의 차이는 6줄이었다.
비교 페이지가 원문 대비 변경을 칠하고 있어서 그 6줄이 묻혔고 에이전트는 "이건 제가 페이지를 잘못 설계한 탓입니다."라고 했다.
2b는 다듬기 전의 초안으로 다시 켜고 껐다.
차이는 31줄이었고 나는 켠 쪽을 골랐다. 켠 쪽은 비용이 $1.62 더 들었다.
에이전트가 적은 한계는 "글 한 편, 판정자 한 명"이었다.
1회전에서는 고른 뒤에 두 작업의 소요 시간을 물었고, 43.7초와 199초라는 답을 듣고 "그럼 5.5가 우월한거네."라고 정리했다.
2b에서는 "Y가 낫다. 이게 윤문한거지?"라고 먼저 고르고 나서 어느 쪽이 켠 쪽인지 물었다.
/korean, 1단 결과와만 비교하는 게이트
이 비교를 바탕으로 /korean 스킬을 만들었다.
1단은 Opus 5.5 medium에 fluent-korean 지침을 얹어 윤문하고 2단은 그 결과를 humanize-korean에 넘겨 마무리한다.
두 단은 별도 프로세스로 돌고 부모 세션에는 결과 한 줄만 돌아온다.
15KB짜리 초안으로 돌린 스모크는 6분 34초, $2.18에 게이트를 통과했다.
게이트는 구조상 원문을 보지 않는다.
2단에 들어가는 입력은 1단 결과이고, humanize-korean의 게이트는 자기 입력과 최종본을 비교한다.
원문과 최종본 사이의 의미 보존은 어느 단계에서도 재지 않는다.
1단에 넘기는 지시는 입력·출력 경로와 "지시대로 윤문해 주세요."가 전부여서 사용자 제약이 들어갈 칸도 없다.
그런데 스킬 문서는 gate=fail을 "의미 보존 문제를 잡은 것"으로 설명한다.
첫 실사용은 10월 8일, 긴 설계 문서였다.
결과 줄은 light B 0.0% gate pass, 152s, $1.39였다.
부모는 "의미 보존 게이트는 통과했고"라고 보고했다.
1단이 150줄 중 20줄을 바꿨지만 커밋된 문서는 입력과 비교해 diff가 0줄이다. 윤문본은 채택되지 않았다.
두 번째는 10월 14일, 두 쪽짜리 문서였다.
부모는 "명사형 종결 유지" 같은 제약을 함께 받았지만 실행 명령에는 파일 경로만 넘겼다.
결과 줄은 light B 0.3% gate pass, 106s, $1.05였다.
1단 자식은 자기 보고에 "원문에 없던 말이라 확인이 필요합니다"라고 썼다.
그런데도 2단 게이트는 "수치 주입·인용·register 이상 없음"으로 통과했다.
10월 16일에 남아 있던 실행 폴더를 보니, 게이트가 비교 기준으로 쓴 입력 파일은 1단 결과와 바이트 단위로 같았다.
1단의 경고는 자식의 실행 기록에만 남았고, 부모가 받은 것은 결과 한 줄이었다.
부모는 숫자와 이름을 따로 대조한 뒤에도 바뀐 문체가 "보고서처럼 읽히는 쪽"이라며 다섯 군데만 받자고 했고 나는 그대로 가자고 했다.
세 번째는 10월 15일, 또 다른 두 쪽짜리 문서였다.
결과 줄은 light B 0.1% gate pass, 162s, $1.27이었다.
바뀐 36곳 가운데 27곳은 그대로 받았고 7곳은 손봐서 받았으며 2곳은 받지 않았다.
| 실사용 | 결과 줄 | 받은 것 |
|---|---|---|
| 10월 8일 긴 설계 문서 | light B 0.0% gate pass | 채택하지 않음 |
| 10월 14일 두 쪽짜리 문서 | light B 0.3% gate pass | 다섯 군데 |
| 10월 15일 두 쪽짜리 문서 | light B 0.1% gate pass | 36곳 중 34곳 |
세 번 모두 똑같이 "gate pass"였다.
받은 양은 0에서 36곳 중 34곳까지 갈렸지만 그 차이는 게이트 줄에 나타나지 않았다.
결론
humanizer를 끈 이유는 채택 글의 트리거에 없던 업스트림 정체와, 다른 도구가 내린 반대 처방이었다.
그 뒤에 만든 2단 윤문의 게이트는 1단 결과와 최종본만 비교했고 원문 대비 의미 보존은 재지 않았다.
10월 17일에 문체 규범의 게이트 절을 고쳐 humanizer 의무를 지웠다.
이제 발행 전 의무는 기계 게이트(문체 규칙·편 사이 겹침 검사), 본문 숫자를 근거표의 원천과 맞추는 사실 대조, 그리고 내 교정이다.
윤문 도구는 내가 고를 때만 쓰고, 초안 대비 검사를 통과한 문장만 받으며, 도구가 낸 통과 신호는 채택 근거로 쓰지 않는다.
이 규정을 정하기 전 같은 날 새벽에 이 글을 포함한 초안 10편을 같은 2단 윤문에 돌렸다.
gate pass를 받은 9편 가운데 3편 4곳에서 윤문이 뜻을 바꿨고, 그 4곳을 잡은 것은 게이트가 아니라 초안과 윤문본의 숫자·인용 집합 비교와 diff 읽기였다.
한계·재검토 트리거
블라인드 비교는 글 한 편과 판정자 한 명으로 이뤄졌고 실사용은 세 건이다.
9월 28일 이후에 일어난 일의 근거는 에이전트 세션 기록, 커밋, Hindsight 원기록, 로컬 파일이다.
2단 게이트가 원문을 보지 않는다는 판단은 실행 스크립트와 게이트 스크립트를 읽고 남아 있던 실행 폴더 두 곳을 대조해서 얻은 결과다.
2026-10 기준 / 재검토 트리거: im-not-ai 158번 이슈가 머지되거나, /korean의 게이트가 원문과 최종본을 직접 비교하도록 바뀌면 이 기록을 다시 연다.
참고
- AI 냄새 제거 도구 20종을 고르다 도구 대신 4단 게이트를 세웠다 - humanizer를 채택한 글
- 블라인드 비교에 쓴 기발행 글 - 1단 지침을 고정하고 윤문 조합만 바꿔 돌린 피험 글
- 에이전트가 '완료'라고 적은 것들 - 에이전트 기록이 실제와 어긋난 사례를 모은 글
- korean-skills - humanizer 업스트림
- im-not-ai - humanize-korean·humanize-scan 업스트림
- im-not-ai 158번 이슈 - 비활성 결정의 재검토 조건