다음, 모바일게임 플랫폼 도전…DeNA와 제휴

Implication : 스마트모바일 app.에 Library, API 형태로 embeded 되는 모바일 플랫폼 Biz 활성화
하나의 플랫폼에서 친구들과 게임/미디어 등을 즐기고 데이터도 공유하는 형태로
소셜게임과 사회관계망 서비스(SNS), 광고 플랫폼, e커머스 서비스를 제공하여
Content 자체 Biz와 부가적인 follow-up되는 네트워크 traffic을 활용한 Biz 전개를
목적으로 함.
(사례 : iOS 게임센터, Open feint, 다음-DeNA(모바게), 네오위즈 인터넷(피망플러스), 컴투스허브(컴투스), tvingAir 등)

다음커뮤니케이션(이하 다음)은 글로벌 모바일게임 플랫폼 모바게를 운영하는 DeNA와 제휴를 맺었다고 11월7일 밝혔다.

다음은 이번 제휴로 “DeNA, DeNA의 미국 자회사인 엔지모코와 국내 모바일게임 네트워크 플랫폼 1위로 발돋움할 계획”이라며 “광고-소셜-로컬-게임 네트워크로 구성된 강력한 모바일 플랫폼을 완성 예정”이라고 밝혔다. 다음은 모바일 광고 플랫폼인 ‘아담’, 모바일 메신저인 ‘마이피플’, 지역 정보를 제공하는 소셜쇼핑과 다음 지도 등을 서비스하고 있다.

DeNA는 소셜게임과 사회관계망 서비스(SNS), 광고 플랫폼, e커머스 서비스를 제공하는 곳이다. 소셜게임 플랫폼인 모바게는 일본 이용자만 3200만명이 넘으며, ‘위룰’과 ‘닌자로열’ 등 1500개 이상의 모바일 게임을 서비스하고 있다. DeNA가 2010년 10월에 인수한 엔지모코는 ‘위룰’과 ‘갓핑거’를 개발한 모바일 소셜게임 개발사로, 이용자가 3천만명이 넘는다.

다음과 DeNA의 제휴 결과물은 2012년 상반기께 나온다. 다음은 DeNA와 모바일게임 플랫폼을 만들어 모바일 앱으로 출시할 계획이다. 두 회사의 게임 플랫폼은 안드로이드 앱으로 먼저 출시되고 이후 iOS 앱으로 나올 예정이다.

두 회사의 모바일게임 플랫폼은 DeNA의 게임을 국내에 소개하는 역할에 그치진 않을 전망이다. 다음과 DeNA와 운영하는 게임 플랫폼에서 게임을 출시하는 개발사는 해외 진출을 꾀할 수도 있다. 다음은 DeNA의 모바게 네트워크를 통해 국내 개발사가 해외 시장에 진출하는 데 DeNA와 힘을 합치겠다고 밝혔다.

스티븐 양 DeNA 서울 대표는 “다음의 파워풀한 네트워크를 통해서 모바게의 고품질 소셜게임을 한국 이용자에게 제공해 기쁘게 생각하며, 한국의 게임 개발사가 모바게의 글로벌 플랫폼을 통해서 세계 각국의 모바게 이용자에게도 게임을 제공하기를 기대한다”라고 말했다.

손경완 다음 이니셔티브 부문장은 “DeNA 및 국내 모바일게임 개발사와 시너지를 통해 국내 1위 모바일 게임 플랫폼을 만들어낼 계획”이라고 말했다. 손경완 부문장은 CPO로서, 다음의 서비스를 총괄해왔는데 이번에 모바일게임 플랫폼을 책임지는 이니셔티브 부문장으로 선임됐다. 앞으로 모바일 게임 플랫폼과 다음 서비스의 연동, 게임 수급, 개발사와 제휴, 투자 등을 맡을 예정이다.

다음과 DeNA가 내놓을 모바일게임 플랫폼은 다음의 기존 서비스와 긴밀하게 연결될 전망이다. 다음 모바일게임 플랫폼에 연동할 다음의 서비스는 손경완 부문장이 언급한 마이피플과 아담, 다음 지도가 유력하다. 다음 아이디와 전화번호를 기반으로 둔 마이피플은 다음 게임 플랫폼에 SNS 성격을 더해 이용자를 끈끈하게 맺어줄 수 있다. 아담은 게임 플랫폼에 기본 광고로 탑재될 가능성이 높다.

DeNA도 이 3가지 서비스에 대한 관심이 높았던 것으로 보인다. 다음은 이번 제휴 배경을 설명하며 “DeNA는 다음이 한국 모바일 시장을 선도하고 있다는 점과 아담, 마이피플, 다음 지도 등 모바일 서비스가 모바게의 게임 비즈니스와 큰 시너지가 날 수 있다는 점 등을 높이 평가했다”라고 말했다.

다음은 그동안 게임 사업은 ‘다음 게임’과 요즘, 카페 등 PC 기반을 둔 웹에서 벌여왔다. DeNA와 손을 잡으며 게임 사업을 모바일로도 확장하게 됐다. 이번 제휴는 게임뿐 아니라 스마트폰과 태블릿PC로 대표되는 모바일에 다음의 깊은 관심을 드러낸다. 정지은 다음 커뮤니케이션 팀장은 “다음은 모바일 플랫폼을 오랫동안 준비해왔다”라며 “현재 모바일 사용자가 웹 사용자의 50%를 넘어서고 있는데 우리가 예측한 것보다 진행 속도가 빠르다”라고 설명했다.

다음은 모바일게임 플랫폼을 홍보하기 위해 PC-모바일-디지털뷰를 적극적으로 활용할 계획이다. “기존 게임 마케팅 플랫폼인 PC, 모바일, 서울 지하철 1~4호선에 설치된 900여대의 디지털뷰를 활용해 10~20대 이용자의 동선에 맞춘 마케팅을 전개하겠다”라고 밝혔다.

한편, 다음은 최근 플로우게임즈의 지분 투자를 진행했다. 플로우게임즈는 다음에 ‘아크로폴리스’, ‘카페 무림대전’, ‘아포칼립스’, ‘해피오션’ 등을 개발한 게임사로 이중 ‘아크로폴리스’와 ‘카페 무림대전’은 다음에서 서비스하고 있다. 이 두 게임은 다음 소셜게임 전체 매출의 80%를 올렸다.

OPEN API 제공을 위한 SOA(Service Oriented Architecture)

[출처 : KTH, 2011년11월25일]

개요 : Open API, Library 기반의 Mash-up서비스/사업을 위한 System Architecture

요즘 OPEN API의 중요성이 대두되고 있다. 아마존, 페이스 북, 구글 등 유명 IT업체에서도 OPEN API를 발표하고 있고, 이를 통해 3rd 개발자들이 만들어 낸 신규 서비스들을 재판매(제공)함으로써 서비스의 규모를 키워가고 있다. 물론, 수익금은 3rd 개발자에게 돌려주는 에코시스템을 표방한다.

사내의 자원을 이용하는 OPEN API 자체도 중요하지만 OPEN API의 결과인 Mash Up 서비스를 재판매(제공)하여 유기적으로 서비스 규모를 키워가기 위해서는 프로세스와 데이터들이 통합되어 있고 변화에 유연하게 대처할 수 있는 서비스 중심 아키텍처(SOA) 구성도 중요하다.

  1. Time To Market 가능한 SOA(Service Oriented Architecture)의 의미
    SOA는 소유하고 있는 소스, Application, Platform, System, Infra등의 자산/자원을 재사용 가능한(독립적인) 서비스 단위로 분리하고, 다른 서비스 단위와 조합(orchestration)할 수 있는 인터페이스를 제공하도록 구성된 아키텍처이다. 또한, 서비스 단위를 실시간으로 조합하여 손쉽게 새로운 서비스를 만들어 내는 Time To Market 실현이 가능한 구조로 구축되어야 한다.SOA에서의 ‘서비스’와 ‘서비스 단위’의 의미는 아래와 같다.
    서비스 재사용하기 편리하도록 서로 독립적이어야 하고(낮은 결합도), 그것 하나로 하나의 서비스에 집중되어 있어야 하고(높은 응집도), 외부에 내부의 구성방식이 노출되지 않아야 하며(정보은닉->캡슐화) 이렇게 하려니 서비스간 결합을 통하여 확장이 용이하도록 제각각 Interface를 가지고 있는 것
    서비스 단위 독립적으로 제공될 수 있는 가장 작은 단위의 서비스. (어느 정도로 분할할지는 서비스 특성에 맞추어 결정해야 함. 기능 단위들의 조합)

    서비스 단위는 기능 단위와 동일한 개념이 아니다. 예를 들어, 사용자는 A라는 서비스를 인터페이스(API)를 이용하여 호출한 후 사용(다른 서비스와 조합하던지 아니면 그냥 하나만 사용하던지)만 하는 것이지, A서비스를 사용하기 위해 이런저런 판단(로직)이 필요해서는 안 된다.

2. 서비스 단위의 재사용이 가능한 SOA의 일반적인 구성
<전통적인 구현 방식과 SOA 구현 방식>

전통적인 구현 방식 시스템 구조 기반으로 설계 및 구현. 서비스 환경 변화 및 정책 변화에 대한 대응이 시스템 구조부터 고려되어야 하기 때문에 시간이 소요
SOA 구현 방식 서비스 단위로 분리. 서비스 환경 변화 및 정책 변화 시 서비스 단위들을 조합하거나 또는 신규 서비스를 유연하게 추가하여 신속한 대응이 가능 서비스 단위가 Interface로만 소통이 가능한 Black Box. 수정 시 영향도 적음

물론, SOA의 서비스 단위가 이렇게 유연해 지기 위해서는 아래와 같은 내부 구조가 필요하며, 아래의 관리, 통합, BI야 말로 SOA가 지향하는 바이다.

<SOA 구성도> 비즈니스 프로세스 관리 – 서비스 조합의 결과로 생긴 비즈니스 프로세스 모니터링. 위험감지 및 대응 – 시장 내외부 변화에 대응하는 정책 추가 시 서비스 단위의 재조합을 통한 비즈니스 로직 자동반영
데이터 및 Legacy System 통합 – 서비스 별로 독립된 이기종 DB의 DATA통합 및 활용 위한 Big Data관리. – Legacy System간 호환을 위한 미들웨어 제공
통계/위험관리/미래예측 Business Intelligence – 통합 된 프로세스와 DATA를 이용하여 통계 추출(DATA Warehouse), 환경변화에 따른 위험감지, 미래 예측(Data Mining) 가능하도록 구축

기존 시스템과 데이터 구조를 변경해야 하는 SOA는 더 많은 시너지를 내기 위해 전사적으로 수행해야 하면 그렇기 때문에 단계적으로 진행되어야 한다. 서비스 단위의 구축은 Buttom-Up이어야 하지만 SOA 기반 플랫폼으로의 변화 의지는 Top-Down 으로 진행되어야 한다.

3. 전사적으로 수행해야 하는 SOA 적용 단계

단계 목표 내용 성숙도
No SOA SOA 이해 SOA 필요성 정리 및 사례 연구 단일 비즈니스 프로세스,데이터 통합
SOA 정의 핵심 기능 서비스 단위로 표준화 단일 프로젝트,시스템 통합. 레거시 시스템 주요기능 서비스로 표준화
SOA 전개 이 기종 Legacy System 통합 동일 업무영역 통합. Composite Service 전사 프로세스, 데이터 통합
SOA 성숙 비즈니스와 IT환경 통합 전사 업무영역 및 시스템 통합 Service Orchestration프로세스 자동화 비즈니스 프로세스 자동관리
SOA 완성 변화에 실시간 대응 기업외부 업무영역 및 외부 시스템 통합 서비스 모니터링 및 실시간 반영Package Services Business Intelligence

요즘 우리 회사에서도 OPEN API의 필요성에 대해 많은 사람들이 얘기하고 있으며, 자연스럽게 데이터 및 중복된 시스템들과 업무들에 대한 통합 및 유연한 관리 그리고 데이터에 대한 활용까지 논의되고 있다. 따라서 우리 회사의 단계는 2단계인 SOA 정의 단계라 하겠다.

4. SOA 정의: 단일 비즈니스의 데이터와 프로세스 통합 예시
현재 내가 맡고 있는 비즈니스는 PHP기반의 웹 서비스(ollehmap.paran.com)이며 RDB와 연동되어 있다. 또한 다수의 외부 시스템 및 Legacy System 들과도 연동이 일어나야 한다. 난 향후에 진행 될 타 비즈니스와의 프로세스 및 데이터 통합에 손쉽게 대응하기 위해, 그리고 지속적인 서비스 개편 요청에 유연하게 대응할 수 있는 구조로 현재의 비즈니스 프로세스와 데이터를 통합할 계획이며 일부는 진행되고 있는 상황이다.간단하게 정리하면 개발자라면 누구나 알고 있을 흔하디 흔한 MVC모델을 비즈니스에 적용하는 것으로 SOA의 2단계인 SOA의 정의를 실천하고 있는 것이다. 좀 다른 점이 있다면 controller를 API형식으로 구현한 것이지만 자체적으로 판단해 볼 때 서비스 지향적인 API는 아닌 듯 싶어 개선이 필요하다.올해까지 계획되어 있는 단일 비즈니스의 2단계를 마무리 하면 전사 프로세스와 데이터를 통합해야 하는 3단계 SOA의 전개를 실시해야 한다. 이를 진행하기 위해 해야 할 일은 아래와 같다- 전사 단위 비즈니스의 SOA 정의 단계 완료
– 단위 비즈니스가 관리하는 데이터와 SOA정의 단계의 결과인 API, 프로세스 공유
– 중복되는 데이터, 프로세스, API 식별 및 정리
– 동일 시스템(Legacy System등)에 접근하는 Interface 표준화
– 단일 비즈니스의 서비스를 조합하여 가능한 비즈니스에 대해 Composite Service 구성

5. 맺음말
SOA 진행은 비즈니스(서비스) 외부를 개편하는 것이 아니라 내부인 플랫폼을 개편하는 것이기 때문에 “지금도 잘 돌아가는 걸 왜?” 라는 의문들이 항상 생길 수 있다. 따라서 전사적으로 SOA 필요성에 대해 홍보하고 함께 이해해 나가는 단계가 필요하다. OPEN API가 필요하다고 많이 얘기되고 있지만 제대로 된 OPEN API를 만들기 위해서는 기반이 되는 플랫폼이 잘 통합되고 변화에 유연하게 대처할 수 있도록 관리되고 있어야 한다. 우선은 본인이 담당하는 단일 비즈니스의 플랫폼 부터라도 SOA를 적용하여 개선해 보겠다는 의지가 필요하다.

페이스북 스파르탄 프로젝트의 비밀병기 Bolt.JS

[출처 : kth 웹어플리케이션팀, 2011년11월10일]

웹 서비스와 어플리케이션 개발을 위해 대부분의 경우 jQuery를 사용한다. 가볍고 훌륭한 이 프레임웍은 전 세계 개발자의 열기에 힘입어 거의 웹개발을 위한 표준 프레임웍이 되었다. jQuery 외에도 jQueryMobile과 Sencha Touch, jQTouch 등 몇가지 프레임웍이 더 있고 계속해서 새로운 종류가 등장하고 있다. 그만큼 프론트엔드 개발분야가 다양하다는 것을 시사하지만 프레임워크마다 좋은 점을 내세우고 개발의 편의성과 효율성을 자랑하는 가운데 정작 프레임워크 간에는 어떤 상호 연결성도 없으며 각각의 프레임워크를 위해 제작된 플러그인이나 라이브러리를 목적에 맞게 조절하지 않고는 그냥 가져다 쓸 수 없다. 이런 점 때문에 개발자는 프로젝트에 프레임워크별로 의존성이 생기는 것을 꺼리게 되고 프로젝트마다 저마다의 고유한 라이브러리나 프레임워크를 제작하려는 경향을 보였다.

이런 문제의 근본 원인은 자바스크립트가 중/대형 규모의 어플리케이션 제작이나 재 사용성 확보에 있어 반드시 제공해야하는 ‘모듈화 프로그래밍 구조’에 무게를 두고 설계된 언어가 아니기 때문이다. YUI와 PrototypeJS 에 이어 jQuery를 활용하는 시기가 지나는동안 개발자들은 모듈화 프로그래밍 문제를 해결하기 위해 자체적으로 꾸준한 시도를 해왔으나 폭넓은 사용자 층을 얻지 못하였다. 그러던중, 2009년 1월에 Kevin Dangoor에 의해서 “ServerJS”라는 이름의 프로젝트가 시작되었다. 곧 “CommonJS”로 변경된 이 프로젝트는 웹 브라우저 밖의 환경을 위한 자바스크립트 ecosystem 을 기술하는 것을 목적으로 하고 자바스크립트의 가장 취약한 부분중에 하나였던 ‘모듈화 개발을 위한 API 표준’을 제시하여 중/대형 규모의 어플리케이션 제작에 물꼬를 트게 하였다.

바로 이 CommonJS API 규격을 바탕으로 Facebook에 의해 제작된 Bolt.JS는 공개되자마자 전 세계 개발자의 상당한 관심을 끌었으나 돌연 GitHub등에서 소스가 삭제되고 어떠한 추가 공지도 없이 제대로 작성되지 않은 홈페이지 문서만 제공될 뿐이다. 홈페이지 문서와 관련된 기사를 훝어보던 중, 단순한 UI 프레임워크가 아님을 직감하였고 여러 경로를 뒤진후에 얻은 소스를 분석하였다. 예상대로 공식문서에서 보이는 것보다 훨씬 잠재력이 있다는 것과 웹 어플리케이션 제작에 있어 상당 부분에 영향을 줄 수 있다는 것을 이 리뷰를 통해 기술하고자 한다.

개요:
BoltJS는 오직 HTML5와 자바스크립트만을 사용하여 환상적인 모바일 웹 어플리케이션을 제작하는 것을 도와주는 UI 프레임웍이다. 서버사이드 처리 과정이 필요없으며 자바스크립트로만 작성되어 브라우저에서 동작하는 BoltJS는 현재 모바일 WebKit 기반 브라우저에 맞춰져 있다. 현재 Facebook의 Spartan 프로젝트가 모바일 WebKit에 초점을 맞추고 있기 때문이다.

구조 및 내장 기능:
Bolt.JS는 공개된 베타버전에서만 13,496 라인에 이르는 코드로 작성되어 있으며 다음과 같은 주요 패키지를 CommonJS 규격에 맞추어 자체적으로 포함하고 있다.

도식 1. Bolt.JS 구조

iScroll v4는 모바일용 HTML5 어플리케이션에 스크롤 관련 필수 기능을 제공하며 tokenizerTypeahead는 유용한 입력기능을, underscore.js 는 functional programming에서 쓰이는 고차함수 (higher-order function) 라이브러리로써 모듈성과 템플릿 기능을 제공한다. 이중에 눈여겨 봐야 할 것은 Javelin.JS 인데, 이벤트 처리를 모바일 웹 어플리케이션 제작에 최적화 시킨 프레임웍이다. Javelin.JS는 또 하나의 주제가 되므로 본 리뷰에서는 제외하였다.
또한, 모바일 웹 어플리케이션 제작에 있어 핵심적인 레이아웃과 ‘View’ 라 명명되는 내장 UI가 상당수 제공된다:

도식 2. Bolt.JS UI components

특징: LDAP 처럼 CommonJS 스펙을 구현하였다는 점이다.
서버사이드 자바스크립팅 환경인 NodeJS 역시 CommonJS 스펙에 기반하여 API를 작성하였기에 안정버전이 0.6 이지만 사용가능 모듈수는 2011년 11월 8일 현재 4870개에 달하며 다양한 서버측 요구조건에 맞는 모듈을 쉽게 찾을 수 있다. 2010년 초반에 소개된 NodeJS 가 불과 2년이 되지 않은 시점에서 이렇게 발전할 수 있었던 것은 저마다 제각각의 API를 가졌던 jQuery, ExtJS, YUI는 달리 CommonJS API에 기반하여 모듈을 제작할수 밖에 없는 구조 때문이다. Bolt.JS 역시 표준화된 API 덕분에 어플리케이션 개발자는 서로의 모듈을 손쉽게 가져다 사용할 수 있으며 통합개발환경 (Facebook이 제작한다는 루머가 있지만 확인하지 못하였다) 의 도움을 받아 고수준의 어플리케이션을 손쉽게 만들 수도 있는 것이다.

예제 코드:
전통적인 ‘HelloWorld’를 표시하는 예제를 통해 Bolt.JS의 활용을 살펴보자. 우선, 기존 웹 어플리케이션과는 달리 ‘패키지’ 개념이 있다는 점이 틀리다. 패키지는 .html 파일과 .js, .css 등으로 구성되며 package.json 파일에 JSON 포맷으로 기술되야 한다. 이 역시 CommonJS 요구사항이다.

package.json:

{
“bolt_build_manifest” : [{ “sources”: [ “css”, [“”, “js”]],
“package_target”: “pkg”, // 이름이 ‘pkg’인 폴더를 가리킨다
“package_name”: “helloworld”}] }

– View를 정의하는 helloworld.js:

require.define({‘helloworld’: function(require, exports, module) {

var core = require(‘javelin/core’);
var View = require(‘view’).View;

var HelloView = core.createClass({
extend: View,

declare: function(options) {
return{
content: “Hello World!”
}}
})

exports.init = function() {
require(‘builder’).build({
view: HelloView
}).placeIn(document.body);
}

}});

– Control 을 담당하는 helloworld.js (위의 것과 이름이 같지만 다른 폴더에 있다):

var core = require(‘javelin/core’);
var View = require(‘view’).View;

var HelloView = core.createClass({
extend: View,
declare: function(options) { return{ content: “Hello World!” }}
});

exports.init = function() {
require(‘builder’).build({ view: HelloView }).placeIn(document.body);
}

– 마지막으로, helloworld.html이다 (helloworld.css 파일은 생략):

<html>
<head>
<title>Hello World Application</title>
<meta name=”apple-mobile-web-app-capable” content=”yes”>
<meta http-equiv=”content-type” content=”text/html; charset=utf-8″>
<meta name = “viewport” content=”initial-scale=1,maximum-scale=1,user-scalable=no,width=device-width,target-densityDpi=device-dpi” />
<link rel=”stylesheet” href=”lib/bolt.css” type=”text/css” media=”screen” charset=”utf-8″>
<link rel=”stylesheet” href=”pkg/helloworld.css” type=”text/css” media=”screen” charset=”utf-8″>
<script src=”lib/bolt.js”></script>
<!– HelloWorld JS –>
<script type=”text/javascript” charset=”utf-8″ src=”pkg/helloworld.js”></script>
</head>
<body>
<script type=”text/javascript” charset=”utf-8″>
var helloworld = require(‘helloworld’);
helloworld.init();
</script>
</body>
</html>

단순한 예제여서 Bolt.JS의 특징을 한번에 파악할 수는 없지만, 모듈 기반의 개발방식을 한눈에 알 수 있다. CommonJS 규약을 지키는 Node.JS 모듈을 Bolt.JS의 모듈로써 사용할 수도 있을 것이다. 성공적인 중/대형 규모의 어플리케이션의 특징가운데 하나는 모듈화에 있으므로 Bolt.JS의 API 표준화 정책은 많은 개발자의 참여를 불러일으킬 것이라 예측할 수 있다.

활용:
지정된 프레임워크가 없는 사내 개발환경에 CommonJS 규약에 의한 개발방식은 언뜻 생각해도 몇몇 부분에서 시너지 효과를 가져올 것이라 쉽게 예측할 수 있다:

– 각 부서별/팀별로 중복으로 제작할 필요가 없고, 부서별로 모듈을 유지보수하는 비용이 줄어들 것이다.
– 사내에서 개발하는 것 자체가 글로벌에 적용될 수 있다.

결론:
Apple AppStore에 휘말리지 않겠다는 의지를 보인 Facebook의 행보는 HTML5 어플리케이션 개발의 흐름에 한번더 큰 변화를 가져다 줄 것이며 글로벌 사업을 향하는 여러 업체의 사업방향에도 영향을 줄 것이다. 따라서, Bolt.JS 와 CommonJS 표준화 개발방식을 검토할 필요가 있다는 것을 강조한다.

[ Google TV , Apple TV 그리고 TV의 미래 ]

AdobeMaxK1-3D-immersive

Flash Low-Level 3D API : Molehill 에 대해..

작년 Adobe MAX 2010에서 선보였던 Flash기반 3D API, Codename ‘Molehill’ 에 대해 포스팅 하려고 합니다.
참고사이트 : http://labs.adobe.com/technologies/flash/molehill/

Flash Player 10.2 까지 플래시플랫폼에서 지원하는 3D기능들은 전부 Software Rendering방식으로 구현됩니다. 이는 CPU에 치중된 방식이기 때문에, CPU점유율이 많이 올라가며 좋지않은 퍼포먼스를 보입니다. 그렇기에 Molehill에서 강조했던 가장 큰 기능인 CPU가 아닌 GPU Hardware Accelating 은 차원이 다른 퍼포먼스를 보여줄수 있다는 강점이 있습니다.

주요 특징으로는,
1. z-buffering
2. stencil color buffer
3. vertex shader

이들은 Flash Platform최초로 GPU를 이용한 3D구현하는 공식API라는 점에서 의미가 있습니다.
Windows에서는 DirectX기반으로,  Mac,Linux에서는 OpenGL 1.3, 모바일에서는 OpenGL ES기반으로 작동된답니다. 이도저도 아닌 플랫폼에서는 기존처럼 소프트웨어렌더방식이구요.

아래에는 이를 활용하여 제작된 3D게임들 영상입니다. 퍼포먼스를 확인해보세요~ 깜짝 놀랍니다 ㅋ

MAX Racer – 3D Flash Game with P2P Multiplayer from Tom Krcha on Vimeo.

[하단의 이미지와 링크들은 지돌스타님 블로그에서 발췌했답니다]

Adobe Labs – 3D APIs for Adobe Flash Player and Adobe AIR
Adobe MAX 2010에서 소개된 차세대 GPU 가속 Flash API – Molehill
Molehill Flash Player 3D APIs 소개
Flash Player 3D APIs 간단한 소개글 – 잼있음
[동영상][at MAX 2010] GPU Acceleration on Adobe AIR “Molehill” – 우야꼬 군이 직접 미국에 MAX 행사에가서 찍은 영상입니다.
[동영상][at MAX 2010] Alternativa 3D in Adobe MAX 2010 – 우야꼬 군이 직접 미국에서 Molehill을 체험했군요.
[동영상] Adobe MAX 2010 – Alternativa 3D 시연 – 땡굴이 님께서 Alternativa의 시연모습을 동영상으로 담았습니다.
Molehill Programming Tutorial
ActionScript의 언어 순위는 몇 위일까?

WiFiDirect (1)

Wi-Fi Direct 등장! Bluetooth의 대응은?

이번 CES2011에서 Wi-Fi Direct라는 기술이 주목받고 있습니다.

WiFi Direct는 WiFi Alliance가 개발한 기술로 기존의 Wi-Fi 기술을 활용해 이통망이나 AP없이도 단말기간 빠르고 안전하며 끊김없는 접속을 지원합니다. 이는 기존의 Bluetooth기술을 대체할 가능성이 높으며 실제로 보다 응용할수 있는 기술이나 기능도 풍부합니다.

Wifi Direct는 표준 WiFi기술을 활용하긴 하지만 네트워크 접속방식은 전혀 다릅니다. 즉 기존의 WiFi네트워크나 라우터,AP등을 경유하지 않고 P2P(Peer to Peer)방식을 활용합니다. 뿐만 아니라 기존의 WiFi단말기에도 적용이 가능하며, Bluetooth에 비해 접속범위,반경이 더 넓을뿐 아니라 데이터전송용량 또한 큽니다.

이러한 WiFi Direct탑재 단말은 디지털카메라, 엔터테인먼트 단말, PC등 다양한 단말간 콘텐츠 동기화가 용이해 진다는 장점이 있습니다. 물론 이러한 기술을 위해서는 보다 강력한 보안기술이 필요할 것입니다.

앞서 소개했던 Zigbee, Bluetooth등의 모든 장점을 포함할수 있을것으로 보여, PAN(Personal Area Network)을 구성하는데도 좋아보입니다. 이제 슬슬 제가 꿈꾸는 디지털라이프가 점점 현실로 다가오는군요. 기기간의 커뮤니케이션! 아~ 기대됩니다 ㅎㅎ

” [http://predicto.tistory.com/63, Predicto님 블로그에서 일부글 발췌했습니다]

Wi-Fi Direct는 탑재된 디바이스는 이전의 Wi-Fi 단말과 자유롭게 통신이 가능합니다. 기존의 Wi-Fi 규격인 802.11 a/g/n을 그대로 사용합니다.

기존의 Wi-Fi 디바이스들은 제조사의 software upgrade만으로 Wi-Fi Direct 기능이 제공 가능합니다. H/W 교체가 필요하지 않습니다.

일부 디바이스들은 Wi-Fi 네트워크와 Wi-Fi Direct 네트워크에 동시에 접속할 수 있습니다. 또한, 이 디바이스를 통해서 Wi-Fi Direct 네트워크에 연결된 다른 디바이스들이 인터넷을 사용할 수 있습니다. 예를 들어, 노트북을 Wi-Fi AP로 만들어서 여러 대의 스마트폰이 노트북을 통해서 인터넷에 접속하도록 할 수 있습니다.

Wi-Fi Alliance 멤버 회사의 제품에서만 Wi-Fi CERTIFIED Wi-Fi Direct 기술이 지원될 것이라고 밝히고 있지만, 애플, 인텔, MS, 시스코, 소니, 삼성 등 저희가 아는 회사들은 대부분 Wi-Fi Alliance 멤버이므로 대부분의 디바이스에서 Wi-Fi Direct 기술이 지원될 것으로 예상됩니다. “

WiFi Direct를 사용하기 위해서는 기존의 WiFi의 경우 펌웨어 업데이트가 필수적이라고 하며, Apple도 Wi-Fi Direct에 합의하고 iPhone, iPod 등에 이 기술을 적용할것이라고 알려지고 있습니다.

앞으로 몇년안에 집안의 모든 이더넷케이블이 사라질거 같습니다. 거실의 이더넷포트에 WiFi AP만 하나 설치해놓고, 다른 모든 기기들은 WiFi를 사용하게 되는 때가 곧 올것입니다. STB, 인터넷전화, 데스크탑, 노트북, 스마트폰, 냉장고, TV등 모든 기기가 WiFi를 사용하는 날이 머지않았습니다.

images

미래의 모바일기술에 대한 고민 #5 – 네트워킹편

현시점에서 모바일에서 이용가능한 통신방식은  2G(GSM,CDMA)/3G(IMT)/4G(LTE Advanced), WiFi, Bluetooth, IrDA, RFID, NFC, GPS 정도가 있을것 같습니다. 혹시 빠진 내용이 있다면 댓글로 부탁드립니다 ^^

* Celluar Network

휴대폰에서 기본적으로 사용하는 2G, 3G, 4G에 대해서는 많이 들어보셨을겁니다.
1995년 세계최초로 CDMA다중 접속기술을 사용하는 이동전화시스템을 상용화한 이래로 PCS(GSM, PHS, AMPS, IMT-2000, TDMA,FDMA 등이 이와 같은 범주에 속함) 기술들이 등장했었고, IMT-2000이라는 3세대(3G) 방식이 등장했습니다.
당시 IMT-2000 의 등장으로 전세계가 떠들썩했었죠. 단일화된 공통의 규격으로 어디에서나 자유로운 로밍서비스를 제공한다는 것과 고속의 데이터서비스를 통해 서비스의 질을 높인다는 것이었습니다. 이와 함께 무선규격은 셀룰러통신방식에 탁월한 성능을 가지는 CDMA방식으로 간다는 대원칙도 있었습니다.

지금 시점에서는 이러한 단일규격의 원칙은 찾아보기 힘들며 3G에서도 GSM방식과 CDMA방식으로 양분되었습니다. 2.5세대급인 CDMA2000은 HSPD(High Speed Packet Data)라는 고속데이터 서비스를 통해 350Kbps이상의 전송률(DTP)을 제공하며, EV-DV의 경우는 2Mbps정도의 전송률을 제공합니다.

3G와 4G의 차이점은 특정한 기술의 이름이 아니라 속도에 따른 세대의 구분입니다.  ITU(국제전기통신연합)기구에서 모바일네트워크의 전송속도에 따라 결정하는데, 이는 같은 4G에도 여러기술이 존재할수 있음을 의미합니다.
3G는 ITU에 의해 144k~2Mbps의 전송속도로 규정됐습니다. KT의 Show, SK의 T, LG의 OZ등이 3G에 속하는데 전부 다른기술기반을 가집니다. 4G는 정지중 1Gbps, 이동중 100Mbps의 속도를 가질것으로 규정되었습니다. 기존 아이폰4에 대한 네이밍에 대한 논란이 있었습니다. 보통 애플제품에 붙이는 Generation이라는 단어가 네트워크세대를 표현하는 단어와 같아서 발생했던 문제였죠.
iPhone 4G(4세대) 제품이 네트워크4G를 지원하느냐라는.. 결국엔 iPhone 4라고 네이밍을 했구요. 진정한 4G는 iPhone 5가 될것 같습니다. 현재 통신사에서 4G서비스를 하는곳이 없으니까요.(미국의 Sprint사가 가장 빠르게 대응하는거 같더군요)

하단의 이미지는 대표적인 4G기술입니다. LTE는 많이 들어보셨을거구요. 국내 대기업에서도 많이 참여하고 있답니다.

* LTE (long-term evolution), UMB (ultramobile broadband), and WiMAX II (IEEE 802.16.m)

4G and the ITU

* Protocol Layer

유선환경에서 사용하는 물리계층 Protocol은 Ethernet이며 Network, Transport 계층은 TCP/IP를 사용합니다. 무선환경에서 사용하는 물리계층 Protocol은 Ethernet이 아닌 Bluetooth, Wireless, Zigbee등이 사용됩니다. 이처럼 물리계층의 프로토콜이 다름에도 불구하고 유/무선 네트워크는 실제로 많은 공통점을 가지고 있습니다.

유/무선의 Network/Transport계층의 프로토콜이 아예 같거나 전송방식 자체가 매우 유사한데, TCP에 대해 간단히 살펴볼 필요가 있습니다. TCP의 중요요소를 대략적으로 구분하면 크게 Source Address, Destination Address, Source Port, Destination Port, Session 이렇게 5가지로 나눌수 있습니다.

Session은 Source/Destination간의 상호 안정적인 통신을 보장하기 위해서 존재합니다. Session은 호스트 간에 상호 통신시 데이터가 정확하게 전달되었는지 확인할 수 있는 기능도 제공하지만, Source와 Destination간의 연결 과정이나 연결 유지에 대한 보안적인 측면에서의 신뢰성도 보장합니다. 즉, 쉽게 표현하면 Source와 Destination이 연결되었다고 가정했을 때, 제 3자는 이들의 연결에 함부로 끼어들 수 없는 기능을 제공합니다.

무선 Network 환경에 쓰일 수 있는 매개체는 다양하게 존재합니다. 모두 무선이라는 연결 매개체를 사용한다는 공통점이 있으나 사용하는 주파수가 다르고, 또 주파수 영역마다 특징이 존재하기 때문에 각각 특성에 맞는 활용 분야가 따로 존재합니다. 예를 들어 어떤 주파수는 전송 거리가 짧거나 어떤 주파수는 한번에 전송될 수 있는 데이터 용량이 적기도 합니다.

무선 Network의 활용도는 매우 광범위하기 때문에 각각의 무선 매개체가 활용될 수 분야에 대한 표준 같은 것이 정해진 것은 아닙니다. 아직까지도 Protocol에 대한 표준 재정 작업이 진행중인 것도 있으며 종전에 촉망 받던 매개체가 여러 가지 문제점이나 혹은 보다 나은 매개체의 등장으로 인해 바뀌기도 합니다.

1. Wireless LAN Network

몇년 사이에 Wireless를 이용한 무선 네트워크는 많은 사람들에게 이용되며 각광받고 있습니다. 무선 Protocol의 표준기술을 가리켜 IEEE 802.11이라 부릅니다. 이는 유선에 비해 이동성, 비용, 유연성등의 장점이 있습니다. (Wi-Fi 라고 명칭하기도 합니다)

IEEE 802.11 (b)
Power Profile Hours
Complexity Very Complex
Nodes/Master 32
Latency Enumeration up to 3 seconds
Range 100m
Extendability Roaming possible
Data Rate 11Mbps
Security Authentication Service Set ID (SSID)

2. Bluetooth Network

비교적 저렴한 생산비용과 확장성, 그리고 유연성적인 측면에서 높은 평가를 받고있고, 실제로 많이 사용되고 있습니다. Wi-Fi에 비해서 일반무선네트워크에 쓰이기엔 부족한 전송속도를 갖고 있으며, Zigbee와 비교하여 홈네트워크에 쓰이기엔 높은전력소모와 생산비용을 갖고 있지만, 그 중간단계의 활용분야에서 많이 사용되고 있습니다.

Bluetooth
Power Profile Days
Complexity Complex
Nodes/Master 7
Latency Enumeration up to 10 seconds
Range 10m
Extendability NO
Data Rate 1Mbps
Security 64 bit, 128 bit

3. Zigbee(Zigzag+Bee의 합성어) Network

앞으로 가정내에서 사용하는 가전제품에도 컴퓨팅능력이 들어갈 것이라고 많은 사람들이 말하고 있으며, 실제로도 몇몇 제품들이 실제로도 사용되고 있습니다. 예를 들어 집 밖에서 원격으로 보일러를 조정하여 방안의 온도들을 설정할수도 있습니다. 또한 가전 제품들이 컴퓨팅 능력을 갖춤으로써 서로 간의 통신을 통해 여러 가지 편리한 점들을 누릴 수도 있습니다. 집 주인이 집에 들어왔을 때 집에 들어온 현재 시간을 파악하여 주인이 선호하는 TV 채널을 자동으로 틀게 하는 것도 좋은 예입니다.

Zigbee
Power Profile Years
Complexity Simple
Nodes/Master 64000
Latency Enumeration 30ms
Range 70m~300m
Extendability YES
Data Rate 250Kbps
Security 128bit AES and Application layer user defined

4. RFID Network

RFID는 일반적으로 13.56Mhz대역, 그리고 UHF대역인 860~960Mhz영역이 가장 많이 활용됩니다. 이는 물류네트워크에서 많이 사용되는데 RFID Tag을 물품이나 물류등에 붙여서 사용될수 있습니다. 이 Tag안에는 EPC(Electronic Product Code)라는 것이 존재하여 상품의 제조일,특징 등에 대한 정보를 포함하고 있습니다.

4-1. NFC (Near Field Communication) – RFID Extension

NFC는 초단거리 무선통신 기술로 대략 10cm이내의 기기간에 통신을 가능하게 해줍니다. ISO/IEC 14443 proximity-card standard(비접촉카드 또는 RFID)표준을 확장한 것으로 스마트카드와 리더기를 하나로 합쳐놓은것이라고 생각하면 됩니다.
ISO/IEEE 14443표준을 확장한 것이기 때문에 NFC디바이스간 뿐 아니고 기존의 ISO/IEEE 14443리더기나 스마트카드와도 통신을 할수 있습니다. NFC는 기본적으로 휴대폰에서 사용할 목적으로 만들어졌습니다.

– 13.56MHz의 ISM밴드에서 14KHz의 대역폭을 사용
– 최대 동작 거리: 20cm
– 지원하는 통신 속도: 106, 212, 424, 848 Kbit/s
– 동작모드: Passive, Active

현재 NFC는 주로 휴대폰에서 사용되는데 3가지 방식으로 동작하고 있습니다.

– 카드 에뮬레이션: NFC디바이스(휴대폰)이 기존의 RFID카드와 같이 동작한다. 즉 리더기에 기존의 카드 대신 휴대폰을 가져다 대면 된다.
– 리더 모드: NFC디바이스가 카드 리더기로 동작하는 모드이다.
– P2P 모드: 두대의 NFC디바이스가 서로 통신하는 모드이다.

이렇게 3가지 모드를 지원하기 때문에 NFC디바이스는 매우 다양한 방법으로 사용할 수 있습니다. 휴대폰이 교통카드, 문 열쇠등으로 동작(카드 에뮬레이션), 미술관, 박물관 등에서 작품에 휴대폰을 가까이 가져가면 해당 작품의 소개로 연결하기, 스마트카드 결제 단말기(리더모드), 휴대폰간 명함 교환 (P2P 모드)등등이 가능해집니다.

그리고 통신거리가 매우 짧기 때문에 보안 문제도 간단해지고 통신을 위한 초기 셋업타임이 매우 짧은것이 (0.1초 이하) 최대의 장점입니다.

NFC에 대해서는 다음에 좀더 자세히 포스팅하도록 하겠습니다.

thumbnails

IE6, 이제는 우리가 헤어져야 할 시간!

 

출처 : http://gsinews.co.kr/ArticleView.asp?intNum=11800&ASection=001014

구글은 올해 초 IE6(Internet Explorer 6, 이하 IE6)에서는 자사의 새로운 기능이 동작되지 않을 수도 있다고 발표했다. 세계적인 사이트인 페이스북, 트위터, 유튜브 또한 IE6 지원을 중단했다. 국내 대형포탈 사이트인 네이버, 다음, 네이트 등은 아직 IE6를 지원하고 있지만, 지속적으로 IE6 사용중단 캠페인을 벌이고 있는 상황이다.

▲ IE6로 페이스북에 접속했을 때 오류화면

IE6, 왜 문제인가?

IE6가 도대체 무슨 문제를 가지고 있기에 해외 유명 사이트들은 다들 지원 중단을 외치는 것일까?

IE6 문제점의 첫 번째는 보안 취약점이 있다는 것이다. IE6는 보안에 취약해 액티브X를 통한 악성 애드웨어, 스파이웨어와 같은 악성 애플리케이션을 걸러내지 못하고 설치하게 된다. 실제로 올해 초, 마이크로소프트는 이러한 IE6의 보안 문제를 인지하고 조사에 착수했었다. 게다가 보안 취약점에 대한 빠른 대응이 반드시 필요하다 보니 마이크로소프트에서도 최신 버전인 IE7이나 IE8을 먼저 대응하고, 그 이후에 IE6의 보안취약성 문제를 해결하기도 했었다.

두 번째 문제는 웹 표준화를 따르지 않는다는 점이다. IE6는 2001년에 Windows XP와 함께 등장했다(무려 9년이 지났다!). 그 당시에는 웹 표준화라는 개념이 크지 않을 때였지만, 현 시점에서는 많은 브라우저들이 웹 표준화를 준수해서 개발되었다. 그러다 보니 IE6 기반으로 만든 웹사이트들은 IE6을 제외한 다른 웹 브라우저에서는 정상적으로 보이지 않을 가능성이 있다. 이는 웹 개발자들로 하여금 IE6 웹 사이트의 수정 작업에 많은 시간과 자본을 투자하게 만들어 웹 서비스를 하는 회사의 손실로 이어지게 된다.

그런데 왜 한국만 아직도 IE6를 지원하는 걸까?

국내 사이트들도 사실은 해외 사이트처럼 IE6 지원을 중단하고 싶은 마음은 굴뚝같을 것이다. 그렇지만 현실이 그렇지 않다는 게 문제이다.

▲ 전세계 브라우저별 점유율 비교(StatCounter Global Stats 2010년 10월)

그림에는 나타나지 않았지만 사용률 추이 또한 계속 내려가고 있는 상태다. 하지만 국내는 그렇지가 못하다.

[그림 3]의 국내 브라우저 점유율 그래프를 보면 알 수 있듯이, IE 점유율이 극단적으로 높고 IE6 점유율도 30%가 넘는 상태이다. 이렇게 많이 사용하고 있는 브라우저이다 보니 지원중단을 쉽게 결정할 수 없는 것이다. 게다가 다른 경쟁사에서 모두 IE6를 지원하고 있는데, 혼자서만 IE6를 지원하지 않는다면 고객만 잃을 것이 뻔하지 않겠는가. 그래서 국내 대부분의 사이트들은 IE6 사용 중단 캠페인을 하면서 사용자가 스스로 IE6를 사용하지 않도록 호소하고 있는 것이다. 하지만, 공공기관 등에서 사용하는 시스템이 아직도 IE6, IE7만 지원하는 경우가 있어서 쉽사리 IE8 나 Firefox, Chrome 등으로 바꾸기도 힘든 것이 현실이다.

▲ 국내 브라우저별 점유율 비교 (StatCounter Global Stats 2010년 10월)

IE6, 이제 그만 사용하자!

얼마 전에 인터넷 한 사이트에서는 ‘개발자 좀 살려주세요. 제발! (Save the developers)’ 캠페인도 벌이면서 IE6 사용 중단을 외친 사례가 있었다. 게다가 이찬진 드림위즈 대표가 트위터와 페이스북에서 IE6, IE7을 사용하지 말자고 호소해 화제가 되었다. 이찬진 대표가 이렇게 호소한 이유는 이런 브라우저는 나온 지 오래돼 해커들이 보안 취약점을 낱낱이 알고 있어 해킹 당할 위험이 크기 때문이다.

필자의 마음으로는 마이크로소프트가 강제적으로 IE6를 제거하고 새 버전의 IE로 업데이트 해줬으면 좋겠다는 생각도 들지만 그건 현실적으로 힘든 얘기라 생각된다. 그럼 어떻게 해야 할까? IE6 점유율이 10% 이하로 떨어질 때까지 계속 캠페인을 하면서 기다려야 하는 것일까?

개인적인 의견으로는 대형 포털이나 게임 업체들이 IE6 사용 중지를 하는 이용자들에게 당근을 줄 수 있는 방법을 적극적으로 찾아보면 좋겠다. 그리고 한두 개 회사에서 주도적으로 해결할 부분이 아니므로, 관련 업체들끼리 연대를 해서 IE6 퇴출 캠페인을 대대적으로 벌이고, 공식적인 지원중단 일정을 마련해서 공포하면 좋겠다는 생각도 든다.

마지막으로 주변에서 IE6를 사용하는 사람을 발견한다면, 더 안전하고 좋은 최신 브라우저로 바꾸도록 권유해 주시길 기대한다.

ARM-logo

미래의 모바일기술에 대한 고민 #4 – CPU편

IBM-PC/Mac 등의 데스크탑PC에서의 CPU(중앙처리장치)는 인텔과 AMD 두회사가 거의 시장을 장악했습니다. 물론 CPU제조업체가 이 두회사만 있는 것은 아닙니다. 하지만 현 시점에서 일반 가전제품/AV기기/게임기 시장외에 PC시장에서는 이 둘이 모든 시장을 장악하고 있다고 보는게 맞습니다.

보통 사람들은 CPU의 Clock속도만으로 성능을 판단합니다. 하지만 CPU의 성능을 계산 하는 방법은 Clock 과 동시처리연산수, 이렇게 2가지를 고려해야 합니다. 3Ghz이상의 CPU가 안나오고 있는 이유이기도 하죠.

CPU성능  =  CPU Clock x CPU 개수(Core개수) x Clock 당 부동소수점 연산 회수

과거 100Mhz짜리 CPU에서부터 10여년만에 2~3Ghz클럭의 CPU가 등장했지만, 최근에는 클럭자체가 높아지지 않는 이유는 고클럭의 CPU의 한계때문입니다.
이는 이전 포스팅에서 다루었던 실리콘소자의 한계점이라고 할수 있습니다.  실리콘이 아닌 다른 소자를 사용한다면 더 고클럭으로 갈수도 있겠죠. 어쨋든 현재로써는 이러한 한계점과 전력소모면에서 문제가 있기때문에, 멀티코어로 방향을 선회했다고 볼수있습니다.

낮은 클럭의 멀티코어를 사용하게 되면서, 효율적인 연산을 위해 Cache관리/Pipeline의 증설,효율화를 신경쓰게 되었고 이는 프로그래밍기법면에서도 하드웨어 기반지식이 필요하게 된것입니다. (주로 쓰레드나 멀티태스킹 기법을 의미하겠죠.)

지금까지 CPU에 대해 간단히 설명했습니다. 여기에서 모바일용 CPU가 대두되기 시작하면서 약간은 판도가 달라졌습니다.
기존엔 가장 빠른 CPU, 성능이 좋은 CPU가 인정받았으나, 모바일에서는 성능도 물론 중요하지만 기기의 특성상 배터리사용량을 신경쓰지 않을수 없는거죠. 배터리산업분야도 많은 발전이 있었으나, 무제한으로 쓸수도 없는 상황이다보니 배터리에 다른 스펙들을 맞춰야 되는 상황이 벌어집니다.

Intel에서 나온 넷북용CPU인 ATOM은 기존에 비해 전력소모가 많이 줄어든것은 사실이나,  스마트폰용으로는 적합하지 않는다고 업계는 판단한 모양입니다. 이에 각광받은 기업이 바로 “ARM”입니다.

최근 거의 모든 스마트폰에 탑재되는 프로세서는 ARM프로세서인데 ARM은 반도체 전문 제조, 설계업체입니다. ARM CPU에 뿌리를 두고있는 요즘 대부분의 스마트폰들은 Cortex시리즈를 탑재합니다. Cortex CPU중 몇몇 종은 매우 적은 저전력에서도 높은 동작속도(Clock)을 주어 소형단말기에 매우 용이하다고 평을 받고 있습니다.

ARM아키텍셔 Cortex-A8 CPU

애플에서 만든 A4 CPU

Qualcomm에서 개발한 스냅드래곤

SAMSUNG에서 개발한 ARM기반 CPU

그리고 모바일CPU시장에서도 2세대로 나뉘게 되는 멀티코어CPU들이 등장하기 시작했습니다.
듀얼코어 ARM Cortex-A9 CPU를 채택하여 보다 적은 전력으로 1080p HD급 영상까지 재생가능할 정도로 성능은 좋아졌습니다. Nvidia, Marvell, Samsung.. 등 여러업체들이 이미 듀얼코어 CPU들을 출시했으며, 구글의 android 3.0인 허니콤에서는 멀티코어CPU를 기본사양으로 권장하고 있습니다. 2011년도 스마트폰에는 대부분 이 듀얼코어CPU를 탑재할 것이며 아이폰5도 이를 장착할것이라는 루머가 돌고있습니다.

최근 삼성에서 개발한 듀얼코어CPU - 코드네임 '오리온'

Nvidia에서 나온 듀얼코어CPU 'TEGRA 2'

SOC 반도체칩 회사인 마벨(Marvell)이 스마트폰용 CPU 시장의 게임의 법칙을 다시 쓰고 있습니다. 마벨은 이제 막 듀얼 코어 아키텍처가 도입되고 있는 스마트폰용 CPU 칩 시장에 코어가 3개인 트리플코어 SOC 애플리케이션 프로세서 칩을 출시하여 경쟁사들을 바짝 긴장시키고 있습니다. 마벨이 출시한 Armada 628 애플리케이션 프로세서(application processor)칩은 세계에서 처음으로 아키텍처의 서로 다른 프로세서 코어를 하나의 실리콘 다이에 집적한 스마트폰용 이종집합(heterogeneous) 트리플 코어 CPU 프로세서 칩입니다. 이 칩을 구성하고 있는 핵심 부위인 같은 아키텍처 구조의 코어 2개는 1.5GHz 데이터 처리속도로 초당 2억 개의 삼각형을 처리하는 그래픽 처리 등 멀티미디어 기능을 수행할 뿐만 아니라 1080p 풀 HD급 해상도의 3차원 동영상 화면과 그래픽을 처리해 줍니다. 이는 두 개의 코어가 각각 두 방향에서 1080p 해상도의 영상 프레임을 동시에 처리해주기 때문에 동영상 속의 물체가 3차원으로 보이는 원리입니다. 우리가 물체를 입체적으로 볼 수 있는 것은 두 눈이 물체를 보는 시점과 각도가 미세하게 다르기 때문인 것을 감안한 3차원 동영상 묘사 기술입니다. 삼성의 스마트폰 갤럭시S에 사용된 허밍버드 애플리케이션 프로세서가 초당 9천개의 삼각형을 처리할 수 있다고 하니Armana 628 칩의 그래픽 처리 성능이 얼마나 뛰어난지 상상이 갑니다. 이 두 개의 코어와 아키텍처 구조가 다른 세 번째 프로세서코어는 소비전력을 최소화하면서 각종 멀티미디어 처리 명령어를 최대한 빠르게 처리하도록 도와주는 컨트롤러 기능을 합니다. 이 칩이 1080p 풀HD급 동영상을 최대 10시간 이상 동안 재생할 수 는 것은 바로 이 세 번 째 코어의 힘입니다. 음악 파일은 최대 140시간 이상 재생할 수 있다고 합니다. 이 칩은 또한 USB3.0 스펙을 지원하는 최초의 모바일 기기용 SOC 칩이라고 합니다.

이러한 멀티코어를 스마트폰에서 채용하게 되면, 웹페이지에 들어가는 Javascript, Flash등을 CPU마다 독립적으로 처리가 가능해지며, Apple에서 더이상 퍼포먼스를 이유로 Flash를 거부할 이유가 없어지겠군요. 같은 작업을 하는데 더 적은 전력을 소모하고, 사양높은 게임들이 구동가능해 지며, 빠른 멀티태스킹과 높은반응성, 부드러운UI가 가능해집니다. 위의 그림중 Marvell이 개발한 ARMADA는 트리플코어 CPU로써 현재 갤럭시S에 탑재되있는 CPU는 초당 폴리곤을 9000개밖에 처리못하는 반면, ARMADA는 2억개의 폴리곤을 처리가능합니다.

ps. 일반PC의 CPU하고 다르게 모바일CPU는 GPU처리까지 같이 합니다.

내년쯤엔 쿼드코어, 하이퍼쓰레딩 같은 CPU기술들도 스마트폰에 적용되지않을까라는 예상을 해봅니다. 진짜로 내손안의 PC라는 말이 무색하지 않을 것 같군요.

MS의 클라우드 컴퓨팅 플랫폼 - Windows Azure

미래의 모바일기술에 대한 고민 #3 – 서비스편

서비스부분에 대해서는 사실 모바일은 새로운 기회를 제공해준것은 부정하지 않지만,  서비스의 본질적인 부분에 있어서는 그 주체가 아닙니다. 엄청나게 빠른 속도로 변화하는 여러것들 중에 현재 웹은 갖가지 대안이 튀어나와 앞으로의 웹은 자신이 중심이라고 얘기합니다.

트위터, 페이스북, 마이스페이스, 구글버즈, 갖가지API들 …  HTML5, 실버라이트, 개선된 플래시, 모바일기기가 발달함에 메신저는 인간과의 밀착성이 떨어짐으로써 효용성이 떨어지며, 무선데이터통신의 자연스런 발로로 인해 소셜네트워킹이 대세를 타고 있습니다. 앞으로의 웹은 포털로부터 웹이 시작되는 것이 아니라, 늘 움직이고 변화하고 이동하는 사람으로부터 웹은 시작한다고 말합니다.
다시 말해 정보를 얻기위해 누군가와 대화하기 위해, 어떤정보를 나누기 위해 포털로 들어가는 것이 아니라 나에게 나를 공유하며, 나에게서 필요한 지식이 파생되며, 이또한 공유되며, 발췌된 정보가 쌓이며, 지극히 개인적일수도, 주관적일수도 있는 정보와 경험, 지식, 커뮤니케이션이 웹속의 나에게 축척되고 또 그것이 내가 되며, 또 그것이 나를 따라다닙니다.

간단하게 말해 지극히 소규모적인 네트웍이 중규모, 대규모를 이루며, 작게는 개인화된 웹에서 소셜네트웍은 핵분열하듯 파생된다는 것입니다. 이건 정말 말이 어려울뿐 지극히 세포분열이나 핵분열과 같은 양상을 띄고있는 웹의 실체를 더욱 공고히 하는 것뿐입니다.

Facebook F8 Keynote by mark zuckerburg #1

Facebook F8 Keynote by mark zuckerburg #2

Facebook F8 Keynote by mark zuckerburg #3

Facebook F8 Keynote by mark zuckerburg #4

Cloud Computing

Google AppEngine은 요청/응답 형태로만 사용이 가능하지만, MS Azure는 Worker Role을 통해 사용자 요청없이도 혼자 작업진행이 가능한 서비스 구현이 가능합니다. Amazon EC2는 가상서버를 지공하기 때문에 문제가 전혀 없습니다.(MS,Google대비 비용이 많이 들어감)

Microsoft의 Azure프로젝트

MS의 클라우드 컴퓨팅 플랫폼 - Windows Azure

MS에서 생각하는 3Screen전략이란 Live(컴퓨터) – XBox(TV) – WindowPhone7(모바일)  이렇게 3스크린을 완벽하게 지원하는 최초의 클라우딩 시스템입니다. 엑박은 지금까지는 단순한 ‘게임기’였지만, 미래에 MS가 꿈꾸는 XBox는 사실 TV시장으로의진출입니다.

2010년 11월경부터  XBox를 통한 IPTV가 서비스됩니다. 거기에 추후 윈도우폰7의 어플을 IPTV로도 사용이 가능할 예정입니다. 이는 요즘 뜨겁게 인터넷을 달구는 ‘스마트TV’입니다. MS는 남들에게 광고하지않지만 은근슬쩍 스마트TV시장에 끼어들기 시작한겁니다.

IPTV를 어렵게 생각할수도 있지만, 쉽게 말하면 드라마/영화 등 영상물을 위한 온라인마켓입니다. 기존 마켓플레이스의 연장선이죠. 거기에 컴퓨터와 윈도우폰7에서도 사용이 가능하다는 겁니다. 단순히 유투브,iTV등을 통한 영상매체서비스를 제공하는 다른 회사와 달리 MS는 HD급의 드라마와 영화를 제공하게 됩니다. 이는 DMB쪽에서는 부실할수밖에 없는 윈도우폰의 한계를 뛰어넘은 것이라고 볼수도 있을겁니다. 거기에 ‘게임까지 되는 IPTV단말기’, ‘TV까지 볼수 있는 게임기’라는 이중적인 면모는 마케팅에도 큰 도움이 될것같습니다.

윈폰7의 핵심기능은 전부 Live기반입니다. Live체제를 기반으로 한 SNS서비스, Live체제를 기반으로한 모바일 Office, XBox Live를 기반으로 한 윈폰7 XBox, June서비스를 기반으로 한 윈폰 마켓플레이스.

윈폰7이 가지는 가장 강력한 경쟁력은 디자인이나 반응속도 같은 것이 아닙니다. MS가 그렇게 떠들고 다닌 ‘강력한 자원’이란 그들의 개발소스나 경제력이 아닌, 그들이 지금까지 구축한 방대한 기술력이란 것입니다. 이번 WP7이 망하게 되면 MS는 스마트폰시장에서 설자리가 없게 되지만, 그들은 절대 WP7을 포기하지 않을 겁니다. 왜냐면 윈폰7은 MS의 궁극적인 목표인 완벽한 클라우딩 시스템의 필수불가결의 요소이고, 그 핵심이기 때문입니다.