K-공문서 HWP가 30년간 묶인 진짜 이유, 그리고 풀어야 할 해법

K-공문서가 30년 동안 특정 소프트웨어에 묶인 진짜 이유, 그리고 풀어야 할 해법

2026년 6월 현재, 한국에서 만들어지는 모든 공문서는 1989년 출시된 한컴오피스(아래아한글)의 HWP 포맷 위에서 동작한다. 문제는 단일 파일이 아니라 그 안에 묶인 폰트와 양식, 그리고 그걸 풀 수 있는 법·제도적 장치가 부재하다는 점에 있다. KrIGF 2026에서 "사전 법적 확신 메커니즘"이 정식 의제로 오르는 이유를 정리한다.

HWP는 왜 30년 동안 표준이 됐는가

1989년은 오픈소스라는 용어 자체가 없던 시절이다. 1985년 GNU 선언이 나왔고, 1998년 Open Source Initiative가 결성되어 "오픈소스"라는 단어가 사회적으로 자리 잡기까지는 10년 이상 걸렸다. 한컴오피스가 한국 정부와 교육기관에 빠르게 안착한 건 이 시점과 맞물려 있다. 그 시절엔 시스템에 들어가는 기본 폰트도 상용이 당연했고, 정부 표준 문서 양식은 그 상용 폰트의 자간·장평 위에서 작성됐다.

이후 30년 동안 정부·공공기관이 생성한 수십억 건의 문서가 특정 상용 폰트와 그 메트릭에 묶였다. 문서 자체의 저작권은 정리할 수 있어도, 문서가 의존하는 글리프 모양과 도화지 크기 정보를 한꺼번에 떼어내는 작업은 제도적으로 보호받지 못한다.

K-공문서 양식이 깨지지 않는 구조

K-공문서 양식은 장평·자간을 mm 단위로 맞춰 짜여 있다. 같은 12pt라 해도 어떤 폰트는 글자 폭이 6.2mm, 다른 폰트는 5.9mm로 0.3mm 차이가 난다. 이 차이가 줄 단위에서 누적되면 페이지당 줄 수가 1~2줄 어긋나고, 표 안에서는 셀이 깨지며, 도장·결재선 같은 좌표값이 한참 밀린다. 결국 "보기 흉하다" 수준이 아니라 "출력 자체가 안 된다"는 문제로 직결된다.

특히 정부 표준 문서에는 본문·표·머리글·꼬리글·도장·결재선·바코드·QR 등 11개 영역이 별도 폰트와 좌표계를 쓴다. 한 영역의 메트릭이 0.1mm만 달라져도 인쇄 시 승인·결재 박스가 도장 위를 가리는 일이 발생한다. 그래서 호환 폰트를 만들 때 글리프 모양은 새로 그려도 메트릭은 원본과 1:1로 일치해야 한다.

"모양은 베끼지 않고 크기만 베끼는" 메트릭 호환 폰트

해법은 의외로 단순하다. 글리프 모양(베지어 곡선)은 새로 그리되, 도화지 크기(advance width, ascent, descent, side bearing)만 원본과 동일한 폰트를 만들면 된다. 이런 폰트를 메트릭 호환 폰트(metric-compatible font)라고 부른다. 모양 자체는 다른 라이센스의 폰트라서 저작권 문제가 없으면서, 폭·높이는 동일하므로 양식이 깨지지 않는다.

폴라리스오피스(Polaris Office)는 이 접근을 도구화한 Polaris MCFG(Metric-Compatible Font Generator)를 오픈소스로 공개했다. 상용 폰트에서 메트릭 데이터만 추출한 뒤, 오픈소스 폰트의 글리프를 같은 메트릭 위에 입혀 새로운 폰트 파일을 만들어낸다. 이 방식은 리눅스·안드로이드·웹 브라우저 같은 오픈소스 렌더러가 K-공문서 양식을 그대로 재현할 수 있게 해준다.

그러나 "써도 되는가"가 더 큰 문제

메트릭 호환 폰트 자체는 기술적으로 검증된 방식이지만, 한국에서는 이걸 만들어도 되는지 사전에 확신받을 길이 없다. 해외에는 "사전 법적 확신 메커니즘(legal pre-clearance mechanism)"이 이미 여러 형태로 존재한다. 미국·EU·일본은 오픈소스 호환 목적을 위해 원본 저작물을 분석·수정해도 된다는 법적 안전장치를 마련했다. 한국은 그런 장치가 없다.

그래서 KrIGF 2026에서는 이 "사전 법적 확신 메커니즘"을 한국형으로 만들자는 논의가 정식 의제로 올라간다. KISTI(한국과학기술정보연구원)·폴라리스오피스·오픈넷·보인정보기술·학계·법률 커뮤니티가 한 자리에 모여, 메트릭 호환 폰트뿐 아니라 HWPX 표준안·오픈소스 HWP/HWPX 처리 도구 생태계 전반에 걸친 안전장치를 함께 그린다.

오픈소스 HWP 생태계는 이미 무르익고 있다

• pypandoc-hwpx — KISTI의 장민석 연구원이 메인테이너로 개발하는 마크다운 → HWPX 변환기
• rHWP — 김영관 메인테이너의 Rust 기반 HWP 파서/라이터. 메모리 안전성 + 고속 처리
• HWPX 표준안 — 보인정보기술의 김현영 부사장이 제정한 표준. 한컴오피스의 폐쇄적 HWP 5.x와 구분되는 OASIS 기반 공개 표준
• 오픈코드리뷰 도구 — 알리바바의 AI 코드 리뷰 도구와 함께, 오픈소스 재단 차원의 HWP/HWPX 처리 도구 목록이 정비되고 있다

2026년 7월 KrIGF에서 다뤄지는 4가지 의제

| 의제 | 현재 상태 | 한국형 해법 후보 |

|------|-----------|------------------|

| 메트릭 호환 폰트 | 기술적으로 가능, 법적으로 회색지대 | 사전 법적 확신 메커니즘 도입 |

| HWPX 표준 | OASIS 기반 표준안 제정 완료 | 정부 공문서 의무 채택 |

| 오픈소스 HWP 처리 도구 | pypandoc-hwpx·rHWP 등 5종+ 공개 | 표준안과 연동한 인증 체계 |

| 상호운용성 권리 | 특정 S/W 종속 상태 30년 지속 | 디지털 공공재로 편입 |

표준 명세만 있으면 어떻게든 만든다 — 그게 AI 시대

표준이 명문화되어 있고 그 표준이 오픈소스로 공개되어 있으면, AI 시대에는 호환 앱이든 렌더러든 자동으로 만들어낸다. LLM이 표준 문서를 읽고 → 호환 코드 생성 → 테스트 자동화까지 한 사이클에 끝낸다. 그런데 한국 정부 문서의 표준은 HWP 5.0(한컴사 독점)이라는 폐쇄 사양이고, 폰트 메트릭은 상용 폰트사에 묶여 있다. 표준이 깨져 있으니 AI가 개입할 여지가 없다.

결국 2026년 7월 2일 KrIGF 세션3의 쟁점은 단순한 폰트 문제가 아니라 "한국 공공 문서가 특정 벤더에 종속된 채 30년을 보낸 것"을 인정하고, 메트릭 호환 폰트 + HWPX 표준 + 사전 법적 확신 메커니즘 3종 세트로 종속을 끊을 법적·기술적 토대를 한 번에 깔자는 데 있다. 표준이 열리면 호환 앱은 AI가 만든다. 문제는 표준을 열 수 있는 법·제도 장치다.

2026년 6월 기준으로 본 정리

• 1989년 한컴오피스 출시 이후 30년 동안 정부 공문서가 상용 폰트·독점 포맷에 종속
• 메트릭 호환 폰트(Polaris MCFG)는 기술적으로 검증된 해법, 그러나 한국에는 "써도 되는지" 확인받을 사전 법적 확신 메커니즘 부재
• 2026년 7월 2일 KrIGF 2026 세션3(13:40-15:00, 80분)에서 한국형 메커니즘 정식 논의 시작
• HWPX 표준안·pypandoc-hwpx·rHWP 등 오픈소스 생태계는 무르익었으나 표준 채택·법적 안전장치 미비
• AI 시대에 표준만 열리면 호환 앱은 자동 생성 가능 → 가장 시급한 과제는 "표준을 열 수 있는 제도" 자체

2026년 6월 기준으로, K-공문서 종속 문제는 더 이상 기술 문제가 아니라 인터넷 거버넌스·디지털 공공재 문제로 자리 이동했다. KrIGF 2026 세션3(2026.07.02. 13:40-15:00, 정동 프란치스코 교육회관 + 유튜브 생중계)이 그 시작점이 된다.