2014년 3월 26일 수요일

행정용 "한국형 OS 개발"에 대해

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 개발이 아니라 리눅스 데스크톱 환경을 국내 행정용 목적에 맞게 발전시킬 수 있어야 한다.
  • 그런 면에서 정부부터가 오픈소스의 적극적인 생산자가 되어야 한다. 개발 과정을 통해 만들어낸 결과물이 배포판 패키징으로 끝나지 않고 업스트림에 올라갈 수 있도록 해야 한다. 그렇게 하면 아마 (탈윈도우나 OS 개발은 실패할지 모르겠지만) 오픈소스 데스크톱 발전에는 조금이라도 기여했다고 역사에 남을 것이다.

"공개소프트웨어"는 "오픈소스"가 아니다

2000년 초중반, 대한민국 정부가 오픈소스를 정책에서 여러가지로 고려하기 시작하면서 정부 주도하에 새로운 용어를 만들어냈다.  바로 "공개소프트웨어"이다. 엉뚱하게도 "Open Source"의 번역이다라고 주장했는데, 처음 그럴 때는 저러다 말겠지 싶었다. 하지만 십수년이 지난 지금까지 안 먹히는 용어를 밀어붙이는 걸 보면 해도해도 너무한다 싶다.

2014년 1월에 개정된 미래창조과학부 고시 "정보통신,방송 연구개발 관리규정"을 보면 아예 용어부터 공개소프트웨어라고 적어놓았다.

40. "공개소프트웨어"라 함은 "오픈소스 소프트웨어" 또는 "오픈 소스" 등 그 명칭과 상관없이 소프트웨어의 저작권자가 해당 소스코드를 공중에 공개하여 이를 사용, 복제, 수정, 배포할 수 있는 권한을 부여한 소프트웨어를 말한다.
41. "공개소프트웨어 라이선스"라 함은 공개소프트웨어 저작권자가 자신의 공개소프트웨어의 사용, 복제, 수정, 배포와 관련하여 허용되는 권한 범위를 명시한 이용허락조건을 말한다.
42. "공개소프트웨어 개발방식"이라 함은 소프트웨어의 소스코드를 공개하고 소프트웨어를 개발 및 유지 관리하는 전 과정에 최초 개발한 자 외에도 누구나 자유롭게 참여할 수 있도록 하는 개발방식을 말한다.
         

아마 정부 말고는 이렇게 오픈소스를 공개소프트웨어라고 부르는 사람은 없을 것이다. 또는 정부 정책에 동조하는 (또는 동조하지 않더라도 눈먼 돈에 관심이 있는) 기업들도 이 용어를 사용한다. 과거 리눅스 관련 회사들의 모임인 리눅스협의회가 전신인 "공개SW협회"가 대표적인 예이다.


"공개소프트웨어"는 옛날부터 하늘소 "이야기"나 안랩 설립 전의 "V3"와 같이 그냥 공짜로 배포하는 (하지만 소스 코드도 없고 명확한 제한 조건이 있었던) 소프트웨어를 가리키는 용어였다. 이 용어를 오픈소스를 가리키는 말로 사용하는 건 오픈소스의 의미를 왜곡하는 것이다.


진짜 문제는, 전세계가 같이 만들어 나가고 같이 쓰는 오픈소스의 의미를 공무원들이 불편해하고 있다. 각종 정책에서도 기업 위주로 혜택을 주고, 엉뚱하게 특허나 상용화를 강조하는 모습을 보면 그렇다. (사실 15년동안 데비안 개발자였지만 데비안으로 산업화를 어떻게 하냐 물어보면 할 말이 없다.) 정부가 바라보는 오픈소스는 기업화된 모습이지 그걸 만들어낸 해커 문화와 공동체 의식은 안중에 없는 것 같다. 기업화된 오픈소스의 모습도 지금의 현실이고, 좋다 나쁘다 가치 평가를 할 수 있는 것은 아니다. 하지만 어떤 오픈소스도 기업만으로는 동작하지 않는다.

애초에 "Open Source"라는 용어는 "Free Software"가 가진 영어 의미의 중의성이나 "자유"라는 단어가 주는 불편함을 완화시키기 위해 만든 말이다. 하지만 이 말조차 불편해 하면 무엇을 할 수 있을까.

정말 오픈소스의 활성화를 생각한다면 현실과 동떨어지고 왜곡된 용어부터 바로잡아야 할 것이다.

2014년 3월 7일 금요일

공인인증서, 보안이 중요하다면 이렇게 불편하지도 않았다

흔히 공인인증서가 NPKI 폴더에서 파일로 복사할 수 있는 것에 대해 공인인증서의 보안 문제를 비판하곤 하지만, 그에 대한 대안으로 (김기창 교수 주장처럼) 브라우저나 OS에 있는 인증서 저장 기능을 제시하는 건 올바른 대안 제시가 아니라고 생각한다. (물론 그렇게 하는 게 좋다. 하지만 그 점은 보안 때문이 아니라 편의성이나 OS 공통 인터페이스 사용이라는 문제에서 접근해야 할 것이다.) 얼마나 어려운가 차이는 있겠지만 결국 복사되는 건 마찬가지이기 때문이다. 아니 애초에 데이터 형태로 키를 만들어서 거기에 집어 넣는 것부터가 복사가 아니던가?

인증서를 공인했든 공인하지 않았든 컴퓨터에 들어 있는 한 모든 인증서는 같은 비판에 직면하게 될 것이다. 인증서의 복사를 근본적으로 막는 방법은 스마트카드나 TPM과 같이 인증서 자체를 하드웨어에서 읽지 못하게 만드는 것 뿐이다. 하지만 그게 우리가 원하는 미래인지는 모르겠다. 발급에 일정 비용이 반드시 필요하고 온라인에서 발급하는 건 불가능해질테니까.

애초에 인증서를 온라인에서 발급하는 것도 문제이다. 특히 재발급의 경우는 그렇다.지금까지 발생했던 온라인 금융 해킹에서 공인인증서 시스템을 우회했던 방법은 모두 개인정보를 취득한 다음 인증서를 재발급한 경우 아니던가? 하지만 마찬가지로 인증서의 오프라인 발급이 우리가 바라는 미래인지는 의문이다. 인증서를 잃어버리는 일은 너무도 흔하게 발생하니까 비용은 말할 수 없이 증가할 것이다.

그러면 공인인증서 시스템의 포인트를 어디로 잡을 수 있는 걸까? 저울질을 해 보자. 공인인증서 및 관련되어 설치해야 하는 액티브엑스의 불편함으로 인한 비용은 보안을 생각하면 감수할 만한 것이고, 인증서 복사를 근본적으로 막는 방법이나 인증서 허위 재발급을 막는 비용은 보안 위험을 감수하고서라도 감수할 수 없는 비용인가? 이 두 가지 저울질의 차이점은 후자의 경우 비용이 금융기관의 부담으로 돌아온다는 것이다. 오프라인 창구 업무가 말도 안 되게 늘어날 것이고 전에 없던 하드웨어 원가도 들어간다.

보안 회사들 역시 상식적이라면 문제에 대한 대응 방법으로 하드웨어 토큰 사용이나 재발급을 막는 걸 주장했을 것이다. 단지 금융 회사들은 직접적인 비용 부담 때문에 받아들이지 못했을 것이다. 그래서 대안은 사용자 컴퓨터에 백신과 방화벽을 설치하는 것과 같이 컴퓨터 보안을 강화하는 장치를 잔뜩 추가한 것이다. 그나마 PC에서는 하드웨어 토큰을 사용할 수도 있는데 스마트폰에서는 그것도 안 된다. 스마트폰에서 동작하는 백신 앱도 아주 제한된 일밖에 하지 못하고 심리적인 안정을 줄 뿐이다. (이제부터 안심할 수 없게 됐다면 죄송.)

부디 기본으로 돌아갔으면 좋겠다. 진짜 보안을 고려했다면 애초에 이 정도로 불편해지지도 않았을 것이다.

2013년 12월 15일 일요일

리눅스에서 왜 유튜브 제목의 초중종성이 분리되는가

리눅스에서 몇몇 유튜브 영상을 보면 제목이 요상하게 초/중/종성이 분리되어 있는 걸 볼 수 있다.

마침 이 NHN NEXT 페이지가 매우 인상적인데, 리눅스에서는 "NHN NEXT 2014학년도 2차 모집 안내동영상_서류제출안내" 영상의 제목이 끝의 "류제출안내"만 "ㄹㅠㅈㅔㅊㅜㄹㅇㅏㄴㄴㅐ"와 같이 보인다.

http://www.youtube.com/user/NHNNEXT

아마도 이 영상을 올리신 분은, 맥에서 "류제출안내"를 파일이름에서 복사해서 붙여넣기 하셨을 것이다.

근본 원인: 맥 오에스의 파일시스템

문제의 시작은 맥 오에스 파일시스템이 내부적으로 유니코드 인코딩을 NFD로 (참고: 유니코드 정규화) 사용하기 때문이다. 맥 오에스의 이 정책은 한글 뿐만 아니라 독일어 umlaut나 프랑스어 cedilla 같은 각종 액센트도 마찬가지로 적용된다. 한글의 경우 NFD는 한글 음절 코드가 U+1100의 한글 자모 코드로 변환되어 초중종성 코드로 나뉘게 된다.

이 문제는 유튜브 외에 여러 곳에서도 드러난다. 네트워크 파일시스템에서 한글 파일이름의 인코딩을 바꿔서 저장한다거나, 배포한 압축 파일의 파일이름도 초중종성이 분리되어 있거나, SVN으로 받은 한글 파일이름을 맥 방식으로 바꿔서 커밋한다든지, 구글 드라이브를 맥에서 싱크하니까 모든 한글 파일이름의 초중성을 분리한다든지 따위의 해프닝이다.

애플의 이러한 정책은 기술적 취지는 이해할 수 있다. 유니코드에서 같은 내용을 여러가지 방법으로 표현할 수 있는 문제가 있기 때문에, 전부 NFD로 바꾸면 한 가지 방법으로 전부 커버할 수 있으면서 유일성을 보장할 수 있다. 하지만 파일 이름이 파일 이름이 아닌 곳에서 드러난다는 건 문제이다. NFD가 틀린 인코딩은 아니다. 하지만 맞다 틀리다의 문제가 아니라, 일반적으로 많이 쓰이는 인코딩을 사용하는 게 상식적이지 않을까.

나눔 글꼴의 기능 미비

이 경우에도 결국 한 음절로 표시하면 되지 않느냐라고 물을 수 있는데, 리눅스의 글꼴이 그런 기능을 지원하면 가능하다. 하지만 현재 대부분 리눅스 배포판에서 사용하고 있는 나눔 글꼴에는 그런 기능이 들어 있지 않다. 이런 나눔글꼴 수정도 작업 중인 게 있으니 앞으로는 이런 기능의 글꼴이 일반적이 될 수도 있지 않을까.


Pango의 버그

윈도우나 맥용 글꼴이라고 해서 한글 자모 코드를 잘 지원하는 건 아니다. 그러면 왜 리눅스에서 유독 분리되어 보일까. 보통 현대 음절의 경우는 글꼴을 사용하기 전에 렌더링 엔진이 조합해 주기 때문이다. 별다른 기능이 아니기 때문에, gtk에서 사용하는 렌더러인 pango의 한글 렌더러를 처음 작성할 때부터 들어 있었는데 무슨 이유에서인가 망가져 있다. 다음 버그로 보고된 상태.

https://bugzilla.gnome.org/show_bug.cgi?id=705727


구글이 좀 고쳐주지

사실 가장 쉬운 해결 방법은 유튜브에서 자동으로 바로잡아 주는 것. 굳이 사용자가 올린 형태를 유지할 필요도 없을 것 같고, 어차피 내부적으로 검색도 하려면 변환하는 게 큰 문제는 아닐 것이다. 실제로 dropbox같은 경우 처리를 해 주는지 맥과 다른 OS 사이에서 한글 파일이름 공유에 문제가 없다.  하지만 구글에 뭐 고쳐달라고 요청한다고 고쳐주는 것 만큼 어려운 건 없으니...



위의 넷 중에 어떤 방법이든 바로잡으면 제대로 동작한다.

2013년 12월 14일 토요일

새 hwp 리스트


libhwp 그룹스마저 폭파됐기 때문에, HWP 그룹스를 새로 만듭니다. 앞으로 어떻게 될지는 모르겠지만 언제나처럼 가볍게 시작합니다.

https://groups.google.com/forum/#!forum/hwp-foss


libhwp 리스트 복구에 대해

제 메일에 있는 내용은 다음에 mbox 포맷으로 올려놨습니다.

https://sites.google.com/site/libhwprestored/home

- 제가 가입한 2010년 10월 22일부터 메일은 다 있지만 그 전에는 없습니다. 거의 만들어지자 마자 제가 가입했기 때문에 누락된 메일은 몇 개 안 될 겁니다. 누락된 부분도 혹시 메일로 보관 중이시거나 찾을 수 있으신 분은 알려 주세요.

- 가공해서 보기 좋은 모양으로 웹에 올려 놓는 것도 과제입니다. 아이디어 있으면 주세요.


2013년 12월 21일 업데이트: 아카이브 완성. 지난 토론 내용, 또는 지난 플레임을 보고 싶으시면:

https://googledrive.com/host/0BzxIVzS0OjQTSEpScE5lcmRhajA/threads.html

2013년 12월 8일 일요일

libhwp woes

libhwp 개발자께서 github 계정을 삭제하셨습니다. 하필이면 제가 evince-hwp에 데비안 패키징과 관련된 이슈를 문의했을 때, 굉장히 신경질적으로 반응하시면서 프로젝트를 삭제하겠다고 선언하셨는데요.

그 분의 선택을 존중합니다. 그리고 최근에 보기 싫은 일 https://plus.google.com/+ChangwooRyu/posts/h7eq6KqhYMW 때문에 기분이 안 좋은 것도 십분 이해합니다. 하지만 저와 해당 이슈에 대한 반응은 이해할 수 없었습니다. 패키징을 위해 업스트림 저자와 의견을 교환하고 하는 일은 일상적인 일이고, 이슈도 대단치 않은 빌드 변경이었습니다. 이슈 내용이나 이런 피드백 활동 자체가 마음에 안 드신다면 어쩔 수 없지만, 이슈 내용에 대해서 불만을 터뜨리는 것도 아니고 지금까지 프로젝트 관련된 각종 불만이나 개인 사정까지 이슈 페이지에서 폭발하는 건 상식적으로 이해가 가지 않았습니다.

다음에 어떤 일을 하시든 부디 마음을 가볍게 갖고 하셨으면 좋겠습니다.

관련 프로젝트도 현재 접근할 수 없는데 다행히 최근 커밋까지 받았기 때문에 제 clone에 푸시해 놨습니다. 데비안 패키징도 계속됩니다.

https://github.com/changwoo/libhwp
https://github.com/changwoo/evince-hwp

2013년 11월 5일 화요일

NIPA "유망 공개SW 프로젝트 목록" 중에서

공개SW 가이드/보고서 - [2013] 유망 공개SW 프로젝트 목록(오픈프론티어)

http://www.oss.kr/oss_notice/oss_repository12/103649

  • 한국 사람이 운영하는 프로젝트가 이상하게 많다.
  • nodejs 관련 프로젝트도 전체에서 비중이 높다
  • "3년간 커밋 수 증가"라는 기준을 통해 커뮤니티 성장성을 평가하려고 시도한 것 같은데 올바른 평가 기준이 되지 못한다. 대략 20%를 넘어서면 성장성이 높다고 평가하는 것 같은데, 숫자가 편차가 지나치게 큰 데다 이렇게 평가한 성장성과 "뜨는 프로젝트"와는 거리가 멀다. 
  • 수없이 많은 프로젝트 중에 186개의 프로젝트를 리스트업하는 게 의미가 있는지 의문이다. "오픈 프론티어" 사업의 평가 기준으로 삼으려는 생각인지 모르겠으나, 제대로 된 오픈소스 개발자라면 스스로 과제를 선정하고 중요성을 어필하고 그걸 제3자가 검토하는 과정을 통해 평가돼야 하지, 현실을 제대로 반영하기 힘든 제한된 리스트를 통해 중요성이 과대 또는 과소 평가돼서는 안 될 것이다.