AI humanizer 에서는 인용구, 표, 수식이 어떻게 되나요?

Turnitin 은 AI writing report 를 처리할 때 참고문헌을 제외하며, 보고서가 분석하는 것은 일반 문장뿐입니다. 따라서 참고문헌 목록을 다시 작성해도 숫자에는 영향이 없습니다. 다만 참고문헌 자체를 잃을 위험은 있습니다. 문장이 합쳐지거나 나뉘면서 표식이 이동하고, 참고문헌 관리자 필드가 죽은 텍스트로 변하며, 한 기록된 검토에서는 참고문헌 목록을 다시 작성한 도구가 입력에 없던 인용구를 만들어냈습니다.

아래 내용은 모두 그 두 번째 문장에 관한 것입니다. 바로 아무도 예상하지 못하는 부분이니까요.

재작성 도구에는 두 가지 유형이 있으며, 각각 다르게 실패합니다.

첫 번째 유형은 텍스트 상자를 사용합니다. 붙여넣으면 재작성하고, 다시 붙여넣습니다. 도구는 문서를 직접 보지 못하므로, 표나 필드에 관한 질문은 실제로 붙여넣기 전후에 당신이 무엇을 했는지에 관한 것입니다. 파일에 있던 구조는 당신이 손으로 제거했고, 이제 다시 손으로 넣어주게 됩니다.

두 번째 유형은 파일 자체를 가져갑니다. 문서를 열고 안에 있는 텍스트 덩어리를 찾아 일부는 재작성한 뒤 문서를 다시 저장합니다. 이런 도구는 구조를 보존할 수도 있지만, 한 번에 모든 문장을 처리하다 보니 당신이 수동으로 절대 관리할 수 없는 규모로 구조를 깨뜨리기도 합니다.

어느 유형도 기본적으로 안전하지 않습니다. 결과를 결정하는 것은 범위입니다. 문서의 얼마나 많은 부분이 재작성되는지, 그리고 실행 전에 그 경계를 볼 수 있었는지가 중요합니다.

Turnitin 이 자체적으로 설명한 탐지 메커니즘을 한 번쯤 읽어볼 가치가 있습니다. 인용구가 탐지기 측에서 어떻게 보호되지 못하는지 이해할 수 있거든요. 제출물은 겹치는 세그먼트로 나뉘고, 각 세그먼트는 0 에서 1 사이로 점수가 매겨집니다. 해당 기준에 맞는 문장은 자신을 덮는 세그먼트들의 값을 가져가고, 이 값들이 모여 보고서에 표시되는 숫자로 집계됩니다 (AI writing detection FAQs). 이 순서 어디에도 인용구를 인식하는 단계는 없습니다.

재작성 도구에서도 같은 맹점이 반대로 작용합니다. 산문을 재작성하는 모델에게 `(Smith, 2019)` 는 문장 안에 놓인 문자열일 뿐이며, 이를 중요한 부분으로 표시하는 것은 아무것도 없습니다. 두 문장을 합치면 표식이 그 출처가 결코 하지 않은 주장 뒤에 남게 됩니다. 문장을 나누면 절반은 표식을 유지하고 나머지 절반은 완벽하게 읽히지만 근거 없는 진술이 됩니다.

그 실패는 교정으로는 드러나지 않습니다. 문법상 틀린 것도, 빠진 것도 없기 때문입니다. 문장은 스스로를 지탱합니다. 다만 더 이상 출처가 말한 바를 말하지 않을 뿐입니다. 그 연결을 하나하나 검토하는 방법은 인용망을 끊지 않고 문헌 고찰 수정하기 에서 다뤘습니다.

두 번째 실패는 의미론적이기보다 기계적입니다. Zotero, Mendeley, EndNote 에서 나온 인용구는 텍스트가 아닙니다. 필드이며, 일반 텍스트 라운드를 거치면 똑같이 생겼지만 더 이상 업데이트되지 않는 문자로 변합니다. Word 필드, 목차 및 상호참조 에서 긴 문서에서 이것이 어떤 비용을 치르는지 설명합니다.

이건 가정이 아닙니다. 제 주장보다 다른 사람의 기록을 가리키는 편이 낫겠습니다.

Tadhg Blommerde 는 Northumbria University 에서 강의하며, 강사용 Turnitin 접근 권한을 가지고 있고, 자기 리뷰 설명에서 이 리뷰들이 후원이 없으며 제휴 링크도 없다고 밝힙니다.

2025 년 2 월 리뷰 에서 그가 사용한 방법이 발견 사항을 검증 가능하게 만듭니다. 테스트 에세이는 그의 글이 아닙니다. ChatGPT 에게 요청했죠—"1,500 words in UK English", "intext citations and a reference list in the APA style"—그래서 다른 작업이 시작되기 전에 화면에 알려진 입력이 존재하게 됩니다. 그 파일은 Walter Writes 를 거쳤고, 그는 그것이 "even humanized the reference list"라고 보고했습니다. 또한 출력의 인용구에서 멈춰서 중요한 부분을 지적했는데, 그 내용은 ChatGPT 버전에는 없었습니다.

바로 그 이유로 두 번째 발견이 첫 번째보다 더 가치가 있습니다. 망가진 참고문헌은 결국 알아차릴 수 있는 오류입니다. 하지만 아무도 쓰지 않은 인용구는 당신이 이름 붙이려는 문서 속에 자리한 조작된 출처이며, 그것이 조작되었다고 말할 수 있는 유일한 이유는 입력물이 영상에서 먼저 생성되어 출력과 일대일로 비교될 수 있었기 때문입니다.

이 주제에서 찾을 수 있는 유일한 공개 데이터셋에는 공개된 설명이 함께 제공됩니다. 그 설명은 숫자와 함께 따라다녀야 합니다. HumanizerBench 는 WriteHuman 이 운영하며, 그들이 게시하는 리더보드의 열두 개 도구 중 하나이고, 제가 인용하려는 주기에서 1 위를 차지한 도구입니다. 이건 제가 알아낸 것이 아닙니다. 그들은 소개 페이지 와 사이트의 모든 페이지 하단에서 직접 언급하고 있습니다. 그러므로 '독립적'이라는 말은 누가 인용하든 붙일 수 없는 단어입니다.

하지만 이 카테고리와 달리 이 벤치마크는 파일을 제공합니다. 2026 년 8 월 주기의 모든 입력과 출력은 CC BY 4.0 으로 공개 저장소 에 올라와 있습니다. 그것이 누가 운영하든 관계없이 유용하게 쓸 수 있는 이유입니다. 누구의 요약에 동의하지 않아도, 이 요약도 포함해서, 같은 파일을 열고 세어보면 되기 때문입니다.

자, 셀 가치가 있는 부분입니다. 규칙은 간단합니다—마크다운 제목은 해시로 시작하는 줄이며, 재작성 후에도 거기에 있거나 없는 것입니다. 해당 주기의 열두 개 도구 중 네 개는 출력에 제목이 하나도 남지 않았고, 세 개는 입력에 있던 모든 제목을 반환했습니다. "이 도구들은 포맷을 모두 파괴한다"는 믿기 편한 생각이지만, 공개된 파일들은 그것을 지지하지 않습니다. 이 카테고리 내의 편차가 전체 범위입니다.

그다음은 측정의 한계입니다. 이는 어떤 백분율보다 더 중요합니다. 세어지는 것은 일반 텍스트 줄 시작의 해시 문자입니다. 그 데이터셋의 모든 도구는 붙여넣기 입력, 붙여내기 출력입니다. `.docx` 는 어디에도 오가지 않습니다. 스타일, 번호 정의, 표 객체, 각주 부분, 상호참조 북마크, TOC 필드는 다른 레이어에 살며, 저는 그 레이어에 근접한 공개 데이터셋을 전혀 찾을 수 없었습니다.

그래서 우리가 직접 셌습니다. 우리 output 으로요. 이건 우리가 우리를 측정한 것입니다—자체 실행에서 나온 세 개의 전후 쌍을, 제품이 스스로 보고하는 것을 신뢰하는 대신 `word/document.xml` 을 열어 읽는 스크립트로 판독했습니다. 그중 가장 큰 것을 가져가 보죠: 비어 있지 않은 문단 405 개, 제목 스타일을 가진 문단 46 개, 7 행 14 개의 셀을 가진 표 하나. 이후에 세 카운트 모두 동일했습니다.

두 가지 조건이 있으며, 두 번째가 중요합니다.

제목이 제목으로 살아남았다고 해서 wording 이 살아남은 것은 아닙니다. 그 46 개 제목 중 18 개는 balanced 설정에서 다른 단어로 돌아왔으며, 여전히 같은 스타일에 연결되어 있었습니다. 단어 재작성과 본문 텍스트로 평평해지는 것은 별개의 사건이며, 이전 섹션의 마크다운 카운트는 두 번째 것을 잡아냅니다.

더 큰 한계는 코퍼스에 없었던 것입니다. 목차 필드 없음, 상호참조 없음, 각주 없음: 패키지 어딘가에 `fldChar` 0 개, 앵커 없음, `footnotes.xml` 없음. 바로 이것들이 조용히 깨질 가능성이 가장 높은 부분들입니다. 각주 표식과 각주 자체는 패키지 내 서로 다른 파일에 위치하며, 숫자로만 연결됩니다. 그중 어느 것도 자신이 속한 단어 옆에 저장되지 않습니다.

우리의 숫자를 재현할 수는 없습니다. 파일은 우리가 게시할 것이 아니며, 공급자의 코퍼스에서 나온 숫자는 대략 당신이 기대할 만합니다. 하지만 절차는 재현할 수 있습니다. 실제로 관심 있는 문서에서, 오후에: `.docx` 를 복사하고, 복사본을 `.zip` 으로 이름 바꾸고, `word/document.xml` 을 열고, 비어 있지 않은 `<w:p>` 요소 수를 세고, 그중 이름이 `Heading` 으로 시작하는 문단 스타일을 가진 것이 몇 개인지 세고, 패키지에서 `fldChar` 와 `footnotes.xml` 을 검색하세요. 고려 중인 도구에 대해 전후로 해보세요. 우리 것도 포함입니다. 그러면 얻는 숫자는 우리 파일 세 개가 아니라 당신의 논문에 관한 것입니다.

자기 도구가 상호참조를 보존한다고 말하는 사람이라면 누구든—우리도 포함해서—무엇을 세었는지 물어봐야 마땅합니다.

Turnitin 의 AI writing detection model 페이지에는 릴리스 노트가 있으며, 2023 년 8 월 9 일 항목에는 이 모델이 이제 표 안의 장문 산문 텍스트를 처리할 수 있게 되었다고 나옵니다. 같은 항목에서 표가 포함된 기존 제출물은 재처리 전에 다시 제출해야 한다고 덧붙입니다.

두 가지 결론이 나옵니다. 표 셀 안의 산문은 AI 하이라이팅을 가질 수 있으므로 "표 안에 있으니까 상관없다"는 3 년이나 낡았습니다. 그리고 이는 표도 재작성 도구의 범위 안에 넣습니다. 셀이 점수에 포함된다면, 파일 단위 도구에는 셀 단위로 들어갈 이유가 있습니다.

셀 안에서 다른 도구들이 무엇을 하는지는 측정하지 않았으므로, 이 단락의 나머지는 발견 사항이 아니라 살펴봐야 할 곳으로 취급하세요. 두 문단을 담았던 셀은 다시 열어볼 가치가 있습니다. 텍스트가 길어지면서 커진 행도 마찬가지입니다. 결과 표에서 먼저 확인해야 할 셀은 단위와 함께 숫자를 담은 셀입니다. 표에서 문장과 가장 비슷한 콘텐츠이니까요.

수식에 관해서는 제공할 측정이 없습니다. 차라리 그렇게 말하는 편이 확실한 단어로 메꾸는 것보다 낫겠습니다. 우리 코퍼스에는 없었습니다.

드릴 수 있는 것은 중요한 경계이며, 실제로 수식에 관한 것이 아닙니다. 가치가 값 자체인 모든 것에 관한 것입니다. 인용된 문장은 따옴표 안의 단어가 그대로 돌아와야 인용으로 남습니다. 표본 크기, p 값, 신뢰구간, 단위, 날짜, 고유명사는 문자 그대로 살아남아야 합니다. 산문은 움직일 수 있습니다. 이것들은 불가능합니다.

Methods 와 Results 에서 수정 가능한 것과 정확함을 유지해야 할 것 이 논문을 두 열로 올바르게 나눕니다.

1. Word 에서 파일을 열고 Ctrl+A 를 누른 다음 F9 를 누르세요. 살아남은 필드가 새로고침됩니다. 평평해진 필드는 아무것도 하지 않은 채 거기에 있으며, 그렇게 찾아냅니다.
2. 전후로 참고문헌 항목 수를 세세요. 바뀐 숫자는 가장 큰 신호이며, 10 초 걸립니다.
3. 출력으로 모든 본문 표식을 검색하고 그것이 이제 속한 문장이 여전히 그 주장을 만드는지 확인하세요. 이게 느린 것입니다. 하지만 조작된 지원을 잡아내는 것입니다.
4. 숫자를 담고 있는 모든 표 셀을 읽으세요. 그 주변의 산문이 아닙니다. 셀 자체를요.
5. 인용된 자료를 diff 하세요. 따옴표 사이의 모든 것은 소스와 바이트 단위 identical 해야 합니다.

이것의 전체 버전은 반복 가능하게 만드는 파일 버전 설정과 함께 제출 전 humanized Word 문서 검토 방법 에 있습니다.

HumanPen 뒤에 있는 전제는 "무엇이 수정되었는지"가 나중에 Word 에서 발견하는 답이 아니라 당신이 주는 답이어야 한다는 것입니다.

엔진은 문단보다 작은 것은 재작성하지 않습니다. 문단 중간에서 선택을 멈추면 전체 문단이 재작성되며, 실행 전에 그 경계를 볼 수 있습니다. 직접 경계를 설정하거나 Turnitin, iThenticate 보고서를 가져와 플래그된 부분이 설정하게 할 수 있으며, 이 경우 플래그된 텍스트만 재작성됩니다. 실제로 재작성된 단어 수만큼 크레딧이 계산되므로, 4 개 문단으로 스코프된 작업은 논문 전체가 아니라 4 개 문단으로 가격이 책정됩니다. 조건을 충족하는 결과는 무료로 계속 AI 를 낮출 수 있습니다.

우리 FAQ 는 그 섹션을 "다운로드 후 복잡한 문서를 검토하라"로 끝내며, 그 줄은 빼지 않았습니다. 복잡한 문서의 재작성은 당신이 점검하는 것입니다. 범위가 당신에게 주는 것은 훨씬 짧은 점검 목록입니다.

humanizer 가 참고문헌 목록을 바꾸나요? 참고문헌 목록이 범위에 있었는지에 전적으로 달려 있습니다. 참고문헌은 AI 숫자에 도움이 되지 않습니다. Turnitin 의 릴리스 노트에 참고문헌이 AI writing report 처리 시 제외된다고 나와 있으므로, 애초에 범위에 있을 이유가 없습니다. 한 도구의 기록된 검토에서는 참고문헌 목록이 어쨌든 재작성되는 것을 보여줍니다.

본문 인용구가 이후에도 참고문헌과 일치할까요? 표식은 대개 문자로 살아남습니다. 끊어지는 것은 표식과 주장 사이의 연결입니다. 문장이 그 주변에서 합쳐지거나 나뉠 때요. 괄호가 아니라 문장을 점검하세요.

표를 재작성하나요? 그럴 수 있습니다. Turnitin 이 표 안의 장문 산문을 분석하므로, 도구가 들어갈 이유가 있습니다. 숫자, 단위, 짧은 라벨을 담고 있는 셀이 먼저 점검해야 할 것입니다.

왜 목차가 깨졌나요? 거의 항상 문서가 일반 텍스트 단계를 거쳤기 때문입니다. TOC 는 필드이며 텍스트가 아닙니다. 문서를 문자열로 평평하게 하면 필드는 사라집니다. 단어가 여전히 페이지에 있어도요.