이미 많은 분들이 AI로 기획서, 보고서, 블로그 초안 작성 등에 활용하실 텐데요. 그러나 진짜 업무는 AI가 준 작업물을 우리가 검토하는 순간부터라고 생각합니다. 저 역시 AI로 생성한 5,000자 분량의 기획서 초안을 보고, 어색하고 불편하다고 느꼈습니다. AI가 생성한 글에는 문장마다 번역투의 흔적, 기계적인 관용구가 빼곡했거든요.

예를 들어, "~에 대해 논의를 진행하고자 합니다", "매우 핵심적인 요소라고 볼 수 있습니다", "결론적으로 이는 시사하는 바가 큽니다"와 같은 표현들인데요. 오히려 AI가 써준 초안의 어색함을 지우려고, 윤문과 후편집에 더 많은 시간을 쏟는 거죠.

AI로 글 작성 시간을 줄이려다가, 수정의 늪으로 빠진 겁니다. 이 어색하고 기계적인 'AI 어투'를 기술적으로 걷어낼 순 없을까요? 이번 글에서는 문맥의 기계적 패턴을 식별해 교정하는 오픈소스 프로젝트 “im-not-ai”로, 그 원리와 문제점을 짚어보고 최적화 전략까지 살펴보겠습니다.

'im-not-ai'는 어떻게 AI를 탐지하고 교정할까?

오픈소스 프로젝트 “im-not-ai”는 글 생성 후 진행하는 윤문, 후편집의 비효율을 통제하기 위해 등장한 도구입니다. 이 프로젝트는 특정 단어를 기계적으로 치환하여, 한글에서 특정 표현이 반복되는 AI의 구조적 결함과 번역학적 오류를 줄이는 프레임워크를 제공합니다.

우선 im-not-ai의 ‘ai-tell-taxonomy.md’는 AI 한글 텍스트의 미세한 흔적들을 10대 대분류와 40개 이상의 세부 패턴으로 정밀하게 분류합니다. 수많은 사용자의 피드백, 깃허브 Contributors 히스토리([Issue #1]를 집약해 구축했는데요. 이 규칙판은 AI 특유의 번역투(A), 기계적인 구조화와 불릿 남용(C), '결론적으로'나 '시사하는 바가 크다' 같은 시그니처 관용구(D), 문장 길이의 단조로운 리듬 균일성(E), 완곡한 회피 표현(G) 등을 심각도(S1 결정적, S2 강함, S3 약함)에 맞춰 스캔합니다.

이후 에이전트는 한국어 윤문 처방집인 ‘rewriting-playbook.md’에 근거해, 사실과 고유명사 등의 핵심 데이터는 100% 보존하면서, 어색한 격조사와 불필요한 정도부사를 한국어 고유의 능동형 서술어와 다양한 종결어미로 재작성하는 작업을 진행합니다.

흥미로운 점은 이 오픈소스의 진단 도구가 깊이 있는 국제 번역학 이론에 뿌리를 두고 있다는 건데요. 1990년대 번역학자 Mona Baker가 정립한 '번역 보편소(Translation Universals)' 이론에 따르면, 번역문은 원문보다 어휘와 통사가 단순해지는 단순화(simplification)와 목표 언어의 전형적 관습에 기계적으로 고착되는 표준화(normalisation) 경향을 띱니다. AI가 영어 중심의 거대 말뭉치(LLM 데이터셋)를 학습해, 한국어 텍스트를 출력하는 메커니즘도 이와 같죠.

특히 스페인 번역학자 Antonio Toral(2019)은 기계번역 결과물을 사람이 어설프게 교정하는 과정에서 발생한 기형적 문체를 'Post-editese(후편집투)'라고 정의했는데요. 어휘의 다양성이 결여되고, 원문 언어의 간섭 법칙(Toury 1995)에 의해 문장이 꼬여버리는 현상입니다.

결국 우리가 AI 글을 읽으며 느낀 묘한 불쾌감은 역사적으로 오랜 연구 대상이었던 '번역투의 악화된 형태'였던 겁니다. `im-not-ai`는 이러한 번역학적 진단을 규칙화해, 텍스트에 축적된 기계적 간섭의 흔적들을 도려내는 방식을 택했습니다.

실전 A/B 테스트: im-not-ai가 만든 결과

이번엔 im-not-ai를 통한 윤문의 효용성을 검증하기 위해, 실제 비즈니스 텍스트로 A/B 테스트를 진행해 봤습니다.

교정에 따른 독자들의 평가가 어떤지 보기 위해, 2~30대의 다양한 직군(PM, 개발자, 디자이너, HR, 마케터 등)을 대상으로 블라인드 테스트를 진행했는데요.

설문 평점(5점 만점)을 분석한 결과,

자연스러움(A안 2.70점 vs B안 4.40점)
명료성(A안 3.15점 vs B안 4.40점)
가독성(A안 2.45점 vs B안 4.35점)
기고문 적합성(A안 2.50점 vs B안 4.25점)

전 영역에서 B안이 압도적인 점수를 받았습니다. 최종 선호도 역시 B안이 85%(17명)의 지지를 얻었고요. 대부분은 B안이 쓸데없는 포장어, 기계적 접속부사가 없어, 정보를 빠르게 파악할 수 있었다고 답했습니다.

그러나 흥미로운 결과는 A안에 있었습니다. A안에 높은 점수와 선호도를 보인 15%(3명)은 HR 담당자, 재무 담당자, 브랜드 컨설턴트였는데요. B안이 읽기는 편했지만, 공적인 칼럼으로서는 어조가 다소 단조롭고 가볍다고 평가했습니다. 이들은 오히려 수동 표현이 섞이더라도, 정중하고 격식을 갖춘 A안의 고전적 톤앤매너가 글의 권위와 신뢰성을 높여준다고 응답했죠.

이 결과는 매우 중요한 비즈니스 시사점을 던집니다. AI 번역투를 완전히 제거하는 기계적 미니멀리즘이 늘 최선은 아니라는 점인데요. 가독성을 높이기 위해 문장을 수정하되, 글의 격식과 신뢰가 필요한 상황이라면 독자의 타깃에 맞는 ‘어조의 미세 조정’이 필요하단 거죠.

현업 도입 전 짚어야 할 한계점은?

윤문 프로세스가 독자에게 주는 영향은 긍정적이지만, 실무에 ‘im-not-ai’를 도입할 때 고려해야 할 두 가지 한계가 있습니다.

첫 번째는 무거운 에이전트 협업 구조에 따르는 API 비용(토큰)의 폭증입니다. 이 오픈소스는 클로드의 고성능 추론 모델인 Opus를 기반으로 동작합니다. 단순히 비싼 모델이라서가 아니라, 정밀 검증(Strict) 모드로 구동할 때 5인의 개별 에이전트(분류학자, 탐지기, 윤문가, 내용 감사관, 자연스러움 리뷰어 등 - 에이전트명 직역 표현)가 다단계 루프를 돌며, API를 수차례 반복 호출하는 무거운 파이프라인 구조가 API 비용을 발생시킵니다.

특히 글자 수가 많은 원고를 처리할 땐, 한 번에 10달러가 훌쩍 넘는 비용이 발생할 수 있습니다. 실제로 개발자는 v1.5에서 단일 호출 monolith Fast 모드가 추가된 것이 비용과 시간을 절감하기 위함이라 밝혔습니다.

두 번째는 또 다른 템플릿화의 부작용입니다. 제공되는 윤문 규칙이 다소 도식적이고 획일적이라, "몇 번 쓰다 보면 결국 툴 고유의 기계적인 수정 패턴이 또다시 들통나 독자에게 피로를 유도할 것 같다"는 우려죠.

가이드라인이 특정 스타일(단문 위주의 기계적 단순화)에만 다소 편향되어 있어, 실무 도메인이나 필자의 본래 개성을 살리지 못하고, 글을 단조롭게 만드는 또 다른 AI 투를 유발한다는 역설입니다.

마치며

오픈소스 ‘im-not-ai’는 기술을 활용해 한글 문체 속 AI 어투를 덜어내는 가능성을 증명했습니다. 그러나 현업에서 오픈소스를 도입할 때는 외부 도구의 자동화 규칙을 맹목적으로 신뢰해서는 안 됩니다. 지속 가능한 비즈니스 원가 구조를 설계하듯, 기업 고유의 브랜드 가이드라인과 톤앤매너를 직접 정의하고 이를 프롬프트 단계부터 치밀하게 설계해야 합니다.

결국 비즈니스 글쓰기는 전달력과 신뢰성 사이에서 균형점을 찾는 일입니다. AI라는 거대한 기술 인프라 속에서 여러분은 요즘 어떻게 쓰고 계신가요? 나도 모르게 너무 AI에 의존하고 있진 않나요?

<출처>

(im-not-ai 긍정 평가) 박성철님 링크드인
(im-not-ai 부정 평가) im-not-ai 글에서 ai티 줄이는 스킬인데 괜찮은듯?, AI 웹소설 연재 갤러리, ‘26.05.24
(Mona Baker (1993) – 번역 보편소) Baker, M. (1993). Corpus linguistics and translation studies: Implications and applications. In M. Baker, G. Francis, & E. Tognini-Bonelli (Eds.), Text and Technology: In Honour of John Sinclair (pp. 233–250). John Benjamins.
(Gideon Toury (1995) – 원문 언어의 간섭) Toury, G. (2012). Descriptive Translation Studies and Beyond. John Benjamins.
(Antonio Toral (2019) – 후편집투(Post-editese)) Toral, A. (2019). Post-editese: An exacerbated translationese. Proceedings of the 17th Machine Translation Summit (MT Summit XVII), 273–281.