Cocoa for Windows + Flash Killer = SproutCore

casaubon · 2008-06-15, 06:57 AM

Cocoa for Windows + Flash Killer = SproutCore
June 14th, 2008 | History, Journal, Markets, Software, Tech

Daniel Eran Dilger

윈도용 사파리가 나왔을 때, 필자는 코코아의 채택과 노출을 높이기 위해 윈도 영역에다가 맥오에스텐 코코아 개발방식을 일부러 보이려는 것이라고 주장했었다. 기억하는 독자들이 계실 것이다. 그동안 필자는 어도비의 Flash와 AIR(그리고 덧붙이자면, 마이크로소프트의 '나 또한' Flash 플러그인이라 할 수 있는 Silverlight)를 죽이기 위해 애플이 이런 일들을 벌이고 있다 주장해왔다. 아이폰이 나왔을 때 전문가들은 아이폰에 Flash가 없는 것은 중대한 결점이며, 애플이 곧/언제인가는/어차피 Flash를 지원할 수밖에 없으리라 주장했었다. 애플의 Flash 공격과 윈도를 코코아로 뒤덮어버리는 공격이 실제로 모두 관련이 있다는 점을 발견하면 놀라실지 모르겠다.

사파리, 그리고 코코아
Safari의 잠재성과 옐로박스

애플의 iPhone 전략: Flash여, 안녕
Flash 워즈 1: Flash의 역사와 미래

A Few More Surprises.
애플이 윈도용 퀵타임과 아이튠스, 사파리에 이어 또 다른 애플리케이션을 내놓는다면 한층 더 놀라실 것이다. 기존 애플의 윈도용 애플리케이션 외에, 수 백만 명의 신규 사용자들 앞에 맥오에스텐의 사용자 인터페이스를 넣을 만한 것이 또 다시 등장한다. 추가적으로 이 모두가 코코아-스타일의 개발을 전면에 내세우게 된다. 새 애플리케이션을 만들 때 사용하는 프레임웍을 뿌리고 있기 때문이기도 하다.

놀라운 일은 더 있다. 이 모든 애플리케이션들이 리눅스 상에서도 크로스-플랫폼으로 돌아가리라는 점이다. 애플이 어떻게 그런 일을 할까? 1997년에 시도한 바 있던 여러 가지 운영체제 상의 옐로박스 런타임을 대규모적으로 돌려서는 아닐 것이다. 그 대신 웹브라우저 상에 코코아를 집어 넣어서 개발자들이 "풍부한 인터넷 애플리케이션(RIA)"을 웹브라우저 상의 코코아를 활용하여 만들 수 있도록 할 것이다. 바로 어도비가 Flash/Flex/AIR로, 마이크로소프트가 Silverlight로, 썬이 지바로 원하는 바이다.

Yellow Box의 죽음, 그리고 Cocoa

RIA MIA.
어도비와 마이크로소프트, 썬, 그 외 RIA 툴킷을 마케팅하는 기업들은 90년대 중반 자바에 대한 환호, 90년대 후반, 씬 클라이언트에 대한 환호처럼 유행을 만들어 보려 노력하고 있다. 그러나 RIA는 그 만큼 뜨지 않고 있는 중이다. 그 대신 Flash와 Sliverlight, 그 외 다른 폐쇄형 툴과 런타임 플러그인들은 RIA 개발 플랫폼을 언젠가 독점하겠다 벼르고 있다.

그러나 오늘날 풍부한 웹용 애플리케이션 대부분은 지도나 리더, 문서, 쉬트 등을 포함한 구글에서 나오고 있고, 구글의 웹 애플리케이션들이 제일 유명하다. 이런 애플리케이션들은 마이크로소프트 오피스를 겨냥하고 있으며, Flash나 Silverlight, 자바까지 쓰지 않아도 된다. 더구나 구글의 웹 애플리케이션은 웹 공개표준인 HTML과 자바스크립트, CSS를 사용한다. 구글의 웹 애플리케이션이 이런 폐쇄형 플러그인을 사용하지 않을진대, Flash 부류의 폐쇄형 기술을 어째서 사용해야 한단 말인가?

구글이 애플과 자주 협력관계를 맺는 것도 같은 맥락이다. 불필요한 Flash를 없애고 웹 공개표준인 HTML과 자바스크립트, CSS를 사용하기 위해서이다.

The Challenge of Funding Open Tools Development.
모든 웹 개발자들이 이제 모두 손잡고 무료와 공개 표준 솔루션으로 나아가리라는 생각을 하실지도 모르겠다. 하지만 이들은 스스로 Flash나 Silverlight와 같은 폐쇄형 기술의 노예를 자처한다. 한 번 그런 런타임에 종속되면 그렇게 된다. 어도비와 마이크로소프트에 쏠리는 힘이 개선을 마치게 되면, 독점을 이룬 후에 맞이하게 된 윈도와 인터넷 익스플로러 꼴이 된다. 물론 PC 업체들이 리눅스를 홍보하는 세상이 오리라고 생각하실지도 모르겠으나, 그런 일은 이제까지도 일어나지 않았다. 이유는 여러 모로 같다. 개방형 웹 표준은 직접 한 회사를 겨냥하여 그 회사를 부자로 만들어주지 않는다. 누구도 소유하지 않기 때문이며, 리눅스 또한 마찬가지이다. RedHat이나 IBM처럼 리눅스 관련서비스를 판매하여 이윤을 남기려는 전략적 목표를 직간접적으로 갖지 않는 한, 누구도 리눅스를 개선시키기 위해 먼저 투신하지 않는다.

간접적인 목표라면 구글과 애플이다. 근시안을 가진 개발자들이 맹목적으로 Flash나 Silverlight를 따르는 이유는 별다른 수고 없이 즉각적인 목표달성을 할 수 있기 때문이다. 구글과 애플은 이들과 달리 개방형 웹을 강력히 추구한다.

iPhone 대 인터넷 타블렛

Why Google and Apple Want an Open Web.
구글이 표준-기반 웹툴에 투자하는 이유는 구글이 개방형 인터넷을 원하기 때문이다. 구글이 개방형 인터넷을 원하는 까닭은 어도비나 마이크로소프트가 개방형 웹에다가 자사 고유의 Flash나 Silverlight 플러그인으로 더럽힐 경우, 경쟁이나 광고판매를 할 수 없어서이다. 어도비나 마이크로소프트는 웹 콘텐트를 개방형 HTML이 아닌, 자신의 바이너리로 묶어버리려든다.

애플은 광고를 판매하지 않고 하드웨어를 판다. 하지만 웹이 Flash나 Silverlight를 요구하게 되면, 어도비나 마이크로소프트가 맥(그리고 리눅스)과 같은 대안형 플랫폼을 의도치 않게 죽여버릴 수 있다. 설사 대안형 플랫폼용으로 플러그인을 만들어준다 할지라도 저질로 만들게 마련이다. 무능해서이기도 하고, 그런 플랫폼을 잘 만들어야 할 이유가 없어서이기도 하다. 어도비는 맥용 Flash를 만드는 데에 있어 이미 그 무능함을 증명한 바 있다. (사실 윈도 외 모든 플랫폼에서 어도비는 무능하다.) 윈도가 아니면 모든 것을 파괴하려드는 마이크로소프트의 역사적인 궤적을 다시 한 번 써야 할 필요는 못느끼겠다.

따라서 구글과 애플은 상호 다른 목적을 갖고 연합을 하고 있다. 구글은 광고를 팔기 위한 개방형 웹을 원하고, 애플은 웹브라우징을 잘 할 수 있는 하드웨어를 판매하기 위해 개방형 웹을 원한다. 현재 이 두 회사는 모두 상호 독립적이고 보완적인 방식으로 목표를 이뤄가고 있다.

Google’s API Inexperience.
구글은 오프라인 스토리지용 웹 애플리케이션을 위해 구글 Gears를 소개하였다. 그러나 구글의 API 개발 경험은 지도나 메일 등의 웹서비스 접속밖에 없었다. 구글 Gears나 Android 외 구글이 펼치고 있는 주요 새 플랫폼 API는 증빙이 안 되었다. 가령 Android SDK의 경우, 이 SDK를 소개했던 때가 2007년 11월이었다. 하지만 2008년 2월에 나온 아이폰 SDK의 업데이트 주기나 세련도, 깔끔함에 비하면 아직 아니다.

다른 문제도 있다. 구글을 좋아하는 대규모 사용자 기반이 없다는 것이다. 구글은 커뮤니티에 엄청나게 많은 코드를 기증하였지만, 그렇다고 해서 커뮤니티가 구글 고드만 써야하는 것도 아니다.

The Apple of Your API.
이와 반대로 애플은 수 년간 시장에서 증명이 된 매우 강력하고 성숙한 개발툴과 플랫폼 프레임웍을 갖고 있다. 게다가 경쟁에 있어서 애플의 개발툴을 널리 받아들인 곳도 많다. 애플은 맥으로 최초의 주류 그래픽 플랫폼을 고안하였으며, 이 방식은 마이크로소프트 윈도의 기반이 되었다. 90년대 초 코플랜드가 수렁에 빠지면서 윈도가 세상을 지배하게 된다.

80년대 애플을 떠나 넥스트로 가서 첫 번째 주류 객체지향 플랫폼 프레임웍을 만든 애플 직원들은 다른 기업들이 따라하려 애쓰거나, 혹은 아예 그에 맞춰 개발을 하려는 표준형 프레임웍을 만들어냈다. 애플과 IBM의 Taligent, 썬의 자바, 마이크로소프트의 미완성 Cairo 모두 넥스트가 이미 출시하여 주요 고객들이 사용하고 있는 뭔가를 출시하려 노력하던 중이었다.

1990-1995, 핑크와 탈리전트, 코플랜드의 비밀
90년대 OS의 역사
1990-1995, 카이로로 가는 머나먼 길
iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스

Apple's API Philosophy.
1996년 넥스트를 인수한 애플은 맥오에스텐 작업을 시작한다. 그 후로 애플은 독특한 철학에 따라 데스크톱용 API를 갈고 닦아왔다.

기능 구현하기
불필요한 API 절제하기
코드 개선을 위한 반복
양이 아닌 질로 승부

애플은 코드 품질과 API의 우아함을 강조한다. 덕분에 애플은 지난 10년간 마이크로소프트보다 더 빠르게 움직일 수 있었다. 또한 고질적인 문제였던 허술한 코드와 대충 만든 계획으로 고생하는 일도 없었다. 따라서 90년대 중반 코플랜드 재앙으로 잃었던 API 개발로서 애플의 명성은 회복되었다.

맥 데스크톱 플랫폼도 상당수의 개발자들이 따랐지만, 애플은 과거의 명성만 갖고 안주하지 않았다. 아이폰을 등장시킨 것이다. 애플은 데스크톱용 코코아 API를 직접 포팅시켰을뿐 아니라, 완전히 새로운 환경에서 어떻게 새로 시작할 터인지를 신중히 고려할 기회도 잡아 놓았다. 애플의 문서 "iPhone Getting Started Docs"를 SproutCore 블로그에서 평한 것이 있다.

"크게 다른 점이 하나 있다. UIKit 클래스 선언을 통해 속성(properties)을 대폭 확장시켜서 사용한다는 점이다. 속성은 맥오에스텐 10.5에 등장하였으며, AppKit 프레임웍의 수많은 클래스가 만들어진 후에 뒤따라들어오게 되어 있다. 단순히 AppKit의 메써드를 제거하고 관리한다기보다, UIKit은 속성을 활용하여 클래스 인터페이스를 간단하게 만든다. 속성에 대해 더 알고 싶다면 The Objective-C 2.0 Programming Language의 속성 편을 보시라."

SproutCore Blog
iPhone Getting Started Docs

Apple’s Cocoa Flavored Open Web.
애플은 현재 맥오에스텐 바깥에서도 코코아형 개발을 홍보하고 있으며, 아이폰이 그 첨병 역할을 맡고 있다. 애플은 원래 지난 가을에 데뷔한 .Mac Web Gallery에서 보듯, 데스크톱 애플리케이션용 오프라인 기술을 온라인용 웹 애플리케이션으로 전달시킨 바 있다. 이런 자바스크립트 프레임웍을 여러 모로 실험해본 뒤, 애플은 SproutCore 뒤에 자원을 투입하였다.

덕분에 애플은 공개 웹표준을 사용하여 웹용 애플리케이션을 개선시켰을뿐 아니라, 코코아에 영감을 받아 만들어진 크로스플랫폼 자바스크립트 프레임웍인 SproutCore와도 공유를 하였다. SproutCore는 오픈소스 MIT 라이센스이다. 이 공유는 RIA 영역에서 Flash에 대해 개방형 대안을 제공하는데 도움이 될 것이다. SproutCore는 광고용 애니메이션이나 애플릿 네비게이션에 있어서 Flash에 대항하려는 것이 아니다. 오히려 어도비의 Flash-기반 AIR 플랫폼 계획을 목표로, 인터랙티브 애플리케이션용으로 나왔다.

WWDC에서 나온 큰 발표로서 .Mac의 브랜드를 바꾼 Mobile Me이다. Mobile Me는 아이폰과 크로스-플랫폼을 덧붙였으며, 애플은 여기에 새로이 웹용 칼렌다와 주소록, 메일과 iDisk 온라인 파일매니저를 추가하였다. Galley도 기존 Mac의 Web Gallery를 업데이트하였으며, 이 갤러리가 SproutCore의 초기 버전을 사용한다.

SproutCore
Apple’s Mobile Me Takes On Exchange, Mobile Mesh

Charles Jolley’s SproutCore.
SproutCore 자바스크립트 프레임웍을 개발한 곳은 애플이 아니다. 원래 Mailroom이라는 온라인 이메일 관리자를 만들어낸 찰스 졸리(Charles Jolley)이다. 졸리는 애플의 .Mac 팀에 들어가서 자기 프레임웍을 급속도로 개선시켰다. SproutCore는 메뉴와 툴바, 드래그앤드롭, 외국어 지원뿐 아니라, Rails(그리고 코코아)와 바인딩, 키밸류 관측, 컨트롤 보기와 같은 완전한 Model View Controller 애플리케이션 스택도 제공하는 진정한 웹애플리케이션을 만들 수 있게 해준다. 또한 late binding과 closures, lambda 기능을 포함한 자바스크립트의 잠재 기능을 드러낸다. 개발자들은 또한 유닛 테스팅과 코드 문서 관리도 잘 할 수 있다.

SproutCore를 코코아로 뿌리내리게 한 깔끔흔 MVC 철학의 핵심은 바인딩(binding)이다. 바인딩 덕분에 개발자는 속성값이 변할 때 자동적으로 자바스크립트가 실행되도록 작성할 수 있다. 바인딩이 있으면, 고도로 일관성 있는 비헤이비어로 구성된 매우 복잡한 애플리케이션도 "연결(glue)" 코드가 거의 없이 작성할 수 있다.

Cocoa Bindings Programming Topics: What Are Cocoa Bindings?

Oh No, Web Apps?
맥오에스텐용 애플리케이션 느낌이 나는 웹용 애플리케이션 작성에 있어서 SproutCore를 가벼운 코코아의 대안으로 생각해도 되는 셈이다. WWDC에서 Pixar의 마이클 존슨(Michael B Johnson) 박사는 오찬 프리젠테이션에서 64-비트 어드레싱이나 멀티쓰레딩, 그 외 데스크톱 전용 기능이 필요 없다면, SproutCore를 이용한 웹용 애플리케이션 제작이 상당히 합리적이라 말하였다.

그런데 웹용이라니, 좀 껄끄럽지 않은가? 역사적으로, 특히 페이지 하나 읽을 때 매번 서버 반응이 필요했던 시기를 생각하면 정말 그렇다. 백그라운드 상에서 싱크되지 않은 채로 서버의 새 데이터를 읽어들일 수 있는 Ajax 기술이 도움이 된다. 현대적인 Ajax 웹사이트(Flickr같은 곳이 그러하다)들은 드래그앤드롭 기능을 제공하며, 구글도 웹용 애플리케이션에서 Ajax를 사용한다. 그러면 데스크톱을 쓰는 느낌이 난다. 그러나 사용할 만한 인터페이스라는 측면에서 보면, 아직 웹용 애플리케이션은 데스크톱을 못따라온다.

SproutCore가 이런 상황의 개선에 도움이 될 것이다. 사용자 브라우저 안에서 풍부한 인터랙션을 거치며, 오프라인 기능도 지원하기 때문이다. 즉, 웹용 애플리케이션을 보다 데스크톱처럼 움직이게 하고, 사용자들이 싫어하는 HTML 다시 읽어들이기를 그 만큼 덜 하는 것이다. 외양도 데스크톱처럼 바뀐다. 특히나 맥오에스텐용 데스크톱 애플리케이션처럼 말이다. SproutCore 프레임웍은 웹 개발자들의 문제점 상당수를 해결할 만하다. 사파리와 파이어폭스, 인터넷 익스플로러 6/7이 각기 갖는 비호환성 문제를 다룰줄 알기 때문이다. 또한 현대적인 브라우저가 가진 CSS 기능도 쉽게 활용할 수 있다.

A Front End to WebObjects, WebDAV.
SproutCore는 백엔드 서버에서 애플리케이션이 돌아가기 때문에, 로컬 클라이언트에 해당 애플리케이션을 설치할 필요가 없는, 씬 클라이언트의 개념도 실현시켜준다. 그런데 씬 클라이언트의 결함이 있다. 웹과 같은 씬 플랫폼의 약점때문에 기능이 최소한으로 국한된다는 점이다. SproutCore는 이 단점을 웹브라우저 기능에 의존하여 해결한다. 요새 웹브라우저는 두터운 클라이언트 웹 애플리케이션을 충분히 돌릴 정도로 발전하였다.

SproutCore 웹 애플리케이션은 클라이언트-서버 컴퓨팅의 장점을 가진 웹서비스의 힘과 융통성을 조합한다. 덕분에 애플은 "웹 클라이언트-서버"라는 신모델을 내세울 수 있게 되었다. Mobile Me의 웹용 애플리케이션은 이제 WebObjects와 WebDAV 서버가 운영하는 웹서비스로 묶이게 되었다. 하지만 SproutCore 웹애플리케이션을 PHP나, XML, JSON 오브젝트와 같은 방식을 제공하는 서버에 묶어둘 수 있다.

Yellow Box의 죽음, 그리고 Cocoa

Thinking Outside the Yellow Box.
윈도용 코코아, 혹은 옐로 박스의 부활을 지금도 기다리신다면, 이제는 기다림을 멈추고 코딩을 시작할 때이다. SproutCore가 레퍼드 코코아의 가치를 웹으로 가져다주고, 자바스크립트를 이미 데스크톱 기능 지원용으로 내장시킨 풍부한 애플리케이션 플랫폼으로 안겨다주기 때문이다.

오픈소스와 개방형 웹표준에 기반을 두기 때문에, SproutCore를 사용하면, 플러그인이나 특정 기업에 얽매이지 않은 크로스 플랫폼 애플리케이션 개발을 할 수 있다. 웹표준을 깔고 앉으면 애플과 커뮤니티도 윈도의 레이어가 갑자기 변한다 할지라도 우려할 일이 전혀 없어진다. 이 점만 생각하면, 그런 변화는 예전 윈도용 옐로 박스나 윈도용 코코아에게 상당한 문제를 야기할 수 있다. SproutCore는 또한 잘 알려진 보안의 보호를 받기에, 새로운 런타임 레이어가 알려지지 않은 구멍을 여는 것도 걱정할 필요가 사라진다.

Make Apple SaaS.
이 모든 개선이 새로우 잠재성을 깨우게 된다. 이미 애플은 .Mac으로 대 소비자 "서비스로서의 소프트웨어"를 조용히 앞지르고 있는 중이다. 구글과 야후, MSN이 그동안 광고를 내세워서 온라인 메일과 사진, 그 외 애플리케이션을 시도하였지만 애플은 .Mac 서비스를 가입자에게 판매하는 독특한 방식을 추구해 왔었다. 애플이 하는 일은 모두가 원하는 일이다.

Mobile Me는 .Mac으로 아이폰 사용자들까지 흡수하겠다는 내용이랄 수 있다. 아이폰은 또한 엄청나게 많은 윈도 사용자들 눈앞에 맥오에스텐 애플리케이션을 갖다놓게 된다. 잠재성이 더욱 더 극대화되는 것이다. SproutCore 버전의 iWork가 온라인으로 나온다면, 그것도 맥과 윈도 사용자 모두가 사용할 수 있게 된다면? Back to My Mac 기능이 확장하여, 가정 파일공유가 바로 가능해지고, VNC 화면 공유 서비스가 웹을 통해 가능해진다면?

써드 파티는 어떨까? Mobile Me 플랫폼상에 뛰어들고 싶어할 기업 개발사들도 분명 있을 것이다. 애플 또한 써드파티 웹 애플리케이션 기업들을 끌어다 둘 생각을 할 것이다. 심지어 서비스의 일부러 번들시킬 수도 있을 것이다. 그러면 Mobile Me의 가치가 더 높아진다. 돈을 조금 더 내면 사용할 수 있게 할 수도 있겠다. 아이폰과 모바일 푸시 싱크와 직접적인 웹접속을 제공하는 QuickBooks의 Mobile Me 버전을 상상해 보시라.

Apple - MobileMe - Features

The WebApps Store.
웹 개발자들은 자기 서비스를 판매하기가 불가능하다는 현실을 깨달을 때가 있다. 하지만 애플은 이 문제를 해결할 수 있다. 모바일 소프트웨어의 동일한 문제를 해결한 방식과 같다. 아이폰 App Store를 Mobile Me 안에다 동일하게 심어 넣으면 된다. 그러면 웹 애플리케이션 시장이 실제로 형성될 수 있으며, 웹 서비스 또한 아이튠스의 확장처럼 작동할 수 있게 된다. 사실 애플은 아이튠스 안의 WebKit에다가 바로 이런 스토어를 추가시켜서 Mobile Me 애플리케이션을 바로 광범위하게 보여줄 수 있다.

물론 웹용 애플리케이션 판매를 꼭 아이튠스에 묶어둘 이유는 없다. 윈도용 사파리를 애플이 갖고 있기도 하고, 결국 파이어폭스나 인터넷 익스플로러에서도 돌아갈 터이기 때문이다. App Store가 흥미롭다 여긴다면, Mobile Me 시장도 정말 흥미롭겠다는 생각이 들 것이다.

유사 Flash 애플릿이나 제공하는 Facebook이 무료 서비스로서 이윤이 남질 않는다고 모두들 불평한다. 진짜 애플리케이션과 웹서비스를 돈 받고 충성스러운 사용자들에게 제공하는 애플은 어떨까? 심지어 이윤까지 올린다고 하면 꽤 관심을 받잖을까 싶다.

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Cocoa for Windows + Flash Killer = SproutCore

2008-06-15, 06:57 AM	#1
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,139 온라인	SproutCore, 웹 2.0을 뒤집는다 Cocoa for Windows + Flash Killer = SproutCore June 14th, 2008 \| History, Journal, Markets, Software, Tech Daniel Eran Dilger 윈도용 사파리가 나왔을 때, 필자는 코코아의 채택과 노출을 높이기 위해 윈도 영역에다가 맥오에스텐 코코아 개발방식을 일부러 보이려는 것이라고 주장했었다. 기억하는 독자들이 계실 것이다. 그동안 필자는 어도비의 Flash와 AIR(그리고 덧붙이자면, 마이크로소프트의 '나 또한' Flash 플러그인이라 할 수 있는 Silverlight)를 죽이기 위해 애플이 이런 일들을 벌이고 있다 주장해왔다. 아이폰이 나왔을 때 전문가들은 아이폰에 Flash가 없는 것은 중대한 결점이며, 애플이 곧/언제인가는/어차피 Flash를 지원할 수밖에 없으리라 주장했었다. 애플의 Flash 공격과 윈도를 코코아로 뒤덮어버리는 공격이 실제로 모두 관련이 있다는 점을 발견하면 놀라실지 모르겠다. 사파리, 그리고 코코아 Safari의 잠재성과 옐로박스 애플의 iPhone 전략: Flash여, 안녕 Flash 워즈 1: Flash의 역사와 미래 A Few More Surprises. 애플이 윈도용 퀵타임과 아이튠스, 사파리에 이어 또 다른 애플리케이션을 내놓는다면 한층 더 놀라실 것이다. 기존 애플의 윈도용 애플리케이션 외에, 수 백만 명의 신규 사용자들 앞에 맥오에스텐의 사용자 인터페이스를 넣을 만한 것이 또 다시 등장한다. 추가적으로 이 모두가 코코아-스타일의 개발을 전면에 내세우게 된다. 새 애플리케이션을 만들 때 사용하는 프레임웍을 뿌리고 있기 때문이기도 하다. 놀라운 일은 더 있다. 이 모든 애플리케이션들이 리눅스 상에서도 크로스-플랫폼으로 돌아가리라는 점이다. 애플이 어떻게 그런 일을 할까? 1997년에 시도한 바 있던 여러 가지 운영체제 상의 옐로박스 런타임을 대규모적으로 돌려서는 아닐 것이다. 그 대신 웹브라우저 상에 코코아를 집어 넣어서 개발자들이 "풍부한 인터넷 애플리케이션(RIA)"을 웹브라우저 상의 코코아를 활용하여 만들 수 있도록 할 것이다. 바로 어도비가 Flash/Flex/AIR로, 마이크로소프트가 Silverlight로, 썬이 지바로 원하는 바이다. Yellow Box의 죽음, 그리고 Cocoa RIA MIA. 어도비와 마이크로소프트, 썬, 그 외 RIA 툴킷을 마케팅하는 기업들은 90년대 중반 자바에 대한 환호, 90년대 후반, 씬 클라이언트에 대한 환호처럼 유행을 만들어 보려 노력하고 있다. 그러나 RIA는 그 만큼 뜨지 않고 있는 중이다. 그 대신 Flash와 Sliverlight, 그 외 다른 폐쇄형 툴과 런타임 플러그인들은 RIA 개발 플랫폼을 언젠가 독점하겠다 벼르고 있다. 그러나 오늘날 풍부한 웹용 애플리케이션 대부분은 지도나 리더, 문서, 쉬트 등을 포함한 구글에서 나오고 있고, 구글의 웹 애플리케이션들이 제일 유명하다. 이런 애플리케이션들은 마이크로소프트 오피스를 겨냥하고 있으며, Flash나 Silverlight, 자바까지 쓰지 않아도 된다. 더구나 구글의 웹 애플리케이션은 웹 공개표준인 HTML과 자바스크립트, CSS를 사용한다. 구글의 웹 애플리케이션이 이런 폐쇄형 플러그인을 사용하지 않을진대, Flash 부류의 폐쇄형 기술을 어째서 사용해야 한단 말인가? 구글이 애플과 자주 협력관계를 맺는 것도 같은 맥락이다. 불필요한 Flash를 없애고 웹 공개표준인 HTML과 자바스크립트, CSS를 사용하기 위해서이다. The Challenge of Funding Open Tools Development. 모든 웹 개발자들이 이제 모두 손잡고 무료와 공개 표준 솔루션으로 나아가리라는 생각을 하실지도 모르겠다. 하지만 이들은 스스로 Flash나 Silverlight와 같은 폐쇄형 기술의 노예를 자처한다. 한 번 그런 런타임에 종속되면 그렇게 된다. 어도비와 마이크로소프트에 쏠리는 힘이 개선을 마치게 되면, 독점을 이룬 후에 맞이하게 된 윈도와 인터넷 익스플로러 꼴이 된다. 물론 PC 업체들이 리눅스를 홍보하는 세상이 오리라고 생각하실지도 모르겠으나, 그런 일은 이제까지도 일어나지 않았다. 이유는 여러 모로 같다. 개방형 웹 표준은 직접 한 회사를 겨냥하여 그 회사를 부자로 만들어주지 않는다. 누구도 소유하지 않기 때문이며, 리눅스 또한 마찬가지이다. RedHat이나 IBM처럼 리눅스 관련서비스를 판매하여 이윤을 남기려는 전략적 목표를 직간접적으로 갖지 않는 한, 누구도 리눅스를 개선시키기 위해 먼저 투신하지 않는다. 간접적인 목표라면 구글과 애플이다. 근시안을 가진 개발자들이 맹목적으로 Flash나 Silverlight를 따르는 이유는 별다른 수고 없이 즉각적인 목표달성을 할 수 있기 때문이다. 구글과 애플은 이들과 달리 개방형 웹을 강력히 추구한다. iPhone 대 인터넷 타블렛 Why Google and Apple Want an Open Web. 구글이 표준-기반 웹툴에 투자하는 이유는 구글이 개방형 인터넷을 원하기 때문이다. 구글이 개방형 인터넷을 원하는 까닭은 어도비나 마이크로소프트가 개방형 웹에다가 자사 고유의 Flash나 Silverlight 플러그인으로 더럽힐 경우, 경쟁이나 광고판매를 할 수 없어서이다. 어도비나 마이크로소프트는 웹 콘텐트를 개방형 HTML이 아닌, 자신의 바이너리로 묶어버리려든다. 애플은 광고를 판매하지 않고 하드웨어를 판다. 하지만 웹이 Flash나 Silverlight를 요구하게 되면, 어도비나 마이크로소프트가 맥(그리고 리눅스)과 같은 대안형 플랫폼을 의도치 않게 죽여버릴 수 있다. 설사 대안형 플랫폼용으로 플러그인을 만들어준다 할지라도 저질로 만들게 마련이다. 무능해서이기도 하고, 그런 플랫폼을 잘 만들어야 할 이유가 없어서이기도 하다. 어도비는 맥용 Flash를 만드는 데에 있어 이미 그 무능함을 증명한 바 있다. (사실 윈도 외 모든 플랫폼에서 어도비는 무능하다.) 윈도가 아니면 모든 것을 파괴하려드는 마이크로소프트의 역사적인 궤적을 다시 한 번 써야 할 필요는 못느끼겠다. 따라서 구글과 애플은 상호 다른 목적을 갖고 연합을 하고 있다. 구글은 광고를 팔기 위한 개방형 웹을 원하고, 애플은 웹브라우징을 잘 할 수 있는 하드웨어를 판매하기 위해 개방형 웹을 원한다. 현재 이 두 회사는 모두 상호 독립적이고 보완적인 방식으로 목표를 이뤄가고 있다. Google’s API Inexperience. 구글은 오프라인 스토리지용 웹 애플리케이션을 위해 구글 Gears를 소개하였다. 그러나 구글의 API 개발 경험은 지도나 메일 등의 웹서비스 접속밖에 없었다. 구글 Gears나 Android 외 구글이 펼치고 있는 주요 새 플랫폼 API는 증빙이 안 되었다. 가령 Android SDK의 경우, 이 SDK를 소개했던 때가 2007년 11월이었다. 하지만 2008년 2월에 나온 아이폰 SDK의 업데이트 주기나 세련도, 깔끔함에 비하면 아직 아니다. 다른 문제도 있다. 구글을 좋아하는 대규모 사용자 기반이 없다는 것이다. 구글은 커뮤니티에 엄청나게 많은 코드를 기증하였지만, 그렇다고 해서 커뮤니티가 구글 고드만 써야하는 것도 아니다. The Apple of Your API. 이와 반대로 애플은 수 년간 시장에서 증명이 된 매우 강력하고 성숙한 개발툴과 플랫폼 프레임웍을 갖고 있다. 게다가 경쟁에 있어서 애플의 개발툴을 널리 받아들인 곳도 많다. 애플은 맥으로 최초의 주류 그래픽 플랫폼을 고안하였으며, 이 방식은 마이크로소프트 윈도의 기반이 되었다. 90년대 초 코플랜드가 수렁에 빠지면서 윈도가 세상을 지배하게 된다. 80년대 애플을 떠나 넥스트로 가서 첫 번째 주류 객체지향 플랫폼 프레임웍을 만든 애플 직원들은 다른 기업들이 따라하려 애쓰거나, 혹은 아예 그에 맞춰 개발을 하려는 표준형 프레임웍을 만들어냈다. 애플과 IBM의 Taligent, 썬의 자바, 마이크로소프트의 미완성 Cairo 모두 넥스트가 이미 출시하여 주요 고객들이 사용하고 있는 뭔가를 출시하려 노력하던 중이었다. 1990-1995, 핑크와 탈리전트, 코플랜드의 비밀 90년대 OS의 역사 1990-1995, 카이로로 가는 머나먼 길 iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스 Apple's API Philosophy. 1996년 넥스트를 인수한 애플은 맥오에스텐 작업을 시작한다. 그 후로 애플은 독특한 철학에 따라 데스크톱용 API를 갈고 닦아왔다. 기능 구현하기 불필요한 API 절제하기 코드 개선을 위한 반복 양이 아닌 질로 승부 애플은 코드 품질과 API의 우아함을 강조한다. 덕분에 애플은 지난 10년간 마이크로소프트보다 더 빠르게 움직일 수 있었다. 또한 고질적인 문제였던 허술한 코드와 대충 만든 계획으로 고생하는 일도 없었다. 따라서 90년대 중반 코플랜드 재앙으로 잃었던 API 개발로서 애플의 명성은 회복되었다. 맥 데스크톱 플랫폼도 상당수의 개발자들이 따랐지만, 애플은 과거의 명성만 갖고 안주하지 않았다. 아이폰을 등장시킨 것이다. 애플은 데스크톱용 코코아 API를 직접 포팅시켰을뿐 아니라, 완전히 새로운 환경에서 어떻게 새로 시작할 터인지를 신중히 고려할 기회도 잡아 놓았다. 애플의 문서 "iPhone Getting Started Docs"를 SproutCore 블로그에서 평한 것이 있다. "크게 다른 점이 하나 있다. UIKit 클래스 선언을 통해 속성(properties)을 대폭 확장시켜서 사용한다는 점이다. 속성은 맥오에스텐 10.5에 등장하였으며, AppKit 프레임웍의 수많은 클래스가 만들어진 후에 뒤따라들어오게 되어 있다. 단순히 AppKit의 메써드를 제거하고 관리한다기보다, UIKit은 속성을 활용하여 클래스 인터페이스를 간단하게 만든다. 속성에 대해 더 알고 싶다면 The Objective-C 2.0 Programming Language의 속성 편을 보시라." SproutCore Blog iPhone Getting Started Docs Apple’s Cocoa Flavored Open Web. 애플은 현재 맥오에스텐 바깥에서도 코코아형 개발을 홍보하고 있으며, 아이폰이 그 첨병 역할을 맡고 있다. 애플은 원래 지난 가을에 데뷔한 .Mac Web Gallery에서 보듯, 데스크톱 애플리케이션용 오프라인 기술을 온라인용 웹 애플리케이션으로 전달시킨 바 있다. 이런 자바스크립트 프레임웍을 여러 모로 실험해본 뒤, 애플은 SproutCore 뒤에 자원을 투입하였다. 덕분에 애플은 공개 웹표준을 사용하여 웹용 애플리케이션을 개선시켰을뿐 아니라, 코코아에 영감을 받아 만들어진 크로스플랫폼 자바스크립트 프레임웍인 SproutCore와도 공유를 하였다. SproutCore는 오픈소스 MIT 라이센스이다. 이 공유는 RIA 영역에서 Flash에 대해 개방형 대안을 제공하는데 도움이 될 것이다. SproutCore는 광고용 애니메이션이나 애플릿 네비게이션에 있어서 Flash에 대항하려는 것이 아니다. 오히려 어도비의 Flash-기반 AIR 플랫폼 계획을 목표로, 인터랙티브 애플리케이션용으로 나왔다. WWDC에서 나온 큰 발표로서 .Mac의 브랜드를 바꾼 Mobile Me이다. Mobile Me는 아이폰과 크로스-플랫폼을 덧붙였으며, 애플은 여기에 새로이 웹용 칼렌다와 주소록, 메일과 iDisk 온라인 파일매니저를 추가하였다. Galley도 기존 Mac의 Web Gallery를 업데이트하였으며, 이 갤러리가 SproutCore의 초기 버전을 사용한다. SproutCore Apple’s Mobile Me Takes On Exchange, Mobile Mesh Charles Jolley’s SproutCore. SproutCore 자바스크립트 프레임웍을 개발한 곳은 애플이 아니다. 원래 Mailroom이라는 온라인 이메일 관리자를 만들어낸 찰스 졸리(Charles Jolley)이다. 졸리는 애플의 .Mac 팀에 들어가서 자기 프레임웍을 급속도로 개선시켰다. SproutCore는 메뉴와 툴바, 드래그앤드롭, 외국어 지원뿐 아니라, Rails(그리고 코코아)와 바인딩, 키밸류 관측, 컨트롤 보기와 같은 완전한 Model View Controller 애플리케이션 스택도 제공하는 진정한 웹애플리케이션을 만들 수 있게 해준다. 또한 late binding과 closures, lambda 기능을 포함한 자바스크립트의 잠재 기능을 드러낸다. 개발자들은 또한 유닛 테스팅과 코드 문서 관리도 잘 할 수 있다. SproutCore를 코코아로 뿌리내리게 한 깔끔흔 MVC 철학의 핵심은 바인딩(binding)이다. 바인딩 덕분에 개발자는 속성값이 변할 때 자동적으로 자바스크립트가 실행되도록 작성할 수 있다. 바인딩이 있으면, 고도로 일관성 있는 비헤이비어로 구성된 매우 복잡한 애플리케이션도 "연결(glue)" 코드가 거의 없이 작성할 수 있다. Cocoa Bindings Programming Topics: What Are Cocoa Bindings? Oh No, Web Apps? 맥오에스텐용 애플리케이션 느낌이 나는 웹용 애플리케이션 작성에 있어서 SproutCore를 가벼운 코코아의 대안으로 생각해도 되는 셈이다. WWDC에서 Pixar의 마이클 존슨(Michael B Johnson) 박사는 오찬 프리젠테이션에서 64-비트 어드레싱이나 멀티쓰레딩, 그 외 데스크톱 전용 기능이 필요 없다면, SproutCore를 이용한 웹용 애플리케이션 제작이 상당히 합리적이라 말하였다. 그런데 웹용이라니, 좀 껄끄럽지 않은가? 역사적으로, 특히 페이지 하나 읽을 때 매번 서버 반응이 필요했던 시기를 생각하면 정말 그렇다. 백그라운드 상에서 싱크되지 않은 채로 서버의 새 데이터를 읽어들일 수 있는 Ajax 기술이 도움이 된다. 현대적인 Ajax 웹사이트(Flickr같은 곳이 그러하다)들은 드래그앤드롭 기능을 제공하며, 구글도 웹용 애플리케이션에서 Ajax를 사용한다. 그러면 데스크톱을 쓰는 느낌이 난다. 그러나 사용할 만한 인터페이스라는 측면에서 보면, 아직 웹용 애플리케이션은 데스크톱을 못따라온다. SproutCore가 이런 상황의 개선에 도움이 될 것이다. 사용자 브라우저 안에서 풍부한 인터랙션을 거치며, 오프라인 기능도 지원하기 때문이다. 즉, 웹용 애플리케이션을 보다 데스크톱처럼 움직이게 하고, 사용자들이 싫어하는 HTML 다시 읽어들이기를 그 만큼 덜 하는 것이다. 외양도 데스크톱처럼 바뀐다. 특히나 맥오에스텐용 데스크톱 애플리케이션처럼 말이다. SproutCore 프레임웍은 웹 개발자들의 문제점 상당수를 해결할 만하다. 사파리와 파이어폭스, 인터넷 익스플로러 6/7이 각기 갖는 비호환성 문제를 다룰줄 알기 때문이다. 또한 현대적인 브라우저가 가진 CSS 기능도 쉽게 활용할 수 있다. A Front End to WebObjects, WebDAV. SproutCore는 백엔드 서버에서 애플리케이션이 돌아가기 때문에, 로컬 클라이언트에 해당 애플리케이션을 설치할 필요가 없는, 씬 클라이언트의 개념도 실현시켜준다. 그런데 씬 클라이언트의 결함이 있다. 웹과 같은 씬 플랫폼의 약점때문에 기능이 최소한으로 국한된다는 점이다. SproutCore는 이 단점을 웹브라우저 기능에 의존하여 해결한다. 요새 웹브라우저는 두터운 클라이언트 웹 애플리케이션을 충분히 돌릴 정도로 발전하였다. SproutCore 웹 애플리케이션은 클라이언트-서버 컴퓨팅의 장점을 가진 웹서비스의 힘과 융통성을 조합한다. 덕분에 애플은 "웹 클라이언트-서버"라는 신모델을 내세울 수 있게 되었다. Mobile Me의 웹용 애플리케이션은 이제 WebObjects와 WebDAV 서버가 운영하는 웹서비스로 묶이게 되었다. 하지만 SproutCore 웹애플리케이션을 PHP나, XML, JSON 오브젝트와 같은 방식을 제공하는 서버에 묶어둘 수 있다. Yellow Box의 죽음, 그리고 Cocoa Thinking Outside the Yellow Box. 윈도용 코코아, 혹은 옐로 박스의 부활을 지금도 기다리신다면, 이제는 기다림을 멈추고 코딩을 시작할 때이다. SproutCore가 레퍼드 코코아의 가치를 웹으로 가져다주고, 자바스크립트를 이미 데스크톱 기능 지원용으로 내장시킨 풍부한 애플리케이션 플랫폼으로 안겨다주기 때문이다. 오픈소스와 개방형 웹표준에 기반을 두기 때문에, SproutCore를 사용하면, 플러그인이나 특정 기업에 얽매이지 않은 크로스 플랫폼 애플리케이션 개발을 할 수 있다. 웹표준을 깔고 앉으면 애플과 커뮤니티도 윈도의 레이어가 갑자기 변한다 할지라도 우려할 일이 전혀 없어진다. 이 점만 생각하면, 그런 변화는 예전 윈도용 옐로 박스나 윈도용 코코아에게 상당한 문제를 야기할 수 있다. SproutCore는 또한 잘 알려진 보안의 보호를 받기에, 새로운 런타임 레이어가 알려지지 않은 구멍을 여는 것도 걱정할 필요가 사라진다. Make Apple SaaS. 이 모든 개선이 새로우 잠재성을 깨우게 된다. 이미 애플은 .Mac으로 대 소비자 "서비스로서의 소프트웨어"를 조용히 앞지르고 있는 중이다. 구글과 야후, MSN이 그동안 광고를 내세워서 온라인 메일과 사진, 그 외 애플리케이션을 시도하였지만 애플은 .Mac 서비스를 가입자에게 판매하는 독특한 방식을 추구해 왔었다. 애플이 하는 일은 모두가 원하는 일이다. Mobile Me는 .Mac으로 아이폰 사용자들까지 흡수하겠다는 내용이랄 수 있다. 아이폰은 또한 엄청나게 많은 윈도 사용자들 눈앞에 맥오에스텐 애플리케이션을 갖다놓게 된다. 잠재성이 더욱 더 극대화되는 것이다. SproutCore 버전의 iWork가 온라인으로 나온다면, 그것도 맥과 윈도 사용자 모두가 사용할 수 있게 된다면? Back to My Mac 기능이 확장하여, 가정 파일공유가 바로 가능해지고, VNC 화면 공유 서비스가 웹을 통해 가능해진다면? 써드 파티는 어떨까? Mobile Me 플랫폼상에 뛰어들고 싶어할 기업 개발사들도 분명 있을 것이다. 애플 또한 써드파티 웹 애플리케이션 기업들을 끌어다 둘 생각을 할 것이다. 심지어 서비스의 일부러 번들시킬 수도 있을 것이다. 그러면 Mobile Me의 가치가 더 높아진다. 돈을 조금 더 내면 사용할 수 있게 할 수도 있겠다. 아이폰과 모바일 푸시 싱크와 직접적인 웹접속을 제공하는 QuickBooks의 Mobile Me 버전을 상상해 보시라. Apple - MobileMe - Features The WebApps Store. 웹 개발자들은 자기 서비스를 판매하기가 불가능하다는 현실을 깨달을 때가 있다. 하지만 애플은 이 문제를 해결할 수 있다. 모바일 소프트웨어의 동일한 문제를 해결한 방식과 같다. 아이폰 App Store를 Mobile Me 안에다 동일하게 심어 넣으면 된다. 그러면 웹 애플리케이션 시장이 실제로 형성될 수 있으며, 웹 서비스 또한 아이튠스의 확장처럼 작동할 수 있게 된다. 사실 애플은 아이튠스 안의 WebKit에다가 바로 이런 스토어를 추가시켜서 Mobile Me 애플리케이션을 바로 광범위하게 보여줄 수 있다. 물론 웹용 애플리케이션 판매를 꼭 아이튠스에 묶어둘 이유는 없다. 윈도용 사파리를 애플이 갖고 있기도 하고, 결국 파이어폭스나 인터넷 익스플로러에서도 돌아갈 터이기 때문이다. App Store가 흥미롭다 여긴다면, Mobile Me 시장도 정말 흥미롭겠다는 생각이 들 것이다. 유사 Flash 애플릿이나 제공하는 Facebook이 무료 서비스로서 이윤이 남질 않는다고 모두들 불평한다. 진짜 애플리케이션과 웹서비스를 돈 받고 충성스러운 사용자들에게 제공하는 애플은 어떨까? 심지어 이윤까지 올린다고 하면 꽤 관심을 받잖을까 싶다. I really like to hear from readers. Comment in the Forum or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks! Cocoa for Windows + Flash Killer = SproutCore __________________ FAQ