AI 휴머나이저 DOCX 테스트: Track Changes와 주석

2026년 팔월 31일에 진행한 HumanPen 테스트에서 답은 '예'였습니다. 선택한 133단어 문단 하나는 바뀌었지만, 추적된 삽입 하나, 추적된 삭제 하나, 검토자 주석 하나, 콘텐츠 컨트롤 하나, 북마크와 REF 필드 한 쌍, 표 하나는 반환된 DOCX에 그대로 남아 있었습니다. 이 글은 HumanPen이 게시한 것이며, 테스트 역시 자사 제품으로 진행했습니다. 다만 이는 파일 하나와 실행 한 번의 결과이며, 모든 Word 문서에 대한 보장은 아닙니다.

이 테스트에서는 감지기를 쓰지 않았습니다. 질문은 더 좁았습니다. 특정 문단을 다시 썼을 때, 그 문단 밖에 있는 Word 객체들은 어떻게 되는가 하는 점이었습니다.

파일은 세 수준에서 확인했습니다. 먼저 Word 내부 구조의 개수를 세었고, 다음으로 DOCX 패키지의 모든 파트를 비교했으며, 마지막으로 입력과 출력을 렌더링해 페이지를 비교했습니다. 다만 한 가지 확인은 끝내 하지 못했습니다. 로컬 컴퓨터 제어 권한을 쓸 수 없어서, 출력물을 Microsoft Word에서 직접 열고 저장하고 닫은 뒤 다시 여는 작업을 할 수 없었습니다. 이 공백은 중요하며, 그대로 열려 있습니다.

입력물은 이 실험을 위해 만든 합성 문서로, 두 쪽짜리였습니다. 학생 과제물, 연구 데이터, 고객 자료는 전혀 들어 있지 않았습니다. 1쪽에는 개수를 세려는 Word 객체들을 배치했습니다. 2쪽에는 다시 쓰기 범위로 지정된 평범한 문단 하나만 두었습니다.

센티널에는 `TRACK-ANCHOR-23`, `COMMENT-ANCHOR-47`, `CONTROL-TABLE-91`, `37.5%`, `12.40 mg`가 포함되어 있었습니다. 북마크 레이블은 의도적으로 두 번 나타납니다. 한 번은 북마크 자리에서, 한 번은 표시된 REF 결과로 나타납니다.

이 구성에는 중요한 경계가 있습니다. 계측 대상 객체는 모두 선택한 문단의 바깥에 있었습니다. 이 실행은 다시 쓰기 범위가 확인된 바깥쪽에서의 보존을 검증합니다. 주석 앵커, 추적된 변경, 필드, 콘텐츠 컨트롤이 다시 쓰는 문단 안에 있을 때 무슨 일이 일어날지는 이 결과로 알 수 없습니다.

손대지 않은 입력물은 40,191바이트였고 SHA-256은 다음과 같습니다.

`cccbac04cf9742037b16c453b54ae3c8a2300e7491ba31a213566c979c6fe4f1`

이 해시는 이번 실행에 쓰인 입력물 그 자체를 식별합니다. Word에서 똑같이 보이는 파일이라도 다른 파일이면 다른 해시가 나옵니다.

2026년 팔월 31일 20:00 (중국 표준시)에 DOCX를 HumanPen에 업로드했습니다. 전략은 Balanced v3, 모드는 지정 콘텐츠로 선택했고, 시작 전에 범위가 문단 하나와 영어 단어 133개임을 확인했습니다.

32초라는 소요 시간과 14크레딧 차감은 이번 작업의 기록일 뿐, 다른 파일에 대한 약속이 아닙니다. 처리 시간과 비용은 선택한 텍스트와 제품 상태에 따라 달라질 수 있습니다.

출력 해시가 입력 해시와 다른 것은 당연한 일입니다. 선택한 문단이 바뀌었기 때문입니다. 파일 전체 해시는 두 파일이 다르다는 것은 증명할 수 있지만, 그 차이가 의도한 문단에만 국한되는지까지는 말해 주지 않습니다. 이를 확인하려면 파트별 비교가 필요했습니다.

DOCX는 XML 파트, 관계, 미디어, 스타일 등의 리소스를 담은 ZIP 패키지입니다. 입력과 출력에는 각각 20개의 파트가 들어 있었고, 파트 이름 집합은 정확히 일치했습니다.

일곱 개의 센티널 그룹도 입력 시의 개수를 유지했습니다. 백분율은 `37.5%` 그대로였고, 측정값은 `12.40 mg` 그대로였으며, 보호된 앵커의 등장 횟수가 늘거나 줄지도 않았습니다.

그다음 내부 파트를 모두 해시했습니다. 열여덟 개의 파트 해시는 동일했고, 둘은 달랐습니다.

본문 문단이 자리한 `word/document.xml`에서는, 형식을 정리한 diff에 변경된 `w:t` 텍스트 노드가 하나만 있었습니다. 바로 선택한 문단입니다. 해당 파트의 다른 형식 노드는 바뀌지 않았습니다.

원시 해시에서 두 번째로 달라진 부분은 `[Content_Types].xml`이었습니다. 크기는 2,125바이트로 유지되었고 `Default`와 `Override` 항목도 같았습니다. 출력물에서는 기존 `/word/comments.xml` override가 목록의 끝에서 다른 Word override들 사이로 이동해 있었습니다. 콘텐츠 타입이 추가되거나 삭제되거나 변경된 것은 없었습니다. 비교 도구가 파트 이름이나 파싱된 항목 집합만 알려 준다면, 이런 순서 차이는 놓치기 쉽습니다.

이는 "파일에 여전히 20개의 파트가 있었다"라고 말하는 것보다 강한 근거입니다. 파트는 이름을 유지한 채 내용이 바뀔 수 있습니다. 눈으로 대충 훑어보는 것보다도 강합니다. 주석 관계나 콘텐츠 컨트롤은 본문의 평범한 텍스트처럼 보이지 않아도 파일 안에 존재할 수 있기 때문입니다.

그렇다고 해서 Word에서 객체 하나하나를 실제로 조작해 본 것과 같지는 않습니다. 개수가 같고 XML 구조가 일치한다는 것은 패키지에 무엇이 남았는지를 보여 줄 뿐입니다. 검토자가 검토 창에서 주석을 클릭했는지, 기존 삽입을 승인했는지, 기존 삭제를 거부했는지, 데스크톱 Word에서 REF 필드를 새로 고쳤는지까지 보여 주지는 않습니다.

두 버전 모두 두 쪽으로 렌더링되었습니다. 이미지 비교에서는 2쪽만 바뀐 쪽으로 확인되었습니다.

• 추적된 변경, 주석 앵커, 콘텐츠 컨트롤, 북마크, REF 필드, 표가 들어 있던 1쪽은 눈으로 보기에 변하지 않았습니다.
• 2쪽은 선택한 문단이 있던 자리에서 바뀌었습니다.
• 새로운 문장 길이 때문에 2쪽에서는 정상적인 줄바꿈이 일어났습니다.
• 렌더링된 출력물에서는 잘린 텍스트, 겹친 텍스트, 사라진 표, 깨진 표 구조가 발견되지 않았습니다.

추출된 텍스트의 diff도 같은 경계에 도달했습니다. 선택한 문단은 바뀌고, 그 뒤에 있는 범위 메모는 제자리에 남아 있었습니다.

렌더링은 패키지 감사와는 다른 질문에 답합니다. 패키지 감사는 구조를 확인하고, 렌더링은 독자가 보게 될 페이지를 확인합니다. 한쪽은 통과하고 다른 쪽은 실패하는 파일도 있을 수 있으므로, 어느 한쪽 결과가 다른 쪽을 대신할 수는 없습니다.

개수가 변하지 않았다는 사실은, 그 카운터가 손실을 실제로 잡아낼 수 있을 때만 의미가 있습니다. 의도적으로 손상시킨 복사본 둘로 이를 확인했습니다.

첫 번째 복사본에서는 주석 구조를 제거했습니다. 같은 감사 도구는 주석 본문 0개, 범위 앵커 0개, 주석 참조 0개, 주석 관계 0개, 주석 content-type 항목 0개를 보고했습니다.

두 번째 복사본에서는 추적된 변경을 승인했습니다. 감사 도구는 추적된 삽입 0개, 추적된 삭제 0개를 보고했습니다.

이 양성 대조군은 이 감사 경로가 우리가 만든 두 가지 손실을 잡아낼 수 있음을 보여 줍니다. 그렇다고 이 감사 도구가 모든 DOCX 오류를 찾아낸다고 인증하는 것은 아닙니다. 깨진 그리기 관계, 잘못된 수식, 손상된 매크로에는 각각 별도의 검사와 별도의 알려진 불량 대조군이 필요합니다.

버려도 되는 복사본을 쓰십시오. 테스트에는 실제 문서에서 되살리는 데 비용이 많이 드는 객체가 들어 있어야 합니다. Word 구조가 전혀 없는 평범한 문단으로는 의미가 없습니다.

1. 의존하는 객체마다 식별할 수 있는 사례를 하나씩 넣으십시오. 추적된 삽입, 추적된 삭제, 주석, 인용 관리 도구 컨트롤, 북마크, 상호 참조, 각주, 표, 수식, 캡션 등이 여기에 해당합니다.
2. 각 객체 옆에 고유한 앵커를 두십시오. `CHECK-COMMENT-01`이나 단위가 붙은 숫자 같은 것이 좋습니다. 기대하는 개수를 기록해 두십시오.
3. 이 대조군들은 평범한 문단 하나의 바깥에 두십시오. 다시 쓰기 위해 선택하는 것은 그 문단만으로 하고, 실행 전에 최종 범위를 확인하십시오.
4. 손대지 않은 입력물을 보관하십시오. 바이트 크기와 SHA-256을 기록해 두면 됩니다. macOS에서는 `shasum -a 256 your-file.docx` 같은 간단한 명령으로 충분합니다.
5. 다운로드 후에는 출력물에 대해서도 같은 값을 기록하십시오. DOCX 파트 목록을 비교한 다음, 관련 XML 파트를 파싱해 객체 수를 확인하십시오. 압축된 DOCX 바이트를 grep으로 훑고 그것을 감사라고 부르지는 마십시오.
6. 두 파일을 같은 렌더러로 렌더링하고 쪽수, 텍스트, 이미지를 비교하십시오. 자연스러운 줄바꿈과, 잘림·겹침·객체 누락은 다릅니다.
7. 제출에 사용할 데스크톱 Word 버전으로 출력물을 여십시오. All Markup 보기와 주석 창을 확인하고, 콘텐츠 컨트롤 하나를 조작하고, 필드 하나를 새로 고치고, 다른 이름으로 저장한 뒤 닫고 다시 여십시오.
8. 의도적으로 손상시킨 복사본을 하나 만들어, 자신의 검사가 그 손실을 보고하는지 확인하십시오. 이 대조군이 없으면 깨끗한 0은 측정이 그 객체를 본 적이 없다는 뜻일 수 있습니다.

이 검사들을 하나의 백분율로 합치지 마십시오. 주석이 실패하고 다른 아홉 줄이 통과했다면, 주석은 여전히 충족되지 않은 요구 사항입니다. 합격 판단은 필요한 문서 객체 각각에 대해 내려야 합니다.

이 실행은 보편적인 보존 주장을 뒷받침하지 않습니다. 테스트하지 않은 것은 다음과 같습니다.

• 다시 쓴 텍스트 안에 있는 주석이나 추적된 변경;
• 실제로 연결된 Zotero, EndNote, Mendeley 라이브러리;
• 각주, 수식, 매크로, 포함된 파일, 텍스트 상자, 부동 이미지;
• 구역별 머리글과 바닥글;
• 다른 HumanPen 전략이나 문서 전체 다시 쓰기;
• 다른 Word 버전이나 운영 체제;
• 다시 쓴 문단의 사실적 품질이나;
• AI 감지기 결과.

Microsoft Word에서 직접 다시 열어 보는 작업은 여전히 가장 큰 미결 검사입니다. OOXML 결과와 렌더링 결과는 증거이지만, Word가 복구 경고 없이 파일을 열었다거나 보존된 모든 객체가 상호 작용 가능한 상태로 남았다고 주장할 수 있는 근거는 아닙니다.

옳은 결론은 작지만 쓸모가 있습니다. 이 한 번의 지정 콘텐츠 HumanPen 실행에서는 선택한 문단이 바뀌었고, 그 바깥에 있던 계측 객체들은 측정된 패키지 구조를 유지했으며, 렌더링된 문서는 온전했습니다. 자신의 DOCX에는 여전히 자신만의 인수 테스트가 필요합니다.

HumanPen은 Track Changes를 보존합니까? 이번 한 번의 실행에서는 원래 있던 추적된 삽입 하나와 추적된 삭제 하나가 반환된 DOCX 패키지에 남아 있었습니다. Microsoft Word에서 직접 승인하거나 거부하지는 않았으므로, 데스크톱 Word에서의 동작은 확인되지 않은 상태입니다.

HumanPen은 Word 주석을 보존합니까? 이 파일에서는 주석 본문, 시작과 끝 앵커, 문서 내 참조, 패키지 관계, content-type 항목이 각각 남아 있었습니다. 다운로드 후 Word의 주석 창에서 직접 열어 보지는 않았습니다.

파트 개수가 같으면 그 DOCX가 안전하다는 증거가 됩니까? 아닙니다. 파트는 이름이 같아도 내용이 바뀔 수 있습니다. 파트 해시를 비교하고, 변경된 XML을 살펴보고, 객체 수준 개수를 확인하고, 페이지를 렌더링하고, Word에서 객체를 직접 조작하십시오.

내 논문이나 보고서에서도 같은 결과를 기대해야 합니까? 하나의 테스트 파일로 모든 Word 객체를 담을 수는 없습니다. 실제 문서가 쓰는 구조를 그대로 반영한 작은 테스트 파일을 만들고, 사용할 계획인 것과 같은 범위와 설정으로 실행하고, 손대지 않은 원본을 보관하십시오.