행정용 "한국형 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"가 가진 영어 의미의 중의성이나 "자유"라는 단어가 주는 불편함을 완화시키기 위해 만든 말이다. 하지만 이 말조차 불편해 하면 무엇을 할 수 있을까.

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

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

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

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

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

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

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

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

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

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

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

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

 
 

"오픈소스 SW 개발 지원 사업" 개인 지원에 대해

http://www.dt.co.kr/contents.html?article_no=2013032002011160600006
("정부 오픈소스 SW 개발 지원, 기업 중심서 개인으로 확대")

http://www.nipa.kr/biz/noticeView.it?bizId=00039&boardId=noti&boardNo=43&menuNo=18&page=1

기존에 기업이나 대학 연구실만 배불리고 실질적인 성과가 없는 문제를 인식하고 해결하려는 NIPA의 노력은 인정할 만 하지만, 여전히 개인이 지원하기는 무리가 있다.

일단 절대적으로 액수가 작다. 개인이 5천만원이라고 써 있지만 세부 항목을 들여다 보면 인건비가 월 150만원으로 제한되어 있다. 또 개인이 지원하려면 다른 직업이 없거나 직업이 있으면 대표이사 승인이 필요하다. 1년 예산이라면 5천만원 중에 나머지를 다른  비용 따위로 소모해야 하는데 개인이 하는 프로젝트에서 인건비만큼의 액수를 다른 비용에 소모할 일이 있을지 의문이다. 특별히 장비나 비용이 필요한 종류의 프로젝트로 지나치게 제한되거나, 아니면 필요없는 비용을 무분별하게 소모하게 되지 않을까. 이런 과제는 인건비 90%로 예산을 짜도 되는 일이었다.

또한 이 구조로는 대형 프로젝트에 적극적으로 참여하는 사람보다는 개인이 거의 혼자 운영하는 독립 프로젝트만 요건에 부합하게 된다. 과거의 KIPA에서 NIPA로 이어지는 오픈소스 지원 프로그램의 결과를 되짚어보면 과제를 위해 잠깐 만들어졌다가 방치되는 초보적인 sf.net / github 프로젝트만 양산하게 될 가능성이 높다.

해법을 어떻게 찾아야 할까. 사업이 공공 과제의 형식을 가지고 있는 한 문제는 해결하기 힘들어 보인다. 세금으로 조성한 자금의 사용 내역을 철저히 남기는 건 중요한 일이지만, 개개인이 만족시키기 힘든 조건과 절차 때문에 지원이 필요한 전문가보다는 과제 전문가들이 이 자금을 가져가게 된다. 또 공공과제처럼 제안서에 쓴대로 오랜 기간 동안에 하는 일과 참여 인원이 고정되어 있는 방식은 바람직한 오픈소스 운영 방식도 아니다.

이러한 프로젝트를 직접 진행하는 조직을 주도적으로 만들고 그 조직이 개발자를 직접 고용하는 우산 역할을 하는 게 가능한 방법이다. 하지만 이렇게 프로젝트를 직접 진행하게 되면, 책임 소재를 유난히 따지는 공공의 특성상 실패할 때 책임도 직접 지게 되어 실현되기는 어려워 보인다. 또 실현이 되더라도 제대로 필요한 프로젝트를 진행하고 개발자를 채용하고 유지할 수 있을지도 의문이고 말이다.


곁다리지만, 만약 공공이 주도하는 프로젝트의 주제가 마땅치 않다면, 다음 기고글에서 언급된 것처럼 전자정부프레임워크를 비롯한 공공정보화 사업이 공공 주도 프로젝트의 좋은 주제가 될 수 있을 것이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20121127155952("공개SW 살리려면 '커미터' 육성“…어떻게?")

OSS 정책 - 디지털교과서 사업이 맨드리바를 부정복제?

메타냅, 한국소프트웨어진흥원에 디지털교과서용 리눅스 부정복제 중지 촉구

맨드리바 리눅스 배포판은 100% 오픈소스 버전인 Mandriva Free와 non-free 소프트웨어가 포함된 Mandriva One으로 나뉘어져 있다. 전자의 경우는 물론이고 후자의 경우도 일부를 제외하고는 모두 오픈소스 라이선스이고 사용이나 재배포를 금지하지 않는다. (단 맨드리바 상표에 대해서는 이득을 취하는 행위에 대해 이의를 제기할 수 있겠지만 메타냅 측이 지금 문제 삼는 부분은 아니다.)

그럼 과연 메타냅에서 주장하는 "부정복제"는 과연 무엇일까? 아마도 바이너리만 카피해서 배포하는 GPL 위반 행위를 말하는 것 같다. 현재 도를 넘어선 임베디드 업체들의 GPL 위반 상황을 생각해 보면 어떤 위반인지 충분히 예측할 수 있다.

하지만 왜 메타냅 측은 어떤 부분을 위반했다고 정확히 지적하지 않는 건가? 기자의 손을 거치면서 의미가 왜곡되었는지도 모르겠지만, 기사에는 어떤 이유로 GPL 위반이라는 것인지에 대해 설명하지 않았고, 오픈소스를 알지 못하는 사람들이 이 기사를 읽는다면 디지털교과서 사업에서 마치 맨드리바 측의 소프트웨어를 불법 복제한 것처럼 이해하기 쉽다.

위 기사에서 언급한 커널/드라이버/라이브러리 따위를 복제했다는 사실은 GPL에서 허용하는 것이고 위반이 아니다. GPL 위반이 문제라면 소스코드가 없다거나 라이선스를 명시하지 않았다거나 따위의 위반한 사항을 구체적으로 말해야 하지 않을까? 디지털 교과서의 컨텐츠 포맷에 특정 업체의 독점 포맷을 사용한 정책적 방향에 대해 비판할 수는 있어도 (나 역시 반대하지만), 역시 GPL 위반은 아니다.

안드로이드폰 G1의 티보이제이션

구글 그룹스에서 Q&A 중의 구글 관계자의 말에 따르면,

The G1 is aimed at end users, not system developers. For user security reasons the G1 will only accept properly signed system images. I'm not sure, in this case, who 'owns' the key, whether it is the carrier or the manufacturer, but one or both of them handle insuring system images are signed.

G1은 일반 사용자용 제품이지 시스템 개발자가 사용하는 게 아니예요. 보안때문에 G1에서는 올바르게 서명한 시스템 이미지만 받아들입니다. 이 경우에는 누가 그 키를 "소유"하는지, 즉 통신사인지 제조사인지 확신하지 못하겠군요. 어쨌든 이 둘 중의 하나 혹은 둘 모두에서 시스템 이미지의 서명을 관리합니다.

Cheers,

Justin
Android Team @ Google

이 말은 즉슨, 커널 및 시스템 프로그램들의 소스코드는 오픈되어 있으나 그 소스코드를 바꾸더라도 T-Mobile이나 HTC가 가지고 있는 디지털 키로 서명하지 않는 한 실제 장비에는 돌릴 수 없다는 뜻이다. 전형적인 티보이제이션이다. G1은 기대와는 달리 오픈 플랫폼이 아니다.

구글 혹은 T-모바일쪽의 이러한 결정이 사악하느냐 (be evil) 아니냐를 떠나서, 컴파일해 봤자 실제 장비에서 돌릴 수 없는 소스코드라면, 안드로이드의 소스 코드를 오픈한 게 과연 무슨 의미가 있는 걸까? 휴대폰 개발사에 소속되어 개발용 폰을 받지 않는 한, 안드로이드의 시스템 코드 개발자들은 안드로이드 SDK에 들어 있는 에뮬레이터의 한계에 갇힐 수밖에 없다.

크롬에 액티브엑스라니

"액티브X와 공존 모색"…구글, 웹브라우저 시장 '초강수'

액티브엑스를 정확히 어떻게 돌리겠다고 한국의 웹 환경을 위해 액티브엑스를 지원한다는 발언을 한 건지 모르겠는데.. 어떻게 만들던 간에 32비트 x86 MS Windows 전용이 되는 걸 피할 수 없다.

지금 MS 전용 브라우저를 만들어서 MS를 넘어서 보겠다는 얘기를 하고 있는 건가? ("`크롬`은 MS 잡을 대항마" 에릭 슈미트 구글 CEO, FT와 인터뷰서 도전 시인) 아니면 악성코드의 매개체였던 기술을 구현해서 MORE SECURE한 ("Google on Google Chrome" comic book) 브라우저를 만들어내겠다는 건가?

아마도 크롬의 소스가 공개된 걸 국정원이 발견하면 보안용으로 못 쓰게 만들 것 같은데 (리눅스 보안 제품 국정원 차별 논란), 그러면 한국을 위해 closed source로 만들 지도?

전자정부를 통한 증명 문서의 인터넷 출력

2008년 현재 대한민국전자정부의 기능을 이용해 인터넷으로 발급할 수 있는 문서는 주민등록등본, 공시지가확인서, 등기부등본, 소득증명 등 수십종에 이른다. 수년 전에 연말정산때문에 이 기능을 처음 이용해 봤을 때 어떻게 내 프린터에서 공공문서를 인쇄하는 게 가능한 건가 몹시 의심스러웠다. 근본적으로 이렇게 출력된 문서가 올바르다고 보장할 방법이 없기 때문이다. 등기부등본과 같이 서류의 목적이 열람용일 경우에는 문제가 되지 않지만, 일부 증명 용도의 서류도 인터넷으로 발급할 수 있다.

연말정산을 위해 내 프린터에서 주민등록등본을 출력했을 때, 발급자인 정부나 수신자인 국세청은 정말 위변조된 문서가 아니라고 안심할 수 있을까? 국세청은 그 문서 내용을 그대로 믿고 그 종이에 쓰여 있는 가족관계에 따라 내 세금공제를 처리해도 되는 걸까?

실제로 이 서비스는 논란이 많았고, 2005년에 위조 가능성이 제기되어 일시적으로 중지되기도 했고, 업데이트될 때마다 프린터가 지원에서 빠지기도 하고 가상머신에서 이용이 금지되기도 하고 이용자들의 불평이 쏟아졌다.

종이가 증명서가 되려면

"등본"이라는 말은 말 그대로 있는 보관되어 있는 서류와 동일한 문서를 뜻한다. 주민등록이 전산화 되기 전에는 그 주민등록 문서가 보관되어 있는 동사무소에서 신청을 하면 동사무소 직원이 서류 창고에서 해당 문서를 찾아서 복사한 다음 동사무소 직인을 찍어서 발급해 주었고 그게 "등본"이었다. 직인은 실제 문서와 동일하다는 보증이었다. 내 프린터로 인쇄하더라도 주민등록등본이 실제 정부 전산망에 기재된 내용과 동일하다는 걸 보장할 수 있는 걸까?

말많은 키보드 보안 기능과 마찬가지로 전자정부 사이트는 이렇게 인쇄한 문서가 올바르다는 보장을 클라이언트 컨트롤을 통해 하고 있다. 액티브엑스 컨트롤로 가능한 프린터의 종류를 제한하고 있다. 프린터에 보안 기능이 있어야 이용할 수 있다고 말하는 사람들이 있지만, 실제 지원하는 프린터들을 보면 보안 기능같은 건 본적이 없는 프린터들도 사용할 수 있는 걸 보면 프린터의 기능과는 상관이 없다. (시중에 나와 있는 일부 프린터에서 구현하고 있는 보안 기능은 전자정부 웹사이트가 인쇄된 문서를 인증할 수 있는 종류의 인증용 보안 기능이 아니라, 인쇄 데이터 전송의 암호화, 인쇄 작업별로 암호 지정과 같은 보안이다.)

이러한 클라이언트 컨트롤 접근 방법때문에 윈도우즈 외에 다른 OS를 지원하지 않는다거나, 시스템 의존적인 버그가 나타나거나, 개발 비용이 높아진다거나 하는 부작용이 나타난 건 물론이다.

내 프린터에서 인쇄한 종이를 증명서로 만드는 방법같은 건 없다. 왜냐하면 컴퓨터는 사용자의 것이지 전자정부 웹사이트가 마음대로 해라 마라 할 수 있는 게 아니기 때문이다. 프린터에 보낼 이미지 데이터는 결국 컴퓨터의 어딘가에서 로우 데이터로 흘러다니게 마련이고 내부에서 나름대로 암호화하고 하더라도 결국 프린터로 그 데이터를 보내야 한다. 전자정부 사이트는 일단 이용자가 소유한 컴퓨터를 서비스 제공자 마음대로 조작할 수 없다는 걸 인정해야 한다. 이 사실을 인정하지 못하고 사용자에게 배포하는 클라이언트 소프트웨어를 조작하는 방법으로 문제를 해결하려고 하면 상황이 지금과 같이 복잡해 진다.


대안 - 종이가 아닌 데이터를 증명용으로 쓰자!

인쇄한 종이 그 자체가 증명 자격을 가지지 않도록 해야 한다.

단 출력한 내용이 사실 여부를 조회할 수 있도록 하는 티켓 역할을 하도록 만들 수는 있을 것이다. 예를 들어, 회사의 복지제도를 이용하기 위해 내 가족관계가 이러하다는 걸 증명하려면 주민등록초본이 필요할 것이고, 초본의 역할은 제 3자에게 나의 가족관계를 증명하는 것이다. 지금의 초본은 출력한 서류 그 자체가 증명 자격을 갖도록 되어 있지만, 이제 그런 공식적인 증명 자격을 없애고 전자정부에 가족관계를 조회할 수 있는 one-time pass 역할만 하게 만드는 것이다. 그러면 서류의 목적도 달성할 수 있고 사용자의 프린터를 컨트롤할 필요도 없다.

현재도인터넷에서 출력한 문서는 고유번호와 바코드가 기재되어 있고 진위여부를 확인할 수 있다. 기술적으로는 아무런 문제가 없다. 단지 출력한 서류 그 자체가 증명 서류가 아니고 one-time pass일 뿐이라는 걸 인정하면서 기존의 업무체계가 동작할 수 있느냐가 관건이다.

OSS 정책 - 리눅스용 키보드 보안

말많던 리눅스용 보안 프로그램이 최근부터 소프트웨어진흥원의 oss.or.kr 사이트를 통해 배포되고 있다. 백신 프로그램과 키보드 보안으로 구성되어 있다.

http://data.oss.or.kr/sw/view.html?sort=name&num=990&page=1

이 프로그램은 정말 사연이 많다. 약 3년전에 소프트웨어진흥원은 공개소프트웨어 진흥 사업의 하나로 우체국 인터넷 뱅킹의 리눅스 운영체제 지원을 추진했다. 하지만 추진 과정에서 국정원이 발목을 잡았다. 보안적합성 평가에서 MS 윈도우즈와 똑같은 기준을 요구했기 때문이다. (관련 기사) 소프트웨어 진흥원은 국정원의 평가에 대해 이의를 제기하지 않고 그 기준을 따르기로 하고 개발하기로 했고 (관련 기사) 2년이 지난 지금에서야 인증이 완료된 프로그램이 지금 배포하는 이 프로그램이다.

소프트웨어진흥원은 국정원의 가이드라인에 대해 부당함을 말하고 정면 대응했어야 했다. 그러기는 커녕 오히려 소프트웨어진흥원 관계자가 국정원의 어긋난 보안평가를 기초로 "리눅스 보안이 문제가 있다"라고 인정하면서 지금과 같은 핀트가 어긋난 프로그램을 개발한 일은 잘못된 정책이었다.

프로그램을 다운로드해 보면, 파일이 zip으로 압축되어 있고 문서가 MS-Word 형식으로 되어 있다는 것부터가 심상치 않다. 이 프로그램을 실제로 돌려 보기는 매우 어렵다. 일단 소스코드가 공개되어 있지 않고 커널 모듈도 들어 있기 때문에 특정 커널 버전이 아니면 동작하지 않는다. 한소프트리눅스 2006에서만 동작하는데 이 한소프트리눅스 2006 버전은 릴리즈한지 2년이 되는 다음달에 지원이 끊길 예정이다. 국정원이 인증하는데 2년을 끌었다는 걸 입증이라도 하듯, 모든 소프트웨어가 2년전 기준으로 되어 있다.

이 프로그램에 포함된 백신의 경우 V3 엔진의 포팅인데, 여기서 검색하는 바이러스와 웜은 리눅스에서는 전파되지 않는 것들이다. 백신이 하는 일이 윈도우용 파일에 있는 바이러스와 웜을 찾아내는 정도인데, 이 프로그램이 있어야 인터넷 뱅킹을 인증한다는 게 앞뒤가 맞는 걸까.

키보드 보안은 커널 모듈과 Firefox 확장 기능으로 구성되어 있는데, 브라우저를 root 권한으로 실행해야 한다고 한다. root 권한으로 소스를 알 수 없는 소프트웨어를 설치해서 브라우저를 root 권한으로 실행하는 게, 이런 소프트웨어 없이 인터넷 뱅킹을 사용하는 것보다 더 안전한 걸까?

소스 코드를 공개하지 않는 이유는 국정원의 보안 지침이 그렇기 때문이라고 하는데, 덕분에 특정 배포판의 특정 커널 버전이 아니면 사용이 불가능한 소프트웨어가 되었다. 이 소스코드 비공개 지침도 이해하기 힘들다. 스티브잡스가 DRM에 대해 한 얘기에서처럼 그 방법을 비밀로 하면서 그 비밀에 의존하는 보안은 언젠가 비밀이 밝혀질 것이고 수명이 오래 가지 못한다.

현재 이 프로그램의 형태로 볼 때 이대로는 절대로 널리 사용할 수 없어 보인다. 이걸 쓰기 위해 한소프트리눅스 구버전을 설치해서 쓰지는 않을 것이다. 인력을 투입해서 여러 OS를 고려해서 빌드하는 수고를 한다고 해도 향후에 커널 업그레이드에 따위에 발생하는 불편함은 남아 있을 것이다. 국정원이 소스 비공개 원칙을 포기할 것 같지도 않고 말이다. 과연 가까운 시일내에 리눅스에서 인터넷 뱅킹을 쓸 수 있을지 모르겠다.

OSS 정책 보기 - 공개SW 유지보수 가이드라인 시행

기사 - 공개SW  유지보수 첫해부터 유료화 (디지털타임즈)

그동안 관련 업체들의 불만으로 지적했던 것이 유지보수 비용을 소프트웨어 패키지 가격의 일정 퍼센트로 계산하는 관행때문이었다. OSS라는 이유로 소프트웨어 가격이 0에 가깝게 책정되면서 유지보수 비용도 0가 된다면 곤란하기 짝이 없다.  그래서 공급업체들은 무리하게 가격이 높은 레드햇을 공급하거나 번들로 불필요하게 독점 소프트웨어를 공급하거나 하드웨어 공급을 통해 매출과 이익을 올리는 편법을 사용해 왔다.

새로 도입된 정책을 환영한다. 오히려 지금에서야 가이드라인이 나온 건 너무 시간을 오래 끌었다는 느낌이다. 꾸준히 공공사업에 참여하는 업체들의 불만이 터져나왔고 몇 년 전부터 마련하려고 했던 사항이기 때문이다. (기사 2004년 - 공개SW 유지보수체계 만든다 (전자신문), 기사 2006년 - 개발 SW 유지보수 비용 현실화 빠르면 내년부터)

(이것 말고도 몇년 씩 끌고 있는 정책이 정보통신부의 폐지때문에 사라지는 건 아닐지 좀 걱정도 된다..)

OSS 정책 - 부요, 필요할까

지난 글들에 이어,

비행기 조종 실습생들은 창백해진 손으로 조정관을 꼭 움켜쥘 때가 많다. 교관들은 손에서 힘을 빼라고 가르친다. 과잉조정은 과소소정에 못지 않게 위험한 것이다. 오는날 소련 등 여러 나라의 위기가 보여주는 바와 같이 국민과 경제를 과잉통제하고자 하는 국가는 결국은 국가가 추구하는 질서 자체를 파괴하게 된다. 간섭을 적게 하는 국가가 가장 많은 것을 성취하고 그 과정에서 자신의 권력을 고양시키게 될 것이다.  - 앨빈토플러, 권력이동(1992) 중에서

과거에 마이크로소프트웨어 기사 및 각종 인터뷰를 통해 말한 바에 따르면, 부요의 입안자들은 국내 OSS 산업이 활성화되지 않는 원인을 "(1) 많은 소프트웨어 중에서 선택이 어려움", "(2) 기술지원 부재", "(3) 외국 업체 선호"라고 분석했고. 그래서 배포판 표준이 필요하다고 주장하고 있다. 일반 소비자나 기업도 이런 분석을 믿지 않았을 것은 물론이고, 분석안을 내 놓은 정책 입안자들도 사실이라고 생각하지 않았을 것이다. 아마도 "배포판"이라는 결론을 내린 다음에 그럴듯한 원인을 짜깁기했겠지만, 정말로 이런 분석을 했다면 배포판을 만들진 않았을 것이다.

산업 육성 정책

한국 정부는 과거부터 어떤 산업을 육성하려고 한정된 기업들에게 직간접적으로 자금을 지원하고, 제도의 정비를 통해 시장 분위기를 조성하고 보호 장벽을 만들어서 한동안 어느 정도의 수요를 보장하는 정책을 사용했다. 얼핏 듣기에는 부질없어 보이지만 정부는 매우 능숙하게 그런 경제 정책을 해 왔고 실제로 꽤 많은 성공을 거두었다. 철강, 조선, 가전, 자동차, 반도체, 휴대전화 모두 그렇게 정부 주도로 시장을 만들어 내고 보호된 시장 내에서 기업을 키워내는 방법을 사용했다. 요즘에는 과거만큼 약빨이 잘 먹히지 않는 것 같지만.

부요라는 정책도 이 전통적인 국가 주도의 산업 육성 전략에서 벗어나지 않는다. 정부 주도로 하나의 틀을 만들고 (리눅스 표준), 그 틀 안에서 국내 업체를 직간접적으로 지원하고 (표준 배포판 제작 업체), 어느 정도의 수요를 일부러 보장해서 (공공기관의 리눅스 전환 등) 업체들이 성장하는 기반을 만드는 것이다.

부요는 그런 면에서 아직 정책이 완성되지 않았다. "부요"의 표면에 보이는 표준 제정과 업체 지원까지는 진행되었지만, 부차적으로 기업들을 살찌우는데 필요한 "어느 정도의 수요를 일부러 보장"하는 일이 아직 진행되지 않았기 때문이다. (소프트웨어진흥원의 공공기관/교육기관의 공개 소프트웨어 전환 사업과 관련이 있다.) 그래서 성급한 부정적인 평가도 경계해야 겠지만, 현재 하는 것처럼 언론을 통해 자화자찬식으로 정책을 평가하는 것도 곤란하다. 그래서 부요가 수년을 끌어왔음에도 불구하고, 부요에 대한 문제 제기는 미래에 어떻게 될 것인가에 대한 걱정이 된다. 첫째로 정말 이런 산업 육성 정책이 정보 산업에 효과가 있을 것인가라는 의문을 제기하고 싶고, 둘째로 이 정책때문에 오히려 성장의 방향이 왜곡되지 않을까 하는 걱정이 앞선다.

이미 개방된 시장에 장벽 쌓기
이러한 방식의 기획성 산업육성 정책은 리눅스 배포판에 적용되기 힘들다고 생각한다.

리눅스 배포판은 이미 다른 어떠한 시장보다도 개방되어 있다. APT와 YUM같은 업데이트 프로그램으로 무장한 리눅스 배포판 사용자들은, 한국을 포함한, 전세계에서 만든 소프트웨어를 매일같이 다운로드하고 있다. 단지 소프트웨어를 받아보는 것뿐만 아니라 의견을 보내기도 하고, 반대로 의견을 받아서 소프트웨어를 만들기도 하고 계속해서 교류하고 있다. "외산 리눅스"라는 말을 붙이는 게 어색할 정도로 국경의 의미가 무색하고 유통의 제약도 없다.  (만드리바는 어느나라 제품이고 수세는 어느나라 제품인지 기억도 희미하다.) 그래서 어떤 기업이든 리눅스 배포판을 만든다면 지구상의 거의 모든 배포판과 같은 위치에서 평가받을 수밖에 없다. 기업용으로 기술지원이라든지 교육같은 이슈가 있긴 하지만, 그것 역시 국내의 리셀러나 서비스 전문 회사와 같은 위치에서 경쟁할 수밖에 없다.

부요는 이러한 개방된 시장에 철지난 폐쇄적 배포판 정책을 들고 나왔다. 여타 산업 육성 정책이 그랬던 것처럼 이들 부요 배포판 기업을 지원함으로써 경쟁력이 생길까? 그렇지 않다고 생각한다. 다른 분야와는 다르게 리눅스 배포판에 관련해 쌓을 수 있는 장벽은 공공시장뿐이고, 다른 개인/기업 분야의 배포판은 여전히 레드햇, 노벨수세와 같은 기준에서 경쟁해야 한다.


공공 시장의 폐쇄화에 대한 우려
그럼에도 불구하고 필요성을 인정하는 사람도 있고, 군침을 흘리고 있는 기업도 있는 이유는 공공시장 때문이다.공공 시장의 리눅스를 위한 기준을 마련해야 하기 때문에 부요의 필요성을 인정하는 사람이 많고, 또 한국 정부의 지출은 지금도 큰 편이지만, 앞으로 성장할 가능성이 매우 높다. (정부 지출은 GDP의 20% 정도로 다른 국가와 비교해보면 아직 낮은 수치이고, 그 중에서 정보통신 관련 지출 비중은 갈수록 늘고 있다.)

먼저 공공 시장의 기준에 관해서..  그게 부요 표준이 됐든, FHS가 됐든 어떤 기준이 필요하다는 데는 동의한다. 만약 부요가 단순한 표준과 인증으로 구성되었다면 공공기관의 기준으로서 부요에 대해 박수를 보내겠다. 하지만 실제 부요는 전에 말한 것처럼 표준인지 소프트웨어인지 딱 잘라서 말하기 어려운 국내 기업 밀어주기 정책으로, 부요 인증을 받는 게 쉬운 일이 아니다. 정말 공공 시장의 기준이 되려는 게 목적이라면 장벽을 낮춰서, 표준도 좀 더 단순 명확하게 하고 인증도 LSB처럼 저렴한 비용으로 단순하고 명확한 검사를 통해 인증할 수 있어야 한다.

또 공공 시장에 부요의 수요가 보장된다면 국내 기업 입장에선 꽤 괜찮겠지만, 일반 시장의 현실과 다른 왜곡된 시장을 만들어낼 수 있다. 민간 시장과는 다르게 유별난 공공 기관의 아래아한글 수요를 생각해 보면 알 수 있다.  부요를 계속해서 업데이트하면서 리눅스 배포판의 트렌드에서 벗어나지 않게 유지될 수 있을까?


인위적인 시장은 그만

최근 그놈 데스크탑은 같은 2.x 버전이면서도 수많은 인터페이스가 바뀌었다. 한국어 번역도 나 혹은 다른 번역자가 내부적으로 기준을 바꾼 것도 있고 우연히 바뀐 것도 있다. 그런데 최근에 릴리스한 그놈 데스크탑과 부요 데스크탑 2.0 표준을 비교해 보면...  최신 그놈 데스크탑을 채용하면 죄다 부요 표준에서 어긋난다! 인터페이스도 많이 바뀌었고 번역에서 사용하는 용어도 많이 바뀌었다. 자유로운 생각에서 개발하는 소프트웨어를 가지고 기준을 만들고 재단하기 위해 그놈 인터페이스를 보면서 문서로 받아적은 결과이다. 부요를 표준으로 유지하기 위해 매번 그놈이 릴리스할 때마다 재빠르게 표준을 개정하기라도 할 것인가, 아니면 코드나 번역을 옛날 버전으로 일부러 되돌리기라도 할 것인가?

정부주도의 산업육성 정책은 한 시장을 키울 수도 있지만, 가만히 두면 빠르든 느리든 잘 발전할 시장을 망가뜨리기도 하고 발목을 잡기도 한다. 앞에서 예를 든 그놈 데스크탑의 인터페이스 변화는 작은 부분이다.  "공개SW" 지원 정책을 쓰려면 장벽을 낮추고 불공정한 제도를 개선하는 데 앞장서야지, 부요와 같은 방법으로 소프트웨어 자체를 제도적으로 만드려고 해서는 곤란하다고 생각한다.

OSS 정책 - "ETRI `큐플러스' 의료 장비에 탑재"

ETRI `큐플러스' 의료 장비에 탑재 (2007/11/14)

큐플러스의 정체는 임베디드리눅스 개발 키트이다. 몬타비스타라던가 임베디드 리눅스 개발지원을 하는 수많은 기업들이 이미 이런 툴을 제공하고 있다. 꽤 오래된 물건이고  SF.NET 페이지에서 초기 버전을 받을 수도 있다. (지금은 관리하지 않는 것 같지만) 크로스 빌드용 컴파일러 툴체인, 라이브러리, 커널 등등을 모아 놓은 것으로 그 이후 버전은 모르지만 내가 받아봤던 2002년 경 초기 버전은 iPAQ에 호환되게 만들었다.

이 오래된 물건에 대해 새삼스럽게 조사하느라 수고하기도 귀찮고, 그럴 필요도 별로 없어서 대충 기억들을 열거해 보면...

• ETRI의 프로그램을 따라가자면 상당한 액수의, 그것도 런타임 로열티를 지급해야 했다. 그게 QPlus에 대해 사람들이 시큰둥한 가장 큰 원인이었다. 외산소프트웨어 대체가 목적이었다면 좀 싸야 하지 않았을까?
  
• 다른 판매된/공개된 ready-made 개발키트나, DIY에 비해 별로 특이한 사항도 없었고 말이다. 이 오래된 녀석이 5년이 지난 지금에서 다시 뉴스에 등장할 줄은 꿈에도 몰랐다. (보도에는 2005년 개발이라고 되어 있는데 어찌된 일인지?)
  
• "그동안 정보가전 솔루션, 텔레매틱스 솔루션, 스마트폰 등 모바일 단말 솔루션 등에 사용돼 왔으며"라고 되어 있지만, 믿기 힘들다. 어설프게 진입하려고 하다가 로열티만 낭비했던 기업이라면 몰라도...
  
• 그것보다도 옛날에 관계자들을 만났을 때, 내가 셋탑 만든다니까 마치 QPlus가 표준이니까 다 써야 한다는 듯이 주장하던 사람들의 얼굴이 떠올라서...

OSS 정책 - 부요, 그 이름과 방향

저번 부요에 관한 네거티브이야기에 이어서, 가십성이긴 하지만 부요의 이름과 그 정의에 대해 생각해 보면,

2004년인가, 2005년에 부요 프로젝트에 몇단계에 건너서 관여된 누군가와 대화를 했었다.

창우: "어, 영어로 Booyo인데 부요 아니었어요?"
누군가: "부여예요"

드라마 "주몽"이 살던, 대소왕자가 살던 그 부여! 오래전 쓰여진 KLDP 위키 페이지에도 그 흔적이 일부 남아 있다.

• BONE:사업 코드명이며 공개SW (OSS: Open Source Software, 뼈)의 本, 골격을 의미
• BOOYO:결과물코드명이며 중국 중원의 대부여의 맥, 일본의 근간인 백제(부여의 계승)의 맥으로써 리눅스 제국 건설을 의미함

너무 민족주의 코드가 들어있었기 때문이었을까? 아니면 다른 어떤 사연이 있었는지 결국 이름은 "부요"가 되었다. KDE가 맨 처음 announcement에서는 "Kool Desktop Project"였는데도 시간이 갈 수록 잊혀져서 "K Desktop Project"가 되었듯이, 부요라고 바뀐 이름은 새로운 의미로 해석되었다. 그런데 이상하게도 영문 위키피디어 페이지에만 부요의 설명이 상세하게 되어 있고 한글 페이지에는 별로 언급이 없다. 이름에 대한 설명을 보면,

Booyo is a Korean onomatopoeia yelled at during pheasant hunting to make the birds take wing, hence meaning the new soaring of the Linux platform in Korea. The Booyo logo shows a penguin taking off the ground. A homonym of Booyo means being rich.

"being rich"...  "부자 되세요?"  한글로 된 설명도 KLDP 게시판의 일부 댓글에서 찾을 수 있다.

    정식 한글 명칭은 '부요' 입니다. '부요'는 표준 스펙으로서의 기능도 하고 해당 스펙을 준수하는 배포판 기능도 합니다.

    이름의 유래는 남쪽지방의 꿩잡기 할 때 나는 소리입니다. 꿩을 잡을때 몰이꾼이 내는 소리가 부요... 뿌요.. 뭐 그렇다고 하는데 인턴인 제가 봐도 믿거나 말거나입니다. :)

어쨌거나, 이름이 그렇게 변화되어 왔는데...  부요의 이름이 바뀌면서 처음에 구상했던 BONE/BOOYO의 구분이 애매해 진 것일까?  부요가 표준인지 배포판 제품인지 명확하지가 않다. 부요를 단순히 "부요 표준을 준수해 구현된 제품"이라고 정의하기에는 사람들이 하는 말이 앞뒤가 맞지 않다. TTA에 표준으로 공개된 수준의 부요 표준은 매우 대략적이고 선언적인 기준만 제시되어 있기 때문에 사실상 거의 모든 리눅스 배포판이 부요 compatible이라고 주장할 수도 있을 정도인데, 사람들은 부요의 제품성에 대해서 말하고 있다.

몇 가지 예를 들어 보면,

• 부요는 LSB 3.1 certification을 받았다. 그러면 부요는 배포판 제품인가?  (참고로 LSB는 Linux Foundation에 인증을 신청하면 제출하는 제품을 기준으로 certification을 부여한다. 부요가 LSB certification을 받았다고, 부요 인증만 하면 LSB 인증이 자동으로 되는 거 절대로 아니다.)
• 부요는 TTAS.KO-05.0037 및 TTAS.KO-05.0038로 한국정보통신기술협회(TTA)의 표준으로 등록되어 있다. 그러면 부요는 표준인가?
• 부요는 ETRI와 리눅스 배포판 업체들과의 합작품이다. 그러면 부요는 제품인가?
• 2005년 12월, TTA로부터 프로젝트 그룹의 표준화 활동 공로로 ETRI 연구원들이 표준화 공로상을 수상한바 있다. 그러면 부요는 표준인가?
• 제품 성능에 대해 말하고 있는 부요 관련 신문 기사들을 보면 역시 부요는 제품인가?  ("부요 프로젝트는 돈먹는 하마?",   "리눅스 플랫폼, 부요 기반 배포판 무상보급 신경전")

부요 리눅스를 서치해 봐도, 리눅스 이용자들은 부요를 리눅스 배포판 제품으로 생각하고 말한다. 업체들은 물론이고, 정부 관계자들도 부요에 대해 선전할 때도 화려한 각종 기능을 선전하는 걸 보면, 부요 표준이 아닌 부요 배포판에 대해서 말하고 있다. 하지만 정책 입안자들과 ETRI에서는 부요를 표준 플랫폼이라고 말하고 있다. 그런데 또 표준 문서만 준수한다고 부요 인증을 해 주는 것도 아니다.

무엇이 맞는 얘기일까? 정책의 애초의 목적, 진흥원, ETRI, 업체, 사용자가 모두 다른 방향을 바라보고 있는 게 아닐까?


(나중에 귀차니즘이 회복되면 부요의 다른 부분에 대해서 계속)

OSS 정책 - "리눅스OS `부요 2.5` 기술이전"

리눅스OS `부요 2.5` 기술이전

ETRI 공개SW솔루션연구팀 우영춘 팀장은 "부요는 그동안 수 차례의 기술이전을 통해 국내 공개SW 활성화에 매우 긍정적인 영향을 미쳤다고 본다"며 "이번에 기술이 이전되는 부요 2.5 버전은 데스크톱 SW 플랫폼의 경우 업데이트 기능이 대폭 강화됐고, 서버 SW 플랫폼은 최근 업계의 이슈가 되고 있는 가상화 기능이 포함된 것이 특징"이라고 말했다.

여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만...  (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등)  그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.

부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까?  실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.