YDN 2회 간략한 후기

오늘(09년 8얼 25일) Yahoo! Korea에서 2번째 YDN이 있었습니다. 

이번 YDN에서는 YUI 3와 YQL을 소개 하였는데, 이에 대해 간략한 후기를 적어보도록 하겠습니다.
참고로, 이 후기는
지극히 개인적인 경험을 기반으로
지극히 개인적인 의견을 덧붙이는 것입니다.
YUI 어려워요
과거 YUI를 가지고 개발을 하는것은 사실 어려웠었습니다.
prototype.js나 jQuery처럼 Core로 사용하기에는 복잡한 Relationships와 도움이 될만한 Reference가 적었기 때문이었죠.(제공하는 Reference는 Interface(Visual적인)에 대한 것들이 대부분이 었죠)
적어도 제가 YUI를 사용해볼려고 시도를 했을때는 그랬었습니다. 어쩌면 제가 못찾은걸 수 도 있겠죠 ;p
이젠 쉬워요
YUI 3에서는 Core로 사용하여도 어려움 없이 사용할 수 있도록 Name Space가 구성되었습니다. (어쩌면 YUI 2에서 지원되었던 것일 수도 있죠.) 우리가 흔히 사용하는 prototype.js, jQuery의 그것 처럼요.
이제는 YUI로 쉽게 Event Bind할 수 있고, 쉽게 DOM을 Select할 수 있으며, 쉽게 Animation Effect를 구현할 수 있어요.

가볍고, 빨라요

발표 내용중에 “가볍고, 빠르다” 라는 내용도 있었는데

사실 다른 Libraries와 비교해서 그렇게 딸리지 않는다
내부적으로 테스트했을땐 타 Libraries와 충분히 경쟁력이 있다

라고 하셨어요.(이 부분은 제가 못들었고 같이 있던 분이 이런 말을 했다고 제게 말씀해주셨습니다.)

Rails에서 쓰고 싶은데
제가 봤을땐 이제는 나름 쓸만해졌다라고 판단이 되어, Rails에서도 사용할 수 있는 Convertor가 있냐고 질문을 했었는데 “잘 모르겠다”고 하시더군요.(이 질문이 Jenny에게 전달 되기까지 힘들었습니다 ㅠ,.ㅠ)
진입장벽
우리가 익히 사용해왔던 Prototype.js, jQuery와는 틀린 Method Names를 가지고 있기 때문에 이것을 익히는데 시간이 소모될 듯 합니다. 하지만 과거처럼 어렵게 구성이 되어 있지 않아 쉽게 넘을 수 있을것 같습니다.
사실 이러한 진입장벽은 새로운것을 배울때 소모되는 지극히 당연한 기회비용이죠.

YUI에서는 축약식 Naming을 사용합니다.
예를들면 Drog&Drop기능을 “dd”로 선언하더군요.
이런류의 축약식 Naming은 양날의 검이죠. 코드를 짜는 사람의 입장에서는 쉽게 타이핑 할 수 있지만.. YUI를 잘 모르는 사람이 code를 보면 이게 무슨말인지 알 수 없으니 말입니다.
그리고 개인적으로 이런식의 Naming을 좋아하지 않습니다.

선입견을 버릴 수 있다면

“무겁다”, “느리다”, “어렵다” 이러한 YUI의 선입견만 버린다면
한번 사용해보는것도 나쁘지 않을 듯 합니다. (물런 실험정신 및 확인정신(사실인지)가 조금은 필요합니다. ;p)
YQL

오해

사실 저는 Pipes가 생긴게 ERD같아서 설계할때 사용하는 UML같은 것인줄 알았었습니다. 그런데 그런것이 전혀 아니더군요. Data Collector(?)이고(자세한 설명이 필요하신분은 @phphloveme님께 질문을!)
YQL은 Pipes의 개발자용 업그레이드 버전이라고 축약할 수 있겠습니다.
Query날려서 Web상에 있는 Data를!
SQL과 비슷한 문법으로 Query를 날려 Data를 Collect해오는 것이 YQL입니다.
Crawler를 만들거나 API를 통해서 Data를 Collect해오는것을 만드는것은 사실 귀찮은 일인데, Query만 날리면 바로 값을 Return해주죠.
오! 귀찮은 일을 줄여주었군!
저는 “와.. 이제 Crawler랑 API랑 통신하는 코드 안짜도 되겠다! 만세!!”라고 생각하며 기쁜마음으로 어느정도의 트래픽이나 규모를 감당할 수 있느냐고 질문을 했었는데

이건 Data가 어떻게 모이나?(혹은 보이나?) 정도로 사용할 수 있는 Prototype용으로 사용할 수 있는 서비스

라고 하시더군요. 어떤 질문자분께서

사용해봤더니 하루에 4000K 트래픽밖에 허용이 안된다

라며 불만을 표하시기도 했었습니다.

재미는 있을 것 같은데, Prototype을 위한 서비스여서..
Prototype을 위한 서비스라 트래픽, 규모, 안정성 부분에 한계가 있어, YQL을 이용해서 서비스를 개발하기엔 무리가 있는것 같습니다.

결국은 내가 다 만들어야해
결국엔 Crawler나 API랑 통신하는 코드 다 짜야한다는 결론이 나옵니다.
이러한 결론을 도출하고 보니 YQL의 매력과 흥미가 사라지더군요.

추가
정진호님께서 제가 했던 YQL의 질문에 대한 답변을 정정해주셨습니다.

Pipes 와 YQL이 트래픽의 제한이 있지만
반드시 프로토타입 제작에만 사용되는 것은 아닙니다.즉, YQL을 이용해 가져오는 데이터는
그 특성상 실시간 업데이트될 확률이 적습니다.
따라서 자체적으로 데이터를 일정 부분 캐싱하는 알고리즘을
이용하면 도움이 됩니다.

참고로 야후 본사쪽에서는 외부 파트너의 컨텐츠를
YQL로 가져와서 캐싱을 한 후에 실제 서비스에 이용하고 있습니다.

따라서 실시간 데이터 업데이트가 아닌
데이터의 수집/가공 영역에서 YQL을 사용해 보시기를 권해 드립니다.

오.. 그렇다면 저의 바람되로 귀찮은 일이 줄어드는 것이네요
물런 fallbacks를 마련해야겠죠?

효율과 한계는?
자 여기서 원래 할려고 했던 질문을 다시 정진호님께 해야 할 것 같네요.

1. 직접 Crawler나 API랑 통신하는 코드를 짜는데 시간을 들이고 안정적으로 Data를 Collect하는것 Vs YQL을 이용해서 빠르게 Collector를 만들지만, 속도와 안정성 측면에서는 모험을 해야 하는것
이 둘을 비교했을때 어떤것이 더 효율이 있을까요? (혹은 어느 수준까지는 YQL이 좋다)

2. YQL의 안정성이나 속도에 대한 통계수치가 나와 있는지 궁금합니다.

3. Query가 날라갔을때 그때 직접 Data를 Collect해오는것인지? 아니면 Cached Data를 가져오는 것인지도 궁금하구요

자.. 한줄요약

YUI 3는 쓸만해졌고, YQL은 재미있는 물건이지만 이걸가지고 뭔가 하기엔 무리가 있다. 재미있는 물건으로 잘만 활용한다면 기획자와 개발자에게 엄청 큰 도움(?)을 줄 것이지만, 안정성과 속도에서는 검증이 되었는지 잘 모르겠다.(이 부분은 정진호님께서 답변을 해주세요~ ㅎㅎ)

jQuery 간단한 소개 및 prototype, yui와 간단 비교

우선 jQuery에 대해 간단히 설명을 하자면,
prototype.js같은 javascript framework(혹은 library)종류중 하나인데, XPath 라는 것을 지원한다.
사실 jQuery하면 대표되는것이 XPath인데, 간단하게 설명하면..

$(“/html/body//p”)

이런거다 ㅎㅎ.

jQuery는 yui처럼 화려한 기능과, Demo를 제공하지 않는다. 이건 단점일 수 도 있겠지만 장점일 수 도 있다.
이를 다른말로 하면 가볍다라는 말로도 표현 할 수 있기 때문이다.
물런, yui도 원하는 js만 빼서 쓰면 되지만, 너무 많은 js 들이 있고, 어떤게 어떤걸 사용하고 호출하고..@_@; 완전 다단계다 ㅠ,.ㅠ
(물런 필자가 yui를 많이 안써봐서 그렇게 느끼는 걸 수 도 있다)

jQuery의 가벼움은 prototype.js 보다도 가볍다.
정말 딱 뼈다귀만 구현해놓은 Library라고 할 수 있다.
prototype.js처럼 class틱하게 코딩도 가능하다.

필자는 처음에

그럼 yui처럼 구현할려면 삽질해야 겠네..

라고 걱정했다. 하지만 이 걱정은 곧 접어야 했다. 왜냐면 수많은 Plugin들이 존재하고 자신이 필요로 하는 Plugin만 다운받아 적용하면 되기 때문이다.

jQuery의 Plugin이 많은 이유를 추측해보자면..
간단하고 직관적인 구성때문에, jQuery는 쉽게 사용할 수 있다.
그렇다 보니..당연히 많은 사람들이 사용하게 될 것 이고..
그럼 결국 필요에 의해 여러 종류의 Plugin들이 나오게 된것이 아닐까..?

그리고 기본적으로 jQuery 는 Compression 되어서 나오기 때문에, 더욱더 용량이 줄어든다.

prototype.js : 66,529 byte
jQuery.js : 20,975 byte

용량 jQuery의 압승~
하지만 prototype.js 은 Compression 을 안했기 때문에 불공정한 시합이었다.
그래서 prototype.js도 Compression 하고 난 후 용량을 비교해 보았다.
결과는 역시나 jQuery의 승리였다.

prototype.js : 27634 byte
jQuery.js : 20975 byte

jQuery의 단점은 수많은 Plugin들 중에 자신이 원하는것을 찾는다는게 쉽지 않다는 것정도..?
검색해보고 쓸만한거 직접 써보고, 아니면 다시 찾아보는 검증(?)작업, 일명 삽질을 해야 한다.
하지만 이것도 유익한 삽질이다.
이런식으로 여러 Plugin들에 대해 알아놓으면, 훗날 Plugin을 찾을때 좀 더 쉽게 찾을 수 있지 않은가?

총 정리를 하자면.

  1. prototype.js 의 가벼움 보다 더욱 가볍다.
  2. yui는 그 자체에서 골라내서 사용할 수 있고, jQuery는 뼈대만 가지고 살(Plugin)은 알아서 붙이는 형태.
  3. XPath 라는 Selector가 재밌다.
  4. 거기다 수많은 Plugin이 존재한다.
  5. 물런 원하는 Plugin을 찾기 위해선 노가다를 좀 해야 한다.