[PDF마스터] 한국 문서 업무에는 PDF만으로 부족했다

PDF 도구를 만들면서 처음에는 파일을 합치고 나누는 기능이면 충분하다고 생각했다. 실제 문서를 들여다보니 금방 생각이 달라졌다. 한국의 문서 업무에는 HWP와 HWPX가 있고, 스캔본에는 도장과 인감이 들어가며, 제출 직전에는 주민번호나 연락처를 가려야 한다. PDF는 최종 형식일 뿐, 사용자가 해결해야 하는 일 전체를 설명하지 못했다.

PDF 바깥에서 시작되는 업무

PDF 합치기와 나누기는 여전히 자주 쓰이는 기능이다. 다만 실제 흐름에서는 그 앞뒤가 더 길다. HWPX 문서를 다시 편집 가능한 형태로 만들고, OCR로 스캔본의 내용을 읽고, 외부로 보내기 전에 민감한 정보를 확인한다. 이 작업들이 따로 떨어져 있지 않다는 점이 문제였다.

HwpForge 같은 실험은 이 경계를 보여준다. Markdown을 HWPX로 바꾸는 일은 단순한 포맷 변환처럼 보이지만, 사람이 다시 손볼 수 있는 문서 구조를 보존해야 쓸모가 생긴다. 파일 하나를 바꾸는 기술보다 문서가 다음 사람에게 넘어가는 순간을 놓치지 않는 게 중요했다.

마스킹은 마지막 버튼이 아니었다

민감정보 마스킹도 같은 맥락이다. 보안 기능을 목록에 하나 추가하는 것으로 끝나지 않는다. 사용자가 문서를 제출하거나 공유하기 전에 어떤 부분을 확인해야 하는지 알고, 가려진 결과를 눈으로 검토할 수 있어야 한다. OCR이 잘못 읽은 문장을 그대로 믿으면 마스킹 역시 놓칠 수 있다.

그래서 PDF마스터와 DocuFlow를 생각할 때 기능별 완성도만 따로 보지 않기로 했다. HWPX, OCR, 도장 이미지, 마스킹이 한 문서 안에서 이어지는 지점을 재현해야 했다. “PDF를 처리한다”는 말보다 “문서를 외부로 내보낼 준비를 한다”는 말이 실제 사용에 가까웠다.

제품의 범위를 다시 잡다

이 경험 뒤에는 PDF만 잘 다루는 도구를 만드는 것으로는 부족하다는 결론이 남았다. Private-PDF와 privacy-shield-pdf가 다루는 로컬 처리와 개인정보 보호, pdftomd가 다루는 추출, HwpForge가 다루는 문서 구조는 각각 다른 기능처럼 보인다. 하지만 사용자의 하루에서는 같은 문서가 그 단계를 차례로 통과한다.

범위를 무작정 넓히자는 뜻은 아니다. 어떤 단계에서 정보가 사라지거나 바뀌는지 설명하고, 사용자가 결과를 확인할 수 있게 만드는 것부터 고정해야 한다. 한국 문서 업무의 구체성을 지우지 않는 것이 오히려 제품을 작게 만드는 방법이었다.

마치며

PDF는 시작점이 아니라 문서가 이동하는 과정의 한 지점이었다. 다음 기능을 고를 때도 새 포맷을 더하는 것보다 HWPX, OCR, 마스킹이 실제 제출 흐름에서 어떻게 만나는지 먼저 확인하려 한다.