한국 공공데이터의 진짜 장벽은 HWP다
대량의 HWP 문서를 구조화하지 못하면 공공데이터는 공개돼 있어도 기계가 쓰기 어렵습니다. 공공 AX의 병목은 바로 여기서 터집니다.
대량의 HWP 문서를 구조화하지 못하면 공공데이터는 공개돼 있어도 기계가 쓰기 어렵습니다. 공공 AX의 병목은 바로 여기서 터집니다.
공공 AX는 원천 문서 포맷에서 먼저 멈춥니다. 원천 문서를 기계가 읽을 수 없으면, 그 뒤의 모델 성능은 힘을 쓰기 어렵습니다.
이 점을 가장 선명하게 보여주는 포맷이 HWP입니다.
대량의 HWP 문서를 다룰 때가 그랬습니다. 파일은 이미 있었습니다. 사람 이름도 있었고, 발령사항도 있었고, 표도 있었습니다. 겉으로 보면 필요한 정보가 다 공개된 것처럼 보였습니다. 그런데 실제로 데이터를 뽑아 쓰려는 순간부터 상황이 달라졌습니다. 사람이 읽을 수 있는 문서와, 기계가 바로 사용할 수 있는 데이터 사이에는 큰 간극이 있었습니다.
많은 사람들은 공공데이터 이야기를 하면 먼저 API를 떠올립니다. 인증키를 어떻게 받는지, JSON 필드를 어떻게 읽는지, 호출 제한이 어떤지를 묻습니다. 물론 그것도 중요합니다. 다만 한국 공공데이터를 실제로 오래 다뤄보면 더 자주 부딪히는 벽은 문서 파일 쪽에 있습니다. 실무의 원천 자료 상당수가 API가 아니라 문서 파일 안에 들어 있고, 그 문서 포맷의 중심에 HWP가 있기 때문입니다.
API는 문서 밖 함정이 많아도 결국 구조화된 필드와 값으로 도착합니다. 반면 HWP는 필요한 내용이 안에 들어 있어도, 그것을 안정적으로 꺼내고 다시 재사용 가능한 데이터로 바꾸는 공정이 별도로 필요합니다. 파일이 존재한다는 사실만으로는 충분하지 않습니다. 업무에 투입 가능한 데이터가 되기까지 추가 노동이 길게 붙습니다.
대량의 HWP 문서를 구조화할 때도 첫 번째 문제는 파서를 고르는 일이었습니다. hwp5txt, pyhwp, hwp-hwpx-parser 같은 도구를 차례로 써보면 결과가 제각각 나옵니다. 어떤 도구는 텍스트는 그럴듯하게 뽑지만 표 구조를 무너뜨립니다. 어떤 도구는 셀 병합을 어긋나게 읽습니다. 이런 문서에서 중요한 것은 문장 몇 줄이 아니라 표 안의 구조였기 때문에, 이 차이는 곧바로 데이터 품질 문제로 이어졌습니다.
HWPX도 사정은 비슷합니다. 겉으로는 공개 포맷이고, 실제로는 ZIP 안에 XML이 들어 있습니다. 그래서 처음에는 더 쉬울 것처럼 보입니다. 하지만 막상 다루기 시작하면 ZIP을 풀고, XML 블록을 읽고, 표 병합과 셀 순서를 다시 해석해야 합니다. 문서마다 구조가 조금씩 달라서 한 번 먹힌 규칙이 다른 문서에서는 바로 깨집니다. 형식이 공개되어 있다는 사실만으로 자동화 비용이 낮아지지는 않았습니다.
여기서 분명해진 것은 파서 하나로는 업무에 바로 쓸 수 있는 데이터까지 잘 가지 않는다는 점입니다.
Python으로 자동 추출한 결과를 그대로 쓰면 누락과 오분류와 구조 깨짐이 반복해서 나옵니다. 텍스트는 뽑혔는데 열과 행이 어긋나 있고, 표는 잡혔는데 의미 단위가 흐트러져 있고, 발령사항이 사람 이름과 잘못 붙는 일이 생깁니다. 결국 파서는 1차 추출기일 뿐입니다. 실제 업무에 쓸 수 있는 데이터로 바꾸려면, 추출 결과를 다시 정리하고 의미 단위로 재구성하는 2단계가 따라와야 합니다.
그래서 파이프라인은 두 단계로 갈 수밖에 없었습니다. 먼저 파서로 최대한 많이 꺼내고, 그다음 LLM으로 구조를 바로잡고 의미 단위를 다시 세우는 방식입니다.
이렇게 해야 비로소 HWP 문서가 데이터처럼 움직이기 시작했습니다. AI 시대가 왔다고 해서 HWP 문제가 사라진 것은 아닙니다. 오히려 병목이 어디 있는지가 더 선명해졌습니다. LLM은 정제와 재구성에는 강하지만, 거친 원천 포맷이 만드는 마찰까지 자동으로 없애주지는 못합니다.
이건 특정 기관의 특정 문서에만 해당하는 문제가 아닙니다. 한국 공공기관의 공식 문서는 여전히 HWP로 작성되는 경우가 많습니다. 인사발령, 직제 시행규칙, 업무보고, 기능분석 자료, 각종 편람과 검토자료가 여기에 걸립니다. 공공데이터포털에서 API로 받을 수 있는 구조화된 데이터는 전체 공공 정보의 일부일 뿐입니다. 실제 업무의 원천 자료는 여전히 문서 파일 안에 많이 묻혀 있습니다.
그래서 한국에서 공공데이터를 진지하게 다루려면 API만 잘 붙여서는 부족합니다. HWP를 열고, 표를 뽑고, 구조를 해석하고, 다시 정제하는 파이프라인이 있어야 합니다. 이 과정은 화려하지 않습니다. 데모 영상에서는 잘 보이지 않고, 발표자료에서도 잘 드러나지 않습니다. 하지만 이 공정을 통과하지 않으면 한국 공공데이터의 큰 부분은 여전히 기계가 쓸 수 없는 상태로 남습니다.
이 지점에서 공공 AI 에이전트의 역할도 분명해집니다. AI 에이전트는 HWP를 마법처럼 없애주지 않습니다. 대신 어떤 파서가 어떤 문서에서 잘 읽히는지, 어디서 표 병합이 자주 깨지는지, 어떤 후처리 규칙이 품질을 끌어올리는지 같은 운영 지식을 계속 축적할 수 있습니다. 사람이 매번 처음부터 다시 실험하지 않아도 되게 만드는 것입니다.
그러면 사람의 역할도 바뀝니다. 어떤 문서를 먼저 구조화할지, 어디까지를 업무에 투입 가능한 데이터로 볼지, 어떤 품질이면 사람 검토로 넘길지를 정하는 일이 더 중요해집니다. 반복적인 파싱 시행착오는 에이전트가 더 많이 흡수하고, 사람은 방향과 기준을 잡는 쪽으로 이동할 수 있습니다.
현장 수요는 이미 올라오고 있습니다. 보고서를 더 빨리 쓰고 싶고, 공개자료를 더 정확하게 비교하고 싶고, 법령과 통계를 함께 읽고 싶어 합니다. 그런데 원천 문서가 HWP에 묶여 있으면 그 수요는 늘 같은 자리에서 한 번씩 멈춥니다.
그래서 결론은 단순합니다.
한국 공공데이터의 진짜 장벽은 HWP입니다.