기사 - 공개SW 유지보수 첫해부터 유료화 (디지털타임즈)
그동안 관련 업체들의 불만으로 지적했던 것이 유지보수 비용을 소프트웨어 패키지 가격의 일정 퍼센트로 계산하는 관행때문이었다. OSS라는 이유로 소프트웨어 가격이 0에 가깝게 책정되면서 유지보수 비용도 0가 된다면 곤란하기 짝이 없다. 그래서 공급업체들은 무리하게 가격이 높은 레드햇을 공급하거나 번들로 불필요하게 독점 소프트웨어를 공급하거나 하드웨어 공급을 통해 매출과 이익을 올리는 편법을 사용해 왔다.
새로 도입된 정책을 환영한다. 오히려 지금에서야 가이드라인이 나온 건 너무 시간을 오래 끌었다는 느낌이다. 꾸준히 공공사업에 참여하는 업체들의 불만이 터져나왔고 몇 년 전부터 마련하려고 했던 사항이기 때문이다. (기사 2004년 - 공개SW 유지보수체계 만든다 (전자신문), 기사 2006년 - 개발 SW 유지보수 비용 현실화 빠르면 내년부터)
(이것 말고도 몇년 씩 끌고 있는 정책이 정보통신부의 폐지때문에 사라지는 건 아닐지 좀 걱정도 된다..)
2008년 1월 18일 금요일
2008년 1월 12일 토요일
OSS 정책 - 부요, 필요할까
지난 글들에 이어,
과거에 마이크로소프트웨어 기사 및 각종 인터뷰를 통해 말한 바에 따르면, 부요의 입안자들은 국내 OSS 산업이 활성화되지 않는 원인을 "(1) 많은 소프트웨어 중에서 선택이 어려움", "(2) 기술지원 부재", "(3) 외국 업체 선호"라고 분석했고. 그래서 배포판 표준이 필요하다고 주장하고 있다. 일반 소비자나 기업도 이런 분석을 믿지 않았을 것은 물론이고, 분석안을 내 놓은 정책 입안자들도 사실이라고 생각하지 않았을 것이다. 아마도 "배포판"이라는 결론을 내린 다음에 그럴듯한 원인을 짜깁기했겠지만, 정말로 이런 분석을 했다면 배포판을 만들진 않았을 것이다.
산업 육성 정책
한국 정부는 과거부터 어떤 산업을 육성하려고 한정된 기업들에게 직간접적으로 자금을 지원하고, 제도의 정비를 통해 시장 분위기를 조성하고 보호 장벽을 만들어서 한동안 어느 정도의 수요를 보장하는 정책을 사용했다. 얼핏 듣기에는 부질없어 보이지만 정부는 매우 능숙하게 그런 경제 정책을 해 왔고 실제로 꽤 많은 성공을 거두었다. 철강, 조선, 가전, 자동차, 반도체, 휴대전화 모두 그렇게 정부 주도로 시장을 만들어 내고 보호된 시장 내에서 기업을 키워내는 방법을 사용했다. 요즘에는 과거만큼 약빨이 잘 먹히지 않는 것 같지만.
부요라는 정책도 이 전통적인 국가 주도의 산업 육성 전략에서 벗어나지 않는다. 정부 주도로 하나의 틀을 만들고 (리눅스 표준), 그 틀 안에서 국내 업체를 직간접적으로 지원하고 (표준 배포판 제작 업체), 어느 정도의 수요를 일부러 보장해서 (공공기관의 리눅스 전환 등) 업체들이 성장하는 기반을 만드는 것이다.
부요는 그런 면에서 아직 정책이 완성되지 않았다. "부요"의 표면에 보이는 표준 제정과 업체 지원까지는 진행되었지만, 부차적으로 기업들을 살찌우는데 필요한 "어느 정도의 수요를 일부러 보장"하는 일이 아직 진행되지 않았기 때문이다. (소프트웨어진흥원의 공공기관/교육기관의 공개 소프트웨어 전환 사업과 관련이 있다.) 그래서 성급한 부정적인 평가도 경계해야 겠지만, 현재 하는 것처럼 언론을 통해 자화자찬식으로 정책을 평가하는 것도 곤란하다. 그래서 부요가 수년을 끌어왔음에도 불구하고, 부요에 대한 문제 제기는 미래에 어떻게 될 것인가에 대한 걱정이 된다. 첫째로 정말 이런 산업 육성 정책이 정보 산업에 효과가 있을 것인가라는 의문을 제기하고 싶고, 둘째로 이 정책때문에 오히려 성장의 방향이 왜곡되지 않을까 하는 걱정이 앞선다.
이미 개방된 시장에 장벽 쌓기
이러한 방식의 기획성 산업육성 정책은 리눅스 배포판에 적용되기 힘들다고 생각한다.
리눅스 배포판은 이미 다른 어떠한 시장보다도 개방되어 있다. APT와 YUM같은 업데이트 프로그램으로 무장한 리눅스 배포판 사용자들은, 한국을 포함한, 전세계에서 만든 소프트웨어를 매일같이 다운로드하고 있다. 단지 소프트웨어를 받아보는 것뿐만 아니라 의견을 보내기도 하고, 반대로 의견을 받아서 소프트웨어를 만들기도 하고 계속해서 교류하고 있다. "외산 리눅스"라는 말을 붙이는 게 어색할 정도로 국경의 의미가 무색하고 유통의 제약도 없다. (만드리바는 어느나라 제품이고 수세는 어느나라 제품인지 기억도 희미하다.) 그래서 어떤 기업이든 리눅스 배포판을 만든다면 지구상의 거의 모든 배포판과 같은 위치에서 평가받을 수밖에 없다. 기업용으로 기술지원이라든지 교육같은 이슈가 있긴 하지만, 그것 역시 국내의 리셀러나 서비스 전문 회사와 같은 위치에서 경쟁할 수밖에 없다.
부요는 이러한 개방된 시장에 철지난 폐쇄적 배포판 정책을 들고 나왔다. 여타 산업 육성 정책이 그랬던 것처럼 이들 부요 배포판 기업을 지원함으로써 경쟁력이 생길까? 그렇지 않다고 생각한다. 다른 분야와는 다르게 리눅스 배포판에 관련해 쌓을 수 있는 장벽은 공공시장뿐이고, 다른 개인/기업 분야의 배포판은 여전히 레드햇, 노벨수세와 같은 기준에서 경쟁해야 한다.
공공 시장의 폐쇄화에 대한 우려
그럼에도 불구하고 필요성을 인정하는 사람도 있고, 군침을 흘리고 있는 기업도 있는 이유는 공공시장 때문이다.공공 시장의 리눅스를 위한 기준을 마련해야 하기 때문에 부요의 필요성을 인정하는 사람이 많고, 또 한국 정부의 지출은 지금도 큰 편이지만, 앞으로 성장할 가능성이 매우 높다. (정부 지출은 GDP의 20% 정도로 다른 국가와 비교해보면 아직 낮은 수치이고, 그 중에서 정보통신 관련 지출 비중은 갈수록 늘고 있다.)
먼저 공공 시장의 기준에 관해서.. 그게 부요 표준이 됐든, FHS가 됐든 어떤 기준이 필요하다는 데는 동의한다. 만약 부요가 단순한 표준과 인증으로 구성되었다면 공공기관의 기준으로서 부요에 대해 박수를 보내겠다. 하지만 실제 부요는 전에 말한 것처럼 표준인지 소프트웨어인지 딱 잘라서 말하기 어려운 국내 기업 밀어주기 정책으로, 부요 인증을 받는 게 쉬운 일이 아니다. 정말 공공 시장의 기준이 되려는 게 목적이라면 장벽을 낮춰서, 표준도 좀 더 단순 명확하게 하고 인증도 LSB처럼 저렴한 비용으로 단순하고 명확한 검사를 통해 인증할 수 있어야 한다.
또 공공 시장에 부요의 수요가 보장된다면 국내 기업 입장에선 꽤 괜찮겠지만, 일반 시장의 현실과 다른 왜곡된 시장을 만들어낼 수 있다. 민간 시장과는 다르게 유별난 공공 기관의 아래아한글 수요를 생각해 보면 알 수 있다. 부요를 계속해서 업데이트하면서 리눅스 배포판의 트렌드에서 벗어나지 않게 유지될 수 있을까?
인위적인 시장은 그만
최근 그놈 데스크탑은 같은 2.x 버전이면서도 수많은 인터페이스가 바뀌었다. 한국어 번역도 나 혹은 다른 번역자가 내부적으로 기준을 바꾼 것도 있고 우연히 바뀐 것도 있다. 그런데 최근에 릴리스한 그놈 데스크탑과 부요 데스크탑 2.0 표준을 비교해 보면... 최신 그놈 데스크탑을 채용하면 죄다 부요 표준에서 어긋난다! 인터페이스도 많이 바뀌었고 번역에서 사용하는 용어도 많이 바뀌었다. 자유로운 생각에서 개발하는 소프트웨어를 가지고 기준을 만들고 재단하기 위해 그놈 인터페이스를 보면서 문서로 받아적은 결과이다. 부요를 표준으로 유지하기 위해 매번 그놈이 릴리스할 때마다 재빠르게 표준을 개정하기라도 할 것인가, 아니면 코드나 번역을 옛날 버전으로 일부러 되돌리기라도 할 것인가?
정부주도의 산업육성 정책은 한 시장을 키울 수도 있지만, 가만히 두면 빠르든 느리든 잘 발전할 시장을 망가뜨리기도 하고 발목을 잡기도 한다. 앞에서 예를 든 그놈 데스크탑의 인터페이스 변화는 작은 부분이다. "공개SW" 지원 정책을 쓰려면 장벽을 낮추고 불공정한 제도를 개선하는 데 앞장서야지, 부요와 같은 방법으로 소프트웨어 자체를 제도적으로 만드려고 해서는 곤란하다고 생각한다.
비행기 조종 실습생들은 창백해진 손으로 조정관을 꼭 움켜쥘 때가 많다. 교관들은 손에서 힘을 빼라고 가르친다. 과잉조정은 과소소정에 못지 않게 위험한 것이다. 오는날 소련 등 여러 나라의 위기가 보여주는 바와 같이 국민과 경제를 과잉통제하고자 하는 국가는 결국은 국가가 추구하는 질서 자체를 파괴하게 된다. 간섭을 적게 하는 국가가 가장 많은 것을 성취하고 그 과정에서 자신의 권력을 고양시키게 될 것이다. - 앨빈토플러, 권력이동(1992) 중에서
과거에 마이크로소프트웨어 기사 및 각종 인터뷰를 통해 말한 바에 따르면, 부요의 입안자들은 국내 OSS 산업이 활성화되지 않는 원인을 "(1) 많은 소프트웨어 중에서 선택이 어려움", "(2) 기술지원 부재", "(3) 외국 업체 선호"라고 분석했고. 그래서 배포판 표준이 필요하다고 주장하고 있다. 일반 소비자나 기업도 이런 분석을 믿지 않았을 것은 물론이고, 분석안을 내 놓은 정책 입안자들도 사실이라고 생각하지 않았을 것이다. 아마도 "배포판"이라는 결론을 내린 다음에 그럴듯한 원인을 짜깁기했겠지만, 정말로 이런 분석을 했다면 배포판을 만들진 않았을 것이다.
산업 육성 정책
한국 정부는 과거부터 어떤 산업을 육성하려고 한정된 기업들에게 직간접적으로 자금을 지원하고, 제도의 정비를 통해 시장 분위기를 조성하고 보호 장벽을 만들어서 한동안 어느 정도의 수요를 보장하는 정책을 사용했다. 얼핏 듣기에는 부질없어 보이지만 정부는 매우 능숙하게 그런 경제 정책을 해 왔고 실제로 꽤 많은 성공을 거두었다. 철강, 조선, 가전, 자동차, 반도체, 휴대전화 모두 그렇게 정부 주도로 시장을 만들어 내고 보호된 시장 내에서 기업을 키워내는 방법을 사용했다. 요즘에는 과거만큼 약빨이 잘 먹히지 않는 것 같지만.
부요라는 정책도 이 전통적인 국가 주도의 산업 육성 전략에서 벗어나지 않는다. 정부 주도로 하나의 틀을 만들고 (리눅스 표준), 그 틀 안에서 국내 업체를 직간접적으로 지원하고 (표준 배포판 제작 업체), 어느 정도의 수요를 일부러 보장해서 (공공기관의 리눅스 전환 등) 업체들이 성장하는 기반을 만드는 것이다.
부요는 그런 면에서 아직 정책이 완성되지 않았다. "부요"의 표면에 보이는 표준 제정과 업체 지원까지는 진행되었지만, 부차적으로 기업들을 살찌우는데 필요한 "어느 정도의 수요를 일부러 보장"하는 일이 아직 진행되지 않았기 때문이다. (소프트웨어진흥원의 공공기관/교육기관의 공개 소프트웨어 전환 사업과 관련이 있다.) 그래서 성급한 부정적인 평가도 경계해야 겠지만, 현재 하는 것처럼 언론을 통해 자화자찬식으로 정책을 평가하는 것도 곤란하다. 그래서 부요가 수년을 끌어왔음에도 불구하고, 부요에 대한 문제 제기는 미래에 어떻게 될 것인가에 대한 걱정이 된다. 첫째로 정말 이런 산업 육성 정책이 정보 산업에 효과가 있을 것인가라는 의문을 제기하고 싶고, 둘째로 이 정책때문에 오히려 성장의 방향이 왜곡되지 않을까 하는 걱정이 앞선다.
이미 개방된 시장에 장벽 쌓기
이러한 방식의 기획성 산업육성 정책은 리눅스 배포판에 적용되기 힘들다고 생각한다.
리눅스 배포판은 이미 다른 어떠한 시장보다도 개방되어 있다. APT와 YUM같은 업데이트 프로그램으로 무장한 리눅스 배포판 사용자들은, 한국을 포함한, 전세계에서 만든 소프트웨어를 매일같이 다운로드하고 있다. 단지 소프트웨어를 받아보는 것뿐만 아니라 의견을 보내기도 하고, 반대로 의견을 받아서 소프트웨어를 만들기도 하고 계속해서 교류하고 있다. "외산 리눅스"라는 말을 붙이는 게 어색할 정도로 국경의 의미가 무색하고 유통의 제약도 없다. (만드리바는 어느나라 제품이고 수세는 어느나라 제품인지 기억도 희미하다.) 그래서 어떤 기업이든 리눅스 배포판을 만든다면 지구상의 거의 모든 배포판과 같은 위치에서 평가받을 수밖에 없다. 기업용으로 기술지원이라든지 교육같은 이슈가 있긴 하지만, 그것 역시 국내의 리셀러나 서비스 전문 회사와 같은 위치에서 경쟁할 수밖에 없다.
부요는 이러한 개방된 시장에 철지난 폐쇄적 배포판 정책을 들고 나왔다. 여타 산업 육성 정책이 그랬던 것처럼 이들 부요 배포판 기업을 지원함으로써 경쟁력이 생길까? 그렇지 않다고 생각한다. 다른 분야와는 다르게 리눅스 배포판에 관련해 쌓을 수 있는 장벽은 공공시장뿐이고, 다른 개인/기업 분야의 배포판은 여전히 레드햇, 노벨수세와 같은 기준에서 경쟁해야 한다.
공공 시장의 폐쇄화에 대한 우려
그럼에도 불구하고 필요성을 인정하는 사람도 있고, 군침을 흘리고 있는 기업도 있는 이유는 공공시장 때문이다.공공 시장의 리눅스를 위한 기준을 마련해야 하기 때문에 부요의 필요성을 인정하는 사람이 많고, 또 한국 정부의 지출은 지금도 큰 편이지만, 앞으로 성장할 가능성이 매우 높다. (정부 지출은 GDP의 20% 정도로 다른 국가와 비교해보면 아직 낮은 수치이고, 그 중에서 정보통신 관련 지출 비중은 갈수록 늘고 있다.)
먼저 공공 시장의 기준에 관해서.. 그게 부요 표준이 됐든, FHS가 됐든 어떤 기준이 필요하다는 데는 동의한다. 만약 부요가 단순한 표준과 인증으로 구성되었다면 공공기관의 기준으로서 부요에 대해 박수를 보내겠다. 하지만 실제 부요는 전에 말한 것처럼 표준인지 소프트웨어인지 딱 잘라서 말하기 어려운 국내 기업 밀어주기 정책으로, 부요 인증을 받는 게 쉬운 일이 아니다. 정말 공공 시장의 기준이 되려는 게 목적이라면 장벽을 낮춰서, 표준도 좀 더 단순 명확하게 하고 인증도 LSB처럼 저렴한 비용으로 단순하고 명확한 검사를 통해 인증할 수 있어야 한다.
또 공공 시장에 부요의 수요가 보장된다면 국내 기업 입장에선 꽤 괜찮겠지만, 일반 시장의 현실과 다른 왜곡된 시장을 만들어낼 수 있다. 민간 시장과는 다르게 유별난 공공 기관의 아래아한글 수요를 생각해 보면 알 수 있다. 부요를 계속해서 업데이트하면서 리눅스 배포판의 트렌드에서 벗어나지 않게 유지될 수 있을까?
인위적인 시장은 그만
최근 그놈 데스크탑은 같은 2.x 버전이면서도 수많은 인터페이스가 바뀌었다. 한국어 번역도 나 혹은 다른 번역자가 내부적으로 기준을 바꾼 것도 있고 우연히 바뀐 것도 있다. 그런데 최근에 릴리스한 그놈 데스크탑과 부요 데스크탑 2.0 표준을 비교해 보면... 최신 그놈 데스크탑을 채용하면 죄다 부요 표준에서 어긋난다! 인터페이스도 많이 바뀌었고 번역에서 사용하는 용어도 많이 바뀌었다. 자유로운 생각에서 개발하는 소프트웨어를 가지고 기준을 만들고 재단하기 위해 그놈 인터페이스를 보면서 문서로 받아적은 결과이다. 부요를 표준으로 유지하기 위해 매번 그놈이 릴리스할 때마다 재빠르게 표준을 개정하기라도 할 것인가, 아니면 코드나 번역을 옛날 버전으로 일부러 되돌리기라도 할 것인가?
정부주도의 산업육성 정책은 한 시장을 키울 수도 있지만, 가만히 두면 빠르든 느리든 잘 발전할 시장을 망가뜨리기도 하고 발목을 잡기도 한다. 앞에서 예를 든 그놈 데스크탑의 인터페이스 변화는 작은 부분이다. "공개SW" 지원 정책을 쓰려면 장벽을 낮추고 불공정한 제도를 개선하는 데 앞장서야지, 부요와 같은 방법으로 소프트웨어 자체를 제도적으로 만드려고 해서는 곤란하다고 생각한다.
2008년 1월 2일 수요일
맘대로 예언 2008 (?)
연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, FL/OSS 세계에 대해 올해 벌어질 일들에 대해 써 보려고 한다. OOXML, DRM, GPLv3 적용 등등 FL/OSS 분야의 큰 뉴스거리가 될 만한 이야기는 이런 예언을 보면 될 것이고, 기술 분야에 대한 광범위한 예언은 이런 예언을 봐도 될 것이지만... 국내의 이야기나 직접 관계있고 당장 생각나는 이야기들을 모아본다.
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
2007년 12월 30일 일요일
브랜드의 번역
예전에 회사 팀장과의 에피소드:
썬의 번역 가이드
썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.
Branding
"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 3가지 방법 중에 하나를 선택하게 될 것이다.
실제로 한국에 진출한 글로벌 기업은 어떤 전략을 사용했을까?
영어 약자로 된 브랜드는 (KFC, HP, ...) 음역으로 쓸 수 없기 때문에 다른 선택이 없지만, 그 외에 1의 선택을 하는 경우는 의외로 별로 많지 않다. 길거리에서 영어로 가득한 간판을 보긴 하지만, "우리 STARBUCKS는..."이라고 회사 소개를 하지는 않는다. 거의 모든 회사가 "맥도나알드~"라고 멋드러지게 한글 음역을 이용하지 TV 화면을 영어로 가득 채우지는 않는다. 우리들도 일상 생활에서 "아웃백에서 봐요"라고 문자를 보내지 "Outback에서 봐요"라고 쓰지는 않는다. (게다가 1바이트 더 많다!)
3번째로 새로운 브랜드를 만들어 내는 경우도 잘 찾아보면 드물지 않게 볼 수 있다. 햄버거 체인점인 하디스(Hardees)는 미국의 찰스 쥬니어를 가져온 것인데 찰스 쥬니어는 말도 길어지고 왠지 맛있는 느낌이 안 나니까한국판에서는 새로운 말을 만들어 냈다. 한솥도시락은 일본의 도시락 체인점인 혼께가마도야의 메뉴와 시스템과 인테리어를 그대로 가져왔지만 이름은 우리말로 다시 지었다.
1과 2의 장단점을 적당히 취하는 경우도 볼 수 있다. 많이 사용하는 방법이 로고는 원래 영어가 들어간 로고를 무슨 그림 마냥 그대로 사용하면서 글자로 쓸 경우는 한글 음역을 사용하는 방법이다. (스타벅스, 커피빈, 아웃백 스테이크하우스, 리바이스, ...) 원래 로고와 한글 로고를 둘 다 만들어 놓거나 원래 로고의 영어에 한글 표기를 추가하는 식으로 동시에 사용하면서 글자로 표기할 때는 한글 음역을 쓰는 경우도 있다. (맥도날드, 버거킹, 철수하기 전의 월마트, ...)
하지만 로고나 간판을 원래 브랜드 그대로 이용하는 경우는 많아도, 일반 광고나 보도자료 등의 일반 텍스트 문서에서 영어 표기를 고집한 회사는 한국에 들어온 글로벌 기업중에 거의 없었다. (약자로 된 브랜드는 제외.) 몇가지 예외가 있으니 바로 소프트웨어 회사들이다. 마이크로소프트는 양지사 와의 상표 분쟁에서 패소했기 때문인지는 몰라도 "Windows 95" 이후 계속해서 한글마이크로소프트의 제품 설명에서도 "Microsoft Windows" 영문 표기를 고집하고 (그 전에는 "윈도우"라고 사용했다) 오피스의 경우에도 프로그램 메뉴에까지 "Microsoft Word"라고 영문으로 들어가 있다. 어도비, 오라클 등등 모두 영문 표기를 고집하고 있다. (하지만 광고나 그렇지 절대로 언론은 영문 표기로 보도해 주지 않는다.)
한글로 음역해서 쓰는 이유는 그게 세종대왕과 주시경선생께서 기뻐하시는 옳은 방향이라서가 아니라, 그게 더 올바른 브랜딩 전략이기 때문이다. 잠재적인 소비자들에게 쉽게 인식되고, 쉽게 기억되고, 눈에 잘 뜨이는 게 좋은 브랜드이다. 현재 평균적인 한국 소비자들은 왠만큼 교육 수준이 높은 경우에도, 영어 그대로 쓴 브랜드는 기억하거나 인식하기에 힘든 게 현실이다. 물론 본래 브랜드를 지역화하는 비용도 있고 본래 브랜드가 손상될 우려가 있어서 본래 로고를 남겨두고 일부만 지역화한다든지 선택을 할 수는 있다. 하지만 트레이드오프로 그런 선택을 할 수는 있어도 영어로 쓰는 게 한글로 쓰는 것보다 더 원래 의미를 전달하니까 좋은 브랜딩이다라고는 할 수 없다. 구찌, 버버리, 까르티에의 영문 철자를 기억하고 있는 사람이 얼마나 될까? (소프트웨어 회사들이 예외적인 전략을 쓰는 이유는 한국의 소프트웨어 소비자들이 영어에 익숙하기 때문일까?)
에볼루션은 있는데 Evolution은 어딨지
썬의 번역 가이드는 첫째로 한국에 진출한 브랜드들이 취한 현실과 다르다. 위에서 말한 것처럼 한국에 진출한 글로벌 기업의 대부분은 브랜드를 한글로 음역했다. 특히 그놈 에볼루션은 분명히 (내가!) 한글로 "에볼루션"이라고 음역했고 한국어 데스크탑에는 프로그램 정보 창을 보지 않는 한, Evolution이라는 단어도 찾아보기 힘든데 예제에까지 "Evolution"이라고 써 놓는 건 맞지 않다.
또 (소프트웨어 회사들의 상업용 소프트웨어들도 그렇지만) 그 지역의 언어로 표기하는 편이 쉽게 인지되고 기억되는 더 좋은 브랜딩인데도, 왜 OpenOffice.org, Firefox 따위의 번역도 그 "OpenOffice.org", "Firefox"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)
팀장모씨: (팀원들에게) 리포트 쓸 때는 말이지 이건 저렇게 하고 저건 저렇게 하고.. 그리고 전문용어 영어 단어같은 거 그냥 영어로 쓰라고. 다 알아들으니까 말이야.
창우: (속으로 투덜투덜...) 얼마나 다 영어로 쓰나요?
팀장모씨: 전부 다. 여기 단어 몇개 영어로 나온다고 문제 될거 없잖아? 오히려 엔지니어들한텐 그게 읽기 좋다고.
창우: 그거보다 훨씬 많아요. encoding, decoding, source code, compile, build, bug, editor, debugger, typing, .... 한글은 몇 개 안 남네요. (다 고쳐서 한 줄에 영어단어가 너덧개씩 있는 보고서를 보여준다) 자 이렇게 쓰면 가독성이 좋을까요?
팀장모씨: ... (독해에 어려움을 겪는 모씨...)
썬의 번역 가이드
썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.
1.4.2한국어로 번역하지 않는 용어들 (Do not translate)이 부분은 내가 오픈오피스 번역 중에서 가장 못 마땅하게 생각하는 부분이다. 번역 가이드의 다른 부분은 몰라도 위 사항은 절대 따르지 않고 번역이나 음역하기를 권장한다. 특히 Gnome은 영문 그대로 쓰지 말고 "그놈"이라고 표기하기를...
1. 고유 명사나 소프트웨어, 운영 체제 등의 고유 이름
MySQL (ODBC) -
PostgreSQL
MySQL (JDBC)
Mozilla
Adabas D
Microsoft Outlook
Oracle JDBC
Microsoft Windows
JDBC
LDAP
ODBC
Evolution
XStorable
...
Branding
"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 3가지 방법 중에 하나를 선택하게 될 것이다.
- 본래 브랜딩의 철자를 그대로 가져간다.
- 본래 브랜딩을 그 나라의 언어에 맞게 음역한다.
- 본래 브랜딩을 포기한다. 새로운 브랜드를 만들어 낸다.
실제로 한국에 진출한 글로벌 기업은 어떤 전략을 사용했을까?
영어 약자로 된 브랜드는 (KFC, HP, ...) 음역으로 쓸 수 없기 때문에 다른 선택이 없지만, 그 외에 1의 선택을 하는 경우는 의외로 별로 많지 않다. 길거리에서 영어로 가득한 간판을 보긴 하지만, "우리 STARBUCKS는..."이라고 회사 소개를 하지는 않는다. 거의 모든 회사가 "맥도나알드~"라고 멋드러지게 한글 음역을 이용하지 TV 화면을 영어로 가득 채우지는 않는다. 우리들도 일상 생활에서 "아웃백에서 봐요"라고 문자를 보내지 "Outback에서 봐요"라고 쓰지는 않는다. (게다가 1바이트 더 많다!)
3번째로 새로운 브랜드를 만들어 내는 경우도 잘 찾아보면 드물지 않게 볼 수 있다. 햄버거 체인점인 하디스(Hardees)는 미국의 찰스 쥬니어를 가져온 것인데 찰스 쥬니어는 말도 길어지고 왠지 맛있는 느낌이 안 나니까한국판에서는 새로운 말을 만들어 냈다. 한솥도시락은 일본의 도시락 체인점인 혼께가마도야의 메뉴와 시스템과 인테리어를 그대로 가져왔지만 이름은 우리말로 다시 지었다.
1과 2의 장단점을 적당히 취하는 경우도 볼 수 있다. 많이 사용하는 방법이 로고는 원래 영어가 들어간 로고를 무슨 그림 마냥 그대로 사용하면서 글자로 쓸 경우는 한글 음역을 사용하는 방법이다. (스타벅스, 커피빈, 아웃백 스테이크하우스, 리바이스, ...) 원래 로고와 한글 로고를 둘 다 만들어 놓거나 원래 로고의 영어에 한글 표기를 추가하는 식으로 동시에 사용하면서 글자로 표기할 때는 한글 음역을 쓰는 경우도 있다. (맥도날드, 버거킹, 철수하기 전의 월마트, ...)
하지만 로고나 간판을 원래 브랜드 그대로 이용하는 경우는 많아도, 일반 광고나 보도자료 등의 일반 텍스트 문서에서 영어 표기를 고집한 회사는 한국에 들어온 글로벌 기업중에 거의 없었다. (약자로 된 브랜드는 제외.) 몇가지 예외가 있으니 바로 소프트웨어 회사들이다. 마이크로소프트는 양지사 와의 상표 분쟁에서 패소했기 때문인지는 몰라도 "Windows 95" 이후 계속해서 한글마이크로소프트의 제품 설명에서도 "Microsoft Windows" 영문 표기를 고집하고 (그 전에는 "윈도우"라고 사용했다) 오피스의 경우에도 프로그램 메뉴에까지 "Microsoft Word"라고 영문으로 들어가 있다. 어도비, 오라클 등등 모두 영문 표기를 고집하고 있다. (하지만 광고나 그렇지 절대로 언론은 영문 표기로 보도해 주지 않는다.)
한글로 음역해서 쓰는 이유는 그게 세종대왕과 주시경선생께서 기뻐하시는 옳은 방향이라서가 아니라, 그게 더 올바른 브랜딩 전략이기 때문이다. 잠재적인 소비자들에게 쉽게 인식되고, 쉽게 기억되고, 눈에 잘 뜨이는 게 좋은 브랜드이다. 현재 평균적인 한국 소비자들은 왠만큼 교육 수준이 높은 경우에도, 영어 그대로 쓴 브랜드는 기억하거나 인식하기에 힘든 게 현실이다. 물론 본래 브랜드를 지역화하는 비용도 있고 본래 브랜드가 손상될 우려가 있어서 본래 로고를 남겨두고 일부만 지역화한다든지 선택을 할 수는 있다. 하지만 트레이드오프로 그런 선택을 할 수는 있어도 영어로 쓰는 게 한글로 쓰는 것보다 더 원래 의미를 전달하니까 좋은 브랜딩이다라고는 할 수 없다. 구찌, 버버리, 까르티에의 영문 철자를 기억하고 있는 사람이 얼마나 될까? (소프트웨어 회사들이 예외적인 전략을 쓰는 이유는 한국의 소프트웨어 소비자들이 영어에 익숙하기 때문일까?)
에볼루션은 있는데 Evolution은 어딨지
썬의 번역 가이드는 첫째로 한국에 진출한 브랜드들이 취한 현실과 다르다. 위에서 말한 것처럼 한국에 진출한 글로벌 기업의 대부분은 브랜드를 한글로 음역했다. 특히 그놈 에볼루션은 분명히 (내가!) 한글로 "에볼루션"이라고 음역했고 한국어 데스크탑에는 프로그램 정보 창을 보지 않는 한, Evolution이라는 단어도 찾아보기 힘든데 예제에까지 "Evolution"이라고 써 놓는 건 맞지 않다.
또 (소프트웨어 회사들의 상업용 소프트웨어들도 그렇지만) 그 지역의 언어로 표기하는 편이 쉽게 인지되고 기억되는 더 좋은 브랜딩인데도, 왜 OpenOffice.org, Firefox 따위의 번역도 그 "OpenOffice.org", "Firefox"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)
2007년 12월 20일 목요일
번역 메세지에서 남용되고 있는 말
기반 (based on, derived)
위하여 (to ~, for ~)
~하는 것이 (to ~, what/which/that ~)
적절한/적절히 (proper, appropriate, accordingly, ...)
제공 (provide, offer, come with, ...)
설정 (option, configure, preference, property, ...)
포함 (have, contain, exclude, consist of, ...)
"A를 기반으로 하는 적절한 B를 포함하기 위해 C 설정하는 것을 제공합니다"
위의 단어를 합쳐보면 이 정도 문장이 되는데... 의외로 많은 메세지 번역에서 제공하고 설정하고 포함하는 정도로 상당히 수많은 영어 단어를 번역하고 있다. 형태소 분리 프로그램이 제대로 돌아가는 게 있다면 PO 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데.. 나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.
해결 방법은 평소에 폭넓은 독서와 글쓰기를... (논술 시험?)
위하여 (to ~, for ~)
~하는 것이 (to ~, what/which/that ~)
적절한/적절히 (proper, appropriate, accordingly, ...)
제공 (provide, offer, come with, ...)
설정 (option, configure, preference, property, ...)
포함 (have, contain, exclude, consist of, ...)
"A를 기반으로 하는 적절한 B를 포함하기 위해 C 설정하는 것을 제공합니다"
위의 단어를 합쳐보면 이 정도 문장이 되는데... 의외로 많은 메세지 번역에서 제공하고 설정하고 포함하는 정도로 상당히 수많은 영어 단어를 번역하고 있다. 형태소 분리 프로그램이 제대로 돌아가는 게 있다면 PO 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데.. 나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.
해결 방법은 평소에 폭넓은 독서와 글쓰기를... (논술 시험?)
2007년 12월 11일 화요일
GtkBuilder 탐험
GTK+ 2.12에 포함된 GtkBuilder 기능에 대해 탐험해 보면,
GtkBuilder는 libglade의 대체품이라고 말할 수 있다. GUI의 구성을 코드 내에서 하지 않고 XML 파일로 기술하고 런타임에 그 XML을 읽어들여서 UI를 구성한다. libglade를 써 봤다면 별로 새로운 건 아니겠지만, 일단 GTK+에 포함되어 버렸으니까 추가로 libglade를 링크할 필요가 없다는 장점이 있다. 또 일부 glade가 커버하지 못하고 있는 TreeView 따위의 복잡한 위젯도 쓸 수 있다. 요즘에 하드코딩으로 GTK+ 코딩하는 사람들이 거의 없다는 걸 생각해 보면 충분히 GTK+에 포함될 만한 기능이다. (GTK+가 너무 커진다 싶으면 언젠가 메이저 버전 뒤엎겠지.)
간단히 맛보기 필요한 소프트웨어: GTK+ 2.12 이상, pygtk (컴파일이 귀찮으므로)
위 파이썬 코드를 실행하면 이런 창이 나온다.
libglade를 사용해 봤다면 XML 문법만 다르지 별 다른 점을 느끼지 못할 것이다. 또 대부분의 glade 파일은 gtk 2.12에 포함되어 있는 gtk-builder-convert 프로그램을 이용해 GtkBuilder용 XML 파일로 변환할 수 있다. ui.glade라는 파일로 저장을 했다고 하면,
GtkBuilder의 장점은 "눈에 보이지 않는 오브젝트"를 정의할 떄 나온다. 특히 libglade를 사용할 때는 UI 디자인에서 지정하지 못하고 코딩으로 해결해야 했던 복잡한 위젯, 특히 모델/뷰/컨트롤러 개념이 필요한 TreeView, ComboBox 따위의 "모델"을 XML 파일에 집어 넣을 수 있다. 이 부분때문에 디자인과 프로그램이 완전히 분리하지 못했던 많은 코드를 분리할 수 있다.
위의 XML 파일을 마찬가지의 python 코드로 돌리면,
이렇게 스트링-숫자 형식의 "모델"과 cwryu/crew/... 따위의 데이터를 포함할 수 있다.
현재 그놈 프로그램은 거의 glade만을 사용하고 있다. 내년 3월이나 9월 릴리스에서 libglade에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.
GtkBuilder는 libglade의 대체품이라고 말할 수 있다. GUI의 구성을 코드 내에서 하지 않고 XML 파일로 기술하고 런타임에 그 XML을 읽어들여서 UI를 구성한다. libglade를 써 봤다면 별로 새로운 건 아니겠지만, 일단 GTK+에 포함되어 버렸으니까 추가로 libglade를 링크할 필요가 없다는 장점이 있다. 또 일부 glade가 커버하지 못하고 있는 TreeView 따위의 복잡한 위젯도 쓸 수 있다. 요즘에 하드코딩으로 GTK+ 코딩하는 사람들이 거의 없다는 걸 생각해 보면 충분히 GTK+에 포함될 만한 기능이다. (GTK+가 너무 커진다 싶으면 언젠가 메이저 버전 뒤엎겠지.)
간단히 맛보기 필요한 소프트웨어: GTK+ 2.12 이상, pygtk (컴파일이 귀찮으므로)
import gtk
builder = gtk.Builder()
xml = '''
<interface>
<object class="GtkWindow" id="cwwindow">
<child>
<object class="GtkButton" id="cwbutton">
<property name="label">Build Me</property>
</object>
</child>
</object>
</interface>
'''
builder.add_from_string(xml, len(xml))
win = builder.get_object('cwwindow')
win.show_all()
gtk.main()
위 파이썬 코드를 실행하면 이런 창이 나온다.
libglade를 사용해 봤다면 XML 문법만 다르지 별 다른 점을 느끼지 못할 것이다. 또 대부분의 glade 파일은 gtk 2.12에 포함되어 있는 gtk-builder-convert 프로그램을 이용해 GtkBuilder용 XML 파일로 변환할 수 있다. ui.glade라는 파일로 저장을 했다고 하면,
$ /usr/bin/gtk-builder-convert ui.glade ui.xml
$ python
Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> builder = gtk.Builder()
>>> builder.add_from_file('ui.xml')
>>> builder.get_object('window1').show_all()
>>> gtk.main()
GtkBuilder의 장점은 "눈에 보이지 않는 오브젝트"를 정의할 떄 나온다. 특히 libglade를 사용할 때는 UI 디자인에서 지정하지 못하고 코딩으로 해결해야 했던 복잡한 위젯, 특히 모델/뷰/컨트롤러 개념이 필요한 TreeView, ComboBox 따위의 "모델"을 XML 파일에 집어 넣을 수 있다. 이 부분때문에 디자인과 프로그램이 완전히 분리하지 못했던 많은 코드를 분리할 수 있다.
<interface>
<object class="GtkListStore" id="treemodel">
<columns>
<column type="gchararray"/>
<column type="gint"/>
</columns>
<data>
<row>
<col id="0">cwryu</col>
<col id="1">2</col>
</row>
<row>
<col id="0">crew</col>
<col id="1">1</col>
</row>
<row>
<col id="0">clue</col>
<col id="1">3</col>
</row>
<row>
<col id="0">None of the Above</col>
<col id="1">4</col>
</row>
</data>
</object>
<object class="GtkWindow" id="window1">
<child>
<object class="GtkTreeView" id="cwbutton">
<property name="model">treemodel</property>
<child>
<object class="GtkTreeViewColumn" id="column0">
<property name="title">Name</property>
<child>
<object class="GtkCellRendererText" id="r0"/>
<attributes>
<attribute name="text">0</attribute>
</attributes>
</child>
</object>
</child>
<child>
<object class="GtkTreeViewColumn" id="column1">
<property name="title">Number</property>
<child>
<object class="GtkCellRendererText" id="r1"/>
<attributes>
<attribute name="text">1</attribute>
</attributes>
</child>
</object>
</child>
</object>
</child>
</object>
</interface>
위의 XML 파일을 마찬가지의 python 코드로 돌리면,
이렇게 스트링-숫자 형식의 "모델"과 cwryu/crew/... 따위의 데이터를 포함할 수 있다.
현재 그놈 프로그램은 거의 glade만을 사용하고 있다. 내년 3월이나 9월 릴리스에서 libglade에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.
2007년 12월 4일 화요일
아시나요 - 데비안 미러
ftp.debian.org 망가진 기념으로 잘 알려지지 않은 진실을 써 보면:
- 데비안 메인 사이트 ftp.debian.org -- 아니다. 이 사이트는 데비안 메인 사이트가 아니라 1차 미러의 하나일 뿐이다. 마스터 사이트는 외부에서 접근이 불가능하다.
- 그래도 ftp.debian.org가 제일 안정적이다 -- 아니다. 지금 하드 공간이 모자라서 업데이트가 안 되는 상태이고, 다른 1차 미러들은 멀쩡하다.
피드 구독하기:
글 (Atom)