글쓰기 규칙은 문서가 아니라 게이트여야 합니다

AI가 쓴 티를 지워 주는 오픈소스 스킬이 몇 개 있습니다. 제 글쓰기 지침과 뭐가 다른지 궁금해서 두 개를 열어 비교했습니다. 비교는 30분이면 끝날 줄 알았는데, 정작 걸린 건 제 블로그였습니다. 이 사이트에 이미 올라가 있는 글 21편에서 제가 스스로 정한 금지 규칙 위반이 122건 나왔습니다.

비교한 것#

두 오픈소스는 NomaDamas/k-skill의 korean-humanizer와 blader/humanizer입니다. 후자는 위키백과의 Signs of AI writing 문서를 그대로 스킬로 옮긴 것입니다.

읽고 나서 알게 된 건, 셋이 경쟁 관계가 아니라는 것이었습니다. 앞의 둘은 다 쓴 글을 넣으면 고쳐 주는 엔진이고, 제 지침은 쓰는 동안 지키고 올리기 전에 막는 게이트입니다. 그래서 겹치는 항목(엠데시 금지, 번역투, 하이프 형용사)이 많은데도 쓰임이 달랐습니다.

게이트가 돌고 있지 않았습니다#

제 지침에는 "게시 직전 기계적 검사"라는 절이 있습니다. 금지 표현을 grep으로 훑고 걸리면 고치라는 내용입니다. 비교를 하다가 문득, 그 명령을 이 블로그 글에 한 번도 안 돌려 봤다는 게 떠올랐습니다.

돌렸더니 이렇게 나왔습니다.

2026-07-14-macos-launchagent-guide.md   19건
2026-07-03-slack-custom-mention-sound.md 16건
2026-07-12-nextjs-markdown-blog-shiki.md 15건
...
21편 중 18편, 총 122건

제 지침에서 예외 없는 하드 금지 1번이 em dash입니다. 한국어 키보드로는 나오지 않는 문자라서 AI가 쓴 티로 가장 확실하다고 적어 뒀습니다. 그게 라이브 글 한 편에서 19번 깨져 있었습니다.

## StartInterval vs WatchPaths — 주기냐 이벤트냐
- **KeepAlive** — 프로세스가 죽으면 launchd가 되살린다.
title: macOS LaunchAgent 실전 입문 — cron 대신 쓰는 이유

규칙을 몰라서 어긴 게 아닙니다. 제가 쓴 규칙이고, 문장으로 명확히 적혀 있었습니다. 그냥 검사를 안 돌렸을 뿐입니다.

grep 한 줄로는 돌릴 수가 없었습니다#

왜 안 돌렸는지 보니 이유가 있었습니다. 지침에 적어 둔 검사가 grep 한 줄이었는데, 이게 코드블록을 못 가립니다.

기술 블로그 글은 절반이 코드입니다. --webpack 같은 플래그, 로그 출력, 설정 파일이 전부 검사에 걸립니다. 한 번 돌려서 화면 가득 오탐이 쏟아지면 다음부터는 안 돌리게 됩니다. 검사가 안 도는 이유가 게으름이 아니라 신호 대 잡음비였던 겁니다.

그래서 12줄짜리 awk로 바꿨습니다.

#!/bin/sh
# 게시 전 검사. 코드블록과 인라인 코드는 건너뛴다.
# [하드] 가 하나라도 있으면 exit 1.
[ $# -eq 0 ] && { echo "usage: check.sh FILE..." >&2; exit 2; }
awk '
/^[ \t]*```/ { inb = !inb; next }
inb { next }
{ l = $0; gsub(/`[^`]*`/, "", l) }
l ~ /—|–/ { print FILENAME ":" FNR ": [하드] " l; h++ }
l ~ /쪽|부분|느낌|결론적으로|본질적으로/ { print FILENAME ":" FNR ": [검토] " l }
END { exit (h > 0) }
' "$@"

핵심은 세 가지입니다. 펜스를 만나면 상태를 뒤집어 코드블록을 통째로 건너뜁니다. 인라인 코드는 백틱 사이를 지우고 검사합니다. 그리고 결과를 하드와 검토 두 단계로 나눕니다. 하드가 하나라도 있으면 exit 1로 떨어지니 나중에 CI나 커밋 훅에 물릴 수 있습니다.

이 스크립트를 쓰자마자, 제가 방금 지침 파일에 새로 써 넣은 문장 하나가 걸렸습니다. "보이면 지키는 쪽으로 기운다"였는데, 명사로 도망가는 종결을 쓰지 말라고 적어 놓은 그 문서에서, 제가 바로 그 종결을 쓴 것입니다. 검사 도구가 없었으면 그대로 남았을 문장입니다.

금지 목록에 빠져 있던 두 가지#

오픈소스 두 개를 읽으면서 제 지침에 없는 절을 두 개 발견했습니다.

첫째, 오탐 방지입니다. 제 금지어에는 부분, 쪽, 느낌이 있습니다. 그런데 "이 부분을 눌러 주세요"는 지극히 정상적인 한국어입니다. 문제는 대비를 만들려다 명사화로 도망가는 종결이지, 단어 자체가 아닙니다. 두 오픈소스는 공통적으로 "이건 그 자체로 AI 신호가 아니다"라는 목록을 따로 두고 있었습니다. 다듬어진 맞춤법, 격식체와 한자어, 접속어 한두 개, 짧고 단호한 문장 하나. 전부 사람도 흔히 쓰는 것들입니다. 판정은 단발이 아니라 무더기로 하라는 원칙도 같이 있었습니다.

둘째, 지켜야 할 것입니다. 지어내기 힘든 구체적 디테일, 해소되지 않은 심경, 특정 연도에 묶인 레퍼런스, 진짜 곁말과 자기 정정. 이런 게 보이면 손대지 말라는 목록입니다. 제 지침은 지울 것만 아홉 항목이고 지킬 것은 사실 규율 하나뿐이었습니다. 금지어만 쌓으면 검사가 점점 공격적으로 변하고, 결국 멀쩡한 사람 글까지 평균값으로 깎게 됩니다.

재미있었던 건, 제가 로컬에 따로 갖고 있던 한국어 윤문 스킬(분류표만 60KB짜리)에도 이 두 절이 한 건도 없었다는 것입니다. 세 자산 전부 지우는 법만 알고 있었습니다.

지우는 규칙만으로는 좋은 글이 안 나옵니다#

두 오픈소스에는 공통으로 "PERSONALITY AND SOUL"이라는 절이 있습니다. AI 패턴을 지우는 건 절반이고, 영혼 없는 글은 슬롭만큼 티가 난다는 내용입니다. 모든 문장이 같은 길이면, 의견 없이 중립 보고만 하면, 어울리는 자리인데 1인칭이 없으면, 문법이 완벽해도 기계처럼 읽힙니다.

제 지침에는 이게 없었습니다. 금지 목록 아홉 줄, AI 관용구 일곱 줄, 번역투 열두 줄. 전부 "쓰지 마라"입니다. 그래서 맨 앞에 절을 하나 새로 만들었습니다. 의견을 가질 것, 리듬을 흔들 것, 흐트러짐을 남길 것, 미해결을 지우지 말 것. 그리고 이 절은 개인적인 글에만 적용하고 기술 문서에는 적용하지 않는다는 단서를 달았습니다. 레퍼런스 문서에서는 담백한 중립이 곧 올바른 사람의 목소리이기 때문입니다.

122건을 0건으로#

고치는 작업은 두 갈래로 나눴습니다.

볼드 머리말이 붙은 불릿 46건은 스크립트로 처리했습니다. - **KeepAlive** — 설명 형태가 규칙적이라 콜론으로 기계 치환이 가능했습니다.

나머지 76건은 손으로 고쳤습니다. 제목, 소제목, 본문 문장이라 문맥을 봐야 했습니다. 여기서 한 가지 함정이 있었는데, em dash를 전부 콜론으로 바꾸면 이번에는 "X: Y" 부제 헤딩이 한 글에 여섯 개씩 생깁니다. 그것도 AI 글의 정체 중 하나입니다. 그래서 헤딩은 문장으로 다시 썼습니다.

## 다운로드 — yt-dlp가 안 될 때가 있다
→ ## 다운로드가 막힐 때가 있다
 
## 흔한 삽질 3종 — 전부 밟아 봤다
→ ## 전부 밟아 본 흔한 삽질 3종

본문에서 삽입구로 쓰인 이중 em dash가 가장 손이 많이 갔습니다.

네이티브 답은 **launchd** — 부팅부터 프로세스 전체를 관리하는 init 시스템 — 고,
→ 네이티브 답은 **launchd**입니다. 부팅부터 프로세스 전체를 관리하는 init 시스템이고,

결과는 하드 122건에서 0건입니다. 남은 em dash 두 개는 옵시디언 글의 코드블록 안 예시라서 새 검사에서는 애초에 대상이 아닙니다. next build --webpack을 통과했고, 당시 태그 페이지 43개까지 정상 생성됐습니다.

검사가 실제 글을 바꾼 세 가지#

규칙은 문서에 있으면 안 지켜집니다. exit code가 있어야 지켜집니다. 저는 이 지침을 만들면서 "읽어서 아는 것과 매 초안에 적용하는 것은 다르다"라고 직접 적어 놨는데, 그걸 적은 문서 자체가 실행 가능한 형태가 아니었습니다.

오탐이 나오는 검사는 결국 안 돌립니다. 검사를 만들 때 잡는 능력만 보고 흘리는 능력을 안 보면, 그 검사는 한 번 돌려 보고 버려집니다. 하드와 검토를 나누고 코드블록을 빼는 데 12줄이면 충분했습니다.

금지 목록은 AI 티를 지울 뿐입니다. 좋은 글을 만드는 건 별개의 규칙이고, 그건 따로 적어야 합니다.

2026년 8월 29일에 다시 본 결과#

세 번째 애드센스 반려를 계기로 공개 글을 다시 검사했습니다. 그사이 검사 규칙이 늘어서 결과는 하드 위반 0건, 검토 68건, 긴 문단 138건이었습니다. 이미지 대체문과 표 제목처럼 정상 용법도 함께 잡히므로, 검토와 문단 길이는 실패 건수로 세지 않았습니다.

대신 사이트 전체에서 반복되는 모양을 따로 봤습니다. 왜 A인가, 배운 것, 정리처럼 되풀이되던 소제목 23개를 각 글의 실제 내용에 맞게 바꿨고, 세 글에 중복되던 헬스체크 코드는 최초 글 한 곳에만 남겼습니다. 숫자를 0으로 만드는 것보다 여러 글이 같은 틀에서 나온 것처럼 보이는 원인을 줄이는 쪽이 맞았습니다.

볼드 머리말이 붙은 목록은 일괄적으로 줄글로 바꾸지 않았습니다. 설정값과 체크리스트는 목록일 때 더 빨리 읽힙니다. 검사는 형식을 없애는 명령이 아니라, 같은 형식이 이유 없이 반복되는지 확인하는 경보로 두었습니다.