gluebyte

애플이 넥스트를 인수한 거였나요, 아니면 그 반대였나요? 애플의 현재를 보고 있으니 갑자기 역사가 헷갈릴 정도입니다.

casaubon

The Future of the Web: Safari, Firefox and Internet Explorer

Saturday, June 23, 2007

1993년으로 되돌아가서, 15년간 독점적 기술에 묶이게 될 세상을 구한다고 해 보자. 그동안 세상의 혁신과 개발은 겨우 몇 명의 세일즈맨의 손아귀 안에 놓여 있었다.

그러면 세상을 어떻게 설득시킬까?

• 넷스케이프와 인터넷 익스플로러 간의 웹브라우저 전쟁은 완전히 불필요하다.
  
• PC 데스크톱이 하나의 기업에, 그것도 제한적이도 파트너들을 존중하지도 않는 회사에 묶일 필요는 없다.
  
• 마이크로소프트에게 무릎을 굽히기 위해, 1993년 최고의 객체지향 기술을 묻힐 필요는 없다.
  
• 빌 게이츠 없이도, 소프트웨어는 더 좋아지고 저렴해지며, 더 빨라지고, 보안도 더 좋아질 수 있다.

물론 시간여행을 할 수 있다 하더라도 설득시키기는 어려울 것이다. 이미 당시에도 기술 업계가 잘못된 방향으로 흘러가고 있으며, 오픈소스와 공개표준의 사용이 기술을 보다 효율적으로 진보시키리라 주장한 개인과 기업은 여러 군데 있었다.

[넷스케이프와 인터넷 익스플로러]
[1995년은 2007년에 되풀이될 수 없다 ]]
[1990-1995, 카이로로 가는 머나먼 길]
[애플, NeXT 서버로 무장하다]

Advocates of an Open World.
그런 선각자들 중에 80년대 초반 때부터 자유 소프트웨어 운동을 해온 리차드 스톨만(Richard Stallman)이 있다. 그는 Free Software Foundation을 세우고, GNU 프로젝트를 만들었으며, GNU General Public License를 소프트웨어 프로젝트의 "언론의 자유"라 칭하였다.

80년대 말, 스티브 잡스의 NeXT는 BSD에서 나온 오픈소스 코드상에서 운영체레를 만들었으며, 처음부터 다시 다 바꿔서 만들 필요가 없음을 배웠다. 90년대 중반, 넥스트는 OpenStep 사양으로서 핵심 기술을 스스로 개방하였다. GNU가 이를 구현한 것이 바로 GNUStep이다.

마이크로소프트가 약속했으나 절대로 나오지는 않은 허풍 소프트웨어인 카이로와 넥스트는 힘겨운 경쟁을 벌였다. 애플의 넥스트 인수 이후, 잡스는 애플에 있어서도 공개 개발과 업계 표준 채택을 늘려갔다. 또한 그저 보여주기 목적이 아닌, 실제적인 사용을 독려하였다.

넥스트가 나타난 이후, 당시 BSD는 독점적인 코드 소송에 휘말려 있었으며, 이네 무료 리눅스 커널 작업을 시작한 리누스 토발즈(Linus Torvalds)가 있다. GNU는 그의 커널을 사용하여, 리눅스를 완전한 운영체제로 만든다.

90년대 후반, 에릭 스티븐 레이몬드(Eric Steven Raymond)와 브루스 퍼렌스(Bruce Perens)는 공개개발의 개념을 재정의하고, 오픈소스 구상(OSI)에 여론의 관심을 모았다. 넷스케이프가 오픈소스 모질라 프로젝트로 변모한 것도 OSI 덕분이었다.

이러한 표준-기반의 오픈소스 개발이 언제나 동의를 모으지는 않았다. 토발즈와 스톨만, 스톨만과 레이몬드는 공개 소프트웨어의 작동 방식에 대해 상당히 다른 의견을 보였으며, 오픈소스 라인의 양다리에 걸쳐 있는 애플에 비판적인 운동가들도 많다.

[애플의 오픈소스 공격]
[BSD와 GPL, 그리고 애플]
[오픈소스의 저열한 무리들]
[애플과 오픈소스]

Enemies of an Open World.
그러나 그 바깥은 모두가 다 동의하는 세상이다. 공개개발의 원칙은 공개가 되어있지만, 공개적으로 경쟁을 못 하는 회사들은 이러한 공개개발의 적이다.

공개개발은 특히 마이크로소프트에게 위협이다. 빌 게이츠와 스티브 발머를 위시한 마이크로소프트의 중역진들은 공개개발을 보통 소프트웨어 업계의 "암"이라 칭한다. 마이크로소프트의 성공도 폐쇄형, 독점적 개발에 기반하고 있었다.

혁신의 경쟁압박이 없는 단일 기업이 지배하는 폐쇄적인 세상을 칭송하는 여러 분석가들은 그러한 칭송으로 생계를 이어왔다.

Forrester Research가 인수했다가 Dataquest로 넘어가고, 다시 Gartner가 인수한 Giga Information Group의 로브 엔더를(Rob Enderle)이 있다. 이런 씽크탱크 사람들은 언제나 개방과 공개에 진저리를 친다. 엔더를 자신은 이제 홀로, 반-오픈, 친-마이크로소프트를 늘상 읊어대는 게으른 분석가가 되었다.

그런데 공개 개발의 간단한 개념을 혼란스러워하는 친-마이크로소프트 칼럼니스트들이 많다. 이들은 단어의 의미도 잘 이해하지 못한 채, 오픈이니 독점형이니 하는 단어들을 내뱉는다. 보통 이들은 마이크로소프트가 공개표준의 원천이라 칭한다. 개발자들이 윈도용 애플리케이션을 만들 수 있어서라는 이유다!

[마이크로소프트의 이길 수 없는 전쟁]
[iTunes와 AppleTV가 죽는데요]
[Bill Gates for President? No Thanks.]

An Open Web Without Time Travel?
시간여행을 할 수 없다면, 90년대를 구할 방법이 없다. 그래도 미래는 바꿀 수 있다. 지난 날의 교훈을 되새기면, 단일 기업의 시장 지배가 기술의 빠른 진보나 혁신을 내지 않았음을 이제 알기 때문이다.

업계의 지배자가 애플이건, 마이크로소프트이건, 그것만은 사실이다. 애플은 그래픽 데스크톱을 지배하였지만, 존 스컬리 시절, 1988년부터 1995년까지의 우위를 상실해 버렸다. 그 뒤, 1995년 이래 내려온 마이크로소프트의 지배가 흔들리는 것도 마찬가지다. 데스크톱은 건강한 경쟁을 필요로 한다.

그러나 90년대 중반 이후, 웹에 있어서의 경쟁 기회는 마이크로소프트때문에 억눌려졌다. 마이크로소프트는 웹 기반 애플리케이션의 잠재성을 잘라내버리고, 웹 개발을 윈도 독점에 묶어버렸다. 경쟁력 있는 플랫폼 대신, 웹은 또다른 윈도의 확장이 되어버렸다.

[파이어폭스와 사파리, 웹브라우저의 르네상스]
[1990-1995: 기업시장에서의 애플 대 마이크로소프트]
[애플과 마이크로소프트: 플랫폼의 위기]
[1990-1995: 옛 기술 지원의 함정]

The Return of an Open Web.
모질라 안에서 다시 태어난 파이어폭스는 표준 기반의 브라우저로 나타났다. Opera나 KDE의 Konquerer, 애플의 사파리 모두 상호운용성에 기반을 둔 범용, 공개 웹 플랫폼을 지원한다.

하지만 웹브라우저 기존 시장기반의 절대다수는 여전히 마이크로소프트 치하에 있다. 그렇다면 어째서 인터넷 익스플로러를 그냥 웹 표준으로 지정하지 않을까? 마이크로소프트의 표준이 QWERTY 키보드와 마찬가지라 생각하는 이들도 있고, IE가 이상적이지 못하다 생각하는 이들도 있다. 쓸 만할 정도이고, 널리 쓰이는 경우를 사실상의 표준이라 말한다.

문제가 있다. IE는 전혀 표준을 따르지 않는다. 모든 키보드의 키 배열이 제멋대로인 상황을 생각해 보시라. 게다가 특정 키는 워드에서만 통하고, 윈도용 PC에서 써드 파티 키보드를 쓸 때 모음을 칠 수 없다면? 비-표준의 상황이 바로 이와 같다!

WHATWG의 HTML 5, FTW.
2004년, 애플과 모질라, 오페라는 WHATWG(Web Hypertext Application Technology Working Group) 작업을 시작한다. 웹 애플리케이션을 보다 쉽게, 보다 강력하게, 보다 플랫폼 간에 일관성 있게 구축하는 것을 목표로 잡고, 코드를 보다 깔끔하게 하여 웹 표준을 개선시키는 그룹이다.

WHATWG 회원사들은 마이크로소프트도 참여를 권했다. 그것도 대표 회사로서의 참여를 권했지만, 마이크로소프트는 참여를 거절한다. 이 그룹이 개방되어 있어서 누구나 실질적으로 기여할 수 있으며, 현재는 W3C와 함께, HTML 5 언어 마무리 작업을 진행중이다.

HTML 5는 훨씬 자세해졌기에, 기본적인 일까지 개별 기업이 일일이 만들어낼 필요가 사라졌다. 근본적인 일을 하기 위한 범용 표준을 정의내리면, 기업들은 호환성 없는 제품을 서로 제공하기보다, 최고의 구현, 최고의 혁신을 제공할 수 있게 된다.

Until HTML 5 There의 Web 2.0.
HTML 5이 나오기 전에, 공개 웹 플랫폼에 제일 접근한 것은 오늘날의 Web 2.0이다. Web 2.0은 공개 웹 애플리케이션의 새 세대에 힘을 불어 넣어주는 공개표준의 개념을 지닌 단어다.

그저 겉치장뿐만이 아니다. Web 2.0은 어느 브라우저와도 연동이 가능하도록 되어 있으며, 표준을 지원한다. 혁신하려는 회사에게는 좋은 소식이다. 하지만 90년대 식을 우기려는 회사에게는 나쁜 소식이다.

공개 웹은 브라우저 개발사들 간의 혁신 경쟁을 촉발시킬 가능성이 크다. 그렇다면 소비자 선택도 윤택해진다. 이러한 웹의 개방이 애플과 마이크로소프트, 모질라에 어떤 영향을 끼칠까?

The Positioning of Safari, Firefox, and Internet Explorer.
모질라 COO, 존 릴리(John Lilly)는 애플이 파이어폭스를 시장에서 갈아치우려 한다고 멋대로 상상해냈다. 유일한 증거란 윈도용 사파리 옆에 마이크로소프트 밖에 없는 차트였다. 분명 시장을 잃을 자는 파이어폭스라는 논리다.

웹브라우저 시장에서 마이크로소프트의 시장점유율은 이제 세 가지 방어선에 좌우된다. 그런데 이 세 전선을 유지하기가 점점 버거워진다.

1. 쉬운 방어선: 대안이 있는지도 모를 게으른 소비자들
   
2. 보통의 방어선: 윈도나 IE에 의존적일 수 밖에 없는 소비자들
   
3. 어려운 방어선: 혁신이나 기능때문에 IE를 선호하는 소비자들

마이크로소프트는 독점적인 지위를 유지하기 위해 첫 번째 방어선에 수동적으로 의지하고 있다. 그런데 두 번째의 방어선은 마이크로소프트의 적극적인 방어를 요구한다. 세 번째 방어선을 막으려면, 아예 마이크로소프트의 상당한 투자가 필요하다. IE는 무료이기 때문에, 경쟁력이 요구하지 않는 한, 마이크로소프트로서야 혁신을 일으킬 이유가 없다.

마이크로소프트와 관련해서, 파이어폭스의 모질라는 정 반대의 위치다.

1. 어려운 공격: 대안을 다운로드받을 이유가 있어야 한다.
   
2. 어려운 공격: 흥미를 끌 만한 상호운용성을 제대로 제공해 줘야 한다.
   
3. 어려운 공격: IE보다 앞선 혁신을 꾸준히 유지시켜 주어야 한다.

애플의 윈도용 사파리도 모질라 파이어폭스와 동일한 위치다. 하지만 사파리는 맥 플랫폼에서 기본 브라우저다. 이것만은 마이크로소프트와 유사하다. 이 때문에 애플은 중간자적 입장이다. 리눅스와 윈도 사이에 처한 운영체제 상황과 유사하다.

애플과 모질라의 동맹은 대안이 있다는 것, 상호운용성의 강조와 혁신 주도에 모두 도움이 된다. 반면 마이크로소프트로서는 특정 브라우저와 윈도에 계속 웹을 묶어 두어야 이롭다.

Learning from the Past.
10년간의 컴퓨터 업계와 웹브라우저의 역사에서 업계는 교훈을 얻었을까? 오늘날 "풍부한 인터넷 애플리케이션" 개발을 내세우는 업체가 많다. 그런데 이들은 예전 넷스케이프와 인터넷 익스플로러처럼, 고유의 기술에 웹 개발을 묶으려한다.

• Adobe의 Apollo/AIR, Flash와 Flex 기반 (필자는 Flashplications이라 부른다).
  
• Microsoft의 Silverlight, .NET과 Vista의 WPF, XAML.
  
• Sun의 JavaFX, Java의 새로운 익스텐션에 기반.
  
• Mozilla의 XUL, 예전 Mozilla Application Suite의 기반

과거로부터 배울 점이 있다. 지난 10년간 애플은 온라인 개발 접근 방향을 변경시켜왔다. 인터랙티브 웹 개발을 퀵타임 아키텍쳐로 집어 넣는 대신, 이제는 공개 산업표준의 사용으로 바꾼 것이다.

Scouring Scum off the Web with Ajax.
애플의 웹 개발 정책은 EMCA의 표준 JavaScript와 표준화된 XML용 비대칭 HTTP 리퀘스트 아키텍쳐로 모아져 있다. 이들 공개 기술을 한데 모아 Ajax라 부른다.

Ajax 웹 개발을 홍보하기 위해 애플은 구글과 손잡고, 표준-기반 개발의 사용 확대를 위해 작업중이다.

애플 자신의 웹사이트도 Flash와 같은 폐쇄형 플러그인 대신, Ajax를 구현시키는 편으로 이주하였다.

그 첫 사례가 새로운 애플 웹사이트에서 벌인 검색결과 필드이다. 이 필드를 보면, 사용자가 친 문자와, 결과를 종류별로 나타내고 있다.

아래 사진을 보면, 검색 결과가 웹페이지에 국한되지 않고, 아이튠스 스토어도 찾아냄을 알 수 있다. 영화 예고편과 포드캐스트마저도 찾아준다. 애플 웹사이트에서 본지를 검색해 보시라. 검색 결과 창에서 필자의 포드캐스트를 찾으실 수 있다!


There Is One More Thing...
윈도용으로 사파리를 포팅시킨 또 다른 이유가 한 가지 있다. 다음 기사에서 밝힌다. 무엇인지 맞추어 보시라!

Register your own ideas in the RoughlyDrafted Forum.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast!

Did I miss any details?

The Future of the Web: Safari, Firefox and Internet Explorer

__________________
FAQ

casaubon

Safari's Controversial Potential as a New Yellow Box for Windows

Monday, June 25, 2007

금요일 날 썼던 글, "사파리, 그리고 코코아"에 대한 독자글이 꽤 왔었다. 게다가 필자의 크로스-플랫폼 개발 문제 글이 오해를 불러 일으킬 수 있으며, 부정확하게 쓰여졌다고 걱정하는 블로그도 있었다. 본 글은 그 점을 해명해 본다.

[사파리, 그리고 코코아]

The Beast with Two Backs.
글 자체는 한 가지 주제를 향한 두 가지 아이디어로 짜여져 있다. 그런데 그 두 아이디어가 너무나 얽혀서 분리할 수 없었다. 그래서 하나의 글로 내보내고 제목에 두 아이디어를 모두 붙여 놓았다.

첫 번재 아이디어는 사파리가 아이튠스와 얼마나 닮았나처럼 보인다. 둘 다 공개표준을 강조하여, 시장을 만들어냈다. 또한 맥에 관심 있는 윈도 사용자들에게 있어서, 사파리는 애플이 제공하는 좋은 미끼가 될 수 있다. 아이튠스나 퀵타임의 전례를 따를 수 있다는 얘기다.

어느 것도 논쟁 거리랄 수는 없다. 문제는 기사의 두 번째 아이디어다. 윈도용 사파리를 만들기로 한 이유와 방법, 그리고 애플 전략과의 관계이다.

필자의 코코아와 옐로박스 묘사가 오해를 불러일으키도록 쓰여 있을까? 코코아와 맥오에스텐이 어디에서 나왔는지를 짧게나마 돌아보면, 혼란감을 어느 정도 없앨 수 있잖을까 싶다.

The Evolution of NeXT Before Apple.
애플에게 인수되기 전, 넥스트의 운영체제 전략은 여러 가지 방향으로 전진하고 있었다. 표준형 BSD 유닉스 커널과 마흐가 같이 들어간, 모노리딕 커널을 기반으로 한 NeXTSTEP은 하나의 완전한 운영체제로 시작했었다.

넥스트스텝의 Mach/BSD OS(기능적으로 리눅스와 유사하달 수 있겠다)의 최상단에 넥스트는 다른 레이어를 개발해 놓는다. 그리고 견고한 객체지향 프레임웍을 제공하는 데에 있어서, 이 레이어가 보통의 운영체제를 뛰어 넘었다. 내장된 기능을 강화시켰을뿐 아니라, 써드파티에게 있어서 빠른 애플리케이션 개발엔진의 역할도 하였다.

넥스트는 매킨토시로부터 상당한 영향을 받았다. 넥스트 엔지니어들 다수가 원래 애플 출신이었다. 쟝-루이 가세의 정책, 고마진 소판매주의때문에, 존 스컬리의 애플이 보수적인 전략으로 돌아서 버리자, 차세대 "최고로 훌륭한" 컴퓨터를 만들어 보려는 사람들이었다.

NeXTSTEP은 여러가지 "키트"로 모듈화되어 있었고, 이 키트(kit)가 맥 툴박스처럼 행동하였다. 하지만 맥처럼 파스칼이나 C 라이브러리를 갖추지 않고, 넥스트는 오브젝티브 C 언어를 사용하여 이들 라이브러리를 현대적인 객체지향 프레임웍화 시켰다. 이들 키트는 다음과 같다.

• 핵심 기능을 가진 Foundation Kit
• 애플리케이션 수준의 기능과 관련된 App Kit
• 특화된 기능을 가진 Sound Kit이나 Music Kit, DB Kit, 등

이들 키트 프레임웍 기능은 후에 Mach/BSD 코어 운영체제에서 벗어나, OpenStep 사양을 낳게 된다. 즉, 썬 솔라리스와 마이크로소프트 윈도 상으로 포팅된 것이다.

[1990-1995, 핑크와 탈리전트, 코플랜드의 비밀]
[iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스]
[Mac OS X 마이크로커널의 미신을 벗긴다 2]

Rhapsody Reborn as Mac OS X.
원래 애플은 맥오에스 사용자들을 NeXTSTEP/Mach의 PowerPC 포팅으로 바로 이주시키는 한편, 솔라리스와 윈도용 OpenStep 프레임웍을 제공하기 원했었다. 새로 나올 NeXTSTEP-기반의 파워맥 운영체제와 호환성을 계속 지키면서 말이다.

애플은 이 NeXTSTEP/Mach를 "랩소디(Rhapsody)"라 부르고, OpenStep을 "옐로박스(Yellow Box)"라 불렀다. 애플이 재빠르게 개발자들을 옐로박스로 이주시켰더라면, 넥스트가 제공했던 진보적인 크로스-플랫폼 환경을 그 때부터 가졌을 것이다.

하지만 이 계획을 철회하게 된 이유가 여러 가지 있다.

• 개발사들은 기존 맥용 애플리케이션의 네이티브-수준 호환성을 요구하였다.
  
• NeXTSTEP은 Display PostScript와 같은 너무나 비싼 기술을 라이센스하고 있었다. 저가형, 소비자용 운영체제에서 쓰기에 비쌌다. (NeXTSTEP은 카피당 700달러에 팔렸다.)
  
• NeXTSTEP도 1997년 당시 현대화와 대대적인 개수가 필요했다. 그동안 거의 개발투자가 이뤄지지 않았기 때문이다. 그러나 마이크로소프트의 장벽때문에 그런 작업이 불가능했다. 그래서 넥스트는 1994년, OS를 포기하고, 특화된 플랫폼을 목표로 잡았다. 그 첫 번째가 다른 운영체제용 OpenStep 환경이었고, 두 번째가 WebObjects였다.

당시 애플은 2001년, 맥오에스텐으로 맥과 넥스트 혼합품을 처음 선보인다. 그 때 이후로 맥오에스, 혹은 넥스트스텝은 상당한 진보를 이루었다. 그런데 애플은 다른 플랫폼용 옐로박스 런타임을 철회하였다.

이 전략 변화 와중에 넥스트 객체지향 키트의 증가도 있었다. Core Foundation을 포함한, 프로시져형 C++ 라이브러리의 추가가 이루어졌다.

덕분에 예전 맥오에스용 애플리케이션도 카본이라 불리는 고단위 C++ 라이브러리를 사용하여 네이티브 실행이 가능해졌다. 옐로박스의 종말이었다.

[Yellow Box의 죽음, 그리고 Cocoa]

Yellow Box is Not Cocoa.
애플은 또한 보다 현대적이고 객체지향적인 프레임웍, 코코아를 제공한다. 넥스트스텝의 App Kit에 대응하는 프레임웍인 코코아는 객체지향 인터페이스를 입힌 Core Foundation 안에서, 프로시져형 C++ 함수를 깔고 있었다.

옐로박스를 "윈도용 코코아"라 부르는 이들이 많은데, 그런 표현이 정확하지는 않다. 옐로박스는 맥오에스텐에서 쓰이는 공유 C++ 코드 기능을 대단히 많이 포함하고 있다. 애플은 이 부분을 코코아라 일컬은 적이 없다.

Cocoa is not the Yellow Box.
사파리 포팅에 대해 "코코아의 일부"를 언급했었지만, 필자가 정확하지 않았다. 옐로박스의 유사한 부분이 코코아였던 적이 없어서이다.

물론 기사의 주안점에서 볼 때, 옐로박스와 코코아 간의 정확한 차이가 그렇게 중요하지는 않다. 주안점은 애플이 사파리의 일부로서, 윈도용 옐로박스 기능과 관련된 부분을 많이 포팅시켰다는 정도다.

즉, 써드파티가 갑자기 자기 애플리케이션의 포팅을 돕는 메커니즘으로서, 사파리에 실린 윈도용 DLL을 개념적으로 사용할 수 있다는 의미다. 물론 애플이 일단 유용하다 생각을 해야 제공할 일이다.

흥미롭게도, 애플은 이미 CF Lite를 통해 Core Foundation의 하부를 공개해 놓은 상태다. CF Lite는 맥오에스텐용 애플리케이션을 특히 리눅스와 같은 유사-유닉스 환경용으로 포팅할 때 쓰라고 만들어 놓은 오픈소스 라이브러리다.

따라서 필자가 언급한 원칙은 제한적으로나마 이미 구현되고 있다. 얼마나 더 이런 식으로 가느냐는 애플의 마음먹기에 따라 달려 있다. 전략적 유지가 가능하고, 합리적이라면, 그런 전략을 펼치지 못할 것도 없다.

[Creating Cross-Platform Applications with Core Foundation and Open Source]

Still Cuckoo for Cocoa?
애플이라면 윈도용으로 코코아 구현을 완전히 제공할 수도 있다. 그러면 Core Foundation과 Core Graphics의 많은 부분이 훨씬 더 쉬워졌을 것이다. 애플이 코코아를 통해 ARM-기반의 아이폰 작업을 한다는 사실도, 코코아의 포팅 가능성이 무궁무진하다는 점을 가리킨다.

코코아 정의 내리기는 일단 뭐가 무엇인지 알아보려는 시도일 따름이다. 현실은 간단하다. 애플은 자기 자신의 프레임웍을 통해, 윈도용 사파리를 흥미롭게 선보였다.

그리고 여기에는 사파리를 윈도상에서 보다 "맥답게" 만드는 것 이상의 의미가 있다. 아직 해야 할 일이 많긴 하지만, 써드파티 애플리케이션의 포팅 가능성에게도 기회를 주기 때문이다. 기존의 맥 애플리케이션 포팅이 쉽지 않은 경우가 많을 테지만, .Net의 대안으로 존재할 가능성은 있다.

필자가 전에 지적했듯, 애플의 사업계획은 이와 전혀 다를 수도 있다. 10년 전 넥스트에서, 그리고 그 후 애플에서 동일한 전략은 두 번 실패하였다. 물론 상황은 그때와는 비약적으로 달라졌다.

The Constant of Change.
2년 전, WWDC 2005에서 애플은 인텔로의 이주를 발표하였다. 그로부터 6개월 뒤, 인텔 맥이 나오고, 새로이 유니버설 바이너리가 나왔는데도, 이주는 참 부드러웠다.

가까운 장래에 애플이 엑스코드를 크로스-플랫폼용으로 개방시킬지는 두고 볼 일이다. 이미 사파리용으로 제공한 런타임은 특히 윈도를 겨냥하고 있다.

가능성으로 말하자면, 이것은 부정확하다거나 오해를 불러 일으킬 것도 없다. 원래 글은 윈도용 사파리가 "코코아 UI"를 지닌다 언급했다. "맥다운 아쿠아 규격 UI"라 묘사한다면야 더 정확해질 테지만, 대부분의 독자들은 코코아 UI를 아쿠아로 본다. 코코아 자체는 특별한 UI를 갖고 있지 않다.

게다가 윈도용 사파리가 특별히 객체지향 코코아 프레임웍을 사용하는 것 같지도 않다. 물론 10년 동안 나타난 것 중, 옐로박스에 제일 근접한 사례이긴 하다. 애플의 마케팅 용어에서 쓰이는 단어들 갖고 까다롭게 생각하기보다, 옐로박스를 염두에 두는 편이 훨씬 더 중요할 것이다.

Register your own ideas in the RoughlyDrafted Forum.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast!

Did I miss any details?

Safari's Controversial Potential as a New Yellow Box for Windows

__________________
FAQ