Cuckoo for Cocoa: Is Safari on Windows the next iTunes?

casaubon · 2007-06-25, 09:03 PM

Cuckoo for Cocoa: Is Safari on Windows the next iTunes?

Tuesday, June 19, 2007

윈도에 번들로 딸려 오는 윈도 미디어플레이어 소프트웨어 대신, 아이튠스와 퀵타임을 수 천만 본씩 깔지 않았더라면, 윈도 사용자들이 어째서 사파리를 쓸지도 상상하기 어려웠을 것이다.

사파리는 과연 아이튠스 수준의 성공을 누릴 수 있을까? 아니면 상황이 완전히 다를까? 이미 좋아하는 웹브라우저를 갖고 있는 마당에, 구태여 윈도 사용자들이 사파리를 써야 할 이유란 과연 무엇일까?

그런 이유를 한 번 살펴보겠다. 특히 애플이 이미 제공하는 아이튠스와 사파리가 공유하는 부분이 있으며, 이는 애플의 향후 전략에 흥미로운 가능성을 준다 하겠다.

Safari/3.0 Windows Intel (Like iTunes).
윈도용 사파리는 분명 아이튠스의 패턴을 따를 것으로 보인다. 윈도용 사파리 광고를 내걸 필요조차 없다는 이야기다. WWDC 발표만으로도 언론은 윈도용 사파리를 대대적으로 보도하였다. 심지어 사파리는 애플의 첫 번째 윈도용 브라우저도 아니다. 첫 번째 브라우저는 아이튠스다.

아이튠스 내부의 온라인 아이튠스 스토어는 사실 단일 호스트, 애플 아이튠스 서버로부터 페이지를 받아 실행하는 특수한 클라이언트이다. 게다가 사파리와는 달리 WebKit 기반도 아니다. 따라서 사파리는 윈도 코드기반에서 새로운 애플리케이션으로서, 미지의 영역에 새로 발을 디딘다고 할 수 있겠다.

뭔가 다른 것은 새롭기도 하다. 맥용 사파리는 WebKit 디스플레이 엔진 최상단에 코코아 사용자 인터페이스를 제공한다. 그러나 윈도는 어떨까? 애플은 코코아 UI와 WebKit을 포팅시켰을뿐 아니라, 맥오에스텐의 Core Foundation과 Core Graphics까지 윈도용으로 포팅시켰다.

Apple’s Beta Browser Blues.
이러한 포팅은 무엇을 의미할까? 애플은 사파리를 베타용 브라우저만으로 내보내지 않았다. 베타 코어 라이브러리도 내보냈다. 오히려 마이크로소프트 네이티브 .Net 프레임웍 상에서 사용자 인터페이스를 구축했더라면, 윈도용 사파리는 버그나 오류가 잠재적으로 더 적었을 것이다.

애플은 구태여 코어 프레임웍까지 포팅시켜가지고 더 많은 버그와 보안 문제에 사파리를 노출시켰다. 어째서 브라우저만으로 내놓지 않았을까? 더구나 윈도용 사파리가 사용하는 이들 코어 라이브러리에서 몇 가지 오류가 발견되자마자, 애플 비방꾼들은 일제히 어둠에서 깨어나 재잘거리기 시작하였다.

스스로 애플의 WiFi 보안을 해킹했노라 알려졌지만, 어떻게 했는지 검증을 회피한 것으로 유명한 해커가 있다. 바로 데이비드 메이너(David Maynor)이다. 윈도용 사파리가 나오자, 그는 사파리 공격에 대한 문서화되어있지 않은 공격을 거행하여, 헤드라인에 그의 이름을 올렸다. 물론 며칠 후 애플은 패치를 제공하였다.

표준형 윈도 애플리케이션이었다면, 사파리는 48시간 동안의 언론 비판과 FUD를 피할 수 있었을 터이다. 그렇다면 애플은 왜 이런 쉬운 길을 택하지 않고, 어려운 길을 택했을까?

Why Did Apple Port its Core OS X Libraries to Windows?
윈도용으로의 포팅을 할 때, .Net을 사용하면 분명 윈도에 어울리는 브라우저가 나왔을 것이다. 이 때문에 파이어폭스를 잡아먹기 위해 사파리를 내보냈다는 주장은 힘을 잃는다. 그저 윈도용 브라우저를 내놓기만 한 것이 아니기 때문이다. 애플은 다른 라이브러리의 포팅을 통해 두 가지 목표를 노리는 것으로 보인다.

First, Core Graphics와 Core Foundation의 윈도 포팅은 보다 맥다운 사용감을 준다. 윈도용 사파리를 써 보면 정말 맥에서 쓰는 것 같다. 윈도다운 사용감을 주려 했더라면, 많은 시간과 노력을 절약할 수 있었을 것이다. 아니, 차라리 외부에 용역을 줘도 됐을 일이다.

맥다운 느낌을 주는 사파리를 쓰다 보면, 윈도 사용자들도 애플의 사용자 인터페이스 컨벤션에 익숙해지게 된다. 게다가 투명 쉬트나 내장형 컬러관리같은 Core Graphic의 기능도 맛볼 수 있게 된다.

Second, Core Graphics와 Core Foundation의 윈도 포팅은 후일, 엑스코드의 확장을 안겨다줄 수 있다. 맥 개발자들이 자신의 코코아 애플리케이션을 윈도용으로 내보낼 여지가 생기기 때문이다.

즉, 윈도용 옐로박스의 부활이다. 완전히 죽어 묻혀졌던 옐로박스가 다시금 현대화된 모습으로 나타난 것이다.

[Yellow Box의 죽음, 그리고 Cocoa]
[레드박스의 미신을 벗긴다]

Thinking Outside the Yellow Box.
원래의 윈도용 옐로박스는 OpenStep의 구현 중 하나였고, 어도비 디스플레이 포스트스크립트 지원을 포함하고 있었다. 그런데 애플이 랩소디에서 맥오에스텐으로 전략을 변경하자, OpenStep과 윈도용 옐로박스 런타임이 맥오에스텐과의 호환성을 잃게 된다. 핵심 기반이 변경됐기 때문이다.

애플은 또한 기존 클래식 맥 개발을 카본 라이브러리로 유지시켰다. 맥오에스텐 소프트웨어 대다수가 카본, 혹은 카본과 코코아 혼합으로 만들어지는 시절이었기 때문에, 애플이 윈도용 옐로박스를 유지시킬 방도가 없었다.

하지만 그런 상황이 변해가고 있다. 애플이 유니버설 바이너리를 개발하고, 맥 개발자들을 엑스코드로 이주시켰기 때문이다. 덕분에 예전 68k 코드의 PowerPC 에뮬레이션 등, 모든 클래식 소프트웨어는 자연스럽게 사라졌다. 단일 개발툴 하의 맥 플랫폼 통일은 포팅 가능성도 훨씬 쉽게 만들어 놓았다.

[iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스]
[유니버설은, 인텔 이주가 아닌 인텔 포용이다]
[왜 애플은 이제서야 인텔을 사용하게 되었나]

Carbon and Cocoa: Which is Tastier?
애플은 또한 모든 미래 개발을 코코아로 이주해왔다. 카본은 앞으로도 한동안 존재할 테지만 메시지는 분명하다. 코코아가 미래다. 새로운 데스크톱용 애플리케이션은 물론, 아이폰용 내부 애플리케이션도 코코아를 사용한다.

카본과 코코아는 원래 맥오에스텐 내부에서 "라이벌 반쪽"의 개념이었다. 하나는 오래 전 맥 툴박스에 기반하는 존재였고, 다른 하나는 NeXTSTEP의 객체지향 프레임웍에 기반하는 존재였다.

하지만 10년에 걸친 맥오에스텐 개발기간동안, 카본과 코코아 모두가 사용하는 Core Foundation 프레임웍이 나타난다. 그렇다고 애플이 맥오에스텐의 "카본" 한 쪽을 저버리진 않을 것이다. 보다 상위 레벨 프레임웍을 합칠 뿐이다. 코코아는 더욱 더 매력적으로 변모할 것이다.

Cuckoo for Windows Cocoa.
윈도용 사파리에 들어간 코코아 기본 프레임웍은 애플의 욕심이 비단 맥-다운 브라우저에 있지만은 않다는 점을 일깨워준다. 엑스코드 개발자들에게 자신의 애플리케이션을 윈도용으로도 만들어줄 세련된 메커니즘을 제공하리라는 예상도 가능하다.

물론 테스트와 다듬기가 필요하다. 바로 그 목적에 쓰일 수단이 윈도용 사파리이다.

모든 애플리케이션을 윈도로 포팅하지는 않을 것이다. 다만 써드파티 개발자들이 크로스-플랫폼 옵션으로 개발을 하게 된다는 의미다. 어쩌면 마이크로소프트 .Net보다 코코아가 훨씬 더 매력적으로 다가설 수도 있다. 맥 플랫폼, 어쩌면 아이폰에서도 지원을 받는 별도의 무료 기능이 가세하기 때문이다.

[WWDC 2007: .Net과 Cocoa]

Pros and Cons of a Ported Cocoa.
써드파티 개발자용 크로스-플랫폼 코코아 전략을 애플이 실제로 추진하건, 추진하지 않건, 애플은 이미 내부적으로 상당한 가능성을 보여주었다.

아이폰 안에 있는 ARM
맥에 있는 PowerPC와, 인텔의 32, 64-비트 버전
윈도용 사파리

이러한 포팅 가능성은 NeXTSTEP의 산물이다. 실제로 넥스트스텝은 여러 CPU 아키텍쳐용으로, 여러 운영체제 환경용으로 포팅이 되었다. 포팅 가능성이 애플 고유의 핵심 전략 중 하나이기에, 애플이 크로스-플랫폼 개발용으로 코코아를 추진해도 놀랄 일은 아니다. 별도의 비용도 거의 들지 않는다.

윈도용 코코아가 금방이라도 나온다는 말은 아니다. 넥스트도 OpenStep을 실패했었다. 애플의 랩소디도 마찬가지의 실패였다. 물론 현재의 애플 상황은 1997년의 애플, 몇 해 전의 넥스트와는 확연히 다르다.

다만 주목해야할 점이 있다. 마이크로소프트의 상황이 예전과 판이하게 다르다. 윈도용 주요 개발 플랫폼인 Win32가 늙어가고 있으며, 마이크로소프트가 현재 이를 .Net으로 교체하려 노력중이다.

따라서 예전 그 어느 때보다도 개발자들이 코코아같은 대안을 찾을 만한 상황이다.

[BIOS PC를 뛰어넘은 애플 펌웨어]
[iPhone은 어째서 Symbian을 선택하지 않았을까]

Why Safari on Windows is the Next iTunes.
즉, 사파리가 개발자들에게 앞으로 상당한 반향을 일으킬 수 있다는 점은 알 수 있겠다. 그렇다면 소비자 전략에는 어떤 영향을 끼칠까? 다름 아닌 아이튠스의 패턴을 그대로 따르리라는 점을 들 수 있다.

마이크로소프트의 독점적인 윈도미디어 포맷에 대해, 표준-기반의 오디오를 뿌리기 위해 윈도용 아이튠스를 선보인 애플이다. 윈도에 포함된 것보다 더 나은 미디어 라이브러리를 제공함으로써, 애플은 모질라가 IE의 대안, 파이어폭스를 홍보하는 것과 마찬가지로, 아이튠스를 홍보하였다.

애플은 업계 표준 포맷 사용의 매력으로 아이튠스를 내세웠다. CD도 구울 수 있고, 포드캐스트도 다운로드받거나 출판할 수 있으며, 제일 덜 귀찮은 DRM으로 온라인으로 음악과 텔레비전 방송, 영화도 구입할 수 있다.

이와 반대로 마이크로소프트는 엄청난 돈을 투입하여, 윈도에 완전히 묶이는 폐쇄형 미디어 플랫폼을 조성하였다. 또한 다른 모든 미디어 기기와 상용 다운로드를 PlaysForSure라는 Janus DRM 하에 묶어 놓기도 하였다.

그러나 아이튠스는 윈도미디어와 PlaysForSure를 모두 물리쳤다. PC 운영체제에서 하던 짓을 미디어에서만은 못하게 막은 것이다.

마이크로소프트는 PlaysForSure 파트너를 모두 팽개치고, Zune으로 직접 경쟁하겠다는 발표를 하게 된다. 하지만 10억 달러를 들여놓고도 관심을 유지시키지도 못하는 상황을 맞이한 마이크로소프트이다.

[Zune, 그리고 마이크로소프트의 낚시질]
[두 얼굴의 괴물, Zune]
[최종병기 퀵타임]

Who Wants Safari on Windows?
소비자와 콘텐트 제작자들은 아이튠스가 터 놓은 미디어의 공개표준 사용을 보다 더 좋아했다. 사파리도 그와 마찬가지 방식으로 표준-기반의 웹 개발을 윈도-전용, 혹은 IE-전용 웹 개발보다 더 매력적이게 만들 수 있다.

애플은 또한 이 목표를 위해, 웹 개발자들을 돕는 웹개발 검사툴도 개발해 놓았다.

Drosera: JavaScript 디버거
Web Inspector: 페이지 각 요소의 속성을 점검하는 라이브 뷰어

[업데이트: 애플은 WWDC에서 새롭고 개선된 Web Inspector를 선보였다. 그래서 스크린샷을 포함시킬 수 있게 되었다.]

[Introducing Drosera - Surfin’ Safari]
[Introducing the Web Inspector - Surfin’ Safari]
[Yet another one more thing... a new Web Inspector! - Surfin’ Safari]

Similarities and Differences of Safari and Firefox.
분명 사파리와 파이어폭스 간에 겹치는 부분이 있다. 파이어폭스 주장처럼, 실제로 사파리가 파이어폭스의 시장점유율을 어느 정도 잡아 먹을지도 모른다. 그러나 사파리와 파이어폭스 모두, 서로 경쟁하기보다는 상부상조할 가능성이 더 크다. 둘 모두 서로 다른 종류의 사용자들에게 각각 매력적이기 때문이다.

가령, 파이어폭스는 리눅스용 표준 브라우저로 존재하며, 사파리가 제공하지 않는 기능을 윈도용으로 제공한다. 파이어폭스의 여러가지 플러그인 기능에 대한 애플의 대응 기능은 없다.

사파리 또한 북마크 라이브러리나 RSS 뷰어, 더 가볍고 빠른 렌더링 엔진, 색상 매치 그래픽지원 등, 파이어폭스에 없는 기능을 몇 가지 제공한다. 또한 윈도 PC에서 일을 해야 하는 맥 사용자들에게도 좋은 선택이 사파리다.

파이어폭스와 사파리 모두 맥 플랫폼상에서 공존하고 있으며, 맥 사용자들은 둘 모두를 사용할 만한 이유가 충분히 있다. 윈도용 사파리가 나왔다고 해서 변치 않는 상황이 존재하기 때문이다. 하나의 브라우저만 사용하기 좋아할 수도 있겠지만, 웹브라우저를 하나만 써야한다는 규칙은 없다.

사파리는 또한 아이포드와 아이폰, 에어포트 익스트림 사용자의 설치 CD에 들어갈 것이 분명하다. 퀵타임이나 아이튠스 다운로드를 받으면서 끼어들어갈 수도 있다. 파이어폭스의 손길이 미처 닿지 못하는 사람들에게 사파리가 간다는 의미다.

[파이어폭스와 사파리, 웹브라우저의 르네상스]
[넷스케이프와 인터넷 익스플로러]
[애플과 웹브라우저]

The Other Obvious Reason for Safari on Windows: iPhone.
물론 윈도용 사파리가 나온 제일 확실한 이유는 다름 아닌 아이폰이다. 아이폰도 사파리 렌더링 엔진을 사용한다. 윈도용 버전을 출하하면서 애플은 사파리 브라우저의 범위를 넓힐 것이다. 사파리, 그리고 아이폰에서도 잘 보여야 하도록 웹을 만들어야 할 상황이 올 수 있어서이다.

아이폰을 겨냥한 개발자들로서도, 사파리를 사용해 PC에서 테스트를 벌일 수 있다. 당연하다. 그리고 애플은 사파리를 예전 넷스케이프나 인터넷 익스플로러의 범주에 넣으려하지 않을 것이다. 넷스케이프와 인터넷 익스플로러는 개발자들을 자사 익스텐션에 묶어 놓았다. "best when viewed from Safari" 같은 웹사이트도 없을 것이다.

그 대신 애플은 정 반대의 행동을 하고 있다. 제일 표준을 지키는 브라우저로서, 인터넷 공동체가 사파리를 승인하고 채택하도록 독려하는 행동이다. 새로이 HTML 5 표준을 제정하는 그룹 회원사로서 애플은 웹을 개방형으로 만들기 위해 작업중이다.

그 의미는 무엇일까? 다음 기사 제목이다. The Future of the Web: Safari, Firefox and Internet Explorer

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?

Cuckoo for Cocoa: Is Safari on Windows the next iTunes?

2007-06-25, 09:03 PM	#15
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz Posts: 2,397 온라인	사파리, 그리고 코코아 Cuckoo for Cocoa: Is Safari on Windows the next iTunes? *Tuesday, June 19, 2007* 윈도에 번들로 딸려 오는 윈도 미디어플레이어 소프트웨어 대신, 아이튠스와 퀵타임을 수 천만 본씩 깔지 않았더라면, 윈도 사용자들이 어째서 사파리를 쓸지도 상상하기 어려웠을 것이다. 사파리는 과연 아이튠스 수준의 성공을 누릴 수 있을까? 아니면 상황이 완전히 다를까? 이미 좋아하는 웹브라우저를 갖고 있는 마당에, 구태여 윈도 사용자들이 사파리를 써야 할 이유란 과연 무엇일까? 그런 이유를 한 번 살펴보겠다. 특히 애플이 이미 제공하는 아이튠스와 사파리가 공유하는 부분이 있으며, 이는 애플의 향후 전략에 흥미로운 가능성을 준다 하겠다. Safari/3.0 Windows Intel (Like iTunes). 윈도용 사파리는 분명 아이튠스의 패턴을 따를 것으로 보인다. 윈도용 사파리 광고를 내걸 필요조차 없다는 이야기다. WWDC 발표만으로도 언론은 윈도용 사파리를 대대적으로 보도하였다. 심지어 사파리는 애플의 첫 번째 윈도용 브라우저도 아니다. 첫 번째 브라우저는 아이튠스다. 아이튠스 내부의 온라인 아이튠스 스토어는 사실 단일 호스트, 애플 아이튠스 서버로부터 페이지를 받아 실행하는 특수한 클라이언트이다. 게다가 사파리와는 달리 WebKit 기반도 아니다. 따라서 사파리는 윈도 코드기반에서 새로운 애플리케이션으로서, 미지의 영역에 새로 발을 디딘다고 할 수 있겠다. 뭔가 다른 것은 새롭기도 하다. 맥용 사파리는 WebKit 디스플레이 엔진 최상단에 코코아 사용자 인터페이스를 제공한다. 그러나 윈도는 어떨까? 애플은 코코아 UI와 WebKit을 포팅시켰을뿐 아니라, 맥오에스텐의 Core Foundation과 Core Graphics까지 윈도용으로 포팅시켰다. Apple’s Beta Browser Blues. 이러한 포팅은 무엇을 의미할까? 애플은 사파리를 베타용 브라우저만으로 내보내지 않았다. 베타 코어 라이브러리도 내보냈다. 오히려 마이크로소프트 네이티브 .Net 프레임웍 상에서 사용자 인터페이스를 구축했더라면, 윈도용 사파리는 버그나 오류가 잠재적으로 더 적었을 것이다. 애플은 구태여 코어 프레임웍까지 포팅시켜가지고 더 많은 버그와 보안 문제에 사파리를 노출시켰다. 어째서 브라우저만으로 내놓지 않았을까? 더구나 윈도용 사파리가 사용하는 이들 코어 라이브러리에서 몇 가지 오류가 발견되자마자, 애플 비방꾼들은 일제히 어둠에서 깨어나 재잘거리기 시작하였다. 스스로 애플의 WiFi 보안을 해킹했노라 알려졌지만, 어떻게 했는지 검증을 회피한 것으로 유명한 해커가 있다. 바로 데이비드 메이너(David Maynor)이다. 윈도용 사파리가 나오자, 그는 사파리 공격에 대한 문서화되어있지 않은 공격을 거행하여, 헤드라인에 그의 이름을 올렸다. 물론 며칠 후 애플은 패치를 제공하였다. 표준형 윈도 애플리케이션이었다면, 사파리는 48시간 동안의 언론 비판과 FUD를 피할 수 있었을 터이다. 그렇다면 애플은 왜 이런 쉬운 길을 택하지 않고, 어려운 길을 택했을까? Why Did Apple Port its Core OS X Libraries to Windows? 윈도용으로의 포팅을 할 때, .Net을 사용하면 분명 윈도에 어울리는 브라우저가 나왔을 것이다. 이 때문에 파이어폭스를 잡아먹기 위해 사파리를 내보냈다는 주장은 힘을 잃는다. 그저 윈도용 브라우저를 내놓기만 한 것이 아니기 때문이다. 애플은 다른 라이브러리의 포팅을 통해 두 가지 목표를 노리는 것으로 보인다. *First, Core Graphics와 Core Foundation의 윈도 포팅은 보다 맥다운 사용감을 준다. 윈도용 사파리를 써 보면 정말 맥에서 쓰는 것 같다. 윈도다운 사용감을 주려 했더라면, 많은 시간과 노력을 절약할 수 있었을 것이다. 아니, 차라리 외부에 용역을 줘도 됐을 일이다. 맥다운 느낌을 주는 사파리를 쓰다 보면, 윈도 사용자들도 애플의 사용자 인터페이스 컨벤션에 익숙해지게 된다. 게다가 투명 쉬트나 내장형 컬러관리같은 Core Graphic의 기능도 맛볼 수 있게 된다. Second, Core Graphics와 Core Foundation의 윈도 포팅은 후일, 엑스코드의 확장을 안겨다줄 수 있다. 맥 개발자들이 자신의 코코아 애플리케이션을 윈도용으로 내보낼 여지가 생기기 때문이다. 즉, 윈도용 옐로박스의 부활이다. 완전히 죽어 묻혀졌던 옐로박스가 다시금 현대화된 모습으로 나타난 것이다. [Yellow Box의 죽음, 그리고 Cocoa] [레드박스의 미신을 벗긴다] Thinking Outside the Yellow Box.* 원래의 윈도용 옐로박스는 OpenStep의 구현 중 하나였고, 어도비 디스플레이 포스트스크립트 지원을 포함하고 있었다. 그런데 애플이 랩소디에서 맥오에스텐으로 전략을 변경하자, OpenStep과 윈도용 옐로박스 런타임이 맥오에스텐과의 호환성을 잃게 된다. 핵심 기반이 변경됐기 때문이다. 애플은 또한 기존 클래식 맥 개발을 카본 라이브러리로 유지시켰다. 맥오에스텐 소프트웨어 대다수가 카본, 혹은 카본과 코코아 혼합으로 만들어지는 시절이었기 때문에, 애플이 윈도용 옐로박스를 유지시킬 방도가 없었다. 하지만 그런 상황이 변해가고 있다. 애플이 유니버설 바이너리를 개발하고, 맥 개발자들을 엑스코드로 이주시켰기 때문이다. 덕분에 예전 68k 코드의 PowerPC 에뮬레이션 등, 모든 클래식 소프트웨어는 자연스럽게 사라졌다. 단일 개발툴 하의 맥 플랫폼 통일은 포팅 가능성도 훨씬 쉽게 만들어 놓았다. [iPhone용 OS X과 WinCE, Palm, Symbian, 리눅스] [유니버설은, 인텔 이주가 아닌 인텔 포용이다] [왜 애플은 이제서야 인텔을 사용하게 되었나] Carbon and Cocoa: Which is Tastier? 애플은 또한 모든 미래 개발을 코코아로 이주해왔다. 카본은 앞으로도 한동안 존재할 테지만 메시지는 분명하다. 코코아가 미래다. 새로운 데스크톱용 애플리케이션은 물론, 아이폰용 내부 애플리케이션도 코코아를 사용한다. 카본과 코코아는 원래 맥오에스텐 내부에서 "라이벌 반쪽"의 개념이었다. 하나는 오래 전 맥 툴박스에 기반하는 존재였고, 다른 하나는 NeXTSTEP의 객체지향 프레임웍에 기반하는 존재였다. 하지만 10년에 걸친 맥오에스텐 개발기간동안, 카본과 코코아 모두가 사용하는 Core Foundation 프레임웍이 나타난다. 그렇다고 애플이 맥오에스텐의 "카본" 한 쪽을 저버리진 않을 것이다. 보다 상위 레벨 프레임웍을 합칠 뿐이다. 코코아는 더욱 더 매력적으로 변모할 것이다. Cuckoo for Windows Cocoa. 윈도용 사파리에 들어간 코코아 기본 프레임웍은 애플의 욕심이 비단 맥-다운 브라우저에 있지만은 않다는 점을 일깨워준다. 엑스코드 개발자들에게 자신의 애플리케이션을 윈도용으로도 만들어줄 세련된 메커니즘을 제공하리라는 예상도 가능하다. 물론 테스트와 다듬기가 필요하다. 바로 그 목적에 쓰일 수단이 윈도용 사파리이다. 모든 애플리케이션을 윈도로 포팅하지는 않을 것이다. 다만 써드파티 개발자들이 크로스-플랫폼 옵션으로 개발을 하게 된다는 의미다. 어쩌면 마이크로소프트 .Net보다 코코아가 훨씬 더 매력적으로 다가설 수도 있다. 맥 플랫폼, 어쩌면 아이폰에서도 지원을 받는 별도의 무료 기능이 가세하기 때문이다. [WWDC 2007: .Net과 Cocoa] Pros and Cons of a Ported Cocoa. 써드파티 개발자용 크로스-플랫폼 코코아 전략을 애플이 실제로 추진하건, 추진하지 않건, 애플은 이미 내부적으로 상당한 가능성을 보여주었다. 아이폰 안에 있는 ARM 맥에 있는 PowerPC와, 인텔의 32, 64-비트 버전 윈도용 사파리 이러한 포팅 가능성은 NeXTSTEP의 산물이다. 실제로 넥스트스텝은 여러 CPU 아키텍쳐용으로, 여러 운영체제 환경용으로 포팅이 되었다. 포팅 가능성이 애플 고유의 핵심 전략 중 하나이기에, 애플이 크로스-플랫폼 개발용으로 코코아를 추진해도 놀랄 일은 아니다. 별도의 비용도 거의 들지 않는다. 윈도용 코코아가 금방이라도 나온다는 말은 아니다. 넥스트도 OpenStep을 실패했었다. 애플의 랩소디도 마찬가지의 실패였다. 물론 현재의 애플 상황은 1997년의 애플, 몇 해 전의 넥스트와는 확연히 다르다. 다만 주목해야할 점이 있다. 마이크로소프트의 상황이 예전과 판이하게 다르다. 윈도용 주요 개발 플랫폼인 Win32가 늙어가고 있으며, 마이크로소프트가 현재 이를 .Net으로 교체하려 노력중이다. 따라서 예전 그 어느 때보다도 개발자들이 코코아같은 대안을 찾을 만한 상황이다. [BIOS PC를 뛰어넘은 애플 펌웨어] [iPhone은 어째서 Symbian을 선택하지 않았을까] Why Safari on Windows is the Next iTunes. 즉, 사파리가 개발자들에게 앞으로 상당한 반향을 일으킬 수 있다는 점은 알 수 있겠다. 그렇다면 소비자 전략에는 어떤 영향을 끼칠까? 다름 아닌 아이튠스의 패턴을 그대로 따르리라는 점을 들 수 있다. 마이크로소프트의 독점적인 윈도미디어 포맷에 대해, 표준-기반의 오디오를 뿌리기 위해 윈도용 아이튠스를 선보인 애플이다. 윈도에 포함된 것보다 더 나은 미디어 라이브러리를 제공함으로써, 애플은 모질라가 IE의 대안, 파이어폭스를 홍보하는 것과 마찬가지로, 아이튠스를 홍보하였다. 애플은 업계 표준 포맷 사용의 매력으로 아이튠스를 내세웠다. CD도 구울 수 있고, 포드캐스트도 다운로드받거나 출판할 수 있으며, 제일 덜 귀찮은 DRM으로 온라인으로 음악과 텔레비전 방송, 영화도 구입할 수 있다. 이와 반대로 마이크로소프트는 엄청난 돈을 투입하여, 윈도에 완전히 묶이는 폐쇄형 미디어 플랫폼을 조성하였다. 또한 다른 모든 미디어 기기와 상용 다운로드를 PlaysForSure라는 Janus DRM 하에 묶어 놓기도 하였다. 그러나 아이튠스는 윈도미디어와 PlaysForSure를 모두 물리쳤다. PC 운영체제에서 하던 짓을 미디어에서만은 못하게 막은 것이다. 마이크로소프트는 PlaysForSure 파트너를 모두 팽개치고, Zune으로 직접 경쟁하겠다는 발표를 하게 된다. 하지만 10억 달러를 들여놓고도 관심을 유지시키지도 못하는 상황을 맞이한 마이크로소프트이다. [Zune, 그리고 마이크로소프트의 낚시질] [두 얼굴의 괴물, Zune] [최종병기 퀵타임] Who Wants Safari on Windows? 소비자와 콘텐트 제작자들은 아이튠스가 터 놓은 미디어의 공개표준 사용을 보다 더 좋아했다. 사파리도 그와 마찬가지 방식으로 표준-기반의 웹 개발을 윈도-전용, 혹은 IE-전용 웹 개발보다 더 매력적이게 만들 수 있다. 애플은 또한 이 목표를 위해, 웹 개발자들을 돕는 웹개발 검사툴도 개발해 놓았다. Drosera: JavaScript 디버거 Web Inspector: 페이지 각 요소의 속성을 점검하는 라이브 뷰어 [업데이트: 애플은 WWDC에서 새롭고 개선된 Web Inspector를 선보였다. 그래서 스크린샷을 포함시킬 수 있게 되었다.] [Introducing Drosera - Surfin’ Safari] [Introducing the Web Inspector - Surfin’ Safari] [Yet another one more thing... a new Web Inspector! - Surfin’ Safari] Similarities and Differences of Safari and Firefox. 분명 사파리와 파이어폭스 간에 겹치는 부분이 있다. 파이어폭스 주장처럼, 실제로 사파리가 파이어폭스의 시장점유율을 어느 정도 잡아 먹을지도 모른다. 그러나 사파리와 파이어폭스 모두, 서로 경쟁하기보다는 상부상조할 가능성이 더 크다. 둘 모두 서로 다른 종류의 사용자들에게 각각 매력적이기 때문이다. 가령, 파이어폭스는 리눅스용 표준 브라우저로 존재하며, 사파리가 제공하지 않는 기능을 윈도용으로 제공한다. 파이어폭스의 여러가지 플러그인 기능에 대한 애플의 대응 기능은 없다. 사파리 또한 북마크 라이브러리나 RSS 뷰어, 더 가볍고 빠른 렌더링 엔진, 색상 매치 그래픽지원 등, 파이어폭스에 없는 기능을 몇 가지 제공한다. 또한 윈도 PC에서 일을 해야 하는 맥 사용자들에게도 좋은 선택이 사파리다. 파이어폭스와 사파리 모두 맥 플랫폼상에서 공존하고 있으며, 맥 사용자들은 둘 모두를 사용할 만한 이유가 충분히 있다. 윈도용 사파리가 나왔다고 해서 변치 않는 상황이 존재하기 때문이다. 하나의 브라우저만 사용하기 좋아할 수도 있겠지만, 웹브라우저를 하나만 써야한다는 규칙은 없다. 사파리는 또한 아이포드와 아이폰, 에어포트 익스트림 사용자의 설치 CD에 들어갈 것이 분명하다. 퀵타임이나 아이튠스 다운로드를 받으면서 끼어들어갈 수도 있다. 파이어폭스의 손길이 미처 닿지 못하는 사람들에게 사파리가 간다는 의미다. [파이어폭스와 사파리, 웹브라우저의 르네상스] [넷스케이프와 인터넷 익스플로러] [애플과 웹브라우저] The Other Obvious Reason for Safari on Windows: iPhone. 물론 윈도용 사파리가 나온 제일 확실한 이유는 다름 아닌 아이폰이다. 아이폰도 사파리 렌더링 엔진을 사용한다. 윈도용 버전을 출하하면서 애플은 사파리 브라우저의 범위를 넓힐 것이다. 사파리, 그리고 아이폰에서도 잘 보여야 하도록 웹을 만들어야 할 상황이 올 수 있어서이다. 아이폰을 겨냥한 개발자들로서도, 사파리를 사용해 PC에서 테스트를 벌일 수 있다. 당연하다. 그리고 애플은 사파리를 예전 넷스케이프나 인터넷 익스플로러의 범주에 넣으려하지 않을 것이다. 넷스케이프와 인터넷 익스플로러는 개발자들을 자사 익스텐션에 묶어 놓았다. "best when viewed from Safari" 같은 웹사이트도 없을 것이다. 그 대신 애플은 정 반대의 행동을 하고 있다. 제일 표준을 지키는 브라우저로서, 인터넷 공동체가 사파리를 승인하고 채택하도록 독려하는 행동이다. 새로이 HTML 5 표준을 제정하는 그룹 회원사로서 애플은 웹을 개방형으로 만들기 위해 작업중이다. 그 의미는 무엇일까? 다음 기사 제목이다. The Future of the Web: Safari, Firefox and Internet Explorer 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? Cuckoo for Cocoa: Is Safari on Windows the next iTunes? __________________