이력서를 메일에 첨부하거나, 과제 파일을 제출하거나, 제안서를 거래처에 넘길 때 우리가 확인하는 것은 보통 파일 이름과 본문입니다. 그런데 워드 문서 안에는 본문과 별개로 누가 만들었고, 마지막에 누가 저장했고, 어느 회사 소속이며, 총 몇 분을 편집했는지가 따로 적혀 있습니다.
이 값들이 정확히 어떤 모습으로 저장되는지, 그리고 지운다고 지웠을 때 정말 다 지워지는지를 워드로 문서를 직접 만들어 확인해 봤습니다. 결론부터 말하면 문서 속성만 비우는 방식으로는 이름이 절반쯤 남습니다.

docx는 압축 파일이고, 속성은 별도 파일에 적혀 있습니다
docx 파일의 확장자를 zip으로 바꿔서 압축 프로그램으로 열면 안에 들어 있는 파일 목록이 그대로 보입니다. 이번에 만든 문서 하나에는 파트, 그러니까 내부 파일이 13개 들어 있었습니다.
word/document.xml 3874 바이트 (본문 내용)
docProps/core.xml 755 바이트 (작성자, 마지막 저장자, 저장 횟수)
docProps/app.xml 732 바이트 (회사명, 총 편집 시간, 글자 수)
word/styles.xml 29823 바이트 (서식)
word/settings.xml 3155 바이트 (문서 설정)
본문 텍스트가 들어 있는 곳은 word/document.xml 하나뿐이고, 우리가 신경 쓰는 개인 정보는 docProps 폴더의 두 파일에 따로 보관됩니다. 엑셀 xlsx도 똑같이 zip 구조라, 파일을 뜯어서 원인을 찾는 방식은 두 형식에 그대로 통합니다.
실제로 무엇이 적혀 있었을까
윈도우 11에서 Microsoft Word 2013으로 제안서 형태의 문서를 만들고, 작성자를 "홍길동", 회사명을 "테스트컴퍼니"로 지정한 뒤 저장과 수정을 여러 번 반복했습니다. 그리고 파이썬 표준 라이브러리 zipfile로 docProps/core.xml을 그대로 꺼내 봤습니다.
import zipfile
z = zipfile.ZipFile("제안서.docx")
print(z.read("docProps/core.xml").decode("utf-8"))
출력에서 네임스페이스 선언을 빼고 값이 든 부분만 옮기면 이렇습니다.
<dc:creator>홍길동</dc:creator>
<cp:lastModifiedBy>dev****@outlook.com</cp:lastModifiedBy>
<cp:revision>5</cp:revision>
<dcterms:created>2026-08-27T21:55:00Z</dcterms:created>
<dcterms:modified>2026-08-27T22:00:00Z</dcterms:modified>
여기서 눈에 걸리는 값이 하나 있습니다. 작성자는 분명 홍길동으로 지정했는데, 마지막 저장자 자리에는 지정한 적 없는 이메일 주소가 들어갔습니다. 이 값은 워드에 설정된 사용자 이름을 그대로 가져다 쓰는데, 이 PC는 사용자 이름 칸에 오피스 계정 이메일이 들어가 있었기 때문입니다. 실제 계정이라 위에서는 중간을 가렸습니다.
작성자 이름만 고쳐 놓아도, 저장하는 순간 워드가 마지막 저장자 자리에 자기 사용자 이름을 다시 적어 넣습니다. 회사 PC나 학교 계정으로 로그인된 오피스에서 만든 파일이 특히 그렇습니다.
이어서 docProps/app.xml도 열어 봤습니다.
<TotalTime>4</TotalTime>
<Company>테스트컴퍼니</Company>
<Application>Microsoft Office Word</Application>
<AppVersion>15.0000</AppVersion>
<Words>39</Words>
<CharactersWithSpaces>266</CharactersWithSpaces>
| 항목 | 측정된 값 | 뜻 |
|---|---|---|
| TotalTime | 4 | 이 문서를 편집한 총 시간(분) |
| Company | 테스트컴퍼니 | 오피스에 등록된 회사명 |
| AppVersion | 15.0000 | 작성에 쓴 워드 버전(15는 2013) |
| cp:revision | 5 | 저장한 횟수 |
총 편집 시간은 처음 저장했을 때 0이었습니다. 문서를 열어 둔 채 3분 반 정도 실제로 타이핑하고 저장하자 값이 0에서 4로 올라갔고, 저장 횟수도 4에서 5가 됐습니다. 급하게 만든 문서인지 오래 붙들고 있던 문서인지가 이 숫자에 남는 셈입니다.
지우는 방법과, 지워도 남는 것
가장 확실한 방법은 워드에 들어 있는 문서 검사 기능입니다. 파일 탭에서 정보로 들어가면 문제 확인 버튼이 있고, 그 안에 문서 검사가 있습니다. 검사를 돌리면 항목별 결과가 나오는데, 그중 문서 속성과 개인 정보에 해당하는 항목에서 모두 제거를 누르면 됩니다. 윈도우 탐색기에서 파일을 우클릭해 속성 창의 자세히 탭에 있는 "속성 및 개인 정보 제거"를 써도 되지만, 지워지는 항목의 범위가 워드 문서 검사와 같지는 않을 수 있습니다.
문제는 그다음입니다. 문서 속성 두 파일만 비우면 끝일 것 같지만, 주석이나 변경 내용 추적을 쓴 문서는 사정이 다릅니다. 검토자가 남긴 이름이 본문 파일 안쪽에 따로 박히기 때문입니다.
주석 하나와 변경 내용 추적 상태의 수정 한 건이 들어 있는 문서를 만들어, "김검토"라는 이름이 어느 파트에 들어 있는지 전부 훑어봤습니다. 아래 코드는 파일 이름과 찾을 이름만 바꾸면 그대로 돌아갑니다.
import zipfile
name = "김검토"
with zipfile.ZipFile("검토본.docx") as z:
for part in z.namelist():
if name.encode("utf-8") in z.read(part):
print("발견:", part)
원본에서는 네 곳에서 이름이 나왔습니다. docProps/core.xml, word/document.xml, word/comments.xml, word/people.xml입니다. 여기서 문서 속성만 비운 사본을 만들어 같은 검사를 다시 돌리면 이렇게 나옵니다.
발견: word/document.xml
발견: word/comments.xml
발견: word/people.xml
작성자와 회사명은 사라졌지만 주석에 붙은 검토자 이름, 변경 내용의 수정자 이름, 검토자 목록은 그대로 남았습니다. 반면 같은 원본에 워드의 문서 정보 제거 기능(문서 검사가 실행하는 것과 같은 기능)을 적용한 사본에서는 같은 검사에서 아무것도 나오지 않았습니다. 주석은 남아 있되 작성자 표기가 "만든 이"로 바뀌었고, 검토자 목록 파트인 people.xml은 파일 자체가 사라졌습니다.
정리하면 문서 속성 화면에서 지우는 것으로는 부족하고, 주석이나 변경 내용을 쓴 문서라면 반드시 워드의 문서 검사를 거쳐야 합니다.
자주 묻는 질문
Q. 문서 검사에서 모든 항목을 다 선택해도 되나요?
안전한 쪽이지만 잃는 것이 있습니다. 모든 항목을 제거하자 word/comments.xml 파트가 통째로 사라졌습니다. 이름만 익명 처리된 것이 아니라 주석 내용 자체가 삭제됩니다. 검토 의견을 보관해야 한다면 원본을 따로 두고 보낼 사본에만 적용하시길 권합니다.
Q. PDF로 내보내면 이 정보도 따라가나요?
같은 문서를 워드에서 PDF로 내보낸 뒤 pypdf로 메타데이터를 읽어 보니 Producer와 Creator에 "Microsoft Word 2013"만 있었고, 작성자 이름이나 이메일 문자열은 파일 어디에서도 검색되지 않았습니다. 다만 만드는 프로그램과 버전에 따라 다를 수 있으니, 확인하고 싶다면 두 줄이면 됩니다.
from pypdf import PdfReader
print(PdfReader("제안서.pdf").metadata)
Q. 매번 지우기 번거로운데 애초에 안 들어가게 할 수 없나요?
워드의 파일 탭에서 옵션으로 들어가 일반 항목의 사용자 이름을 확인해 보세요. 이 PC처럼 계정 이메일이 그대로 적혀 있으면 저장할 때마다 그 주소가 문서에 기록됩니다. 실명이나 이메일 대신 무난한 표기로 바꿔 두면 이후 만드는 문서부터 적용됩니다.
Q. 이미 만들어 둔 파일이 수십 개인데 하나씩 열어야 하나요?
위의 전수 조사 코드를 폴더 단위로 돌리면 어떤 파일에 이름이 남아 있는지 목록부터 뽑을 수 있습니다. 실제로 걸린 파일만 워드로 열어 문서 검사를 돌리는 편이 빠릅니다.
사진 파일에 촬영 위치가 남는 것과 같은 이야기가 문서 파일에도 있습니다. 사진 쪽은 EXIF라는 이름으로 따로 다룬 적이 있는데, 문서 쪽은 정보가 여러 파트에 흩어져 있어 한 곳만 지워서는 해결되지 않는다는 점이 다릅니다. 오늘 보낼 파일이 있다면 사본을 하나 만들어 문서 검사부터 돌려 보시면 좋겠습니다.
위 값들은 Word 2013으로 문서를 직접 만들어 저장한 뒤, 파이썬 zipfile로 docx 내부 XML을 열어 읽은 결과입니다. 이메일 주소는 실제 계정이라 일부를 가려 옮겼습니다.
Parquet 저장할 때 compression만 바꿨을 뿐인데 용량이 갈립니다, 코덱 3종 실측 비교
데이터를 Parquet로 저장하다 보면 compression 옵션에 snappy, gzip, zstd 같은 낯선 이름이 등장합니다.아무거나 골라도 열리기는 하니 대충 넘기기 쉽지만,이 한 줄이 파일 크기와 저장 속도를 꽤 크게
richyeon.com
CSV를 열었더니 주소 뒷부분이 옆 칸으로, 값 속 쉼표 때문에 열이 밀리는 문제
이름과 주소가 잘 정리돼 있던 CSV를 프로그램으로 읽었더니,주소 한 칸이 두 칸으로 쪼개지면서 그 뒤 금액까지 줄줄이 옆으로 밀려 버리는 경우가 있습니다.데이터는 멀쩡한데 표만 어긋난 것
richyeon.com
수백만 행 CSV를 pandas로 읽는 게 느릴 때, 읽기 속도를 끌어올리는 방법
수십 메가바이트가 넘는 CSV를 pd.read_csv로 불러올 때마다몇 초씩 기다리게 되면, 분석을 반복할수록 그 시간이 쌓입니다. 그런데 같은 파일이라도 읽는 방법을 조금만 바꾸면 훨씬 빨라집니다.무
richyeon.com
사진 용량 줄일 때 해상도를 줄일까 화질을 낮출까, 무엇이 더 효율적인지 실측
사진 용량을 줄이는 방법은 크게 두 갈래입니다.하나는 가로세로 크기(해상도)를 줄이는 것이고,다른 하나는 크기는 그대로 두고 화질(quality)을 낮추는 것입니다. 둘 다 파일을 가볍게 만들지만,
richyeon.com
'파일 형식 백과사전' 카테고리의 다른 글
| hwp와 hwpx, 같은 문서를 두 형식으로 저장해 안을 열어 봤습니다 (0) | 2026.09.01 |
|---|---|
| PDF에 암호를 걸었는데 그냥 열립니다, 암호 칸이 두 개인 이유 (0) | 2026.08.31 |
| 1.4MB 사진 한 장을 넣는 방법에 따라 워드 파일이 119KB도 되고 372KB도 됐습니다 (0) | 2026.08.31 |
| 같은 폰트를 WOFF와 WOFF2로 각각 바꿔봤더니, 압축 방식 차이가 이만큼 났습니다 (0) | 2026.08.31 |
| .xls와 .xlsx, 확장자만 다른 게 아니라 안에 든 구조 자체가 다릅니다 (0) | 2026.08.30 |