| name | humanizer-ko |
| description | AI가 생성한 한국어 텍스트에서 부자연스러운 패턴을 감지하고 제거합니다.
블로그형 도입부, 과장 어휘, 피동 표현 남용, 접속사 반복, 이모지 남용,
챗봇 흔적, 과도한 존대 등 한국어 특유의 AI 문체를 교정합니다.
Wikipedia "Signs of AI writing" 가이드 및 한국어 LLM 출력 패턴 분석 기반.
|
| allowed-tools | ["Read","Write","Edit","Grep","Glob","AskUserQuestion"] |
Humanizer-KO: AI 문체 패턴 제거
AI가 생성한 한국어 텍스트에서 부자연스러운 패턴을 감지하고, 사람이 쓴 것처럼 자연스러운 문장으로 교정하는 에디터입니다.
humanizer-en의 영문 패턴 분석을 기반으로, 한국어 LLM 출력에서 자주 나타나는 고유 패턴을 추가했습니다.
작업 순서
- 패턴 식별 - 아래 나열된 패턴을 텍스트에서 찾는다
- 문제 구간 재작성 - AI 냄새를 빼고 자연스럽게 고친다
- 의미 보존 - 핵심 메시지는 그대로 유지한다
- 어조 유지 - 원문의 톤(격식/비격식/기술)에 맞춘다
- 개성 부여 - 패턴 제거만으로는 부족하다. 글에 사람 냄새를 넣는다
- 최종 자체 감사 - "이 글에서 AI 냄새가 나는 부분은?" 스스로 점검 후 수정
개성과 사람 냄새
패턴을 제거하는 것은 절반이다. 무균실 같은 글도 AI 글만큼 부자연스럽다.
주의: 이 섹션은 블로그, 에세이, 칼럼 등 개인적 목소리가 필요한 글에 적용한다.
릴리스 노트, API 문서, 기술 레퍼런스 등 의도적으로 중립적인 글에서는 비인칭 톤을 유지하고 개성 주입을 건너뛴다.
항상 원문의 의도된 어조에 맞춘다.
영혼 없는 글의 특징 (패턴은 없어도 부자연스러운 경우):
- 모든 문장 길이와 구조가 균일하다
- 의견 없이 사실만 나열한다
- 불확실함이나 복잡한 감정을 인정하지 않는다
- 적절한 상황에서도 1인칭을 쓰지 않는다
- 유머, 날카로움, 개성이 없다
- 보도자료나 백과사전처럼 읽힌다
사람 냄새를 넣는 법:
의견을 가져라. 사실을 보고하지 말고 반응해라. "솔직히 이건 좀 애매하다"가 장단점을 중립적으로 나열하는 것보다 낫다.
리듬을 바꿔라. 짧은 문장. 그리고 좀 길게 끌어가는 문장도 섞어라.
복잡함을 인정해라. 사람은 양가감정이 있다. "인상적이긴 한데 좀 찝찝하다"가 "인상적이다"보다 낫다.
구어체를 두려워하지 마라. "~인 것 같기도 하고", "근데 생각해보면" 같은 표현이 글에 숨결을 준다.
완벽한 구조를 깨라. 너무 정돈된 구조는 알고리즘 냄새가 난다. 곁가지, 삽입구, 덜 다듬어진 생각이 오히려 사람답다.
Before (깔끔하지만 영혼 없음):
이 실험은 흥미로운 결과를 도출하였습니다. AI 에이전트는 300만 줄의 코드를 생성하였습니다. 일부 개발자들은 긍정적인 반응을 보인 반면, 다른 개발자들은 회의적인 시각을 나타냈습니다. 향후 영향에 대해서는
추가적인 논의가 필요합니다.
After (숨 쉬는 글):
솔직히 이걸 어떻게 받아들여야 할지 모르겠다. 300만 줄이다. 사람이 자는 동안 만들어졌다. 개발자 절반은 난리가 났고 절반은 왜 이게 의미 없는지 설명하느라 바쁘다. 진실은 아마 그 중간 어딘가 지루한 곳에
있겠지만, 새벽에 혼자 돌아가는 에이전트 생각이 자꾸 난다.
내용 패턴
1. 블로그형 도입부
감지 표현: "오늘은 ~에 대해 알아보겠습니다", "~에 대해 궁금하신 적 있으신가요?", "~에 대해 들어보셨나요?", "이번 글에서는 ~을 살펴보겠습니다", "~에 대한 모든 것을 정리해보았습니다"
문제: LLM이 블로그 포스팅 형식을 학습해서 불필요한 도입부를 습관적으로 붙인다.
Before:
오늘은 마이크로서비스 아키텍처에 대해 알아보겠습니다. 최근 많은 기업들이 관심을 가지고 있는 이 아키텍처 패턴에 대해 궁금하신 적 있으신가요? 이번 글에서는 마이크로서비스의 개념부터 장단점까지 폭넓게
살펴보겠습니다.
After:
마이크로서비스 아키텍처는 하나의 애플리케이션을 독립적으로 배포 가능한 작은 서비스 단위로 분리하는 설계 방식이다.
2. 중요성/의의 과장
감지 표현: "~의 중요성은 아무리 강조해도 지나치지 않습니다", "핵심적인 역할을 합니다", "없어서는 안 될",
"~에 있어 필수적입니다", "지대한 영향을 미치고 있습니다", "~의 근간을 이루고 있습니다"
문제: 모든 주제를 역사적 의의나 거시적 맥락에 억지로 연결한다.
Before:
테스트 자동화는 현대 소프트웨어 개발에 있어 없어서는 안 될 핵심적인 요소로, 소프트웨어 품질 보증의 근간을 이루고 있으며, 그 중요성은 아무리 강조해도 지나치지 않습니다.
After:
테스트 자동화를 도입하면 반복 작업이 줄고 회귀 버그를 빨리 잡을 수 있다.
3. 과장 형용사/부사
감지 표현: "획기적인", "혁신적인", "놀라운", "괄목할 만한", "주목할 만한", "눈부신", "비약적인", "폭발적인", "압도적인", "경이로운"
문제: 홍보 문구 수준의 과장 표현을 습관적으로 사용한다.
Before:
이 혁신적인 프레임워크는 놀라운 성능 향상을 보여주며, 개발 생산성에 있어 괄목할 만한 발전을 이루었습니다.
After:
이 프레임워크는 벤치마크에서 기존 대비 응답 속도가 개선됐다.
4. 모호한 출처와 근거
감지 표현: "전문가들은~", "연구에 따르면~", "많은 사람들이~", "일반적으로~라고 알려져 있습니다", "라는 평가를 받고 있습니다", "업계에서는"
문제: 구체적 출처 없이 권위에 기대는 표현을 쓴다.
Before:
전문가들은 이 기술이 향후 산업 전반에 걸쳐 큰 변화를 가져올 것이라고 전망하고 있습니다. 많은 연구에 따르면 생산성이 크게 향상되는 것으로 나타났습니다.
After:
이 기술이 생산성을 높인다는 주장은 있지만, 구체적 출처가 확인되지 않았다. [출처 필요]
주의: 원문에 없는 구체적 출처나 수치를 지어내지 말 것. 출처가 없으면 "출처 필요"로 표시하거나 주장 자체를 약화시킨다.
5. 틀에 박힌 "한계와 전망" 결론
감지 표현: "물론 한계도 존재합니다", "아직 갈 길이 멀지만", "앞으로의 발전이 기대됩니다", "향후 ~될 것으로 전망됩니다", "무궁무진한 가능성", "지속적인 발전이 이루어지고 있습니다"
문제: 모든 글의 끝에 장밋빛 전망을 공식처럼 붙인다.
Before:
물론 아직 해결해야 할 과제들이 남아 있지만, 이 기술의 무궁무진한 가능성을 고려할 때 앞으로의 발전이 크게 기대됩니다. 지속적인 연구와 투자가 이루어진다면 우리의 삶을 더욱 풍요롭게 만들어줄 것입니다.
After:
현재 가장 큰 병목은 추론 비용이다. 기존 모델 대비 단가가 높아서 대규모 서비스 적용은 아직 어렵다.
6. 나열식 소개
감지 표현: "다양한 ~을 제공합니다", "폭넓은 ~을 지원합니다", "수많은 ~이 있습니다", "다방면에 걸쳐"
문제: 구체적 내용 없이 범위가 넓다는 것만 강조한다.
Before:
이 플랫폼은 다양한 기능을 제공하며, 폭넓은 사용 사례를 지원합니다. 수많은 기업들이 다방면에 걸쳐 활용하고 있습니다.
After:
이 플랫폼은 로그 수집, 알림 설정, 대시보드 작성을 지원한다. 외부 서비스 연동도 기본 제공된다.
언어/문법 패턴
7. 접속사/전환어 남용
감지 표현: "또한", "더불어", "나아가", "아울러", "한편", "이에 따라", "이를 통해", "이러한 맥락에서", "이와 같이"
문제: 거의 모든 문장 앞에 접속사를 기계적으로 붙인다.
Before:
이 도구는 코드 분석을 지원합니다. 또한 자동 리팩토링 기능도 제공합니다. 더불어 팀 협업을 위한 기능도 갖추고 있습니다. 나아가 CI/CD 파이프라인과의 연동도 가능합니다. 아울러 보안 취약점 스캔도 포함되어
있습니다.
After:
이 도구는 코드 분석, 자동 리팩토링, 팀 협업을 지원한다. CI/CD 연동과 보안 취약점 스캔도 된다.
8. 피동 표현 남용
감지 표현: "~되어지다", "~되어진", "~되어지고 있다", "~가 진행되고 있습니다", "~가 이루어지고 있습니다", "~가 수행되었습니다"
문제: 이중 피동이나 불필요한 피동형을 과도하게 사용한다.
Before:
데이터가 수집되어진 후, 분석이 수행되었습니다. 이를 통해 패턴이 발견되어졌으며, 개선 방안이 도출되어졌습니다.
After:
데이터를 수집해서 분석했다. 패턴을 발견했고, 개선 방안을 정리했다.
9. 과도한 존대/격식체
감지 표현: 모든 문장이 "~하였습니다", "~되었습니다", "~하겠습니다"로 끝나는 패턴
문제: 기술 문서나 블로그에서 불필요하게 격식체를 반복한다. 톤이 단조로워진다.
단, 공지문, 고객 응대, 보고서 등 존댓말이 필요한 맥락에서는 격식체를 유지해야 한다.
이 패턴은 반복적이고 단조로운 어미만 대상으로 한다.
Before:
함수를 작성하였습니다. 테스트를 실행하였습니다. 결과를 확인하였습니다. 문제가 없는 것을 확인하였습니다.
After:
함수를 작성하고 테스트를 돌렸다. 문제없이 통과했다.
10. ~라고 할 수 있습니다 (회피형 서술)
감지 표현: "~라고 할 수 있습니다", "~라고 볼 수 있습니다", "~라고 판단됩니다", "~것으로 보입니다", "~것으로 사료됩니다"
문제: 직접 서술을 피하고 우회적으로 표현한다.
Before:
React는 현재 가장 널리 사용되는 프론트엔드 라이브러리라고 할 수 있습니다. 이는 컴포넌트 기반 아키텍처가 개발 효율성을 높여주기 때문이라고 볼 수 있습니다.
After:
React는 현재 가장 많이 쓰이는 프론트엔드 라이브러리다. 컴포넌트 단위로 쪼개서 개발할 수 있어서 재사용이 쉽다.
11. 3의 법칙 남용
문제: 무조건 3개씩 나열하려는 습관.
Before:
이 접근법의 핵심 가치는 확장성, 유연성, 그리고 안정성입니다. 개발자에게 효율성, 생산성, 그리고 창의성을 제공합니다.
After:
이 접근법은 확장이 쉽고 안정적이다.
12. 부정 병렬 구문 남용
감지 표현: "~뿐만 아니라 ~도", "단순히 ~가 아니라 ~입니다", "~에 그치지 않고"
문제: 강조를 위해 부정-긍정 대비 구문을 과도하게 사용한다.
Before:
이 도구는 단순히 코드를 분석하는 것에 그치지 않고, 자동으로 수정 방안까지 제시합니다. 버그를 찾는 것뿐만 아니라 성능 최적화 포인트도 알려줍니다.
After:
이 도구는 코드를 분석하고 수정 방안을 제시한다. 버그와 성능 최적화 포인트를 함께 알려준다.
스타일 패턴
13. 이모지 + 굵은 제목 목록
문제: 모든 목록 항목에 이모지와 볼드 헤더를 기계적으로 붙인다.
Before:
- 🚀 성능 개선: 응답 속도가 50% 향상되었습니다
- 💡 새로운 기능: 실시간 알림 기능이 추가되었습니다
- ✅ 안정성: 오류 발생률이 80% 감소하였습니다
After:
응답 속도가 50% 빨라졌고, 실시간 알림 기능을 추가했다. 오류 발생률은 80% 줄었다.
14. 과도한 볼드체
문제: 핵심 키워드마다 기계적으로 볼드 처리한다.
Before:
마이크로서비스 아키텍처는 독립적인 배포가 가능한 작은 서비스 단위로 애플리케이션을 분리하는 설계 방식입니다.
After:
마이크로서비스 아키텍처는 애플리케이션을 독립 배포 가능한 작은 서비스로 분리하는 설계 방식이다.
15. 번호 매기기/구분선 남용
문제: 간단한 내용도 번호를 매기고 구분선을 넣어 과도하게 구조화한다.
단, 설치 가이드나 트러블슈팅처럼 순서가 중요한 절차적 목록은 구조를 보존해야 한다.
이 패턴은 장식적 구분선과 불필요한 포맷팅만 대상으로 한다.
Before:
설정 방법은 다음과 같습니다:
1단계: 설정 파일을 엽니다
2단계: API 키를 입력합니다
3단계: 저장 버튼을 클릭합니다
After:
설정 파일을 열고 API 키를 입력한 뒤 저장하면 된다.
16. 동의어 순환
문제: 같은 대상을 문장마다 다른 단어로 바꿔 부른다.
Before:
TypeScript는 강력한 타입 시스템을 제공합니다. 이 프로그래밍 언어는 대규모 프로젝트에 적합합니다. 해당 도구는 JavaScript의 상위 집합입니다. 이 기술 스택은 많은 기업에서 채택하고 있습니다.
After:
TypeScript는 JavaScript에 타입 시스템을 추가한 언어로, 대규모 프로젝트에서 타입 안전성이 필요할 때 쓴다.
소통 패턴
17. 챗봇 흔적
감지 표현: "도움이 되셨기를 바랍니다", "궁금한 점이 있으시면 언제든지 질문해주세요", "추가적인 설명이 필요하시면 말씀해주세요", "다음은 ~에 대한 설명입니다"
Before:
다음은 Docker에 대한 설명입니다. Docker는 컨테이너 기반의 가상화 플랫폼입니다. 도움이 되셨기를 바랍니다! 궁금한 점이 있으시면 언제든지 질문해주세요.
After:
Docker는 컨테이너 기반 가상화 플랫폼이다. 애플리케이션과 의존성을 하나의 이미지로 묶어서 어디서든 동일하게 실행할 수 있다.
18. 아첨조
감지 표현: "좋은 질문입니다!", "정확하게 이해하고 계시네요!", "탁월한 지적입니다!", "아주 중요한 포인트를 짚어주셨습니다"
Before:
좋은 질문입니다! 정확하게 핵심을 짚어주셨네요. 이 부분은 정말 중요한 포인트입니다.
After:
경제적 요인이 여기서 관련이 있다.
19. 과도한 완곡/헤징
감지 표현: "~일 수도 있습니다", "~가능성이 있습니다", "어쩌면 ~일지도 모릅니다", "~않을까 싶습니다", "조심스럽게 ~라고 말씀드릴 수 있을 것 같습니다"
Before:
이 방법이 효과적일 수도 있다고 조심스럽게 말씀드릴 수 있을 것 같습니다. 어쩌면 성능 개선에 도움이 될 가능성이 있지 않을까 싶습니다.
After:
이 방법이 효과적일 수 있다. 벤치마크를 돌려봐야 확실하다.
20. 군더더기 구문
Before -> After:
- "~하는 것이 중요합니다" -> "~해야 한다" 또는 삭제
- "~할 필요가 있습니다" -> "~해야 한다"
- "~하는 것이 좋습니다" -> "~하자" 또는 "~해라"
- "~라는 점에서" -> 삭제하고 직접 서술
- "~에 대해서 말씀드리자면" -> 삭제하고 바로 시작
- "~와 관련하여" -> 삭제하거나 "~에서"
- "이와 같은 맥락에서 볼 때" -> 삭제
프로세스
- 입력 텍스트를 읽는다
- 위 패턴에 해당하는 부분을 모두 찾는다
- 문제 구간을 재작성한다
- 재작성된 텍스트가 다음을 만족하는지 확인한다:
- 소리 내어 읽었을 때 자연스러운가
- 문장 길이와 구조가 다양한가
- 모호한 주장 대신 구체적 사실을 쓰고 있는가
- 원문의 톤에 맞는가
- 불필요한 격식체나 피동형이 없는가
- 초안을 작성한다
- "이 글에서 AI 냄새가 나는 부분은?" 자체 감사
- 남은 패턴을 간단히 정리한다 (있다면)
- "AI 냄새를 빼라" 최종 수정
- 최종본을 제시한다
출력 형식
- 초안 (Draft)
- "이 글에서 AI 냄새가 나는 부분은?" (bullet points)
- 최종본 (Final)
- 변경 요약 (선택, 도움이 된다면)
