abulaphiaa

Keep Yourself Social

Archive for the ‘Cloud’ Category

클라우드에 대한 이해

with 3 comments

우리는 일상적인 환경에서 어떤 용어를 사용할 때 그것의 의미를 상대방도 동일하게 받아 들일 것이라고 가정하는 경향이 있습니다. 그러나 그 의미가 정확하지 않아 나중에 서로 확인하는 경우도 많은데, 최근에 많이 사용되는 “클라우드”라는 용어가 대표적인 것 같습니다. 예를 들어, 트위터에 “클라우드 전문가”  채용공고가 올라왔을 때나 우리 회사의 미래가 “클라우드”에 있다고 말할 때, 이것이  uClould나 SkyDrive와 같은 대용량 파일관리 시스템을 의미하는지, 아마존의 AWS와 같이 소프트웨어 개발자가 직접 프로그래밍을 통해 서버 인스턴스, 네트워크, 스토릿지 등의 자원을 즉각 할당받을 수 있는 IaaS를 의미하는지, 또는 Netflix와 같이 서버에 저장된 디지털 컨텐츠를 N-Screen으로 불러올 수 있다는 의미로 사용하는지 명확하지 않을 때가 많습니다.

더군다나 최근에는 “클라우드”라는 용어가 “인터넷”을 대체하는 용어로 많이 사용되면서 더욱 혼란스러워 진 것 같습니다. 얼마전까지 많은 사람들은 “사진이나 동영상을 인터넷(또는 웹 또는 서버)에 올렸다“고 표현했는데 지금은  “클라우드에 저장했다“는 표현도 많이 사용합니다. 이는 유저 입장에서 볼 때 인터넷과 동의어로 사용되고 있을 정도로 클라우드가 트렌디한 단어가 되었다는 것을 의미합니다. 넓은 의미에서 보면 인터넷을 통해 자신의 서비스를 제공하는 모든 사업자들을 cloud company라고 부를 수도 있을 것 같습니다.

이 글에서는 다양한 의미로 사용하는 “클라우드의 개념”을 여러가지 Article을 참고해서 번역하고 정리해 보았으니 더 정확한 이해를 원하시는 분들은 이 글을 쓰면서 참고로 한 아래 영문 Article들을 직접 읽어 보시기 바랍니다.

It Just Works (TechCrunch, 2011년 6월 8일)

Who’s Driving the Real Cloud Revolution ? It’s the Consumers, Stupid (Venture Beat, 2011년 11월 29일)  

Clound 101 : What the Heck Do IaaS, PaaS And SaaS Companies Do ?  (Venture Beat, 2011년 11월 4일)

Top 10 Consumer Web Products  of 2011 (ReadWriteWeb, 2011년 11월 29일) 

Jeff Bezos Owns the Web In More Ways Than You Think (Wired, 2011년 11월 13일)

Say Hello To Window Azure, The World’s Most Misunderstood Cloud (Wired, 2012년 4월 27일)

The Rise of Mobile Cloud Services : BaaS Start Ups Grow Up (ReadWriteWeb, 2012년 4월 17일)

BaaS : The Mobile Backend Is Now A Service (apigee, 2012년 7월 2일) 

1. 클라우드의 등장배경

National Institute of Standards and Technology에 따르면, “클라우드 컴퓨팅이란 공유된 컴퓨팅 자원(네트워크, 서버, 스토릿지 등)에 언제 어디서나 필요할 때마다 접근해서 최소한의 관리 노력으로 또는 시스템운영자와 굳이 인터액션을 하지 않더라도 신속하게 이것을 상용서비스에 투입할 수 있는 모델“이라고 정의하고 있다.

  • Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

이것은 실제로 정확한 정의이긴 하지만 여기에서 혁명적이거나 새로운 것은 무엇일까 ? 이러한 정의에 따르면 클라우드는 혁명이라기 보다는 진화에 가깝다. 이것은 상업적인 인터넷 시대가 개막된 90년대부터 개시된 일련의 변화의 연속이긴 하지만 그것의 뿌리는 훨씬 더 과거로 거슬러 올라간다.

네트워크를 통해 접속 가능한 최초의 클라우드 컴퓨팅 리소스가 온라인에 나타난 것은 American Airline이 60년대 초반 SABRE를 런칭했던 50년 전의 일이다. 

80년대에 BBS와 미니텔은 네트워크를 통해 사용할 수 있는 어플리케이션으로 가득차 있었다. 이 당시 주도적인 어플리케이션은 옐로우 페이지 (검색),  여행예약, order input systems, 그리고 online dating이었다.

1) Software As A Service의 등장 : 90년대말 모든 온라인 서비스는 낮은 비용으로 보다 많은 고객들에게 서비스가 가능한 인터넷으로 전환되었다. 인터넷에 대한 기업의 신뢰성과 의존성이 증대되자 소프트웨어를 기업에 임대해 준다는 개념으로 Software-As-Service가 등장했다. 몇몇 혁신적인 소프트웨어 벤더들은 인터넷이 기업에서 안심하고 사용할 수 있을 정도로 신뢰성이 좋아졌다는 것을 깨달았다. 우리는 BBS 시대부터 주문 처리 시스템(order input system)을 근본적으로 발전시켜 왔던 Salesforce.com의 성공에 대해 잘 알고 있다.

2) Infrastructure As A Service의 등장 : 10년 후 bandwidth의 희소성이 해소되고 유저들은 다양한 단말을 통해 언제 어디에서나 인터넷에 접속할 수 있게 되자 아마존과 같은 혁신적인 벤더들은 S/W뿐만 아니라 컴퓨팅 인프라 자체를 서비스로 제공할 수 있다는 것을 깨달았다. 이렇게 해서 클라우드가 탄생했지만, AWS에서 인스턴스를 제공한다는 것이나 30년전 BBS에서 원격지에 있는 컴퓨터를 사용했던 것 사이에는 큰 차이점이 없었다.

그럼에도 불구하고 혁명은 일어나고 있고 이제는 모든 곳으로 번지고 있다. 그것은 바로 IT의 소비재화 (the consumerization of IT)이다.

3) IT Consumerization에 의한 인프라스트럭쳐의 변경

2000년대 초반까지 약 10년간 IT의 혁신은 주로 기업, 정부, 군대의 주도하에 이루어졌다. 그러나 클라우드 웨이브와 함께 혁신이 일어나는 장소도 변화했다. 오늘날 IT에서 혁신의 바람을 일으키는 추진력은 바로 소비자이다. 

인터넷을 통해 대규모 가입자들에게 안정적으로 서비스를 제공할려면 골치가 아프다. 상황이나 단말, 타임존, 언어 등에 상관없이 서비스는 모든 사람에게 항상 제공되어야만 한다. 이렇게 거대한 인구를 대상으로 서비스를 제공할려면 안정적인 유지보수가 절대로 필요했다. 심야 시간이나 크리스마스 이브에도 누군가는 당신의 서비스를 사용할 것이기 때문에 당신은 일주일 내내 24시간 ubiquitous하고 매우 신뢰성이 높은 컴퓨팅 환경을 1 페니를 받고 팔거나 광고로 돈을 벌 수 있을 정도로 싸게 제공해야 했다.

결과적으로 대규모 가입자들에게 안정적으로 서비스를 제공하기 위해 수많은 서버들을 분산처리하는 아키텍쳐가 탄생했다  : 2000년대 중반 아마존과 구글, 페북같은 회사는 모든 사람에게 24시간 신뢰할 수 있는 컴퓨팅 서비스를 인터넷을 통해 제공해야 했다. 그들은 특정 컴포넌트에 장애가 발생하거나, 그것을 업그레이드 하거나 개별적으로 변경한다 하더라도 전체 시스템에 아무런 물리적인 충격을 주지 않도록 서버들을 분산된 아케텍쳐로 처리했다. 이것이 바로 클라우드 웨이브의 기초이다 (This approach is now the foundation for the cloud wave).

Jeff Bezos의 Wired인터뷰 (2011년 11월 13일, Wired)

  • 우리 어플리케이션 엔지니어들은 자신의 일을 하기 위해 네트워킹 인프라스트럭쳐 엔지니어들과 매일 세세한 부분에 대해 의견을 나누어야만 했다. 우리는 지난 9년간 이것때문에 내부적으로 많은 시간을 낭비했다. 모든 디테일에 대해 세부적으로 의견을 조율하는 대신에 우리는 데이타센터 엔지니어들이 믿을만한 툴들의 셋트, 즉  앱 엔지니어들이 신뢰를 바탕으로 그 위에 프로덕트들을 쉽게 개발할 수 있는 인프라스트럭쳐를 제공해 주기를 원했다. 문제는 명확했다. 우리는 그러한 인프라스트럭쳐를 가지고 있지 않았다. 그래서 우리는 우리 내부에서 사용할 목적으로 이러한 인프라스트럭쳐를 만들기 시작했다. 그러고 나서 우리는 “웹 스케일 어플리케이션을 개발하고 싶은 사람은 누구든지 이것을 필요로 할 것 (Whoa, everybody who wants to build web-scale applications is going to need this)”이라는 점을 깨달았다.

구글과 페이스북도 유사한 테크놀로지를 구축해야만 했다. 그들은 다른 경로를 통해 여기에 도달했다. 구글은 수많은 어플리케이션을 동력화하기 위해 모든 것을 인-하우스로 개발해 왔는데, 그렇게 만들어진 것의 결과물을 화이트페이퍼로 공개했다 (notably MapReduce, which is the foundation to Hadoop). 페이스북 또한 자신의 인프라스트럭쳐에 관한 많은 작업을 통해 카산드라나 OpenCompute.org 등 오픈소스 커뮤니티에 공개했다 (Facebook contributed much of its infrastructure work to the open-source community).

이러한 인프라스트럭쳐로 인해 소프트웨어 개발은 혁명적으로 변화되었다. 오늘날 개발자들은 인프라스트럭쳐가 너무 비싸고 느리기 때문에 방해요소로 생각하기 보다는 컴퓨팅 파워, 네트워크 자원, 스토릿지 용량을 정확히 필요한 만큼만 사용할 수 있도록 인프라스트럭쳐를 프로그램할 수 있게 되었다.

4) 새로운 종류의 개발자가 등장하다

오늘날의 개발자들은 20년 전과 전혀 다른 언어와 패러다임을 사용한다. 그들은 어플리케이션에서 원하는 것에만 초점을 맞추는 방식으로 개발에 접근한다. 그들은 더이상 하드웨어를 관리할 필요가 없다.

이러한 어플리케이션들은 전형적으로 “웹서비스” 타입의 소프트웨어 아키텍쳐를 활용하는데, 이렇게 하면 어플리케이션들을 서로 연결시키는 것이 극단적으로 쉬워진다. 트위터 피드를 페이스북이나 링크드인에 동시에 보여주는 것이 얼마나 쉬운지, 페이스북 크레덴셜을 사용하여 다른 사이트에 얼마나 쉽게 로그인할 수 있는지 보라. 이것은 바로 웹서비스 아키텍쳐로 인해 가능해 졌다.

게다가 인프라스트럭쳐를 직접 프로그래밍할 수 있게 됨에 따라 개발자들은 인프라스트럭쳐 자체도 또 하나의 서비스처럼 다룰 수 있게 되었다. 오늘날 어플리케이션은 아무런 수작업이 전혀 없어도 (all without any manual intervention) 필요한 경우 1천대의 서버에 동시에 리퀘스트를 날린 후, 바로  이 천대의 서버를 회수하여 다른 태스크 용도로 활용할 수 있다. 이것이 바로 클라우드이다 (Furthermore, since the infrastructure is programmable, these developers can treat the infrastructure itself as just another service. Now, an application can request 1,000 servers but only for the time it needs to get your result, and then free up these 1,000 servers for some other task, all without any manual intervention. That’s the cloud!)

사실 클라우드에 대한 NIST의 정의에서 “최소한의 관리 노력 또는 서비스 제공자의 개입이 없이도“라는 개념은 많이 과소평가되어 있다. 만약에 어플리케이션이 높은 인기를 끌어 더 많은 자원이 필요하게 되면, IaaS로부터 간단히 이것을 요청하기만 하면 된다. 바로 이러한 이유 때문에 아마존의 웹서비스가 스타트업들로부터 인기를 끌고 있는 것이다. 오늘날 개발자들은 인프라스트럭쳐와 Operation을 그들의 소프트웨어 개발의 일부로서 프로그램할 수 있게 되었다. 바로 이런 이유로 과거에는 완전히 다른 스킬 셋으로 구분되었던 소프트웨어 개발과 IT Operation이 명백하게 하나로 통합된다는 의미에서 “devops”라는 새로운 용어까지 생기게 되었다(Now developers can program the infrastructure and operations as part of their software development. That’s led to a new term, “devops,” that makes explicit the merger of what used to be completely different skill sets, software development and IT operations).

이런 스타일로 개발할 수 있게 됨에 따라 Functionality와 Capacity 측면에서 모두 보다 재미있고, 보다 사용하기 쉬우며, 보다 확장성이 좋은 (more fun, easier to use, more practical, and more reliably scalable) 어플리케이션이 탄생하게 되었다. 이 모든 것으로 인해 개발 과정의 생산성은 더 좋아졌다.

늙은이들은 젊은이들의 이런 방식의 개발을 별로 좋아하지 않는다. 그러나  Facebook, SmugMug 또는 Dropbox 등 이런 방식으로 개발된 어플리케이션의 성공과 안정성으로 판단해 본다면, 향후 10년내에 이러한 스타일의 개발이 기업내에서 표준이 될 것이라고 생각한다.

하드웨어 측면에서도 소비자 테크놀로지에 의해 혁신이 추동되고 있다. 실리콘 기반 (반도체) 부품의 생산 비용은 R&D와 Fab 구축 비용까지 포함해서 대부분 자본비용이다. 이리하여 실리콘 기반의 부품 생산비용은 판매량에 반비례하는 결과가 나오게 된다.  바로 이러한 이유 때문에 원래 디지털 카메라, 스마트폰, USB Key 등에 사용되었던 SSD(Solid State Drivers)가 특정 비즈니스 어플리케이션 용도로 사용되었던 하드디스크와 경합할 정도로 비용이 하락하게 되었다. 수십억개의 SSD가 매스 마켓에서 팔리지 않았다면 오늘날 스타트업이 스토릿지의 대안으로 SSD를 고려할 수는 없었을 것이다.

5) 직원들이 컨트롤하는 세상

마지막으로 컨수머 테크놀로지가 혁신을 일으키는 또 다른 방식에 대해 살펴보자. 비교적 최근까지도 직원들은 IT 부서가 공급한 것으로 일을 해야만 했다. 그들은 때때로 어플리케이션이 느리다거나 프로세스가 실용적이지 않다는 불만을 제기하지만 결국은 그들에게 주어진 툴을 사용하는 수밖에 없었다.

그러나 오늘날 많은 어플리케이션과 비즈니스 프로세스가 웹을 통해 쉽게 사용할 수 있게 됨에 따라 기업내 솔루션의 사용패턴에도 변화가 발생하고 있다. 대용량 첨부파일을 이메일로 전송할려다가 기업용 메일박스에서 수없이 거절당하자 IT 관리자가 차라리 Gmail을 사용하라고 추천하는 형편이다. 실제로도 직급이 올라갈 수록 비밀이 유지되어야만 하는 문서일수록 이런 일은 더 자주 발생하게 된다.

이제 테이블이 뒤집어 지고 있다. 직원들은 집에서도 IT를 잘 이용하는 뛰어난 유저들이다. iPad, Kindle, 안드로이드 스마트폰, 페이스북이나 넷플릭스와 같은 웹사이트, Xfinity나 Skype 또는 Evernote와 같은 애플리케이션들은 그들의 일상생활의 일부로 잡리 잡았다. 사람들은 같은 음악을 집에서, 차안에서 또는 휴가처에서도 들을 수 있다.  Xfinity로 그들은 iPad에서 영화를 선택하고 HDTV에서 그것을 실행시킬 수 있다. 그들은 버튼 한번만 누르면 모든 친구들, 또는 그중 일부와 지난 파티에 관한 사진과 비디오를 공유할 수 있게 되었다.

그리고 스마트폰으로 ERP 시스템에서 제품을 구매하는 것이 직장에서는 불가능하다는 것을 깨닫는다. 그들이 집에서 누리는 놀라운 테크놀로지와 직장에서 일하는 후진 테크놀로지간 갭이 커질 수록 직원들은 참아 내기가 어려워진다. 바로 이와 같은 참을 수 없는 상황으로 인해 혁명이 발생한다 (Intolerable situations cause revolutions).

IT의 소비화가 클라우드의 바람을 일으키면서 실질적인 혁명을 촉발시키고 있다. 실제 토론의 논점은 Public이냐 Private이냐가 아니다. 기업 IT가 직면한 진짜 도전은 이러한 혁명을 어떻게 끌어 안느냐 하는 것이다. 기업들은 수많은 웹 프로세스와 일반적인 서버로 사용하기 편리하게 만들어진 IT를 통해 더 좋은 어플리케이션, 더 좋은 functionality, 더 재빠르고 더 신뢰성이 높은 서비스를 대규모 철제 박스들에 투입되는 일부의 비용으로도 전달할 수 있다는 것을 받아 들어야만 한다.

별로 직관적인 이야기는 아니지만 이것이 바로 현실이다. 이것이 바로 클라우드가 무엇이냐에 관한 답이다.

이렇게 해서 IT 혁명의 한축을 형성하고 있는 클라우드 서비스에 어떤 종류가 있는지 이제부터 보다 자세하게 살펴 보자.

2. 클라우드의 종류

Sean Ludwig는 VentureBeat에서 이와 같은 “클라우드”의 개념을 레이어에 따라 아래 그림과 같이 IaaS, PaaS, SaaS 등 3가지 카테고리로 분류해서 정의하고 있는데 이 글에서는 최근 등장하고 있는 BaaS (Backend As A Service)까지 포함해서 알아보겠습니다.

레이어에 따른 클라우드의 분류

제공 레이어에 따른 클라우드의 분류

1)   Software As Service

우리가 일상생활에서 웹브라우저를 통해 거의 항상 접근할 수 있는 Application의 상당 부분이  SaaS에 해당한다.  원격 서버에 호스팅되어 있고 인터넷을 통해 접근할 수 있는 거의 모든 어플리케이션은 SaaS의 범주에 속한다고 할 수 있다. 

그러나 클라우드와 관련하여 PC, 스마트폰, 태블릿, Connected TV 등 다양한 단말에서 언제 어디서나 인터넷에 접속할 수 있는 환경이 만들어짐에 따라 다양한 형태의 파일과 User Data를 클라우드에 저장하고 여러가지 단말에서 이 데이타를 싱크해서 사용하는 “클라우드 어플리케이션”들에 관해 살펴 보면 대충 다음과 같은 카테고리가 존재하는 것 같다.

  • Sync과 Backup 전용의 파일관리자 (또는 Hard Disk In the Sky) : DropBox, SugarSync, MS SkyDrive, uCloud, Google Drive 처럼 기존 탐색기와 같은 User Interface를 활용하여 특정 유무선 단말에서 유저가 생성한 모든 형태 파일 및 폴더를 클라우드와 싱크시켜서 다른 단말에서 접근할 수 있도록 하는 서비스들이 존재한다.  이것은 기능적인 관점에서 보았을 때 2000년대 중후반까지 우리나라에서 불법 컨텐츠 공유의 온상이 되었던 웹하드 개념의 다양한 P2P 형 어플리케이션들에 싱크와 백업 개념이 추가되고,  PC뿐만 아니라 모바일과 Tablet 등 다양한 유무선 단말에 적용된 것이라고 할 수 있다.  전세계 최강의 초고속 인프라의 보급을 바탕으로 요즘 말하는 “클라우드” 맹아적인 형태로서 다른 나라에 비해 상대적으로 일찍부터 보급되었던 토착의 웹하드 서비스들이 지금은 거의 존재감이 없어졌다는 점은 안타깝다. 미래를 내다보고 좀더 적극적으로 우리나라의 웹하드 서비스들을 업그레이드했다면 지금 세계를 주름잡는 DropBox보다 훨씬 더 앞선 서비스를 만들 수도 있지 않았을까 ?
  • žContent-Shifting : Evernote나 Instapaper와 같이 상황에 따라 생각나는 아이디어나 경험, 또는 웹페이지 URL을 App.에 기록해 두었다 나중에 다른 단말에서 접속해서 다시 읽기 위한 목적으로 유저가 직접 생성한 컨텐트 (텍스트 파일, 포토, 음성 녹음 파일, URL 등)를 클라우드에 저장하고 싱크시키는 류의 서비스도 큰 인기를 끌고 있다. 웹과 모바일, 태블릿 버전 등 다양한 단말에서 서비스를 제공하는 많은  App.들이 User Data를 클라이언트에 캐슁해 놓고 있기 때문에 오프라인 상태에서도 데이터를 읽을 수 있으며 온라인시 서버에서 추가로 갱신된 데이타를 상호 싱크하는 방식으로 제공하고 있다.  Evernote와 Instapaer는 나중에 읽을 목적으로 웹컨텐츠를 클라우드에 저장하고 블로그와 유사한 User Interface를 통해 다양한 단말에서 싱크시켜 사용한다는 점에서 첫번째 범주의 “파일관리자” 형태의 어플리케이션과는 차이가 있다.
  • žPlatform Level의 자동 싱크 :  iCloud와 같이 특정 어플리케이션에 국한되지 않고 플랫폼 레벨에서 다양한 어플리케이션 데이타를 유저가 인지하지도 못한 상태에서 자동으로 싱크해 줌으로써 어떤 단말에서든지 동일한 데이타에 편리하게 접근할 수 있는 서비스도 있다. iCloud는 하나의 Application이라기 보다는 모든 iOS단말에 존재하는 주소록, 사진, 음악, 동영상 등 다양한 OEM Application Data들을 백그라운드에서 상호 연결시키는 일종의 클라우드 백본이라는 점에서 U/I가 별도로 존재하는 위의 단일 어플리케이션과는 차이가 있다. 스티브 잡스가 DropBox의 인수의사를 타진하면서 “이것은 서비스가 아니라 플랫폼이다”라고 말했던 의미를 이해할 수 있을 것 같다.  이러한 관점에서 John Gruber는 iCloud가 PC의 카운터 파트로서 구름위에 존재하는 하드디스크가 아니라 클라우드에 존재하는 iTUNES라고 주장한 바 있다.
  • Purchased Item Stored In the Cloud For N Screen : 위와는 달리 Netflix나 Hoffin, Spotify, Kindle 등과 같이 음악, 책, Video 등의 유료 컨텐트를 유저가 어떤 단말의 App.에서 구입하면 관련 정보와 해당 컨텐트를 클라우드에 저장하고 있다가 유저가 다른 단말의 동일한 App.으로 접속할 때 동일한 컨텐트를 다운로드 또는 스트리밍하는 방식으로 접근할 수 있도록 하는 “N-Screen형” 서비스가 존재한다. Netflix는 아마존의 인프라스트럭쳐 클라우드를 기반으로 동작하는 SaaS인 셈이다.

    아마존 책 구매경로

2)    IT Infra로서의 클라우드 컴퓨팅 (IaaS)

우리가 클라우드라는 말을 쓸 때 아마존의 AWS, VMWare, RackSpace 등과 같이 Infrstructure-As-A-Service를 의미할 때가 많다.

Amazon Web Service처럼 하드웨어 인프라, 미들웨어, 어플리케이션 등 개발자들이 App. 개발 및 운영에 필요한 자원과 툴을 제공하는 B2B형 클라우드 서비스가 있다. AWS는 App. 개발자들이 굳이 networks, servers, storage, applications, services 등의 하드웨어 인프라를 자체적으로 구축하지 않고 (과거에는 데이터센터와 하드웨어, 네트워크 인프라를 전담하는 IT Administrator가 별도로 존재했다) Application에서 필요한 기능만 집중하고, 나중에 가입자가 늘어나거나 트래픽이 증가할 때 필요한 만큼의 자원을 앱개발자가 간단한 툴로 직접 할당해서 사용할 수 있다. 물론 클라우드의 컴퓨팅 자원을 쓴 만큼 돈을 내기 때문에 합리적이다.

아래 그림을 보면 AWS를 사용하는 Application 중에는 FourSquare, Netflix, Yelp 등 우리도 알고 있는 Application들이 많이 있다는 것을 알 수 있다.

AWS 기반의 어플리케이션들

AWS 기반의 어플리케이션들

IDC와의 차이 : 우리나라에서도 Server와 Network를 임대해 주는 IDC 사업자들이 존재하나, 결정적으로 다른 점은 1) 공간과 하드웨어 및 네트워크 인프라만을 임대해 주는 것이 아니라 EC2와 같은 컴퓨팅 자원, , 아마존 dynamoDB나 RDB와 같은 데이터베이스, S3나 EBS와 같은 스토릿지, CDN 등 아마존이 자체적으로 개발한 다양한 솔루션도 함께 제공할 뿐만 아니라 2) App. 개발자가 Infrastructure 자체를 어플리케이션처럼  프로그래밍해서 필요로 하는 컴퓨팅 자원을 클라우드로부터 동적으로 할당받아 사용할 수 있다는 점이다.

3)    Platform As A Service

MS Azure와 Google App Engine 등은 최근 IaaS, 그 이상을 제공하기 때문에 PaaS로 알려지고 있다.

PaaS가 IaaS와 다른 점은 미들웨어까지 제공한다는 점이다. 모든 개발작업이 미들웨어 레이어 위에서 이루어지기 때문에 시간과 리소스를 절약할 수 있다.

PaaS 회사들은 Virtualized Server, OS, 협업환경, Web Application Management, Application Design, App Hosting 등 인터넷을 통해 어플리케이션을 개발하고 배치하는데 필요한 다양한 솔루션을 제공한다.

žGoogle App Engine, Microsoft Azure, Saleforce’s Force.com, the Salesforce-owned Heroku, and Engine Yard 등이 가장 규모가 큰 PaaS 제공자이다.

žPaaS로서 MS Azure 활용사례 : 호주 출신의 Jeremy Howard는 최근 실리콘 밸리로 이주하여 고급인력에 대한 온라인 마켓플레이스인 Kaggle을 1년 전에 AWS에서  .Net 기반으로 운영되는 MS의 Azure로 이전했다.  그는 Kaggle이 MS의 .Net 플랫폼과 C# 프로그래밍 언어와 딱 맞아 떨어졌기 때문에 이러한 결정을 내린 것이었지만 실리콘밸리의 스타트업들은 Amazon EC2에서 MS Azure로 플랫폼을 이전한 결정에 대해 멀 잘 모르고 내린 결정이라는 비아냥을 들었다. 실리콘밸리에서 스타트업들은 AWS위에  Ruby on Rails, Python 같은 언어를 사용하거나 좀 지루하긴 하지만 Java를 전형적으로 사용한다. 사실 MS Azure는 AWS, Texas의 Rackspace, Salesforce의 Heroku에 비하면 개발자들의 대화에 끼지도 못하는 처지이다. 왜냐하면 그들은 MS를 클라우드 컴퍼니로 간주하지 않기 때문이다. 그러나 알고 보면 MS Azure 또한  Node.js와 Hadoop과 같은 오픈소스 소프트웨어를 수용하고 있을뿐만 아니라, .NET과 C#이외에도 Java, Ruby, PHP, Python과 같은 개발툴도 지원한지 오래이다.  Movideo는 최근 GoGrid라는 IaaS에서 사용하던 Java를 그대로 사용하여 Azure로 플랫폼을 변경했다.  Infrastructure Cloud인 AWS에서 개발자들은 어플리케이션을 운영하는 virtual server와 virtual infrastructure를 관리해야 한다. 그러나 Google App Engine과 같이 Azure는 Paltform Cloud로서 SQL Azure DB는 자동 스케일링과 오토백업을 지원하는 등 AWS보다 손이 덜가기 때문에 프로덕트에 더 집중할 수 있다. SQL Azure뿐만 아니라 MongoDB도 활용가능하며, Customization도 지원한다.

4)    Backend As A Service (RWW, 4월 17일)

ž최근에는 PaaS를 넘어서 어플리케이션의 구동에 필요한 모든 백엔드의 Server Function을 모듈화해서 제공하는 Backend As A Service까지 등장하고 있다 ( Backend as a Service” (BaaS) companies provide easily integrated cloud-based backends for mobile app developers).

žServer Function : Iaas든 PaaS든 네트워크, 하드웨어, Storage, DB 솔루션, OS 등 클라우드의 컴퓨팅 자원만을 필요한 만큼 임대해서 사용할 수 있긴 하지만, Application의 모든 Business Logic 자체는  App. 개발자가 직접 개발해야 한다.

그러나 최근에는 BrightCove나 Appcelerator처럼 개발자가 플랫폼에서 제공하는 JavaScript API를 호출해서 서비스 로직과 U/I를 클라이언트 Level에서 구현하기만 하면, User, Push Notification, Chat, Social Integration, Location 등 모듈화된 Server의 Function을 통으로 제공해 주는 BaaS Provider들이 탄생하고 있다.

테크놀로지 관점에서 볼 때 모바일 에코시스템의 성장으로 낡은 스택은 소멸했고 Object-C, Java, HTML5, Ruby, Node.js 등 최신 개발 스택이 등장하게 되었다. 사업적인 관점에서 볼 때 개발자들은 새롭게 등장하는 다양한 모바일 스택 위에서 app. 개발 방법을 배워야만 했는데 이것에 필요한 스킬을 따라잡기도 벅찬 상태에서 새롭게 등장하는 백엔드 시스템까지 새로 배워서 개발하기에는 더욱 어렵기 때문에 Appcellerator, Stackmob, YorAPI, BrightCove 등과 같은 Backend As A Service 플랫픔이 인기를 끌고 있다.

BaaS Provider에는  BaaS로서 보다 폭넓은 범위를 커버하는 사업자도 있지만 API만을 서비스로 제공하는 사업자,  Node.js나 SQLLite 플랫폼 등 보다 좁은 범위만을 제공하는 Niche 플레이어들도 존재한다.

예를 들어 StackMob은 아래와 같은 서버의 기능들을 제공하고 있다.

žYorAPI의 CEO는 BaaS가 제공해야할 Top Function에 대해 아래와 같이 열거하고 있다.

  • User profiles with social login support for Facebook and Twitter
  • Custom data objects and storage
  • Analytics and metrics
  • Push notification support
  • Rich location data (Ling did not mention this specifically)

자칭 API Best Practice Blog인 “apigee” 의 최근 글 “BaaS : The Mobile Backend Is Now A Service” 에서는 최근 모바일 개발자들이 요구하는 BaaS의 기능을 아래와 같이 정의하고 있다.

The Backend Features of BaaS Provider

The Backend Features of BaaS Provider

BaaS에는 Visual 요소만 디자인하면 코딩을 전혀 할 줄 모르는 사람들도 쉽게 게임을 개발할 수 있는 Game Creation Platform도 존재한다. 게임샐러드는 코딩이 필요없는 게임 Creation 플랫폼으로서 디쥬얼 디자인만 하면 iOS, 안드로이드, HTML5 등 게임 앺을 자동으로 만들어 준다. 전세계 30만명의 개발자들이 활용하고 있으며, 6만개의 게임 App.이 출시되었으며 그중 1만개는 iOS App.이다. 미국 App. Store에서 이중 60개가 Top 100에 랭크되었다.

BaaS의 Business Model은 API를 호출하는 횟수에 따라서 개발사들로부터 돈을 받는 것이다.  Appcellerator의 경우 특정 Function별로 한달에 25만번까지는 무료로 호출할 수 있으나, 호출건수 100만번 단위로 $8 ~$10를 과금한다.

žFacebook이나 Twitter 또한 OAuth 인증체계를 통한 회원가입, User Profile 정보, Social Graph, Like나 Comment API를 통한 Social Plugin, Open Graph API 등을 통해 웹 기반으로 App을 쉽게 개발할 수 있는 서버 Function들을 제공함으로써 자신의 코어 서비스에 다양한 3rd App.을 전략적으로 통합시키고 있다는 점에서 BaaS와 유사하다. 그러나 Facebook과 트위터는 대규모 가입자 기반 및 이것을 통해 획득한 소셜 리소스를 외부 개발자들에게 API형태로 제공함으로써 자신의 서비스를 더욱 전략적으로 확대시키는데 초점을 맞추고 있는 반면,  BaaS는 자체 서비스를 운영하지 않으면서 서버 자원에 Access할 수 있는 API만을 제공한다는 점이 다르다고 할 수 있다.

이와같이 클라우드 기반의 개발환경이 고도화됨에 따라 앞으로 10년 아니면 5년쯤 지나면 초등학생들도 컴퓨터로 문서 작업하듯이 모바일 어플리케이션을 개발하는 시대가 오지 않을까라는 기대를 하면서 긴 글을 마치고자 합니다.

Advertisements

Written by abulaphia

August 2, 2012 at 11:25 pm

Posted in Cloud

Tagged with , , , ,

ReadWriteWeb이 선정한 2011년 탑10 웹 프로덕트

with 2 comments

ReadWriteWeb에서 2011년 일반 유저들이 웹을 이용하는 방식에 대해 가장 큰 영향을 준 10대 제품을 아래와 같이 선정했습니다 (RWW,2011년 11월 29일). 가장 큰 특징은 Web과 Native의 구별이 점점 더 약화되고 있다는 점, 클라우드에 데이타를 저장해 놓고 싱크를 통해 여러 단말에서 접근할 수 있다는 점, 모바일과 태블릿을 통해 정보에 접근하는 유저들이 폭발적으로 증가하고 있다는 점, 인공지능을 활용한 Voice Interface가 등장하고 있다는 점 등입니다.

1. Chrome 브라우저

Chrome New Beta Version 2011년 9월 22일 By Google

Chrome New Beta Version 2011년 9월 22일 By Google

  • 크롬 점유율의 가파른 상승 : StatCounter의 6월 데이타에 따르면 올해 11월말 크롬의 전세계 브라우저 시장 점유율은 약 28%로 Firefox를 추월했을 것으로 추정됨
  • 크롬 웹스토어 Renovation : 웹에서 동작하는 소프트웨어라는 구글의 비전 (Google’s vision of software living on the Web)을 달성하기 위해 데스크탑에서 WebApp.의 중요성에 초점을 맞추어 웹스토어 개편
  • Web과 Native가 브라우저를 통해 융합 :  C, C++로 짠 네이티브 코드가 크롬 브라우저에서 동작할 수 있도록 지원 (blurring the line between Web and native applications)
  • Web Audio API : 단순한 사운드 파일을 백그라운드에서 실행시키는 것 보다 훨씬 정교한 오디오 효과를 구현할 수 있는 API 제공 (some examples of the kinds of cool effects)
  • TTS Engine API :  웹에서 사람의 목소리로 명령어를 내릴 수 있는 API를 제공 (이 API는 Google의 Native Client SDK for speech를 사용함)
  • 새로운 이미지 포맷 WebP를 통해 브라우저에서 이미지 로딩 속도를 개선 : 화질의 손상이 없이도 JPEG의 압축률보다 25 ~ 34% 개선, 가장 압축이 잘된 PNG 보다 28% 개선 (일반 웹에서 샘플링한 PNG 파일 대비 45% 개선)
  • WebApp. EchoSystem : 향후 크롬의 태블릿 버전이 출시되면 Google의 WebApp. 에코시스템이 모든 단말로 확장
Chrome WebStore

Chrome WebStore

2. Dropbox :  A Key Player in the Consumer Cloud

다양한 단말에서 웹에 접속할 수 있게 됨에 따라 파일 관리를 위한 클라우드 컴퓨팅 서비스의 필요성이 크게 증가되고 있다.  우리나라에서도 다양한 웹하드 솔루션이 있었으나 자동 “Back-Up”과 “Sync.” “3rd Party API” 등을 제공하는 클라우드 솔루션이 다수 등장하고 있으며 그 중 드랍박스가 군계일학

  • 대부분의 컴퓨터 유저들이 익숙해져 있는 메타포를 사용하여 소비자용 클라우드 시장의 핵심 플레이어로 부상
  • Onilne Backup, Sync & Share : 파일들을 백업해 주고 다양한 단말을 통해 싱크, 다른 사람들과 공동작업도 가능
  • Mobile 활용성 증대 : 유연성이 뛰어나기 때문에 특히 모바일용 백엔드 파일시스템으로 활용
  • 3rd Party Data 저장 : 안드로이드와 같이 Google Docs를 지원하지 않는 iOS 기반의 3rd Party Text App.들이 데이타 백업용으로 드랍박스를 사용중 (ex.아마존의 1password)
  • Daily Usage : RWW가 페이스북과 트위터에서 조사한 결과 많은 사람들이 하루에도 여러번 접속해서 사용, 컴퓨터에 있는 모든 폴더를 DropBox에 옮겨 놓고 사용하는 사람도 있고, 모든 중요한 문서를 기본적으로 드랍박스에 저장 (Default Directory for A Lot of Important Saves)해서 사용하는 사람들도 있다.
  • Business용으로도 사용 : 회사에서 타임존이 다르거나 지리적으로 먼 거리에 있는 사람들과 함께 협업할 때 파일 공유용으로도 사용한다 (we also use it at work to share common files : Collaborating on Docs across Timezones and Geographies, Regularly For Multiple Shared Projects).
  • Dropbox just works : 많은 사람들이 드랍박스를 좋아하는 이유는 다른 솔루션들이 많은 오류를 가지고 있어서 싱크할 때 짜증이 나는 반면 드랍박스는 사용하기 쉽고 잘 동작하기 때문. 아마존, 구글, MS 등 클라우드 컴퓨팅 자이언트들보다  앞서 나가고 있다 (Due to its Generally Frictionless Service and Excellent Usability)

3. iCloud : It Just Works

  • 2011년 10월 iOS 5 업데이트시 출시되었다.
  • Push Files Behind Scene : Dropbox보다 깊이있는 레벨에서 동작, 폴더 뿐만 백그라운드에서 파일을 다른 단말로 푸쉬해 주기 때문에 Mac이든 아이폰 또는 태블릿이든 단말별로 이동해서 App.을 열기만 하면 이전 단말에서 작업했던 동일한 파일이 존재한다.
  • Automatically Sync. & Backup Everything : 주소록, 이메일, 포토, 캘릭더, 음악, 영화, 문서, 심지어는 환경설정까지 모든 컨텐트가 다양한 단말로 자동 싱크되며, 모든 것이 온라인에 안전하게 백업된다.
  • Over-The-Air : 모바일 단말을 컴퓨터에 연결하지 않더라도 무선 네트워크를 통해 소프트웨어를 업데이트하거나 컨텐트를 싱크할 수 있다.
  • 제한점 : 자신의 데이타를 iCloud에 저장할 수 있는 3rd Party App.은  iA Writer 외에는 아직 존재하지 않지만 앞으로 그렇게 될 것이다. 또한 아직 다른 OS 기반의 단말, 즉 Cross-Platform은 지원하지 않는다.
  • Backbone of Apple’s Vision of Computing : “it’s-just-there syncing paradigm은 Apple의 컴퓨팅에 대한 비전을 구현하기 위한 백본이 될 것이다.  iCloud는 자체 U/I가 존재하는 독립적인 파일 싱크 어플리케이션이라기 보다는 Mac과 iOS 단말에서 동작하는 모든 Application들의 데이타를 클라우드와 싱크시키고 여러 단말에서 Seamless하게 사용 하기 위해 플랫폼 레벨에서 백그라운드로 조용하게 동작하며 – 유저가 굳이 PC에서 iTUNES를 실행시키고 모바일 단말을 USB로 연결하여 싱크시키지 않아도 되는 –  iTunes In the Cloud”이다.
  • iCloud에 대한 자세한 내용은 “At one point during the keynote, Jobs noted that some people think of the cloud as a hard disk in the sky where you put files in and then take them out. Many again just extend the idea of the cloud as a remote hard drive.  New iTunes moves the digital hub from the desktop computer to the cloud.” (TechCrunch, It just works”, 2011년 6월 8일)
iTunes In the Cloud

iTunes In the Cloud

4. Kindle :  Kindle is a service, not a product
  • 아마존 스토어에 최적화된 전용단말 : Apple에게 소프트웨어는 수익성 좋은 단말을 팔기 위한 서비스이지만, 아마존에게 킨들은 아마존 스토어에 접속하기 위한 윈도우이다 (Kindles are just windows into Amazon’s stores).
  • Kindle Fire : Amazon Prime Video Streaming, Cloud Drive (Amazon’s Cloud-Based Music Storage), Amazon Silk Browser (Cloud-Accelerated Web browser) 등 자세한 내용은 “아마존 킨들 파이어에 대한 Wired지의 비판적 리뷰“를 참고하세요.

5. Evernote : 다른 쟝르의 Clould

  • 2007년 창업하여 새로운 쟝르의 클라우드 서비스를 개척, 올해 3월말 기준 400만명의 User를 확보했다
  • iCloud, Dropbox와 차이점 : iClould는 주로 주소록, 포토, 캘린더, 음악 등 Apple의 전용 App. 데이타를 유저도 인지하지 못한 상태에서 자동으로 백그라운드에서 싱크해준다 (환경설정 외에 파일 탐색기나 싱크 버튼 같은 U/I도 존재하지 않는다).  이와 달리 Evernote는 Window, Mac, Android, iOS 등 대부분의 플랫폼을 지원한다. 또한 Dropbox처럼 유저가 생성한 모든 종류의 데이타 파일과 PC의 폴더구조까지 서버와 싱크시키기 보다는 해당 App.에서 유저가 직접 생성한 메모나 사진 등 작은 파일들의 싱크에 집중하고 있다.
  • Sync Little Files : 리치 텍스트 파일, 이미지, To-Do List, 음성녹음, Web URL 등 유저가 그때 그때 생각나는 것이나 경험한 것을 나중에 사용할 목적으로 의도적으로 생성한 작은 파일들을 클라우드에 저장해 놓고 다른 단말들과 싱크시킨다.
  • Web Clipping : PC에서 Evernote Website에 접속하여 “Web Clipper”라는 브라우저 Extention을 설치한 후 1) Article Clips, 방문한 웹사이트에서 이것을 한번만 클릭하면  전체 아티클을 자동으로 저장하고 2) Selection Clips, 유저가 텍스트, 이미지, 링크 등 해당 웹페이지에서 원하는 Object만을 마우스로 찍어서 별도로 저장할 수도 있으며,  Full Page 또는 특정 Link만을 저장할 수도 있다. Evernote Web 사이트에 로그인된 상태에서 일단 유저가 어떤 웹페이지에서 든지 무엇인가를 클립핑하면 Web Clipper가 백그라운드에서 자동으로 동작하면서 서버 및 다른 단말의 EverNote와 싱크되며 검색도 가능하다.  Evernote의 Web Clipping은 Instapaper의 ReadLater 기능을 카피한 것이다.
  • Optical Character Recognition : 광학 문자인식 기술을 활용하여 노트, 명함, 영수증 등을 카메라로 읽어서 텍스트를 캡쳐할 수 있다.
  • 테스트 결과 : 직접 PC에서 Web Clipper로 특정 웹 페이지를 저장해 놓은 후 모바일에서 접속해 보니 App.을 열때 해당 컨텐츠 리스트가 모바일 버전에 자동으로 싱크되어 내려오며, 리스트에서 보고 싶은 컨텐트 아이템을 선택하면 해당 웹페이지를 그대로 불러온다. 반대로 모바일에서 업로드한 사진이나 To-Do-리스트 등도 Evernote 웹사이트에서 볼 수 있다. Evenot Web U/I는 아웃룩이나 RSS P Client와 유사하다.
Evernote Contents Listing & Outlook Style Navigation

Evernote Contents Listing & Outlook Style Navigation

6. Spotify : Socialization of Music Listening Experience

  • Facebook의 Frictionless Sharing 효과 : Facebook의 Open Graph 플랫폼을 활용, Like를 클릭하고 음악을 듣기만 해도 Facebook 친구들과 자동으로 공유되는 서비스를 지난 9월 22일 F8 행사 이후 도입, 2주만에 Spotify Facebook App.의 월간 액티브 유저가 340만명에서 530만명으로 급증
  • 음악과 소셜의 결합 : Facebook을 통한 Soptify의 Frictionless Sharing으로 Social Network를 통해 음악이 자동으로 공유되는 새로운 모델을 제시했다. Google Music 또한 Google +의 “Activity Stream”에서 친구가 듣고 있는 음악을 그 자리에서 바로 Play할 수 있도록 지원할 것이다.
  • Spotify는 우리나라에서는 아직 서비스가 되지 않기 때문에 Facebook에서 실제로 어케 동작할지는 미루어 짐작할 수 있을 뿐이다.

7. Instapaper : Private Bookmarking For Read Later And Elsewhere On iPAD

  • iOS Reading App. Goldrush For Tablet : Flipboard, Zite, Editions (AOL), Livestand (Yahoo) 등 태블릿에 최적화된 “읽기” 경험을 제공하는 App.들이 경쟁적으로 출시되고 있는 가운데 Instapaper가 iOS 리딩 App. 중 상위권를 차지하고 있음
  • Cross Platform Content Shifting App.이라는 컨셉을 구현 : 다양한 소스를 통해 취득한 컨텐트를 랩탑, 모바일폰, 태블릿, TV 등 인터넷에 연결된 단말로 옮겨가면서 소비하고 싶어하는 현상 (The desire and (sometimes) the ability to shift content across a variety of Internet platforms to a variety of connected devices)을 의미한다. Instapaper는 유저가 현재 대충 읽고 있는 웹 페이지를 원클릭으로 저장해 놓았다가 나중에 웹, 태블릿, 스마트폰 등에서 좀 더 집중해서 읽을 수 있는 경험을 제공하고 있다.
  • Bridge the Web and iOS Worlds : Instapaper를 비롯한 Reading App.들은 Web와 iOS를 연결시켜 주는 다리 역할을 한다. 많은 사람들은 PC의 Web 브라우저보다는 iPAD에서 읽기 경험을 선호하기 때문에 인스타페이퍼는 “나중에 읽기”일뿐만 아니라 “다른 단말에서 읽기” 위한 것이다 (It’s not just “read later”, but “read elsewhere” – most people would prefer the reading experience on an iPad to a web browser on a PC).
  • Offline Reading :  네트워크가 끊겨 있는 상태에서도 자신이 북마크해 놓은 웹문서를 읽을 수 있지만, 정작 Instapaper의 창업자인 Marco Armento는 이에 대한 유저들의 Needs가 별도 크지 않다고 판단하고 있다.
  • Curation of Instatpapered Content : instapaper.com과 별도로 GiveMeSomethingToRead.com이라는 사이트를 운영하며 유저들이 인스타페이어퍼에서 북마크해 놓은 컨텐트를 인기순, 카테고리별로 Curation해서 제공한다 (Curated List of the Best Long-Form Nonfiction Writing and Reporting).
  • From Friends : 4.0 iPAD 버전에서 전체적인 인터페이스가 매거진 스타일로 변경되고, 인스타페이퍼의 유저가 아니더라도 Facebook이나 Twitter에서 친구들이 업로드하거나 Like한 컨텐츠 리스트를 보여주는 기능이 추가됨에 따라 Flipboard와 조금 더 유사해 졌다.
  • Evernote의 WebClipping과도 유사 : Instapaper에서 로그인된 상태에서 뉴스나 블로그를 읽다가 Like나 Tweet과 같이 “I” 버튼을 클릭하면 Instatpaper URL 등록창이 Outlink되어 별도 페이지로 실행된다. 이 페이지에서 저장하기 버튼을 누른 후 iPAD나 iPhone의 Instapaper App.을 실행하면 내가 다른 단말에서 저장한 웹 URL 리스트가 제목과 함께 출력된다는 점에서 Evernote처럼 단말간 싱크를 지원한다고 할 수 있다. 그러나 거창하게 싱크라기 보다는 어떤 단말에서든 컨텐츠를 추가하면 일단 서버에 저장되며, 다른 단말에서 Instapaper에 로그인할 때 새로이 추가된 컨텐트가 뺑뺑이 돌면서 자동으로 업데이트된다. 그러나 아직까지는 Like나 Tweet 처럼 Instatpaper의 API를 지원하는 사이트가 많지 않아 수동으로 URL과 제목을 Copy해서 등록해야 하는 불편함도 존재한다 (웹에서 관심있는 컨텐트를 발견한 후 공유를 위해서 라기 보다는 내용을 간단히 정리해서 기억할 목적으로 트위터를 사용하는 사람들 입장에서 볼 때 혼자 쓰는 트위터와 같은 느낌을 받을 수도 있다).
Instapaper Web, Bookmark List For Read Later In A Twitter's Timeline Style

Instapaper Web, Bookmark Web Content List For Read Later In A Twitter’s Timeline Style

8. Flipboard : Personalized Social Magazine

  • Flipboard CEO Mike McCue : 태블릿으로 인해 컨텐트를 소비하는 완전히 새로운 경험이 만들어지고 있다 (The tablet is creating a totally new kind of content consumption experience).
  • 올해 10월말 기준 다운로드수 : 18개월간 3,500만대의 iPAD가 보급되었다. 14개월간 플립보드의 다운로도 건수는 14개월만에 350만
  • Personalized Social Megazine : iPAD에서 낡은 미디어인 잡지 구독 경험을 Emulation해서 제공하는 iPAD 전용 App.으로서 Facebook이나 Twitter에서 친구들이 URL 형식으로 포스팅한 컨텐트뿐만 아니라 다양한 미디어 사이트들로부터 RSS 형태로 컨텐트를 수집해서 보여준다.
  • Megazine Style Feed Reader With Nice Interface : SNS Feed를 통해 많은 정보를 수집함에 따라 사장된 기술이라고 생각되었던 RSS 기술이 iPAD에서 플립보드를 통해 잡지같은 U/I로 부활했다.
  • User 계정 생성을 통한 Personalization : 지금까지는 별도의 회원가입 절차 없이 Facebook이나 Twitter 계정을 연동해서 사용했으나  11월 업데이트시 User의 계정을 생성하는 기능이 추가되었다. 이는 플립보드 유저들간 공유뿐만 아니라 다양한 단말에서 컨텐트를 싱크시켜서 사용할 수 있도록 하기 위한 것으로 풀이되며 조만간 iPhone 버전이 출시될 것으로 전망된다.
  • 단말에 따른 User Experience 최적화 : 다른 뉴스 사이트는 제외하고 Facebook이나 Twitter 사용자 입장에서 볼 때, 플립보드는 친구들이 업데이트한 모든 컨텐트가 태블릿에서 읽기에 최적화된 잡지형식으로 보여진다는 점에서 Social Network의 User Interface가 태블릿에서는 PC나 스마트폰과는 전혀 다른 방식으로 경험될 수 있다는 것을 말해 주는 대표적인 사례라고 할 수 있다.
Megazine Style Reading Experience On Flipboard

Megazine Style Reading Experience On Flipboard

9. Google Maps : The Best Way To Navigate the World with the Web

  • Layered Contents : 지도 위에 사진뿐만 아니라 실시간 교통정보, 몇십분 전에 웹캠으로 올린 짧은 비디오, 높낮이, 지하철 노선도 등이 표시되며 올해에는 데스크탑 버전에 날씨 레이어까지 추가되었다. 3rd Party 개발자들도 API를 활용하여 구글 지도 위에 App.을 개발할 수 있다.
  • Multiple Viewing Mode : 아이나비와 같이 3D로 여행전 출발지에서 목적지까지 경로를 비디오 플레이하듯이 볼 수 있으며(3D route views),  WebGL 기술을 활용하여 하늘에서 45도 각도로 큰 건물을 내려다 볼 수도 있고 3D로 실제 거리 모습을 회전해 가면서 볼 수 있다 (3D Street View). 그리고 위성사진 모드로 변경해서 지도를 볼 수도 있다. 올해 추가된  3D Route View나 Street View는 데스크탑의 그래픽 카드가 WebGL을 지원하지 않을 경우 보이지 않는다.
  • Voice-Powered Search : 데스크탑에서 음성으로 장소를 검색할 수 있다.
  • Local & Social : Google+와 연동되어 Activity Stream에서 바로 친구들과 장소를 공유할 수 있다. 또한 “My Place” Tab을 클릭하면 Google Place에서 유저가 Rating을 매긴 장소를 하일라이트 처리해서 보여 주며, 유저가 공유한 데이타에 기초하여 Google이 추천하는 장소도 바로 표시해 준다. 지난 6월에는 유저가 구글 플레이스에서 레스토랑과 비즈니스들을 검색하면 결과페이지나 지도 위에 링크형태로 보여 주었던 Yelp나  TripAdvisor와 같은 3rd Party의 리뷰를 제거하고 구글 플레이스에서 추천하는 장소를 바로 보여주는 방식으로 변경했다. 이에 따라Yelp는 상원청문회에서 로칼 비즈니스에 대한 구글의 관행이 반경쟁적이라고 증언한 바 있다 (Testified Before the Senate).
  • Crowedsourced Maps : 2008년 부터 Google Map Maker를 런칭,  40여개 국가에서 사람들이 이것을 활용하여 자발적으로 구글이 자체적으로 수집하기 어려운 도로나 장소에 관한 상세 정보를 입력하는 프로그램을 운영해 왔으며, 올해 이 사람들에게 졸업장을 수여했다 (Crowd Contributions from Map Maker).
  • Mobile Maps Inside the Building : 11월말에는 안드로이드 단말의 Google Maps 6.0 버전에서 공항이나 백화점, 쇼핑몰, 회사 등 큰 건물 내부의 지도를 제공하는 서비스를 런칭했다. 안드로이드 단말을 보유한 유저들은 이것을 들고 건물 내부에 있는 특정 장소를 찾아 갈 수 있으며 쇼핑하던 중 친구를 쉽게 만날 수도 있다. 특정 건물내에 입주해 있는 상점 주인이 주소를 찾아 건물과 맵핑시키고 사진이나 추가 정보를 입력하고 플로어를 업로드하면(Upload This Floor), 안드로이드 단말의 건물내부 지도에서 자신의 상점을 찾을 수 있게 된다. 일명 뚜벅이용 내비게이션이라고도 할 수 있다.
  • 전체적으로 볼 때 Google Maps는 검색, 플레이스, 소셜 등과 연동되고, 건물 내부까지 진입함으로써 모바일에서 활용성을 극대화하는데 초점을 맞추고 있다고 할 수 있다.
Multiple Applications Layered On the Google Map

Multiple Applications Layered On the Google Map

10. Siri : Cloud Based Smart Search Engine ? 

  • Smarter Than Human : Apple의 목표는 우리가 찾는 것에 대해 우리보다 더 잘 아는 서비스를 만드는 것
  • Cloud Based Service : iOS 단말에 이미 존재하는 “Onboard Voice Search”가 아니다. 아이폰은 Device Interface에 불과하다. 시리는 유저 리퀘스트를 이해하고 처리하기 위해 애플의 데이타센터에 모든 쿼리를 조회하는 웹서비스이다. 시리는 애플의 클라우드 컴퓨팅 파워를 활용하여 쿼리를 이해하고, 가장 의미있는 결과를 찾아 주고자 한다.
  • Search the Web as a Last Resort : 시리가 아이폰이나 클라우드에서 답을 찾지 못할 때 최후 수단으로 웹서치를 활용한다.

글을 맺으며

지금까지 ReadWriteWeb에서 선정한 2011년 10대 웹 프로덕트를 살펴 보았다. 이것을 살펴 보면서 우리가 올해 자주 들어왔던 여러가지 Trend가 실제로 제품에 구현되어 시장을 이끌어 가고 있음을 알 수 있다.

1. Web과 Native의 융합 : 많은 브라우저들이 HTML5 표준을 지원함에 따라 Web 자체에서 단말에 귀속된 Native Function을 구현할 수 있게 되었다.

2. Cloud와 싱크 : PC, 스마트폰, 태블릿, Connected TV 등 다양한 단말에서 인터넷에 접속할 수 있는 환경이 만들어짐에 따라 다양한 형태의 싱크 어플리케이션들이 등장하고 있다. 1) Sync과 Backup 전용의 파일관리자 : Drop Box, SugarSync 처럼 기존 탐색기와 같은 User Interface를 활용하여 어떤 단말에서 유저가 생성한 모든 형태 파일 및 폴더를 클라우드와 싱크시켜서 다른 단말에서 접근할 수 있다. 2) Platform Level의 자동 싱크 :  iCloud와 같이 특정 어플리케이션에 국한되지 않고 플랫폼 레벨에서 다양한 어플리케이션 데이타를 유저가 인지하지도 못한 상태에서 자동으로 싱크해 줌으로써 어떤 단말에서든지 동일한 데이타에 편리하게 접근할 수 있다. 3) Content-Shifting : Evernote나 Instapaper와 같이 상황에 따라 생각나는 아이디어나 경험을 App.에 기록해 두었다 나중에 다른 단말에서 접속해서 다시 읽기 위한 목적으로 유저가 직접 생성한 컨텐트 (텍스트 파일, 포토, 음성 녹음 파일, URL 등)를 클라우드에 저장하고 싱크시키는 류의 서비스도 큰 인기를 끌고 있다. 웹과 모바일, 태블릿 버전 등 다양한 단말에서 서비스를 제공하는 많은  App.들이 User Data를 클라이언트에 캐슁해 놓고 서버에서 추가로 갱신된 데이타를 싱크하는 방식으로 제공하고 있다. 4) IT Infra로서의 클라우드 컴퓨팅 :  위에서 언급되지는 않았지만 Amazon Web Service처럼 하드웨어 인프라, 미들웨어, 어플리케이션 등 개발자들이 App. 개발 및 운영에 필요한 자원과 툴을 제공하는 B2B형 클라우드 서비스가 있다

※ 4번째 의미의  클라우드 컴퓨팅에 대한 참고자료

3. 미디어별 특성에 최적화된 User Experience 구현하기 : 새로운 미디어가 처음 등장하면 그것을 직접 써고보 경험하면서 그것의 온전한 가치를 이해하기 전에 사람들은 당황하며 기존 미디어의 형식을 그대로 새로운 미디어에 적용하는 경향이 있다. 예를 들어 TV가 처음 나왔을 때 사람들은 이것을 “보는 라디오”라고 정의하고 라디오에 적합한 컨텐츠 포맷을 비쥬얼화해서 TV 화면에 제공했다. 스마트폰이 처음 출시되었을 때 사이즈가 작은 인터넷이라고 생각했다. 그러나 맥루한이 지적했듯이 미디어의 형식에 적합한 컨텐츠는 따로 있다. 위에서 언급된 10대 프로덕트중 Flipboard,  Evernote, Instapaper 모두 사람들이 집안에서 PC를 켜고 의자에 앉아 브라우저를 통해 인터넷을 쓰기 보다는 소파나 침대에서 편안한 자세로 태블릿을 키고 자신에게 필요한 뉴스나 블로그, SNS 등을 주로 읽는 용도로 활용한다는 데에 초점을 맞추었다. 즉 동일한 컨텐츠일지라도 PC, 스마트폰, 태블릿 등 매체가 활용되는 User Context에 따라 완전히 다른 경험을 제공할 수 있다.  이 3가지 App.들은 태블릿에 최적화된 Reading Experience를 제공한다는 점에서 비슷하지만 플립보드는 RSS 잡지 스타일, Evernote는 아웃룩, Instapaper는 타임라인과 유사한 형태의 인터페이스로 정보를 조직화하고 있다는 점에서 사용용도와 느낌, 즉 고객가치도 다르다.

4. 감각기관의 연장 : 강력한 컴퓨딩 파워와 다양한 입출력 장치를 가지고 있는 스마트폰은  인간의 감각기관과 두뇌의 연장이라고 할 수 있다. 클라우드를 기반으로 음성 입출력을 지원하고 (Siri나 Google의 Vocie Search), 사진이나 이미지를 카메라로 스캔하여 텍스트를 캡쳐해 내거나 정보를 획득하거나 얼굴을 인식하고, 마이크 인풋을 활용하여 유저가 시청하거나 듣고 있는 영화나  음악, TV에 관한 정보를 제공하고 (IntoNow나 Soundhound 등), GPS나 Location 기능을 지도와 결합하여 방향감각을 가지고 길을 찾아 갈 수 있게 도와주기도 한다.  읽기, 듣기, 보기, 방향감각 등 인간의 감각기관을 에뮬레이션하여 User의 Context를 인지하고 유용한 정보를 제공하는 App.들이 계속 출시되고 있다. 물론 모바일 단말의 이러한 성능에 초점을 맞춰 App.을 개발하다 보면 기존 PC 기반의 웹과는 전혀 다른 User Experience를 창조해 낼 수 있다는 점에서 역시 매체의 형식에 적합한 컨텐츠는 따로 있다는 진리는 여기에서 다시 한번 확인할 수 있다.

Written by abulaphia

December 5, 2011 at 2:43 pm

아마존 킨들 파이어에 대한 비판적 리뷰

with 3 comments

아마존은 자사가 보유한 온라인 쇼핑 인프라와 방대한 컨텐츠, 경쟁력있는 클라우드를 기반으로 “Kindle Fire”라는 저가의 태블릿을 출시했습니다. 킨들 파이어는 단말 자체 보다는 아마존의 강점인 쇼핑과 디지털 컨텐츠 판매에 초점을 맞춘 태블릿입니다. Wired지에 따르면, Kindle Fire는 책을 비롯하여 영화, 음악, 쇼핑 등 아마존이 보유한 경쟁력있는 컨텐츠의 판매를 위한 아마존의 전용 태블릿으로서 최근 iPAD와 경쟁할 수 있는 유일한 태블릿으로 급부상하고 있으나 1) 스크린 사이즈의 제약으로 잡지를 읽기가 불편하며 2) 종이와 같은 자연스러움을 제공하는 e-Ink 대신 LCD를 사용한 결과 오랫동안 몰입해서 책을 읽는 경험을 하기가 어렵고 3) 아마존의 자체 안드로이드 App.만을 지원하기 때문에 아직 쓸 수 있는 App.이 많지 않고 4) 웹브라우징시 화면사이즈와 CPU의 오류로 자주 버벅거리는 등 아직 개선해야할 문제점들이 많이 있다고 지적하고 있습니다.

Kindle Fire에 대해 편향적으로 보일 정도로 비판적인 Wired의 Review를 간단히 번역해 보았습니다 (Is This Really the Tablet Everyone’s Talking About, 2011년 11월 14일). Wired 지보다 Kindle Fire에 대한 더욱 신랄한 비판을 보고 싶으신 분은 “Human Review of Kindle Fire“라는 블로그를 참고하세요.

※ 역자주 : 킨들 파이어가 문제없이 잘 동작한다는 리뷰도 있는 만큼 Wired지의 기사는 기존 iPAD와 같이 완성도 높은 제품의 관점에서 바라보고 있기 때문에 다소 공정하기 못한 비평일 수 있습니다. 안드로이드 폰도 처음 나왔을 때 열라 버벅거리고 구렸으며, 비평가들이 악평을 한 영화가 힛트를 치는 경우도 얼마든지 있습니다. 따라서 기존 강자가 지배하고 있는 태블릿 시장에서 아마존이 자신의 강점을 전략적으로 극대화하는 방식으로 저가의 태블릿을 어떻게 구현했는지에 더 관심을 두고 읽는 것이 객관적인 판단을 하는데는 더 도움이 될 것 같습니다.

1. Kindle Fire Spec : 200$는 충동구매를 자극할 수 있는 정도의 낮은 가격이지만 iPAD 등 다른 태블릿 대비 낮은 해상도, 느린 속도, 카메라나 3G 외장하드 접속 슬롯 등은 지원하지 않는다.

  • 7 inche LCD Display, 1024 x 600 Screen Size
  • 1Ghz Dual Core CPU
  • 아마존 EC2에 최적화된 Silk Browser
  • Camera, 3 G Data Connectivity, Slot of Removable  Storage 등은 지원하지 않음

2. Kindle Fire의 특징 : Device 판매 수익보다는 페타바이트에 달하는 아마존의 디지털 컨텐트 판매에 초점을 맞춘 태블릿이다.

Amazon Kindle Fire Tablet With Silk Browser Powered By EC2

Amazon Kindle Fire Tablet With Silk Browser Powered By EC2

  • 아마존의 익숙한 구매경험을 정교하게 재포장하고 정렬했다 (It elegantly repackages and streamlines every phase of the familiar Amazon purchasing experience).
  • 7인치 슬레이트를 가장한 효과적인 쇼핑 포탈 (effective shopping portal in the guise of a 7-inch slate)
  • Netflix, Hulu Plus, 아마존 등에서 가져 온 수십만개의 TV Show와 Video를 시청할 수 있다 (무료 컨텐트도 꽤 많음)
  • 아마존 클라우드 무제한
  • Amazon Prime 1달 무료 : Amazon Prime은 일년에 79$ 인 프리미엄 멤버쉽 서비스로서 이틀간 전지역 무료배송, 13,000개 무료 비디오 스트리밍, 뉴욕타임즈가 선정한 100권 이상의 베스트셀러를 포함하여 5천권 이상의 eBook을 한번에 한권씩 한달간 빌릴 수 있는 Kindle Owner’s Landing Library 등으로 구성되는데 Kindle Fire를 구입하면 한달간 무료로 Amazon Prime을 사용할 수 있다.

3. The User Interface

1) 홈스크린안드로이드 2.3 User Interface에 책장의 메타포를 기막히게 입혔 놓았다 (reskins the Android 2.3 user interface with a whimsical bookshelf metaphor).

Kindle Fire Home Screen

Kindle Fire Home Screen, Carousal

  • 제일 상단의 첫번째 칸은 Carousal이라고 하는데,  유저가 최근에 사용한 App, e북, 비디오, 잡지, 음악 트랙, 웹페이지 등을 보여준다.
  • 그 다음 칸에는 유저가 좋아하는 컨텐트들이 저장되어 있는 소규모 책꽂이들이 밑으로 계속 나열되어 있다.
  • 홈스크린은 다양한 컨텐트들의 썸네일 애니메이션을 스크롤링하면서 내비게이션한다는 점에서 애플 뮤직 App.의 “Cover Flow“와 유사하게 동작하고, 화려하게 디자인 되어 있으나 기존 iPAD 처럼 정적인 그리드에 획일적인 타입의 아이콘을 사용하는 메타포 (“uniform icons on a static grid” metaphore) 보다 더 우월하다고는 할 수는 없다.
  • 모든 종류의 미디어 타입으로 도배가 되어 있다는 점에서 Carousal은 Kindle Fire가 본질적으로 미디어 소비용 단말(a media consumption device)이라는 점을 말해줌.
  • Newsstand, Books, Music, Video, Docs, Apps, Web 등 홈스크린 상위의 7가지 메뉴를 보면 이 점이 더욱 더 강조된다. 이 7가지 메뉴를 보면 Kindle Fire가 무엇을 하는 태블릿인지 굳이 생각해 보지 않아도 된다. 이것은 궁극적으로는 유료로 구매해서 디지털 미디어를 소비하기 위한 단말이다 (consuming — and ultimately buying — digital media).

그러나 모든 종류의 미디어가 Kindle Fire에서 동작하는 것은 아니다.

2) News Stand : 아마존은 Kindle Fire를 Magazine Reading Platform이라고 대대적으로 홍보하고 있으나 (a big push to promote the Fire as a magazine-reading platform) 일반적인 잡지의 해상도와 일치하지 않는 화면 사이즈와 후진 CPU로 인해 비쥬얼 요소가 많은 디지털 잡지를 읽기가 어렵다.

  • 화면 사이즈의 문제 : 킨들 파이어의 스크린은 1024 x 600 사이즈로서 “고릴라 글래스” 라는 튼튼한 제품을 사용, 유저가 보는 각도가 달라져도 상이 일그러지지 않는 IPS (in plane switching) 기술을 도입하였다. 그러나 가로 세로 화면 비율과 관련하여 보통 잡지 인쇄물은 8.5 x 11 인치이나 Kindle Fire는 3.5 x 6 인치라서  잡지 페이지는 읽을 수 없을 정도도 작게 화면에 표시된다.
  • 느린 프로세서의 문제 :   파이어의 프로세서는 비쥬얼 요소로 가득한 디지털 잡지를 페이지별로 보여 주는데 버벅 거린다.

3) Books: 아마존은 e북의 우아한 전송에 초점을 맞춰 하드웨어 브랜드를 구축했다( built its Kindle hardware brand on the elegant delivery of e-books). 그러나 기존 저가의 킨들에 적용되어 있던 e-Ink 스크린 테크놀로지 대신 LCD를 채택했기 때문에 오랫동안 읽기 어렵다.

  • LCD의 문제 : e-Ink 테크놀로지는 실제 종이책 처럼 자연스럽게 보이고 눈부심이 덜하여 햇볕 아래에서도 쉽게 읽을 수 있고 전력소모도 적었는데 Kindle Fire에는 다양한 칼라를 지원하는 LCD를 사용하고 있기 때문에 장기간 독서용으로는 적합하지 않다. 그래서 어린이용 e-Book, 그래픽 노블, 만화 등 킨들 파이어 전용 컨텐츠가 별도로 제작했다.
  • 화면사이즈의 문제 : 7인치로는 몰입해서 책을 읽는 경험을 제공하기에는 화면이 너무 작다 (still too small for any semblance of an immersive reading experience).

4) Videos : Kindle Fire에서 가장 훌륭한 기능

  • Perfectly Serviceable Video Player : WiFi 망이 깔려있는 곳이라면 어디에서든지 7인치 Wide Screen 모드로 아마존, Netflix, Hulu가 제공하는 비디오 컨텐트를 끊김없이 즐길 수 있다. 9.7 인치의 iPAD, 10.1 인치의 안드로이드 태블릿에서 동작하는 750 p의 비디오 컨텐트가 와이드 스크린 모드에서 잘 동작한다.
  • Amazon 자체 컨텐트 : 10만개의 TV Show와 영화, 그중 아마존 프라임을 쓰면 1만3천개는 무료로 볼 수 있다.
  • Netflix와 Hulu Plus App. 제공 계획 : 조만간 기존 넷플릭스 가입자라면 무료로 TV와 영화 컨텐트를 스트림해서 바로 볼 수 있게 될 것이고(watch instantly), 훌루 플러스 App.을 통해  수천개에 달하는 ABC, NBC, Fox 등 메이저 방송사들의 TV 에피소드를 즐길 수 있게 될 것이다.
  • Unlimited Amazon Cloud Storage : Kindle Fire 유저는 아마존에서 구입한 모든 컨텐트를 클라우드에 무제한적으로 저장할 수 있으나, WiFi가 없는 장소에서는 클라우드에 접근이 불가하다. 그러나 8 G 스토릿지 중 6 G만 사용하여 아마존에서 다운받은 비디오, 책, 음악 등 컨텐트를 저장할 수 있기 때문에 WiFi가 없는 지역에서 Video Library를 주의깊게 관리해야 한다.

5) Apps : 모든 안드로이드 App.이 Kindle Fire에서 동작하는 것은 아니다.

  • Exclusively Amazon’s AppStore For Android : Kindle Fire도 결국은 안드로이드 디바이스이기 때문에 이론상 구글의 모바일 OS에서 동작하는 35만개의 App.이 모두 Fire에서 동작할 수 있으나, 현실적으로 볼 때 이 태블릿은 아마존이 자체 개발한 안드로이드 App Store에 전적으로 의존하고 있기 때문에 수천개의 App.만을 사용할 수 있다.
  • Amazon’s Diligent Working : 아마존은 Netflix, Hulu Plus, ESPN SportsCenter, Facebook, Pandora, Rhapsody 등 인기가 높은 양질의 App.을 Fire에 제공하기 위해 동분서주 하고 있다.
  • App. Perfomrnace : Kindle Fire에서 테스트해 본 App.들은 잘 동작했다. 이것은 아마존에서 App.들을 사전승인했기 때문이기도 하겠지만 원래 안드로이드 App.은 프로세싱 파워가 낮은 안드로이드 스마트폰에서도 잘 동작하도록 만들어져 있기 때문이기도 하다.
  • Amazon Shop :  아마존 샵이란 App.은 아마존의 데스크탑 쇼핑 Experiece를 터치 컨트롤 드림으로 바꿔 놓았다 (collapses Amazon’s desktop shopping experience into a touch-control dream). 그러나 원클릭 구매에 동의한 후 ( signed up for 1-click purchasing) 손가락을 잘 못 놀리면 신용카드로 결제가 되기 때문에 조심해야 한다.

6) Web : Fire는 iPAD와 동일하게 1Ghz 듀얼코어 칩과 아마존이 자랑해 왔던 Silk Browsing Technology를 사용함에도 불구하고 웹페이지 로딩속도와 유저의 액션에 대해 반응이 매우 느리기 때문에 웹브라우징 경험은 매우 후지다 (The Fire’s Web Browsing Experience is Emotionally Draining).

  • Silk Browser Technology : Fire에 내장된 Silk 브라우저는 EC2를 기반으로 동작하는 아마존의 전용 브라우저로서 웹브라우징에 필요한 모든 프로세싱과 데이타 페칭(fetching)시 워크로드를 단말과 클라우드에 분산시키도록 설계되어 있다. 아마존에 따르면 “모든 페이지 리퀘스트에 대해 실크는 네트워크의 상태와 페이지의 복잡성, 캐쉬된 컨텐트의 위치 등의 팩터를 고려하여 워크로드를 모바일 하드웨어와 아마존의 EC2 클라우드로 다이나믹하게 쪼개서 처리한다.”
  • Poor Loading Time : 모든 조건을 동일하게 한후 iPAD와 함께 테스트해 본 결과 Fire의 브라우저에서 웹페이지를 로딩하는 속도는 iPAD 보다 2~3배 느리다.
  • 웹브라우징 도중 버벅거림 : 로딩이 완료된 웹페이지를 스와이핑하면 버벅거리고, 터치 제스쳐에 반응하지 않을 때도 있으며, 화면 확대를 위한 Pinch in-out이 잘 동작하지 않기 때문에 인내심 테스트와 같다. iPAD와 동일한 칩을 사용함에도 이렇게 버벅거리는 이유는 칩의 코어 아키텍쳐에 오류가 있거나 소프트웨어 최적화가 덜 되어 있을 가능성이 높다.
  • Screen Size : 웹페이지를 어렵게 로딩했다 하더라도 사이즈가 너무 작아서 글을 읽을려면  탭을 해서 확대해야 하는 등 웹브라우징을 하기가 너무 어렵다 (They suck for web browsing). 사람들이 7인치 태블릿을 피했는지 이해가 되는 대목이다. 웹브라우징은 태블릿이 해야 하는 가장 중요한 일 (web browsing is a key tablet responsibility)중에 하나이기 때문에 이것은 심각한 문제이다.

7) 음악은 훌륭하지만 휴대하고 다니기는 어렵다 : 오디오 트랙과 앨범은 라이브러리로 빠짐없이 잘 정리되어 있기 때문에 Fire에서 고객은 바로 구매가 가능하고, 클라우드 스토릿지에 저장되기 때문에 어디서든지 접근이 가능하다. 그러나 음악을 듣기 위해 7인치 테블릿을 휴대하고 다니기는 어렵지 않나?

8) U/I 디자이너가 공백을 메우기 위해 억지로 만든 같은 DOCs  : 유저가 Kindle Library의 다큐먼트섹션에 업로드해 놓은 이미지, 텍스트, PDF 파일을 보기 위한 단순한 컨테이너(Simple Container)에 불과하다.

4. 결론

킨들 파이어는 1) 많은 비디오의 재생이 가능하고 2) 다양한 안드로이드 App.이 동작할 수 있으며 3) 아마존 쇼핑을 놀라울 정도로 재미있고 쉽게 구현했다는 점을 제외하고는 별로 좋을게 없다.

많은 문제점들이 개선되기를 기다렸다가 킨들 Fire 2를 구매하라. 그러나 Kindle Fire 2가 나올 때 쯤에 iPAD3도 나올 텐데, 그때 싼가격에 iPAD2를 사는 것이 더 낫지 않을까?

Written by abulaphia

November 18, 2011 at 6:11 pm

HTML5에 관한 11가지 냉혹한 진실

with 6 comments

Infoworld의 기고가  가 밝히고 있는 HTML5의 11가지 문제점을 간단히 번역해 본다.

※ Source : 11 Hard Truths About HTML5

HTML 5에 몇가지 강력한 기능들이 추가됨에 따라 웹프로그래밍의 패러다임이 변화할 것이라는 호들갑에도 불구하고 실제로는 Web상에서 Native-App.의 퍼포먼스를 아직까지 따라가지 못하고 있다. HTML5의 강력한 성능에도 불구하고 그것이 모든 문제를 해결할 수는 없다.  HTML5에 추가된 매력적인 기능들로 인해  Web App이 Native App. 의 강력한 경쟁자로 부상하고 있으나, 보안문제, Local Data Storage의 한계, 동기화 문제, 브라우저 벤더간 정치싸움으로 우리의 기대에는 한참 미지치 못하고 있다.

1. Security Is Nightmare

클라이언트 사이드 컴퓨팅의 근본적인 문제는 User가 궁극적으로 머신에서 동작하는 Code를 통제할 수 있다는 점이다. Web App의 경우 당신의 브라우저를 뛰어난 툴로 디버깅하면  남용하기가 훨씬 더 쉽다.

Firebug와 같은 Javascript Debugger를 사용하면 Facebook이나 Google같은 사이트가 어떻게 동작하는지 알고 싶은 사람은 누구든지 Breakpoint들을 삽입해 놓고 코드를 볼 수 있다. 이로 인해 웹사이트의 디버깅과 동작방식을 쉽게 이해할 수 있게 되지만 “보안”의 관점에서는 악몽에 가깝다.

Firebug를 비롯하여 브라우저 디버깅 툴을 사용하면 특정 변수의 값을 당신이 원하는 대로 조작할 수 있다. 즉 당신의 브라우저가 지구상에 위치해 있는 위도와 경도값 등 위치 변수를 쉽게 편집해서 친구들에게 당신의 위치를 속일 수 있다.  Web App이 제공하는 모든 기능들 역시 수정될 수 있다. Web 환경은 정상적인 Native Code에서 보다 훨씬 더 쉽게 조작이 가능하다.

보안문제가 발생하는데에는 한계가 있다. Google Web Tool Kit과 같은 JavaScript Tool은 표준 컴파일러 만큼이나 복잡하고, 이러한 툴들의 아웃풋은 측량하기가 어렵다. 그러나 운좋게도 JaveScript Deminifier같은 툴들을 사용하면 보완이 가능하다.

물론 보안상의 위험은 어플리케이션의 본성에 달려있다. 당신은 위도와 경도값을 편집해서 친구들에게 당신이 지구의 반대편에서 체크인한 것처럼 보이게 만들 수 있다. 만약 누군가 위치 조작에 의해 특정 장소의 Mayor로서의 권한을 취득하고 이것이 돈과 관련이 된다면 게임은 훨씬 더 복잡해 진다. 이러한 이유로 중요한 데이타를 수집을 위해  Client Based HTML5 App.들을 신뢰하기는 어렵다.

2. Local Data Storage Is Limited

당신의 브라우저에서 파뭍혀 동작하는 로칼 데이타 베이스는 HTML5의 가장 똑똑한 기능들중에 하나인데, 이것을 사용하면 Web App.으로 당신의 컴퓨터에 데이타를 쉽게 캐슁할 수 있게 된다. 누군가 브라우저에서 Desktop과 유사한 functionality를 기대한다면,  Local Database를 사용함으로써Bandwidth를 절약하고 퍼포먼스를 개선할 수 있다.

그러나 Desktop App.과 달리 User들은 브라우저의 Local Database에 캐슁된 데이타를 거의 통제하기 어렵다.  HTML5 Data Storage 성능은 매우 중요한 추가사항임에는 분명하지만 1) 저장된 데이타를 다른 머신으로 옮기거나,  2) 데이타를 카피하거나 3) 데이타를 백업해 놓거나 4) 다른 App.으로 열어 볼 수 없다. 이 데이타는 브라우저가 감추어 놓은 곳에 깊숙하게 파뭍혀 있다. User는 데이타를 호스팅하는 책임만 있고 그것을 컨트롤할 수 없다는 점에서 최악이라고 할 수 있다.

최근의 몇몇 브라우저들은 어떤 데이타베이스가 당신의 머신에서 생성되어 있는지를 볼 수 있게 하고 있으나, 이 정보들은 매우 제한적이다. 사파리를 사용하면 이 데이타베이스를 삭제할 수 있 수 있으나, 이 정보를 브라우징하거나 다른 머신으로 옮길 수는 없다. User가 어디를 보아야하는지 인지한 상태에서 이것을 옮기려 한다 하더라도 파일들은 쉽게 옮길 수 있도록 설계되어 있지 않다.

User들은 파일들을 들이 파서 무엇이 저장되어 있는지를 찾아낸다 하더라도 볼 수는 없다. 물론 프로그래머들은 그것들을 분리해 낼 수 있으나 이것조차도 포맷을 먼저 공부하거나 해킹한 후에야 가능하다. Desktop App.과 달리 Local Storage에 저장된 데이타는 스프레스 쉬트나 텍스트 다큐먼트처럼 쉽게 어떤 에디터로든지 열 수가 없다 (They’re not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app).

3. Local Data Is Manipulated

User는 데이타에 대한 통제력이 없지만, 중앙의 웹사이트 역시 클라이언트 데이타를 처리하기가 어렵기는 마찬가지다. 만약에 User가 브라우저나 머신을 변경한다면 어떻게 될까? 많은 웹 개발자들은 이 문제에 손을 들고 단기적인 컨텐트만을 캐슁하기 위해  local data storage를 사용한다.

개발자들은 동기화문제 때문에 User들이 많은 컨텐트를 생산하지 못하도록 꼼수를 쓴다. 웹개발자들은 local database의 보안에도 신경을 써야 한다.  적절한 툴이 없기 때문에 User들이 local data를 편집하거나 권한을 업그레이드하기는 어렵지만, 중앙 서버가 데이타 조작 자체를 방지할 방법은 없다. User에게 JavaScript를 변경할 수 있도록 허용함에 따라 데이타베이스 자체가 변경될 수 있는 Security Hole도 존재한다. Local Data는 폭넓게 개방되어 있기 때문에 누구든지 Grassmonkey 스크립트나 Nativecode를 짜서 데이타를 변경할 수 있다.

4. Offline Apps Are Nightmare to Sync. 

HTML5 Local Data Storage로 인해 Web App.을 오프라인 상태에서 쓸 수 있게 되었다. 여기에서 유일한 문제는 Data Synchronization이다. 만약에 Web App.이 인터넷에 연결되어 있다면, 계속해서 데이타를 클라우드에 저장할 수 있다. 그러나 오프라인인 경우 변화가 항상 클라우드에 저장되지는 않는다.

만약에 누군가 브라우저를 변경하거나 다른 머신을 사용한다면, 복사본이 증식되어 데이타 동기화가 어려워 진다. 만약 시계가 불일치 할 경우 가장 최근에 저장된 데이타가 무엇인지를 판단하기 어렵기 때문에 문제가 더욱 심각해 진다. 물론 이러한 문제는 Native App.에서도 언제나 발생하지만 데이타 동기화의 책임 주체가 누구인지가 명확하다. 즉 사람이 파일네임과 날짜를 보고 Syncronization Trouble을 해결할 수 있다.

그러나 HTML5는 브라우저에 깊숙히 저장되어 있는 Database에 대한 통제권한을 User에게 허용하지 않기 때문에 개발자들은 동기화를 핸들링할 수 있는 User Interface를 제공해야만 한다. 이것은 완전히 통제할 수 없는 문제는 아니다. 프로그래머들은 Version Control System을 사용하여이 골칫거리를 관리하고자 한다.  이러한 문제들을 해결하기 위해 버전 관리 시스템은 더욱 정교해지고 있다. 그러나 테크놀로지가 존재한다고 해서 그것이 개발자들이 쉽게 사용할 수 있는 솔루션이라는 의미는 아니다. 다양한 GIT 레포지터리들을 머징하는데는 시간이 필요하다. HTML5 Web App의 동기화를 관리하고자 한다면 HTML5 개발자들은 이러한 이슈들을 마스터해야만 한다.

5. The Could Ows You Nothing

데이타를 클라우드에 저장할때 구조적인 문제가 발생한다고 해서 HTML5를 비난하는 것은 온당치 않으나, Cloud는 HTML5가 꿈꾸는 비전의 근본적인 부분이다. HTML5는 클라이언트 소프트웨어의 설치 및 데이타 백업 등 모든 골칫거리를 해결하기 위해 클라우드를 적극 활용하고 있다 (leverages the cloud to fix all of the headaches for installing software and backing up data).

HTML5 Local Data Storage의 한계가 존재하는 상황에서 대용량 Storage가 필요한 Web App Data (The bulk of Web app data storage)를 서버에 맡기는 방식으로 접근할 경우 파괴적인 결과가 나올 수도 있다. 최근에 Facebook은 사진을 업로드하는데 사용했던 Linux 기반의 플러그인을 제거하기로 결정했다. 최고 전문가들의 면밀한 검토가 있은 후 플러그인은 제거되었으나, 이 플러그인을 사용하여 업로드된 모든 사진들도 함께 사라졌다(With a wave of the caliph’s hand, the plug-in was gone, along with all of the photos that were uploaded using it).

이러한 스토리들은 일반적이진 않으나 어떤 이유로 점점 더 자주 발생하고 있다. HTML5 App.으로 모든 것을 무료로 제공하겠다고 약속하는 소규모 Web Start-Up들에게나 이런 문제가 몇 달 또는 몇년 후에 발생할까? 아마도 이렇게 생각하는 편이 편할 것이다. 이 문제는 점점 더 악화되고 있다.

많은 Web App.들이 이용약관에서 명확히 하고 있듯이, 데이타는 User들의 것이 아니다. 오히려 대부분의 경우 User들에게는 데이타의 복구를 요청할 수 있는 법적인 수단이 존재하지 않는다. 심지어 데이타가 아무런 이유없이 삭제될 수 있다는 것을 강제하는 보다 뻔뻔스러운 이용약관도  존재한다.

HTML5는 어떤 방식으로든 이 문제의 해결을 회피할 뿐만 아니라 구조적으로 당신의 브라우저에 캐쉬되어 있는 모든 로칼 데이타는 클라우드에 저장되도록 되어 있기 때문에 User들은 이것에 접근할 수도 없고 통제할 수도 없다. HTML5 예찬론자들은 이것을 기능이라고 부르고 있으나 오히려 자신의 모델과 상충되기 쉽다.

6. Forced upgrades aren’t for everyone

어떤 사람이 바에서 만난 사람들과의 Casual Relationship을 위해 가끔씩 Gmail로 연락을 주고 받곤 했는데, Google+ 출시 후에 이런 사람들과의 오래된 기억들이 홍수처럼 밀려오는 경험을 한 적이 있다. Google+는 이런 낡은 주소들을 Discussion Forum에 연결시키기 때문이다. 매일 오래전에 잊혀진 사람들의 이름과 얼굴이 나타나서 써클로 분류하라는 것이다. (클라이언트 업그레이드 없이도 웹을 통해 훨씬 편리하게 새로운 서비스를 출시할 수 있지만, 고객이 원하지 않는 방식으로 웹업데이트가 이루어질 수 있다는 의미)

Web App.을 업그레이드할 필요가 있을 때 그것은 모든 사람에게 동시에 적용되어야 한다. Web App.을 사용하면 User들이 소프트웨어를 굳이 인스톨할 필요가 없긴 하지만 새로 추가된 기능을 원하지 않는 User들에겐 이것이 악몽일 수도 있다. 새로운 소프트웨어는 낡은 기능들에 의존하는 다른 패키지들과 충돌을 일으킬 수도 있다.

7. Web Workers offer no prioritization

Web Wokrers는 HTML5에 추가된 좀더 매력적인 기능이다. Web 개발자들은 묵직한 JavaScrip의wait, delay, pause commands에 의존하기 보다는 코드들을 쪼개고 CPU hogs를 Web Workers로 분리시킬 수 있게 되었다. 다시 말해 HTML5 Web Workers로 인해 브라우저가 보다 OS처럼 동작할 수 있게 되었다.

그러나 불행하게도 Web Workers는 OS의 모든 기능을 복제해서 가지고 있지는 않다. Web Workers는 워크로드를 포크(fork)하고 분리해서 처리할 수 있는 방식을 제공하고 있기는 하지만, 워크로드를 효과적으로 관리하거나 우선순위를 정하는 방법은 전혀 없다. API를 사용하면 메시지를 Worker Object로 입력하거나 출력해줄 뿐이다 (The API just allows messages to be passed into and out of Worker objects). 이것이 전부이다. 나머지는 브라우저가 알아서 처리해야 한다.

만약 CPU 자원을 많이 잡아먹는 code-cracker와 같은 어플리케이션이 인기 웹사이트의 백그라운드에서 몰래 동작한다면 어떻게 될까? User들이 웹사이트의 Cycle-Stealing도 할 수 있지 않을까 ? Malware는 이미 유용한 소프트웨어에 편승하고 있기 때문에, Web Worker의 기능적 약점이 악용되는 것은 시간 문제이다.

Worker Object가 생성되거나 그것이 무엇을 하는지 트래킹할 수 없기 때문에 User들은 이러한 Malware에 대해 아무것도 할 수 없다.  Malware의 공격대상인 특정 웹페이지에 접속한 후 그들의 컴퓨터가 느려지는 현상을 경험할 뿐이다.

8. Format incompatibilities abound

HTML5는 <audio> <video> 태그를 도입,  이미지 태그처럼 쉽게 사용할 수 있고 브라우저가 데이타를 스트림해 주게 될 것이라고 자랑해 왔다. 그러나 이것이 그렇게 쉽다면 왜 내가 모든 메이저 브라우저에서 동작하는 기본 오디오 파일을 찾는데 2주나 소모했을까? 이것은 HTML5의 잘못이라기 보다는 브라우저 개발자들이 모든 오디오, 비디오 포맷을 지원하지 않기로 결정했기 때문이다.

사람들은 인간이고 인간은  지배를 위해 싸운다. 그러나 개발자들은 어떤 브라우저에서 완벽하게 동작하는 파일이 다른 브라우저에서는 동작하지 않을 때 이 문제를 다뤄야만 한다. 이것을 어떻게 테스트할까? API 개발자들은 canPlayType이라는 함수를 개발할 정도로 충분히 스마트했지만, 이것조차도 모든 브라우저가 지원하는 것은 아니다.

9. Implementations are browser-dependent

HTML5가 꿈꾸는 이상은 그것을 구현해야하는 지저분한 현실과는 큰 갭이 존재한다. 프로그래머들은 최선을 다해 아키텍트의 꿈을 실현하고자 하나 어떤 태그와 오브젝트들은 잘 동작하지 않는다. 예를 들어 HTML5의 Geo Location API와 같이 작동하지 않는 것들이 많이 있다. geolocation API는 Privacy 보호와 정확성에 대한 통제수단을 제공한다. 이것이 지속적으로 잘 동작할 때 조차도 어떤 브라우저에서는 타임아웃이 걸린다. 심지어 Desktop에서는 GPS가 존재하지 않는다는 것을 알고 있을 때 조차도 그렇다.

궁극적으로 이것은 API 자체의 구조적 문제에 대한 불만이라기 보다는 브라우저가 특정 기능이 일관성있게 동작하도록 지원하지 못하고 있다는 사실에 대한 불만이다. 웹 개발자들이 HTML5 기반 Web App의 이상을 Reality로 만들고자 할 때 브라우저 의존적인 문제점들에 직면하게 된다는 것이 냉혹한 진실이다 (This hard truth highlights the browser-dependent challenges that Web developers face in making the HTML5-based Web app nirvana a reality).

10. Hardware idiosyncracies bring new challenges

몇몇 브라우저 개발자들이 성능 개선을 위해 원래 스펙 이상을 구현했거나 덜 구현했다고 해서 불평하는 것은 불공평하지만, 아무리 좋게 개선했다 하더라도 부작용이 따르기 마련이다 (no good deed goes unpunished).

MS는 low-level의 hardware driver들과 그것을 통합시킴으로써 IE 브라우저의 Canvas Object의 Performance를 개선하는 위대한 일을 했다. MS는 이것을 과시하기 위해 pirateslovedaisies.com과  같은 게임들을 지원하기도 했다.

이제 프로그래머들은 이러한 새로운 기능을 사용할 수 있는지의 여부에 대해 면밀히 살펴 보아야 하겠지만 우리가 짠 코드가 얼마나 빨리 동작하는지를  확인할 방법이 명확하지는 않다.

예를 들어 pirateslovedaisies.com의 디자이너들은 IE가 제공하는 기능들을 킬지 끌지를 스위치로 선택할 수 있게 만들었다. 이러한 추가 기능들을 짐작해서 사용할 수 있는 API가 현실적으로 존재하지 않는다.  가장 간단한 방법은 브라우저 네임별로 테스트를 진행하고 Frame Rate를 측정하는 것이다.  나는 많은 Native Game 개발자들이 수년동안 폭넓은 범위의 하드웨어를 다루어 온 것을 잘 알고 있다. 여기서 유일한 솔루션은 혁신을 금지하는 것이지만 그렇게 된다 하더라도 웹 개발자들은 이런 상황에 적응해야만 할 것이다.

11. Policitcs As Usual

어떤 사람들은 Ian Hickson이 HTML5 표준의 창시자 (main drafter of HTML5 standards)라고 부르지만, 이것은 농담에 불과하다. Standard Wirter들은 제안을 할 뿐이고 실질적인 결정은 브라우저 회사의 코딩 천재들이 내린다. 그들이 어떤 기능을 구현할지 구현하지 말지 선택하면 웹 개발자들은 결과가 안정적인지 결정을 내린다. 그리고 몇년 후 표준 자체가 구현된 결과에 맞게 변경되는 일도 종종 발생한다.

많은 JavaScript 개발자들은 호환성의 문제를 jQuery와 같은 라이브러리를 생성한 사람들에게 떠 넘긴다. 이런 Layer들로 인해 우리는 브라우저간 차이(cross-browser differences)에 대해 크게 개의치 않고 지나가지만, 이러한 차이가 미래에도 별 문제가 안될지에 대해서는 지켜봐야 할 것이다.

이러한 이슈들은 브라우저 업계의 근본적인 문제이다. 우리같은 웹 개발자들은 브라우저간 치열한 생존경쟁의 결과로 탄생하는 풍요로운 기능과 자유, 창의성을 원한다. 브라우저 개발자들이 앞서 나가기 위해 앞다투어 새로운 기능들을 개발함에 따라 혁신의 속도가 빨라지고 있으나 대신 브라우저간 차이가 점점 더 커지고 있다.

그러나 우리는 중앙에서  플랫폼을 통제하는 독재자가 제공하는 안정성도 원한다. 세계는 권위주의와 민주주의간 전쟁을 해결하기 위한 이상적인 솔루션을 아직도 찾지 못하고 있다. 차이로 인해 발생하는 골칫거리에 대해 불평하기 보다는 하원 (House of Commons)에서 다음과 같이 연설한 윈스턴 처칠의 태도를 취하는 것이 더 나을 것이다. “실제로 사람들은 민주주의가 지금까지 때때로 시도되었던 다른 모든 체제를 제외하고  가장 나쁜 지배의 형식이다 ( “Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.”)

Written by abulaphia

August 23, 2011 at 3:59 pm

Facebook Investor Roger McNamee Explains Why Social Is Over

leave a comment »

좀 지나긴 했지만 업계의 중요한 포인트를 잘 지적하고 있어서 간단히 정리해 보았습니다. 페이스북의 투자자인 Roger McNamee의 IT 업계에 대한 예측입니다.

※ 출처 : Facebook Investor Roger McNamee Explains Why Social Is Over

1. MS는 토스트다.

Internet Connected Device 시장에서 MS의 점유율은 향후 3년 이내에 95%에서 50%로 감소할 것이다. 기업들이 ROI이 안나오는 Window 대신 다른 프로덕트와 서비스를 찾게 된다.

Market Share of Smartphone Platform

Unit Share Top Smartphone Platform Q2 2011

* Android 48%, iOS 19%, Nokia Symbia 16%, RIM 12%, Bada 4%, MS WP7 1% (2Q, 2011)

2. 아이폰의 gross margin이 대부분의 안드로이드 폰보다 훨씬 좋다. 

얼마전 Apple사가 2/4분기 영업이익이 “93억  7천만달러 (약 9.9조원) 이라고 발표했으며, 미국 정부보다 Apple의 현금을 더 많이 보유하고 있다는 뉴스가 보도되었습니다. Apple의 영업이익은 삼성전자, BlackBerry를 만드는 RIM, 넥서스 폰 제조업체인 HTC 등 3대 안드로이드 폰 제조업체의 영업이익을 다 합한 것보다 많습니다.

Apple사의 영업이익은 삼성/HTC/RIM의 영업이익의 합보다 크다

Apple사의 영업이익은 삼성/HTC/RIM의 영업이익의 합보다 크다

3. 구글은 Self-Victim

구글은 자신의 성공에 의해 스스로 희생되었다 (SEO에 의한 검색결과 오염). 구글의 문제는 Match.com이나 Realto 같은 Non-Search 펌에 의해 해결 (검색수요의 50%를 이들 Non-Search Firm들이 차지)

2달전에는 단순히 Web과 Web을 연결해 주는 Google의 Searcheable  Web의 시대는 끝났고 보다  사람과 사람이 연결되는 Social Web의 시대가 올 것이라는 전망이 많이 제기되었다. 

Google이 Orkut 인수에서 시작하여 Jaiku 인수, Google Wave, Google Buzz 등 SNS 서비스를 계속 추진했던 이유는 Facebook을 따라하기 위해서가 아니라 Like, Retweet, Comment 등 Social Network에 방대하게 축적되어 있는 사람들간 Interaction Data (Recommendation and Social Signals of Their Friends)를 분석해서  검색결과에 반영하려는 것이다. 즉 “Social Search” 서비스를 제공하기 위해 Google+ 및 +1 버튼을 계속 출시하고 있다.

구글의 Gmail 담당자였던 Doug Edwards는 “the information created in social networks is extremely important and valuable. If we don’t have access to that information, Google will be less valuable as an information source.”

※ 참고자료 : Google’s Long History of Social Media Attempts [infographics]

4. HTML5의 효과

HTML5의 세상에서는 모든 것이 App.이다. HTML5는 Web Socket을 통한 Real Time Notification, Web Caching 을 통한 오프라인 Access, Drag&Drop 등 과거에 전용 App.으로만 가능했던 많은 기능들을 지원할 수 있게 되었다.

HTML5에서 디스플레이 광고가 필요없다. 북리뷰를 하다 책을 바로 살 수 있다. 한 장소에서 수요를 창출하고 바로 만족시키는 것은 오늘날 인포머셜 밖에는 없지만, 앞으로 웹에서도 그렇게 될 것이다 (Highly Disruptive To TV Advertising).

최근에는 HTML5로 개발된 Web App.이 1) Apple의 심사등록 절차 및 In-App Purchase 정책을 우회하고,  2) Cloud에 저장된 데이타를 다양한 단말에서 접근할 수 있도록 지원하고 3) Minor한 업데이트를 할 때도 2~3주에 걸리는 Apple의 심사를 받지 않고 웹상에서 U/I 변경, 기능 추가 등을 하면 바로 Release가 가능하기 때문에 전용 App.의 전략적 대안으로 많은 IT기업들의 주목을 받고 있다.

그중 대표적인 것이 Amazon의 Kindle Cloud Reader이다. 아래 그림에서와 같이 아마존의 고객은 어떤 단말에서든지 HTML5를 지원하는 웹브라우저를 통해 Amazon에 접속한 후 책을 구매하면 이전과 같이 책을 단말에 다운로드해서 Kindle 전용 App.으로 읽는 것이 아니라 “클라우드”에 먼저 저장한 후 Kindle뿐만 아니라 iPAD, iPhone, Android 등 다양한 고객단말에서  WebApp.형태로 제작된 Kindle Cloud Reader를 통해 읽을 수 있다. 고객은 인터넷이 끊긴 상태에서도 책을 볼 수 있다.

5. iPAD는 HTML5의 훈령장

iPAD는 IBM PC 이후 가장 중요한 단말이 되었다.
Apple은 멈출수 없는 화물열차와 같다. Apple이 올해 판매한 인터넷 접속단말은 PC Market의 2/3에 해당한다. iPAD App.들은 HTML5로 어떻게 하면 더 좋은 User Experience를 만들어 내는지를 잘 보여 주고 있다. You need to find a way to play with it, but you also need to find a way to play over it” with HTML5.

Flipboard 초기화면

Personalized Social Megazine

※ “Personalized Social Megazine”을 표방하며 HTML 5로 제작된 플립보드

  • Facebook, Twitter, Flickr, Wired, Mashable, National Geographics 등 3rd Party의 컨텐츠를 Aggregation해서 잡지와 같은 U/I로 보여줌

6. Cloud의 중요성

여러개의 인터넷 접속 단말을 보유하게 됨에 따라 모든 정보가 Local에 저장되는 PC 패러다임은 죽었다. 앞으로는 모든 것이 클라우드에 저장되고 여러개의 단말과 싱크될 것이다. 클라우드에 관해서라면, 적어도 지금까지는 구글, MS, Apple, Facebook 모두 제대로된 모바일 경험을 만들어 내는데 실패했다.

※ 애플은 iCloud에서 알아서 해 줄테니, iPhone과 iPAD를 그냥 쓰기만 하라고 합니다. 고객 입장에서 아이폰에 있던 사진이 자동으로 클라우드에 저장되고 iPAD를 키면 별 다른 짓을 안해도 그냥 아이폰에 있던 사진을 보게 된다는 것인데요(Just it works). 고객은 iCloud의 존재 자체도 알 필요가 없게 되는 셈입니다. 이거이 스티브 잡 말대로만 그렇게 잘되면 해피하기는 할 것 같은데 진짜 어려운 일인 것 같습니다. 잘못 삭제하면 다른 단말기에 저장된 데이타도 자동으로 삭제될 것이기 때문에 그만큼 데이타 관리의 Risk도 커질 것 같습니다. 그리고 단말마다 용도가 다르므로 사용하는 데이타가 다 다를텐데 이것을 어떻게 Just It Works하게 될지도 궁금합니다. 예를 들어 Mac OS에서 작업한 문서 파일이 iClould에 자동으로 저장되고, 이것이 iPhone으로 내려온다고 생각하면 끔찍할 수도 있겠습니다.

※ 참고문헌 : Cloud에 접근하는 Apple과 Google의 전략적 차이

7. Facebook

Facebook은 Connect를 유료화함으로써 소셜그래프를 필요로하는 퍼블리셔들로부터 돈을 벌것이다. 이제 소셜은 그만해라. 거대한 소셜 플랫폼은 이미 완성되었다. VC의 투자를 받은 나머지 500개의 소셜 컴퍼니들은 이제 아무 짝에도 쓸모 없다 (worthless).
그러나 모든 사람들이 Social Distribution에 목매고 있을 때, 뮤직 비디오가 그랬 듯이 HTML5로 제대로 된 컨텐트를 만들면 큰 기회가 생길 것이다.

※ 우리나라에서는 제대로된 “Social”이 아직 시작도 안됐는데, 이 양반은 이제 소셜은 그만하고 iPAD에다 HTML5로 제대로된 컨텐츠를 만들라고 합니다. HTML5가 중요하긴 한 것 같습니다. 그건 그렇고 Facebook이 이미 수십만개의 웹페이지에서 사용하고 있는 Social Plug-In의 사용료를 과연 받을까요? 이 저자가 Facebook의 투자자이기 때문에 먼가 신빙성이 있어 보이기도 하지만, Facebook이 Open AIP 정책을 통해 Global Player로 성장해 온 점과 작년에 이미 22억불의 광고수익을 올린 점을 감안하면 자기가 올아 온 사다리를 걷어찰 것 같지는 않습니다.

※ 실제로 Gartner가 2010년 12월부터 2011년 1월까지 17세에서 74세까지 11개 선진국 6,295명을 조사해 본 결과, 24%가 자신들이 가장 좋아하는 Social Media Site에 처음 가입시 보다  덜 사용한다고 응답했습니다. 그러나 저 젊고 tech-savvy한 세그멘트에서는 37%가 가장 좋아하는 사이들을 더 자주 사용한다는 응답도 있기 때문에 섣부르게 Social Media에 사람들이 지쳐가고 있다는 결론을 내리기는 어렵습니다.

그러나 Early adoptor들 사이에서 Social Media Fatigue 현상을 보이고 있으며, Aspirer (younger, more mobile, brand-conscious consumers)의 31%가 소셜미디어의 이용이 점점 더 지루해지고 있다는 응답이 나온 것으로 볼 때 소셜 미디어를 좀더 개혁하고 다양하게 운영할 필요가 있다고 Gartner는 지적하고 있습니다.

처음보다 조금 덜 또는 훨씬 덜 사용한다는 24%에게 왜 그런지 물어봤더니 이중 33%가 “Privacy” 문제를 제기하고 있습니다. 그러나 10대의 경우 privacy 문제로 소셜미디어에 대한 열정이 감소한다고 답한 비율은 22%로 평균보다 훨씬 작았습니다.

미국, 영국, 일본에서는 40%가 처음 가입시보다 더 많이 사용하며, 40%는 비슷한 수준, 20%는 덜 사용한다고 응답했습니다. 한국과 이탈리아에서는 거의 50%가 처음보다 더 많이 사용한다고 응답한 반면,   러시아(30%)와 브라질(40%)에서는 처음보다 덜 사용한다고 응답한 비율이 미국, 일본, 영국보다 1.5배에서 두배 정도로 높은 비중을 보이고 있습니다.

우리나라에서는 Social Network가 언론이나 업계의 주목을 받는 것과 실제 Usage/보급율 간에는 아직 커다란 갭이 존재하는 것 같습니다. 즉 Social Media Heavy User군이 분명히 형성되어 있는 반면 아직 전체 인터넷 인구로 저변이 많이 확산되지는 않은 것 같습니다. 즉, Facebook User보다 카카오톡 사용자가 훨씬 많은 것이 현실이고, 아직까지는 싸이월드의 영향력도 무시할 수는 없는 것 같습니다. 우리나라에서 Social Metwork 서비스는 어쩌면 지금까지도 Early Adoptor들이 주도하는 시장이기 때문에 대충  50% 정도의 User들이 처음보다 Social Network 서비스를 더 많이 사용한다고 나온 것 같습니다.

8. 기존 방송산업의 취약성

텔레비전이 컴퓨터가 되면, 광고주에게 유리한 리포트를 제공하는 닐슨 패널보다 훨씬 더 정확한 시청률을 알게 될 것이다.

Netflix가 ’09년 1천만명에서 올해 12/4분기 2,500만명에 육박하는 가입자를 확보하여 미국 1위의 Cable 회사인 Comcast를 추월했습니다. 작년 매출은 216억불, 올해 2/4분기 7,700억불, 미국내 디지털 영화 시장점유율 61%, 피크타임대 다운스트림 인터넷 트래픽 점유율 30%, 450여개의 단말에서 시청 가능, 2010년 영화관에서 상영된 영화의 48%를 공급, 2011년에만 컨텐트 확보하는데 10억불을 투입하는군요. 이래서 Cable Cord Cutting한다는 애기가 나오나 봅니다.

※ 출처 :  Netflix의 자세한 실적은 여기를 참조하세요.

실제로 방송이 인터넷, 모바일, Hulu나 Netflix의 위협을 받고 있다는 것은 어제 오늘의 얘기는 아닙니다. 2011년 3월 “Ideas & Solution사”의 조사에 따르면 PayTV를 시청하는 미국 Y세대(7천만명)를 loyalist, leaners, at-risk 등 3가지 그룹으로 분류해 봤는데, at risk 그룹의 50%가 Hulu와 Netflix가입자라는 군요. 실제로 방송이 위험한 것 같기는 한데 우리나라에서는 어떨까요?

이 사람 글을 보면 앞으로 윈도우 플랫폼에 닭질하는 넘, Social을 하는 넘, HTML5를 모르는 넘, iPAD 가지고 놀 줄 모르는 넘, 시청률을 기반으로 기존 광고모델에 집착하는 지상파/케이블 방송사들 모두 똘아이가 되겠군요.

Written by abulaphia

August 8, 2011 at 7:33 pm

Posted in Cloud, Facebook, Google, Smart TV, TV

Tagged with , , , ,

4가지 Social Music Charts

leave a comment »

소셜웹에서 아티스트들에 대한 고객의 Action을 수집해서 음원차트를 구성하는 Social Music Chart가 등장하고 있다는 내용의 Mashable 기사

※ 출처  Measuring Clout : 4 Music Charts Powered By Social Media 

1958년 8월 4일 빌보드가 최초로 Ricky Nelson의 “Poor Little Pool”을 1위로 선정한 후, 빌보드 주간 “Hot 100 Chart”는 digital music streaming 데이타가 추가되긴 했지만 지난 50여년간 거의 변화하지 않았다. 지금까지 전 장르에 거친 빌보드 차트는 Nielson이 수집한 3가지 소스의 데이타에 의존했는데, 1) 닐슨 BSD에 의해 수집된 Radio Airplay Audience Impression 2) 닐슨의 SoundScan으로 컴파일된 앨범판매 데이타 3) Yahoo/AOL 등 Online Music Source로부터 수집된 Streaming Activity Data로 구성되었다.

빌보드 챠트는 음악적 성공의 주요한 indicator이긴 하나 최근에는 소셜미디어의 영향력에 기초한 음악적 성공을 수집하여 발표하는 “Social Music Chart”가 등장하고 있다.

2010년 3월에 오프된 Next Big Sound는 Facebook, YouTube, Twitter를 비롯하여 약 16개 사이트에서 Fan, (Page)Views, Play, Like, Downloads, Comment 등 약 70만명의 아티스트들에 대한 Fan들의 Activity를 수집해서 아티스트들의 인기도를 실시간으로 추적하고, 그래프로 표시해준다.

회원가입을 하지 않고도 자신이 좋아하는 아티스트들을 등록해 놓으면 매주 해당 아티스트들에 대한 신규 팬들의 숫자, Play수, (Page) Views, 코멘트의 주간 변화를 이메일로 리포트 해준다. 테스트삼아 Nirvana, U2, Coldplay, Green Day 4개 아티스트들을 등록해 보니 Social Media별로 주간 단위 변화의 추이를 멋진 그래프로 그려준다.

음악 저널리스트, 업계 전문가, 음악 애호가 등이 피리미어 리포트를 보려면 아티스트별로 한달에 79$를 지불해야 한다. 이 리포트에는 소셜 미디어 데이타뿐만 아니라 1) 전통적인 음반 판매량, 2) 라디오 방송횟수, 3) 아티스트 웹페이지 트래픽, 4) P2P Activity 등도 볼 수 있다.

Next Big Sound는 비슷한 방식으로 주간 아티스트 인기도를 추적하여 주간단위로 “Social 50” 차트를 빌보드에 제공한다.

이와 유사한 서비스로는 We Are Hunted, MTV Music Meter 등이 존재한다.

We Are Hunted는 블로그 activity와 Social Network Mention, Buzz on Message Board and Forum, P2P Network 상에서 트위터 토크와 Movement 등을 집계해서 매일 음악의 인기도에 관한 차트를 갱신해서 제공해 준다.

또한 당신 자신의 차트를 생성해서 친구들과 공유할 수도 있는 커뮤니티 기능을 지원하면, ‘Discover”를 통해 당신이 선호하는 새로운 음악을 찾을 수도 있다. 얼마 전엔 음악 어플리케이션의 개발을 지원하는 Echonest의 API를 통해 다양한 기능을 제공하는 iPAD App.도 출시하였다.

MTV Music Meter는 Social Media Status에 기초하여 아티스트에 관한 순위를 제공한다. MTV는 Music Intellignece Company인 Echonest와 공동 작업을 하고 있는데, Echo Nest는 음반 판매량과 라디오 플레이뿐만 아니라 블로그, 소셜 미디어, 비디오까지 포괄하여 데이타를 정리하는 알고리즘을 개발해서 특정한 날 어떤 밴드가 가장 많은 주목을 끌었는지를 확정한다(Algorithm that combs through blogs, social media, blogs and more traditional metrics (like radio plays and sales) to determine which band s are receiving the most attention on any given day). MTV는 iOS와 안드로이드 App.도 출시했다.

Echonest와 같이 음악 관련 App.의 개발을 지원하는 서비스로는 Soundcloud도 있다.

Written by abulaphia

August 8, 2011 at 4:23 pm

Cloud에 접근하는 애플과 구글의 전략적 차이

with 2 comments

고객을 보는 관점과 Market Positioning에 따라 “Cloud”에 접근하는 애플과 구글의 전략이 어떻게 달라지는지를 분석한 테크크런치의 기사를 제가 이해한 방식대로 의역한 글입니다. (Source : “It Just Works” By MS Siegler, 2011, 6월 10일)

Steve Job는 2011년 WWDC Keynote에서 iCloud에 대해 “It Just Works”와 “Automatically”라는 말을 계속 반복해서 사용하면서 아이폰과 아이패드, OS X Lion 단말이 어떻게 클라우드와 Seamless하게 연동되어 동작하는지에 대해 설명했다.

노스캐롤라이나에 있는 애플 전용 데이터센터

“It Just Works”와 “Automatically”라는 말의 반복사용을 통해 클라우드에 대해 Jobs가 던지고 싶어했던 메시지는 무엇일까 ?

Jobs는 클라우드가 무엇인지에 대해 새롭게 정의하는데서 부터 시작했다 (They’re attempting to redefine what the “cloud” is).

1. Apple’s Redefinition of Cloud 

  • 1) 클라우드는 Remote Hard Disk 또는 Hard Disk in the Sky가 아니다.
  • 지금까지 많은 사람들은 클라우드를 필요할 때 파일을 저장하거나 꺼내어 쓸 수 있는 하늘에 있는 하드디스크라고(Hard Disk in the Sky) 생각해 왔으나,
  • iCloud는 John Gruber가 적절히 지적했듯이 새로운 iTUNES로서 디지털 허브를 데스크 탑 컴퓨터에서 클라우드로 옮기는 것을 목적으로 한다.
  • 여기서 한발 더 나아가서 Cloud를 User가 어떤 파일을 찾기 위해 우리가 방문하는 물리적인 장소(파일 탐색기와 같이 U/I가 존재하는 물리적 Hard Disk)가 아니라, 2) 공기와 같이 유저가 인지하지 못하게 백그라운드에서 그냥 조용하게 동작하는 시스템으로 정의하고 있다. 
  • Apple은 우리가 공기를 의식하지 않고 숨을 쉬듯이 유저들이 어떤 단말에서 접속하든 자신이 찾고자 하는 파일이 존재하기만 한다면 클라우드가 실제로 어떻게 동작하는지 전혀 알 필요조차 없어야 한다고 생각한다 (Apple’s belief is clearly that users will not and should not care how the cloud actually works.)
  • 바로 이것 때문에 잡스는 ‘iCloud’가 어떻게 동작하는지를 설명하기 위해 매우 단순화된 다이아그램을 사용하기는 했지만 개발자 컨퍼런스가 아니었다면 Jobs는 이것 조차 하지 않았을 것이다. 대신 iPAD에서 작업중이던 문서 파일을 User가 아무것도 하지 않아도 Mac에서 iPAD에서 편집한 문서파일의 페이지까지 정확하게 불러와서 읽을 수 있게 된다는 데모를 보여주는데 더 많이 신경썼을 것이다. 음악, 포토, 주소록 다 마찬가지이다.
  • 또한 잡스는 “Sync”가 어떤 특정 장소에 파일이 존재하고 이것을 다른 곳으로 옮겨야 한다는 개념을 가지고 있고 소수만이 이해할 수 있는 너무 기술적인 용어이기 때문에 이 말을 사용하지 않는다. 대신 아이폰, 아이패드, OS X Lion을 사용하면 작업한 파일들이 클라우드에 자동으로 저장되고(save automatically) 모든 단말에 “이전에 작업한 그대로” 실시간으로 존재하기 때문에 (they just exist, as is, in real time on all your devices) User는 더이상 파일을 저장할 필요가 없다.

2. Cloud에 대한 Google의 Concept (클라우드에 존재하는 PC의 카운터파트)

  • 구글은 기존 PC에서 User들이 클라우드에 어떻게 쉽게 접속하게 할 것인가라는 관점에서 접근한다 (Google’s approach has been to make the cloud more accessible to existing PC users.)
  • 구글은 “클라우드에 존재하는 PC의 카운터 파트(파일관리자)”라는 컨셉 : 구글 DOCS는 클라우드에 존재하는 MS Office이고, Gamil은 클라우드에 존재하는 MS Outlook이며, User의 Main Interaction Point인 파일시스템(탐색기) 또한 클라우드에 존재한다.
  • Amazon과 MS 공히 구글과 같이 PC User 입장에서 “클라우드”를 “파일관리시스템”으로 정의하고 있지만, Apple 입장에서 iCloud는 그냥 애플리케이션을 실행시키면 원하는 파일에 접근할 수 있는 그 무엇이다 (Apple’s iCloud is about opening an application and the thing you want to access being there)

3. Apple의 Cross-Device Native App. vs. Google의 크롬/크롬 OS 접근전략   

  • 많은 사람들은 Apple의 iCloud가 기존 Web Component에 초점을 맞춘 MobileMe의 개선판일 것으로 기대했으며 실제로 애플은 오랫동안 공을 들여 완전히 새로운 Web App.을 재개발하긴 했지만, Jobs의 핵심 포인트는 웹이 아니라 iCloud의 매직과 함께 동작하는 “cross-device native apps”에 있었다(The primary emphasis will on the cross-device native apps with iCloud magic)
  • 구글 역시 애플의 iCloud의 매직처럼 크롬북을 부팅시킨 후 ID, P/W를 입력하면 “클라우드”에 존재하는 모든 파일이 자동으로 싱크가 되기 때문에 모든 것이 거기에 이미 거기에 존재한다.
  • 크롬 O/S에서 “Cloud Syncing”이 매우 중요한 요소이긴 하지만 Android O/S도 존재하기 때문에 Apple처럼 User가 인지하지 못한 상태에서 모든 것이 백그라운드오 자동으로 싱크되지는 않는다.
  • 즉, 구글은 클라우드를 “브라우저에서 사용하는 파일 관리시스템“이라는 관점에서 어떤 단말에서든지 웹을 통해 파일을 업로드하고 싱크할 수 있긴 하지만, 어떤 것은 자동으로 되고 또 어떤 것은 고객이 한번 더 생각해서 선택적으로 해야 하기 때문에 애플처럼 지가 알아서 동작하는 것이 아니라(just it works)가 아니라 그것과 유사하게 동작(sort of just works)하게 된다.
  • 이것은 “Cloud”를 중심으로 보는 관점에서 후퇴한 것이다. 구글의 목적은 PC User가 클라우드로 쉽게 바꿀 수 있도록 하는 것이다 (their aim is to ease the transition of current PC users to the cloud).

4. Apple과 Google의 본질적인 차이는 Targer 고객이 누군인지에 대한 접근방식의 차이

  • Apple은 클라우드가 무엇이고 그것이 어떻게 동작하는지는 전혀 관심도 없는 고객들을 대상으로 하고 있기 때문에 (Apple is going after consumers who have absolutely no idea what the cloud is, and don’t care), 그것은 그냥 동작하면 되고 고객은 그것을 신경쓸 필요도 전혀 없어야 한다.
  • 반면 구글은 현재의 컴퓨팅 패러다임을 잘 이해하고 있고, 클라우드 컴퓨팅에 관심이 있는 “Power User”를 대상으로 한다.
  • Apple은 Desk-Top App.을 포함하여 자신들의 App.들을 처음부터 완전히 재개발하여 iCloud Fabric으로 통합시킴으로써 유저들에게는 전혀 인지되지 않도록 했지만, Google은 User들에게 클라우드의 동작방식을 보여 주고 선택적으로 사용할 수 있도록 함으로써 PC User들이 보안이 유지되는 클라우드로 갈아 타라고 설득하고 있는 셈이다.
  • 구글은 Apple과 같이 자신의 에코시스템을 완벽하게 통제하지 못하기 때문에 Jobs는 “구글이 절대로 우리처럼 지가 알아서 동작하게 할 수 없다(They can never make this so it just works)”고 말한 것이다.
  • 즉, Apple은 아이폰, 아이패드, Mac 등 3가지 Type의 단말을 Seamless하게 동작하게 할 수 있으나, 구글은 안드로이드 폰 외에 태블릿은 아직 약하고 PC는 손도 못대고 있기 때문에 크롬 브라우즈, 즉 웹을 통해 자신이 통제할 수 없는 단말을 통합시키고자 한다.
  • 3가지 단말을 단일한 뿌리의 O/S로 통제할 수 있는 에코시스템을 구축하고 있는 애플과 안드로이드 O/S와 크롬 O/S 두가지를 운영함에도 단말에 대한 통제력은 약한 구글의 Martket Position의 차이로 인해 “Cloud”의 접근방식의 차이가 생겼으며, 이점은 Apple이 더 유리할 수 밖에 없다.

Jobs는 월요일날 말하기를 “여러분 모두 알고 있듯이 하드웨어가 우리 제품들의 두뇌이고 힘줄이라면 거기에서 동작하는 소프트웨어는 우리의 영혼”이다 (You know, if the hardware is the brain and the sinew of our products, the software in them is their soul). 애플은 그 어느 때 보다도 분명하게 웹 소프트웨어가 아니라 눈에 보이지 않게 웹의 지원을 받는 Native Software에 자신의 운명을 건 것이다. 반면 구글은 Native를 지원하는 안드로이드와 크롬 O/S 두가지에 목숨을 걸고 있다.

5. 교훈

  • 2008년 “N-Screen Project”시 우리도 Apple이나 Google과 똑같이 PC, Web, Mobile, 심지어는 TV상에서 까지 주소록과 버디, 포토, 동영상 등 모든 것을 Seamless하게 자동으로 싱크시켜서 고객이 편리하게 사용하기를 바랬으나, 기술적인 용어를 그대로 사용하는 등 너무 공급자 관점에서 접근했던 것 아닌가 ?
  • 1) Apple이 iCloud에서 목표로 설정하고 있듯이 고객이 인지할 수 없을 정도로 완벽하게 다양한 단말에서 싱크가 자동으로 실행될 수 있도록 지원할 수 있는 정도의 설계와 기술적 노하우를 우리는 갖지 못하고 있었고, 2) 잘못 싱크가 되면 고객의 소중한 파일들이 분실될 수도 있다는 우려 때문에 구글이나 MS처럼 고객이 “싱크의 개념”을 이해한 상태에서 단말별로 선택적으로 “Cloud”와 연동시켜 사용할 수 있기를 바랬었다는 점. 즉 싱크의 개념이 매우 어려워서 개발자들도 헷갈릴 정도인데 이것을 고객이 이해하고 쓰기를 바랬다는 점에서 거의 불가능한 것을 하려 했었다.
  • 철저하게 고객관점에서 자신이 작업중이던 파일이 Automatic하게 저장되고, 다양한 단말 Application에서 그것을 열었을 때 Just Working하면 되지, 고객이 그것이 어떻게 동작하는지 알 필요도 없으며, 싱크와 같은 어려운 기술적인 단어로 고객에게 그것을 굳이 설명해봐야 혼란스럽기만 할 것이다.

Written by abulaphia

June 10, 2011 at 3:02 pm

%d bloggers like this: