PDF는 iLovePDF, 한글은 포맷팝.
표 구조까지 그대로.

여전히 필요한 한글 문서와 높은 변환 장벽

일상에서는 한글 파일을 쓸 일이 줄었지만, 공공기관 제출 서류·나라장터 입찰 문서·각종 계약과 신청 서류처럼 실제 업무에서는 여전히 HWP/HWPX를 마주칩니다.

RAG 프로젝트를 진행하면서 동료들이 문서 파싱 단계에서 어려움을 겪는 모습도 보았습니다. 관련 오픈소스가 공개되어 있어도 문서 구조를 이해하고 실제 서비스에 연결하는 일은 별개의 문제였습니다.

기존 변환 도구는 글자를 옮겨도 병합 셀과 중첩 표, 문단과 이미지의 순서가 무너지는 경우가 있었습니다. 변환 뒤에 표를 다시 만들고 서식을 손봐야 한다면, 다시 쓸 수 있는 문서라고 보기 어려웠습니다.

문서 구조 해석과 서비스 전 과정 설계

서비스 기획과 UI/UX, 문서 변환 구조 설계, 구현, 배포와 오류 개선을 맡았습니다. HWP/HWPX 안의 문단·글자 서식·표·셀 병합·이미지·페이지 정보를 읽고, 특정 파일 형식에 종속되지 않는 공통 문서 구조로 정리한 뒤 DOCX로 재구성했습니다.

내부 변환 과정은 입력 파일 검증 → 문서 파싱 → 구조 정리 → DOCX 생성 → 결과 검증 순서로 구성했습니다. 사용자 화면에서는 도구 선택과 지원 범위 확인, 파일 변환, 결과 다운로드가 자연스럽게 이어지도록 설계했습니다.

처리 위치와 지원하지 않는 요소, 변환 후 확인해야 할 항목도 함께 안내해 결과를 과장하지 않고 실제 사용에 필요한 정보를 전달했습니다.

텍스트 추출이 아닌 편집 가능한 구조 재구성

파일의 글자만 추출해 새 문서에 넣는 방식은 비교적 간단하지만, 표와 문단이 맺고 있던 관계는 사라집니다. 표를 하나의 문자열로 합치지 않고 셀의 행·열 위치와 병합 범위, 셀 안에 들어 있는 문단·중첩 표·이미지의 순서를 구분해 처리했습니다.

기본 문단과 표는 문서 처리 라이브러리로 생성하고, 병합 셀·고정 너비·세부 테두리·이미지 배치처럼 정밀한 설정이 필요한 부분은 문서 XML을 보완해 재구성했습니다.

모든 작업을 서버로 보내지도 않았습니다. 브라우저에서 처리할 수 있는 PDF·이미지 작업은 사용자 기기 안에서 실행하고, HWP/HWPX 변환과 OCR처럼 서버가 필요한 작업만 별도 경로로 분리했습니다. 기능별 처리 위치를 안내해 개인정보 노출 범위와 서버 연산·전송 부담을 함께 줄였습니다.

실제 문서 기반 회귀 검증

RFP, 공공 서식, 계약서, 보유 문서 등 구조가 다른 파일을 반복 변환하며 병합·중첩 표가 어긋나는 경우, 줄바꿈과 페이지 구성이 달라지는 경우, 이미지 위치와 특수문자가 손실되는 경우를 확인했습니다.

특정 예제 하나에 맞추는 대신 오류가 발생한 문서를 검증 대상으로 남겨, 이후 수정에서도 같은 문제가 다시 생기지 않는지 확인했습니다. 편집 가능한 Word 변환을 제공하는 웹 서비스를 배포한 뒤에도 실제 실패 사례를 기준으로 개선을 이어가고 있습니다.

모든 문서를 원본과 100% 동일하게 재현한다고 표현하지 않습니다. 편집 가능한 문단과 표 구조를 우선 보존하고, 설치되지 않은 글꼴·수식·복잡한 도형처럼 차이가 생길 수 있는 요소는 지원 범위와 점검 방법으로 안내합니다.

도구 선택 → 파일 확인 → 변환 → 결과 점검

1. 도구 선택 HWP/HWPX → Word 변환 도구와 지원 형식, 파일 처리 위치를 확인합니다.
2. 파일 확인 변환할 문서를 선택하고 파일 형식과 필요한 옵션을 확인합니다.
3. 문서 변환 문서의 문단·표·병합 셀·이미지 구조를 분석해 편집 가능한 Word 문서로 변환합니다.
4. 결과 점검 변환 파일을 내려받아 표·문단·이미지와 페이지 구성을 원본과 비교합니다.