Monthly Archives: April 2007

One Laptop Per Child (OLPC)

OLPC라는 프로젝트에 대해 근래 많은 소식을 접할수 있습니다. 교육이 필요한 어려운 나라에 싸게 노트북을 제공하는 프로젝트 정도로만 생각했었는데, 기술적으로도 많은 고민을 한것 같네요. 구글 비디오에서 1시간 정도의 소개를 봤습니다.

http://1laptop1student.blogspot.com/2007/04/olpc-tech-talk-w-google.html

가격은 $175 로 정해졌다고 얼마전에 slashdot에 올라왔었습니다. 국가를 대상으로 파는거고, 원래는 개인에게는 안판다고 했었는데, $200에 판다는 뉴스도 있네요.

하드웨어를 보면, CPU는 AMD Geode 700MHz, 메모리는 256MB로 사양은 떨어집니다. 디스플레이가 좀 특이한데 듀얼모드입니다. 칼라모드는 일반적인 LCD와 같지만 해상도는 낮고, 흑백모드는 직사광선이 있는곳에서 볼수 있으며 해상도는 1200×900이고 전력소비가 매우 적다고 합니다. 흑백모드는 백라이트가 없기 때문에 어두운곳에서는 잘 안보입니다. 무선랜을 지원하는데 네트워크 인프라가 없는 낙후된 지역에서 원활한 네트워크가 가능하도록 무서랜은 컴퓨터를 끈상태에서도 동작할수 있다고 합니다. OLPC들로만 adhoc 네트워크가 원활히 유지되도록 신경을 쓴거 같네요. 크기는 좀 큰거 같지만, 무게는 1.5 Kg 이하일거라 합니다. 전력사용은 최대 일반 노트북의 10분의 1 수준이라고 합니다.

OS는 리눅스(FedoraCore) 기반이고, 그 위에 어플리케이션은 python으로 대부분 구현되었다고 합니다. Sugar라는 UI 라이브러리를 개발하였지만, 아직 UI는 개발중이라고 합니다. 전력 소모를 줄이기 위해서 사용하는 중에도 suspend 모드로 간다고 합니다. 이를 위해서 suspend 상태로 오가는 시간을 대폭 줄여 사용자가 인식하지 못하는 시간(100ms)으로 줄이려고 노력하고 있다고 합니다. 현재 200ms 정도 소요된다고 합니다.

가격을 낮추는거에만 초점을 둔것이 아니라 정말 여러 사항들을 고려하고 있다는 생각이 들고, 그래서 많은 주목을 받고 있는거 같네요. 취지 또한 좋죠. 전세계 인구의 6분의 1 정도가 학습을 받지 못하는 어린 아이들이라고 합니다. 이러한 어린이들에게 교육 기회를 주자는 거죠.

LiveCD가 있어서 한번 구해서 돌려봤습니다. ^^

http://olpc.download.redhat.com/olpc/streams/sdk/build1/livecd/

아직 완성도가 떨어지고, UI가 너무 단순해서 좀 실망이긴 하지만, 아이들이 쓰기에는 괜찮을거 같네요. 저는 네트워크 인식이 되지 않아서 네트워크 기능은 테스트해보지 못했습니다.

아래가 부팅 후 처음 뜨는 로그인 창입니다. My Name에 이름을 적고, 사람모양을 누르면 색을 바꿀수 있습니다. 커서가 좀 엽기적으로 크네요.


로그인을 하면 아주 단순한 창이 뜨는데 마우스를 코너로 가져가면 테두리에 메뉴가 생깁니다. 밑에는 어플리케이션(activity) 리스트, 위에는 시스템메뉴(?)와 실행중인 어플리케이션이 나옵니다.

어플리케이션은 웹브라우저, RSS 리더, 그림판, 테트리스, 카메라, 계산기, 문서작성기, EToy, 음악 프로그램 등이 제공됩니다. EToy는 Squeak Smalltalk에서 제공하는 환경으로 아이들이 쉽고 재미있게 프로그래밍을 학습할수 있는 환경입니다. EToy는 squeakland에서 많은 정보를 얻을수 있습니다. 음악 프로그램은 Csound에 기반하여 여러악기를 연주할수있는 프로그램들로, 건반프로그램, 시퀀싱 프로그램, 악기를 만들수 있는 프로그램 등이 있습니다.

아래는 문서편집기를 실행한 화면입니다. 아주 기본적인 기능만 있으며, 가운데 창은 이미지를 삽입하기 위해서 파일을 선택하는 창이 뜬건데, GTK+ 기반의 인터페이스를 아직 안고친거 같네요. Sugar UI 라이브러리가 GTK+ 위에 구현되었고, GTK 위젯을 안쓰고 따로 구현한 캔버스만을 사용한다고 들었는데 아직 공통(common) 다이얼로그는 개발이 안되었나보네요. 글씨가 너무 작고 비율도 안맞아서 파일 고르기도 힘들더군요. 차차 나아지겠죠… 문서편집기 기능은 딱 꼭 필요한거만 있는거 같네요.


구글 비디오를 보고, 라이브 CD를 실행해보고 느끼는게 국제화에 대한 얘기가 전혀 없다는게 좀 의아하긴 하네요. 6개월의 개발 기간이 남았다고 하는데 6개월후에 어떤 모습으로 변해있을지 지켜봐야겠네요.

CLucene CJK 분석기

CLucene을 이용하여 검색엔진 구현하는데, 한글처리에 대한 정보가 거의 없더군요. 아주 기본적인 한글처리만 구현해보았습니다. CLucene에서 한글 처리에 대해서 참고하시면 도움이 되리라 생각하여 소스를 공개합니다.

리눅스와 윈도우즈에서 동작하지만 먼저 리눅스 소스만 공개합니다. 윈도우즈에서 아직 _MBCS 정의를 빼지않고 컴파일에 성공하지 못했습니다. 좀더 연구해봐야할듯하네요. 소스는 코드변환 외에는 차이가 없습니다.

clucene-core-0.9.16a 버전을 사용했으며 Makefile에서 CLUCENEPATH를 설정하고 make하시면 됩니다. 소스에 포함된 한글은 UTF-8로 인코딩되어있으며, CentOS 4.4 AMD64 리눅스(LANG=ko_KR.UTF-8)에서 테스트했습니다.

clucene의 StandardTokenizer에 보면 CJK관련 처리가 있지만, next()에서 _CJK로 인식하기 전에 다른곳(_istalpha)으로 빠져서 CJK 토큰으로 분류가 안되더군요. 그래서 복사해서 CJKTokenizer.cpp를 만들고 비교 순서만 바꿔줬습니다. 왜 한글코드가 _istalpha으로 인식되어 빠져나가는지는 잘 모르겠네요.

KoreanStemFilter.cpp에서는 CJK 토큰을 2글자 단위로 나누는 역할을 합니다. 루씬인액션에 설명되어있는데 clucene에는 구현이 안되어 있는거 같더군요. “검색엔진” 토큰을 “검색” “색엔” “엔진” 토큰으로 바꾸죠. 한글의 조사를 뺀다던가 하는 기능을 추가하기 위해서 KoreamStemFilter로 만들었는데 지금 기능은 CJK 필터만 구현되어있네요.

ConvertUtil.cpp는 iconv를 이용하여 UTF-8을 UTF-32LE로 바꾸는 소스 입니다. 윈도우즈의 경우는 MultiByteToWideChar()와 WideCharToMultiByte() 함수를 이용했습니다.

CLuceneTest.cpp는 간단한 데이타 3개를 넣고 터미널 상에서 검색할 수 있는 테스트 프로그램입니다. clucene의 데모 소스를 약간 바꿔서 구현했습니다.

다음은 실행한 화면입니다:

$ ./CLuceneTest
adding doc: doc1 – hahaha 한글단어 hohoho 비 bye 검색엔진
adding doc: doc2 – hello zaza 한글 김현정 김건 건모 검색
adding doc: doc3 – goodbye 김건모 서영은 검색 엔진 SG워너비
Indexing took: 5 ms.

Enter query string: 검색엔진
Searching for: “검색 색엔 엔진”

0. doc1 – hahaha 한글단어 hohoho 비 bye 검색엔진 (0.974307)

Search took: 1 ms.
Screen dump took: 0 ms.

Enter query string: +검색 +엔진
Searching for: +검색 +엔진

0. doc1 – hahaha 한글단어 hohoho 비 bye 검색엔진 (0.383675)
1. doc3 – goodbye 김건모 서영은 검색 엔진 SG워너비 (0.383675)

Search took: 0 ms.
Screen dump took: 0 ms.

소스입니다.
1204400252.tgz

검색 기술 좌충우돌

검색 기술은 제대로 배워본적이 없었는데, 서비스 운영하다보니 여러번 발목을 잡더군요. 서버에서 검색 기술이 필요한 부분도 있었고, 클라이언트에서도 필요했습니다.

클라이언트 단에서는 처음에는 인덱스 없이 직접 스트링 비교를 해서 검색하다가, 검색할 데이타가 늘면서 느려져서, 검색 인덱스를 메모리에 간단히 만들고 (stl map 이용), 사용하니 큰 문제없이 잘 동작하더군요. 근데 경우에 따라서 검색 인덱스가 아주 커지는 클라이언트 들이 생겨서 메모리에 전체 인덱스를 올리는것이 불가능한 경우가 생겼습니다. 그래서, 어쩔수 없이 파일 기반으로 map처럼 사용할수 있는 dbm 계열의 라이브러리를 사용하여 인덱스를 저장하여 사용하고 있습니다. 현재까지는 큰 문제없이 사용하고 있습니다. 하지만 검색 인덱스가 커지고 쿼리가 늘면 좀 버벅대더군요. 아무래도 인덱스 만드는거나 검색자체가 효율적으로 구현한것이 아니고, 저장하는 방법 또한 효율적으로 검색할수 있는 구조가 아니었던것 같네요.

서버 단에서는 디비에 있는 필드 검색이라 MySQL의 FullText 검색을 이용할 방법을 고민했었습니다. 요즘도 해결 안됐을거 같은데 FullText 검색은 한글을 지원하지 않죠. 그래서 고민하다가 생각한 방법이 한글을 영문으로 인코딩하여 필드하나 더 만들어서 박아넣는거였습니다. 일단 영문은 다 소문자로 변경해서 넣고, 한글은 대문자로 자~알 인코딩 해서 넣고, 디비 Insert,Update할때 인덱스 필드에 변환해서 넣고, 검색할때 한글 변환해서 fulltext search하고.. 이렇게 하니 잘 동작은 하더군요. 몇달간 서비스하면서 데이타가 몇기가 쌓이니, 점점 느려져만 가더군요. 이건 서비스 기획의 문제였지만, 운영하던 서비스는 거의 삭제의 개념이 없고 계속 누적되는 형태로 운영이 되었습니다. 그러니 문제가 될수 밖에 없었죠. 나중에는 검색을 새로 구현할 엄두가 나지 않아서 검색 자체를 빼고 P2P 검색으로 대체했습니다…

서버 단에서 다시 검색이 필요하여, MySQL fulltext보다는 좀더 좋은 방법을 찾으려고 했는데… 인덱싱하는 페이지들이 모두 html로 만들어져 있기 때문에, 웹기반 인덱싱 쪽으로 알아보았습니다. 외국에서 만든 많은 검색엔진들이 단어 단위로 인덱스를 만들기 때문에 한글 검색이 잘 안되는 경우가 많더군요. “검색엔진”이라는 단어가 인덱싱 되면 “검색”으로는 해당 문서가 검색이 안되는 엔진들이 많더군요. mnogosearch라는 검색엔진을 발견했는데, 한글 검색이 완벽하게 되더군요. 구현할 시간은 없고 일단 동작을 하다보니 그냥 사용하기로 하고 서비스 했습니다 –; 뭐 처음에는 사용자들이 검색 들어갔는지도 잘 몰랐기 때문에, 서비스 운영에 전혀 문제 없었습니다. 데이타가 쌓이고, 검색 많아지고 하면서 문제가 조금씩 생기더군요. 일단 서버 여러대에 분산 처리했습니다. 근데 문제는 몇몇 사용자가 검색을 집중적으로 해도 서비스가 상당히 불안해졌습니다. 서비스가 다운되거나 그런건 아니지만, 디비에 부하가 걸려서 응답속도가 느려지더군요. mnogosearch에 대한 최적화 방법 같은걸 찾아보고, 들어오는 쿼리들을 저장하고 벤치마킹을 해봤습니다. 처음 벤치마크 결과는 절망적이더군요. 일단 쿼리에 따라 검색시간에 큰 편차가 있었습니다. 내부적인 동작을 모르니, 최적화는 한계가 있을거 같다는 생각을 하고 mnogosearch를 대체할수 밖에 없다고 결론을 냈습니다.

로레벨(ㅎㅎ) 개발자이기 때문에 먼저 위키피디아에서 검색 알고리즘들을 찾아보고, 필요한 소스코드(주로C)를 수집하기 시작했습니다. 알고리즘 소스들을 연결하여 인덱싱하고 검색하는거 구현하는 거는 정말 쉬운일이 아닐거 같다는 생각이 금방 들더군요. 그래서 좀더 검색하다 찾은것이 루씬(Lucene)입니다.

루씬은 자바로 된 검색엔진입니다. 검색엔진이라는 용어 자체가 좀 애매한데, mnogosearch는 사용자를 위한 검색 엔진이라면, 루씬은 개발자용 검색 엔진입니다. mnogosearch는 인덱스할 url을 입력하고, 화면에 검색결과가 어떻게 표시될지만 설정해주면 바로 사용이 가능합니다. 루씬의 경우는 검색엔진 라이브러리입니다. 개발자가 직접 문서를 읽어들이는 코드, 인덱싱하고, 검색하는 코드를 직접 작성해야합니다. 또한 어느정도 기술에 대한 이해도가 있어야 좋은 성능을 낼수 있다고 하네요. 다행히 Lucene in Action이라는 책이 나와있어서 큰 도움이 되더군요. 번역판도 나온거 같더군요…

제가 자바를 선호하지 않고, 잘 동작한다면 클라이언트(win32)단에서도 사용하고 싶었기 때문에 C++로 포팅된 CLucene을 사용하기로 결정했습니다. CLucene이 자바 루씬에 비해서 버전이 낮긴하지만, 성능도 뛰어나고, 제가 C++이 더 익숙해서요…. win32 클라이언트는 종속성을 줄이기 위해서 static 링크되지 않는 외부라이브러리는 가능하면 안씁니다. ( 특히 .net 같은거는 절대 안씁니다. )

CLucene으로 현재 검색 서버를 개발 완료했으며, 클라이언트 단에도 실험적으로 돌려보고 있는데 성능은 아주 잘 나오고, 검색 시간 편차는 정말 적더군요. 서버단에서 벤치마크 결과 아주 만족스런 결과가 나왔습니다.

시간내서 CLucene으로 한글 검색 되도록 스탬필터로 개발한 소스를 공개하도록 하겠습니다. 한글스탬필터는 2글자씩 짜르는거 외에 별도 처리는 구현하지 않았습니다. 자바 루씬에는 이렇게 구현된 것이 들어있는지 모르겠는데, CLucene에서는 소스 찾아봐도 없더군요. 그리고 CLucene의 StandardAnalyzer로는 CJK 처리가 정상적으로 동작안하더군요. (win32, linux에서 모두)

소스 조만간 공개하겠습니다 ^^

Unix/Linux 모임 참석 후기

정말 오랜만에 오프라인 모임에 나가보았습니다. 온라인으로도 활동을 거의 안하긴 하지만… 얼마전부터 다른 사람들의 블로그 글들을 꾸준히 읽다보니 제가 뒤쳐지는 느낌도 들고, 회사 내에서 회사일만 하기도 바쁘다보니 보는 시야가 너무 한정되는거 같아서 오프라인 모임 같은곳에 한번 나가야겠다는 생각은 했었습니다.

스마트플레이스에서 “Unix/Linux 엔지니어, 개발자, IT 매니저와의 대화“글을 보고 설문에 참여했었는데 연락 주셔서 어제 모임에 참석하게 되었습니다. 모임의 성격은 약간 애매했던거 같은데, 개발자가 아닌 다른 입장에서 왜 유닉스를 사용하는지에 대해서 들을수 있어서 도움이 되었습니다. 또한 작은 기업에서 서비스 운영하다보니 싼 서버에 오픈 소스 유닉스만 사용하고, 최적화의 끝을 찾아헤매는데, CPU 32개 이상 서버, 문제있을때 4시간만에 출장은 다른 나라 얘기같더군요. 그래도 최적화를 하면서 많은 보람을 느끼는데 최적화를 통해서 다른 곳에서 하지 못하는 서비스를 언젠가 할수 있다고 믿고 싶네요.

모임은 스플 멤버 외에 참가한 사람들의 소개로 시작해서 소개로 끝났습니다. 많은 얘기 나누지는 못했지만 참가한 모든 사람들의 열정적인 모습 보고 많은 자극 받았습니다. 블로그 들어가서 보니 참 많은 생각 하시고, 부지런한 분들이시더군요.

앞으로도 오프모임 자주 참석해서 사람들 많이 만나봐야겠다는 생각이 드네요.

그리고 준비해주신 기념품 너무 고맙게 받았습니다. ^^