Changwoo Hacks

옮깁니다. migration은 차차 해 나갈 예정.

https://changwoo.xyz/

kakao 블로그 ”다음 맞춤법 검사기와 관련된 논란에 대해 설명드립니다.” 를 보고

컴퓨터를 사용한 맞춤법 검사 소프트웨어의 역사는 1970년 PDP-1까지 거슬러 올라간다. 맞춤법 검사 소프트웨어는 컴퓨터로 텍스트를 처리함과 동시에 시작된 엄청 오래된 소프트웨어라는 말이다.

hunspell용 한국어 맞춤법 사전을 처음 시작하면서 많은 사람들에게 접했던 반응은, "국문학 전공자가 필요한 것 아닌가", "한국어는 어렵지 않나?" 따위였다. 하지만, 쓸만한 수준의 맞춤법 검사를 만드는 일에 한국어나 자연어처리 학위가 필요한 것도 아니고, 한국어는 다른 언어의 하나일 뿐 더 어려운 다른 언어들에 비해 처리가 그리 어려운 언어도 아니다. 맞춤법 검사는 어렵지 않다. 단지 충분한 데이터를 축적하고 다듬는 데서 품질이 판가름이 날 뿐이다.

자작한 makefile의 문제점이 슬슬 짜증이 날 때 쯤 고쳐 쓰는 것도 한계이고, 오랜 세월이 지났지만 여전히 협업하는 사람들의 대부분은 내가 만든 makefile이 무엇을 하는지 이해하지 못한다는 점을 개선해야 겠다는 생각이 들어  생겨서 이번에 Scons를 사용해 보게 되었다.

Scons는 파이썬으로 작성되었고 파이썬으로 빌드 파일을 작성하게 되는 빌드 툴이다. 빌드 파일이 곧 파이썬 파일이 되므로 보통 선언적으로 작성되는 makefile보다 더 절차적인 기술을 할 수 있다. 일반 makefile에서도 (어떤 언어에서든지 복잡도를 n배로 높이는) eval을 사용하거나 하면 못 만드는 게 없지만 eval을 사용하기 시작하면 읽기와 쓰기 모두 어려움이 많은 게 사실이다.

그리고 생짜 make보다는 빌트인 기능들이 많이 들어 있다. 사실 make에서 C/C++ 코드를 제대로 빌드하는 makefile을 작성하는 것 조차 초심자에게는 쉽지 않다. GNU make 같은 경우 implicit rule이 몇 가지 들어 있지만 많이 부족하다. (.c 파일에서 같은 파일이름의 .o를 빌드하는 정도.)

어차피 없는 빌드 기능이야 직접 만들어야 겠지만, 만들어진 규칙의 재사용이 생짜 make보다는 더 쉽다. makefile을 공유하지 못할 거야 없지만, 매크로를 통해 사용해야 하는지 특정 변수를 사용해야 하는지 다른 makefile을 include해야 하는지 예제를 보거나 해당 makefile을 읽어보면서 익혀야 한다. Scons에서는 이름과 인자 순서만 정하면 된다.

파이썬을 사용한다는 점은 비슷하게 빌드 툴의 대안이 될 수 있는 cmake에 비해서도 좋다. 독자적인 문법보다는 파이썬 문법이 장벽이 낮고, 또 여러가지 파이썬 라이브러리 기능을 사용할 수 있다는 점도 좋은 점이다.

http://producingoss.com/

알만한 사람들에게는 책의 내용이 너무 뻔한 얘기이기 때문에 읽어볼 필요를 느껴보지 못할 것이다,

내가 맨 처음 했던 패치가 Texinfo 포맷으로 된 한글 문서를 처리하는 방법이었으니, 자연스럽게 내가 개조한 Texinfo-ko를 이용해 몇 가지 GNU 매뉴얼을 한국어로 번역했었다. Automake, Gettext, Make 매뉴얼은 전체를 번역했었고, Texinfo 매뉴얼도 절반 가량 번역했었다. (아직도 automake와 make 매뉴얼은 검색하면 종종 보이는데, 10년이 넘은 구버전이니 웬만하면 안 봤으면 좋겠다.)

2000년 즈음에 한국에 GNU Korea가 설립되고 자연스럽게 그 안에서 GNU 매뉴얼 번역을 조율하려고 할 때 나는 기쁘게 협업할 생각이었다. 하지만 GNU Korea의 담당자들은 현실성이 떨어지는 번역 절차를 내세웠다. 번역은 담당자를 특정해서 초벌 번역을 하고, 검수를 거친 다음에 공개한다는 현실성이 없는 절차를 내세웠고 덕분에 이전에 내가 공개했던 매뉴얼 번역들이 (전체가 번역된 문서까지) 감춰졌다. (게다가 새로운 참여자들은 문서의 원본 포맷인 Texinfo 형식이 익숙하지 않다는 이유로 HTML 위에서 문서를 번역하는 바람에 중복 작업이 계속 생겨났다.)

결국 나는 그 체계 안에서 작업하기는 힘들겠다고 메일링 리스트에 알린 다음 작업을 계속했었다. (그 이후에는 나 스스로 흥미를 잃었지만.) 결과적으로 보면 그런 식의 초벌 번역과 검수 절차를 통해 완성된 매뉴얼 번역은 몇 페이지가 되지 않는 짧은 문서 밖에 없었다. 당시에는 그것이 바로 1997년 에릭레이몬드의 "성당과 시장" 문서에 등장하는 성당식 프로젝트의 문제점이라고 느꼈었다. (지금은 http://korea.gnu.org/manual/ 페이지에 당시 작업 내용이 남아 있을 뿐 추가 번역 작업은 진행되지 않는다.)

"한글이 입력이 안 된다. 짜증난다. 뭔가 다 뒤엎고 새로운 배포판이 나왔으면 좋겠다."

리눅스 사용자들도 "한글" 리눅스 배포판을 만들면 좋겠다는 생각을 하기도 하고 이런 점은 이해가 간다. 릴리스된 리눅스 배포판의 여러가지 버그를 해결하는 게 힘들기 때문에, 이런 점을 긁어줄 수 있는 로컬라이즈된 배포판을 만들면 뭔가 굉장히 좋을 것만 같다. 로컬 배포판을 개발하려는 입장에서도 별로 어려운 작업은 아닐 것 같고 실제로 별로 어렵지 않다.

다른 배포판에 기반한 커스텀 배포판은 나쁜 것이 아니다. 특히 데비안과 데비안 기반 배포판에서 커스텀 배포판을 만드는 게 어려운 일이 아니고 여러가지 툴이 준비되어 있다.

하지만 지금까지 한국어 로컬 배포판들의 수명이 길지 않았던 이유는, 배포판이 오래 사용되기를 바라면서도 단기적인 목표를 세웠기 때문이라고 생각한다. "릴리스된 레드햇 또는 우분투에 한글 입출력 버그를 바로잡자, 번역을 채워 넣자, 예쁜 데스크톱 배경과 테마를 띄우자, 마음에 드는 애플리케이션을 포함해 보자..." 이러한 개발 주제는 비교적 간단하고 명확한 만큼, 수명이 길지 않다. 이런 개발을 진행하다가 몇달의 시간이 흐르면 결국 대망의 릴리스를 달성해 낸다. 그런데 문제는 그 때 쯤에는 6개월에서 1년의 시간이 흐르고, 베이스로 사용했던 배포판이 다음번 또는 다음 다음번 릴리스가 나온다는 점이다.

배포판을 개발하는 입장에서는 새로 릴리스된 베이스 배포판에서 예전에 패치했던 이슈가 이미 해결되어 있는 대신, 또 다른 종류의 이슈가 생긴다. 그럼 다시 처음부터 버그 수정 작업을 계속 한다.

사용자 입장에서도 (특히 데스크톱 사용자의 경우) 로컬 배포판과 원본 배포판 사이에 저울질을 하면, 시간이 갈 수록 과거 버전의 소프트웨어가 들어 있는 로컬 배포판을 사용할 이유가 줄어든다. 전체 배포판의 발전에 비하면 로컬 배포판이 수정한 부분은 아주 작은 부분이기 때문이다.

로컬 배포판이 이 차이를 최소화하는 한 가지 방법은 민트리눅스가 사용하는 전략을 따라 하는 것이다. 민트리눅스는 매번 우분투 개발버전을 기반으로 개발을 진행하다가 우분투가 릴리스되고 한 두달 내에 추가 작업을 마치고 민트 버전을 릴리스한다. 이런 식으로 로컬 배포판을 빠르고 꾸준하게 만들어낼 수 있다면 가치를 인정받을 수 있을 것이다. 하지만 지금까지  한국의 로컬 배포판이 그랬던 것처럼, 간단하고 명확한 패치를 적용하는 것만으로 배포판을 개발하려는 로컬 배포판에서는 이렇게 로컬 배포판을 훌륭하게 개발할 수 없을 것이다. 소프트웨어 개발자와 사용자에 대한 개방된 커뮤니케이션을 꾸준히 했을 때 가능한 일이다.

최근 레노보 노트북에  "수퍼피쉬"라는 애드웨어가 깔려 판매되었다는 소식이 들렸다. 이 녀석은 사용자한테 어떻게든 광고를 보여주기 위해 브라우저의 네트워크 스택의 일부를 자체 구현으로 대체하는 식으로 동작해 SSL 웹페이지까지 광고를 띄우고야 만다. 모르긴 해도 아마 이 애드웨어를 탑재한 당사자는 아무런 문제의식을 느끼지 못했을 것이다. 광고 수익을 통해 이익을 증대하는 건 그 세계에서 자연스러운 수익 모델의 하나라고 생각했을 것이다.

오늘날 윈도우를 사용하는 일은 피곤하기 짝이 없다. 악성 코드까지는 아니더라도 수많은 소프트웨어는 사용자의 의사에 반하는 일을 너무 많이 하고, 그게 그 소프트웨어 제작사의 수익 모델이 된다. 무료의 경우에는 그 정도가 심하다. 모든 소프트웨어가 내 인터넷 트래픽과 개인 정보를 노린다. 넘쳐나는 툴바 소프트웨어는 실행할 때마다 물어보면서 내 브라우저의 주소창과 기본 검색 설정을 노린다.  윈도우용 무료 소프트웨어가 유명세를 탄 다음에 기업에 인수되고, 그 다음에 광고와 끼워팔기로 떡칠이 되어 한껏 돈을 끌어 모은 다음 사용자의 외면 끝에 사라지는 시나리오는 쉽게 볼 수 있다. 이 세계의 소프트웨어는 사용자와 낚느냐 낚이느냐 씨름을 벌인다.

가끔 윈도우를 쓰게 될 때마다 드는 생각이지만, 이 바닥에서 어뷰징은 해가 갈 수록 그 정도가 심해지고 이제는 참을 수 있는 한계를 넘어섰다. 게다가 어뷰징이 다른 플랫폼에까지 전염되고 있다. 오픈마켓에서는 제휴 광고에서 쿠폰을 준다고 낚시질을 하면서 보험 가입을 유도한다. 안드로이드 휴대폰에서는 시덥지 않은 이유로 기기 정보를 수집하고 특정 백신 앱을 설치하도록 강제한다.

과거 포스팅에서도 언급했지만, 이제 파일시스템에서 /usr를 별도 파티션으로 분리하는 일은 의미가 없어졌다. 저장 장치의 가격이 낮아졌고 실제로 많은 소프트웨어가 이런 부분을 고려하지 않고 있다.

게다가 최근 리눅스 시스템에서는 /usr가 아니라 /lib 따위의 루트 파티션에 들어가야 할 소프트웨어가 너무 커졌기 때문에 더 이상 부팅에 필요한 파티션을 최소로 유지하기가 힘들어졌다. 이제 대부분 커널을 직접 빌드하지 않기 때문에 사용하지 않는 커널 드라이버나 펌웨어 이미지가 잔뜩 들어 있게 되었고, udev, systemd와 같은 덩치 큰 소프트웨어들이 부팅 과정에서 동작하게 되었다. /usr 파티션을 구분해서 동작하도록 소프트웨어를 관리하기도 어려운 일이지만, 그렇게 철저하게 분리해서 얻는 이득도 알 수 없다. 이제 아무도 /usr를 공유하지 않기 때문이다.

최근 NIPA 과제를 통해 탄생한 하모니카 배포판은 LinuxMint 배포판의 버전 17 MATE 버전에 Numix 테마를 기본으로 입히고 여러가지를 수정한 버전이라고 할 수 있다. 주목할 부분은 데스크톱 환경으로 MATE 를 사용한 것인데, 그리 좋은 선택으로 보이지 않는다.

하모니카 측은 리눅스 사용 경험이 없는 여러 사람의 사용 테스트를 통해 윈도우와 비슷한 MATE를 선택했다고 밝히고 있지만, 내가 사용해 본 경험으로는 의문이 생기는 부분이다. (차라리 KDE가 더 윈도우와 비슷하다.) 어차피 윈도우 데스크톱과는 다른 부분이 마찬가지로 많고 모든 걸 똑같이 만들 수는 없는 노릇인데, 어떤 데스크톱을 선택하든 사용자 교육과 지원을 통해 해결할 문제이고 다르지 않다고 보인다.

MATE는 마테라고 발음하고 스페인어로 마테차를 가리킨다. (주요 애플리케이션의 이름도 스페인어로 되어 있다.) MATE는 그놈 데스크톱이 버전 2.x에서 3.0으로 넘어가면서 급격한 UI 변화에 반발한 개발자들이 만든 그놈2의 파생(fork) 프로젝트이다.

리눅스에서는 데스크톱을 선택할 여지가 있고, 개인이 리눅스에서 어떤 데스크톱을 사용할지는 개인의 취향 문제라고 할 수 있다. 현대적인 데스크톱에 들어 있는 여러가지의 기능 중에는 개개인에 따라서는 별로 중요한 게 아닐 수도 있다. 예를 들어 몸이 불편한 사람들을 위한 접근성과 같은 기능은 XFCE나 LXDE와 같은 경량 데스크톱에서는 전혀 고려를 안 했다고 볼 수 있지만 사용하는데 별 문제가 없는 사람이라면 생각할 필요가 없다. MATE의 경우에도 그놈 3.x 버전의 데스크톱이 불편하고 그놈2 방식이 좋아서 선택할 수도 있다.

이렇게 취향은 존중하지만, 행정용 OS를 목표로 하는 배포판에서 정책으로 무엇을 선택할 것인가의 문제가 된다면 지금 시점에서 그놈이나 KDE를 놔두고 MATE를 선택할 이유가 없어 보인다. 기술적인 이유는 아니지만 MATE의 사용자/개발자 수가 상대적으로 훨씬 적다는 점이 (그리고 앞으로도 달라질 것 같지 않다는 점이) 문제이다. 그놈, KDE, MATE의 프로젝트 규모 차이와 발전 추세는 OpenHub의 데이터만 봐도 명백하다.

https://www.openhub.net/p/gnome

https://www.openhub.net/p/kde

https://www.openhub.net/p/mate

절대적인 숫자도 MATE가 그놈/KDE의 10분의 1 정도이고 성장하는 추세도 더디다. 쓰기 좋으면 되지 왜 문제가 되느냐고 생각할 수도 있지만, 오픈소스 프로젝트에서 여기에 작업하고 있는 개발자가 얼마나 되고 사용자 규모가 얼마나 되느냐는 무시할 수 없는 문제이다. 행정용으로 적용된다고 하면 일부만 사용된다고 해도 그 숫자가 수만 수십만을 넘어가게 되는 큰 규모가 되는데 이를 받쳐줄 개발자와 사용자 커뮤니티의 규모와 건전성이 가장 중요하게  고려되어야 한다.

GPLv2 and Its Infringement by Xiaomi

중국의 수많은 유명 제조사가 GPL을 위반했고 그러고 있기에 샤오미라고 해서 특별히 놀랍지는 않지만, 1년이 넘게 끌어오면서 "다음 모델의 수정 사항이 들어 있어서 공개 못하겠다"는 핑계를 뻔뻔하게 대는 건 새롭다.

... ‘한국형 리눅스’ 프로젝트라는 가소로운 발상은, 지레 주눅이 들어 자기 자신을 주변세력(periphery)으로 자진해서 미리 규정하고, 세계의 주류에는 감히 가까이 갈 엄두도 못내는 열등감의 표현이다. ...

김기창, 토종 OS라고요? (2011) 중에서

이렇게까지는 생각하지 않지만, 오늘날 배포판에 "한글"이라는 걸 테마로 특별한 커스터마이즈가 들어가야 할 이유는 별로 찾아보지 못하겠다.

지금이 아니라 10여년 전에 debian-installer가 처음 만들어질 때부터 데비안과 거기에서 파생된 배포판에는 한글 폰트와 한글 입력기가 들어 있고, 한국어로 설치 화면이 나오고, 설치할 때 언어 선택에 따라 적절한 패키지가 설치되고 기본 설정이 된다. 언어를 선택하는 것조차 마음에 들지 않는다면 debian-installer/locale이라는 preseed 값을 설정하는 간단한 커스터마이즈 만으로 한글 배포판 제작은 끝난다. 레드햇 등 다른 배포판도 크게 다르지 않다.

부족한 점이 있다면 꾸준한 번역과 테스트가 부족할 뿐이지, 외국에서 만든 거라 한글이 원래 안 된다거나 외국 사람이라서 안 넣어준다거나 하는 건 요즘 분위기가 아니다.

과거에 OEM 고객으로부터 받은 황당한 요청 중에는 "버전 번호를 2.1로 해 달라"는 요청이 있었다. 왜냐하면 버전 2는 돼야 오래 검증된 제품처럼 보이고 그렇다고 2.0은 불안해 보이니까 2.1로 하자는 것이었다. 당시 사용하던 실제 버전은 1.x였던 것으로 기억하는데, 결국 겉으로 보이는 문구만 2.1로 바꿨다.

자바 8의 버전이 사실 버전 1.8이라는 건 잘 알려져 있다. 윈도우 7의 버전은 6.1이고, 윈도우 8은 6.2이고, 윈도우 8.1은 6.3이다. 모 증권사에서 사용하는 HTS 프로그램은 매번 그 다음 해 연도를 버전 넘버로 쓴다. 2013년에는 "XXXX 2014", 2014년에는 "XXXX 2015"와 같이 말이다. (미래지향적인 느낌이 들도록?)

이미 버전 번호는 마케팅 수단이 되어 버렸다. 이걸 현실로 인정한다면 윈도우나 자바 버전처럼 마케팅용 버전과 실제 버전을 분리해야 하겠지만, 오픈소스 개발에서 이런 버전 번호 마케팅을 하기는 쉽지 않은 일이다. 보통 개발하고 있는 버전이 무엇인지는 알려져 있으니까 뜬금없이 버전 1.2를 버전 2라고 광고하기는 힘든 노릇이다

최근 NIPA 과제로 진행됐던 하모니카 배포판은 사용자가 번역에 참여하면 바로 패키지가 빌드되고 바로 사용할 수 있는 점을 내세우고 있다.

메시지 번역을 오래 해 온 입장에서 봤을 때 어려운 얘기이다. 오픈소스 번역에 온라인 시스템을 사용한 건 아주 오래 됐지만 그게 반드시 활발한 참여와 훌륭한 번역으로 연결되는 게 아니라는 것도 오래전부터 알려져 있다. 훌륭한 온라인 시스템이 PO 파일 편집의 부담도 줄였고, 메일을 보내고 하는 비기술적인 장벽도 낮췄다고 할 수 있지만 여전히 자발적인 참여자는 소수이고 사용자와의 간격이 있다. 매번 새로운 온라인 번역 시스템을 만드는 사람들은 대부분이 번역 활성화 희망을 갖고 있었던 것 같지만, 지금까지 보면 활발한 번역과 적절한 품질은 온라인 시스템에서 나오지 않고 참여자들의 노력과 커뮤니케이션을 통해서 나온다. 적절한 간격의 업데이트는 필요하지만 하루이틀 사이에 사용해 볼 수 있게 하는 건, 별로 도움이 되지 않는다.

'전자문서 산업을 위한 학술 토론회' 관련 기사: http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140725153903 OOXML은 ISO/IEC 29500 표준으로 MS 오피스의 포맷이고 (docx, pptx 등), OWPML은 KS X 6101 표준으로 한컴오피스2014부터 hwpx라는 이름으로 (아직은 시험적인) 포함된 포맷이다. 이 학술 토론회에서는 업체 사람들이 서로 자기 업체의 포맷을 가지고 자기 포맷이 더 개방적이고 표준으로 바람직한 공공문서 포맷이라고 주장하고 있으나, 사실 OOXML이든 OWPML이든 공공 문서 포맷이 되기에는 마찬가지 문제를 가지고 있다.

OOXML

OOXML의 문제는 이미 과거 표준화 과정에서부터 충분히 알려진 바 있다. 마이크로소프트 측은 6000 페이지의 문서로 구성된 표준을 급행으로 검토할 시간도 주어지지 않은 채 진행하면서, 그 전에 기존에 표준 결정 기구에 가입하지 않은 개발도상국가에 입회비를 지원한 스캔들이 있었다. 이들 개발도상국가가 표준안에 찬성표를 던진 것은 물론이다. (대한민국은 최종적으로 반대에 투표했다.) http://www.zdnet.co.kr/column/column_view.asp?artice_id=00000039161482 기술적으로도 알려진 것만 해도 그렇다. OOXML은 기존의 바이너리 오피스 포맷을 가지고 XML을 컨테이너로 이용한 것 뿐이다. 이러면 XML 파서로 읽을 수 있을 뿐 기존 오피스 포맷과 다를 게 없다. 대표적인 예로 드는 useWord97LineBreaks attribute는 "Word97방식으로 렌더링하라"라고 지정되어 있고 그 Word97 방식이 무엇인지 설명하지 않는다. http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx

OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다. XML 은 새 문서 형식을 정의하는 강력하고 풍부한 도구지만, 프로젝트 범위를 잘못 정하는 실수까지 무마해 주는 만병통치약은 아니다. '참고할 문서가 없는 대형 독점 렌더링 라이브러리를 사용한다'는 플래그를 문서 형식에 넣는다면, 플래그를 문서 없는 이진 문자열 내 비트 하나로 명세하든 세 쪽짜리 <>으로 명세하든 상관이 없다. 이 명세는 어디까지나 독점이며, 단순히 XML로 감싸는 방법만으로는 렌더링이 불가능하다.

IBM Developer Works, "OOXML 무엇이 그리 대단한가 " 중에서, http://moonistar.tistory.com/m/post/16

OWPML

이 글을 쓰기 시작한 이유가 바로 이 포맷 때문이다. 올해 초에 직접 KS X 6101 표준 문서를 구입해서 한컴오피스 2014 체험판의 HWPX 결과물과 같이 검토해 봤기 때문이다. 바이너리 MS 오피스 포맷을 XML로 옮긴 게 OOXML이라면, 바이너리 HWP 포맷을 XML로 옮긴 게 바로 OWPML이다. 이것 뿐이다. XML의 파일 하나하나는 HWP에 있던 Compound Document의 스트림 하나하나에 대응하고, XML 태그 하나하나는 HWP에 있던 레코드 정보에 대응하고, XML 속성(attribute)은 레코드의 바이너리 데이터에 해당한다. IP over XML 같은 만우절 장난이라면 몰라도, 이런 포맷을 만드는 게 무슨 의미가 있는 걸까? KS X 6101 역시 OOXML 포맷과 같은 오류를 저지르고 있다. 무엇무엇이 있다라는 설명만 하고 실제 어떻게 구현되는지 제대로 설명하지 않아 사실상 한글과컴퓨터의 구현만이 알 수 있게 되어 있다. 예를 들어 표준 7.1에 보면 XMLTemplate/ 이라는 폴더에 대해 언급했으면서 표준 문서 다른 어디에도 여기에 대한 설명이 없다. 또 한 가지 예를 들면 표준 문서 "8.2.4 호환성 정보"를 보면 "compatibleDocument" 태그가 있다.

...

이런 식으로 쓰면 붙이면 MS-Word 방식으로 렌더링한다. 앞의 OOXML에 있던 useWord97LineBreaks 속성이 생각나는 부분이다. 이 MS-Word 방식이 무엇인지는 알 길이 없다. 원래 HWP 포맷에도 마찬가지의 호환성 문서 정보가 있는데 이 정보까지 OWPML에 그대로 구현해 놓은 것이다. 한컴오피스에서 MS-Word 문서가 상당히 잘 변환되는 비밀이 여기 있다. HWP 포맷에 MS-Word 호환 모드가 있고 한컴오피스에 MS-Word와 비슷한 렌더링 방식을 구현해 놓은 것이다. 이런 것까지 표준에 포함하면 표준 구현은 한컴오피스가 한 것처럼 MS-Word 렌더링 방식까지 따라해야 한단 말인가? 이런 문제점을 지적해야 할 표준 심의 과정도 문제였다. KS X 6101:2011 문서의 해설에 기록되어 있는 표준 제정 과정의 7가지 심의 의견 중에서 문제를 지적한 의견이 6가지인데, (1) 표준 제목 수정 (2) 오타 수정 (3) HWP 약자 설명 추가 (4) ODF, OOXML 상호운용성 추가 (5) ODF, OOXML 인용 추가 (6) 수식, 화학식 누락. 이 중에서 (1)(2)(3)(5)은 단순 수정이고, (4)는 이 표준에서 해당하지 않는다고 조치했고, (6)에서 수식이 추가 된 게 그나마 유일하게 의미 있는 문제점 수정 사항이었다. 한글과컴퓨터에서도 최근 한컴오피스2014에서 처음 구현했으니 검증될 기회도 없었다. OOXML과 마찬가지로 똑같은 포맷을 XML로 감싼다고 해서 구현할 수 있는 건 아니다. 검토했던 결과를 다음 페이지에 기록해 놓았다. https://docs.google.com/spreadsheet/ccc?key=0AjxIVzS0OjQTdEc5V1dhLWJwenhSTEpPWGNMdy12NUE&usp=sharing 기록한 것과 같이 OWPML은 표준에도 오류가 있는데, 이 포맷을 최초로 구현한 한컴오피스 2014의 HWPX 포맷에서도 표준에 없거나 표준과 다르게 사용하고 있다.

ODF 뿐이다

아무리 OOXML과 OWPML이 표준으로 인정받았더라도, 의도적이든 아니든 사실상 특정 업체 독점적이 될 수밖에 없도록 기술된 포맷은 공공문서의 포맷이 되면 안 된다. 현재 나와 있는 해법은 ODF 뿐이다. ODF는 다들 좋아하는 그 표준을 국제/국내 모두 오래전에 획득했다. 물론 같은 학술 대회에서 다음과 같이 한컴 측이 주장한 것과 같이 ODF도 구현별로 차이가 나는 것도 사실이다.

또 국제표준이 만능이 아니라고 반박했다. 그는 “MS 오피스도 환경에 따라 레이아웃이 깨지는 경우가 많고, ODF도 오픈오피스, 심포니, MS 오피스 등 구현회사마다 조금씩 차이가 있다”고 말했다.

http://www.ddaily.co.kr/news/article.html?no=120789

최근의 오픈프론티어 오픈소스 라이선스 세미나에서 발표했던 사례, http://www.slideshare.net/changwoo/20140715-37005257 예외적인 케이스에 대한 이야기는 보통 재미있다. 지금까지 갖고 있던 생각이 고정관념이 아니었나 한번 쯤 가다듬는 기회가 되기 때문일 것이다. 재미있는 케이스를 찾다 보면 지나치게 예외적인 이야기에 치중할 수도 있는데, 이 경우는 한번 OSI-approved 라이선스의 예외적인 경우를 지적해 보고 싶었다. 예로 들었던 예외는 NASA Open Source Agreement(NOSA)라는 라이선스이다. NASA(미항공우주국)는 유일무이한 일을 하는 기관이니만큼 다른 곳에서 보기 힘든 상당히 흥미로운 소프트웨어를 공개하고 있다. http://ti.arc.nasa.gov/opensource/ 여기 사용되는 라이선스가 이 NOSA 라이선스이다. 예외로 들었던 이유는 이 라이선스는 OSI approved 라이선스이지만, FSF나 데비안은 거절했기 때문이다. http://www.gnu.org/licenses/license-list.html#NASA 문제되는 조항은 이 부분인데

G. Each Contributor represents that that its Modification is believed to be Contributor's original creation and does not violate any existing agreements, regulations, statutes or rules, and further that Contributor has sufficient rights to grant the rights conveyed by this Agreement.

Bad Voltage 팟캐스트 1x19 에피소드 중에서 freecode(freshmeat)와 관련된 얘기, http://www.badvoltage.org/2014/06/26/1x19/ (33:20부터) 리눅스 배포판 개발과 사용에 있어서 생각할 만한 게 많은 것 같아서 해당 부분을 대략 번역한다.

며칠 전에 freecode, 과거에 freshmeat였던 사이트가 고정 웹사이트로 변했어요. 여러분이 옛날 freshmeat을 얼마나 쓰셨는지 모르겠지만, 제 생각에는 엄청나게 유명했던 곳이었어요. (모두 공감) 그런 점에서 몇 가지 의문이 드는데요. 진짜 이유가 무엇이라고 생각하시나요? 오늘날 리눅스 소프트웨어에 무슨 일이 일어난 걸까요? 앱스토어같은 것 때문일까요, 그냥 패키지가 잘 동작하기 (just work) 때문일까요. 무슨 일 때문에 이렇게 된 것일까요. 그건 이제 아무도 GIMP 0.1 alpha를 다운로드하지 않기 때문이죠. (모두 웃음) 한 가지 지적할 점은 그 당시는 다른 어떤 사이트보다도 freshmeat이 소프트웨어의 최신 내용을 담고 있었어요. 심지어 메인테이너들이 자기 홈페이지보다 더 freshmeat에 먼저 발표하곤 했죠. 네 그 점이 핵심이예요. 그 당시에는 신선(fresh)한 내용이었죠. 그런데 이제는 신선한 내용이 아니니까 아무도 신경쓰지 않게 됐죠. 그냥 고기(meat)죠. (웃음) <모두> 네 오래된 고기(old meat)예요. 네 바로 그 부분이에요. 재미있는 부분이 Jeremy가 말한 그대로예요. 10-15년 전에는 모든 소프트웨어 메인테이너들이 freshmeat를 썼어요. freshmeat이 유일한 수단이었죠. 하지만 더 이상 아니에요? 왜일까요? 제 생각에 큰 부분은, 당시에는 패키지 관리는 새로운 개념이었어요. RPM 패키지 관리는 얼마 안 됐고 데비안은 패키지 관리가 당시에도 있었지만 데비안을 모두가 쓰지는 않았죠. 그래서 기준이 freshmeat로 가서 tarball을 다운로드한 다음에 빌드하는 거였어요. "./configure; make; make install"하는 거죠. 또, 제가 기억하기에는 freshmeat에 등재되는 게 일종의 훈장 같이 취급됐어요. "우와 freshmeat에 올라간 소프트웨어라니 멋지다"라고요. ("맞아요 맞아") 그런데 그 일부분을 배포판들이 대체했어요. 또 소프트웨어를 직접 다운로드해서 설치하는 방식은 사용하지 않죠. 폰이나 데스크톱에서도 더 이상 그렇게 하지 않아요. 또 한 가지 제 느낌에는, freshmeat을 소유한 회사에 대해서 잘은 모르지만 sourceforge도 인수했죠? 제 생각에 이건 리소스 낭비였어요. 이제 아무도 freshmeat을 신경쓰지 않아요. 저는 이게 리눅스만의 이슈가 아니라고 생각해요. 당시에는 맥의 경우에도 versiontracker라는 기본적으로 freshmeat과 똑같은 일을 하는 사이트가 있었어요. 당시에도 거기 가면 각종 업데이트된 정보가 들어 있었죠. 모든 맥 유저가 그 사이트를 봤어요. 윈도우 사이트도 마찬가지로 있었고요. 하지만 지금은 비슷한 일을 하는 오만가지 경쟁자들이 나타났고 중앙 집중적인 한 사이트가 이제 없어요. 어떤 사이트를 가도 최신 업데이트된 내용을 담고 있다고 확신할 수 없게 됐죠. 그러니 아무 것도 사용하지 않게 된 거고요. (...)

네 같은 비극이 일어난 것 같네요. freshmeat 1개 사이트만 있을 때는 이 사이트에 모두 있는데,  누군가 "야 freshmeat같은 사이트를 만들면 돈을 벌 것 같아" 하면서 사이트가 2개 3개가 되면서 모든 사이트의 가치가 제로가 되고 더 이상 이용하지 않게 되는 거죠. 일반적으로는 동의해요. 다른 얘기를 하면 이제 데비안 패키지 저장소도 있고, 우분투도 있고 페도라도 있어요. freshmeat은 상당히 리눅스에 치우쳐져 있잖아요? 당시에는 크로스 플랫폼 이었어요. 모든 소프트웨어가 어떤 배포판에도 돌아갔죠. 직접 컴파일하니까요. 정확히 말해서 크로스 리눅스겠죠? 아 미안해요. 네 크로스-리눅스배포판이죠. 그런데 점점 자기 소프트웨어를 데비안, 우분투 또는 페도라에서 컴파일하겠다라고 말하고 다른 배포판은 신경쓰지 않겠다라고 말하는 게 허용되는 분위기예요. 거기에 대해서 일부 이유를 말하면, 우분투와 페도라가 상당히 달라요. 당시에는 예를 들어 슬랙웨어와 데비안은 별로 다르지 않았어요. 각종 설정 옵션이 다르기도 하고 네트워크 파일 방식이 다르고 그런건 있지만 기본적으로 어떤 배포판을 쓰든 같은 사용자 경험을 공유했죠. 분화되지도 않았는데, 이유 중 하나는 당시에는 달라져야 한다는 요구 사항이 별로 없었어요. 그럴 시간도 없고요. Jono의 의견에 동의해요. freshmeat은 "configure; make; make install"시대의 산물이죠. 한 가지 더 문제를 말씀드리면 제가 과거에 freshmeat 이용을 중지한 건 사이트를 개편하면서 부터에요. 사이트의 대부분의 기능을 없애 버렸죠. 당시에 제가 이용했던 건 trove 였는데.. trove는 잘 관리되고 있고, 예를 들어 파이썬으로 작성된 BSD 라이선스의 메일 클라이언트를 찾는 건 trove 계층에서 쉽게 찾을 수 있었어요. 그런데 freshmeat 사이트가 개편되면서 그 데이터를 통째로 잃어버렸죠. 그리면서 소프트웨어 센터, 패키지 관리 따위가 쓸만한 수준으로 좋아졌고요. 어쨌든 사이트를 개편한 게 큰 역할을 했어요. 네 옛날에 "fm"이라는 freshmeat의 trove를 이용해 검색하고 결과를 출력하는 프로그램을 작성했던 기억이 있네요. 사이트가 개편되면서 동작을 안 했고요. 사이트 관리가 문제였던 것도 맞아요. 그리고 주인이 많이 바뀌었어요. 기억이 가물가물한데 slashdot과 합병했죠? ("네") 그리고 ("geeknet으로 갔다가, 그 다음엔 다시 sourceforge랑 합병하고.,."). 하고 싶은 말은 사이트의 자산이 회사를 거쳐가면서 이익이 되는 slashdot과 geeknet에 자원이 집중됐을거예요.

(...) 개인적으로 이제 저는 소프트웨어를 컴파일하는데 신경 쓰지 않아요. 여러분이 KDE에 기여하는 사람이라면 아마 KDE 컴파일에 신경 쓰겠지만 파이어폭스나 커널을 빌드하지는 않을 거예요. 제 생각에 freshmeat이 이제는 의미가 없더라도, 고정 페이지로 남겨두고 최소한 과거 컨텐츠를 볼 수 있다는 건 괜찮은 것 같아요. 실제로 ESR이 다른 이름으로 freshmeat을 되살리려고 하는 거 알아요? 진짜요? VA의 이사회 멤버라서 slashdot과 freshmeat을 인수하라고 설득한다는데요. 그래서 사이트를 다시 시작한다고요. ESR이 말하는 건 사람들이 다운로드하지 않는다고 해도, 패키징하는 사람은 패키징할 걸 어디서 찾아야 하지 않느냐는 거예요. 음, 사실 중요한 부분이긴 해요. 알게 뭐예요. ESR이 그러고 싶다는데. 하하. 제가 배포판 작업을 하면서 한 가지 배운 게 있는데요. 배포판에서는, 항상 패키징할 게 있어요. 아이고 ESR이 말하려고 하는 건 잘 알겠어요. ESR이 당시에는 유명한 사람이었고요. 그 당시의 방식을 좋아할 수도 있죠. 근데 지금 15년 전 웹사이트를 살리려고 하고 있어요. 오래 된 건 그냥 넘어가지. 이봐요. 저는 아직도 BBS를 돌리고 있어요. 오래된 건 멋져. (웃음)

2014년 3월 25일 기사: 정부, 공개 SW기반 한국형 OS 개발 나선다 과거에도 부요의 문제점에 대해 언급했었지만 ([1] [2]) 간단히 평하면,

탈 윈도우나 오픈소스 기반 OS 사용이라는 기본적인 방향 자체는 환영할 만한 일이라고 생각한다. 하지만 과거에 실패했던 일들을 되새길 필요가 있다. 

과거 부요의 개발과 배포 방식을 왜곡시킨 장본인이었던 ETRI 주도의 절차는 배제해야 한다. "기술이전"을 통해 수익을 올려야 하는 ETRI의 폐쇄적인 개발 모델은 동작하는 오픈소스 개발 방식이 아니다. 이미 부요는 10년전 실패한 역사이다. 활용할 가치가 있는 것도 남아있지 않을 뿐더러, 오히려 과거의 방식 때문에 왜곡될 가능성이 높다. 부디 바닥부터 시작한다는 마음으로 시작해야 한다.

(업데이트) 구체적으로 당시 ETRI 부요 배포판의 문제는 업체 입장에서 일단 실속도 없으면서 굉장히 조건이 까다로웠다는 점이다. 마지막 부요 3.0의 경우가 이런 식이었다. 약 5년전 중소기업 기준 1억7500만원의 착수금과 매출 2.7%의 런타임 로열티가 사업자의 입장에서는 그렇게 비싼 건 아닐 수도 있지만, 배포판 커스터마이즈 정도와 (분쟁이 일어난다면 실효성이 있는지 논란의 여지가 굉장히 많은) 소프트웨어 특허 몇개가 그만한 가치를 할까? (미안한 얘기지만 부요 기반으로 배포판을 만들었던 회사는 "표준리눅스"라는 겉포장에 넘어간 호구 고객이었다.) 게다가 리눅스에서 소프트웨어 특허에 배포 제한이라니 이게 대체 무슨 분위기 파악 못하는 얘기인가? GPL에 특허에 대해 royalty free 조건이 있다는 걸 ETRI에서는 알기나 하는 걸까?

업체 미팅과 간담회로 폐쇄적으로 진행되는 개발이 아니라 누구나 소스코드를 볼 수 있고 누구나 의견을 제시할 수 있는 공개적인 개발이 이루어져야 한다.

현 정부 임기를 고려한 것인지는 모르겠으나, 3년이라는 시간은 너무 짧다. 독일 뮌헨이 부럽다면 뮌헨처럼 10년 이상 진행하고 그 이후로도 계속 진행한다는 마음가짐을 갖고 있어야 한다. 장기적으로 지속적인 투자가 필요한 문제이지, 단기적으로 많은 투자를 하면 눈먼 돈만 많이 쓸 뿐이다.

오픈소스는 원래 전세계가 같이 만들고 같이 쓰는 것이다. 한국형, 독자, OS주권, 경쟁력같은 말은 이제 안 먹힌다는 걸 깨달을 때가 됐다. 개발을 진행한다면 리눅스 기반 행정용 OS 개발이 아니라 리눅스 데스크톱 환경을 국내 행정용 목적에 맞게 발전시킬 수 있어야 한다.