캡스톤 프로젝트와 AI 탐지: 단계별 제출, 공유 문서

캡스톤을 과목 에세이와 다르게 만드는 요소는 세 가지이고, 각각의 결과도 다릅니다. 두 번 이상 제출되므로 중간 보고서가 저장소에 들어가 최종 보고서와 비교되는 대상이 될 수 있습니다. 여러 사람이 쓰므로 AI 작성 비율은 아무도 혼자 쓰지 않은 문서에 대한 수치이며, 저자 항목이 없습니다. 그리고 마지막에 모두의 섹션을 하나의 목소리로 합치는 사람은, Turnitin 자체 문서가 오탐이 나기 쉽다고 지목한 바로 그 수정 작업을 하고 있습니다.

이 세 가지 중 어느 것도 연말에 파일을 다시 쓴다고 해결되지 않습니다. 그중 두 가지는 몇 달 전에 다른 사람이 선택한 설정으로 결정되며, 도움이 되는 행동은 편집이 아니라 질문입니다.

여기에는 점수를 예측하는 내용이 없습니다. Turnitin은 파이프라인의 구조와 파일 요건을 공개합니다. 기준값은 공개하지 않으며, 우리도 공개하지 않습니다.

Turnitin에는 캡스톤이 가진 형태에 맞춰 만들어진 기능이 있습니다. 이름은 Multipart assignment이고, 가이드에 실린 설명은 프로젝트 일정표처럼 읽힙니다:

"Multipart assignments let instructors connect two or more assignment parts into one larger assignment workflow. Use Multipart assignments when students need to complete a larger project in stages, such as an outline, annotated bibliography, first draft, and final draft." (Multipart assignment를 사용하면 강사는 두 개 이상의 과제 부분을 하나의 큰 과제 흐름으로 연결할 수 있습니다. 개요, 주석 달린 참고문헌, 초고, 최종고처럼 학생이 큰 프로젝트를 단계별로 완료해야 할 때 Multipart assignment를 사용하세요.)

핵심은 그다음 문장입니다:

"A Multipart assignment is a connected set of assignment parts. Each part has its own title, instructions, dates, settings, and submissions, but the parts are grouped together as one assignment experience." (Multipart assignment란 서로 연결된 과제 부분들의 묶음입니다. 각 부분에는 고유한 제목, 안내, 날짜, 설정, 제출물이 있지만, 이 부분들은 하나의 과제 경험으로 묶입니다.)

설정도 제각각이고 제출물도 제각각입니다. 그리고 화면의 학생 쪽에서 보면, Turnitin은 그 묶음을 전혀 알아차리지 못할 수도 있다고 말합니다. "Students see each part of a Multipart assignment as a separate assignment in their LMS or Turnitin, as they normally would." (학생은 Multipart assignment의 각 부분을 LMS나 Turnitin에서 평소처럼 개별 과제로 봅니다.) 학생 가이드도 같은 말을 반복합니다. 각 부분은 "appear in your assignment list as separate assignments" (과제 목록에 개별 과제로 표시됩니다)이고, "each part of a Multipart assignment has its own submission" (Multipart assignment의 각 부분에는 고유한 제출물이 있습니다).

즉, 일곱 번째 주에 중간 보고서를 올리고 스물두 번째 주에 최종 보고서를 올린다면, 그것은 하나의 파일이 수정되는 것이 아니라 설정이 각각 다른 두 번의 제출입니다. 사람들이 믿고 있는 보호 장치, 즉 재제출하면 이전 제출물을 덮어써서 둘이 서로 비교되지 않는다는 규칙은 같은 과제에 다시 제출할 때 적용되는 규칙입니다. 그 규칙이 언제 적용되고 언제 적용되지 않는지는 내 이전 초안이 재제출본과 일치할까에서 자세히 다뤘고, 짧게 말하면 문제가 되는 경우는 두 번째 업로드가 아니라 두 번째 과제입니다.

일곱 번째 주의 파일이 저장소에 있는지 여부 자체가 설정이고, 그 설정은 여러분보다 두 단계 위에서 정해집니다. Turnitin 계정 설정 가이드에는 관리자가 강사에게 넘길 수 있는 항목이 나열되어 있습니다:

"Enable instructor standard repository options: Chosen instructors will be able to set the assignment option to either store student papers within the standard paper repository or not store the papers in any repository." (강사 표준 저장소 옵션 사용: 선택된 강사는 학생 논문을 표준 논문 저장소에 보관하거나 어떤 저장소에도 보관하지 않도록 과제 옵션을 설정할 수 있습니다.)

확장 옵션이 켜져 있으면 강사는 표준 저장소와 기관 저장소 중에서 선택합니다. 그리고 관리자가 "Submit all papers to the standard repository" (모든 논문을 표준 저장소에 제출)를 선택하면 그 선택권 자체를 없앨 수도 있습니다. 같은 페이지는 이를 이렇게 설명합니다. "All student papers submitted to the account will be stored in the standard paper repository." (계정에 제출된 모든 학생 논문은 표준 논문 저장소에 보관됩니다.)

즉, 한 모듈의 제출 시점들이 같은 규칙을 따를 필요는 없고, 이 설정 중 어느 것도 업로드 화면에서는 보이지 않습니다.

그래서 여러분이 할 수 있는 유용한 일은 하나뿐이고, 타이밍이 전부입니다. 최종 제출 후가 아니라 중간 제출 전에 물어보세요. 중간 부분이 제출물을 저장소에 보관하는지 묻는 이메일 한 통은 여섯 번째 주에는 금세 처리되지만, 스물세 번째 주에는 답을 받을 수 없습니다.

Multipart 구조에 대해 한 가지 더 말씀드리면, 여러분의 학교에도 이 기능이 있다고 쉽게 가정할 수 있습니다. Turnitin은 이 기능을 사용할 수 없는 연동 대상을 나열합니다: Google Classroom, Sakai, Manaba, In Campus. 캡스톤이 그중 하나로 운영된다면 각 부분은 서로를 연결하는 고리가 없는 개별 과제일 뿐입니다. 이는 저장소 문제에는 아무런 영향을 주지 않지만, 강사가 채점 중에 여러분의 제출물을 넘나들 수 있는지에는 전적인 영향을 줍니다.

여러분이 건너뛰었으면 하는 실패 사례가 있습니다. 한 팀이 최종 보고서에서 높은 유사도를 발견하고, 그 출처가 중간 제출물에 있던 자기 팀의 문헌 검토라는 것을 알아낸 뒤, 그 문헌 검토가 일치하지 않도록 일주일을 들여 다시 쓰는 경우입니다.

여기에는 문제가 두 가지 있습니다.

첫째, 유사도 점수와 AI 비율은 같은 측정값이 아니며 서로 영향을 주지 않습니다. Turnitin은 이를 분명히 밝힙니다. "The Similarity score and the AI writing detection percentage are completely independent and do not influence each other." (유사도 점수와 AI 작성 탐지 비율은 완전히 독립적이며 서로 영향을 주지 않습니다.) 자기 일치는 유사도 사건입니다. 그것은 AI 수치에 대해 아무것도 알려주지 않으며, 고친다고 그 수치가 움직이지도 않습니다. AI 작성 보고서와 유사도 보고서 비교에서 높고 낮음의 네 가지 조합이 모두 가능한 이유를 다룹니다.

둘째, 그리고 이 부분이 뼈아픈데, 자기 문헌 검토를 이전의 자기 자신과 일치하지 않도록 다시 쓰는 일은 Turnitin이 자사 오탐을 설명할 때 언급하는 특징 쪽으로 텍스트를 밀어 넣습니다:

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas." (때때로 오탐, 즉 사람이 쓴 텍스트를 AI가 생성한 것으로 잘못 표시하는 경우에는 구조적 변동이 많지 않은 내용, 문자 그대로 자신을 반복하는 텍스트, 또는 새로운 생각을 전개하지 않고 바꾸어 쓴 텍스트가 포함될 수 있습니다.)

그 바로 다음 문장이 기억해야 할 문장입니다:

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated." (그러한 텍스트에서 AI 작성 비율이 더 높게 나타난다면, 표시된 비율을 보실 때 그 점을 고려하시기를 권합니다.)

오로지 이전의 자기 자신과 닮지 않게 하려고, 그 뒤에 새로운 읽기 없이 다시 쓴 문헌 검토는 그 문장의 특정 항목 하나에 가깝게 놓입니다. 즉, 뒤에서 새로운 생각이 자라지 않은 채 바꾸어 쓴 텍스트입니다. 여러분은 강사 쪽에 해결책이 있는 유사도 수치를, 해결책이 없는 텍스트 특징과 맞바꾸려는 셈입니다.

여기서 실제 답은 강사 쪽의 해결책입니다. 이전 제출물을 보고서에서 제외하는 것은 강사는 쥐고 있고 여러분은 쥐고 있지 않은 통제권입니다.

이 메커니즘을 보면 그룹 문서가 왜 그렇게 행동하는지 설명이 됩니다. Turnitin의 설명은 대략 이렇습니다. 제출물은 겹치는 섹션으로 나뉩니다. 각 섹션에는 영과 일 사이의 확률이 부여됩니다. 대상 문장은 자신을 덮고 있는 섹션에서 점수를 가져오고, 여러 점수가 하나로 합쳐지며, 그것들이 위로 집계되어 문서 전체 수치 하나가 나옵니다.

이것을 파이프라인으로 읽으면 한 가지가 분명해집니다. 어디에도 그 부분을 누가 입력했는지 적는 항목이 없습니다. 단위는 문서입니다. 저자 다섯 명이 들어가고 비율 하나가 나오며, 그 비율은 다시 다섯 명에게 나눌 수 없습니다. 이미 이 한가운데 있는 분들을 위해, 이 문제의 일반적인 형태는 AI를 쓰지 않았는데 그룹 과제가 AI로 표시된 경우에서 다룹니다.

하지만 보고서에는 점수에 없는 차원을 가진 것이 하나 있습니다. 강조 표시에는 위치가 있습니다. 강조된 부분은 어떤 페이지의, 어떤 섹션의, 어떤 제목 아래에 놓여 있고, 그 제목을 누가 썼는지는 팀이 알고 있습니다.

이것이 도움이 되려면 조건 두 개가 충족되어야 합니다. 보고서가 필요한데, 스스로는 구할 수 없습니다. Turnitin은 "The AI writing detection indicator and report are not visible to students" (AI 작성 탐지 표시와 보고서는 학생에게 보이지 않습니다)라고 말하고, 이어서 "with the PDF download feature, instructors can download and share the AI report with students" (PDF 다운로드 기능을 사용하면 강사가 AI 보고서를 내려받아 학생과 공유할 수 있습니다)라고 말합니다. 그러니 요청해야 하는 것은 숫자의 스크린샷이 아니라 PDF입니다. Turnitin AI 작성 보고서 읽는 법에서 보고서를 손에 넣은 뒤 무엇을 보게 되는지 다룹니다.

그리고 누가 무엇을 썼는지에 대한 기록이 그 시점에 만들어져 있어야 합니다. 날짜가 있는 섹션 담당 표를 두 번째 주에 만들어 섹션이 옮겨질 때마다 갱신하는 일은 따분하지만, 한 학기에 십 분이면 됩니다. 똑같은 표를 스물세 번째 주에 압박 속에서 만들면, 그것은 의혹 제기 이후에 만든 문서가 되고, 그 자리에 있는 모두가 그것을 압니다.

Turnitin은 자사가 qualifying text, 즉 대상 텍스트라고 부르는 것만 분석하며, 이를 긴 형식의 글 안에서 표준 문법에 맞게 쓰인 산문 문장으로 정의합니다. 또한 그 비율이 "is not necessarily the percentage of the entire submission" (반드시 제출물 전체의 비율인 것은 아닙니다)라고 밝혀 둡니다. 제외 항목까지 포함한 정의의 전문은 Turnitin의 대상 텍스트란 무엇인가에 있습니다.

이제 캡스톤 보고서가 실제로 무엇으로 이루어져 있는지 떠올려 보세요. 요구사항 표. 번호가 붙은 시험 절차. 코드 목록. 그림 캡션. 간트 차트. 부록에 들어 있는 인터뷰 일정표. 그것들 가운데 문장으로 된 단락은 거의 없습니다.

결국 배경, 문헌 검토, 논의, 결론 이 네 부분이 측정의 거의 전부를 짊어집니다.

이것이 서식 문제가 아니라 그룹 문제인 이유가 여기에 있습니다. 대부분의 팀에서 이 네 섹션은 고르게 배분되지 않습니다. 영어를 유창하게 쓰는 사람, 또는 다른 사람들이 결과물을 만드는 동안 "글 쓰는 부분"을 자원한 사람에게 몰립니다. 그래서 문서 수준의 비율은 거의 전적으로 한두 사람이 쓴 텍스트에 대해 계산되고, 그것이 이름이 다섯 개 달린 문서의 속성으로 보고됩니다.

회의 전에 알아둘 만한 사실입니다. 그 방에서 첫 질문은 보통 "이거 누가 썼어"이기 때문입니다. 그리고 그 수치를 만들어 낸 부분에 대한 솔직한 답은 저자 목록보다 짧을 수 있습니다.

모든 그룹 문서에는 한 명 있습니다. 마감 일주일 전에 파일 다섯 개를 받아 하나의 문서처럼 읽히게 만드는 사람입니다.

그 사람이 하는 일 중 일부는 필요하고 위험도 전혀 없습니다. 세 번째 섹션의 "참가자"가 다섯 번째 섹션의 "응답자"가 되지 않도록 정의된 용어를 통일하는 일. 방법론의 시제를 고치는 일. 누군가 그림을 하나 끼워 넣은 뒤 번호를 다시 매기는 일. 모든 인용을 한 가지 스타일로 맞추는 일. 제목 수준을 정렬하는 일. 이 중 어느 것도 누군가의 문장 형태를 건드리지 않습니다.

조심해야 하는 부분은 이음새가 눈에 띈다는 이유로 문서 전체를 하나의 목소리로 매끄럽게 다듬는 작업입니다.

Turnitin이 오탐에 대해 제시한 목록으로 돌아가 보세요. 구조적 변동이 많지 않은 내용이 첫 번째 항목입니다. 다섯 사람이 쓴 문서에는 구조적 변동이 애초에 들어 있습니다. 그리고 그것은 다섯 사람이 썼기 때문에 들어 있는 변동입니다. 목소리를 매끄럽게 다듬는 작업은 바로 그것을 제거하는 작업입니다.

실무적으로 정리하면 이렇습니다. 용어, 서식, 참고문헌은 맞추고 문장의 리듬은 그대로 두세요. 캡스톤 보고서가 팀이 쓴 것처럼 읽혀도 괜찮습니다. 실제로 팀이 썼으니까요. 이음새는 채점자가 감점할 결함이 아니며, 그것을 감추려는 노력은 오히려 여러분이 남겨 두고 싶어 하는 바로 그 차원에 쓰입니다.

문서가 공유 편집기에 있다면, 손대지 말아야 할 두 번째 이유가 있습니다. 누가 어떤 섹션을 썼는지 편집기가 남기는 기록은 한 사람이 모든 단락을 편집하는 순간 쓸모가 없어집니다. 그 기록이 실제로 무엇을 보관하는지 도구별로 살펴본 내용은 Word, Google Docs, Overleaf에서 버전 기록을 남기는 방법에 있습니다.

외부 파트너, 즉 기업, 병원, 지방자치단체가 있는 캡스톤은 위에서 설명한 모든 시스템의 바깥에 있는 독자를 한 명 더합니다. 그러면 미리 정리해 둘 만한 구체적인 일이 세 가지 생깁니다.

그 대화에 있는 사람 가운데 보고서를 가진 사람은 아무도 없습니다. 학생은 AI 작성 표시를 볼 수 없습니다. 기관 밖의 사람도 볼 수 없습니다. 파트너가 AI 검사를 했는지, 무엇이라고 나왔는지 묻는다면 답에 이르는 유일한 경로는 담당 강사가 PDF를 내려받는 것입니다. 대학을 통해서 물어보세요. 대학을 우회해서 물어보지 마세요.

파트너에게 건네는 파일은 제출하는 파일과 다를 수 있습니다. 납품본은 보통 성찰 섹션과 채점 기준 부록을 빼거나, 대학이 보지 않는 자료를 더합니다. 파일이 둘, 단어 수가 둘입니다. 그것이 문제가 되는 경계는 정해져 있습니다. Turnitin은 30,000단어를 넘는 제출물에는 AI 작성 보고서를 생성하지 않습니다. 부록까지 묶은 캡스톤 보고서가 그 선 근처에 닿는 일은 사람들이 예상하는 것보다 잦습니다. 파일 요건을 벗어난 제출물은 깨끗한 결과로 돌아오지 않고 처리되지 않은 상태로 돌아오며, 그 차이는 Turnitin이 학위 논문 전체를 검사할 수 있는지에서 다뤘습니다.

프로젝트 자료가 기밀이라면 저장소 문제는 행정 문제가 아니게 됩니다. 제출물이 보관되는지는 앞에서 인용한 설정이며, 강사가 과제별로 선택하도록 할 수도 있고 계정의 모든 논문이 무조건 보관되도록 할 수도 있습니다. 나중에 삭제하는 것은 여러분이 하는 일이 아닙니다. Turnitin은 이를 위로 올라가는 요청으로 설명합니다. "instructors have the ability to request the deletion of any submissions in their assignments. Administrators can approve or reject requests." (강사는 자기 과제의 제출물에 대한 삭제를 요청할 수 있고, 관리자는 그 요청을 승인하거나 거부할 수 있습니다.) 그러니 파트너의 데이터가 부록에 들어 있다면, 그것은 마지막 제출 후에 낼 신청서가 아니라 첫 업로드 전에 지도교수와 나눌 대화입니다.

여러분의 파트너 기관이 무엇을 요구하고 무엇을 받아들일지는 우리가 말씀드릴 수 없습니다. 누구도 말할 수 없습니다. 그것에 대해 확신에 찬 답을 공개하는 사람이 있다면, 그 사람은 여러분 대신 추측하고 있는 것입니다. 알 수 있는 것은 대학 쪽이고, 대학 쪽은 이름이 붙은 스위치들의 집합입니다.

위의 인용문은 모두 Turnitin 자체 도움말 페이지에서 가져온 것이므로, Turnitin을 쓰는 학교에만 해당하고 다른 곳에는 해당하지 않습니다. 여러분의 학교가 다른 시스템을 쓴다면 옮겨갈 수 있는 것은 벤더의 용어가 아닙니다. 질문 세 개이며, 지도교수나 프로그램 관리자에게 보내는 이메일 한 통에 들어갑니다:

• 이 모듈의 각 제출 시점은 각각 별개의 보관입니까, 아니면 하나의 것에 대한 여러 버전입니까?
• 제출물을 보관할지 누가 결정하며, 그 결정은 어느 수준에서 내려집니까?
• 나중에 무엇을 철회해야 한다면 절차가 어떻게 되고, 누가 최종 승인을 합니까?

모든 시스템에는 이 세 가지에 대한 답이 다른 이름으로 있습니다. 문제가 생기는 이유는 거의 언제나 기능 이름을 몰랐기 때문이 아닙니다. 여러 번의 제출을 하나의 사건이라고 가정했기 때문입니다.

이 모든 것은 캡스톤 초기에는 비용이 적게 들고, 마지막에는 불가능합니다.

• 어느 부분이 제출물을 보관하는지 물어보세요. 모듈의 모든 제출 시점을 한 통의 이메일로 지도교수에게 묻습니다. 첫 제출 전에요.
• 섹션 담당 표를 유지하세요. 섹션, 담당자, 시작일, 마지막으로 크게 수정한 날짜. 공유 드라이브에 두고 진행하면서 갱신하고, 나중에 다시 만들지 마세요.
• 공유 문서의 소유자를 정하세요. 대부분의 공동 편집 도구에서 파일을 만든 사람은 다른 사람에게 없는 기록 관련 권한을 가집니다.
• 각 이정표에 버전 이름을 붙이세요. 편집기의 용어가 무엇이든, 날짜와 두 단어 메모가 붙은 이름 있는 버전 하나는 자동으로 만들어진 백 개보다 가치가 있습니다.
• 마지막 주 전에 통일 규칙을 정하세요. 용어 목록, 인용 스타일, 그림 번호, 제목 수준. 둘째 주에 적어 두면 스물두 번째 주에 아무도 매끄럽게 다듬을 일이 없습니다.
• 최종 제출물이 30,000단어를 넘는지 미리 확인하세요. 처리되지 않은 보고서를 전날 밤에 발견하는 일이 없도록, 나눌 수 있을 만큼 일찍 확인하세요.

이미 예방 조언이 통하지 않는 지점을 지났다면, 표시되었지만 직접 쓴 글에서 대응 자료를 모으는 방법을 다룹니다. 그리고 여러분의 모듈이 파일 업로드가 아니라 Turnitin의 브라우저 작성 공간을 쓴다면, 그 공간이 무엇을 기록하는지는 전혀 다른 주제이며 Turnitin Clarity가 기록하는 것에서 다룹니다.

다시 쓰기는 위의 세 문제 중 어느 것에 대한 답도 되지 않습니다. 중간 보고서를 어느 과제가 보관했는지 바꿀 수 없고, 비율에 저자 항목을 더할 수 없으며, 문서가 어떻게 만들어졌는지에 대한 기록을 대신할 수도 없습니다.

다시 쓰기가 자리를 갖는 곳은 좁고 구체적입니다. PDF 보고서를 손에 넣었고, 일부 부분이 강조되어 있으며, 다른 네 사람이 쓰고 확인한 문서의 나머지는 건드리지 않은 채 그 부분만 수정하고 싶은 경우입니다. 이 마지막 부분이 그룹 문서를 다르게 만드는 제약입니다. 도구가 다시 쓴 것은 문서로 돌아가기 전에 사람이 확인해야 하며, 캡스톤에서 그 사람은 도구를 실행한 사람이 아닌 경우가 많습니다.

이 제약에 맞춰 만들어진 것이 HumanPen 도구입니다. 문서를 보고서와 함께 업로드하면 보고서의 강조 표시가 범위를 정하고, 거기에 포함되지 않은 부분은 쓰인 그대로 돌아옵니다. 다루는 최소 단위는 단락이므로 부분 일치는 단락 전체로 확장되어 실행 전에 여러분에게 표시됩니다. 요금은 파일 크기가 아니라 실제로 다시 쓰인 단어 수에 따릅니다. 조건을 충족하는 부분은 무료로 다시 실행할 수 있습니다.

이것은 범위와 비용에 대한 설명입니다. 다음 보고서가 무엇이라고 할지에 대한 설명이 아니며, 우리는 그런 설명을 하지 않습니다. 저자가 다섯 명인 문서에서 쓸모 있는 속성은, 팀이 되돌려 놓기 전에 다시 읽어야 할 단락의 짧은 목록입니다.

AI 비율이 우리 중 누가 AI를 썼는지 지도교수에게 알려줍니까? 아닙니다. 메커니즘에 대한 Turnitin 자체의 설명에는 저자 항목이 없습니다. 제출물은 분할되고, 각 조각에 점수가 매겨지며, 그 결과가 합쳐져 문서 수준 수치로 집계됩니다. 강조 표시는 문서 안에서 위치를 갖는데, 그것이 보고서에서 사람과 연결될 수 있는 유일한 요소이고, 그것도 팀이 누가 무엇을 썼는지를 이미 알고 있을 때만 가능합니다.

중간 보고서와 최종 보고서가 둘 다 시스템에 있습니다. 문제입니까? 그것은 AI 문제가 아니라 유사도 문제이며, 답은 중간 제출물이 보관되었는지에 따라 달라집니다. 그것은 담당 강사가 관리하는 과제 설정이고, 관리자가 활성화한 선택지 가운데 고른 것입니다. 중간 제출물이 들어가기 전에 물어보시고, 이미 자기 일치가 일어났다면 강사에게 가져가세요. 이전 제출물을 제외하는 것은 보고서의 강사 쪽에 있는 통제권이기 때문입니다.

최종 보고서가 부록을 포함해 45,000단어입니다. 어떻게 됩니까? Turnitin의 파일 요건은 AI 작성 보고서가 생성되려면 제출물이 30,000단어를 넘지 말아야 한다고 명시합니다. 상한을 넘으면 비율이 나오지 않고, 표시는 깨끗한 결과가 아니라 제출물을 처리할 수 없었다는 사실을 보여줍니다.

마지막에 한 사람이 문서 전체를 편집해 읽히는 방식을 통일했습니다. 그것이 실수였습니까? 자동으로 그렇지는 않으며, 용어, 참고문헌, 서식에 관한 부분이라면 더욱 그렇지 않습니다. 조심할 부분은 모두의 문장을 하나의 목소리로 매끄럽게 만드는 일입니다. "content without a lot of structural variation" (구조적 변동이 많지 않은 내용)은 Turnitin 자체의 오탐 발생 요인 목록에서 첫 번째 항목이고, 다섯 사람이 쓴 문서는 그 변동을 처음부터 공짜로 안고 시작하기 때문입니다.

점수로 다투는 대신 버전 기록을 보여줄 수 있습니까? 보여줄 수 있고, 가져가는 것도 합리적입니다. 다만 그것만으로는 아무것도 결정되지 않습니다. Turnitin은 자사 점수에 대해 "should not be used as the sole basis for adverse actions against a student" (학생에게 불리한 조치의 유일한 근거로 사용되어서는 안 됩니다)라고 말하고, 다른 곳에서는 "a single data point rather than a definitive response" (확정적인 답이 아니라 하나의 데이터 포인트)라고 표현합니다. 여러분의 버전 기록도 같은 의미에서 또 하나의 데이터 포인트입니다. 각각에 얼마나 무게가 실리는지는 학교의 결정이며, 학교의 학술 진실성 절차에 규정되어 있습니다. 읽어야 할 문서는 바로 그것입니다.