AI 말투를 고치는 방법, 단어로 작성자를 단정하지 않기

AI로 글을 쓰는 사람이 많아졌다는 것은 이제 새로운 이야기가 아닙니다. 다만 AI가 쓴 글이 실제로 얼마나 퍼졌는지, 사람들이 그중 무엇을 특히 싫어하는지는 수치로 확인된 적이 거의 없습니다. 그래서 "이 단어를 쓰면 AI가 쓴 글"이라는 말만 근거 없이 돌아다니고, 사람이 직접 쓴 글이 그 통념 때문에 의심받는 일도 생깁니다.

이 글에서 AI 말투는 AI가 만든 초안에서 자주 반복된다고 느끼는 낱말과 문장 구조를 뜻합니다. 사람도 같은 표현을 쓰므로 특정 단어만으로 작성자를 가릴 수는 없습니다. 2026년 8월에 공개된 조사 하나가 그 습관이 얼마나 퍼졌는지를 숫자로 다뤘습니다. 루이 아브라함(Louis Abraham)이 만든 load-bearing 프로젝트입니다. GitHub는 프로그램 코드를 함께 관리하는 서비스이고, 풀 리퀘스트(PR)는 코드 변경을 검토해 달라는 요청입니다. 여기서 분석한 것은 프로그램 자체가 아니라 요청에 붙인 설명문입니다.

필체를 보고 누가 썼는지 짐작하듯, 이 조사는 글의 내용이 아니라 단어 선택만 보고 글을 나눕니다. 아래에서는 조사 결과의 의미를 먼저 읽고, 실제 문장을 고치는 방법으로 이어갑니다. 아래 수치는 2026년 9월 2일에 생성된 자료 기준입니다. 이 조사는 매일 갱신되므로 지금 사이트를 열면 수치와 분석 설정이 달라질 수 있습니다. 이 글의 원래 그래프와 수치는 당시 기록으로 보존합니다. 숫자를 AI 사용률로 바꾸어 해석하지 않습니다.

한눈에 보는 조사 결과

어휘만으로 46만 건을 나눈 방법

먼저 자료를 어떻게 모았는지부터 봐야 합니다. 조사자는 깃허브의 공개 이벤트 기록을 쓰려다 포기했습니다. 2025년 10월에 깃허브가 이벤트 기록에서 커밋 배열을 빼면서 설명 텍스트가 사라졌기 때문입니다. 초기 버전은 load-bearing이라는 단어를 17건으로 셌는데, 이는 실제보다 158배 적은 값이었습니다.

대신 프로그램에서 GitHub 검색 결과를 받아 오는 연결 방식인 검색 API를 씁니다. 하루를 2.4시간씩 열 구간으로 나누고 각 구간에서 5분짜리 창을 하나씩 뽑아 그 시간에 올라온 풀 리퀘스트를 가져옵니다. 창을 여는 시각을 초 단위로 흩뜨린 이유가 있습니다. 5분의 배수에 맞추면 정기 실행 자동화가 풀 리퀘스트를 올리는 순간과 정확히 겹치기 때문입니다.

걸러내는 기준도 분명합니다.

• 봇 계정 제외: 로그인 이름이 [bot]이나 -bot으로 끝나는 계정과 copilot. 3,784개 계정이고 수집한 행의 13.2%입니다
• 한 주에 저자당 세 건까지: 사람처럼 보이는 계정이 같은 문장을 대량으로 올리는 경우를 막습니다. 사람에게도 똑같이 적용되므로 제외가 아니라 상한입니다
• 서로 다른 계정 50개 기준: 50명 이상이 쓴 낱말만 어휘로 셉니다

마지막 기준이 이 조사에서 가장 중요한 장치라고 볼 수 있습니다. 등장 횟수만 세면 여러 사람이 함께 쓴 낱말과 한 사람이 200번 복사한 낱말을 구분하지 못합니다. 실제로 store-path는 242번 나왔지만 계정이 둘뿐이라 빠졌고, load-bearing은 848개 계정이 썼기 때문에 남았습니다.

비슷한 자료를 묶는 군집 분석을 사용하며, 방법 이름은 KL 발산 기반 k-평균입니다. 이 이름이나 수식을 외울 필요는 없습니다. 쉽게 말하면 각 묶음을 단어 확률표 하나로 두고, 글마다 자기 단어 구성과 가장 가까운 표를 찾아 배정하는 방식입니다. 여기에는 시간이라는 변수가 아예 들어가지 않습니다. 그래서 어떤 묶음이 늘어난 그래프가 나왔다면, 시간에 따라 증가하도록 모형에 직접 지시한 결과는 아닙니다. 다만 표본 선택과 묶음 수, 초기 설정이 분류 결과에 영향을 주므로 실제 전체 글의 변화를 그대로 측정했다고 단정하지 않습니다.

2026년에 나타나 40%가 된 어휘 묶음

열 묶음 가운데 하나가 2025년 내내 1% 아래에 머물다가 2026년 들어 급격히 커졌습니다. 주별로 보면 변화 시점이 뚜렷합니다.

2026년 2월까지 1% 언저리였던 것이 반년 만에 40%가 됐습니다. 조사 페이지는 최근 12주 추세선 기울기를 자동으로 계산해 보여주는데, 당시 표시 값은 주당 1.07퍼센트포인트였습니다. 이를 현재 증가 속도로 사용하지 않습니다.

이 조사를 소개한 기사에서 잘 다뤄지지 않은 부분이 하나 더 있습니다. 같은 기간에 크게 늘어난 묶음이 하나가 아니라 둘입니다.

두 번째 묶음의 대표 단어는 전부 프로그래밍 언어 러스트(Rust)의 빌드와 테스트 도구인 카고(Cargo) 명령 옵션입니다. 실행 명령이 설명문에 포함된 흔적일 수 있지만 누가 그 명령을 작성했는지는 알 수 없습니다. 위 표의 8월 집계값 37.4%와 31.2%를 더하면 68.6%입니다. 앞의 특정 주 40.06%와 같은 기간의 값으로 혼용하면 안 되며, 이 합계도 AI 작성 비율은 아닙니다. 산문 쪽과 명령 기록 쪽이 각각 다른 묶음으로 잡혔을 가능성이 있습니다.

대표 단어 스물다섯 개

묶음을 대표하는 단어는 묶음 안에서 쓰인 빈도를 묶음 밖 빈도로 나눠 정합니다.

프로젝트 이름이 된 load-bearing은 배수 기준으로는 23위입니다. 1위가 아닌데도 제목에 올라간 것은 뜻이 두드러지기 때문으로 보입니다. 건축에서 load-bearing wall은 건물 무게를 실제로 받치는 내력벽을 가리킵니다. 코드 설명에 이 표현이 들어가면 "이 부분은 빼면 무너진다"는 뜻이 됩니다.

이 단어는 2026년 이전에는 거의 보이지 않다가 최고 시점에 백만 단어당 94회까지 올라왔습니다. 전체 기간 평균은 21회입니다.

교정할 때 살펴볼 표현 일곱 가지

낱말 목록만으로는 읽는 사람이 왜 불편해하는지 설명되지 않습니다. 같은 표현을 얼마나 반복하는지와 문장 구성이 전달을 방해하는지도 봐야 합니다.

이 부분을 폭넓게 정리한 곳은 영어 위키백과의 편집자 모임입니다. AI 정리 작업반이 만든 "Signs of AI writing" 문서에 실제 편집 사례와 함께 항목이 쌓여 있습니다.

부정 대구

앞의 것을 부정하고 뒤의 것을 세우는 구조입니다. Not only A but also B, It is not just A, it is B 형태가 대표적입니다. 한국어로는 "단순한 A가 아니라 B였습니다"로 나타납니다.

위키백과 편집 안내에서 별도 항목으로 다루며, 참여도 조사와 한국어 교정 사례에서도 등장합니다. 여러 곳에서 언급됐다는 것만으로 모든 사람이 싫어하거나 성과를 떨어뜨린다고 결론 내리지는 않습니다.

필요 없는 대비는 읽는 사람이 하지 않은 오해부터 제시할 수 있습니다. 실제로 구분할 두 대상이 있을 때만 그 대비를 남깁니다.

세 개씩 나열하기

형용사든 장점이든 요점이든 항상 세 개로 맞추는 습관입니다. 위키백과 문서는 이를 rule of threes로 부릅니다. 한 번은 읽기 좋지만 문단마다 반복되면 내용이 아니라 틀이 먼저 보입니다.

단순 동사 회피

is나 are로 충분한 곳에 serves as, stands as, functions as, operates as를 넣습니다. 한국어에서 같은 구실을 하는 표현이 "기능합니다"입니다. "이 값은 기준으로 기능합니다"는 "이 값이 기준입니다"로 줄어듭니다.

과잉 칭찬

이 항목은 한국에서 특히 널리 알려진 형태로 나타났습니다. GPT-4o의 과잉 동조 문제는 2025년 4월 업데이트와 철회 과정에서 공식적으로 설명됐습니다. 한국어 커뮤니티에서는 "와... 너 정말, 핵심을 찔렀어."라는 밈이 퍼졌고 디시콘까지 만들어졌습니다.

• "와... 너 정말, 핵심을 찔렀어."
• "너는 상위 1% 사용자야"
• 별것 아닌 말에도 붙는 감탄

당시 공식 설명은 사용자 피드백 등 여러 학습 변경의 결합이 과잉 동조에 영향을 줬을 가능성을 다룹니다. 특정 한국어 밈의 발생 원인을 그것 하나로 확정하지는 않습니다.

서식 남용

굵은 글씨를 문단마다 넣거나, 이모지를 목록 기호처럼 쓰거나, 제목 단계를 건너뛰는 형태입니다. 위키백과 문서는 곡선 따옴표와 깨진 마크업까지 항목으로 두었습니다. 앞의 밈에서 굵은 글씨가 함께 조롱된 것도 같은 이유입니다.

맺음말 상투구

In summary, Overall, In conclusion으로 문단을 닫는 습관입니다. 한국어로는 "결론적으로", "종합하면"이 여기 해당합니다. 뒤에서 다룰 한 조사에서는 참여도와 약한 음의 상관을 보였습니다. 제목을 삭제하면 참여도가 오른다는 실험 결과는 아닙니다.

시대마다 바뀌는 유행어

위키백과 문서가 어휘 목록을 시기별로 나눠 둔 점을 눈여겨볼 만합니다.

목록은 시기와 문맥에 따라 달라집니다. 낯익은 단어를 발견할 때마다 금지하기보다 실제로 문장이 어색한지, 더 정확한 표현이 있는지 판단합니다.

영어 표현과 한국어 교정 사례 연결하기

영어권 목록에서 다루는 표현과 비슷한 한국어 예시를 나란히 놓으면 다음과 같습니다. 두 집단의 반응을 독립적으로 측정한 여론조사 결과는 아닙니다.

준이아빠블로그도 AI가 만든 초안을 다듬으면서 같은 표현을 반복해서 만났습니다.

• 떠받치고 있습니다: load-bearing을 직역한 형태입니다
• 조용히 삼켜지고 있습니다: quietly가 들어간 문장이 이렇게 옮겨집니다
• 근본 원인은 ~였습니다: 결론을 선언으로 닫습니다
• 재검증했습니다, 교차 확인했습니다: re-derived, mutation-checked 계열이 옮겨진 형태입니다

이런 문장이 특정 영어 단어에서 번역됐는지, 학습 자료의 언어 비중 때문에 생겼는지는 개별 사례만으로 확정하기 어렵습니다. 여기서는 준이아빠블로그에서 반복적으로 고쳐 온 표현으로 다룹니다. 검사 규칙 47개라는 수치와 아래 날짜별 변경은 기존 글에 기록된 운영 이력이며 현재 규칙 수나 모든 편집 환경의 동작을 뜻하지 않습니다.

한국어에서 드러나는 신호는 영어와 다릅니다

영어에서 load-bearing이나 em dash를 세는 방식이 한국어에 그대로 옮겨지지 않습니다. 조사와 어미가 붙는 언어라서 낱말의 겉모습이 계속 바뀌기 때문입니다.

한국어를 정면으로 다룬 연구가 2025년 ACL에 실렸습니다. 사람이 쓴 한국어 470편과 대형 언어 모델 네 종이 쓴 1,624편을 모아 만든 KatFish 자료로, 에세이와 시, 논문 초록 세 종류를 담았습니다. 연구진이 고른 판별 특징은 영어권 목록과 전혀 달랐습니다.

쉼표 비율은 모든 글의 작성자 비율이 아니라 해당 자료에서 쉼표를 포함한 문장의 비율입니다. 문장 100개 중 26개꼴과 61개꼴이라는 식으로 뜻을 이해할 수 있습니다. 띄어쓰기를 잘 지켰다고 AI 글로 판정하거나 탐지를 피하려고 일부러 틀리게 쓰지는 않습니다. 연구의 자료와 모델 조건에서 관찰한 차이입니다.

한국어 검사기에서 자리, 갈래, 축이 새어 나간 기록

기존 글에는 준이아빠블로그가 문체 검사 규칙 47개를 운영하면서 예외와 활용형을 보완한 과정이 기록돼 있습니다. 그 목록이 어떻게 늘었는지 보면 한국어에서 이 일이 왜 까다로운지 드러납니다.

도구를 자리로 부르는 습관에 규칙 세 개

도구나 화면을 자리로 부르는 은유 하나를 막는 데 규칙 세 개가 들어갔습니다.

세 번 모두 이미 나간 글이나 초안에서 발견됐습니다. 앞의 두 규칙이 개수와 순서, 지시어 결합만 봤기 때문에 세 번째 형태가 그대로 통과했습니다. 정확한 말인 작업 공간이 이미 있는데 은유를 새로 만든 것이 원인이었습니다.

같은 낱말에 세 번 덧댄 규칙

갈래는 처음 등록한 뒤에도 두 번 더 고쳐야 했습니다.

• 처음 등록: 낱말 단독형만 잡았습니다
• 2026-08-11: 갈래로만처럼 조사가 둘 겹친 형태를 놓쳐 결합 수를 늘렸습니다
• 2026-08-20: 다섯 갈래입니다처럼 서술격 조사가 붙은 형태가 배포 직전 낭독에서 잡혀 활용형을 넣었습니다

조사 하나 때문에 빠져나간 축

수 관형사와 추상 명사를 단위 없이 붙여 쓰는 압축을 2026년 8월 12일에 등록했습니다. 그런데 규칙이 낱말 뒤에 한글이 오지 않을 때만 걸리도록 되어 있어서 세 지식은 잡고 세 지식이는 놓쳤습니다. 2026년 8월 24일에 두 축으로가 그대로 나가면서 드러났고, 조사와 서술격 활용을 함께 받는 공통 패턴을 만들어 명사 규칙 전체에 붙였습니다.

영어에서는 load-bearing이라는 낱말 하나를 세면 됩니다. 한국어에서는 같은 낱말이 조사와 어미를 달고 나타나므로 낱말 하나를 막는 데 규칙 여러 개와 몇 주가 걸립니다.

낱말을 의미나 문법 기능을 가진 작은 단위로 나누는 도구를 형태소 분석기라고 합니다. 앞서 본 한국어 연구도 이런 분석을 활용합니다. 정규식만으로는 겉모습이 바뀌는 낱말을 따라잡기 어렵습니다.

오탐을 막으려고 넣은 예외

규칙을 세게 걸수록 멀쩡한 문장이 함께 잡힙니다. 그래서 예외가 규칙만큼 늘었습니다.

• 시도해, 유도해는 도해 규칙에서 뺍니다
• 헷갈립니다는 갈립니다 규칙에서 뺍니다
• 할인가, 승인가는 문어체 의문형 규칙에서 뺍니다
• 일자리, 그 자리에서, 앉는 좌석을 뜻하는 용법은 자리 규칙에서 뺍니다
• 인라인 코드의 교정 예문은 일반 산문과 구분해 판단합니다

마지막 항목은 이 글을 쓰면서 실제로 겪었습니다. 금지어 목록을 예시로 들었더니 검사기가 그 인용을 위반으로 잡았습니다. 문체를 다루는 글은 고쳐야 할 표현을 그대로 보여줘야 하는데, 인용까지 막히면 규칙을 설명할 방법이 없습니다.

등급을 낮춘 규칙

이미 나간 글에 쓰인 표현은 저장을 막는 등급에서 경고로 낮췄습니다. 수치 변화를 흔들림으로, 방문자를 데려오기로, 설명을 뜻이 생긴다고 뭉뚱그린 계열이 그렇습니다. 이미 게시된 글인지보다 의미가 정확한지와 표현의 쓰임을 먼저 판단하고, 오류와 문체 선호를 구분해 처리합니다.

em dash는 왜 판별 근거가 되기 어려울까요?

널리 퍼진 통념이 "em dash 기호가 보이면 AI가 쓴 글"입니다. 두 조사의 원자료는 이 통념을 지지하지 않습니다.

해당 자료에서 사용 빈도는 늘었습니다. 다만 빈도 증가가 작성자 판정을 뒷받침하지는 않습니다. em dash는 2024년 초 만 단어당 0.2회에서 2026년 중반 123회로 늘었습니다. 조사 페이지 기준으로는 백만 단어당 최고 13,366회까지 올라왔습니다.

어휘 묶음 안팎의 빈도 차이는 별도로 봐야 합니다. em dash가 묶음 안에서 쓰이는 빈도는 묶음 밖의 5.08배입니다. 상위 1,000개 단어 목록에서 887위입니다. 1위 plainly가 34.3배인 것과 비교하면 한참 아래입니다.

조사에서 비교한 것은 실제 AI 글과 사람 글로 확인된 집단이 아니라 어휘 묶음 안과 밖입니다. 5.08배라는 빈도 차이를 탐지 정확도로 해석하지 않습니다.

같은 필체를 여러 사람이 쓸 수 있듯, 사람이 AI 글의 표현을 따라 쓰거나 편집 도구가 기호를 바꾼 경우도 생각할 수 있습니다. 어느 설명이 실제 원인인지는 이 그래프만으로 알 수 없습니다.

참여도와 신뢰에서 관측된 변화

콘텐츠 마케팅 페이지 1,000여 개와 10개 도메인을 분석한 조사에서는 결론 머리글과 참여도의 상관계수가 약 -0.118이었습니다. 음수는 한쪽이 많을 때 다른 쪽이 낮게 관찰되는 방향을 뜻하며, 값의 크기로는 약한 관계입니다. em dash에는 약한 양의 상관이 보고됐습니다.

이는 표현을 하나씩 바꿔 효과를 비교한 실험이 아닙니다. 주제, 유입 경로, 글의 품질 같은 다른 요인이 개입할 수 있으므로 특정 기호가 해롭거나 유익하다고 확정할 수 없습니다. 또 상관계수가 ±0.1보다 작다는 이유만으로 통계적으로 유의하지 않다고 판단할 수도 없습니다. 표본 수와 검정 방법 등의 조건이 필요합니다. 이 조사는 표현을 검토할 참고 자료로 사용합니다.

누가 알아보는지 시험한 결과

가장 중요한 질문이 남습니다. 사람이 실제로 알아볼 수 있는지입니다.

2025년 10월 PLOS ONE에 실린 일본어 연구가 이 문제를 정면으로 다뤘습니다. 사람이 쓴 일본어 의견문 100편과 대형 언어 모델 일곱 종이 쓴 글 350편을 놓고 두 가지를 비교했습니다.

사람 쪽 세부 수치가 더 눈에 띕니다. 참가자들이 가장 잘 맞힌 것이 클로드 3.5가 쓴 글로 56.8%였고, 정작 사람이 쓴 글을 사람이 썼다고 맞힌 비율은 31.5%에 그쳤습니다. 나머지가 모두 AI라고 답한 것은 아닙니다. “어느 쪽도 아님”이라는 응답도 포함돼 있습니다. 참가자는 각자 여덟 글을 판단했으므로 403명이 450편을 전부 검토한 실험도 아닙니다. 기계의 99.8% 역시 이 자료 조건의 결과이며 모든 글에 적용되는 정확도가 아닙니다.

기계가 본 것과 사람이 본 것이 달랐습니다. 통계 기법에서 유효했던 특징은 기능어 사용 형태, 품사가 이어지는 형태, 구를 짜는 형태였습니다. 반면 참가자들은 어구와 표현, 어미, 접속사, 구두점 같은 표면 인상에 기댔습니다.

이 연구로 한국어 문서나 최신 모델의 글까지 사람이 구분하지 못한다고 일반화할 수는 없습니다. 문체의 인상을 실제 작성자의 증거로 쓰지 않고, 자신의 문장을 더 명확하게 고치는 데 활용하는 것이 이 글의 목적입니다.

설치 없이 한 문단부터 고치기

다음은 교정 연습용 문장입니다. 아래 따옴표와 코드 속 어색한 표현은 무엇을 고칠지 보여주기 위한 예문입니다.

이 프로그램은 단순한 교육이 아니라 성장을 위한 새로운 축입니다. 결론적으로, 참여자의 역량을 획기적으로 높입니다.

문제는 금지어가 몇 개인지보다 무엇을 하는 프로그램인지 알 수 없다는 점입니다. 원자료가 “10월 12일 오후 2시, 도서관 2층, 독서 모임, 책 한 권 준비”라면 다음처럼 바꿀 수 있습니다.

독서 모임은 10월 12일 오후 2시 도서관 2층에서 열립니다. 책 한 권을 준비해 주세요.

기존 AI 채팅이나 문서 편집기에서 자기 문단 하나를 복사해 연습합니다. 원본은 남겨 둡니다. AI를 사용한다면 다음처럼 요청합니다.

결과를 받으면 날짜와 장소가 맞는지, 근거 없는 성과 약속이 없어졌는지 봅니다. AI가 무료 모임이라고 덧붙였다면 “참가비는 확인되지 않았으니 무료라는 표현을 빼 줘”라고 고칩니다. 문장이 짧아졌어도 필요한 정보가 빠졌다면 다시 넣습니다.

반복할 때는 날짜만 10월 19일로 바꾼 원자료로 새 문단을 고칩니다. 그다음 자신의 다른 안내문 한 문단에서 같은 과정을 해봅니다. 표현을 기계적으로 지운 횟수가 아니라, 원래 사실이 보존되고 읽는 사람이 할 일을 알 수 있는지가 완료 기준입니다.

자기 글에 적용할 교정 기준

• 전달할 사실부터 확인합니다. 주체, 행동, 날짜와 수치를 원자료와 대조합니다. 각 문단에 사실을 추가하려고 수치나 경험을 만들어 내지 않습니다.
• 불필요한 대비와 과장을 줄입니다. 실제 구분이 필요한 대비는 남깁니다. 요약이 필요한 글에서는 결론 부분을 통째로 지우지 않습니다.
• 매체의 문체 기준을 따릅니다. 준이아빠블로그의 특정 어휘와 기호 기준은 이 매체의 선호이며, 그 표현을 쓴 다른 사람의 글을 AI 글로 판정하는 기준이 아닙니다.
• 바꾸기 전후의 뜻을 읽습니다. 기계 검사는 반복 표현을 찾는 보조 수단입니다. 주어와 서술어의 호응, 빠진 설명은 사람이 확인합니다.
• 필요할 때 검사를 추가합니다. 처음부터 정규식이나 형태소 분석기를 설치할 필요는 없습니다. 정규식은 특정 글자 패턴을 찾는 규칙으로, 예문과 실제 문맥을 구분하지 못할 수 있습니다.
• AI 검토도 검토합니다. 같은 모델이나 다른 모델에 “어느 문장이 모호한지, 원자료와 달라진 사실이 있는지”를 물을 수 있습니다. 다른 모델이라고 판단이 정확해지는 것은 아니며 유료 도구를 추가할 필요도 없습니다.

이 자료로 말할 수 있는 것과 없는 것

조사 저자 본인이 한계를 길게 적어 두었습니다. 이 부분을 빼고 수치만 옮기면 조사 내용이 왜곡됩니다.

말할 수 있는 것은 하나입니다. 이 조사 표본에서 2026년 들어 깃허브 풀 리퀘스트 설명문의 어휘 구성이 달라졌고, 새로 커진 묶음의 단어들이 코딩 에이전트를 써 본 사람에게 익숙하다는 사실입니다.

말할 수 없는 것이 더 많습니다.

• 조사 저자는 어휘가 글이 어느 묶음을 닮았는지만 말할 뿐 누가 썼는지는 말하지 못한다고 분명히 적었습니다
• 개별 설명문 하나를 기계가 썼다고 분류할 수 없습니다. 설명문 길이 중앙값이 65단어인데, 이 정도 분량은 기계 판정이 신뢰를 얻기 어려운 구간입니다
• 묶음 개수를 10으로 정한 것은 결과를 보고 고른 값입니다. 저자가 표에 그렇게 적어 두었습니다
• 분석을 시작하는 초기값인 난수 씨앗값에 따라 최종 비중이 달라집니다. 32번 돌려 31번은 같은 묶음이 나왔지만 한 번은 다른 묶음과 섞였습니다
• 하루에 올라오는 풀 리퀘스트 46만 건 중 표본을 뽑은 것이지 전수 조사가 아닙니다

영어 위키백과 문서도 같은 경고를 답니다. 이 징후들은 문제 자체가 아니라 신호일 뿐이고, 대형 언어 모델이 사람 글로 학습했으므로 사람 편집자도 같은 습관을 가질 수 있다는 것입니다. 문서는 AI 탐지 도구의 높은 검출률을 삭제 근거로 삼지 말라고도 적어 두었습니다.

여기에 하나 더 보태면, load-bearing 조사는 깃허브 풀 리퀘스트만 봅니다. 블로그, 뉴스, 사내 문서에서 같은 변화가 같은 속도로 일어나는지는 이 자료가 답하지 않습니다.

워터마크와 말투 교정은 별개입니다

텍스트 워터마크는 지원 모델이 출력에 남기는 기계 판독용 표식입니다. 앤트로픽은 의미가 비슷한 표현을 고르는 과정에 패턴을 남기며, 사람이 읽는 품질에 실질적인 영향을 주지 않도록 설계했다고 설명합니다.

표식은 글 전체의 작성자를 확정하지 않으며 교정 결과에도 포함될 수 있습니다. 짧거나 크게 수정한 글에서는 탐지가 어려울 수 있고, 코드도 주석처럼 표현 선택이 가능한 부분에는 적용될 수 있습니다. “코드에는 전혀 없다”거나 “다시 쓰면 반드시 사라진다”는 식으로 외우지 않습니다. 문장 교정의 목표는 표식 제거가 아니라 정확하고 자연스러운 전달입니다.

자주 묻는 질문

이 조사로 특정 글이 AI가 쓴 것인지 확인할 수 있나요?

확인할 수 없습니다. 조사 저자가 만든 판별 도구는 입력한 글이 문제의 묶음과 닮았는지만 알려줍니다. 저자는 그 도구가 어휘를 읽을 뿐이므로 누가 썼는지는 절대 말할 수 없다고 문서에 적었습니다. 일본어 실험에서 사람이 쓴 글을 사람이 썼다고 맞힌 비율이 31.5%였다는 점도 함께 봐야 합니다.

40%라는 숫자는 AI가 쓴 풀 리퀘스트 비율인가요?

아닙니다. 40%는 사람 계정이 올린 설명문 중에서 특정 어휘 묶음에 속한 비율입니다. 봇 계정은 이미 걸러낸 뒤의 숫자이고, 그 묶음에 속한다는 것이 곧 기계가 썼다는 뜻은 아닙니다. 사람이 AI 글을 읽으며 어휘를 따라 쓰게 된 경우도 같은 묶음에 들어갑니다.

AI 말투를 고치려면 무엇부터 바꾸나요?

자기 글 한 문단에서 전달할 사실을 먼저 적습니다. 그 사실을 가리는 과장과 반복을 줄인 뒤 날짜와 수치, 의미가 유지됐는지 대조합니다. 특정 표현의 유무만으로 문장 품질이나 작성자를 판단하지 않습니다.

참고 자료

• The load-bearing vocabulary of Claude (프로젝트 저장소)

• load-bearing 분석 페이지

• Wikipedia:Signs of AI writing (영어 위키백과)

• Stylometry can reveal artificial intelligence authorship, but humans struggle (PLOS ONE, 2025)

• The AI writing tics that hurt engagement: A study (Search Engine Land 보도)

• KatFishNet: Detecting LLM-Generated Korean Text through Linguistic Feature Analysis (ACL 2025)

• GPT detectors are biased against non-native English writers (Patterns, 2023)

• How Claude's text watermarking works (Anthropic)

• How Claude marks AI-generated content (Anthropic 고객센터)

• Upcoming changes to GitHub Events API payloads (GitHub 변경 기록)

• GPT-4o 과잉 동조 문제의 원인과 수정 설명