im-not-ai 해설: AI 글 윤문은 탐지 점수보다 문체 신호·의미 보존·발행 게이트를 먼저 설계해야 하는 이유

1. 한 줄 문제 정의

핵심 한 줄: AI 글의 진짜 문제는 “AI가 썼는가”가 아니라, 독자가 읽을 때 번역투·근거 누락·의미 훼손을 알아차리기 전에 발행자가 잡아내지 못한다는 점입니다.

2026년 기준으로 블로그, 뉴스레터, 랜딩 페이지, 내부 문서 초안은 이미 ChatGPT, Claude, Gemini, Codex 같은 도구를 거쳐 나옵니다. 그래서 “AI 사용 금지”는 현실적인 운영 정책이 아닙니다. 더 중요한 질문은 AI가 만든 초안을 사람이 책임질 수 있는 문서로 바꾸는 검수 구조가 있느냐입니다.

이 글은 한국어 기술 블로그, 기업 콘텐츠, 교육 자료, 제품 문서를 운영하는 개발자와 콘텐츠 운영자를 위한 글입니다. 범위는 epoko77-ai/im-not-ai 같은 한국어 문체 검증 스킬을 사례로, 문체 신호 탐지, 의미 보존 감사, 출처 확인, 발행 전 게이트를 설계하는 방법입니다. 반대로 학생 과제의 저자 판정, 법적 증거 수집, 사람을 처벌하기 위한 AI 탐지 운영은 다루지 않습니다.

2. 먼저 결론

핵심 한 줄: im-not-ai는 “AI 탐지기”로 쓰기보다 “게시 전 문체 품질 게이트”로 쓸 때 가치가 큽니다.

제가 추천하는 도입 방식은 세 단계입니다. 첫째, AI 티를 점수 하나로 낙인찍지 않습니다. 둘째, 번역투·기계적 병렬·과도한 접속사·피동태 같은 문체 신호를 span 단위로 잡습니다. 셋째, 수정 뒤에는 수치, 고유명사, 직접 인용, 주장, 출처가 보존됐는지 따로 감사합니다.

im-not-ai는 이 방향에 맞는 좋은 사례입니다. 리포는 AI가 쓴 한국어 글에서 흔히 보이는 번역투, 영어 인용 과다, 기계적 불릿, “결론적으로/시사하는 바가 크다”류 관용구, 리듬 균일성, 과도한 형식명사를 10개 대분류와 60개 이상 서브 패턴으로 다룹니다. Claude Code에서는 strict 파이프라인, Codex와 Gemini CLI에서는 Fast 모드 중심으로 사용할 수 있다는 차이도 명시돼 있습니다.

다만 이 도구를 “사람 글인지 AI 글인지 판결하는 도구”로 쓰면 위험합니다. KatFishNet 논문도 한국어 AI 텍스트 탐지에는 띄어쓰기, 품사 다양성, 쉼표 사용 같은 언어별 신호가 필요하다고 말하지만, 탐지는 확률적 신호입니다. 발행 운영에서는 탐지보다 수정 가능한 품질 항목으로 바꾸는 게 더 안전합니다.

3. 핵심 구조 분해

핵심 한 줄: 좋은 윤문 워크플로는 탐지, 재작성, 의미 감사, 자연스러움 검증을 한 덩어리로 섞지 않습니다.

im-not-ai의 구조를 실무 관점으로 나누면 네 층입니다.

1. 문체 신호 탐지 층: “~를 통해”, “~에 있어서”, “첫째/둘째/셋째”, “결론적으로”, 문두 접속사 반복처럼 한국어 AI 글에서 자주 보이는 패턴을 찾습니다. 중요한 점은 문서 전체에 AI 점수를 붙이는 대신, 수정할 위치를 span으로 잡는다는 것입니다.
2. 수술적 윤문 층: 탐지된 구간만 고칩니다. 예를 들어 “AI 기술을 통해 효율을 높일 수 있다”는 “AI로 효율을 높인다”처럼 바꿀 수 있습니다. 문체는 자연스러워지지만 사실 관계는 그대로여야 합니다.
3. 의미 보존 감사 층: 수치, 날짜, 고유명사, 제품명, 직접 인용, 법률 조항, 핵심 주장이 바뀌지 않았는지 봅니다. 이 단계가 없으면 윤문은 쉽게 “그럴듯한 오역”이 됩니다.
4. 발행 판단 층: 최종 결과가 충분히 자연스러운지, 과윤문은 없는지, 출처 링크가 살아 있는지, 글의 책임자가 최종 확인했는지 결정합니다.

초보 개발자 기준으로 비유하면, 탐지는 린터이고 윤문은 자동 수정이며 의미 감사는 테스트입니다. 테스트 없이 자동 수정만 켜면 코드가 컴파일돼도 동작이 깨질 수 있습니다. 글도 같습니다.

4. 설계 의도 해설

핵심 한 줄: 한국어 AI 글은 영어권 humanizer를 그대로 가져오면 놓치는 신호가 많아서, 언어별 문체 규칙과 의미 보존 규칙을 분리해야 합니다.

영어권 humanizer는 주로 perplexity, burstiness, 문장 다양성 같은 신호를 봅니다. 하지만 한국어에서는 번역투 조사, 피동태, 관계절식 긴 관형구, 쉼표 위치, 형식명사 반복, 영어식 대명사 사용 같은 신호가 더 직접적으로 보입니다. im-not-ai가 한국어 패턴을 별도 taxonomy로 관리하는 이유가 여기에 있습니다.

Claude Code 문서의 skills 구조도 이 설계와 잘 맞습니다. skills는 반복해서 붙여 넣는 절차, 체크리스트, 다단계 작업을 SKILL.md로 분리해 필요할 때만 로드하는 방식입니다. 즉 “좋은 글로 고쳐줘”라는 감각적 요청을, 탐지 기준과 검증 절차가 있는 재사용 가능한 작업 매뉴얼로 바꾸는 셈입니다.

대신 포기하는 것도 있습니다. strict 파이프라인은 Fast 모드보다 느리고, 8,000자 이상 장문에서는 검토 시간이 늘어납니다. 또 완벽한 자동 판정은 없습니다. 발행 책임을 AI 도구에 넘기는 것이 아니라, 사람이 검수할 항목을 더 선명하게 만드는 구조로 이해해야 합니다.

5. 근거 및 비교

핵심 한 줄: 비교 대상은 AI 탐지기, 일반 윤문 프롬프트, 사람 편집자, 그리고 문체 검증 스킬입니다.

접근	장점	한계	권장 상황
일반 AI 탐지기	빠르게 확률 점수를 준다	한국어 장르별 오탐 가능성이 있고 수정 지점을 충분히 설명하지 못할 수 있다	대략적인 위험 신호 확인
일반 윤문 프롬프트	도입이 쉽고 비용이 낮다	수치·고유명사·주장 훼손을 놓치기 쉽다	짧은 내부 메모, 낮은 위험 문서
사람 편집자	맥락 판단과 책임 소재가 가장 분명하다	반복 패턴 탐지와 대량 초안 처리에는 시간이 많이 든다	브랜드 문서, 법무·의료·투자 문서
im-not-ai식 문체 검증 스킬	한국어 AI 티 패턴을 명시하고 의미 보존 감사를 분리한다	도구 설치와 운영 규칙이 필요하고, 최종 책임자는 여전히 사람이다	기술 블로그, 교육 콘텐츠, 기업 지식문서 발행 전 게이트

ACL 2025의 KatFishNet 논문은 한국어 LLM 텍스트 탐지를 위해 띄어쓰기 패턴, 품사 다양성, 쉼표 사용을 분석했고, 기존 최고 탐지 방법보다 평균 19.78% 높은 AUC-ROC를 보고했습니다. 이 수치는 한국어에는 한국어 전용 신호가 필요하다는 근거로 볼 수 있습니다. 다만 운영 관점에서는 탐지 성능보다 “오탐이 나왔을 때 무엇을 고칠 것인가”가 더 중요합니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 발행 게이트는 초안 생성 뒤에 한 번 돌리는 장식이 아니라, 초안 입력부터 최종 승인까지 연결된 체크포인트여야 합니다.

1. 초안의 책임 범위를 정합니다.
   예: “이 글은 AI 초안을 사용했지만, 수치·출처·추천 판단은 작성자가 검증한다.” 내부 문서라면 PR 템플릿이나 CMS 체크박스에 넣습니다.
2. 문체 탐지 기준을 고정합니다.
   예: S1은 무조건 수정, S2는 3회 이상 반복 시 수정, S3는 다른 패턴과 겹칠 때만 수정. 기준이 없으면 리뷰어마다 판단이 흔들립니다.
3. Fast와 strict를 나눕니다.
   5,000자 이하 블로그 초안은 Fast로 1차 정리하고, 8,000자 이상 장문·광고 문구·외부 배포 문서는 strict 또는 사람 리뷰를 붙입니다.
4. 의미 보존 감사표를 둡니다.
   수치, 단위, 날짜, 고유명사, 직접 인용, 출처 제목, 링크, 핵심 주장을 별도 목록으로 만들고 수정 전후를 비교합니다.
5. 출처 링크를 발행 직전 확인합니다.
   본문 참고자료는 평문 URL 나열이 아니라 제목이 붙은 HTML 링크로 넣습니다. 클릭 가능한 링크와 접근 날짜를 함께 관리하면 CMS 이관 때 깨진 링크를 잡기 쉽습니다.
6. 최종 DoD를 자동화합니다.
   예: img 포함, 참고자료 anchor 형식, 평문 URL 없음, 필수 섹션 7개 이상, 의미 보존 체크 완료, 작성자 관점 포함을 발행 스크립트에서 확인합니다.

// 문서 발행 게이트 예시
const gate = {
  styleSignals: { s1: 0, s2Max: 2 },
  fidelity: ['numbers', 'dates', 'names', 'quotes', 'claims', 'links'],
  publishing: ['referencesAsAnchors', 'noPlainUrlList', 'authorViewpoint', 'definitionOfDone']
};

7. 실수/함정(Pitfalls)

핵심 한 줄: AI 문체 검증에서 가장 흔한 실패는 탐지를 처벌 도구로 쓰거나, 윤문을 의미 보존 없이 자동 적용하는 것입니다.

• 함정 1: 탐지 점수로 사람을 판정한다.
  예방: 탐지 결과를 “AI 사용 증거”가 아니라 “검토할 문체 신호”로 기록합니다.
  복구: 점수만 남긴 리뷰는 폐기하고, 수정 가능한 span과 근거 문장을 다시 뽑습니다.
• 함정 2: 자연스럽게 고치다가 사실을 바꾼다.
  예방: 수치, 날짜, 인용문, 제품명은 수정 금지 목록에 넣습니다.
  복구: 변경 전후 diff에서 금지 목록이 바뀌면 해당 문단을 롤백하고 다시 윤문합니다.
• 함정 3: 모든 글을 같은 강도로 윤문한다.
  예방: 내부 메모, 블로그, 광고 문구, 법무 문서의 허용 변경률을 다르게 둡니다.
  복구: 과윤문이 발생하면 강도를 낮추고 S1 패턴만 제거합니다.
• 함정 4: 출처 확인을 문체 검수와 섞는다.
  예방: 문체 게이트와 사실 게이트를 분리합니다. 문장이 자연스러워도 출처가 틀리면 발행 금지입니다.
  복구: 참고자료를 1차 출처 우선으로 다시 정렬하고, 링크 제목과 날짜를 보강합니다.

8. 강점과 한계

핵심 한 줄: im-not-ai식 접근의 강점은 반복 가능한 기준이고, 한계는 자동화가 책임을 대신하지 않는다는 점입니다.

강점은 명확합니다. 한국어 AI 글에서 자주 보이는 패턴을 taxonomy로 관리하면 리뷰어가 매번 감으로 판단하지 않아도 됩니다. Claude Code의 plugin/skills 구조를 쓰면 팀 단위로 같은 절차를 공유하기도 쉽습니다. Codex CLI와 Gemini CLI Fast 모드를 지원한다는 점도 여러 작업 환경에서 활용하기 좋습니다.

한계도 분명합니다. 첫째, 좋은 사람 글도 정돈된 문체 때문에 탐지 신호에 걸릴 수 있습니다. 둘째, 문체를 고쳤다고 글의 근거가 좋아지는 것은 아닙니다. 셋째, 브랜드 톤이 강한 글은 “자연스러운 한국어”보다 “브랜드답게 말하는 방식”이 더 중요할 수 있습니다. 이 경우 taxonomy를 그대로 적용하기보다 사내 스타일가이드와 함께 조정해야 합니다.

그래서 저는 이 도구를 단독 결재권자로 두는 것을 비추천합니다. 대신 편집자, 개발자, 마케터가 같은 체크리스트로 초안을 통과시키는 보조 게이트로 두는 것을 추천합니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 다음 단계는 도구 설치가 아니라, 우리 조직의 문서 장르별 실패 패턴을 모으는 것입니다.

• 한국어 AI 텍스트 신호: KatFishNet 논문의 띄어쓰기, 품사 다양성, 쉼표 사용 분석을 먼저 봅니다.
• 스킬 운영 구조: Claude Code의 skills와 plugins 문서를 보고 개인 절차와 팀 배포 절차를 나눕니다.
• im-not-ai 내부 구조: taxonomy, rewriting playbook, fidelity audit 흐름을 봅니다. 특히 “탐지 없는 구간은 건드리지 않는다”는 원칙이 중요합니다.
• CMS 발행 자동화: 참고자료 anchor 형식, 평문 URL 검사, 이미지 포함 여부, 필수 섹션 검사를 스크립트로 자동화합니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 발행 기준은 “AI 티가 안 난다”가 아니라 “사람이 책임질 수 있는 문서가 됐다”여야 합니다.

• 문서 장르별 윤문 강도와 변경률 상한이 정해져 있는가?
• S1/S2/S3 같은 문체 신호 기준이 리뷰어에게 공유돼 있는가?
• 수치, 날짜, 고유명사, 직접 인용, 핵심 주장의 의미 보존 검사가 끝났는가?
• 참고자료는 클릭 가능한 HTML anchor 형식이며, 평문 URL 나열이 없는가?
• 탐지 결과를 사람 처벌이나 저자 판정 근거로 쓰지 않는다는 운영 원칙이 있는가?
• Fast 모드와 strict/사람 리뷰로 넘기는 기준이 문서화돼 있는가?
• 최종 발행 책임자가 도구 결과가 아니라 본문 자체를 읽고 승인했는가?

Definition of Done: 문체 신호 S1 0건, 의미 보존 감사 통과, 출처 링크 확인, 작성자 관점 명시, 발행 책임자 승인까지 끝났을 때만 게시합니다.

제 판단은 이렇습니다. AI 글을 많이 쓰는 팀일수록 “AI 티 제거”라는 말보다 “문체 검증 게이트”라는 말을 써야 합니다. 전자는 숨기는 느낌이 강하고, 후자는 책임지는 구조를 만듭니다. im-not-ai는 그 구조를 한국어 문서 운영에 맞춰 생각하게 해주는 좋은 출발점입니다.

참고자료

• epoko77-ai/im-not-ai GitHub README (확인일: 2026-06-29)
• im-not-ai INSTALL.md: Claude Code, Codex CLI, Gemini CLI 설치 방식 (확인일: 2026-06-29)
• KatFishNet: Detecting LLM-Generated Korean Text through Linguistic Feature Analysis (ACL 2025)
• Claude Code Docs: Extend Claude with skills (확인일: 2026-06-29)
• Claude Code Docs: Create plugins (확인일: 2026-06-29)