안녕하세요? 정리하는 개발자 워니즈입니다.
AI에게 한국어 초안을 받아서 나름대로 손을 봤는데도 어딘가 기계 냄새가 남아 있다는 느낌을 받아보신 적 있으신가요? 맞춤법도 멀쩡하고 문장도 다 말이 되는데, 소리 내어 읽어보면 사람이 쓴 글 같지가 않은 그 상태 말입니다.
이번 시간에는 그 냄새를 잡아준다는 한국어 전용 도구인 humanizer를 실제로 설치해서 돌려보고 같은 내용을 AI 문체와 사람 문체로 각각 써서 점수가 얼마나 벌어지는지 재본 기록을 정리해보려고 합니다. 판정 기준이 어디서 나온 숫자인지부터 이 도구가 무엇을 잡고 무엇은 끝내 못 잡는지까지 같이 적어두었습니다.
【한 줄 요약】 humanizer는 쉼표 비율과 번역투를 포함한 40개 패턴으로 한국어 AI 문체를 잡아내는 Claude Code 스킬입니다. 같은 내용을 두 문체로 써서 검사기에 넣어보니 58점과 100점으로 42점이 벌어졌는데요, 다만 총점이 100점이어도 쉼표 비율은 여전히 AI 쪽에 가까웠고 아예 처음부터 다시 쓰면 변경률이 94%까지 올라가서 윤문이 아니라 재작성이 되어버립니다.
먼저 이 글에서 확인한 것 세 가지만 추려두겠습니다.
- 같은 내용을 AI 문체와 사람 문체로 각각 써서 검사기에 넣으니 58점과 100점으로 갈렸습니다
- 그런데 100점을 받은 쪽도 쉼표 비율은 50%로, 사람 기준선인 26%의 두 배였습니다
- 두 표본은 어절 기준으로 94%가 다른 글이었고, 이 정도면 윤문이 아니라 재작성입니다
목차
- humanizer는 어떤 도구인가요?
- 같이 쓰는 스킬 세 개와 실행 순서
- 설치부터 첫 실행까지
- 한국어 글에서 실제로 걸리는 패턴들
- 직접 확인 1: 같은 내용, 두 문체, 42점 차이
- 검사기 점수가 100점이면 안심해도 될까요?
- 직접 확인 2: 재현성은 확인하지 못했습니다
- 안 되는 것, 윤문이 재작성으로 넘어가는 지점
- 누구에게 맞고 누구에게는 안 맞나
1. humanizer는 어떤 도구인가요?
humanizer는 AI가 생성한 한국어 텍스트에서 기계적인 흔적을 찾아내고 자연스러운 문장으로 고쳐주는 Claude Code 스킬입니다. 만든 사람은 DaleSeo이고, DaleSeo/korean-skills 저장소에서 MIT 라이선스로 공개되어 있어서 누구나 그대로 가져다 쓰실 수 있습니다. 필자가 확인한 시점 기준 스킬 버전은 1.6.0이었습니다.
이 도구가 다른 윤문 도구와 갈리는 지점은 판정 근거를 언어학 논문에 두고 있다는 것인데요, 스킬 문서에 KatFishNet 논문(ArXiv 2503.00032v4)이 출처로 명시되어 있고 패턴마다 판별 정확도가 숫자로 붙어 있습니다. 감으로 “이건 AI 같다”고 말하는 게 아니라 어떤 축이 얼마나 잘 갈라내는지를 먼저 밝히고 들어가는 구조라서 필자는 이 부분이 제일 마음에 들었습니다.
스킬 문서에 적힌 판별 정확도 중에 가장 높은 축은 뜻밖에도 쉼표였습니다. 사람이 쓴 한국어 문장 중에 쉼표가 들어간 문장은 26% 정도인데, LLM이 쓰면 61%까지 올라가고 이 축 하나만으로 94.88% AUC가 나온다고 되어 있습니다. 우리가 AI 글을 읽으면서 뭔가 이상하다고 느낄 때 실제로 눈에 걸리는 게 어휘가 아니라 문장부호였다는 얘기가 되는 셈입니다.
| 카테고리 | 패턴 수 | 문서에 적힌 판별력 | 대표 항목 |
|---|---|---|---|
| 문장부호 | 7 | 94.88% AUC | 쉼표 과다, 영어식 배치, 연결어미 뒤 쉼표 |
| 품사 다양성 | 3 | 82.99% AUC | 명사 과다, 동사와 형용사 빈곤 |
| 띄어쓰기 | 3 | 79.51% AUC | 의존명사 띄어쓰기가 지나치게 일정함 |
| 번역투 | 13 | 경험적 | 에 대해, 통해, 되어진다, 에 있어서 |
| 어휘 | 10 | 중간 | AI 유행어, 복수형 남용, 대명사 과다 |
| 구조 | 4 | 중간 | 문장 리듬 단조로움, 3박자 나열, 접속사 과다 |
패턴은 심각도로도 나뉘는데요, S1은 한 번만 나와도 결정적인 신호라서 무조건 고치라는 것이고 S2는 한두 번은 넘어가지만 세 번을 넘으면 걸리는 빈도 기준이며 S3는 단독으로는 약하지만 다른 패턴과 겹칠 때만 판정에 들어가는 축입니다. 이 세 단계 구분이 있어서 문장 하나에 꽂혀 글 전체를 뜯어고치는 사고를 막아준다는 점이 실제로 돌려보니 체감이 됐습니다.
2. 같이 쓰는 스킬 세 개와 실행 순서
humanizer는 혼자 쓰는 도구가 아니라 같은 저장소에 들어 있는 세 스킬 중 하나입니다. 나머지 둘은 grammar-checker와 style-guide인데, 셋이 보는 층위가 서로 완전히 다릅니다. 필자는 처음에 이걸 모르고 humanizer만 돌린 다음 다 됐다고 생각했다가 존댓말과 평어체가 한 글 안에서 섞여 있는 걸 한참 뒤에야 발견했습니다.
| 스킬 | 보는 것 | 안 보는 것 | 언제 쓰나 |
|---|---|---|---|
| humanizer | AI 문체 흔적 40패턴 | 맞춤법, 용어 통일 | AI 초안을 사람 글로 바꿀 때 |
| grammar-checker | 맞춤법, 띄어쓰기, 조사, 구두점 | 문체가 AI 같은지 | 문장 자체가 틀렸는지 볼 때 |
| style-guide | 어조와 용어와 형식의 일관성 | 개별 문장의 옳고 그름 | 글 여러 개를 같은 톤으로 맞출 때 |
순서는 humanizer를 먼저 돌리고 그다음에 grammar-checker와 style-guide로 가는 게 맞습니다. 이유는 단순한데요, humanizer가 문장 구조를 제법 크게 바꾸기 때문에 맞춤법을 먼저 잡아봐야 그 문장이 통째로 사라지면 헛수고가 되기 때문입니다. 뒤에 오는 두 검사기는 humanizer가 내놓은 결과물을 입력으로 받는다고 생각하시면 편합니다.
다만 게시 규격이 따로 정해진 글이라면 style-guide의 제안보다 그 규격을 위에 두셔야 합니다. 예를 들어 필자처럼 제목 형식이나 종결어미를 미리 못 박아둔 경우에는, 검사기가 통일하자고 제안하더라도 원래 규격이 이깁니다. 검사기는 문서 안에서의 일관성만 볼 뿐이지 그 문서가 어디에 올라가서 어떤 규칙을 통과해야 하는지는 알지 못하거든요.
그리고 세 스킬 모두 결과를 자동으로 파일에 덮어쓰지는 않습니다. 고친 버전을 보여주고 반영 여부는 사람이 정하도록 두었는데, 이게 답답해 보여도 실은 안전장치입니다. 뒤에서 다시 말씀드리겠지만 이런 도구는 잘 안 잡혀서가 아니라 지나치게 잘 잡혀서 글을 망가뜨리는 쪽이 훨씬 흔합니다.
3. 설치부터 첫 실행까지
설치는 플러그인 마켓플레이스를 등록하고 플러그인을 넣는 두 줄이면 끝납니다. Claude Code 안에서 슬래시 명령으로 그대로 실행하시면 됩니다.
/plugin marketplace add DaleSeo/korean-skills
/plugin install korean-skills@korean-skills설치하고 나면 스킬 세 개가 한꺼번에 들어옵니다. 호출할 때 명령어를 따로 외우실 필요는 없고 “이 글 AI 티 좀 빼줘”처럼 자연어로 부탁하시면 되는데요, 스킬 설명에 트리거 문구가 넉넉하게 적혀 있어서 윤문이나 맞춤법이나 문체라는 말만 들어가도 알아서 붙습니다. 마크다운 파일 경로를 같이 주면 그 파일을 읽어서 분석하기 때문에 긴 글은 통째로 넘기시는 편이 낫습니다.
한 번에 얼마나 넣을지도 결과에 영향을 줍니다. 스킬 문서에 한두 문장짜리 짧은 입력은 패턴을 잡아내기에 표본이 모자라다고 아예 못 박아 두었는데요, 실제로 짧은 문단을 넣으면 판정을 보류한다는 답이 돌아옵니다. 필자는 최소한 문단 서너 개 분량은 넣어야 쓸 만한 리포트가 나오는 것 같다고 느꼈습니다.
출력은 감지된 패턴 목록과 자연스럽게 고친 버전과 주요 변경 사항 요약이라는 세 덩어리로 나옵니다. 여기서 제일 먼저 눈여겨보실 것은 맨 위에 붙는 자연도 등급인데요, S1이 하나도 없고 S2가 둘 이하면 A가 붙고 S1이 셋 이상이거나 S2가 여섯 이상이면 C로 떨어집니다. 등급이 C나 D로 나왔다면 한 번 더 돌리라는 뜻으로 읽으시면 됩니다.
4. 한국어 글에서 실제로 걸리는 패턴들
패턴이 40개라고 하면 많아 보이는데, 필자가 실제로 한국어 초안을 여러 개 넣어보니 반복해서 걸리는 것들은 몇 가지로 좁혀졌습니다. 영어권 도구에서 흔히 말하는 금지 어휘 목록은 한국어 글에서 거의 쓸모가 없었고 대신 번역투 축이 훨씬 자주 잡혔습니다.
가장 자주 나오는 것은 조사 번역투입니다. “~를 통해”와 “~에 대해”와 “~에 있어서” 세 가지인데, 이게 한 문단에 두 번 이상 나오면 신호로 잡힙니다. 한국어에서는 “~로”나 “~으로”를 쓰거나 아예 동사를 직접 붙이는 쪽이 자연스러운데 번역기를 거친 문장 습관이 그대로 남아서 이 형태가 자꾸 되살아납니다.
두 번째는 피동을 겹쳐 쓰는 버릇입니다. “되어진다”와 “지게 된다” 같은 표현은 이미 피동인 말에 피동을 한 번 더 붙인 것이라 한 번만 나와도 걸리는 S1 항목인데요, 글쓴이가 단정을 피하려다 보면 자기도 모르게 손이 그쪽으로 갑니다.
세 번째는 판단을 흐리는 어미입니다. “~할 수 있을 것으로 보인다”나 “~할 필요가 있다” 같은 표현이 여기 들어가는데, 문장은 정중해 보이지만 정작 누가 무엇을 판단했는지가 사라집니다. 같은 계열로 “전문가들은”이나 “업계에 따르면”처럼 출처를 뭉개는 표현도 별도 항목으로 잡히는데 이건 문체 문제가 아니라 사실 확인 문제에 가깝습니다.
네 번째는 한국어에 원래 없던 문법이 끼어드는 경우입니다. 복수형 “-들”을 영어처럼 꼬박꼬박 붙이거나 “그”와 “그녀” 같은 대명사를 문장마다 넣는 습관이 대표적인데요, 한국어는 문맥으로 주어를 생략하는 언어라서 이걸 다 살려두면 번역문처럼 읽힙니다.
아래는 필자가 만든 나쁜 표본의 첫 문단입니다. 위에 적은 것들이 한 문단 안에서 어떻게 겹쳐 나오는지 보시면 감이 잡히실 겁니다.
AI 도구를 통해 개인 블로그를 운영하는 것은 매우 다양한 이점을 가지고 있습니다. 글쓰기에 있어서 가장 중요한 것은 꾸준함인데, 자동화를 통해 이 문제가 상당히 해결되어질 수 있습니다. 전문가들은 이러한 흐름이 앞으로도 지속될 것으로 보인다고 말합니다.
같은 내용을 필자가 평소 쓰는 말투로 다시 쓰면 이렇게 됩니다.
블로그를 몇 년째 붙잡고 있으면서 제일 어려웠던 건 글솜씨가 아니라 그냥 매일 쓰는 일이었는데요, 그래서 초안을 대신 뽑아주는 장치를 하나 붙여봤습니다. 처음에는 시간만 아끼면 되겠거니 했는데 막상 돌려보니 엉뚱한 문제가 튀어나오더군요.
두 문단이 담고 있는 사실은 같습니다. 다른 것은 누가 무엇을 했는지가 문장에 남아 있느냐뿐인데요, 아래 문단에는 “제일 어려웠던 건”과 “붙여봤습니다”와 “튀어나오더군요”처럼 화자의 위치가 계속 드러나 있고 위 문단에는 그게 전부 지워져 있습니다. AI 문체가 어색하게 느껴지는 진짜 이유는 어휘가 어려워서가 아니라 말하는 사람이 문장 안에 없기 때문이라는 게 필자 생각입니다.
5. 직접 확인 1: 같은 내용, 두 문체, 42점 차이
여기서부터가 실제로 재본 부분입니다. 스킬은 결과를 문장으로 설명해주기 때문에 좋아졌다는 건 알겠는데 얼마나 좋아졌는지가 기록으로 남지 않습니다. 그래서 필자는 블로그 발행 전에 돌리는 검사 스크립트를 하나 따로 붙여두고 있는데요, 정규식과 세기만으로 0점에서 100점을 매기는 결정적인 방식이라 같은 파일을 몇 번을 넣어도 똑같은 숫자가 나옵니다.
이 스크립트가 쓰는 패턴과 임계값은 공개된 저장소 세 곳에서 가져왔습니다. patina는 한국어 패턴별로 몇 번 나오면 걸리는지를 문서에 적어두었고, im-not-ai는 한국어 AI 문체를 10개 범주로 나눠 정리해두었으며 avoid-ai-writing은 점수 매기는 엔진을 하나만 두라는 설계 원칙을 제시합니다. 셋 다 MIT 라이선스라서 규칙을 그대로 가져다 쓰셔도 됩니다.
앞 절에서 보신 두 표본을 각각 파일로 만들어 넣었습니다. 명령은 파일 이름만 바꿔가며 두 번 돌린 게 전부입니다.
python3 style-check.py sample-ai.md
python3 style-check.py sample-human.md결과가 예상보다 훨씬 크게 갈렸습니다.
| 항목 | AI 문체 표본 | 사람 문체 표본 |
|---|---|---|
| 총점 | 58점 | 100점 |
| 등급 | D | A |
| 감점 합계 | 42.0 | 0.0 |
| S1 감점 항목 | 5개 | 없음 |
| S2 감점 항목 | 5개 | 없음 |
| 같은 문단 중첩 판정 | 두 문단에서 9종과 11종 | 없음 |
감점 내역을 뜯어보면 어디서 점수가 빠졌는지가 아주 분명합니다. “~를 통해”가 문단당 두 번을 넘어서 5점이 빠졌고, “~다는 점”이 반복돼서 4점이 빠졌으며 “전문가들은”에서 3.5점과 “것으로 보인다”에서 3점과 “필요가 있습니다”에서 2.5점이 각각 빠졌습니다. 여기까지가 S1이고 다 합치면 18점입니다.
S2에서는 AI 유행어가 문단당 셋을 넘어서 4.5점이 빠졌고, “첫째 둘째 셋째”라는 기계적인 열거로 다시 4.5점이 빠졌으며 “결론적으로”와 “시사하는 바”가 겹쳐서 4점 그리고 강조 부사 남발로 3점과 “보다 ~한” 형태로 2점이 빠졌습니다. 여기에 같은 문단 안에 여러 패턴이 동시에 겹쳐 있다는 이유로 6점이 추가로 깎여서 최종 42점이 됐습니다.
마지막 6점이 사실 제일 눈여겨볼 대목인데요, 이건 개별 패턴이 아니라 겹침 자체를 보는 축입니다. 쉼표 하나나 접속사 하나만 가지고는 AI라고 단정할 수 없지만 한 문단 안에 열 가지가 동시에 나오면 그건 자백에 가깝다는 발상이고 이 설계는 humanizer 계열 도구들이 공통으로 강조하는 원칙이기도 합니다. 그래서 걸린 패턴을 하나씩 붙잡고 고치는 것보다 걸린 문단을 통째로 다시 읽는 쪽이 점수를 올리는 데 훨씬 빨랐습니다.
6. 검사기 점수가 100점이면 안심해도 될까요?
아닙니다. 필자가 이번에 제일 크게 데인 부분이 바로 여기인데요, 사람 문체 표본은 100점 만점을 받았는데도 정작 humanizer가 가장 중요하다고 말하는 쉼표 축에서는 여전히 AI 쪽에 가까웠습니다. 두 도구가 서로 다른 것을 보고 있기 때문에 한쪽 점수만 믿으면 통째로 놓치는 구간이 생깁니다.
쉼표가 들어간 문장의 비율을 세 표본에서 각각 세어봤습니다. humanizer 문서가 제시한 기준선은 사람이 26%이고, AI가 61%입니다.
| 표본 | 문장 수 | 쉼표 포함 문장 | 비율 | 검사 스크립트 총점 |
|---|---|---|---|---|
| AI 문체 | 11 | 8 | 73% | 58점 |
| 사람 문체 | 8 | 4 | 50% | 100점 |
| 사람 문체에서 쉼표만 정리 | 10 | 0 | 0% | 100점 |
세 번째 줄이 문제입니다. 쉼표를 50%에서 0%로 완전히 바꿨는데도 점수는 100점 그대로였는데요, 반대로 말하면 이 스크립트는 쉼표를 아예 감점 축에 넣지 않았다는 뜻이 됩니다. 실제로 패턴 표를 다시 열어보니 번역투와 어휘와 구조 항목은 있어도 쉼표를 세는 규칙은 한 줄도 없었습니다.
이게 왜 생기는가 하면 총점 하나로 품질을 요약하는 게이트에서는 판별력이 좋은 축이 판별력 없는 축들과 평균되면서 신호가 죽어버리기 때문입니다. 점수가 만점에 몰린다면 그건 글이 좋아서가 아니라 그 점수가 볼 줄 아는 게 그것뿐이라는 신호일 수 있습니다. 필자도 예전에 검사기 점수만 믿고 넘어갔다가 비슷하게 당한 적이 있는데 그때 정리한 내용은 코드 리뷰가 못 따라갈 때 검사기 3가지 함정에 적어두었습니다.
그러니까 실무에서는 이렇게 쓰시는 편이 안전합니다. 먼저 결정적인 스크립트로 번역투나 관용구처럼 세기 쉬운 것들을 걸러내고, 그다음에 humanizer로 쉼표나 리듬처럼 세기 어려운 축을 따로 보시면 됩니다. 마지막으로 소리 내어 한 번 읽어보시는 게 남는데 이 세 번째가 빠지면 앞의 둘이 아무리 만점이어도 어색한 문장이 그대로 나갑니다.
7. 직접 확인 2: 재현성은 확인하지 못했습니다
여기는 확인에 실패한 항목이라 실패한 채로 적습니다. 검사 스크립트는 정규식으로만 판정하기 때문에 같은 파일을 열 번 넣으면 열 번 다 같은 숫자가 나오지만 humanizer는 언어 모델이 판정하는 스킬이라서 같은 글을 두 번 넣었을 때 같은 결과가 나온다는 보장이 없습니다.
필자는 이걸 제대로 확인하려면 같은 입력을 여러 번 돌려서 감지된 패턴 목록과 자연도 등급이 얼마나 흔들리는지를 봐야 한다고 생각하는데 이번에는 그 실험을 하지 않았습니다. 그래서 등급이 A로 나왔다는 사실을 다음 실행에서도 A가 나온다는 뜻으로 읽으시면 안 됩니다.
같은 이유로 문서에 적힌 94.88%라는 숫자도 그대로 믿고 쓰기에는 조심스러운 면이 있습니다. 그 수치는 논문이 쓴 코퍼스에서 나온 값이고, 개인 블로그 글이 그 코퍼스와 같은 분포인지는 아무도 확인하지 않았습니다. 필자가 참고한 패턴 임계값들도 도구 문서에 적힌 값일 뿐이고 한국어 글 뭉치로 검증된 값이 아니라는 단서가 원문에 그대로 달려 있습니다.
그래서 필자는 이 숫자들을 이렇게 대하고 있습니다. 어디를 다시 볼지 방향을 잡는 데는 쓸모가 있지만 통과와 탈락을 가르는 기준선으로 쓰기에는 근거가 모자랍니다. 점수는 합격선이 아니라 다시 읽을 문단을 고르는 용도로만 쓰고 있습니다.
8. 안 되는 것, 윤문이 재작성으로 넘어가는 지점
이 도구를 쓰면서 가장 크게 망가지는 경우는 잘 안 잡히는 쪽이 아니라 지나치게 잘 잡히는 쪽입니다. 스킬 문서에도 과잉 교정을 막는 장치가 따로 들어 있는데 원문 대비 어절이 30% 넘게 바뀌면 경고를 붙이고 50%를 넘으면 아예 출력을 멈추고 사용자에게 되묻게 되어 있습니다.
이 기준이 실제로 얼마나 빡빡한지 필자가 직접 재봤습니다. 앞에서 만든 두 표본은 담고 있는 내용이 같은데도 어절 기준 변경률이 무려 94%였는데요, 전체 어절 103개 중에 그대로 살아남은 게 겨우 6개뿐이었습니다.
| 비교 | 값 |
|---|---|
| AI 문체 표본 어절 수 | 103 |
| 사람 문체 표본 어절 수 | 83 |
| 두 표본에 공통으로 남은 어절 | 6 |
| 어절 기준 변경률 | 94% |
| 스킬 문서의 중단 기준 | 50% 초과 |
숫자가 말해주는 건 분명합니다. 필자가 한 일은 윤문이 아니라 재작성이었습니다. 두 표본이 담은 사실은 같은데 문장은 완전히 다른 글이 되어버렸고 이 정도 변경률이면 humanizer 기준으로는 애초에 출력이 중단됐어야 하는 수준입니다. 윤문을 부탁했는데 다른 글이 돌아왔다면 그건 도구가 일을 잘한 게 아니라 선을 넘은 것입니다.
그래서 실제로 조심하셔야 할 지점이 몇 군데 있습니다. 하나는 수치와 고유명사가 사라지는 경우입니다. 문장을 매끄럽게 만들다 보면 “닷새 연속”이 “한동안”으로 뭉개지는 일이 생기는데, 이러면 글의 신뢰도를 만들던 유일한 근거가 통째로 없어집니다. 스킬 문서에도 수치와 날짜와 인용이 보존됐는지 스스로 점검하라는 항목이 들어 있는 이유가 바로 이것입니다.
다음은 인과가 뒤집히는 경우입니다. “A 때문에 B가 됐다”를 다듬다가 “B 때문에 A가 됐다”로 바뀌는 사고인데 문장만 보면 둘 다 자연스러워서 검사기로는 절대 안 잡힙니다. 비슷한 걸로 부정 표현이 반전되는 경우도 있는데 “확인되지 않았습니다”가 “확인했습니다”로 바뀌어버리면 그 순간부터 글이 거짓말을 하게 됩니다. 그래서 필자는 고친 버전을 받으면 숫자와 부정어만 따로 훑어보는 습관을 들이고 있습니다.
한 가지 더 알아두시면 좋은 게 이런 도구들은 훅에 해당하는 표현을 감지해도 점수를 깎지는 않는 쪽으로 설계되어 있다는 점입니다. “정말 가능한 일일까요” 같은 문장은 글쓴이가 일부러 넣었을 수도 있으니 판단은 사람에게 넘긴다는 것인데요, 그래서 리포트에 뜬 항목을 전부 고쳐야 할 목록으로 읽으시면 글에서 개성만 빠지고 밋밋해집니다.
마지막으로 웃긴 일이 하나 있었는데 지금 읽고 계신 이 글을 검사 스크립트에 넣어보니 52점이 나왔습니다. 이유를 찾아보니 앞에서 나쁜 표현이라고 설명하려고 따옴표에 넣어둔 “전문가들은”이나 “결론적으로” 같은 말들을 검사기가 전부 필자가 쓴 문장으로 세고 있었습니다. 인용한 것과 실제로 쓴 것을 구분하지 못하는 것인데요, 그래서 AI 문체를 다루는 글일수록 점수를 그대로 믿으면 안 되고 걸린 위치를 하나씩 열어서 이게 예시인지 내 문장인지 눈으로 확인하셔야 합니다. 필자도 이렇게 열어보다가 예시인 줄 알았던 문장 두 개가 진짜 제 문장이었다는 걸 발견해서 고쳤습니다.
9. 누구에게 맞고 누구에게는 안 맞나
쓰시면 좋은 경우부터 적겠습니다. AI에게 초안을 받아서 자기 이름으로 발행하는 분이라면 붙일 값어치가 확실히 있습니다. 한국어 번역투는 본인 눈에는 잘 안 보이는데, 읽는 사람 눈에는 바로 걸리기 때문에 자기가 못 보는 걸 대신 봐주는 용도로 쓰시면 딱 맞습니다. 여러 사람이 문서를 나눠 쓰는 경우에도 style-guide를 얹어두면 톤이 흔들리는 지점을 찾기가 훨씬 쉬워집니다.
반대로 굳이 안 쓰셔도 되는 경우도 있습니다. 처음부터 본인이 손으로 쓰는 분이라면 얻는 게 별로 없습니다. 필자가 만든 사람 문체 표본은 검사에서 감점이 하나도 없었는데, 애초에 AI가 안 쓴 글에는 AI 흔적이 없으니 당연한 결과입니다. 게시 규격이 엄격하게 정해진 문서도 마찬가지인데요, 검사기가 제안하는 통일안이 그 규격과 부딪히면 오히려 손이 더 갑니다.
마지막으로 필자가 이번에 배운 것 하나만 적어두겠습니다. 검사기를 붙이면 점수가 올라가는 건 맞는데, 점수가 올라가는 것과 글이 사람 것처럼 읽히는 건 서로 다른 문제입니다. 100점을 받은 표본이 정작 쉼표 축에서는 기준의 두 배 가까이 나왔다는 게 그 증거고 그래서 마지막 판단은 결국 소리 내어 읽어보는 사람 몫으로 남습니다.
오늘 하나만 하신다면 최근에 AI로 뽑은 글 아무거나 하나를 골라서 쉼표가 들어간 문장이 몇 퍼센트인지만 세어보시면 좋겠습니다. 26%보다 한참 높게 나온다면 어휘를 바꾸기 전에 쉼표부터 손보시는 쪽이 훨씬 빠릅니다.
관련해서 같이 보시면 좋은 글도 남겨둡니다. 점수만 보고 넘어갔다가 놓친 이야기는 자동 검사가 통과시킨 코드에서 뒤늦게 나온 것들에 적어두었고 자동화에서 사람이 반드시 맡아야 하는 부분은 Claude Code 자동화, 사람 몫 4가지에 정리해두었습니다.