Run forever as a resident worker in ONE Codex turn: every 5 minutes poll a watched directory for new task files and execute each one to completion, then keep watching — the turn never ends. Use when the user says "queue-loop", "무한 루프로 돌려", "큐 감시해서 계속 실행", "resident worker", "watch a directory and run new tasks forever", or wants a single invocation that keeps picking up dropped commands indefinitely. Because the work stays inside one already-running turn, it keeps issuing model requests across usage-limit windows (the workspace spend cap gates only NEW top-level turns, not an in-flight one). Do NOT use for a single one-shot task, or when the user wants the turn to finish and report back.

2026-07-260

writing-fixer

hletrd/setup

Use when the user wants Korean prose cleaned of AI tone, stiff old-fashioned (할아버지/훈장/공문서) tone, translationese, and excessive quotation marks - or asks to "글 다듬어", "자연스럽게", "AI 말투 제거", "할아버지 말투 빼", "deslop 한국어", or "writing-fixer". Removes as many AI and unnatural expressions as possible in one thorough pass while preserving meaning, code, math, and markup. Korean prose only.

2026-07-260

queue-submit

hletrd/setup

Inject a task into the queue-loop worker's queue so a running Codex resident worker picks it up on its next poll (~5 min). Use when the user says "queue-submit", "큐에 작업 넣어", "task 주입해", "이거 워커한테 넘겨", "submit a task to the codex worker", "enqueue this for queue-loop", or wants to hand a job off to the always-on worker instead of doing it inline. It only writes a *.task file into the watched queue directory (default ~/codex-queue) — it does NOT run the task in this session. Do not use when the user wants the work done right now in the current session.

2026-07-250

review-plan-fix

hletrd/setup

Iteratively review the current repository, plan fixes from the reviews, and implement the plans. Runs three prompts in strict order (deep review → plan from reviews → implement with ralph) and repeats the full three-prompt cycle up to N times (default 100). Context is cleaned between iterations by spawning each full cycle in a fresh subagent.

2026-07-160

agent-browser-config

hletrd/setup

Browser configuration: viewport sizing, device emulation, geolocation, offline mode, color scheme, and HTTP settings.

2026-03-100

agent-browser-debug

hletrd/setup

Browser debugging: execute JavaScript, view console output and page errors, record traces, and run performance profiling.

2026-03-100

تشغيل أي مهارة بنقرة واحدة

name	korean-naturalizer
version	1.0.0
description	한국어 텍스트에서 AI가 쓴 흔적, 번역체, 부자연스러운 표현을 제거하고 자연스러운 한국어로 다시 써 주는 스킬. 말투 통일, 문장부호 교정, 피동 표현 정리, 영어 직역체 제거를 수행한다.
allowed-tools	["Read","Write","Edit","Grep","Glob","AskUserQuestion"]

한국어 자연화: AI 말투 제거 및 문체 교정

입력받은 한국어 텍스트에서 AI가 쓴 흔적을 모두 제거하고, 사람이 쓴 것처럼 자연스러운 한국어로 다시 쓴다.

적용 범위 (Scope)

이 스킬은 한국어 산문(문서, 블로그, 이메일, README, 기사, 주석 등) 전용이다. 목적과 대상이 다른 슬롭 제거 스킬은 각자의 영역에서 쓴다.

상황	사용 스킬
한국어 산문의 AI 말투 제거	이 스킬 (korean-naturalizer)
코드 자체의 AI 슬롭 (중복, 죽은 코드, 껍데기 추상화 등)	`oh-my-claudecode:ai-slop-cleaner`
영어 산문의 AI 말투 제거	`humanizer`
한국어 산문 + 내부 코드 슬롭이 섞인 저장소	`ai-slop-cleaner`로 코드 정리 → 이 스킬로 문서/주석 정리 (두 패스로 분리)

경계 규칙: 코드는 건드리지 않는다. 코드 내 한국어 주석이 명백히 AI 말투이고 사용자가 문서성 주석 정리를 요청한 경우에만 주석 텍스트를 교정한다. 코드의 로직, 식별자, 시그니처는 이 스킬의 범위 밖이다.

작업 원칙 (ai-slop-cleaner에서 차용)

텍스트 교정도 코드 정리와 같은 규율을 따른다. 다음은 oh-my-claudecode:ai-slop-cleaner의 집행 태세를 산문 작업에 맞춰 옮긴 것이다.

원뜻 보존 (behavior-preservation): 사용자가 명시적으로 의미 변경을 요청하지 않는 한, 문장의 사실적·주장적 내용은 바꾸지 않는다. 바꾸는 것은 말투와 표현뿐이다. 구체 수치·고유명사·인과 관계·문장의 주어/목적어/동사 역할을 임의로 교체하지 않는다.
삭제 우선 (deletion-first): 새 표현을 끼워 넣기 전에 먼저 지워도 되는 것부터 지운다. 빈 수식어, 뻔한 도입/마무리, 중복 강조, 불필요한 영어 병기가 최우선 삭제 대상이다.
범위를 좁힌다 (scoped): 사용자가 파일 목록이나 문단 범위를 지정했으면 그 밖으로 나가지 않는다. 원문 어딘가가 눈에 띈다고 해서 무단으로 범위를 넓히지 않는다.
한 번에 한 가지 스멜만 (one smell per pass): 한 번에 뒤섞어 고치지 않는다. 먼저 삭제 패스, 다음 피동 정리 패스, 다음 말투 통일 패스 식으로 순차로 처리하면 검증이 쉽다.
의존성 추가 금지 (no new scope): 새 예시, 새 주장, 새 섹션을 AI 슬롭 제거를 핑계로 슬쩍 끼워 넣지 않는다. 슬롭 제거는 빼는 작업이지 채우는 작업이 아니다.
증거 중심 보고 (evidence-dense report): 교정 후에는 무엇을 왜 지웠는지, 어떤 규칙 번호에 해당하는지 간결하게 적는다. 추측이 아니라 근거로 말한다.
리뷰어 분리 (writer/reviewer separation): 직접 교정한 내용을 같은 패스에서 스스로 "좋다"고 승인하지 않는다. 큰 분량(1000자 이상)이나 공개 발행용 글은 교정 패스와 점검 패스를 나눈다.

작업 순서

문체 선택을 먼저 묻는다 (필수, 건너뛰지 않는다). 원문의 말투가 한 가지로 확실해 보여도, 사용자가 바꾸고 싶을 수 있으므로 교정 시작 전에 반드시 AskUserQuestion으로 문체를 받는다. 아래 "문체 인터뷰" 절 참고.
범위를 확인한다. 파일 목록·문단 범위가 지정됐으면 그 밖으로 나가지 않는다.
입력 텍스트를 처음부터 끝까지 읽고, 교정 계획(어떤 규칙을 어느 문단에 적용할지)을 먼저 메모한다. 계획 없이 바로 수정하지 않는다.
삭제 패스부터 돌린다: 뻔한 도입/마무리, 빈 수식어, 불필요한 영어 병기, 과한 볼드·불릿을 먼저 지운다. (원뜻 유지 확인)
문법·피동·번역체 패스: 이중 피동, "-되다" 남용, "have" 직역, 관계절 과다를 손본다.
AI 슬롭 패턴 패스(섹션 11): 규칙의 삼, 공허한 상징, 홍보성 어휘, 부정 평행, 피상 분석, 모호한 출처, 연결어 과잉, AI 상투어휘를 제거한다.
말투·리듬 패스: 1단계에서 고른 문체로 전체를 맞추고, 문장 길이와 연결어를 다듬는다.
최종 점검 패스 (섹션 12): 체크리스트를 돌리고, 원문 대비 사실 내용이 왜곡되지 않았는지 확인한다.
교정된 텍스트와 함께 교정 내역(어떤 규칙 번호가 어디에 적용됐는지)을 간결히 출력한다.

문체 인터뷰 (교정 시작 전 필수)

교정 전에 아래 세 가지를 AskUserQuestion으로 받는다. 사용자가 "원문 그대로" 유지하길 원할 수 있으므로, 기본 선택지에 "원문 판단에 맡김"을 포함한다.

질문 1 — 문체 기조 (구어체 vs 문어체)

선택지	설명	예시
문어체 (격식, 글말)	문서, 논문, 공지, 기사 등	"이 방법으로 성능이 올랐다."
구어체 (캐주얼, 입말)	블로그, 에세이, 커뮤니티 글, 대화	"이렇게 하니까 빨라지더라고요."
반구어체 (친근한 문어)	튜토리얼, 사내 문서, 개발 블로그	"이 방법을 쓰면 빨라져요."
원문 판단에 맡김	원문 톤을 그대로 유지	—

질문 2 — 종결 어미 (설명문 vs 합쇼체 vs 해요체 vs 해체)

선택지	어미	쓰임새	예시
하다체 (~이다/~한다)	설명문, 논문체	기술 문서, 위키, 논문, 뉴스 기사	"이 방법을 쓴다."
합쇼체 (~합니다/~입니다)	격식 경어	공식 문서, 보고서, 프레젠테이션, 강연 원고	"이 방법을 씁니다."
해요체 (~해요/~이에요)	친근 경어	블로그, 안내문, 튜토리얼	"이 방법을 써요."
해체 (~해/~야)	반말	캐주얼 에세이, 친구에게 보내는 글	"이 방법 써."
원문 판단에 맡김	—	원문 그대로 유지	—

"설명문 투"(~이다 계열)와 "합쇼체"(~입니다 계열)는 둘 다 문어체지만 사용 맥락이 다르다. 논문·기사는 설명문, 공식 보고·매뉴얼은 합쇼체가 자연스럽다.

질문 3 — 교정 강도

선택지	내용
약 (문법·오탈자 위주)	맞춤법, 띄어쓰기, 이중 피동만 손댄다. 말투는 유지
중 (AI 흔적 제거)	빈 수식어·AI 상투어·번역체를 교정. 구조는 유지
강 (전면 자연화)	문장 구조·리듬·섹션 길이까지 재구성. 원뜻만 유지

사용자가 세 질문에 답하지 않고 그냥 "자연스럽게 고쳐 달라"고 하면, 기본값으로 문어체 / 하다체 / 중 으로 설정하되, 출력에서 이 기본값을 사용했음을 명시한다.

1. 문장부호 교정

한국어에서 쓰이지 않는 문장부호를 모두 바꾼다.

잘못된 부호	교정 방법
em dash (—)	쉼표, 괄호, 마침표로 대체
en dash (–)	쉼표, 물결표(~), "부터/까지"로 대체
가운뎃점 (·)	쉼표로 구분하거나 "및", "과/와"로 연결
curly quotes (" ")	쌍따옴표("")로 교체
curly single quotes (' ')	작은따옴표('')로 교체
말줄임표 (...) 남용	꼭 필요한 곳만 남기고 삭제

교정 예시:

Before	After
이 기술은 다양한 분야—의료, 금융, 교육—에서 쓰인다.	이 기술은 의료, 금융, 교육 등 여러 분야에서 쓰인다.
2020–2024년 사이에	2020년부터 2024년 사이에
속도·정확도·안정성을 모두 갖췄다.	속도, 정확도, 안정성을 모두 갖췄다.
"혁신적인 접근법"이라고 평가했다.	"혁신적인 접근법"이라고 평가했다.

2. AI 특유 어휘 제거

아래 단어와 표현이 보이면 삭제하거나 구체적인 말로 바꾼다.

2.1. 빈 수식어 (삭제 또는 구체화)

"다양한", "다양하게", "폭넓은", "폭넓게"
"핵심적인", "근본적인", "본질적인"
"혁신적인", "획기적인", "선도적인", "선구적인"
"심층적으로", "포괄적으로", "체계적으로", "종합적으로"
"주목할 만한", "흥미로운 점은", "놀라운 것은"
"중요한", "핵심적인" (뒤에 "역할을 한다"가 붙을 때)
"보다 효과적인", "보다 효율적인" ("더"로 줄이거나 구체 수치로)

Before	After
다양한 분야에서 중요한 역할을 한다.	검색 엔진, 추천 시스템, 자동 번역에 쓰인다.
혁신적인 접근법을 제안한다.	기존보다 20% 빠른 방법이다.
보다 효과적인 결과를 보여준다.	정확도가 3% 올랐다.

2.2. AI 상투어 (삭제)

"살펴보겠습니다", "알아보겠습니다", "자세히 살펴보면"
"~라고 할 수 있다", "~라고 볼 수 있다"
"이를 통해", "이를 기반으로", "이를 바탕으로"
"궁극적으로", "결론적으로", "종합적으로"
"~에 기여한다", "~를 가능하게 한다", "~를 제공한다"
"~하는 데 있어", "~의 관점에서", "~라는 측면에서"
"~와(과) 관련하여", "~에 대해 논의하면"

Before	After
이제 성능에 대해 살펴보겠습니다.	(삭제하고 바로 성능 이야기로)
이를 통해 성능을 향상시킬 수 있다.	그래서 빨라진다.
결론적으로 의미 있는 기여를 했다고 볼 수 있다.	(삭제. 이미 본문에서 다 말했다.)

2.3. 영어 직역 어휘 (한국어다운 표현으로)

영어 직역	자연스러운 한국어
활용하다 (utilize)	쓰다, 사용하다
수행하다 (perform)	하다, 처리하다
제공하다 (provide)	주다, 내놓다
도출하다 (derive)	끌어내다, 얻다
탐구하다 (explore)	찾아보다, 알아보다
논의하다 (discuss)	이야기하다, 따지다
시사하다 (imply/suggest)	보여주다, 뜻하다
기여하다 (contribute)	도움이 되다, 보태다
촉진하다 (promote/facilitate)	돕다, 빠르게 하다
구현하다 (implement)	만들다, 짜다 (문맥에 따라)
직면하다 (face)	부딪히다, 겪다
존재하다 (exist)	있다
동반하다 (accompany)	따르다, 함께 오다
기인하다 (be caused by)	때문이다, 탓이다

2.4. 비격식 강조어와 주관적 형용사

격식 있는 기술 문서에 구어체 강조 부사나 감정적 형용사가 섞이면 톤이 무너진다. 특히 "진짜", "그냥", "완전", "되게" 같은 표현을 문어체에 쓰지 않는다.

Before	After
이 규칙이 진짜 강제는 아니다	이 규칙이 완전한 강제는 아니다
백업이 진짜 필요한 경우	백업이 꼭 필요한 경우
그냥 기본값으로 두는 게 안전하다	기본값으로 두는 편이 안전하다
진짜로 지우고 싶다면	실제로 지우고 싶다면
되게 빠르다	매우 빠르다 / 아주 빠르다

또한 코드, 알고리즘, 데이터 구조처럼 감정 없는 대상에 주관적 형용사를 쓰지 않는다.

Before (주관적)	After (중립적)
예쁜 코드	깔끔한 코드, 읽기 좋은 코드
흉측한 이름	알아보기 어려운 이름
아름다운 알고리즘	우아한 알고리즘, 단순한 알고리즘
끔찍한 API	쓰기 어려운 API
멋진 최적화	효과적인 최적화

2.5. 부사 중복

같은 강조 부사를 한 문장 안에 두 번 이상 쓰지 않는다. AI는 강조를 위해 "매우 매우", "아주 아주" 식으로 반복하거나, "아주 X 아주 Y" 같은 중복 패턴을 만든다.

Before	After
아주 작은 파일을 아주 많이 만들면	작은 파일을 수없이 만들면
매우 중요하고 매우 어려운 문제	까다로운 핵심 문제
정말 정말 빠르다	매우 빠르다
너무 너무 느리다	참을 수 없이 느리다

2.6. 에둘러 말하기

AI는 부정적 사실을 직접 말하지 않고 에둘러 쓴다. 사실을 그대로 쓴다.

AI 말투	자연스러운 표현
~을/를 잃었습니다	0점입니다 / 틀렸습니다
감점이 있었습니다	틀렸습니다
오류가 있었습니다	틀렸습니다
~를 놓쳤습니다	~를 틀렸습니다
방향은 잡았으나	방향은 맞았지만
눈에 띄는 성과입니다	(구체적 사실로 대체)
돋보입니다 / 인상적입니다	(구체적 사실로 대체)

3. 부자연스러운 피동 표현 교정

한국어는 능동문이 자연스럽다. 영어식 수동태를 능동으로 바꾼다.

3.1. 이중 피동 (틀린 문법)

Before	After
만들어지게 되다	만들어지다 / 만들다
읽혀지다	읽히다
보여지다	보이다
잊혀지다	잊히다
쓰여지다	쓰이다
지어지다	짓다 (능동으로)

3.2. 불필요한 피동 (능동으로 전환)

Before	After
이 방법이 사용된다.	이 방법을 쓴다.
문제가 해결되었다.	문제를 해결했다. / 문제가 풀렸다.
성능이 향상되었다.	성능이 올랐다. / 성능을 올렸다.
결과가 도출되었다.	결과를 얻었다. / 결과가 나왔다.
데이터가 수집되었다.	데이터를 모았다.
실험이 수행되었다.	실험했다. / 실험을 돌렸다.
모델이 학습되었다.	모델을 학습시켰다. / 모델이 학습했다.

3.3. "-되다" 남용

"-하다" 동사를 "-되다"로 바꿔 쓰는 습관을 교정한다.

Before	After
추정된다	추정할 수 있다 / ~로 보인다
판단된다	~로 보인다 / ~인 듯하다
요구된다	필요하다
기대된다	기대할 수 있다 / ~일 것이다
우려된다	걱정스럽다 / 걱정이 된다

3.4. "have" 직역 ("~를 갖다 / 갖고 있다")

영어 "have"를 그대로 "갖다", "갖고 있다"로 옮기면 번역체가 된다. 한국어는 "있다"를 쓴다.

Before	After
이 객체는 세 개의 속성을 갖는다	이 객체에는 속성이 세 개 있다
이 표는 두 개의 열을 갖고 있다	이 표에는 열이 두 개 있다
함수가 반환 값을 갖지 않는다	함수에 반환 값이 없다
배열이 n개의 원소를 가진다	배열에는 원소가 n개 있다
클래스가 생성자를 갖고 있다	클래스에 생성자가 있다

예외: 추상적·비유적 의미일 때는 "갖다"가 자연스러울 수 있다. ("관심을 갖다", "의미를 갖다" 등)

4. 번역체 문장 구조 교정

4.1. 관계절 과다 (영어 관계대명사 직역)

Before	After
우리가 사용하는 방법은 기존에 제안된 방법을 개선한 것으로서 성능을 높이는 데 기여하는 접근법이다.	우리는 기존 방법을 개선해서 성능을 올렸다.
저자가 제안한 모델은 기존 모델이 가지고 있던 한계를 극복한 모델이다.	이 모델은 기존 한계를 넘었다.

4.2. 명사 과다 (명사구 나열)

Before	After
성능 향상의 달성을 위한 방법론의 적용	성능을 올리려고 이 방법을 썼다
데이터 처리 과정의 효율성 개선	데이터 처리를 더 빠르게 했다
사용자 경험의 극대화를 위한 인터페이스 설계	쓰기 편한 화면을 만들었다

4.3. 주어 생략 과다 / 주어 불일치

한국어는 주어를 적절히 생략하지만, AI는 주어 없이 문장을 계속 이어 누가 하는 건지 헷갈리게 한다. 필요한 곳에 주어를 넣어 준다.

4.4. 한 문장에 절이 너무 많음

Before	After
A는 B이며, C를 통해 D를 E하고, F와 G를 H함으로써 I를 달성한다.	A는 B다. C로 D를 E한다. 그러면 F와 G가 H되면서 결국 I가 된다.

5. 강조 표현 정리

5.1. 볼드 남용

AI는 핵심 단어마다 볼드(bold)를 건다. 문단 하나에 볼드가 3개 이상이면 정리한다.

Before	After
성능이 크게 향상되어 사용자 경험이 개선되었습니다.	성능이 크게 올라서 쓰기 편해졌다.

5.2. 불릿 리스트 남용

AI는 뭐든 불릿으로 나열한다. 3개 이하이거나 한 줄짜리면 문장으로 풀어 쓴다.

Before	After
장점은 다음과 같습니다: - 빠르다 - 정확하다 - 쉽다	빠르고 정확하면서도 쓰기 쉽다.

5.3. 불필요한 영어 병기

맥락상 뻔한 영어는 빼고 한국어만 쓴다.

Before	After
초안 (Draft) 단계에서	초안 단계에서
성능 (Performance)을 비교했다	성능을 비교했다
확장성 (Scalability)이 좋다	확장성이 좋다

전문 용어가 처음 나올 때만 한 번 병기하고, 이후로는 한국어만 쓴다.

6. 구조적 AI 패턴 제거

6.1. 뻔한 도입/마무리 삭제

삭제 대상	이유
"이번 글에서는 ~에 대해 살펴보겠습니다."	읽으면 안다. 안내할 필요 없다.
"지금까지 ~에 대해 알아보았습니다."	읽었으니 안다. 요약할 필요 없다.
"이 글이 도움이 되셨기를 바랍니다."	챗봇 말투.
"궁금한 점이 있으시면 댓글로 남겨주세요."	챗봇 말투.
"그럼 시작해 보겠습니다!"	그냥 시작하면 된다.

6.2. 모든 섹션이 같은 구조

AI는 모든 섹션을 "도입 한 줄 + 본론 세 줄 + 마무리 한 줄"로 쓴다. 섹션마다 길이와 구조를 다르게 한다. 어떤 섹션은 한 문단이고, 어떤 섹션은 다섯 문단이어야 자연스럽다.

6.3. 3의 법칙 (Rule of Three)

AI는 모든 나열을 세 개로 맞춘다. 두 개면 두 개, 네 개면 네 개로 있는 그대로 쓴다.

Before	After
속도, 정확도, 안정성을 갖췄다.	속도랑 정확도가 좋다. (안정성이 실제로 언급 안 됐다면)

7. 말투 통일

문서 전체에서 말투를 하나로 맞춘다.

7.1. 말투 선택 기준

입력 텍스트의 원래 말투를 파악해서 그에 맞춘다. 판단이 어려우면 사용자에게 묻는다.

말투	쓰임새	예시
해요체 (~합니다/~입니다)	블로그, 안내문, 설명글	"이 방법을 쓰면 빨라집니다."
하다체 (~이다/~한다)	기술 문서, 위키, 논문	"이 방법을 쓰면 빨라진다."
해체 (~해/~야)	캐주얼 글, 대화체	"이 방법 쓰면 빨라져."

7.2. 말투 섞임 교정

한 문서 안에서 말투가 왔다 갔다 하면 하나로 맞춘다.

Before	After (하다체로 통일)
이 방법은 빠릅니다. 하지만 정확도가 낮다. 그래서 주의해야 해요.	이 방법은 빠르다. 하지만 정확도가 낮다. 그래서 주의해야 한다.

8. 문장 리듬

8.1. 문장 길이 변화

AI는 모든 문장을 비슷한 길이로 쓴다. 긴 문장 뒤에 짧은 문장을 넣어 리듬을 만든다.

Before	After
이 모델은 기존 방식보다 빠르다. 이 모델은 정확도도 높다. 이 모델은 메모리도 적게 쓴다.	기존 방식보다 빠르고 정확도도 높다. 메모리도 적게 먹는다. 셋 다 잡았다.

8.2. 연결어 반복 방지

"또한", "그리고", "더불어" 같은 연결어가 연달아 나오면 다른 방식으로 잇는다.

Before	After
또한 A도 좋다. 또한 B도 개선되었다. 또한 C 기능도 추가되었다.	A도 좋다. B도 나아졌고, C 기능까지 붙었다.

9. 자연스러운 한국어 표현

교정할 때 아래 표현을 적극적으로 쓴다.

9.1. 체언 종결

"~하는 구조다.", "~인 셈이다.", "~수준이다."

9.2. 자연스러운 종결어미

"~인데", "~더니", "~길래", "~다 보니", "~거든"
"~나 다름없다", "~일 수밖에 없다", "~라고 보면 된다"
"~치고는", "~답게"

9.3. 구어체 삽입 (문맥에 맞을 때)

"쉽게 말해", "한마디로", "거칠게 말하면"
"솔직히", "사실", "어쨌든"
"뭐 그렇다.", "그냥 그런 거다."

10. 한국어 문법 교정

AI는 한국어 문법 규칙을 자주 틀린다. 아래 항목을 반드시 점검한다.

10.1. "이다" 활용 오류

받침 있는 명사 뒤에는 "이다"를 써야 한다. "다"만 붙이면 틀린다.

Before (틀림)	After (맞음)
예시다	예시이다 / 예시다 (구어체 축약 허용 시)
이것은 결과다	이것은 결과이다 / 이것은 결과다 (문맥에 따라)
좋은 방법이 아닐 수 있다	(맞음 - "이" 포함)

규칙: 받침 있는 명사 + "이다", 받침 없는 명사 + "다". 단, 구어체에서는 "이"가 탈락할 수 있으나 문어체에서는 정확히 쓴다.

10.2. 조사 오류

Before (틀림)	After (맞음)	규칙
모델을 사용	모델을 사용	(맞음)
서버는 → 서버을	서버를	받침 없으면 "를"
결과은	결과는	받침 없으면 "는"
값를	값을	받침 있으면 "을"
속도와 정확도와	속도와 정확도 / 속도, 정확도와	"와/과" 반복 금지

10.3. 띄어쓰기

Before (틀림)	After (맞음)
할수있다	할 수 있다
해야한다	해야 한다
못하다 (보조 용언)	못 하다 / 못하다 (본용언)
되어지다	되다 (이중 피동이기도 함)
안될	안 될

10.4. 맞춤법

Before (틀림)	After (맞음)
됬다	됐다
안됀다	안 된다
웬지	왠지
몇일	며칠
어떻게 (의도가 "어째서"일 때)	어째서 / 왜
되요	돼요
할께요	할게요
금새	금세

10.5. 하다체 종결어미 오류 (동사 vs 형용사)

AI는 동사와 형용사의 하다체 종결어미를 자주 혼동한다.

규칙:

동사 하다체: -ㄴ다 / -는다 (받침 없으면 -ㄴ다, 있으면 -는다)
형용사 하다체: -다 (기본형 그대로)
있다/없다: -다 (형용사처럼 활용)

Before (틀림)	After (맞음)	이유
이 방법이 맞다.	이 방법이 맞는다.	"맞다"는 동사 → -는다
서버가 돌아가다.	서버가 돌아간다.	"돌아가다"는 동사 → -ㄴ다
값이 들어가다.	값이 들어간다.	"들어가다"는 동사 → -ㄴ다
이 함수는 리스트를 반환하다.	이 함수는 리스트를 반환한다.	"반환하다"는 동사 → -ㄴ다
오류를 발생시키다.	오류를 발생시킨다.	"발생시키다"는 동사 → -ㄴ다
좋는다.	좋다.	"좋다"는 형용사 → -다
빠르는다.	빠르다.	"빠르다"는 형용사 → -다
있는다.	있다.	"있다"는 형용사 활용 → -다
없는다.	없다.	"없다"는 형용사 활용 → -다

주의: 관형형에서는 반대다.

동사: -는 (돌아가는 서버, 맞는 방법)
형용사: -ㄴ / -은 (좋은 방법, 빠른 서버)
있다/없다: -는 (있는 값, 없는 파일)

10.6. 서술형 종결 혼동 (기본형을 문장 끝에 그대로 쓰는 오류)

AI가 문장 끝에 동사 기본형을 그대로 놓는 경우가 있다. 하다체든 해요체든 종결어미를 붙여야 한다.

Before (틀림)	After (하다체)	After (해요체)
이 값을 사용하다.	이 값을 사용한다.	이 값을 사용해요.
결과를 반환하다.	결과를 반환한다.	결과를 반환해요.
에러가 발생하다.	에러가 발생한다.	에러가 발생해요.
파일을 읽다.	파일을 읽는다.	파일을 읽어요.
설정을 변경하다.	설정을 변경한다.	설정을 변경해요.

10.7. 무정물 조사: "에게" vs "에"

"에게"는 유정물(사람, 동물)에만 쓴다. 무정물(프로그램, 컴파일러, 시스템, 함수, 객체 등)에는 "에"를 쓴다. AI는 영어의 "to"를 반영하며 모든 대상에 "에게"를 붙이는 경향이 있다.

Before (틀림)	After (맞음)
컴파일러에게 힌트를 준다	컴파일러에 힌트를 준다
함수에게 인자를 전달한다	함수에 인자를 전달한다
운영체제에게 요청을 보낸다	운영체제에 요청을 보낸다
서버에게 데이터를 준다	서버에 데이터를 준다
시스템에게 알린다	시스템에 알린다

예외: 유정물처럼 의인화한 경우(비유, 픽션)에는 "에게"도 허용된다.

유지 가능 (유정물)	의미
학생에게	사람
고양이에게	동물
친구에게 물어봤다	사람

11. AI 슬롭 패턴 (의미 보존, 삭제 우선)

섹션 1~10이 잡지 못하는 AI 특유의 글쓰기 패턴을 제거한다. 이 섹션은 humanizer 스킬의 "Signs of AI writing" 분류와 oh-my-claudecode:ai-slop-cleaner의 삭제 우선 원칙을 한국어 산문에 맞게 옮긴 것이다. 각 패턴마다 먼저 삭제가 가능한지부터 따진다. 삭제로 의미가 상하지 않으면 삭제한다.

11.1. 규칙의 삼 (Rule of Three) 억지 맞춤

AI는 나열을 항상 세 개로 맞춘다. 원문에서 실제로 언급된 항목 수대로 쓴다.

Before	After
빠르고, 정확하고, 안정적이다. (안정성은 언급 안 됨)	빠르고 정확하다.
속도, 비용, 확장성 세 측면에서 유리하다. (확장성 근거 없음)	속도와 비용 측면에서 유리하다.

11.2. 공허한 상징 (Inflated Symbolism)

의미보다 장식이 앞서는 비유 표현. 대부분 삭제해도 원뜻이 유지된다.

"~의 등불이 되다", "~의 문을 열다", "~의 이정표가 되다"
"새로운 지평을 열다", "시대의 흐름을 선도하다"
"~라는 여정의 시작", "~라는 모험"
"패러다임의 전환", "게임 체인저"

Before	After
이 라이브러리는 한국어 NLP의 새로운 지평을 열었다.	이 라이브러리는 한국어 NLP 작업을 간단하게 만들었다.
Docker는 배포의 이정표가 된 도구다.	Docker는 배포를 단순화한 도구다.

11.3. 홍보성 어휘 (Promotional Language)

기술 문서·위키·뉴스에서 특히 문제가 되는 광고성 표현. 구체 사실로 대체하거나 삭제한다.

"업계를 선도하는", "최고 수준의", "타의 추종을 불허하는"
"강력한 성능", "압도적인 속도", "탁월한 품질"
"차세대", "첨단의", "최신의" (구체 버전/연도로 대체)
"획기적으로", "파격적으로", "대폭"

Before	After
업계를 선도하는 강력한 성능의 모델이다.	MMLU에서 86.4%를 기록한 모델이다.
차세대 데이터베이스 기술이다.	2024년에 나온 데이터베이스다.

11.4. 피상적 "-하면서" 분석 (Superficial -ing Analysis)

"~하면서", "~함으로써", "~을/를 통해"로 원인-결과 관계를 얼버무리는 구문. 대부분 실제 메커니즘이 없다. 삭제하거나 실제 메커니즘으로 바꾼다.

Before	After
이 모델은 어텐션을 활용하면서 문맥을 더 잘 이해한다.	이 모델은 어텐션으로 앞뒤 단어를 같이 본다.
캐시를 적용함으로써 성능이 향상된다.	캐시를 넣으면 두 번째 요청부터 DB를 안 친다.
API를 제공함으로써 개발자 편의성을 높였다.	API가 있어서 외부에서 호출할 수 있다.

11.5. 모호한 출처 (Vague Attributions)

실제 인용 없는 "일부 전문가들", "업계 관계자"류 표현. 근거가 있으면 구체적으로 쓰고, 없으면 삭제한다.

Before	After
업계 전문가들은 ~라고 전망한다.	(구체 출처 없으면 삭제, 있으면 "A사 CTO 아무개는 ~라고 말했다")
연구에 따르면 ~하다고 알려져 있다.	(논문 이름 없으면 삭제)
많은 개발자들이 ~를 선호한다.	(Stack Overflow 설문 등 실제 출처 명시)

11.6. 부정 평행 (Negative Parallelisms)

"A이자 B", "A일 뿐만 아니라 B이기도 한" 형태로 같은 뜻을 두 번 쓰는 병렬. 한쪽을 지운다.

Before	After
이 방법은 효율적일 뿐만 아니라 생산적이기도 하다.	이 방법은 효율적이다.
단순하지 않고 복잡하지도 않다.	적당한 복잡도다. (혹은 그냥 삭제)
쉽고 간단하다.	쉽다.

11.7. 연결어 과잉 (Excessive Conjunctive Phrases)

"게다가", "나아가", "더욱이", "한편", "결과적으로", "요컨대"가 문장마다 붙는다.
한 문단에 세 번 넘게 나오면 절반은 지운다. 한국어는 연결어 없이도 흐름이 이어진다.

Before	After
게다가 성능도 좋다. 나아가 메모리도 적게 쓴다. 더욱이 배포도 쉽다.	성능이 좋고, 메모리도 적게 쓰고, 배포도 쉽다.

11.8. AI 상투어휘 사전 (빠른 찾기/지우기)

AI 특유의 "그럴듯한" 단어들. 원문에서 보이면 바로 지우거나 구체 표현으로 바꾼다. 2.1~2.3과 중복되는 항목은 있으나, 일괄 검색용으로 묶어 둔다.

명사: "여정", "모험", "영역", "지평", "생태계", "패러다임", "랜드스케이프", "중추", "기반", "토대"
형용사/부사: "섬세한", "정교한", "우아한", "지능적인", "유기적으로", "총체적으로", "전방위적으로"
동사: "탐색하다", "탐험하다", "조망하다", "엿보다", "풀어내다", "녹여내다"
구: "~의 세계", "~의 중심에서", "~를 향한 발걸음", "~에 있어"

11.9. 의미 없는 메타-언급 (Self-referential Filler)

글 자체를 언급하는 문장은 대부분 삭제해도 본문이 자립한다.

"이 글에서는 ~다룬다/ 살펴본다/ 알아본다"
"앞서 언급한 바와 같이", "위에서 말했듯이"
"다음 절에서는 ~를 설명한다"
"이 섹션에서 중요한 것은"

정말 필요하면 한 번만 남긴다. 보통은 모두 지워도 된다.

11.10. 수치 부재 + 비교 남발

구체 수치 없이 "더 빠르다", "훨씬 좋다", "상당히 개선되었다"로 끝내는 문장은 의심한다. 원문에 수치가 있으면 반드시 끌어 올리고, 없으면 비교 주장을 빼거나 "어느 정도"로 약화한다.

Before	After
기존 방식보다 훨씬 빠르다. (원문에 근거 있음)	기존 방식보다 2.3배 빠르다.
상당히 개선되었다. (원문에 수치 없음)	개선되었다. (혹은 관련 문장 삭제)

중요: 슬롭 제거 과정에서 없는 수치를 만들어 넣지 않는다. 원문에 없는 사실은 교정에서도 생기지 않는다. 의미 보존 원칙.

전체 교정 예시

예시 1: 기술 문서 (하다체)

Before (AI 말투)

본 문서에서는 최신 자연어 처리 기술의 다양한 발전 동향에 대해 살펴보겠습니다.

최근 대규모 언어 모델이 다양한 분야에서 혁신적인 성과를 보여주고 있습니다. 이러한 모델들은 텍스트 생성, 번역, 요약 등 폭넓은 태스크를 수행하는 데 있어 핵심적인 역할을 담당하고 있으며, 이를 통해 사용자 경험을 크게 향상시킬 수 있게 되었습니다.

주목할 만한 점은 이 기술이 기존 방식 대비 우수한 성능을 보여준다는 것입니다. 다양한 벤치마크에서 기존 모델 대비 성능이 향상되었으며, 특히 속도·정확도·안정성 측면에서 큰 개선이 이루어졌습니다.

결론적으로, 이 기술은 다양한 분야에 의미 있는 기여를 했다고 볼 수 있으며, 향후 더욱 발전할 것으로 기대됩니다.

After (자연스러운 한국어)

요즘 대규모 언어 모델이 자연어 처리 전반을 바꾸고 있다.

글을 쓰고, 번역하고, 요약하는 일에 이 모델들이 들어가면서 사람이 직접 하던 작업이 줄었다. 예전에는 태스크마다 모델을 따로 만들었는데, 이제는 하나로 여러 가지를 처리한다.

GPT-4 기준으로 MMLU 벤치마크에서 86.4%를 찍었다. 기존 최고 기록보다 5% 넘게 올랐고, 추론 속도도 2배 가까이 빨라졌다.

아직 환각 문제가 남아 있긴 하다. 하지만 쓸 만한 수준까지 온 건 맞다.

교정 내역

"살펴보겠습니다" 도입 삭제
"다양한", "혁신적인", "핵심적인 역할을 담당" 등 빈 수식어 제거
"향상되었으며" 피동 표현을 "올랐다" 능동으로 전환
"속도·정확도·안정성" 가운뎃점을 구체 수치로 교체
"결론적으로 ~기여를 했다고 볼 수 있으며" 상투적 마무리 삭제
"주목할 만한 점은 ~것입니다" AI 상투어 삭제
볼드 제거, 말투 하다체로 통일
문장 길이 변화 추가 ("아직 환각 문제가 남아 있긴 하다. 하지만 쓸 만한 수준까지 온 건 맞다.")

예시 2: 블로그 포스트 (해요체)

Before (AI 말투)

Docker 입문: 컨테이너의 세계로의 여정

안녕하세요! 오늘은 Docker에 대해 자세히 살펴보겠습니다. Docker는 혁신적인 컨테이너 기술로, 개발자들에게 다양한 이점을 제공합니다.

Docker를 활용하면 다음과 같은 장점이 있습니다:

환경 일관성: 개발 환경과 운영 환경의 차이를 해소할 수 있습니다

빠른 배포: 애플리케이션을 신속하게 배포할 수 있습니다

리소스 효율성: 가상머신 대비 효율적인 리소스 활용이 가능합니다

흥미로운 점은 Docker가 기존의 가상화 기술이 직면하고 있던 다양한 문제점들을 해결했다는 것입니다. 이를 통해 개발자들은 보다 효율적인 워크플로우를 구현할 수 있게 되었으며, 궁극적으로 생산성 향상에 크게 기여하고 있습니다.

이 글이 Docker를 이해하시는 데 도움이 되셨기를 바랍니다. 궁금한 점이 있으시면 댓글로 남겨주세요!

After (자연스러운 한국어)

Docker 입문

Docker는 앱을 컨테이너에 넣어서 돌리는 도구예요. VM보다 가볍고, 어디서든 똑같이 동작해요.

왜 쓰냐면요. 개발할 때 "내 컴퓨터에서는 되는데?"라는 말, 해 보셨죠? Docker를 쓰면 개발 환경이랑 서버 환경이 같으니까 이런 일이 없어요. 배포도 이미지 하나 올리면 끝이고요.

VM은 OS 전체를 올리지만, 컨테이너는 필요한 것만 담아요. 같은 서버에서 컨테이너를 10개 돌릴 수 있어도, VM은 3개도 버거울 때가 많아요.

설치는 brew install docker로 시작하면 돼요.

교정 내역

"안녕하세요! 오늘은 ~살펴보겠습니다" 챗봇 도입 삭제
"혁신적인", "다양한" 빈 수식어 제거
"활용하면" → "쓰면" 영어 직역 교체
3개짜리 불릿 리스트를 문장으로 풀어 씀
"흥미로운 점은 ~것입니다" AI 상투어 삭제
"이를 통해 ~기여하고 있습니다" 상투적 연결 삭제
"도움이 되셨기를 바랍니다 / 댓글로 남겨주세요" 챗봇 마무리 삭제
"직면하고 있던" 피동/번역체를 구어로 전환
해요체로 통일, 구체적 예시 추가 (VM vs 컨테이너 비교)

예시 3: 개발자 문서 / README (하다체)

Before (AI 말투)

개요

본 라이브러리는 다양한 데이터베이스 작업을 수행하기 위한 포괄적인 ORM 솔루션을 제공합니다. 이를 기반으로 개발자들은 복잡한 SQL 쿼리 작성 없이도 효율적인 데이터베이스 조작을 달성할 수 있습니다.

주요 기능

본 라이브러리의 주요 기능은 다음과 같습니다:

자동 마이그레이션: 스키마 변경을 자동으로 감지하여 마이그레이션을 수행합니다

타입 안전성: TypeScript와의 완벽한 통합을 제공하여 런타임 에러를 최소화합니다

쿼리 빌더: 직관적인 API를 통해 복잡한 쿼리를 구현할 수 있습니다

설치 방법

설치는 다음과 같은 방법으로 수행할 수 있습니다:
npm install myorm
설치가 완료되면, 다음 단계에서는 설정 파일을 생성하는 과정을 진행하겠습니다.

After (자연스러운 한국어)

개요

SQL 안 쓰고 데이터베이스를 다루는 ORM이다.

주요 기능

스키마가 바뀌면 마이그레이션을 자동으로 만들어 준다

TypeScript 타입을 그대로 쓴다. 런타임 에러가 줄어든다

복잡한 쿼리도 메서드 체이닝으로 짠다

설치
npm install myorm
설치 후 설정 파일을 만든다.

교정 내역

"본 라이브러리는 ~포괄적인 ORM 솔루션을 제공합니다" → 한 줄로 축약
"수행하기 위한", "달성할 수 있습니다" 번역체 동사 정리
"주요 기능은 다음과 같습니다" 뻔한 안내 삭제
"완벽한 통합을 제공하여" → "그대로 쓴다"
"직관적인 API를 통해 ~구현할 수 있습니다" → "메서드 체이닝으로 짠다"
"설치는 다음과 같은 방법으로 수행할 수 있습니다" → 코드 블록만 남김
"다음 단계에서는 ~과정을 진행하겠습니다" 안내체 삭제
볼드 과다 제거, 하다체 통일, 불릿은 간결하게 유지

예시 4: 비즈니스 이메일 (해요체)

Before (AI 말투)

안녕하세요, 김 팀장님.

금번 프로젝트 진행 상황과 관련하여 말씀드리고자 합니다. 현재 백엔드 API 개발이 완료되었으며, 프론트엔드 작업이 진행 중에 있습니다. 이와 관련하여 몇 가지 논의가 필요한 사항이 존재합니다.

첫째, 인증 시스템 구현에 있어 OAuth 2.0과 JWT 중 어떤 방식을 채택할지에 대한 결정이 요구됩니다. 둘째, 데이터베이스 스키마 변경이 필요한 상황이 발생하였으며, 이로 인해 일정이 2일 정도 지연될 것으로 예상됩니다.

상기 사항들에 대해 내일 오전 중으로 미팅을 진행하면 좋을 것 같습니다. 검토 부탁드리겠습니다.

감사합니다.

After (자연스러운 한국어)

김 팀장님, 안녕하세요.

프로젝트 진행 상황 공유드려요. 백엔드 API는 다 만들었고, 프론트엔드는 작업 중이에요.

두 가지 정해야 할 게 있어요.

인증을 OAuth 2.0으로 갈지 JWT로 갈지 아직 못 정했어요.

DB 스키마를 바꿔야 해서 일정이 이틀쯤 밀릴 것 같아요.

내일 오전에 잠깐 미팅하면 좋겠어요.

감사합니다.

교정 내역

"금번", "상기 사항들" 공문서체 → 일상 비즈니스 표현
"~와 관련하여 말씀드리고자 합니다" 장황한 도입 축약
"존재합니다" → 삭제 (있다고 안 해도 뒤에 나옴)
"채택할지에 대한 결정이 요구됩니다" 피동 → "못 정했어요"
"발생하였으며, 이로 인해" 번역체 연결 → "바꿔야 해서"
"진행하면 좋을 것 같습니다" → "하면 좋겠어요"
"검토 부탁드리겠습니다" 불필요한 문장 삭제 (미팅 요청만으로 충분)
번호 리스트로 핵심만 정리, 해요체 통일

예시 5: 뉴스 기사 (하다체)

Before (AI 말투)

국내 반도체 산업, 혁신적 도약을 이루다

국내 반도체 산업이 글로벌 시장에서 다양한 분야에 걸쳐 혁신적인 성과를 달성하고 있다. 삼성전자와 SK하이닉스로 대표되는 국내 기업들은 차세대 메모리 기술 개발에 있어 선도적인 역할을 수행하고 있으며, 이를 통해 글로벌 경쟁력을 한층 강화시키고 있다.

특히 주목할 만한 점은 HBM(High Bandwidth Memory) 분야에서의 기술적 우위이다. 양사는 HBM3E 및 차세대 HBM4 개발을 본격화하고 있으며, 이는 AI 반도체 시장의 폭발적 성장과 맞물려 핵심적인 성장 동력으로 작용하고 있다.

업계 전문가들은 향후 국내 반도체 산업이 AI·자율주행·데이터센터 등 다양한 첨단 분야에서 보다 중요한 역할을 담당하게 될 것이라고 전망하고 있으며, 이를 위한 지속적인 투자와 인력 양성이 요구된다고 강조하였다.

After (자연스러운 한국어)

삼성·SK, HBM으로 AI 반도체 시장 잡는다

삼성전자와 SK하이닉스가 고대역폭 메모리(HBM) 시장에서 앞서 나가고 있다. 두 회사 모두 HBM3E 양산에 들어갔고, HBM4 개발도 시작했다.

AI 서버에는 HBM이 필수다. 엔비디아 H100 GPU 하나에 HBM이 80GB 들어간다. AI 수요가 커지면서 HBM 매출이 1년 만에 3배 뛰었다.

반도체 업계에서는 AI, 자율주행, 데이터센터용 수요가 계속 늘어날 것으로 본다. 다만 인력이 부족하다는 목소리도 나온다.

교정 내역

제목: "혁신적 도약을 이루다" 빈 수식 → 구체적 내용("HBM으로 AI 반도체 시장 잡는다")
"다양한 분야에 걸쳐 혁신적인 성과를 달성" 빈 수식어 전체 삭제
"선도적인 역할을 수행하고 있으며" → "앞서 나가고 있다"
"이를 통해 글로벌 경쟁력을 한층 강화시키고 있다" 상투 문장 삭제
"주목할 만한 점은 ~우위이다" AI 상투어 삭제, 바로 사실 서술
"폭발적 성장과 맞물려 핵심적인 성장 동력으로 작용" → 구체 수치로 대체
"AI·자율주행·데이터센터" 가운뎃점 → 쉼표
"요구된다고 강조하였다" 피동 + 인용 중첩 → "목소리도 나온다"
하다체 통일, 구체 수치 삽입 (H100 GPU, 80GB, 3배)

처리 방식

공통 선행 단계 (파일/텍스트 상관없이 반드시 먼저)

"문체 인터뷰" 섹션의 세 질문(문체 기조, 종결 어미, 교정 강도)을 AskUserQuestion으로 받는다.
사용자 응답을 교정 패스의 기본값으로 고정한다. 이후 교정에서는 이 기본값을 따른다.
사용자가 응답을 건너뛰거나 "알아서 해 달라"고 답하면 문어체 / 하다체 / 중 을 기본값으로 쓰되, 최종 출력 상단에 사용된 기본값을 한 줄로 명시한다.

파일이 주어진 경우

공통 선행 단계로 문체를 확정한다.
Read로 파일을 읽는다.
위 규칙(섹션 1~11)에 따라 전문을 교정한다.
Edit으로 원본 파일을 수정하거나, Write로 새 파일에 저장한다.

텍스트가 직접 주어진 경우

공통 선행 단계로 문체를 확정한다.
위 규칙(섹션 1~11)에 따라 전문을 교정한다.
교정된 텍스트를 출력한다.
주요 교정 내역을 간단히 정리한다(어떤 규칙 번호가 적용됐는지).

12. 최종 점검 (교정 완료 전 반드시 확인)

em dash, en dash, 가운뎃점이 하나도 없는가?
AI 상투어("살펴보겠습니다", "결론적으로" 등)가 하나도 없는가?
이중 피동("보여지다", "만들어지게 되다")이 없는가?
빈 수식어("다양한", "혁신적인") 없이 구체적으로 썼는가?
문체 인터뷰에서 고른 말투(문어체 vs 구어체, 하다체/합쇼체/해요체/해체)가 문서 전체에서 일관되게 적용됐는가?
문장 길이가 자연스럽게 섞여 있는가?
볼드가 과하지 않은가?
소리 내어 읽었을 때 어색한 문장이 없는가?
원뜻이 보존됐는가? 구체 수치·고유명사·인과 관계가 원문과 일치하는가? (ai-slop-cleaner 원칙 — 의미 변경 금지)
삭제 패스 우선 원칙을 지켰는가? 새 비유·새 예시를 임의로 추가하지 않았는가?
규칙의 삼(11.1), 공허한 상징(11.2), 홍보성 어휘(11.3), 피상적 "-하면서"(11.4), 모호한 출처(11.5) 점검이 끝났는가?
원문에 없던 수치·인용·출처를 만들어 넣지 않았는가?

name	korean-naturalizer
version	1.0.0
description	한국어 텍스트에서 AI가 쓴 흔적, 번역체, 부자연스러운 표현을 제거하고 자연스러운 한국어로 다시 써 주는 스킬. 말투 통일, 문장부호 교정, 피동 표현 정리, 영어 직역체 제거를 수행한다.
allowed-tools	["Read","Write","Edit","Grep","Glob","AskUserQuestion"]

한국어 자연화: AI 말투 제거 및 문체 교정

입력받은 한국어 텍스트에서 AI가 쓴 흔적을 모두 제거하고, 사람이 쓴 것처럼 자연스러운 한국어로 다시 쓴다.

적용 범위 (Scope)

이 스킬은 한국어 산문(문서, 블로그, 이메일, README, 기사, 주석 등) 전용이다. 목적과 대상이 다른 슬롭 제거 스킬은 각자의 영역에서 쓴다.

상황	사용 스킬
한국어 산문의 AI 말투 제거	이 스킬 (korean-naturalizer)
코드 자체의 AI 슬롭 (중복, 죽은 코드, 껍데기 추상화 등)	`oh-my-claudecode:ai-slop-cleaner`
영어 산문의 AI 말투 제거	`humanizer`
한국어 산문 + 내부 코드 슬롭이 섞인 저장소	`ai-slop-cleaner`로 코드 정리 → 이 스킬로 문서/주석 정리 (두 패스로 분리)

작업 원칙 (ai-slop-cleaner에서 차용)

텍스트 교정도 코드 정리와 같은 규율을 따른다. 다음은 oh-my-claudecode:ai-slop-cleaner의 집행 태세를 산문 작업에 맞춰 옮긴 것이다.

원뜻 보존 (behavior-preservation): 사용자가 명시적으로 의미 변경을 요청하지 않는 한, 문장의 사실적·주장적 내용은 바꾸지 않는다. 바꾸는 것은 말투와 표현뿐이다. 구체 수치·고유명사·인과 관계·문장의 주어/목적어/동사 역할을 임의로 교체하지 않는다.
삭제 우선 (deletion-first): 새 표현을 끼워 넣기 전에 먼저 지워도 되는 것부터 지운다. 빈 수식어, 뻔한 도입/마무리, 중복 강조, 불필요한 영어 병기가 최우선 삭제 대상이다.
범위를 좁힌다 (scoped): 사용자가 파일 목록이나 문단 범위를 지정했으면 그 밖으로 나가지 않는다. 원문 어딘가가 눈에 띈다고 해서 무단으로 범위를 넓히지 않는다.
한 번에 한 가지 스멜만 (one smell per pass): 한 번에 뒤섞어 고치지 않는다. 먼저 삭제 패스, 다음 피동 정리 패스, 다음 말투 통일 패스 식으로 순차로 처리하면 검증이 쉽다.
의존성 추가 금지 (no new scope): 새 예시, 새 주장, 새 섹션을 AI 슬롭 제거를 핑계로 슬쩍 끼워 넣지 않는다. 슬롭 제거는 빼는 작업이지 채우는 작업이 아니다.
증거 중심 보고 (evidence-dense report): 교정 후에는 무엇을 왜 지웠는지, 어떤 규칙 번호에 해당하는지 간결하게 적는다. 추측이 아니라 근거로 말한다.
리뷰어 분리 (writer/reviewer separation): 직접 교정한 내용을 같은 패스에서 스스로 "좋다"고 승인하지 않는다. 큰 분량(1000자 이상)이나 공개 발행용 글은 교정 패스와 점검 패스를 나눈다.

작업 순서

문체 선택을 먼저 묻는다 (필수, 건너뛰지 않는다). 원문의 말투가 한 가지로 확실해 보여도, 사용자가 바꾸고 싶을 수 있으므로 교정 시작 전에 반드시 AskUserQuestion으로 문체를 받는다. 아래 "문체 인터뷰" 절 참고.
범위를 확인한다. 파일 목록·문단 범위가 지정됐으면 그 밖으로 나가지 않는다.
입력 텍스트를 처음부터 끝까지 읽고, 교정 계획(어떤 규칙을 어느 문단에 적용할지)을 먼저 메모한다. 계획 없이 바로 수정하지 않는다.
삭제 패스부터 돌린다: 뻔한 도입/마무리, 빈 수식어, 불필요한 영어 병기, 과한 볼드·불릿을 먼저 지운다. (원뜻 유지 확인)
문법·피동·번역체 패스: 이중 피동, "-되다" 남용, "have" 직역, 관계절 과다를 손본다.
AI 슬롭 패턴 패스(섹션 11): 규칙의 삼, 공허한 상징, 홍보성 어휘, 부정 평행, 피상 분석, 모호한 출처, 연결어 과잉, AI 상투어휘를 제거한다.
말투·리듬 패스: 1단계에서 고른 문체로 전체를 맞추고, 문장 길이와 연결어를 다듬는다.
최종 점검 패스 (섹션 12): 체크리스트를 돌리고, 원문 대비 사실 내용이 왜곡되지 않았는지 확인한다.
교정된 텍스트와 함께 교정 내역(어떤 규칙 번호가 어디에 적용됐는지)을 간결히 출력한다.

문체 인터뷰 (교정 시작 전 필수)

질문 1 — 문체 기조 (구어체 vs 문어체)

선택지	설명	예시
문어체 (격식, 글말)	문서, 논문, 공지, 기사 등	"이 방법으로 성능이 올랐다."
구어체 (캐주얼, 입말)	블로그, 에세이, 커뮤니티 글, 대화	"이렇게 하니까 빨라지더라고요."
반구어체 (친근한 문어)	튜토리얼, 사내 문서, 개발 블로그	"이 방법을 쓰면 빨라져요."
원문 판단에 맡김	원문 톤을 그대로 유지	—

질문 2 — 종결 어미 (설명문 vs 합쇼체 vs 해요체 vs 해체)

선택지	어미	쓰임새	예시
하다체 (~이다/~한다)	설명문, 논문체	기술 문서, 위키, 논문, 뉴스 기사	"이 방법을 쓴다."
합쇼체 (~합니다/~입니다)	격식 경어	공식 문서, 보고서, 프레젠테이션, 강연 원고	"이 방법을 씁니다."
해요체 (~해요/~이에요)	친근 경어	블로그, 안내문, 튜토리얼	"이 방법을 써요."
해체 (~해/~야)	반말	캐주얼 에세이, 친구에게 보내는 글	"이 방법 써."
원문 판단에 맡김	—	원문 그대로 유지	—

질문 3 — 교정 강도

선택지	내용
약 (문법·오탈자 위주)	맞춤법, 띄어쓰기, 이중 피동만 손댄다. 말투는 유지
중 (AI 흔적 제거)	빈 수식어·AI 상투어·번역체를 교정. 구조는 유지
강 (전면 자연화)	문장 구조·리듬·섹션 길이까지 재구성. 원뜻만 유지

1. 문장부호 교정

한국어에서 쓰이지 않는 문장부호를 모두 바꾼다.

잘못된 부호	교정 방법
em dash (—)	쉼표, 괄호, 마침표로 대체
en dash (–)	쉼표, 물결표(~), "부터/까지"로 대체
가운뎃점 (·)	쉼표로 구분하거나 "및", "과/와"로 연결
curly quotes (" ")	쌍따옴표("")로 교체
curly single quotes (' ')	작은따옴표('')로 교체
말줄임표 (...) 남용	꼭 필요한 곳만 남기고 삭제

교정 예시:

Before	After
이 기술은 다양한 분야—의료, 금융, 교육—에서 쓰인다.	이 기술은 의료, 금융, 교육 등 여러 분야에서 쓰인다.
2020–2024년 사이에	2020년부터 2024년 사이에
속도·정확도·안정성을 모두 갖췄다.	속도, 정확도, 안정성을 모두 갖췄다.
"혁신적인 접근법"이라고 평가했다.	"혁신적인 접근법"이라고 평가했다.

2. AI 특유 어휘 제거

아래 단어와 표현이 보이면 삭제하거나 구체적인 말로 바꾼다.

2.1. 빈 수식어 (삭제 또는 구체화)

"다양한", "다양하게", "폭넓은", "폭넓게"
"핵심적인", "근본적인", "본질적인"
"혁신적인", "획기적인", "선도적인", "선구적인"
"심층적으로", "포괄적으로", "체계적으로", "종합적으로"
"주목할 만한", "흥미로운 점은", "놀라운 것은"
"중요한", "핵심적인" (뒤에 "역할을 한다"가 붙을 때)
"보다 효과적인", "보다 효율적인" ("더"로 줄이거나 구체 수치로)

Before	After
다양한 분야에서 중요한 역할을 한다.	검색 엔진, 추천 시스템, 자동 번역에 쓰인다.
혁신적인 접근법을 제안한다.	기존보다 20% 빠른 방법이다.
보다 효과적인 결과를 보여준다.	정확도가 3% 올랐다.

2.2. AI 상투어 (삭제)

"살펴보겠습니다", "알아보겠습니다", "자세히 살펴보면"
"~라고 할 수 있다", "~라고 볼 수 있다"
"이를 통해", "이를 기반으로", "이를 바탕으로"
"궁극적으로", "결론적으로", "종합적으로"
"~에 기여한다", "~를 가능하게 한다", "~를 제공한다"
"~하는 데 있어", "~의 관점에서", "~라는 측면에서"
"~와(과) 관련하여", "~에 대해 논의하면"

Before	After
이제 성능에 대해 살펴보겠습니다.	(삭제하고 바로 성능 이야기로)
이를 통해 성능을 향상시킬 수 있다.	그래서 빨라진다.
결론적으로 의미 있는 기여를 했다고 볼 수 있다.	(삭제. 이미 본문에서 다 말했다.)

2.3. 영어 직역 어휘 (한국어다운 표현으로)

영어 직역	자연스러운 한국어
활용하다 (utilize)	쓰다, 사용하다
수행하다 (perform)	하다, 처리하다
제공하다 (provide)	주다, 내놓다
도출하다 (derive)	끌어내다, 얻다
탐구하다 (explore)	찾아보다, 알아보다
논의하다 (discuss)	이야기하다, 따지다
시사하다 (imply/suggest)	보여주다, 뜻하다
기여하다 (contribute)	도움이 되다, 보태다
촉진하다 (promote/facilitate)	돕다, 빠르게 하다
구현하다 (implement)	만들다, 짜다 (문맥에 따라)
직면하다 (face)	부딪히다, 겪다
존재하다 (exist)	있다
동반하다 (accompany)	따르다, 함께 오다
기인하다 (be caused by)	때문이다, 탓이다

2.4. 비격식 강조어와 주관적 형용사

Before	After
이 규칙이 진짜 강제는 아니다	이 규칙이 완전한 강제는 아니다
백업이 진짜 필요한 경우	백업이 꼭 필요한 경우
그냥 기본값으로 두는 게 안전하다	기본값으로 두는 편이 안전하다
진짜로 지우고 싶다면	실제로 지우고 싶다면
되게 빠르다	매우 빠르다 / 아주 빠르다

또한 코드, 알고리즘, 데이터 구조처럼 감정 없는 대상에 주관적 형용사를 쓰지 않는다.

Before (주관적)	After (중립적)
예쁜 코드	깔끔한 코드, 읽기 좋은 코드
흉측한 이름	알아보기 어려운 이름
아름다운 알고리즘	우아한 알고리즘, 단순한 알고리즘
끔찍한 API	쓰기 어려운 API
멋진 최적화	효과적인 최적화

2.5. 부사 중복

Before	After
아주 작은 파일을 아주 많이 만들면	작은 파일을 수없이 만들면
매우 중요하고 매우 어려운 문제	까다로운 핵심 문제
정말 정말 빠르다	매우 빠르다
너무 너무 느리다	참을 수 없이 느리다

2.6. 에둘러 말하기

AI는 부정적 사실을 직접 말하지 않고 에둘러 쓴다. 사실을 그대로 쓴다.

AI 말투	자연스러운 표현
~을/를 잃었습니다	0점입니다 / 틀렸습니다
감점이 있었습니다	틀렸습니다
오류가 있었습니다	틀렸습니다
~를 놓쳤습니다	~를 틀렸습니다
방향은 잡았으나	방향은 맞았지만
눈에 띄는 성과입니다	(구체적 사실로 대체)
돋보입니다 / 인상적입니다	(구체적 사실로 대체)

3. 부자연스러운 피동 표현 교정

한국어는 능동문이 자연스럽다. 영어식 수동태를 능동으로 바꾼다.

3.1. 이중 피동 (틀린 문법)

Before	After
만들어지게 되다	만들어지다 / 만들다
읽혀지다	읽히다
보여지다	보이다
잊혀지다	잊히다
쓰여지다	쓰이다
지어지다	짓다 (능동으로)

3.2. 불필요한 피동 (능동으로 전환)

Before	After
이 방법이 사용된다.	이 방법을 쓴다.
문제가 해결되었다.	문제를 해결했다. / 문제가 풀렸다.
성능이 향상되었다.	성능이 올랐다. / 성능을 올렸다.
결과가 도출되었다.	결과를 얻었다. / 결과가 나왔다.
데이터가 수집되었다.	데이터를 모았다.
실험이 수행되었다.	실험했다. / 실험을 돌렸다.
모델이 학습되었다.	모델을 학습시켰다. / 모델이 학습했다.

3.3. "-되다" 남용

"-하다" 동사를 "-되다"로 바꿔 쓰는 습관을 교정한다.

Before	After
추정된다	추정할 수 있다 / ~로 보인다
판단된다	~로 보인다 / ~인 듯하다
요구된다	필요하다
기대된다	기대할 수 있다 / ~일 것이다
우려된다	걱정스럽다 / 걱정이 된다

3.4. "have" 직역 ("~를 갖다 / 갖고 있다")

영어 "have"를 그대로 "갖다", "갖고 있다"로 옮기면 번역체가 된다. 한국어는 "있다"를 쓴다.

Before	After
이 객체는 세 개의 속성을 갖는다	이 객체에는 속성이 세 개 있다
이 표는 두 개의 열을 갖고 있다	이 표에는 열이 두 개 있다
함수가 반환 값을 갖지 않는다	함수에 반환 값이 없다
배열이 n개의 원소를 가진다	배열에는 원소가 n개 있다
클래스가 생성자를 갖고 있다	클래스에 생성자가 있다

예외: 추상적·비유적 의미일 때는 "갖다"가 자연스러울 수 있다. ("관심을 갖다", "의미를 갖다" 등)

4. 번역체 문장 구조 교정

4.1. 관계절 과다 (영어 관계대명사 직역)

Before	After
우리가 사용하는 방법은 기존에 제안된 방법을 개선한 것으로서 성능을 높이는 데 기여하는 접근법이다.	우리는 기존 방법을 개선해서 성능을 올렸다.
저자가 제안한 모델은 기존 모델이 가지고 있던 한계를 극복한 모델이다.	이 모델은 기존 한계를 넘었다.

4.2. 명사 과다 (명사구 나열)

Before	After
성능 향상의 달성을 위한 방법론의 적용	성능을 올리려고 이 방법을 썼다
데이터 처리 과정의 효율성 개선	데이터 처리를 더 빠르게 했다
사용자 경험의 극대화를 위한 인터페이스 설계	쓰기 편한 화면을 만들었다

4.3. 주어 생략 과다 / 주어 불일치

한국어는 주어를 적절히 생략하지만, AI는 주어 없이 문장을 계속 이어 누가 하는 건지 헷갈리게 한다. 필요한 곳에 주어를 넣어 준다.

4.4. 한 문장에 절이 너무 많음

Before	After
A는 B이며, C를 통해 D를 E하고, F와 G를 H함으로써 I를 달성한다.	A는 B다. C로 D를 E한다. 그러면 F와 G가 H되면서 결국 I가 된다.

5. 강조 표현 정리

5.1. 볼드 남용

AI는 핵심 단어마다 볼드(bold)를 건다. 문단 하나에 볼드가 3개 이상이면 정리한다.

Before	After
성능이 크게 향상되어 사용자 경험이 개선되었습니다.	성능이 크게 올라서 쓰기 편해졌다.

5.2. 불릿 리스트 남용

AI는 뭐든 불릿으로 나열한다. 3개 이하이거나 한 줄짜리면 문장으로 풀어 쓴다.

Before	After
장점은 다음과 같습니다: - 빠르다 - 정확하다 - 쉽다	빠르고 정확하면서도 쓰기 쉽다.

5.3. 불필요한 영어 병기

맥락상 뻔한 영어는 빼고 한국어만 쓴다.

Before	After
초안 (Draft) 단계에서	초안 단계에서
성능 (Performance)을 비교했다	성능을 비교했다
확장성 (Scalability)이 좋다	확장성이 좋다

전문 용어가 처음 나올 때만 한 번 병기하고, 이후로는 한국어만 쓴다.

6. 구조적 AI 패턴 제거

6.1. 뻔한 도입/마무리 삭제

삭제 대상	이유
"이번 글에서는 ~에 대해 살펴보겠습니다."	읽으면 안다. 안내할 필요 없다.
"지금까지 ~에 대해 알아보았습니다."	읽었으니 안다. 요약할 필요 없다.
"이 글이 도움이 되셨기를 바랍니다."	챗봇 말투.
"궁금한 점이 있으시면 댓글로 남겨주세요."	챗봇 말투.
"그럼 시작해 보겠습니다!"	그냥 시작하면 된다.

6.2. 모든 섹션이 같은 구조

6.3. 3의 법칙 (Rule of Three)

AI는 모든 나열을 세 개로 맞춘다. 두 개면 두 개, 네 개면 네 개로 있는 그대로 쓴다.

Before	After
속도, 정확도, 안정성을 갖췄다.	속도랑 정확도가 좋다. (안정성이 실제로 언급 안 됐다면)

7. 말투 통일

문서 전체에서 말투를 하나로 맞춘다.

7.1. 말투 선택 기준

입력 텍스트의 원래 말투를 파악해서 그에 맞춘다. 판단이 어려우면 사용자에게 묻는다.

말투	쓰임새	예시
해요체 (~합니다/~입니다)	블로그, 안내문, 설명글	"이 방법을 쓰면 빨라집니다."
하다체 (~이다/~한다)	기술 문서, 위키, 논문	"이 방법을 쓰면 빨라진다."
해체 (~해/~야)	캐주얼 글, 대화체	"이 방법 쓰면 빨라져."

7.2. 말투 섞임 교정

한 문서 안에서 말투가 왔다 갔다 하면 하나로 맞춘다.

Before	After (하다체로 통일)
이 방법은 빠릅니다. 하지만 정확도가 낮다. 그래서 주의해야 해요.	이 방법은 빠르다. 하지만 정확도가 낮다. 그래서 주의해야 한다.

8. 문장 리듬

8.1. 문장 길이 변화

AI는 모든 문장을 비슷한 길이로 쓴다. 긴 문장 뒤에 짧은 문장을 넣어 리듬을 만든다.

Before	After
이 모델은 기존 방식보다 빠르다. 이 모델은 정확도도 높다. 이 모델은 메모리도 적게 쓴다.	기존 방식보다 빠르고 정확도도 높다. 메모리도 적게 먹는다. 셋 다 잡았다.

8.2. 연결어 반복 방지

"또한", "그리고", "더불어" 같은 연결어가 연달아 나오면 다른 방식으로 잇는다.

Before	After
또한 A도 좋다. 또한 B도 개선되었다. 또한 C 기능도 추가되었다.	A도 좋다. B도 나아졌고, C 기능까지 붙었다.

9. 자연스러운 한국어 표현

교정할 때 아래 표현을 적극적으로 쓴다.

9.1. 체언 종결

"~하는 구조다.", "~인 셈이다.", "~수준이다."

9.2. 자연스러운 종결어미

"~인데", "~더니", "~길래", "~다 보니", "~거든"
"~나 다름없다", "~일 수밖에 없다", "~라고 보면 된다"
"~치고는", "~답게"

9.3. 구어체 삽입 (문맥에 맞을 때)

"쉽게 말해", "한마디로", "거칠게 말하면"
"솔직히", "사실", "어쨌든"
"뭐 그렇다.", "그냥 그런 거다."

10. 한국어 문법 교정

AI는 한국어 문법 규칙을 자주 틀린다. 아래 항목을 반드시 점검한다.

10.1. "이다" 활용 오류

받침 있는 명사 뒤에는 "이다"를 써야 한다. "다"만 붙이면 틀린다.

Before (틀림)	After (맞음)
예시다	예시이다 / 예시다 (구어체 축약 허용 시)
이것은 결과다	이것은 결과이다 / 이것은 결과다 (문맥에 따라)
좋은 방법이 아닐 수 있다	(맞음 - "이" 포함)

규칙: 받침 있는 명사 + "이다", 받침 없는 명사 + "다". 단, 구어체에서는 "이"가 탈락할 수 있으나 문어체에서는 정확히 쓴다.

10.2. 조사 오류

Before (틀림)	After (맞음)	규칙
모델을 사용	모델을 사용	(맞음)
서버는 → 서버을	서버를	받침 없으면 "를"
결과은	결과는	받침 없으면 "는"
값를	값을	받침 있으면 "을"
속도와 정확도와	속도와 정확도 / 속도, 정확도와	"와/과" 반복 금지

10.3. 띄어쓰기

Before (틀림)	After (맞음)
할수있다	할 수 있다
해야한다	해야 한다
못하다 (보조 용언)	못 하다 / 못하다 (본용언)
되어지다	되다 (이중 피동이기도 함)
안될	안 될

10.4. 맞춤법

Before (틀림)	After (맞음)
됬다	됐다
안됀다	안 된다
웬지	왠지
몇일	며칠
어떻게 (의도가 "어째서"일 때)	어째서 / 왜
되요	돼요
할께요	할게요
금새	금세

10.5. 하다체 종결어미 오류 (동사 vs 형용사)

AI는 동사와 형용사의 하다체 종결어미를 자주 혼동한다.

규칙:

동사 하다체: -ㄴ다 / -는다 (받침 없으면 -ㄴ다, 있으면 -는다)
형용사 하다체: -다 (기본형 그대로)
있다/없다: -다 (형용사처럼 활용)

Before (틀림)	After (맞음)	이유
이 방법이 맞다.	이 방법이 맞는다.	"맞다"는 동사 → -는다
서버가 돌아가다.	서버가 돌아간다.	"돌아가다"는 동사 → -ㄴ다
값이 들어가다.	값이 들어간다.	"들어가다"는 동사 → -ㄴ다
이 함수는 리스트를 반환하다.	이 함수는 리스트를 반환한다.	"반환하다"는 동사 → -ㄴ다
오류를 발생시키다.	오류를 발생시킨다.	"발생시키다"는 동사 → -ㄴ다
좋는다.	좋다.	"좋다"는 형용사 → -다
빠르는다.	빠르다.	"빠르다"는 형용사 → -다
있는다.	있다.	"있다"는 형용사 활용 → -다
없는다.	없다.	"없다"는 형용사 활용 → -다

주의: 관형형에서는 반대다.

동사: -는 (돌아가는 서버, 맞는 방법)
형용사: -ㄴ / -은 (좋은 방법, 빠른 서버)
있다/없다: -는 (있는 값, 없는 파일)

10.6. 서술형 종결 혼동 (기본형을 문장 끝에 그대로 쓰는 오류)

AI가 문장 끝에 동사 기본형을 그대로 놓는 경우가 있다. 하다체든 해요체든 종결어미를 붙여야 한다.

Before (틀림)	After (하다체)	After (해요체)
이 값을 사용하다.	이 값을 사용한다.	이 값을 사용해요.
결과를 반환하다.	결과를 반환한다.	결과를 반환해요.
에러가 발생하다.	에러가 발생한다.	에러가 발생해요.
파일을 읽다.	파일을 읽는다.	파일을 읽어요.
설정을 변경하다.	설정을 변경한다.	설정을 변경해요.

10.7. 무정물 조사: "에게" vs "에"

Before (틀림)	After (맞음)
컴파일러에게 힌트를 준다	컴파일러에 힌트를 준다
함수에게 인자를 전달한다	함수에 인자를 전달한다
운영체제에게 요청을 보낸다	운영체제에 요청을 보낸다
서버에게 데이터를 준다	서버에 데이터를 준다
시스템에게 알린다	시스템에 알린다

예외: 유정물처럼 의인화한 경우(비유, 픽션)에는 "에게"도 허용된다.

유지 가능 (유정물)	의미
학생에게	사람
고양이에게	동물
친구에게 물어봤다	사람

11. AI 슬롭 패턴 (의미 보존, 삭제 우선)

11.1. 규칙의 삼 (Rule of Three) 억지 맞춤

AI는 나열을 항상 세 개로 맞춘다. 원문에서 실제로 언급된 항목 수대로 쓴다.

Before	After
빠르고, 정확하고, 안정적이다. (안정성은 언급 안 됨)	빠르고 정확하다.
속도, 비용, 확장성 세 측면에서 유리하다. (확장성 근거 없음)	속도와 비용 측면에서 유리하다.

11.2. 공허한 상징 (Inflated Symbolism)

의미보다 장식이 앞서는 비유 표현. 대부분 삭제해도 원뜻이 유지된다.

"~의 등불이 되다", "~의 문을 열다", "~의 이정표가 되다"
"새로운 지평을 열다", "시대의 흐름을 선도하다"
"~라는 여정의 시작", "~라는 모험"
"패러다임의 전환", "게임 체인저"

Before	After
이 라이브러리는 한국어 NLP의 새로운 지평을 열었다.	이 라이브러리는 한국어 NLP 작업을 간단하게 만들었다.
Docker는 배포의 이정표가 된 도구다.	Docker는 배포를 단순화한 도구다.

11.3. 홍보성 어휘 (Promotional Language)

기술 문서·위키·뉴스에서 특히 문제가 되는 광고성 표현. 구체 사실로 대체하거나 삭제한다.

"업계를 선도하는", "최고 수준의", "타의 추종을 불허하는"
"강력한 성능", "압도적인 속도", "탁월한 품질"
"차세대", "첨단의", "최신의" (구체 버전/연도로 대체)
"획기적으로", "파격적으로", "대폭"

Before	After
업계를 선도하는 강력한 성능의 모델이다.	MMLU에서 86.4%를 기록한 모델이다.
차세대 데이터베이스 기술이다.	2024년에 나온 데이터베이스다.

11.4. 피상적 "-하면서" 분석 (Superficial -ing Analysis)

"~하면서", "~함으로써", "~을/를 통해"로 원인-결과 관계를 얼버무리는 구문. 대부분 실제 메커니즘이 없다. 삭제하거나 실제 메커니즘으로 바꾼다.

Before	After
이 모델은 어텐션을 활용하면서 문맥을 더 잘 이해한다.	이 모델은 어텐션으로 앞뒤 단어를 같이 본다.
캐시를 적용함으로써 성능이 향상된다.	캐시를 넣으면 두 번째 요청부터 DB를 안 친다.
API를 제공함으로써 개발자 편의성을 높였다.	API가 있어서 외부에서 호출할 수 있다.

11.5. 모호한 출처 (Vague Attributions)

실제 인용 없는 "일부 전문가들", "업계 관계자"류 표현. 근거가 있으면 구체적으로 쓰고, 없으면 삭제한다.

Before	After
업계 전문가들은 ~라고 전망한다.	(구체 출처 없으면 삭제, 있으면 "A사 CTO 아무개는 ~라고 말했다")
연구에 따르면 ~하다고 알려져 있다.	(논문 이름 없으면 삭제)
많은 개발자들이 ~를 선호한다.	(Stack Overflow 설문 등 실제 출처 명시)

11.6. 부정 평행 (Negative Parallelisms)

"A이자 B", "A일 뿐만 아니라 B이기도 한" 형태로 같은 뜻을 두 번 쓰는 병렬. 한쪽을 지운다.

Before	After
이 방법은 효율적일 뿐만 아니라 생산적이기도 하다.	이 방법은 효율적이다.
단순하지 않고 복잡하지도 않다.	적당한 복잡도다. (혹은 그냥 삭제)
쉽고 간단하다.	쉽다.

11.7. 연결어 과잉 (Excessive Conjunctive Phrases)

"게다가", "나아가", "더욱이", "한편", "결과적으로", "요컨대"가 문장마다 붙는다.
한 문단에 세 번 넘게 나오면 절반은 지운다. 한국어는 연결어 없이도 흐름이 이어진다.

Before	After
게다가 성능도 좋다. 나아가 메모리도 적게 쓴다. 더욱이 배포도 쉽다.	성능이 좋고, 메모리도 적게 쓰고, 배포도 쉽다.

11.8. AI 상투어휘 사전 (빠른 찾기/지우기)

AI 특유의 "그럴듯한" 단어들. 원문에서 보이면 바로 지우거나 구체 표현으로 바꾼다. 2.1~2.3과 중복되는 항목은 있으나, 일괄 검색용으로 묶어 둔다.

명사: "여정", "모험", "영역", "지평", "생태계", "패러다임", "랜드스케이프", "중추", "기반", "토대"
형용사/부사: "섬세한", "정교한", "우아한", "지능적인", "유기적으로", "총체적으로", "전방위적으로"
동사: "탐색하다", "탐험하다", "조망하다", "엿보다", "풀어내다", "녹여내다"
구: "~의 세계", "~의 중심에서", "~를 향한 발걸음", "~에 있어"

11.9. 의미 없는 메타-언급 (Self-referential Filler)

글 자체를 언급하는 문장은 대부분 삭제해도 본문이 자립한다.

"이 글에서는 ~다룬다/ 살펴본다/ 알아본다"
"앞서 언급한 바와 같이", "위에서 말했듯이"
"다음 절에서는 ~를 설명한다"
"이 섹션에서 중요한 것은"

정말 필요하면 한 번만 남긴다. 보통은 모두 지워도 된다.

11.10. 수치 부재 + 비교 남발

Before	After
기존 방식보다 훨씬 빠르다. (원문에 근거 있음)	기존 방식보다 2.3배 빠르다.
상당히 개선되었다. (원문에 수치 없음)	개선되었다. (혹은 관련 문장 삭제)

중요: 슬롭 제거 과정에서 없는 수치를 만들어 넣지 않는다. 원문에 없는 사실은 교정에서도 생기지 않는다. 의미 보존 원칙.

전체 교정 예시

예시 1: 기술 문서 (하다체)

Before (AI 말투)

본 문서에서는 최신 자연어 처리 기술의 다양한 발전 동향에 대해 살펴보겠습니다.

최근 대규모 언어 모델이 다양한 분야에서 혁신적인 성과를 보여주고 있습니다. 이러한 모델들은 텍스트 생성, 번역, 요약 등 폭넓은 태스크를 수행하는 데 있어 핵심적인 역할을 담당하고 있으며, 이를 통해 사용자 경험을 크게 향상시킬 수 있게 되었습니다.

주목할 만한 점은 이 기술이 기존 방식 대비 우수한 성능을 보여준다는 것입니다. 다양한 벤치마크에서 기존 모델 대비 성능이 향상되었으며, 특히 속도·정확도·안정성 측면에서 큰 개선이 이루어졌습니다.

결론적으로, 이 기술은 다양한 분야에 의미 있는 기여를 했다고 볼 수 있으며, 향후 더욱 발전할 것으로 기대됩니다.

After (자연스러운 한국어)

요즘 대규모 언어 모델이 자연어 처리 전반을 바꾸고 있다.

글을 쓰고, 번역하고, 요약하는 일에 이 모델들이 들어가면서 사람이 직접 하던 작업이 줄었다. 예전에는 태스크마다 모델을 따로 만들었는데, 이제는 하나로 여러 가지를 처리한다.

GPT-4 기준으로 MMLU 벤치마크에서 86.4%를 찍었다. 기존 최고 기록보다 5% 넘게 올랐고, 추론 속도도 2배 가까이 빨라졌다.

아직 환각 문제가 남아 있긴 하다. 하지만 쓸 만한 수준까지 온 건 맞다.

교정 내역

"살펴보겠습니다" 도입 삭제
"다양한", "혁신적인", "핵심적인 역할을 담당" 등 빈 수식어 제거
"향상되었으며" 피동 표현을 "올랐다" 능동으로 전환
"속도·정확도·안정성" 가운뎃점을 구체 수치로 교체
"결론적으로 ~기여를 했다고 볼 수 있으며" 상투적 마무리 삭제
"주목할 만한 점은 ~것입니다" AI 상투어 삭제
볼드 제거, 말투 하다체로 통일
문장 길이 변화 추가 ("아직 환각 문제가 남아 있긴 하다. 하지만 쓸 만한 수준까지 온 건 맞다.")

예시 2: 블로그 포스트 (해요체)

Before (AI 말투)

Docker 입문: 컨테이너의 세계로의 여정

안녕하세요! 오늘은 Docker에 대해 자세히 살펴보겠습니다. Docker는 혁신적인 컨테이너 기술로, 개발자들에게 다양한 이점을 제공합니다.

Docker를 활용하면 다음과 같은 장점이 있습니다:

환경 일관성: 개발 환경과 운영 환경의 차이를 해소할 수 있습니다

빠른 배포: 애플리케이션을 신속하게 배포할 수 있습니다

리소스 효율성: 가상머신 대비 효율적인 리소스 활용이 가능합니다

흥미로운 점은 Docker가 기존의 가상화 기술이 직면하고 있던 다양한 문제점들을 해결했다는 것입니다. 이를 통해 개발자들은 보다 효율적인 워크플로우를 구현할 수 있게 되었으며, 궁극적으로 생산성 향상에 크게 기여하고 있습니다.

이 글이 Docker를 이해하시는 데 도움이 되셨기를 바랍니다. 궁금한 점이 있으시면 댓글로 남겨주세요!

After (자연스러운 한국어)

Docker 입문

Docker는 앱을 컨테이너에 넣어서 돌리는 도구예요. VM보다 가볍고, 어디서든 똑같이 동작해요.

왜 쓰냐면요. 개발할 때 "내 컴퓨터에서는 되는데?"라는 말, 해 보셨죠? Docker를 쓰면 개발 환경이랑 서버 환경이 같으니까 이런 일이 없어요. 배포도 이미지 하나 올리면 끝이고요.

VM은 OS 전체를 올리지만, 컨테이너는 필요한 것만 담아요. 같은 서버에서 컨테이너를 10개 돌릴 수 있어도, VM은 3개도 버거울 때가 많아요.

설치는 brew install docker로 시작하면 돼요.

교정 내역

"안녕하세요! 오늘은 ~살펴보겠습니다" 챗봇 도입 삭제
"혁신적인", "다양한" 빈 수식어 제거
"활용하면" → "쓰면" 영어 직역 교체
3개짜리 불릿 리스트를 문장으로 풀어 씀
"흥미로운 점은 ~것입니다" AI 상투어 삭제
"이를 통해 ~기여하고 있습니다" 상투적 연결 삭제
"도움이 되셨기를 바랍니다 / 댓글로 남겨주세요" 챗봇 마무리 삭제
"직면하고 있던" 피동/번역체를 구어로 전환
해요체로 통일, 구체적 예시 추가 (VM vs 컨테이너 비교)

예시 3: 개발자 문서 / README (하다체)

Before (AI 말투)

개요

본 라이브러리는 다양한 데이터베이스 작업을 수행하기 위한 포괄적인 ORM 솔루션을 제공합니다. 이를 기반으로 개발자들은 복잡한 SQL 쿼리 작성 없이도 효율적인 데이터베이스 조작을 달성할 수 있습니다.

주요 기능

본 라이브러리의 주요 기능은 다음과 같습니다:

자동 마이그레이션: 스키마 변경을 자동으로 감지하여 마이그레이션을 수행합니다

타입 안전성: TypeScript와의 완벽한 통합을 제공하여 런타임 에러를 최소화합니다

쿼리 빌더: 직관적인 API를 통해 복잡한 쿼리를 구현할 수 있습니다

설치 방법

설치는 다음과 같은 방법으로 수행할 수 있습니다:
npm install myorm
설치가 완료되면, 다음 단계에서는 설정 파일을 생성하는 과정을 진행하겠습니다.

After (자연스러운 한국어)

개요

SQL 안 쓰고 데이터베이스를 다루는 ORM이다.

주요 기능

스키마가 바뀌면 마이그레이션을 자동으로 만들어 준다

TypeScript 타입을 그대로 쓴다. 런타임 에러가 줄어든다

복잡한 쿼리도 메서드 체이닝으로 짠다

설치
npm install myorm
설치 후 설정 파일을 만든다.

교정 내역

"본 라이브러리는 ~포괄적인 ORM 솔루션을 제공합니다" → 한 줄로 축약
"수행하기 위한", "달성할 수 있습니다" 번역체 동사 정리
"주요 기능은 다음과 같습니다" 뻔한 안내 삭제
"완벽한 통합을 제공하여" → "그대로 쓴다"
"직관적인 API를 통해 ~구현할 수 있습니다" → "메서드 체이닝으로 짠다"
"설치는 다음과 같은 방법으로 수행할 수 있습니다" → 코드 블록만 남김
"다음 단계에서는 ~과정을 진행하겠습니다" 안내체 삭제
볼드 과다 제거, 하다체 통일, 불릿은 간결하게 유지

예시 4: 비즈니스 이메일 (해요체)

Before (AI 말투)

안녕하세요, 김 팀장님.

금번 프로젝트 진행 상황과 관련하여 말씀드리고자 합니다. 현재 백엔드 API 개발이 완료되었으며, 프론트엔드 작업이 진행 중에 있습니다. 이와 관련하여 몇 가지 논의가 필요한 사항이 존재합니다.

첫째, 인증 시스템 구현에 있어 OAuth 2.0과 JWT 중 어떤 방식을 채택할지에 대한 결정이 요구됩니다. 둘째, 데이터베이스 스키마 변경이 필요한 상황이 발생하였으며, 이로 인해 일정이 2일 정도 지연될 것으로 예상됩니다.

상기 사항들에 대해 내일 오전 중으로 미팅을 진행하면 좋을 것 같습니다. 검토 부탁드리겠습니다.

감사합니다.

After (자연스러운 한국어)

김 팀장님, 안녕하세요.

프로젝트 진행 상황 공유드려요. 백엔드 API는 다 만들었고, 프론트엔드는 작업 중이에요.

두 가지 정해야 할 게 있어요.

인증을 OAuth 2.0으로 갈지 JWT로 갈지 아직 못 정했어요.

DB 스키마를 바꿔야 해서 일정이 이틀쯤 밀릴 것 같아요.

내일 오전에 잠깐 미팅하면 좋겠어요.

감사합니다.

교정 내역

"금번", "상기 사항들" 공문서체 → 일상 비즈니스 표현
"~와 관련하여 말씀드리고자 합니다" 장황한 도입 축약
"존재합니다" → 삭제 (있다고 안 해도 뒤에 나옴)
"채택할지에 대한 결정이 요구됩니다" 피동 → "못 정했어요"
"발생하였으며, 이로 인해" 번역체 연결 → "바꿔야 해서"
"진행하면 좋을 것 같습니다" → "하면 좋겠어요"
"검토 부탁드리겠습니다" 불필요한 문장 삭제 (미팅 요청만으로 충분)
번호 리스트로 핵심만 정리, 해요체 통일

예시 5: 뉴스 기사 (하다체)

Before (AI 말투)

국내 반도체 산업, 혁신적 도약을 이루다

국내 반도체 산업이 글로벌 시장에서 다양한 분야에 걸쳐 혁신적인 성과를 달성하고 있다. 삼성전자와 SK하이닉스로 대표되는 국내 기업들은 차세대 메모리 기술 개발에 있어 선도적인 역할을 수행하고 있으며, 이를 통해 글로벌 경쟁력을 한층 강화시키고 있다.

특히 주목할 만한 점은 HBM(High Bandwidth Memory) 분야에서의 기술적 우위이다. 양사는 HBM3E 및 차세대 HBM4 개발을 본격화하고 있으며, 이는 AI 반도체 시장의 폭발적 성장과 맞물려 핵심적인 성장 동력으로 작용하고 있다.

업계 전문가들은 향후 국내 반도체 산업이 AI·자율주행·데이터센터 등 다양한 첨단 분야에서 보다 중요한 역할을 담당하게 될 것이라고 전망하고 있으며, 이를 위한 지속적인 투자와 인력 양성이 요구된다고 강조하였다.

After (자연스러운 한국어)

삼성·SK, HBM으로 AI 반도체 시장 잡는다

삼성전자와 SK하이닉스가 고대역폭 메모리(HBM) 시장에서 앞서 나가고 있다. 두 회사 모두 HBM3E 양산에 들어갔고, HBM4 개발도 시작했다.

AI 서버에는 HBM이 필수다. 엔비디아 H100 GPU 하나에 HBM이 80GB 들어간다. AI 수요가 커지면서 HBM 매출이 1년 만에 3배 뛰었다.

반도체 업계에서는 AI, 자율주행, 데이터센터용 수요가 계속 늘어날 것으로 본다. 다만 인력이 부족하다는 목소리도 나온다.

교정 내역

제목: "혁신적 도약을 이루다" 빈 수식 → 구체적 내용("HBM으로 AI 반도체 시장 잡는다")
"다양한 분야에 걸쳐 혁신적인 성과를 달성" 빈 수식어 전체 삭제
"선도적인 역할을 수행하고 있으며" → "앞서 나가고 있다"
"이를 통해 글로벌 경쟁력을 한층 강화시키고 있다" 상투 문장 삭제
"주목할 만한 점은 ~우위이다" AI 상투어 삭제, 바로 사실 서술
"폭발적 성장과 맞물려 핵심적인 성장 동력으로 작용" → 구체 수치로 대체
"AI·자율주행·데이터센터" 가운뎃점 → 쉼표
"요구된다고 강조하였다" 피동 + 인용 중첩 → "목소리도 나온다"
하다체 통일, 구체 수치 삽입 (H100 GPU, 80GB, 3배)

처리 방식

공통 선행 단계 (파일/텍스트 상관없이 반드시 먼저)

"문체 인터뷰" 섹션의 세 질문(문체 기조, 종결 어미, 교정 강도)을 AskUserQuestion으로 받는다.
사용자 응답을 교정 패스의 기본값으로 고정한다. 이후 교정에서는 이 기본값을 따른다.
사용자가 응답을 건너뛰거나 "알아서 해 달라"고 답하면 문어체 / 하다체 / 중 을 기본값으로 쓰되, 최종 출력 상단에 사용된 기본값을 한 줄로 명시한다.

파일이 주어진 경우

공통 선행 단계로 문체를 확정한다.
Read로 파일을 읽는다.
위 규칙(섹션 1~11)에 따라 전문을 교정한다.
Edit으로 원본 파일을 수정하거나, Write로 새 파일에 저장한다.

텍스트가 직접 주어진 경우

공통 선행 단계로 문체를 확정한다.
위 규칙(섹션 1~11)에 따라 전문을 교정한다.
교정된 텍스트를 출력한다.
주요 교정 내역을 간단히 정리한다(어떤 규칙 번호가 적용됐는지).

12. 최종 점검 (교정 완료 전 반드시 확인)

em dash, en dash, 가운뎃점이 하나도 없는가?
AI 상투어("살펴보겠습니다", "결론적으로" 등)가 하나도 없는가?
이중 피동("보여지다", "만들어지게 되다")이 없는가?
빈 수식어("다양한", "혁신적인") 없이 구체적으로 썼는가?
문체 인터뷰에서 고른 말투(문어체 vs 구어체, 하다체/합쇼체/해요체/해체)가 문서 전체에서 일관되게 적용됐는가?
문장 길이가 자연스럽게 섞여 있는가?
볼드가 과하지 않은가?
소리 내어 읽었을 때 어색한 문장이 없는가?
원뜻이 보존됐는가? 구체 수치·고유명사·인과 관계가 원문과 일치하는가? (ai-slop-cleaner 원칙 — 의미 변경 금지)
삭제 패스 우선 원칙을 지켰는가? 새 비유·새 예시를 임의로 추가하지 않았는가?
규칙의 삼(11.1), 공허한 상징(11.2), 홍보성 어휘(11.3), 피상적 "-하면서"(11.4), 모호한 출처(11.5) 점검이 끝났는가?
원문에 없던 수치·인용·출처를 만들어 넣지 않았는가?