'IT'에 해당되는 글 67건

C/C++ 프로그램을 하다 보면 종종 메모리를 할당하고 해제하지 않아
시스템에 부하를 주는 일이 다반사이다.

할당한 개수 만큼 해제했는지 일일이 쫓아 다니며 체크하기엔 무리인 경우가 많으며,
core가 떨어지면 core를 분석해보면 찾아갈 수도 있겠지만,

간단히, 해당 프로그램의 매크로로 정의를 해서 확인해 볼 수 있는 방법도 있겠다.

#define malloc(args...) \
           (fprintf(stderr, "malloc by %s\n", __FUNCTION__)) ? malloc(args) : NULL)

#define free(args...) \
do { \
           fprintf(stderr, "free by %s\n", __FUNCTION__);\
           free(args);\
} while(0)


#define realloc(x, args...) \
           ((x ? fprintf(stderr, "free by %s\n calloc by %s\n", __FUNCTION__, __FUNCTION___ : \
                   fprintf(stderr, "calloc by %s\n", __FUNCTION__)) ? realloc(x, args) : NULL)

이런 매크로를 사용한다면,
해당 함수에서 몇 번의 메모리 할당이 발생했고, 해제가 일어났는지, 화면상에 나타나는 문장을 보고 판단을 할 수 있을 것이다.

이전 회사에 다닐 때 정리하였던 문서이다.
간만에 하드를 정리하면서 찾아서 올려본다.

Merge sort는 본래 이미 정렬된 두 개 이상의 배열을 하나의 정렬된 배열로 만드는 것으로
일반적으로 알고 있는 사실이다.

그러나, 정렬되지 않은 하나의 배열을 정렬하는데도 사용할 수 있다는 사실~~~!!!
정렬되지 않은 하나의 배열의 각 원소(인자) 값을 이미 정렬된 배열로 가정하여 2개씩 병합을 하면 된다.

다음과 같은 값들이 입력되었다고 하자.

입력값 :

26

5

77

1

61

11

59

15

48

19

이들의 병합과정은 다음과 같다.

Pass 1 :	[26]	[5]	[77]	[1]	[61]	[11]	[59]	[15]	[48]	[19]
	↘	↙	↘	↙	↘	↙	↘	↙	↘	↙
Pass 2 :	[5	26]	[1	77]	[11	61]	[15	59]	[19	48]
	↘		↙		↘		↙		↓
Pass 3 :	[1	5	26	77]	[11	15	59	61]	[19	48]
	↘				↙				↓
Pass 4 :	[1	5	11	15	26	59	61	77]	[19	48]
	↘								↙
Pass 5 :	[1	5	11	15	19	26	48	59	61	77]

간만에 여유가 생겨 하고 싶었던 부분들을 하나씩 정리하고자 하는 의미에서
일단은 정보검색에 대한 개요 부분을 정리했다.

1. data vs. information retrieval
2. definitions
    - collection, volume, document, term query, IRS
3. concept
4. requirement
5. issues

로 나누어서 정리를 했으며,
정보검색에 입문 하는 사람이라면 이 정도만 알고 시작해도 검색에 대한 두려움을 약간을 떨칠 수 있지 않을까 라는 생각이 든다. (나만의 생각인가???)

암튼, 부족한 부분들은 조금씩 채워나가는 방향으로 할 것이다.

구글은 3월 초에 새로운 검색 방식을 제공하고 있다.
아직 구글코리아에는 반영이 되어 있지 않지만, Google.com에서는 제공하고 있다.
이차검색??
생소한가??

위 그림에서 보듯이 "daum"이라는 검색어에 대한 결과 중에 main URL에 해당하는 결과에 검색 창을 별도로 두고 있다.
즉, "daum"내의 검색에 대한 이차 욕구를 구글에서 해결하라는 의미인 것이다.
물론, 모든 웹사이트에 대해서 이런 룰을 적용하지 않고, 주 메이저 사이트에 한해서 보여주고 있다.
이로 인해 많은 관련 사이트들은 불만을 터트리고 있다.
이전엔 자사 사이트로 이동을 하여 검색을 했었는데, 이젠 구글 내에서의 검색이 더 이루어지다 보니
광고 수입에 전적으로 의존하고 있는 사이트들이 수입이 줄어든다고 토로하고 있는 것이다.
구글은 오히려 사용자들에게 체류시간을 늘리게 할 수 있고, PV 또한 더 올릴 수 있게 되었다.

그러나, 내가 보기엔 한국 실정과는 좀 맞지 않지 않나라는 생각이 든다.
그 이유는 많은 한국 사용자들은 포털 방식에 이미 길들여져 있구,
검색 결과가 분류별로 혹은 섹션별로 나뉘어 보여주길 원하는 욕망과는 거리가 멀다.
이차 검색창에서 검색한 결과는 아무래도 한국 실정과의 거리가 있는 듯 하여 구글코리아에서는 아직 적용을 하지 않는 것이 아닐까??
아무튼, 구글의 이런 시도는 1위로서의 아성을 지키고 싶은 욕망을 표현한 것이라 볼 수 있을 것이다.

시맨틱스에서 현재 개발/테스트 중인 Qrobo...
자사 홈페이지에 소개되어 있는 내용을 정리하자면 다음과 같다.

디렉토리 검색엔진은 예전부터 사용해 온 도서 분류학을 모태로 하여 각 홈페이지의 성격을 정하여 사용자의 접근을 좁혀 나가 결국에는 자신이  원하고자 하는 자료를 획득할 수 있었으나,
이젠 하나의 사이트가 하나의 성격을 가지는 것이 아니라, 여러가지 성격을 내포하고 있어
더 이상 구조화된 분류 체계로 표현하기 힘들다.
또한, 200억 페이지 가까이 되는 페이지를 사람(일명 서퍼)들이 일일이 분류하기엔 불가능한 일이다.

키워드 기반 검색엔진은 애매모호성을 띈다.
언어적으로 봤을 경우 하나의 단어가 여러가지 의미를 지니고 있음에도 불구하고
많은 링크가 달렸다는 이유로, 혹은 자주 봤다는 이유로 앞 페이지 대부분을 차지하여
정작 다른 의미의 정보를 원하고자 하여도 한참 뒷 페이지로 넘겨보거나
혹은 확실하지 않은 키워드를 여러개를 나열하여 좁혀 나가야 한다.
그러나, 정보에는 사용자가 원하는 키워드가 표현되지 않았다면 과연 어떻게 찾을까??

그리하여 탄생한 것이 Qrobo 이라고 한다.

검색 엔진 개발에 깊이 참여하고 있는 사람들은 최근 10년 남짓 키워드 기반의 검색엔진에 한계가
있음을 느끼고 있으며, 그렇다고 해서 이것을 뛰어넘는 기술 개발은 아직 많은 시간이 소요된다고 판단하고 있다.
나 또한 검색 엔진 개발만 10년이 넘었지만 쉽지 않은 일임을 잘 알고 있다.

언젠가는 시맨틱스가 지향하고 연구하고 있는 방향은 누군가가 해야할 임에는 분명해 보인다.
그게 1년이 걸리든, 10년이 걸리든...
결국엔 그 방향으로 가야함을 검색 기획자 또한 충분히 동의하는 부분일 것이다.

이런 전제를 놓고 현실의 Qrobo를 보자면 좋은 시도이긴 하나 첫 인상은 실망이다.

일단 시맨틱스가 지향하는 모토는 "사람의 손이 가지 않는 로봇이 만드는 검색엔진"이다.
그래서, 검색 창에 "사람의 손이 가지 않는 로봇이 만드는 검색엔진" 이라고 입력을 해 봤다.

기대감이 컸는지 실망감도 컸었다.
일단, 검색 속도는 둘째 치더라도 결과에 만족스럽지 못하였다.
단, 문서성향 분석은 그나마 위안은 된다.

최근의 검색의 추세는 비쥬얼과 시맨틱에는 의심의 여지가 없어 보이나
문서성향 분석은 이미 오래 전에 나왔던 것들이다.
내부적으로 어떻게 구현했는지 잘은 모르겠으나, 겉으로 보이는 모습은 클러스터링이다.
클러스터링과 무슨 차이가 있는지 내부가 궁금해질 뿐이다.

"Google"이라고 검색을 해봐도 별다른 반응을 주지 못할 뿐이다.
관련 키워드들로 정제되지 않은채 그대로 방치된 듯 전혀 키워드로서의 역할을 하지 못하고 있다.

여기에서 관련 키워드들이라고 제시해 놓은 것들 중에 과연 몇 개나 연관도가 높은지 전혀 모르겠다.
오히려 연관도를 잘 나타내고 있는 러시아의 "퀸투라" 엔진이 훨씬 나아 보인다.
이렇게 의외의 결과를 보여주는 것은 이젠 하나의 페이지조차 하나의 성격을 띄고 있지 않다는 것을 간과하지는 않았나 라는 생각이 물씬 풍긴다.

온톨로지를 사용한다는 것은 단어들간의 관계가 잘 정리가 되어야 한다.
이를 바탕으로 추론을 해야 하나 사람이 추론하는 거와는 정말  비교할 수 없는 결과를 낳고 만다.
또한, 온톨로지를 구축한다는 것은 아직은 Vertical한 성격을 지닐 수 밖에 없다.

아무리 기술이 뛰어나다고 해서 이러한 조건을 컴퓨터가 잘 정리할 수 있을까??
정말 사람이 손도 대지 않고 정리가 잘 될까??

아직은 정말 모체에서 갓 태어난 태아 수준이라고 밖에 말할 수 없다.
이러한 관점에서 보자면 시도를 떠나 아직은 실망스럽고 갓 태어난 내 새끼가 사람처럼 보이지 않듯
좀 더 많은 기술과 지식과 추론이 이루어져야 기는 수준이 될 거 같아 보인다.

그러나, 검색엔진...
영어로 그대로 옮기자면 Search Engine이다. 다른 표현으로는 Information Retrieval이다.
디렉토리 검색이든, 키워드 기반 검색이든 Information을 찾는 것이 아니라, data를 찾고 있다.
그 data에서 좀 더 나은 결과를 보여주기 위해 격렬한 전쟁을 벌이고 있으며 이런 전쟁에서 구글이 승자가 되었다.

앞으로는 Information을 찾아주는 시맨틱웹 검색을 취하는 자가 승자가 될 것이다.

나 또한 이런 시도에 대해서는 대만족이며, 나 또한 온톨로지와 검색엔진과의 결합을 고민하고 있으며
감성 또한 심어 보고자 노력하고 있는 중이다.

앞으로 시맨틱스의 도전과 과정을 지켜보고 싶다.

러시아 개발자들이 아직 개발 중인 비쥬얼 베타 검색엔진입니다.
(퀸투라 : http://www.quintura.com/)

이젠 이런 비쥬얼이 대세인 듯하다.
비쥬얼에 대해 4~5년 전부터 논의가 되었고,
마땅한 대책을 찾고 있지 못하고 있는 가운데 이런 시도들이 나오면서 많은 생각을 갖게 한다.

해당 키워드와 관련된 연관 검색어들을 연관도에 의해 키워드를 중심으로 보여주고 있다.
의외로 내가 찾고자 하는 키워드가 정확하지 않을 수 있음에도 불구하고
이를 충분히 보완해주는 역할을 하고 있다.

이 엔진은 소문에 야후 검색엔진을 기반으로 하고 있다는데
이러한 시도는 충분히 의미 있는 일이며 앞으론 이런 방향으로 흘러가는 것이 당연한 듯하다.

어쩜 웹2.0과 더불어 검색2.0이라는 아젠다가 이젠 서서히 두각을 드러내고 있는
활성화 시기에 접어든 거 같다.

이젠 사용자들이 정확한 키워드를 입력하지 않는 이상 많은 시간을 낭비해야 하는 불편함을
이런 비쥬얼 측면으로 많은 시간을 줄여줄 수 있을 것으로 보인다.

위 그림에서 google 우상(2시) 방향에 있는 Gmaps에 마우스를 올려 놓는 순간
질의어는 google maps로 변하며 동시에 검색 결과도 바뀌게 된다.
재미있는 아이디어이다...

만들어 놓고 쓰지 않는 함수가 if 분기로 인해 실행이 되지 않는 코드를 찾기 위한 방법으로

아래와 같이 컴파일 하면

gcc -fprofile-arcs -ftest-coverage -g test.c -o test

  test.gcda , test.gcno 와 같은 두개의 파일이 생긴다.

execution>> ./test 1000

execution>> gcov test.c

test.c.gcov 이 생성된다.

vim으로 test.c.gcov를 열어보면

        1:   10:    if(argc != 2)
        -:   11:    {
    #####:   12:        printf("Usage "%s count\n",argv[0]);
    #####:   13:        exit(1);
        -:   14:    }
        -:   15:
        -:   16:
        -:   17:    else

     1001:   38:    for(i = 0; i < count; i++)
        -:   39:    {

실행되지 않는 코드가 표시된다.
참고 : http://korea.gnu.org/manual/release/gcov/

그동안 다음 커뮤니케이션(이하 다음컴)의 검색 엔진의 역사는
한메일의 강세를 등에 업고, 투자를 받았던 독일의 기업 제품인 FireBall이라는 제품으로
서비스를 했었죠.
당시에는 n-gram 방식과 디렉토리 검색으로 접근을 했던터라 (아무래도 외산 제품이다 보니)
한국 내에서는 상당히 질이 떨어질 수 밖에 없었고 속도도 굉장히 짜증이 났었던 서비스였습니다.

왜 Fireball에 의존하고 검색엔진 개발에 박차를 가하지 못할까? 라는 의구심이 들게 했습니다.
하긴 다음컴의 탄생은 한메일이였고 검색은 안중에 없었습니다.
인터넷이라는 것이 수 많은 정보에 대한 접근이 시작인데 그걸 간과한 것이고
당장의 안위가 우선이였던 것으로 보입니다. 그런 예로 온라인 우표제가 있었죠.
이로 인해 많은 사용자들을 잃게 되는 아픔이 있어 보입니다.

계약 만료인지 검색에 대한 관심도가 높아진 것인지
오픈베이스는 영국의 잉크토미 검색엔진을 이용해서 네이버와 비슷한 검색 서비스를 시작했습니다.
2001년부터 2003년까지 오픈베이스의 외주로 검색서비스를 시도하였으나,
오픈베이스의 효율적인 운영을 위해 최소의 인원으로 최대의 효과를 얻고 싶어했었구,
또한, 당시 다음컴의 검색관련 인력은 채 20명도 되지 않아 효율적인 검색 서비스가 나오지 않았습니다.


2003년 다음컴은 검색에 대한 중요성을 윗 분들부터 인지함에 따라 본격적인 검색 서비스를
준비하기 위해 검색엔진을 교체하는 동시에 내부에서 자체 개발하기 위한 노력을 보입니다.
야후에서 검색으로 돈을 벌 수 있다는 것을 증명해 보였고,
이 시점에 구글이 무지막지한 성장을 했었구, 국내 인터넷 수성을 위해서라도 준비하지 않으면
안 되었던 것이죠.

이에 치열한 BMT를 통해 다음소프트의 TalkroIR이라는 검색엔진이 낙찰을 받고
본격적인 검색 서비스에 돌입하게 되었습니다.
이 시점에 PV가 네이버에 비해 검색관련 PV가 월등히 차이가 났었습니다.

검색서비스를 시작하면서 내부 인력도 50명으로 늘어났고,
런칭시점에 불안했던 서비스도 차츰 안정을 찾으며 많은 서비스 시도를 했었습니다.

연관검색어 서비스인 서치자키, 검색어 순위, 검색리모콘, 검색섹션 추천공, 와글과 같은 대화엔진과 같은 다양한 경험을 했었고, 나름의 성공을 거두었습니다.

PV에서의 성공이 아니라, 내부적으로 우리(다음컴)도 이제 검색 시장에서 성공할 수 있다는
자신감이 붙게 된 것이죠.
이러한 서비스들이 컨셉이 좋다고 한들 고객들의 꾸준한 사용이 없다면 서비스에서 오래 살아남지 못합니다.
결국, 많은 시도들이 3개월 이내에 사라지게 되는 아픔도 맛 보았습니다.

네이버와의 격차를 줄이기 위해 화면 구성도 2단, 3단으로 바꿔 사용자들의 추이도 지켜 보았고,
차츰차츰 검색 시장에서의 다음 포지션이 상승할 수 있었습니다.

2005년부터 '실시간 급등 검색어", "관련검색어"과 같은 피싱 서비스들이 네이버를 필두로 퍼져
나갔으며 이로 인해 각 업체들은 엄청난 PV와 광고 수입을 얻게 됩니다.

2006년 12월 다음소프트가 계약을 종료하며 검색 관련 기술 이전과 서비스 이전을 통해 빠져나왔고,
다음컴 자체에서 2005년부터 준비해 오던 자체 검색엔진 개발의 결실이 2007년부터 조금씩
서비스에서 모습을 보이기 시작했습니다.

베타 웹검색을 시도했으며, 그로 인해 수정된 사항이 최근에는 카페글로서 승화가 되어
기존 다음소프트 엔진을 서서히 교체하기에 이르렀습니다.


앞으로 다음컴의 검색에 대한 강화는 더욱 더 심화되리라 봅니다.
작년 2007년 9, 10월경에 자체 PV 결과(3,000만을 훨씬 초과)는 2003년에 비해 실로 놀라운 수치를 기록하였습니다.
현재 검색관련 인원도 200명이 되었고, 내부에서도 천대받는 본부가 아니라,
가장 파워있는 본부로 발돋움하게 되었습니다.

이젠 네이버와 대등한 위치에서 싸울 수 있다고 판단했는지 대대적인 공세를 펼치고 있습니다.
2007년엔 자체 검색엔진으로 UCC 검색을 시작을 했으며
검색과 IPTV와의 연계도 고려하고 있으며 검색 결과 화면에 대놓고 심리전을 전개하고 있습니다.

이러한 자신감은 네이버보다 훨씬 우월하다고 판단하는 카페에 있습니다.
단순 질의 응답의 지식IN이 아닌 10년동안 쌓여 있는 카페의 글이 좀 더 양질의 데이터로 판단을
하는 것이고 DB양의 차이도 엄청 나다는 데에 있습니다.
다음컴이 지식인으로 1위 자리를 확보한 네이버의 자리를 다시 뺏어올 수 있을지 흥미롭습니다.
적어도 이젠 다음컴이 쉽게 물러서지 않을 것으로 보이고, 네이버도 수성을 하기 위해
부단히 노력을 할 것입니다.
영원한 승자도 없고, 영원한 패자도 없듯이 향후 1~2년 안에 추세를 결정할 만한 결과를 볼 수
있을 듯합니다.


※ 이 글의 일부분은 조영환 박사님의 華怡價帽가 하늘을 바라보며 블로그를 인용했음을 밝힙니다.

인터넷 포털 파란(www.paran.com)에서 "항공사진 Wings" 라는 서비스를 시작했다.
위성사진은 위에서 아래로만 찍는 거에 반해 항공사진은 비스듬한 각도에서 촬영하기 때문에
식별하기가 낫다는 얘기를 합니다.


구글어스 서비스는 위성 사진입니다.
그럼에도 불구하구 실물처럼 보이는 것은 단순히 사진만을 보여주는 것이 아니라,
3D의 느낌을 주도록 하는 기술이 가미가 되었습니다.
그러나, 2D를 기반으로 해서 3D의 느낌을 주도록 했기 때문에 한계가 있습니다.
좀 더 클로즈업을 하면 굉장히 허접해 버린다는 단점이 있지요.

이에 반해 MS의 버추얼어스(Virtual Earch)는 항공사진 서비스에 가깝습니다.
버추얼어스는 한 지역을 다양한 각도에 맞춰서 수 만장에서 수 십만장의 사진을 기반으로 해서
클로즈업을 했을 경우 구글어스보다는 훨씬 깨끗하게 보입니다.

그러나 두 서비스 모두 단점을 가지고 있습니다.
사진을 기반으로 하기 때문에 지역 내의 조금의 변화가 있으면 똑같은 사진을 또 찍어야 한다는 것이지요.

파란의 "항공사진 Wings" 또한 같은 문제를 가집니다.

제가 보기엔 구글어스에 비해 좀 더 식별하기에 좋겠지만, 2차원에 한계를 벗어나지 못합니다.
또한 지역에 변화가 있을 때마다 매번 사진을 새로 찍어야 하겠죠.


각설하고 제가 파란 항공사진 지도 서비스를 검색이야기와 엮고자 하는 것은
이젠 인터넷도 점점 단순 텍스트에서 3D로 넘어가는 과도기로 보고 있기 때문입니다.

이로 의도에서 11번가의 검색 인터페이스는 상당히 새로운 시도라 판단을 하는 것이고요.
이런 지도 데이터를 단순히 지도로서만 인식을 하는 것이 아니라,
좀 더 많은 방향성을 가지고 다른 서비스들도 접근 가능할 것으로 보입니다.
그런 서비스에 또한 검색도 빠질 수가 없겠지요.

검색과 지도의 연계는 많은 생각을 할 수 있겠습니다.

파란의 Wings 서비스처럼 주로 부동산 관련해서 얘기들을 많이 하시는데,
단순 정해진 검색 조건을 이용하여 찾아가는 것이 아니라,
특정 조건을 가진 혹은 만족하는 지역을 찾아가는 것도 가능하겠지요.

그 특정 조건을 사용자가 입력을 하게되면
검색은 그 질의어들을 분석하여 조건을 만족하는 최적의 위치를 보여주는 것도 가능하리라 봅니다.

누군가는 어쩜 이런 서비스를 준비하고 있을지도 모르겠습니다.

암튼, 최근에 많은 인터페이스 및 시도들을 쏟아내고 있는 IT  인터넷 업계들을 보며
많은 생각들을 하게 됩니다.