[스나이퍼팩토리] 한컴AI 2기 - OWPML 프로젝트 CLI와 백엔드 FastAPI 세팅

처음 목표는 명확했다. 한글(HWP, HWPX) 문서를 AI가 이해하게 만들자.
그런데 막상 열어보니 구조가 너무 복잡했다.
텍스트는 있지만 의미 단위로 구분되지 않았고, 문단과 표, 각주가 한데 엉켜 있었다.

OWPML(Open Word Processor Markup Language) 필터를 활용해
한글 문서를 XML 구조로 풀 수 있다면, AI가 이해할 수 있는 데이터로 바꿀 수 있을 것 같았다.
그 순간 “이걸 파싱해서 RAG 구조에 얹으면 되겠다”는 감이 왔다.


2️⃣ extract.py — 문서를 뜯어내는 과정

HWPX 파일은 내부적으로 ZIP 형식이었다.
압축을 풀면 XML 파일들이 나오고, 그 안에 <hp:p>는 문단, <hp:tbl>은 표를 의미했다.
파이썬의 xml.etree.ElementTree로 태그를 읽고, 문단과 표를 각각 리스트로 정리했다.
이미지는 BinData 폴더에서 추출했다.

이 과정을 자동화하기 위해 extract.py를 만들었다.
파일을 넣으면 자동으로 텍스트, 표, 이미지, 구조 정보를 모두 뽑아 JSON으로 저장하도록 했다.
결과를 처음 봤을 때는 꽤 감동적이었다.

예시 데이터로 충주의료원 규정집을 파싱했는데, 문단이 1만 5천 개, 표가 400개가 넘었다.
그 방대한 데이터가 전부 구조화된 순간, “이제 이걸 AI가 읽을 수 있겠구나”라는 확신이 들었다.


3️⃣ RAG 구상 — 문서 이해의 뼈대를 세우다

문서 구조를 추출했으니, 이제는 ‘이해’를 시켜야 했다.
핵심은 RAG(Retrieval-Augmented Generation)였다.
문단 단위로 청킹하고, 임베딩 후 벡터 검색을 수행해 GPT가 근거를 포함한 답변을 생성하도록 하는 구조다.

문제는 표였다.
“이건 표입니다”라는 텍스트 형태로 들어가는데, 표 데이터와 결합해 전달할 방식이 필요하다.
문서의 형태적 구조가 답변의 품질을 결정한다는 걸 실감했다.

4️⃣ FastAPI

AI 모델을 실제 서비스처럼 다루려면 API가 필요했다.
그래서 FastAPI를 선택했다

추출함수를 모듈화하여 FastAPI에서 구동하여 API 라우트를 제공할 수 있기를 기대했다. jpype임포트에 문제가 있어서 난항을 겪었다. hwpx에는 jar파일이 필요하지 않아서, 그쪽에는 로컬에서도 문제가 없었다.

동일한 환경을 만들기 위해 도커 빌드가 필요했다.
 
docker build -t owpml-fastapi-backend
의 형태로 명령어를 실행할 수 있었다.