본문 바로가기
IT/Software/Google

구글의 미래 소프트웨어 전략

by 에비뉴엘 2012. 8. 13.
반응형


● Web 프로그래밍 vs 네이티브 프로그래밍 
 
 프로그래밍 세계에서 몇 년 최대의 관심사가되고있는 것은 "Web 프로그래밍 갈 것인가, 네이티브 프로그래밍 갈 것인가 '라는 선택의 문제이다. 이것이 햄릿의 제안과 같이 프로그래머에게 최고의 선택이되고있다. Web 프로그래밍면 어플리케이션을 휴대용이 될 수도 있지만 네이티브 코드가 아닌 성능을 낼 수 없다.

 그리고 프로그래밍의 흐름에서 보면 기본에서 Web 프로그래밍으로 점점 흐르고있는 것으로 보인다. 미국 등에서는 Web 프로그래밍에 발전진척이 급속하게 진행되어왔다. 상징적인 것은 Adob​​e가 모바일 버전의 Flash Player를 종료하고 HTML5에 주력한다고 지난해 (2011 년) 11월에 발표한 것이다.

 이런 상황에서 네이티브 코드로 써 온 소프트웨어 개발자가 Web 프로그래밍로 옮겨야하는지 고민을 하는 상황이 발생하고있다. 거기에 기본 어플리케이션 대부분이 곧 Web 어플리케이션으로 대체하는것에는, 한 가지 의문점이 숨어있다. Web 프로그래밍의 강력한 추진자인 Google은 이 점에 대해 어떻게 생각하고있는 것이다. 


 "내 견해는, Web 어플리케이션이 기본 어플리케이션을 대체할 같은 것은 아니다. 어플리케이션의 미래는 매우 명료하고, 클라우드 어플리케이션으로 향한다. 모든 어플리케이션, 클라우드 어플리케이션이 될 것이다. 어플리케이션이 Web 또는 네이티브가 아니라, 클라우드 측에 바로 초점이있다.

 그리고 각 장치에 이르기까지, 클라우드 어플리케이션 클라이언트 소프트웨어를 어떻게 쓰는가에 대한 프로그래머는 선택이있다. 개발자는 클라우드 어플리케이션을 작성하는데, Web 기술과 기본 기술을 결합 것이다.

 예를 들어, 개발자는 클라우드 어플리케이션을 Web 어플리케이션으로 작성하고 모든 장치에서 작동하게 하는 것이다. 브라우저가 탑재된장치라면, 클라우드 어플리케이션처럼 접근할 수있다. 한편 한 개발자는 클라우드 어플리케이션을 브라우저뿐만 아니라 네이티브 어플리케이션 쓰는 것이다. 스마트폰과 태블릿으로 실행할로만 네이티브 어플리케이션한다고하는 선택이다.

 Gmail이 좋은 예다. Gmail은 Android에서는 네이티브 어플리케이션이지만, 브라우저에서 Web 어플리케이션으로서도 작동한​다. 그러나 사용자 입장에서는 모두 같은 Gmail이다. 우리가 추진하고있는 것은 뛰어난 클라우드 어플리케이션을 만들 수있다. 그 점을 잊지 말라. Web 어플 대 네이티브 어플리케이션적인 대립의 견해는 잘못된 접근이라고 생각한다. 모두가 클라우드로 향하는 방향은 매우 명료하고, 이러한 변화는 향후 몇 년 동안 눈에 띄게되어가는 것이다. "

 Google의 견해는 일반이다. 중요한 부분은 백그라운드 서버 엔진 (Google App Engine한다)에 있고, 클라이언트는 없다. 그리고 클라이언트 쪽 프로그래밍, Google은 대안을 제공한다.


● 프로그래밍 모델 선택을 펼친다 
 
실제로 Google의 프로그래밍 모델은 Web 프로그래밍 통일되어있는 것은 아니고, Android는 Dalvik VM 모델이 표준으로되어있다. 또한 네이티브 프로그래밍 모델, Android에서 "NDK (Native Development Kit)", Chrome에서 "Native Client"를 제공하고있다. 선택이있다.

  프로그래머에게 선택권을 주는 Google의 개념은 명확하지만, 그래도 어플리케이션 개발자는 Google의 프로그래밍 모델의 분단은 귀찮다. 특히, Chrome의 Web 프로그래밍 모델과 Android의 Dalvik 모델의 차이는 크다. 클라우드 서비스는 좋지만 현재의 클라이언트 달리는 어플리케이션의 경우는 전혀 다른 모델이된다.

 "확실히, 응용 프로그램 모델은 2 종류가있다. 예를 들어, Android의 Google Play 속에서 클라우드 Play Music (음악 서비스), Play Movies (영상 전달 서비스) 그리고 Play Books (전자책)은 중 도 Chrome도 제공되고있다. Chrome에서 버전에서 Android처럼 사용할 수있다. 그러나 Android 응용 프로 그램인 Play Apps는 다르다. Chrome는, Chrome 어플리케이션이있다.

 현재는 2 개의 다른 응용 프로그램 모델이되어있다. 하지만 저희는 사용자 중심이므로 두 모델을 각각 융합시켜가는 것은 말이있다. 지금은, Chrome를 Android 겨우 제공한 단계다. 모든 것은 향후 말이지 "(Pichai 씨).

 이전에는 Web 프로그래밍 모델을 완전한 형태로 가지고 올만한 기능을 모바일 장치 측이 제공했다. 지금은 그 문제가 해소되고 있고, 실제로 Chrome도 Android와 iOS에 이식되었다. Android에 Chrome 응용 프로그램의 진입이 앞으로 가능하게되면 응용 프로그램 모델의 융합화가 실현된다.



● 모바일 클라우드 아키텍처를 가속 
 
무엇보다, iOS에서 Chrome 브라우저는 Apple의 마련한 제약 때문에 쉽게 가지 않는다. Pichai 씨도 어려움이 있음을 인정한다.

 "iOS 버전 Chrome는 매우 빠른 브라우저지만, 확실히 제약이있다. 우리는, Chrome의 기능을 실현하기 위해 iOS의 Web보기위한 클래스 라이브러리이다" UIWebView "에 의지해야한다. 우리는, Chrome의 모든 것을 iOS 원인이 될 수 없다. 거기에는 제약이있는 것은 확실하다.

그러나, 우리는, 그 제약 중(안)에서 최상의 어플리케이션을 만들었다. 유저로부터의 피드백도 좋다.이것은, 아직 시작되어에 지나지 않는다.그 이상는, Apple와의 NDA에 있어서, 코멘트는 할 수 없다」.

 iOS판 Chrome에서는, 예를 들면, Google은 Chrome 독자적인 고속의 JIT(Just-In-Time) 타입 컴파일러의 JavaScript 엔진인 「V8엔진」을 사용할 수 없다.
그러나, 그러한 제약 중(안)에서 할 수 있는 일은 하고 있다. 그리고, iOS판 Chrome은, 아직 시작되었던 바로 직후로, 어떠한 전개가 있을 수 있는 것을 Pichai씨는 시사한다.

 Google은, 클라우드의 흐름은, 시작되었던 바로 직후로, 본격화하는 것은 나중이라고 보고 있다.그리고, 클라우드로 견인하는 것은 모바일 디바이스의 융성이라고 보고 있다.특히, 지금부터는 기업 시스템으로 클라우드를 접목하는 페이즈에 있다고 생각하고 있다.
 "하이레벨시점으로로 말하면, 기업은 클라우드에 관심을 갖고 있지만 아직 매우 초기 단계에있다. 초보적인 사용법 밖에하지 않는 것이 실정이다. 그러나 변화는 수면 아래에서 진행되고 있다. 왜냐하면 모바일이 융성 해오고 있기 때문이다.

 나는 모바일 클라우드로의 전환을 가속한다고 생각하고있다. "pre-모바일 시대"는, PC 아키텍쳐가 지배적 응용 프로그램은 Win32 API에 묶여 있었다. 그러나 모바일 시대에는 사람들은 Android 스마트폰과 태블릿, iPhone과 iPad 등 Windows 이외의 장치를 사용하고있다. 그리고 클라우드를 활용하는 스타일로 바뀌고있다. 진정한 클라우드 아키텍처로 전환 해 버리면, 중후 장대한 Windows 시스템은 기업에있어서​​ 단순한 선택의 하나에 지나지 않게되어 버릴 것이다.

 클라우드 혁명은 진행하고 있으며, 모바일 가속되고있​​다. 그리고 Google은 그 흐름 속에서 중요한 위치를 차지하고있다. 왜냐하면 처음부터 클라우드를 전제로 어플리케이션을 개발하고 있기 때문이다. 레거시 (클라우드 아니다) 소프트웨어 아키텍처, 클라우드 아키텍처로 재편성하는 것은 매우 어려울 것이다. 그 점에서 우리는 매우 유리한 입장에 서있다 "(Pichai 씨).


● 크롬 고속화로​​ 차별시킨다. 
 Google은 모바일 OS 분야에서는 Android에서 Apple의 iOS와 치열한 점유율 경쟁을하고있는 것으로 보인다. 이런 경우 일반적인 소프트웨어 기업은 자사 OS의 장점을 강화하고, 자사 OS에서만 사용할 수없는 서비스와 어플리케이션을 강화한다. 그러나 Google은 적극적으로 iOS에 자사의 서비스와 어플리케이션을 제공하고있다. 최근에는, Chrome와 Google +를 iOS 제공했다. 이러한 행동은 OS에 어플리케이션의 의지에 입각한 기존의 소프트웨어 전략은 다르다. iOS에 Android 서비스를 제공하는건 위험하지 않을까?

 "우리는 (iOS와 Android)에 충돌이 일어날 같은 견해는하고 있지 않다. 같은 클라우드 어플리케이션을 모든 플랫폼에 제공하는 것이야말로 중요하다고 생각하고 있기 때문이다. Gmail 응용 프로그램은 iOS와 Android에 제공 지금은 Google +와 Chrome도 마찬가지다. 모든 플랫폼에 걸쳐 중요하다고 생각하기 때문에, iOS도 제공한다.

 특히, Chrome은 Web의 기초가되는 것이다. 하드웨어에 상관없이 모든 크로스 플랫폼으로, 어느 나라에서나 모든 것을 사용할 수있다. 이것은 오픈 플랫폼에서 우리의 목표는 그 안에서 가능한 한 많은 사용자에게 다가갈하는 것이다. Google은 항상 그것 (많은 사용자에게 다가갈 수)을 적용하고있다. "

 Web 기업인 Google은 Web의 크로스 플랫폼의 강점을 살리는 것을 포인트로하고있다. OS에 묶는 것을 전제로 한 기업과 자세가 다르다. HTML5, CSS3, JavaScript 등의 Web 표준의 어플리케이션은 크로스 플랫폼 / 크로스 브라우저로 달리고 Google은 그러한 Web 어플 리케이션의 강점과 추진력을 이용하고있다.

 그러나 Web 기업은 크로스 플랫폼 Web에서 자사의 차별화를 도모할 필요가있다. 거기 항상 Web 기업 족쇄가된다. 차별화의 가장 큰 포인트는 말하는 동안도 아니고 브라우저 자체이다.

 Chrome에서는, 우리는 세 가지 영역에 초점을 맞춘. 속도, 심플함, 보안이다.

 첫째, 우리는 빠른 브라우저로 Chrome를 개발했다. 이것은 큰 차별화되었다고 생각하고있다. 실제로 빠른 브라우저인 것은 신흥 시장에서 큰 힘이되었다. 이러한 시장에서는 느린 컴퓨터와 느린 네트워크 밖에 없었기 때문이다. Chrome 먼저 성숙한 시장보다 신흥 시장에서 빠르게 성장하기 시작했다.

 심플리시티는 그 많은 사람들은 Web 어플리케이션을 사용하기 위해서만 브라우저를 사용하면 생각하고있다. 복잡한 브라우저는 원치 않는 것이고, 따라서 Chrome는 가능한 한 간단하게 유지하고있다.

 보안을 위해 사람들은 그렇게 명확하게 의식하고 있지 않을지도 모르지만, 우리는 Chrome의 보안을 유지해왔다. 버그를 발견하면 24 시간 이내에 패치를 맞추고있다. 이러한 조합이 Chrome을 성공으로 이끌어 왔다고 생각한다 "(Pichai 씨).


● 자바스크립트 언어의 고속 화는 새로운 언어 "dart"실현 
 
특히 네이티브 코드 실행 모델 써 온 프로그래머 측에 이러한 대립의 존재를 의식하고있는 사람이 많다. 그리고 기본파가 Web 프로그래밍에 항상 문제가되는 것은, 프로그램의 실행 성능이다. 그리고 Web 프로그래밍 성능의 열쇠가되는 ​​것은 JavaScript의 성능이다.

 JavaScript는 스크립트 언어로, Web 브라우저 엔진이 내장되어있다. 동적컴파일하는 JavaScript는 네이티브 코드에 대해 아무 래도 성능이 떨어진다. 그래서 Web 브라우저는 각각 JavaScript를 고속화하는 데 힘을 쏟고있다. 특히 Google은 "V8 JavaScript Engine"이라고 직접적인 JIT (Just In Time) 엔진, Chrome에서 JavaScript를 가속화 해왔다. 그러나 V8으로 고속화 수법을 다했기때문에 JavaScript는 더 이상 비약적인 속도는 바랄 수없는 것이 아니냐는 목소리도있다.
JavaScript의 속도가 둔화하면 Web 어플리케이션의 진화에 영향을 준다.


<크롬,파이어폭스,익스플로러 자바스크립트성능 변천사>



 "JavaScript를 지금 이상으로 빠르게 할 여지는 충분히 있다. 과거에도 크게 성능을 이동시킨, 앞으로도 다시 큰 도약이 가능하다.

 그러나 그러기 위해서는, 스크립트 자체의 개혁이 필요하다고 생각하고있다. 우리가 새로운 스크립팅 언어 "dart"에 임하고있는 것은 그 때문이다. 성능을 위한 다음 도약은 프로그래밍 언어 자체의 혁신이 필요하며 그것이 dart이다. "

 dart는 Google이 작년 (2011 년) 발표한 새로운 프로그래밍 언어 JavaScript와 마찬가지로 엔진이 Web 브라우저에 통합되는 것을 전제로하고있다. dart는 JavaScript 대안이며 Pichai 씨의 말을에서도 Google의 "JavaScript → dart"라는 입지는 분명하다.

구글의 새로운 프로그래밍 언어 "dart"
 

Google은 원래 스크립트 언어 호환성을 위해 책정되어왔다 "ECMAScript"스펙은 고속 화가 어렵다고보고있는 마디가있다. 따라서 사공이 많은 ECMAScript 계와는 별도로 병행하여 새로운 언어 dart를 개발한 것으로 보인다. Pichai 씨의 말을에서는 Google이 dart에서 다음 큰 성능 점프를 이루 고자하는 것을 알 수있다.

 그러나 dart 전략은 Google의 기본 전략과 일치하는 것 면도있다. Google은 Web 표준의 보편성과 추진력을 이용하고 있지만, dart는 당분간 Google만의 솔루션이다. 만약 타사의 브라우저가 Google에 추종하여 dart 엔진을 구현하고 dart가 업계 표준이되어 간다는 전개된다고해도, 그것은 긴 여정이 필요하다.

 물론 단기적으로는 dart 코드를 JavaScript 엔진에 전달 크로스 컴파일러 해결할 수 있지만, dart의 원래의 목적은 성능 점프이기 때문에 그럼 dart 의미가 희미해져 버린다. Google은 차기 JavaScript  "Harmony"도 추진하면서, dart 도 도모라는 두 방면 전쟁을하고있다. 여기에는 Web 어플리케이션의 진화 (스크립트 언어의 성능 점프)와 Web의 이념 (크로스 브라우저에서 동일한 코드를 달린다) 사이에서 고통 Google의 모습이 보이는 것 같다.

 참고로, Google은 샌드박스에서 네이티브 코드를 실행하는 "Native Client (NaCl)"도 추진하고있다. 이것도 네이티브 코드의 성능을 Web 프로그래밍의 세계에 소개하기 위하여 접근이라고 볼 수있다. 또한 NaCl은 LLVM (Low Level Virtual Machine) 버전 "Portable Native Client (PNaCl)"도 개발되고있다. 하드웨어를 추상화하는 소프트웨어 계층은 현재 Web 브라우저 (또는 그에 상응하는 레이어)와 LLVM (또는 같은 수준의 런타임)의 상하 2 개의 레이어에 집약되고 있지만, 그 브릿지를 전달하려하고있다. 그러나 NaCl도 오픈 소스라고해도, 현재 Google의 프로젝트이며, dart 마찬가지로 업체를 끌어들인 움직임이되는지 여부를 보이지 않는다.

● Google의 3D 그래픽 API "WebGL"의 위치 
 
"WebGL"는 Web 프로그래밍의 세계에 쉐이더 프로그래밍 3D 그래픽을 들여왔다.
Google은 지난해 Google I/O에서 WebGL을 강하게 밝힌 게임을 WebGL에서 쓰는 고무되었다.

 그러나 WebGL에는 보급에 큰 벽이있다. WebGL은 말하자면 쉐이더코드를 HTML5에 포함 같은 사양으로되어 있으며, JavaScript 중심 프로그래머에게는 생소한 때문이다. 쉐이더 프로그래밍에 대한 지식이 어느 정도 필요하며 일반적인 프론트 엔드 엔지니어 (Web 프로그래머)에 새로운 기술을 요구한다.


WebGL에 대한 대응

 
 따라서 WebGL을 취급하기 쉽게하기위한 추상 레이어를 마련하려는 움직임이 일어나고있다. 일반적으로, WebGL을 포함하는 래퍼 라이브러리를 JavaScript API로 만들 자고 활동이되고있다. 복잡한 WebGL을 의식하지 않고, JavaScript 간단한 쉐이더 3D 그래픽을 취급할 수 있도록하고있다.

 그러나 이러한 WebGL을 추상화하는 움직임은 산발적으로, WebGL을 견인하는 기업 중 하나이다 Google 자체의 움직임이 보이지 않는다. Google 자체는 "O3D"이라고 JavaScript API에 따르면 WebGL에 대한 래퍼 프로젝트를 가지고 있지만, 그 입지가 명료하지 않다. 즉, Google이 WebGL을 Web 프로그래머에 사용하기 쉽게하려고하는 공식적인 움직임이 보이지 않는다.

 이를 위해 Google에서 WebGL가 널리 보급 수 있는지 의문을 품는 개발자도 많다. 코어 게임 개발자는 WebGL가 보급되어도 그 앞에 퍼지지 않는다 우려가있다. 이 문제에 대해 Pichai 씨는 명료한 견해를 말했다.

 "Google I/O의 키노트 연설에서 행한"Cirque du Soleil "의 데모처럼, 우리는 WebGL를 사용하지 않아도 3D 표현을 할 수 방법을 제시하고있다. Cirque du Soleil의 데모는 HTML5와 CSS3를 사용하는 것만으로 이미지를 3D으로 취급할 것을 보여주었다. 이것으로 Web 개발자가 WebGL을 사용할 필요는 없다.


HTML5의 위치설정

 
 그러나 WebGL이 필요한 개발자도있다. 물론, Web 개발자는 WebGL에 너무 익숙하지 않다. 하지만 OpenGL 및 OpenGL ES를 다룬 적이있는 개발자가 WebGL 매우 친숙하다. WebGL 및 OpenGL / OpenGL ES 사이에는 많은 유사성이 있기 때문이다. 이러한 개발자를 위해 WebGL도 추진한다.

 우리의 견해로는, 3D 표현을 실현하는 방법은 HTML5/CSS3와 WebGL 두 길이다. 두 가지 방법이있는 것 자체에 문제는 없다고 생각하고있다. 각각 용도가 다르기 때문이다. 그래서 우리는 WebGL 위해 더 이상의 추상 레이어를 제공하는 계획은 없다. WebGL을 필요로하는 개발자는 이러한 레이어는 필요 없다고 생각하고있다. "


 이 설명에서 Google의 방향성이 명료하게 보인다. 간단한 3D 및 셰이더수준의 본격적인 3D 프로그래밍 2층으로 나누고, 후자는 WebGL에 맡긴다. WebGL 영역은 게임 프로그래머 등 세계에서 WebGL을보다 간단하게 취급하기위한 라이브러리는 당분간 설치하지. 즉, Google에서 WebGL의 위치는 일반적인 프론트 엔드 프로그래머를위한 것이 아니라, 그래픽 어느 정도 전문 프로그래머를위한 것이다. 이 자세가 앞으로도 계속하는지 모르겠지만, 현재 상태로서는 그렇게되어있다.

 Google의 WebGL에 대한 자세는 하드웨어 업계에있어서도 매우 중요하다. 왜냐하면, WebGL 뒤에  WebCL이 준비하고 있기 때문이다. WebGL이 OpenGL의 Web 판이라고하는 위치 설정의 그래픽용 API 인 반면 WebCL는 OpenCL의 Web 버전 범용 컴퓨팅을위한 API이다.

 미래에는 다크실리콘의 제약으로 GPU 코어의 용도의 대부분이 CPU 코어 오프로드되어 간다는 기대에 선다면, Web 프로그래밍 모델의 유연한 GPU에 대한 액세스를 허용하는 WebGL / WebCL은 중요하다. 그리고 CPU에서 GPU로 오프로드는 전력의 제약이 심한 모​​바일 이야말로 중요하다. 즉, Google가 열어 가고있는 시장이 바로 GPU 컴퓨팅이 요구되고있다. Google이 이러한 하드웨어 측면의 변화에​​ 얼마나 준비하고 있는지, 아직, 지금 단계에서는 모른다.

 
 
반응형

댓글