AI가 한글(HWP)을 못 읽어서 그래요.
Contents
HWP 탓만은 아닙니다: AI가 ‘못 읽는 것처럼’ 보이는 이유1) 공공문서가 유독 AI를 힘들게 하는 이유: 글자가 아니라 ‘구조’ 때문입니다2) 핵심은 LLM이 아니라 ‘3단계’입니다 (여기서 80%가 결정돼요)3) HWP라서가 아니라 ‘구조가 깨져서’입니다 (Gemini가 되는 이유도 여기)4) 공공기관 관점에서 더 중요한 이유: 보안·감사는 정답보다 ‘추적성’입니다5) 그래서 한국딥러닝은 무엇을 ‘다르게’ 하나요6) 공공기관에서 ‘안전하게’ 굴리는 문서 AI 흐름은 이렇게 잡으면 됩니다정리 : 공공문서가 AI에서 깨지는 이유는 모델보다 ‘Parser(문서 구조화)’입니다HWP 탓만은 아닙니다: AI가 ‘못 읽는 것처럼’ 보이는 이유
공공기관에서 생성형 AI를 써본 분들이라면, 이런 장면이 익숙할 거예요.
“문서 올렸는데… 표가 풀려서 숫자 의미가 바뀌었어요.”
“요약은 그럴듯한데… 근거가 어디인지 못 찾겠어요.”
“결국 사람이 다시 확인하고, 다시 정리하고, 다시 붙여넣고…”
그래서 결론이 종종 이렇게 납니다.
🤔
지디넷코리아도 AI는 한글(HWP)가 바이너리 구조라 그대로는 구조를 시각화·분석하기 까다롭다는 지적이 있지만,
진짜 본질은 이거예요.
🥸
AI가 못 읽는 게 아니라,
공공문서가 ‘AI가 이해할 형태로 정리되지 않아서’
못 읽는 것처럼 보이는 경우가 많아요.
오늘 글은 HWP vs DOCX 논쟁을 하려는 게 아닙니다. 공공기관 실무자(정책·보안·감사)가 바로 써먹을 수 있게, 왜 깨지는지 → 어디서 깨지는지 → 어떻게 해결하는지를 한 편으로 정리해보겠습니다.
1) 공공문서가 유독 AI를 힘들게 하는 이유:
글자가 아니라 ‘구조’ 때문입니다
공공 문서가 어려운 건 한국어라서가 아니라, 문서 구조가 가장 큰 난관이기 때문이에요. 공공 보고서·결재문서에는 이런 게 흔하죠.
표 안의 표(중첩표)
병합셀이 많은 표
텍스트박스로 배치한 문단, 도형/화살표, 각주·캡션
머리말/꼬리말(페이지마다 반복되는 정보)
도장·서명 이미지
사람은 눈으로 대충 연결해서 이해합니다. 하지만 AI는 그런 대충이 없어요.
읽는 규칙이 필요합니다.
이 표의 헤더는 어디인지
이 값이 어느 행/열의 의미인지
캡션이 어떤 표를 설명하는지
본문 순서가 실제 읽기 순서인지
이 규칙이 깨지면, AI는 읽었다고 하지만 사실은 다른 문서를 읽은 셈이 됩니다.
2) 핵심은 LLM이 아니라 ‘3단계’입니다 (여기서 80%가 결정돼요)
문서를 AI가 업무에 쓸 만큼 읽는 과정은 보통 3단계예요.
(용어 혼동이 많아서, 한국딥러닝이 쓰는 표현처럼 더 명확히 나눠볼게요.)
1) Format Reader(포맷 리더): 파일을 열어서 재료를 꺼내는 단계
HWP/HWPX/DOCX/PDF 같은 파일에서 텍스트·표·이미지·객체를 꺼냅니다. 이 단계가 없거나 품질이 낮으면 이런 일이 생깁니다.
업로드 자체가 안 됨
글자가 깨짐
표가 통째로 누락됨
2) Parser(파서): 재료를 AI가 이해할 구조로 정리하는 단계
Parser는 텍스트를 뽑는 게 아니라, 문서의 뼈대(구조)를 복원합니다.
제목-섹션-본문의 계층
표의 헤더/바디 관계, 병합셀 의미
표/캡션/각주 연결
읽기 순서(2단 문서, 텍스트박스 배치 등)
여기가 흔들리면 LLM은 아무리 좋아도 그럴듯한 답을 하면서도 정확한 근거/관계를 자주 놓칩니다. 실무에서 “요약은 잘하는데, 왜 믿기 어렵지?”가 나오는 지점이 바로 여기입니다.
3) Doc Understanding(LLM): 정리된 구조를 바탕으로 요약·질의응답하는 단계
GPT/Gemini 같은 모델은 여기서 일합니다.
중요한 건, LLM은 ‘정리된 문서’를 전달 받을 때 가장 안정적이라는 점입니다.
쉽게 비유하면
LLM = 말 잘하는 팀원
Parser = 자료를 ‘표준 양식’으로 정리해주는 팀원
정리 담당이 일을 못 하면, 발표 담당이 아무리 똑똑해도 실수합니다.
3) HWP라서가 아니라 ‘구조가 깨져서’입니다 (Gemini가 되는 이유도 여기)
기술적으로는 조건이 맞으면 HWP/HWPX를 읽는 것도 가능합니다.
실제로 Google Workspace 업데이트에서도 Gemini(제미나이)가 업로드 가능한 문서 형식에 HWP/HWPX를 포함한다고 안내합니다.
하지만 여기서 많은 팀이 착각합니다.
❓
그럼 업로드만 되면 끝 아닌가요?
아닙니다. 열리는 것(포맷 리더)과 업무에 쓸 만큼 구조화되는 것(파서)은 다릅니다.
텍스트는 나왔는데 표 구조가 풀려서 숫자 맥락이 뒤집히거나 캡션이 다른 표에 붙거나 읽기 순서가 섞여 문장이 뒤엉키면 AI는 “읽었다”고 하지만, 실무자는 “어디를?”이라고 되묻게 됩니다.
4) 공공기관 관점에서 더 중요한 이유: 보안·감사는 정답보다 ‘추적성’입니다
공공 문서는 단순히 빨리 요약하면 끝이 아니죠.
감사/민원 대응은 왜 그렇게 결론이 났는지가 남아야 하고 누가/언제/무엇을 수정했는지 어떤 근거 문장/표에서 나온 답인지 추적 가능해야 합니다.
그래서 공공기관에서 진짜 중요한 건 이겁니다.
감사 가능한 AI
= 문서 구조화 + 검수(사람 확인) + 로그(이력/근거)
LLM이 혼자 결론 내리는 방식은 공공에서 오래 못 갑니다. 결국 검수와 추적성을 설계해야 안전하게 운영됩니다.
5) 그래서 한국딥러닝은 무엇을 ‘다르게’ 하나요
한국딥러닝은 문서를 읽는 AI를 만들었다고 말하지 않습니다.
공공문서를 AI가 읽을 수 있게 구조를 복원하고, 근거·검수·이력까지 남기는 운영 기반을 제공합니다.
(1) 한국딥러닝 Parser의 기본값은 이미지 기반 구조 복원(VLM)입니다
많은 접근은 가능하면 텍스트 메타데이터로 추출하고, 안 되면 이미지(OCR)로 우회라고 생각합니다.
그런데 공공문서의 난이도는 텍스트가 아니라 레이아웃/표/배치에 있고,
이건 이미지 관점에서 구조를 잡는 게 강합니다.
그래서 한국딥러닝 Parser는 VLM 기반으로 ‘이미지 우선’ 구조 복원을 기본으로 가져갑니다.
표 안의 표, 병합셀, 텍스트박스 배치처럼
사람 눈에는 자연스럽지만 기계 규칙은 복잡한 요소에서
구조가 더 안정적으로 복원되도록 설계하는 방향입니다.
(2) 목표는 텍스트 추출이 아니라
LLM이 헷갈리지 않는 구조화 데이터입니다
Parser는 전처리입니다. LLM이 헛소리(환각/오독)를 줄이려면, 입력이 문서가 아니라 구조화된 데이터여야 합니다.
JSON/HTML/Markdown 같은 형태로
섹션/표/캡션 관계가 살아있고
(운영 환경에 맞춰) 근거 위치/메타데이터를 함께 남길 수 있게
즉, 문서를 AI가 학습/검색/자동화에 쓰는 데이터 자산으로 바꿉니다.
(3) DEEP Agent 는 운영의 현실을 해결합니다
PoC에서 가장 흔한 실패는 데모는 되는데 운영이 안 된다예요.
예외 케이스가 쌓일 때 누가 어떻게 검수할지
수정한 결과를 어떻게 반영할지
로그/이력을 어떻게 남길지
대량 문서를 어떻게 처리할지
DEEP Agent 는 문서 업로드 → 추출 → 검수(휴먼 인 더 루프) → 이력/로그를 통해
공공기관이 요구하는 운영 가능한 문서 AI로 연결하는 데 초점을 둡니다.
6) 공공기관에서 ‘안전하게’ 굴리는 문서 AI
흐름은 이렇게 잡으면 됩니다
여기까지 읽으셨다면 이런 질문이 자연스럽게 나올 거예요.
“그럼 우리 기관에서는 문서를 AI에 어떻게 붙여야 안전하게 쓸 수 있나요?”
답은 의외로 복잡하지 않습니다. 핵심은 AI(LLM)를 앞에 세우지 말고, 문서를 먼저 정리하는 흐름을 만드는 거예요.
실무에서 가장 현실적인 단계는 아래처럼 정리됩니다.
1) 반입 단계에서 먼저 막기 (보안·감사 기준)
파일이 손상됐는지, 암호가 걸렸는지, 반출 제한이 있는지 확인
어떤 문서가 AI 처리 대상인지(대외비/개인정보 포함 여부) 1차 분류
이 단계가 없으면, AI 성능보다 먼저 감사 리스크가 터집니다.
2) 문서를 그대로 넣지 말고, 먼저 읽을 수 있게 바꾸기
HWP/HWPX/PDF 같은 파일에서 내용을 꺼내고(Format Reader)
표/레이아웃/읽기 순서를 복원해 문서 구조를 살린 데이터로 바꿉니다(Parser)
여기서부터가 못 읽힘을 “읽힘”으로 바꾸는 핵심 구간이에요.
3) 결과는 텍스트 덩어리가 아니라 근거가 남는 형태로 남기기
JSON/HTML 같은 구조화 결과물로 저장하고
필요하다면 페이지/구역 단위로 어디에서 나온 정보인지를 추적할 수 있게 합니다.
공공에서 중요한 건 요약이 아니라 근거이기 때문이죠.
4) 생성형 AI는 마지막에 붙이기
구조화된 결과를 기반으로 필요한 부분만 요약·질의응답에 쓰고
답변에는 가능하면 근거(출처 위치)가 따라오게 설계합니다
AI가 틀린 답을 하는 이유는 대개 모델이 아니라 입력 문서 구조가 깨진 상태에서 시작합니다.
5) 운영은 검수와 로그로 완성하기
예외 케이스만 사람이 확인(휴먼 인 더 루프)
수정 이력/재처리 기록/권한 로그를 남겨 감사 가능한 운영으로 마무리
정리 : 공공문서가 AI에서 깨지는 이유는
모델보다 ‘Parser(문서 구조화)’입니다
HWP/HWPX 자체가 절대 불가능이라기보다 문서가 AI가 이해할 구조로 복원되지 않아서 문제가 됩니다.
Gemini처럼 HWP/HWPX 업로드를 지원하는 사례도 있지만, 업로드 가능과 업무 활용 가능은 다릅니다.
결국 공공 AX에서 중요한 건 Format Reader → Parser → LLM 3단계를 갖추고,
검수·로그로 감사 가능한 운영을 만드는 것입니다.
Share article