2026-08-18

이중맹검 동료평가 제출 전, 원고 파일의 숨은 메타데이터부터 지우는 법

이중맹검(더블 블라인드) 학술지·학회에 논문을 제출할 때는 익숙한 체크리스트가 따라옵니다 — 제목 페이지에서 이름과 소속을 지우고, "저희가 앞서 보인 바와 같이" 같은 문장을 저자를 드러내지 않는 표현으로 바꾸고, 감사의 글은 본문이 아닌 별도의 커버레터로 옮기는 것들입니다. 하지만 정작 자주 놓치는 단계가 하나 있습니다. 네이처(Nature)는 자체 이중맹검 저자 체크리스트에서 이렇게 명확히 밝힙니다 — "제출하는 모든 파일의 메타데이터에 저자 정보가 없는지 확인하십시오. 이 정보는 보통 여러분 컴퓨터의 신원 정보로부터 자동으로 추가됩니다." 원고는 리뷰어가 화면에서 읽는 텍스트와는 완전히 별개로, 그 자체로 숨겨진 필드를 가진 파일입니다 — 눈에 보이는 페이지를 익명화한다고 해서 이 필드들이 함께 지워지지는 않습니다.

체크리스트가 실제로 가리키는 곳

네이처의 체크리스트는 메타데이터가 존재한다고만 말하지 않고, 어디를 봐야 하는지까지 알려줍니다 — "워드처럼 널리 쓰이는 프로그램 다수에서는 저자 정보가 '파일' 탭의 '속성(properties)' 항목에 표시되며, 직접 수정할 수도 있습니다." 이는 이력서 작성 관련 조언에서 흔히 말하는 그 속성(Properties) 대화상자와 같은 것입니다 — 그 안쪽을 들여다보면 .docx 파일의 경우 docProps/core.xml(작성자 이름, 마지막 수정자), docProps/app.xml (Company·Manager, 파일을 만든 오피스 설치본에 등록된 조직 이름으로 자동 채워지는 경우가 많습니다), docProps/custom.xml(서식이나 참고문헌 관리 도구가 추가한 자유 형식의 커스텀 속성) 로 나뉘어 있습니다. PDF 버전도 형태만 다를 뿐 같은 종류의 정보를 담고 있습니다 — 제목(Title), 작성자(Author), 주제(Subject), 키워드(Keywords), Creator, Producer, 그리고 두 개의 타임스탬프로 이루어진 Info 딕셔너리, 그리고 이와 별개로 같은 필드를 중복하거나 확장할 수 있는 XMP 메타데이터 스트림입니다. 이 중 어느 것도 화면에는 보이지 않습니다. 하지만 파일을 여는 모든 리뷰어에게 전부 함께 전달됩니다.

실제로 얼마나 자주 일어나는 일인가

이는 가정이 아닙니다. Supriya Adhatarao와 Cédric Lauradoux가 2021년 발표한 연구 "Exploitation and Sanitization of Hidden Data in PDF Files"는 47개국 75개 보안 기관이 공개한 실제 PDF 파일 39,664건을 수집해 그 메타데이터가 무엇을 드러내는지 확인했습니다. 작성자나 제작자 이름 같은 신원 정보는 13,166건, 33%에서 발견됐습니다. 파일을 만든 소프트웨어 정보는 30,155건, 76%에서 드러났습니다. 이 연구는 학술 논문 제출물을 대상으로 한 것이 아닙니다 — 오히려 세심함을 갖출 이유가 충분한 기관들이 공개한, 훨씬 더 크고 독립적으로 측정된 일반 PDF 표본입니다. 그럼에도 이 연구가 보여주는 요점은 여기에도 그대로 적용됩니다 — 네이처가 말한 "보통 자동으로 추가된다"는 표현은 원고에 국한된 특이 현상이 아니라, 완전히 다른 파일 집단을 대상으로 한 대규모 측정에서도 확인되는, 문서 소프트웨어의 기본 동작 방식이라는 것입니다.

"정리했다"고 해서 항상 사라진 것은 아닙니다

같은 연구는 기관이 공개 전에 실제로 파일을 정리(sanitize)하려 시도한 경우까지 살펴봤고, 그 조치가 겉보기와 달리 제대로 작동하지 않는 경우가 많다는 것을 발견했습니다 — 일부 정리 단계를 거친 파일 중 65%에서 여전히 복구 가능한 민감 정보가 남아 있었습니다. 특히 exiftool을 거친 파일에 대해서는 논문이 그 이유를 직접 설명합니다 — "메타데이터는 PDF 파일 내의 별도 객체에 저장되며, exiftool은 파일 안에서 이 메타데이터 객체에 대한 참조만 제거할 뿐입니다. 따라서 이 객체에는 여전히 접근이 가능합니다." 다시 말해, 어떤 도구는 속성을 확인했을 때 필드가 비어 보이게 만들면서도 실제 바이트는 파일 안에 그대로 남겨 둘 수 있으며, read-back 결과를 믿는 대신 원시 구조를 직접 들여다보는 사람에게는 여전히 복구될 수 있습니다. "속성 패널에 빈칸으로 표시된다"는 것과 "지금 업로드하려는 파일에서 그 문자열이 실제로 사라졌다"는 것 사이에는 이런 틈이 있습니다.

NearScrub이 원고에 대해 실제로 지우는 것

PDF 원고라면 NearScrub은 Info 딕셔너리의 여덟 개 키 — Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate — 를 모두 삭제하고, XMP 메타데이터 스트림이 있으면 함께 제거합니다. 이 모든 과정은 브라우저 탭 안에서만 이루어집니다. 일부 학회·학술지가 여전히 직접 받아 주는 .docx라면 docProps/core.xml, app.xml, custom.xml을 한 번에 비웁니다. 또한 별도의 파일이라는 사실을 잊기 쉬운 부분도 다룹니다 — 휴대폰 사진이나 스크린샷에서 시작해 벡터 소스에서 무손실로 삽입되지 않고 독립된 JPEG나 PNG로 저장된 그림은, 원고 파일 자체의 속성과는 완전히 별개로 자체적인 EXIF/GPS, XMP, IPTC 데이터 — 카메라·기기 이름, 촬영 시각, 때로는 위치 정보까지 — 를 담고 있을 수 있습니다. NearScrub은 원고 본문과 같은 방식으로 JPEG·PNG 그림에서도 이를 제거합니다. 그리고 이 처리 자체가 어디에도 업로드를 필요로 하지 않으므로, 낯선 사람이 여러분에 대해 알아낼 수 있는 정보를 줄이기 위한 단계 자체가, 실제로 제출하려는 곳에 도달하기 전에 파일이 거쳐 가는 또 하나의 경유지가 되지는 않습니다.

닿지 않는 부분

그 경계는 정확히 짚어 둘 필요가 있습니다. NearScrub은 속성 필드를 지울 뿐 문서의 눈에 보이는 내용은 지우지 않습니다 — 감사의 글 문단이나 그림 캡션에 여전히 타이핑되어 있는 이름은 메타데이터가 아니라 본문 편집의 문제이며, 여러분이 남겨 둔 그대로 남아 있습니다. 워드의 추적된 변경 내용을 대신 수락해 주거나 댓글을 지워 주지도 않습니다 — 이들은 word/document.xml과 comments.xml이라는, 같은 .docx 압축 파일 안의 별도 부분에 저장되어 있어서 docProps를 지워도 전혀 닿지 않으므로, 워드 자체의 검토 탭에서 변경 내용을 수락·거부하고 댓글을 지우는 작업이 먼저 이루어져야 합니다. 그리고 실제로 지원하는 형식 — JPEG, PNG, PDF, OOXML 오피스 형식 — 만 읽을 수 있으므로, 오래된 .doc나 .rtf, 원시 LaTeX 소스 트리는 애초에 처리할 수 있는 대상이 아닙니다. 이 도구가 채우도록 만들어진 자리는 위의 두 자료가 함께 가리키는, 잘 알려진 바로 그 틈입니다 — 아무도 직접 입력하지 않았고 아무도 채워 달라고 요청하지 않았지만, 체크리스트는 확인하라고 말할 뿐이고, 속성 패널에서 감추는 것이 아니라 실제로 지우도록 만들어진 도구만이 확실히 메울 수 있는 그 필드들입니다.