Calm Shouting!

ODF

최근 정통부가 ODF(Open Document Format)를 행정업무의 문서 표준으로 채택하는 것을 추진하겠다는 뉴스가 나왔다. KLDP에서는 이를 지지하는 서명운동을 여기에서 펼치고 있다. 물론 나도 지지한다는 댓글을 달았다.

ODF 포맷은 여기에서 볼 수 있는 것과 마찬가지로 XML(eXtensible Markup Language)을 사용하는 문서용 포맷이다. 파일 구조가 공개되어 있기 때문에 누구나 이 포맷을 읽고 쓸 수 있다. XML 기반이기 때문에 문서의 내용이 텍스트 포맷으로 저장되어 있다는 면도 (최소한 작은 크기의 문서에서는) 문서 크기 대비 파일 크기가 작아질 수 있다는 생각도 든다.

현재는 OpenOffice.org, KOffice, StarOffice등에서 기본적으로 지원하고 있고, google docs에서도 지원하고 있다. MS Office의 경우에는 이 플러그인을 통해 파일 포맷 변환을 할 수 있다.

ODF를 지지하는 이유는 간단하다. 정부의 표준 문서 포맷으로 HWP가 사용되고 있기 때문에 아래아한글이 없으면 행정 관련 업무를 아예 할 수 없는 상황이고, 이런 상황은 모든 국민이 특정 회사의 특정 제품을 구매하도록 강요하고 있기 때문이다. 실제로, 정부 부처의 홈페이지를 가 보면 (일반 텍스트로도 충분히 전달 가능한) 간단한 공고조차 “첨부한 파일을 참조하세요”라는 말과 함께 hwp 파일을 올려놓은 경우가 굉장히 많다. 물론 정보를 보는 것은 무료로 배포되는 뷰어만으로도 가능하다고 말할 수 있다. 그러나, 정부에 어떤 제안서를 제출할 때는 반드시 hwp 파일을 편집해야 하기 때문에 아래아한글을 구입하지 않고서는 제안서를 제출할 수 있는 방법이 없는 것이다.

이런 상황에서 ODF가 행망용 문서 표준이 된다면, 어떤 사람이든 어떤 환경에서든 문서를 읽고 편집할 수 있게 되며, 특히 자신이 원하는 프로그램에서 그 일을 할 수 있게 된다. 닫힌 포맷을 이용한 닫힌 경쟁 을 하는 것이 아니라 열린 포맷으로 열린 경쟁을 할 수 있게 되는 것이다.

아래아한글은 이 포맷을 이용해서 지금까지 높은 시장 점유율을 얻을 수 있었다. 한때는 세계적으로 MS 워드에 맞서 경쟁할 수 있는 토종 워드프로세서로는 유일하다는 점을 홍보에 활용하기도 했었다. 그런 측면이 기술적인 경쟁을 유도하고 실제 지금까지 꽤 좋은 워드프로세서를 만들어온 바탕이 되었음을 부정할 수는 없다. 그러나, 이 상황을 살펴보면 구글과 네이버의 현 상황이 자연스럽게 떠오른다.

구글과 네이버

구글이 한국 시장을 평정하지 못하는 가장 큰 걸림돌은 바로 네이버라고 볼 수 있다. (다음이나 네이트같은 곳도 있다. 그냥 통칭해서 네이버라고 하자) 그런데, 네이버가 한국에서 구글을 이길 수 있는 가장 큰 무기는 바로 한국어라는 장벽이다. 한국에만 적용되는 특수한 환경이 네이버의 버팀목이 되고 있는 것이다. 이 사실에서 인정할 수 밖에 없는 슬픈 현실은 네이버가 세계 시장에서 성공할 수 있는 요소를 갖고 있지 못하다는 것이다. 아니, 어쩌면 세계 시장에서 성공해야 할 이유나 필요가 없기 때문에 그런 것을 고려하지 않았을 수도 있다.

아래아한글이 한국의 특수한 상황을 통해 성장하면서 자신의 영역을 한국에 국한시킬 수 밖에 없었던 것처럼 네이버도 마찬가지라는 것이다. 이러한 예는 MP3 플레이어, 리눅스 배포판 등에서도 있었다. 한국의 기술이 충분한 경쟁력을 가질 수 있는 기회가 있었음에도 불구하고 한국어 혹은 한글이라는 특수한 환경에 자신의 경쟁력을 한정하다보니 결국 한국의 좁은 시장에서 경쟁할 수 밖에 없고, 세계시장에 도전할 수 있는 기회를 잃게 된 예 말이다.

웹 2.0이라는 화두 앞에서 작아지기만 하는 한국의 IT 상황은 바로 이런 현실의 반영이라고 생각된다. 한국의 IT 인프라가 최고였을 때, 세계적으로 경쟁할 수 있는 수많은 아이디어와 화두를 가지고 있었지만 어느 것도 웹 2.0 시대를 이끌어가는 리더가 되지 못했다. 어느 블로그였는지 잘 기억이 나지 않지만, 판도라가 만약 active X와 주민등록번호로 등록하는 쓸데없는 장벽이 없이 영어 서비스로 제공이 되었더라면 지금의 유튜브의 자리를 차지하게 되었을지 모른다는 요지의 글을 읽고 크게 공감했던 기억이 난다.

웹 2.0 시대를 규정하는 정신은 집단 지성 이라는 말에 있고, 이 바탕에는 공유 라는 것이 있다. 많은 사람들이 제약없이 생각을 공유하기 위해서는 열린 포맷이 무엇보다 중요하다. 블로그의 폭발이 RSS(Really Simple Syndication) 이라는 포맷의 성공에 기인한 것처럼. 그래서 네이버와 다음은 자신의 서비스들을 하나씩 열고, 이것들을 매쉬업하도록 장려하고 있는 것이다. 이제 게임의 법칙을 깨닫고 있는 것이다.

결론

그래서, 한글과컴퓨터도 깨달아야 한다. 열린 포맷에서의 열린 경쟁이 피할 수 없는 대세이며, 이 경쟁에서 승리하는 것이 세계 시장에서 성공할 수 있는 더 큰 기회를 제공할 수 있다는 사실 말이다. ODF 포맷의 행망 문서 표준 선정은 이런 경쟁을 직시하게 만들어 주는 신호탄이 될 것이다.

사실 한국이라는 특수한 상황을 성공의 요소로 가지고 있는 모든 서비스들이 세계와 경쟁해야 하는 것은 아니다. 그러나, 한국에서 1등을 하는 곳이라면 세계에서 1등을 할 수 있도록 노력해야 하는 것은 당연한 일이고, 그러기 위해서는 세계의 열린 경쟁 속으로 뛰어들어야 한다. 최소한 언어와는 상관 없이 경쟁을 이겨낼 수 있는 기술적 요소를 갖추기 위해 노력해야 한다.

SimpleLog는 Ruby on Rails를 이용한 또 다른 블로그 프로그램이다. 대표적인 RoR(Ruby on Rails) 블로그 프로그램인 typo mephisto 그리고 radiant에 대해서는 이미 이 글에서 비교를 한 바 있다. 내가 한 때는 typo를 썼었고, 나중에 mephisto로 약 두 달간 블로그를 운영해 본 바가 있으니, radiant를 오랜기간 써 보지 않았을 뿐 (그냥 설치만 해 봤었다) 모두 사용해 본 경험이 있다고 할 수 있다.

그런데, SimpleLog의 경우에는 앞의 세 프로그램들에 비해 더욱 블로그 쪽에 특화되어 있고 무엇보다도 사용자 편의 기능들이 잘 구현이 되어 있는 것을 알 수 있었다. Movable Type의 데이터로부터 이전할 수 있게 되어 있고, wordpress나 textpattern으로부터 Movable Type 데이터 형태로 백업할 수 있는 스크립트도 공개가 되어 있으니, 결국 wordpress나 textpattern으로부터 simplelog로 이전하는 것은 아무런 문제가 없다. 실제로 내가 사용하고 있는 textpattern의 데이터를 옮기는 것도 아무 어려움 없이 쉽게 할 수 있었다.

여기에 자세하게 적어놓은 것과 마찬가지로 simplelog의 가장 눈에 보이는 단점 중 하나는 테마에 관한 것이다. 일단 기본 테마가 하나 제공이 되는데, 테마를 바꾸려면 rhtml 파일을 수정해야 한다. Admin 패널에서 템플릿 기능을 제공하는 것이 일반적인 블로그 프로그램들의 특징인데, 이런 기능을 제공하지 않는 것이다. 물론 rhtml이 어려운 것이 아니니 다른 프로그램의 템플릿을 수정하는 것보다 어려울 것도 없지만, 일단 접근하는데 있어서 좀더 어려운 것은 분명한 사실이다.

내가 보기에 simplelog의 가장 큰 장점은 다음 두 가지이다.

1. 깔끔한 Admin 인터페이스
2. 자동화된 업데이트

Admin 인터페이스에 관한 한 어느 프로그램보다도 정리가 잘 되어 있고, 보기에 깔끔한데다가, 모든 메뉴가 명확하게 이해되는 구조로 되어 있다. 누가 봐도 이 인터페이스에서 모호한 점을 찾기는 어려울 것이다.

그리고 업데이트가 자동으로 된다는 것은 또다른 중요한 장점이다. 다른 프로그램들의 업데이트가 어렵지는 않지만 꽤 귀찮은 일이기 때문에, 자동화된 업데이트 시스템이 있는 것은 중요한 가치가 있다. 물론, 소스를 마음대로 수정해서 쓰는 경우라면 어렵겠지만, 일반 유저가 소스를 건드릴만한 일은 없으니까.

트랙백 기능이 따로 구현되어 있지 않(은 것 같)고 Ping-o-matic에 ping을 보내는 것만 되어 있다는 점이 아쉽기는 한데, 그건 어차피 textpattern에도 없는 기능이니까 뭐 그렇다고 넘어갈 수 있다. 그동안 textpattern에서 고생했던 갤러리 기능의 경우에도, 결국 flickr에 존재하는 photostream에 링크를 거는 것으로, 굳이 thumbnail을 보여주고 싶다면 그냥 Square (75×75) 그림으로 링크를 여러 개 걸면 되니까 귀찮긴 해도 문제가 될 것 까지는 없다고 볼 수 있다.

지금 사이드바를 보니 이것저것 내용이 많아 보여도 결국은 tag cloud 기능을 제외하면 문제가 되는 것이 전혀 없다. 사이드바의 기능을 위해서는 typo와 같은 형태로 만들지 않는 한, 누가 어떤 테마를 만들어서 올려 놓더라도 결국은 그 테마를 수정하지 않을 수 없음(textpattern도 마찬가지이다)을 생각해 보면 테마 문제는 별로 큰 문제가 아니다.

결국, 옮길 마음이 있느냐가 가장 중요한 변수라는 말. 지금 쓰고 있는 디자인을 rhtml로 다시 써야 한다는게 귀찮은 일이니까 일단은 옮길 마음이 내키지가 않는다. 그래도 언젠가는 한 번 더 시도해 볼 수 있을 듯 하다.