핵심 답변
HWPX가 XML을 쓰는 이유는 문서의 요소와 속성을 명시적인 구조로 표현하고, 특정 프로그램 밖에서도 기계가 읽고 재가공할 수 있도록 하기 위해서입니다. 하지만 실제 HWPX는 XML 한 장이 아니라 여러 XML과 이미지·리소스가 참조로 연결된 ZIP 패키지이므로, 텍스트 태그만 모으는 것과 문서를 구조적으로 해석하는 것은 다릅니다.
XML은 글자를 저장하는 형식보다 ‘관계’를 표현하는 방식에 가깝습니다
XML은 태그와 계층을 이용해 데이터의 구조를 표현합니다. 워드프로세서 문서에서는 단순히 “이 문장에 어떤 글자가 있다”는 정보뿐 아니라 이 글자가 어느 문단에 속하는지, 어떤 속성을 참조하는지, 표의 어느 셀 안에 있는지 같은 관계를 표현하는 데 사용할 수 있습니다.
예를 들어 제목과 본문이 모두 같은 문자열로만 저장된다면 둘을 구분하기 어렵습니다. XML에서는 서로 다른 요소나 속성을 통해 역할을 나눌 수 있기 때문에 프로그램이 문서 구조를 따라가며 읽기 좋은 출발점을 제공합니다.
HWPX는 XML 파일 하나가 아니라 ZIP 기반 문서 패키지입니다
한컴의 HWPX 포맷 설명에 따르면 HWPX는 ZIP 구조 안에 여러 XML 파일과 리소스를 배치하는 방식입니다. 대표적으로 문서 구역의 본문, 서식과 스타일, 버전·설정 정보, 컨테이너 정보, 이미지 같은 바이너리 데이터가 서로 다른 파일이나 디렉터리에 존재할 수 있습니다. 실제 구성은 문서 내용에 따라 달라질 수 있습니다.
| 구성 요소 | 쉽게 보면 | 데이터화에서 보는 이유 |
|---|---|---|
| 본문 구역 XML | 문단·런·텍스트와 문서 요소 | 실제 내용과 표·개체 구조를 찾기 위해 |
| 스타일·헤더 정보 | 글자·문단·테두리 등 재사용되는 속성 | 본문의 ID가 무엇을 의미하는지 연결하기 위해 |
| BinData 등 리소스 | 그림과 기타 바이너리 데이터 | 본문의 참조와 실제 파일을 연결하기 위해 |
| META-INF·컨테이너 정보 | 패키지 구성과 파일 관계 | 패키지를 올바르게 해석하기 위해 |
| 미리보기·설정 | 미리보기와 편집 환경 정보 | 본문 데이터와 보조 정보를 구분하기 위해 |
ID와 참조 관계를 놓치면 XML을 읽고도 문서를 잘못 이해할 수 있습니다
문서 포맷은 같은 스타일이나 리소스를 매번 복제하기보다 한곳에 정의하고 ID로 참조하는 방식을 많이 사용합니다. HWPX도 본문 요소가 다른 XML이나 리소스의 정보를 참조할 수 있습니다. 따라서 본문 XML에서 숫자 ID만 읽고 참조 대상은 확인하지 않으면 실제 글자 모양, 테두리, 이미지 또는 다른 속성을 잃을 수 있습니다.
이 구조는 자동화에서 특히 중요합니다. 문서 두 개의 XML 조각을 단순히 합쳤는데 서로 같은 ID를 다른 의미로 쓰고 있다면, 눈으로 보기에는 비슷한 태그라도 참조가 충돌할 수 있습니다. 문서 조각을 합치는 일은 문자열을 붙이는 일이 아니라 참조 공간을 다시 정합시키는 일에 가깝습니다.
표는 XML이어도 단순한 CSV가 아닙니다
표는 HWPX가 XML이라는 이유만으로 자동으로 2차원 데이터가 되는 것이 아닙니다. 셀 하나 안에 여러 문단이 있을 수 있고, 셀 병합과 크기, 행·열 위치, 문단 속성, 중첩된 개체가 함께 존재할 수 있습니다. 특히 여러 칸을 묶는 병합셀이나 2단 이상의 헤더가 있다면 화면에서 보이는 의미를 복원하기 위해 셀 관계를 함께 읽어야 합니다.
그래서 표를 데이터베이스로 옮길 때는 “셀 안의 문자열”과 “셀의 위치·병합·헤더 역할”을 분리해서 생각하는 편이 좋습니다. 전자는 값이고 후자는 값의 의미를 결정하는 구조입니다.
HWPX를 ‘텍스트 파일’처럼 보면 무엇을 놓칠까?
| 단순 접근 | 얻을 수 있는 것 | 잃을 수 있는 것 |
|---|---|---|
| 모든 텍스트 태그 이어 붙이기 | 검색 가능한 문자열 | 문단 경계, 표 셀 관계, 읽기 순서 |
| 본문 XML만 읽기 | 주요 본문 요소 | 스타일 정의, 외부 리소스, 패키지 관계 |
| 이미지만 별도 추출 | 리소스 파일 | 어느 문단·개체와 연결되는지 |
| XML 일부를 직접 교체 | 국소적인 내용 변경 | ID·참조·스키마 일관성이 깨질 가능성 |
개방형 포맷 ≠ 평면적인 포맷 — XML이라서 구조를 읽고 가공하기 쉬운 것은 맞지만, 문서 자체는 여전히 많은 요소와 참조가 연결된 복합 구조입니다.
직접 수정할 때는 스키마보다 참조 무결성까지 봐야 합니다
XML 문법이 올바르다는 사실만으로 HWPX 문서가 정상이라는 뜻은 아닙니다. 태그가 잘 닫혀 있어도 참조하는 ID가 존재하지 않거나, 패키지에 필요한 리소스가 빠졌거나, 문서 구조상 허용되지 않는 위치에 요소가 들어가면 프로그램이 문서를 다르게 표시하거나 열지 못할 수 있습니다.
자동 생성·병합 작업에서는 최소한 XML 문법 → 스키마/구조 → ID·참조 → 패키지 리소스 → 실제 렌더링 순으로 검증하는 것이 좋습니다. 파일이 생성되었다는 것보다 최종 문서가 원래 의도대로 열리고 구조가 유지되는지가 중요합니다.
XML 구조와 페이지에서 보이는 위치는 같은 정보가 아닙니다
XML은 문서의 논리적 구성과 속성을 잘 표현하지만, 사용자가 보는 최종 페이지는 용지 크기, 여백, 글꼴, 줄바꿈, 표 크기, 개체 배치 같은 여러 조건이 반영된 렌더링 결과입니다. 그래서 “이 문단이 XML에서 세 번째다”와 “이 문단이 2페이지 중간에 보인다”는 서로 다른 종류의 정보입니다.
문서 검색이나 의미 분석에는 원본 구조가 중요하고, 사람이 다시 검토할 위치를 안내하거나 원본과 변환본을 비교할 때는 페이지·좌표 같은 렌더링 정보도 중요합니다. 한쪽만으로 모든 목적을 해결하려고 하면 손실이 생기기 쉽습니다.
실제 HWPX 자동화에서는 결과 목적부터 정합니다
- 검색용 텍스트가 목적이면 문단 경계와 읽기 순서를 우선 확인합니다.
- 표 데이터가 목적이면 행·열·병합·헤더와 셀 내부 문단까지 함께 봅니다.
- 문서 재생성이 목적이면 스타일·리소스·참조 무결성과 렌더링을 확인합니다.
- 원문 검토 연결이 목적이면 구조 요소가 실제 페이지와 어디에서 대응되는지도 확인해야 합니다.
목적이 다른데 동일한 “HWPX 파싱 성공” 지표 하나만 사용하면 필요한 정보가 실제로 보존됐는지 판단하기 어렵습니다.
DOGURANG은 XML을 최종 데이터가 아니라 원본 구조의 한 층으로 봅니다
DOGURANG에서는 HWPX의 XML을 그대로 최종 분석 결과로 취급하기보다, 문단·표·개체·참조를 원본 구조로 읽은 뒤 다른 문서 포맷과 함께 사용할 수 있는 공통 구조로 연결하는 것이 중요합니다. XML은 강력한 원본 신호이지만, 필요에 따라 렌더링 위치와 검증 정보도 함께 유지해야 합니다.
HWP와 HWPX 전체 비교는 HWP와 HWPX는 무엇이 다른가에서, 표 관계가 왜 중요한지는 표가 많은 문서는 왜 텍스트 추출만으로 부족한가에서 이어서 볼 수 있습니다.
공식 참고자료
- 한컴테크 — HWPX 포맷 구조 살펴보기
- 한컴 — HWP/OWPML 형식 공개 자료
- 한컴 도움말 — HWPX와 OWPML 안내
- 한컴 Developer — HWPX/OWPML 관련 오픈소스
HWPX 내부 구성은 문서 내용과 저장 옵션에 따라 달라질 수 있습니다. 특정 XML이나 디렉터리가 모든 문서에 동일하게 존재한다고 가정하기보다 공식 규격과 실제 패키지를 함께 확인해야 합니다.