AI가 쓴 한글, 검사기에 넣어봤다

AI에게 한글 초안을 맡기면 내용은 멀쩡한데 문장이 어딘가 어색할 때가 있습니다. “~에 대하여”, “~를 통해”, “가지고 있다”, “되어진다” 같은 표현이 자꾸 나오고, 문단마다 “먼저 ~ 반면 ~ 결국” 같은 틀이 반복됩니다. 번역기를 거친 문장 같기도 하고, 읽다 보면 사람이 쓴 글과 미묘하게 다릅니다.

im-not-ai는 바로 그 “AI 티”를 잡아내는 Claude 스킬입니다. 현재 별이 4천 개가 넘습니다.

설치

마켓플레이스를 등록하고 플러그인을 설치하면 끝입니다.

/plugin marketplace add epoko77-ai/im-not-ai
/plugin install humanize-korean

설치 후에는 /humanize 커맨드를 쓰거나, 그냥 “이 글 AI 티 없애줘”처럼 말해도 스킬이 붙습니다.

티를 10개 갈래로 나눠 본다

스킬이 참고하는 분류표(ai-tell-taxonomy.md)는 AI 한글의 특징을 A부터 J까지 열 갈래로 나눠 놓았습니다.

	갈래	예시
A	번역투	“~에 있어서”, “가지고 있다”, 이중 피동 “되어진다”
B	영어 인용·용어 과다	불필요한 괄호 병기, 일회성 jargon
C	구조적 패턴	기계적 병렬 열거, “A인가, B인가” 반복, 이모지 남발
D	AI 특유의 관용구	흔히 보이는 정형 표현
E	리듬·문장 길이 균일성	문장 길이가 지나치게 고른 것
F~J	수식 중복, hedging, 접속사, 형식명사, 시각 장식

세부 항목까지 세면 71개입니다. 흥미로운 점은 항목마다 심각도(S1~S3)와 함께 “여기까지는 남겨둘 것”이 적혀 있다는 겁니다. 예를 들어 “~를 통해”는 한 문단에 세 번 이상 반복될 때만 손대고 한두 번은 그대로 둡니다. 개발 문맥의 API, token처럼 이미 원어로 굳은 용어를 “표식”같이 기계적으로 직역하지 말라는 단서도 붙어 있습니다. 그 자체로 정상인 표현을 무조건 치환하면 글이 오히려 망가지니까요.

경로를 먼저 정하고 시작한다

이 스킬에서 가장 실용적이라고 느낀 부분은 윤문을 시작하기 전에 파이썬 스크립트가 먼저 점수를 낸다는 점입니다. 그 점수로 세 갈래 중 하나를 고릅니다.

• light — 카운트형 티가 2건 이하이고 위험도가 낮으면. 이미 잘 쓴 글이니 한 번만 호출.
• standard — 그 사이. 진단 한 번 + 윤문 한 번.
• heavy — 위험도가 높고 티가 8건 이상이거나, 1만 5천 자를 넘는 장문일 때.

왜 이런 분기를 뒀는지는 코드 주석에 그대로 적혀 있었습니다. 9,817자짜리 글을 가장 무거운 경로로 돌렸더니 610K 토큰을 썼는데, 같은 글을 단일 호출로 처리하니 134K 토큰에 품질이 같았다는 겁니다. 잘 쓴 글에 무거운 파이프라인을 돌리는 건 그냥 낭비인 것이지요.

이 블로그 글로 돌려봤다

마침 좋은 검사 대상이 있었습니다. 지난 글은 Claude가 초안을 쓴 한글 문서입니다. 본문 2,804자를 그대로 점수 스크립트에 넣어봤습니다.

risk_band=medium  risk_score=4
route_hint=light
→ 카운트형 어휘·피동 티 0건 · risk_band medium
  — 이미 잘 쓴 글, 단일 콜·최소 파이프라인 권장

이중 피동, “~에 의해” 피동, have/make 직역, 이중 조사가 전부 0건으로 나왔습니다. 반대로 세부 지표에서는 어미 다양성이 기준선보다 크게 낮고, 관형절 중첩이 눈에 띄게 높다고 잡혔습니다. “~다”로 끝나는 문장이 연달아 나오는 것도 지적됐습니다. 번역투는 피했지만 문장 리듬은 단조로웠다는 뜻입니다.

대조군으로 번역투를 일부러 채운 문단도 넣어봤습니다.

카운트형 티 3건 · risk_band low → route_hint=standard

“성능인가, 정합성인가?”와 “먼저 ~ 반면 ~ 결국” 틀, “~에 의해 저장되어지고” 같은 걸 의도적으로 넣었더니 카운트형 티가 3건 잡혀 더 무거운 경로로 갔습니다.

여기서 하나 짚어둘 게 있습니다. 카운트형 티는 3건으로 늘었는데 risk_band는 오히려 low로 나왔습니다. 대조군이 376자짜리 짧은 글이라 리듬 관련 z-score가 안정적으로 나올 분량이 아니었기 때문입니다. 스크립트 주석도 같은 이야기를 하고 있습니다 — 밀도·z-score 지표는 기준선이 아직 placeholder라 경로 판정에서 아예 제외했고, 정수로 세는 티만 판정에 씁니다. 두 숫자를 나란히 놓고 볼 게 아니라, 신뢰할 수 있는 쪽이 어디인지 스킬이 이미 정해 두고 있었던 겁니다.

생각

이번에는 점수를 내는 단계까지만 돌려봤고, 실제 윤문 결과물까지는 확인하지 않았습니다. 앞으로 블로그 글을 쓸 때 자주 활용해보고자 합니다. 사실 이래저래 프로젝트를 진행하고, CS 공부하고, 현업 업무를 진행하다 보면 제가 100% 글을 다 쓸 수 있는 시간이 많지는 않아서 AI의 도움을 많이 받고 있는데, 이 도구를 많이 활용할 것 같네요.

AI가 쓴 글을 다시 AI에게 검사하게 한다는 구조가 앞서 CLAUDE.md를 점검했을 때와 닮았습니다. 스스로 못 보는 걸 도구에 맡겨 세어 보게 하는 방식이 꽤 자주 통하는 것 같습니다.