구글을 이용한 나만의 검색엔진 만들기

구글은 특정 사이트에서 이용가능한 검색이 가능한 서비스를 지원하고 있다. 개인화 검색이라고 할만한데, 이러한 서비스들을 이용하면 자신의 사이트를 위한 검색창을을 붙일 수 있다. 이미 field 별 검색을 오래전부터 지원하고 있는 구글임을 생각할 때, 이러한 서비스를 개발하는건 크게 문제가 되지 않았을 것이다. 예를 들어서 pthread를 포함한 문서를 www.joinc.co.kr 사이트내에서만 검색하길 원한다면 site:www.joinc.co.kr pthread 하는 식으로 field를 지정할 수 있었다. 그렇다면 iframe만 적용하면 되니, 구글 입장에서도 이러한 사이트 전용 검색서비스를 만드는게 어렵진 않았을 것이다. 다음은 사이트 전용 검색엔진을 만드는 방법들로 필자의 사이트에 실제 활용하고 있는 서비스들이다.

검색을 위한 Adsense

Adsense는 구글의 광고서비스중에서 전체 광고 수익의 50%가량을 차지하는 중요한 서비스다. 이 서비스는 사용자의 페이지의 성격에 맞는 광고를 게재하고 이를 클릭하면 과금하는 방식인데, 검색창을 통해서 광고수익을 낼 수 있도록 하고 있다. 사이트에 검색창을 달아 놓고, 이를 통해서 검색하면, 검색어와 관련있는 광고가 뜨고 이를 클릭하도록 유도하는 방식이다.

검색을 위한 Adsense를 사용하기 위해서는 먼저 Adsense에 가입해야 된다. 과정은 매우 간단하다. 그러면 Wizard 형식으로 간단하게 사이트에 삽입가능한 HTML 형식의 검색코드를 만들 수 있는데, 이걸 가져다가 붙이기만 하면 된다. 검색코드에는 검색결과를 어떤 사이트에서 찾을 건지를 결정할 수 있다. 또한 자신의 사이트내에 검색결과가 삽입되게 할 수도 있다. 아래는 필자의 사이트에 있는 검색을 위한 Adsense인데, 직접 검색을 해보기 바란다. 어떤 형식으로 사이트에 붙이는지 알 수 있을 것이다.

	Web joinc

구글 co-op

검색을 위한 Adsense를 이용하는 방법도 괜찮기는 하지만, 애초에 광고를 위한 서비스라서 개인화 검색 지원에 좀 취약한면이 있다. 또한 과금과 관련된 서비스라서 이것 저것 기입해야 하는 것이 많은 것도 불만이다. 그렇다면 구글 co-op를 이용하길 바란다.

gmail 계정만 가지고 있으면, 간단하게 만들 수 있다. 검색에 포함시킬 사이트, 검색에서 제외시킬 사이트 등을 지정할 수 있으며, Look and Feel 도 변경가능하다. Adsense 계정이 있을 경우 광고를 노출 시킬 수도 있다. 그리고 Collaboration 이라는 기능도 있는데, 이걸 이용하면 검색창을 다른 사이트에도 게재할 수 있다. 기본적인 성능으로 봤을 때는 검색을 위한 Adsense로도 필요한 것을 다 할 수 있기는 하지만, 구글 co-op가 아직 베타서비스이고 개인화 전용 서비스라는걸 감안한다면 앞으로 더 유용하게 사용할 수 있으리라 생각된다.

다음은 필자의 구글 co-op 테스트 페이지다. http://www.joinc.co.kr/custom.html 기존에 구축해논게 있어서 당분간은 검색을 위한 Adsense를 사용할 계획이다.

구글 블러거 BETA

구글 블러거 BETA 가 발표되었다. 구글은 일반적으로 사람을 끄는 힘이 부족한 것으로 알려져 왔었다. 비록 구글의 검색엔진의 검색결과가 최고의 품질을 보증해 줄 수 있다고 하더라도, 사용하는 사용자가 적으면 말짱 도루묵. 구글 블러그는 인터넷 사용자들을 적극적으로 구글 도메인으로 끌어모으기 위한 중요서비스 중 하나다. - 이러한 서비스로는 Gmail과 유튜브가 대표적일 것이다. -

필자는 한달전부터 블러그를 사용하기 시작했다. 그전에는 블러그 자체를 사용해본적이 없으니, 구글 블러거가 최초로 사용해본 블러그 시스템이라고 할 수 있다. 사실 구글 블러거도 사용할 필요는 그리 느끼지는 못했지만 google docs 에서 작성된 문서를 바로 개인이 운영하는 joinc wiki와 구글 블러그로 publish할 수 있는 기능이 맘에 들어서 사용하게 되었다. 이렇게 몇번 post를 생성하다 보니, 나름 블러그도 일상생활에서 활용하는 수준까지 된거 같다. -그래봤자 한달 남짓한 블로거 생활이지만-

어제인가? 블러그로 남기고 싶은 글이 있어서 구글 블로거에 접속했더니, google blogger beta가 떳으니 사용해 보고 싶음 한번 사용해보라고 메시지가 뜨는 것이였다. 한번 beta로 옮기면 이전 구글 블러그로 되돌아가는 건 불가능 합니다. google_docs의 publish 기능을 사용할 수 없습니다. 라는 경고 문구가 기분을 찝찝하게 했지만 호기심에 beta 사용자로 등록을 했다.

달라진점

가장 눈에 띄는 점은 블러그 템플릿을 관리하는 기능이 한결 직관적이고 강력해 졌다는 점이다. 이전 버젼에서의 템플릿은 템플릿 선택하고 나면 거의 수동으로 자신의 블러그를 디자인 했어야 했는데, Beta에서는 Ajax를 이용해서 일반 애플리케이션 제작하는 것처럼 드래그앤 드롭으로 아이템을 배치하고, 그 결과를 즉시 확인할 수 있다.


마우스의 드래그앤 드롭으로 메뉴를 자유롭게 배치할 수 있으며, 사용자 정의 메뉴를 추가할 수도 있다.


변경내용을 실시간으로 확인할 수 있다.

구글 블러거의 템플릿을 이용하니 나름대로 홈페이지를 꾸미는 재미가 느껴진다. 지금은 썰렁한 모양을 보여주고 있는데, 시간이 생기면 좀 더 그럴듯하게 바꿔봐야 겠다.

구글은 뭐 먹고 사나

누구나 궁금해 하는 내용일 것이다. 구글은 국내의 다른 검색관련 회사가 그러하듯이 다양한 검색서비스를 제공하지 않는다. 말이 나왔으니 얘기인데, 검색엔진과 검색서비스는 전혀 다른 개념이다. 구글에서 제공하는 google.co.kr 은 검색엔진이다. 반면 국내의 네이버나 다음이 제공하는 검색은 '검색 서비스로 검색엔진을 통해서 축적된 데이터를 가지고 이를 서비스화 한것들이며, 대부분의 수익이 서비스에서 발생한다.

예를 들어보자면, 네이버의 검색엔진관련된 카테고리는 웹 검색이며, 검색 서비스와 관련된 카테고리는 통합 검색이다. (아마도)90%이상의 유저가 통합 검색을 통해서 검색을 하고 있다. 네이버는 이 제어가능한 서비스를 통해서 이런 저런 수익을 창출하는 것이다.

그렇다면 사실상 검색엔진을 제공한다고 생각되는 구글은 도대체 어디에서 수익을 창출하는 것일지 궁금할 것이다. 그것은 다름아닌 광고이다. 여러분은 아마도 아래와 같은 광고를 본적이 있을 것이다.

google에서 제공하는 Adsense라 는 광고 서비스인데, 요즘에는 국내사이트에서도 심심찮게 볼 수 있을 것이다. 언뜻 보면 대단히 한심스러워 보일 수도 있는 썰렁한 광고다. 도대체 저런걸로도 돈이 되려나라고 의구심을 가질 수 도 있을 것같다. 그러나 이 지극히 썰렁해보이는 Adsense 광고 시비스로 구글이 일년에 벌어들이는 액수는 (구글 수익의 95%정도를 차지하는 광고서비스로 벌어들이는 금액의 45%정도) 2조에 육박하는 금액이다.

그렇다 구글은 광고로 먹고사는 것이다.

저런 썰렁한 텍스트 기반의 광고로 1조라니 놀랍지 않은가 ?

구글의 경쟁력은 어디에서 오는가

어떤 회사는 대단한 일을 하는 것 같은데도, 수천 수억 정도다. 그런데 어떤 회사는 별거 아닌거 같은 일을 하는데도 했다하면 수백, 수천억이다. 구글이 후자의 경우인데, 이러한 경쟁력은 어디에서 오는 것일까.

그것은 바로 훌륭한 검색엔진에 있다. 검색에서 검색서비스의 질은 얼마나 많은 데이터를 확보하고 있느냐로 결정된다. 1억건의 웹페이지를 색인하고 유지할 수 있는 엔진과 80억건의 웹페이지를 색인할 수 있는 엔진을 가진 회사와는 당연하지만 경쟁자체가 안된다. 지역적 특성을 살려서 웹 서비스를 이용해서 좁은지역에서는 승부를 걸 수 있을 지 모르지만, 절대 글로벌 시장에서 경쟁을 할 수는 없다.

구글의 경쟁력은 수십억건의 웹문서를 색인할 수 있는 검색엔진 기술에서 시작된다. (그러한 기술을 획득할 수 있게 만든 기업문화 인재활용 등에 대한 얘기는 하지 않겠다)

30억건의 웹문서를 위한 검색엔진을 위해서 중요한건 무엇일까 ? 색인및 검색 알고리즘이라고 생각할 수 있겠지만, 이건 부수적인 문제다. 효과적인 색인과 검색알고리즘은 내가 알기로도 (현재 2006년) 10년도 이전에 완성된 걸로 알고 있으며, 공개된 검색엔진들 조차도 최신의 알고리즘을 사용하고 있다. 튜닝을 위해서 인자 몇개 바꾸고, log를 sqrt로 바꾸고 이런거 좀 해봐야 별로 티도 안날 정도로 알고리즘은 거의 완성되었다.
문제는 이러한 데이터를 유지할 수 있는 분산 환경 구축 기술을 가지고 있느냐 하는 것이다. 구글은 가지고 있다. 규모가 중요하다는 건데, 여기에서 경쟁력의 차이가 난다. 구글은 MapReduce 프로그래밍 모델을 통해서 추상화된 분산파일 시스템, 분산 수집, 분산 색인등 필요한 기술을 가지고 있다.

서비스가 엔진위에서 만들어지는 거라고 봤을 때, 80억문서를 수집할 수 있는 엔진을 가진 회사에서 만들어지는 서비스와 1억건 문서를 수집할 수 있는 엔진을 가진 회사에서 만들어지는 서비스의 차이는 당연하지만 엄청날 수 밖에 없다. 산술적으로 생각해도 비슷한 서비스를 붙였을때, 80억건의 데이터를 가진 회사는 1억건의 데이터를 가진회사의 80배의 수익을 창출해 낼 수 있을 것이다. 글쎄.. 다른 국내의 포탈이 검색서비스로 얻어내는 수익을 잘 모르기는 하지만 비슷한 서비스에 대해서 저정도의 수익의 차이는 날 것 같은데.. 그렇지 않을까 ?

물론 국내 포탈회사들도 나름대로의 고충이 있었을 것이다. 영어권에서 엔진을 만든 그들과 같을 수가 없기 때문이다. 일단 영어를 사용하는 인터넷인구와 한글을 사용하는 인터넷 인구에서 10배 정도의 차이가 난다. 문서에 있어서는 더 큰 차이가 날 것이다. 당연히 구글과 같은 회사는 규모를 염두에 두고 엔진을 제작할 수 밖에 없었을 것이다.

개인이 사용하는 Adsense ?

구글에게는 엄청난 수익원이 되지만 개개인의 입장에서 봤을 때는 큰돈을 벌기는 힘들다라는건 분명한 사실이다. 상당한 양의 컨텐츠를 포함한 꽤나 유명한 사이트가 아니라면 최소지불금액인 100달러에 도달하는데, 아마도 1년이상이 걸릴 것이다.

Adsense와 관련된 개인사용자의 블러그등을 보면 하루에 2달러를 얻은게 이슈화가 될 정도이다. 호스팅 비용을 얻거나 차 기름값을 버는 정도가 될거 같다.

Adsense로 하루 5달러 벌기 ?

뭐 어쨋든 가능하면 Adsense를 잘활용해서 기름값이나 교통비 정도를 뽑을 수 있으면 좋지 않을까 ? 해서 나름 Adsense로만 하루 5달러를 벌기 위해 필요한 것들에 대해서 생각해 보았다.

전문화된 다수의 컨텐츠. 개인 블러그에 심심풀이로 달아 보는 걸로는 왠만큼 방문객이 있는 블러그라도 1년에 100달러 모으기 힘들 것이다. 서점에 보니 1인 기업을 시작하라라는 제목으로 손쉽게 광고 수익을 얻을 수 있는 방법에 대해서 기술하고 있던데, 내가 봤을 땐 그리 현실성이 없다. 컨텐츠를 전문화 시키고, 꾸준히 관심을 유지하면서 컨텐츠를 생산해야 한다. 적어도 3-4년은 컨텐츠를 생산해야 할 건데, 뭐 이정도면 Adsense로 버는 돈은 문제가 되지 않을 정도의 해당분야의 전문가 수준에 도달할 것이다. 꿩먹고 알먹고인 방식이긴 한데, 3-4년 동안 꾸준히 컨텐츠를 생산할 수 있는 집념을 가지고 있느냐가 문제가 될 것이다. 우리나라에 특정 전문분야에서 4년이상 컨텐츠를 축적하고 있는 사이트가 몇개나 있는지 생각해보면 될 것이다. 돈벌기 쉽지 않군!!!

일단은 양질의 컨텐츠가 준비되어서 사이트 방문자를 늘여야 한다. 애드센스의 적절한 배치, 기존의 컨텐츠의 재배치를 통한 킬러 컨텐츠의 생산은 부차적인 문제다.

참고로 다음은 분야별 컨텐츠의 점유율이다.

Arts	14.6%	Arts: Music	6.1%
Computer	13.8%	Regional: Noth America	5.3%
Regional	10.3%	Adult:Image Galleries	4.4%
Society	8.7%	Computers: Software	3.4%
Adult	8%	Computers: Internet	3.2%
Recreation	7.3%	Business:Industries	2.3%
Business	7.2%	Regional:Europe	1.8%

원문 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Google/Service/Adsense/GoogleAdsense

Vim으로 외부명령어 실행하기

쉘로 빠져나가기

vim은 매우 강력하지만 또한 그만큼 복잡한 에디터이기도 하다. vim의 강력함을 제대로 이해하려면 수많은 숨겨진 기능들을 익혀야 한다. 이 문서는 이러한 숨겨진(혹은 잘 알려지지 않은)기능중 외부명령어를 실행하는 방법에 대해서 알아보도록 하겠다. vim은 단순히 외부명령을 실행시키는 외에도, 다양한 일들을 할 수 있다.

vim을 좀 사용해 봤다면 :shell 혹은 :sh를 이용해서 쉘로 빠져나가는 법을 알고 있을 것이다. 이렇게 해서 원하는 쉘작업을 하고, 작업이 끝났다면 exit를 이용해서 쉘을 끝내면 vim에디터로 되돌아올 수 있다. 또한 대부분의 *nix 에서, Ctrl+z를 이용해서 쉘로 빠져나갈 수 있다. 이경우 Vim은 백그라운드 상태가 되는데, fg 명령을 이용해서 vim으로 되돌아갈 수 있다(븍그라우드로 빠져나가는 기능은 쉘에서 지원하는 기능이다.).

쉘로 빠져나가지 않고 외부명령어 실행

또한 vim은 쉘로 빠져나가지 않고서도 느낌표 (!)를 이용해서 쉘명령을 실행시킬 수 있다.
:! wc index.html
wc는 문서의 단어와 라인수를 구하는 프로그램이다. 위와 같은 방법으로 굳이 쉘로 빠져나가지 않고서도 index.html파일의 단어와 라인수를 조사할 수 있다. 또다른 응용으로, 여러분이 Perl등의 스크립트를 작성하고 있을 때, vim에서 스크립트가 제대로 작성되었는지 직접확인 할 수도 있다. my.pl이라는 Perl 스크립트를 만들었다면, 다음과 같이 Vim 상에서 테스트 가능하다.
:! ./% 혹은 :! ./my.pl
눈치챘겠지만 %는 자기자신을 가리킬때 사용한다. 이렇게 해서 스크립트를 만들게 되면, 약간식 수정하면서 계속적으로 테스트를 하게 될거다. 다음과 같이 하면 가장 최근에 실행한 명령을 재 실행하게 된다. 타이핑에 걸리는 시간을 절약할 수 있을 것이다.
:! !

명령어 실행결과를 출력하기

느낌표를 사용하면 간편하게 명령을 실행할 수 있지만, 명령의 실행결과가 쉘에 표준출력 되어버린다는 문제가 발생한다. 이럴경우 출력결과물을 편집기에 불러오려면, 마우스를 이용한 copy & paste를 해야 한다. 다행 스럽게도 Vim은 표준출력을 에디터에 바로 복사하는 기능을 가지고 있다.
:r ! ls -al /home/yundream
위와 같이 하면 ls -al /home/yundream 명령의 실행결과가 vim 에디터 화면에 저장이 된다. 이 기능을 잘 이용하면 웹페이지의 내용을 쉽게 긁어와서 편집할 수도 있다.
:r ! w3m http://en.wikipedia.org/wiki/Vi -dump
w3m(:12)은 텍스트 기반 브라우저다. -dump 옵션을 이용하면 브라우징한 웹페이지의 내용을 화면에 뿌려주게 되는데, 위와 같은 방식으로 vim에디터로 내용을 직접 불러와서 편집할 수 있다.

뿐만 아니라 pipe의 사용도 가능하다.
:r ! ls -1 /home/yundream | sort -r

다음과 같이 grep한내용을 에디터로 불러오는 식의 응용은 유용하게 사용할 수 있을 것이다.
:r ! grep string /var/log/apache2/site-error.log

쉘 바꾸기
당신이 리눅스 사용자라면 아마도 bash쉘을 사용하고 있을 것이다. 그러나 쉘을 바꾸고 싶은 경우가 생길 수 있다. 우선은 현재 사용중인 쉘을 확인해야 할건데, 다음과 같이 확인 가능하다.
:set shell ?

그러면 Vim은 shell=/bin/bash 와 같은 출력결과를 보여줄 것이다. 만약 bash대신 csh를 사용하고 싶다면, 다음과 같이 하면 된다.
:set shell=/usr/bin/csh






Firefox의 시장점유율

얼마전 firefox 2.0이 공개되었다. 해서 firefox의 시장점유율이 어느정도 되는지 조사를 좀 해보기로 했다. 다음은 웹통계 조사기관인 onestat 에서 조사한 결과를 보여주는 이미지다.

전체적으로 여전히 IE가 절대적인 강세를 보여주고 있긴 하지만, Firefox 역시 상당한 점유율을 기록하고 있는걸 확인할 수 있다. 특히 유럽과 호주는 20%에 육박하는 점유율을 보여주고 있으며, 이러한 점유율은 꾸준히 증가하고 있는 추세다. 다음의 1년간의 점유율 변화는 IE의 점유율이 지속적으로 떨어지고 있다는걸 보여주고 있다. 1년간 5%의 점유율 변화는 대단히 큰 것이라 볼 수 있다.


아시아와 유럽, 남미지역은 10%이하로 2배이상 낮은 점유율을 보여주고 있다. 우리나라는 7%에도 미치지 못하는 점유율을 보이고 있는데, 브라우저의 접근 자체를 보장받기 힘든 포털 사이트의 영향이 상당히 큰 것으로 생각된다. 이들 지역이 브라우저에 대한 다양성이 결여되면서 전체적으로 낮은 점유율을 보여주는 데에는 정보/통신자원에 대한 인식과 사용문화가 낙후된 때문인거 같다. (반드시 그런건 아니지만)어떤 영역에서든지 다양성이 결여되었다는 것은 그 영역이 그만큼 낙후되었음을 의미한다.

다음은 Google Analytics를 통해서 필자가 운영중인 joinc 에 접근한 브라우저 통계 순위를 보여주고 있다. 사이트의 특성상 Firefox의 접근이 많았을 것을 감안하면, 우리나라에서 firefox의 평균사용율은 7%이내일 거라고 예측가능하다.



그래도 비 IE계열의 브라우저 점유율이 10%정도인걸 보면, 조금씩이나마 브라우저의 다양성이 늘어나고 있는거 같기도 하다. 정확한 자료는 없지만 2-3년전만 해도 IE의 우리나라에서의 점유율은 97%이상이였던 것으로 기억한다.

다음은 유럽에서의 firefox의 점유율을 따로 정리한 결과다.
핀란드 - 38.39%
슬로베니아 - 35.55%
독일 - 30.27%
체코 - 29.29%
슬로바키아 - 28.87%
크로아티아 - 28.01%
헝가리 - 24.54%
폴란드 - 22.6%
에스토니아 - 22.49%
그리스 - 22.08%
오스트리아 - 19.79%

핀란드는 40%에 육박하는 점유율을 보여준다. 리누즈 토발즈와 노키아의 영향일까 ?

저는 Firefox만 사용합니다.!!

이유는 간단하다. IE가 리눅스(:12)에서 돌아가지 않기 때문이다.

Google Reader 사용기

드디어 Google Reader가 공개되었다. 외형상으론 기존의 모습에서 크게 달라진점이 보이진 않지만, 어쨋든 정식으로 발표되었다는데 의의가 있을 거 같다. 필자가 기존에 사용했던 Rss Reader는 Akregate라는 KDE용 RSS Reader이였다. 상당히 쓸만한 RSS 리더이긴 하지만 폐쇄성이라는 데탑 애플리케이션의 한계를 지니고 있었다. 역시 RSS리더는 개방된 웹환경에서 사용해야 제격이리라. 물론 몇개의 웹기반의 RSS 리더기가 있기는 했었다. 가장 쓸만하다고 생각되는게 http://www.3fishes.co.kr 에서 제공하는 FISH라고 하는 RSS리더기 였으나 아직 Beta버젼으로 본격적으로 사용하기엔 인터페이스와 기능에 있어서 문제가 있었다.

구글 RSS 리더기(이하 구글리더기)는 (아마도)내가 생각하기에 현재 나와 있는 RSS리더기 중에서 가장 좋은 인터페이스와 사용자 편의성을 제공하는 것 같다. 기본적인 기능도 충실하고, 몇몇 개선되어야할 부분이 있기는 하지만 인터페이스도 쓸만하다. 하지만 이정도 가지고는 굳이 RSS리더기를 선택할 필요가 있을까 하는 생각이 들 것이다.

구글리더기가 좋다고는 하지만 그렇다고 혁신적이라고 할만한 서비스는 아니다. 비슷비슷한 기능에, 약간 뛰어난 인터페이스를 가지고 있을 뿐이다. 뭐 어떻게 보면 리더기라는거 자체의 목적이 최근 소식을 보여준다는 목적이 거의 전부이기 때문에, 혁신이라고 할만한 발전이 있기는 힘든게 사실이긴 하다. 차라리 RSS가 혁신이엿다고 보는게 맞을 것이다. 그럼에도 불구하고 구글리더기가 다른 리더기에 비해서 가지는 장점은 구글의 다른 서비스들과 연동되며, 동일한 인터페이스를 사용하며 서비스 통합에 따른 편리함을 누릴 수 있다는 점이다. 얼마전에 인수한 유트부의 RSS 같은경우를 보자면, 다른 RSS리더기는 단순히 링크만 보여줄 수 있는데 반해 구글리더기는 굳이 링크를 따라갈 필요없이 리더기 자체에서 동영상을 감상할 수 있다. 하나의 도메인에서 서비스를 유지하기 때문에 가능한 기능일 것이다.

또한 아직 만족할만한 수준은 아니지만 gmail과 연동된다는 점도 장점이다. Gmail의 웹클립에 구글리더의 RSS를 추가하면 편지함의 상단에, 최근의 RSS를 읽어올 수도 있다. 별도의 폴더를 만드는 형식으로 gmail과 완전히 연동되었으면 하는 바램인데, 조만간 기능이 추가될 것으로 생각된다.

구글서비스그룹에 있는 단일 서비스들을 떼어놓고 보자면 비교적 빠른시간내에 개발이 되어서 해당분야를 선도했다는데, 점수를 줄 수 있겠지만 그 자체에 큰 점수를 주긴 힘들 것이다. 무한에 가까운 계정공간을 제공하는 Gmail서비스는 시기에 있어서 약간 늦었을 뿐 다른 사이트들도 이미 다 하고 있는 것들이고, 구글맵스나 RSS리더기와 같은 기능역시 비슷비슷하게 구현하거나 따라갈려고 하고 있다. 구글서비스의 진정한 힘은 역시 발전 가능성에 있어서 타 사이트의 서비스를 능가할 수 있다는데 있을 것이다. 완전히 통합되지 않은 유튜브, Gmai, 구글리더기, 검색서비스(데스크탑, 논문, 웹, 코드검색, Map, 도서), 개인화 홈페이지, Google Docs 등의 서비스가 성공적으로 통합된다면 엄청난 파괴력을 지닐 것이다. 말그대로 네트워크 운영체제가 실현되는 순간이라 할 수 있을 것이다.

프로그래밍이 예술의 영역일까 ?

얼마전에 최소리님의 소리를 본다 라는 공연을 봤어. 예술가가 그렇듯이 대중성을 확보한 연주자는 아니다. 그룹 백두산때부터 드러머로 활약했다고 하니까 수십년정도를 연주자로 활약을 한거 같어 그런데 지금껏 한번도 이름을 들어본적이 없었어. 그러다가 우연찮게 기회가 생겨서 공연을 보게 되었지. 국립극장 해오름관에서 공연을 했었는데, 국립극장정도에서 퍼포먼스를 펼칠 정도면 어느정도 인정받는 예술가라고 할 수 있겠지.

2시간 가까운 공연이였는데, 간단히 말해서 감동 먹었어. 예술이란 이런 거구나, 예술가란 저런 모습을 보여주는 구나 라는 거 말이지. 그 공연을 보면서 예술가란 영혼과 대화를 하는 사람이며, 공연(작품이 될 수도 있지)이란 영혼과 대화하는 위한 과정을 타인에게 보여주는 것 이라고 나름 결론을 내리게 되었어. 예전에도 대략 이런 생각을 하고 있기는 했지만 가슴으로 느꼈다고 보면 될거 같어.

공연을 보고나서, 그렇다면 프로그래밍이 과연 예술이라고 불리울 수 있을까 라는 생각을 해보게 되었지. 역시 나도 프로그래머니까 말이야. 그렇다면 한 사람이 예술가로써 인정받기 위한 그 과정을 알아볼 필요가 있지. 그런데 그러한 과정을 프로그래머를 모델로 해서 알아보기는 좀 힘들단 말이야. 프로그래밍 과정이 저급이라서 그런게 아니고 음악이라든지 미술같은거에 비해서 역사가 짧기 때문에 판단할 자료가 좀 상당히 부족하다는 느낌이 들었거든.

일단 예술가가 되려면 엄청난 노력을 해야 하는건 맞는거 같어, 영혼이란 형체가 없는 거잖아. 그런데, 영혼이 없는 화폭이라든지 북같은 지극히 평범해 보이는 도구를 사용해서 그림과 음악을 만들어내고, 그것을 통해서 영혼을 구체적으로 타인에게 보여주려고 할라치면, 그야말로 엄청난 노력이 필요한 거겠지. 최소리씨의 인생사에 대해서는 잘 모르지만 소리에 미쳐서 학업도 대충 때우고, 백두산의 드러머로써 잘 나갈수 있는 기회를 버리고, 산에 들어가서 도닦으면서 소리를 찾기 위해 정진했다고 들었어. 세상에 나온뒤로도 물론 계속되는 힘든 생활이였겠지. 대충 어떤 생활을 했을지 다들 상상이 되리라 생각되.

그러나 노력만으로 예술가다 아니다를 말하기는 힘들지 싶어. 보통 대중가요를 하는 사람에게 예술가로 불러주진 않지, 뛰어난 가창력을 소유한 가수라든지 만능 엔터테이너라든지 뭐 이렇게 불러주는거 같어. 대중가요를 했던 사람으로써 예술가로 불리우는 소수의 경우도 있는데, 이런 사람들을 보면 어느 시점을 지나서 엔터네이너가 아닌 예술가로써의 그런 길을 걷는 경우가 많지.

아뭏든 노력만 가지고 예술가라고 판단하기 힘들다 하는 이유는, 대중가요 하는 사람들이라고 노력을 하지 않어 ? 성공하기 위해서 엄청난 노력을 하는 많은 가수들이 있지, 연기자도 마찬가지고 그러나 성공했다고 해서 예술가라고 불러주진 않어. 뛰어난 가수, 뛰어난 연기자라고 하지. 어떤 차이가 있는 걸까 ? 내가 봤을적엔 그 에너지가 내부로 향하느냐 외부로 향하느냐의 차이인거 같어. 예술가는 저 깊이에 있는 내면의 영혼을 향해 에너지를 분출하는 사람들이고, 엔터테이너는 외부를 향해서 스킬을 연마하는 사람들이라고 난 생각해.

스티븐 호킹 박사를 예술가라고 하진 않지, 정말 예술적으로 생각한다 라는 식으로 얘기하긴 하겠지만, 이게 여기에서 말하고자 하는 예술과는 다른 뜻이지. 아뭏든 과학자를 예술가라고 하지 않는 이유는 그 에너지가 외부로 표출되는 형태이기 때문이라고 생각해. 우주의 구조와 중력 뭐 이런 바깥의 것들을 탐구하는게 그가 하는 일이지. 자기 내면의 영혼을 찾아나가는 그런건 아니라고 보거든. 다른 기술적인 분야도 그렇고, 그 분야의 마스터를 최고의 박사, 역사상 유래가 없는 등으로 불러주긴 하지만 역시 예술가라고 하진 않지.

그럼 프로그래밍이 예술의 범주에 포함하느냐 ? 난 그렇지 않다고 봐. 창조의 영역이기 때문에 예술이라고 할 수 없어. 창조하지 않는 직업이 어딨어? 모든 학문과 공학이 창조의 영역이지. 프로그래밍이라는 것도 과학과 마찬가지로 외부의 다른 주어진 것을 탐구, 혹은 쉽게 활용하기 위한 기술적인 분야로 봐야지 예술적인 그런 분야로 보는건 좀 그렇다고봐.

그리고 가만히 보면 프로그래밍이 예술의 범주에 속하냐 그렇지 않느냐에 대한 논쟁의 밑바닥에는 기술을 향한 탐구는 예술을 위한 행위보다 열등한 것으로 생각하는 경향이 상당히 있는거 같더라구. 예술하는 사람이라고 소개하면 그럴듯해보이고, 기술자라고 소개하면 그저그런 사람으로 보여서 그러는거 같기도 한데, 그런거에 민감할 필요가 있을까 라는 생각이 들어. 자기가 하는 일을 사랑하고 최선을 다하면 되는거야. 그게 예술이건, 육체노동이건 정신노동이건간에 말이지.

전운 감도는 하반기 '검색 2.0' 개발경쟁

모 처럼 국내 포털들이 기술개발과 관련 마케팅에 힘을 쏟고 있다. 수치화된 알고리즘과 기계적인 로봇에 의한 웹사이트 수집에서 쇼핑검색, 도서검색, 동영상검색 등 다양화의 길을 걷고 있는 구글과 달리 국내 포털들은 그동안 인위적인 배열과 나열에 의존한 통합검색에서 벗어나 검색엔진 본연의 차세대 검색 기술 개발에 총력을 쏟고 있다.

국내 포털 빅3 가운데 하나인 네이트와 싸이월드를 운영중인 SK커뮤니케이션즈가 '집단 지성'을 반영한 검색 엔진 '써플(searchplus.nate.com)'을 새로 선보이면서 네이버의 첫눈 인수 후 국내에서는 보기 드물게 검색엔진 품질 논쟁이 다시 불고 있다.

집단지성과 UCC로 기술의 빈자리를 채워라

웹 2.0을 대변하는 키워드 가운데 '집단 지성'은 자발적 다수에 의해 꾸며지는 세계 최대 온라인 백과사전 '위키피디아(www.wikipedia.org)'가 대표적이다. 위키피디아의 가장 큰 특징은 극단적으로 소수에 의해 조작될 수 있는 정보조차 다수의 지성에 의한 검토를 거치면 최선의 결과물이 만들어질 것이란 '절대 다수 지능에 대한 믿음'이 바탕에 깔려 있다.

일부는 국내 지식 검색 시스템도 '집단 지성'의 예로 들고 있다. 질문과 대답을 하는 과정에 이의제기가 이어지고 다시 반박해가면서 가장 정확한 답을 찾기 위한 노력이 끊임없이 이어진다는 것이다.

새로운 자체 검색엔진 '써플' 베타를 서비스하기 시작한 SK커뮤니케이션즈는 이러한 집단지성의 개념이 기계적인 알고리즘에 의존하는 검색 기술이 채우지 못한 2%를 채울 수 있다고 주장한다.

이 용자가 단순히 검색결과를 받아들이는 기존 검색과는 달리 탐색 과정을 통해 이용자가 검색 결과에 영향을 줄 수 있는 검색이란 설명이다. 특정 검색결과에 대해 이용자가 더 정확하고, 유용한 정보라고 판단되면 ‘플러스’ 버튼을 누른다. 이렇게 ‘플러스’가 추가된 정보는 보다 내용이 충실한 것으로 평가돼 다른 검색 결과보다 상위에 놓여지며 이런 과정은 실시간으로 검색 결과를 재배치하게 만든다.

SK커뮤니케이션즈는 "많은 사람들이 좋은 정보라 평가한 정보가 가장 먼저 보여지는 것"이라며 '수작업을 통해 가공된 검색결과'라는 말을 통해 네이버의 검색에 대해 정면 겨냥했다.

하 지만 업계는 이러한 실시간 통계에 의한 재배치 방식에 대해 "그다지 새롭진 않다"는 반응을 보이고 있다. 이미 네이버 웹 검색 결과에서도 사용자들이 많이 선택해서 누른 정보가 상위 랭크되고 있으며 엠파스도 열린검색을 통해 사용자의 선택에 의해 '뉴스', '블로그', 게시판' 등 카테고리조차 사용자들의 선택에 의해 실시간 재배치된다는 점을 강조한 바 있다.

또한 집단지성을 이용하는 방법이 사용자가 좋다고 판단한 링크에 '플러스' 버튼 누르기 방식 또한 경쟁 업체들은 '조심스럽다'는 반응이다. 사용자의 적극적인 반응를 수집하는 것은 좋으나 상업적 또는 악의적 목적에 의한 '플러스' 누르기가 횡행할 것이란 우려다.

이에 대해 SK커뮤니케이션즈 관계자는 "한 사람이 하루에 특정 링크에 플러스를 단 한 번만 누를 수 있도록 했다"며 꾸준한 모니터링과 스팸신고를 통해 불건전 정보를 걸러낼 수 있다고 자신했다.

국내 검색엔진, 알고보니 끊임없는 혁신중

' 써플'의 출현은 검색엔진에 대한 세인의 관심을 촉발시킬 것으로 보인다. 알고 보면 '닫혀있다'라는 폐쇄성에 대해 비판받고 있는 국내 검색엔진들은 나름 다양한 방법으로 사용자 검색 편의성을 높이려는 노력을 하고 있다. 이에 전문 기술업체인 온네트의 관심도에 따른 RSS기반 검색엔진 기술 개발도 눈에 띈다.

하반기에는 일단 네이버(www.naver.com)와 다음(www.daum.net)의 차제 검색엔진 업그레이드가 예고되고 있다. 네이버는 최근 인수한 첫눈 검색엔진 개발자들을 포함해 300여명의 검색엔진 개발진이 하반기 검색엔진 업그레이드에 매진하고 있다고 관계자는 전했다.

네 이버 이상훈 서비스파트장은 "현재도 베타 서비스를 통해 게시판 및 블로그 등 외부 데이터 인덱싱에 심혈을 기울이고 있다"며 "사실 검색결과 첫 화면만 보고 폐쇄성을 논하는 경향이 있지만 네이버가 검색을 통해 확보한 데이터 가운데 7, 80%가 외부 데이터를 검색 로봇이 가져 오고 있다"며 네이버 검색의 개방성에 대해 강조했다.

또한 그는 하반기 첫눈(www.1noon.com)의 기술이 합쳐진 검색엔진 개발과 함께 일본 시장 진출을 위한 검색엔진 업그레이드를 병행하고 있다고 전했다.

한 편 UCC 검색엔진 개발에 집중하고 있는 다음의 경우 일단 신뢰성 있는 외부 데이터베이스를 우선 확보하겠다는 전략이다. 또한 다음은 "올 하반기 적용을 목표로 검색엔진을 자체 개발 중에 있으며, 이를 통해 다음 내부의 약 30억건 이상의 양질의 UCC를 빠르고 정확하게 검색결과로 보여줄 수 있도록 대용량처리 기술을 강화할 계획"이라고 밝혔다.

사용자들이 각종 커뮤니티 활동 등을 통해 뿜어내는 양질의 콘텐츠가 그동안 검색 결과에 반영되지 않았다는 지적에 적극적으로 대처한다는 생각이다. 다음은 새로운 자체 검색 기술을 완성하게 되면 장기적으로는 웹검색에 한해 사용하고 있는 구글 검색을 떼어낼 계획도 갖고 있다고 밝혔다.

구글(www.google.co.kr) 의 기계적 검색 기술과 비등한 수준으로 검색 기술을 끌어올리기 위해 애쓰고 있는 야후의 경우 구글을 능가할 수 있는 비법을 사용자들의 기여에서 찾고 있다. 이른바 '태그'와 각종 서비스를 하나로 모으는 '허브'를 통해서 구현하겠다는 것이다. 야후코리아는 이미 작년 12월부터 야후!허브 서비스를 내놓고 베타 서비스 중이다. 야후!허브(hub.yahoo.co.kr)란 태그를 통해 나와 타인의 컨텐츠를 한 곳에 모아 보다 사용자 중심의 검색 결과를 보여주는 검색 서비스이다.

야 후! 관계자는 "현재 허브 서비스는 일일 약 60만명의 이용자가 이용하고 있으며 태그를 통해 재창조된 검색 DB는 약 1200만 건으로 이용자의 좋은 반응을 얻고 있다"고 전했다. UCC와 집단지성을 두루 섭렵한 기획이라고 야후!는 자랑하고 있다.

최근 재도약을 꿈꾸는 파란닷컴도 '온에어(onair.paran.com)' 라는 새로운 사용자 참여 검색 서비스를 선보였다. 이 서비스는 아예 특정 검색 키워드에 대응하는 검색 결과를 사용자가 직접 입력할 수 있는 서비스다. 다른 어느 서비스보다 사용자의 직접 참여에 크게 의존하는 서비스로 다수의 사용자가 한 가지 키워드에 대해 자신이 만든 정보가 정확하다는 것을 놓고 벌이는 경쟁 시스템도 도입돼 있다.

검색포털 사이트 엠파스(www.empas.com)도 꾸준히 외부 포털이나 커뮤니티, 콘텐츠 사이트들을 광범위하게 검색할 수 있는 '열린검색'으로 승부를 보겠다는 생각이다.

한편 첫눈 이후 뚜렷한 중소 개발사의 검색엔진이 사라진 마당에 RSS 구독 SW인 '피쉬(www.3fishes.co.kr)' 를 서비스중인 온네트가 RSS 이용자들의 집단 관심도를 이용한 검색엔진을 개발중이어서 화제다. 온네트가 개발중인 '크로스마인드'라는 기술은 RSS를 기반으로 사용자들이 관심을 갖고 주목하는 콘텐츠를 찾아주는 검색엔진 기반 기술이다.

온 네트 CTO인 박영찬 박사는 "기존 검색들이 문서들에 대한 관계성에만 집중했다면 크로스마인드는 사용자 참여에 기반한 사용자 관심도까지 고려해 검색의 결과를 제공한다는 점이 가장 큰 차이점"이라고 설명했다. 온네트는 이 검색엔진을 국내에서 9월께 선보이고 이 기술이 완성되면 일찌감치 일본 진출도 계획중이다.

외부 데이터베이스 제휴 마케팅과 수익성만을 따지던 인터넷 검색 기술 업계에 간만에 기획력과 기술력으로 승부를 내려는 기술 경쟁이 일고 있다. 이들 가운데 치열한 경쟁 속에서 소비자에게 최종적으로 선택될 검색 기술이 검색 2.0의 권좌에 오를 것으로 보인다. ⓢ

-------------->

#저작권 공지 : 해당 저작권 표시가 없는 글은 링블로그 소유이며 저작권은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.5 라이센스를 따릅니다.
이 저작물은 크리에이티브 커먼즈 라이센스에 따라 이용하실 수 있습니다.

써플에 대한 비판 위키페디아가 집단지성의 결과물인건 사실이다. 사용자는 단순히 보는데에서 그치지 않고, 스스로 컨텐츠를 만드는데 동참하고, 만들어진 컨텐츠를 연결시킴으로써 하나의 거대한 지성으로 만들어가고 있다. 이제는 브리테니커 백과사전과 비교될만한 위치에 까지 오른 것으로 알고 있다. 써플에 대해서 비판하자면, 써플은 집단지성이라고 할 수 없다는게 나의 견해다. 사용자의 참여에 의해서 검색된 문서의 중요도가 결정된다고는 하지만 위키페디아처럼 사용자가 지식컨텐츠를 생성하고 연결해서 네트워크 효과를 얻어내는 것과는 다른 차원의 것이라 생각한다. 게시판에 포스팅된 글에 대한 점수를 유저가 줄 수 있도록 했다고 해서, 이게 집단지성이 될 리는 없는 것이다. 검색의 랭킹을 위한 기계적 알고리즘이라는게 아무리 뛰어나다 하더라도, 인간의 그 판단에는 미치지 못함은 분명할것이다. 그러나 지식검색서비스에서 랭킹점수를 메기는 것처럼 유저가 참여할경우 참여자체에는 의의를 둘 수 있을지 모르지만 그 효과가 나타날런지는 회의적이다. 네이버의 지식검색에 질문과 답변에 대한 사용자 랭킹이 있다고 해서, 이걸 집단지성의 결과물이라고 말하는 사람은 없을 것이다. 기술적인 문제도 있는데, 사용자가 점수를 부여한 문서가 계속 첫페이지에 노출된다는 점으로, 새로 추가된 문서나 혹은 사용자 문화에 따라서 중요하지만 관심없는 문서 자체가 검색결과에 나타나지 않을 수도 있다는 점이다. 예를 들어서 자바라는 유명한 그룹이 있다고 가정을 해보자. 그렇다면 연애/오락관련 정보에 민감한 유저가 많은 우리나라의 특성을 봤을 때, 자바라는 그룹에 대한 팬페이지만 잔뜩 올라오고 프로그래밍 언어로써 중요한 위치에 있는 Java언어는 페이지에서 아예 밀려버리는 현상이 발생할 수 있다. 위의 기술적인 문제는 물론 여러가지 방법으로 해결할 수 있을 것이다. 기존의 랭킹공식은 그대로 두고 여기에 사용자의 의견을 수치화 해서 곱해줌으로써 랭킹을 조절하는 방법이 대표적일 것이다. 그러나 이정도를 가지고 집단지성의 반영이라고 하기엔 한참은 부족한거 같다. 또한 너무 주관적이라는 문제도 있다. 위키페디아도 주관적이다고 할 수 있겠지만 이와는 전혀 다르다. 위키페디아도 주관이 들어가긴 하지만 그 주관은 구체적인 컨텐츠의 형식으로 표현이 된다. 고로 그 주관에 문제가 있는지, 받아들일만 한지 보강해야 하는지가 다른 참여하고자 하는 유저에게 구체적으로 들어난다. 그래서 필요한 부분은 보강하고 삭제하는 등의 상호작용이 일어나는 것이다. 즉 개인의 주관을 집단지성화 할 수 있는 구체적인 행위를 하게 된다는 것이다. 그러나 1부터 5까지의 점수를 두고 사용자가 선택하는 것으로 개인의 의견이 집단지성에 작용할 수 있다고 보기는 힘들다는게 개인적인 의견이다. 위키페디아가 집단지성의 대명사가 된건 사용자의 직접적인 참여 때문에 가능한거지, 점수를 카운트 한것 때문에 가능한게 아니다.

리눅서로 생활한지 어언 10년

올해(20006년 10월)로써 리눅스 에 발을 담근지도 어언 10년이 되었다. 처음 리눅스를 접했던게, 슬랙웨어였었고 아마도 1997년인가? 1996년인가 되었던거 같다. 버젼도 잘 기억나지 않지만 책에 부록으로 있는 것을 4Mega램의 486컴퓨터에 설치를 해보았던게 리눅스에 대한 첫 경험이다. 전공도 아니고 컴퓨터의 사용이라고 해봤자 게임으로의 용도가 거의 전부였던 내가 왜 이름도 들어본적이 없는 리눅스를 설치하려고 했었는지는 지금도 모르겠다. 그렇게 설치는 했지만 4Mega램이라는 시스템의 압박과 인터넷에 연결되어 있지 않았다는 점 때문에, 결국 설치한지 이틀만에 삭제해 버리고 말았다. 프롬프트에서 ls한번치면 한참을 버벅대다가 파일목록이 떳던거 같다. 게다가 이걸 뭐 어디에 어떻게 사용하라는 건지 도통 감을 잡을 수 없어서 결국 포기해 버리고 말았다. 만약 인터넷이 있었다면 훨씬 효과적으로 사용했으리라..

본격적으로 리눅서로써 생활을 시작한건 알짜 리눅스 5.3(버전이 정확하지 않다)을 만나면서 부터다. 이게 아마 1998년 쯤이였던거 같다. 이때는 가정형편이 좀 좋아진? 관계로 그럭저럭 쓸만한 컴퓨터를 장만할 수 있었고, x-window 환경을 경험할 수 있게 되었다. 당시 windows maker를 윈도우메니저로 사용했었는데, 큼직큼직한 아이콘과 퉁명스럽지만 뭔가 있어보이는 인터페이스가 마음을 사로잡았던거 같다. 하지만 리눅서로 남게 해준데, 결정적으로 도움을 준건 인터넷, 그 중에서도 IRC의 역할이 가장 컷던거 같다.

Internet Relay Chating 으로 맛을 들이다.

이렇게 해서 리눅스에 맛을 들일까 말까 하면서 폼을 잡던게 대학 2학년때인가? 되었던듯 싶다. 학업에 뜻이 없던 터라 학교에서 짤리지 않을 정도로만 출석을 하던 막장 인생을 살던 나에게 IRC 는 독특한 재미를 줬다. 물론 그전에도 netsgo등의 인터넷 서비스 회사에서 제공하던 온라인 채팅방에서 놀기는 했지만 IRC는 저러한 놀이위주의 채팅방과는 다른 모습을 보여줬다. 꽤나 얌전한 언어를 사용했으며, 채널의 주제에 맞는 여러가지 이야기도 나누는 등 온라인 토론채널이라고 불러줄 만한 모습을 보여줬었다. 물론 내가 활동했던 채널이 Linux라서 유독 그랬을지도 모르지만 말이다.

당시에 그리고 지금도 활동했던 irc 서버는 irc.nuri.net 과 irc.mdworld.com이다. 채널은 물론 linux채널로 많은 도움을 받고 많은 사람을 만났었다. 그중 기억에 남는 아이디는 비니루님과 노가다님이다. 아마 아이디가 독특해서 더욱 기억에 남는거 같다. 지금은 뭐하고 지낼지 궁금하다.

그당시 리눅스 환경

한마디로 나몰라 환경이었다. 변변한 데스크탑 환경도 없었고, 제대로된 브라우저도 없었고, 변변한 사용자 애플리케이션도 없었다. 매일 매일 하는 일이 어떤 쓸만한 윈도우 메니저와 응용 어플이 있는지 찾으러 다니는 거였고, 덕분에 컴파일이니 패키징이니 리눅스 쉘 환경이 어쩌고 하는 기본적인 지식을 익혔던거 같다. 당시에 가장 즐겨 사용했던 윈도우 메니저는 windows maker였다. 지금은 KDE나 GNOME와 같은 워낙에 좋은 윈도우 환경(윈도우 메니저까지를 포함한)이 갖추어져 있기 때문에 거의 사용하지 않는거 같기는한데, 가볍고 시원한 느낌 때문에 꽤나 오래 사용했었다.

그리고 얼마 후에 최초의 쓸만한 윈도우 환경이라고 할만한 KDE의 beta 0.4 버젼이 나왔다. 지금에서 보자면 인터페이스도 조악하고, 쓸만한 어플도 부족하고 툭하면 뻗고 했지만 통일된 인터페이스의 제공과 konqueror라는 강력한 파일메니저겸 브라우저로 지금까지 사용하는 윈도우즈 환경이 되었다.

옆의 그림을 보면, 당시 킬러 애플리케이션이였던 xmms와 BitchX irc client가 보인다. 지금 다시 보니 외형상으론 그리 나뻐보이지도 않는 거 같다...

PHP 로 프로그래밍 세계 입문

대학시절 유일한 A+과목이 교양으로 한학기 들었던 전산학개론 이였던거 같다. 역시 교양스포츠로 수강했었던 검도(역시 몇개 안되는 A학점 과목)와 함께 가장 재미있게 들었던 과목이긴 했지만 교양은 교양일 뿐, 할줄 아는 거라고는 hello world 찍는게 전부였다. 그러다가 어떤 계기로(아마 IRC에서 누가 바람을 집어 넣었지 싶다) php를 하게 되었다. 당시 php 버젼이 3.0.2였을 것이다.

PHP는 상당히 재미있었고 재미에 매료되었다. 일단 결과가 브라우저를 통해서 눈에 바로바로 보인다는게 무언가를 배웠다라는 만족감을 줬던거 같다. 그래서 거의 1년간을 PHP에 매달려서 상당히 많은 것을 해보았던거 같다. 흔히 그렇듯이 게시판도 만들어보고 웹메일도 만들어보고, 쇼핑몰도 만들어 보면서 지냈다.

그런데 운이 좋게도? IMF가 터지고, IMF가 터진와중에 경기를 부양해 보겠다고 IT산업육성정책을 실시했고 때마침 불어온 닷컴열풍에 힘입어, 지방대에 학점 3점도 안되는 처지에 그것도 졸업하기도 전에 그리 나쁘지 않은 조건으로 취직이 되어서, 본격적으로 이 바닥에서 구르기 시작했다. 그러다가 어찌어찌해서 C프로그래밍에 입문 지금까지 이르르게 되었다.

지금은 PHP는 재미로 C /C++을 주요 무기로 밥벌이를 하고 있다. 개발환경은 물론 Linux이고 바닥이 바닥이다 보니 다른 상용 Unix환경에서도 개발경험을 가지게 되었다.

모든걸 Linux로

전적으로 모든 개발을 Linux로 하다보니, 회사업무가 보통 짜증나는게 아니였다. 이미 윈도우즈는 콘솔게임기계로 전락한 상태에서 불편해서 도저히 쓰지못하겠다 하는 지경에 까지 이르렀는데, 팀에서 공유하는 문서는 ms office 제품군의 포맷을 사용했다. 지금이야 open office가 꽤나 완성되어서 그럭저럭 쓸만하지만 당시에는 보기에도 힘이 겨울 지경이었다. 그래도 리눅스 환경을 고집했던 나는 모든 문서를 plain text나 html형식으로, 좀 형식을 갖추어야 되겠다라고 생각되는 문서는 docbook으로 제출했었고, 이것 때문에 꽤나 핀잔을 들어야 했다.

경영지원팀에도 찍혔는데, 뭐 메일을 보내면 잘 읽지도 않고 - 그냥 text로 보내면 얼마나 좋아.. 왜 ms office로 보내냐고 -, 기껏 힘들게 양식써서 보내주면 text로 변환해서 답장주고, 그나마 양호한 경우가 동료의 윈도우를 통해서 문서를 작성해서 보내주는 정도였다. 처음엔 듀얼부팅도 해보고 vmware도 설치해 보고 했었지만 결국 귀차니즘의 압박으로 포기 했었다. 문서는 읽을 수만 있음 됬지 않냐?가 나의 모토였고, 지금도 그렇다.

대충 데스크탑 작업환경은 이렇다. 가장 중요한 웹브라우징은 konqueror와 firefox, 문서작업은 vi, 문서 포맷은 plain text혹은 docbook - 그나마 요즘은 openoffice가 쓸만해져서 자주 사용한다 -, 이미지 작업은 gimp, 통계자료 처리는 gnuplot, 개발환경을 위해서 gcc/g++, make, perl, python, eclipse , vi , 운영체제와 그리 관련있지는 않지만 이런 저런 관리를 위해서 cvs, wiki등등이다.

현재의 Linux life

Linux에서 되는 것만 하자는게 지금의 컴퓨팅 생활 모토다. 노트북과 회사에서 사용하는 데스크탑에는 오직 리눅스만 설치되어 있고, 집에서는 동생도 컴터를 사용해야 하는 터라 듀얼부팅환경으로 만들어 두었다. 싸이 ? firefox에서 안떠서 안한다. 인터넷 뱅킹도 안한다. 그냥 통장들고 찾아간다. 시티뱅크가 리눅스에서도 인터넷뱅킹가능한 환경을 제공해 준다고 한다. 주 거래은행을 바꿀까 고민중이다. 무슨 공인인증키관련된게 ActiveX환경으로만 제공하는 바람에 인터넷 쇼핑도 포기다. 필요한게 있으면 직접 발품을 판다. 동영상 공유니 하는것도 포기다. 덕분에 야동에서 격리된 건전한 생활을 하고 있다.

윈도우를 쓰는 유일한 경우는 World of Warcraft를 할 때이다.

-.-;

구글(:12)을 통해 배우는 효과적인회의

비지니스가 주제이든지 개발(:12)이 주제이든지 간에 의도하지 않았음에도 불구하고 회으는 "지긋지긋한", "끝이 없는 마라톤 경주"가 되는 일이 많다. 그나마 업무시간내에 끝나면 천만다행이련만, 업무시간을 훌쩍 넘겨서 진행되면 정말 짜증이다. 더욱 문제는 무슨 이유에서인지는 모르겠지만 이 회의란 것이 업무시간 끝나기 10분 전에 시작된다는 점이다. 아마도 회의를 업무시간에 하는건 낭비라고 생각하기 때문이 아닐까 ?

어쨋든 지긋지긋 하다고 하지만 회의는 반드시 필요하다. 개발자가 하는 회의는 프로젝트의 방향을 명확히 해주고, 일어날수 있는 문제를 미리 파악하도록 도와주며, 서로의 의사소통을 원할히 함으로써 더 좋은 해법을 더 빨리 찾도록 도와준다. 안타깝게도 회의가 진행되는 도중에 반상회가 되어버리는게 문제지, 회의는 반드시 필요하다. 그렇다면 회의를 회의답게 만들어야 할 것이다. 그래서 구글에서 사용하고 있는 회의의 6가지 원칙에 대해서 살펴보기로 했다.

1. 주제를 명확히 하라.

회의는 중요한 업무중 하나다. 모든 업무가 그렇듯이 회의를 하기전에 분명한 계획을 세운다. 이 계획표에는 회의에서 다루어질 주제와 참석인원 시간을 명시하며, 계획표는 참가자 전원이 공유해서 미리 준비할 수 있도록 한다.

2. 필기할 사람을 정한다.

구글은 회의를 진행할때 회의 내용을 필기할 사람을 지정한다. 필기자는 회의 내용을 필기하는데, 그 내용은 프로젝터를 통해서 모두가 볼 수 있도록 한다. 중요한 내용이 빠지거나, 의도를 잘못 이해하고 내용을 적을 수 있기 때문이다. 기껏 회의를 끝마치고 났더니, 중요한 내용을 서로 공유하지 못하거나, 의도를 잘못 이해해서 프로젝트가 산으로 가는 일을 막을 수 있다.

회의가 끝난 후에는 필기된 내용을 간단하게 리뷰한다.

3. 작은 미팅을 가진다.

주요 주제를 가지고 미팅을 하기전에 독립적으로 진행할 수 있는 작은 주제들에 대해서 5분이나 10분이내의 짧은 회의를 가진다. 이 정도의 회의는 짜투리 시간을 내는 정도로 끝낼 수 있으므로 업무흐름에 방해를 주지 않는다. 또한 주요 주제에 대해 더 많은 이해를 가질 수 있으므로, 주요 회의에 대한 더 좋은 계획이 가능해 진다.

4. 업무시간을 지킨다.

말이 필요없다. 업무시간을 넘겨서 회의를 하게 될경우, 집중력이 떨어지고 산만해진다. 배도고프고, 약속도 있고, 친구도 만나고 싶고, 얼렁 집에 가고 싶은 마음들 때문이다. 그런데도 왜 대부분의 회의는 업무시간 끝날 즘에 시작되는 걸까.!!

5. 데이터를 활용하라.

주제에 대해서 토론하는데, 주관적인(혹은 정치적인) 호불호를 배제하고, 데이터를 활용하라. 이렇게 하는게 좋은거 같다 식의 막연한 주장에는 회사의 정치적 구도, 특정 개인에 대한 감정등이 개입될 수 있다. 이런 시스템 구성을 할경우 10%의 성능향상을 기대할 수 있습니다. 라는 식으로 데이터를 제시하도록 한다.

6. 시간을 정하라.

구글은 모든 회의실 벽에 커다란 타이머가 부착되어 있다. 회의가 시작되면 타이머가 작동 한다. 회의 참가자들은 시간에 부담을 가지게 되므로 주제에 집중하게 된다. 잡담으로 시간을 보내거나, 별로 중요하지 않는 문제로 감정싸움까지 가는 문제를 피할 수 있다. 첨언하자면 회의 시간을 줄이기 위해서는 원탁에 동일한 수준의 의자를 배치해야 한다. 리더를 위한 특별한 의자는 안락한 환경에서 거드름을 피우며 잡담을 하게되는 빌미를 주게된다.


이상 구글에서 사용되고 있는 회의의 6원칙에 대해서 알아보았다. 다들 알만한 그러 내용들이지만, 역시 지켜지지 않는게 문제다. 당장 모든 원칙을 적용하긴 힘들겠지만 몇개씩 적용하기위해서 노력하면서 회의문화를 만들어가 보도록 하자.

교양있는 바보가 회의시간에 정치를 논한다.

유닉스의 각 설비에서 데이터 seek효율성

간단한 데이터 베이스를 만든다고 가정했을 때, 원하는 데이터의 위치를 찾기 위한 seek 과정은 프로그램의 속도성능을 결정짓는 중요한 요소다.

그래서 이에 대한 테스트를 해보기로 했다. 테스트는 유닉스 설비별로 이루어질 것이다.

1. 메모리
2. 메모리맵(MM)
3. 파일
4. 공유메모리

상식적으로 생각해 봤을 때, 메모리에서 연산하는게 가장 빠르겠지만, 이 경우 많은 메모리를 사용해야 한다는 단점이 있다. 파일 같은 경우는 저장이 용이하고 메모리 사용이 상대적으로 적다는 장점이 있지만 Disk I/O가 문제가 될것이다. 공유메모리의 경우 커널에서 관리하므로 빠르게 사용할 수 있다는 장점이 있을 거 같지만, 커널 메모리를 사용할 경우 다른 자원에 비해서 제약이 크다는 단점이 있을 것이다. 메모리 맵도 마찬가지로 장단점을 가지고 있을 것이다.

결 국 속도 우선인지, 메모리 우선인지 그리고 각 방법을 선택했을 때, 다른 방법을 선택했을 때보다 그만큼의 이익을 얻을 수 있는지에 대한 판단을 해야 하고, 이 문서는 이러한 판단에 근거를 만들기 위한 데이터의 수집을 목적으로 작성되었다.

테스트 시나리오

다음과 같은 고정된 크기를 가지는 구조체를 포함하는 배열을 만든다.

struct data { int did; int score; };

배열의 크기는 10,000,000개로 9Mbyte 정도의 크기를 가지게 될 것이다. 이렇게 만들어진 데이터를 파일, 메모리, 공유메모리(:12), 메모리맵에 적재하고 seek(2)에 걸리는 시간을 검사한다.

Memory 우선 사용 테스트

malloc(:3)을 이용해서 천만개의 메모리를 할당하고 여기에서 값을 읽어들이는데 걸리는 시간을 테스트 했다. 10000*1, 10000*2, 10000*3,..., 10000*n으로 데이터를 읽어들였다.

#include
#include
#include
#include
#include
#include
#include
#include

struct data
{
int did;
int score;
};

const int dsize = 10000000;

int main(int argc, char **argv)
{
struct data *ldata;
struct data dumy;
int i,j,n;
clock_t stime, etime;
int offset = 10000;
ldata = (struct data *)malloc(sizeof(struct data) * dsize);
memset((void *)ldata, 0x00, sizeof(struct data)*dsize);

n = dsize/offset;
for (i = 0; i < n; i++)
{
stime = clock();
for (j = 0; j < offset * (i+1); j++)
{
dumy = ldata[j];
}
etime = clock();
//printf("%d : %.3fsn", offset * (i+1), (double)(etime-stime)/CLOCKS_PER_SEC);
printf("%d %.3fn", j, (double)(etime-stime)/CLOCKS_PER_SEC);
}
}

다음은 테스트 결과를 gnuplot(:12)를 이용해서 출력한 화면이다.

파일우선 테스트

파일에서 읽을 때 걸리는 시간을 측정해 보았다. 측정방식은 Memory방식과 동일하며, 이를 위해 다음과 같은 프로그램을 만들었다. *8 하는 것만으로 데이터의 위치를 구할 수 있을 것임으로 굳이 seek함수를 이용하진 않았다. 다음은 테스트를 위해 작성한 코드다.

#include
#include
#include
#include
#include
#include
#include
#include

struct data
{
int did;
int score;
};

const int dsize = 10000000;

int main(int argc, char **argv)
{
struct data *ldata;
struct data dumy;
int i,j,n;
clock_t stime, etime;
int offset = 10000;
int fd;


fd = open("data.dmb", O_CREAT|O_RDWR);
if (fd < 0)
{
perror("Open errorn");
}
memset((void *)&dumy, 0x00, sizeof(struct data));
for (i = 0; i < 10000000; i++)
{
write(fd, (void *)&dumy, sizeof(struct data));
}
printf("File Create endn");

n = dsize/offset;
for (i = 0; i < n; i++)
{
stime = clock();
for (j = 0; j < offset * (i+1); j++)
{
read(fd, (void *)&dumy, sizeof(struct data));
}
etime = clock();
printf("%d %.3fn", j, (double)(etime-stime)/CLOCKS_PER_SEC);
}
}

측정결과는 gnuplot를 이용해서 그래프로 만들었다.


비교를 쉽게 하기 위해서 하나의 그래프로 만들어 봤다.

블로거가 되다

때늦은 감이 있지만 나도 블로거가 되었다. 그동안 블로그의 필요성을 느끼지 못하고 있는데(사실은 지금도 별로 느끼지는 못한다), 구글 서비스들을 이용하다 보니 어찌어찌해서 블로거의 대열에 합류하게 되었다.

블로그의 필요성을 느끼지 못했던 이유는 아마도 인터넷을 개인미디어의 창구라기 보다는 정보검색과 지식축적의 창고로 인식하고 있었던게 크지 싶다. 그래서 정보를 축적하고 지식화 할 수 있는 위키에 열광했었고, 시간이 지남에 따라 잊혀질 수 밖에 없는 블러그에 별 반응이 없었던거 같다.

사실블로그를 쓰기로 마음 먹은 지금도 꼭 필요하다고 느끼진 않고 있다. 블로그를 쓰느니 그냥 동일한 내용을 위키에 정리하면, RSS등을 통해서 원하는 바도 달성할 수 있을 뿐더러, 카테고리에 분류되어서 필요할 때 쉽게 찾아볼 수도 있기 때문이다.

그럼에도 불구하고 블로그를 쓰게된건 순전히 구글의 서비스들 때문이였다. 특히 구글의 writely 때문인데, wizwig방식의 인터페이스를 통해서 쉽게 문서를 작성할 수 있고, 작성된 문서를 다양한 형태 특히 개인의 구글 블로그 로 바로 post할 수 있다는 점이 맘에 들었기 때문이다. 이렇게 개인 블로그로 post된 문서는 wiki에 간단한 plugin 하나 추가하는 정도로 쉽게 불러올 수 있으니, 쉬운문서작성, 블로그에 대한 경험(시류에 편승한다는 기분이 강하긴 하지만), 거기에 위키를 통한 정보축적 의 3마리 토끼를 동시에 잡을 수 있기 때문이다. 현재로서는 상당히 만족스럽다.

가벼운 개인 문서는 writely로 빠르게 작성해서 블로그로 포스팅하고, 위키로 정리할 필요가 있다고 생각되는건 위키페이지에서 불러오는 방식으로 사용할 계획이다.

구글 네트워크 운영체제를 위한 발걸음?

드디어 writely가 google 도메인으로 들어왔다. 이로써 이터넷 Office구현을 위한 핵심 애플리케이션이라 할 수 있는 워드프로세스, SpreadSheets, 프리젠테이션 프로그램중 워드와 스프레드쉬트 2개의 애플리케이션을 구글 도메인에 넣을 수 있게 되었다. 이제 기존의 gmail 사용자는 한번의 로그인으로 메일, 문서작성기, 표계산기의 서비스를 사용가능 하게 되었다.

아직 전문 워드프로세스에 비할 정도의 기능을 가진건 아니지만, 웹상에서 그리 복잡하지 않은 문서를 작성하기에는 충분한 성능을 보여준다. 데스크탑의 전용 프로그램에 비해서 성능이 떨어진다고는 하지만, 인터넷 특유의 강력한 특성인 어디에서든지 사용가능하다 와 별도의 응용을 설치할 필요가 없다 는 점 때문에 매우 유용하게 사용할 수 있을 것같다.

폰트선택과 크기 조절, 링크, 테이블등의 기본적인 기능외에, 이미지, 북마크, 코멘트, 특수문자등의 입력도 가능하다. 만들어진 문서는 웹을 통해서 통합관리 할 수 있으며, Revision 기능을 통해서 문서버전관리도 가능하며, 메일로 보내고, 공동으로 문서작업을 위한 문서공유 역시 가능하다.

일정관리, 검색(논문,웹문서,뉴스,블러그,동영상), 문서작성, 표계산, 메일 까지 몽땅 구글에서 끝낼 수 있는 서비스가 나올지도 모르겠다.

쓸만한 기능의 표계산기

약간 느리고, 그래프나 메크로등의 고급기능이 없긴 하지만, 대부분의 연산을 지원하고 있으며, 매우 쓸만하다. 아주 복잡한 계산을 필요로 하는 곳이 아니라면 부담없이 사용할 수 있을거 같다. 웹의 특성을 살려서 공동작업환경도 지원하고 있다. publish 기능과 writely로의 표 삽입기능까지를 지원한다면 더할나위 없이 훌륭한 프로그램이 될거 같다.

블러거를 위한 최고의 문서편집기

만들어진 문서는 publish 기능을 이용해서 웹문서 형식은 물론이고 자신이 사용하는 블러그로 바로 올릴 수 있는데, 이러한 점 때문에 특히 블러거들에게 유용하게 사용할 수 있을거 같다. 필자가 사용중인 google blog를 상대로 테스트 해봤는데, 성공적으로 post되는걸 확인했다.

웹뿐만 아니라, word, openoffice, RDF, PDF(:12)의 포맷으로 로켓 파일시스템에 저장할 수도 있다.

이 문서는 리눅스(:12) firefox 1.5에서 구글 writely를 통해서 작성되었으며 http://joinc-yundream.blogspot.com 와 http://docs.google.com/View?docid=dgfb53hh_0gg9d56 로 publish 되었다.

Joinc Wiki에서의 사용

joinc에서 사용하는 wiki는 moniwiki을 바탕으로 하고 있다. 그러다 보니 wizwig지원도 되지 않는 열악한 에디팅 환경을 제공한다. google writely를 이용하면 이런 문제를 해결할 수 있다. 필자는 writely로 편하게 문서를 작성하고 wiki페이지에서는 불러서 보여주는 방식을 사용했다. 이를 위해서 googledoc 이라는 wiki 플러그인을 만들어서 doc문서의 id만 넘기면 읽어오도록 했다. 꽁수이긴 문서 인덱스가 필요하지 않은 작은 크기의 문서를 만들 때는 꽤나 편할거 같다.

마치며

데스크탑 어플리케이션의 기능에는 미치지 못하지만(당연한가?) 어차피 데탑에서 사용되는 오피스 도구도 10-20%의 기능만을 사용한다고 하지 않던가. 그렇게 본다면 지금의 google docs도 이미 그정도의 성능은 보여주는거 같다. 무엇보다 만들어진 문서들이 구글의 다른 인터넷 서비스들과 유저에게 공유될 수 있다는 점이 엄청난 장점이라고 생각된다. 한번 문서를 만들면 별다른 작업없이 Blog, Web, Mail, 캘린더, FTP로 공유되고, 구글의 검색엔진을 통해서 검색될 수 있다. 게다가 별도의 무거운 애플리케이션의 설치 필요없이 인터넷에 연결된 PC만 있으면 이러한 일들을 할 수가 있다. 운영체제와 애플리케이션에 따라 문서가 이상하게 보이거나 아예 보이지 않는 그런 걱정도 할 필요 없다(리눅스 OO에서 작성한 문서를 윈도우에서 한번 보기 바란다).


모든 일을 구글에 연결해서 웹브라우저를 통해서 끝내버리는 구글 데스크탑(혹은 구글 OS) 환경이 만들어지는걸 기대해도 될거 같다.