지난 회고를 쓰면서 한 가지 궁금증이 생겼다. 요즘 블로그 글 중에 AI 말투가 섞인 글이 많다는데 내 글은 어떨까. 궁금하면 만들어보는 게 빠르다. 그래서 하루 만에 작은 실험 도구를 하나 만들었다.
https://github.com/chaeyoonakim/korean-skills-webhook
이름 그대로 한국어 블로그 글에서 AI 냄새가 나면 슬랙으로 알려주는 파이프라인이다. 거창한 프레임워크 없이 순수 함수 여섯 개를 이어 붙였고 상태는 Pydantic 모델로 넘긴다. 형태소 분석은 kiwipiepy를 썼다. 자바 없이 파이썬만으로 돌아가서 GitHub Actions 러너에 올리기 좋았다.
무엇을 보는가
KatFishNet이라는 ACL 2025 논문에서 아이디어를 가져왔다. 저장소에 라이선스가 없어서 코드는 한 줄도 베끼지 않고 아이디어만 처음부터 다시 구현했다. 흥미로운 지점은 쉼표였다. LLM이 쓴 한국어는 문장의 약 61%에 쉼표가 들어가는데 사람 글은 26% 정도라고 한다. 그래서 쉼표 사용 패턴에 가장 큰 가중치 40점을 줬다. 나머지는 번역투 패턴 25점 (되어진다, ~에 있어서 같은 것들), 품사 n-gram 다양성 20점, 띄어쓰기 일관성 15점이다. 띄어쓰기 항목이 재밌는데 기계는 맞춤법 표준을 지나치게 잘 지키고 사람은 적당히 틀린다. 나처럼.
첫 실험 대상은 내 글
7월 3일에 올린 설문 분석 회고를 첫 제물로 삼았다. 사람이 쓴 글이니 낮은 점수가 나와야 정상이고 높게 나오면 그 자체로 오탐 사례가 된다. 결과는 9/100. 다행이다. 그런데 그 9점 안에서도 오탐이 하나 있었다. “데이터가 손에 있어서 간단하게 돌려본”이라는 문장에서 번역투 패턴 ‘~에 있어서’가 걸렸다. 여기서 ‘있어서’는 그냥 데이터가 손에 있었다는 뜻이다. 규칙 기반 탐지기의 한계가 정확히 이런 곳에 있다. 그래서 슬랙 메시지에는 어떤 패턴이 어디서 걸렸는지 증거를 전부 붙였다. 점수는 참고용이고 판정은 사람이 한다는 원칙을 코드와 메시지 양쪽에 박아뒀다.
얼마나 걸렸나
커밋 히스토리를 보니 빈 저장소에서 동작하는 파이프라인 PR까지 한 시간이 안 걸렸다. 코어 구현 자체는 30분 남짓. Claude Code와 함께 작업한 결과다. 물론 그 뒤로 하루 동안 자잘한 손질이 이어졌다. 첫 피드 스캔이 과거 글 9개를 한꺼번에 쏟아내지 않게 조용히 seed만 하도록 했고 (덕분에 나는 “알람이 안 와요”라는 이슈를 직접 겪었다), .env 파일을 읽는 코드가 없어서 로컬 실행이 막혔던 것도 고쳤다. 윈도우 콘솔에서 한글이 깨지는 문제와 Gemini로 문장 다듬기 제안을 붙이는 작업은 내가 직접 했다. GitHub push protection이 .env.example 안의 가짜 웹훅 URL까지 차단해서 커밋을 다시 쓴 일도 있었다. 진짜 비밀도 아닌데 모양만 보고 막는 게 처음엔 귀찮았지만 생각해보면 그게 맞는 동작이다. 실제로 에러 메시지에 API 키가 그대로 노출되는 사고를 하루 만에 겪었으니까.
이 글은 몇 점일까
여기서 고백. 이 글은 그 도구를 같이 만든 Claude와 함께 썼다. AI 말투 탐지기 개발기를 AI와 같이 쓰는 셈이라 발행 전에 이 글 자체를 탐지기에 넣어봤다.
결과는 17.6/100. 그런데 내역을 보다가 웃음이 났다. 17.6점 중 16점이 패턴 항목에서 나왔는데 걸린 문장들이 하필 위에서 ‘되어진다’와 ‘~에 있어서’를 예시로 언급한 바로 그 대목이다. 패턴을 설명하려고 인용한 것을 실제로 사용한 것으로 오인한 셈이다. 언급과 사용을 구분하지 못하는 것. 규칙 기반 탐지기의 오탐 유형 목록에 하나가 더 추가됐다.
한편으로는 문체를 흉내내는 AI 글이 이렇게 낮은 점수로 통과한다는 사실 자체가 이 도구의 한계를 보여준다. 어느 쪽이든 결과를 그대로 공개하는 것이 이 실험의 규칙이다.
다음 숙제도 남아 있다. 임계값들이 에세이 데이터 기준이라 블로그 글이라는 장르에 맞는지 검증이 필요하고 짧은 글에서는 신호가 흔들린다. 무엇보다 진짜 AI가 쓴 한국어 글을 더 모아서 방향이 맞는지 확인해야 한다. 지금은 합성 픽스처 두 개로 방향만 확인한 상태다.