회사 자료를 AI에 넣어 쓰려고 할 때 한국에서만 유독 먼저 막히는 지점이 있습니다. 한글 파일입니다.
결론부터 말씀드립니다. 가장 널리 쓰이는 범용 변환기인 MarkItDown은 HWPX를 아예 지원하지 않습니다. 변환이 서툰 게 아니라 처리 경로 자체가 없어서 실패합니다. 대신 python-hwpx, hwpxkit 같은 한글 전용 도구가 있고, 합성 샘플 5개에서는 본문과 표를 정상적으로 회수했습니다.
그런데 실제로 돌려보고 더 중요하게 느낀 건 따로 있었습니다. “변환에 성공했다”와 “내용이 다 넘어왔다”는 전혀 다른 말이라는 점입니다. 같은 HWPX 파일을 두 전용 도구에 넣었더니 회수된 글자 수가 최대 2.6배까지 차이 났습니다. 둘 다 “성공”이라고 표시된 상태에서요.
기준일과 한계: 2026년 8월 12~13일 실행 기록입니다. 사용한 샘플은 전부 합성 자료이며 실제 기업 문서가 아닙니다. 문단과 표 중심 문서에서 확인한 결과이고, 각주·메모·이미지 개체·중첩표·암호화 문서는 아직 검증하지 않았습니다. 도구 버전이 올라가면 결과는 달라질 수 있습니다.
목차
왜 한글 파일이 유독 문제가 되나
사내 AI 도입 이야기를 할 때 해외 자료를 그대로 가져오면 잘 맞지 않는 대목이 여기입니다. 해외 문서 변환 도구들은 DOCX·PPTX·XLSX·PDF를 기본으로 다룹니다. 한국 공공기관과 기업 문서의 상당 부분을 차지하는 한글 문서는 우선순위에서 밀려 있습니다.
게다가 한글 파일은 두 종류로 나뉩니다.
| 확장자 | 구조 | 기계 처리 |
|---|---|---|
.hwp |
한/글 고유 바이너리 형식 | 어렵습니다. 전용 파서가 필요합니다 |
.hwpx |
OOXML 계열 개방형 포맷(ZIP + XML) | 상대적으로 접근하기 쉽습니다 |
그래서 실무에서 가장 먼저 할 일은 도구를 고르는 게 아니라 .hwp를 .hwpx로 저장하는 것입니다. 한/글에서 다른 이름으로 저장할 때 형식만 바꾸면 됩니다. 이 글의 실측도 전부 .hwpx 기준입니다.
무엇을 어떻게 측정했나
직접 확인하지 않고는 판단할 수 없어서 아래 조건으로 돌렸습니다.
| 항목 | 내용 |
|---|---|
| 실행일 | 2026-08-12 (H1), 2026-08-13 (H2~H5 확장) |
| 샘플 | 합성 HWPX 5개 (H1~H5), 8.7KB~9.9KB |
| 샘플 성격 | 운영 서식, 긴 본문+표, 다중 섹션+표 2개, 권한 검토 서식, 대형 표 |
| 비교 도구 | MarkItDown 0.1.7 / python-hwpx 6.0.3 / hwpxkit 0.2.1 |
| 측정 항목 | 변환 성공 여부, 회수 문단 수, 회수 글자 수, 처리시간(ms), 구조 진단 오류 수 |
평가 원칙은 하나였습니다. 변환 성공과 의미 검증을 같은 것으로 보지 않는다. 파일이 열렸다는 사실과 내용이 제대로 넘어왔다는 사실은 따로 확인해야 합니다.
결과 1: 범용 변환기는 HWPX에서 멈춘다
| 도구 | 실행 결과 | 회수 결과 |
|---|---|---|
| MarkItDown 0.1.7 | 실패 · 미지원 | 변환하지 못함 |
| python-hwpx 6.0.3 | 통과 | H1 본문·표, H2~H5 추가 샘플 회수 |
| hwpxkit 0.2.1 | 통과 | 본문·HTML 표·JSON·구조 진단 제공 |
MarkItDown은 DOCX·PPTX·XLSX에서는 문제없이 동작했습니다. HWPX에서만 지원 목록에 없어서 멈췄습니다.
실무적으로 중요한 함의가 있습니다. “우리 회사는 문서 변환 도구 하나로 통일한다”는 접근이 한국에서는 성립하지 않습니다. 한글 문서는 별도 경로를 따로 만들어야 한다고 처음부터 설계에 넣어야 합니다. 나중에 붙이면 권한·로그·검수 절차를 두 번 만들게 됩니다.
결과 2: 전용 도구 2종은 통과했지만, 회수량이 달랐다
여기가 이 실험에서 가장 예상 밖이었던 부분입니다.
| 샘플 | 성격 | python-hwpx 문단 | python-hwpx 글자 | python-hwpx 처리시간 | hwpxkit 글자 | 진단 오류 |
|---|---|---|---|---|---|---|
| H2 | 긴 본문 + 표 | 17 | 1,111 | 10.07ms | 1,729 | 0 |
| H3 | 다중 섹션 + 표 2개 | 12 | 479 | 6.28ms | 1,077 | 0 |
| H4 | 권한 검토 운영서식 | 7 | 291 | 6.14ms | 586 | 0 |
| H5 | 대형 표 회수 시험 | 5 | 734 | 11.42ms | 1,921 | 0 |
두 도구 모두 “성공”이고 진단 오류는 0건입니다. 그런데 같은 파일에서 회수한 글자 수는 이만큼 벌어집니다.
표 비중이 큰 H5에서 차이가 가장 컸습니다.
다만 이 숫자를 “hwpxkit이 2.6배 더 정확하다”로 읽으면 안 됩니다. 두 도구가 글자 수를 세는 기준 자체가 다를 수 있습니다. 표 셀 텍스트, 머리글, 구조 태그를 어디까지 집계에 넣는지가 다르면 이런 차이가 납니다. 저는 이 실험에서 그 내부 기준까지는 확인하지 않았습니다.
그래서 여기서 가져갈 결론은 이겁니다.
한 도구만 돌려보고 “변환 잘 되네”라고 판단하면 안 됩니다. 같은 파일을 최소 두 도구에 넣고 결과 길이를 비교해야 무엇이 빠졌는지 보입니다.
처리시간은 모두 6~12ms 수준이라 성능은 이 규모에서 고려 대상이 아니었습니다. 두 도구를 다 돌려도 부담이 없다는 뜻이기도 합니다.
두 도구의 성격 차이도 기록해 둡니다.
- python-hwpx: 결과가 Markdown 표로 바로 나와서 사람이 읽고 쓰기 편했습니다.
- hwpxkit: Markdown·HTML·JSON과 구조 진단을 함께 줘서, 자동 파이프라인에 넣고 검수하기에 유리해 보였습니다.
용도가 다르므로 둘 중 하나를 고르기보다 사람이 볼 결과물과 시스템이 쓸 결과물을 나눠서 생각하는 편이 맞다고 봅니다.
결과 3: 한글만의 문제가 아니었다 — 엑셀은 수식이 사라진다
같은 실험에서 엑셀도 확인했는데, 여기서 더 조심해야 할 게 나왔습니다.
합성 XLSX 2개를 변환한 뒤 원본 파일의 XML을 직접 열어 대조했습니다.
| 파일 | 시트 | 원본에 있던 수식 | 변환 결과 |
|---|---|---|---|
| X1 | Summary, Review_Log | 1개 (B3/B2) |
계산된 숫자만 보임 |
| X2 | Summary, Review_Log, Controls, Calc | 8개 (C2-B2, SUM(B2:B5) 등) |
계산된 숫자만 보임 |
변환된 Markdown에는 계산 결과 숫자는 그대로 나옵니다. 표가 예쁘게 만들어지니 잘 된 것처럼 보입니다. 그런데 그 숫자가 어떤 식으로 나온 값인지는 사라집니다.
이게 왜 위험하냐면, AI에게 “이 지표가 왜 이렇게 나왔는지 설명해줘”라고 물었을 때 AI는 수식을 못 본 상태에서 그럴듯한 설명을 만들어냅니다. 숫자는 맞는데 근거는 지어낸 답이 나옵니다. 검토하는 사람 입장에서 가장 걸러내기 어려운 종류의 오류입니다.
엑셀 파일을 AI 파이프라인에 넣는다면 원본 XLSX와 변환 결과를 함께 보관하고, 수식·숨김 시트·외부 링크는 원본에서 따로 확인해야 합니다.
엑셀을 AI에 직접 연결하는 경우의 점검 항목은 Claude for Excel, 회사 엑셀에 연결하기 전 확인할 것에 정리해 두었습니다.
결과 4: PPT는 텍스트가 나와도 그림의 의미는 안 나온다
발표자료도 같은 함정이 있었습니다.
| 샘플 | 구성 | 변환 | 남는 문제 |
|---|---|---|---|
| P1 | 슬라이드 3장, 텍스트 중심 | 통과 | 발표자 노트가 비어 있음 |
| P2 | 슬라이드 4장, 디자인 중심 | 통과 | 배치가 전달하던 의미는 회수 안 됨 |
| P3 | 슬라이드 3장, 이미지 1개 포함 | 통과 | 차트 값은 회수, 이미지 의미는 시각 검수 필요 |
슬라이드 순서와 텍스트는 잘 넘어옵니다. 하지만 화살표로 그린 흐름도, 박스의 위치 관계, 이미지 안에 든 도식은 텍스트로 바뀌지 않습니다.
실무에서 PPT는 그림이 결론을 말하는 경우가 많습니다. 텍스트만 추출해서 AI에 넣으면 정작 핵심이 빠진 자료를 근거로 답이 나옵니다.
그래서 실무에서 무엇을 해야 하나
이 실험에서 쓴 판단 기준을 그대로 공유합니다. 도구를 먼저 채택하지 않고, 같은 샘플을 여러 도구에 통과시킨 뒤 6가지를 비교했습니다.
| 축 | 질문 |
|---|---|
| 충실도 | 내용·표·수식·슬라이드 의미가 얼마나 보존되는가 |
| 구조 | 표와 수식, 시각 요소의 구조가 살아 있는가 |
| 추적성 | 변환본에서 원본과 근거를 다시 찾을 수 있는가 |
| 근거·최신성 | 이 자료가 언제 기준인지 확인할 수 있는가 |
| 운영성 | 구성원이 배워서 반복해 쓸 수 있는가 |
| 복구성 | 실패하면 원본을 그대로 되돌릴 수 있는가 |
Work N Rich 워크시트 — 내 회사 문서로 30분 안에 확인하기
그대로 따라 하실 수 있게 순서로 정리했습니다.
- 대표 문서 5개를 고릅니다. 가장 흔한 형식으로, 되도록 표가 들어간 것으로. 기밀이 아닌 것부터.
.hwp는.hwpx로 저장합니다. 이 단계를 건너뛰면 대부분 여기서 막힙니다.- 같은 파일을 두 도구에 넣습니다. 결과 길이를 비교합니다. 차이가 크면 표나 각주가 빠졌을 가능성이 높습니다.
- 원본을 옆에 띄우고 표를 한 줄씩 대조합니다. 특히 병합된 셀과 표 안의 표.
- 엑셀은 수식이 살아 있는지 확인합니다. 숫자만 맞는 건 통과가 아닙니다.
- PPT는 그림이 말하던 결론이 텍스트에 남았는지 봅니다. 없으면 사람이 한 줄로 요약해서 따로 붙입니다.
- 통과한 형식과 실패한 형식을 표로 기록합니다. 실패 기록이 나중에 더 쓸모 있습니다.
이 7단계를 거치면 “AI가 우리 문서를 읽을 수 있느냐”는 질문이 “어떤 형식은 되고, 어떤 형식은 사람이 먼저 손봐야 한다”는 구체적인 목록으로 바뀝니다. 사내 AI 도입에서 실제로 필요한 건 그 목록입니다.
아직 확인하지 못한 것
정직하게 남겨 둡니다. 이 실험은 여기까지만 말할 수 있습니다.
- 합성 샘플 기준입니다. 실제 기업 문서의 정확도를 보증하지 않습니다.
- 문단과 표 중심 문서만 봤습니다. 각주, 메모, 실제 이미지 개체, 중첩표(표 안의 표), 암호화된 파일은 별도 샘플이 필요합니다.
- 두 도구의 글자 수 집계 기준을 내부까지 확인하지 않았습니다. 차이가 났다는 사실까지가 이번 결과입니다.
.hwp바이너리는 다루지 않았습니다. 전부.hwpx기준입니다.- 도구 버전이 바뀌면 결과도 바뀝니다. 2026년 8월 기준 버전으로 적어 두었습니다.
다음 단계로는 각주·메모·이미지 개체·중첩표를 포함한 샘플에서 항목별 회수율과 처리시간을 재고, 그 결과로 채택 여부를 정할 계획입니다.
정리
- MarkItDown 같은 범용 변환기는 HWPX를 지원하지 않습니다. 한글 문서는 처음부터 별도 경로로 설계하세요.
.hwp는.hwpx로 저장하는 것이 첫 단계입니다.- 한 도구만 믿지 마세요. 같은 파일에서 두 전용 도구의 회수량이 최대 2.6배 차이 났고, 둘 다 “성공”이었습니다.
- 엑셀은 숫자가 맞아도 수식이 사라집니다. 원본을 함께 보관하고 따로 검수하세요.
- PPT는 그림이 말하던 결론이 빠집니다. 사람이 한 줄로 보충해야 합니다.
“AI가 회사 문서를 읽는다”는 말은 생각보다 좁은 범위의 약속입니다. 그 범위를 직접 측정해서 목록으로 갖고 있는 조직과, 막연히 될 거라고 가정한 조직의 차이는 도입 3개월 뒤에 드러납니다.
함께 보면 좋은 글
- AI는 평균을 알고, 나는 이번을 안다 — 이 블로그가 AI를 다루는 기준
- AI에 회사 문서를 넣어도 될까? 개인정보 점검표 — 형식 문제를 풀었다면 다음은 권한 문제입니다
- Claude for Excel, 회사 엑셀에 연결하기 전 확인할 것 — 엑셀 수식 검수 기준
- AI 산출물 보안 검토를 3단계로 끝내는 법 — 변환한 자료를 내보내기 전 점검
- NotebookLM은 좋은 출처를 넣을수록 강해진다 — 변환 품질이 답변 품질을 정하는 이유