HWPX 의무화가 공공 SI·AI 개발사에 의미하는 것: 레거시 HWP 아카이브 마이그레이션 체크리스트

새 문서는 규정이 해결하지만, 과거 문서는 누군가 해결해야 한다

2026년 5월 HWPX 의무화 이후 새로 생성되는 공공문서는 정책적으로 개방형 포맷을 따르게 됐습니다. 하지만 이 조치가 다루지 않는 영역이 있습니다 — 이미 수년, 길게는 수십 년치 쌓여 있는 기존 HWP 아카이브입니다.

공공기관의 RAG/AI 프로젝트를 수행하는 SI사와 개발사 입장에서는, "앞으로 생성되는 문서"보다 "이미 존재하는 문서 자산을 어떻게 검색 가능한 지식베이스로 만드는가"가 훨씬 큰 작업량을 차지하는 경우가 많습니다. 신규 문서 정책과 별개로, 레거시 아카이브 마이그레이션은 사업 범위에 명시적으로 포함시켜야 하는 항목입니다.

마이그레이션 전 확인 체크리스트

1. 문서 인벤토리부터 만든다

전체 문서 수, 포맷별(HWP/HWPX/DOC/PDF) 비중
스캔 이미지를 그대로 첨부한 "이미지형 HWP"가 얼마나 섞여 있는지 (이 경우 OCR 단계가 별도로 필요합니다)
암호화되어 있거나 배포용으로 잠긴 문서 비율

2. 구조 보존 여부를 기준으로 변환 방식을 정한다

단순 텍스트 덤프와 구조 보존 변환은 결과물이 다릅니다. 표, 문단 계층, 제목 구조가 필요한 문서(규정집, 지침, 평가표)는 반드시 구조를 보존하는 변환 경로를 택해야 하며, 단순 공지문처럼 구조가 중요하지 않은 문서는 텍스트 추출만으로 충분할 수 있습니다. 전체 아카이브를 하나의 방식으로 일괄 처리하면 둘 중 한쪽에서 손실이 발생합니다.

3. 변환 검증 샘플을 문서 유형별로 뽑는다

전체를 다 확인할 수는 없지만, 문서 유형(규정, 회의록, 예산서, 공고문 등)별로 최소 1건씩은 변환 전후를 직접 대조해야 합니다. 특히 표가 포함된 문서는 반드시 행·열 관계가 유지됐는지 확인이 필요합니다.

4. 메타데이터 매핑 규칙을 먼저 정의한다

작성 부서, 시행일, 문서 번호 같은 메타데이터를 어디서 가져올지(파일명 규칙, 문서 내부 표기, 별도 관리대장) 미리 정의해두지 않으면, 수만 건 규모의 마이그레이션에서 메타데이터 누락이 뒤늦게 발견되어 재작업으로 이어집니다.

5. 버전 충돌을 처리할 규칙을 세운다

같은 문서의 여러 버전(수정 이력, 부서별 사본)이 동시에 존재하는 경우가 흔합니다. RAG 벡터 DB에 최신본과 구본이 함께 색인되면 AI가 폐기된 규정을 최신 정책인 것처럼 인용하는 문제가 생길 수 있습니다. 어떤 버전을 '정본'으로 취급할지 규칙을 마이그레이션 이전에 정해야 합니다.

6. 보안 등급별 처리 경로를 분리한다

공공문서에는 대외비, 배포 제한 문서가 섞여 있을 수 있습니다. 전체를 동일한 파이프라인으로 처리하기 전에, 보안 등급에 따라 외부 API 호출이 가능한 문서군과 온프레미스에서만 처리해야 하는 문서군을 먼저 구분해야 합니다.

7. 마이그레이션은 1회성이 아니라 파이프라인으로 설계한다

아카이브 마이그레이션이 끝나도 신규 문서는 계속 생성됩니다. 초기 마이그레이션에 사용한 변환 로직을 상시 파이프라인으로 재사용할 수 있는 구조로 만들어두면, 프로젝트 종료 후 운영 단계에서 별도 개발 없이 이어갈 수 있습니다.

결론

HWPX 의무화는 신규 문서의 문제를 해결하지만, 레거시 아카이브는 사업 계획 단계에서 별도로 다뤄야 하는 작업입니다. 공공 AI 사업을 수주했다면, 제안 단계에서부터 아카이브 규모 실사와 구조 보존 변환 검증을 사업 범위에 명시적으로 포함시키는 것이 이후 재작업 리스크를 줄이는 방법입니다.

참고 자료

이 글의 체크리스트는 일반적인 문서 마이그레이션 실무 원칙을 정리한 것이며, 특정 기관이나 프로젝트의 사례를 지칭하지 않습니다. 실제 사업에서는 발주 기관의 보안 지침과 개인정보 처리 규정을 최우선으로 확인하시길 권장합니다.