Roess' 127.0.0.1 http://roess.egloos.com ....여기가 바로 거기 ko Thu, 29 Jan 2009 14:24:11 GMT Egloos Roess' 127.0.0.1 http://pds10.egloos.com/logo/200808/13/77/c0009177.jpg http://roess.egloos.com 80 104 ....여기가 바로 거기 <![CDATA[ 내가 쓰고 싶은 멀티미디어 검색 - 입력창에 이미지를 넣게 해줘! ]]> http://roess.egloos.com/4642276 http://roess.egloos.com/4642276
EnswerMe

엔서미(EnswerMe)는 새로 떠오르고 있는 국산 동영상 검색 엔진입니다.
현재 클로즈 베타 상태에 들어가 있고  최근 스마트플레이스 주관의 Demo Day 행사에서 시연과 전략 브리핑을 해서 뉴스도 탔는데 그 내용은 마루날님의 블로그에서 자세히 볼 수 있습니다. 메인 페이지에서 이메일 주소로 테스트 계정 신청하면 하루이틀 안에 금방 계정을 만들 수 있습니다.

처음 이 동영상 검색의 소식과 데모를 보고 흥미있었던 것은 Enswer가 검색 대상 웹 공유 동영상들의 멀티미디어 데이터 부분을 직접 분석하여 '같은 동영상', '같은 컨텐츠의 부분 동영상', '비슷한 동영상' 들을 엔진 내에서 추려내고 그 결과를 합리적인 순서로 묶어 결과 페이지로 제시한다는 소개때문입니다. 소개만 그랬던 것이 아니고 실제로도 꽤 흥미있게 동작하고 있습니다.


멀티미디어의 내용을 까서 검색하는 시대

이미지, 사운드, 동영상같은 멀티미디어 바이너리 는 사람 귀로 듣고 눈으로 보면 뭐가 뭐랑 비슷하거나 같은 동영상인지 금방 알 수 있지만 검색 엔진 프로그램 관점에서는 그냥 거대한 바이너리 청크일 뿐입니다. 그래서 현재까지의 텍스트 키워드 중심의 검색 엔진 서비스에서는 그 멀티미디어를 포함한 (링크한/임베드한-근본적으로는 그게 그거인) 웹 문서에서 멀티미디어의 메타 데이터 텍스트나 웹 문서 제목과 본문 텍스트에서 '키워드'를 추출하고 색인하여 해당 멀티미디어 바이너리의 검색 색인으로 삼고 있습니다.

네이버 비디오 검색-"노바디"
구글 이미지 검색-"노바디"

와 같은 것이지요. 자주 보던 겁니다.
각 검색 결과 아이템을 누르면 제시된 아이템(멀티미디어)을 포함하고 있는 해당 웹 문서쪽으로 리다이렉트하는 것이 현재의 멀티미디어 검색 관행입니다. 리다이렉트한 페이지에 프레임을 표시하나 안 하나 같은 것은 그냥 선택사항이구요.
보시다시피 같은 이미지/동영상도 많고, 키워드 제목은 비슷하나 의도에 맞지 않은 이미지/동영상도 무질서하게 포함되어 있으며 문서 랭킹에 의한 정렬이 된 결과이긴 하겠지만 그다지 일목요연해보이지는 않습니다.

오디오/비디오 신호처리 기술을 동원, 웹 공유 동영상의 바이너리 스트림을 직접 분석하여 각 프레임의 유사도를 평가하고 멀티미디어의 내용을 직접 인식한다는 Enswer의 검색엔진은 현재의 텍스트 키워드에 의존한 동영상 결과 분석에 비해 이런 장점을 가지고 있다고 선전합니다.
  • 중복된 동영상(동일한 동영상 소스를 여기저기 퍼나른 사용자 생성 페이지들을 포함)을 인식하여 클러스터링(묶기)한다.
  • '동일한 컨텐츠'를 담은 서로 다른 동영상을 클러스터링하면서 컨텐트의 전,후,포함관계를 인식할 수 있으므로 컨텐트의 시간 순서대로 검색 결과들을 나열할 수 있다.
  • 색인된 키워드는 같으나 실 내용은 다른 동영상은 다른 클러스터로 분류하여 일목요연한 결과를 만든다.
  • 동영상의 '퍼나르기'가 일반적인 지금 원본 동영상의 rank를 높여 우선 표시되게 하는데에 미디어 내용의 평가부분이 정확도를 높인다.
  • 저작권 동영상의 필터링 기반으로 동작하여 추후 수익모델을 구축할 수 있다.

아, 그렇군요. 프로그램(검색엔진)이 멀티미디어의 내용 자체를 이해하니 이런 장점이 있군요. 참 좋은 기술 시대예요.


그런데, 사용자 입력은?

그런데, 이 Enswer에 제가 기대했던 것 중 정말 큰 하나가 누락되어 아쉽습니다.
멀티미디어를 검색하는 사용자가 목표로하는 멀티미디어 결과에 도달하기 위해 '텍스트 키워드를 입력하는' 관행에서 벗어나는 검색 UX가 그 기대였습니다.

"노바디" 라는 텍스트 문자열과 '원더걸스 노바디 뮤직비디오 동영상'은 사용자의 뇌속에서는 의미론으로 연결되어있지만, 디지털 데이터로는 완전히 다른 것입니다. 이미지도 사운드도 마찬가지입니다.

가끔 이런 생각이 들 때가 있습니다. "지금 보고있는 이 동영상/이미지/사운드가 포함되어 있는 다른 웹페이지들을 찾아보고 싶다." "이 짤방이 제일 처음 등장한 웹페이지가 어디인지 알고 싶다."

예를 들면 이런 것입니다.

매우 자주 사용되는 유명한 짤방입니다. 유머러스하고 짓궂은 블로그 포스트들에 블로거들이 많이 사용합니다.

이게 매우 재밌게 느껴저서 이 짤방을 사용한 다른 웹문서들 (블로그 포스트들) 도 찾아보고 이 짤방을 처음 만들어 올린 사람의 페이지도 보고 싶습니다. 이왕이면 쭈욱 하나의 목록으로 만들어 보여주면 좋겠습니다.

자, 나는 이미지 검색 엔진에 무엇을 입력해야 합니까?  ........  저기..... 이미지에 대사가 들어가 있으니 그거로라도 찾아볼까요?

구글 이미지 검색 - "틀렸어 이제 꿈이고 희망이고 없어"
네이버 이미지 검색 - "틀렸어 이제 꿈이고 희망이고 없어"

뭐, 그럴 줄이야 알았지만...


틀렸어 이제 꿈이고 희망이고 없어!!! ㅠㅠ


뭐, 그렇군요. 그런겁니다. 구글의 검색 결과 페이지에는 그림들이 한참 많이 있으니 1,2,3,4,... 페이지 번호 하나씩 누르다보면 뒤에 어딘가에서 찾아질지도 모르겠네요.


저는 이럴 때 검색 엔진이 멀티미디어 자체를 입력 key로 쓸 수 있게 해주면 좋겠습니다.
이런 검색 인터페이스를 '이미지로 찾기' 옵션과 함께 제공해주는 것이지요.


                      검색할 이미지 :



음, 맨날 보던 파일 업로드 창 아니겠습니까.

  • 키워드 텍스트 입력 --> [검색엔진] --> 키워드와 같은 색인어로 분류된 이미지 포함 문서 리스트

와 함께,

  • 이미지 입력 --> [검색엔진] --> 같은 이미지를 포함한 문서 리스트                                         
  • 이미지 입력 --> [검색엔진] --> 같은 이미지의 부분을 포함한 문서 리스트
  • 이미지 입력 --> [검색엔진] --> 비슷한 이미지(변형, 패러디) 를 포함한 문서 리스트

이런 걸 추가해주는 것이지요.
또, 웹 상에 존재하는 이미지 자체의 '링크'를 입력받는 방법도 있습니다. 이미지를 포함한 문서의 URL을 입력받는 방법도 있겠습니다. 어느 쪽이든 사용자의 입력으로부터 얻어지는 '멀티미디어 바이너리'를 시작점으로 그것을 key factor로 저장된 문서 검색 결과를 얻게 됩니다.

화제가 되고 있는 사건사고 이미지에 대해 그 이미지를 포함한 원본 뉴스 페이지나 블로거들의 왈가왈부 평가 포스트를 보고 싶을 때, 재미를 느낀 동영상을 포함하며 논평을 늘어놓은 웹페이지들을 찾아보고 싶을 때, 즐겁게 들은 음악이나 사운드 파일을 처음 공개해 걸어놓은 페이지를 찾고 싶을 때... 등등. 저 위에 꿈도 희망도 없는 짤방이야 그렇다치고, 생각보다 많은 사용 사례가 나올 수 있을 것 같습니다.


가능한 얘기인가, 동영상도 가능한가

동영상도 가능합니까? 약간 간접적이지만 현재에도 가능해보입니다.

  • 사용자의 PC에 다운로드되어 있는 동영상 파일이라면 이미지와 마찬가지로 파일 업로드한다.
  • 웹에 있는 동영상이라면 대부분의 flash 기반 웹 동영상은 동영상 페이지 URL과 퍼가기(embed)용 script를 제공하므로 그걸 복사하여 입력한다.
  • 현대적인 브라우저들은 페이지에 보여지고 있는 멀티미디어를 툴바나 외부 입력창으로 마우스 Drag할 수 있는 UI를 가지고 있으므로, 그것을 이용하는 브라우저 플러그인을 제공한다
  • 마우스 오른쪽 버튼 메뉴에 ".....로 이미지/동영상 검색" 같은 메뉴를 만들어 확장할 수도 있다.

이렇게 입력받은 'Key 동영상'은 예를 들면 Enswer같은 회사가 갖고 있는 멀티미디어 분석 기술을 이용하여 유니크한 바이너리 지문 (Finger Print)을 얻어내고, 이미 자체 색인 결과에 잘 저장되어 있을 '동영상별 Finger-Print'를 고속 검색하여 비디오와 원본 문서를 동일한 순서대로 정리해 결과 페이지로 제시하면 되는 것입니다.

Enswer의 경우, 뒷 부분들은 다 개발해 놓은 상태라고 보입니다. 그러니까 동일/유사 동영상 클러스터링 결과를 보여주고 있는 것이겠지요?
다만 해결해야 할 것은 지금 막 입력된 Key 멀티미디어 파일을 분석해서 색인과 비교할 Key 데이터로 변경하는 것은 입력된 텍스트를 처리하는 것보다 훨씬 많은 시간이 소요된다는 점입니다. 사용자를 너무 기다리게 해서는 안 되지요. 이걸 고속화하는 것은 분산 처리와 동시성 처리를 통해  최적화해나갈 수 있을텐데요, 뭐 Demo Day 내용 보니까 Enswer에는 분산 동시 처리 전문가도 있으시다니...

오우, 엄청 쉬운 것처럼 말하고 있네요. 저보고 하라면 하지도 못하면서!

하지만, 어렵고 세심한 기술이긴 해도 Enswer의 기반 기술을 '비디오/오디오 신호처리를 이용한 구별'이라고 말하듯이 동영상과 함께 이미지와 사운드 부분에서도 해당 요소 기술은 꾸준히 발전해왔습니다.


"음악지문? 이거 뭐야?"  [via 한겨레]
"image Fingerprint" 검색 결과 - google


기억하기에도 한참 전에 이미 전화기에 '들려오고 있는 음악을 입력하면' 곡 정보를 찾아 알려주는 이동통신 서비스도 있었구요(그런데 이 좋은 기술은 서비스도 접고 어디로 소리소문 없이 사라졌는지 모르겠네요), 모바일에서의 불편을 해소하기 위해 이미지 인식 기술을 정보 검색에 이용하는 사례도 이 블로그에서 알려드린 적이 있지요. 특히 '이미지'라면 왠만한 크기의 이미지라도 그 Key finger print 생성 과정은 순식간일 것이므로 바로 적용할 일도 멀지 않을 것 같습니다.

구글도 이런 준비를 하고 있습니다.

"VisualRank" 라 이름붙인 이미지 유사성 분석 기반 검색 알고리즘에 대해 올해 5월에 연구 중인 컨셉을 발표했지요. (링크를 방문하면 약간정도 학술적인 PDF 파일도 다운받아 볼 수 있습니다.)

요소 기술이 많이 개발되어있고 새 서비스 UX에 대한 기대가 많은 요즘같은 분위기라면, 비교적 적은 투자로 서비스의 질을 획기적으로 바꿀 수 있는 "멀티미디어 직접 입력"에 대해서 생각해볼만 할 것 같습니다.

Enswer로 말하자면, 구글이 아직 손대지 않은(내부적으로 손 안 댔을리가 없지만 아무튼..)  웹 비디오 데이터 분석과 Finger-print 생성 방식을 이미 타이밍 좋게 확보한 김에, 검색 사용자의 경험 측면에 대해서도 더 연구해 주면 좋겠습니다. 런칭한 서비스가 안착하도록 빨리 쐐기를 박아야지요.

텍스트로 키워드를 입력하는 방식은 필수적인 요소이긴 하지만 그것만 가지고는 너무 지루합니다. :-)


Roess



tag : , , ,  ]]> 멀티미디어검색 멀티미디어인식 검색Key Enswer http://roess.egloos.com/4642276#comments Mon, 29 Sep 2008 12:51:03 GMT roess <![CDATA[ 아이폰 (iphone) 공장 소녀 ]]> http://roess.egloos.com/4568804 http://roess.egloos.com/4568804
<이미지는 Gizmodo 사진 겔러리로부터 http://gizmodo.com/photogallery/iphonefactorygirl>


낄낄 아이고 웃겨.

아이폰 생산을 하는 중국 공장은 일반인의 접근을 통제하는 보안시설일 것이 당연할텐데요.
거기도 공장이니까 패키징되는 제품들을 마지막 순간에 선별 검수한다든지 하는 절차들이 있을 거고, 이런저런 기능 테스트와 함께 사진 기능 테스트도 하게 될 겁니다.

가끔 작업자들의 실수로 찍었던 사진 안 지우고 출하되는 물건들이 있나본데, 한 두달 전인가도 공장 작업대와 전경이 살짝 물려나온 사진이 인터넷에 떠돌았었죠. 아이폰에 대한 좀 지나치다 싶은 열기 때문에 괜한게 다 화제가 되곤 했었는데요.
이번에는 공장에 근무하는 귀여운 표정의 젊은 여성 사진 서너장이 담겨나와 또 재밌는 풍경을 연출해주고 있습니다.

Gizmodo의 사진 겔러리에 해당 '제보'된 이미지들이 걸려있는데 그 밑에 리플들이....

- "완전 예뻐!"

- "하루에 몇 백번이라도 보고 싶은 사진이다"

- "실수했다고 이 아가씨 해고될까봐 걱정된다"

- "중국 쪽 공장장님 이 아가씨 자르지 마세요!"


뭐 이런 것들 태반...

껄껄, 상황과 대상의 본질에서 약간 비껴난 엉뚱한 측면으로 갑자기 네트워킹 러시가 일어나는 게 인터넷 전반에 종종 보이지만 (빠삐코도, 미녀 수배범 때도, 그리고 솔직히 말하자면 괜찮은 외모의 젊은 여성이 얽혀있을 때 특히 더), 늘 그렇듯이 이번에도 웃겨줬습니다.
철두철미하다는 아이폰 생산라인의 보안 상태나 네티즌들 반응이나 약간 '삑사리'에 가깝지만, 뻑뻑해보이는 세상이 종종 천진난만하게 웃을 일을 만들어주니 그것도 좋네요.

그나저나 정말 뭐 이 일때문에 직장을 잃는다거나 하는 바보짓은 안 생기겠지?
아, 그리고 저 위에 링크 들어가면 두어 장의 다른 사진들도 볼 수 있는데, 뭐 괜히 "안 예뻐", "내 취향 아니야" 이런 식으로 나온다면 당신은.... 역시 삑사리. 낄낄.


]]> http://roess.egloos.com/4568804#comments Sat, 23 Aug 2008 05:21:33 GMT roess <![CDATA[ 4시간만에 검색 엔진 서비스를 - 4HourSearch와 Yahoo BOSS API ]]> http://roess.egloos.com/4545550 http://roess.egloos.com/4545550


CUIL과 YUIL과 4HourSearch

Google에서 나온 주요 개발자들이 만들었다는 새로운 검색엔진 CUIL이 화제를 모았던 것이 불과 한 두 주밖에 안 되었지요.
취향에 따라 CUIL의 검색 결과 표시 방식이 좋다는 사람 아닌 사람 다양했지만, 구글로 대변되는 초 고용량 인프라 운영 기술을 표방하며 새 플레이어가 나타난 것 자체가 사람들을 재미있게 해 주었습니다. 다만 다국어 검색 결과에 대해 기대를 충족 못 시키는 Beta 특유의 모습을 보여주는 건 한국이나 일본의 호사가들에게 충분히 씹혔었구요.
현재 CUIL 첫 페이지에는 1억 2천만 페이지가 넘는 웹페이지가 수집되어 있다고 표시되고 있는데 부쩍부쩍 늘어나는 페이지 인덱싱 량을 해결하기 위해 그 뒤에서 어떻게 인프라들이 팽팽 돌고 있을지 생각해보면 약간 아득합니다.

그런데, CUIL 런칭 이후 좀 있다가 YUIL이라는 서비스가 소개되었습니다.
CUIL과 동일한 UI를 가졌을 뿐 아니라 인덱싱된 페이지의 규모나 검색 결과도 그닥 차이 나지 않았던 이 서비스는 "이 짧은 시간에 누가 이정도로 따라 잡을 수 있는거야" 식의 놀라움보다는 "아니 뭐 이런 짓까지 ㅋㅋ" 류의 가십성 화제를 불러일으켰는데 다름이 아니라 야후의 검색 관련 임원(Sam Pullara)이 자사의 검색 API 플랫폼 BOSS와 Google App Engine을 이용하여 장난 치듯이 뚝닥 CUIL 클론을 만들어낸 Mash-up 결과물이었기 때문입니다. 약간 치기 어리다는 느낌이지요. 이름도 'Yahoo+CUIL'인가요.

구글이나 CUIL이나 검색엔진이라면 고용량의 문서를 처리할 back-end 인프라의 조직이 얼마나 견고하고 효율적이냐의 과제를 벗어날 수 없을텐데, UI 구성 방식과 달리 결코 작은 아이디어와 아마추어적인 기획으로 감당할만한 문턱이 아니지요.
그런데, 주어져있는 API 환경들과 호스팅 환경을 적당히 엮어 나름대로 잘 돌아갈 수 있는 '검색 엔진'씩이나 금방 만들어낼 수 있다고 하니, Yahoo 임원 입장에서는 치기어려 보일지라도 한 번 꼭 과시해보고 싶었을 법은 합니다.
아무튼 YUIL 서비스 자체는 잠깐의 화제와 함께 금방 내려졌습니다. (남의 서비스 배낀 거 농담으로라도 계속 유지하기는 좀 힘들었을 법 합니다. TechCrunch는 "Yahoo나 CUIL 중 누군가는 유머 감각이 좀 부족했던 듯.." 이라고 논평했지요. 역시 한 번 더 ㅋㅋㅋ)


4HourSearch 소스 제공!

그런데, YUIL 개발자들은 이 서비스를 4HourSearch 라는 이름으로 다시 열어놓고 (UI 등이 CUIL과 완전히 동일하지는 않습니다) 이제는 그 '소스 코드'까지 다운받게 해 놓았습니다. @.@
예, 이름이 표방하고 있듯이 4시간 정도를 투자해 만든 Yahoo BOSS + Yahoo YUI + Google App Engine Mash-up 어플리케이션이라는거지요.
들어가보면 아시겠지만, 이론적으로나 실질적으로나 검색 결과 컨텐트는 http://search.yahoo.com 에서와 동일합니다. (다국어 검색 결과 / 국내 검색 결과의 밀도와 조직화는 국내 Yahoo 검색의 튜닝을 전혀 타지 않았으므로 CUIL과 비슷하게 그다지 만족스럽지는 않습니다)

Web2.0 매쉬업에 관심이 많은 가난한 개발자라면 그들의 방법을 참고해볼 참으로 소스 다운받아 살펴보는 것도 괜찮을 것 같습니다. Zip 압축된 소스 파일이 전체 32kb에 지나지 않습니다 (꽥)

서버 한 대 안 사고, 크롤러나 인덱싱 엔진 제작 하나 안 하고 전세계를 대상으로 하는 검색 엔진 서비스를 만들 수 있는 시대가 된거네요.
재밌다는 느낌과 함께 뭔가 허망하기도 한 이 기분은?






tag : , , ,  ]]> 4HourSearch 검색엔진 Yahoo BOSS http://roess.egloos.com/4545550#comments Mon, 11 Aug 2008 10:50:56 GMT roess <![CDATA[ 구글 SMS ]]> http://roess.egloos.com/4499462 http://roess.egloos.com/4499462 구글이 세계를 지배한다면 에 대한 트랙백입니다.


어우, 트랙백한 푸른하늘님 글에 달린 댓글들은 너무 진지들하셔요...
웃자는 납량특집 구글 동영상 하나 더 보시고.. 그냥 웃어요. ㄳ

(자막 있어요~ powered by subtitle.in)


[via textually.org]

코메디 그룹인 Vacationeer의 작품.
다른 작품들("Googling" I~III 포함)을 더 볼 수 있는 곳




]]> http://roess.egloos.com/4499462#comments Sun, 20 Jul 2008 03:16:23 GMT roess <![CDATA[ mjelly's view on the mobile web ]]> http://roess.egloos.com/4494206 http://roess.egloos.com/4494206
clipped from blog.mjelly.com

- Google mobile are moving all development away from downloadable apps to the mobile web (wow! this is big news)

- but mobile web apps also suck at the moment:

  - can only support one javascript thread or the UI blocks

  - can't access location, camera, address book

  - high latency etc

 blog it


tag : ]]> mobileweb http://roess.egloos.com/4494206#comments Thu, 17 Jul 2008 09:35:12 GMT roess <![CDATA[ "애플 앱 스토어(App Store) 좋지!... 애플한테는." ]]> http://roess.egloos.com/4481806 http://roess.egloos.com/4481806 The Apple App Store - What A Good Idea... If You're Apple [via Mobile Messaging 2.0, Ewan Spence]


애플 앱 스토어 오픈

아시다시피 아이폰(iphone)과 아이팟터치(ipod touch)를 위한 애플 앱 스토어가 오픈했고, 애플은 오픈 초기 500개의 어플리케이션을 제공하며, 그중 1/4 정도는 무료 어플리케이션으로 준비할 것이라고 했답니다.
기존의 mp3 판매 방식과 같이 아이튠스(iTunes)를 그 GUI로 사용하여 메뉴 중 하나로 동작합니다.


앱 스토어 - 또 하나의 Walled Garden?

낚시성(!)임을 인정하는  이 포스트의 제목은 저 위에 링크로 소개한'Mobile Messaging 2.0'의 까칠하고 시니컬한 필자 중 하나인 Ewan Spence의 글 제목에서 왔습니다.
미리 배경삼아 말씀드리자면 Ewan Spence는 애플 아이폰에 대해 종종 비판적인 태도를 보여오고 있는 필자입니다. 아이폰이 세계의 이동통신을 완전 집어삼킨 것처럼 난리 필 것 없다, 유럽 판매 상황만 봐도 썩 그렇지는 않다... 같은 취지의 글을 쓰기도했고요.

그렇다고 Spence의 글을 완전히 무시할 만한 것도 아닌 것 같아 굳이 소개하는 중입니다.
전반적으로 애플과 앱 스토어가 어플리케이션 제작사들을 위한 또 다른 Walled Garden으로 동작하는 것 아니냐는 비평인데요, "Perhaps it is for Apple, but not for the developer community." 라고 깊은 회의를 보여주고 있습니다.

듣자하니 이런 얘깁니다.

아이튠 앱 스토어의 상품화면이란 어차피 한정되어 있고, 잘 나가는-추천받는 상품이 되려면 개발자(사)들은 그(App Store) 안에서도 사용자들의 시선을 끌기 위해 홍보를 위한 웹사이트를 꾸려야 할 것이며 자신들의 상품(소프트웨어)이 동종의 다른 상품에 비해 우월함을 홍보하기 위해 시장에서의 마케팅 노력을 기존과 같이 계속해나갈 수밖에 없다는 것입니다.
애플은 상품 리스트 표현을 순환하는 방법 등을 고려하겠지만 불분명한 (애플 단독의) 기준에 의한 것일 뿐. 개발자(사)들이 상품을 개발하고 업로드하고 마케팅 노력을 여전히 기울이는 동안, 애플은 아이폰과 아이팟 터치를 위한 유일한 판매자의 지위를 공고히 할 뿐이고 이 시장의 '콘트롤'은 애플 혼자서만 가져가게 된다는 것이지요.

윈도우즈 모바일을 위한 패키지(.cab) 파일과  심비안(Symbian)을 위한 패키지(.sisx) 파일, 자바 어플을 위한 .jar 들이 제작사의 선택에 의해 어디서든 다운로드 되고 판매될 수 있는 방식과 왜 다르냐고도 하고 있습니다.


오~, 그럴듯 해?

모바일 어플리케이션 상업 환경에 관한 애플의 행보에 대해, 이미 열정적인 팬덤(Fandom)을 형성한 애플 모바일 상품 소비자들은 희망 일색으로 칭송하는 분위기입니다. 국내에서도 다르지는 않지요.
Spence씨의 글이 이런 축제 분위기에 괜한 까칠함을 드러내는 걸로 보여질 수도 있겠지만, 사실 제 마음 속의 불안한 미심쩍음을 슬쩍 자극하긴 했습니다.
왜 그런가 스스로에게 물으니, 제가 모바일 CP 입장에 제 정서를 투영하고 있기 때문이더랍니다. 이동통신사의 Walled Garden 담장에 들러붙어 시들시들 말라들어간다고 코웃음 당하는 그 모바일 CP의 한 직원 마인드이지요.

모든 종류의 애플 플랫폼에서 상품의 개발 경험이 전무하긴 합니다만, 저도 연초에 애플의 포터블 기기들에 대한 SDK 공개와 앱 스토어 정책들을 유심히 보게 됐습니다. 그리고 보면서 좀 의아한 질문을 주위에 하곤 했습니다.

  "아니, 애플이 상품 판매비를 30%나 떼어간다고? 이봐, 이동통신 망 사업자에게 다운로드  상품 공급 계약을 할 때도 그만큼은 아니라고."

반면 애플이 30%를 가져가는 분배 정책과 함께 스티브 잡스가 앱 스토어 비전을 발표하는 작년인가 올 초인가의 프리젠테이션 행사장은 박수와 함께 열광의 분위기였다고 하더군요.
저는 여전히 30%:70%가 도대체 어떤 근거로 잡힌 분배 비율인지 이해는 못 합니다만(거기다 Apps 등록비라는 것도 있다는데), 애플의 기술 플랫폼을 둘러싼 개발자 커뮤니티가 그걸 환호와 함께 받아들였다니 그것도 나름대로 그 바닥 풍토에서는 받아들일만 한가보다 생각하기로 했습니다.

하지만, 그런 상업 조건이 형성되어 있다면 모든 매출의 30%를 '플랫폼을 소유했다는 것만으로' 차지하는 대형사업자는 파트너 개발자들을 위한 더 넓고 열린 환경 (요즘은 '에코시스템'이라고도 많이 말하던데) 을 형성시켜줄 의무는 있을 것 같습니다.
사실 단일 플랫폼에 자신의 살을 깎아 달려드는 개발 업체는 그런 걸 기대하고 있기 때문이지요. 10000원짜리 상품을 개발한 회사가 하나 팔아 매출을 7000원밖에 못 얻는 건 개발자(사) 하나하나에게는 장난이 아닌 현실의 문제지 않습니까. 매출을 30% 끌어올리려고 당신의 직장에서 당신과 동료들이 겪는 고생과 회한을 떠올려보세요.

기존의, 특히 국내의 이통 사업자들이 비판받는 이유도 판매비를 떼간다는 표피적인 것보다는 그러면서도 자신의 정원을 수성하기 위해, 사업의 '콘트롤'을 홀로 독점하기 위해 전체 모바일의 에코시스템을 훼손했다는 지점입니다. 이게 지난 10여년간의 모바일 산업의 어두운 면이였습니다.
그런데, Spence의 의혹대로 애플도 역시 '그 짓'을 하려고 하는 거면, 지금의 열정적인 분위기는 결국 비슷하게 시들해지지 않겠나 하는 생각이 드는 겁니다. 이동통신사의 Walled Garden에서 단말 플랫폼 사업자의 Walled Garden으로, 매달려있을 담장만 바꾸는 꼴이 된다면 누구에게도 바람직하지 않겠지요.


결론이 뭔데?

모르겠습니다 -_-;
사실 잘 모르게 됐습니다.

그래도 그렇지, 애플과 애플 앱 스토어가 모바일 산업의 '개방과 혁신'의 화신인 것처럼 무조건 칭송되거나, 그 아이폰이 국내에 못 들어온다는 사실과 그 중 하나의 이유가 WIPI 라는 것 때문에 '우리가 웃음거리' 될까봐 걱정씩이나 하는 것은 좀 심하지 않나 싶습니다.
필요가 있으면 걷어내거나 개선하면 되고, 새로 들어올 물건과 환경은 차악이 아닌지 냉정하게 경계하고 분석하며 여유있게 대응해야지요.

자, 저 위에 줄줄 써놓은 '판매방식'과 '세금'의 압박을 무시할만큼 개발사에게 더 도움이 되고 리워드가 될만한 다른 비젼들(그리고 세부적이고 사려깊은 정책들!) 이 있는 건가요? 제가 모르는 게 있으면 '소통'을 위해 알려주세요.

제가 뭐, 아이폰 SDK로 나도 새 플랫폼용 개발 연습 좀 해봐야지 하다가 할려면 맥을 '사야' 된다는 거 확인하고 어느 날 새벽엔가 혼자 버럭했던 기억때문에 까칠하게 굴고 있는거 아닙니다. 진짜라니깐요.
기존 모바일 어플 개발팀이 Object-C 로 개발할 수 있도록 재교육과 재조직되려면 시간과 비용이 어떻게 투자되야 하는거지 같은 걱정 하면서 괜히 신경 날카로워지고 그럴 수도 있지만 그런게 다 발전이다 생각하기로도 했어요. 진짜예요.

그러니까 한 번 가르쳐 주십쇼. 굽신굽신 (인정합니다. 결론이 매우 이상합니다!)






tag : , ,  ]]> apple appstore 앱스토어 http://roess.egloos.com/4481806#comments Fri, 11 Jul 2008 11:57:10 GMT roess <![CDATA[ iPhone을 이용한 모바일 비주얼 검색 (Visual search) - ViPR / evolution robotics ]]> http://roess.egloos.com/4318227 http://roess.egloos.com/4318227


무선인터넷 인프라와 서비스 관련 직업을 몇 년간 해오고 있음에도 모바일 검색에 '키워드'를 입력해 넣다가 짜증이 용솟음치곤 하는 일이 종종 있습니다.
익숙하지 않은 키배열도 그렇고 WAP 브라우저가 제공하는 인풋 박스의 동작도 그렇지요. 한글과 함께 영어, 숫자 등을 번갈아 입력하려면 더 합니다.

WAP이 아니면 괜찮은 편인가요?
그렇지도 않은 것 같습니다. 스마트폰이나 PDA류의 모바일 단말이 흔히 제공하는 software 키패드를 이용해 뭔가 '문자열'을 찍어넣는 것 자체도 평균적인 사용자들에게 널리 받아들여지기는 참 어려워 보입니다. 예를 들어 저의 부모님에게 이런 feature들을 잘 설명하고 일상적으로 즐기시도록 만들어라 한다면 자신 없어집니다. 나이 어린 제 조카에게도 마찬가지이네요.

무선인터넷이 활성화되지 않았다는 평가들이 많은데, 모바일 단말 고유의 '방식'이 충분히 성숙하지 않았다는 것도 그 이유 중의 하나일 것 같습니다.

그래서 무선인터넷 영역에는 사용자의 검색 key factor 입력을 더 직관적으로 구성하기 위한 시도들이 늘 있었습니다.
  • RFID를 이용한 검색 입력
  • QCode, 2차원 바코드 등 이미지 identifier 를 이용한 검색 입력
  • WINC 와 같이 서비스 End-point를 코드화 하는 것 (이것은 검색 대상의 key factor를 입력하는 것과는 좀 다르지만 아무튼)
검색 대상의 직접적인 디지털 이미지를 이용한 검색 방법을 광범위하게 지칭하는 visual search도 그와 마찬가지로 keyword 문자열을 사용자가 찍어넣는 과정을 직관적으로 생략하는 시도 중의 하나입니다.

위 동영상은 직접적인 무선인터넷 서비스나 단말 사업자는 아니지만, 그 Back-end로 동작하는 이미지 인식과 분석 기술을 제공하는 Evolution robotics, Inc. 의 ViPR 엔진을 이용한 데모 서비스 시연입니다.
검색 대상의 이미지를 폰 카메라로 찍고 그걸 이메일로 보내면 정보 조회 결과를 (다른 정보 source로의 링크들을 포함하여) 다시 이메일로 전달받는 다는 것이군요. 이메일을 중간에 매개체로 사용하는 것이야 변경될 수도 있는 방법이겠지만, 아이폰의 부드러운 UI 전환, 풀브라우징, 동영상 재생 기능 등과 어울려 데모 상태에서도 그럭저럭 매력적으로 보이는군요

ViPR 엔진은 일본 Bandai 와의 협력으로 KDDI가 차후 출시할 모든 단말에 위와 같은 Visual Search feature를 탑재하겠다고 사업 발표를 하기도 했습니다.







tag : , ,  ]]> VisualSearch Mobile 무선인터넷 http://roess.egloos.com/4318227#comments Sat, 26 Apr 2008 11:27:08 GMT roess <![CDATA[ Deep web까지 자동 수집 해주겠다고 나선 구글봇(Googlebot) ]]> http://roess.egloos.com/4291576 http://roess.egloos.com/4291576 HTML form 을 이용한 웹페이지 수집
Crawling through HTML forms  [via Google Webmaster Central Blog, 2008.04.11]


구글이 크롤러(Crawler)를 개선하여 이른바 "Deep Web" 이나 "Invisible Web"로 알려진 HTML form 입력 이후의 동적 생성 페이지들까지 자동화된 인덱싱(indexing)의 대상으로 삼는 실험을 수 개월 전부터 진행하고 있다는군요.

보통 <form action=...> 태그를 사용하여 입력을 받는 요소들이 포함된 페이지는 브라우저 상에서 사용자 (그러니까 진짜 '사람' 사용자;;)의 직접적인 오퍼레이션이 있기를 기대하며 제작되는 것이고, 이 페이지들에 뭔가 자동화된 프로세스가 값을 채워넣고 동적으로 페이지 생성을 요청해댄다면 그건 주로 SpamBot 들의 행태이기가 십상이지요.

구글은 text box, select box, radio button 등의 HTML 표준 input element 에 해당 html 문서에서 얻어진 '적절한 범위의' 입력을 자동 생성하고 그에 의해 생성되는 동적인 페이지들을 인덱싱하고 있다며, 그러나 "피해 없게 잘 할 수 있다!" 고 주장하고 있습니다.

그 근거로는
  • 한정된 수의 유용한 사이트에 대해서만 이런 crawler 기능을 적용한다  (근데 그 '유용한' 사이트는 누가 결정을?)
  • robot.txt 와 "nofollow", "noindex" directive 준수한다  (근데 robot.txt 와 noindex 등도 제대로 설정 안 했지만 이래저래 직간접적인 사용자 정보를 처리하고 있는 좀 덜떨어진-웹에는 지천으로 널린-사이트들은?)
  • GET 요청되는 form만 crawl에 포함한다 (근데 바로 위의 좀 덜떨어진 사이트가 form 파라미터 전달을 GET으로 하는 미묘한 구성을 하고 있는 경우라면?)
  • login, userid 등을 처리하는 password input이 있는 경우 처리 제외 
등등.

좋습니다. 착하게 굴겠다니 좋은거지요.
이런 '좀 더 후벼파주는' crawler가 순효과를 가져오는 몇몇 케이스들은 바로 상상 가능하군요. 예를 들면 체크옵션 박스나 라디오 버튼 선택으로 상품 카테고리를 제한하여 페이지를 보여주는 기능이 있는 쇼핑몰 사이트들은 각각의 동적인 개별 페이지들이 검색엔진에 인덱싱 되어 좀 더 노출의 기회를 얻는다든지..

그런데, 세상과 마찬가지로 이 웹세상도 이렇게 착하고 질서에 맞게만 구성되어 있는 것은 아니지 않습니까.
구글봇의 의도와 달리 특정 사이트에서의 페이지 구조 구현에 따라 공연한 SpamBot같은 역할을 하게 될 수도 있고  말이지요.

Googlebot, WTF are you doing?
벌써 이런 반응도 있네요.


저도 웹서버 이용한 개발하면서 초기 개발 스케치로 그저 입력 대충 할 수 있는 form 구성해놓고 입력값의 서버측 검증 대충대충 때우면서 쓱쓱 pilot 만들어 올리고 하는 경우도 있는데 말이지요. (그리고 고백하자면 이렇게 쓱쓱 개발하다 잘 디자인된 이미지들 대충 엮어서 눈에만 그럴싸하게 보이게 한 채로 '상용 가동'씩이나 한 경우도 솔직히 있습니다. robot.txt 나 적당한 page directive 고민들도 없이...)
꽤 많은 '상용으로 배포되고 있는' 페이지들이 사실 이런 비슷한 실정에 놓여 있다는 것도 우리는 알고 있는데요.

SpamBot과 해킹의 '밥'이 되는 이런 널널한 구현들은 앞으로 자칫 검색엔진에 노출되어서는 안되는 output까지 홀라당 긁혀버리는 참사를 맞을 수도 있겠습니다.
더 정신차리고 웹에 임할 수밖에 없는 시대가 더 빠르게 오는군요.






tag : , ,  ]]> 구글봇 Crawler DeepWeb http://roess.egloos.com/4291576#comments Mon, 14 Apr 2008 11:39:00 GMT roess