HWPX lineseg 필드의 기묘한 진실 — 한컴 자신이 비표준을 생산하고 있다

[edwardkim]

앞선 두 글(#183, #184)에서 HWPX 포맷의 설계 잔재와 LLM 기반 비표준 HWPX 생성의 위험을 짚었습니다. 이번엔 한 단계 더 들어갑니다. 한컴 자신이 그 비표준 HWPX의 주된 생산자 중 하나라는 현장 관찰입니다.

관찰된 현상

rhwp 개발 중 재현한 기묘한 시나리오입니다.

한컴이 만든 HWPX (원본)
    ↓ rhwp 로 열기
    ↓ 아무것도 편집하지 않음
    ↓ rhwp 로 저장 (HWPX)
저장된 HWPX 파일
    ├─▶ 한컴으로 열기: ✅ 줄 넘김 정상 렌더링
    └─▶ rhwp 로 다시 열기: ❌ 한 줄에 텍스트가 겹쳐 조판

같은 파일을 원작자인 한컴은 정상 렌더하고 후발주자 rhwp는 깨진 렌더를 보여줍니다. 상식적으로는 반대여야 합니다 — 표준을 만든 쪽이 더 엄격하고, 후발주자가 맞춰야 하는 구조.

원인 분석

HWPX의 <hp:lineseg> 요소는 문단의 각 줄 좌표(vertpos, vertsize, textheight 등)를 담습니다. 명세상 이 값은 사전 계산된 정확한 값이어야 합니다.

그런데:

1. 한컴 어떤 버전이 부정확한 lineseg 값을 생산하고 있습니다
2. 한컴 프로그램은 자기가 만든 과거 파일도 열리게 하려고 방어 로직(reflow)을 내장했습니다 — 파일 열 때마다 lineseg 를 무시하고 textRun 기반으로 재계산
3. 후발주자(rhwp)는 명세를 신뢰하고 <hp:lineseg> 값을 그대로 렌더 → 부정확한 값이 그대로 반영 → 겹침

즉 한컴 자신만이 자기 파일을 정상 렌더할 수 있는 상태입니다.

이게 왜 심각한 문제인가

생태계 전체가 기술부채를 나눠 지게 됨

한컴 내부에는 기술부채가 있지만, 그 존재가 외부에 드러나지 않으면 후발주자는 자기 구현이 틀렸다고 오해합니다. rhwp도 처음엔 "우리가 렌더링을 잘못했나?"를 먼저 의심했습니다. 명세는 맞고, 코드는 명세대로 구현했는데도 결과가 "틀린" 것으로 보이기 때문입니다.

비표준이 표준처럼 자리잡는 메커니즘

• 한컴 방어 로직이 조용히 모든 걸 보정합니다
• 사용자는 "한컴에서 열리니까 정상 파일"이라고 생각합니다
• 그 파일이 유통되어 생태계 전체로 퍼집니다
• 후발주자가 처음 마주할 때는 "이미 비표준이 표준처럼 된" 상태입니다

Discussion #184와의 직접 연결

앞 글에서 지적한 "LLM이 생성한 비표준 HWPX가 한컴에서 열린다는 경험이 누적되면 깨진 구조가 표준으로 자리잡는다" 는 우려. 한컴 자신이 같은 일을 하고 있었습니다. 방식은 같습니다:

• LLM: "구조가 좀 틀려도 한컴이 받아준다" → 비표준 생산
• 한컴 일부 버전: "lineseg 가 좀 틀려도 한컴이 보정한다" → 비표준 생산

둘 다 생태계를 서서히 오염시킵니다.

왜 한컴이 이 사실을 공개하지 않는가 — 추정

한컴이 이를 공식화하지 않는 이유는 여러 가능성이 있습니다:

1. 개발 조직 내부에서만 알고 있을 가능성 — 개발자가 방어 로직으로 덮은 기술부채를 임원진은 모를 수 있습니다
2. "상관없는 문제"로 인식할 가능성 — 사용자가 한컴으로 열기만 하면 정상이니 외부 문제로 보이지 않을 수 있습니다
3. 공개 시 파생되는 책임 — "우리 파일이 표준 위반"임을 공식 인정하면 공공기관·법정 문서 등의 검증 체계와 충돌 가능

어느 쪽이든 결과는 같습니다 — 기술부채가 내부에 숨겨지고, 비용이 외부 후발주자에게 전가됩니다.

일반 소프트웨어 엔지니어링 원칙

비표준 파일을 감지했을 때 정상적 프로그램이 해야 할 일:

1. 사용자에게 명백히 고지: "이 파일은 명세를 준수하지 않습니다"
2. 자동 수정은 사용자 동의 하에만: 조용한 수정은 금지
3. 기술부채를 외부에 공개: 어떤 비표준을 발견했는지 투명하게 기록

한컴은 이 세 가지를 모두 하지 않았습니다. 후발주자로서 rhwp는 이 방식을 따르지 않기로 결정했습니다.

rhwp의 입장

rhwp는 다음을 실천합니다:

1. 표준 준수 입력은 정확히 렌더 — 명세를 정답으로 취급
2. 비표준 입력은 감지하고 사용자에게 고지 — 경고·로그·validation 리포트
3. 자동 보정은 사용자의 명시적 선택 후에만 — "이 파일은 비표준입니다. 보정하여 보시겠습니까?" 같은 명시적 UI
4. rhwp 자신도 비표준을 새로 생산하지 않음 — 저장 시 정확한 값만 내보내거나, 불확실한 경우 원본을 보존하거나, 값을 생략

rhwp validate CLI (향후 계획 #185)

한컴의 DVC를 Rust로 포팅하면서 두 계층 검증을 제공합니다:

• Spec mode (엄격): OWPML 명세 준수 여부. 한컴 파일도 fail 가능
• Compat mode (관대): 한컴이 실제 받아들이는 범위 통과

두 결과를 모두 리포트해서 사용자가 "내 파일이 공식 표준인가 vs 한컴 한정 호환인가"를 스스로 판단할 수 있게 합니다.

생태계에 대한 제안

1. 한컴이 공식 인정 — "우리 과거 버전 일부가 비표준 lineseg 를 생성한다" 를 기술 문서로 공개
2. 공식 변환 도구 제공 — 기존 비표준 파일을 표준으로 정규화
3. 검증 도구 공개 강화 — DVC 같은 도구가 두 계층 검증을 분리
4. 후발주자 친화 문서 — OWPML 명세와 실제 한컴 구현의 차이점 공개 자료

이 네 가지가 없으면 HWPX 생태계는 계속 "한컴만 정답, 나머지는 피해자" 상태가 유지됩니다.

한 줄 요약

한컴의 방어 로직은 사용자에겐 친절한 기능, 후발주자에겐 보이지 않는 덫, 생태계엔 기술부채의 확산 채널이다. 숨김을 받아들이지 않는 것이 rhwp의 원칙이다.

---

관련 글: #183 HWPX 포맷 관찰, #184 LLM 기반 HWPX 생성 함정

[gameworkerkim]

잘 읽었습니다. 레거시를 정리하고 표준을 강제하는 것이 소프트웨어 개발자의 몫인데 그동안 한컴은 독과점을 이용해서 편하게 살아갔던 것으로 보입니다. 아래아 한글의 수 많은 고쳐지지 않은 버그는 보이지 않는 팬스로 이용되었던 것 같습니다. 늘 응원합니다.

[postmelee]

"이 네 가지가 없으면 HWPX 생태계는 계속 "한컴만 정답, 나머지는 피해자" 상태가 유지됩니다."

정말 공감합니다. 지금껏 한컴 생태계가 발전하지 못하고 오픈소스들이 매번 좌절했던 이유가 여기에 있다고 생각합니다.

[edwardkim]

일단 이번 크롬과 엣지 확장은 급한 것부터 패치해서 업데이트 배포 심사 요청해 놓은 상태입니다. HWPX 는 뷰어까지만 허용하고 저장은 disable 시켰습니다. 그리고 명시적으로 사용자들에게 문단내 줄 정보가 미흡한 경우 경고가 보여지도록 해놓았으니, 사용자 반응을 보면서 향후 대응방안을 설계하고 구현할 시간은 벌은 것 같습니다.

[INMD1]

글 감사합니다.
저도 이번에 Hwpkit 오픈소스로 개발 하면서 hwp hwpx을 html docx md 변환 하는건 성공 하는데 아직 재현율은 80%이지만 docx을 hwpx나 hwp로 열때 깨지거나 빈문서라고 뜨네요 ㅜㅜ

아직 수정할건 테산..

[edwardkim]

글 감사합니다.
저도 이번에 Hwpkit 오픈소스로 개발 하면서 hwp hwpx을 html docx md 변환 하는건 성공 하는데 아직 재현율은 80%이지만 docx을 hwpx나 hwp로 열때 깨지거나 빈문서라고 뜨네요 ㅜㅜ

아직 수정할건 테산..

mydocs 폴더 중 트러블슈팅이 있습니다. 공식 스펙 문서 오류 정오표 정리 문서와 hwp 저장 시도 실패와 이를 해결하면서 얻은 인사이트 문서를 공유하고 있습니다. 이 문서들은 여전히 작성 중인 상태이며 부족한 지점이나 잘못된 부분이 발견되면 PR 주세요.

[INMD1]

위의 원인 분석 부분에서 설명된 내용을 참고하여 HWPX의 hp:lineseg 요소를 역 분석해서 이를 코드로 구현하고 있습니다. 작업이 완료되면 공유드리겠습니다. 여기서 만든 곳에 넣어서 만들어 보고 싶네요 ㅎㅎ

[OctopusET]

다른곳에서도 간단하게 이야기했는데, hwp/hwpx 스펙을 작성하는 프로젝트를 하고 있습니다. 해당 스펙 데이터는 yaml형식입니다. 따로 검증 툴도 만들어서, hwp과 hwpx 파일을 직접적으로 분석한 스펙과 비교하여 잘못된 데이터를 확인할 수 있습니다. 폰트나 DRM 분석 부분은 법적 문제가 있을 것 같아 바로 공개는 못하고, 곧 공개 예정입니다. 필요하신 분들은 미리 공유 드리겠습니다.

[OctopusET]

yaml로만 작성한건 아니고 typst로 해당 데이터를 불러와서 PDF및 HTML으로 확인이 가능합니다

[edwardkim]

다른곳에서도 간단하게 이야기했는데, hwp/hwpx 스펙을 작성하는 프로젝트를 하고 있습니다. 해당 스펙 데이터는 yaml형식입니다. 따로 검증 툴도 만들어서, hwp과 hwpx 파일을 직접적으로 분석한 스펙과 비교하여 잘못된 데이터를 확인할 수 있습니다. 폰트나 DRM 분석 부분은 법적 문제가 있을 것 같아 바로 공개는 못하고, 곧 공개 예정입니다. 필요하신 분들은 미리 공유 드리겠습니다.

매우 중요한 일을 하시고 계셨네요! 덕분에 삽질을 많이 줄일 수 있을 것 같아 기대됩니다. 주말내내 삽질하고 있었습니다 ㅠㅠ

[Miles-Haeseok-Lee-80]

아 이게 저작권이 있을 수 있어서 재배포가 가능할지는... 대체 왜 표준 문서를 돈 24만원을 주고 파는지... ㅠㅠ 확인 받고 하시길... xsd 파일 조차 여러 페이지에 쪼개 표시한 표준 pdf 혹은 머신리더블이라고 주장하는 나라 표준 인증의 자료를 보고 있자면 ㅠㅠ 만들어주시면 감사하겠습니다.

https://www.kssn.net/search/stddetail.do?itemNo=K001010149626

[jangster77]

표준 문서를 오픈해 놓고, 여기서는 돈받고 파네요. 표준문서도 엉터리라, hwp3 포맷팅 IR 로 매핑하는데 상당히 어렵더군요.