한국어 AI 문장을 고칠 때 패턴 목록보다 브레이크가 먼저인 이유

AI가 쓴 티를 지우려면 AI가 좋아하는 단어를 바꾸면 된다는 생각이 꽤 널리 퍼져 있습니다. 영어권에서는 실제로 그게 어느 정도 통해요. QuillBot이나 Undetectable AI 같은 휴머나이저가 하는 일도 크게 보면 자주 등장하는 단어를 동의어로 갈아끼우는 일입니다. 그런데 한국어에서 같은 방법을 쓰면 단어만 바뀌고 어색함은 그대로 남습니다. 어색함이 단어에 있지 않기 때문이에요.

단어를 바꿔도 남는 것

"~에 의해 발생되어진다고 볼 수 있는 상황입니다." 이 문장에서 거슬리는 건 특정 단어가 아니라 '에 의해', '되어진다', '볼 수 있는'이 겹겹이 쌓인 모양입니다. "기술이 아니라 방식이다. 속도가 아니라 방향이다." 역시 단어는 평범한데 같은 틀이 두 번 연달아 찍혀 나오는 리듬이 기계 냄새를 냅니다.

오픈소스 윤문 도구 im-not-ai는 이런 증상을 10개 카테고리, 85개 패턴으로 나눠 잡습니다. 실제 원고에서 가장 자주 걸리는 건 네 가지라고 정리하는데, 이중 피동('생각되어집니다', '보여집니다'), 영어식 대명사 직역('그는 그의 손을 들어'), 'A가 아니라 B다'를 반복하는 대칭 강박의 대구, 그리고 '살펴보았습니다'류의 상투적 종결구입니다. 넷 다 단어 하나를 바꿔서는 사라지지 않고, 문장을 다시 짜야 없어집니다.

README에 실린 예시가 이 차이를 잘 보여줍니다. "이에 있어서 중요한 점은 AI 기술을 통해 효율을 높일 수 있다는 것입니다"가 "여기서 중요한 건 AI로 효율을 높일 수 있다는 점입니다"로 바뀝니다. 뜻은 그대로고 '~에 있어서'와 '~를 통해'라는 뼈대만 빠졌어요. 문장 길이로 보면 몇 글자 줄었을 뿐인데 읽는 속도는 꽤 달라집니다.

85개 패턴 중에는 문장 안쪽이 아니라 글 전체의 모양에서 나오는 것도 있습니다. 한국어로 충분한 말을 굳이 영어로 적는 영어 인용 과다, 모든 문장이 비슷한 길이와 호흡으로 이어지는 리듬 단조로움, 볼드와 이모지와 글머리표를 과하게 쓰는 시각 장식 남용. 이 셋 중 리듬 단조로움이 도구로 고치기 가장 어렵다고 봐요. 문장 하나하나는 멀쩡하고, 문제는 문단과 문단 사이의 간격에 있으니까요. 길고 짧은 문장을 섞는 일은 패턴 탐지보다 필자가 자기 글을 처음부터 다시 읽는 쪽에 가깝습니다.

번역투라는 설명은 어디까지 믿을까

왜 하필 이런 모양이 나올까에 대해서는 그럴듯한 설명이 있습니다. 안토니오 토랄이 2019년 MT Summit에서 발표한 'Post-editese' 연구는 기계번역 결과를 사람이 다듬은 글이 처음부터 사람이 번역한 글보다 번역투가 더 두드러진다고 보고했고, 모나 베이커(1993)와 기디언 투리(1995)의 번역 보편소 개념도 함께 근거로 쓰입니다. 영어 데이터를 훨씬 많이 먹은 모델이 한국어를 쓸 때도 영어의 뼈대가 비친다는 해석이죠.

저는 이 설명을 원인으로 받아들이기보다 작업 가설로만 두는 편이 맞다고 봐요. 토랄의 연구는 기계번역을 다룬 것이고 AI가 직접 쓴 한국어를 실험한 게 아닙니다. 글을 쓴 쪽도 이 점을 스스로 밝혀두었고요. 실무에서 중요한 건 원인이 번역투냐가 아니라, 증상이 단어가 아니라 구조에 있다는 관찰 쪽입니다. 그 관찰만으로도 고치는 방법은 충분히 달라지니까요.

뼈대를 고치면 뜻이 흔들린다

여기서부터가 제가 이 도구에서 가장 중요하다고 보는 대목입니다. 단어를 바꾸는 윤문은 뜻을 크게 건드리지 않습니다. 구조를 바꾸는 윤문은 다릅니다. 피동을 능동으로 돌리면 주어가 생기고, 대구를 풀면 강조가 사라지고, 상투적 종결구를 걷어내면 문장이 단정해집니다. 고친 뒤의 문장이 원래 필자가 의도한 수위보다 세지거나 약해지기 쉬워요.

im-not-ai는 이걸 네 가지 원칙으로 막습니다. 사실·통계·고유명사·인용은 건드리지 않고, 패턴이 탐지된 구간만 고치고, 보고서를 감성 에세이로 바꾸지 않고, 원문 대비 변경률이 30%를 넘으면 경고하고 50%를 넘으면 작업을 멈춥니다. 탐지한 패턴마다 S1부터 S3까지 심각도를 매겨 심각한 것부터 고치게 한 것도 같은 방향이고요.

제가 보기엔 마지막 장치, 변경률 상한이 85개 패턴 목록보다 값집니다. 금지 표현 목록을 운영해본 사람은 압니다. 목록이 길어질수록 고친 문장은 목록을 피하는 데 급급해지고, 그 피한 자리에서 또 다른 균일한 말투가 생깁니다. AI 티를 지우려다 '윤문 도구 티'가 나는 셈이죠. 변경률 상한은 그 미끄러짐을 기계적으로 끊는 브레이크입니다. 덜 고치는 쪽이 안전하다는 원칙을 사람의 판단에 맡기지 않고 숫자로 강제한다는 점에서, 이 도구를 쓸지 말지 고민하는 팀이라면 이 기능부터 확인해보길 권합니다.

비용도 구조를 따라간다

도구는 클로드 코드에서 플러그인 두 줄로 설치되고, 코덱스 CLI와 깃허브 코파일럿 CLI도 지원하며 제미나이 CLI는 일부 기능만 됩니다. MIT 라이선스이고 9월 기준 깃허브 스타는 5,700개 수준이에요. 글 상태에 따라 한 번, 두 번, 1만 5천 자가 넘는 긴 글은 세 번 이상 나눠 처리합니다.

눈여겨볼 숫자는 README의 실측입니다. 1만 자짜리 글을 7번으로 나눠 돌리면 약 61만 토큰, 한 번에 돌리면 약 13만 4천 토큰이 들었다고 적혀 있어요. 나눠 돌린 쪽이 4.5배 넘게 비쌉니다. 나눌 때마다 지침과 맥락을 다시 읽히니 당연한 결과인데, 쪼갠 쪽 결과물이 4.5배만큼 좋아진다는 근거는 어디에도 없습니다. 구독 한도가 빠듯한 팀이라면 쪼개기보다 한 번에 처리하고, 결과를 사람이 한 번 더 보는 쪽이 비용 대비 낫다고 봅니다.

그래서 어디에 끼워 넣나

윤문을 모든 글에 돌릴 이유는 없습니다. 효과가 큰 건 제안서, 브랜드 콘텐츠, 고객 응대 메일처럼 읽는 사람이 문장으로 신뢰를 판단하는 글이에요. 이런 글에 한해 발행 직전의 고정 단계로 두고, 초안 단계에서는 속도에만 집중하는 배치가 현실적입니다. 개인 메모나 회의록까지 돌리면 토큰만 탑니다.

도구를 못 쓰는 환경이라면 방법은 더 단순합니다. 완성한 원고를 소리 내어 읽고, '~에 있어서', '~를 통해', '~라고 볼 수 있습니다'부터 찾아 지우고, 한 문단에 같은 구조가 세 번 이상 반복되는지 보는 것. 귀로 들으면 눈으로 넘긴 이중 피동이 걸립니다. 결론을 먼저 말하고 근거를 뒤에 붙이는 순서로 바꾸는 것만으로도 꽤 많은 상투적 종결구가 저절로 빠지고요.

저는 결국 이 도구의 가치가 '사람처럼 쓰게 만드는 것'보다 '고치다 망치지 않게 막는 것'에 있다고 봅니다. 뼈대를 손대는 윤문은 원래 위험한 작업이고, 그 위험을 숫자로 묶어둔 도구라면 마지막 게이트로 둘 만합니다. 반대로 변경률 상한 없이 패턴만 열심히 지워주는 도구라면, 고친 글이 더 매끄러워졌다고 해서 더 믿을 만해졌다고 보긴 어렵습니다.