Overleaf, LaTeX, Turnitin: 컴파일된 PDF가 바꿀 수 있는 것

Turnitin은 PDF를 받지만, 그것이 자사 비공개 추출기가 무엇을 보는지 알려 주지는 않습니다. 재현 가능한 저희 검증에서 mutool과 PyMuPDF는 동일한 2단 pdfTeX 파일에서 각각 공백으로 구분된 694단어를 반환했고, pypdf는 692단어를 반환했습니다. 텍스트 스트림을 형성한 것은 컴파일과 추출기 모두였습니다. 이것은 측정 가능합니다. Turnitin의 입력이나 점수에 대한 영향은 측정된 바가 아닙니다.

이 경계가 이 글 전체의 주제입니다. 소스와 PDF 3개, 원본 추출 스트림 9개, 측정 스크립트는 증거 패키지와 함께 보관되어 있습니다. 끝부분에 있는 5분 점검이야말로 자신의 논문에 적용할 버전입니다.

`.tex` 파일 하나: 표준 `article` 클래스, `twocolumn`, 10pt입니다. 초록, 번호가 붙은 네 개의 절, 본문 안 수식과 별도 수식, `itemize` 목록, 번호가 매겨진 의사 코드 줄이 있는 `algorithm` 환경, `table` 플로트, 완전한 문장으로 작성한 캡션이 붙은 `figure` 플로트, 줄이 바뀔 만큼 긴 각주 하나, 그리고 번호가 매겨진 참고문헌으로 해석되는 `\cite` 호출 두 개가 들어 있습니다. 2단 빌드는 두 쪽이 되고, 1단 대조 버전은 세 쪽이 됩니다.

pdfTeX 3.141592653-2.6-1.40.26, TeX Live 2024로 컴파일했습니다. 읽기에는 서로 독립적인 추출기 세 개, mutool 1.25.6, PyMuPDF 1.26.0, pypdf 6.4.0을 사용했습니다.

연속된 공백을 하나로 줄인 뒤, mutool과 PyMuPDF는 2단 pdfTeX PDF에서 각각 694단어를 반환했습니다. pypdf는 692단어를 반환했습니다. 세 스트림은 절의 큰 순서를 유지하지만, 두 단어의 차이는 독립적인 추출기가 동일한 객체를 본다는 편한 주장을 기각하기에 충분합니다.

2단 PDF를 제출할 때 가장 흔히 듣는 경고는 추출기가 두 단을 가로질러 그대로 읽어 논문을 뒤섞인 글로 만들어 버린다는 것입니다. 여기서는 그런 일이 일어나지 않았습니다. 첫 번째 단 맨 아래에 있는 초록의 마지막 문장은 두 번째 단 맨 위에 있는 서론의 첫 문장 바로 앞에 옵니다. 순서는 문서 전체에서 온전합니다.

레이아웃 하나, 클래스 하나, 추출기 세 개, 컴퓨터 한 대. 주장의 범위가 그것입니다. 플로트 배치가 특이하거나 사이드바가 있는 저널 고유의 `.cls`이라면 다르게 동작할 수 있습니다. 바로 그렇기 때문에 이 글 끝의 점검은 저희 파일이 아니라 실제 파일에 5분을 들일 가치가 있습니다.

대신 다른 것이 망가졌고, 그 문제는 훨씬 덜 논의됩니다.

다음은 PyMuPDF 스트림에서 그대로 가져온 부분입니다. 공백은 정규화했지만 인용한 양 끝 사이의 내용은 하나도 지우지 않았습니다.

"…justification for treating a visually correct page as a reliable 1This footnote is deliberately long enough to wrap onto a second line so that its position in the extracted stream can be observed and compared with nearby prose. 1 Table 1: Primary outcome by condition. Condition Mean SD Control 12.4 3.1 Intervention 18.9 2.7 Figure 1: The framed area is a fixture rather than a reported empirical result. text stream…" (…시각적으로 올바른 페이지를 신뢰할 수 있는 1이 각주는 추출된 스트림에서 그 위치를 관찰하고 주변 산문과 비교할 수 있도록 의도적으로 두 번째 줄로 넘어갈 만큼 길게 작성했습니다. 1 표 1: 조건별 주요 결과. 조건 평균 SD 대조군 12.4 3.1 중재 18.9 2.7 그림 1: 테두리 친 영역은 보고된 실증 결과가 아니라 검증용 장치입니다. 텍스트 스트림…)

소스에서 `reliable text stream`은 하나의 구입니다. 이 추출에서는 각주와 맨숫자 쪽 번호, 표 캡션과 그 셀, 그림 캡션이 모두 `reliable`와 `text stream` 사이에 들어갑니다. 각주 표시가 앞의 문장 부호에 붙어 `follows:1`처럼 나타나는 곳도 있습니다.

인용문에 있는 맨숫자 `1`은 쪽 번호입니다. 페이지 스트림을 이어 붙이면 그것은 각주와 표 사이에 놓입니다. 어느 쪽의 일부로도 독자가 인식하지 못하는 자리입니다.

이 가운데 PDF에 눈에 보이는 손상은 없습니다. 이것은 이름을 밝힌 이 로컬 추출기가 반환한 결과이며, 추출 방식을 알기 전에는 "앞 문장"과 "뒤 문장"이 안정적인 개념이 아니라는 점을 보여 줍니다.

LaTeX은 줄바꿈 지점에서 하이픈으로 단어를 나눌 수 있고, 단이 좁으면 그 기회가 늘어납니다. PyMuPDF는 저희의 2단 pdfTeX 빌드에서 분할된 토큰 22개를 찾았습니다. 그중 여섯 개는 다음과 같습니다.

예: ex- poses · differ- ences · specifica- tions · observa- tions · justifica- tion · partici- pants

그다음 같은 소스를 단일 단으로 컴파일하면서 클래스 옵션만 바꿨습니다. PyMuPDF는 정규화된 단어 678개를 반환했고, 분할된 토큰은 22개가 아니라 5개였습니다: `or- dinary`, `extrac- tion`, `jus- tification`, `partici- pants`, `par- ticular`.

같은 소스에 레이아웃 하나만 바꿨을 뿐인데 분할 위치가 달라졌습니다. 이것은 모든 클래스 파일에 대한 규칙이 아니라 하나의 사례지만, 소스의 토큰화가 그대로 남아 있다고 가정하지 말고 컴파일된 파일을 점검해야 할 근거로는 충분합니다.

같은 소스를 XeLaTeX로 세 번째로 컴파일했습니다. 2단 레이아웃도 같고 페이지의 단어도 같습니다.

pdfLaTeX 빌드에서는 세 도구 모두 합자 코드포인트 `ff`, `fi`, `fl`, `ffi` or `ffl`를 포함한 토큰을 하나도 노출하지 않았습니다. In the XeLaTeX build, PyMuPDF and pypdf each exposed six: `affiliated`, `affiliation`, `difficult`, `efficiency`, `insufficient`, `office` (XeLaTeX 빌드에서는 PyMuPDF와 pypdf가 각각 여섯 개를 노출했습니다). Mutool이 0개였던 것은 이 글리프를 보통 글자로 정규화했기 때문입니다. 따라서 `efficiency`을 단순 검색하면 한 스트림에서는 찾고 다른 스트림에서는 놓칩니다.

수식은 반대 방향으로 바뀌었습니다. pdfTeX 파일에서 mutool은 총합 기호에 대해 유니코드 대체 문자를 반환한 반면, PyMuPDF와 pypdf는 대문자 `X`를 반환했습니다. In the XeLaTeX file, all three exposed the actual `∑` (XeLaTeX 파일에서는 세 도구 모두 실제 기호를 노출했습니다). 컴파일러와 추출기가 모두 영향을 미쳤습니다.

여기서 인용한 Turnitin 페이지는 자사 추출기를 밝히거나 이러한 변환을 설명하지 않으며, 저희도 이것이 점수를 움직인다고 주장하는 것은 아닙니다. 저희가 말하는 것은 더 좁고 확인 가능한 사실입니다. 텍스트 레이어는 컴파일의 산물이며, 추출기에 따라 같은 PDF에서 서로 다른 문자가 드러날 수 있다는 점입니다.

공급업체 자체 문서 가운데 네 구절은 이런 형태의 논문에 직접 관련됩니다. 해당 페이지에는 더 많은 내용이 있지만, LaTeX 제출과 맞닿은 것은 이 네 가지입니다.

형식은 허용됩니다. Turnitin의 AI Writing Report 파일 요건에는 `.docx, .pdf, .txt, .rtf`가 나열되어 있습니다. 이는 PDF가 처리될 수 있음을 보여 줄 뿐, 어떤 추출 경로가 쓰이는지는 말해 주지 않습니다. Turnitin은 PDF에서 AI를 탐지할까요에서는 그 질문 가운데 문서화된 부분을 다룹니다.

산문만 집계됩니다. FAQ는 분석 대상이 되는 텍스트를 이렇게 정의합니다.

"This qualifying text includes only prose sentences, meaning that we only analyze blocks of text that are written in standard grammatical sentences and do not include other types of writing such as lists, bullet points (short non-sentence structures), or other non-sentence structures." (이 대상 텍스트에는 산문 문장만 포함됩니다. 즉, 표준 문법 문장으로 작성된 텍스트 블록만 분석하며, 목록이나 불릿 포인트(문장이 아닌 짧은 구조) 또는 그 밖의 비문장 구조는 포함하지 않습니다.)

그다음 문장이 기억해 둘 만한 문장입니다: "This percentage is not necessarily the percentage of the entire submission." (이 비율이 반드시 제출물 전체에 대한 비율인 것은 아닙니다.) `itemize` 불릿과 `algorithm` 줄은 문장이 아닙니다. 표의 셀 한 줄도 마찬가지입니다. Turnitin은 수식과 산문이 아닌 내용을 어떻게 처리할까요에서는 수식 위주의 논문에서 이것이 무엇을 뜻하는지 다룹니다. 다만 무엇이 집계되는지는 보십시오. `\caption`로 완전한 문장 형태로 작성한 캡션은, 대부분의 사람들이 그렇게 쓰듯, 스트림에서 본문 산문과 똑같이 도착합니다.

참고문헌은 제외됩니다. 2023년 8월 9일 자 릴리스 노트에는 참고문헌 안의 AI 작성 부분을 강조 표시하던 버그가 수정되었고 "Bibliographies are now excluded when processing the AI writing report" (AI 작성 리포트를 처리할 때 참고문헌은 이제 제외됩니다)라고 적혀 있으며, 같은 노트는 기존 제출물은 이 조치가 적용되려면 다시 제출해야 한다고 덧붙입니다. 공급업체가 공개하지 않는 것은 평탄화된 텍스트 스트림 안에서 참고문헌을 어떻게 식별하는가입니다. 저희 추출에서도 단서는 없습니다. `References`는 평범한 단어로 도착하고 그 뒤에 `[1] J. Smith, "A study of things," Journal of Testing, vol. 4, no. 2, pp. 100–110, 2019.`이 이어질 뿐, 경계를 표시하는 것은 아무것도 없습니다. 어느 쪽 해석에도 계획을 세우지 마십시오. 참고문헌 제외가 실제로 무엇을 다루는가에는 문서화된 것과 그렇지 않은 것이 정리되어 있습니다.

짧은 논문은 다르게 동작합니다. 문서가 수백 단어 수준으로 줄어들면, 공급업체 표현에 따르면 예측은 "mostly 'all or nothing' because we're predicting on a single segment without the opportunity to overlap" (겹칠 기회 없이 단일 세그먼트에 대해 예측하기 때문에, 예측이 대개 '전부 아니면 전무'가 됩니다) 상태가 되고, 다음 문장은 그 안의 혼합 콘텐츠가 전적으로 AI 생성으로 표시될 수 있다고 덧붙입니다. 절반이 수식인 6쪽 분량 학회 논문에는 대상 텍스트가 거의 없을 수도 있습니다. 짧은 문서와 전부-아니면-전무 문제에 그 메커니즘이 나와 있습니다.

`\cite{smith2019,jones2020}`는 추출 결과에서 네 문자 `[1, 2]`로 도착했습니다. `\ref{sec:method}`는 `2`로 도착했고, `\label`는 아무 흔적도 남기지 않았습니다. 절 제목은 번호와 제목이 분리된 채 도착하므로 `2 Method`는 앞 문장 바로 뒤에 놓이고, 앞서 있던 상호 참조 `Section 2 describes the method.`는 숫자 하나가 섞인 산문처럼 읽힙니다.

즉, 인용 서식을 전제로 세운 모든 계획은 존재하지 않는 것을 대상으로 삼고 있습니다. 추출된 텍스트에는 인용 객체가 없고 괄호와 숫자만 있으며, Turnitin이 공개한 계산 방식 설명 어디에도 인용은 등장하지 않습니다. Turnitin은 왜 내 참고문헌을 표시했을까요에는 여기서 비롯되는 구체적인 수정들과, 각각이 손댈 대상이 아무것도 없는 이유가 나와 있습니다.

저희가 쓴 도구는 필요하지 않습니다. 컴파일된 PDF를 사용 중인 뷰어에서 열고 전체를 선택해 일반 텍스트 편집기에 붙여넣으십시오. 이것은 또 하나의 추출 경로이며 Turnitin을 대신하지는 않지만, 실제로 제출하는 텍스트 레이어의 문제를 드러낼 수 있습니다.

다음 순서로 확인하십시오.

1. 분할된 단어. 하이픈 뒤에 줄바꿈이 오는 부분을 찾으십시오. 발견된 것은 모두 하나의 단어이기를 멈춘 단어입니다.
2. 플로트가 자리 잡은 곳. 표 캡션을 찾아 그 앞뒤 문장 두 개를 읽으십시오. 캡션과 셀이 문단 안에 들어가 있다면, 그것이 이제 그 문단의 읽기 순서입니다.
3. 캡션. 완전한 문장으로 된 캡션은 산문처럼 보입니다. 실제로 산문이기 때문입니다.
4. 수식. 붙여넣은 텍스트에서 별도 수식 하나를 읽어 보십시오. 눈에 보이는 것이 추출기가 얻은 것입니다. 문자가 빠졌거나 잘못됐다면, 그것은 대수학이 아니라 글꼴 삽입에 관한 사실입니다.
5. 참고문헌의 시작. 일반 텍스트에서 참고문헌 목록이 시작되는 지점을 무언가가 표시하는지 살펴보십시오. 저희 경우에는 아무것도 표시하지 않았습니다.
6. 이름과 소속. 이것도 텍스트 레이어에 들어 있습니다. 익명성을 기대하는 곳에 제출한다면 중요한 부분입니다.

`.tex`를 Git이나 Overleaf에 보관하고 있다면 마지막에 한 번이 아니라 큰 수정마다 한 번씩 하십시오. 그리고 Overleaf의 작성 기록이 증거로서 가치가 있는지라는 별개의 질문에 대해서는, Word·Google Docs·Overleaf에서 버전 기록이 있는 곳에 무료 플랜의 보관 규칙과 대응 방법이 나와 있습니다. 대부분이 예상하는 것보다 훨씬 구체적입니다.

LaTeX 논문의 답은 지루하지만 옳습니다. 소스를 고치고, 다시 컴파일하고, PDF는 절대 편집하지 마십시오. 문장은 `.tex` 파일에 있습니다. 나머지는 모두 그것을 렌더링한 결과일 뿐입니다.

이 흐름이 불편해지는 것은 PDF가 아닌 다른 지점에서 끝날 때입니다. 지도교수가 변경 추적을 원할 수도 있고, 저널이 Word 원고를 요구할 수도 있습니다. 또는 컴파일된 PDF를 대상으로 한 AI 작성 리포트를 돌려보내며 어떤 부분이 바뀔지 묻는 사람도 있습니다. 이제 같은 논문이 두 형식으로 존재하게 됩니다.

영어 DOCX 버전이라면 HumanPen 도구가 다시 쓰기를 사용자가 선택한 부분 또는 Turnitin·iThenticate 리포트에서 일치한 부분으로 제한할 수 있습니다. Humanize는 현재 영어만 지원하며 편집 가능한 소스로 `.tex`이나 컴파일된 PDF를 받지 않습니다. 문단 단위 범위를 확인하고, LaTeX 소스를 마스터로 유지하며, 다운로드 후 변환된 문서를 다시 점검하십시오. 조건을 충족하는 부분은 무료로 다시 실행할 수 있습니다.

PDF 대신 `.tex` 파일을 제출해야 할까요? 과제나 저널이 요구하는 것을 제출하십시오. `.tex` 파일은 마크업이 들어 있는 일반 텍스트이고, 그 안의 모든 명령은 문자 그대로의 문자로 도착합니다. 따라서 사람이든 다른 대상이든 어떤 독자에게도 더 깔끔한 버전이 아닙니다.

내 수식이 AI 점수를 올릴까요? 수식은 산문 문장이 아니므로 공급업체 정의에 따라 대상 텍스트 밖에 있습니다. 그 주변의 설명 문장은 안에 포함됩니다. 수식 위주의 논문이라면 그 숫자는 페이지의 작은 부분만을 대상으로 계산된다는 뜻입니다.

2단 형식 자체가 문제를 일으킬까요? 이 사례에서는 절의 큰 순서가 유지되었습니다. PyMuPDF에서 2단 빌드는 줄바꿈 분할이 22개, 1단 빌드는 5개였습니다. 이것은 이 클래스 파일에 대한 측정된 차이이며 모든 저널 템플릿에 대한 규칙은 아닙니다.

소속 기관은 Word 파일을 원하는데 저는 LaTeX으로 씁니다. 그렇다면 변환 단계가 생기고, 번호 매기기와 상호 참조, 인용 필드가 가장 잘 깨지는 지점이 바로 그 단계입니다. 늦은 시점에 한 번만 변환하고, 앞의 두 페이지를 읽는 대신 객체 유형을 점검하십시오.

Overleaf 기록으로 논문이 어떻게 쓰였는지 보여 줄 수 있을까요? 그것은 기록이지 판결이 아니며, 무료 플랜에서는 버전에 라벨을 붙이지 않는 한 하루 만에 대부분 사라집니다. 위에 연결한 글에 정확한 규칙과 이를 해결하는 라벨링 습관이 나와 있습니다.