애플은 OS X의 그래픽스 시스템으로 쿼츠(Quartz)라는 새로운 시스템을 선보였습니다. 쿼츠는 이전의 퀵드로우(QuickDraw)보다 훨씬 더 풍부한 그래픽을 가능케 해줄 것입니다.

물론 퀵드로우는 여전히 맥 애플리케이션들 그리고 예전의 애플리케이션들을 (카본을 통해) 지원할 것입니다. 하지만 미래에는 쿼츠가 보다 더 풍부한 성능을 앞세우며 퀵드로우를 대체하게 될 것입니다.

그래픽스의 역사

제록스 PARC의 쟌 워녹, 마틴 뉴월, 그리고 쳑 게스크.
이 세 사람은 잼(JAM)이라 명명된 페이지기술언어(Page Discription Language) 연구를 시작했었습니다. 이 언어는 어떤 페이지 상에 있는 그래픽 이미지를 플랫폼이나 해상도에 상관없이 기술해 줄 목적으로 개발되었습니다. 나중에 워녹과 게스크씨는 PARC를 박차고 나와 어도비(Adobe)社를 세우게 됩니다. 그리고 이들이 개발한 언어는 포스트스크립트(PostScript)로 발전되어 나가게 됩니다.

사실 제프 레스킨(Jef Raskin)씨는 이미 60년대 후반에 퀵드로우에 관한 논문을 발표하기도 했습니다. 그것은 JAM과 무척 유사했지만, CRT 화면 상의 이미지를 다루는 것이었습니다. 제프 레스킨은 그 뒤 애플로 갑니다. 얼마 뒤 빌 앳킨슨(Bill Atkinson)씨는 퀵드로우를 맥 그래픽 시스템의 기반으로 완성해 냅니다. (처음에는 리자(Lisa) 에 쓰일 그래픽 엔진으로 LisaGraf를 만들었고, 여기에 여러가지 자신의 아이디어를 덧붙여 퀵드로우로 완성해 낸 것입니다)

퀵드로우는 훌륭했습니다.
파워풀했고, 빨랐습니다.
하지만 퀵드로우는 72-75 DPI 흑백 스크린을 위해 만들어진 것이었습니다.
물론 보다 더 높은 해상도(그리고 8색 컬러)를 더 큰 디스플레이상에서 구현할 능력이 있기는 했지만요.

퀵드로우는, 퀵드로우가 완성되었던 1982년에서 1983년까지 훌륭히 자기 역할을 해냅니다. 하지만 애플이 300 DPI 이상의 레이져 프린터 쪽에 관심을 가지면서부터 퀵드로우의 단점이 하나 둘 드러납니다. 이에 애플은 독자적으로 디바이스 독립적인 프린터기술언어를 개발하려다가 (이름이 퀵스크립트(QuickScript)였습니다) 어도비가 프린터기술언어를 개발하는 것에 투자하는 쪽으로 선회하게 됩니다.

어도비와 애플의 그 계약은 괜챦은 결합이었습니다. 왜냐하면 퀵드로우는 화면상에서 보다 더 뛰어난 성능을 보여줬고 포스트스크립트는 고해상도 프린터 쪽으로 특화된 기술이었으니까요. 그리고 이 둘 사이의 변환은 충분히 감당할 만한 수준이었습니다.

얼마 뒤 애플은 컬러 퀵드로우를 개발하는 데 착수 합니다. 포스트스크립트와 오리지널 퀵드로우는 상당히 흑백쪽으로 치우친 기술이었습니다. (물론 컬러 사용을 위한 몇가지 확장성은 있긴 했었습니다.) 애플은 퀵드로우를 컬러를 다룰 수 있게 확장해 나갔고 곧 32비트 컬러(수백만 컬러로 사진 수준의 사실감을 표현할 수 있는)를 다룰 수 있게 되었습니다. 포스트스크립트 쪽이 이런 성능을 갖추는 데는 보다 더 오랜 시간이 걸립니다.

그러다가 1980년대 후반 스티브 잡스는 애플을 그만두고 나가서 넥스트(NeXT)를 설립하게 됩니다. 넥스트는 좋은 이미징 시스템을 필요로 했고 스크린과 프린터 양자 모두에서 사용될 수 있는 디스플레이 엔진을 원했습니다. 하지만 넥스트는 독자적으로 그런 것을 만들 시간이나 자금이 없었기 때문에 그리고 그들은 하이엔드 웍스테이션 쪽을 뚫어 보려고 했기 때문에 어도비와 손잡고 디스플레이 포스트스크립트(DPS, Display PostScript)를 개발합니다. 하이엔드 웍스테이션 쪽은 라이센스 비용을 더 저렴하게 해결할 수 있었기 때문입니다.

DPS는 프린터나 스크린 양쪽 모두에서 다 잘 동작하는 기술이었고, 그레이스케일을 (훗날 컬러까지도) 지원했으며, 기타 여러가지 기능을 갖추고 있었습니다.

어도비는 DPS를 여러 회사에 라이센스하려 했습니다만 가격 대비 성능이 그다지 뛰어나지 못한 것으로 밝혀집니다. DPS는 여러 해상도를 모두 다 지원하는 보다 일반화된 기술이었기 때문에 퀵드로우를 비롯한 여러 회사에서 독자적으로 개발한 특화된 솔루션에 비해 느렸습니다. (잊지마세요. 1988에 느렸다고 해서 1992년이나 1995년 컴퓨터에서도 느린 것은 아닙니다. 1999년 컴퓨터는 말할것도 없습니다. '느리다'는 문제는 대개 시간의 경과에 따른 성능의 증가로 해결 됩니다.)

얼마 뒤 포스트스크립트의 높은 라이센스 요금은 결국 애플과의 계약을 파기하게 만듭니다. 높은 가격은 포스트스크립트 보급 역시 제한합니다. (애플은 포스트스크립트 폰트를 맥에 첨가하고 싶어 했지만 포스트스크립트 라이센스 비용이 레이져 프린터 가격의 거의 두 배에 이르렀습니다.) 그래서 애플은 트루타입(TrueType) 폰트를 개발합니다. 트루타입 폰트는 훨씬 더 강력했고 라이센스 비용을 지불할 필요가 없었습니다. 그리고 애플은 퀵스크립 프로젝트를 다시 시작하게 됩니다. 이것은 훗날 퀵드로우 쥐엑스(QuickDraw GX)가 됩니다.

퀵드로우 쥐엑스는 완전히 새롭게 개발된 그래픽스 엔진이었습니다. 이것은 해상도 독립성 지원은 물론이거니와 모든 종류의 새로운 변형, 투명도(transparency) 부여를 가능케 했고 그 외 다양한 기능을 갖추고 있었습니다. 게다가 퀵드로우는 여러가지 면에서 객체지향적이었고, 이것은 분명한 강점이었습니다. (여기서 자세하게 얘기하기에는 너무 복잡한 얘깁니다만)

어도비는 애플이 자신들의 머리에 총을 겨누고 있다는 것을 알아채고, 자사 소유의 폰트 포맷 사용 방법을 공개하는 한편, 포스트스크립트 가격도 보다 현실적으로 낮추게 됩니다.

하지만 퀵드로우 쥐엑스는 별로 성공적이지 못했습니다.
그것은 그 기술 자체가 좋지 않은 것이서라기 보다는 (물론 첫 버전은 그다지 훌륭하지 못했습니다만), 기존의 방식에 따라 이뤄지고 있던 많은 것들이 굳건히 버티고 있었기 때문이었습니다. 어도비 및 유사 회사(알더스, 알트시스, 쿽 등등..)들은 쥐엑스라는 새로운 기술을 철저히 외면하고 잊혀지게 만들 수 있었습니다. 이것은 그래픽스나 퍼블리슁 쪽에서 활동하는 회사들로서는 당연했습니다. 이 회사들은 수년간 일러스트레이션이나 레이아웃을 해주는 프로그램을 만드는 데 많은 투자를 했었고, 따라서 다른 회사들이 쥐엑스같은 기술을 이용해서 무임승차 하는 것을 절대 원하지 않았기 때문입니다. 수 년간 퀵드로우를 확장하는데 노력했던 회사들로서는 당연했습니다.

물론 쥐엑스의 실패가 완전히 다른 회사들 때문이었던 것은 아닙니다. 애플 자신이 제대로 마케팅하지 못했습니다. 애플은 퀵드로우 쥐엑스 안에 지나치게 많은 것을 담으려 했고 쥐엑스를 통해 돈을 벌려고도 했습니다. 쥐엑스는 결국 별 소리 소문 없이 사라져 버립니다.

아이러니컬하게도, 애플로부터 떨어져 나온 탤리젼트(Taligent)가 이 쥐엑스 엔진을 (적어도 개념상으로 나마) 차용해오게 됩니다. 아이비엠이 썬과 함께 사이좋게 자바를 개발해 나갈 때 사용했던 자바 2D 그래픽스 엔진을 보면 썬이 탤리젼트 2D 그래픽스 엔진으로부터 많은 점들을 차용한 것처럼 보였습니다. 결국 자바 그래픽스는 애플에게 상당히 많은 빚을 지고 있다고 할 수 있습니다. 어떻게 해서 동일 아이디어가 여러 회사들간을 계속해서 왔다 갔다 하면서 서로 차용되며 사용 되었는지를 생각해 보는 것도 상당히 재미있습다.

넥스트는 결국 애플과 합쳐지게 됩니다.
그리고 이들은 미래(OS X)에 어느 방향으로 나아가야 할 지를 결정해야만 했습니다.
예전의 퀵드로우(또는 퀵드로우GX)를 선택할 것인가? 아니면 디스플레이 포스트스크립트(DPS)를 선택할 것인가? 그것도 아니면 완전히 새로운 어떤것을 개발해 낼 것인가를 결정해야만 했습니다. 이 때 어도비의 라이센스 비용이 다시 한 번 판단 기준으로 작용하게 됩니다.

애플은 메인스트림 운영체계를 만들어 내면서, 어도비에게 유닛 당 라이센스료를 지불해야 하는 식으로 개발하기는 무리라 판단했습니다. 그렇다고 쥐엑스를 사용하기에는 쥐엑스의 나쁜 평판도 부담이었고 다시 사용하려면 상당한 수준으로 재작업을 해야 했습니다. 완전히 새롭게 개발해 낸다는 것 (extended QuickDraw라는 이름으로 불리웠습니다) 역시 너무 많은 작업이 소요될 것 같았고 설령 만들어 냈다 하더라도 퀵드로우와 포스트스크립트 양자 모두와 호환성을 유지하는 것은 간단한 일이 아니었습니다.

넥스트사로부터 건너온 사람들은 디스플레이 포스트스크립트(DPS) 방식을 더 선호했습니다. DPS는 화면상의 이미징과 프린팅을 최대한 유사하게 유지할 수 있었을 뿐만 아니라, 기존에 포스트스크립트를 이용하고 있던 많은 프로페셔널들에게 보다 익숙한 방식이었기 때문입니다.

어도비는 자사로부터 라이센스를 얻어서 PDF를 사용하는 쪽으로 애플을 몰아갔습니다. PDF는 일종의 객체화 된 (그룹지어진) 포스트스크립트 문서로, 그래픽스 파일을 화면상으로 또는 프린터로 보내는 데 사용되던 기술이었습니다. PDF는 포스트스크립트와 디스플레이 포스트스크립트를 절충한 것으로 부가적인 정보(예를 들면 문서에 폰트 정보를 담아서 이동할 수 있게 한 것같은)를 첨가한 것이었습니다. 그리고 PDF는 퀵드로우 쥐엑스로부터 몇 가지 개념들을 이미 차용해 놓기도 했습니다.

따라서, PDF는 아주 적절한 절충안이었습니다. (비록 쥐엑스의 객체 방식보다는 포스트스크립트 스트림 방식 쪽에 더 가깝긴 했지만요)

PDF가 꽤 괜챦은 기술이기는 했지만 애플이 염려하던 근본적인 문제를 해결해 주지는 못했습니다. 근본적 문제란 라이센스 요금 문제, 그리고 애플 수준의 회사가 그래픽스 시스템같은 핵심적인 기술을 다른 회사에 의존하는 걸 원치 않는다는 점이었습니다.
애플은 코드를 소유할 필요가 있었습니다.

이처럼 여기 저기 왔다 갔다 한 기술에 있어서 어떤 종류의 혁신이 있었는지를 파악한다는 것 매우 어려운 작업입니다. 애플이 다른 회사로부터 차용하기도 했고, 다른 회사들 역시 애플로부터 기술을 빌어가기도 했습니다. 관련 인력 역시 이 회사 저 회사를 왔다 갔다 했었습니다. 확실히 어도비는 퀵드로우 쥐엑스로부터 많은 아이디어를 얻어서 훨씬 더 많은 것을 이뤄낼 수 있었습니다. 쥐엑스 역시 어도비를 비롯한 다른 회사들이 미리 개발해 놓은 것들을 빌어올 수 있었습니다. 결국 그래픽스 시장에서 전혀 기여하지 않은 회사를 딱 하나 꼽으라면,

마이크로소프트였습니다.

그렇다면 무엇이 더 좋은가 (퀵드로우, GX, 포스트스크립트/DPS/PDF)

각각의 이미징 시스템은 나름의 장점과 단점이 있습니다. 이들 중 어떤 것은 개념상으로 더 뛰어나서 보다 더 제대로 만들어진 기술인 반면, 어떤 것은 실용적인 면에서 월등해서 보다 더 표준에 가깝습니다.

퀵드로우는 빨랐고, 타이트했고, 적은 메모리만을 차지했으며, 파워풀했습니다. 하지만 퀵드로우는 정수시스템(Integer system)에 기반해서 구축된 기술이었기 때문에 고해상도 레이져 프린터와 같은 곳에서 요구되던 큰 영역을 제대로 다룰 수 없었습니다.

퀵드로우는 화면상의 이미지를 다루는데 있어서 최고였습니다. 또한 해상도 독립적인 면도 갖고 있었습니다. 하지만, 그 방면으로 충분히 사용되지 못했기 때문에 관행에 밀려 고해상도 레이져 프린터 영역으로 진출하지는 못하게 됩니다. 퀵드로우는 또한 낡은 프로시져럴/ 스트림 기반의 API를 사용했기 때문에 장기간 계속해서 발전해 나가기엔 부족한 면이 있었습니다.

퀵드로우 쥐엑스는 일반 퀵드로우에 비해서 훨씬 뛰어난 기술이었습니다. 쥐엑스는 부동소수점(floating point) 좌표를 썼기 때문에 훨씬 더 큰 디스플레이 영역을 보다 더 세밀하게 다룰 수 있었습니다. 데이타 스트림을 사용하지 않고 각각의 이미지 객체가 드로우잉 환경 상태에 의존한 형태로 존재했기 때문에 훨씬 더 객체 기반적일 수 있었습니다. 각각의 객체 자신이 자기 자신의 특징에 관한 정보를 담고 있었고, 다른 객체와 독립적이었으며, 현재의 드로우잉 상태로부터도 분리될 수 있었습니다. (개념상으로는)

불행히도, 그런 특징들을 제대로 완성해 내지는 못했습니다.
API는 여전히 객체 기반이 아니라, 프로시져 기반이었습니다. 그리고 마케팅도 제대로 이뤄지지 못했습니다. 결국 퀵드로우 쥐엑스는 다른 기술들에 의해 부분 부분 각 아이디어 별로 뜯겨 나가게 됩니다.

포스트스크립트와 디스플레이 포스트스크립트는 동일한 것의 다른 측면이라 할 수 있습니다. DPS는 화면상의 정보를 보다 더 잘 조절할 수 있고 이해하기가 용이했다는 점이 달랐습니다. 둘 다 어떤 페이지를 이미쥐化 하는곳에 사용된 스트림 기반의 언어였습니다. 어떤 한 페이지나 객체를 그리기 위해서는 상태 정보를 얻기 위해 먼저 모든 객체들(페이지들)을 그려야만 했고 그리려는 객체를 그린 뒤 나머지 객체들을 그려야 했습니다. (그래야 그리고자 하는 객체가 하얀 사각형에 의해 가리지 않을 테니까요)

그런데 프린트에 사용되던 포스트스크립트 언어(구문)은 정말 조잡했습니다. 암호처럼 생겨서 이해하기 힘들었고 사용하는것도 여간 불편한 게 아니었습니다. 퀵드로우쪽이 훨씬 더 쉽게 프로시져럴 형태로 호출할 수 있었습니다. 하지만 해상도 독립성 측면에서는 포스트스크립트가 더 뛰어났습니다. 그리고 포스트스크립트 환경에서 그려진 그래픽은 그야말로 환상적이었고 화면상에서나 프린터에서나 똑같이 출력되었습니다. 퀵드로우 쥐엑스는 어떤 프린터에서는 제대로 출력이 되었지만, 다른 프린터에서는 에러가 나곤 했습니다. 게다가 대다수는 (하이엔드 쪽은 특히) 이미 포스트스크립트 프린터를 쓰고 있었습니다. 관행이란 것은 중요합니다.

PDF는 포스트스크립트와 디스플레이 포스트스크립트를 보다 새롭게 절충해서 객체들을 그루핑할 수 있게 한 기술입니다. 하지만 완전히 새로운 것이었다기 보다는 여전히 포스트스크립트에 부가적인 것들을 덧붙여 놓은 쪽에 가까왔습니다. PDF가 새롭게 선보인 특징으로는 다른 페이지와 독립적으로 각 페이지를 렌더링 할 수 있었다는 점 그리고 한정적이기는 했지만 보안이나 압축 능력이 있었다는 점 페이지기술(page description)을 확장하기 용이하게 잘 설명해 놓았다는 점 등이었습니다.

PDF는 그것이 화면상의 포맷, 프린트 포맷이면서 또한 파일 포맷이기도 했다는 점에서 아주 독특했습니다. PDF는 또한 퀵드로우 쥐엑스처럼 폰트 정보를 파일 내에 임베드 할 수 있었습니다. 그 결과 사용자가 특정 폰트를 갖고 있지 않더라도 훨씬 더 정확하게 페이지를 보여줄 수 있었습니다. 그리고 PDF는 문서로부터 그러한 정보를 추출하는 것을 다룰 수 있었습니다. 따라서 저는 PDF를, 폰트와 문서 관리 기능을 덧붙인 '수퍼 포스트스크립트'라고 얘기하고 싶습니다.

이러한 모든 것들이 혼동스럽게 느껴지시더라도 뭐 크게 신경쓰지는 마세요. 각각의 기술들은 수 많은 자그마한 장단점들을 갖고 있으니까요. 퀵드로우는 화면상에서는 훌륭하지만 고해상도에서 많은 문제를 갖고 있습니다. PDF는 프린터상에서는 훌륭하지만 화면상의 디스플레이는 제가 보기에 그다지 훌륭하지 못합니다. 디스플레이 포스트스크립트는 포스트스크립트나 PDF보다 화면상에서 더 훌륭하게 보이지만 몇 몇 프린터에서 제대로 동작하지 않도록 어도비가 장난을 쳐놓았습니다. (넥스트가 디스플레이 포스트스크립트로 모든 것을 처리하지 못하게 하려 했던 것입니다. 계속 포스트스크립트를 사용하게 만들기 위해 그렇게 했죠)

결국, 모든 것이 서로 뒤죽박죽이기 때문에 어느 한 기술이나 어느 한 제품이 완벽하다고 생각지는 않습니다. (너무나 많은 기존 관행이 있습니다) 하지만 대체로 시간이 지남에 따라 전체적으로 어떤 식으로든 나아져 가는 것 같고, 대체로 최근 기술,완성품일수록 보다 더 낫다고 얘기할 수 있겠습니다.

그리고 이제 우리는 쿼츠(Quartz)를 갖게 되었습니다. 가장 최근 기술이면서 또 하나의 대단한 도약인 쿼츠말입니다.

쿼츠(Quartz)는 무엇인가

애플이 쿼츠를 개발할 때 다음의 요구 조건을 걸었다고 합니다. 이런 요구 사항을 만족하는 것이 바로 쿼츠입니다.

• 디스플레이 포스트스크립트는 없애라.
• 새로운 윈도우잉 시스템과 그래픽스 라이브러리를 만들어 내라.
• 프린팅, 컬러싱크(ColorSync), 퀵타임(QuickTime), 자바, 그리고 유져인터페이스를 통합하고 확장해라.
• 프린터상에서 대형 이미지들을 다룰 수 있도록 부동소수점 기반의 2D 그래픽스 시스템이어야 한다. (퀵드로우는 정수 기반 쥐엑스는 부동소수점 기반이었습니다)
• 쿼츠를 지원할 수 있는 보다 새로운 윈도우 써버를 만들어 내라. 보다 가벼워야 하고 (그림이 없어야 한다), 버퍼링 지원 기능이 있어서 공유 메모리를 이용한 오프 스크린 드로우잉을 할 수 있어야 한다.
• 가급적 표준에 호환되게 하라. 그리고 그래픽스에 해당하는 문서 포맷도 만들어 내라.

위의 요구사항은 애플이 PDF를 사용하도록 압박하던 어도비의 당초 생각과 상당히 다른 것이었습니다. 어도비는 애플이 자신들의 PDF를 사용하기를 원했지, 애플 고유의 새로운 PDF를 만들어 내는 것을 바라지 않았습니다. 하지만 쿼츠 계획은 애플에게 아주 훌륭한 절충안이었습니다. 세계 최고의 기술 중 하나를 빌어와서 애플 소유의 완성품으로 만들어 낸다, 어도비에게 로열티를 지불할 필요도 없다라는 측면에서 그랬습니다.

쿼츠는 완전히 새로운 윈도우잉 시스템이자 핵심 2D 그래픽스 라이브러리입니다. 분명히 디스플레이 포스트스크립트와 PDF를 기반으로 하고 있지만 확실한 애플 테크널러지입니다. 애플은 디스플레이 포스트스크립트를 기반으로 하고 있던 넥스트 시스템을 참조할 수 있었고 PDF와 퀵드로우 쥐엑스(개념상으로) 등으로부터 많은 것을 차용할 수 있었기 때문에 단시간 내에 아주 산뜻한 시스템을 만들어 낼 수 있었습니다. 그리고 쿼츠는 지나치게 새로운 것도 아니었습니다. (물론 계속해서 개선된 새 버젼을 내놓을 수도 있습니다) 실제 애플은 쿼츠를 개선해 나갑니다. 쿼츠는 이제 로테이션, 변형 (늘리기, 찌그러뜨리기 등등) 등을 다룰 수 있으며, 모든 텍스트와 그래픽스는 앤티-에일리리어스화(anti-aliased) 되어 있고, 투명하게 만들 수도 있으며, 반짝거린다든지 하일라이팅을 한다든지 하는 여러가지 이펙트들도 다룰 수 있습니다.

모든 것은 감탄할 정도로 샤프하게 보이는데다가 처리하는 이펙트 수준에 비추어 볼 때 놀랄 만큼 빠릅니다. 객체를 임의로 회전시킬 때도 깜박거림이나 모서리의 찌그러짐이 없습니다. 모든 것은 다양한 정도의 투명도를 가질 수 있습니다. 애플이 그 점을 자랑하기도 했습니다. 즉 어떤 객체를 다른 것 위에 올려다 놓으면 위의 객체를 통해 아래 객체가 비춰 보였습니다. 어떤 객체는 그림자를 짓게 만들 수도 있고 이 그림자에 의해 다른 객체는 부드럽게 흐려지기도 합니다. 그리고 그림자는 다른 모든 객체와 잘 혼합 됩니다 . 텍스트는 특정 패쓰에 한정지울 수 있으며 패쓰 그 자체도 드라마틱하게 바꿀 수 있습니다. 게다가 텍스트는 실시간으로 업데이팅 됩니다. 모든 것이 너무나 부드럽고, 너무나 명확하면서 또한 너무나 샤프합니다. 거의 사진처럼 보일 정도입니다. 물론 애플이 더 개선해야 할 부분도 있습니다. 아직까지는 그래픽스 가속을 완성해 내지 못했다는 점 등은 과제입니다. (비록 속도는 받아들일만한 수준이었지만)

결론

최종 결론은 보다 더 완성 단계에 이른 다음, 또 보다 더 많은 문서를 본 뒤에 내려야 할 것입니다. 하지만 정말 훌륭한 많은 발전이 진행되고 있습니다. 쿼츠 그래픽스는 제가 예전에 본 그 어떤 것보다 샤프했습니다. 어도비 일러스트레이터에 보다 더 나은 프리뷰 기능과 이펙트 기능을 덧붙인 것처럼 보였습니다. 게다가 이러한 모든 것이 운영체계 자체에 기본 장착되어 있습니다. 쿼츠는 오에스 텐의 환상적인 기반이 될 것입니다. 그리고 프로그래머들은 이 기능들을 카본이나 코코아를 통해 불러 들일 수 있기 때문에 쿼츠는 여러가지 용도를 갖게 될 것입니다. 이 말은 드로우잉이나 일러스츠레이션을 해주는 모든 애플리케이션들이 기본 장착된 엔진의 파워를 이용할 수 있게 된다는 의미입니다. 모든 것을 프로그래머 자신이 직접 만들 필요가 없습니다.

이런 점은 앞으로 훨신 강력한 프로그램이 만들어져 나올 수 있음을 의미합니다. 제 생각에 프린팅 쪽에서 가장 강력한 특징을 드러낼 것 같습니다. 사용자들은 실제 프린터를 이용해서 출력을 하든 안하든 PDF 파일 형태로 프린트를 하게 될 것입니다. 이 말은 프린트 프리뷰 (그리고 편집) 기능도 기본으로 갖춰지게 된다는 의미입니다. 사실 PDF는 시스템의 어느 부문에서나 다 응용될 수 있습니다. 이메일에 포함시킬 수도 있고, 프로그램간에 그림을 이동시켜 가며 편집하고 붙이는 데도 쓰일 수 있습니다. 이런 점은 클립보드를 보다 더 파워풀 하게 만들어 줄 것입니다.

모든 것이 PDF 기반 위에서 구축된다, 이것은 오에스 텐 유져에게는 분명히 희소식입니다. 그리고 보다 하위 수준의 API가 만들어 져서 프로그래밍 時 그래픽스 루틴을 호출할 수 있게 될 것입니다. 아주 깔끔하게 추출된 파워풀한 API가 만들어 질 것입니다. (퀵드로우 비슷한 대체품이 되는 것입니다)

하지만 대부분의 프로그래머들은 그런 수준까지 내려갈 필요도 없습니다. 쿼츠는 퀵타임과 보다 더 긴밀하게 통합될 것이기 때문입니다. 이는 곧 퀵타임의 기본적인 임포터와 익스포터를 이용해서 수 십개 이상의 그래픽스 포맷들을 네이티브로 지원하게 된다는 것을 의미합니다. GIF, TIF, JPEG, PNG, PICT, BMP, EPS ..

또한 퀵타임의 애니메이션 (스프라잇) 처리의 강력함과 유연성 역시 쿼츠에 첨가될 것입니다. 애플은 심지어 미래의 표준 격인 SVG(Scaleable Vector Graphics)에 대한 지원, 그리고 그래픽을 텍스트 형태로 익스포트 하는 것을 계획하고 있기도 합니다.

물론 다른 회사들이 쿼츠를 채용하도록 하는 과정에서 넘어야 할 몇가지 장애물이 있습니다. 이들 회사들로서는 쿼츠를 채용하는 것이 전혀 새로운 방식을 받아들인다는 것을 의미하기 때문입니다. 프로그래머나 소프트웨어 회사 경영진은 그런 것을 별로 좋아하지 않습니다. (돈과 시간이 든다는 얘기니까요)

하지만 쿼츠는 분명히 시간과 비용을 투입할 가치가 있습니다. 쿼츠를 통해서 새로운 경쟁력을 얻을 수 있기 때문입니다. 애플이 쿼츠를 확실하게 가꾸어 나가기만 한다면, 그리고 충분한 탄력을 받고 새로운 기능도 충분하게 갖추게 된다면, 많은 회사들이 쿼츠를 채용하게 될 것입니다.

쿼츠야 말로 기존에 있던 것들의 장점을 기반으로 구축된, 그리고 그것을 잘 확장한 차세대 이미징 시스템이라 할 수 있습니다. 쿼츠는 이를 기반으로 만들어 질 모든 애플리케이션들을 받치고 있는 그래픽스 서브시스템의 새로운 하부 경계 역할을 하게 됩니다. 이건 곧 보다 더 표준적이면서 보다 풍부한 기능의 뛰어난 그래픽이 오에스 텐에 기본적으로 장착된다는 것을 의미합니다.

쿼츠에 의해서.