Mac OS X 10.6 Snow Leopard: the Ars Technica review

casaubon · 2009/09/03, 06:12 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

Mac OS X 10.4 Tiger: 150+ new features

2004년 6월, WWDC 기조연설에서 스티브 잡스는 개발자들과 일반인들에게 처음으로 맥오에스텐 10.4 타이거를 선보였다. 타이거 완제품이 2005년 4월에 나왔을 때, 타이거는 맥오에스텐 역사상 가장 기능이 많고 대단히 중요한 운영체제였다. 애플 마케팅 캠페인은 타이거를 두고 "150가지가 넘는 신기능"을 강조하였다.

그 모든 기능들은 시간이 걸리는 기능들이었다. 2001년 나온 이래, 맥오에스텐은 매년 적어도 한 번의 메이저급 업데이트를 치러왔다. 하지만 타이거의 경우는 나오는데 1년 반이 걸렸다. 당시 관점에서, 이 정도는 충분히 기다릴만 했다. 타이거는 사용자와 개발자들 모두에게 히트작이었으며, 애플은 다음 메이저 업데이트인 레퍼드를 어떻게 내놓을지에 대한 교훈을 마음속 깊이, 그리고 빠르게 터득하였다. 여러 소식통을 통해, 애플은 맥오에스텐의 업데이트 주기를 기존 12개월에서 18개월로 늘리겠다 밝혔으며, 공식적으로 레퍼드는 "2007년 봄"에 출시예정이었다.

그리고 그 날짜가 다가오자 애플 마케팅은 예상가능한 수순을 밝아나갔다.

Steve Jobs at WWDC 2007, touting 300 new features in Mac OS X 10.5 Leopard

심지어 애플은 웹사이트에 300가지가 넘는 신기능을 모두 표시하기도 하였다. 그런데 "봄"이라는 시기가 좀 낙관적인 일정이었다. 실제 레퍼드의 출시는 2007년 10월이었다. 타이거가 나온지 거의 2년 반이 흐른 뒤였다. 그렇다면 레퍼드는 타이거보다 정말 두 배의 신기능을 가졌을까? 논쟁이 될만한 주제다. 하지만 레퍼드는 멋진 기능과 기술을 견고하게 포함시켜 놓았고, 현재 우리들 다수는 그 기능을 당연스레 여기고 있다. 그 점만은 확실하다. (가령 레퍼드가 나온 이후로, 타임머신을 말하지 않는 맥 사용자를 본 적이 있으신가? 필자는 분명 없다.)

맥오에스텐도 이제 성숙해가고 있었다. 방향은 분명했다. 업데이트 주기가 더 길어지고, 기능이 더 많아지는 방향이다. 그렇다면 맥오에스텐 10.6은 어떨까? 레퍼드가 나온지 3년 반은 지나야 나오잖을까? 신기능이 500가지는 들어갈까? 아니, 천 가지일까?

WWDC 2008에서, 세를레(Bertrand Serlet)는 PC 업계 역사상 대단히 "전례 없는" 발표를 거행한다.

Mac OS X 10.6 - Read Bertrand's lips: No New Features!

그렇다. 맥오에스텐 다음 메이저 업데이트에 신기능이 없다는 발표다. 이름 자체가 그것을 반영한다. 맥오에스텐 10.6은 "스노레퍼드"이다. 레퍼드의 일종이라는 의미다. 다만 더 낫고 더 빠르며 더 깔끔해졌다. 에... 더 하얘지기도 했다.

애플로서는 위험도가 있는 전략이었다. 10.1과 10.2, 10.3이라는 초고속 업데이트를 통해 애플은 신기능과 API를 집어 넣었고, 10.4와 10.5가 지나자 이제 "휴식"을 부르는 것일까? WWDC에 모인 맥 개발자들 앞에서 생방송으로, 그런 말을 하는 것이 세를레 입장에서 꽤 고역이었을 것이다. 반응은 어땠을까? 박수갈채였다. 심지어 환호성이 있기도 했다.

타이거의 "150가지가 넘는 신기능", 레퍼드의 "300가지가 넘는 신기능"에 박수쳤던 개발자들하고 같은 개발자들인가? 이들이 이제는 스노레퍼드의 "신기능 없음"에 또 박수를 친다고? 도대체 어떻게 설명을 할까?

사실 이 "신기능 없음"의 슬라이드가 나올 때는, 이미 한 시간에 걸린 프리젠테이션의 끝자락이었다. 그 한 시간은 스노레퍼드의 새 API와 기술에 대한 설명이었다. 이 슬라이드가 나온 뒤, 갑자기 백페달을 밟았다. 이윽고 "well, there is one new feature..."라는 슬라이드가 나오고, 마이크로소프트 익스체인지 지원이 나왔다. "신기능 없음"만 보면 정체를 의미할지 모르겠지만, 사실 그 맥락을 보면 개발자-친화적이라는 의미를 확인시켜 주었다고 볼 수 있다.

애플이 개발자들에게 전하는 메시지는 다음과 같다. 기존 코드를 더 빠르게 돌려주고, 애플리케이션을 더 잘 작성할 수 있게 도울 수 있도록, 맥오에스텐에 새로운 것을 대단히 많이 갖다붙였다. 그리고 이 새로운 점들이 될 수 있는 한 버그가 없고, 견고해지게 만들려 한다. 다만 소비자들이 알만한, 마케팅-친화적인 신기능까지 덧붙이지는 않겠다. 그 대신 여러분, 개발자들에게 영향을 끼치는 것에만 100% 집중하겠다.

자, 스노레퍼드는 개발자들에 대한 연애편지인 셈이다. 그렇다면 사용자들에게는 "친애하는..."으로 시작하는 편지일까? 마케팅 쪽 사람들이야 사용자들을 "고객"으로 언급하는데 전문가들이시다. 아시잖는가? 도대체 그 단어에 무엇이 있을까? 사실 그 속을 들여다보면, 사용자에게 광고하는 것도 개발자들과 꽤 비슷하다. 새로운 API를 계속 선보이는 것이나, 맥오에스텐의 '소비자용' 기능을 선보이는 것이나 매한가지이다. 엑스포제와 새 파인더, 스폿라이트, 새로운 독, 타임머신, 그리고 다시금 새 파인더, 매년 새로 나오는 iLife와 iWork 등이다. 애플 API에 있는 버그를 개발자들은 싫어한다. 충돌을 일으키는 애플리케이션 역시, 사용자들은 싫어한다.

스노레퍼드로 들어가 보자. 신기능/새 버그로부터 자유로운 버전이다. 주안점이 그것이다.

Uncomfortable realities

하지만 잠깐만. 혹시 필자가 "이미 한 시간에 걸린 프리젠테이션의 끝자락이었다. 그 한 시간은 스노레퍼드의 새 API와 기술에 대한 설명이었다."라는 말을 하지 않았던가? 신기능이 없다는 애플의 메시지는, 개발자 입장에서 "새로운 버그가 없음을 의미한다. 스노레퍼드는 새 버그를 소개하지 않은 채, 옛 버그를 소탕하는 OS로 나왔다. 메이저급 새 API처럼 "새 버그가 곧 나온다"고 말하지 않았다. 어느 쪽일까?

사용자들로서도 비슷하다. "신기능 없음"은 안정성과 신뢰성을 내포한다. 그런데 스노레퍼드를 WWDC에서 소개하기 위해, 핵심 OS 변화점들 말하는 데에만 한 시간이 걸렸다. 실제 출시 1년도 더 전에 말이다. 애플이 이 약속을 정말 잘 지켰을까? 아니면 타이거나 레퍼드에 나오는 신기능이라는 버그, 처음 버전은 쓰지 말라는 교훈으로부터 이제 벗어날 수 있을까? 신기능 없이도?

그렇다. 애플의 진짜 의도에 대해 이정도 했으면 충분히 회의론자 역할을 한 셈이다. 아래 그림에 나와 있는 맥오에스텐 출시일정 도표를 한 번 보기 바란다. 각 출시 버전마다 제일 중요한 기능들을 덧붙여 보았다.

Mac OS X release timeline

곡선이 상당히 축 늘어진 모양새다. 신기능이 마치 끝없이 늘어날 모양으로 말이다. 하지만 Y축 간격은 버전별로 일정하다. 즉, 각 버전 출시 때마다 전 버전보다 더 많은 것들이 들어갔음을 알 수 있겠다. 10.6도 위로 향해있긴 하다. 하지만 아셔야 한다. "신기능 없음"을 말이다. 버전 10.1 또한 비슷한 성격을 가졌지만, 출시에 훨씬 시간이 덜 걸렸다.

이 그래프를 보면, 맥오에스텐 개발 자원을 빨아들이는 것이 뭔가 있잖을까라는 생각을 안할 수 없게 된다. 아마 첫 번째나 두 번째 출시 때는 아직 잠들어있는 상태였을 것이다. 당연히 필자는 아이폰 얘기를 하고 있다. 특히 아이폰 OS이다. 아이폰 사업은 애플의 실적보고서를 뒤바꿀 정도의 파괴력을 가졌다. 심지어 아이포드도 그렇게까지는 못했는데 말이다. 아이폰은 또한 놀라운 속도로 개발자들을 끌어모았다.

맥오에스텐 10.4와 10.5에서 사용자 눈에 보이는 기능에 익숙해진 아티스트와 개발자들은 많다. 이들이 아이폰 OS에 몰린 것도 무리가 아니다. (일시적이건 그렇지 않건 말이다.) 하지만 한편, 맥오에스텐과 아이폰 OS의 핵심 운영체제는 같다. GUI 개발 언어도 같고, API도 다수가 같다. 어느 정도의 이주는 어쩔 수 없는 노릇이다.

"맥오에스텐" 기술이 사실은 아이폰 기술이었다는 점, 아이폰이 계속 비밀이었기에 Core Animation이나 코드인증(code signing)같은 기술들이 맥으로 먼저 나왔다는 점을 잊지 말아야 한다. WWDC와 맥오에스텐이나 맥때문에 상처받은 이들이 만드는 음모론이 아니다. 아이폰이 등장했기 때문이다. 다른 모든 것과 마찬가지로, 스노레퍼드 또한 맥오에스텐을 빛내주는 것으로 채워져 있다.

이제 아시겠는가? 거의 2년에 걸친 개발시간이 걸렸되, 신기능이 없다. 개발자들을 위해 대규모의 새로운 프레임웍이 생겨났지만, 새로운 버그는 거의 없다. 핵심 OS에 상당한 변화가 이루어졌으며, 신뢰성이 강화됐다. 사용자 눈에 보이는 변화는 거의 없다.

이정도만 하더라도 사실, 레퍼드 위에 눈이 내리기에는 충분하다.

http://arstechnica.com/apple/reviews...os-x-10-6.ars/

casaubon · 2009/09/03, 06:14 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

The price of entry

일단 소비자들이 스노레퍼드에서 제일 먼저 주목하는 것은 가격이다. 레퍼드로부터의 업그레이드 가격이 29달러에 불과하기 때문이다. 맥오에스텐 10.0과 지난 네 번의 메이저 업데이트 가격은 모두 129달러였다. 그리고 업그레이드를 위한 특별한 가격은 없었다. 이 원칙이 거의 8년간 지켜졌다. 하지만 29달러라면, 레퍼드 사용자들이라면 당장 가서 스노레퍼드를 집어올만한 가격이다. 스노레퍼드 업그레이드 가격은 정말, 바로 구입할 이들이 많을 정도의 가격이다. 이십 구 달러에 애플이 OS를 버전업할 때마다 뭔가 좋아지리라는 약간의 믿음, 그러면 붐! 바로 구입이다.

아직도 여기 계시는가? 좋다. 스노레퍼드에 대해 뭔가 더 알아야할 부분이 있는 모양이시다. 스노레퍼드는 유혹이라기보다는 격려 차원의 OS이다. 스노레퍼드는 인텔 맥에서만 돌아간다. PowerPC 팬들에게는 미안한 일이지만, 이번이 끝이다. 인텔로의 이주 발표가 4년 전이었다. 제일 마지막에 나온 PowerPC 맥은 2005년 10월이었다. 이제는 바꿀 때가 되었다.

그러나 PowerPC로부터 완전한 인텔 이주가 스토레퍼드라면, "신기능 없음"은 좀 이상한 자세라 볼 수 있다. PowerPC-기반 맥에서 레퍼드를 돌린다면, 스노레퍼드라 한들, 천 불이 넘는 새 맥을 구입하게 될 요인이 거의 없다는 얘기 아닌가? 따라서 PowerPC 맥 보유자가 새 맥을 구입할 조건은 대부분 바뀌지 않을 것이다. 예전 맥이 너무나 느려졌을 경우에나 나가서 한 대 살 것이며, 그 때는 이미 스노레퍼드가 미리 설치되어 있을 터이다.

스노레퍼드가 PowerPC 소유자들의 새 맥 구입을 결국 이끌어낸다면, 그것은 스노레퍼드에 감화됐다기보다는 단순한 교체가 될 것이다. 인텔 전용 스노레퍼드는 맥 플랫폼 상에서 PowerPC 지원을 그만뒀다는 의외의 면이 제일 중요하다 볼 수 있다.

흥미로운 그룹이 또 하나 있다. 맥오에스텐 10.4 타이거를 돌리는 인텔 맥 소유자들이다. 애플이 타이거를 탑재한 맥을 출하한 기간은 1년 9개월이 약간 넘는다. 즉, 레퍼드로 결코 업그레이드하지 않은 이들 머신 소유자들은 29달러 짜리에도 적합하지 않다. 그렇다고 해서 129달러 가격표의 스노레퍼드를 구입할 이들도 아니다. 여기에서 애플의 스노레퍼드 가격정책의 면모를 알 수 있다.

맥오에스텐 10.6 스노레퍼드는 2009년 9월, 기존 맥오에스텐 10.5 레퍼드에서 업그레이드할 수 있게 나온다.[...] 스노레퍼드 단일 사용자 라이센스의 소매가는 29달러이며, 5명-라이센스의 가족용인 패밀리팩은 49달러가 될 것이다. 인텔-기반 맥을 갖고 있는 타이거 사용자들은 맥오에스텐 스노레퍼드와 iLife 09, iWork 09가 들어있는 맥박스 셋을 169달러에 살 수 있으며, 이 경우 패밀리팩은 229달러이다.

일단 패밀리팩은 잠시 잊자. 위 말을 보면 새 맥을 살 경우 스노레퍼드는 무료이고, 레퍼드를 갖고 있으면 29달러이다. 반면 타이거가 깔려 있는 인텔맥이라면 169달러이다. 타이거에서 업그레이드할 사용자들은 iLife와 iWork을 원하건, 원하지 않건 같이 구매해야 한다. 스노레퍼드가 129달러였다면 분명 이들이 그 대상이었을 것이다. 하지만 어째서 정확히 29달러가 되었는지에 대해서는 알 수가 없다.

(맥 사용자가 아닌 이들을 위해 알려드리자면, 맥오에스텐은 서버 버전이 아닌 이상, 사용자당 시리얼 번호가 없고, 어떤 종류의 액티베이션도 없다. 이제까지도 그런 적이 없었다. 맥오에스텐 설치 과정 중에 "등록"이 있기는 하지만, 이것은 옵션일 뿐이고, 몇 명이 쓰고 있느냐의 정보밖에 안된다. 등록하지 않는다로 하여 컴퓨터를 운용하는데에는 전혀 불이익이 없다. 이점이야말로 맥오에스텐의 진짜 장점이라고 보는데, 애플 입장에서 본다면 레퍼드의 "합법" 사용자가 몇 명인지 전혀 알 수 없게된다는 효과도 있겠다.)

일단 스노레퍼드 업그레이드 DVD 가격 29달러는 레퍼드가 이미 있어야 설치되기 때문이라는 가능성이 있겠다. 예전에도 이런 종류의 업그레이드를 실시한 적은 있다. 그 때도 구매확인같은 절차는 없었다. 하지만 이 경우 문제가 없지 않다. 하드드라이브에 오류가 있다거나, 깨끗한 설치를 원할 경우, 29달러 짜리 스노레퍼드 업그레이드는, 레퍼드를 일단 설치한 다음에 업그레이드하는 식을 강요하게 되기 때문이다. 설치 시간이 두 배로 걸린다는 의미다. 대단히 성가신 일이다.

이 쪽 분야의 애플 이력을 아신다면, 애플이 너무나 간단한 29달러 짜리 "업그레이드" DVD를 선택한 사실이 그리 놀랍지 않을 것이다. 사실 레퍼드가 있건 없건, 이 "업그레이드" DVD는 스노레퍼드를 설치할 수 있다. 심지어 하드드라이브가 완전히 비어있더라도 설치가 가능하다.

확실하게 말하자면, 29달러 짜리 스노레퍼드 업그레이드를 레퍼드가 적절하게 깔려있지 않은 시스템 상에 설치하는 경우, 이 경우는 제품 라이센스 동의서 위반이다. 하지만 애플의 자세는, 모두를 범죄인으로 취급하여 벌주기보다는, 정직한 이들을 믿고 보상해주는 정책이다. 이러한 "정직 시스템" 업그레이드때문에 맥박스 셋의 169달러가 나왔을 것이다. 원래의 iLife와 iWork 가격에 11달러만 덧붙이면 스노레퍼드가 딸려오니, 이 박스셋은 정직한 이들을 위한 셋트이다.

맞다. 설치를 얘기하고 있는 중이다. 이 이야기를 끝내 보자.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/2

casaubon · 2009/09/03, 06:15 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

Installation

애플은 스노레퍼드의 설치과정이 "45%까지 더 빠르다"고 주장한다. 하지만 설치시간은 속도와 내용, 디스크의 상태, 광드라이브의 속도 등에 의존하기 때문에 제각기 다르게 마련이다. 게다가 설치는 한 번 뿐이다. 뭔가 정말 심각한 문제가 생기지 않는 이상, 흥미로운 과정이랄 수가 없다. 아무튼 애플이 그런 주장을 했으니, 정말 그러한지 알아볼 가치는 있겠다.

변수를 될 수 있는 한 줄이기 위해, 필자는 하나의 디스크에서 다른 비어있는 디스크로 레퍼드와 스노레퍼드를 각기 설치하였다. 광디스크로부터의 랜덤 접근을 줄이는데 집중하는 것이, 스노레퍼드 설치 최적화에서 제일 중요한 점이다. 따라서 필자의 실험은 이 제일 중요한 최적화를 무시하는 꼴이다.

하지만 이런 불이익에도 불구하고, 스노레퍼드의 설치는 레퍼드 설치보다 약 20% 시간이 덜들어갔다. 물론 45%까지는 아니다. 애플은 45%"까지" 줄인다고 하였다. 사실 두 버전 모두 설치에 30분이 안걸렸다.

놀라운 점은 따로 있었다. 스노레퍼드의 스폿라이트 인덱싱하는 시간이다. 필자 테스팅에서 스노레퍼드의 첫 인덱싱은 174%가 더 빨랐다. 다시 말하건데 시간 자체는 별 차이 없다. (5분 49초 대 3분 20초) 하지만 비어있는 디스크에 새로 설치한다고 딱히 더 유리하지는 않다는 점이 드러났다. 사용자들 대부분은 스노레퍼드의 첫 대면을 이 스폿라이트 인덱싱으로 맞이하게 된다. 그렇기 때문에 이 시간이 더 짧아졌다 함은 상당히 지적할만하다.

설치에 있어서 또 한 가지 지적할만한 사항이 있다. PowerPC 바이너리를 인텔맥에서 돌리도록 해주는 로제타(Rosetta)가 기본설치가 아니라는 점이다. 물론 우리는 애플을 이해한다. PowerPC는 이제 죽었다. 평화롭게 잠들기 바란다. 이제 무대에서 사라질 때가 되었다. 애플 입장에서, PowerPC는 이제 죽었다.

하지만 로제타가 기본 설치가 아니라 함은? 좀 가혹하게 비쳐진다. 스노레퍼드로 업그레이드할 사용자들이 혹이 PowerPC용 애플리케이션이 있다는 점을 잊고 있었다면? 놀랍게도, 아래와 같은 일이 일어난다.

Rosetta: auto-installed for your convenience
스노레퍼드에서 Disk Inventory X를 실행시키려 했을 때 본 화면이다. PowerPC 전용이라는 사실을 오랜동안 잊고 있었다. 맞다. "설치" 버튼을 눌렀다. 필자는 설치 DVD를 넣으라는 명령이 떠오르리라 기대하였다. 하지만 스노레퍼드는 애플서버로부터 로제타를 불러들어와서 설치하였다.

재부팅도 필요 없었고, 로제타 설치가 끝나자 Disk Inventory X도 잘 돌아갔다. 맥오에스텐은 그동안 주문형 설치로 소프트웨어 컴퍼넌트를 설치하지 않았다. 하지만 로제타 설치의 편리함은 상당히 좋아 보인다. "설치"를 클릭하면, 맥오에스텐 패키지를 담고 있는 XML 프로퍼티 리스트가 다운로드되었는데, 스노레퍼드는 프린터 드라이버 또한 이렇게 주문식으로 다운로드/설치를 하였다. 설치 DVD를 구태여 찾을 필요가 없었다. 미래에는 이런 형식의 기술이 더 보편화되기를 희망해본다.

Installation footprint

로제타는 제쳐두고, 스노레퍼드는 디스크 공간도 덜 사용한다. 애플은 이전 버전보다 절반 이상 줄어들리라 주장하는데, 거짓말은 아니다. 깨끗한 기본설치(스폿라이트 인덱스도 포함한다)를 하면 레퍼드는 16.8GB이고, 스노레퍼드는 5.9GB이다. (우연히도, 이들 수치는 2의 거듭제곱 식으으로 나온 수치이다. 아래를 참조.)

A gigabyte by any other name

스노레퍼드는 디스크 사용량에 있어서도 트릭을 한 가지 구사하고 있다. 스노레퍼드의 파인더는 1GB를 109 (1,000,000,000)바이트로 인식한다. 반면 레퍼드의 파인더는 (지적해야겠다. 레퍼드 이하 모든 이전-오에스텐의 파인더) 1GB를 230 (1,073,741,824)바이트로 본다. 따라서 스노레퍼드를 설치할 경우 하드디스크 용량이 갑자기 커져보이게 된다. 가령 필자의 "1TB" 짜리 하드드라이브는 레퍼드에서 931.19 GB였지만, 스노레퍼드에서는 999.86 GB이다. 추측하셨을 듯 한데, 하드디스크 제조업체들은 10의 거듭제곱(power of ten)을 사용한다. 상당히 혼란스러운 일이다. 필자는 2의 거듭제곱(power of two)식 표현 편이다. 그렇다고 해서 애플만 뭐라 할 수는 없다. 하드디스크 용량 측정이 너무나 오랜동안의 관행으로 되었기 때문이다.

스노레퍼드의 무게감량에 비밀이 몇 가지 더 있다. 첫 번째는 분명하다. PowerPC 지원이 없어서다. 즉, 관련 코드가 없다. 레퍼드의 실행가능 바이너리는 최대 네 가지이다.(32-bit PowerPC, 64-bit PowerPC, x86, x86_64) 이제 스노레퍼드에서는 절반이 사라졌다. 물론 레퍼드에서 64-비트 코드를 가진 애플리케이션은 거의 없었지만, 그래도 50%의 실행 바이너리가 줄긴 준 것이다.

운영체제의 파일 전부가 실행 바이너리는 아니다. 당연하다. 데이터 파일과 이미지, 오디오 파일, 심지어 비디오도 있다. 하지만 비-실행 파일의 대다수의 공통점이 하나 있다. 압축 파일포맷으로 저장된다는 점이다. 이미지는 PNG나 JPEG, 오디오는 AAC, 비디오는 MPEG-4, 심지어 프리퍼런스 파일 리스트도 XML이 아닌, 컴팩트한 바이너리 포맷이 기본으로 되어 있다.

스노레퍼드에서 이런 압축이 된 것이 비단 실행/데이터 파일들만은 아니다. 사례를 하나 들자면, 스노레퍼드의 실행파일 중 97%는 압축되어있다. 그런데 그 압축을 어떻게 했을까? 보시라.

% cd Applications/Mail.app/Contents/MacOS

% ls -l Mail

-rwxr-xr-x@ 1 root  wheel  0 Jun 18 19:35 Mail

여러분. 매우, 작잖은가? 이것은 실행 파일일까, 다른 무엇일까? 우리의 가정을 확인해보자.

% file Applications/Mail.app/Contents/MacOS/Mail

Applications/Mail.app/Contents/MacOS/Mail: empty

도대체 무슨 일일까? 말 안해준 사실이 하나 있다. 위에 나온 명령이 스노레퍼드 디스크를 찾는 레퍼드 시스템에서 실행되었다는 사실이다. 사실 압축된 모든 스노레퍼드 파일의 크기는, 맥오에스텐 이전 버전에서 볼 때 모두 제로 바이트로 보인다. (스노레퍼드로 부팅하면 당연히 완벽하게, 평범하게 돌아간다.)

그러면 데이터는 어디에 있나? ls 아웃풋 안의 퍼미션 스트링 끝에 있는 자그마한 "@"가 그 실마리를 제공해준다. Mail의 파일 크기가 비록 제로이지만, Mail 실행파일은 확장된 속성(attributes)을 갖는다.

% xattr -l Applications/Mail.app/Contents/MacOS/Mail

com.apple.ResourceFork:

0000     00 00 01 00 00 2C F5 F2 00 2C F4 F2 00 00 00 32    .....,...,.....2

0010     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

(184,159 lines snipped)

2CF610   63 6D 70 66 00 00 00 0A 00 01 FF FF 00 00 00 00    cmpf............

2CF620   00 00 00 00                                        ....



com.apple.decmpfs:

0000   66 70 6D 63 04 00 00 00 A0 82 72 00 00 00 00 00    fpmc......r.....

아. 모두 데이터로군. 하지만 기다리시라. 리소스 포크 안에 있다? 8년 전에 죽은 것 아니었나? 실제로 죽긴 죽었다. 여기서 보이는 것은 애플이 사랑하는 파일 시스템인 HFS+에 뭔가 추가가 됐다는 사실이다.

맥오에스텐의 여명기, 애플은 저널링과 심볼릭 링크, 하드링크를 추가시켰다. 타이거에서는 확장속성(extended attributes)과 access control 리스트도 추가됐다. 레퍼드에서 HFS+는 디렉토리로 연결되는 하드링크를 지원하였고, 스노레퍼드의 HFS+는 또다른 새 트릭을 추가시켰다. per-file 압축이다.

per-file 압축은 com.apple.decmpfs을 보면 이 파일이 압축되었다는 힌트를 알 수 있다. 스노레퍼드로 부팅했을 때, xattr 커맨드에서는 원래 숨겨져 있지만, 레퍼드 시스템에서 볼 경우에는 확실히 보인다. 그 중요도에 대한 지식을 레퍼드는 모르기 때문이다.

맥오에스텐 내부의 책임자, 싱(Amit Singh)의 hfsdebug 프로그램의 도움을 받으면 더 많은 정보가 나온다. 이 또한 스노레퍼드에서 업데이트가 되었다. 조용히 말이다.

% hfsdebug /Applications/Mail.app/Contents/MacOS/Mail

...

  compression magic    = cmpf

  compression type     = 4 (resource fork has compressed data)

  uncompressed size    = 7500336 bytes

보다시피 리소스 포크는 정말 압축된 데이터를 담고 있다. 그렇다면 어째서 리소스 포크일까? 원래 애플이 그러하다. 영리하게 하위호환성을 구사하는 것이다. 디렉토리에 연결되어 (레퍼드 이전 시스템에서 볼 때) 가상본처럼 보이는 하드링크가 그 사례이다.

HFS+ 압축의 경우, 애플은 스노레퍼드 이전 시스템에서 압축 데이터를 읽거나 해석할 수가 없었다. (물론 이해할 수 있다.) 당시 운영체제를 작성할 때는 존재하지 않는 방식으로 저장되었기 때문이다. 하지만 10.6 시스템 이전에서 애플리케이션(그리고 사용자들)이 수정을 통해 파일을 코럽트시키거나, 예기치 않게 파일 콘텐츠가 압축되었을 때, 애플은 압축된 데이터를 숨기는 편을 택하였다.

그렇다면 스노레퍼드 이전 시스템에서 숨겨진 파일을 볼 때, 특히 그 파일이 거대한 경우에는 데이터 손실 없이 복사가 가능할까? 리소스포크에서는 당연히 가능하다. 파인더는 움직이거나 복사할 때 언제나 맥-전용 메타데이터,즉 리소스와 데이터 포크를 올바르게 보존한다. 레퍼드에서는 cp와 rsync 커맨드마저도 똑같이 작동한다. 그렇다면 스노레퍼드의 디스크를, 스노레퍼드 이전 OS에서 볼 때 "비어있는" 0KB의 파일이 나타나는 것이 좀 안좋겠지만, 이동이나 복사시 데이터 손실의 위험도는 적다.

리소스 포크는 애플이 압축된 데이터를 집어넣는 장소일뿐이 아니다. 더 작은 파일의 경우, hfsdebug는 다음을 보여준다.

% hfsdebug /etc/asl.conf

...

  compression magic    = cmpf

  compression type     = 3 (xattr has compressed data)

  uncompressed size    = 860 bytes

압축된 형태이기는 하되, 모두 확장속성 안에 저장될정도로 데이터가 작은 경우이다. 다음을 보자.

% hfsdebug /Volumes/Snow Time/Applications/Mail.app/Contents/PkgInfo

...

  compression magic    = cmpf

  compression type     = 3 (xattr has inline data)

  uncompressed size    = 8 bytes

그렇다. 파일 콘텐츠 전체가 확장속성 안에 비압축 저장되어 있다. 이와 같은 표준 PkgInfo 파일의 콘텐츠는 클래식-맥오에스 타입의 4-바이트이다.

% xattr -l Applications/Mail.app/Contents/PkgInfo 

com.apple.decmpfs:

0000   66 70 6D 63 03 00 00 00 08 00 00 00 00 00 00 00    fpmc............

0010   FF 41 50 50 4C 65 6D 61 6C                         .APPLemal

com.apple.decmpfs 속성의 앞서 사례를 모두 보면, 동일한 "fpmc..." 프리앰블(preamble)이 보인다. 하지만 값 끝에 보면, 데이터는 다음과 같이 나온다. 타입코드는 "APPL" (애플리케이션), 그리고 생성자 코드 "emal"이다.

이것이 과연 데이터 압축만을 위하는 것일지 궁금하실 것이다. 확장속성 안에 비압축 8바이트와 17-바이트 프리앰블이 디스크 공간 절약에 얼마나 도움이 될까? 답변은 HFS+가 디스크 공간을 어떻게 배분하느냐에 달려 있다. 데이터나 리소스 포크에 정보를 저장할 때, HFS+는 파일 시스템의 블럭 사이즈(기본 4KB) 여러 개에 공간을 할당한다. 따라서 8바이트는 전통적 방식으로 저장했을 때, 최소한 4,096 바이트를 점유하게 된다. 그러나 확장속성으로 디스크 공간을 배분할 경우, 배분 블럭 크기는 문제가 안된다. 데이터를 보다 더 타이트하게 패키지하기 때문이다. 25바이트 짜리 데이터를 확장속성에 저장하는 경우 절약할 수 있는 공간은, 4,000바이트가 넘는다.

그러나 디스크 공간 절약의 이유가 압축만이 아니다. CPU 주기가 늘면, I/O 지연현상이 준다는 전통적인 사례를 다시 들어도 좋다. 지난 수 십년간 CPU 성능은 디스크 성능보다 훨씬 더 빨라졌다. 현대적인 하드디스크의 디스크 접근시간(seek times)과 회전지연(rotational delays)은 여전히 밀리세컨드로 잰다. 2 GHz CPU에서 1 밀리세컨드는 2백만 사이클에 해당된다. 물론 실질적인 데이터 전송시간은 따로 존재한다.

당연히 OS와 하드웨어를 통한 캐시는 이런 지연현상을 상당히 가려준다. 하지만 이 캐시를 채우기 위해서는 어느 순간, 비트가 디스크에서 나와야 한다. 이 때, 압축이 동원되어서, 더 적은 수의 비트를 전송하게 된다. 현대적인 멀티-코어 맥에 들어간 CPU 리소스는 웃길 정도로 포화상태이다. 따라서 디스크에서 압축된 콘텐츠를 전송하여, CPU가 압축을 푼 다음, 메모리로 집어넣는 시간은 보통 비압축 형태의 데이터 전송보다 시간이 훨씬 덜 걸린다.

말하자면, 데이터 전송 시간이 덜걸리니, 잠재적으로 성능 개선이 이루어진다는 의미이다. 그렇지만 파일 콘텐츠 저장을 위해 사용하는 확장속성은 잠재적이 아니라 실제로 속도를 더 빠르게 해주기도 한다. 이 모두가 데이터 지역성(data locality) 덕분이다.

거대한 용량의 데이터 전송보다 하드디스크를 더 느리게 하는 주범이 있다면, 그것은 디스크의 한 부분에서 다른 부분으로 디스크 판독/기록 헤드(heads)를 움직일 때이다. 움직인다는 의미는 헤드에 있어서 시작, 정지, 원하는 위치 확인, 디스크 회전 대기, 비트 전송의 의미다. 이 모두 물리적으로 움직이는 부품으로 이뤄진다. 이 작업을 빠르고 효율적으로 한다는 사실이 놀라울 따름이다. 하지만 물리학은 제약이 따르게 마련이다. 이런 움직임은 하드디스크와 같은 회전형 스토리지의 성능을 제약시키는 주범이다.

HFS+ 볼륨 포맷은 파일에 대한 모든 정보를 메타데이터(참고: 맥과 메타데이터(metadata))에 저장한다. 이 메타데이터는 디스크 상에서 Catalog File과 Attributes File에 저장된다. Catalog File은 파일 날짜와 퍼미션, 소유, 그 외 다른 정보를 저장하며, Attributes File은 "네임드포크(named forks)"를 저장한다.

HFS+의 확장속성은 Attributes File에서 네임드포크로 구현이 되는데, 파일시스템이 지원하는대로 매우 커질 수 있는 리소스 포크와는 달리, HFS+ 상에서는 Attributes File 안의 "인라인(inline)"에 저장된다. 실질적인 의미로 보자면, 속성당 128 바이트의 한계를 지닌다는 의미다. 반면 디스크 헤드가 실제 데이터를 얻기 위해 이리저리 움직이지 않아도 된다는 의미이기도 하다.

상상해보실 수 있다. Attributes와 Catalog 파일을 구성하는 디스크 블럭은 접근이 굉장히 많은 블럭이다. 따라서 캐시 안에 있게 마련이다. 그리고 이 모든 협력에 따라 파일의 완전한 저장이 이뤄진다. 데이터 안의 메타데이터와 B-tree-구조로 된 Attributes와 Catalog 파일이다. 이 또한 성능을 개선시킨다. 8 바이트짜리가 25 바이트까지 커져봤자 우려스럽지 않다. 원래의 데이터 스토리지 블럭 크기 배분보다 훨씬 적기 때문이다. 게다가 Attributes 파일 안의 B-tree 노드에 맞다면, OS는 어떻게든 전체를 읽어들여야 한다.

스노레퍼드의 줄어든 디스크 용량에 다른 큰 이유도 있다. (불필요한 언어 파일 삭제와 "designable.nib" 파일 삭제) 하지만 HFS+의 압축시스템이야말로 기술적으로 제일 흥미로운 부분이다.

Installer intelligence

애플은 설치 과정에서 흥미로운 약속을 두 가지 하였다.

스노레퍼드는 여러분의 애플리케이션에 호환성이 있는지 확인하고, 호환성이 없는 프로그램을 사용금지(set aside)한다. 설치중 전력공급에 차질이 있을 경우, 데이터 손실 없이 설치과정이 다시 시작된다.

호환성이 없다고 알려진 애플리케이션에 대한 사용금지는 분명 "블루 스크린"에 대한 대응이랄 수 있다. 2년 전, 타이거에서 레퍼드로 업그레이드할 때 보고가 됐던 문제이기도 하다(써드파티의 불법 익스텐션 때문이라는 말도 나올 것이다). 그런 소프트웨어에 대해 필자는 실용적인 관점을 갖고 있으며 애플 또한 사용자에게 미치는 여파를 최소화시키기 위해 실용적인 접근을 한 것에 대해 기쁘게 생각한다.

당연히 애플이 일일이 호환성이 없는 소프트웨어 모두 잠재적으로 알아내서 비활성화시켜버릴 수는 없다. 제일 위험도가 높거나 제일 유명한 소프트웨어만 목록화시키지 않았나싶다. 개발자라면 이 인스톨러 기능을 통해, 자신이 애플의 블랙리스트에 올라있는지 알아볼 수 있는 좋은 수단이 될 수도 있겠다.

전력차질의 경우, 그런 기능을 테스트해볼 수는 없었다. (필자는 UPS를 갖고 있다.) 설치처럼 시간이 오래 걸리는 프로세스에서 이런 견고함은 환영할만한 기능이다. 특히나 노트북처럼 배터리로 돌아간다면 더욱 그러하다.

위 에 말한 두 가지 약속을 언급한 이유는, 애플 개발자들이 OS 컴퍼넌트를 정리할 시간을 갖게 되었을 때 가능한 종류의 약속이라서이다. 인스톨러 팀이 거의 2년의 개발기간 동안 할 수 있는 일을 다 하라는 압박을 받았으리라 볼 수 있겠다. 정말 그랬는지는 알 수 없어도, 분명 소비자들이 그 혜택을 누리게 되었다.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/3

tiens · 2009/09/04, 09:30 AM

윗첨자 표기를 글을 쓸때 쓸 수가 없네요. 10^9라든가 2^30 으로 임시변통해야겠네요.

casaubon · 2009/09/04, 02:49 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

Snow Leopard's new looks

맥오에스텐의 Aqua가 나왔을 때처럼 필자는 애플이 적어도 시각적으로 깔끔한 변경(break)이 필요하다고 오랫동안 주장했었다. 그러나 슬프게도 좀 더 기다려야겠다. 스노레퍼드도 그런 쪽으로는 혁명적이어서가 아니다. 스노레퍼드 또한 친숙한 외양을 갖고 있다. 하지만 뭔가 다른 점도 있다. 사실을 알려드리자면, 스노레퍼드는 화면상의 거의 모든 픽셀 모양을 바꿔버렸다. 우리가 상상할 수 있던 방식은 아니지만 말이다.

매킨토시 상에서 컬러가 나온 이래, 매킨토시 운영체제는 1.8의 감마 보정을 기본 출력값으로 지켜왔다. 그러나, 윈도는 감마 보정을 2.2로 사용해왔다. 전문 그래픽 아티스트가 아니면 그 값이 얼마건 별 상관 없어보이기는 하지만, 전문가가 아니더라도, 똑같은 이미지를 두 모니터로 비교해 볼 때, 그 차이는 알아볼 수 있을 정도이다.

물론 익숙해진대로 매킨토시 사용자들은 1.8의 감마 보정을 본능적으로 더 선호할 것이다. 그렇지만 애플은 이 보정을 지키는 것이 더 문제라고 결정내렸다. 이제 스노레퍼드의 기본 감마 보정은 2.2가 되었다.

이 때문에 스노레퍼드 사용자 인터페이스의 콘트라스트가 레퍼드보다 약간 더 올라갔다는 느낌이 생길 것이다. 기본 데스크톱 배경도 바뀌었기에 더욱 더 그러하다. (완전히 다른 이미지이기는 하지만, 감마 보정값 수정으로 인한 효과를 보여주려고 한 것은 아닐 것이다.)


Leopard		Snow Leopard

Dock Exposé spotlight effect

그런데 색상 보정보다 스노레퍼드 인터페이스에서 애플이 추가시킬 수밖에 없었던 것이 따로 있다. 제일 눈에 띄는 변화는 독과 관련된 부분이다. 우선 독의 애플리케이션 아이콘을 클릭하고 있으면 생기는 "스폿라이트"가 있다. (이로써 엑스포제를 실행시킬 수 있다. 클릭한 애플리케이션에 속한 윈도만이지만 말이다.)

또한 독 상에서 뜨는 모든 메뉴(독에서만 그러하다)가 스노레퍼드에서는 독특한 외양을 갖는다. 모양새 개인화로 할 수 있으며, 시스템 모양새 설정과 잘 맞는다.

New Dock menu appearance. Mmmm… arbitrary.

특정 세대 맥 사용자들은 아마 안좋았던 지난날의 Copland 시스템에 있었던 애플의 하이테크 테마를 떠올릴지 모르겠다. 보다 더 미묘하지만 말이다. 곡선화된 코너를 강조하는 반투명의 가장자리를 보시기 바란다. 선택된 영역도 자제가 되어 있다.

그럼에도 불구하고 이것은 단일 애플리케이션을 위한 완전히 새로운 외양이며, 독의 기본 모양새인 "비스듬하고 빛나는" 모양새와 충돌한다. 하지만 필자는 이미, 여러 차례, 말한 바 있다. 스노레퍼드 모양새의 맹세 1조가 "first, do no harm"이라면, 통과 등급을 주겠다. 거의.

스노레퍼드의 시각적인 추가부분에 대해서 무엇이 잘못되었는지 말하라고 한다면, 두 단어로 얘기하겠다. "모두가 빛바래진다." 애플은 스노레퍼드의 모든 애플리케이션에 Core Animation을 끼얹은 듯 하다. 사용자 인터페이스가 나타났다가 사라지고, 변화한다. 그리고 애니매이션에 따라 사라진다.

일반적인 경우에야 이런 효과는 좋다. 하지만 몇몇의 경우 도가 지나쳤다. 아니, 정확히는 필자의 기준을 넘어섰다. 이것은 지적할만하다. 레퍼드와 그 이전 맥오에스텐의 번지르함에 이미 싸늘해진 사람들도 있을 터이다. 그런 이들은 스노레퍼드의 시각적 변화를 별로 환영하지 않을 것이다.

정말 필자를 미치게 만든 것이 한 가지 있다. (놀랍게도 파인더다!) 데스크톱 상의 파일 이름을 바꾸려 할 때 나타나는 파일 제목 영역이 춤을 추는 부분이다. 너무나 많이 사라지고, 색상과 문자도 바뀐다. 그 조그마한 영역이 너무나 빠르게 바뀌어서 괴로울 정도였다. 컴퓨터를 쓸 수 있을 때까지 이 애니메이션이 멈추기를 기다리는 듯한 느낌이 들었다. 물론 필자는 평범한 이들 대부분(이 기사 전체를 읽지 않을 이들이다)은 이러한 시각적 변화를 오히려 더 좋아하거나, 전혀 알아차리지 못하리라고 본다.

Branding

애니메이션 부분만 빼면, 스노레퍼드는 시각적으로 레퍼드와 동일하다. 애플로서는 마케팅하기 어렵다는 얘기다. "신기능 없음"이라는 말을 소비자들한테 하면서, 운영체제 업그레이드를 하라니, 이 자체가 문제가 될 수 있다. 스노레퍼드가 존재하지도 모를 이들에게는 더욱 더 문제다.

스노레퍼드 출시를 준비하면서 애플은 레퍼드의 우주 테마를 약간 수정한 채로 놓아 두었다. 기조연설 슬라이드, WWDC 배너, 개발자용 DVD, 애플 웹사이트 내 모든 맥오에스텐 섹션에 이르기까지, 스노레퍼드 출시 1주일 전까지 계속 쓰였다. 바깥 우주와 별, 빛나는 성운, 그리고 렌즈의 깜빡임이 그려진 예쁜 그림이다.

Snow, The final frontier.

그러다가 GM(golden master) 버전이 나왔다. 스노레퍼드가 나오기 수 주일 전이었다. 이 버전의 인스톨러는 완전히 다른 모양이었다. 이 모양이 소매판매본으로 그대로 넘어갔다. 패키지 디스크별로 보자면 아래와 같다. (크기는 거의 디스크 크기로 급속히 줄어들었다.) 맥오에스텐 10.0부터 10.6의 패키지이다. (10.0과 10.1은 본질적으로 같다.)

One of these things is not like the others…

그렇다. 진짜 눈표범이다. 그리고 눈까지 얹어져 있다. 필자 취향은 아니지만, 매력은 있다. 그리고 한 가지 거대한 효과를 가져왔다. 이 이미지만으로 갑자기 뭔가 완전히 다르다는 인식이 생겨나는 것이다. 8년간 여러가지 형태의 거대한, 중앙정렬된 "X", 그리고 붐. 동네 애플스토어에 지난 2년간 그런 엑스 자 모양의 레퍼드만 놓여 있었다. 그러다가 갑자기 이런 눈표범 디스크가 올라와 있는 것을 놓칠리가 없다.

(스노위 스노레퍼드(그렇다. 필자가 이름붙였다.)의 이미지가 좋다면? 친절하게도 애플은 OS 안에 배경화면으로 쓸 수 있도록 이 이미지를 포함시켜 놓았다. 지긋지긋한 윈도 이용자들도 직접 다운로드받을 수 있다.)

http://arstechnica.com/apple/reviews...s-x-10-6.ars/4

casaubon · 2009/09/04, 07:50 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

Warning: internals ahead

드디어 "내부" 섹션의 시작에 왔다. 스노레퍼드는 내부 변화가 전부랄 수 있으며, 이는 아래 리뷰 콘텐츠에 반영되어 있다. 사용자 눈에 띄는 변화가 뭔지에만 관심 있다면, 넘어가셔도 된다. 하지만 스노레퍼드의 핵심이 이 내부 변화이며, 아무래도 놓치기 아쉬워하시잖을까.

64-bit: the road leads ever on

맥오에스텐의 64-비트의 여행은 2003년, 팬써(Panther)로 거슬러 올라간다. 팬써는 당시 새로 나온 PowerPC G5 64-bit CPU를 최소한으로 지원하고 있었다. 2005년의 타이거(Tiger)는 진정한 64-비트 프로세스를 만들어낼 수 있었지만, GUI 라이브러리와는 전혀 링크가 안되어 있었고, 2007년에 나온 레퍼드는 드디어 64-비트 GUI 애플리케이션을 지원하였다. 하지만 지원하는 애플리케이션이 64-비트 Cocoa 애플리케이션 뿐이었다. 이는 Carbon의 죽음을 뜻하였다.

즉, 레퍼드도 64-비트형이기는 했지만, 완전한 64-비트 열반에 오르기 위해서는 몇 단계가 더 필요했다. 아래 표를 참고하시기 바란다.


Mac OS X 10.4 Tiger	Mac OS X 10.5 Leopard	Mac OS X 10.6 Snow Leopard

보시다시피, 스노레퍼드 표의 노란색은 모두 능력을 보여주는 것이지, 기본 모드라는 의미는 아니다.

K64

스노레퍼드는 64-비트 커널(애플은 "K64"라 부른다)을 탑재한 첫 번째 맥오에스텐이다. 하지만 시스템 대부분은 기본이 아니다. 이유는 간단하다. 맥오에스텐에 "혼합 모드"가 없다는 사실을 알아야 한다. 32비트이건 64비트이건, 맥오에스텐의 프로세스는 같은 종류의 다른 코드-라이브러리, 플러그인 등-만 읽어들일 수 있다.

이 경우 커널이 읽어들이는 중요한 플러그인이 디바이스 드라이버들이다. 스노레퍼드는 기본적으로 64-비트 커널이며, 따라서 64-비트 드라이버만 읽을 수 있다. 64-비트 커널을 탑재한 최초의 버전이 스노레퍼드이기 때문에, 소비자들용 드라이버는 거의 없었을 것이다.

그래서 스노레퍼드는 2008년에 나온 엑스서브 이후 하드웨어에서만 64-비트 커널로 부팅한다. 엑스서브에 있는 기기들 전부 애플이 스노레퍼드를 통해 드라이버를 공급하지 않나싶다.

따라서 64-비트 프로세서를 가졌다고 해서 모든 맥이 64-비트 커널로 부팅할 수는 없다. 놀랄 일은 아니다. 스노레퍼드의 업데이트를 통해 바뀔 수도 있겠지만, 아래 표를 보면 K64로 부팅할 수 있는 맥 목록이 나와 있다. (자기 맥의 "모델명"을 찾은 다음, 애플 메뉴의 "이 맥에 대하여"를 클릭한 다음에 "More Info" 버튼을 누른 다음, ""Model Identifier"가 어떻게 나오는지 보면 된다.)

제품	모델명	K64 status
Early 2008 Mac Pro	MacPro3,1	Capable
Early 2008 Xserve	Xserve2,1	Default
MacBook Pro 15"/17"	MacBookPro4,1	Capable
iMac	iMac8,1	Capable
UniBody MacBook Pro 15"	MacBookPro5,1	Capable
UniBody MacBook Pro 17"	MacBookPro5,2	Capable
Mac Pro	MacPro4,1	Capable
iMac	iMac9,1	Capable
Early 2009 Xserve	Xserve3,1	Default

K64가 되는 맥은 모두, 부팅할 때 "6"과 "4"를 동시에 눌러서, 64-비트 커널로 부팅할 수 있다. 기본부팅을 하려면, boot-args 스트링에 있는 nvram 커맨드로 arch=x86_64를 붙이면 된다. 혹은 /Library/Preferences/SystemConfiguration/com.apple.Boot.plist파일을 열어서, Kernel Flags 스트링에 arch=x86_64을 붙이면 된다.

...

	<key>Kernel</key>

	<string>mach_kernel</string>

	<key>Kernel Flags</key>



	<string>arch=x86_64</string>

...

다시 32비트 커널로 돌아가려면 부팅 때 "3"과 "2"를 동시에 누르면 된다. 아니면 위의 기술대로, "x86_64"를 "i386"으로 바꾸면 되겠다.

적어도 처음에는 K64로 부팅하지 않기 바랄 것이라는 점을 이미 논의한 바 있다. 그러나 스노레퍼드 채택이 늘어나고, 기존 커널 익스텐션의 64-비트 업데이트가 증가하더라도, 과연 64-비트 커널을 실제로 사용하게 될까?

첫 번재 이유는 RAM이다. 지금 여러분이 생각하는 그 이유가 아니다. 레퍼드가 32-비트 커널을 사용하지만, 레퍼드를 돌리는 맥은 "32-비트"의 한계인 4GB보다 훨씬 많은 RAM 을 사용할 수 있다. 그러나 RAM 크기가 늘어날수록 다른 문제가 생긴다. 어드레스 공간의 소모만이 아니다. 커널 스스로의 소모량때문이다.

32-비트 프로세스에서 커널은 스스로를 32-비트로 묶어둔다. 즉, 4GB의 어드레스 공간이 생긴다. 문제같아 보이지 않는다. 사실 4GB 이상의 메모리를 커널이 정말 필요로할까? 커널의 임무가 무엇일까? 시스템 메모리의 추적 및 관리이다. 이 사실을 기억해야 한다. 커널은 각각 시스템 상에서 4KB의 RAM page의 상태를 추척하는 64-바이트 구조를 사용한다.

64 바이트이다. 킬로바이트가 아니다. 전혀 많아보이지 않는다. 하지만 그리 머지않은 장래에 96GB RAM을 탑재한 맥을 상상해 보시라. (웃기게 들린다면, 현재 필자가 사용하고 있는 8GB RAM의 맥도 5년 전에 상당히 웃기게 들렸다는 점을 알아주시기 바란다.) 96GB의 RAM이라면, 커널 어드레스 공간은 1.5GB이다. 커널 어드레스 공간의 1/3 이상을 단지 메모리 추적하기 위해 쓴다는 의미다. 별로 바람직하지 않은 상황이다.

달리 말해서, 64-비트 커널의 커널 어드레스 공간은 실질적으로 무제한이다. (16 exabytes이다). K64도 어쩔 수 없이 필요하다. 시스템 메모리가 급속히 증가하기 때문이다. 당장 데스크톱에 필요로하건 그렇지 않건, 두 자리 숫자대의 RAM이 서버에서는 이미 흔해졌다.

K-64의 다른 방향은 속도이다. x86 인스트럭션 셋 아키텍쳐의 역사는 좀 고통스러운 역사다. x86 아키텍쳐에서 64-비트 익스텐션인 x86-64 디자인을 위해, AMD는 지난 과거는 놓아둔 채, 더 많은 레지스터와 새로운 어드레싱 모드, 스택-기반이 아닌 플로팅 포인트 연산, 등 더 많은 현대적 기능을 집어넣는다. K64도 이런 혜택을 받으며, 애플은 성능 개선에 대해 다음과 같은 주장을 하고 있다.

250% faster system call entry point

70% faster user/kernel memory copy

벤치마크도 비슷하게 나오리라 확신한다. 하지만 커널 성능이 좋아졌다고 해서 일상적인 사용까지 속도개선이 있을 것 같지는 않다. 커널을 실제로 비중있게 다루는 소수의(보통은 서버-기반이다) 애플리케이션의 병목현상을 해소해줄 뿐이라 생각하라.

커널이 보다 효율적으로 돌아간다는 사실을 알아서 다행이라고 느낀다면(그리고 실제로 96GB의 RAM이라면), 어드레스 공간의 커널이 부족할 일은 없을 것이다. 그리고 정말 사용해야 할 32-비트 드라이버가 없다면, 꼭 64-비트 커널로 부팅하도록 한다. 그렇지 않다면, K64는 커널 익스텐션들이 K64 지원을 다 갖출 때까지 기다리시면 되겠다. 결국 필요할 때가 올 것이다.

마지막으로 이 말은 거듭할만하다. 64-비트 애플리케이션을 돌린다거나, 맥에 4GB 이상의 RAM을 설치하기 위해서 64-비트 커널이 필요한 것이 아니다. 32-비트 커널이라 하더라도 64-비트 모드로 애플리케이션이 잘 돌아간다. 심지어 64-비트 커널이 아닌, 예전 맥오에스텐에서도 4GB 이상의 RAM을 설치해서 효과를 볼 수 있었다.

64-bit applications

레퍼드가 64-비트 GUI 애플리케이션 지원을 처음 했을지는 몰라도, 실제로 지원한 GUI 애플리케이션은 매우 소수였다. 필자가 볼 때 레퍼드에 딸려온 64-비트 GUI 애플리케이션은 딱 두 가지였다. 선택사항으로 설치하는 Xcode와 Chess다. 써드파티가 64-비트 GUI 애플리케이션을 만들 수 있는 길을 레퍼드가 터주기는 했지만(단, 레퍼드 전용이 되어버린다), 실제로 나온 애플리케이션은 거의 없었다. 실질적인 이득이 없어서이다. 그랬다가는 맥오에스텐 10.4 이하 사용자들을 잃는 효과를 초래한다.

현재 애플은 64-비트 이주를 더 강하게 밀고 있다. 사례로 설명해보겠다. 스노레퍼드에서 64-비트가 아닌 애플리케이션은 단 네 가지이다. 아이튠스와 Grapher, Front Row, 그리고 DVD Player다. 나머지는 모두 64-비트이다. Finder와 Dock, Mail, TextEdit, Safari, iChat, Address Book, Dashboard, Help Viewer, Installer, Terminal, Calculator 등 모두가 64-비트이다.

두 번째 당근(혹은 관점에 따라 채찍이 될 수도 있겠다)은 새 API와 기술이 32-비트 지원을 하지 않는 추세라 볼 수 있다. 이러한 경향을 주도한 것은 원래 레퍼드였다. 새로운 API만 64-비트로 포팅을 했으니 말이다. 레퍼드에 들어있던, 개선된 오브젝티브-C 2.0 런타임 또한 64-비트 전용이었다.

스노레퍼드 또한 비슷한 선상에 있다. 스노레퍼드의 오브젝티브-C 2.1 런타임의 취약하지(fragile) 않은 인스턴스 변수, C++와 통합된 익셉션(exception) 모델, 더 빠른 vtable 처리도 오로지 64-비트 애플리케이션만 활용할 수 있다. 그러나 무엇보다도 새롭고 중요한 64-비트 전용 API는 퀵타임 텐(X)이다. 여기에 대해서는 별도로 얘기해야 할 정도로 가치가 있으니 좀 기다리시라.

64-bits or bust

애플이 직접적이라 할 수 있을 정도로 말하고자 하는 바는 결국 64-비트로 이제 이주할 때라는 것이다. 그리고 그 64-비트가 앞으로 새로 나올 애플리케이션 모두의 기본이 될 것이다. 개발자가 그것을 "필요로 하건" 아니건 말이다. 대부분의 경우 이들 새 API는 64-비트와 꼭 결부되어야 할 이유가 없다. 다만 애플이 이들을 64-비트로 끌고 가는 미끼로 결정내렸다.

하지만 위의 모든 말에도 불구하고, 스노레퍼드는 아직도 64-비트로 향한 여행이라 말하겠다. 맥오에스텐 10.7이 나오면 완전히 64-비트 커널로 기본부팅되고, 모든 애플리케이션과 플러그인, 커널 익스텐션을 64-비트화시키리라 기대한다. 옛 API나 어울리지 못하는 API는 32-비트로 남겨두고 말이다.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/5

casaubon · 2009/09/04, 07:52 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

QuickTime X

레퍼드가 나왔을 때, C-기반이던 퀵타임 API를 애플은 64-비트로 포팅하지 않았다. 당시로서는 대수롭지 않은 결정이었고, 64-비트로의 맥오에스텐 이주는 이미 수년 동안 진행중이었다. 그러니 퀵타임이 아직 때가 아니었나보다라고 생각할 수도 있겠다.

하지만 필자는 간결하되 비관적인 평가를 내렸다. 그것이 맞았다. 퀵타임이 "카본 취급"받은 것이다. 카본처럼 우리가 알고 사랑해온 퀵타임 API는 영원히 64-비트화되지 않을 터였다.

분명히 말하자면, 퀵타임 기술과 퀵타임 브랜드는 당연히 64-비트화가 된다. 1991년에 소개된 다만 C-기반의 API만이 32비트로 남아있으리라는 의미다. 18년의 세월이다. 스노레퍼드의 64-비트 퀵타임은 이름이 퀵타임 엑스로 바뀌었다. 퀵타임 텐의 "X"는 맥오에스텐과 마찬가지로 "텐"이라 발음한다. 정말 맥오에스텐을 방불케 하는 으스스함이 감돈다. 비교해보자.

전임과 깔끔한 단절이 그 목표
원래 다른 플랫폼용으로 개발한 기술을 기반함.
이전 버전과 투명한 호환성을 포함
더 나은 성능과 보다 현대적인 아키텍쳐를 약속
첫 버전에는 중요한 기능이 몇 가지 없음.

Maximum available Mac CPU speed (MHz)

하나 하나씩 알아보자. 첫 번재로, 깔끔한 단절? 간단히 말해서, 퀵타임은, 정말 늙었다. 공포스러울정도로 뭉툭하다. 1991년 당시 첫 등장 때는 우표 크기만한 영상을 표시했던 기술이 퀵타임이다. 당시로서야 최신 기술이었다.

당시 제일 빠른 매킨토시는 25 MHz CPU였다. 지금과 비교하면 얼마나 웃기는지 오른편 차트를 보시라. 진보적 디자인만이 따라잡을 수 있는 법이다. 기술이란 무릇 태어나면 결국 운명이 된다. 오랜동안 남아 있어서 하위 호환성이 강력하던 퀵타임 API에서는 정말로 그러하다.

개인용 컴퓨터에서 최초로 비디오 구현을 성공시킨 기술로서 퀵타임 API는 그 기간만큼이나 놀라운 존재였다. 하지만 세상이 바뀌었다. 맥오에스가 협력형 멀티태스킹과 비보호 메모리로 갑자기 포위당한 것처럼, 2009년의 퀵타임은 한물 간 하부시스템을 갖고 있었다.

최신 버전인 퀵타임 7을 보자. 아이폰용 비디오 코드를 작성할 때가 되자, 퀵타임은 한계에 부딪혔다. 데스크톱에서 너무나 비효율적으로 자라나버린 나머지, 휴대 기기에서 현대적인 비디오 코덱을 다루기 위한 GPU-가속지원도 갖고있지 않았다. (제아무리 퀵타임 1.0이 나왔을 시절 맥보다 현재의 CPU가 16배 더 빠르더라도 말이다.) 그래서 애플은 현대적이고 견고하며, GPU-친화적인 비디오 엔진을 만들어낸다. 아이폰용 RAM과 CPU에 들어맞도록 말이다.

흠. 나이가 들어가는 데스크톱 비디오 API를 교체할 때가 되었다. 좀 (상대적으로) 떨어지는 하드웨어에서도 좋은 성능을 내면서, 산뜻하고 새로운 비디오 라이브러리가 필요했다. 이번에도 결국은 이주 문제였다. 언제나 그랬듯이 말이다. 하지만 이주야말로 애플이 잘 하는 것 아니겠는가? 퀵타임 자신도 세 개의 전혀 다른 CPU 아키텍쳐와 세 가지의 전혀 다른 운영체제 속에서 살아남았다.

64-비트로의 이주 또한, 드라마틱하지는 않지만, 변곡점이다. 애플은 퀵타임 7과 새로운 퀵타임 텐 사이에 아예 경계선을 분명하 하기로 결정내렸다. 이 때문에 스노레퍼드에서는, 64-비트 애플리케이션이 퀵타임을 사용할 때, 아예 QTKit Objective-C 프레임웍만 사용하도록 하였다. QTKit이 새 주인공이 되었다.

QTKit이 전혀 새롭게 나오지는 않았다. 원래 Cocoa용 애플리케이션에 퀵타임 7 인터페이스를 붙여서 네이티브같은 느낌이 나게 하기 위해 시작된 키트다. 그 때가 2005년이었다. 이러한 엑스트라 추상 레이어가 퀵타임 텐 이주의 열쇠이다. QTKit은 이제 퀵타임 7과 퀵타임 텐 모두를 객체-지향적인 벽 안에 숨겨놓고, QTKit을 애플리케이션이 사용할 경우, 퀵타임 7을 사용할지, 퀵타임 텐을 사용할지, QTKit이 결정내리게 된다.

퀵타임 텐이 그리도 좋다면, QTKit이 항상 퀵타임 텐만 사용하면 되잖겠나? 퀵타임 텐은 이름처럼 맥오에스텐과 닮았다. 즉, 아직 처음 상태이기 때문에 제약이 많다. 퀵타임 텐은 재생과 캡쳐, 추출을 지원하지만 일반적인 목적의 비디오-편집은 지원하지 않는다. 또한 "현대적인" 비디오 포맷만 지원한다. 기본적으로 아이포드와 아이폰, 애플티비에서 돌릴 수 있는 포맷들이다. 다른 비디오 코덱은 어떨까? 플러그인이 생각날 텐데, 퀵타임 텐은 플러그인도 아직 지원하지 않는다.

퀵타임 텐이 어울리지 않는 경우, 퀵타임 7이 등장하게 된다. 자르기나 복사하기, 붙이기는 무엇으로 할까? 퀵타임 7이다. 영상에서 개별 트랙 추출은? 퀵타임 7이다. 기존 애플 휴대기기에서 네이티브로 다루지 못하는 영상은? 퀵타임 7이다. 퀵타임 코덱 지원용 플러그인이 필요하다면? 역시 퀵타임 7이다.

하지만 기다리시라. QTKit은 퀵타임을 사용하려는 64-비트 애플리케이션 전용이고, QTKit이 퀵타임 7과 퀵타임 텐 사이에서 선택을 한다. 퀵타임 텐은 가려져 있고, 퀵타임 7은 32-비트 전용이며, 맥오에스텐은 32비트와 64비트 코드를 둘 다 돌릴 수 있는 "혼합 모드"를 지원하지 않는다. 그렇다면 퀵타임 7을 요구하는 64-비트 프로세스가 나온다면 어떻게 될까?

이를 알기 위해, 새로운 64-비트 퀵타임 플레이어 애플리케이션을 열고, 퀵타임 7을 필요로하는 영상을 돌려보자. 말하자면, Sorenson 코덱이 들어간 영상은 어떨까? (이 코덱을 기억하시는가? 좋았던 시절이다.) 분명 잘 돌아갈 것이다. 하지만 Activity Monitor 상에서 "퀵타임"을 검색해보면 아래와 같이 뜬다.

Pretty sneaky, sis: 32-bit QTKitServer process

답변이 나왔다. QTKit을 사용하는 64-비트 애플리케이션이 32-비트 전용 퀵타임 7 서비스를 필요로 할 경우, QTKit은 별도의 32-비트 QTKitServer를 띄운다. 이 QTKitServer가 원래의 64-비트 프로세스에게 결과를 되돌려주는 작업을 한다. 새 퀵타임 플레이어 애플리케이션을 사용하면서, Activity Monitor를 계속 열어놓으면, QTKitServer 프로세스가 필요할 때 어떻게 생기고 나가는지 구경할 수 있다. 그리고 이 모든 것을 QTKit이 투명하게 처리한다. 애플리케이션 자신은 어떻게 처리되는지 모르는 채로 말이다.

그렇다. 맥오에스텐에서 퀵타임 7이 사라질 시기는 매우 오래, 오래 남았다. (적어도 애플이 "퀵타임 클래식"이라는 명칭 정도를 만들지 않는 한 말이다.) 그러나 방향은 분명하다. 맥오에스텐이 새로 나올 때마다 퀵타임 텐도 확장되고 퀵타임 7을 요구하는 것은 줄어들 것이다. 가령 맥오에스텐 10.7 쯤 나오면, 퀵타임 텐이 플러그인 지원도 받게 되잖을까싶다. 그리고 맥오에스텐 10.8이 나오면 퀵타임 텐은 완전한 비디오 편집 지원도 하게 될 것이다. 이 모든 것이 QTKit의 그림자 안에서 돌아가게 되고, 결국은 퀵타임 7이 필요없어질 때가 오게 된다.

Say what you mean

아마 놀랄지도 모르겠는데, 퀵타임 텐이 현재 갖고 있는 제약 중 상당수는 오히려 QTKit API가 독특한 장점을 갖게 될 것이며, 앞으로 더욱 더 자라나리라는 점을 시사하기도 한다. QTKit이 퀵타임 텐을 사용하도록 요구할 직접적인 방법이 ㅤㅇㅏㅈ기 없다 하더라도, 그런 결정을 내리에 할 간접적인 수단이 몇 가지 있다. 주안점은 역시 QTKit API이다.

퀵타임 버전 1~7은 모든 미디어 리소스, 무비 객체를 내부적으로 다루는 단일 표시방식이었다. 영상을 구성하는 개별 트랙이나 각 트랙별 샘플 테이블 등, 퀵타임이 이해하고 조작하는데에 필요한 모든 정보를 이 표시방식이 포함하고 있다.

근사한 말이다. 이 포괄적인 영상 객체를 요구하는 퀵타임에서, 미디어 리소스로 뭔갈 하려할 때까지는 말이다. 퀵타임으로 MP3 파일 돌리기를 고려해 보시라. 퀵타임은 재생 전에 MP3 파일을 내부적으로는 영상 객체로 만들어내야 한다. 불행히도 MP3 컨테이너 포맷은 오디오 구조에 대한 포괄적 정보를 거의 갖고 있지 않다. 그저 패킷 스트림의 합체물일 뿐이다. 그러면 퀵타임이 영상 객체를 완수하기 위해, 전 오디오 스트림을 열심히 스캔하고 분석해야 한다.

퀵타임 7 이하 버전은 스캐닝과 분석을 백그라운드에서 한다. 그래서 그리 고통스럽지는 않다. 무비 컨트롤러 상에서 퀵타임-기반 플레이어 애플리케이션들이 열심히 프로그레스 바를 채워나가는 모습을 볼 수 있다. 아래 이미지는 63MB 짜리 포드캐스트로서, 플레이어는 레퍼드에 들어있는 퀵타임 플레이어이다. 영상 타임라인의 그림자 부분이 느리게 채워지고 있는 중이다.

QuickTime 7 doing more work than necessary

재생을 거의 순간적으로 하기는 하지만(거의 열자마자 시작한다), 무슨 일이 일어나서 재생을 하는지 한 번 생각해봄직하다. 퀵타임은 퀵타임이 수행할 수 있는, 그러니까 편집이나 트랙추출, 추가, 추출, 이름짓기 등의 작업에 맞도록 영상 객체를 만들어낸다. 하지만 원하는 것이 오로지 재생 뿐이라면?

퀵타임 7 API에는 그런 종류의 목적을 표현할 방법이 없다. 이것이 문제다. 퀵타임 7에서 "최대한 빨리 열어서 재생만 가능하도록 하고, 디스크에 있는 파일의 모든 바이트를 읽거나, 추출/편집할까봐 구조를 분석하는 일은 하지 말 것"이라 명령을 내릴 방법이 없다.

스노레퍼드의 QTKit은 바로 이런 기능을 제공한다. 사실 퀵타임 텐을 사용하는 유일한 방법이 퀵타임 텐이 다룰 수 있는 것만 하겠다고 스스로 표현하는 것이다. 더해서 이전에 표현한 의도가 아니라면, QTKit은 예외를 불러일으킨다.

이러한 의도 메커니즘은 퀵타임 텐의 신기능이다. 또한 원격으로 있거나 거대한 파일을 비대칭으로 돌리기도 한다. 애플리케이션의 주 쓰레드에서 돌리는 UI를 막지 않고서도 말이다.

퀵타임 텐 버스에 타야 할 이유는 이 외에도 많다. 퀵타임 텐이 지원하는 미디어 포맷을 보면, 퀵타임 텐은 퀵타임 7보다 CPU에 덜 의존한다. (즉, 재생할 때는 편집이나 추출이라는 가능성에 시간을 빼앗기지 않는다는 의미를 넘어선다.) 퀵타임 텐은 H.264의 GPU-가속을 지원하지만, 처음 버전에서는 NVIDIA 9400M GPU만 지원하였다. (즉, 2009년형 아이맥과 2008~2009년에 나온 맥북 모델들) 마지막으로 퀵타임 텐은 비디오용 컬러싱크를 포함한다. 오랜 숙원이 해결된 셈이다.

The X factor

퀵타임 텐은 이제 막 여행을 시작했을 따름이다. 그리 앞날이 쾌청하지도 않다. 편집 지원이 없는 퀵타임 엔진? 플러그인이 없다? 웃길 뿐이다. 하지만 이런 방식이 애플 방식이었음을 알아야 한다. 꾸준하지만 지속적인 개선이 바로 그것이다. 애플은 때가 되기 전까지는 기능을 풀지 않는다.

완전하고 64-비트 계승자에 대해 근심하는 개발자들도 있다. 하지만 퀵타임 코드 기반을 최대로 깔고 앉은 회사가 애플이다. 파이널컷 스튜디오 때문이다. 지금까지는 32-비트로 남아 있으며, 애플 또한 퀵타임 텐 확장에 "상당히 관심을 갖고 있다." 삼가해서 말하는 것이지만 말이다.

그럼에도 불구하고, 애플이 서두르리라 기대해선 안된다. 18년된 API가 퀵타임이다. 꾸준히 개발되온 이 API가 하루아침에 사라지지는 않는다. 수 년이 걸릴 테며, QTKit을 독점적으로 쓰도록 모든 맥오에스텐 애플리케이션이 다 업데이트되더라도, 퀵타임은 아직일지 모를 일이다. 다시 이주 시기이다. 그냥 즐기도록 하자.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/6

casaubon · 2009/09/04, 08:20 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

File system API unification

역사적으로 맥오에스텐은 애플리케이션으로부터 디스크 상의 파일을 대하는 여러가지 방식을 지원해왔다. 단순한 옛 방식(가령, /Users/john/Documents/myfile)은 운영체제중 제일 로레벨에서 쓰인다. 간단하며 예측가능하지만, 애플리케이션이 파일을 추적하는 유일한 방법이라고 할 수는 없겠다. 애플리케이션이 path 스트링 상에 있는 파일을 하나 열어서 아직 편집중인데 다른 곳에다가 옮긴다고 해 보자. 애플리케이션이 파일을 저장하려 할 때, path만으로 작업하게 된다면, 예전 위치에 새로운 파일을 만들게 된다. 사용자가 원하는 식이 아니다.

클래식 맥오에스는 파일의 내부 표시에 대해 보다 세련된 방법을 구사하였다. 실제 디스크 위치를 독립적으로 추적할 수 있도록 하는 방식이다. 이는 HFS/HFS+가 지원하는 독특한 파일 id로 가능했다. 맥오에스텐은 FSRef 데이터 타입 개념을 사용한다.

마침내 현대가 되자, 로컬 머신 말고 다른 어딘가에 파일이 어디에 있는지 가리키려 할 때, URL이야말로 사실상 표준이 되어버린다. URL로 로컬 파일을 가리킬 수도 있지만, 이 경우 파일 path와 똑같은 단점을 지니게 된다.

데이터 타입의 다양성은 맥오에스텐 파일시스템 API에 반영이 되어 있다. 어떤 함수는 파일 path를 argument로 파악하고, 파일에 불투명한 리퍼런스를 기대하기도 하며, URL하고만 돌아가는 것도 있다. 이들 API를 사용하는 프로그램은 종종 매우 많은 시간을 들여서 파일 리퍼런스를 전환시키곤 한다.

파일에 대한 정보를 모을 때에도 유사한 상황이 일어난다. 운영체제의 모든 레벨에서, 파일 시스템 메타데이터 검색 함수는 엄청나게 많다. 하지만 포괄적인 것은 하나도 없다. 디스크 상의 파일에 대해 모든 정보를 얻으려면, 별도의 호출을 해야 한다. 아규먼트로서, 파일 리퍼런스의 각기 다른 타입을 기대하면서 말이다.

애플이 WWDC에서 보여준 사례이다. 레퍼드 버전의 Preview에서 파일 하나를 열 때 결과는 이러하다.

Four conversions of an FSRef to a file path
Ten conversions of a file path to an FSRef

Twenty-five calls to getattrlist()
Eight calls to stat()/lstat()
Four calls to open()/close()

스노레퍼드에서 애플은 싱글 데이터 타입인 URL에 따르는, 새롭고, 통합적이며 포괄적인 파일 시스템 API 셋트를 만들어냈다. 하지만 이들은 URL "객체"이다. NSURL과 CFURL이라는 불투명한 데이터타입과 이 둘을 연결시켜주는 toll-free bridge이다. 하나의 FSRef의 바람직한 속성을 모두 받아들인 것이다.

불투명하다는 특징때문에 이런 개선이 생겼고 이들을 사용하는 기존 API가 대단히 많다. 그래서 애플이 이 데이터 타입을 받아들였다. URL은 모든 선택들 중에서도 가장 미래가 보장된 선택이다. 새로운 데이터나 접근 메커니즘에 대해 URL은 거의 무한정한 융통성을 제공한다. 이런 불투명한 URL 타입의 캐시와 메타데이터 상에서 새로운 파일 시스템 API가 만들어 졌으며, 앞으로도 성능 개선이 있을 것이다.

북마크(브라우저의 북마크와 혼동하지 않기 바란다)라 부르는 디스크에 기록되는 표현법도 있다. 클래식 맥오에스에 있던 가상본(aliases)의 네트워크화된 버전이랄 수 있는데, 북마크는 다른 파일 안에 하나의 파일과 연결되는 제일 강력한 수단이다. 각 북마크마다 임의의 메타데이터를 붙일 수 있다. 가령 애플리케이션이 자신에게 특화된 정보를 "즐겨찾는(favorite)" 파일의 목록에 덧붙이고, 이들 파일의 움직임에 대해 탄력있게 대응하기 원할 경우, 북마크는 최고의 수단이다.

필자가 이런 말을 언급하는 이유는, 스노레퍼드의 파일 시스템 API같은 부분을 필자가 특별히 좋아해서 알리려는 것이 아니다. Core Text처럼, 젊은 맥오에스텐이 플랫폼으로 어떻게 자라나는지를 정확히 보여주는 사례라서 하는 것이다. 그동안 메이저 업데이트가 일곱 번 있었지만, 맥오에스텐은 여전히 조상의 그림자에서 완전히 다 나오지는 못하였다. 조상이란 다름아닌 NeXTSTEP과 클래식 맥오에스, BSD Unix이다. 아니면, 애플의 핵심 OS 팀이 옛날 API와 데이터 타입을 보다 새롭고 현대적인 버전으로 어떻게 바꿔치려하는지를 보여주는 사례이기도 하다.

이런 변화를 최종 사용자들에게 느껴질 정도가 되려면 오랜 시간이 필요하다. 새 API를 사용하여 만들거나, API를 수정한 맥용 애플리케이션이 나와야 하기 때문이다. 잘 작성된 맥용 애플리케이션 대부분은 이미 그런 방향을 보여주고 있다. 가령 레퍼드에 있는 TextEdit 애플리케이션은 작업하는 파일이 이동했을 때를 정확히 검출할 수 있다.

Document moved dialog

TextEdit: a good Mac OS X citizen

여기서 주안점은 당연히 "잘 작성된"이다. 파일 시스템 API의 단순화는 더 많은 개발자들이 들이는 노력이 크게 줄어든다는 의미이기도 하다. 사용자-친화적으로 만들기 위해서이다. 이에 수반하는 성능 개선은 빙산의 일각일 뿐이다. 개발자들이 기존의 API 대신 새로운 API를 선택할 공산은 크다. 이유가 더 있다.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/7

casaubon · 2009/09/04, 08:23 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

Doing more with more

무어의 법칙(Moore's Law)을 인용하는 사례가 매우 많다. 하지만 잘못 이해하는 것이 바로 무어의 법칙이다. 무어의 법칙은 "매년 컴퓨터의 속도가 두 배가 된다"로 알려져 있지만, 고든 무어(Gordon Moore)가 한 말은 그렇지 않다. 1965년, 무어는 Electronics magazine에 반도체 산업의 여러가지 주제에 대해 말을 하였는데, 하나의 "법칙"까지 되기 위해서는, 실리콘 1 스퀘어 인치에 들어가는 트랜지스터 수가 12개월마다 두 배가 된다는 식으로 썼어야 했다.

2년 뒤 무어는 실제로 그렇게 글을 수정하였다. 문제는 사람들이 오해할만한 시기가 아니었다. 문제는 사람들이 트랜지스터 응집도의 두 배, 그리고 컴퓨터 속도의 두 배를 헷갈려했다는 점이다. (1965년의 논문에 근거하여 "법칙"이라 부르는 것도 문제가 있었다. 하지만 그 주제는 여기서 다루지 않겠다. 무어의 법칙에 대해서는 다음의 기사를 참조하시라.)

지난 10년간 트랜지스터 응집도는 사실 컴퓨팅 속도를 동반하였다. 끝없이 오르기만하는 클럭 주파수와 슈퍼스칼라(superscalar)의 출현 덕분이었다. 이 체제는 너무나 잘 작동하였다. 새 CPU가 나올 때마다 기존 코드는 더 빠르게 돌아갔다. 전력밀도의 현실이 문제로 닥치기 전까지는 말이다.

적어도 아직까지는 무어의 법칙이 지속되고 있지만, 트랜지스터 응집도를 올릴 때마다 코드를 더 빠르게 돌릴 능력은 서서히 느려졌다. 공짜 점심은 끝난 셈이다. CPU 클럭속도도 수 년간 정체중이며, 실제로는 아예 후퇴중이기도 하다. (2009년 최신 맥프로는 2.93 GHz CPU이지만 2008년 모델은 3.2 GHz CPU가 실리기도 했었다.) CPU에 실행유닛을 덧붙이기는 이제 그 실익이 없을 정도가 되었다. 인스트럭션-수준의 패러렐리즘(parallelism)의 한계때문이다.

하지만 우리는 여전히 매년 더 많은 트랜지스터를 집어넣고 있다. 문제는 컴퓨터를 실제로 더 빠르게 만들 수 있을 새로운 방법이다.

지금까지 반도체 산업의 답변은 우리가 이미 갖고 있는 것을 더 주는 것이었다. CPU에 논리 프로세서 유닛이 하나 뿐이었던 시절이 있었는데, 이제는 제일 저사양 컴퓨터라 할지라도 프로세서 코어는 두 개씩이다. 하이엔드 모델에서는 아예 칩이 두 개, 여기에 코어는 8개씩 붙기도 한다. 코어 자체는 일처리를 더 빨리 하게 해 준다. 같은 클럭 주파수라도 더 많이 처리할 수 있기 때문이다. 하지만 코어가 말그대로 두 배 세 배 더 빠르게 해주지는 못한다.

불행히도, 아니 일반적으로 얘기할 때 듀얼-코어 CPU는 싱글-코어 CPU보다 애플리케이션을 두 배 더 빠르게 돌리지 못한다. 진실을 말하자면 이렇다. 싱글-코어 CPU보다 코어가 더 많을 때, 이 많아진 코어를 이용하도록 코드를 재작성하지 않는 한, 애플리케이션은 더 빨라지지 않는다. 칩 업체들은 더 많은 리소스를, 트랜지스터를 주기로 마음먹었지만, 프로그래머들은 그것을 갖고 어떻게 할줄 모른다. 컴퓨터를 더 빨리 돌리는 것은 누구 책임일까? 소프트웨어 쪽의 책임인가?

We're with the operating system and we're here to help

이런 인식 하에 스노레퍼드가 태어났다. (보안과는 별개로) 2009년 운영체제 업체로서 책임이 있다면, OS는 물론 애플리케이션이 늘어나기만 하는 컴퓨팅 리소스를 활용할 방법을 찾아줘야 한다. 스노레퍼드의 주제를 한 가지만 정하라고 한다면, 필자는 이 주제를 택하겠다. 개발자들에게 실리콘 활용법을 알려주는 것이다. 더 많이 할 수 있도록 말이다.

그 목적을 위해 스노레퍼드는 두 가지 중요한 API를 포함시켰다. 더 작지만, 중요도는 큰 기본적인 개선이다. 믿거나 말거나, 그것은 컴파일러부터 시작한다.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/8

casaubon · 2009/09/04, 08:24 PM

Infinite Loop : Ars covers the world of Apple

Mac OS X 10.6 Snow Leopard: the Ars Technica review
Mac OS X 10.6, aka Snow Leopard has landed. This time around, Apple goes light on the glitz in favor of some heavy work under the hood. John Siracusa dives deep into Apple's new OS offering to see what's new, what's still the same, and whether it's worth upgrading.

By John Siracusa | Last updated August 31, 2009 10:00 PM CT

LLVM and Clang

몇 년 전, 애플은 LLVM 오픈소스 프로젝트에 전략적 투자를 시행하였다. 필자의 레퍼드 리뷰에 LLVM의 근본 토대에 대해 이미 써 놓았다. (시간이 있다면 이 글을 더 읽기 전에, 필자의 예전 글을 더 읽어보시기 바란다.) 그 기사에서 필자는 레퍼드가 어떻게 LLVM을 활용하는지, 이를 통해 OpenGL의 JIT-컴파일 소프트웨어 구현을 어떻게 더 효율적으로 하는지에 대해 써 놓았다. 필자는 충고로 끝을 맺었다.

레퍼드에서 수수하게 사용한다고 하여 현혹되지 않기 바란다. 애플은 LLVM으로 언대한 계획을 세워두었다. 얼마나 원대할까? 현재 맥오에스텐이 사용하는 gcc 컴파일러를 걷어내고, 이를 LLVM으로 바꾸면 어떨까? 이 프로젝트는 잘 진행중이다. 이정도로도 충분하지 않나? gcc를 아예 없애고, 완전히 새로운 LLVM-기반(단, gcc-호환을 갖춘) 컴파일러 시스템은 어떨까? 이 프로젝트 이름이 Clang이다. 그리고 이미 인상적인 결과가 나오고 있다.

스노레퍼드는 그것을 공식화시켰다. Clang과 LLVM는 이제 애플 컴파일러 미래 전략화 되었다. LLVM은 심지어 새 로고까지 가졌다. 잘 알려진 컴파일러 디자인 교과서에 대한 오마쥬이다.

LLVM! Clang! Rawr!

현재 애플은 맥오에스텐에서 컴파일러 네 개를 제공하고 있다. GCC 4.0과 GCC 4.2, LLVM-GCC 4.2 (GCC 4.2 front-end에 LLVM back-end를 조합했다), Clang이다. LLVM화가 계속 늘어나는 형태인데, 아래 표가 있다.

Mac OS X compilers

이 모든 컴파일러가 맥오에스텐 상에서 바이너리-호환을 갖는다. 가령 하나의 컴파일러로 라이브러리를 만든 다음, 다른 컴파일러로 만든 실행 바이너리에 이것을 링크시킬 수 있다. 물론 이론상 모두 커맨드-라인과 소스-호환성을 갖긴 한다. Clang은 GCC의 비법을 다 지원하지는 못한다. Clang은 C와 Objective-C, 그리고 C++을 약간 지원(Clang(uage)이라는 이름이다. 아시겠는가?)한다. GCC야 훨씬 많이 지원하고 말이다. 애플은 Clang에서 완전한 C++을 지원한다. 스노레퍼드에서 GCC와의 비호환성을 보충하려는 것이다.

새로나온 컴파일러로서 Clang은 으레 기대하게 만드는 두 가지 특징을 갖는다. 더 짧은 컴파일 시간과 더 빠른 실행시간이다. iCal, Address Book, 엑스코드와 같은 애플 애플리케이션과 함께, Adium과 Growl같은 써드파티 애플리케이션 테스팅에서 Clang은 GCC 4.2보다 거의 세 배가 더 빨랐다. 완성된 제품 속도로 보자면, Clang이건 LLVM-GCC이건, GCC 4.2로 컴파일한 것보다 5~25%가 더 빨랐다.

Clang은 또한 GCC보다 더 개발자 친화적이다. 사실 지금부터 얘기하는 것이 다중 CPU 코어의 장점과는 별 관계가 없음을 인정하겠다. 하지만 개발자들이 Clang을 사용할 때 느끼게 될 첫 번째 특징이라서 그렇다.

우선 Clang은 임베드가 가능하다. 따라서 최종 실행 파일을 컴파일 할 때 사용하는 것처럼, 엑스코드는 IDE 안에서 똑같은 컴파일러 인프라스트럭쳐를 사용할 수 있다. (symbol look-up, code completion 등) Clang은 또한 컴파일링 중에 보다 확장적으로 메타데이터를 만들거나 보전할 수 있다. 따라서 에러 보고에 훨씬 더 탁월하다. 가령 GCC라면 아래처럼 나온다.

문제가 뭔지 정확하지가 않다. C 프로그래밍에 초보라면 더욱 더 그러하다. 그렇다. 특히 이 문제를 WWDC에서 보셨다면, 무엇이 문제인지 아실 것이다. Clang이 만들어낸 이 에러에 대해 모두가 동의하지는 않으리라고 보지만, 도움이 되는 것만은 사실이다.

초보시라면 무엇을 할지 여전히 오리무중일 테지만, 적어도 문제가 뭔지는 확실해졌다. NSString을 컴파일러가 어째서 모르는지 알아내기가, GCC의 비밀스러운 에러에서 나오는 것보다 훨씬 더 집중화된 작업이다.

이 메시지가 확실할 때조차도, 그 컨텍스트는 그렇지 못할 수 있다. GCC는 이 에러를 이렇게 나타낸다.

단일 선상에 "+"가 네 개나 있다. 도대체 어느 것이 문제를 일으킬까? 보다 확장된 메타데이터덕분에 Clang은 문제가 무엇인지 집어낼 수 있다.

에러가 완벽하게 확실할 때도 있지만, 완벽하게 보일 뿐이다. GCC가 보고하는 에러로 뛰어들어가보면, 세미콜론을 더해야 할 곳으로 커서가 데려다준다.

GCC error message for missing semicolon

사소한 것도 중요하다. 아시겠는가? Clang은 한 발 더 나아간다.

Clang error message for missing semicolon

믿거나 말거나, 개발자들에게는 이런 것들이 대단히 중요하다. LLVM식 static analyzer가 들어간다면, 이런 작지만 중요한 것들의 의미가 더 커진다. 아래 이미지를 보면, static analyzer가 잠재적인 버그를 어떻게 표시하는지 나온다.

OH HAI I FOUND UR BUG

어지러운 화살표를 빼면(인정하시라. 이 화살표들은 사실 사랑스럽다), 실제 버그가 강조된다. 모든 프로그래머들이 더러운 편집을 통해 만들어내기를 상상하는 식으로 강조되는 것이다. static analyzer는 여기서, myName 변수를 초기화시키지 않게 하는 조건집합을 통한 경로가 최소한 한 가지가 있다고 판단하였다. 따라서 마지막 선의 mutableCopy 메시지를 보내려고 시도할 경우, 잠재적으로 위험해질 수 있다.

애플이 운영체제 자신과 모든 애플 애플리케이션을 static analyzer로 돌려보고 있으리라 확신한다. 수 년동안 코드 깊숙이 존재했을지 모를 버그를 발견할 자동화된 방법이기 때문이다. 개발자-플랫폼 소유자에게는 거의 포르노와 마찬가지다. 맥오에스텐 10.6은 10.x.0보다 훨씬 버그가 없는데, LLVM이 여기서 큰 역할을 하였으리라고 본다.

Master of the house

Clang/LLVM의 미래에 몸을 맡긴 애플은 마침내 개발 플랫폼을 완전히 통제할 수 있게 되었다. CodeWarrior의 경험때문인지, 플랫폼 개발툴을 써드파티에 맡기지 않는 편이 낫다고 확신한 것으로 보인다. 수 년이 걸리기는 했지만, 이제는 제일 극렬한 Metrowerks 팬이더라도, 스노레퍼드의 엑스코드가 꽤 좋은 IDE라는 점에 동의하리라고 생각한다.

GCC 프로젝트의 목표와 애플이 필요로 하는 컴파일러의 목표 사이에서 수 년을 노력한 끝에, 애플은 마침내 앞치마 끈을 잘라냈다. 좋다. 그럴만하다. GCC 4.2가 스노레퍼드에서 여전히 기본 컴파일러이기는 하지만, 이제는 이주시기이다. Clang이 권장 컴파일러이며, 애플의 미래 노력은 모두 Clang에 집중되어있다.

가슴이 복받쳐 오르지 않나? 하지만 트랜지스터가 확장되는 이 때에, 이런 컴파일러가 얼마나 더 도움이 될지 모르겠다 여기실 것이다. 다음 장이 바로 그 내용이다. LLVM의 규모성 있는 금속성의 본체가 주요 장소에서 등장한다.

http://arstechnica.com/apple/reviews...s-x-10-6.ars/9