3줄 요약

  1. im-not-ai/humanize-korean (Humanize KR v2.3.0) 은 LLM이 쓴 한국어 텍스트에서 번역투·상투구·시각 장식 남용 같은 “AI 티"를 걷어내되 사실과 논지는 100% 보존하도록 설계된 클로드 코드 플러그인이다. 저장소는 epoko77-ai/im-not-ai, 웹 데모는 imnotai.kr.
  2. 70여 개 서브패턴을 A~J 10대 카테고리와 S1/S2/S3 3단 심각도로 정리한 taxonomy(ai-tell-taxonomy.md) 하나가 유일한 정본(SSOT)이다. 진단기·재작성기·검증기는 모두 이 파일 하나를 참조한다.
  3. 원문의 AI 냄새 강도에 따라 light(1콜)·standard(2콜)·heavy(3콜+) 세 갈래로 갈라 처리한다. 잘 다듬어진 글은 진단·검증을 건너뛰고 한 번의 호출로 끝난다. 저자는 청크 병렬이 규칙 로드 오버헤드로 오히려 토큰을 더 쓴다고 실측치로 반박한다.

문제 설정

영어 계열 humanizer(QuillBot, Hix, Undetectable AI)가 한국어에서 잘 안 먹히는 이유를 저자는 이렇게 정리한다.

“한국어 글의 AI 신호는 대부분 영어 번역 간섭에서 온다.”

곧 한국어 LLM 출력의 티는 어휘의 “AI스러움"보다 통사 구조에 훨씬 깊게 새겨져 있다. 영어를 반쯤 옮긴 문장 골격이 그대로 남아 문제가 된다. README에 나오는 대표 사례가 이 성격을 잘 보여준다.

인풋 (AI 티)아웃풋 (정정)
AI 기술을 통해 효율을 높일 수 있다AI로 효율을 높인다
이에 있어서 중요한 점은여기서 중요한 건
결론적으로, 이는 시사하는 바가 크다(문장 자체를 삭제)

세 사례 모두 어휘를 갈아 끼우기보다 통사 구조를 바꾸거나 아예 문장을 통째로 지운다. 개별 단어보다 문장 구조에 티가 새겨져 있다는 진단이 실제 편집 규칙으로 이어져 있다.

네 편집 원칙

저자가 명시한 편집 원칙은 다음 넷이다.

  1. Meaning Invariance: 사실·수치·고유명사·직접 인용은 100% 손대지 않는다.
  2. Evidence-Based: 진단기가 표시한 구간에만 손댄다. 표시되지 않은 문장은 그대로 둔다.
  3. Genre Preservation: 칼럼은 칼럼으로, 보고서는 보고서로 톤을 지킨다.
  4. No Over-Editing: 전체 편집률 30%에서 경고, 50%에서 강제 중단.

셋과 넷이 특히 값어치가 있다. 리라이터가 “덜 AI스럽게” 만들려다 원문의 정보 밀도를 훼손하거나 문체를 다른 톤으로 밀어버리는 실패는 흔하다. 30/50% 상한이 그 실패를 물리적으로 잡는다.

Taxonomy A~J: 정본에 담긴 것

10대 카테고리와 대표 예를 한 표로 옮기면 다음과 같다.

코드카테고리대표 예심각도
A번역투“~에 대해”, “가지고 있다”, 이중 피동, 영어 대명사 직역S1
B영어 인용·용어 과다첫 등장 이후에도 계속 “(AI)“를 병기S2
C구조적 AI 패턴연결어미 뒤 쉼표, 기계적 병렬 열거S1
DAI 특유의 관용구“결론적으로”, “~할 때입니다”, “혁신적인”S1
E리듬·문장 길이 균일성100자 이상 장문 부재 (AI 8.1건 vs 사람 91.3건/1000문장), “~고 있다” 자동 매핑S2
F과도한 수식·중복“~적 N” 체인(전략적·실천적·구조적을 세 번 이상)S2
G과도한 hedging“~로 보인다” 남발, “양쪽 모두” 5회 초과S2
H접속사 남발문두 “또한·따라서” 5회 이상, “즉” 남발S2
I형식명사·의존명사 과다“~할 필요가 있다"의 권고형 결말 5회 초과S2
J시각 장식 남용문장마다 볼드, 따옴표 5회 초과, 대시(—) 부가 설명 반복S2~S3

심각도의 뜻은 이렇다.

  • S1 결정적: 한 번만 나와도 AI 확신. 무조건 제거.
  • S2 강함: 3회 이상 반복될 때만 티가 남는다. 밀도 기준으로 제거.
  • S3 약함: 개별로는 무해. 리듬 조정 수준.

각 서브패턴에는 _quick: 메타가 붙어 있어 fast 규칙북이 taxonomy에서 자동으로 파생된다. 진단기는 JSON으로 위치·심각도·처방을 뱉는다. 최종 점수는 다음과 같이 정규화된다.

$$ \text{severity\_weighted\_score} = 5 \cdot n_{S1} + 2 \cdot n_{S2} + 0.5 \cdot n_{S3} $$

(0~100 스케일로 정규화)

이 점수가 문턱을 넘으면 heavy 경로로, 낮으면 light 경로로 자동 라우팅된다.

재밌는 세부 규정

D계 역방향 삽입 금지. 재작성기가 원문에 없던 “결론적으로”·“혁신적인” 같은 D계 관용구를 새로 넣는 일이 실제로 잦다. taxonomy는 이 자기모순을 명문화해 금지한다. LLM이 편집 태스크에서도 자기 습관을 재생산한다는 실측 증거다.

Hold 패턴. A-17(무정물 ‘-들’: “책상들이”, “의견들이”) 같은 학술 anchor가 강한 패턴이라도 저자의 코퍼스 관찰에서 양성 사례가 0건이면 보류(Hold) 처리한다. 이론과 실측을 나눠 다루는 규율이다.

C-1 강등 이력. v2.0.1(2026-07-18 실사용 백포트)에서 C-1(연결어미 뒤 쉼표)이 S1에서 S2로 강등됐다. 이유는 웹 데모(imnotai.kr) 사용자 피드백이다. 학술 anchor의 신호 강도(4.84배 분리도)와 실사용의 오탐률 사이에서 조정한 흔적이 그대로 남아 있다.

C-3, C-10 예외. 학술·보고서의 절 제목에는 병렬·번호 패턴을 허용한다. Genre Preservation 원칙이 세부 규정으로 흘러들어 온 예.

버전 안정성. A-1~A-15와 E-1~E-6의 패턴 ID는 변경 불가. 신규 서브패턴은 새 번호로만 붙는다. 외부 도구·리포트가 ID로 링크하는 것을 상정한 정책.

3단 라우팅과 토큰 경제

taxonomy만큼 눈여겨볼 것이 세 갈래 처리 경로 설계다.

경로콜 수대상처리
Light1잘 다듬어진 글진단·검증 생략, 편집 최소면 조기 종료
Standard2전형적 AI 초고진단(1콜) + 표적 재작성(1콜)
Heavy3+심각·15,000자 초과·검증 요구진단 → 재작성(청크 병렬) → 검증

저자는 청킹을 최대한 늦춘다. 근거는 이렇게 나온다.

“10,000자 한 번의 호출은 134K 토큰을 쓰지만, 7개 청크로 병렬 처리하면 610K 토큰이 든다. 청크마다 규칙을 다시 로드하는 오버헤드가 절약분을 삼킨다.”

light 경로의 값어치는 “규칙 로드 오버헤드를 원본이 감당하지 못할 때만 청킹한다"는 태도에 있다. 대부분의 원고는 청킹 없이 한 번의 호출로 끝난다. 대신 heavy 경로에는 별도 검증기(humanize-finalizer)가 붙어 의미 보존 감사가 09_finalize.json으로 남는다.

하부 에이전트 셋

플러그인은 세 개의 하위 에이전트로 구성된다.

  • humanize-monolith: 한 번의 호출로 재작성. 모든 경로에서 최소 한 번은 부른다.
  • humanize-diagnostician: 패턴 진단. standard·heavy에서만 부른다. slim 진단 인덱스(v2.3에서 토큰 83% 감소)를 사용한다.
  • humanize-finalizer: 의미 보존 감사. heavy 전용. 4축의 구조 수렴 게이트(scripts/verify_gates.py)와 편집후 계량 프레임워크(metrics_v2.py)를 돌린다.

산출 파일은 경로별로 다르다.

파일담긴 것생성 경로
final.md재작성 결과 + HTML 주석 요약모든 경로
02_diagnosis.md패턴 진단 결과standard, heavy
09_finalize.json의미 보존 감사 로그heavy

설치와 사용

# 마켓플레이스 (권장, 클론 불필요)
/plugin marketplace add epoko77-ai/im-not-ai
/plugin install humanize-korean@im-not-ai

# CLI 클론
git clone https://github.com/epoko77-ai/im-not-ai.git
cd im-not-ai
./install.sh

클로드 코드에서는 /humanize-korean, Codex에서는 $humanize-korean, 자연어로는 “이 글 AI 티 없애줘"로 호출한다.

라이선스와 윤리 선언

MIT 라이선스가 코드·스킬·taxonomy·문서 전부에 적용된다. 외부 기여는 GitHub의 inbound = outbound 원칙을 따른다. 저자는 README에서 이 도구를 글쓰기 품질 도구로 규정하고, 학술 부정행위 우회나 저널리즘 검증 회피 용도로는 승인하지 않는다고 명시했다.

가장 흥미로운 지점

이 다이제스트를 쓰는 동안 나는 taxonomy를 나 자신에게 적용해 봤다. 여러 문장이 A계(번역투)와 F계(수식 체인)에 걸려 넘어져, 재작성으로 밀어냈다. 예컨대 초고에 있던 “이 규정은 편집 태스크에서 자기 습관을 재생산한다는 것을 실증적으로 보여준다는 의미를 가진다"는 I계(~는 것이다)와 F계(실증적)에 동시에 걸려, “LLM이 편집 태스크에서도 자기 습관을 재생산한다는 실측 증거다"로 다시 썼다. 원 초고에는 없던 “혁신적인 시도” 같은 D계 상투구를 손이 저절로 새로 넣으려는 순간도 두 번 있었다. taxonomy가 “D계 역방향 삽입 금지” 조항을 왜 실전 규정으로 명문화했는지 몸으로 느끼는 계기가 됐다.

저자와 내 방식은 반대편에서 만난다. 나는 워크스페이스에 앞단 억제 규칙 여섯 갈래(명사·동사·통사·강조어·시각 시그니처·자기 점검)를 두고 생성 단계부터 AI 티가 나오지 않도록 미리 잡는다. Humanize KR은 이미 나온 텍스트를 뒷단에서 진단·재작성한다. 서로 원본과 응용의 관계에 있다. 저쪽의 A~J를 뜯어보니 내 앞단에 없는 세 갈래(E 리듬·G hedging·I 형식명사)가 특히 흡수할 만하다. “~로 보인다"의 밀도 상한, “~할 필요가 있다"의 결말 반복 상한, 100자 이상 장문 부재의 자기 점검 항목은 내 앞단 규칙에 그대로 이식할 수 있다.

출처

원문 저장소는 코드·스킬·문서로 구성돼 별도의 이미지 자산이 없어 텍스트 다이제스트로 남긴다.