카본 (API)

카본

개발자	애플
저장소	{{URL|example.com|optional display text}}
엔진
운영 체제	Classic Mac OS, macOS
라이선스	사유 소프트웨어

카본(Carbon)은 애플이 Mac OS X 운영체제를 위해 개발한 두 가지 주요 C 기반 API 중 하나이다. 카본은 맥 OS 8 및 맥 OS 9에서 실행되는 컴퓨터 프로그램에 대해 높은 수준의 하위 호환성을 제공했다. 개발자들은 오픈스텝에서 유래하여 구조가 완전히 다른 코코아 시스템으로 앱을 이식하는 것에 비해 적은 노력으로 기존의 “클래식” 맥 응용 프로그램과 소프트웨어를 Mac OS X 플랫폼으로 이식(“카본화”)하기 위해 카본 API를 사용할 수 있었다. 매킨토시의 10.15 (카탈리나) 업데이트 릴리스와 함께 카본 API는 공식적으로 중단 및 제거되었으며, 코코아가 현대적인 맥 응용 프로그램 개발을 위한 유일한 주요 API로 남게 되었다.

카본은 기존 소프트웨어 응용 프로그램을 빠르게 이식할 수 있는 경로를 제공했을 뿐만 아니라 Mac OS X 또는 클래식 맥 OS 중 어느 쪽에서도 실행될 수 있는 응용 프로그램을 배포할 수 있는 수단을 제공함으로써 Mac OS X를 시장에 출시하려는 애플 전략의 중요한 부분이었다. 특히 iOS 출시 이후 시장이 점점 더 코코아 기반 프레임워크로 이동함에 따라 이식 라이브러리에 대한 필요성이 줄어들었다. 애플은 2007년경 다른 프레임워크를 업데이트하는 동안 카본의 64비트 버전을 만들지 않았으며, 결국 2012년 7월 24일에 출시된 OS X 마운틴 라이언에서 API 전체를 사용 중단했다.

역사

클래식 맥 OS 프로그래밍

오리지널 맥 OS는 파스칼을 주요 개발 플랫폼으로 사용했으며, API는 파스칼의 호출 세맨틱에 크게 기반을 두었다. 매킨토시 툴박스의 상당 부분은 파스칼의 가변 레코드 개념에 기반한 다양한 자료 구조를 사용하여 API와 프로그램 간에 정보를 주고받는 프로시저 호출로 구성되었다.

시간이 흐르면서 맥에서는 여러 객체 라이브러리가 진화했는데, 특히 오브젝트 파스칼 라이브러리인 맥앱(MacApp)과 싱크 C(THINK C)의 싱크 클래스 라이브러리, 그리고 이후 버전의 맥앱 및 C++로 작성된 코드워리어의 파워플랜트(PowerPlant)가 대표적이다.

랩소디

1996년 말 NeXT를 인수한 애플은 기존 오픈스텝 for Mach 플랫폼에 크게 기반한 새로운 운영체제 전략을 개발했다. 새로운 랩소디 OS 전략은 비교적 단순했다. "옐로 박스"(Yellow Box)라는 이름으로 오픈스텝의 기존 객체 라이브러리 대부분을 유지하고, 오픈스텝의 기존 GUI를 이식하여 맥과 더 유사하게 만들었으며, 맥 OS의 몇몇 주요 API를 랩소디의 기반이 되는 유닉스 계열 시스템으로 이식(특히 퀵타임 및 애플서치)하고, 기존 맥 OS 소프트웨어를 실행하는 "블루 박스"(Blue Box)라는 에뮬레이터를 추가하는 것이었다.

1997년 세계 개발자 회의(WWDC)에서 이 계획이 공개되자, 자신들의 코드 베이스가 업데이트될 가능성이 낮은 에뮬레이터에 사실상 갇히게 될 것을 우려한 기존 맥 OS 개발자들의 반발이 있었다. 그들은 블루 박스를 "페널티 박스"라고 부르기도 했다. 마이크로소프트와 어도비와 같은 대형 개발사들은 노골적으로 난색을 표하며, 기존 맥 OS와 너무 달라 호환성이 거의 없는 오픈스텝으로의 이식 고려를 거부했다.

애플은 이러한 우려를 진지하게 받아들였다. 스티브 잡스는 1998년 다음 WWDC에서 애플의 방향 전환을 발표하며, "개발자들이 진정으로 원하는 것은 맥 OS의 현대적인 버전이었고, 애플은 그것을 제공할 것"이라고 밝혔다.

기존 맥 OS 소프트웨어를 실행하기 위한 블루 박스만을 포함했던 원래의 랩소디 컨셉은 결국 1999년에 맥 OS X 서버 1.0으로 출시되었다. 이것이 오리지널 랩소디 컨셉에 기반한 유일한 릴리스였다.

코코아와 카본

기존 맥 OS 코드 베이스를 위해 실질적이고 잘 지원되는 업그레이드 경로를 제공하기 위해 애플은 카본 시스템을 도입했다. 카본은 맥과 유사한 API를 제공하는 많은 라이브러리와 함수로 구성되어 있지만, 에뮬레이션으로 실행되는 맥 OS의 복사본이 아니라 기반이 되는 유닉스 계열 OS 위에서 실행된다. 카본 라이브러리는 광범위하게 정리되고 현대화되었으며 더 잘 "보호"되었다. 맥 OS가 데이터를 전달하기 위해 메모리를 공유하는 API로 가득했던 반면, 카본 하에서 그러한 모든 접근은 오페이크 데이터 타입에 대한 액세서 서브루틴을 사용하여 재구현되었다. 이를 통해 카본은 맥 개발자들이 10년 동안 요구해 온 기능인 진정한 다중작업과 메모리 보호를 지원할 수 있게 되었다. 기존 API의 다른 변경 사항으로는 Mac OS X와 개념적으로 호환되지 않거나 단순히 시대에 뒤떨어진 기능들을 제거한 것이 있다. 예를 들어, 응용 프로그램은 더 이상 인터럽트 핸들러나 장치 드라이버를 설치할 수 없었다.

카본을 지원하기 위해 전체 랩소디 모델이 변경되었다. 랩소디가 사실상 에뮬레이터를 포함한 오픈스텝이었던 반면, 새로운 시스템 하에서는 오픈스텝과 카본 API가 가능한 경우 공통 코드를 공유하게 되었다. 이를 위해 Objective-C로 작성되었으며 파운데이션(Foundation)으로 알려진 오픈스텝 시스템 하위 계층의 유용한 코드 조각들이 순수 C로 재구현되었다. 이 코드는 코어 파운데이션(Core Foundation), 줄여서 CF로 알려지게 되었다. CF를 호출하도록 이식된 옐로 박스의 버전이 새로운 코코아 API가 되었고, 카본의 맥 방식 호출들 또한 동일한 함수들을 호출했다. 새로운 시스템 하에서 카본과 코코아는 대등한 관계였다. 이러한 변환은 일반적으로 객체 메서드가 하위 C 라이브러리를 호출함에 따라 코코아의 성능을 저하시킬 수 있었으나, 애플은 이러한 영향을 줄이기 위해 톨프리 브리징이라 불리는 기술을 사용했다.

이러한 전환의 일환으로 애플은 라이선스 문제가 얽힌 디스플레이 포스트스크립트를 대체하기 위해 새로운 윈도우 서버와 그래픽 엔진을 처음부터 다시 작성했다. 그것이 바로 쿼츠(Quartz, "디스플레이 PDF"라고도 불림)이다. 쿼츠는 카본이나 코코아 양쪽에서 모두 사용할 수 있는 C API 호출을 제공했다. 하위 운영체제 자체는 더욱 고립되어 다윈으로 출시되었다.

출시와 진화

카본은 2000년에 1997년의 맥 OS 8.1과 하위 호환되는 공유 라이브러리로서 불완전한 형태로 도입되었다. 이 버전을 통해 개발자들은 기존 맥 OS 기기에서 해당 프로그램이 실행될 수 있는 능력을 잃지 않으면서 코드를 카본으로 이식할 수 있었다. 카본으로의 이식은 "카본화"(Carbonization)로 알려지게 되었다. 공식적인 Mac OS X 지원은 새로운 OS의 첫 번째 공개 버전인 2001년 맥 OS X 10.0 출시와 함께 이루어졌다. 카본은 초기 Mac OS X 버전에서 애플을 포함한 거의 모든 주요 소프트웨어 하우스에 의해 매우 널리 사용되었다. 예를 들어 파인더는 수년 동안 카본 응용 프로그램으로 남아 있었으며, 2009년 맥 OS X 10.6 출시와 함께 코코아로 이식되었다.

2007년 10월 26일에 출시된 맥 OS X 레퍼드부터 시작된 64비트 컴퓨팅 매킨토시 응용 프로그램으로의 전환은 카본에 첫 번째 주요 제한을 가져왔다. 애플은 64비트 환경에서 매킨토시 그래픽 사용자 인터페이스와 C 프로그래밍 언어 간의 호환성을 제공하지 않았으며, 대신 코코아 API와 함께 오브젝티브-C 방언을 사용할 것을 요구했다. 많은 논평가들은 이를 카본이 결국 사라질 것이라는 첫 번째 징후로 받아들였으며, 애플이 카본 시스템에 더 이상의 주요 추가 사항은 없을 것이라고 밝히면서 이러한 입장은 더욱 강화되었고, 2012년의 사용 중단 발표로 다시 한번 확인되었다.

코코아로의 전환

코코아의 주장된 이점에도 불구하고, 방대한 양의 레거시 코드를 다시 작성해야 할 필요성 때문에 카본 기반 응용 프로그램의 전환은 늦어졌다. 유명한 사례로 어도비 포토샵은 2010년 4월에야 코코아로 업데이트되었다. 이는 애플 자신의 주요 소프트웨어 패키지에도 해당되어, 아이튠즈, 파인더 응용 프로그램, 그리고 파이널 컷 프로(및 이를 구동하는 퀵타임 엔진의 기능들)은 수년 동안 카본으로 작성된 채 남아 있었다. 아이튠즈, 파인더, 파이널 컷 프로는 이후 코코아 버전으로 출시되었다.

사용 중단 및 제거

2012년 OS X 10.8 마운틴 라이언의 출시와 함께 대부분의 카본 API는 사용 중단(deprecated)된 것으로 간주되었다. API는 여전히 개발자가 접근 가능했고 모든 카본 응용 프로그램이 여전히 실행되었지만, API는 더 이상 업데이트되지 않았다. 2017년 6월 28일, 애플은 모든 카본 응용 프로그램과 같은 macOS용 32비트 소프트웨어가 macOS 10.13 하이 시에라 이후의 macOS 버전에서는 더 이상 “타협 없이” 지원되지 않을 것이라고 발표했다. macOS 10.15 카탈리나는 모든 카본 응용 프로그램을 포함하여 32비트 응용 프로그램에 대한 지원을 공식적으로 제거했다.

아키텍처

카본은 툴박스에서 유래되었으므로 "매니저"(Managers)들로 구성되어 있다. 각 매니저는 기능적으로 연관된 API이며, 이를 조작하기 위한 자료 구조와 함수의 집합을 정의한다. 매니저들은 종종 서로 상호 의존적이거나 계층화되어 있다. 카본은 파일, 메모리, 데이터, 사용자 인터페이스 및 기타 시스템 서비스를 관리하기 위한 광범위한 함수 집합으로 구성된다. 이는 다른 API와 마찬가지로 구현된다. macOS에서는 여러 프레임워크(공유 라이브러리를 중심으로 구축된 구조체)에 분산되어 있으며, 주로 Carbon.framework, ApplicationServices.framework, CoreServices.framework가 그 역할을 하며, 클래식 맥 OS에서는 CarbonLib이라는 단일 공유 라이브러리에 상주한다.

카본은 호환성 박스가 아니며 Mac OS X를 위한 네이티브 API이다. 아키텍처 다이어그램에서 코코아와 나란히 위치한다. 카본 앱은 Mac OS X의 모든 네이티브 기능을 사용할 수 있으며, 동일한 프로세스 내에서 카본과 코코아 윈도우를 혼합하여 사용할 수 있다.

카본은 PowerPC 맥 OS에서 사용할 수 있는 여러 실행 파일 형식과 호환된다. Mac OS X와 이전 버전 간의 바이너리 호환성을 위해서는 Preferred Executable Format 파일의 사용이 필요한데, 애플은 자사의 통합 개발 환경인 엑스코드에서 이를 지원한 적이 없다.

카본의 최신 부분들은 그 개념에 있어 훨씬 더 객체 지향적인 경향이 있으며, 대부분 코어 파운데이션에 기반을 두고 있다. HIView 매니저(컨트롤 매니저의 슈퍼셋)와 같은 일부 매니저는 C++로 구현되어 있지만, 카본은 여전히 C API로 남아 있다.

카본 매니저의 몇 가지 예시:

• 파일 매니저(File Manager) — 파일 시스템에 대한 접근을 관리하며, 파일을 열고 닫고 읽고 쓴다.
• 리소스 매니저(Resource Manager) — 파일의 리소스 포크에 있는 데이터 덩어리에 대한 접근을 관리한다. 리소스의 예로는 아이콘, 소리, 이미지, 위젯용 템플릿 등이 있다.
• 폰트 매니저(Font Manager) — 글꼴을 관리한다. 맥 OS X 타이거 이후 애플 타입 서비스(ATS)를 위해 (QuickDraw의 일부로서) 사용 중단되었다.
• QuickDraw — 2차원 그래픽스 프리미티브. 맥 OS X 타이거 이후 Quartz 2D를 위해 사용 중단되었다.
• 카본 이벤트 매니저 — 사용자 및 시스템 활동을 코드가 인식하고 응답할 수 있는 이벤트로 변환한다.
• HIObject — 카본에 GUI 구축을 위한 객체 지향 모델을 제공하는 완전히 새로운 객체 지향 API이다. 이는 맥 OS X 10.2 이상에서 사용할 수 있으며, 카본 프로그래머에게 더 강력한 API를 제공한다. 맥 OS X 10.2부터 HIObject는 카본의 모든 GUI 요소에 대한 기본 클래스이다. HIView는 애플 개발자 도구의 일부인 인터페이스 빌더에서 지원된다. 전통적으로 이러한 종류의 GUI 아키텍처는 제3자 응용 프로그램 프레임워크가 제공하도록 남겨져 있었다. 맥 OS X 10.4부터 HIObject는 NSObject이며, 전송이나 디스크 저장을 위해 데이터 스트림으로 직렬화될 수 있는 능력을 상속받는다.
• HITheme — QuickDraw와 쿼츠를 사용하여 그래픽 사용자 인터페이스(GUI) 요소를 화면에 렌더링한다. HITheme은 맥 OS X 10.3에서 도입되었으며, 해당 버전 이후 Appearance 매니저는 HITheme 위의 호환성 계층으로 존재한다.
• HIView 매니저 — 컨트롤의 생성, 그리기, 히트 테스트, 조작을 관리한다. 맥 OS X 10.2 이후 모든 컨트롤은 HIView이다. 맥 OS X 10.4에서 컨트롤 매니저는 HIView 매니저로 이름이 변경되었다.
• 윈도우 매니저 — 윈도우의 생성, 배치, 업데이트 및 조작을 관리한다. 맥 OS X 10.2 이후 윈도우는 루트 HIView를 가진다.
• 메뉴 매니저 — 메뉴의 생성, 선택 및 조작을 관리한다. 맥 OS X 10.2 이후 메뉴는 HIObject이다. 맥 OS X 10.3부터 메뉴 콘텐츠는 HIView를 사용하여 그려질 수 있으며, 모든 표준 메뉴는 HIView를 사용하여 그려진다.

이벤트 처리

맥 툴박스의 이벤트 매니저는 원래 응용 프로그램 설계를 위해 폴링 모델을 사용했다. 응용 프로그램의 메인 이벤트 루프는 GetNextEvent를 사용하여 이벤트 매니저에게 이벤트를 요청한다. 큐에 이벤트가 있으면 이벤트 매니저는 이를 응용 프로그램으로 전달하여 처리하게 하고, 그렇지 않으면 즉시 반환한다. 이 동작은 "바쁜 대기"(busy-waiting)라고 불리며, 불필요하게 이벤트 루프를 실행한다. 바쁜 대기는 다른 응용 프로그램이 사용할 수 있는 CPU 시간을 줄이고 노트북의 배터리 전력을 감소시킨다. 클래식 이벤트 매니저는 어떤 응용 프로그램이 실행되든 그것이 유일하게 실행되는 응용 프로그램임을 보장받고 전력 관리가 고려 사항이 아니었던 1984년의 오리지널 맥 OS 시절부터 시작되었다.

멀티파인더(MultiFinder)의 등장과 하나 이상의 응용 프로그램을 동시에 실행할 수 있는 능력이 생기면서, 응용 프로그램이 절전 간격을 지정할 수 있게 해주는 새로운 이벤트 매니저 호출인 WaitNextEvent가 등장했다. 레거시 코드가 소스 코드를 크게 수정하지 않고도 더 효율적인 모델을 채택할 수 있는 한 가지 쉬운 방법은 WaitNextEvent에 전달되는 sleep 파라미터를 매우 큰 값으로 설정하는 것이다. macOS에서 이는 할 일이 없을 때마다 스레드를 잠들게 하고, 처리할 이벤트가 있을 때만 이벤트를 반환한다. 이런 방식으로 폴링 모델은 신속하게 반전되어 콜백 모델과 동등해지며, 응용 프로그램은 원래 방식대로 자체 이벤트 디스패칭을 수행한다. 그러나 허점도 있다. 예를 들어, 레거시 툴박스 호출인 ModalDialog는 내부적으로 이전의 GetNextEvent 함수를 호출하므로, 블로킹 없이 빡빡한 루프 내에서 폴링이 발생하게 된다.

카본은 카본 이벤트 매니저라고 불리는 대체 시스템을 도입했다. (오리지널 이벤트 매니저는 레거시 응용 프로그램과의 호환성을 위해 여전히 존재한다). 카본 이벤트 매니저는 개발자에게 이벤트 루프를 제공한다(현재 구현에서는 코어 파운데이션의 CFRunLoop를 기반으로 함). 개발자는 이벤트 핸들러를 설정하고 메인 함수에서 이벤트 루프에 진입하며, 카본 이벤트 매니저가 응용 프로그램에 이벤트를 디스패치하기를 기다린다.

타이머

클래식 맥 OS에는 응용 프로그램 수준의 타이머에 대한 운영체제 지원이 없었다(하위 수준의 타임 매니저를 사용할 수 있었으나, 이는 인터럽트 시간에 타이머 콜백을 실행했으므로 그동안 대부분의 툴박스 루틴을 안전하게 호출할 수 없었다). 타이머 구현은 보통 응용 프로그램 개발자의 몫이었으며, 대개 유휴(idle) 이벤트 동안 경과 시간을 계산하여 수행되었다. 유휴 이벤트는 다른 이벤트가 없을 때 WaitNextEvent에 의해 반환되는 이벤트이다. 이러한 타이머가 합리적인 해상도를 갖기 위해 개발자들은 WaitNextEvent가 너무 오래 지연되는 것을 감당할 수 없었고, 그래서 보통 낮은 "sleep" 파라미터가 설정되었다. 이는 스레드가 오래 잠들지 못하고 이러한 유휴 이벤트를 반환하기 위해 반복적으로 깨어나기 때문에 매우 비효율적인 스케줄링 동작을 초래한다. 애플은 이 문제를 해결하기 위해 카본에 타이머 지원을 추가했으며, 시스템은 매우 효율적으로 타이머를 스케줄링할 수 있게 되었다.

오픈 소스 구현

그누스텝은 Boron(붕소)이라 불리는 카본 API의 구현체를 포함하고 있다. 이는 ApplicationServices 및 CoreServices의 사용 중단되지 않은 부분들과 호환되는 것을 목표로 한다. 이 이름은 원소 주기율표에서 붕소가 Carbon(탄소) 앞에 온다는 사실에서 유래했다. 달링 또한 카본 구현체를 포함하고 있다. 두 구현체 모두 매우 불완전하며 대부분 스텁(stub) 함수로 구성되어 있다.

같이 보기

• 코코아 (API)
• 인터페이스 빌더
• 오브젝티브-C
• 엑스코드

외부 링크

• (영어) Apple Developer Connection: Carbon 보관됨 2012-10-12 - 웨이백 머신