Web2Hub

(원본포스트링크: 댓글과 트랙백은 여기로 부탁드립니다.)

"차세대 웹기술과 컨버전스" 세번째 수업시간 "All About Open&Sharing" Part 4입니다. (강의자료는 Part1에서 다운)

5.3 Microformats

[S16] Microformats은 웹페이지에 semantic을 심자는 것입니다. 그것도 간단하게 XHTML class와 attribute만 써서 말이죠. 자, 그럼 웹페이지에 semantic을 심는자는게 무슨 뜻일까요? 예를 들어 설명드리죠. (위키피디아에 있는 예입니다.) 만약 웹페이지에 contact 정보를 넣는다고 할 때 HTML은 아래와 같이 딱히 정해진 포멧이 없습니다.  

<div> 
   <div>Joe Doe</div> 
   <div>The Example Company</div> 
   <div>604-555-1234</div> 
   <a href="http://example.com/">http://example.com/</a> 
</div>

이 웹페이지를 검색 크롤러가 분석한다면 이 부분이 contact 정보라는 것을 알기 어렵습니다. 즉, 데이터의 의미(semantic)을 모른다는거죠. 그래서 이것을 알려주기 위해 contact 정보의 경우 class 이름으로 "vcard"를 사용합니다. 그리고 contact 정보의 각 속성에 대해 fn(full name), org, tel, url 등의 class를 사용하여 속성이 무엇을 의미하는지 알려줍니다. 그러면 아래와 같은 HTML이 나옵니다.

<div class="vcard"> 
   <div class="fn">Joe Doe</div> 
   <div class="org">The Example Company</div> 
   <div class="tel">604-555-1234</div> 
   <a class="url" href="http://example.com/">http://example.com/</a> 
</div>

class 이름을 왜 저렇게 지었을까요? 아~~~무 이유 없습니다. 단지 약속입니다. ^^

이렇게 정해 놓은 Microformats엔 다음과 같은 것들이 있습니다.

  - hCard: contact 정보
  - hCalendar: 이벤트 및 스케쥴 정보
  - rel-license: 라이센스 정보
  - rel-nofollow: 블로그에서 스팸을 막기 위한 정보 (검색 Ranking에서 제외)
  - rel-tag: 현재 페이지의 태그 정보
  - XFN (XHTML Friends Network): social relationships
  - hReview: 리뷰
  - hResume: 이력서
  - adr: 주소 정보
  - geo: 좌표 (위도,경도)

자세한 내용과 모든 Microformats의 리스트는 Microformats 위키와 위키피디아를 참고하기 바랍니다.

웹에 semantic을 표현하고자 한 시도로 Microformats 이전에 이미 Semantic Web이 있었습니다. 웹의 아버지인 팀버너스리경에 의해 제안된 것이죠. 하지만 처음 의도와는 다르게 점점 더 복잡해지기 시작했죠. Ontology, RDF, RDF Schema, OWL, SPARQL 등 많은 기술적인 내용들이 있어 웹 컨텐츠 제작자 입장에선 접근하기 쉽지 않습니다. Microformats은 그 복잡함의 단점을 극복하고자 제안된 것입니다. Semantic Web 처럼 완벽하진 않더라도 당장 필요한 "의미"들을 간단하게 표현할 수 있는 "약속"을 정한 것이죠. 이것이 웹 2.0의 접근법이죠. Semantic Web과 웹 2.0이 지향하는바가 서로 비슷하지만 접근방법에서 차이가 납니다. Semantic Web이 Top-Down 방식이라면 Microformats은 Bottom-Up 방식이죠. 그리고 Semantic Web이 이론적 접근이라면 Microformats은 실용적 접근입니다. 하지만 웹 2.0의 등장과 함께 Semantic Web도 웹 2.0적인 접근법을 배우려 노력하며 좀 더 실용적으로 나가고 있습니다. 앞으로 Semantic Web과 웹 2.0이 어떻게 만날지를 주의깊게 고민해 볼 필요가 있습니다. (어떤 분들은 웹페이지에 semantic이 들어가는걸 웹 3.0 이라고 합니다. 그래서 Semantic Web이 웹 3.0이라고 주장하죠.)

자, 그럼 Microformats은 왜 웹에 의미를 심으려 하는걸까요? 그것은 데이터에 의미가 추가됨으로써 다른 복잡한 처리(screen scraping, natural language processing(NLP))없이 데이터를 인덱싱, 검색, 참조 등이 가능해져 정보의 재사용과 믹싱의 장점을 얻을 수 있기 때문입니다. Google Maps, Flickr Photo, Yahoo! Upcoming Events 등이 이미 Microformats을 사용하고 있습니다. 또한 Firefox version 3와 IE version 8에선 Microformats에 대한 지원이 기본 탑재된다 합니다. Microformats은 Mashup도 용이하게 해 줍니다. 예를들어 geo Microformats가 표시된 웹페이지들은 바로 Google Maps와 Mashup 할 수 있겠죠? 또한 hCalendar Microformat + Google Calendar 이런 조합도 가능하겠죠? 더 많은 가능성에 대해선 Gerald Bauer의 What is the Semantic Web? What's Web 3.0? What are Microformats? 발표를 참고하세요.

하지만 Microformats은 일종의 권고사항일 뿐이기 때문에 컨텐츠 생산자에게 분명한 이점을 제시해 주지 않는 이상 파급되는데 시간이 걸릴 것 같습니다. 그나마 희망을 가질 수 있는건 요즘 이슈가 되고 있는 Data Portability에서 기본 기술로 Microformats을 사용한다는 것이죠. 다음 포스트에서 Data Portability에 대해 알아보겠습니다.

Microformats에 대한 철학이나 자세한 내용을 알고 싶으신 분들은

CommerceNet의 2006년 Technical Report을 참고해 보세요. Microformats을 처음 제안한 사람들이 적은 겁니다.
Microformats: A Pragmatic Path to the Semantic Web

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

(원본포스트링크: 댓글과 트랙백은 여기로 부탁드립니다.)

반갑습니다, "차세대 웹기술과 컨버전스" 세번째 수업시간입니다. 이번 시간의 주제는 "참여"와 함께 웹 2.0의 다른 축인 "개방"과 "공유"에 대해 말씀드리겠습니다. 강의자료는 아래에서 다운받으세요.



제 수업이 저녁 6시부터 시작이라 저녁을 못 드시고 오시는 학생분들이 있습니다. 제가 수업마치고 대전내려오는 기차시간 때문에 어쩔 수 없이 그 시간으로 한건데 죄송스럽네요. 그래서 수업시간에 피자시켜서 먹었습니다. /^^/ 피자를 시켜주신 문대표님께 감사감사~


1. 개방과 공유: Overview


[S2] 개방과 공유에 대해 크게 두 부분으로 말씀드리겠습니다. 개방에 대한 기본적인 구조로 데이터 개방을 위한 기술과 서비스 개방을 위한 기술, 그리고 이를 통해 새롭게 창조해 낼 수 있는 Mashup 서비스들이 한 부분이 됩니다. (일반적인 웹 2.0의 개방과 공유에 대한 이슈들입니다.) 그리고 다음으로 최근 개방과 공유에 대한 이슈들, 즉 OpenID, Open Social, Microformats, Data Portability, CCL 등에 대해 논의해 보겠습니다.

2. Open Data


[S3] RSS가 데이터 개방을 위한 대표 기술이라해도 과언이 아닙니다. RSS는 최신 업데이트된 컨텐츠를 발행(publish)하기 위한 표준적인 데이터 포멧입니다. 여러 분들이 블로그나 뉴스 싸이트를 방문하시면 아래에 조그만 RSS 버튼을 보실 수 있습니다. 이것이 RSS 발행 주소가 되고 이것을 복사하여 즐겨 사용하는 RSS 리더에 등록하면 그 웹싸이트를 가지 않고도 새로 업데이트된 내용을 받아볼 수 있습니다. 말하자면 신문구독과 같은 역할을 하는 것입니다. RSS 리더는 등록된 RSS 주소들을 주기적으로 방문하여 최신 업데이트 내용을 가져와 사용자에게 제공합니다. 최근 인터넷 익스플로러 7에 RSS 리더 기능이 내장되면서 PC 설치형 RSS 리더는 힘을 잃어가고 있는 실정입니다. RSS를 통해 텍스트 컨텐츠만 전달할 수 있는 것은 아닙니다. 오디오, 비디오 등의 멀티미디어 데이터도 구독할 수 있습니다. Podcasting은 RSS를 통해 오디오 컨텐츠를 구독하고 자동으로 다운로드해 주는 것을 말합니다.

[S4] RSS는 웹에서 구독이라는 새로운 형태의 컨텐츠 전송방식을 제공했다는 점에서 그 의미가 크지만 다른 한편으로 웹 데이터 포멧을 표준화했다는 측면에서 웹에 많은 변화를 가져 왔습니다. 기존에는 웹에서 뉴스나 블로그포스트 등을 표현하는 통일된 포멧이 없었습니다. 따라서 그러한 데이터를 가져와서 사용하기가 쉽지 않았었죠. 하지만 RSS가 뉴스나 블로그 포스트를 동일한 포멧으로 표현할 수 있게 함으로써 데이터의 공유가 용이해 졌습니다. 공유된 데이터는 메타블로그나 검색 등 여러 채널을 통해 소비가 이루어지고 재가공이 되어 컨텐츠의 활용도를 높였습니다.

[S5] 이러한 RSS의 장점을 활용한 웹 서비스들은 여러 가지가 있는데 여기서는 대표적으로 세 가지 종류의 서비스들에 대해 간단히 살펴보겠습니다. 우선 RSS 리더가 있습니다. RSS 등장 초기에는 RSS 리더가 큰 주목을 받았으나 지금은 웹 RSS 리더가 명맥을 유지하고 있면서 메타블로그로 진화하고 있는 상황입니다. 메타블로그는 등록된 RSS들을 모아서 보여주는 블로그의 포털 역할을 합니다. 올블로그가 대표적인 예이지요. 하지만 지금은 RSS 리더와 메타블로그의 경계가 애매해지고 있는 상황이죠. (떡이떡이님의 블로그 포스트 참고) 또 다른 RSS 비즈니스로 Feedburner와 같은 RSS 피드 통계 관리 서비스입니다. 여기에 RSS 피드에 광고를 삽입하는 RSS 광고 서비스도 시도하고 있습니다. RSS가 새로운 광고채널로 인식되기 시작하면서 얼마전 Google이 이 회사를 인수했죠.

보통 RSS라고 하면 뉴스나 블로그포스트에 대해서만 생각하기 쉬운데 RSS는 업데이트가 일어나는 컨텐츠면 어떤 종류든 실을 수 있습니다. 예를 들어 버그 리포핑이나 위키페이지의 RecentChanges, 관심 쇼핑 아이템 정보, 관심 BitTorrents 정보 등도 모두 RSS로 발행하고 있는 대상이죠. 또 하나 재미있는 RSS 컨텐츠를 소개해 드리자면 오늘의 운세서비스 입니다. 자신의 생년월일 정보를 입력하면 매일 그날의 운세를 RSS로 보내주죠. 기발하지 않습니까? ^^

3. Open Services


[S6] 서비스 개방은 Open API를 통해 이루어집니다. 웹 서비스가 제공하는 다양한 기능을 공개된 API 형태로 제공하는 것입니다. 따라서 다른 서비스나 어플리케이션에서 Open API를 통하여 공개된 서비스를 이용할 수 있는 것이죠. 이렇게 공개된 Open API는 개인 개발자, 다른 웹 서비스, 혹은 개인 유저에 의해 사용되어(프로그래밍) 새로운 서비스를 만들어 내는 재료가 됩니다. 몇 가지의 Open API가 함께 사용하여 새로운 서비스를 만드는 경우를 Mashup이라고 하죠. 지금까지 윈도우나 리눅스 위에서 OS가 제공하는 API를 사용해 프로그래밍했다면 이제는 구글, 네이버, 아마존 위에서 그들이 제공하는 Open API를 이용해 프로그래밍하는 시대인겁니다.

[S7] 자, 그럼 Open API에는 어떤 종류들이 있을까요? ProgrammableWeb을 보면 현재 등록된 API가 659개(3월2일)입니다. 그리고 이 중에서 가장 많이 쓰이고 있는 API로는 Google Maps, Flickr, YouTube, Amazon 등이 있습니다. 그들이 정리해 놓은 API 카테고리를 보면 Mapping, Photos, Video, Shopping, Music, Community, Email, Advertising 등 모든 영역에 걸쳐 개방되어 있는 것을 볼 수 있습니다. 즉, 웹에서 제공할 수 있는 모든 서비스가 개방의 대상이 된다는거죠.

[S8] 이제 Open API를 가능케하는 기술에 대해 간단히 살펴 보겠습니다. Open API라는 용어가 나오기 전부터 기업시장에선 SOA(Service-Oriented Architecture)라는 기업 서비스 통합을 위한 기술이 주목받고 있었습니다. SOA에서 서비스들간 메세지 전송 프로토콜로 SOAP(Simple Object Access Protocol)이 사용됩니다. Open API도 처음엔 SOAP를 사용하는 것으로 출발점을 삼았습니다. 하지만 SOAP는 기능이 풍부한 대신 좀 복잡한 측면이 있어 좀 더 쉬운 REST(Representational State Transfer)가 인기를 끌고 있죠. REST는 새로운 기술이라기 보다 하나의 방법론입니다. SOAP와 REST의 차이에 대해 좀 더 자세히 알고 싶은 분은 아래 첨부해 놓은 PPT 자료를 살펴 보시기 바랍니다. (출처: http://www.razorsoft.net/, 원본 링크가 깨져있어 첨부합니다)



이외에 요즘 또 각광받고 있는 기술이 Javascript를 이용한 Open API입니다. 데이터와 서비스를 접근할 수 있는 자바스크립트 라이브러리를 제공하는 것입니다. 가장 대표적인 예가 Google Maps입니다. 이 방식은 강력한 기능을 제공할 수 있다는 장점이 있는 반면 다른 서비스들과의 통합이 쉽지 않다는 단점이 있습니다.

4. Mashup 서비스
[S9] 공개된 데이터와 서비스를 이용해 새로운 서비스를 만드는 것이 Mashup 입니다. Craigslist에서 부동산 정보를 가져와서 Google Maps위에 올린 HousingMaps.com이 최초의 Mashup 서비스입니다. 각기 다른 역할을 하는 두 서비스를 합쳐 새로운 가치를 끌어낸 것이죠. Chicago Crime Map이라는 서비스는 시카고 경찰서의 범죄 데이터를 Google Maps 위에 뿌려 줌으로써 구역별 범죄 현황에 대해 알기 쉬운 인터페이스를 제공했고 일반인들이 접근하기 쉬운 서비스를 만든 것입니다. 이것은 향후 다른 지역에도 비슷한 서비스가 나오게 한 계기가 되었습니다.

[S10] Open API의 종류가 제한이 없는 것처럼 Mashup 서비스 역시 다양한 종류가 시도되고 있습니다. 아직 제일 많이 만들어지고 있는 Mashup 종류는 Mapping Mashup입니다. 아마도 가장 쉽게 생각할 수 있기 때문인 듯합니다. Mashup 카테고리와 유명 Mashup들은 programmableweb에서 확인해 보시기 바랍니다. 한 가지 주목할 점은 Enterprise Mashup입니다. 기업 환경에서 Open API와 Mashup을 기업 서비스 통합의 방법으로 쓰려는 시도가 늘고 있습니다. 물론 아직 이런 툴들은 기업과 사용자 사이 연결점에서 주로 쓰이고 있는데 향후엔 기업 내에서 필요한 기능 및 서비스가 Mashup 방식으로 만들어질 가능성이 있습니다. 기업용 Mashup 툴들에 대해선 Dion Hinchcliffe의 ZDNet 포스트를 참고하시기 바랍니다. Enterprise Mashup이 중요한 이유는 Mashup의 수익모델의 한가지 방향을 제시한다는 점 때문입니다.

Mashup 서비스의 수익모델에 대해선 많은 비판들이 있습니다. 현재 쏟아져나오고 있는 많은 Mashup 서비스들이 수익과 직결되는 경우는 많지 않기 때문이죠. 대부분 기발한 아이디어를 가지고 재미삼아 만든 경우가 많습니다. 물론 이것 자체로도 의미가 크지만 Mashup과  Open API가 확산되기 위해선 API를 오픈하는 사업자에게, 그리고 Mashup 서비스를 만드는 개발자 입장에서 금전적인 장점이 있어야 합니다. 현재로선 Amazon이나 eBay 등의 온라인 쇼핑몰의 Open API를 이용해 Shopping Mashup을 만들고 Mashup 서비스를 통해 일어난 수익을 분배하는 Affiliate Program이 가장 현실적인 수익모델이라 할 수 있습니다. 그래서 Amazon과 eBay는 외부 개발자에 대한 지원과 관리가 훌륭합니다.

Mashup이 주로 개인 개발자나 소규모 벤쳐에 의해 개발되는 경우가 많기 때문에 수익 모델도 이런 케이스에 촛점을 맞추는데 오히려 Open API 제공자 입장에선 다른 방향에서 실질적인 수익이 날 가능성도 많습니다. 예를 들어 Open API를 한 다른 사업자와 제휴를 통해 이익을 얻는 것입니다. 지난 해 말 다음과 옥션이 Open API를 활용하여 다음 카페 게시판 내에서 옥션 물품등록이 가능하도록 한 제휴가 그 대표적인 예가 됩니다. (ZDNet 기사 참고) 이로써 옥션은 마켓플레이스의 확장이라는 이득을 얻고 다음은 옥션 사용자가 카페로 유입되는 효과를 얻게 됩니다. 이 경우처럼 Open API가 성숙해 지는 단계에선 다른 서비스들과의 제휴를 통해 실질적인 이득을 보는 경우가 늘어날 것으로 예상합니다.

[S11] 그렇다면 Mashup을 위한 구조와 기술은 어떤 것이 될까요? 이것은 이미 앞에서 데이터 개방과 서비스 개방을 위한 기술을 설명하면서 언급한 것입니다. 여기에 하나 더 추가된다면 Screen Scraping 역시 아직 많이 사용되고 있는 기술입니다. 왜나면 아직 많은 웹 서비스들은 RSS나 Open API를 통해 개방이 되어 있지 않기 때문에 직접 페이지를 가져와 필요한 정보를 끌어내는 Screen Scraping 기술이 필요한 것입니다. Mashup을 위한 기술적인 내용에 대해선 IBM Developerworks의 문서 (원문)를 참고하시기 바랍니다.

[S12] 수익모델 이외에 Mashup 서비스가 확산되기 어려운 또 한가지 이유가 있습니다. 바로 "프로그래밍"입니다. Mashup 서비스가 이미 존재하는 기능과 데이터를 조합하여 만들어진다 하더라도 Open API를 사용하는 것과 조합하는 프로그래밍이 필요합니다. 따라서 일반인이 시도하기는 불가능하다고 볼 수 있죠. 이 단점을 극복하기 위해 Yahoo, MS, Google 등은 Mashup 에디터라는 서비스를 개발했습니다. 코딩이 필요없이 기능 블럭들을 조합함으로써 원하는 Mashup을 만들어 낼 수 있게 한 것이죠. 가장 먼저 등장한 Yahoo Pipe의 경우 데이터 소스를 지정할 수 있는 다양한 Sources 블럭을 제공하고 소팅이나 대치 등과 같은 데이터 처리를 위한 다양한 Operations 블럭을 제공합니다. 사용자는 필요한 블럭을 가져와서 서로 연결을 해 주면 새로운 서비스가 탄생합니다. Mashup 확산을 위해 등장한 Mashup 에디터는 서비스들이 플랫폼화 되어가고 있음을 보여주는 한가지 예입니다. 즉, Mashup Editing, Hosting, Sharing 등의 전 Process가 서비스화되어 몇몇 글로벌 회사에 의해 제공되는 것이죠. 앞으로 Mashup이 이런 중앙집중된 방향으로 발전할 것인지 아니면 다양한 소규모 개발자 그룹들에 의한 독립적인 Mashup 서비스들이 주를 이룰지는 지켜봐야 할 포인트 같습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선