---
name: ai-killer
description: "고객·외부 전달용 산출물(매뉴얼·슬라이드·리포트·UI 카피·README)에서 'AI가 대충 뽑은 티'를 잡아 격식·깊이·정확성·시각 완성도를 끌어올리고, 독자가 비개발자일 때 '너무 개발자스러운 티'(파일명·스택·jargon)를 눈높이에 맞게 푸는 리뷰·수정 스킬. 산출물을 만들거나 검토할 때, 특히 사용자가 'AI스럽다 / 성의 없다 / 밋밋하다 / 너무 개발자스럽다 / 고객이 어떻게 볼까'라고 지적할 때 자동 참고. /ai-killer [대상] 으로 호출."
---

# ai-killer

AI가 만든 결과물 특유의 "성의 없어 보이는 티"를 제거하는 리뷰·수정 스킬.
핵심 전제: **고객사 입장에서 '대충 만들었다'는 인상은 내용보다 디테일에서 온다.** 톤(구어체), 빈 데이터, 기능 나열식 깊이 부족, 어긋난 박스/작은 글자, 없는 기능 단정 — 이런 신호를 사용자가 짚기 전에 먼저 잡는다.

## 트리거 조건

- 고객/외부에 나갈 문서·슬라이드·리포트·UI 카피·README 를 작성하거나 검토할 때
- 사용자가 "AI스럽다 / 성의 없다 / 밋밋하다 / 고객이 보면 어떨까" 류 피드백을 줄 때
- 완성도 낮은 산출물에 "이거 좀 다듬어줘"
- `/ai-killer [대상]` 명시 호출

## 절차

1. **대상 독자로 통독**: "이 프로젝트를 처음 듣는 사람"이 읽는다고 가정하고 산출물 전체를 본다. 목적·사용법·취지가 이해되는가? 안 되면 구조 결함(B).
2. **신호 탐지**: 아래 체크리스트 A~F·H 로 훑는다. 각 신호는 구체 위치(페이지/문장/요소)와 함께 기록. (H는 독자가 비개발자일 때만 적용 — 먼저 독자를 확인)
3. **구체 수정안 제시**: 막연한 "더 명확히"가 아니라 `before → after` 로. 사용자가 바로 판단할 수 있게.
4. **적용 후 검증**: 텍스트는 다시 읽고, 시각물은 **실제로 렌더/스크린샷 떠서 눈으로 본다**(G). "고쳤다"를 눈으로 확인하기 전에 선언하지 않는다.
5. **모르는 것은 질문**: 연락처·실제 수치·FAQ 등 내가 모르는 내용은 지어내지 말고 사용자에게 묻거나 비운다.

## AI스러움 신호 체크리스트 (핵심)

각 신호에 심각도를 붙여 보고한다 (im-not-ai taxonomy 차용):
- **S1 (결정적)**: 발견 즉시 수정 제안. 1회만 나와도 AI 티
- **S2 (강함)**: 문서 내 3회 이상 반복되면 수정 제안
- **S3 (약함)**: 다른 신호와 중첩될 때만 언급

리뷰 결과는 S1 → S2 → S3 순으로 정렬해 사용자가 취사선택하기 쉽게.

### A. 톤·워딩

#### A-1. 구어체를 격식체로 (S1)
고객 문서는 격식체. 구어체 어미·필러를 정리한다.

| before | after |
|---|---|
| 보여줍니다 | 표시합니다 |
| (조건)으로 좁힙니다 | 한정합니다 / 필터링합니다 |
| 데이터를 빼면 | 데이터를 제외하면 |
| 골라 / 골라서 | 선택해 |
| 바꿔 / 바꿔서 | 변경해 |
| 켜고 끄거나 | On/Off 하거나 |
| "아예 / 그냥 / 좀" 같은 필러 | 삭제 |

#### A-2. 번역투 (문어체인데 어색한 한글)
| 심각도 | before | after |
|---|---|---|
| S1 | ~에 대해 논의할 필요 | ~를 논의해야 한다 |
| S1 | 데이터 분석을 통해 인사이트를 | 데이터를 분석해 인사이트를 |
| S1 | 이 문제에 있어서 | 이 문제에서 |
| S1 | 경쟁력을 가지고 있다 | 경쟁력이 강하다 |
| S1 | 판단되어진다 (이중 피동) | 판단된다 |
| S1 | 그/그녀/그것 대명사 직역 | 주어 생략 또는 명사 반복 |
| S2 | AI에 의해 생성된 | AI가 만든 |
| S2 | 효율을 높일 수 있다 남발 | 효율을 높인다 (단언 가능하면 단언) |
| S2 | 합의가 이루어졌다 | 합의했다 |
| S2 | ~에 기반하여 / ~와 관련하여 | ~로 / ~에 |

#### A-3. AI 상투구·과장 (S1)
| before | after |
|---|---|
| 결론적으로 / 요약하면 / 다시 말해 (기계적 마무리) | 구체 근거로 맺거나 삭제 |
| 매우 중요하다 / 주목할 만하다 | 구체 수치·사례로 |
| 크게 세 가지로 나눌 수 있다 | 도입구 없이 바로 열거 |
| 획기적인·혁신적인·강력한·압도적·원활하게 (빈 마케팅 형용사) | 무엇이 어떻게 좋은지 구체적으로 |
| "성능이 크게 향상됐습니다" (수치 없는 주장) | "RMSE 0.18, 직전 모델 대비 8% 개선" |

#### A-4. 반복·밀도 신호 (S2 - 3회 이상일 때)
- **"첫째/둘째/셋째" 기계적 병렬**: 일부를 서술문으로 풀기
- **문두 접속사 연속** (또한/따라서/즉/하지만): 70% 이상 제거해도 읽힘
- **"것이다 / ~할 필요가 있다 / ~해야 한다" 종결 남발**: 주어·동사 구체화 ("혁신이 필요하다" → "기업은 혁신해야 한다")
- **hedging 중첩**: "~할 가능성이 있을 수 있다" → 완곡 하나만
- **동의어 이중 수식**: "중요하고 핵심적인 역할" → 하나만
- **"~적/-성/-화" 명사화 체인**: "근본적 관점에서 구조적 변화" → "구조가 근본부터 바뀐다"
- **연결어미 뒤 쉼표** ("~지만, / ~고,"): 제거 (이건 S1)
- **볼드·따옴표·대시(—) 남발**: 본문 볼드 최소화, 대시는 쉼표/괄호/문장 분리로
- **문장 리듬 균일** (모든 문장 30~50자, 모든 문단 3~4문장): 단문·장문 혼용

> 전체 37패턴 상세: https://github.com/epoko77-ai/im-not-ai `references/ai-tell-taxonomy.md`

### B. 깊이·구조 — 기능 나열에서 목적+시나리오로 (가장 흔한 치명타)
"이 버튼은 X" 나열만으로 끝내면 매뉴얼이 아니라 라벨 모음이다. 다음을 갖췄는지 점검:
- **목적/개요(TL;DR)**: 무슨 목적의 시스템/문서인가 (한 줄 정의 + 왜 쓰는지)
- **사용법 안내**: "이런 질문이면 어디를 보라" (질문 → 위치 매핑)
- **시나리오/워크플로우**: 기능별 설명 후 "어떤 목표로 어떤 순서로 조작하며 무엇을 봐야 하나" (IF 시나리오 A → 화면 흐름)
- **실제 예시**: 추상 설명 대신 실제 데이터/사례 기반 한 사이클
- 기준: **프로젝트를 처음 듣는 직원도 목적·사용법·취지를 이해**할 수 있어야 함

### C. 빈/가짜 데이터 — 채우되 진짜처럼
- 빈 화면(0%, 빈 차트, "데이터 없음") 캡처 금지 → 더미라도 채워서 다시 캡처
- 더미가 **완벽한 직선/균일값**이면 가짜 티 → 노이즈·변동·위상차를 넣어 실제 데이터처럼
- 가능하면 **실제 사례**(예: "수신 30건 중 정상 10건") 기반으로, 시나리오와 수치를 일치시킴

### D. 시각 디테일 — AI가 잘 안 챙기는 것들
- **가독성**: 라벨·글자가 실제 모니터(예: 27")에서 안 보일 만큼 작지 않은지. 캡처 오버레이/배지 폰트가 충분히 큰지
- **마커가 콘텐츠를 가림**: 번호 배지가 아이콘·텍스트 위를 덮으면 위치를 옮긴다(위 공간 없으면 아래로)
- **박스 정렬**: 강조 박스가 대상 요소에 딱 맞는지. `position:fixed`/포털 요소(드롭다운 등)는 좌표 측정과 그리기를 같은 스크롤 상태에서 — 어긋남 주의
- **중복 강조**: 큰 박스가 그 안의 작은 박스를 포함하는 식의 겹침/중복 박스는 하나로 통합·제거
- **군더더기 잔텍스트**: 의미 없는 작은 회색 부제·푸터 브랜드·URL 줄 등은 삭제해 깔끔하게
- **과한 그라데이션 (AI 티 1순위)**: 배경·버튼·카드에 보라↔파랑 같은 그라데이션을 깔면 "AI가 찍어낸 템플릿" 느낌이 가장 강하게 난다 → 단색(flat) 또는 아주 옅은 단색 한 톤으로. (예: `linear-gradient(...)` 배경 → `#1e40af` 단색 / 옅은 `#f8fafc`)
- **과한 라운드 코너**: 모서리를 지나치게 둥글게 하면(카드가 알약처럼 보임) 장난감 같고 AI 티가 난다 → 적당한 라운드로. (예: `rounded-2xl` / `rounded-large`(16~24px) → `rounded` / `rounded-md`(4~8px))
- **형광/네온 색 + 글로우**: 채도 높은 형광색이나 빛나는 그림자(glow)는 업무 문서에 거의 의도된 적 없는 AI 티 → 차분한 브랜드 톤 + 옅은(또는 없는) 그림자
- **과도한 여백**: 콘텐츠가 한쪽에 몰리고 화면 절반이 비어 허전하면 → 요소를 키우거나 위로 당겨 균형. (예: 카드 높이를 옆 사진 높이에 맞추기, 제목 아래 콘텐츠를 위로 올리기)
- **기본 폰트(한글)**: 시스템 기본 맑은 고딕은 다소 투박함 → **Pretendard** 권장. 강조=`Pretendard`(Bold), 본문=`Pretendard Variable Medium` (ExtraLight는 너무 얇으니 피함)
- **한글 줄바꿈(어절 단위)**: 한글이 단어 중간에서 끊기면("데이/터 분석") 가독성↓·AI 티 → `word-break: keep-all`로 어절 단위 줄바꿈. 긴 영문/URL 넘침 방지로 `overflow-wrap: break-word` 함께. (CSS 제어 불가한 산출물=PPTX/이미지면 줄바꿈 위치를 수동으로 어절 경계에 맞춤)

### E. 정확성·정직성
- **없는 기능 단정 금지**: "예측 vs 실제 자동 비교" 처럼 실제로는 미구현인데 있는 것처럼 쓰지 않는다 → 코드/사실 확인 후 정직하게
- **고객사·제품명 풀네임/정확 표기**: 약칭·혼용 금지
- **모르면 비우거나 질문**: 연락처·FAQ·실측치를 추측으로 채우지 않는다
- **미완성 흔적 제거**: "Lorem ipsum", "여기에 내용", "TODO", 임시 더미 라벨이 남아 있으면 → 실제 내용으로 채우거나 삭제

### F. 일관성
- **브랜드 표기 통일**: 띄어쓰기/대소문자를 문서 전체에서 한 가지로 (예: 'AcmeAI'/'Acme AI' 중 하나로 고정)
- **도메인 용어 맥락**: 특정 용어가 다른 맥락에서 오해되지 않게 (예: '양품/불량'은 공정 KPI 용어 → 데이터 검증 맥락에선 '정상/검증 통과' 등으로 구분)

### H. 독자 눈높이 — 개발자 시점 잔재 (대상이 비개발자일 때만)
**먼저 독자를 확인한다.** 독자가 개발자(README·기술문서·인수인계·API 문서)면 파일명·스택·코드는 **필수 정보라 유지** — 이 항목 적용 안 함. 독자가 경영진·고객·현업 등 비개발자면 아래를 푼다.

| before | after |
|---|---|
| `harness-data.ts에 정적 데이터로 보관` | "데이터는 화면에 내장" (파일명은 부록/각주로) |
| `fetch/axios/WebSocket 미구현` | "아직 서버와 실시간으로 연결되지 않음" |
| `Next.js 16 Server Components + Suspense 스트리밍` | "최신 웹 기술로 빠르게 렌더링" (또는 표 한 줄로 압축) |
| 기술 스택 8줄 나열 | "왜 그 선택인지" 한 줄 + 상세는 부록 |
| 독자가 실행 안 할 코드블록 남발 | 요약 문장으로 (실행/복붙 대상일 때만 코드 유지) |
| `미구현 / TODO / null 반환` 등 내부 상태 | 로드맵 표현("예정")으로 |
| 영어 약어 무번역 (RSC·SSR·SLA·E2E) | 풀어쓰거나 괄호 병기 (처음 1회) |

- 판단 기준: "이 독자가 이 단어/경로/코드를 보고 **행동이 달라지는가**?" 아니면 부록으로 내리거나 평이하게.
- 과교정 금지: 도메인 핵심 용어(공정·수율·PLC 등 독자가 아는 업무어)까지 풀어버리지 말 것. 제거 대상은 **구현 jargon**이지 업무 용어가 아니다.

### G. 검증 규율 (메타 교훈)
같은 시각 문제를 사용자가 여러 번 지적하는 건 "검증 없이 선언"했다는 신호다.
- 시각물은 **반드시 렌더/스크린샷 떠서 직접 본 뒤** 보고. 좌표가 의심되면 픽셀 검출 등으로 근거 확보
- 텍스트 일괄 치환 후에도 결과를 다시 읽어 오·과교정 확인

## 주의사항/함정

1. **일반론 금지**: "더 명확하게/전문적으로 쓰라" 같은 막연한 조언 자체가 AI스럽다. 항상 `before → after` 실예시로.
2. **과교정 금지**: 사용자 고유 톤·표현까지 밀어버리지 말 것. 격식화는 구어체·필러에 한정하고, 사용자가 의도한 강조/표현은 보존.
   - **span 단위 수술 원칙**: 문체 수정(A)은 탐지된 구절만 고치고 문장을 통으로 재작성하지 않는다. 사실·수치·고유명사는 100% 보존.
   - 문체 수정으로 문서의 30% 이상이 바뀌면 과교정 신호 → 사용자에게 경고하고 S1만 적용.
3. **검증 없이 완료 선언 금지**: 특히 박스 정렬·라벨 크기·레이아웃은 눈으로 확인 전까지 "됐다" 금지.
4. **지어내기 금지**: 모르는 사실(수치/연락처/기능 유무)은 확인하거나 비우고 질문. 그럴듯하게 채우는 게 가장 위험한 AI스러움.
5. **범용 규칙 + 특정 예시 분리**: 규칙은 범용으로, 프로젝트 전용 디테일은 예시로만 인용.

## 검증 방법

- 시각물(PPTX/PDF/이미지): 실제로 렌더(예: PowerPoint COM, LibreOffice, fitz)해서 슬라이드/페이지를 눈으로 확인. 의심 영역은 크롭·확대.
- 텍스트: 치환 후 전체 desc/문장을 다시 출력해 오·과교정 점검.
- 구조(B): "처음 듣는 사람이 목적/사용법/취지를 이해하는가" 1문장 자문에 통과하는지.

## 사용 예시

사용자: "이 매뉴얼 좀 AI스러운데 고객 주기 민망해"

1. 대상 독자(고객사 신입) 입장으로 통독 → 목적·사용법·시나리오 부재(B) 발견
2. 체크리스트로 탐지: 톤 구어체 다수(A), 대시보드 빈 데이터(C), 박스 어긋남·작은 라벨(D), 미구현 기능 단정(E)
3. 항목별 `before → after` 제시 + 구조 보강안(개요/사용법/시나리오 슬라이드 추가)
4. 수정 적용 후 슬라이드 렌더해서 확인, 모르는 값(연락처 등)은 질문 목록으로
5. 보고: 무엇을 어떤 근거로 고쳤는지 + 남은 확인 필요 항목