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

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


사용자 삽입 이미지

이번 강의는 Facebook을 많이 들여다 볼 겁니다. 아직 가입하지 않으신 분은 또 계정하나 늘인다셈치고 가입해 보시기 바랍니다. 처음 가입하면 친구리스트가 텅~ 비었겠죠? 그럼 제게 친구신청하세요~ ^^
http://www.facebook.com/profile.php?id=681944947

3. Facebook: Social Platform
[S24]
오늘 강의의 하이라이트라고 할 수 있죠. 소셜 플랫폼의 선두주자, Facebook입니다. 요 근래 Facebook의 고공행진과 더불어 소셜 플랫폼의 중요성이 점점 부각되면서 Facebook이 플랫폼의 대표적인 예로 자주 거론되고 있습니다. 사실 세계에서 가장 큰 소셜 네트워크는 MySpace이지만 가장 빠르게 성장하는 것은 Facebook입니다. 200% 이상의 꾸준한 성장율을 보이고 있죠. Facebook은 2004년 2월에 Mark Zuckerberg라는 하버드 학생에 의해 시작되었습니다. 초기에는 하버드 학생들만의 위한 네트워크였는데 점점 다른 대학으로, 고등학교로, 결국 13살 이상의 모든 사람들의 네트워크로 확대되었습니다. 작년에 MS가 Facebook의 주식 1.6%를 2.4억달러에 인수하면서 Facebook의 가치는 순식간에 150억달러라는 거액으로 뛰었지요.

사용자 삽입 이미지

[S25] 그럼 현재 Facebook의 상태를 보실까요? 위 슬라이드의 자료는 Facebook이 제공하는 현재 통계자료입니다.
http://www.facebook.com/press/info.php?statistics
가입자수는 6700만명을 넘어섰고 매일 평균 25만명이 새로 가입한다네요, 놀랍지 않습니까?
하지만 우리가 눈여겨봐야할 통계는 아래에 있는 플랫폼 관련 통계입니다. Facebook 플랫폼을 이용한 어플리케이션이 15,000개를 넘어섰고 매일 140개정도 새로 추가된다고 합니다.

사용자 삽입 이미지

[S26]
Facebook은 2007년 5월 Facebook 플랫폼을 론칭하였습니다. 즉, 외부 개발자나 써드파티 회사들이 Facebook의 방대한 소셜 네트워크 정보를 이용하여 직접 Facebook 어플리케이션을 개발하고 Facebook에 설치할 수 있도록 하는 모든 기능을 담고 있는 것이죠. Facebook이 말하는 플랫폼의 세 가지 특징1) 어플리케이션이 Facebook의 기능이나 UI를 그대로 사용하기 때문에 Facebook과 완벽히 통합될 수 있고 2) Facebook의 방대한 소셜 네트워크를 활용하여 어플리케이션의 mass distribution이 가능하며 3) 어플리케이션에서 수익모델을 가져갈 수 있는 기회를 제공한다는 것입니다.

이 중에서도 아마 두번째 특징이 어플리케이션 개발자에게 가장 매력적인 요소가 아닐까 싶습니다. 멋진 아이디어를 구현하여 새로운 웹 서비스를 만들더라도 초기 사용자를 끌어모으지 못해서 고전을 하는 경우가 많습니다. 이는 특히 한국과 같이 닫힌 웹, 웹 비즈니스에 건강한 생태계가 갖추어지지 않은 상태에서는 거의 불가능한 일이죠. 하지만 Facebook은 이미 6700만명이라는 사용자 베이스를 가지고 있기 때문에 좋은 어플리케이션을 만들기만 한다면 소셜 네트워크를 타고 빠르게 확산될 희망을 가질 수 있는겁니다. 이것이 소셜 플랫폼의 강점입니다. 또한 Facebook은 뉴스피드라고 해서 사용자들의 모든 액션을 그 사람의 소셜네트워크에 전파시키는 기능이 있어 어플리케이션이 입소문을 타고 확산될 수 있는 장치를 마련해 두었습니다. 이미 여러 어플리케이션에서 이런 효과를 맛보았지요. 또한 어플리케이션을 개발하고 추가하는 절차가 매우 간단하기 때문에 초기진입장벽이 아주 낮습니다. 그리고 많은 어플리케이션이 만들어질 수 있도록 Funding 프로그램과 무료 호스팅 서비스 등을 제공하고 있습니다. 이런 여러 매력적인 특징들로 인해 Facebook 어플리케이션이 급속히 증가하고 있는 것입니다.

하지만 Facebook 플랫폼이 어플리케이션 개발을 위해 제공하는 기술들은 완전히 Facebook에 의존적입니다. 즉, Facebook 어플리케이션을 다른 소셜 플랫폼에선 사용할 수 없는 것이죠. 물론 대부분의 소셜 플랫폼들이 동일한 방식의 접근을 하고 있습니다. 지난 시간에 설명드린 Open Social이 이런 문제를 해결하자고 Google이 제안한 것입니다. 소셜 어플리케이션 개발을 위한 표준 프레임워크를 정하자는 것이죠. Facebook을 제외한 대부분의 소셜 네트워크 서비스들이 참가하고 있습니다. 제가 보기엔 Facebook 플랫폼과 Open Social 중에 어느 쪽이 더 맞는 방향이냐는 논쟁은 의미가 없어 보입니다. 둘 다 자기 서비스들의 현재 상태에서 취할 수 있는 전략을 선택한 것이죠. 만약 Google의 Orkut이 1위를 달리고 있다면 Open Social이 나왔을까요? (나왔을 수도 있지만 다른 업체들에서 참여를 안했겠죠, 즉 "Open"은 의미없는게 되는거죠) Open Social이 많이 확산되어 의도된대로 개발자들에게 편의를 제공해 준다면 바람직한 일이겠지만 SNS들의 복잡한 역학관계 속에서 쉽게 예상할 수 있는문제는 아닌 것 같습니다.

사용자 삽입 이미지

[S27] Facebook 어플리케이션의 성공 사례로 iLike 소셜 음악 서비스를 보도록 하겠습니다. iLike는 Facebook 어플리케이션을 런칭 후 첫 두주만에 300만명이 가입하는 효과를 봤습니다. 이것은 ICQ, Hotmail, Skype 등 인기 어플리케이션의 성장률을 훨씬 뛰어 넘는 수준입니다. 현재는 1500만명의 Facebook 사용자들이 사용하고 있고 매일 30만명이 추가로 가입한다고 하니 그 성장세가 놀라울 따름입니다. 자, 어떤 플랫폼이 단기간에 이렇게 많은 사용자를 확보할 수 있게 해 줄 수 있나요? 이것이 바로 "소셜"의 힘입니다. 그리고 소셜 플랫폼이 주목받고 있는 이유이구요.

사용자 삽입 이미지

[S28]
그럼 이제부터 Facebook 플랫폼에 대해 뜯어보도록 하겠습니다. 우선 Facebook의 페이지들을 보면 깔끔하고 구조적으로 되어 있는 것을 알 수 있습니다. 어플리케이션을 추가하면 Left Nav 박스에 어플리케이션 이름이 추가됩니다. 그리고 어플리케이션을 위한 공간인 Canvas에 개발자가 만든 화면이 들어갑니다. 그리고 사용자의 Profile 페이지에도 어플리케이션을 위한 공간을 추가할 수 있는데 그것이 Profile Box입니다. 어플리케이션에서 최신 정보를 알릴 필요가 있을 때 News feed에 포스팅할 수 있습니다. 대략 어플리케이션 개발시 중요한 모듈에 대해 소개를 드렸습니다. 완전한 Facebook 페이지의 구조는 "Anatomy of a Facebook Application"에서 살펴 보시기 바랍니다.

[S29] Facebook이 동작하는 방식을 살펴 보기 전에 전형적인 웹 어플리케이션의 동작을 살펴 보면 웹 브라우저가 어플리케이션이 돌고 있는 웹 서버에게 요청하면 처리해서 결과 HTML을 돌려줍니다. 간단하죠?

사용자 삽입 이미지

[S30]
하지만 Facebook 어플리케이션이 동작하는 방식은 약간 복잡합니다. 기본적으로 어플리케이션은 개발자의 서버에 존재합니다. 즉, Facebook 외부에 있다는 것이죠. 그러면 Facebook은 어플리케이션의 존재를 어떻게 알까요? 이것은 어플리케이션 추가시 Callback URL에 해당 어플리케이션의 URL 주소를 입력함으로써 가능해집니다. 웹 브라우저는 Facebook에 요청을 하면 어플리케이션 화면을 만들어내기 위해 Facebook은 Callback URL로 요청을 보냅니다. 그러면 Callback URL의 프로그램 코드가 실행되고 결과 페이지를 만들어 Facebook에 돌려주고 최종적으로 Facebook 페이지와 결합하여 사용자에게 보내 줍니다. 여기서 어플리케이션 코드가 어떤 작업을 하여 무엇을 만들어 돌려 주는지가 중요합니다. 소셜 어플리케이션이므로 당연히 사용자 정보나 친구, 그룹, 이벤트 등에 대한 정보가 필요합니다. Facebook 플랫폼에서 제공하는 API와 FQL(Facebook Query Language)을 이용해 그런 정보를 가져 올 수 있습니다. 어플리케이션 작업 후 만들어지는 페이지는 FBML(FaceBook Markup Language)이라는 마크업 언어로 기술됩니다. 이것은 Facebook에서 해석되어 HTML로 변환되어 웹 브라우저에게 전달되는 것이죠. 이 과정에 대한 자세한 설명은 "Step-by-step Guide to Creating an Application"을 참고하시기 바랍니다. (관심있는 분은 직접 해 보세요, 그리 많은 시간 걸리지 않습니다.^^)

[S31] 그럼 지금부터 어플리케이션 개발을 위해 제공되는 플랫폼의 세 가지 컴포넌트, API, FQL, FBML에 대해 간략히 살펴보겠습니다. 자세한 내용은 아래의 링크들을 참고하세요.

사용자 삽입 이미지

1) API
Facebook에 접근하여 profile, friend, Page, group, photo, and event data 등의 정보를 가져 오거나 News feed를 보내는 등의 기능을 제공하는 REST 방식의 API 모음입니다. 이러한 API를 어플리케이션 프로그래밍에 가져다 쓸 수 있도록 API 클라이언트 라이브러리를 제공합니다. 공식적으로 PHP와 Java 라이브러리만 제공하지만 비공식적으로 Ruby, Perl, Python, .NET 등 대부분의 프로그래밍 언어를 위한 라이브러리를 지원하고 있습니다.

2) FQL (Facebook Query Language)
Facebook data를 요청할 수 있는 SQL 스타일의 인터페이스로서 API를 통해서 접근할 수 있는 데이터에 모두 접근할 수 있습니다. API가 있는데 왜 FQL을 제공할까요? 우선 FQL을 이용하면 특정 필드 정보만 가져 올 수 있어 bandwidth와 parsing cost를 줄일 수 있습니다. 또한 복잡한 요청을 한번에 기술하여 보낼 수 있기 때문에 request 수가 현저히 줄어들고 단일 API(fql.query)를 사용할 수 있기 때문에 일관성 있는 프로그래밍의 장점이 있습니다. 슬라이드의 예와 같이 복잡한 요청을 한번의 query로 끝낼 수 있는 것이죠.

사용자 삽입 이미지

[S32]

3) FBML (FaceBook Markup Language)
Facebook 페이지와 조화롭게 통합하기 위해 마크업 언어로 HTML과 유사하지만 어떤 element는 빠지고 Facebook에 특화된 어떤 요소는 추가되었습니다. 슬라이드의 예를 보면 Photo 어플리케이션 Canvas 상단에 "Create a new photo album"과 "Photos of you" 메뉴 추가는 FBML로 간단히 기술할 수 있습니다. 또한 drag-and-drop 등과 같은 복잡한 기능도 간단한 FBML 태그로 기술할 수 있습니다.

사용자 삽입 이미지

[S33]
2007년 Facebook은 몇 가지 광고 모델들을 발표하였습니다. Facebook 비즈니스 페이지에 가 보면 그들의 광고모델에 대한 소개가 나와 있습니다. 이 중에서 가장 주목해 봐야 할 것이 Social Ads입니다. 많은 SNS가 소셜 광고를 고민하고 있을건데 Facebook Social Ads가 그 첫 시험대에 올랐다고 볼 수 있습니다. 좌측 Left Nav 박스 아래 사용자에 타겟팅된 광고가 노출됩니다. 그리고 News Feed에 매우 재미있는 형태로 웹싸이트가 광고됩니다. 이것은 Facebook Beacon과 관련있습니다. 웹페이지에 Facebook이 제공하는 세줄짜리 코드를 추가하면 사용자들의 액션들(로그인, 상품구매, 상품찜 등)에 대한 정보가 Facebook으로 보내져서 그 사용자의 Profile News feed에 추가되는 것입니다. 마찬가지로 친구들에게 News feed가 날라가겠죠. 예를들어 Joost에서 어떤 채널을 시청하게 되면 그 정보가 Facebook에 News feed에 기록된 것을 볼 수 있습니다. 재밌는 아이디어입니다. 외부 웹싸이트에서 사용자의 액션을 그 싸이트를 홍보하는 광고로 사용하겠다는거죠. 그러면서 덤으로 Facebook 외부에서 사용자들이 무엇을 하는지 정보도 얻구요. 하지만 Privacy 문제가 일어날 가능성이 다분하죠? 아니나다를까 Beacon이 privacy 문제를 일으켰고 급기야 CEO가 공식사과하고 나섰죠. 좀 더 지켜봐야 할 모델인 듯 합니다. 하지만 외부 싸이트와 소셜 네트워크를 어떤 식으로든 연결시키려는 시도를 했다는 점에서 의미가 있다고 봅니다. 좀 더 개선된 아이디어들이 또 나오겠죠? ^^

SNS(소셜 네트워크 서비스)는 이제 단순히 소셜 네트워크만 만들고 보여주는 단계를 넘어서고 있습니다. 어플리케이션들을 플러그인시킴으로써 웹에서 할 수 있는 모든 것
사용자 삽입 이미지
을 그 안에서 할 수 있는 환경을 만들어가고 있는 것이죠. 즉, 소셜 플랫폼으로 진화하고 있는 것입니다. 소셜 플랫폼은 잘 확보된 사용자 기반을 무기로 소셜 광고, 소셜 검색, 소셜 쇼핑 등의 다양한 시도를 할 겁니다. 그리고 어떤 다른 플랫폼 보다 막강한 파워를 낼 것으로 기대됩니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선


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

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

3. Google: Ad Platform
[S15]
Google은 워낙 다양한 종류의 서비스를 제공하기 때문에 딱히 어떤 플랫폼이라고 한정짓기 어렵지만 그래도 그 중에 하나를 고르라면 광고(Ad) 플랫폼이라고 하겠습니다. 왜냐면 그 이외의 다른 서비스들(Gmail, Google Docs, Google Search 등)은 그 자체 기능을 가지고 있지만 궁극적으로 Google이 목표로 하는 바는 광고매체를 늘리는 역할이기 때문입니다. 따라서 모든 서비스의 중심에 광고가 있다고 볼 수 있죠. Google의 광고 플랫폼은 광고주(Advertiser)-광고매체(Publisher)-소비자(Audience) 모두를 AdWords와 AdSense 광고 모델로 묶으면서 웹을 일종의 마켓플레이스로 진화시키고 있습니다. 즉, 웹 자체가 온라인 쇼핑몰이라는 것이죠. (비슷한 주장을 하고 있는 Read & Lead 블로그의 "누가 진정한 마켓플레이스인가? - 이베이 vs 구글"도 참고해 보세요.)

사용자 삽입 이미지

[S16] 그렇다면 우선 Google 광고의 핵심인 AdWords에 대해 알아보겠습니다. AdWords는 검색 키워드와 관련있는 광고를 띄워주는 검색광고입니다. Google 검색엔진에서 "digital camera"를 검색하면 우측이나 상단에 "Sponsored Links"라고 뜨는 것들이 AdWords에 해당합니다. 사용자가 관심을 가지는 아이템(키워드)에 맞게 광고를 하기 때문에 Targeted Ad입니다. Pricing 모델은 두 가지가 있는데 가장 일반적으로 알려진 것이 CPC(Cost-per-Click)입니다. 즉, 광고를 클릭하는 만큼 광고주가 Google에게 비용을 지불하는 것이죠. 키워드 광고가 여기에 해당합니다. 반면에 특정 싸이트에 어떤 광고를 노출하도록 요청하는 경우 CPM(cost-per-thousand impressions) 모델을 적용합니다. 즉 노출 빈도에 따라 광고비를 지불하는 것입니다. 광고주는 자신이 구매하고자 하는 키워드에 클릭당 얼마를 쓸 수 있는지 책정합니다. 그러면 경매방식으로 비싼 값을 부른 사람들이 키워드를 구매할 수 있고 고가를 부를 수록 더 윗자리에 노출될 가능성이 높아집니다. 하지만 단지 경매가만 가지고 광고의 위치를 결정하는 것은 아닙니다. Google은 광고 역시 하나의 정보로 생각하여 광고의 CTR(Click-Through Rate) 역시 Ad Rank 결정에 반영합니다. 이것이 다른 검색광고의 정책과 차이가 나는 점입니다.

사용자 삽입 이미지

[S17] AdWords와 함께 Google을 먹여 살려 주는 또 하나의 광고 모델이 AdSense입니다. (대략 40~50% 정도 매출) AdWords는 예전에 Overture가 제안한 것이라면 AdSense는 Google이 독자적으로 개발해 낸 모델입니다. AdSense는 웹페이지를 가진 누구나 Google에 신청하여 광고를 보내주는 Javascript 코드를 받아 자신의 웹페이지에 추가하는 것으로 Google 광고에 참여할 수 있습니다. 일반 사용자들이 그 웹페이지를 방문하면 광고 스크립트 코드가 실행되면서 현재 페이지와 가장 관련이 있는 광고를 보내주는 것입니다. 즉, Context Ad입니다. 그 광고를 보고 클릭을 하게 되면 광고주는 클릭당 광고비(CPC모델)를 Google에게 지급하게 되고 이것을 웹페이지 주인과 분배하는 것입니다. 기존 배너 광고가 트래픽 상위의 대규모 싸이트를 광고매체로 이용하였다면 AdSense는 타겟을 중소규모 싸이트로 맞춘 것입니다. 광고매체에서 롱테일을 활용한 셈이죠. 즉, 중소규모 싸이트는 개개 싸이트가 발생시키는 CTR은 그렇게 높지 않으나 이 영역의 싸이트는 무수히 많기 때문에(롱~~~테일) 총 광고클릭수는 무시할 수 없는 양이 된다는 겁니다. 또한 중소 싸이트들에 새로운 수익모델을 제공해 준다는 점에서 그 의미가 크다고 할 수 있습니다.

사용자 삽입 이미지

[S18][S19] 자, 이 정도면 Google 광고에 대한 기본적인 지식은 충분합니다. 지금부터는 Google 광고가 어떤 전략을 취하고 있는지 살펴 보겠습니다. Google 수익의 99%가 광고에서 나온다는 것은 익히 잘 알려진 사실입니다. 그렇다면 Google에게 가장 큰 위협이 되는 곳은 어디일까요? 제 생각에는 대형 온라인 쇼핑몰이라고 생각합니다. 왜냐면 대형 온라인 쇼핑몰이 사용자의 니즈를 파악하고 구매에 필요한 모든 정보들을 다 갖추고 있다면 그 안에서 떠날 필요가 없기 때문입니다. 그렇게 되면 굳이 검색을 하거나 Google 광고를 클릭해서 다른 쇼핑몰로 갈 필요가 없지요. 즉, Google은 중소규모 쇼핑몰들의 대표가 되어 대형 쇼핑몰과 싸우고 있다고 볼 수도 있습니다. 따라서 Google 입장에선 광고주들을 위해 자신의 광고 네트워크와 Google 싸이트를 묶어 하나의 거대한 마켓플레이스를 만들어 나가는 것이 대응전략이 될 것입니다. "쇼핑=검색"과 같은 등식을 모든 소비자들의 머리 속에 각인시키고 싶어하겠죠. 이를 위해 다양한 광고 Pricing 모델을 개발하고 새로운 서비스를 개발하여 광고 네트워크의 범위를 점점 더 확대시키기 위해 노력하고 있습니다. 이것이 Google Ad Platform이 취하고 있는 전략입니다.

사용자 삽입 이미지

[S20] Google 광고 네트워크는 이미 웹의 80% 정도를 커버한다고 합니다. 이것은 Google 검색과 같은 자체 서비스들과 검색 파트너(AOL, Ask 등), 컨텐츠 사업자(MySpace, NYT 등)를 모두 포함합니다. 또한 광고 네트워크를 확장시키고 광고 타입을 다변화하기 위해 다양한 회사들을 M&A하고 있습니다. DoubleClick과 같이 직접 광고 회사를 인수하거나 dMarc(라디오광고), Youtube(동영상광고), Feedburner(RSS광고) 등 다른 형태의 광고를 시도하기 위해 회사들을 인수하고 있습니다. 결국 최종 목표는 광고의 범위와 종류를 더 넓게 확대하여 광고주에게 원하는 형태의 광고를 더 많은 소비자에게 노출시킬 수 있는 매력을 주겠다는 것입니다. Google의 광고매체에 대한 확장은 이제 PC를 넘어 모바일, TV, 오프라인 매체 등으로 점점 확산되어갈 전망입니다.


사용자 삽입 이미지

[S21][S22] Google이 주도하고 있는 온라인 광고 시장은 성장가도에 있다는게 일반적인 견해입니다. 온라인 광고 시장은 점점 확대되고 있고 향후 라디오 광고를 넘어 TV 광고를 위협하는 단계로 나갈 것이라고 예측하고 있습니다. 온라인 광고 시장의 40% 정도를 차지하는 검색광고에서 Google은 79% 정도를 차지하고 있다니 그 영향력을 짐작할 수 있습니다. 하지만 최근들어 Google의 광고지배력에 대해 우려의 목소리가 나오고 있습니다. 시발점이 된 것은 얼마전 발표된 comScore의 리포트 때문이죠. 여기서
사용자 삽입 이미지
Google의 Piad Click Rate가 8.1% 감소했다는 발표가 있었고 이것은 다른 검색엔진이 소폭 상승한 것과는 대조적인 결과입니다. 아직 원인에 대해선 정확한 분석이 없지만 지금껏 잘나가던 Google에게 제동이 걸린 것만은 분명한 것 같습니다. 700 달러대의 주가가 400달러대로 곤두박질 친 것이 이를 잘 반영한 결과라 할 수 있죠.

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

Posted by 한재선


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

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

2. eBay: E-commerce Platform
[S10]
아마 웹플랫폼의 시작은 E-commerce 플랫폼일 것입니다. Amazon과 eBay는 웹 2.0이라는 용어가 정의되기 전부터 플랫폼으로서 역할을 시작하고 있었습니다. Web Services라는 기술의 등장과 함께 서비스를 외부로 오픈하는 표준 인터페이스(SOAP, UDDI, WSDL)가 마련되었고 이를 통해 외부 서비스들과의 소통과 통합이 이슈가 되었죠. Amazon는 2002년 Amazon Web Services를 론칭하고 eBay는 2000년 이미 Developer Program을 시작하고 2004년 SOAP API를 추가했습니다. 그만큼 E-commerce 영역에서 플랫폼으로의 진화는 자연스런 현상이었습니다.

왜 다른 인터넷 서비스보다 전자상거래 분야에서 플랫폼의 모습이 먼저 나오는 것일까요? 너무나 당연한 것이 돈이 되기 때문입니다. 원래 eBay나 Amazon에 찾아오는 고객들에게만 상품을 팔다가 플랫폼을 구축하여 외부 상점들도 eBay나 Amazon의 상품을 취급할 수 있게 해 줌으로써 자신들의 마켓플레이스가 엄청나게 확장된 것이죠. 이는 바로 수익의 증가와 직결되었구요. 또한 다양한 외부 개발자와 써드파티 회사 등에서 신선한 아이디어를 수혈받으면서 내부 혁신의 한계를 극복할 수 있는 효과도 얻게됩니다. 실제로 eBay를 위한 툴이나 서비스를 만드는 외부 등록 개발자수는 5만명이나 되고 이들이 만든 어플리케이션이 4,800개나 된다고 합니다. eBay 상품 목록의 25%는 이 어플리케이션에서 생성되고 있습니다.

ebay Platform에 대한 참고글
- eBay Unveils Major Platform Extensions, Business Wire, June 2007
- Auctions For All: eBay Expands Platform and APIs, Software Developer, January 2008

사용자 삽입 이미지

eBay 비즈니스 플랫폼은 다음과 같은 5가지 핵심 서비스를 제공하고 있습니다.
1. eBay: Auction 및 오픈마켓 등의 마켓플레이스
2. Paypal: 전자결제 서비스
3. Skype: 거래 당사자간 인터넷 전화
4. Shopping.com: 가격 비교 서비스
5. ProStores: 온라인 쇼핑몰 구축 서비스

이런 E-commerce에 필요한 기능을 이용하여 다양한 외부 서비스들이 개발되고 있습니다. 외부 서비스들은 eBay Affiliate Program을 통해 eBay로 보낸 트래픽에 대해 수익을 공유합니다.
- Earn between 50% and 75% of eBay's Revenue (not item sale price) on Winning Bids or Buy It Now (BIN) transactions.
- Earn between $25.00 and $35.00 for each new eBay active user (ACRU)

그럼 eBay 플랫폼이 제공하는 API를 이용하여 구현된 예를 살펴 보겠습니다.
사용자 삽입 이미지

비드머신은 옥션의 입찰, 낙찰 등의 옥션 운영을 관리해 주는 상업용 서비스로 eBay Bidding API를 이용합니다.

사용자 삽입 이미지

또한 mapBid는 어떤 지역 근처에서 진행되고 있는 경매정보를 Google Maps위에 보여주는 Mashup 서비스를 구현하고 있다.

사용자 삽입 이미지

그리고 2007년 DEMO 컨퍼런스에선 Adobe의 차세대 RIA 기술인 AIR(Adobe Integrated Runtime)를 이용해 eBay Desktop 어플리케이션을 시연함으로써 최신 RIA 기술과 eBay 플랫폼 연동 가능성을 보여주었습니다. (데모 동영상)


사용자 삽입 이미지
[S11][S12][S13]
eBay 플랫폼의 구조에 대해 기술적으로 살펴보겠습니다. 가장 기본적으로 웹 서비스들에서 접근할 수 있는 SOAP 기반의 API와 XML 기반의 eBay API를 제공하고 있습니다. 그 위에 어플리케이션을 쉽게 만들 수 있도록 eBay SDK를 제공
사용자 삽입 이미지
합니다. .NET 기반의 윈도우즈 SDK와 Axis 기반의 자바 SDK, 두 가지를 제공합니다. 이와 같이 웹 서비스와 데스크탑 어플리케이션 양쪽을 개발할 수 있는 환경을 갖추고 있습니다. 그리고 매년 eBay Developers Conference를 개최하여 개발자들에 대한 지원을 아끼지 않고 있습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선


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

반갑습니다, "차세대 웹기술과 컨버전스" 네번째 수업시간입니다. 이번 시간의 주제는 웹 2.0의 핵심이자 웹의 궁극적인 발전 방향인 "플랫폼"에 대해 말씀드리겠습니다. 강의자료는 아래에서 다운받으세요.



이번 시간엔 자장면을 시켜 먹었습니다. ^____^ 혹시 오해있을까봐 말씀드리는데, 학생들 수업이 연속적으로 있어서 저녁 먹을 시간이 마땅히 없어 수업 중간에 쉬는 시간에 먹는겁니다. 혹자는 이 수업시간은 맨날 먹기만 하느냐고 오해를 하실까봐 노파심에 말씀드렸습니다, 수업도 합니다. ^^


1. 플랫폼: Overview

사용자 삽입 이미지

[S3] 지난 시간까지 웹 2.0의 세 가지 기본 철학, "참여", "공유", "개방"을 가능케한 기술과 비즈니스에 대해 살펴 보았습니다. 웹 2.0의 철학과 기술은 궁극적으로 웹이 "플랫폼"으로 진화하는데 결정적인 계기가 되었습니다. 그래서 웹 2.0의 핵심, 혹은 웹 2.0이 아니더라도 향후 웹의 미래는 "Web as Platform"입니다. 웹 2.0을 정의한 팀오렐리의 "What is Web 2.0?"에서도 가장 핵심적으로 등장하는 개념입니다. 자, 그럼 웹으로서의 플랫폼이 무엇일까요? 이것을 알기 위해선 우선 Platform이 무엇인지 짚고 넘어가야 합니다.

[S4] Platform이라는 용어는 IT쪽에선 꽤 오래전부터 쓰던 용어입니다. 하드웨어 플랫폼, 소프트웨어 플랫폼, 모바일 플랫폼, 미들웨어 플랫폼 등 무수히 많은 플랫폼이 존재합니다. 컴퓨터 운영체제로 윈도우즈 플랫폼과 리눅스 플랫폼이 유명하고 모바일쪽에선 국내 표준으로 위피 플랫폼이 한참 떳었지요. 팀오렐리를 비롯해 다양한 분야, 다양한 사람들이 플랫폼에 대해 나름대로 정의를 하는데 저는 올라웍스의 류중희대표님의 비유가 가장 맘에 듭니다.

사용자 삽입 이미지

[S5] 왕의 남자 보셨죠? 주인공 장생과 공길이 사고를 치고 서울로 도망쳐와 저자거리에서 멍석을 깔고 놀이판을 벌이고 있는 광대들을 만나게 됩니다. 하지만 그들의 묘기가 시원찮자 직접 나서서 재주를 부립니다. 관중들은 열광하죠. 그러면서 돈을 막 던집니다. 그 돈으로 주인공과 광대들은 함께 술먹으며 행복한 시간을 보냈다는 전설이 있죠. ^^ 자, 어디가 플랫폼일까요? 네, 바로 "멍석"이 플랫폼입니다. 광대들은 플랫폼 제공자(사업자)죠. 그럼 주인공은? 네, 바로 여러 분과 같은 정보 생산자, 서비스 개발자 등입니다. 광대들의 역할은 멍석을 깔고 처음 몇 명의 관객을 모으는겁니다. 재주를 부리는건 주인공과 같은 재주꾼들이 하는거죠. 그리고 함께 수익을 분배하는거죠.

[S6] 그럼 제 나름대로 플랫폼을 정의해 보도록 하겠습니다.
플랫폼이란 그 자체가 최종 결과물이 아니라 소프트웨어나 서비스가 만들어지는 재료환경을 제공하는 것입니다. 여러분이 많이 쓰시는 윈도우즈 플랫폼을 볼까요? PC에 윈도우즈 OS만 있다면 사용자는 아무 일도 못합니다. 즉, OS 자체가 최종 결과물은 아닙니다. 여기 위에서 워드나 웹브라우저 등의 소프트웨어가 있어야 비로서 쓸모있는 도구가 됩니다. 윈도우즈 OS는 이런 소프트웨어에게 "재료"로서 프로그램 라이브러리를 제공하여 PC 자원을 사용할 수 있게 해 주고 소프트웨어가 실행될 수 있는 "환경"을 제공해 주어 플랫폼의 역할을 합니다.

사용자 삽입 이미지

[S7] 그렇다면 "Web as Platform", 즉 웹 플랫폼은 무엇을 말하는 것일까요? 윈도우즈 플랫폼과 똑같이 비유하자면 웹 플랫폼도 소프트웨어를 개발할 수 있는 재료를 제공하고 그것을 실행시켜 주는 환경을 제공해 주는 것이겠죠? 맞습니다. 이제는 웹 자체가 서비스를 개발하고 운영할 수 있는 재료와 환경을 제공해 줍니다. 이것이 가능하게 된 것은 서비스의 재료인 데이터와 기능들이 이미 웹에 대부분 존재하고 공개되어 있기 때문입니다. 서비스 제공자가 만든 RMC(Ready-Made Contents)와 함께 "참여"를 통해 사용자가 만든 UCC(User-Created Contents)가 웹을 하나의 거대한 "데이터베이스"로 만든 것입니다. 이런 웹 데이터베이스는 RSS나 Open API와 같은 표준 인터페이스를 통해 접근할 수 있도록 "개방"되었습니다. 이제는 서비스를 만들기 위해 따로 DB를 구축할 필요없이 웹 데이터베이스에서 표준 인터페이스를 통해 데이터를 가져오면 됩니다. 이것이 웹 플랫폼입니다.

[S8] 웹 플랫폼의 등장으로 현대는 플랫폼 전쟁의 시대로 접어들었습니다. 지금까지 PC 시대에선 윈도우즈 플랫폼이 지배적인 위치를 차지하고 있습니다. 윈도우즈 플랫폼 이전에 각각의 영역에서 선두를 달리던 어플리케이션들이 있었습니다. Lotus 1-2-3, WordPerfect, Netscape Navigator 등이 그 예입니다. 하지만 MS가 윈도우즈 플랫폼이라는 우월적 지위를 활용함으로써 기존 어플리케이션과의 전쟁에서 승리한 것입니다. 즉, 플랫폼과 어플리케이션과의 전쟁에선 플랫폼이 승리함을 입증한 셈이죠.

하지만 현대는 이미 PC 시대를 넘어 인터넷 시대가 되었습니다. 인터넷 시대의 어플리케이션은 보내는 쪽과 받는 쪽의 커뮤니케이션이 가장 중요하고 이를 위해서는 양쪽이 상호운용성(Interoperability)가 보장되어야 합니다. 따라서 통신의 양쪽 끝단을 모두 컨트롤할 수 없다면 인터넷 어플리케이션을 지배하기 힘든 것입니다. 윈도우즈 플랫폼은 인터넷 익스플로러를 통해 클라이언트 사이드를 컨트롤 할 수 있었지만 서버 사이드에선 독점적인 지위를 차지할 수 없었지요. (IIS라는 웹서버가 Apache 웹서버를 이기고 전 세계 웹서버 시장을 장악했다면 어떻게 되었을까요?) 윈도우즈 플랫폼이 웹 플랫폼과의 전쟁에서 밀릴 수 밖에 없는 이유입니다. 또한 윈도우즈 플랫폼은 한 회사의 독점적인 플랫폼인데 반해 웹 플랫폼은 Open Standard와 Protocol, 그리고 협력에 대한 동의가 한데 어우러져 만들어낸 주인없는 플랫폼입니다. 어느 쪽이 더 강력한 힘을 가지겠습니까? (물론, MS 역시 웹 플랫폼 방향으로 발빠르게 적응해 가고 있습니다. 미래에는 윈도우즈 플랫폼의 경험과 지배력을 잘 살려서 양쪽 플랫폼을 결합한 새로운 플랫폼이 나올 수 있지 않을까도 기대해 봅니다.)

자, 지금까지 플랫폼과 웹 플랫폼에 대한 소개를 드렸습니다. 지금부터 다음과 같은 글로벌 플랫폼 기업들의 사례 를 살펴보면서 웹 플랫폼에 대해 더 자세히 알아보도록 하겠
사용자 삽입 이미지
습니다.
- E-commerce platform: eBay
- Ads platform: Google
- Social platform: Facebook
- Web Service platform: Amazon
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선


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

"차세대 웹기술과 컨버전스" 세번째 수업시간 "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 한재선


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

"차세대 웹기술과 컨버전스" 세번째 수업시간 "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 한재선


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

"차세대 웹기술과 컨버전스" 세번째 수업시간 "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 한재선


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

"차세대 웹기술과 컨버전스" 세번째 수업시간 "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 한재선


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

반갑습니다, "차세대 웹기술과 컨버전스" 세번째 수업시간입니다. 이번 시간의 주제는 "참여"와 함께 웹 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 서비스들이 주를 이룰지는 지켜봐야 할 포인트 같습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선


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

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

3.3 개인적인 목적을 위한 암묵적인 참여
[S16]
아마도 이 부분이 가장 낯설면서도 기술적으로 가장 어려운 부분이 될 것입니다. 그런만큼 얻는 것도 많죠. 그리고 제가 항상 가장 강조하는 부분입니다. 참여라고 하면 보통 블로그에 글을 쓰거나 지식인에 답변을 올리는 등의 사용자의 의도적인 액션이 있어야 된다고 생각할 수 있습니다. 하지만 조금만 더 시각을 넓혀 참여를 바라본다면 사용자가 하는 모든 행위들이 다 참여에 해당한다고 생각할 수 있습니다. 블로그 포스트 읽기, RSS 피드 등록, 온라인 쇼핑몰 구매, 웹페이지 링크 걸기, 검색, 이 모든 것이 모두 사용자의 "참여"입니다. 컨텐츠를 생산하는 것만큼의 적극적인 참여는 아닐지라도 이런 소소한 사용자의 모든 행위는 서비스에 매우 중요한 정보를 제공합니다. 그 정보를 잘 활용하면 집단지성을 끌어낼 수 있습니다. 여기에 주로 복잡한 데이터 분석 기술이 사용되기 때문에 경쟁 서비스에서 쉽게 모방할 수 없는 경쟁력을 가집니다.

Tim O'Reilly의 "What is Web 2.0?" 문서에 다음과 같은 구절이 나옵니다.
The Architecture of Participation
One of the key lessons of the Web 2.0 era is this: Users add value. But only a small percentage of users will go to the trouble of adding value to your application via explicit means. Therefore, Web 2.0 companies set  inclusive defaults for aggregating user data and building value as a side-effect of ordinary use of the application. As noted above, they build systems that get better the more people use them.
요약해 보자면 사용자가 가치를 부여하는 것은 사실이지만 적극적인 방식("explicit means")으로 참여할 사용자는 극소수일 것이므로 일반적인 서비스 이용에서 사용자 데이터를 모아 가치를 찾아내는 내부적인 장치를 가지라는 것입니다. 이것이 참여의 Architecture인 것이고 이번 섹션에서 언급하고 있는 참여와 이를 통한 집단지성을 말하는 것이죠.

[S17] 자, 그럼 지금부터 대표적인 케이스로 다음의 네 가지를 살펴 보겠습니다.
1) Google PageRank
2) Amazon Recommendation
3) Folksonomy
4) Collaborative Spam Filtering

 
3.3.1 Google PageRank
사용자 삽입 이미지

[S18]
일반적으로 Google 검색엔진의 성공요인으로 PageRank라는 검색 순위 알고리즘을 언급합니다. Google 이전 대부분의 검색엔진들은 검색 결과 순위를 웹페이지내 검색 키워드의 빈도에 따라 결정했습니다. 하지만 이 방법은 중요한 문서를 찾아내는데는 그다지 효과적이지 못하고 스팸에 취약한 단점이 있습니다. 그에 대한 해결책으로 Google은 웹페이지가 다른 웹페이지에 의해 링크된 개수를 순위에 적용하는 PageRank를 개발했습니다. (여기서 Page가 웹페이지의 Page갔죠? 사실은 처음 고안한 구글 창업자 래리 페이지의 Page 입니다. ^^) 웹페이지에 링크 거는 행위를 민주주의 투표에서 한표를 던지는 행위(voting)로 생각한 것입니다. 하지만 한가지 틀린 점이 있습니다. 민주주의에선 대통령의 한표나 보통 사람의 한표나 똑같지만 PageRank에선 링크를 건 주체의 영향력(PageRank)에 따라 링크의 가치가 다르다는 것입니다. 예를 들어 제 개인 블로그에서 이 블로그를 링크한 것보다 야후 디렉토리 페이지에서 링크한 것이 훨씬 높은 점수를 받는 것이죠. 일리있죠?
자, 그렇다면 지금까지 설명드린 Google PageRank에서 Collective Intelligence가 보이십니까? 바로 그겁니다. 사용자들은 PageRank를 위해 링크를 단 것이 아니라 각 개인의 목적을 위해 링크를 달았을 뿐이고 그렇게 개인적인 용도에 제한되었을 수 있는 행위를 Google은 모아서 PageRank라는 시스템으로 "참여"시킨 것입니다. (Implicit하게) PageRank 알고리즘의 기본 아이디어는 기술적으로 복잡하지 않습니다. 웹을 사용하는 사람이면 누구나 생각해 낼 수 있는 것입니다. 앞으로 설명드릴 대부분의 예도 기본 아이디어는 누구나 생각할 수 있는 수준입니다. (물론 구현에선 기술적인 지식이 있어야 합니다.) 우리가 얻어야 할 교훈은 성공적인 기술은 복잡하지 않다는 것, 그러므로 주의깊게 관찰하여 가치를 끌어낼 수 있는 부분을 찾고 빠르게 실행하는 것입니다.

3.3.2 Amazon Recommendation
[S19]
Amazon의 성공요인 중 하나는 그들의 강력한 추천 시스템입니다. 지금 한번 Amazon을 방문해서 책을 하나 검색해 보세요, 얼마나 다양한 종류의 추천들이 나오는지 보실 수 있을겁니다. 이러한 추천은 사용자들로 하여금 관심을 불러일으켜 구매를 유발합니다. 수익과 직결되는 부분이죠. 사용자와 아무 관련없는 베스트셀러를 내세우는 것보다 사용자가 사려는 책과 관련된 책을 제시하는게 더 의미가 있는겁니다. 개인화 서비스로 연결되는 것이죠. 저는 추천 시스템을 매우 중요하게 봅니다. 다음과 같은 세 가지 이유 때문이죠.

사용자 삽입 이미지

1) Long Tail 활성화
[S20]
Long Tail은 웹 2.0을 설명하는 중요한 키워드 중 하나입니다. Amazon과 같이 온라인 판매 싸이트에서 베스트셀러가 아닌 대부분의 상품들은 그 수가 매우 많아 판매순위 그래프에서 긴꼬리를 이룹니다. 긴꼬리에 있는 유명하지 않은 아이템들은 개별 판매량은 적더라도 그 총합을 따지면 무시하지 못할 수익을 달성한다는 거죠. 바로 롱~~~~테일이기 때문입니다. 온라인에서 판매되고 소비되는 많은 아이템들이 롱테일 현상을 보입니다. 자, 여기서 한가지 의문이 생깁니다. 롱테일에 포진되어 있는 그 수많은 유명하지 않은 아이템들의 존재를 사용자가 어떻게 알 수 있는가? 소비를 하려해도 알아야 할 것 아닙니까? 즉, Findability가 떨어지는 것 아니냐는거죠. 바로 추천 시스템이 롱테일 아이템들의 Findability를 높여주는 것입니다. 베스트셀러 정보 옆에 관련된 내용의 롱테일 아이템 리스트를 보여주는거죠. 따라서 추천 시스템이 얼마나 정확하냐에 따라 롱테일 아이템들의 판매량이 영향을 받을 것이고 수익으로 직결되므로 추천 시스템은 보조적인 도구 이상의 역할을 한다고 볼 수 있습니다.

사용자 삽입 이미지

2) Attention Economy의 핵심기술
[S21]
앞으로 가장 희소한 자원은 사용자의 "Attention"이 될 것입니다. 정보의 양은 폭발적으로 늘어나지만 사용자가 관심을 가질 수 있는 시간은 언제나 한정적이기 때문이죠. 이에 대한 해결책으로 Attention Economy에선 사용자의 허락하에 자신의 Attention을 제공해 주고 관련 개인화 서비스를 받을 수 있도록하는 마켓플레이스를 만들것을 제안합니다. 지금은 사용자 Attention이 각 서비스별로, 사용자의 동의와 상관없이(가입시 약관에 있을테지만 거의 무용지물) 서비스의 목적을 위해 사용되고 있습니다. 이것을 Attention을 모으는 서비스, 저장하는 서비스, Attention에 맞는 개인화 서비스 등으로 나누어 사용자의 선택에 따라 각각이 연결되도록 하자는 것이죠. Attention Economy가 제안하는 방식으로 서비스들이 진화할지 아직 확실하지는 않지만 Attention이 점점 더 희소자원이 될 것이고 Attention을 인식하는 서비스, 즉 개인화 서비스가 향후 대세를 이룰 것이라는 것은 의심의 여지가 없습니다. (이 부분은 논란의 여지가 있다. 정말 개인화 서비스가 성공할 것인가? 여러 분의 의견을 듣고 싶습니다. 댓글, 트랙백 주세요~) 개인화 서비스에 핵심기술이 바로 추천 시스템이고 결국 Attention Economy를 이끌 미래 기술로 각광받을 것입니다.

3) Next Search Engine?
[S22]
이 부분이 가장 공격적인(혹은 허무맹랑한 ^^) 예측입니다. 여러 분들은 검색과 추천의 차이가 뭐라고 생각하세요? 검색은 찾고자 하는걸 사용자가 알려주는 것이고 추천은 알려주지도 않았는데 찾아주는 것입니다. 말하자면 "찾는다"라는 것은 똑같다는겁니다. 만약 요즘 이슈가 되고 있는 사건을 찾으려 네이버에 들어갔는데 인기검색어가 떡~ 하니 나오면 검색할 필요가 없겠죠? 애기가 이유식을 먹을 때가 되어 검색 서비스에 들어갔더니 이유식 관련 정보들을 대문에 쏟아낸다면? 검색할 필요가 없겠죠! 검색이 진화하면 결국 가장 진화된 형태의 추천 시스템이 되지 않을까 싶습니다. Google과 네이버를 뒤집으려면 현 검색의 방식틀에선 힘들거라 봅니다. 뭔가 패러다임을 바꿀 수 있는게 필요한데 제 생각엔 추천 시스템을 잘 생각해 보면 되지 않을까 점쳐봅니다~


[S23] 이런 이유들로 추천 시스템을 강조하고 있습니다. 그럼 지금부터 쬐끔 머리 아픈 기술 얘기를 해 볼까요? 추천 시스템은 어떻게 방식으로 만들어질까요? 일반적으로 세 가지 방식이 있습니다.
- Content-Based Recommendation
- Collaborative Filtering
- Hybrid Approach

1) Content-Based Recommendations
[S24]
컨텐츠의 내용을 분석하여 유사한 컨텐츠를 찾아 주는 방식입니다. 음악 추천 서비스 중에 Pandora라는 서비스가 내용기반 추천의 대표적인 예입니다. (아쉽게도 얼마전부터 미국 이외 지역에선 사용할 수 없습니다.) 이들은 수백가지의 음악적 속성을 정의하고 각 곡을 직접 들으면서 각 속성별로 값을 정해서 곡의 특징벡터를 만드는 것입니다. 그렇게 만든 음악적 특징벡터를 이들은 Music Genome이라고 부릅니다. 말되죠? ^^ 이제 곡들의 비교는 이 벡터들 사이의 수학적인 비교로 기계적으로 처리할 수 있습니다. 이 방식의 장점은 사용자의 데이터가 전혀 없더라도 아무 곡이나 하나 좋아하는 곡을 입력하면 유사한 분위기의 곡들을 찾아준다는 것입니다. 하지만 단점은 추천한 곡의 좋고 나쁨은 보장하지 못한다는거죠. 판단은 사용자의 몫으로 맡기는겁니다. 이것은 매우 중대한 단점입니다. 열심히 추천하고도 욕먹는 일이 자주 생기겠죠. 이런 문제를 해결한 것이 Collaborative Filtering입니다.

2) Collaborative Filtering
[S25][S26][S27] 추천 시스템으로 가장 많이 쓰이고 있는 기술입니다. 또한 우리가 논의하고 있는 Collective Intelligence의 좋은 예이기도 하구요. Amazon에서 사람들이 어떤 책을 검색하고 훓어보고 구매를 하는 일련의 행위는 그 책에 대해 관심이 있기 때문입니다. 따라서 사용자가 그 책의 가치에 대해 한표 던진 것으로 생각할 수도 있겠죠. 물론 서비스에 따라서는 사용자가 직접 평점을 주도록 하는 경우도 있습니다. 이와 같이 여러 가지 방법에 의해 사용자들은 각 아이템에 대해 평점을 주게 되고 그 정보를 모으면 사용자의 취향 정보 벡터를 만들 수 있습니다. 이 정보를 각 사용자끼리 비교해 보면 각 사용자에 대해 유사한 성향의 사용자 리스트를 얻어낼 수 있고 유사한 성향의 사용자들이 좋게 평가했던 아이템을 추천해 주게 되는 것이지요. (좀 복잡하게 설명한 듯 한데 강의자료 슬라이드 25번을 보면 예로 간단히 설명되어 있으니 참고하시기 바랍니다.) 구매를 하든 평점을 매기든 이런 행위들은 사용자의 개인적인 행위이지만 이 정보를 잘 모아 비교함으로써 추천 시스템이라는 집단지성을 끌어낸 것입니다. 이 방식을 이용하여 음악을 추천하는 대표적인 서비스가 Last.fm입니다. Pandora와 반대되는 방식의 서비스이죠. 재밌는 서비스니 한번쯤 경험해 보시기 바랍니다.

3) Hybrid Approach
Collaborative Filtering을 통해 사용자의 취향에 맞으면서도 괜찮은(좋은 평점) 아이템을 추천 받을 수 있게 되었습니다. 즉, 내용기반 추천의 단점을 해결한 셈이죠. 하지만 모든 사용자들끼리 비교해야 하기 때문에 사용자가 많은 대규모 서비스에선 확장성이 떨어집니다. 또한 초기 사용자 정보가 어느 정도 쌓이기 전까진 추천이 부정확한 단점도 안고 있습니다. 그래서 Collaborative Filtering과 Content-Based Recommendation을 접목한 Hybrid Approach가 등장했습니다. 이에 대한 내용들은 너무 기술적이기 때문에 이쯤에서 멈추기로 하고 더 관심이 있으신 분은 Toward the next generation of recommender systems: a survey of the state-of-the-art and possible extensions라는 서베이 논문을 살펴 보시기 바랍니다. 추천 시스템과 관련된 거의 모든 기술과 문제점, 이슈 등이 잘 정리되어 있습니다. 다만 좀 기술적입니다. ^^ (다운받으려면 IEEE이나 ACM 계정이 필요하므로 필요하신 분은 댓글 남겨 주시면 개인적으로 메일로 보내드리겠습니다.)


[S28] 추천 시스템에 대해 마무리짓기 전에 상금이 걸린 재밌는 이벤트를 소개해 드리겠습니다. Netflix라는 온라인 DVD 대여 서비스가 있습니다. 여기가 수익을 많이 남기려면 사용자들이 영화를 자주 빌려 봐야 합니다. 그러려면 관심있을만한 영화를 잘 추천해 주는 것이 중요하죠. 그래서 그들은 자체적으로 추천 시스템을 갖추고 있습니다. 여기서 재밌는 것은 자신들의 추천 시스템을 개선하기 위한 R&D를 외부로 오픈해 버렸다는 점입니다. (Crowdsourcing이라는 개념이죠.) Netflix Prize라는 것을 걸고 자신들의 시스템 보다 성능이 10%만 향상되면 상금을 주겠다고 했습니다. 상금이 얼마나 될까요? 자그마치 100만달러입니다!!! 한번 도전해 볼만 하지 않습니까? 누구나 도전할 수 있습니다. 미국에선 수업 프로젝트로도 많이 도전한답니다. 시작한지 아직 2년이 안되었는데 벌써 8.7% 정도 향상되었습니다. 대단하죠? 핵심은 이렇게 큰 액수의 상금을 걸만큰 추천 시스템이 중요하다는 것입니다. ^^

3.3.3 Folksonomy
[S29][S30][S31]
 태깅del.icio.usFlickr와 같은 대표적인 웹 2.0 서비스의 성공요인입니다. 태깅을 통해서 정보가 조직화되고 멀티미디어 데이터가 검색 가능해지는 장점이 있습니다. 여기에 추가적으로 사람들에 의한 분류, 즉 Folksonomy의 장점을 얻을 수 있습니다. 일반적으로 분류(Taxonomy)는 각 분야의 전문가들이 모여서 고민 끝에 분류 체계를 만들어 냅니다. 하지만 이런 분류체계가 완전하지도 않고 일부 전문 분야에 대해서만 되어 있습니다. 하지만 많은 사람들이 컨텐츠에 태깅을 한다면 자동으로 분류체계를 만들 수 있는 가능성이 있습니다. 한 컨텐츠에 함께 달린(co-occurance) 태그들은 서로 연관성이 있는 키워드로 볼 수 있고 빈도수를 측정하면 키워드간에 계층구조를 알 수 있습니다. 예를들어 "암"과 "질병"이란 태그는 자주 함께 달릴 것이지만 전체적으로 보면 "질병"이라는 태그수가 더 많을 것입니다. 결론적으로 "질병"을 "암"의 상위 개념으로 분류할 수 있겠죠. 실제로 "위암(stomach cancer)"에 대해 위키피디아의 카테고리에 의해 Folksonomy를 만들어 보면 의학전문 분류체계보다 덜 전문적이지만 더 포괄적임을 알 수 있습니다. (슬라이드 30) 물론 Folksonomy가 Taxonomy보다 더 좋다거나 대체를 할 것이라고 볼 순 없습니다. 다만 Folksonomy는 분류에 대한 새로운 가능성을 열었고 Folksonomy를 활용할 수 있는 응용을 개발하면 그 힘을 발휘할 수 있을 것입니다. Folksonomy 역시 태깅이라는 개인적인 행위를 모아서 분류 체계라는 의미있는 참여로 바꾼 Collective Intelligence의 예라고 할 수 있겠죠. 태깅과 Folksonomy에 대해선 2006년도 TagDay 행사 발표자료에 잘 정리되어 있으니 참고하시기 바랍니다.

3.3.4 Collaborative Spam Filtering
[S32]
앞서 말씀드렸듯이 스팸과의 전쟁은 아마 영원히 계속 될 것입니다. 요즘 스팸을 걸러내는 방법으로 Collaborative한 방법을 많이 사용합니다. 태터툴즈의 EAS(EOLIN Anti Spam Service)도 이 방법을 쓰고 있죠. 어떤 방법이냐고요? 제가 모든걸 다 얘기해 주면 여러 분이 생각할게 없잖습니까? 이건 한번 고민해 보세요. 지금까지 설명드린 예를 곰곰히 생각해 보면 비슷한 방법으로 스팸 필터링도 떠 오를 것입니다.


사용자 삽입 이미지

4. 참여의 확대
[S33] 웹 2.0이 보통 "참여"라는 키워드로 정의되기 때문에 "참여"가 마치 웹 2.0에서 등장한 것처럼 오해할 수도 있습니다. 하지만 그 전에도 "참여"의 케이스는 많았고 지금도 웹을 넘어 다양한 분야에서 "참여"가 시도되고 있습니다. 오픈소스 운동은 어떻게 생각하면 웹 2.0의 산파 역할을 하지 않았나 생각됩니다. 그리고 우리나라의 자랑스러운 오마이뉴스는 세계 최초로 시민기자라는 사용자 참여에 의한 뉴스 미디어를 만든 경우지요. Skype는 사용자들의 PC들이 참여하여 만든 전세계적인 P2P 네트워크 위에서 전화가 되도록 만든 "User-Generated Network"입니다. 또한 FON은 사용자들이 자신이 가진 유선 가입자망에 무선공유기를 연결하고 이를 공유함으로써 공짜로 무선랜을 사용할 수 있는 인프라를 제공하고 있습니다. 또한 R&D를 불특정 다수에게 아웃소싱하는 Crowdsourcing이 시도되고 있습니다.
사용자 삽입 이미지
Innocentive는 아예 Crowdsourcing을 중재하는 사업을 합니다. 이와 같이 "참여"는 이미 웹을 넘어서 사회전반에 퍼져있는 사회현상입니다. 하지만 아직도 참여를 적용해 볼 수 있는 미개척지가 무수히 많습니다. 그리고 어떤 방식으로 참여를 적용할까 고민할 때 이번 수업시간에 배운 내용이 도움이 될 것입니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선



블로그 이미지

모든 기술과 서비스가 웹과 컨버전스를 이루는 미래를 향해...

Calendar

«   2012/02   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

Site Stats

Total hits:
294186
Today:
26
Yesterday:
44