AI 해결 노트 · 2026-09-18 · 실측 2026-09-18

워드를 PDF로 — 다른 이름으로 저장·내보내기·Print to PDF 셋이 무엇을 잃는지

한 줄로

목차·표·그림·쪽 번호가 든 5쪽짜리 더미 보고서를 세 가지 길로 PDF로 만들어 맞춰 봤습니다. [다른 이름으로 저장]과 [내보내기]로 나온 두 파일은 다섯 쪽을 150dpi로 그렸을 때 다른 화소가 0개였습니다. Microsoft Print to PDF만 다릅니다. 쪽 수·목차 쪽 번호·뽑히는 글자는 그대로인데, 목차를 누르면 그 쪽으로 가는 링크 15개가 0개가 되고 글꼴 이름이 CIDFont+F1로 바뀌며 파일이 18% 커졌습니다.

증상

워드 보고서를 PDF로 넘겨야 하는데 길이 여럿입니다. [다른 이름으로 저장]에서 PDF를 고르는 것, [내보내기]를 쓰는 것, 인쇄에서 Microsoft Print to PDF를 고르는 것. 아무거나 써도 되는지, 뭘 쓰면 뭐가 없어지는지가 문제입니다.

실측 환경

보고서는 직접 지어낸 더미입니다. 사람 이름은 홍길동처럼 지어낸 값만 넣었습니다.

세 가지 저장은 워드 자동화(Word COM)로 걸어 돌렸습니다. 화면에서 메뉴를 눌러 찍은 그림은 이 글에 없습니다.

더미 보고서

제목 1 다섯 개(맨 위 「목차」 포함)와 제목 2 열 개로 짰고, 목차는 그 두 수준을 긁어 갑니다. 워드가 세는 쪽과 목차에 적힌 쪽이 처음부터 맞습니다.

[쪽 수] 5 | [문단 수] 71 | [표] 1 | [그림] 1
[목차 필드코드] 'TOC \\o "1-2" \\h'
[목차 안 하이퍼링크 수] 15
[꼬리말 쪽번호 개수] 1
[문서에 쓰인 글꼴] {'맑은 고딕': 69}

세 가지 길

같은 .docx 하나를 원본으로 세 번 저장했습니다.

[원본] KO3_56_report.docx  39059바이트
[기본 프린터] Microsoft Print to PDF

① SaveAs2(FileFormat=17)                 -> True  166252바이트  1.98초
② ExportAsFixedFormat(ExportFormat=17)   -> True  166104바이트  1.09초
③ PrintOut(PrintToFile=True)             -> True  196276바이트  1.62초

①이 [파일] → [다른 이름으로 저장]에서 파일 형식을 PDF로 고르는 것, ②가 [파일] → [내보내기]로 PDF를 만드는 것, ③이 인쇄에서 Microsoft Print to PDF를 골라 찍는 것에 해당합니다. 호출에 준 값은 형식 지정과 저장할 경로뿐이고, 책갈피·품질 같은 항목은 아무것도 건드리지 않았습니다.

쪽 수·쪽 번호·목차 쪽 번호

먼저 안 잃은 것부터 봅니다.

목차 쪽 번호는 목차 줄에 적힌 숫자와, 그 제목이 PDF 본문에서 실제로 검색되는 쪽을 하나씩 맞춰 센 것입니다.

① 다른 이름으로 저장       맞음 14 / 틀림 0
② 내보내기             맞음 14 / 틀림 0
③ Print to PDF        맞음 14 / 틀림 0

쪽별로 뽑히는 글자 수도 셋이 같습니다.

① 쪽별 글자수 [2349, 967, 1040, 961, 55]
② 쪽별 글자수 [2349, 967, 1040, 961, 55]
③ 쪽별 글자수 [2349, 967, 1040, 961, 55]

한국어 낱말 검색도 세 파일이 같은 쪽에서 걸립니다. 표 안 글자도 그림으로 굳지 않았습니다.

③ Print to PDF  과정별 수료 현황=[1, 4] | 수료율=[4] | 88.9%=[5] | 홍길동=[2, 3, 4]

공백을 뺀 글자를 통째로 견줘도 ①과 ③이 5,372자로 똑같았습니다. 저희는 PyMuPDF로 뽑고 찾았고, 받는 사람의 뷰어에서 Ctrl+F와 복사가 되는지까지는 시험하지 않았습니다.

①과 ②는 그린 결과가 같다

두 파일을 150dpi로 그려 쪽마다 견줬습니다.

① 기준 ['b16da85ae70e', '07a6bcb8a411', '55d7abe578a4', '319bba660386', 'e40851326653']
② 크기 (1241, 1754) | ①과 같은 쪽 [1, 2, 3, 4, 5] / 다른 쪽 []
③ 크기 (1241, 1754) | ①과 같은 쪽 []       / 다른 쪽 [1, 2, 3, 4, 5]

화소를 하나씩 견줘도 ①과 ②는 다섯 쪽 모두 다른 화소가 0개였습니다. 파일 크기는 166,252바이트와 166,104바이트로 148바이트 차이가 났습니다. 어디가 다른지는 뜯어보지 않았습니다.

글꼴 목록도 두 파일이 같습니다.

① 글꼴 3벌: {'BCDEEE+MalgunGothic': 'ttf', 'BCDFEE+MalgunGothic': 'ttf', 'BCDGEE+CambriaMath': 'ttf'}
② 글꼴 3벌: {'BCDEEE+MalgunGothic': 'ttf', 'BCDFEE+MalgunGothic': 'ttf', 'BCDGEE+CambriaMath': 'ttf'}
   파일에 글꼴 데이터가 든 것 3벌 / 안 든 것 0벌

MalgunGothic이라는 이름이 남아 있고, 앞에 붙은 BCDEEE+는 쓴 글자만 잘라 넣었다는 표시입니다. 셋 다 글꼴 데이터가 들어 있다고 표시돼 있습니다. 그 데이터가 온전한지, 맑은 고딕이 없는 컴퓨터에서 열었을 때 모양이 유지되는지는 확인하지 않았습니다.

③ Print to PDF가 잃는 것

목차 링크가 없어진다

① 다른 이름으로 저장   링크 15개 {1: 15} | PDF 책갈피(목차) 0개
② 내보내기         링크 15개 {1: 15} | PDF 책갈피(목차) 0개
③ Print to PDF    링크 0개 {}       | PDF 책갈피(목차) 0개

원본 워드 문서의 목차에는 링크 15개가 붙어 있었습니다(TOC 필드의 \h). ①과 ②는 그 15개를 1쪽에 그대로 옮겼습니다. ③은 하나도 없습니다. 긴 보고서를 PDF로 돌릴 때 목차를 눌러 넘어가길 기대한다면 ③은 쓰지 않는 게 낫습니다.

단, 원본 목차에 링크가 없으면 이 차이도 없습니다. \h 없이 만든 목차로 같은 세 길을 돌려 보니 셋 다 0개였습니다.

목차 필드코드 = 'TOC \\o "1-2"'      목차 안 하이퍼링크 수 = 0
way1_saveas      쪽수=3   66949바이트  링크=0개  책갈피=0개
way2_export      쪽수=3   66854바이트  링크=0개  책갈피=0개
way3_printtopdf  쪽수=3  141439바이트  링크=0개  책갈피=0개

PDF 왼쪽에 뜨는 책갈피 목록은 이번에 만든 여섯 PDF 모두 0개였습니다.

글꼴 이름이 사라진다

③ 글꼴 2벌: {'CIDFont+F1': 'ttf', 'CIDFont+F2': 'ttf'}
   파일에 글꼴 데이터가 든 것 2벌 / 안 든 것 0벌

글꼴 데이터 두 벌이 들어 있다고 표시돼 있고, 따로 잰 글자 뽑기·검색 결과도 ①과 같았습니다. 다만 이름이 CIDFont+F1, CIDFont+F2로 바뀌어서, 이 목록만 봐서는 원래 무슨 글꼴로 썼는지 알 수 없습니다.

파일이 커지고, 그린 화소가 달라진다

196,276바이트로 ①보다 30,024바이트(18%) 큽니다. 같은 쪽을 겹쳐 보면 글자가 미세하게 다릅니다.

쪽 수·뽑히는 글자·목차 쪽 번호는 다 같으니 줄이 통째로 밀린 건 아닙니다. 화소가 왜 다른지까지는 확인하지 않았습니다.

그림은 세 길 모두 5쪽에 900x560 화소 그대로 한 장씩 들어갔습니다.

① 그림 1개 ['5쪽 900x560 화소']
② 그림 1개 ['5쪽 900x560 화소']
③ 그림 1개 ['5쪽 900x560 화소']

표도 마찬가지입니다. 세 PDF 모두 "수료율"은 4쪽에서, 합계 줄의 "88.9%"는 5쪽에서 검색됐습니다. 표가 4쪽에서 시작해 5쪽으로 넘어간다는 뜻이고, 세 길 다 같았습니다.

결과

이번 시험에서 ①과 ②는 그린 결과가 같았고, ③은 목차 링크가 없어지고 글꼴 이름이 바뀌고 그린 화소가 달라졌습니다.

실패한 것

• 처음 만든 보고서의 목차에는 링크가 없었습니다(TOC \o "1-2"). 그 상태로 세 길을 견줬더니 셋 다 링크 0개로 나와 차이가 안 보였습니다. 목차를 링크 붙는 쪽(\h)으로 다시 만들어 처음부터 돌렸고, 이 글의 숫자는 두 번째 것입니다. 링크 없는 쪽 결과도 위에 그대로 실었습니다.
• 목차를 넣을 빈 문단을 Range로 미리 잡아 뒀더니, 뒤에 쓴 본문이 그 범위에 끌려 들어가 목차를 넣는 순간 함께 지워졌습니다. 같은 일을 작은 문서로 다시 내 봤습니다.

잡아 둔 Range 시작=11 끝=12 / 문단 번호=3
본문 다 쓴 뒤 : 문단 20개 / 3쪽
잡아 둔 Range 는 지금 시작=11 끝=2324 (문서 끝=2324)
그 Range 에 목차를 넣은 뒤 : 문단 5개 / 1쪽

• 스타일을 영어 이름으로 부르면 안 됩니다. 화면 언어가 한국어라 이름이 「제목」·「제목 1」·「표준」이었습니다. 번호로 부르면 됩니다.

doc.Styles('Title')     -> com_error: … '요청한 모음의 요소가 존재하지 않습니다.'
doc.Styles('Heading 1') -> com_error: … '요청한 모음의 요소가 존재하지 않습니다.'
doc.Styles(wdStyleTitle -63)    -> 제목
doc.Styles(wdStyleHeading1 -2)  -> 제목 1

• 보고서를 만드는 스크립트가 마지막 점검 단계에서 워드와 끊겨 멈췄습니다(RPC 서버를 사용할 수 없습니다). 파일은 이미 저장된 뒤라, 문서를 다시 열어 확인하는 쪽으로 나눠 돌렸습니다. 끊긴 원인은 못 밝혔습니다.

확인하지 않은 것

• 워드 창을 띄워 메뉴를 눌러 보지 않았습니다. [다른 이름으로 저장]·[내보내기] 창의 생김새, 그 안의 [옵션] 단추는 이 글에 없습니다. 여기 있는 것은 같은 기능을 자동화로 불러 나온 결과뿐입니다.
• ③을 화면에서 인쇄로 고르면 저장 위치를 묻는 창이 뜨는지는 확인하지 않았습니다. 자동화에서는 저장할 경로를 함께 줘서 창 없이 파일이 만들어졌습니다.
• 옵션을 바꾼 경우는 돌려 보지 않았습니다. 책갈피 만들기, PDF/A, 표준·최소 크기 같은 항목은 호출에서 아예 주지 않았습니다.
• 다른 컴퓨터에서 세 PDF를 열었을 때도 같게 보이는지는 확인하지 않았습니다. 만든 컴퓨터에서 PyMuPDF로만 읽었습니다.
• 뷰어에서 목차 줄을 실제로 눌러 봤을 때 그 쪽으로 넘어가는지는 확인하지 않았습니다. 확인한 것은 PDF 안에 링크가 15개 있다는 것입니다.
• 각주·머리말·수식·차트가 든 문서, 글꼴을 여러 벌 섞은 문서는 만들지 않았습니다. 이 더미의 글꼴 집계에는 맑은 고딕만 나왔습니다.
• Hancom PDF 인쇄기로도 찍어 보지 않았습니다. 목록에 있는 것만 확인했습니다.
• 파일에 든 글꼴 데이터가 온전한지는 검사하지 않았습니다. 「들어 있다」는 표시가 붙은 것만 셌습니다.

함께 보기

• 워드 자동 목차 만들고 고친 뒤 갱신하기
• 한글을 PDF로 저장할 때 표·그림·쪽번호가 그대로 나오는지
• 한글 양식 빈칸 채우는 세 가지