HWP 파일 파싱 후 재가공, 어디까지 자동화할 수 있을까(로컬 처리와 웹 한글 편집 비교)

한글 문서 업무를 자동화하려고 마음먹는 순간, 누구나 한 번쯤 이런 생각을 합니다.
“어차피 최종 결과만 HWP로 나오면 되는 거 아닌가? 중간은 좀 더 다루기 쉬운 방식으로 처리하면 훨씬 편한 거 아닌가?”

이번에는 바로 그 질문을 중심에 놓고, HWP 파일을 파싱한 뒤 필요한 정보를 뽑아 재가공하고, 다시 문서 형태로 만들어 내는 흐름을 실제로 여러 방식으로 테스트해 봤습니다. 결론부터 말하면, “가능은 하다. 하지만 어디서 처리하느냐에 따라 난이도와 안정성이 생각보다 크게 달라진다”입니다. 보기에는 비슷한 자동화 같아도, 실제로는 길이 꽤 다른 두 개의 등산로를 걷는 기분이었습니다.

 

우선 시작전에 로컬 파일 처리와 웹 한글에서 처리한 내용을 비교한 도표부터 첨부하겠습니다.

hwp 편집 자동화 로컬vs웹 한글(한컴독스)

이번 테스트의 핵심 목표

이번 검토의 초점은 특정 양식 문서를 그대로 따라 만드는 것보다, HWP 파일 안의 내용을 읽고 구조화한 뒤 다시 재가공 가능한 데이터로 바꾸는 흐름이 얼마나 실용적인지 확인하는 데 있었습니다.

 

테스트는 크게 다음 흐름으로 진행했습니다.

1. HWP 파일에서 본문 정보를 읽는다.
2. 필요한 항목을 구조화된 데이터로 정리한다.
3. 그 데이터를 바탕으로 새로운 문서 내용을 생성한다.
4. 최종적으로 다시 HWP 문서 형태로 결과를 만든다.
5. 이 과정을 로컬 환경과 웹 편집 환경 각각에서 비교한다.

겉으로만 보면 간단해 보이지만, 실제로 해보면 “읽기 쉬운 것”과 “안정적으로 수정 가능한 것”은 전혀 다른 문제라는 점이 금방 드러납니다.

HWP 파싱 자체는 생각보다 가능하다

먼저 HWP 파일에서 텍스트를 읽어오는 작업은 충분히 가능합니다.
문서 안에서 제목, 기간, 세부 일정, 활동 설명 같은 주요 텍스트를 뽑아 JSON 같은 구조화 데이터로 바꾸는 단계까지는 비교적 잘 진행됐습니다.

 

이 단계에서 중요한 포인트는 다음과 같았습니다.

• 문서 내용을 그대로 긴 문자열로 다루지 말고 항목별로 구조화할 것
• 날짜, 주제, 활동, 안내사항처럼 후속 생성에 필요한 단위를 분리할 것
• 원문에 없는 사실을 억지로 보완하지 말 것
• 최종 생성 전에 검수 가능한 중간 산출물을 남길 것

이렇게 해 두면 문서를 다시 만들 때도 훨씬 유연해집니다. 결국 자동화의 핵심은 “문서를 읽는 것”이 아니라 “문서를 데이터로 바꾸는 것”에 있었습니다.

로컬 처리: 가장 현실적이고 안정적인 방법

로컬 환경에서 HWP를 읽고, 필요한 내용을 재가공한 뒤, 다시 결과 문서를 만드는 흐름은 전체적으로 가장 안정적이었습니다.

이 방식의 장점은 꽤 분명합니다.

• 파일 접근이 단순하다
• 파싱 결과를 바로 저장하고 검수할 수 있다
• 생성 규칙을 코드로 고정하기 쉽다
• 동일 입력에 대해 동일 결과를 다시 만들 가능성이 높다
• 브라우저 UI 상태나 로그인 세션에 영향을 받지 않는다

특히 중간 산출물을 남기기 좋다는 점이 컸습니다. 예를 들어 다음처럼 단계를 분리할 수 있습니다.

{
  "title": "주간 계획",
  "period": "3월 1주",
  "sections": {
    "theme": "주제",
    "daily_items": [],
    "notes": []
  }
}

이런 구조를 만들어 두면, 이후 문장 생성 로직이나 템플릿 주입 로직을 따로 다듬을 수 있습니다.
한마디로 로컬 방식은 “문서 자동화”라기보다 “데이터 처리 파이프라인”에 가깝게 설계할 수 있었습니다. 이 점이 꽤 든든했습니다. 문서가 삐끗해도 데이터는 남으니까요.

웹 처리: 읽기는 편하지만 쓰기는 까다롭다

반면 웹 편집 환경은 조금 다른 성격을 보였습니다.
장점부터 말하면, 문서를 열었을 때 내부적으로 반환되는 구조화 응답은 HWP 바이너리보다 훨씬 읽기 쉬웠습니다. 즉, 입력 파싱 관점에서는 웹이 의외로 편했습니다.

 

하지만 문제는 그다음입니다.
문서를 웹에서 직접 편집해 결과를 만드는 순간 난이도가 확 올라갑니다.

 

대표적으로 이런 이슈들이 있었습니다.

• 로그인 세션과 문서 세션이 모두 필요함
• 문서를 열 수 있는 URL이 있어도 바로 편집 가능한 것은 아님
• UI 상태에 따라 같은 동작이 다르게 반응함
• 긴 문장 치환이 불안정함
• 표 안 줄바꿈 포함 텍스트는 치환 성공률이 낮음
• 같은 문자열이 여러 번 있을 때 과치환 위험이 생김
• 저장은 자동으로 되지만 실제 반영 확인까지 추가 검증이 필요함

즉, 웹은 “사람이 눈으로 보기엔 편한데, 기계가 안정적으로 수정하기엔 까다로운 환경”이었습니다.
문서를 읽는 것은 꽤 잘 되는데, 쓰는 순간부터는 작은 함정이 여기저기 숨어 있었습니다. 마치 잘 닦인 전시장 바닥처럼 보여도, 실제로 카트를 밀고 가면 턱이 많은 구조에 가까웠습니다.

결국 어느 쪽이 더 나았나

이번 테스트 기준으로 최종 판단은 꽤 명확했습니다.

비교 항목	로컬 처리	웹 처리
안정성	높음	낮음
속도	빠름	느림
토큰 사용량	적음	많음
입력 파싱 편의성	보통	좋음
최종 편집 안정성	좋음	불안정
재현성	높음	상대적으로 낮음

정리하면 이렇습니다.

로컬이 더 좋은 이유

• 자동화 로직을 코드 중심으로 고정할 수 있음
• UI 상태에 영향을 덜 받음
• 반복 실행 시 결과 예측이 쉬움
• 검수와 디버깅이 수월함

웹이 유용한 지점

• 문서를 시각적으로 확인하기 좋음
• 일부 경우 입력 문서의 구조를 읽기 쉬움
• 결과 공유와 최종 확인에는 편리함

그래서 추천하는 방식은 하이브리드다

가장 추천할 만한 방식은 웹만 쓰거나 로컬만 고집하는 것이 아니라, 각자의 장점을 나눠 쓰는 구조였습니다.

추천 흐름

1. 입력 문서는 로컬 파일 또는 웹 링크로 받는다.
2. 파싱과 구조화는 가능하면 안정적인 로컬 파이프라인으로 처리한다.
3. 생성과 검수도 로컬에서 끝낸다.
4. 최종 결과 확인이나 공유가 필요하면 웹에서 열어 본다.

이 흐름이 좋은 이유는 단순합니다.
복잡한 연산과 생성은 안정적인 곳에서 하고, 사람이 확인하기 좋은 작업만 웹으로 넘기면 되기 때문입니다. 문서 자동화를 하다 보면 멋진 구조보다 덜 깨지는 구조가 오래 갑니다. 그리고 대체로 후자가 승리합니다.

마무리: HWP 자동화의 핵심은 문서가 아니라 구조다

이번 테스트를 하면서 가장 크게 느낀 점은, HWP 자동화의 본질은 “한글 파일을 직접 만지는 기술”보다 “문서 내용을 구조화해서 다시 쓰는 기술”에 더 가깝다는 것이었습니다.

 

HWP를 읽고, 필요한 정보를 정리하고, 생성 규칙을 만들고, 검수 포인트를 두고, 마지막에 다시 문서화하는 흐름이 잡히면 자동화 품질은 확실히 올라갑니다. 반대로 그 구조 없이 무작정 문서 안의 문자열만 바꾸기 시작하면, 결과는 금방 미끄러집니다.

 

정리하면 이번 판단은 이렇습니다.

• 입력 파싱은 충분히 자동화 가능하다.
• 재가공도 잘 된다.
• 최종 결과를 HWP로 만드는 것도 가능하다.
• 다만 전체 과정을 웹 편집기에만 맡기는 것은 아직 불안정하다.
• 현재 가장 실용적인 방식은 로컬 중심, 웹 보조 방식이다.

한마디로 요약하면 이렇습니다.
HWP 자동화는 된다. 다만 문서를 직접 붙잡고 씨름하기보다, 먼저 문서를 데이터로 바꾸는 쪽이 훨씬 덜 고생스럽다. 괜히 문서와 힘겨루기하다가 오후가 사라지는 일은 줄일 수 있다는 뜻입니다.

출처

• 본문 내용은 실제 HWP 파싱, 구조화 JSON 생성, 로컬 HWP 출력, Hancom Web 문서 열기 및 편집 테스트를 바탕으로 정리함
• 한컴 웹 편집기 동작 확인, 내부 JSON 응답 확인, 로컬 생성 파이프라인 검수 결과를 종합하여 작성함