Search Results for '개방'


5 POSTS

  1. 2008/03/11 [차세대웹기술수업-강의03-05] Advanced Issues About Open&Sharing - Data Portability by 한재선 (2)
  2. 2008/03/11 [차세대웹기술수업-강의03-04] Advanced Issues About Open&Sharing - Microformats by 한재선
  3. 2008/03/05 [차세대웹기술수업-강의03-03] Advanced Issues About Open&Sharing - Open Social by 한재선
  4. 2008/03/05 [차세대웹기술수업-강의03-02] Advanced Issues About Open&Sharing - OpenID by 한재선 (18)
  5. 2008/03/05 [차세대웹기술수업-강의03-01] All About Open & Sharing by 한재선

[차세대웹기술수업-강의03-05] Advanced Issues About Open&Sharing - Data Portability

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

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

5.4 Data Portability

사용자 삽입 이미지

[S17] Data Portability는 사용자 입장에선 너무나 당연하고 있었으면 하는, 사용자 데이터에 대한 이동성 요구를 만족시켜 주자는 노력입니다. 아마 이 수업을 듣거나 블로그를 보시는 분 중에 싸이월드 미니홈피가 없으신 분 없을 겁니다. 하지만 그 미니홈피 중에는 폐업 중인 곳도 있을 겁니다. 미니홈피를 접고 블로그로 옮겨가고 싶다고 할 때 몇 년동안 미니홈피에 올렸던 사진과 글, 일촌 리스트, 방명록 등을 블로그로 옮길 수 있는 방법이 있을까요? NEVER!!! 절대 없습니다. 사업자 입장에서 보면 당연한거죠. 옮겨갈 수 있게 하면 사용자들의 이탈을 어떻게 막겠습니까? 하지만 웹 2.0의 등장과 함께 동종의 서비스만 하더라도 여러 종류가 나와 서로 경쟁하고 있습니다. 미국의 경우 SNS로 MySpace, Facebook, hi5, Orkut, LinkedIn, Ning 등 매우 많습니다. 그리고 많은 사람들이 두개 이상의 SNS에 가입되어 있죠. 여기서 문제가 생기는겁니다. 다른 SNS끼리 친구목록을 공유할 수도 없고 다른 SNS로 바꿀 때 친구목록을 가져갈 수도 없습니다.

이런 문제를 해결하고자 업계의 전문가들이 모여서 Data Portability를 해결하려는 논의를 시작했습니다. Data Portability의 중요한 철학은 이를 위해 새롭게 기술을 만들지 말고 기존 기술을 사용하자는 것입니다. 이 기술엔 앞서 설명드린 OpenID, Microformats, RSS를 비롯해서 APML, OPML, oAuth, RDF 등이 사용됩니다. 하지만 완전한 스펙이 나오기까지는 아직 시간이 걸릴 것 같습니다. Google, Facebook, Plaxo, LinkedIn, Flickr, Twitter 등이 참여하고 있다.

사용자 입장에선 매우 좋은 시도이지만 몇 가지 비판의 목소리가 나오고 있습니다. Korean Identity Management(KIM)님이 정리하신 비관적인 평가는 다음과 같습니다.
  - 데이터 이동성을 제공하기 위해서는 합의해야 할 항목들이 많은데 쉽게 해결할 수 있는 사안이 아님
  - 업체에서는 적극적인 의지를 보이지 않고 있음
  - Facebook의 참여는 마케팅 전략이라는 분석

 저도 동의하는 바입니다. 사실 Data Portability는 사용자가 먼저 요구할 사항이지 서비스 제공자가 자발적으로 추진할 기능은 아니죠. (적어도 현재의 서비스 관행에선) 그런데 여기에 Google, Facebook 등의 메이저 업체가 참여한다는게 이해가 가지 않는 점 아닙니까? 그래서 일종의 제스춰라고 의심도 들 수 있는겁니다. 또한 참가자들도 밝혔듯이 회사를 대표하는 것이 아니라 개인적인 관심에서 참여라고 했습니다. 따라서 회사 차원에서 실질적인 액션이 나오기까지는 넘어야 할 산이 많을겁니다.

제가 보기에 메이저 업체에서 Data Portability를 주도적으로 끌고갈 동기가 부족합니다. 새롭게 중소규모의 서비스 업체의 사용자를 끌어올 수 있는 가능성은 있으나 원래 자신의 사용자를 뺏길 위험이 더 큽니다. 따라서 Data Portability는 중소규모 업체들이 메이저 업체와 경쟁하기 위한 전략으로 함께 뭉치고 주도적으로 이끌어갈 때 더 의미가 있을거라 생각합니다. Data Portability에 대한 니즈는 사용자보다 중소규모 서비스 업체가 더 클 수 있죠. 그리고 Data Portability가 꼭 업체들의 협의하에서 표준을 정해야 해결된다고 보진 않습니다. 업체들은 기존 방식대로 변경없이 서비스하고 그들간 데이터의 호환성을 해결해 주는 새로운 서비스가 나타날 수도 있겠죠. 방법은? 글쎄요, 고민해 봐야죠~ ^^

Data Portability에 대해선 Korean Identity Management(KIM) 블로그의 "DataPortability.org] 내 소셜 네트워크 정보를 마음대로 사용할 수 있게 된다."
사용자 삽입 이미지
완전 강추합니다. (그 포스트 덕분에 Data Portability에 대해 자세히 적고 싶은 의지가 꺾였습니다. ㅠㅠ)

자, 이로써 세번째 수업 "All About Open & Sharing"을 마치도록 하겠습니다. 수고하셨습니다~

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

Posted by 한재선

Tag
dataportability, kaist, ksim, 개방, 차세대웹수업, 한재선
Response
No Trackback , 2 Comments

[차세대웹기술수업-강의03-04] Advanced Issues About Open&Sharing - Microformats

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

"차세대 웹기술과 컨버전스" 세번째 수업시간 "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
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

Tag
kaist, ksim, microformats, 개방, 공유, 차세대웹수업, 한재선
Response
No Trackback , No Comment

[차세대웹기술수업-강의03-03] Advanced Issues About Open&Sharing - Open Social

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

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

5.2 Open Social

사용자 삽입 이미지

[S15] 얼마전 Google이 Open Social을 발표하면서 인터넷 업계가 한번 들썩거렸었지요. Open Social이 등장하게 된 배경에 대해 설명하기 위해선 Social Network Service(SNS)의 최근 상황에 대해 간단히 살펴 볼 필요가 있습니다. 요즘 SNS는 단순히 네트워크만 맺어주는 것이 아니라 서비스 내에서 다양한 어플리케이션(위젯)을 사용할 수 있는 소셜 플랫폼으로 진화하고 있습니다. 가장 주목받고 있는 SNS인 Facebook은 2007년 5월 어플리케이션 개발을 할 수 있는 플랫폼을 런칭하였고 그 이후 2008년 1월까지 1만 4천여개의 어플리케이션이 개발되었습니다. 엄청난 속도 아닙니까! 이것이 가능한 것은 Facebook에 등록된 5000만명 이상의 사용자 때문이죠. 또한 그러한 사용자들을 기반으로 소셜 광고를 런칭함으로써 Google에게 확실한 위협을 하기 시작한 셈이죠.

Google이 가지고 있는 SNS라고 해 봐야 Orkut 정도인데 이것 가지고는 게임이 안되는건 자명한 사실입니다. 그럼 어떻게 해야 할까요? SNS에서 Google은 일인자가 아니기 때문에 Google이 취한 전략은 다른 SNS 서비스들과 연합하는 것입니다. 그래서 제안한 것이 Open Social입니다. 이것은 여러 SNS에서 어플리케이션을 개발하기 위한 공통 API를 제공함으로써 한번 개발된 어플리케이션을 Open Social을 채택한 SNS에서 공통으로 사용하게 하자는 것입니다. "Many Sites, One API" 혹은 "Write Once, Distribute Broadly"라는 구호를 외치는거죠. 이 외침에 MySpace, Friendster, hi5, Ning, Bebo, Orkut 등 많은 SNS들이 Open Social을 지원하고 나섰습니다. 당연히 Facebook은 관심이 없구요. ^^

그럼 좀 더 기술적으로 자세히 들어가 볼까요? OpenSocial API는 기본적으로 Google Gadget 기술을 기반으로 하고 있습니다. 이것은 Google 개인화 페이지인 iGoogle에서 실행되는 어플리케이션(Gadget)을 만들기 위한 기술 스펙입니다. 즉, OpenSocial API를 이용해 어플리케이션을 만든다는 것은 Social 기능이 들어간 Google Gadget을 만든다는 것입니다. Social 기능은 Javascript API를 통해서 제공됩니다. 이렇게 제공되는 Social 기능엔 다음과 같은 것들이 있습니다.
  - People: 사용자 정보와 관계 정보
  - Activities: 사용자들의 활동에 대한 업데이트를 보거나 포스팅하는 기능
  - Persistence: 오프라인에서 동작하게 하기 위한 key-value 형태의 간단한 데이터 저장소
하지만 Javascript가 지원되지 않는 모바일 단말에선 어떻게 이용할까요?  걱정 안하셔도 됩니다. 이를 위해 RESTful Data API에 대한 스펙을 제공하고 있습니다. 이를 이용하면 URL 요청하듯이 필요한 기능을 실행시킬 수 있습니다. 결국 Open Social에서 정의하고 있는 것은 Google Gadget 기술 기반의 social application framework과 SNS를 access할 수 있는 Javascript API와 RESTful Data API입니다. API들은 Open Social을 지원하는 SNS 들에서 직접 구현하겠지요.

기술적인 관점에서 봤을 때 Google Gadget 기술 기반을 이용한다는 것은 기존 기술을 사용하기 때문에 새로이 개발할 필요가 없고 Google Gadget Editor 같은 도구를 사용할 수 있다는 장점이 있는 반면에 Google 기술에 더욱 종속될 가능성을 안고 있습니다. SNS가 향후 플랫폼 서비스 형태로 진화해 가는데 있어서 그 컴포넌트 어플리케이션을 개발할 때 대부분이 Google Gadget 기술로 개발하게 되는 것입니다. 그것이 Google이 바라는 목표일지도 모르죠. 또한 Google이 제안한 Gadget 프레임워크 기반이므로 원한다면 Google의 AdSense 같은 광고를 심기도 편하겠죠? 뭐, 대충 정해진
사용자 삽입 이미지
수순 아닐까 하는 생각이 듭니다. 결국 Social Ad를 Facebook과 Google이 양분하겠다는... 제 생각입니다. ^^ (태클 환영입니다.)

Open Social에 대한 비판의 소리가 나오고 있다는 Channy님 글 추천합니다~
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

Tag
kaist, ksim, open social, opensocial, 개방, 차세대웹수업
Response
No Trackback , No Comment

[차세대웹기술수업-강의03-02] Advanced Issues About Open&Sharing - OpenID

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

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

5. Advanced Issues
지금부터 개방과 공유에 관한 최근 이슈들에 대해 살펴 보겠습니다.

5.1 OpenID

사용자 삽입 이미지

[S14] OpenID는 분산화된 Single Sign-On 서비스입니다. 우선 SIngle Sign-On에 대해서는 다들 한번쯤 들어보셨을겁니다. ID 하나로 모든 서비스에 로그인 가능하게 하는 것이죠. 매우 오래된 주제이면서 아직도 딱히 해결책이 없는 주제이기도 하지요. OpenID도 Single Sign-On을 하자는 것인데 예전에 제안되었던 방법들과의 큰 차이점은 분산화입니다. MS Passport와 같은 이전 방법들은 ID 인증과 관리를 독점하는 방식이라 이를 지원하려는 업체가 늘지 않았습니다. 하지만 OpenID는 공개 표준 스펙에 의해 누구나 구현하여 서비스 할 수 있는 구조라서 이를 지원하는 사이트가 속속 늘어나고 있습니다.

간단하게 사용방법을 설명드리자면 사용자는 선호하는 Identity Provider(IDP)에게서 OpenID를 발급받습니다. 우리나라에는 myid.net, IDtail, 다음 오픈ID가 IDP 서비스를 제공합니다. 발급받은 ID는 URL 형태로, 예를 들어 myid.net에서 발급받았다면 xxx.myid.net과 같은 형태의 ID를 받게됩니다. 자, 그럼 이 ID를 가지고 OpenID로 로그인이 되는 사이트를 방문하여 직접 로그인을 하면 됩니다. 이 때 인증은 그 사이트에서 일어나는 것이 아니라 자신이 ID를 발급받은 IDP에서 일어나게 됩니다. 즉, IDP의 인증화면이 뜨고 지금 방문하려는 사이트를 승인할 것인지 여부를 결정합니다. 이로써 사이트에 OpenID로 로그인이 이루어집니다. 현재 OpenID 적용 사이트 리스트입니다.

기술 스펙이 공개되어 있기 때문에 누구나 IDP 서비스를 제공할 수 있고 사용자 역시 어떤 IDP도 선택할 수 있습니다. 즉, OpenID는 독점적인 기술이나 서비스가 아니라는 것이죠. 이같은 분산구조 때문에 OpenID가 성공할 가능성이 큰 것입니다. DNS가 분산구조를 채택하여 인터넷 네이밍 인프라스트럭쳐로서 성공하였던 것처럼 말이죠. 하지만 OpenID도 단점들이 있습니다. 우선 사용자 입장에서 익숙한 인증 체계가 아닙니다. 따라서 처음 사용하는 사용자들은 몇 번 시도하다 포기하는 경우도 있습니다. 또한 피싱 공격에 취약합니다. 악의적인 서비스가 OpenID 로그인시 지정된 IDP로 요청을 보내지 않고 가짜 IDP 인증 화면을 보여주어 사용자의 ID 정보를 알아낼 수 있습니다. 이러한 취약점은 조만간 해결되리라 기대합니다.

자, 그럼 OpenID 서비스 제공자, 즉 IDP 제공자는 왜 IDP 서비스를 제공할까요? 자신이 직접 하지 않더라도 이미 IDP들이 존재하는데 말이죠. 공익을 위해서? 설마... 기업이 수익과 상관없이 그렇게 할까요? 다른 관점에서 질문하자면 "ID를 가지고 있으면 무슨 장점이 있을까요?"쯤 되겠죠. 한번쯤 생각해 보시기 바랍니다. ^^
사용자 삽입 이미지


OpenID와 ID 체계에 대한 전반에 대해 Korea Identity Management(KIM) 블로그를 추천합니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

Tag
kaist, ksim, openid, 개방, 차세대웹수업
Response
No Trackback , 18 Comments

[차세대웹기술수업-강의03-01] All About Open & Sharing

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

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



제 수업이 저녁 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/, 원본 링크가 깨져있어 첨부합니다)
RESTfulSOAP.ppt



이외에 요즘 또 각광받고 있는 기술이 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 서비스들이 주를 이룰지는 지켜봐야 할 포인트 같습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

Tag
kaist, ksim, mashup, openapi, rss, 개방, 공유, 오픈api, 차세대웹수업
Response
No Trackback , No Comment
« Previous : 1 : Next »