Changwoo Hacks

HWP → HWPX 전환, 과연 인공지능 활용에 좋은가?

Sun, 26 Apr 2026 15:00:00 +0000

TL;DR: 전환은 찬성. 2026년 기준으로는 글쎄요? 진짜 문제는 페이지 렌더링 위주의 문서 작성 문화가 문제다.

최근 공문서 포맷을 HWP에서 HWPX로 전면 전환한다는 소식이 들려옵니다. AI 전략위원회는 그 이유로 “hwp 파일은 개방형 포맷인 hwpx와 달리 AI가 내부 정보를 분석하고 학습하기 어려운 폐쇄형 구조를 지니고 있어 여전히 AI 시대의 걸림돌이 되고 있다”라는 점을 들었는데요.

드디어 ‘hwp’ 공문서 사라진다 - 미디어오늘

과연 실상은?

HWP v5: 폐쇄형이지만, 이미 많이 알려져 있는 포맷

우리가 흔히 말하는 HWP는 정확히 HWP 포맷 v5를 의미합니다. 마이크로소프트의 Compound Document Format을 기반으로 한 바이너리 포맷이죠. (v3 또는 그 전의 포맷도 있으나 수십년 전이라 사실상 찾아볼 수 없습니다.)

바이너리 데이터라 다루기 까다로운 건 사실입니다. 하지만 “읽을 수 없는 폐쇄형 포맷”은 아닙니다. 한컴이 포맷을 공개한 일이 이미 15년이 넘었고, hwp 포맷을 읽을 수 있는 수많은 오픈소스 구현이 있습니다. 저 역시 GNOME 데스크톱 환경에서 섬네일이나 문서 정보를 추출하는 기능을 직접 구현했습니다. 2026년 현재 수준에서 HWP 포맷 구현은 그렇게 대단한 일이 아닙니다. 어렵게 스펙 문서를 읽지 않고도 AI의 도움만 받아도 될 정도죠. 실제로 한국 시장을 공략하는 ChatGPT나 Gemini 같은 AI 서비스들도 이미 HWP를 무리 없이 읽어내고 있습니다.

다만, 바이너리 처리 과정에서 발생하는 보안 취약점은 여전히 만악의 근원입니다. 악성코드 실행의 단골 통로가 된다는 사실만으로도 보안 측면에서 교체하는 것이 마땅합니다.

HWPX: 더 낫긴 하지만, 결국 같은 내용인데?

HWPX 역시 표준화 시점인 2011년부터 공개된 이후 3차례 개정까지 거쳐서 꽤 오랜 시간이 지났습니다. 비교적 최근인 2021년부터 한컴오피스에서도 기본 포맷이 되었습니다. 한글과컴퓨터가 열심히 추진하지 않은 게 다행이랄까요. 구현이 더 쉬운만큼 오픈소스 구현도 HWP v5보다 HWPX 쪽 완성도가 높습니다. 하지만 HWPv5와 비교했을 때 ‘AI 학습’ 측면에서 달라지는 게 있냐고 묻는다면 부정적입니다.

이 문서의 스펙은 KS X 6101(OWPML) 표준에 잘 기술되어 있는데, HWPX는 본질적으로 HWPv5의 논리 구조를 XML 포맷으로 옮겨 담은 것에 불과합니다. 정확히 다음과 같이 대응됩니다.

HWP v5의 compound document 스트림 → XML 파일
레코드 → XML 태그
레코드 내부 바이너리 데이터 → XML 속성

껍데기만 바이너리에서 XML로 바뀌었을 뿐, 그 내용은 완전히 동일합니다. 한컴오피스가 아니면 의미없는 구버전 호환성을 위한 정보도 들어있어서 표준으로 부적절할 정도로 내용이 똑같습니다. 구현이 조금 더 쉬워지고 보안성이 높아지는 효과는 분명하나, AI가 읽을 수 있는 문서의 표현력은 100% 동일합니다. 그러므로 포맷 전환이 AI 학습 효과를 높여줄거라고 보기는 어렵습니다.

문제는 ‘포맷’이 아니라 ‘문서 작성 방식’

AI가 한국 문서를 학습할 때 겪는 진짜 고충은 파일 포맷이 아니라, 문서 구조를 파괴하는 문서 양식에 있습니다.

워드 프로세서의 문서는 ‘문서 - 챕터 - 섹션 - 문단’으로 이어지는 계층적 구조를 가집니다. 하지만 많은 공문서가 이 구조를 무시한 채, 오직 ‘종이 위에서 어떻게 보이는가’, 즉 렌더링에만 집착합니다. 칸을 맞추기 위해 표 안에 글자의 크기를 미세하게 조정해서 구겨 넣거나, 문단 기능을 무시하고 스페이스바와 엔터로 여백을 조절하는 것과 같이 말입니다.

이런 식으로 작성된 문서는 포맷이 HWPX든, DOCX든, PDF든, 엑셀이든 상관없이 AI가 맥락을 파악하기 어렵습니다. AI가 이러한 문서를 읽으려면 페이지 렌더링 구조를 읽은 다음 문서 작성자의 의도를 역추적해 구조를 파악해야 하며, 이는 자원 낭비가 되겠죠. 지난 수십년간의 잘못으로 인한 대가를 치른다고 말할 수 있습니다.

포맷의 전환은 환영할 일이지만, AI가 잘 인식하는 문서 같은 얘기를 하려면 포맷보다도 ‘보기 좋은 문서’를 작성하던 문화의 변화를 얘기해야 하지 않을까요.

MariaDB 오픈소스 라이선스와 제품에서의 사용 가능 여부

Fri, 02 May 2025 15:00:00 +0000

2024년 9월 MariaDB plc를 K1 investment management LLC라는 사모펀드가 인수했다. 이로 인해 라이선스 정책이 바뀌지 않을까 하는 우려의 목소리가 있다.

한줄 요약하면: 공포마케팅이다.

MariaDB 회사와 MariaDB 오픈소스와의 관계

MariaDB는 MySQL AB가 2008년 썬마이크로시스템즈에 인수되고 다시 2010년에 썬마이크로시스템즈가 오라클에 인수된 뒤, 오라클에 대해 신뢰하지 못한 많은 MySQL 사용자들의 반발로 MySQL의 fork 프로젝트로 탄생했다. MariaDB 오픈소스 프로젝트는 미국의 비영리 재단인 MariaDB Foundation이 진행하고 있다.

반면 재단과는 별개로 영리 회사인 MariaDB plc도 있는데, 과거 SkyDB라는 회사가 이름을 MariaDB로 바꾼 곳으로, 뉴욕증시에 상장할 때 티커도 “MRDB”로 하면서 오픈소스 프로젝트로서의 MariaDB와 혼동하도록 마케팅하고 있다. MariaDB plc는 우여곡절 끝에 “MariaDB” 상표권을 구입해 현재 소유하게 되었고 몇몇 개발자가 회사의 직원으로 일하고 있기 때문에 어느 정도는 영향력을 행사하고 있다고 말할 수도 있다. 하지만 MariaDB 프로젝트와는 별개의 회사가 상표권을 구입한 경우로, 회사 소속이 아닌 개발자가 아직 많기 때문에 MariaDB 상표 외에는 개발에 절대적인 통제권을 갖고 있다고 보기는 어렵다.

오라클이 MariaDB를 통제할 수 있는가?

할 수 없다. MariaDB는 오픈소스 GPL/LGPL 라이선스로 릴리스한 MySQL 소스코드를 기반으로 하고 있으며, 이는 낙장불입으로, 이미 오픈소스로 전달된 소프트웨어는 저작권자인 오라클이라고 해도 철회할 수 없다. 소프트웨어의 라이선스는 오픈소스이든 아니든 저작권자가 릴리스 시점에 임의로 결정할 수 있으나, 이미 사용자에게 부여한 라이선스를 “아 생각해 보니까 안 되겠어. 몇년 전에 했던 말 취소하고, 지금 사용하고 있는 곳은 계속 사용하려면 백만달러를 받아야 겠어.” 하고 철회할 권한은 법적으로 없다. 너무도 당연한 것이, 이미 성립된 계약을 나중에 취소하고 일방적으로 유리한 계약으로 마음대로 변경하는 것과 같아서 계약 상대방인 소비자를 기만적인 행위이기 때문이다. (처음 계약 때부터 라이선스에 철회 가능하다고 미리 명시하는 방법도 있으나, GPL/LGPL은 그런 제한을 추가하는 일이 금지되어 있고, 명시한 라이선스더라도 철회 조건을 미리 명시하지 않은 임의의 철회는 미국이나 유럽 등에서 불법이라고 판결이 남.)

상식적으로 생각해 봐도 “법무팀이 영업하는 회사“라고 알려진 천하의 오라클이 2010년에 포크 뒤에 MariaDB에 뭔가를 할 수 있었으면 지금까지 가만히 있었을까? 비영리 프로젝트라서 가만히 놔뒀다고 쳐도, 뉴욕증시에 상장까지 한 MariaDB plc 회사에 대해 뭔가를 할 수 있는데도 지금까지 가만히 있었을까? 최근 K1 investment management LLC의 인수 전후로 아무것도 달라지지 않았다.

MariaDB 소프트웨어를 회사에서 사용할 수 없게 되는가?

계속 사용할 수 있다.

MySQL 시절부터 오픈소스와 상업용 라이선스 이중(dual) 라이선스 정책을 유지하고 있기 때문에 많은 사람들이 오해하지만, 오픈소스/상업용 이중 라이선스라고 해서 상업용일 때 상업용 라이선스를 “사용해야” 할 의무는 없다. 이중 라이선스는 사용자가 둘 중에 하나의 라이선스를 선택할 수 있는 것인데, 특정 조건에 따라 오픈소스 라이선스 사용이 금지된다면 그건 오픈소스라고 말할 수 없기 때문이다. 널리 인정되는 “오픈소스 정의”에 (https://opensource.org/osd) 따르면,

5. No Discrimination Against Persons or Groups (대상에 따른 차별 금지)
6. No Discrimination Against Fields of Endeavor (분야에 따른 차별 금지)

와 같아서, 오픈소스 라이선스라면 회사에서 사용한다거나 상업용으로 이용한다고 해서 금지하지는 않는다. 이는 MariaDB의 라이선스인 GPL v2 및 LGPL에도 해당되어, GPL/LGPL의 조건을 지키면서 회사의 사업을 하는데 문제가 없다면 계속 사용할 수 있다.

향후 변경 가능성

MariaDB 역시 (MariaDB 재단이든 회사든) 오픈소스 라이선스를 다른 제한된 라이선스로 변경할 수 없다. 첫째로 앞에서 말했듯이 소스 코드의 상당부분의 저작권자는 오라클이기 때문에 MariaDB 측은 변경할 권한이 없다. 또한 MariaDB의 라이선스인 GPL v2 및 LGPL은 결합되는 소프트웨어의 라이선스도 GPL 및 LGPL로 배포해야 하고, 제한적인 라이선스로 변경하는 일이 금지된다. MariaDB plc에서는 이른바 MariaDB pro라는 이름으로 유료 버전을 내놓고 있어서 라이선스 변경이 가능할 거라고 착각하기 쉽지만, “pro” 버전의 실체는 서버 애드온과 관리툴과 같은 부가 소프트웨어 및 기술지원일 뿐이지, 서버 소프트웨어의 라이선스는 동일하다.

만의 하나 MariaDB 상표권을 통해 프로젝트를 통제하려는 시도를 할 수는 있겠지만, MariaDB 프로젝트에 손상을 가한다면 MariaDB plc의 사업도 잃어버리기 때문에 그런 일은 쉽게 일어나지 않을 것이다. 설령 그런 일이 발생한다고 해도 MariaDB라는 이름을 버리고 같은 소스 코드를 기반으로 한 새로운 이름의 또 다른 오픈소스 프로젝트가 만들어질 게 뻔한 일이다. Postgres 등 대안으로 마이그레이션하려는 동력도 커질 수 있다. 어쨌든 설령 이런 일이 일어나더라도 수년에 걸쳐 벌어질 일이지, 내년부터 법적으로 못 쓰게 된다거나 하는 식의 일은 일어날 수가 없다.

왜 자꾸 이런 루머가 퍼지는가?

사실 이러한 루머는 하루이틀이 아니고, 오라클에 인수되기 전 MySQL AB 시절의 2000년대부터 시작해서 지금까지 계속 되어 왔다. 이는 상업용 라이선스를 최대한 판매하고 싶은 회사측과 리셀러 측에서 듀얼 라이선스가 동작하는 방식과 오픈소스 라이선스의 정확한 사실 관계를 고객에게 알리지 않고 왜곡해서 공포마케팅을 하기 때문이다. 또 이 시장에서 소비자인 많은 기업들은, 앞에서 말한 것처럼 상업적 이용에 아무런 문제가 없는 것이 명백함에도 불구하고, 마치 애매하게 법적인 “논란”이 있는 것처럼 말하고 그 존재하지 않는 “논란”에 대한 위험을 회피하려는 성향이 강해 제대로 알지 못한 채 막연한 공포감을 피하고 막연한 안정감을 찾으면서 불필요한 상업용 라이선스를 구매하는 일이 잦기도 하다. 이러한 현상이 MariaDB 프로젝트의 포크 이후 아직까지도 계속되는 걸 보면 기업용 소프트웨어 시장의 고질적인 패턴으로 보인다.

부디 이런 막연한 공포심에 휘둘려서 돈과 시간을 낭비하지 않기를 바랄 뿐이다.

지금까지 쓴 내용은 오픈소스 라이선스에 대해 어느 정도 아는 사람이라면 당연하고 상식적인 내용이지만, 반복되는 말을 줄이기 위해 쓴다.

해설: 레드햇이 RHEL의 오픈소스를 중지하는가? (답: 그렇지 않다)

Thu, 06 Jul 2023 15:00:00 +0000

2023년 6월 21일 레드햇 블로그, “Furthering the evolution of CentOS Stream (CentOS Stream의 계속된 진화)”
2023년 6월 26일 레드햇 블로그, “Red Hat’s commitment to open source: A response to the git.centos.org changes (레드햇의 오픈소스에 대한 약속: git.centos.org 변화에 대한 답)”

요악하면, 레드햇이 분위기를 흔들었지만 RHEL 기반 배포판 사용자 입장에서는 당장은 사정이 달라질 것이 없다. RockyLinux 등 RHEL 기반 배포판 버전 8 또는 버전 9 사용자는 아마도 이 버전의 지원이 끝날 때까지 계속 사용할 수 있을 것이다. 하지만 이러한 방향이 계속된다면 버전 10 이후는 어떻게 될지 알 수 없다.

복기: CentOS 종료

2020년 12월 글(해설: CentOS 종료)에서 설명했다시피 레드햇은 RHEL 배포판의 다운스트림 배포판으로서의 CentOS를 종료했다. CentOS 버전 8의 EOL까지 단축하는 등 갑작스러운 이 시도는 커뮤니티의 강한 반발을 낳았고, 결국 CentOS와 같은 또 다른 RHEL 기반 배포판 프로젝트가 다수 탄생하게 되었다. 그 중에서도 많이 쓰이는 RockyLinux 및 AlmaLinux와 같이 비영리 재단과 펀딩 구조까지 갖춘 배포판이 나와 오늘날에 이르렀다.

레드햇의 발표

레드햇에서 RHEL 개발을 총괄하는 코어 플랫폼 부사장 마이크 맥그레이쓰는 2023년 6월 21일 블로그에서, 앞으로 RHEL의 git 저장소를 RHEL 고객 계정으로 로그인해야만 접속할 수 있게 변경한다고 발표했다. 이 발표 내용을 보고 많은 사람들은 레드햇이 “오픈소스를 그만둔다”고 호들갑을 떨면서 반응하기도 했지만, 이는 사실이라고 볼 수 없다.

오픈소스인데 고객에게만 소스 코드를 공개하는 것이 허용되나? 사실 그렇다. “오픈소스”라는 용어는 언제나 사람들에게 혼동을 일으키는데, 소스를 널리 “오픈/공개”하는 것 여부는 그 소프트웨어가 오픈소스냐 여부와는 직접 상관이 없기 떄문이다.

오픈소스 정의(Open Source Definition) “2. Source Code” 내용을 보면, 오픈소스 소프트웨어는 소스 코드를 직접 배포하거나 바이너리 형태로 배포하는 경우

“Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge.”

“어떤 제품이 소스 코드 형태로 배포되지 않을 경우, 합리적인 복제 비용 이하로 소스 코드를 얻을 수 있는 잘 알려진 방법이 있어야 합니다. 인터넷을 통해 비용 없이 다운로드하는 방법이 좋습니다.”

즉 RHEL의 배포 대상에 대해 소스를 전달해야 할 뿐, 불특정 다수에 대한 소스 공개를 해야 한다는 뜻은 아니다. 단,

“must allow distribution in source code”

“소스 코드 형태의 배포를 허용해야 합니다”

그 소스 코드에 대한 배포를 제한할 수는 없다. 전달받은 소스 코드를 제3자에게 배포하는 것도 막을 수는 없다는 뜻이다.

레드햇의 조치가 별 문제가 없는 이유

앞에서 말한 것처럼 레드햇이 배포하는 RHEL의 소프트웨어는 여전히 오픈소스이므로, 그 정책을 포기하지 않는 한, RHEL의 소스 코드를 감출 수는 없다.

또 2021년부터 RHEL 구독 프로그램 중에 무료 티어가 생겼기 때문에, 무료 구독 권한으로도 얼마든지 소스 저장소에 접속할 수 있다. 소스 코드에 대한 배포를 제한할 수 없으므로, RHEL 고객 자격으로 소스 코드를 다운로드해서 전달하면 끝나는 일이다.

레드햇이 RHEL 빌드에 사용하는 git 저장소를 막았을 뿐이지 RHEL 소스(SRPM)의 배포를 막기는 쉽지 않은 일이며, 실제로 RockyLinux에서는 문제의 여지를 없애기 위해 레드햇의 서버에 접속하지 않고 소스 코드를 구할 수 있는 몇 가지 방법을 설명하기도 했다.

하지만 레드햇의 조치가 짜증이 나는 이유 (대체 왜 이러는 걸까?)

아무런 효과가 없는 일임에도 왜 그러는 것일까? 이유를 명확히 드러내지 있지만 레드햇의 포스트를 보면 RHEL 파생 배포판에 대한 불만에서 시작된 일임을 알 수 있다. 레드햇의 두 번째 포스트를 보면 RockyLinux와 같은 RHEL 파생 배포판에 대한 (“rebuilders”) 불만을 볼 수 있다.

“I feel that much of the anger … comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous. “

“… 분노의 대부분은 RHEL에 들어가는 시간, 노력 및 자원에 대해 비용을 지불하고 싶지 않은 사람들 또는 자기 이익을 위해 RHEL을 재패키징하려는 사람들에서 온 것이라고 생각합니다. RHEL 코드에 대한 이러한 요구는 솔직하지 않습니다.”

“More recently, we have determined that there isn’t value in having a downstream rebuilder … The generally accepted position that these free rebuilds are just funnels churning out RHEL experts and turning into sales just isn’t reality.”

“최근 우리는 다운스트림 리빌더를 보유하는 일이 가치가 없다고 판단했습니다 … 이러한 무료 리빌드 배포판이 RHEL 전문가를 배출하고 (레드햇의) 매출로 이어진다는 일반론은 현실과 달랐습니다.”

레드햇 입장에서 도움이 안 된다는 건 사실일 수 있다. (CentOS를 인수하고 운영하면서 그걸 깨닫는데 7년이 걸렸단 말인가?) CentOS 배포판에 익숙해진 엔지니어는 고객이 RHEL을 사용한다면 RHEL 지원을 할 수도 있지만 일부러 RHEL을 구입하라고 권하지는 않을 것이다. 그러한 엔지니어는 대부분 RHEL보다 CentOS 사용을 통해 이득을 보았을 것이다. CentOS를 비롯한 파생 배포판이 RHEL의 노력을 이용한 무임승차(free loader)였다고 말한다면 어느 정도 사실이라고 볼 수 있다.

하지만 파생 배포판이 없었다고 해서 그 고객이 RHEL의 고객이 되었을 것 같지는 않다.

시스템마다 수백불에서 (클러스터링 등 옵션을 추가하면) 수천불에 달하는 RHEL 구독 비용을 지불하는 일이 합리적인지는 각각의 사정마다 다를 수 있다. 그러나 2020년 내 글과 같이 CentOS의 사용자는 “엔터프라이즈”답게 높은 RHEL의 구독 비용을 낼 의사가 없기 때문에 사용자가 되었거나, 내지 않는다는 가정 하에 적절한 가격에 배포판에 번들된 추가 솔루션을 판매하고 있는 곳이거나, RHEL 구독에서 제공되는 고객 지원도 필요가 없는 고급 사용자로 자체 지원이 가능한 곳이었을 것이다.

무료 RHEL 배포판이 없어지면 이들은 과연 RHEL 구독을 할 것인가? 어느 정도는 당장은 익숙함을 찾아 구독할 수도 있다. 하지만 그들 대부분은 멋들어진 엔터프라이즈 리눅스를 선택한 사람이 아니기 때문에 결국 대안을 찾아 빠져나갈 것이다. 사실 리눅스 배포판은 대안이 너무 많다.

“In a healthy open source ecosystem, competition and innovation go hand-in-hand. Red Hat, SUSE, Canonical, AWS and Microsoft all create Linux distributions with associated branding and ecosystem development efforts.”

“건전한 오픈 소스 생태계에서 경쟁과 혁신은 함께 가는 것입니다. 레드햇, SUSE, 캐노니컬, AWS 및 마이크로소프트는 모두 관련된 브랜딩 및 생태계 개발 노력을 통해 Linux 배포판을 만듭니다.”

배포판 개발자인 내가 보기에도 이는 절반의 진실이다. RockyLinux나 AlmaLinux와 같은 파생 배포판도 나름의 브랜딩을 하고 자체 커뮤니티를 구축한다. 위에서 언급된 배포판들은 이슈가 생길 때마다 서로의 패치를 카피하고 “리빌드”를 한다. 물론 패치가 단순히 카피한다고 되는 것도 아니고 본인의 작업을 추가하며 가치를 쌓아 나가는 점에서는 마찬가지이다. 레드햇은 대체 어디부터 단순 “리빌더”라고 말하는 것일까?

또 데비안의 일종의 “리빌더”라고 할 수 있는 파생 배포판 우분투를 만드는 캐노니컬이 여기 포함된 이유는 무엇일까? 거대한 비영리 업스트림 배포판의 존재를 언급하고 싶지 않았던 것일까? 계속해서 보면,

“This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. … We don’t want that and I know our community members, customers and partners don’t want that.”

“이것은 오픈 소스에 대한 진정한 위협이며, 오픈 소스를 다시 취미나 해커 전용 활동으로 되돌릴 가능성이 있는 것입니다. … 우린 이를 원하지 않으며 커뮤니티 구성원, 고객 및 파트너도 원하지 않는 것을 알고 있습니다.”

누가 봐도 RockyLinux나 AlmaLinux이 운영하는 비영리 재단을 통한 오픈소스 프로젝트가 문제가 있는 것처럼 은근히 비판을 하고 있다.

이렇게 말하는 게 정당할까? 꽤 알려진 파생 배포판 중에서 정말 단순 리빌드만 하는 파생 배포판 같은 것은 없다. 당연히 RockyLinux/AlmaLinux도 버그를 수정하고 업스트림에 기여한다. 물론 레드햇은 오픈소스 기여가 매우 많은 회사이므로 자신있게 말할 자격이 있지만, 다운스트림을 상대로 이렇게 말할 수는 없다고 생각한다. 이러한 논리로 말하자면 레드햇 역시 다운스트림으로서 수많은 업스트림 오픈소스 때문에 기업으로서 많은 이익을 보고 있지만, 그렇다고 레드햇이 그 수백 수천의 업스트림의 몫을 정당하게 챙겨 줬다고 할 수 있을까? 이것이 오픈소스 생태계가 동작하는 방식이고 시장이 동작하는 방식이라고 정당화할 수 있겠지만, 그렇게 말할 수 있으려면 파생 배포판들도 그러한 생태계의 일원일 뿐이라고 말할 수 있어야 한다.

대체 왜 이러는 것일까? 회사가 돈을 못 벌어서 문제가 되는 상황을 걱정할 수도 있겠지만, 레드햇은 IBM이 인수하기 전에도 수조원 수준의 매출과 꾸준한 이익을 가져가고 있는 안정적인 회사로, 망할 가능성이나 수익성 때문에 레드햇의 아이덴티티인 배포판 사업을 포기할 가능성은 없다고 봐도 된다. 아니면 모회사 IBM에서 압박이 왔던 것일까?

앞으로는 & 생각

실제 RHEL 파생 배포판의 사용에는 별 문제가 없을 것으로 보인다. 하지만 이런 방향으로 가게 된다면 앞으로 부정적인 변화가 또 있을 수 있고, 2025년에 릴리스할 RHEL 10에는 어떻게 될지 알 수 없다.

한편 이 사건을 가지고 RHEL 리셀러들이 엉뚱하게 RHEL 다운스트림 배포판이 마치 불법인 것처럼 공포 마케팅을 시작할 수도 있으니 속지 말기를 바란다.

레드햇이 진짜 클로즈드 소스로 가게 되는 최악의 경우를 상상하더라도, GPL 또는 MPL과 같이 소스 코드의 배포를 강제하는 라이선스가 있는 소프트웨어가 RHEL 안에 필수적으로 들어가야 하고, 그 소스 코드의 배포를 제한할 수 없기 때문에 부분적인 클로즈드 소스가 될 것이다. 특히 레드햇은 RHEL 내용 중에서 레드햇이 직접 만드는 소프트웨어의 배포를 제한할 수 있다. 하지만 이렇게 부분적으로 비공개 소스로 가려면 OS의 구성도 많이 달라져야 할 것이다. 또 배포판 사업에서 부분적인 비공개 정책은 부정적인 결과가 많았기 때문에 레드햇이 그러한 선택을 하기는 쉽지가 않다.

비슷하게 여러가지 비공개 소스 번들 소프트웨어를 포함해 배포판을 구성했던 칼데라 리눅스같은 경우는 무엇보다도 그 특유의 폐쇄성과 라이선스 정책 때문에 고객에게 외면당했었다. 이를 만든 회사는 나중에 SCO라는 이름으로 바뀌면서 악명 높은 SCO - 리눅스 법적 공방을 시작했고 파산으로 이어졌다. 당시 SCO의 소송에 대항해서 승리한 당사자이기도 한 레드햇과 IBM이 이렇게까지 흑화하지는 않을 것으로 보인다.

진짜로 RHEL 파생 배포판을 만들 수 없는 일이 벌어진다고 하면, 이용자 대부분은 결국 RHEL 구독보다는 다른 대안을 찾아갈 것이다. 언제나처럼 데비안과 그 파생 배포판들을 선택할 수 있고 어떤 선택을 할 지는 이용자들의 몫이다.

나는 오픈소스를 판매하고 요금을 부과하는 것에 반대하지 않는다. 하지만 어떻게 해도 매출에 도움이 될 의사가 없는 다운스트림을 상대로 적대시하고 그들의 활동을 방해한다고 한다고 해서 회사가 이득을 볼 수 있는 부분은, 적어도 리눅스 배포판에 대해서는 거의 없다고 생각한다. 이렇게 해서 달라지는 건 지금까지 레드햇 본인들이 30년간 쌓아 온 생태계가 파괴되는 것 뿐이다.

여담

이번 뉴스 이후 합성 이미지 (레드햇 HQ 로비에 있는 마하트마 간디의 문구인데, 원래 이미지는 5년 전 IBM의 인수 직후 원문의 “THEN YOU WIN”을 “THEN THEY BUY YOU”라고 덧붙인 이미지다):

해설: CentOS 종료

Wed, 09 Dec 2020 15:00:00 +0000

2020년 12월 9일 CentOS 발표, “CentOS Project shifts focus to CentOS Stream”

요약하면 이제까지 우리가 알던 CentOS는 이제 끝이다. CentOS를 사용하던 사용자, 사용 회사, 사용 제품은 대안을 알아봐야 한다.

CentOS의 탄생

레드햇(회사)의 리눅스 배포판은 최초에 레드햇 리눅스(RedHat Linux)라는 이름으로 출발했다. 회사로서 레드햇은 인터넷 서비스의 폭발적인 성장 시대에 리눅스 서버의 성공을 이끈 장본인이었고, 1999년 닷컴 버블 때 나스닥에 상장하는 행운까지 겹쳤다.

레드햇은 2003년 리눅스 배포판을 커뮤니티 배포판과 기업용 제품으로 배포판 둘로 나누었다. 데비안과 같이 커뮤니티의 노력이 레드햇 리눅스에도 필요하다는 생각을 한 레드햇은, 제품으로의 기업용 유료 배포판인 RHEL(Red Hat Enterprise Linux) 배포판을 만들고 그 기반이 되는 커뮤니티 배포판으로 페도라(Fedora) 배포판을 만들었다. Fedora는 레드햇에서 후원은 하지만 커뮤니티가 독립적으로 운영하고 있어서 몇 가지 주요한 부분이 다르다. 2020년 현재까지도 이렇게 페도라와 RHEL로 운영되고 있다.

제품으로서의 RHEL은 흔히 소프트웨어를 구입한다고 할 때 사람들이 생각하는 소프트웨어 라이선스를 유료로 판매하는 배포판이 아니라 서비스 구독에 대한 비용을 (subscription fee) 받는 유료 배포판이다. 레드햇 회사에서 배포판의 업데이트, 고객 지원, 기타 부가 서비스를 제공할 뿐이지 리눅스 배포판이라는 사실은 변하지 않는다. RHEL을 구성하는 소프트웨어도 당연하게 배포하는 소프트웨어의 상당 부분이 GNU GPL이나 MPL과 같이 소스 코드의 공개가 불가피한 소프트웨어이고 레드햇은 이들 소프트웨어를 비롯해 모든 소프트웨어의 소스 코드를 공개하고 있다. (다른 몇몇 유료 정책을 가진 배포판은 상업/독점 소프트웨어를 포함하는 경우도 있었으나, 레드햇은 가능한 모두 오픈소스로 릴리스하는 정책을 취하고 있다.)

그러면 공개된 소스 코드를 빌드해서 RHEL과 똑같은 배포판을 합법적으로 만들 수 있지 않을까라는 생각을 자연스럽게 할 수 있다. (정확히 말하면 공개된 소스를 그대로 빌드해서 배포할 수는 없다. 소프트웨어의 라이선스가 GPL이기는 하지만 RHEL의 상표는 레드햇 소유라서 사용할 수 없고 레드햇이 운영하는 미러 사이트와 같은 서비스도 이용할 수 없기 때문에 몇 가지를 변경해야 한다.) 이런 생각에서 탄생한 배포판이 여럿이 있었고 그 중에서 남아서 아직까지 지속된 배포판 프로젝트가 CentOS(Community ENTerprise OS)이다.

즉 CentOS는 RHEL의 패키지를 다시 빌드하는 프로젝트로 만들어졌다.

레드햇의 CentOS의 “인수”

RHEL의 가장 큰 장점은 안정된 버전의 배포판을 오랫동안 지원한다는 점이었다. 예를 들어 2010년 11월에 처음 릴리스된 RHEL 버전 6이 지난달 2020년 11월에야 종료되었는데, 다른 어떤 리눅스 배포판에서도 10년이나 업데이트를 지원하는 경우를 거의 볼 수 없었던 것을 보면 안정된 버전을 추구하는 사용자들에게는 가장 이상적인 선택이었다.

RHEL을 다시 빌드한 CentOS는 그러한 RHEL의 장점을 무료로 누릴 수 있다는 점에서 큰 인기를 누렸다. RHEL처럼 레드햇의 고객 지원은 받을 수는 없지만, 보안 업데이트는 그대로 이용할 수 있었다. CentOS에 대한 고객 지원 서비스를 레드햇보다 저렴하게 제공하는 회사도 등장하기도 했다.

그러던 레드햇은 2014년에 CentOS 프로젝트를 “인수”했다. 비영리 프로젝트를 영리 회사가 인수한다는 표현이 적합하지 않을 수도 있지만, CentOS의 프로젝트 방향을 레드햇이 원하는 방향으로 결정할 수 있는 구조가 되었기 때문에 사실상 인수라고 말할 수 있다. 페도라와 마찬가지로 커뮤니티가 프로젝트의 결정권을 가지지만, 레드햇이 CentOS 상표의 소유권을 갖고, 미러 사이트와 빌드 서버와 같은 인프라를 제공하고, CentOS 프로젝트 주요 멤버 대부분을 레드햇이 직원으로 고용했다.

롤링 릴리스와 CentOS stream

한편 리눅스 배포판 중에서는 정기적인 특정 버전의 소프트웨어 릴리스를 하지 않고 자동 업데이트를 통해 배포판을 최신으로 유지하는 쪽을 선호하는 경우도 있다. 이를 포인트 릴리스(point release)에 대응하는 롤링 릴리스(rolling release)라고 하는데 Arch Linux나 Gentoo Linux가 대표적인 예이다. 개발 버전의 배포판을 사용하는 것과 비슷하지만 안정 버전을 따로 릴리스하지 않는다는 점이 차이점으로 개발과 안정의 중간의 적절한 지점을 찾는 게 중요하다.

CentOS Stream은 Fedora와 RHEL 사이의 그런 지점에 해당하는 롤링 릴리스 배포판으로 올해 초 CentOS 8 기반으로 새로 만들어졌다. 물론 사용자에 따라서는 이런 롤링 릴리스 포지션의 배포판을 선호하기도 하지만, 기존의 CentOS나 RHEL 사용자가 원하는 형태라고 보기는 어렵다.

이번 발표

이번 레드햇 발표에서 나온 사항은

CentOS 7은 예정대로 2024년까지 지원한다.
CentOS 8은 예정보다 빠르게 2021년에 종료한다.
CentOS 8을 쓰고 싶으면 CentOS stream으로 가는 방법이 있고,
아니면 RHEL 8 유료 구독을 할 수 있다. RHEL은 예정대로 2029년까지 지원한다.

CentOS의 대안이 CentOS stream이라는 건 말이 되지 않는다. CentOS 개발자는 롤링 릴리스를 써도 상관없다고 할지 모르겠으나, 롤링 릴리스를 쓰려는 사용자의 대부분은 지금의 CentOS 사용자가 아니다. CentOS를 쓰는 이유는 보통 안정 버전의 오랜 지원이기 때문이다. 계속 업데이트하는 롤링 릴리스를 원했다면 Fedora 개발 버전을 쓰거나 Arch Linux나 Gentoo Linux를 쓰고 있었을 것이다.

이번 발표의 가장 큰 문제는 애초에 2029년까지 보안 업데이트가 예정되어 있던 CentOS 8 버전을 당장 2021년까지 중지하겠다고 EOL 약속을 뒤집었다는 부분이다. 이 일정을 신뢰하고 지난 1년간 CentOS 8을 선택했던 사용자들은 순식간에 10년의 배포판 수명이 2년으로 줄어들어 버린 셈이 되었다.

흔히 기업의 제1목표가 수익이라고 말하지만, 이런 변화 때문에 RHEL 구독이 크게 늘어날 것이라고 연결하기는 어렵다. CentOS를 사용하는 사용자나 회사는 애초에 RHEL 구독 비용을 낼 의사가 없거나 내지 않는다는 가정 하에 비지니스를 운영하고 있는 곳이고, RHEL에서 제공하는 고객 지원도 필요가 없는 사용자일 것이기 때문이다. RHEL 수익을 기대한다기 보다는 발표한 것처럼 개발 인력과 자원의 투입을 중지하는 결정이라고 볼 수 있다.

이번 결정은 이와 같이 CentOS 사용자의 대부분은 원하지 않을 방향이고 CentOS 개발 메일링 리스트에서 어떤 사전 토의가 있었던 것도 아니었다. 레드햇 CTO의 글과 메일링 리스트의 메일을 보면 결국 레드햇의 결정에 의해 CentOS 이사회가 따른 것임을 알 수 있다.

대안은?

내 생각에는 CentOS가 처음 만들어졌을 때처럼 RHEL 8.x를 다시 패키징하는 또 다른 오픈소스 프로젝트가 생겨날 것이다. 레드햇 역시 예상이라도 한 듯이 이 발표에 대한 FAQ에 추가해 놓았고, 답변으로 오픈소스라서 할 수는 있지만 여기에 대해 레드햇의 어떤 자원도 사용하지 않을 것이고 CentOS 브랜드 사용도 허용하지 않을 것이라고 명시했다.

그래서 아마도 CentOS 사용자의 대안은 십중팔구 이렇게 만들어질 또 다른 CentOS와 같은 RHEL fork가 되겠지만, 만의 하나 분명한 대안이 나오지 않는다면 다른 배포판 대안을 찾게 될 것이다. 비슷하게 RPM을 사용하고 10년 지원이 되는 Oracle Linux가 있지만 오라클은 다른 의미에서 신뢰가 낮기도 해서, 개발자들 선호가 높은 데비안 계열 배포판으로 이동할 수도 있다.

커뮤니티 거버넌스

이번 변화는 리눅스 배포판의 커뮤니티에 의한 거버넌스가 얼마나 중요한지를 보여주는 사례라고 생각한다. 커뮤니티 배포판의 형식을 유지했지만 사실상 회사의 결정을 따를 수밖에 없는 레드햇 인수 이후 CentOS는 언제든 이런 일이 일어날 수 있었다. 커뮤니티라고 해서 언제나 모두를 만족시키는 결정을 할 수는 없겠지만, 만약 데비안에서 이런 결정을 내렸다면 지지부진하다고 느낄 정도의 토론이 미리 있었을 것이고 민주적인 결정과정이 있었을 것이다. 회사처럼 풍부한 인력과 자원을 보장할 수는 없어도 커뮤니티 배포판이 어쩌면 프로젝트의 지속성에서는 더 나을 수도 있다.

데비안 개발자/사용자로서 강 건너 불구경이지만, 한편 이런 커뮤니티 배포판의 중요성을 느끼는 사용자가 늘어난다면 Debian LTS가 CentOS와 같은 수요를 흡수하기를 기대해 본다.

짧은 글: 공공누리 (KOGL) 라이선스

Sat, 16 May 2020 15:00:00 +0000

2014년 저작권법이 개정되면서 들어간 저작권법 제24조의2는 국가나 지자체 공무원의 업무상 저작물 또는 국가나 지자체 소유의 저작물에 대해 “허락 없이 이용할 수 있다”라고 되어 있다(몇가지 특정한 예외를 제외하고). 이는 미국 연방 정부의 저작물에 대해 저작권을 인정하지 않는 미국의 연방 법률 저작권 규정과 (17 U.S. Code § 105) 비슷한데, “이용할 수 있다”라고 하는 걸 보면 아예 저작권이 없다고 볼 수는 없을 것이다.

이용할 권리를 명시적으로 허용하지 않더라도 법률에 따라 허용되는 상황인 셈인데, 후속 조치로 이러한 공공 저작물이 사용할 공공누리 (KOGL, Korean Open Government License) 라이선스가 만들어졌다. CreativeCommons 라이선스의 복제품이라고 볼 수 있어서 상업적 금지(BY-NC)와 2차저작물 금지(BY-ND) 규정이 들어간 라이선스의 유형을 구분해 (단 동일조건 재배포를 요구하는 BY-SA 조건은 없다) 비슷한 구조로 만들어졌지만, 저작권법 제24조의2에 해당하는 저작물은 상업적 이용 및 2차 저작물을 허용하는 “유형 1”만 가능하다. 저작권법 문맥에서 “허락 없이 이용할 수 있다”의 “이용”은 저작권법에서 허락해야 하는 상업적 이용 및 2차 저작물 권한까지도 포함하기 때문이다.

처음에는 공무원들도 이 법조항을 잘 모르고 공공 저작물에 대해 사용에 임의로 제한을 두는 일이 흔했지만, 날이 갈수록 개선되는 것으로 보인다.

오픈소스 기준에도 맞기 때문에 공공누리 유형1 라이선스의 저작물을 사용하는 것도 문제가 없어 보인다. 국제적인 인정을 더 받으려면 공공누리 관련 부처가 opensource.org에서 라이선스 심사를 받아 보는 게 좋을 것 같은데, (부처는 다르지만) 파이어폭스 NPKI GPKI 인증서 탑재와 관련된 지지부진했던 과거를 (1, 2) 보면 공공부처에서 이러한 과정을 처리하는 것에 그리 큰 기대는 할 수 없을 것이다.

한편 데비안에 포함하려면 (몇몇 글꼴은 가능성 있음) debian-legal 리스트에서 확인을 받아 보는 게 좋은데 어떻게 해야 하나 고민 중.

해설: '중국 자체 OS' UOS

Sat, 18 Jan 2020 15:00:00 +0000

최근 IT 기사에서 등장한 ‘중국 자체 OS’에 대해 알아보자.

‘PC 독립 선언’…중국, 자체 OS 정식 발표, 지디넷코리아 2020.01.17
윈도에 발목 잡힌 한국…OS 독립 선언한 중국, 머니투데이 2020.01.18

기사만 보면 단순히 중국 정부가 UOS라는 중국만의 자체적인 PC OS를 새로 만들었고 이를 이용해 윈도우를 사용하던 PC의 OS를 교체할 것처럼 생각하기 쉽지만 자세히 보면 그렇게 간단하지는 않다.

UOS는 Deepin 2020 버전

참여하고 있는 업체 중에 우한디핀테크놀로지(Wuhan Deepin Technology)라는 회사가 눈에 띄는데 이 회사가 Deepin이라는 데비안 기반 배포판을 개발하는 곳이기 때문이다. 공개된 스크린샷을 봐도 현재 Deepin이 현재 버전에서 사용하고 있는 Deepin Desktop과 크게 다르지 않고, 이미 한두달 전부터 Deepin V20 버전이 UOS라는 이름으로 베타 버전이 유출(?)된 버전이 돌고 있었다.

이제야 실행해 본 결과:

(엄밀히 말해서 위의 origins 설정은 틀렸다. 파생 배포판은 Parent 필드가 필요하다. 관련 man page)

단순히 “중국 OS”라는 낙인을 찍기 쉽지만 Deepin은 중국 외에도 많이 알려져 있고 2004년부터 데비안 기반 배포판을 개발하던 팀이 2011년 회사를 설립하면서 꾸준히 개발되던 데비안 기반 OS이다. Distrowatch에서 계속 10-20위권을 유지하는데 이 정도면 꽤 메이저 배포판이다.

데스크톱의 경우에도 윈도우/컴포짓 매니저는 Elementary OS의 Pantheon 데스크톱에서 쓰는 윈도우/컴포짓 매니저인 Gala를 기반으로 만들어졌다. Gala와 마찬가지로 mutter를 사용하므로 윈도우/컴포짓 매니저는 GNOME 기반이지만 다른 데스크톱과 앱은 Qt 기반으로 작성되는 등 나름 독특한 길을 가고 있기도 하다.

단지 사용하다 보면 중국어로 문서가 나오고, 개발자 커뮤니티도 회사 위주에 중국인들이 중국어로 소통하는 점 때문에 근본적으로 중국이나 중국어 구사자를 벗어나기는 쉽지 않다고 보인다.

즉 UOS는 완전히 새로운 것은 아니다. 유출된 버전을 살펴 보면 패키지 미러 사이트로 deepin의 미러 사이트가 아닌 새로운 도메인을 사용하고 있고, https://www.chinauos.com/applyfor 사이트에 회사 메일 주소로 개발자 계정을 등록해서 승인을 받아야 root 권한을 얻을 수 있는 등 (물론 수많은 우회 방법이 있다), 새롭게 브랜딩을 만들었지만 내용 상으로는 Deepin이다.

백도어, 감시, 사생활 침해? 충분히 의심스럽다.

UOS에서는 자체적인 음성 비서 기능을 내세우고 있는데 이는 Deepin에는 없던 내용이다. 이 부분도 미리 알려졌었다.

문제의 이 음성 처리 소프트웨어는 오픈소스로 공개될 가능성이 적은 데다가 사생활 문제에 대해 민감한 음성을 다루기 때문에 중국 당국의 감시에 대한 의심을 거두기 어렵다. 게다가 위 기사에서 추정한 것처럼 중국 국가 소유의 음성 기술 회사인 iFLYTEK에서 만든 iFLYTEK Open Platform처럼 중국 정부가 직간접적으로 영향을 미치는 회사의 음성 기술이라면 더욱 의심할만 하다.

하지만 내 생각에는 중국 당국의 감시 보다는 느슨한 중국의 개인정보 정책에 따른 회사의 무분별한 수집이 더 큰 문제가 아닐까 싶다.

성공할까?

내 생각에는 이 프로젝트가 큰 의미가 있는지도 모르겠다. MS 윈도우를 리눅스로 대체한다는 선언인 셈인데 그걸 위해 국적이 붙은 리눅스를 만들 필요는 없기 때문이다. 다른 여러 오픈소스 프로젝트와 마찬가지로 리눅스 배포판 프로젝트는, 특히 Deepin과 같은 파생 배포판이 사용하고 있는 데비안과 같은 주요 배포판은 국적이라는 개념이 모호하다. 배포판 뒤에 회사가 있는 경우에도 페도라 처럼 상당 부분이 커뮤니티의 힘에 의해 개발되는 경우가 많다.

오픈 소스는 그런 것이다. 미중 무역분쟁의 결과로 화웨이가 쓸 수 없게 된 안드로이드도 구글 서비스 앱, 플레이스토어, 구글 모바일 서비스에 대한 라이선스가 취소된 것이지 안드로이드 오픈 소스 프로젝트 코드에 대한 접근은 여전히 가능하다. 그런데 보통 리눅스 배포판은 그마저도 안드로이드와 다르게 구글 서비스와 같은 오픈소스에서 벗어난 제약이 전혀 없거나 있어도 구글 서비스처럼 필수적인 경우가 없다. 여차 하면 프로젝트 운영을 위한 서비스를 자체적으로 운영할 수 있는 여러 소프트웨어도 보통 같이 공개되고 있기 때문에 (우분투는 런치패드 정도가 예외적) 리눅스 배포판을 “외국 제품”으로 규정 지으면서 못 쓰게 될 걱정을 할 필요가 없다.

MS 윈도우를 대체하려는 계획으로 돌아가면, 문제는 윈도우에 익숙해진 사람과 호환성 같은 시장의 장벽을 해소하는 게 문제의 대부분을 차지하지 리눅스 배포판을 잘 만들고 아니고의 문제가 아니다. 중국 정부의 입김이 들어가는 예산에 대해 강제로 MS 윈도우 구매를 못 하게 하면 쓸 수밖에 없겠지만, 민간의 경우에는 그런 입김도 덜 들어가는데 사용하는 소프트웨어에 대한 호환성과 같은 한계가 분명히 있어서 쉽지 않은 일이다. (한국에서 벌어지고 있는 공공 수요의 개방형 OS 대체 계획이 민간 수요로 발전되길 기대하기 힘들듯이 비슷한 성격으로 볼 수 있다.)

하지만 성공 여부와 무관하게 예상할 수 있는 긍정적인 효과는 있다. 중국의 컴퓨터와 부품이 전세계에 유통되는 만큼, 중국의 컴퓨터와 부품 제조사가 UOS 호환성을 위해 노력한다면, 그들이 기여한 리눅스 커널과 관련 소프트웨어의 발전은 UOS 뿐만 아니라 전반적인 리눅스의 호환성에 도움이 될 것이다. 또 개발자 풀을 늘리게 되면 전반적인 오픈소스 데스크톱의 발전에 도움이 될 것이다.

결론

UOS를 엄청난 기술력의 존재로 생각할 필요도 없고, 반대로 급조된 제품으로 생각할 필요도 없다. UOS는 꽤 잘 만들어진 리눅스 기반 OS인 Deepin의 한 버전으로, 새로운 것은 아니다. MS 윈도우의 대체 성공 전망은 글쎄, 부정적이다.

OFL 글꼴의 흔한 문제

Sat, 28 Dec 2019 15:00:00 +0000

OFL이란

SIL Open Font License는 (SIL OFL, OFL) 여러 오픈소스 글꼴에 사용되는 라이선스이다. 여러 글꼴에 사용되고 있고, 페도라의 추천 라이선스이기도 하다.

한국 회사에서 만든 글꼴에서도 꽤 사용되고 있다. 네이버가 2010년 나눔글꼴의 라이선스를 OFL로 정하면서 한국의 글꼴에도 많이 사용되기 시작했다. 우아한형제들의 배달의민족 글꼴, 리디주식회사의 리디바탕도 있다.

왜 글꼴에 특별히 라이선스가 필요한가

글꼴의 경우에 발생할 수 있는 골치아픈 라이선스 문제는 문서에 글꼴을 포함하는 임베딩 상황이다. 어떤 문서를 배포할 때 (특히 인쇄를 고려한 문서의 경우) 문서에서 사용한 글꼴이 문서를 받아 본 사람의 컴퓨터에 설치되어 있지 않은 경우 그 문서를 제대로 표현할 수 없기 때문에 MS 오피스, ODF, PDF와 같은 문서 포맷에는 사용한 글꼴을 문서에 포함하는 기능이 들어 있다. 하지만 글꼴을 문서에 포함해 배포한다면, 그 순간 글꼴을 복사해서 문서와 합쳐 배포하는 것이므로 저작권법에 따라 해석한다면 글꼴의 2차 저작물을 재배포하는 셈이다. 글꼴의 저작권자들도 이런 식의 해석을 원하지 않기 때문에 글꼴 라이선스에는 임베딩을 명시적으로 허용하는 조항을 넣는다.

특히 글꼴이 GPL일 경우 문서 전체가 GPL이 되어 버리는 묘한 상황이 되기 때문에 GPL 글꼴 예외처럼 부가 조항이 생겨나기도 했다.

OFL 역시 임베딩을 명시적으로 허용하는 조항이 들어가 있다.

OFL 라이선스에 포함된 “타협”

단독으로 판매할 수 없다. 판매하려면 다른 소프트웨어와 함께 번들 형태로만 판매할 수 있다. 이 제약은 글꼴 디자인 회사의 경쟁사가 OFL 글꼴을 복사해 손쉽게 상업적인 글꼴 판매 시장으로 진입하지 못하도록 한다.
수정한다면 수정한 버전도 같은 OFL 라이선스로 배포해야 한다. GPL과 마찬가지이고, 이러한 제약을 수정 버전에서도 계속 유지하기 위해서 필요하다.

이런 제약을 생각해 보면 OFL은 폰트 임베딩을 허락할 뿐 GPL보다 제약이 많은 라이선스이다. 파생 소프트웨어가 계속 자유롭게 공개되기를 바라는 GPL과는 다르게 이런 제약은 글꼴을 공개하는 회사의 권리를 보호하기 위한 제약이다. OFL은 위와 같은 타협을 통해 충분히 자유롭게 사용하고 재배포할 수 있는 글꼴 라이선스를 선택하도록 유도하고 있다.

OFL 라이선스의 부작용

같은 이름으로 글꼴을 수정 재배포할 수 없다는 OFL 제약은 버그를 수정해야 할 때 문제가 된다. 즉 버그를 수정한 버전을 같은 이름으로 재배포할 수 없다.

결국 회사에서 수정사항을 반영해야 한다. 하지만 회사에서 브랜딩을 위해 만드는 글꼴은 지속적으로 관리하기 보다는, 한번 릴리스하고 몇 번 수정한 다음 몇 년이 지나면 또 다른 글꼴을 만드는 경우가 흔하기 때문에 글꼴의 버그나 개선사항을 반영하기가 쉽지 않다. 저작권자는 글꼴을 제작한 디자인 회사와 계약을 통해 제작하는 경우가 보통이기 때문에 장기간의 후속 작업을 기대하기 쉽지 않다. 아무래도 글꼴의 발표가 일종의 이벤트로 기획되는 탓이 크다.

대표적으로 한국에서 나오는 거의 모든 글꼴은 백슬래시에 원화 기호 글리프가 들어 있다. (당장 키보드의 백슬래시 자리에 원화 기호가 적혀 있기 때문이다. EUC-KR 인코딩의 영문 인코딩을 ASCII에서 백슬래시를 원화 기호로 만든 KS X 1003을 표준으로 사용하면서 유니코드가 나오기도 전부터 단추를 잘못 끼운 결과이다.)

또 나눔고딕, 나눔명조, 나눔바른고딕에는 U+22CE CURLY LOGICAL OR (⋎) 글리프와 U+22CF CURLY LOGICAL AND (⋏) 글리프가 서로 뒤바뀌어 있는 너무도 명백한 버그가 있다. 하지만 네이버는 나눔고딕/나눔명조에 대한 관심을 끊은 지가 오래전이라 문제를 수정하길 기대하기 쉽지 않다. 나눔바른고딕이 후속작이지만, 최근에는 또 다른 글꼴을 제작하고 있다. 게다가 네이버의 글꼴 프로젝트는 여느 오픈소스 프로젝트처럼 사용자와 개발자의 피드백을 받아들이는 체계가 없기 때문에 의견이나 개선 방향을 전달하기부터 쉽지 않다. 나눔글꼴의 데비안 패키지를 관리하는 내 입장에서도 문제를 발견했을 때 뭔가 할 수 있는 자유도가 없다고 느껴진다.

버그를 수정해야 하는데 글꼴 저작권자가 움직이지 않을 때 오픈소스 다운 해법은 라이선스에 규정된 대로 이름을 바꿔서 fork를 하는 게 정석적인 방법이다. 하지만 기존 글꼴을 사용하는 소프트웨어와의 호환성은 물론, 글꼴을 사용하는 사람들의 커뮤니티를 다시 만들다시피 해야 해 사실상 하기 힘든 선택이다. 나 개인적으로 실제로 fork 시도를 하기도 했지만 그리 성공적이지는 못했다. (Source Han Sans/Noto Sans CJK라는 본문 글꼴의 더 나은 대안이 생기기도 했고.)

또한 데비안과 같은 배포판의 경우에는 가능한 한 바이너리를 통째로 넣기 보다는 소스에서부터 빌드하는 편을 선호하는데, 글꼴에서는 사용하는 툴의 버전과 설정에 따라 결과물이 달라질 수 있으므로 SIL OFL을 준수하려면 소스 빌드는 어렵다.

해결 방법?

구글/어도비가 함께 제작한 Source Han Sans (어도비 브랜딩, 본고딕) 또는 Noto Sans CJK (구글 브랜딩) 글꼴은 2014년 처음 릴리스할 때는 Apache 라이선스를 채택했었지만, 2015년에 SIL OFL로 라이선스를 변경했다. 역시 이슈에 대해 대응하지 않았다면 위에서 말한 것과 같은 문제가 있었겠지만, 이 경우는 한국 글꼴이 공통으로 가지고 있던 문제를 대부분 해결한데다가 (처음부터 다국어 버전으로 기획된 이유가 크다), 현재까지 꾸준하게 메인테인하고 있고 피드백도 계속 받아들이고 있어 (아직까지는) 비교적 문제가 적은 편이다. 단 소스 빌드한 버전의 배포는 현재도 앞으로도 어렵다.

웹에서 많이 쓰는 Font Awesome도 마찬가지이다. 역시 OFL 라이선스지만 2012년 릴리스 이후 피드백을 받으면서 꾸준히 버전업을 하고 있다.

티맥스OS 리뷰: 대체 왜?

Sun, 25 Aug 2019 15:00:00 +0000

2019년 8월 14일에 공개된 티맥스OS 버전을 이제야 제대로 실행해 보고 드는 생각. 물론 오랜 리눅스 사용자, 데비안 개발자, 소프트웨어 엔지니어로서 단순히 실행한 것은 아니고 각 부분이 어떻게 돌아가는지, 어떤 부분이 리눅스와 데비안의 기능을 이어받았고, 어떤 부분을 바꾸고 추가했는지, 왜 이러한 선택을 했을까 생각하면서 살펴봤다. 오픈소스가 아닌 부분은 어느 정도는 짐작할 수밖에 없었지만 그래도 꽤 많은 것을 알 수 있었다.

결과적으로 보면 티맥스OS에는 흔히 생각하는 것보다 많은 노력이 들어갔다. 안 보고 리눅스에 껍데기만 씌웠다 정도라고 말하기는 쉽지만, 실제 여기저기를 뜯어보면 티맥스에서 그런 말을 듣기에는 억울할 것 같을 정도로 많은 부분을 티맥스에서 자체적으로 만들었다. 물론 거짓 홍보를 남발하던 지난 역사가 있었기 때문에 티맥스OS와 관련된 모든 것을 의심하는 게 당연하고, 나 역시 계속 의심을 하면서 살펴봤지만 실체를 보면 티맥스 측에서 자체 개발했다고 발표했던 부분을 자체 개발한 것은 꽤 사실이었다.

티맥스OS에서는 리눅스의 DRM GBM을 이용해 버퍼를 전달하고 Mesa를 통해 EGL을 사용하는, 2D/3D 하드웨어 가속을 하는 자체 컴포지트 디스플레이 서버를 만들었다. 정확한 방식은 알 수 없었지만 Wayland 프로토콜을 사용하지도 않는다. 기존의 오픈소스 툴킷 라이브러리는 여기에 호환되지 않고 자체적인 GUI 툴킷도 들어 있다. GTK에서 Cairo를 사용하는 것처럼 2D 드로잉은 Skia 그래픽 라이브러리를 사용한다.

WINE의 껍데기 정도로 생각했던 윈도우 에뮬레이션 기능도 WINE 프로젝트의 결과물을 여기 저기에서 사용하기는 하지만, 커널 레벨에서 PE 바이너리를 디텍트하고 (여기까지는 리눅스의 binfmt 기능) 변환하는 것까지 하는 기묘한 자체적인 방법을 사용한다.

tnetd라는 자체 네트워크 관리 서버가 돌아간다. 지금은 리눅스 시스템에서 일반화되어 있는 NetworkManager는 사용하지 않는다.

크로미움에서 이름만 바꾼 브라우저로 생각했던 ToGate 브라우저도 위에서 말한 자체 GUI 덕분에 GTK 프론트엔드를 빼고 자체 GUI용 라이브러리를 붙여놨다.

정말 많은 노력을 기울였다는 사실은 인정해야 한다. 문제는 이렇게 실제로 노력을 한 것들이 무슨 의미가 있는지이다. 그냥 리눅스 데스크톱 쓰는 것과 비교해서 뭐가 더 낫길래 티맥스는 그 시간과 돈과 인력을 투입한 것일까?

자체 디스플레이 서버를 만드는 일이 아주 불가능한 일은 아니다. 우분투를 만든 캐노니컬도 Mir 디스플레이 서버를 만들었었으니까. 하지만 Mir가 망한 것처럼 하드웨어 벤더들의 지원을 받으면서 새로운 환경의 생태계를 만들기는 쉽지 않다. 티맥스 측에서는 “무거운 X 윈도우 시스템”을 대체한다고 어떤 언론 기사에서 밝혔지만, 이는 몇년 전에나 할 수 있는 이야기이다. 비슷한 목표를 가지고 비슷한 기술 스택으로 구성된 Wayland가 기본으로 탑재되는 배포판/데스크톱이 많아진 (Fedora 및 Debian) 지금 이 때에 이런 문제 제기는 유효하지 않다.

가상머신에서 똑같이 2D 가속을 위해 DRM 드라이버를 설치한 상태에서 아무리 봐도 GNOME+Wayland 환경보다 빠르거나 가볍다고 느껴지지 않았고, 파이어폭스와 그놈 터미널을 띄운 GNOME/Wayland 세션과 ToGate와 터미널을 띄운 티맥스OS 세션을 비교해 보면 티맥스OS 쪽이 1.4배나 더 많은 메모리를 사용했다. (ToGate는 크로미움이니까 파이어폭스보다 메모리를 차지하는 거야 어쩔 수 없다고 쳐도 software_center 프로세스가 브라우저만큼 많은 메모리를 차지하는 건 이상했다.) X11 호환성으로 Xvfb를 이용하고 있는데, 내가 아는 Xvfb라면 여기서 실행한 X 호환 프로그램은 Wayland의 Xwayland와는 다르게 하드웨어 가속 효과도 받지도 못한다. 소프트웨어 개발 측면에서 훌륭한 구조를 보여주는 것도 아니다. (지난 5월 유출된 티맥스OS 헤더 파일을 보고 GUI API가 저급하다고 평가한 트위터 글이 있었는데, 그것을 의식했는지 이번에는 개발용 헤더 파일도 깔끔하게 지워놨다.)

리눅스 WINE보다 잘 돌아가는 윈도우 프로그램은 카카오톡을 비롯한 테스트한 몇 개 밖에 없는 것 같다. 파일 구조는 XDG Base Directory Specification을 따르는 프로그램 덕분에 ~/.local 폴더도 들어 있었고, 일부 티맥스 앱은 XDG 표준의 ~/.config 폴더에 설정을 저장하기도 하지만, 윈도우 이름을 무비판적으로 따라한 티가 나는 자체적인 ~/AppData, ~/Favorite, ~/Local Settings, ~/.Recyclebin과 같은 폴더 구조도 동시에 있었다. 파일 관리자의 C 드라이브는 진짜 C 드라이브도 아니고 윈도우 에뮬레이션에 사용하는 듯한 /tos 폴더를 가리켰다. NetworkManager에서 VPN, 본딩, 브릿지 같은 다양한 기능들은 고사하고 티맥스OS에서 새로 만든 네트워크 설정은 IPv6 설정도 할 수 없는 20년 전 네트워크 설정 UI를 다시 시작하고 있다. 지금 2019년에 윈도우 글꼴과 비슷한 느낌의 커스텀 폰트를 사용하고 윈도우처럼 만들기만 하면 사람들이 윈도우처럼 쓸 것이라고 생각했을까?

행정용 PC면 이 정도면 충분하다는 의견이 있지만, 그런 이유라면 애초에 새로 만들 이유가 없었다. 데비안 기반 배포판에서 패키지를 잘 취사선택하고 이슈를 해결하고 브랜딩을 잘 씌우면 되고, 그렇게 하더라도 제품으로 사용할 정도가 되려면 많은 노력이 필요하다. 그런데 정작 풍부하게 들어 있던 데비안 10 buster의 패키지들은 티맥스OS의 APT 아카이브에는 올려놓지도 않았다. (그래서 VirtualBox guest OS 드라이버 패키지를 데비안 아카이브에서 따로 받아서 설치했다.)

티맥스는 리눅스 데스크톱을 보고 느낀 문제가 무엇이었길래 이러한 작업을 시작했을까? 대체 WINE에서 안 되는 무슨 문제를 해결하겠다고 PE 바이너리 처리에 커널 모듈까지 동원해야 했는지? Wayland compositor를 직접 만들려고 했어도 쉽게 만들 수 있는 충분한 오픈소스 재료가 있었음에도 왜 바닥부터 그래픽 서버를 만들어야 했는지? 기존 GUI 툴킷의 백엔드를 작성한다든가 하는 방법이 아니라 왜 GUI 툴킷도 자체적으로 만들어야 했는지? 어떤 근거로 티맥스가 앞으로 이 방향으로 더 나은 데스크톱을 만들 수 있다고 생각하는 것일까? 설령 미래에 미국이나 유럽이 대한민국에 대한 소프트웨어 수출 규제를 하더라도 리눅스를 못 쓰게 될 일은 없을 것인데, 멀쩡히 잘 돌아가고 앞으로도 못 쓰게 될 가능성이 없는 오픈소스의 대체품을 왜 다시 다른 기반 오픈소스를 이용해서 일개 기업이 만드는 국산 소프트웨어로 개발해야 하는 것일까? 아무리 봐도 이런 곳에 자원을 투자해서 달성할 수 있는 가치가 무엇인지 알 수 없다.

티맥스OS 회사 입장에서 내가 생각할 수 있는 다른 종류의 가치라면 수익 뿐일텐데, 공공 시장이 이런 방식으로 수익이 날 수 있는 시장이라면 안타까울 따름이다.

짧은 느낌: 방 안에 코끼리

Fri, 02 Aug 2019 15:00:00 +0000

Elephant in the room. 누구나 알고 있는 문제이지만 여기에 대해 말하기 꺼려하는 문제. 2020년 DebConf 개최지가 이스라엘 하이파로 결정되면서 잘 알려진 이스라엘 정부의 팔레스타인 탄압 정책이 있음에도 개최지로 적절한가에 대한 논란이 벌어졌고, 여기에 대한 의견을 청취하는 세션이 DebConf19 브라질 쿠리치바에서 있었다. 조용히 다녀오기로 마음먹었던 이번 DebConf19에서 가장 인상적인 세션이었다.

정부에 대한 정치적인 비판들이 공개되면 위험하거나 부적절할 수 있기 때문에 외부에 공개되지는 않았으나 여러가지 입장의 충분한 의견이 제시되었다. 토론 세션이니만큼 강당이 아니라 작은 강의실이 배정되었는데 자리가 모자라서 바닥에 앉고 뒤에 서 있는 사람들로 방은 미어터졌다. 문제를 피하지 않고 각각의 대립되는 의견을 경청하는 모습은 데비안이 지금까지 지속된 이유를 잘 보여준다고 생각한다.

문제에 대해 이야기하지 않는 것이 미덕이라고 생각하는 경우가 다수인 문화, 단지 시비를 걸기 위해 문제를 제기하거나 반대로 문제에 대해 이야기하는 걸 무작정 싸우자는 의도로 쉽게 받아들이는 환경에 젖어있던 내게 신선한 경험이 되었다.

티맥스오에스 살펴보기

Thu, 30 May 2019 15:00:00 +0000

(트위터에서 옮김.)

다른 분들의 @Realignist @perillamint @segfault87 티맥스오에스 설치기를 보고 알게 된 티맥스오에스의 apt 저장소에 들어 있는 패키지 내용을 내 전문성?을 발휘해 살펴 봤는데, ISO는 없고 온라인 패키지만 살펴본 것이니 한계는 있겠지만. 내용은 일반적인 커스텀 배포판과 다르지 않다.

단 티맥스 전용 소프트웨어는 패키지 목록에 없는 것으로 보아 설치 ISO에만 들어 있는 것 같고 패키지 흔적을 찾을 수 없었다. 패키지 내용은 데비안 10 buster에서 많은 패키지를 줄였다. 남아있는 패키지 목록을 봐도 의미없는 게 많은데 패키지를 뺀 이유는 알 수 없었다.

데비안 10/buster가 릴리스되지 않은 버전이 맞는데, 커스텀 배포판은 원래 이렇게 릴리스 예정 버전 갖고 만드는 게 맞다. 우분투도 그렇게 하고 있고. 2년 전의 데비안 9 썼다면 오히려 그게 바보짓이다. 데비안은 말이 unstable/testing이지 나부터 일상과 업무용으로 쓰고 있고 별다른 문제 없음.

티맥스가 바꾼 부분을 구체적으로 들어가면. 커스텀 배포판에서 당연히 바꾼다고 예상할 수 있는 부분이 있는데 fontconfig의 글꼴 설정, plymouth의 부팅 화면 브랜딩 이런 단골 메뉴를 바꿨다. 또 apt 저장소 키를 배포해야 되니 tmaxos-archive-keyring이라는 패키지를 당연히 추가.

또 배포판을 빌드할 때 꼭 필요한 debootstrap을 수정했는데 (패키지로 부팅 가능 시스템 빌드하는 SW), 버전 1.0.114 수정해서 1.0.114.1 이렇게 버전을 붙여놨다. ㅁㄴㅇㄹ 이렇게 하는 거 아닌데 본래 버전 혼동되게 하지 말고 우분투처럼 1.0.114tmaxos1 이런 식으로 해 주시면 안 될까요.

티맥스 전용 소프트웨어의 경로를 빌드 경로에 끼워넣는 패치는 여러 군데 들어 있다. 왜 유닉스 관습과 다르게 /system/{include,lib} 경로에 자기들 라이브러리를 설치해 놓고 x고생을 하는지 모를 일이다.

티맥스에서 새로 만든 패키지 중에 이상하게 libopenh264가 있는데, 시스코 OpenH264 코덱은 법적인 문제로 데비안에 안 들어 있고 debian-multimedia에만 들어 있다. 그냥 debian-multimedia에 있는 거 쓰면 되는데 있는지 몰라서 새로 만든 게 아닐까 의심.

또 하나 흥미로우면서도 비판할만한 부분은 사운드서버인 pulseaudio에 추가한 libpulse-mainloop-tos 패키지이다. 유일한 기능 패치라고 할 수 있는데 pulseaudio 코드를 이해해야 정확히 알 수 있겠지만 티맥스 전용 테스크톱과 사운드 입출력을 주고받는 기능을 pulseaudio에 추가한 것으로 보인다.

이 패치의 존재로 즉 티맥스오에스 데스크톱 앱 전용 사운드 API가 있다는 걸 유추할 수 있다. 공공시장의 이른바 “개방형OS”가 티맥스와 함께 언급될 때 우려할 수 있는 부분이 이런 부분이다. 티맥스와 같은 회사가 원하는 건 개방이 아니라 또 다른 락인이다.

이윤을 추구하는 기업으로서 이런 방향을 추구하겠다는 생각이면 그것만 가지고 나쁘다고 말할 수는 없으나, 한편으로는 OS의 MS 종속을 해소하겠다거나 개방성 높이자고 말하는 정책 사업에 티맥스 전용 API가 등장하는 건 모순적이다. 여기까지.