2026-09-07

제 컴퓨터에선 잘 열렸는데요, 내 PDF가 상대방 화면에서 다르게 보이는 이유

PDF 문제로 들어오는 문의는 거의 전부 "두 번째 화면"에서 벌어진 일입니다. 만든 컴퓨터에서는 멀쩡히 열렸습니다. 그런데 받은 사람이 열자 다른 게 나옵니다. 고르지도 않은 글꼴로 바뀌어 있고 줄이 엉뚱한 데서 넘어가거나, 분명히 채워 넣은 서식의 칸이 전부 비어 있거나, 휴대폰에서는 아예 열리지 않습니다. 보낸 사람은 이 현상을 재현할 수조차 없습니다. 자기 화면에서는 여전히 멀쩡하니까요.

이 글은 그 두 번째 화면 이야기입니다. 서류를 어떻게 묶어 제출하느냐가 아니라 — 그건 이 블로그의 다른 글들이 다룹니다 — PDF를 보낼 때 파일 안에서 실제로 무엇이 함께 건너가는지, 어느 부분이 받는 사람 컴퓨터에 뭔가가 깔려 있어야만 제대로 보이는지, 그리고 보내기를 누르기 전 2분 동안 해볼 만한 확인이 무엇인지에 관한 글입니다. 여기서 NearPDF가 하는 역할은 작고 대부분 경고에 가깝습니다. 절대 NearPDF에 맡기면 안 되는 일 한 가지까지 포함해서, 그대로 적겠습니다.

저장 대화 상자에서 이미 갈린다

한국에서 이 문제가 가장 흔하게 시작되는 지점은 문서를 PDF로 저장하는 순간입니다. 한컴오피스 공식 도움말의 [PDF로 저장하기] 문서는 그 함정을 한 화면에 세 개나 적어 두고 있습니다. 어느 오피스 프로그램에나 비슷한 게 있으니 한컴을 쓰지 않더라도 알아 둘 값어치가 있습니다.

첫째, 글꼴입니다. 도움말은 "OTF 글꼴이 포함된 문서를 PDF로 변환하는 경우 해당 글꼴은 다른 글꼴로 대체되어 표시됩니다"라고 명시합니다. 대체된다는 건 글자 폭이 달라진다는 뜻이고, 글자 폭이 달라지면 줄바꿈 위치가 움직이고, 표가 한 칸씩 밀립니다. 둘째, 글꼴을 넣을 수 있느냐 자체가 저작권 문제입니다. "글꼴 제공업체에서 포함 허가를 설정한 글꼴만 포함할 수 있습니다. 글꼴을 포함하면 사용자가 파일을 보거나 인쇄할 때 글꼴이 대체되지 않으며 텍스트가 원래 글꼴로 표시됩니다." 셋째, 용지 크기입니다. "[사용자 정의] 용지 크기로 설정된 문서를 변환하는 경우 해당 PDF는 기본 용지 크기(A4)로 생성되며, 영역을 벗어나는 원본 문서의 일부 내용이 올바르게 나타나지 않을 수 있습니다." 상장이나 도면처럼 규격 밖 용지로 만든 문서는 받는 사람이 등장하기도 전에, 변환되는 그 순간 가장자리를 잃습니다.

국가 표준은 이걸 아예 규칙으로 못박아 두었다

글꼴을 파일 안에 넣어야 한다는 건 취향 문제가 아닙니다. 국가기록원의 NAK 30:2022(v1.1) 문서유형 전자기록물 보존포맷 기술규격: PDF/A-1b 기반의 포맷은 「공공기록물 관리에 관한 법률」 제20조 및 같은 법 시행령 제36조에 따라 중앙기록물관리기관의 장이 정하는 '보존포맷'에 해당하는 표준인데, 제6.3.4항 '내장된 폰트 프로그램'에서 이렇게 정합니다. "규격에 적합한 파일에 사용된 모든 폰트의 폰트프로그램들은 … 그 파일에 포함되어야 한다." 그리고 "파일에 합법적으로 제한 없이, 전체 표현이 가능하게 포함될 수 있는 폰트만을 사용한다", "규격에 적합한 모든 판독기들은 로컬에 상주, 대치 또는 흉내낸 폰트들 대신에 파일에 포함된 폰트들을 표현에 사용한다"까지 못박습니다. 왜 그렇게까지 하느냐는 제6.3.1항에 한 줄로 적혀 있습니다. 조건들이 의도하는 바는 "규격에 따르는 파일의 문자 모양이 원래 생성된 대로 일치하는 것을 보장"하는 것.

같은 표준은 암호도 금지합니다. 제6.1.3항은 파일 트레일러 사전에서 "Encrypt 키워드는 … 사용되어서는 안 된다"고 하고, 상세설명은 그 효과를 이렇게 풀어 둡니다. "Encrypt 키워드의 명백한 금지는 암호화와 비밀번호-보호된 접근 허가를 금하는 암시적인 효과가 있다." 보존해야 할 문서에 비밀번호를 걸어 두면, 비밀번호를 아는 사람이 사라지는 순간 그 문서도 사라지기 때문입니다.

비어서 도착하는 서식, 그리고 값이 저장되는 두 자리

받는 쪽에서 가장 흔한 사고는 채워 보낸 서식이 빈 칸으로 도착하는 일입니다. 분명히 다 입력하고, 저장하고, 첨부해서 보냈는데 "칸이 비어 있는데요"라는 답이 옵니다.

원인은 채워진 서식 칸이 값을 두 군데에 저장하고, 판독기마다 어느 쪽을 믿을지가 다르기 때문입니다. 하나는 값 그 자체로, 필드 사전에 들어갑니다. 다른 하나는 그 값을 칸 안에 그려 넣는 작은 그리기 프로그램 — '모양 스트림(appearance stream)' — 입니다. 제대로 만든 입력 도구는 둘 다 씁니다. 게으른 도구는 값만 쓰고 NeedAppearances라는 깃발을 세웁니다. 그건 판독기에 대한 부탁입니다. "이건 네가 그려라." 그 깃발을 존중하는 판독기에서는 글자가 보이고, 무시하는 판독기에서는 빈 칸이 보입니다. 애초에 그려진 적이 없는 칸을 충실하게 그대로 보여 주는 것뿐이죠.

앞서 인용한 NAK 30:2022은 제6.9항 '대화식 폼'을 통째로 여기에 씁니다. 목적부터 명시적입니다. "이 하위 조항의 조건들의 의도는 폼 필드의 표현에 애매함이 없게 보증하는 것이다." 규칙은 위 실패 모드에서 곧장 따라 나옵니다. "대화식 폼 사전의 NeedAppearances flag는 존재하지 않거나 값이 false이다." 그리고 "모든 폼 필드는 필드 데이터와 연계된 모양 사전을 가지고 있다. 규격에 적합한 판독기는 폼 데이터와 상관없이 모양 사전에 따라 필드를 표현한다." 표준 문투를 걷어내면 이렇습니다. 남에게 건넬 문서라면 데이터만이 아니라 그림을 함께 실어야 한다, 상대 판독기가 대신 그려 줄 거라고 가정하지 마라.

미국 법원은 거부 사유를 아예 공개해 둔다

같은 문제를 다른 각도에서 보여 주는 자료가 있습니다. 미국 연방법원 행정처가 펴낸 차세대 CM/ECF 전자소송 시스템의 PDF 관련 기능 안내(Release 1.6, 2020년 11월)는 제출자에게 어떤 PDF가 시스템에서 거부되는지를 목록으로 공개합니다. PDF 형식 표준을 따르지 않는 파일, 자바스크립트가 들어 있는 파일, "암호화되었거나 비밀번호로 보호된" 파일, 내부 첨부 파일이 들어 있는 파일, 오디오·비디오가 들어 있는 파일이 거부됩니다.

그 목록에서 두 줄은 두 번 읽어 볼 만합니다. 내용과 아무 상관이 없거든요. "Mac OS X에서 Safari 브라우저로 작성 가능 서식을 채워 만든" PDF는 거부되고, "Mac OS X에서 MS Word로 만들면서 '인쇄에 최적화' 옵션을 선택한" PDF도 거부됩니다. 그런데 허용 목록에는 "Mac OS X에서 Chrome 브라우저로 작성 가능 서식을 채워 만든" PDF와 Word에서 '전자 배포에 최적화'를 고른 PDF가 들어 있습니다. 같은 사람이, 같은 서식을, 같은 오후에 만들었는데 — 어느 브라우저가 열려 있었는지, 인쇄 대화 상자에서 어느 라디오 버튼을 눌렀는지가 상대편에서 그 파일이 쓸모 있는지를 가릅니다. 내 화면에서는 둘이 구분되지 않습니다. 이 글 전체를 한 문단으로 줄이면 이겁니다. PDF는 한 덩어리가 아니라 그릇이고, 그릇에 무엇이 담겼는지는 담은 프로그램이 정합니다.

그래서 미국 연방법원들은 작성 가능 서식에 대해 하나같이 같은 말을 합니다. 제5순회항소법원의 PDF 서식 평탄화 방법 안내는 이유를 한 문장으로 끝냅니다. "PDF 작성 가능 서식을 사용할 때, 이용자는 서식 칸을 다 채운 뒤 그 PDF 문서를 잠그거나 '평탄화(flatten)'해야 한다. 그래야 모든 기기에서 문서를 볼 수 있고, 다른 이용자가 그 정보를 조작하거나 편집하는 것을 막을 수 있다." 애리조나 파산법원 안내는 같은 문장을 그대로 쓰고 작동 원리를 덧붙입니다. 평탄화하면 "어떤 이용자도 그 문서를 저장해 서식 칸을 편집하지 못하게 된다." 방법은 두 곳 모두 똑같고, 일부러 단순합니다. 채운 서식을 열고, 파일 → 인쇄 → PDF 프린터 선택 → 인쇄본을 저장. 인쇄는 페이지를 다시 그리는 과정이라, 화면에 있던 것이 평범한 페이지 내용이 되고 이견을 낼 필드 자체가 남지 않습니다.

아예 열리지 않는 서식

드물지만 더 고약한 부류는 문서 대신 안내문이 보이는 경우입니다. 미국 네브래스카주 교육부는 자기 기관 서식 이용자들이 실제로 만나는 문구를 그대로 공개해 두었습니다. "Please wait… If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document."(잠시 기다려 주십시오… 이 메시지가 문서의 본래 내용으로 바뀌지 않는다면, 사용 중인 PDF 뷰어가 이 종류의 문서를 표시하지 못하는 것입니다.) 이건 로딩에 실패한 화면이 아닙니다. 파일 안에 일부러 넣어 둔 표지 페이지이고, 뒤에 있는 것을 다루지 못하는 판독기에게만 보이도록 되어 있습니다. 그 뒤에 있는 것이 XFA 서식 — PDF 껍데기에 싸인 XML 서식 정의 — 입니다.

마이크로소프트가 엣지 관리자용으로 펴낸 정책 문서 ViewXFAPDFInIEModeAllowedOrigins는 이 기술의 상태를 이례적으로 직설적으로 씁니다. "XFA는 그 원 제작자들이 지원을 중단한 레거시 기술이다. ISO 표준이 아니며, 따라서 현대 웹 아키텍처에 맞지 않는다. 계속 사용하는 것은 잠재적 위험과 취약점을 낳는다." 마이크로소프트가 제시하는 우회로는 이런 파일을 인터넷 익스플로러 모드에서 Acrobat ActiveX 플러그인으로 여는 것인데, 그 플러그인은 정책이 설치해 주지도 않습니다. 그리고 바로 아래 지원 플랫폼 표가 이 비상구가 얼마나 좁은지 알려 줍니다. Windows 132 버전 이상, 그리고 macOS·Android·iOS는 전부 "지원하지 않음". 당신이 전달한 서식이 XFA라면 받는 사람의 휴대폰에서는 열리지 않고, 맥에서도 열리지 않습니다. 마이크로소프트의 권고는 아예 다른 방식으로 갈아타라는 것입니다.

NearPDF는 XFA 서식을 고칠 수 없고, 고칠 수 있는 척도 하지 않습니다. 그런 파일은 거의 빈 껍데기로 읽히거나 아예 해석에 실패합니다. 쓸모 있는 수는 상류에 있습니다. 데스크톱의 Acrobat Reader에서 채우고, PDF로 인쇄해서, 그 인쇄본을 보내십시오. 그렇게 나온 건 세상 모든 판독기가 그릴 수 있는 평범한 페이지입니다.

PDF는 그림이 아니라 그릇입니다. 네 개 층 중 세 개는 상대방 컴퓨터에서도 뭔가가 참이어야만 제대로 보입니다.

2분짜리 확인

지금까지의 이야기는 거의 공짜인 습관 하나로 줄어듭니다. 중요한 파일을 보내기 전에, 그 파일을 만든 프로그램이 아닌 다른 뷰어로 한 번 더 열어 보십시오. 한글이나 워드에서 내보냈다면 브라우저에서 보고, 브라우저에서 서식을 채웠다면 데스크톱 판독기에서 봅니다. 그다음 휴대폰에서 열어 봅니다. 이 두 번의 확인이 위에서 다룬 실패 대부분을 걸러 냅니다. 바로 그 두 판독기가 내 파일이 몰래 깔고 있던 가정을 덮어 주지 않는 쪽이거든요. 볼 것은 세 가지입니다. 채운 칸이 여전히 채워져 있는가, 글꼴이 내가 고른 그 글꼴인가, 각 페이지의 마지막 줄이 아직 페이지 안에 들어와 있는가.

채워 넣은 서식이라면 어디로 보내기 전에 법원들이 공개한 인쇄 방식으로 평탄화하십시오. 그리고 문서가 보관까지 살아남아야 하거나 그냥 가장 강한 보장을 원한다면, 일반 PDF 대신 PDF/A로 내보내십시오. 애초에 글꼴 포함을 강제하고 암호화를 금지하는 스위치가 그겁니다. 대부분의 오피스 제품이 같은 저장 대화 상자에서 제공하고, 앞서 인용한 한컴 도움말은 자사 PDF 저장이 기본적으로 PDF/A-1b 포맷으로 저장된다고 적어 두었습니다.

NearPDF가 할 수 있는 일, 그리고 절대 맡기면 안 되는 일

NearPDF는 페이지 단위 도구입니다. 합치고, 나누고, 순서를 바꾸고, 회전하고, 페이지를 지우고, 쪽번호와 워터마크를 찍고, 페이지를 JPG로 바꿉니다. 전부 브라우저 안에서 처리되고 파일은 기기를 떠나지 않습니다. 이 글의 문제들에 대해 NearPDF가 하는 일은 소박한 세 가지와, 위험해 보여서 반드시 짚고 넘어가야 할 한 가지입니다.

첫째, 암호에 대한 탄광 속 카나리아로 쓸 만합니다. 누가 비밀번호 걸린 PDF를 보내오면 NearPDF는 그 파일을 열지 못하고, 조용히 빼 버리는 대신 "암호로 보호되어 제외되었습니다"라고 파일 이름과 함께 알려 줍니다. 이건 CM/ECF가 그냥 거부하는 범주이자, 국가기록원 보존포맷이 트레일러 사전의 Encrypt 키워드를 금지하는 방식으로 막아 둔 범주와 정확히 같습니다. NearPDF가 거부하는 파일은 받는 사람 쪽에서도 말썽을 일으킬 가능성이 높습니다. 다만 역은 성립하지 않습니다. NearPDF가 파일을 열었다는 사실은 어느 법원이나 기관의 접수 시스템이 그 파일을 받아 준다는 증거가 전혀 아닙니다.

둘째, 상대가 정말로 PDF를 아예 열지 못할 때 PDF-to-JPG 도구가 페이지를 어느 기기에서나 보이는 이미지로 바꿔 줍니다. 최후의 수단으로만 쓰고 맞바꿈을 이해하십시오. 결과물은 그림입니다. 아무도 그 안의 글자를 선택하거나 검색하거나 숫자를 복사해 갈 수 없고, PDF를 요구하는 접수 시스템은 받지 않습니다.

셋째 — 그리고 이게 조심해야 할 항목입니다 — 작성 가능 서식을 NearPDF에 통과시켜 놓고 평탄화했다고 생각하지 마십시오. NearPDF는 남긴 페이지를 새 문서로 복사하는 방식으로 결과물을 다시 만듭니다(src/merge.worker.js의 pdf-lib copyPages). 이 앱이 싣고 있는 바로 그 버전인 pdf-lib 1.17.1로 채워진 서식을 넣고 결과를 뜯어보면, 무슨 일이 벌어지는지가 정확히 드러납니다. 카탈로그의 AcroForm 항목이 사라져서 그 파일은 더 이상 서식이 아니고, 서식을 다루는 도구는 필드가 0개라고 보고합니다. 그런데 위젯 주석은 페이지에 그대로 남아 바이트 단위로 동일한 모양 스트림을 들고 있어서 입력한 글자는 여전히 그려지고, 그 주석이 가리키는 필드 사전에는 입력한 값이 그대로 들어 있습니다. 즉 결과물은 평탄화된 것처럼 보이고 필드가 없다고 보고되는데, 답은 아직 파일 안에 앉아 있습니다. 양쪽으로 최악입니다. 서식은 잃고, 데이터는 잃지 않으며, 필드 검사는 근거 없는 안심을 줍니다. 평탄화는 법원들이 안내한 대로 PDF로 인쇄해서 하고, 그다음에야 페이지를 합치거나 순서를 바꿀 일이 있으면 NearPDF로 가져오십시오.

솔직한 한계

NearPDF는 글꼴을 파일에 넣지 못합니다. 자기가 글자를 더하는 경우가 쪽번호와 워터마크 스탬프뿐이고, 그 둘은 Helvetica를 씁니다. 모든 판독기가 내장하고 있는 14개 기본 글꼴 중 하나라 싣는 데 한 바이트도 들지 않고, 바로 그 이유로 라틴 문자만 커버합니다. 워터마크에 한국어·일본어·중국어·키릴·아랍·타이 문자를 넣으면 도구는 아무것도 처리하기 전에 찍을 수 없는 문자를 하나씩 짚어 주고 거부합니다. 빈칸 투성이 페이지를 만들어 내는 대신에요. OCR이 없어서 스캔본은 글자를 찍은 그림으로 남습니다. 압축이 없어서 파일을 줄이는 유일한 방법은 페이지를 빼는 것뿐입니다. 책갈피나 개요도 만들지 않습니다. 페이지를 지우면 남긴 페이지만으로 파일을 다시 만들기 때문에 지운 페이지는 숨겨지는 게 아니라 정말로 없어지지만, 그건 페이지 단위 제거일 뿐 가림 처리가 아닙니다. 그리고 위의 서식 이야기가 보여 주듯 "도구가 더 이상 보고하지 않는다"는 건 "파일에 더 이상 없다"와 같은 말이 아닙니다. 받는 형식은 PDF뿐이고, 일반 데스크톱에서는 500MB까지, 휴대폰이나 메모리가 적은 기기에서는 파일당 50MB에 합계 100MB까지입니다. 암호가 걸린 파일은 아예 열지 못합니다.

하지만 이 글의 요점은 그게 아닙니다. 요점은, 지금 보내려는 파일이 가정들이 담긴 그릇이라는 것, 그 가정 대부분은 두 번째 화면에서 2분이면 확인할 수 있다는 것, 그리고 그중 하나 — 채워 넣은 서식 — 에 대해서는 미국 연방법원들이 수년째 똑같은 해법을 공개해 두고 있다는 것입니다.