2026년7월2일 오픈넷 박경신 이사는 KrIGF세션에서 Metric Compatible Font의 저작권 문제에 대해서 토론하였습니다. MCF는 유료폰트파일로 만든 서류를 오픈소스SW로 열때 줄바꿈이나 포맷팅이 깨지지 않도록 폰트의 모양과 크기가 똑같게 만든 폰트파일을 말합니다. 이렇게 하면 유로폰트파일이 폰트 구현을 위해 이용하는 수치들(metric)을 정확히 입력해야 합니다. 즉 폰트파일을 복제하는 것이 아니라 유료폰트파일에 입력된 각종 수치들만 수집해서 새로운 폰트파일을 만들때 입력하는 것을 말합니다. 이런 것은 당연히 저작권침해가 아닙니다. 오히려 INI파일 판결(대법원 2014. 10. 27. 선고 2013다74998, 2013다75007 판결)에 비추어보면 더욱더 수치입력은 저작권침해가 아니라고 합니다. 그런데 유료폰트파일 제작사들이 EULA에 metric을 이용하지 못하도록 하는 조항을 두고 있는데 그와 같은 비밀유지조항이 과연 효력이 있는가가 쟁점으로 남아 있습니다.
아래는 세션 소개, 토론내용 및 발제자료입니다.
_________________________________________________
본 세션은 한국의 공공 문서 생태계에서 발생하는 “공익적이지만 법적으로 불확실한” 상호운용성 시도들을 다룬다. 구체적 사례로 (1) 2026년 5월 12일 HWPX 저장 기능을 잠정중단한 rHWP 프로젝트, (2) 폴라리스오피스가 공개한 메트릭 호환 폰트(Polaris MCFG) 생성기를 둘러싼 폰트 EULA·저작권 회색지대, (3) AI/LLM이 생성한 공문서의 폰트·포맷 책임 귀속 문제를 다룬다. 이 문제들이 단순한 문서 포맷 이슈가 아니라 개방형 표준, 다중 이해관계자 인프라, 보편적 수용성, 디지털 공공재, AI 거버넌스 등 인터넷 거버넌스의 핵심 의제와 맞닿아 있음을 보인다. 발제 이후 청중과의 라운드테이블 토론으로 운영하며, “한국형 사전 법적 확신 메커니즘”(미국 SEC No-Action Letter 유사 제도)의 윤곽을 함께 그려나간다. 마지막 5분은 도출된 합의점과 이견 지점을 분리해 기록·정리하는 시간으로 사용한다. 세션 결과는 KrIGF 종료 후 정책 제안 보고서 초안으로 회수되며, 오픈소스 HWP/X 개발자 커뮤니티와의 후속 작업으로 이어진다.
◎ 패널 구성
■ 사회 : 장민석(한국과학기술정보연구원(KISTI), 선임)
■ 토론 :
김영관(rHWP 메인테니어), 오픈
이해석(폴라리스오피스 CTO), 상용·오픈
이호준(동의대학교), 청년·오픈
박현제(한림대학교 소프트웨어학부 특임교수), 학계
박경신(오픈넷 이사), 법률 (온라인)
김현영(보인정보기술 부사장), 표준
표준에 새로 들어가야 할 것 (★★★ · 전원 중 희망자 · 5분)
【배경】 이제 한컴 말고도 여러 도구가 HWPX를 만들고, AI까지 문서를 읽고 씁니다.
【질문】 그렇다면 지금 HWPX 표준에 새로 들어가야 할 게 있다면 뭘까요?
【방향】 예를 들어 ‘이 문서를 무엇이(어떤 구현체·AI·버전이) 만들었는지’ 표시하는 규약, 또는 어디서든 똑같이 재현되게 하는 데 필요한 정보 같은 것을 떠올려 주셔도 좋습니다.
rHWP는 왜 HWPX 저장을 멈췄나 (★★★ · 김영관 · 3분)
【배경】 rHWP가 올해 5월, HWPX 저장 기능을 잠정중단했습니다.
【질문】 그 결정을 내리기까지, 가장 컸던 이유가 뭐였나요?
【방향】 기술적인 이유든(버전마다 다른 렌더링, 데이터 손실 등), 그 외의 부담이든 — 실제로 결정을 누르게 한 지점을 솔직하게 들려주시면 됩니다.
MCFG, 발단을 만든 분께 (★★★ · 이해석 · 3분)
【배경】 오늘 이 세션은, 사실 폴라리스 MCFG를 보다가 제가 의제를 만들게 된 데서 시작됐습니다. 발단을 만드신 분께 직접 듣고 싶습니다.
【질문】 (1) MCFG, 어떤 도구이고 왜 만드셨나요? (2) 만들고 공개하는 과정에서 가장 곤란했거나 망설여졌던 순간은 언제였나요?
【방향】 (1)은 프로젝트 소개를 편하게 해주시면 됩니다. (2)는 기술 외적인 어려움 — 라이선스나 ‘이걸 이렇게 써도 되나’ 하는 망설임이 있었다면, 말씀하실 수 있는 선에서 들려주시면 오늘 논의의 출발점이 됩니다.
호환을 무엇으로 증명하나 (★★ · 김영관 + 이해석 · 3분)
【배경】 표준도 있고, 한컴이 공개한 검증기 DVC도 있고, 폴라리스에선 그걸 Rust로 포팅하기도 했죠. 렌더링도 다들 어떻게든 해내고 있습니다.
【질문】 (1) 그런데 ‘내가 만든 게 표준에 맞다’는 걸 무엇으로 증명하나요? 지금 그럴 만한 게 있나요? (2) 없다면 — 그런 기준을 누가 만들고, 누가 계속 관리해야 할까요?
【방향】 ‘구조가 맞는지’는 봐도 ‘똑같이 그려지는지’를 판정할 공통 기준(테스트 문서셋)이 없다는 점, 그리고 그 기준의 ‘정답’을 무엇에 맞춰야 하는지(특정 제품인지 표준 명세인지), 만든 뒤 누가 유지보수할지 — 평소 느끼신 현실을 짚어 주시면 됩니다.
변환기를 만든 청년이 본 벽 (★★ · 이호준 · 3분)
【배경】 이호준 님은 학생이면서 HWPKit, docx↔hwpx 변환기를 직접 만드셨죠.
【질문】 만들면서 ‘이건 표준만 봐선 도저히 안 되겠다’ 싶었던 순간이 있었나요?
【방향】 가장 까다로웠던 케이스(표, 줄바꿈, 폰트 등) 하나를 구체적으로 들려주시면 좋습니다.
폰트, 어디까지가 보호 대상인가 (★★★ · 박경신 · 5분)
【배경】 폰트의 글자 모양 자체는 판례상 저작물로 보호되지 않고, 폰트 프로그램 파일만 보호된다고 알려져 있습니다.
【질문】 그렇다면 폰트에서 수치 데이터(메트릭)만 뽑아 쓰는 것은 법적으로 어디쯤 있는 행위인가요? 명확한 편인가요, 아니면 아무도 확답하기 어려운 회색지대인가요?
【방향】 94누5632 이후의 판례·학계 동향, ‘측정 가능한 사실 데이터’와 ‘보호받는 프로그램’의 경계, 폰트 약관(EULA)의 추출 금지 조항이 실제로 어디까지 미치는지 — 법률가의 시선에서 현재 위치를 짚어 주시면 됩니다.
‘미리 안심시키는 장치’는 가능한가 (★★ · 박경신 · 4분)
【배경】 해외에는 ‘이 행위는 문제삼지 않겠다’고 기관이 미리 의견을 주는 제도가 있습니다(미국 SEC·FDA 등).
【질문】 이런 것을 한국에 만든다면, 법적으로 담을 수 있는 그릇이 있을까요? 기존 제도로 가능한가요, 새로 설계해야 하나요?
【방향】 비조치의견서·규제샌드박스 같은 기존 제도의 범위와 한계, 디지털·오픈소스 영역에서의 공백, 새 틀이 필요하다면 어떤 모습일지 — 가능성 중심으로 그려 주시면 됩니다.
인터넷은 열려 있는데, 왜 문서는 안 그런가 (★★★ · 박현제 · 4분)
【배경】 교수님은 한국 인터넷을 누구에게나 열린 인프라로 만들어 오셨고, 작년 인터넷 명예의 전당에 헌액되셨습니다.
【질문】 인터넷은 누구나, 어떤 기기로든 접속할 수 있게 열려 있습니다. 그런데 그 인터넷을 타고 오는 공문서는, 시민이 아무 도구로나 열고 고치고 출력할 수 있나요? 인터넷을 열어오신 눈으로 볼 때, 이 상황을 어떻게 보십니까?
【방향】 네트워크에서 ‘패킷이 자유롭게 흐르는 것’과 그 위에서 ‘문서가 자유롭게 흐르는 것’을 같은 선상에서 봐 주시면 좋겠습니다. 5만원짜리 라즈베리파이로도 공문서를 다룰 수 있어야 한다는 보편적 접근권의 관점, 인터넷 거버넌스 원칙(개방표준·보편적 수용성)에서 이 문제를 짚어 주시면 됩니다.
이 표준, 원래 무엇을 하려던 것이었나 (★★★ · 김현영 · 4분)
【배경】 이 표준을 직접 만드신 분이 자리에 계십니다. 외부에서는 결과만 보지, 왜·어떻게 만들었는지는 잘 모릅니다.
【질문】 (1) KS X 6101, 애초에 무엇을 하려고 만든 표준이었나요? 그때 어떤 논의가 오갔나요? (2) 그 표준이 지금, 만들 때 생각한 대로 쓰이고 있나요?
【방향】 표준의 본래 목적(기존 HWP 호환)뿐 아니라, 적용범위에 함께 담긴 ‘확장성’이나 ‘호환성 평가 기준’ 같은 부분이 처음에 어떤 의도였는지, 그리고 14년이 지난 지금 그 의도가 충분히 실현됐는지 — 만드신 분만 아는 이야기를 들려주시면 됩니다.
표준을 만들어도 왜 결과가 다른가 (★★★ · 김현영 · 4분)
【배경】 같은 HWPX인데 한컴 버전마다, 웹에서, 조금씩 다르게 그려집니다(발제에서 보여드린 대로). 문서 포맷 분야에는 여러 회사가 모여 ‘정말 똑같이 작동하는지’ 맞춰본 사례(ODF 등)도 있습니다.
【질문】 표준을 직접 쓰신 입장에서 — 표준이 ‘이렇게 그려라’까지 책임질 수 있는 영역인가요, 아니면 그건 표준 밖인가요? 그리고 그 간극은 어떻게 메워야 할까요?
【방향】 명세가 ‘저장’은 정해도 ‘렌더링 동일성’까지 강제하기 어려운 부분, 그렇다면 구현체들이 모여 맞춰보는 자리(PlugFest 같은)와 그 결과를 표준 개정에 반영하는 구조가 필요한지, 누가 그 자리를 만들어야 할지 — 표준화 관점에서 짚어 주시면 됩니다.
0 Comments