2026년 blader Humanizer: v3.1의 변경 사항과 사용 방법

저는 채팅창에서 시작된 초안들을 많이 편집합니다. 저의 것도 있고, 클라이언트에게서 온 것도 있으며, 점점 더 많은 비중이 도구들에서 나옵니다. 올해 대부분 동안 제가 게시물을 올리기 전에 실행하는 마지막 것은 GitHub의 blader/humanizer에 있는 오픈 소스 에이전트 스킬인 blader humanizer였습니다. 만약 누군가 스레드에서 '그냥 humanizer로 돌려봐'라고 말해서 검색하셨다면, 제가 갖고 싶었던 글입니다. 이것이 무엇인지, 가장 초창기 버전들이 설명하는 것과 비교하여 무엇이 변경되었는지, 그리고 제가 실제로 이를 출판 루틴에 어떻게 통합하는지에 대한 내용입니다.

나머지 내용을 이해하기 위한 제 설정에 대한 간단한 메모를 먼저 드립니다. 한 작은 클라이언트 사이트의 경우, 키워드 선택 및 초안은 구매자들이 입력하는 검색어를 찾아 각 검색어에 대해 기사를 작성해 주는 SupaTraffic를 통해 나옵니다. 저의 개인적인 게시물의 경우, 제가 직접 첫 번째 초안을 작성합니다. 어느 쪽이든 humanizer는 제가 소리 내어 읽기 바로 직전에 초안을 받게 됩니다.

blader humanizer가 실제로 무엇인지

이것은 스킬 파일입니다. 해당 저장소는 자신을 '텍스트에서 AI 생성 글의 흔적을 제거하는 에이전트 스킬'이라고 설명하며, 핵심은 코딩 에이전트가 로드하는 단일 SKILL.md 파일입니다. 웹 UI나 API 키, 또는 그 뒤에 있는 서비스는 없습니다. 이미 사용하고 있는 어떤 에이전트(Claude Code, Codex, Claude Desktop 등) 안에서 실행됩니다. 이 저장소는 또한 Cursor 플러그인 매니페스트도 제공합니다.

패턴 목록은 Wikipedia의 'AI 글쓰기의 흔적' 페이지를 기반으로 하는데, 이는 위키피디아 편집자들이 기계가 작성한 기사를 정리할 때 사용하는 가이드입니다. 따라서 규칙들은 전문적으로 AI 텍스트를 검토하는 사람들로부터 나오며, 3.0 버전에서는 이 페이지의 현재 버전에 맞춰 목록을 재조정했습니다.

README에는 사람들이 혼동하는 한 가지에 대해 명확하게 설명되어 있습니다. 바로 AI 탐지기를 우회하는 것이 목표가 아니며, 이 도구는 여전히 출력물의 대부분을 탐지한다는 것입니다. 이 도구는 사람 독자를 위해 편집합니다. 만약 에세이를 분류기(classifier)를 통과시키려는 계획이라면, 이것은 잘못된 도구이며 저자는 이를 초반부터 명시하고 있습니다.

제가 의존하는 또 다른 규칙은 사실을 지어내지 않는다는 것입니다. 이름, 숫자, 날짜, 인용문 또는 출처 표기는 반드시 원본 텍스트나 사용자로부터 나와야 합니다. 문장에 필요한 세부 정보가 없을 경우, 이 도구는 임의로 만들어내기보다 질문하도록 안내받습니다. 클라이언트 작업에 있어서 그 규칙 하나 때문에 저는 초안을 맡길 때 신뢰할 수 있습니다.

dev.to에서 찾을 수 있는 게시물 대비 변경된 사항

현재 blader humanizer 순위가 높은 dev.to 기사는 2026년 2월에 작성되었으며, 당시 저장소(repo)는 약 6,600개의 스타를 보유하고 있었고 24가지 패턴을 확인했습니다. 이번 주 기준으로 이 수치는 54.4k 스타와 4.3k 포크로 올라갔으며, 최신 버전은 2026년 9월 28일의 v3.1.0입니다. 변경 로그를 읽었을 때 놀라웠던 점은 패턴 수가 증가했다가 다시 감소했다는 것입니다.

3.0 리라이트는 흥미롭습니다. 단어 금지 목록이 늘어나는 대신, 이 도구는 하나의 아이디어에서 시작합니다. 즉, 언어 모델(language model)은 가장 광범위한 독자층에 맞는 선택을 고르는 반면, 사람은 한 명의 독자와 한 가지 주제를 위해 선택하는 것입니다. 모든 패턴은 이러한 기본 선택 형태로 취급됩니다. 이 패턴들은 강도별로 번호가 매겨져 있으며, 처음 다섯 가지는 단일 발견에 대한 편집을 정당화합니다:

1. X가 아니라 Y (

일부 패턴은 '약함(weak alone)'으로 표시되며 여러 텔(tells)이 한 구절을 공유할 때만 카운트됩니다. 대시(dashes), 중첩된 수식어(stacked qualifiers), 하이픈 연결 쌍(hyphenated pairs), 수동태(passive voice), 그리고 곡선 따옴표(curly quotes)가 이 그룹에 속합니다. 왜냐하면 세심한 작가는 이들 중 무엇이든 의도적으로 사용할 수 있기 때문입니다. 실제로, 깔끔한 단락의 대시 하나는 그대로 유지되는 반면, 대시, 완화 표현(hedges), 그리고 수동 구문으로 쌓인 단락은 다시 작성됩니다.

README에는 또한 심사위원들이 인간화 도구(humanizer)가 재작성한 텍스트를 원본 AI 텍스트보다 16번 중 16번 선호했다는 블라인드 테스트 결과도 언급되어 있습니다(리포지토리의 issue #229). 저는 직접 그런 것을 실행해 본 적이 없으니, 이는 유지 관리자의 주장으로 받아들여 주십시오.

설치 방법

설치한 후, 이 기능은 /humanizer에 응답합니다. 다음은 현재 README에 있는 명령어들입니다:

Claude Code 2.1.142 이상 버전 내에서는 플러그인 경로가 슬래시 명령어 두 개이며, 플러그인은 /humanizer:humanizer에 응답합니다:

/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer

나머지 모든 것은 터미널의 Skills CLI를 통해 진행됩니다:

# 구 버전 Claude Code의 경우
npx skills add blader/humanizer --global --agent claude-code

...

현재 프로젝트에만 설치하려면 --global을 생략하십시오. Claude.ai 또는 Claude Desktop의 경우, 리포지토리를 ZIP으로 다운로드하여 설정(Settings)에서 스킬로 업로드하십시오. Skills CLI가 인식하지 못하는 에이전트의 경우, SKILL.md 파일을 해당 에이전트의 스킬 폴더에 복사하십시오.

제가 일상적으로 사용하는 방법

저는 세 가지 모드를 모두 사용합니다.

붙여넣은 텍스트(Pasted text). 저는 /humanizer를 호출하고 구절을 붙여넣습니다. 그러면 첫 번째 재작성본, 여전히 인공적인 느낌이 드는 부분에 대한 간략한 비평, 그리고 최종 버전이 반환됩니다. 저는 재작성본보다 비평을 더 주의 깊게 읽는데, 왜냐하면 그것이 어떤 습관들이 계속 나타나는지를 보여주기 때문입니다.

파일 모드(File mode). 저는 이 기능을 파일에 지정합니다: Humanize the prose in drafts/launch-post.md. 이 모드에서는 최종 텍스트만 파일에 다시 작성하고 산문만 변경합니다. 코드 블록, 인라인 코드, 명령어, 경로, 프론트 매터(front matter), 링크 대상은 건드리지 않습니다. 코드로 가득 찬 dev.to 초안의 경우, 제가 가장 많이 사용하는 모드가 바로 이것입니다.

음성 일치(Voice matching). 이 기능이 사람들이 놓치는 부분입니다. 사용자 본인의 글 두세 단락을 먼저 제공할 수 있습니다:

/humanizer

여기에 음성 일치를 위한 제 글 샘플이 있습니다:
...

샘플은 대시 규칙(dash rule)을 포함하여 패턴 규칙을 무효화합니다. 만약 사용자 샘플에 대시가 사용되었다면, 재작성본도 비슷한 비율로 유지합니다. 샘플 없이 사용할 경우, 텍스트 유형에서 음성을 가져옵니다: 블로그 게시물은 의견과 여담(asides)을 유지하는 반면, 참고 자료 및 기술적 산문은 중립적으로 유지됩니다.

Blader humanizer vs. 자체 구축

현재 이 주제로 순위가 높은 dev.to 게시물에서는 사용자가 직접 발행한 글의 코퍼스에 맞춰 보정된(calibrated) 자신만의 휴머니저를 구축해야 한다고 주장합니다. 그 이유는 일반적인 도구가 일반적인 기준선(generic baseline)을 확인하기 때문에 여전히 목소리가 없는 산문으로 남길 수 있기 때문입니다. 이는 타당한 지적이며, 해당 작성자의 프로젝트(blader의 패턴 목록을 기반으로 구축된 voice-humanizer)는 이에 대한 합리적인 답변이 됩니다.

부족한 점

이 도구는 평범한 초안을 좋게 만들 수는 없습니다. 원본에 구체적인 내용이 없다면, '발명하지 않는 규칙(no-invention rule)' 때문에 재작성본 역시 아무것도 없고, 결국 같은 빈 게시물의 더 짧고 평이한 버전만 얻게 됩니다. 빠진 세부 정보가 요청되면 답변하세요. 거기서 개선이 나옵니다.

패턴 26은 독자가 이미 알고 있는 것을 다시 설명하는 것이며, 답글에만 적용되므로 이것이 장문의 글을 결정 중심으로 재구성할 것이라고 기대해서는 안 됩니다.

전체 패턴 목록은 repo README에 있으며, 각 항목마다 전(before)과 후(after)가 있는 여섯 개의 섹션으로 그룹화되어 있습니다. 아무것도 설치하지 않을 것이라고 해도 한 번 읽어볼 가치가 있습니다.

FAQ

blader humanizer는 무료인가요?
네. MIT 라이선스를 따르며, 이미 비용을 지불하거나 사용하고 있는 에이전트 내부에서 실행됩니다. 별도의 구독은 없습니다.

blader humanizer가 GPTZero나 Turnitin 같은 AI 탐지기를 우회하나요?
README에 따르면 탐지기를 통과하는 것이 목표는 아니며, 여전히 대부분의 출력물이 탐지되는 것으로 나와 있습니다. 독자들에게 텍스트를 더 좋게 만드는 데 사용하세요.

blader humanizer를 v3.1.0으로 업데이트하려면 어떻게 해야 하나요?
이전에 사용했던 것과 동일한 명령어로 재설치하면 됩니다. 예를 들어 npx skills add blader/humanizer --global --agent codex와 같습니다. 버전은 SKILL.md의 metadata.version 필드에 명시되어 있습니다.

Claude Code 외부에서도 작동하나요?
네. README에는 Codex, Claude.ai 및 Claude Desktop(ZIP 업로드)과 Skills CLI가 지원하는 모든 에이전트(Gemini CLI, GitHub Copilot, Windsurf 포함)가 다루어져 있습니다. 레포지토리에는 Cursor 플러그인 매니페스트도 있습니다.

마무리 생각

Humanizer는 보수적이기 때문에 제 루틴의 마지막 단계로 자리를 잡았습니다. 사실은 유지하고, 코드는 건드리지 않으며, 자신이 가지고 있지 않은 것이 필요할 때 알려주기 때문입니다. 연구와 초안 작성은 더 이전에 이루어지며, 클라이언트 사이트의 경우 그 부분이 SupaTraffic를 통해 진행됩니다. 이를 통해 실제 검색 쿼리와 연결된 초안 일정을 얻게 되어, 무언가를 게시하기 전에 검토하고 편집할 수 있습니다. 그런 다음 초안은 humanizer를 거치고, 제가 소리 내어 읽은 후, 게시합니다.