2026-09-07

PDF로 저장하면 지워진다는 오해 — 변환은 메타데이터를 지우는 게 아니라 새로 씁니다

이력서든 제안서든 견적서든, 파일을 보내기 직전에 다들 한 번쯤 하는 동작이 있습니다. "워드로 쓰고 PDF로 저장해서 보내면 되지." 이 동작은 왠지 정리처럼 느껴집니다. 수정 이력이 화면에서 사라지고, 파일이 더는 편집되지 않고, 내 손을 떠나는 결과물이 작업 중이던 파일과 전혀 달라 보이니까요. 그런데 실제로 일어나는 일은 정반대에 가깝습니다. PDF로 내보내면 원본 문서의 속성이 대체로 그대로 따라오고, 거기에 더해 내보내기를 수행한 소프트웨어가 자기 자신에 대한 정보와 버튼을 누른 시각을 새 항목으로 써 넣습니다. 변환은 메타데이터 이력을 끝내는 동작이 아니라, 거기에 한 줄을 추가하는 동작입니다.

따라오는 쪽: 원본 속성은 체크박스 하나에 달려 있습니다

먼저 사람들이 더 놀라는 쪽부터. docx 안에 들어 있던 작성자 이름은 변환하면서 남겨지지 않습니다. 마이크로소프트는 이 동작을 Office 데스크톱 앱에서 PDF 또는 XPS로 저장하거나 변환 문서에 한 문장으로 적어 두었습니다. "PDF에 문서 속성을 포함하려면 문서 속성이 선택되어 있는지 확인하십시오." 이 스위치는 다른 이름으로 저장 대화상자의 옵션 버튼 뒤에 있습니다. 제안서를 메일로 보내기 직전에 사람들이 들어가 보는 자리는 아닙니다.

그래서 무슨 일이 생기느냐를 건조하게 적으면 이렇습니다. 워드 파일의 docProps/core.xml 안에 있는 dc:creator와 cp:lastModifiedBy — 내 이름일 수도, 같은 팀 동료 이름일 수도, 애초에 받아 쓴 양식을 만든 사람 이름일 수도 있습니다 — 그리고 docProps/app.xml의 <Company> 항목은 내가 내보내는 PDF에 그대로 실릴 후보입니다. PDF 저장은 필터가 아닙니다. 앞에 체크박스가 하나 붙어 있는 복사이고, 그 체크박스가 내 컴퓨터에서 어느 쪽으로 켜져 있는지는 대화상자를 열어 보기 전에는 알 수 없습니다.

새로 찍히는 쪽: 변환 도구는 자기 서명을 남깁니다

두 번째 절반은 체크박스가 관여하지 않는 영역입니다. PDF에는 문서 정보 사전(document information dictionary)이 있고 Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate 같은 항목이 들어갑니다(ISO 32000-1). 요즘 파일은 대부분 같은 정보를 다른 형태로 담은 XMP 패킷도 함께 가지고 있습니다. 이 중 두 항목은 도구를 가리키기 위해 존재합니다. 하나는 문서가 원래 어느 프로그램에서 왔는지, 다른 하나는 그 PDF를 실제로 만들어 낸 소프트웨어가 무엇인지를 적습니다. 또 두 항목은 시각입니다. 이것들은 원본 문서에서 복사되어 오는 값이 아닙니다. 애초에 원본 문서에 관한 값이 아니기 때문입니다. 내보내기가 실행되는 순간, 내보내기를 하는 프로그램이, 자기 자신에 대해 씁니다.

이 구분을 눈으로 확인하기 좋은 예가 있습니다. 영국 정보위원회(ICO)는 How to disclose information safely(정보를 안전하게 공개하는 방법)라는 안내 문서를 PDF로 배포합니다. ICO가 제공하는 그 PDF를 내려받아 XMP 패킷을 열어 보면(2026년 9월 7일 시점에 배포되는 사본 기준) dc:title과 dc:creator는 비어 있습니다. 제목과 작성자는 누군가 지웠고, 그건 잘한 일입니다. 그 옆에는 xmp:CreatorTool "Acrobat PDFMaker 17 for Word", pdf:Producer "Adobe PDF Library 15.0", xmp:CreateDate 2018-06-01T15:35:52+01:00, xmp:ModifyDate 2020-12-24T08:46:58Z가 그대로 남아 있습니다.

여기에 개인정보 유출은 없습니다. 사람 이름도 없고, 흠집을 내려고 가져온 사례도 아닙니다. 이 파일을 인용하는 이유는 구조가 아주 깔끔하게 드러나기 때문입니다. 사람이 지우는 항목과 변환 도구가 쓰는 항목은 서로 다른 항목이고, 서로 다른 시점에, 서로 다른 소프트웨어가 씁니다. 앞쪽을 아무리 정성껏 지워도 뒤쪽은 그대로입니다. 남아 있는 것은 결국 작업 도구 이력입니다. 워드로 썼고, Acrobat PDFMaker로 변환했고, 어느 어도비 라이브러리가 찍어 냈고, 2018년 6월의 어느 금요일 오후에 처음 만들어졌고, 2020년 12월 24일에 마지막으로 손댔다는 이야기. 한 조직의 소프트웨어 구성과 누군가의 근무 시각에 관한 짧은 문단이, 하필 "정보를 안전하게 공개하는 방법" 문서 안에 들어 있는 셈입니다.

생성 시각은 사소한 정보가 아닙니다

작성일·수정일 정도는 별것 아니라고 넘기기 쉽습니다. 법정에서는 그렇지 않습니다. 미국 애리조나주 대법원이 2009년 10월 29일 선고한 Lake v. City of Phoenix 사건에서, 피닉스시 소속 경찰관이 자신의 근무 평가에 관해 상급자가 작성한 메모를 정보공개로 청구해 종이 사본을 받았습니다. 그는 그 메모가 "컴퓨터로 작성될 때 날짜가 소급되었다(backdated)"고 의심했고, 메타데이터가 붙은 전자 원본을 다시 청구했습니다. 시는 메타데이터는 공공기록이 아니라며 거부했고 1심과 항소심은 시의 손을 들어 주었지만, 대법원은 이를 뒤집으며 이유를 한 문장으로 정리했습니다. "공무원이 컴퓨터로 공적 기록을 작성할 때, 메타데이터는 지면 위의 문구와 마찬가지로 그 문서의 일부를 이룬다."

미국 정보공개법에 관한 판단이므로 다른 나라 제도에 그대로 옮겨지지는 않습니다. 다만 그 바탕에 있는 관찰은 어디서나 유효합니다. CreationDate는 장식이 아니라 이 파일이 언제 만들어졌는가에 대한 주장이고, 받는 쪽은 실제로 그렇게 읽습니다. 그리고 여기서 이 글이 분명히 해 둬야 할 방향이 하나 생깁니다. 지우면 안 되는 문서가 있습니다. 소송·수사·감사·기록물 보존 의무의 대상인 파일에서 메타데이터를 제거하는 것은 개인정보 관리가 아니라 증거를 훼손하는 행위이고, 그 자체로 불이익의 사유가 됩니다. 이 글이 다루는 것은 내가 내 판단으로 보낼 수 있는 문서 — 이력서, 포트폴리오, 견적서, 사진, 내가 어떤 노트북으로 작성했는지 알 이유가 없는 곳에 내는 신청서 — 이지, 상대방에게 원본 그대로 받을 권리가 있는 문서가 아닙니다.

그래서 정리는 순서상 가장 마지막이어야 합니다

앞의 두 절을 붙이면 실무 규칙이 저절로 나옵니다. 메타데이터는 파일을 쓰는 쪽이 씁니다. 그러니 아무리 깨끗하게 정리한 파일이라도, 다른 무언가가 그 파일을 한 번 더 저장하는 순간 깨끗하지 않게 됩니다. 조용히 다시 찍는 단계들은 하나같이 평범한 작업입니다.

• 내용을 조금 고치고 PDF로 다시 내보내기
• "PDF 용량 줄이기"나 "PDF 합치기" 웹 도구에 한 번 통과시키기
• 인쇄 → PDF로 저장 (인쇄 경로 자체가 하나의 생성 도구입니다)
• 클라우드 문서 도구로 열었다가 다시 내려받기
• PDF 편집기로 서명·도장·쪽번호 넣기
• 다른 형식으로 변환했다가 되돌리기

어느 것도 잘못된 사용이 아닙니다. 그냥 사람들이 파일에 하는 일입니다. 결론은 하나입니다. 메타데이터 제거는 문서에 한 번 걸어 두고 잊어버리는 상태가 아니라, 순서 안에서 자리를 갖는 단계이고, 그 자리는 맨 끝 — 파일이 내 컴퓨터를 떠나기 직전 — 입니다. 지운 다음에 뭔가를 더 했다면, 다시 지우십시오.

NearScrub이 하는 일과, 하지 못하는 일

NearScrub은 브라우저 탭 안에서만 동작합니다. 파일은 서버로 올라가지 않습니다. PDF에 대해서는 정확히 두 가지를 합니다. 위에서 나열한 문서 정보 항목 여덟 개를 삭제하고, XMP 메타데이터 스트림이 있으면 함께 삭제합니다. JPEG에서는 EXIF/GPS, XMP, IPTC 구간과 이미지 주석을 떼어 냅니다. PNG에서는 텍스트·시각 청크를 제거합니다. docx·xlsx·pptx에서는 docProps/core.xml, docProps/app.xml, docProps/custom.xml 세 파트를 비우고 압축을 다시 만듭니다.

그리고 그 목록이 곧 한계선입니다. 정직하게 적으면 기능 목록보다 이쪽이 더 깁니다.

• 다음 내보내기를 막지 못합니다. 이 글 전체의 요지입니다. 그 파일을 다시 쓰는 다음 소프트웨어 앞에서, 제거 도구가 한 일은 남지 않습니다.
• 페이지 내용은 건드리지 않습니다. 문단 위에 그려 넣은 검은 사각형은 그려 넣은 도형으로 남고, 그 아래 텍스트는 그대로 선택되고 복사됩니다. 주석·양식 필드·첨부 파일·레이어, 스캔본 뒤에 깔린 OCR 텍스트층도 손대지 않습니다. 지운 단어가 주변 글자들의 배치(글리프 위치)로 새어 나가는 문제도 메타데이터 제거로는 전혀 다루지 못합니다.
• 오피스 문서에서는 docProps 세 파트만 비웁니다. 변경 내용 추적, 댓글, 발표자 노트, 숨긴 행·열, 포함된 개체는 같은 압축 파일 안의 다른 자리에 있고 그대로 남습니다. 그것들은 워드나 엑셀에서 먼저 정리하셔야 합니다.
• ODF는 파일 선택 화면이 주는 인상보다 약합니다. .odt·.ods·.odp도 받아 주지만, 오픈도큐먼트는 속성을 docProps/가 아니라 meta.xml에 보관합니다. 그래서 이 파일들에 NearScrub이 실제로 하는 일은 압축을 다시 만드는 것뿐입니다. 속성은 리브레오피스에서 직접 지우십시오.
• 한글 문서(HWP·HWPX)는 지원하지 않습니다. 지원 형식은 JPEG, PNG, PDF, 그리고 OOXML 계열뿐입니다. 아이폰 기본 촬영 형식인 HEIC, 동영상, TIFF, RAW도 대상이 아닙니다. 지원하지 않는 파일은 "정리했다"고 표시하지 않고 그대로 통과시킵니다.
• 결과물은 재직렬화입니다. PDF는 다시 저장되고 오피스 파일은 다시 압축되므로, 바이트 배열과 해시값이 원본과 달라집니다. 받는 쪽이 해시를 대조해야 하는 상황이라면 정리한 뒤에 해시를 내야 합니다.
• 눈에 보이는 것에 대해서는 아무 말도 하지 않습니다. 사진에 찍힌 간판, 문서 머리의 회사 로고, 본문에 적힌 고객사 이름은 전부 그대로 남고, 그대로 읽힙니다.

직접 확인하는 데 30초면 됩니다

이 글의 첫 문단을 검증하는 데 특별한 도구는 필요 없습니다. 아무 문서나 PDF로 내보낸 다음 그 결과물의 속성을 열어 보십시오. 아크로뱃이면 파일 → 속성, 맥 미리보기면 도구 → 검사기 표시, 브라우저 PDF 뷰어에도 대부분 문서 속성 패널이 있습니다. 작성자, 응용 프로그램, PDF 제작 도구 항목에 무엇이 들어 있는지, 생성 시각이 언제로 찍혀 있는지 보십시오. 그다음 그 파일을 NearScrub에 넣고 속성을 다시 열어 항목이 비었는지 확인하십시오. 그리고 여기서부터가 진짜입니다. 원래 다음에 하려던 작업 — 용량 줄이기든 전자서명이든 재변환이든 — 을 그 정리된 파일에 해 보고, 속성을 한 번 더 여십시오. 거기 다시 들어와 있는 값이, 그대로 두었다면 상대방이 받았을 값입니다.