humanize-doc

name

humanize-doc

description

마크다운 문서에서 AI가 작성한 티가 나는 단어, 문장, 문장부호, 구조, 톤을 사람 전문가가 직접 쓴 글처럼 고치는 반복 루프 KernForge 내장 스킬. 매 루프마다 web_search로 최신 AI 문체 판별 동향(AI스러운 단어/문장/문장부호 목록)을 수집해 체크리스트를 갱신하고, 탐지-수정-블라인드 판정을 목표 달성까지 반복한다. "휴머나이즈", "humanize", "AI 티 제거", "AI 냄새", "AI스러운 문장 고쳐줘", "사람이 쓴 것처럼", "AI 문체 제거", "자연스러운 문장으로 다듬어", "말투가 기계 같아/로봇 같아", "결론적으로, 살펴보겠습니다 같은 상투 말투 없애줘", "make this sound human", "remove AI writing style" 등의 요청에 트리거한다. "AI"라는 단어가 없어도 마크다운 문서/스크립트/블로그 글의 기계적인 말투나 상투 표현을 없애 달라는 요청이면 사용한다. 문서를 공개/제출/게시하기 전에 문체를 사람답게 다듬어 달라는 요청, AI 초안을 최종본으로 완성해 달라는 요청에도 사용한다.

Humanize Doc — AI 문체 제거 루프 (KernForge 내장)

마크다운 문서를 입력받아, AI가 작성한 흔적(단어, 문장 패턴, 문장부호, 구조, 톤)이 사라질 때까지 탐지-수정-판정 루프를 반복한다. 성공 기준은 하나다: 문서 전체가 해당 분야의 사람 전문가가 직접 쓴 글로 판정받는 것.

KernForge 도구 매핑

이 스킬은 KernForge 네이티브 도구만 쓴다.

• 입력/출력: read_file로 문서를 읽고, replace_in_file(정밀 치환) 또는 apply_patch로 수정한다. 새 파일은 write_file.
• 백업: 원본을 write_file로 <이름>.orig.md에 복사(먼저 read_file로 내용을 읽어 그대로 기록).
• 기계적 스캔: grep으로 체크리스트의 단어/문장부호 패턴을 찾는다.
• 웹 조사: web_search(쿼리), web_fetch(본문 확인).
• 블라인드 판정: spawn_task로 read-only 조사 서브태스크를 띄운다(read_file/grep만 가능하므로 문서만 읽고 판정하기에 딱 맞다). 결과는 get_task로 회수한다.

왜 이렇게 하는가

AI스러운 글의 근본 원인은 개별 단어가 아니라 다음 다섯 가지다. 체크리스트에 없는 새로운 패턴을 만나도 이 근본 원인에 비추어 판단하라.

1. 균일한 리듬 — 문장 길이와 문단 길이가 전부 비슷하다. 사람은 3단어 문장 뒤에 40단어 문장을 쓴다.
2. 입장 부재 — 모든 관점을 균형 있게 다루고 아무것도 단정하지 않는다. 전문가는 의견을 가진다.
3. 경험 부재 — 구체적 수치, 실패담, 특정 도구/버전/에러 메시지 같은 디테일이 없다.
4. 과잉 신호 — "살펴보겠습니다", "결론적으로" 같은 이정표 문장과 완벽한 병렬 구조로 글의 뼈대를 그대로 노출한다.
5. 과잉 헤징 — "~일 수 있습니다", "일반적으로" 같은 책임 회피 표현이 문장마다 붙는다.

단어 치환(synonym swap)은 대표적인 실패 패턴이다. "delve"를 "explore"로 바꿔도 리듬과 톤은 그대로 AI다. 문장 단위로 다시 써라. 필요하면 문장을 합치고, 쪼개고, 순서를 바꿔라.

불변 조건

모든 루프에서 지킨다. 어기면 "자연스러운 문서"가 아니라 "다른 문서"가 된다.

1. 의미, 사실, 기술적 주장, 논리 전개는 그대로 유지한다. 문체만 바꾼다. 없는 사실을 지어내지 않는다.
2. 보호 영역은 수정하지 않는다: 코드 블록, 인라인 코드, URL과 링크 대상, 인용문(blockquote), YAML frontmatter, 고유명사, 수치, 표의 데이터 셀.
3. 원문의 레지스터를 유지한다: 합니다체는 합니다체로, 한다체는 한다체로, 영어 기술문서는 그 격식대로. 단, 같은 레지스터 안에서 어미와 구문은 다양화한다. 영어 문서에서 레지스터란 문서 유형의 격식 수준(README의 2인칭 안내체, 보고서의 무인칭체 등)을 말한다. 마케팅 카피 톤(과장 수사, 세일즈성 마무리)은 레지스터가 아니라 tell이므로 제거 대상이다.
4. 오버슈팅 금지: 목표는 "그 분야 전문가가 쓴 자연스러운 글"이지 반말 블로그나 구어체 수필이 아니다. 은어, 과한 감탄, 인위적 오탈자를 넣지 마라. 전문 문서에서는 그런 것 자체가 부자연스럽다.
5. 수정을 시작하기 전에 반드시 백업을 만든다.

워크플로우

Phase 0 — 준비

1. 입력 확보. 파일 경로를 받았으면 read_file로 읽는다. 채팅에 붙여넣은 텍스트라면 먼저 write_file로 작업 파일(.md)로 저장한 뒤 진행한다.
2. 백업 생성: read_file로 원본을 읽어 write_file로 같은 위치에 <이름>.orig.md로 저장한다.
3. 문서 프로필 작성: 주제 도메인, 대상 독자, 언어(한국어/영어/혼합), 레지스터, 문서 유형(기술문서/보고서/블로그/README)을 한 줄씩 정리한다. 이후 모든 수정은 이 프로필에 맞춘다.
4. 보호 영역 위치를 목록화한다(코드 블록 라인 범위 등).
5. references/ai-tells.md를 read_file로 읽고 작업 체크리스트를 초기화한다. 이 파일은 바닥선(baseline)이다 — 루프마다 웹 조사로 확장한다.

루프 — 최대 5회, 성공 시 즉시 종료

Step 1: 웹 조사 (매 루프 필수)

web_search로 2~3개 쿼리를 실행해 "지금 무엇이 AI스럽다고 판별되는가"의 최신 동향을 수집한다. 같은 쿼리를 반복하지 말고 루프마다 각도를 바꾼다.

• 루프 1 (포괄): AI-generated text telltale words <올해 연도>, ChatGPT writing style cliches list
• 쿼리 언어는 문서 언어를 따른다: 한국어 문서면 AI 문체 특징 챗GPT 말투 류의 한국어 쿼리를 반드시 포함하고, 영어 문서면 영어 쿼리로만 구성해도 된다. 혼합 문서는 두 언어 쿼리를 모두 넣는다.
• 루프 2 (잔여 문제 집중): 직전 판정에서 지적된 카테고리로 좁힌다. 예: 문장부호가 지적됐으면 AI writing em dash punctuation pattern
• 루프 3 이후 (판별기 관점): how AI detectors flag text, GPTZero perplexity burstiness what gets flagged, 특정 표현이 실제로 AI tell인지 검증하는 쿼리

유망한 출처는 web_fetch로 본문을 확인한다. 수집한 새 패턴(단어/구문/문장부호/구조)을 작업 체크리스트에 병합하고, 이번 루프에서 새로 반영한 항목을 기록해 둔다(최종 보고에 쓴다). 출처는 가려 쓴다: 서로 다른 출처 두 곳 이상에서 확인된 패턴만 병합하고, 휴머나이저 업체의 SEO성 글은 단어 후보 수집용으로만 쓴다. 검색이 실패하거나 유의미한 결과가 없으면 baseline 체크리스트만으로 계속 진행하고, 그 사실을 보고에 남긴다.

Step 2: 탐지

두 방식을 모두 쓴다. 하나만 쓰면 반드시 놓친다.

1. 기계적 스캔 — grep으로 체크리스트의 단어/문장부호 패턴을 찾는다. em-dash(—), 대표 AI 어휘, 반복 어미 등. 보호 영역 안의 히트는 제외한다.
2. 정독 스캔 — read_file로 문서를 처음부터 끝까지 읽으면서 리듬 균일성, 완벽 병렬 구조, 이정표 문장, 입장/경험 부재, 헤징 밀도를 잡는다. 기계적 스캔으로는 잡히지 않는 것들이다.

발견마다 기록한다: 위치(줄), 인용, 어떤 tell인지, 왜 AI스러운지.

Step 3: 수정

발견 목록을 순회하며 replace_in_file 또는 apply_patch로 다시 쓴다. 원칙:

• 문장 단위 재작성. 단어만 갈아끼우지 마라.
• 리듬을 부순다: 짧은 문장과 긴 문장을 섞고, 문단 길이를 다양화한다.
• 이정표를 지운다: "살펴보겠습니다", "결론적으로", "In conclusion" 없이도 글이 흐르도록 앞 문단의 개념을 다음 문단 첫 문장이 받게 한다.
• 헤징을 줄인다: 확실한 것은 단정하고, 불확실한 것에만 조건을 단다. 조건을 달 때는 근거를 함께 쓴다. "환경에 따라 다를 수 있다"가 아니라 원문에 근거가 있으면 그 환경을 명시한다.
• 병렬 구조를 부순다: 불릿 3개가 모두 같은 품사, 같은 길이로 시작하면 하나는 서술형으로 풀어 쓴다. 불릿일 필요가 없는 내용은 문단으로 되돌린다.
• 구체성을 살린다: 원문에 이미 있는 수치, 도구명, 조건을 문장의 중심으로 끌어온다. 단, 없는 사실을 만들어내면 안 된다 — 불변 조건 1이 우선이다.

세부 재작성 기법은 references/ai-tells.md 8절을 참조한다.

Step 4: 판정

수정이 끝난 문서를 블라인드 판정에 부친다.

우선 방식 — 블라인드 서브태스크(spawn_task). read-only 조사 서브태스크는 문서만 읽고 판정하기에 적합하다. 판정 전에 문서를 중립적인 이름의 임시 사본(예: .kernforge/tmp/doc-review-3f.md)으로 write_file 복사해 그 경로만 objective에 준다. 이 대화의 수정 이력, 이 스킬의 존재, "방금 humanize했다"는 사실을 절대 알리지 마라. 알려주는 순간 판정이 오염된다. 원본 경로에 든 단어(humanize, draft, ai 등)가 판정을 어느 쪽으로든 기울일 수 있어 중립 이름 사본을 쓴다. 판정 프롬프트는 문서 언어에 맞춘다 — 영어 문서면 아래 템플릿을 영어로 옮겨 쓴다.

<파일 경로>의 마크다운 문서를 read_file로 읽고 작성 주체를 판정하라.
이 파일 외의 다른 파일은 열지 마라.
(A) 사람 전문가가 직접 작성 / (B) AI가 생성했거나 AI 흔적이 남아 있음
(B)라면 근거를 전부 나열하라: 줄 번호, 해당 문장 인용, 이유.
확신 없는 지적과 단순 취향 지적은 제외하라. 확신할 근거가 0건이면 (A)다.
출력 형식: 판정(A/B), 지적 목록(없으면 "없음"), 확신도(높음/중간/낮음)

spawn_task가 반환한 task_id를 get_task로 폴링해 완료된 결과를 수거한 뒤 판정을 확정한다. 결과를 수거하기 전에 "대기 중" 상태로 턴을 끝내지 마라.

대체 방식 — 서브태스크를 띄울 수 없거나 결과 수거에 실패한 경우(출력이 비어 있는 등): 수정 직후 바로 판정하지 말고 기계적 스캔을 한 번 다시 돌린 뒤, 문서를 "처음 받은 검수자" 관점으로 전체 정독하고 같은 출력 형식으로 판정한다. 자기 수정을 변호하지 말고 지적거리를 찾는 자세로 읽는다.

성공 조건 — 둘 다 만족해야 한다:

1. 갱신된 체크리스트 기준, 기계적 스캔 잔여 히트 0건 (보호 영역 제외)
2. 블라인드 판정 결과 (A), 확신 지적 0건

예외 규칙: 체크리스트 단어가 기술적 주장의 일부라서 빼면 의미가 바뀌는 경우, 불변 조건 1이 우선한다. 의미를 보존하는 다른 표현을 먼저 시도하고, 그래도 불가능하면 그 히트는 "의미 보존 예외"로 기록하고 잔여 히트로 세지 않는다. 예외 목록은 최종 보고에 남긴다.

성공이면 루프를 종료하고 최종 보고로 간다. 실패면 판정자의 지적 목록을 다음 루프의 최우선 수정 대상으로 넘기고, Step 1의 쿼리도 지적된 카테고리에 맞춘다.

종료 규칙

• 성공: 위 성공 조건 달성.
• 강제 종료 1: 루프 5회 도달. 잔여 지적을 숨기지 말고 그대로 보고한다.
• 강제 종료 2: 2회 연속 지적 건수가 줄지 않으면 수렴 실패로 종료한다. 고치면 다른 곳을 지적받는 무한 왕복은 판정자 노이즈일 가능성이 높다. 잔여 지적과 함께 그렇게 판단한 근거를 보고한다.

최종 보고 형식

## Humanize 결과
- 판정: 성공 | 부분 성공 (잔여 N건)
- 루프: N회 실행
- 파일: <결과 경로> (백업: <백업 경로>)

### 루프별 요약
| 루프 | 웹 조사 반영 | 탐지 | 수정 | 판정 |
|---|---|---|---|---|
| 1 | 새 패턴 n건 (핵심 항목 명시) | n건 | n건 | B — 지적 n건 |
| 2 | ... | ... | ... | A — 통과 |

### 주요 수정 (카테고리별 대표 예시, before -> after)
- 어휘: ...
- 문장: ...
- 문장부호: ...
- 구조/톤: ...

### 잔여 리스크
(부분 성공일 때만: 어떤 지적이 왜 남았고, 왜 더 고치지 않았는지.
의미 보존 예외로 남긴 히트가 있으면 여기 나열)

표의 "수정"은 편집 연산 횟수가 아니라 해소한 발견(탐지 항목) 수를 센다.

엣지 케이스

• 긴 문서(1,500줄 이상): 섹션 단위로 탐지-수정하되, 판정은 반드시 문서 전체로 한다. 섹션별로만 판정하면 문서 전반의 리듬 균일성을 놓친다.
• 혼합 언어 문서: 한국어/영어 체크리스트를 모두 적용한다. 인용문 안의 표현은 보호 영역이다.
• 이미 사람이 쓴 문서: 루프 1 탐지가 0건이면 판정만 한 번 돌리고 "수정 불필요"로 종료한다. 억지로 고치지 마라 — 과잉 수정도 문서를 망친다. 이 경로에서 판정이 (B)로 나오면 조기 종료를 취소하고 지적 목록을 들고 일반 루프로 진입한다. 무수정 종료가 확정되면 백업(.orig.md)은 원본과 동일하므로 삭제하고, 보고는 표준 형식에 "판정: 수정 불필요"로 쓰되 수정 예시 섹션은 생략한다.
• 개조식 문서(불릿 위주 설계 문서): 불릿 자체는 문서 유형의 관례다. 불릿 안의 완벽 병렬과 볼드-콜론 패턴만 다듬는다. 문서 유형의 관례와 AI tell을 혼동하지 마라.
• 사용자가 특정 표현 유지를 요청한 경우: 그 표현을 보호 영역에 추가하고 보고에 명시한다.