Trade Show Remote: Jaguar snarls through WWDC
---------------------------------------------

**Mac OS X update far more than bug fixes**

일 주일 전, WWDC 2002 기조 연설에서, 애플 CEO, 스티브 잡스는 차세대 맥 오에스 텐의 프리-알파 프리뷰를 선보였다. 코드 네임은 "재규어"로서, 애플은 공식 석상에서 이를 "맥 오에스 텐 10.2"로 표현한 바가 전혀 없으며, "여름 하반기" 출하(여름 하반기는 9월 근처를 가리킨다)할 때 다른 버전을 선택할 지도 모른다. 하지만 현재 프리-알파 빌드는 실제 버전에 상관없이 10.2로 갖춰졌다. 숫자에 상관말고, 재규어가 갖는 큰 업데이트는, 파인더와 퀵타임, 주소록, 그리고 특히 애플리케이션과 네트워킹이다.

잡스는 연설을 맥 오에스 9에 대한 추도사와 장송곡으로 시작했다. 이윽고 무대 위에 맥 오에스 9 상자가 들어간 관이 나왔다. "소비자들에게 맥 오에스 9는 죽지 않았습니다만, 여러분에게 있어서는 죽었습니다." 여러분은 모두 이번 일 주일간의 WWDC 참석을 위해 1300 달러 정도를 지불한 개발자들이었다. "맥 오에스 9는 오에스 텐이라는 차세대 오에스로 살아남을 것입니다." 개발자들의 박수가 이어졌다. 맥센트럴은 이부분을 기조 연설 "생방송"으로 보였었지만 연설 이후에는 이 링크를 없애고 좀더 잘 짜여진 필립 마이클(Phiplip Michaels)과 피터 코헨(Peter Cohen)의 기사로 바꾸었다. MacNN은 단순한 기조 연설 스케치로 기사를 올렸다.

개발자들은 애플이 원하는 바 이상으로 맥 오에스 9를 다뤄야하지만, 재규어의 기능이 더 많은 사용자들과 개발자들을 끌 것이다.

애플이 재규어 프리뷰를 선보인 리스테에서는 아홉 가지의 주요 기능이 나와있으며, 이중 다섯 가지는 직접, 간접적으로 인터넷 메시지와 메일, 웹 서비스, 확장된 주소록, 향상된 메일 애플리케이션과 관련있다. 어떻게보면, 몇 년 전부터 나오던 인터넷 관련 기술들은 여전히 시장에서 "차세대"로 불리고 있기도하다. 이번주, 본지는 사용자와 개발자들에게 안겨다주는 충격을 상세히 다루도록 하겠다.


**Sherlock 3**

셜록은 맥 오에스 8.5에서 처음 등장했으며, 매킨토시 사용자들에게 막강한 파일/인터넷 검색 기능을 제공하였다. 파일에 있어서 셜록은 내용으로 찾기를 추가하였고(여기엔 애플 인포메이션 억세스 툴킷의 검색 엔진이 이용됐음으며, 코드네임은 "V-Twin"이었다), 인터넷에 있어서는, 단순한 텍스트 파일이 관련되는 어떠한 사이트도 찾아낼 수 있었다. 더해서 수 천개의 셜록 플러그인이 1998년 말에 등장했으며, 광범위한 결과물을 얻기 위한 다수의 검색 엔진 이용은 셜록으로 대체됐다.

1999년 맥 오에스 9가 출하되기 전까지 셜록에 대한 불만은, 플러그인 그룹화의 어려움과 한 번에 몇 개의 플러그인만을 찾는 것이었다. 애플은 이를 인정하고 플러그인을 "채널"로 그룹화하게 했지만 이 기능을 옵션으로 하진 않았다. 장점으로는, 새로운 종류의 플러그인으로 제품과 뉴스를 찾기 쉽도록 하였다. 단점으로는, 강요된 "채널" 인터페이스로 한 번에 모든 플러그인을 찾을 수는 없었다. 즉, 보통의 검색 엔진과 정보를 위한 제품 사이트를 보려면, 두 번은 검색해야함을 뜻했다.

더우기, 애플은 애플이 승인한 플러그인 말고는 "부적절한" 광고를 없애버렸다. 대다수의 검색 엔진과 웹 사이트는 광고를 유치하건만 셜록은 이를 허용하지 않았기에, 더 쉽고 저렴하게 이들 웹을 검색할 수 있도록 도운 꼴이었다. 애플은 셜록을 계속 자라나기만 하는 다중 검색 툴에서, 사용자에게 더 어필하는 진기한 툴로 탈바꿈시켰지만, 메탈 인터페이스를 가지고 있었다.

애플이 선보인 셜록 3은 셜록 2보다는 카렐리아(Karelia) 소프트웨어 사의 뛰어난 코코아-기반의 인터페이스인 왓슨에 가깝다. 웹 서비스가 셜록-기반의 플러그인의 다음 세대라고 주장할 수 있다. HTML 아웃풋을 내는 대신, 웹 서비스는 HTTP 서버로부터 즉정한 정보를 위해 직접 퀴어리를 허용하여 XML 포맷으로 되돌린다. 즉 8K에 해당되는 테이블과 광고를 HTML로 보는 대신, 500 바이트면 충분한 XML로 볼 수 있다는 것이다.

셜록 3은 바로 이 기능을 채택했다. 애플이 "새 버전" 페이지(메인 셜록 페이지도 아니고, 셜록 개발자 페이지도 아니다)의 스크린샷을 보면 셜록 3은 완전한 지도와 단계별 방향을 포함한 마운틴 뷰(캘리포이나에 있다) 시청으로 향하는 방향과 "출력" 버튼을 보여주고 있다. "인터넷"과 영화, 그림(사진), 옐로우 페이지, 뉴스, 주식, 운항표, 짐 트랙킹, 디렉토리 검색, 번역, 애플케어(애플 놀리지 베이스를 의미한다), 등의 플러그인이 있으며, 사실 왓슨을 이용하면 지금도 사용할 수 있다.

셜록 3은 웹 서비스 애플리케이션이다. 파일 검색은 셜록에서 제거되어서 파인더로 들어갔으며, 드디어, 파인더가 실제로 어떤 것을 "찾는 것"은 아니라는 지난 18년 동안의 농담을 이젠 하지 못하게 됐다(시스템 7의 파인더는 실제로 "찾기" 명령이 있었지만, 윈도우 안에서 찾은 파일의 선택된 결과만을 보여주었고, 필요한 경우 하드 드라이브를 리스트화해서 보여주었다. 별로 유명하지 않은 기능이다). 사실, 재규어에서의 파인더는 윈도우 툴바에서 검색 필드를 허용하기 때문에, 파일 이름을 어떤 윈도우 내에서도 찾을 수 있다. 바로, 재규어 페이지에서 애플이 선전한 빠른 찾기(Fast Find) 기능이다. 좀더 진보적인 검색은 "Advanced Find"라고 불리는 대화상자를 요구한다.

따라서, 셜록은 웹 서비스에 집중한다. 다중-엔진 검색 유틸리티로서는 급격한 변화이다. 셜록 3이(애플은 밝히지 않았지만) 확장 가능하다면, 플러그-인은 분명 실제적인 코드를 원할 것이다. 데모를 보면, 커스텀 휴먼 인터페이스가 각 웹 서비스마다 있었으며, 이는 코드를 포함하지 않는 플러그인으로는 어려운 일이다. 왓슨은 써드 파티 익스텐션을 허용하지만, 코코아로 작성됐어야 한다는 제약이 있다. 개발자가 코드를 더할 수 있거나 자동적으로 업데이트하도록 조정되어있다면, 이는 보안 문제를 야기할 수 있다.

기본적으로 셜록 3은 셜록이라기보다는 왓슨의 제구현에 가깝다. 이제는 주식이나 정보를 얻기 위해 인터넷을 "검색"하는 것이 아니라, 이런 서비스가 가능한 페이지를 가는 것이다. WWDC에서 왓슨의 저자인 댄 우드(Dan Wood)는 애플의 WWDC 사진 갤러리에도 실렸다. 애플이 자신의 프로그램과 경쟁하자는 것일까? 우드의 말이다. "애플로부터 왓슨을 매입하겠다는 접근은 없었습니다. 왓슨은 애플과는 무관한 프로그램입니다." 그는 WWDC 세션은 비공개였기 때문에 셜록 3에 대한 코멘트를 할 수 없다고 말했다.

진정 유용한 아이디어를 기껏 개발해놓으면 애플이 이를 시스템에 포함시켜버린다는 관행이 처음은 아니다. 하지만 단지 다소 나을 뿐인 셜록이 나온 이래로 매킨토시용 다중 검색-엔진 유틸리티들은 대부분 사장됐다. 앞으로 재규어의 파인더가 파일 권한이나 다른 메타데이터를 바꾸는 법을 기본제공하면, "더 많은 정보"를 제공하는 다른 유틸리티딜도 같은 운명을 걷게될 것이다. 애플은 이렇게 작은 유틸리티인 셜록에서부터, 중간 정도의 프로그램인 아이튠즈, 대형 애플리케이션인 파이널 컷 프로에 이르기까지 경쟁에서 물러서지 않는 경향을 보인다. 전쟁인 셈이다.


**Rendezvous**

IP-기반의 네트워킹을 달리보면 애플토크의 확장에 다를 바 없다. 하지만 IP 네트워킹은 더 빠르고(더 큰 패킷 사이즈를 이용한다), 소규모 로컬 네트웍에서 인터넷이라는 대규모 네트웍에 이르는 연결을 허용하고, 네트워크의 유지에 더 적은 패킷이 필요할 뿐이며, 애플톡 이상의 다양한 컴퓨터와 디바이스에 쓰인다. 물론 애플톡은 더 친밀하다는 장점이 있다. 애플톡 네트웍을 만드려면, 다중의 컴퓨터를 이더넷에 연결만 하면 된다. DHCP 서버도 필요없고, DNS 설정 절차도 필요 없다. 어떠한 설정도 필요 없는 것이다. 컴퓨터 자신이 다른 디바이스를 인식하고, 서비스를 제공하기 시작한다. 맥 오에스와 맥 오에스 텐도 애플톡이 연결될 때를 김지해낸다.

이제까지, 애플은 IP 네트워킹이 애플톡만큼 쉬워지길 원했지만, 전혀 진전이 없었다. 애플은 애플 닷컴과 같은 하이레벨 도메인이나 주어진 서브넷에서 웹 서버나 파일 서버와 같은 네트워크 서비스를 발견해내는 DNS나, SLP와 같은 프로토콜을 이용하는, "네트워크"의 네비게이션 서비스 대화 상자를 맥 오에스 8.5에서부터 지원했다. (.com과 같은 최상위 레벨 도메인의 모든 웹서버를 요구하진 말기 바란다. 그러기에 여러분 맥의 램은 터무니없이 부족할 것이다.)

네트워크 서비스 로케이터는 모든 컴퓨터가 SLP(Service locator protocol)이나 특정 DNS 익스텐션(DNS 서비스 디스커버리라고 불린다) 네트웍 상에 있는 것을 요구한다. 만약 찾기 원하는 웹서버가 이 프로토콜을 다루지 않는다면, NSL(네트워크 서비스 로케이터)은 나타나지 않는다. 즉, 설정을 요구하는 문제는 대동소이한 것이다. 특정 DNS 리코드를 유지해야하거나, 혹은 SLP 구현이 각 컴퓨터마다 올바르게 구성되어있어야하는 것이다. 맥 오에스 8.5 이후 버전에서는, 파일 공유가 SLP를 올바르게 이용해서 여러분의 컴퓨터가 파일 공유 서비스를 가지고 있으며, 그렇기 때문에 네트웍을 보기 위해 NSL를 사용할 경우 파일 공유 서버 이상을 찾지 못할 것이라고 경고하고 있다.

자, 애플이 원하는 것이 애플톡의 특징인, 무설정은 아니다. 윈도우즈 98 이후 버전과 맥 오에스 8.5 이후 버전은 이미 이런 기능을 내장하고 있다. 컴퓨터에게 TCP/IP를 통한 연결을 요구하면서 DHCP 서버를 불러들이려 하는데 만약 DHCP 서버가 없으면 어떻게 되는가? 두 오퍼레이팅 시스템 모두 하위넷 마스크 255.255.0.0에 169.254.1.0에서 169.254.254.255에 이르는 범위의 IP를 취한다.

이러한 자동 설정이 인터넷의 연결을 해주진 못하며, DNS 기반의 서비스도 허용하진 않지만, 로컬 허브 내에서의 IP에 따른 교환을 할 수 있게 해준다. 즉, 위의 IP 주소를 가진 한, 같은 네트웍 상의 같은 범위의 IP를 가진 컴퓨터끼리 통신이 가능한 것이다. 애플의 스튜어트 체셔(Stuart Cheshire)와 마이크로소프트의 버나드 어보바(Bernard Aboba)가 여기에 대해 IETF(Internet Engineering Task Force) 문서로 지난달 상세하게 설명해놓았다.

체셔는 또한 썬 독일 지사의 에릭 구트만(Erik Guttman)과 함께, IETF의 제로 컨피규레이션 네트워킹 워킹 그룹(Zero Configuration Networking Group)을 이끌고 있기도 하다. (이 그룹은 Zeroconf로 알려져있다) 이 그룹은 모든 IP 네트워킹이 애플톡만큼 쉬워지는 것을 목표로 하고 있다. 이문제는 사용상의 문제 뿐만이 아니다. 만약 네트웍 인터페이스가 자신을 설정할 수 있다면 이 정보는 ROM이나, 준-ROM 기기에 들어가야한다. 네트웍화된 기기나 심지어는 아이폿도 문제의 소지가 있는 것이다.

구트만은 IEEE에 제로콘프를 위해 네 가지의 서비스가 필요하다 는 기사를 썼다. DHCP가 없어도 주소를 할당하는 것은 이미 윈도우즈와 맥 오에스에 내장됐으며, 공식 스펙으로 하는 작업이 진행중이다. DNS 서버 없이 IP 주소에 이름을 전송하기 위해서 제로콘프는 멀티캐스트 DNS를 제안한다. 이름을 갖는 로컬 서비스 검색을 원하는 모든 컴퓨터가 로컬 링크를 통해 브로드캐스팅을 하는 것이다. 네트웍 상에서 프린터와 같은 서비스를 찾는 것은 맥 오에스에서처럼, SLP나 DNS 익스텐션으로 이관하며, 멀티캐스트 주소를 MADCAP 서버 없이 지정하는 것은 제로콘프 멀티캐스트 어드레스 얼로케이션 프로토콜(ZMMAP)로 한다.


**Making a Rendezvous** --

하지만 IP의 문제점이 이미 존재한다. 맥 오에스나 윈도우즈에서, 위 169.254.X 범위의 IP 주소는 DHCP 서버가 발견될 때까지만 작동되며, DHCP 서버를 발견하면, 즉각 "실제" 설정을 공급한다. 제로콘프 워킹 그룹은 현재 스스로 설정하는 IP 주소가 DHCP가 지정하는 주소에 더해서 유지될 수 있어야함을 권유하고 있다.

IP 주소의 재설정은 서버에도 문제가 될 소지가 있으며, OS는 서버가 돌아가고 있는 지 돌아가고 있는 지 모르는 상태이에 있기 때문에 여기서도 주의가 필요하다. 만약 OS가 같은 인터페이스(이를테면 단일 이더넷 포트)에서 두 개의 IP 주소를 유지할 수 없다면, DHCP가 가능해졌을 때 인터넷 접속을 위해 네트웍을 재설정하거나, 재시동해야한다. 더 복잡해질 수도 있는 것이다.

재규어에서, 애플은 이 모든 프로토콜을 랑데부(Rendezvous) 콜렉션으로 지원한다. 애플은 별도의 매킨토시에 있는 MP3를, 스트리밍으로 네트웍 자동 설정을 통해 재생시키는, 출하되지 않은 아이튠즈를 선보였다. 매우 멋진 기능이다. 만약 다른 컴퓨터로부터 파일을 스트리밍할 수 있는 아이튠즈를 원한다면 지금도 그럴 수 있다. 올바르게 TCP/IP만 설정되어있다면, 현재의 아이튠즈도 그런 일을 할 수 있다. 애플의 주안점은 랑데부이며, 심지어는 에어포트만 있는 네트워크라 하더라도 돌릴 수 있다는 것을 보여준 것이다.

애플은 모든 공개 인터넷 표준을 맞추리라고 말했지만, 이들 프로토콜은 이미 표준화 과정에 들어가 있으며, 공개 인터넷 표준은 아마도 다윈의 한 부분으로서 오픈소스화 시킬 것임을 나타낸 것 같다. 제로콘프를 애플이 가지거나 선전할 수 있는 이름으로 바꾸는 것이 최고의 아이디어는 아니다. 사실 애플은 소니나 파나소닉이 "파이어와이어"의 사용을 막았기 때문에 이들 회사는 "i.Link"라는 다른 이름을 택할 수 밖에 없었고, 때문에 대다수의 소비자들은 파이어와이어와 아이링크가 같은 것임을 모르고 있는 형편이다.

사실, 이번달에 애플은 마침내 "파이어와이어" 이름과 로고를 하나의 브랜드 이름으로서 1394 트레이드 협회에 라이센스하였다. 애플은 자사 제품에서만 파이어와이어를 언급했으며, 소니에게는 파이어와이어 아이콘과 이름을 사용하는 데에 로열티를 요구하였었다(물론 소니는 이를 지불하려하지 않았다). 마침내 애플의 이름 고집이 가치가 없었음이 드러난 것이다. "랑데부"에도 똑같은 일이 일어나지 않기를 희망해보자.

이름이 무엇이건 간에, 랑데부는 득이면 득이지, 실은 아니다. 만약 애플톡을 이용해서 다중 네트웍을 연결하고자 한다면, 누군가는 라우터를 설치해서 설정해놓아야한다. 비슷하게, 만약 인터넷에 연결하고 싶다는 의도라면 랑데부가 도움이 되진 못한다. 여전히 설정이 필요한 네트웍 억세스가 있어야한다. 다행히도, 랑데부는 더 많은 프린터 제조업체와 SLP를 구현하고자 하는 서버 소프트웨어 업자들에게 다가설 것으로 보인다. 애플만의 SLP 구현은 당연히 충분하지 않다.

랑데부는 작으면서 지역적인 네트웍 설정에 사용된 애플톡과 비슷하게 돌아가며, 광범위한 네트웍엔 적합하지 않다. 만약 차세대 야후를 기대했다면 우선 네트웍 설정부터 하시라.


**iChat**

이번에 크게 관심을 가진 기능은 아메리카 온라인 인스턴트 메시지 프로토콜에 기반하여 재규어에 내장된 바로 아이챗이며, 자신만의 프레스 릴리즈를 갖고 있다. 현재 AOL의 모든 프로토콜을 이용하는 채팅 애플리케이션은 AOL 인스턴트 메신저만이 유일하다(혹은 AIM). 이전의 AOL 프로토콜을 이용하는 써드 파티 소프트웨어도 있지만 현재, AOL이 프로토콜을 공개하여 리눅스 클라이언트도 작성할 수 있도록 하리라는 기대가 있었다.

이 프로토콜이 AIM 최신 기능-파일 전송, 직렬 메시지, 그룹 채팅, 프라이버시 등-을 지원하진 않는다. AOL이 써드 파티가 사용할 여지를 막고 있기 때문이다. 따라서 이제까지 전체 AOL 서비스를 모두 구현할 수 있는 소프트웨어는 AIM이 유일했다. 아이챗이 나오기 전까지 말이다.

잡스는 WWDC 참석자들에게 아이챗이 AOL 소프트웨어와 "같은 기반을 갖는(under the tent)" 첫 번째 프로그램이라고 소개하였다. 조그마한 스크린샷에서, 아이챗은 브러쉬드-메탈 인터페이스와 대화형의 메타포어를 가지고 있다. "버디 아이콘"이 대화 옆에 나타나며, 대화는 마치 만화책을 방불케 한다.

아이챗은 현존하는 모든 AIM-호환 스크린 네임(AOL 계정, 혹은 AIM만의 이름)을 지원하며, 아이툴즈 계정도 지원한다. 애플은 분명히 여러분들이 아이툴즈 계정을 이용하기 원하고 있으며, 아이챗이 AOL의 스크린 네임과 호환된다는 언급조차 하지 않았다. 사실 아이챗을 기다릴 필요도 없다. 당장, 아이툴즈 이 메일 계정과 암호로 AIM에 로그온해보라(이를테면 sjobs@mac.com으로). 애플이나 AOL 그 누구도 아이툴즈 계정 정보를 공유하고 있다고 발표하지 않았지만, 이렇게 해도 즉시 AIM에 로그해서 들어갈 수 있다. 어쩌면, 애플의 컴퓨터로만이 이렇게 로그인할 수 있는지도 모르지만 확인해보지 못하였다.

만약 아이챗이 그저 또다른 AIM 클라이언트라면, 전혀 주목할만한 사실도 아니었을 것이다. 하지만 아이챗을 돋보이게하는 부분은 재규어와의 통합성이다. 메일 애플리케이션이 아이챗 버디의 상태를 알려주면서, 이메일 대신 인스턴트 메시지 사용을 하게 해주는 선택을 제공하며, 아이챗은 시스템-전반에 걸쳐서 주소록에 다른 정보는 물론 버디의 이름과 사진을 저장하게 한다. 아이챗 자신이 애플의 새로운 랑데부 IP 디스커버리를 이용해서 로컬 네트웍에서 다른 아이챗 사용자를 발견하기도 한다.

하지만 아직 아이챗은 완성과는 거리가 멀며, 흥미로운 텍스트 색상을 제공하고 있다. 그러나 복사본 저장도 잘 못하는 프리-알파 버전이기 때문에 WWDC에서 나온 아이챗을 평가하는 데에는 무리가 있다.


**Mail application**

애플이 카렐리아 소프트웨어와의 경쟁을 불사하는 것처럼, 맥 오에스 텐의 메일 클라이언트에도 수많은 향상이 있었다. 재규어 이전까지, 메일 프로그램은 기본적이었으며, 그런데로 사용할만한 기능들 뿐이엇다. POP3과 IMAP4 프로토콜을 지원했으며, 아이툴즈와 맥닷컴 서버와 함께 운용되었다. 코코아 핸들링 텍스트와 새로운 인터페이스가 있었으며, 맥 오에스 텐 독 상에서 정보를 표시할 수 있었다. 즉, 특별히 다른 기능을 보일 필요 없이 메일은 맥 오에스 텐과 조화롭게 돌아갔다.

재규어는 이점을 바꾸었다. 애플은 스팸 메일의 판별을 위해 기호 식별 기반의 필터를 추가했다. 즉, "advanced semantic inference engine"을 택함은 곧 스팸 구조를 실제적으로 이해한다는 뜻이다. 애플에 따르면, 메일은 이미 이 포맷을 알고 있으며, 전형적인 스팸 편지의 내용 또한 알고 있으며, 여러분이 정크 메일이라고 판별하는 것에 대한 학습 효과도 있다. 따라서 실제 내용에 따라, 주소 거부와 같은 형태로 스팸 메일을 막는 것이다. 이 엔진에 대한 세부 사항은 아직 나오지 않았지만, 시스템 프레임웍이라기보다는 메일에 특화된 것으로 보인다.

그게 다가 아니다. 메일은 그동안의 소비자 불만 사항이었기도 한 데, 메일은 메시지를 보내지 않으면 드라프트에 저장해놓았다가, 메일을 다시 열었을 때 이를 연다. 여기에 메일의 룰, 필터는 더 많은 선택 사항과 다중의 기준을 마련하였다. 가령 새로운 메일 애플리케이션은 다중 주소로의 메일인가를 판별하거나, 미리 지정한 송신자가 보낸 것인 지, 아니면 "광고"와 같은 내용이 담겨져있는 지도 판별해낸다(잡스에 따르면 "최고의 기능"이다). 또한 모든 메일박스를 검색할 수 있으며, 내용 기반의 검색을 위해 V-Twin을 이용하여 인덱스화시킨다.

만약 메일박스가 단일하다면 재규어의 메일은 모든 메시지를 단일 메일박스에 저장하며, 색상별로 쓰레드를 추적한다. 메시지 윈도우 내에서 퀵타임 미디어를 재생할 수도 있으며 CRAM-MD5와 같은 현대 이메일 보안 프로토콜과 SSL, 마이크로소프트 아웃룩을 위한 "더 나아진" 지원도 포함하고 있다. 하지만 대부분에 대한 정보가 아직은 빈약하다.

따라서 이러한 "진보적인" 기능들을 뭐라 하기에는 아직 이르다. 당연히 모든 맥 오에스 텐용 상용 메일 클라이언트들은 위 기능들 이상을 지원하고 있으며, 파워메일같은 경우에는 프리-인덱스 내용 검색마저 이미 지원하고 있다. 더구나 메일은 아직 유도라만큼 세세한 설정을 지원하지 못하고 있으며, 메일스미쓰와 같은 텍스트 핸들링, 앙투라쥬와 같은 통합 스케쥴링에 대한 지원도 없다.

물론 모든 써드 파티 애플리케이션과 한 번에 대적하려 함은 아닐 것이다. 그저 맥 오에스 텐과 코코아 기술을 선보이고 기본적인 메일 기능을 덧붙인 것에 불과할 수도 있다. 애플은 맥 오에스 8 이후 버전에 마이크로소프트 아웃룩 익스프레스를 번들 출하한 경험이 있지만, 코코아의 메일 프로그램을 애플이 맥 오에스 텐에 포함시키고, 앙투라쥬를 오피스의 부분으로 포함시키면서 마이크로소프트는 아웃룩 익스프레스를 맥 오에스 텐용으로 개발할 흥미를 잃어버렸다.

메일이 유도라나 메일스미쓰, 앙투라쥬와 비교하기에는 아직 멀었지만, 지적한 바 대로 맥 오에스 텐과는 제일 잘 어울리는 메일러임에는 틀림없다. 메일은 아이챗 버디가 온라인에 있는 지도 알아내며, 이런 API들이 다른 프로그램에도 알려진다면 상황은 좋아질 것이다. 만약 애플 사용자들이 잘 작성된 메일 클라이언트 사용을 관두고 애플이 그런 기능을 공개하지 않는다면, 이는 더 큰 문제이다. 애플은 아직 메일과 OS에서의 프라이빗한 부분과의 연관성에 대해 발표하지 않고있다.

아이튠즈와 파인더가 사용하는 디스크버너와 같은 프레임웍이 공개되지 않은 이유 중에 하나는 모든 애플리케이션이 옵티컬 미디어를 구워야할 필요성이 없기 때문이다. 하지만, 그렇게 비공개로 함으로써 애플은 공개용 CD 제조 프레임웍을 내놓지 않았기 때문에 정확한 드라이브 컨트롤이 필요한 토스트나 레트로스펙트, 그 외 자신만의 디스크를 작성하는 음악 재생기나 파일 유틸리티들에겐 안좋은 소식일 수 밖에 없다.

문서화와 지원은 어려울 뿐만 아니라, 비용도 많이 든다. 하지만 공개하라는 여론도 없기 때문에 애플로서는 디스크버너 프레임웍을 써드 파티 프로그램에 굳이 내놓아야할 동기가 없다. 메일도 그러할까? 수만 개 이상의 프로그램들이 인터넷과 인스턴트 메시징에 초점을 맞추고 있는 현재, 메일은 디스크버너와는 분명히 다르다. 만약 재규어의 내장 애플리케이션이 아이챗의 모든 컨트롤을 맡으면서 써드 파티 애플리케이션에게 프레임웍을 공개하지 않는다면, 개발자들에게 심각한 타격으로 돌아올 것이다.

하지만 우린 낙관적이다. 재규어에서 애플은 마침내 디스크버너를 써드 파티 개발자들에게 공개하였다. 전체 WWDC 세션에서 애플은 디스크리코딩 API를 선보였다. 아직은 메일의 새로운 기능에 대한 세세한 사항이 안나왔지만 애플이 올바른 생각을 갖고 있는 듯 하다.


**Address Book**

같은 주제이다. 맥 오에스 텐 10.1에서 제한적이고 별로 유용하지도 않았던 주소록을 재규어는 시스템 핵심 컴퍼넌트의 한 부분으로 통합시켰다. 현재 맥 오에스 텐에서, 주소록은 거의 메일 애플리케이션만이 사용하는 스탠드-얼론 애플리케이션이며, 24개의 필드에 AIM이나 Jabber 주소, 커스텀 필드도 지원한다. 여기에 주소를 추가하려면 표준 vCard 파일(아이폿이 "콘택트" 기능으로 사용하는 종류와 같다)에서 드래그 앤 드롭하거나 수동으로 작성할 수 밖에 없으며, 출력도 없고, 추출도 없다. 싱크로나이즈 또한 없으며 그저 주소를 저장하고, 메일로 보내는 류의 일밖에는 못한다.

하지만 재규어에서의 주소록은 시스템 서비스 이상이다. 이제 주소록은 콘택트의 사진을 지원하면서 이 사진이 아이챗의 버디 아이콘으로 뜨게 한다. 또한 재규어의 블루투쓰 지원과 합체되어, caller ID를 수행한다. 즉, 핸드폰이 컴퓨터에게 누가 걸고 있는 지를 블루투쓰를 통해서 알려줄 수 있다. 그러면 주소록은 여기에 연동되어서 그사람이 누구인지 주소록에서 찾아내준다. 재규어의 주소록은 역시 블루투쓰를 이용하여 휴대폰을 통해 SMS를 보내거나 전화를 걸게 할 수도 있다. 이런 식의 시스템 활동이 모뎀에서도 똑같이 적용되는 지는 아직 알려지지 않았다.

이 모든 기능은 재규어가 주소록 프레임웍을 갖고 있기 때문에 가능해졌다. 맥 오에스 텐에서 하나의 핵심 디스크 버닝 프레임웍을 아이튠즈와 파인더, 디스크카피가 이용하는 것처럼, 재규어의 주소록은 API를 통해 어떤 프로그램일 지라도 사용할 수 있도록 해놓았다. 따라서 아이챗의 버디 아이콘이나 메일과 아이챗의 주소록 공유가 가능해진 것이다. 그런데 메일과 아이챗의 주소 공유로 어떻게 버디가 온라인인 지 알려주는가에 대해서는 아직 알려지지 않고있다.

재규어에서, 주소록은 LDAP 퀴어리에 반응하며, 현재의 버전보다 더 나은 그룹 지원을 갖는다. 애플은 2002년 하반기까지 Palm OS와의 일체화를 약속한 바 있다. 좋은 소식은 다른 모든 애플리케이션들도 이를 이용할 수 있다는 것이다. 금요일 WWDC 세션에서 애플은 개발자들에게 주소록을 한 프로그램이 어떻게 억세스할 수 있는 지를 선보였다. 여기에서 이 프로그램은 주소록의 정보를 바꾸거나, 지울 수도 있었다. 개별 세션들은 비공개였기 때문에 자세한 사항은 당분간은 루머로만 떠돌 것이다.

하지만 역시 애플은 올바른 생각을 갖고 있었다. 이 프레임웍도 비공개가 아니기 때문에 콘택트 정보를 원하는 모든 프로그램이 이 기능을 구사할 수 있다. 안좋은 소식은 주소록이 막강한 콘택트 매니저는 아니며 시스템이 사용한다는 점 밖에 돋보이는 것이 없다는 소식이다. 이제 개발자들이 얼마나 이를 사제화시킬 것인 지만 남아있다. 주소록을 나우 콘택트나 앙투라쥬에서 다룬다고 생각해보라. 각 프로그램이 주소록 이상의 일을 해주면서 좀더 사제화된 필드를 제공한다고 생각해보라. "내가 주소록 데이터베이스가 있다면서 누가 나한테 누군가에 대해 묻더라구."라고 자랑하는 장면이 그려지지 않는가.

차이점은 중요하면서도 미묘하다. 이를테면, 주소록의 네이티브 포맷이 다른 시스템 서비스와 연동하여, 써드 파티 프로그램이 이를 대체할 수 없는 상황이 생길 수도 있다. 이런 식이라면, 주소록과 연동하는 프로그램이 시스템과 항상 데이터를 일치시켜야한다. 만약 앙투라쥬에 새로운 주소를 입력한다면, 누군가는 이를 다시 주소록에도 올려야하며 그렇지 않으면, 새 프레임웍을 사용하는 메일, 아이챗, 등 어떠한 프로그램에서도 이 주소를 사용할 수 없다는 얘기이다.

다른 시나리오도 있다. 다른 주소록 매니저를 사용할 때, 주소록 프레임웍이 이 데이터를 끄집어낸다면, 다른 모든 프로그램들은 주로 사용하는 컨택트 매니저와 똑같은 정보를 자동적으로 갖게될 것이다. 이런 방식에서는 앙투라쥬나 나우 콘택트, 팜 데스크탑이 자동적으로 일치된다는 뜻이다. 따라서 당분간 주소록을 사용하지 않더라도 데이터는 항상 최신을 유지하기 때문에 주소록 자체를 실행시키지 않아도 된다는 의미이기도 하다.

여기에서도 써드 파티와의 경쟁 문제가 대두된다. 팜이나 파워 온 소프트웨어와 경쟁하고픈 마음은 없을 것이지만, 시스템 전반에 걸친 주소록은 써드 파티 개발자들에게 있어서도 너무나 유용한 기능이다. 주소록 프레임웍으로 다른 애플리케이션이 상호 연동할 수 있지만, 이런 통합성이 써드 파티와 어느 정도로 이뤄질 지는 두고봐야할 일이다. 재규어에서 그 통합성이 기대 밖에더라도 실망하지 않기 바란다. 다음 버전에서는 더 향상될 것이다. 이런 기술들은 서로 영향을 미치면서 진화하게 마련이기 때문이다. 독 또한 완벽하지 않고, 파인더도 시작할 때부터 완성되진 않았다. 주소록도 마찬가지이다. 시스템 전반에 걸친 프레임웍은 그 의미가 어느 정도이냐를 따지기 이전에 그 자체가 향상이라고 말할 수 있다.


**QuickTime 6**

아직 MPEG-4 라이센스 논쟁이 타결되지 않았지만, 애플은 기조 연설중에 첫 번째이자, 대규모로 퀵타임 6을 시연하였다. 주요 기능은 지난 2월 선보였을 때 이후로 변한 것이 없었다. 특히 MP3의 계승자로서 더 우월한 음질과 더 낮은 비트레이트를 갖는 AAC 오디오도 선보여졌다.

기조연설 자체도 퀵타임 6의 프리-버퍼링을 제거하는 "Instant On" 스트리밍과 pre-existing 스트리밍 미디어의 "instant scrubbing"에 포함되었다. 현재 대부분의 스트리밍 미디어는 재생 시작 이전에 몇 초 정도의 데이터 버퍼링을 요구한다. 데이터 버퍼는 재생기가 전송에 차질이 있을 때에도 재생할 수 있기를 보장하지만, 생방송을 몇 초 후에나 보여준다는 약점 또한 가지고 있다. 이전 버전의 퀵타임은 더 낮은 비트레이트와 더 큰 버퍼를 이용한 "스킵 프로텍션"을 가지고 있었다. 가령, 56K 모뎀 연결 대신, 퀵타임은 33K의 연결을 하면서 더 큰 버퍼를 사용하는 식이었다. 따라서 좀더 많은 데이터를 한 번에 볼 수 있으며, 더 낮은 데이터 레이트덕분에, 기본 연결 사양도 낮아진다.

WWDC에서, 애플은 이전에는 보도가 안됐던, "인스턴트 온" 기능을 보여주었다. 자세한 사항은 나오지 않았지만, 클라이언트와 서버 양쪽 모두에 버퍼없이 스트리밍을 하게하는 옵션을 의미하는 것으로 보인다. 즉, 이경우 연결에 지장이 생기면 데이터 스트림에도 지장이 생기는 스킵 프로텍션이 아니다. 더 낮은 데이터 레이트와 결부된다면 스킵 프로텍션은 결국 버퍼를 만들게 되어있다. 현재 본지는 추측중이지만 당연히 수상식같은 생방송에서는 스킵을 안할 수 있는 선택을 주는 것이 합리적이다. 물론 물리 법칙의 존재 때문에 아직 일어나지 않은 이벤트를 퀵타임이 버퍼링할 수는 없는 노릇이지만 말이다.

"라이브 스크러빙"도 새로운 사실이다. 스크러빙은 재생 표시자를 가리키는 단어(퀵타임 플레이어나 아이튠즈에서의 다이아몬드)로서, 재생 지점을 순간적으로 바꿀 수 있는 가늠좌이기도 하다. 현재 버전의 퀵타임에서 스트리밍 무비를 스크러빙하면, 다시 몇 초간 데이터 버퍼링이 시작된다. 하지만 "인스턴트 온" 기능은 스크러빙을 순간에 이루도록 한다. 즉, 스크러빙을 하는 즉시 그 지점에서 스트리밍을 다시 시작하는 것이다. 기술적으로 0:00에서 스트림을 시작하는 것과 다른 지점에서 스트림을 시작하는 것이 별다르진 않다. 따라서, "인스턴트 온"과 "라이브 스크러빙"은 같은 말을 의미한다. 당연히 물리 법칙이 적용되기에, 생방송을 미리 볼 수는 없다.

월요일 WWDC 참석자들에게 발표된 재규어 프리뷰 릴리즈에는 퀵타임 6과 퀵타임 브로드캐스터가 내장되어있었다. 애플은 재규어와 퀵타임에서 상충되는 이해 관계를 갖고 있다. 개발자들의 이주를 쉽게 하기 위해서, 애플은 사용자들이 될 수 있는 한 빨리 맥 오에스 텐으로 이주하기를 바라지만, 퀵타임이 되도록이면 스트리밍과 저장 미디어 플랫폼으로서 널리 퍼지기 또한 바라고 있다. 만약 애플이 잡스말마따나, 맥 오에스 9에 대한 개발을 더이상 하지 않는다면, 퀵타임 6은 (본지의 추측에 따르면)여전히 맥 오에스 9를 사용하는 90%의 매킨토시를 기만하는 꼴이 되버린다. 퀵타임 6이 WWDC 이전에 발표됐기 때문에, 만약 애플이 퀵타임을 재규어만의 기술로 만들어버리는 우린 아마 상당한 충격을 받을 것이다. 애플에게는 퀵타임이 시장을 점유하기를 바란다. 물론 퀵타임 7 대에 이르러서는 다른 얘기가 될 터이다.

위민복님의 글입니다.
http://casaubon.tv
* kmug님에 의해서 게시물 이동되었습니다 (2002-05-23 18:48)