im-not-ai 사용법: AI 글투를 세 경로로 다듬는 원리

im-not-ai는 AI가 만든 한국어 초안에서 번역투와 기계적인 문장 습관을 찾아, 뜻을 지키면서 표현만 다듬도록 설계된 오픈소스 CLI 스킬입니다. 단순한 ‘AI 탐지기’라기보다 원문을 보존하는 편집 절차와 검증 장치를 묶은 도구에 가깝습니다. 다만 글이 사람 손에서 나왔는지 판정해 주는 증명서는 아니며, 최종 판단은 작성자가 해야 합니다.

이 글의 목차

im-not-ai는 정확히 무엇을 하나요?세 경로는 어떻게 고르나요?작은 입력은 어떤 출력으로 바뀌나요?최신 v2.3.2에서 무엇이 달라졌나요?설치 방법은 왜 도구마다 다른가요?의미 보존은 어떻게 검사하나요?언제 쓰고, 언제 피해야 하나요?초보자는 무엇부터 확인하면 되나요?공식 자료

30초 요약 - 최신 GitHub 릴리스는 v2.3.2, 2026년 8월 18일 공개입니다. - 글 상태를 먼저 점수화해 light, standard, heavy 가운데 처리 경로를 고릅니다. - Claude Code는 세 경로를 모두 쓰지만 Copilot CLI·Codex CLI·Gemini CLI는 단일 호출 경로만 제공합니다. - 문서의 테스트·성능 수치는 프로젝트 측 결과입니다. 이 글에서는 저장소 코드를 직접 실행하지 않았습니다.

im-not-ai는 정확히 무엇을 하나요?

이 저장소의 정식 이름은 Humanize KR입니다. 대규모 언어 모델(LLM, Large Language Model)이 쓴 한국어에서 ~를 통해, 기계적인 병렬 나열, 같은 종결어미 반복, 과도한 굵은 글씨처럼 인공적으로 느껴질 수 있는 패턴을 찾고 고치는 에이전트 스킬입니다.

생활에 비유하면 자동 세차보다는 교정지가 붙은 세탁소에 가깝습니다. 옷의 주인과 용도는 그대로 두고 구김과 보풀만 손보겠다는 설계죠. 저장소는 사실·주장·수치·고유명사·직접 인용을 보존하고, 탐지된 구간만 고친다는 원칙을 내세웁니다.

핵심 대상은 ‘AI가 썼다는 사실’ 자체가 아닙니다. 읽는 흐름을 끊는 번역투와 반복 습관입니다. 그래서 사람이 쓴 글에도 패턴이 있으면 반응할 수 있고, 매끄러운 AI 글에는 손댈 부분이 적을 수 있습니다.

세 경로는 어떻게 고르나요?

입력은 바로 언어 모델로 가지 않습니다. 먼저 prepare_monolith_input.py라는 사전 처리기(shim)가 문장 특성을 정량화하고 route_hint를 만듭니다. 이 힌트가 작업량을 정합니다.

경로	모델 호출	맞는 입력	처리 방식
light	1회	이미 자연스러운 글	보수적으로 한 번 윤문
standard	2회	흔한 AI 초안	진단 후 겨냥 윤문
heavy	3회 이상	패턴이 많거나 15,000자 초과 장문, 검증이 필요한 글	진단·윤문·최종 검증

흐름을 짧게 적으면 이렇습니다.

입력 글
  ↓
정량 사전 점수 + route_hint
  ↓
light / standard / heavy 중 한 경로
  ↓
변경률·구조·수치 보존 게이트
  ↓
final.md

여기서 재미있는 판단은 ‘큰 글이면 무조건 잘게 자른다’가 아니라는 점입니다. 저장소 설명에 따르면 청킹(chunking, 긴 글을 조각으로 나누는 처리)은 heavy에서 필요할 때만 씁니다. 조각마다 규칙과 진단 문맥을 다시 읽으면 오히려 비용이 커질 수 있기 때문입니다.

작은 입력은 어떤 출력으로 바뀌나요?

아래는 저장소 README의 변환 방향을 바탕으로 다시 구성한 문서 기반 예시입니다. 이 글을 쓰며 도구를 실행해 얻은 결과는 아닙니다.

입력
AI 기술을 통해 업무 효율을 높일 수 있습니다.
또한, 반복 작업을 자동화할 수 있다는 점이 중요합니다.

예상되는 편집 방향
AI로 업무 효율을 높입니다.
반복 작업도 자동화할 수 있습니다.

첫 문장은 ~를 통해와 ~할 수 있습니다를 더 직접적인 표현으로 줄였습니다. 둘째 문장에서는 문두 접속사와 ~다는 점이 중요합니다를 걷어냅니다. 정보가 새로 생기거나 사라져서는 안 된다는 게 저장소의 원칙입니다.

다만 같은 표현이 보인다고 무조건 지우지는 않습니다. v2.3.0 릴리스에서는 자체 대조 코퍼스 결과를 반영해 ~를 통해를 단독 결정 신호로 보던 기준을 완화했습니다. 규칙도 고정된 금지어 사전이 아니라, 반례와 측정 결과에 따라 조정되고 있습니다.

최신 v2.3.2에서 무엇이 달라졌나요?

GitHub Releases 기준 최신 공개판은 v2.3.2이며 공개 시각은 2026년 8월 18일입니다. GitHub 저장소의 최근 push 시각은 별도 활동 정보일 뿐 릴리스 날짜로 보지 않았습니다.

v2.3.2는 새로운 문체 패턴보다 설치 구조를 바로잡은 패치입니다. 스킬 파일을 .claude/skills/에서 플러그인 관례 위치인 루트 skills/로 옮겼고, 고정된 디렉터리 깊이에 의존하던 경로 계산을 없앴습니다. 끊어진 Codex 쪽 참조 링크도 복구했습니다.

이 수정이 필요한 이유는 제법 현실적입니다. 이전 구조에서는 스킬이 겉으로 로드돼 결과물도 나왔지만, 마켓플레이스 설치 환경에서 정량 shim과 진단 계층이 조용히 빠질 수 있었습니다. ‘에러가 없으니 정상’이라는 개발자의 오래된 함정이 여기서도 얌전히 출근한 셈입니다.

프로젝트 릴리스 노트는 v2.3.2 검증 결과로 pytest 236개 통과와 claude plugin validate . 통과를 밝힙니다. 이는 프로젝트가 보고한 검증 결과이며, 이 글에서 같은 환경으로 재현한 수치는 아닙니다.

설치 방법은 왜 도구마다 다른가요?

Claude Code에서는 플러그인 마켓플레이스 설치가 권장 경로입니다.

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

설치한 뒤 새 세션에서 /humanize-korean 또는 자연어 요청으로 부릅니다. Claude Code에서는 light 1회, standard 2회, heavy 3회 이상으로 이어지는 전체 오케스트레이션을 쓸 수 있습니다.

Codex CLI는 저장소를 클론한 뒤 설치 스크립트를 사용합니다.

git clone https://github.com/epoko77-ai/im-not-ai.git
cd im-not-ai
./install.sh --codex-only

공식 설치 문서는 Codex CLI 0.121.0 이상을 요구하며 $humanize-korean으로 실행하라고 안내합니다. GitHub Copilot CLI와 Gemini CLI도 지원하지만, 이 세 도구는 Claude Code의 다중 에이전트 경로가 아니라 단일 호출 경로를 사용합니다. 이름은 같아도 내부 작업량까지 같은 것은 아닙니다.

설치 스크립트는 심링크를 만들 수 있습니다. 저장소를 옮기거나 삭제하면 링크가 끊길 수 있으니, 위치를 바꾼 뒤에는 재설치가 필요합니다. 외부 저장소의 스크립트를 실행하기 전 내용을 확인하는 기본 습관도 빼놓지 않는 편이 좋습니다.

의미 보존은 어떻게 검사하나요?

윤문은 자연스러워 보여도 숫자 하나가 바뀌면 실패입니다. 이 프로젝트는 변경률 검사뿐 아니라 진단 목표가 실제로 줄었는지, 원문의 대구 표현을 모조리 없애지 않았는지, 새 숫자가 끼어들지 않았는지 등을 코드 게이트로 확인합니다.

변경률에는 상한도 있습니다. README가 밝힌 원칙은 30% 초과 시 경고, 50% 초과 시 강제 중단입니다. 많이 바꿀수록 잘 고친다는 단순 계산을 막는 안전장치입니다.

v2.3.1에는 문장별 핵심 내용 명사를 편집 전에 기록하는 anchor_ledger 계약도 들어갔습니다. 핵심 앵커가 사라지는 편집은 되돌리는 방식입니다. 그래도 언어 모델을 쓰는 이상 모든 의미 보존이 자동 보장된다고 받아들이면 안 됩니다.

언제 쓰고, 언제 피해야 하나요?

블로그 초안, 제품 설명, 보고서처럼 내용은 이미 확정됐지만 문체가 뻣뻣한 글에 잘 맞습니다. 변경 전후를 비교할 수 있고, 마지막 사실 확인을 사람이 맡는 작업 흐름이라면 특히 유용합니다.

반대로 법률 조항, 계약서, 의료 안내, 논문 인용처럼 한 표현의 법적·전문적 의미가 큰 문서를 자동 윤문본 그대로 내보내면 위험합니다. 문학 작품처럼 의도적인 반복과 낯선 리듬이 중요한 글에도 규칙 기반 편집이 개성을 깎을 수 있습니다.

AI 판별 도구로 쓰는 것도 피해야 합니다. 저장소 자체가 외부 반례를 계기로 사람 글 오판 문제를 고쳤고, 같은 코퍼스로 기준을 만들고 다시 측정한 결과에는 표본 내 검증이라는 한계가 남는다고 밝힙니다. 패턴 점수는 편집 힌트이지 저자 신원 판정이 아닙니다.

초보자는 무엇부터 확인하면 되나요?

처음이라면 아래 네 가지만 지키면 됩니다.

• 지원 CLI와 최소 버전을 설치 문서에서 확인합니다.
• 중요한 원문은 별도 파일로 보관합니다.
• 짧은 비핵심 문서로 먼저 시험하고 변경 전후를 비교합니다.
• 수치, 고유명사, 인용, 링크가 그대로인지 사람이 마지막으로 읽습니다.

이 저장소의 가치가 가장 또렷한 부분은 ‘사람처럼 보이게 만드는 마법’이 아닙니다. 무엇을 고칠지 고르고, 덜 고쳐도 되는 글은 가볍게 보내며, 지나친 수정은 게이트에서 막는 작업 설계입니다. 도구 이름보다 이 편집 절차를 이해하면 다른 AI 글쓰기 파이프라인을 만들 때도 판단 기준으로 써먹을 수 있습니다.

공식 자료

• epoko77-ai/im-not-ai GitHub 저장소
• README.md
• 설치 가이드
• v2.3.2 릴리스 노트
• 전체 태그

자료 확인일: 2026년 9월 5일