PDF로 받은 문서를 한글에서 고쳐야 할 때

막히는 이유는 PDF가 문서가 아니기 때문이다. 정확히는 문서를 인쇄한 결과물이다.

PDF 안에는 문단이 없다

PDF는 글을 담는 형식이 아니라 쪽을 그리는 형식이다. 파일 안에 들어 있는 것은 "가로 72, 세로 680 자리에 글자 ‘신’을 찍어라" 같은 지시뿐이다. 어디서 문단이 끊겼는지, 어느 줄과 어느 줄이 한 표의 같은 행이었는지는 어디에도 적혀 있지 않다.

한글이나 워드에서 PDF로 내보내는 순간 그 정보가 버려지기 때문이다. 인쇄물에 문단 정보가 필요 없는 것과 같은 이치다. 그래서 PDF를 문서로 되돌리는 일은 변환이 아니라 복원이다. 글자가 놓인 자리를 보고 원래 모양을 추측하는 것이다.

이 차이를 알고 나면 "변환기가 왜 이 모양이냐"는 물음이 "여기까지가 원래 가능한 범위구나"로 바뀐다. 어떤 도구를 쓰든 마찬가지다.

무엇이 넘어오고 무엇이 넘어오지 않나

자리를 보고 추측할 수 있는 것과 없는 것이 갈린다. 줄 간격이 벌어졌으면 문단이 끊긴 것으로 볼 수 있다. 여러 줄에 걸쳐 칸의 왼쪽 끝이 같은 자리에 서 있으면 표로 볼 수 있다. 그림과 도장은 추측할 필요가 없다. 쪽에 박혀 있는 실물이라 그대로 꺼내면 된다. 다만 꺼낸 그림을 어디에 놓을지는 다른 문제다. 원래 좌표에 박으면 고칠 수 없는 문서가 되므로, 글의 순서를 따라 그림이 있던 자리 앞뒤 문단 사이에 넣는다. 반면 원본이 어떤 글꼴이었는지는 추측의 대상조차 아니라 그냥 없는 정보다.

그림으로 붙이는 변환과는 다르다

변환 결과가 한글에서 열리기는 하는데 글자를 하나도 고칠 수 없는 경우가 있다. 쪽을 그림으로 떠서 문서 안에 붙여 놓은 것이다. 파일 확장자만 .hwp 일 뿐 내용은 사진첩이다.

그렇게 만들면 화면상 원본과 똑같아 보이므로 변환기 입장에서는 유혹이 크다. 하지만 고칠 수 없는 문서는 애초에 고치려고 변환한 사람에게 아무 쓸모가 없다. 판별법은 간단하다. 한글에서 열어 글자 가운데를 클릭해 커서가 들어가면 진짜 문서이고, 그림 전체가 선택되면 사진이다.

한컴오피스 없이 어디까지 되나

예전에는 두 가지 길뿐이었다. 한컴오피스를 설치하거나, 온라인 변환 서비스에 파일을 올리거나. 앞의 것은 유료이고 맥에서는 불편하며, 뒤의 것은 남에게 보이면 안 되는 문서를 남의 서버에 올리는 일이다. 공고문이야 공개된 문서지만, 그 서식으로 만든 신청서에는 주민등록번호와 계좌번호가 들어간다.

지금은 세 번째 길이 있다. 한글 문서를 읽고 쓰는 엔진이 WebAssembly 로 컴파일되어 브라우저 안에서 도는 것이다. 이 사이트의 PDF → HWP, PDF → HWPX 도구가 그렇게 동작한다. 처음 한 번 8MB 짜리 엔진을 내려받은 뒤로는 파일이 기기 밖으로 나가지 않는다.

HWP 와 HWPX 중 무엇으로 만들까

내는 곳이 형식을 정해 줬다면 그것을 따르면 된다. 정해진 것이 없다면 HWPX 가 낫다. 구조가 공개된 개방형이고, 2026년부터 공공기관이 문서를 낼 때 쓰도록 정해진 형식이다.

HWP 를 골라야 하는 경우도 있다. 한글 2007 이전 버전에서 열어야 하거나, 받는 쪽 업무 시스템이 .hwp 확장자만 받을 때다. 두 형식은 같은 문서를 담는 두 그릇이라 안에 담기는 내용은 같다.

스캔한 PDF 는 어떤 도구로도 안 된다

종이를 복합기로 스캔해 만든 PDF 는 쪽 전체가 사진 한 장이다. 사람 눈에는 글자로 보이지만 파일 안에는 글자가 한 자도 없다. 꺼낼 것이 없으니 되돌릴 것도 없다. 이것은 도구의 성능 문제가 아니라 원본에 정보가 없는 문제다.

그림 속 글자를 알아보는 기술(OCR)을 쓰면 글자를 만들어 낼 수는 있다. 다만 그것은 추출이 아니라 인식이라, 숫자 0 과 영문 O 를 뒤바꾸는 식의 오류가 섞인다. 제출용 문서에서는 그 오류가 비싸다. 이 사이트에서 OCR 을 넣지 않은 이유다.

스캔본이라면 원본 한글 파일을 발급처에 요청하는 편이 빠르다. 공공기관은 대개 원본을 가지고 있고, 요청하면 주는 경우가 많다.