TNF Needlworks

요즘 일찍 자려고 노력합니다. 12시 이전에요. (그러나, 지금도 10분 남았다는 사실) 빠지는 머리 나오는 배, 요거 인생 겁주더라구요. 12시에 잔다고 하지만 6시에 일어날 것을 목표로 하고 있습니다.

일찍 자면서 할 일을 어떻게 하느냐, 전엔 노트북을 회사나 집에 놓고 다녔지만, 이제 들고 다니면서 짬짬히 시간나는대로 작업하렵니다. 최대한 시간을 쪼개서요. 참고로 출퇴근 시간, 걷는 것을 제외하고, 지하철에 앉아 있는거 합치면 한시간 조금 넘게 나옵니다.

지하철에서 책을 읽다가 자리나면 앉아서, 조금 뜸들이고, 놋북을 켭니다. 요즘 ACL 관련해서 텍스트 큐브(TC) 소스를 수정하는데, 지하철에서 집중이 더 잘 돼요. 페도라의 베릴 조합이므로 가끔 큐브 돌릴 때 의식이 되긴 하지만요. ;)

총 합 2시간 정도를 TC에 넣는 정도로 집중하고 있습니다. 여러분 저의 이 시간 관리가 성공해야 아내에게 사랑 받습니다. 좀 격려 해 주십쇼.

물리학이 전공인데 자바스크립트를 죽자살자 붙잡고 있는 중입니다. 수강중인 DR (Data retrieval 또는 information retrieval이라고 하는 분야입니다) 과목의 프로젝트를 구현하기 위해 자바스크립트 의존적인 클라이언트? 를 짜고 있기 때문입니다. 재미있는 아이디어의 프로젝트입니다. IR의 한 분야에서는 middleware 등에서 조건에 맞는 요소를 뽑아내는 부분에 대한 것을 다룹니다 -top-k query라고 합니다-

프로젝트로 제안하고 만들고 테스트하고 있는 것은 관점을 좀 바꿔본 top-k query 방법입니다. 보통 서버에 키워드를 날리면 서버에서 처리한 결과가 날라오고, 그에 따른 카테고리를 선택하면 또 서버에 쿼리가 날라가고 돌아오고는 하는데, 그 과정을 전부 클라이언트로 옮기게 됩니다. 이 과정의 장점중 하나는 개인의 검색 성향을 서버에 제공해주지 않을 수 있다는 것입니다. 그러면서 검색에 대한 개인화 구현이 가능하게 되지요.

이런 부분을 실제 서비스 업체들은 그다지 안 좋아할 수도 있습니다만, 전 필요하다고 생각하고 있습니다. 응용이 별 것 없을 것 같이 보입니다만 생각해보면 다양합니다. 전 로그인이 참 귀찮습니다. 그렇지만 뭘 보고 싶은지 잘 모르는 상태에서 서비스를 사용하거나 쇼핑을 할 때, 저절로 자신의 관심사로 검색 결과들이 포커싱되는 것은 로그인없이 구현하기가 어렵지요. 이 프로젝트는 그걸 가능하게 해줍니다. 자세한 것은 귀찮아서 생략하고 페이퍼 나오면 붙이도록 하겠습니다.

그런데 이 과정에서 해당 클라이언트를 activeX로 짜면 우선 제가 못 씁니다. 그래서 서버와 상호통신하고 top-k 계산 과정을 수행하는 클라이언트를 통째로 자바스크립트로 짜고 있습니다. 참 상반된 느낌을 받으면서 짜고 있습니다. 하나는 '자바스크립트가 이렇게 강력한 언어였나' 하는 것이고 다른 하나는 '뭐 이딴 언어가 다있냐' 는 것입니다. ajax가 때늦게 각광받는 이유도 동시에 배우고 있습니다.

맘잡고 써 본 자바스크립트는 굉장히 객체지향적입니다. 게다가 각 객체들을 웹페이지 구성요소와 붙이는 것에 있어서는 페이지와 동시에 독립적으로 로딩된다는 점 때문에 다른 방법으로는 흉내낼 수 없는 것들을 해 볼 수가 있습니다. 적당한 프레임웍과 희한한 자바스크립트 notation에 대한 이해와 노가다가 합체하면 생각한 것은 대부분 해 볼 수가 있을 듯 합니다.

하지만 동시에 '호환성'이 문제가 됩니다. 브라우저마다 다르게 돌아가는 (자바스크립트 파서가 다르기 때문이지요) 자바스크립트를 생각하면 무작정 생으로 짜다가는 activeX 못지 않은 변태 스크립트가 등장할 수 있습니다. 게다가 JSparser가 잘 뻗습니다. 좀 잘못짰다 싶으면 테스트 중에 브라우저가 수많은 친구 탭들을 안고 사망합니다. (왜 사냐건 울지요) 게다가 (이건 이제서야 JS활용이 극대화되는 이유중 하나이기도 할텐데) 느립니다. 정말 느립니다....

php로 구현한 서버측 드라이버들을 제외하면 원하는 기능을 구현한 자바스크립트 모듈은 천 줄 정도밖에 안됩니다만, 하부에 dojo framework의 컴포넌트 일부를 연결했기 때문에 필요한 기능만 잘라 왔다고 하더라도 실제로는 크기가 좀 됩니다. 제가 무식한 것들을 요구해서이기도 하겠습니다만, 속도가 잘 안 나옵니다. (그래서 온갖 편법을 동원하여 속도를 늘리려고 했습니다만 여전히 느립니다.[footnote]예를 한 번 들어보면 이런 것도 있습니다. string을 number로 변환하려면 앞에 + 붙이는 것이 가장 빠른 방법입니다. 여러가지 방법 중 parseInt는 가장 느린 방법이지요.[/footnote]) 그래서 구현한 결과가 컴퓨터 사양을 탑니다.

쉽게 쓴다고 썼는데 쓰다 중간에 위를 읽어보니 더 쓰면 안 되겠다는 생각이 드네요. -_-;
그래도 즐거운 이야기로 붙이렵니다. ~

덧) 일주일째 테스트 데이터베이스를 셋팅하고 있는 프로젝트 공동 진행자 모 분은 끝없이 좌절하다가 막 자러 갔습니다. 검색 엔진 구현을 위해 word relation 측정을 위한 웹문서 샘플링과 카테고리 저장을 하는데 DB가 벌써 60기가가 넘어가네요. 단일 mysql에서 50기가 넘는 데이터베이스를 핸들링 하는 것은 실제로는 처음 봤습니다. (보통 분산하면 했지 이렇게는 잘 안하지요)