ARM 기반 맥, 애플은 맥OS를 어떻게 할까

애플의 연례개발자행사 세계개발자대회(WWDC)20이 22일 열린다. 최근 10여년 간 iOS 업데이트에 방점을 찍어온 WWDC는 올해 ARM 기반 맥 공개 여부로 관심을 받고 있다.

현재까지 외신 보도에 따르면, 애플은 올해 WWDC에서 ARM 기반 맥 출시 계획을 발표하고, 내년 상반기 중 신제품을 내놓을 것으로 알려졌다. 실제 제품이 나오면 15년 만에 인텔 x86 프로세서를 벗어난 맥을 내놓게 된다.

미국 지디넷은 최근 ARM 기반 맥의 출현이 어떤 방식으로 이뤄질 것인지 예측하는 칼럼을 게재했다.

애플이 WWDC20 행사를 오는 22일부터 26일까지 온라인으로 개최한다.(사진=애플)

애플이 아이패드를 처음 공개했을 때 많은 전문가가 맥의 미래를 점쳤다. 미래 모바일 컴퓨팅에서 아이패드가 맥을 대체하고, 맥의 존재감이 옅어질 것이란 전망이 다수였다.

애플 전체 매출에서 맥의 비중은 9~11% 정도다. 성장률은 아이폰이나 아이패드에 비해 수년째 정체돼 있다. 그러나 맥은 iOS, 아이패드OS, 애플TV, 애플워치 등의 앱 개발 플랫폼으로 사용되기 때문에 애플에게 결코 소홀히 할 수 없는 존재다. 또, 파이널컷프로나 로직프로X 등 맥에서만 쓸 수 있는 독점 미디어 콘텐츠 편집 앱 사용자도 많다. 파레토 최적에 의하면, 맥 매출의 80% 이상이 크리에이터에서 나온다.

결과적으로 아이패드는 일반 사용자의 PC를 대체하겠지만, 대형 화면, 고성능 데스크톱 애플리케이션, 멀티 모니터 등에 최적화된 맥은 계속될 것으로 보인다.

WWDC20에서 나올 발표를 점치자면, 애플은 x86 기반 맥에서 ARM 프로세서 아키텍처로 이전하는 계획을 공개할 것으로 예상된다. 애플은 하드웨어와 소프트웨어를 완벽히 장악하고 관리하므로, 맥의 CPU를 바꾸는 행위 자체는 크게 어렵지 않다. 단, 맥OS를 ARM 아키텍처에 맞게 재설계할 지, 완전히 새로운 수단을 만들어낼 지가 관심 대상이다.

■ 역사속 맥OS 재설계

애플의 맥 CPU 전환 사례는 이미 두차례 있었다. 1990년 중반 모토로라68000 시리즈에서 IBM/모토로라 파워PC로 전환했고, 2006년 파워PC를 인텔 x86으로 전환했다.

모토로라68000을 파워PC로 전환할 때 애플은 당시 맥의 OS였던 '시스템7.1.2'를 바로 새 CPU에 올리려 했다. 첫 시스템은 1994년 나왔다. 스티브 잡스가 극적인 복귀를 하기 전이었다. 파워PC 기반 매킨토시는 모토로라68000 에뮬레이터를 갖고 있었고, 이 OS는 2000년까지 존재했다. 그리고 2000년 '랩소디(Rhapsody)'란 코드명을 가진 OS의 베타버전가 파워PC 플랫폼 전용으로 나왔다. 랩소디는 OS X을 거쳐 오늘날 맥OS에 이르게 된다.

애플은 1997년 복귀한 스티브 잡스의 회사 '넥스트(NeXT)'를 인수해 '오픈스텝' OS를 얻어 랩소디를 만들었다. 랩소디는 맥OS란 이름을 처음 달고 나왔고, 맥의 기존 앱을 구동할 수 있었다.

애플은 파워PC로 CPU를 교체하고, OS도 맥OS 8로 바꾸면서, 써드파티 회사의 맥 복제품 생산을 위해 제공하던 OS 라이선스 공유을 없애버렸다. 맥OS 라이선스는 써드파티에 제공되지 않았고, 난립했던 맥의 복제품을 없애 수익을 애플에 집중시켰다.

그러나 기존 맥의 앱을 파워PC에서 구동하기 위해 애플이 에뮬레이터 계층과 시스템8과 9의 작동을 모방한 실행환경만 만든 건 아니었다. 애플은 이전의 API를 맥OS 네이티브 API 내부에 집어넣어야 했다. 그래야 소프트웨어 개발자가 구형 OS에 맞춰 개발된 앱을 맥OS로 옮기기 위해 API를 재작성하지 않아도 되기 때문이다.

새로 개발된 맥OS 네이티브 API가 '코코아(Cocoa)'다. 코코아 API는 지금도 쓰인다. 애플은 당초 코코아로 기존 앱을 재작성하게 할 작정이었지만, 내부에서도 어려움에 봉착해 기존 맥의 API 집합을 OS 안에 별도로 집어넣어야 했다.

이전 맥의 앱을 지원하는 API는 '카본(Carbon)'이다. 카본은 2001년 맥 OS X 10.0 치타 버전에서 등장했다. 카본은 32비트 코드만 지원한다. 초창기 카본은 완벽하지 않았다. 호환성과 성능 이슈가 수년 간 터져나왔고, 첫 맥 OS X은 기존 '클래식 맥'에 비해 느렸다.

랩소디에 기반한 클래식 맥은 최종사용자와 개발자 모두에게 어려운 전환을 요구했다.

두번째 CPU 교체는 2006년에 일어났다. 스티브 잡스는 2005년 WWDC 기조연설에서 맥 CPU를 인텔 x86으로 교체하는 게획을 발표했다. WWDC2006에서 인텔 x86 기반 맥이 공개됐다. 모토로라에서 파워PC로 전환할 때도 애플에 x86을 공급하려 했다가 성능 때문에 외면받았던 인텔은 펜티엄으로 맥을 품을 수 있었다. 2006년의 인텔 x86은 파워PC를 성능에서 압도했기 때문에 애플의 선택이 완전히 틀리지 않았다. 인텔의 생산 규모와 공급망도 CPU 교체를 결정하게 한 요인이었다.

애플은 인텔 x86으로 전환하면서 파워PC 에뮬레이터를 포함시켰다. 이 에뮬레이터는 실리콘밸리의 스타트업 트랜서티브에서 만든 '로제타(Rosetta)'다. 로제타는 파워PC용 맥 OS X 앱 모두를 구동할 수 있게 했다. 로제타는 2009년 8월 OS X 스노레오파드 등장과 함께 사라진다.

애플의 세번째 CPU 교체가 예상되는 가운데, iOS와 맥 개발자인 브렌단 샹크스는 ARM 채택에 따른 예상 시나리오를 정리했다. 그는 애플이 맥OS 재설계를 택할 것이고, 전환은 근본적으로 단순할 것이며, 최종사용자에게는 체감되지 않을 것이라고 전망했다.

터치스크린 같은 하드웨어 교체가 없고, 샌드박스화된 앱, 앱스토어를 통한 배포, UI킷과 카탈리스트로 작성된 앱 등은 소프트웨어 변경이 필요없다는 게 이유다. ARM과 인텔 모두에서 돌아가는 하이브리드 앱 같은 복잡한 계획도 없다고 덧붙였다.

그는 ARM이 인텔 64비트 앱을 구동할 수 있는 로제타 같은 에뮬레이터를 보유했다고 설명했다. ARM을 위한 맥OS 10.16에서 '하이퍼바이저프레임워크(Hypervisor.framework)'를 쓸 수 없겠지만, 10.17 버전에서 추가될 것이라고 전망했다. 그는 또 맥용 소프트웨어를 돌리기 위해 맥이 존재하므로, 애플의 최우선순위는 기존 앱을 ARM에서 네이티브하게 돌아가도록 리컴파일을 쉽게 하는 것에 있다고 예상했다.

■ 맥을 다시 상상한다면

애플이 ARM을 채택할 때 인텔로 전환할 때처럼 맥OS를 재설계할 가능성은 낮다. 오히려 이전에 클래식 맥에서 랩소디로 전환한 것과 유사한 방식일 것으로 전망된다. 이 경우 모든 개발자와 최종 사용자가 고통을 겪을 수 있다.

랩소디 등장 후 20년 동안 많은 변화가 있었다. 애플은 이제 모든 소프트웨어 구매를 앱스토어로 관리한다. 웹 다운로드 같은 사이드로딩 앱은 써드파티 개발사에게 돈을 쥐어주지 않는다. 파이널컷프로, 메인스테이지, 모션, 로직프로X 등은 앱스토어 독점으로 판매된다. 개발환경인 X코드도 앱스토어에서만 받을 수 있다.

애플의 ARM 기반 맥은 iOS와 아이패드OS처럼 앱의 사이드로드 설치를 불가능하게 할 가능성이 높다.

이미 애플은 작년 모든 32비트 앱 지원을 중단함으로써 카본 API 지원을 종료했다. 최신 맥OS에서 돌아가는 많은 앱이 64비트로 전환됐으므로 32비트 API와 라이브러리, 모든 카본 API를 제거하면 인텔 64비트 에뮬레이터는 ARM에서 필요없어진다.

이는 ARM 기반 맥이 현존하는 x86 맥과 상당기간 병존할 것이란 추론을 가능하게 한다. 앱스토어로 앱 생태계를 묶어놓음으로써 수많은 아이패드용 앱이 이미 ARM 아키텍처에 맞춰 개발돼 앱스토어에 쌓여 있다.

x86에 맞춰 개발된 앱을 X코드에서 ARM용으로 빌드하고 크로스 컴파일하게 할 수도 있다. 그러나 애플은 자체 호스팅 플랫폼이 없다. 또 코드 작성과 컴파일에 요한 성능을 첫 ARM 맥이 제공할 것으로 보이지 않는다. 클라우드 개발환경을 제공하는 것도 한 방법이지만 애플은 마이크로소프트나 구글, 아마존웹서비스 같은 SW개발을 위한 클라우드에 투자하지 않는다.

4K 비디오와 CPU 및 GPU를 최대로 소모하는 작업에서 첫 ARM 맥이 기존 맥 워크스테이션을 대체하는 건 사실상 불가능하다. 애플이 전문가용 앱을 ARM에 올린다 해도 ARM 맥은 가벼운 작업에 적합할 것이다. 어도비가 크리에이티브클라우드를 ARM에 맞게 재개발할 가능성도 낮다.

결국 x86 기반 맥은 앞으로도 탄탄히 존재감을 유지할 것으로 전망할 수 있다.

ARM 맥은 애플의 모바일 컴퓨터 시장 확장으로서 의미를 갖는다. 맥의 성장률은 몇년째 0에 가깝다. 애플은 새 사용자를 끌어들일 수단이 필요하다.

프로젝트 카탈리스트 로고

■ 프로젝트 카탈리스트와 API의 제한

애플은 아이패드 앱을 맥용으로 전환하는 툴을 '카탈리스트'란 이름으로 제공하고 있다. 차후 맥용 앱을 아이패드로 전환하는 기능도 제공할 예정이다. 작년 WWDC에서 공개된 카탈리스트는 현재까지 큰 반향을 일으키지 못했다. 개발자가 카탈리스트를 활용할 이유가 별로 없기 때문이다.

ARM 맥을 내놓으면, 카탈리스트의 쓸모는 빠르게 늘어난다. 애플은 카탈리스트를 ARM 아키텍처의 기본 프로그래밍 API로, 스위프트를 주요 언어로 강제할 수 있다.

파이널컷프로나, 키노트, 페이지, 넘버스, 개러지밴드, 로직프로X 같은 데스크톱 앱을 위해 애플이 코코아 API를 내부용도로 남겨둘 수는 있다. 애플 외부 개발자가 ARM에서 완전한 API 세트를 사용할 수 없도록 제한하는 것도 가능하다. 개발자는 아키텍처와 하드웨어 제한만으로 새로운 맥에서 사용가능한 것과 사용불가능한 것에 다른 제한을 받을 수 있다.

현재의 맥OS 시스템 구성요소와 UX 요소를 ARM에서 작동시키려면 애플은 카탈리스트로 모든 구성요소를 재작성하게 될 때까지 코코아 API를 유지해야 한다.

애플이 내부용도로 새 OS 요소를 개발해 사용자관점에서 테스트하며 고도화할 수도 있다. 그러나 마이크로소프트는 윈도10에서 예전 UI 요소를 현대화하기 위해 상당기간 UX 재작성에 공을 들였다. 레거시 요소를 제거하고 교체하는 마이크로소프트의 작업은 수년을 들여서 달성됐다. 그럼에도 여전히 윈도는 기본 앱 호환성과 관련없는 흔적을 갖고 있다. 애플도 비슷한 상황에 처할 것으로 예상된다.

카탈리스트를 사용해 아이패드용 앱을 맥으로 이동시키는 노력과 더불어, ARM 맥과 x86 맥 간 '앱의 간극'을 최소화하는 노력도 병행될 수 있다. 맥에서 완벽하게 작동하는 '아이패드 에뮬레이터'다. 아이패드 앱을 수정하지 않고 ARM 맥의 창으로 띄워 쓰게 하는 것이다. 아이패드OS 앱스토어를 이용하게 하는 게 함께 쓰일 수 있는 방법이다.

애플이 앱을 전환하도록 하는 툴셋들을 공개할 가능성은 높다. 그러나 다양한 플랫폼에 맞춰 코드를 기꺼이 관리하고자 하는 개발자는 드물다. 툴을 이용해 빠르게 코드를 재활용하게 해도 그 자체가 새롭게 부여되는 작업이므로 호응을 얻기 힘들다. 마이크로소프트 정도의 SW회사는 카탈리스트로 아웃룩과 오피스 앱을 변환할 수 있다. 그러나 대부분의 개인 개발자는 거의 움직이지 않을 것이다.

■ 비즈니스 및 일반 사용자가 겪을 변화

ARM 맥이 x86 맥처럼 보일 수는 있다. 런처나 파일 관리자의 외관은 크게 차이없을 것이다. 단, 사용자가 x86 맥에서 쓰는 것과 동일한 수준으로 플랫폼에 접근하는 건 불가능하다.

모든 앱을 앱스토어로 설치하게 되면, 사용자는 애플리케이션 폴더에 접근하기 힘들 수 있다. 터미널 앱을 이용해 루트 차원의 시스템 폴더에서 로컬 커널레벨 프로세스와 컨피규레이션 파일과 상호작용하는 것도 불가능할 것이다. 사용자 레벨 디렉토리만 접근할 수 있을 뿐이다.

맥OS의 시스템 환경설정 같은 부분도 재작성되거나 다시 구현해야 할 수 있다. 초기 ARM 맥에선 아예 빠지거나 이식할 수 없는 유틸리티도 있을 것이다. 보안 문제 때문에 크롬이나 마이크로소프트 엣지 같은 타사 브라우저를 사용할 수 없게 제한할 수도 있다. 사파리 브라우저만 존재하거나, 아이패드의 크롬과 엣지처럼 사파리 렌더링 엔진을 써야 할 수 있다.

기존 전문 맥 사용자가 ARM 맥으로 이동하는 것을 배제한다는 전제다. 애플은 새로운 맥 사용자를 끌어들이는 목적으로 ARM 맥을 공급할 가능성이 높다. 간단한 오피스 앱, 브라우저와 SaaS로 실행되는 클라우드 앱 등을 사용하는 정도다. 아이패드나 크롬북보다 자유로우면서 기존 맥보다 제한적인 위치에 존재하는 것이다.

맥에 앱을 제공해온 대규모 SW 개발사에서 눈에 띄는 변화를 보일 수 있다. 일례로 맥용 오피스를 제공중인 마이크로소프트가 네이티브 앱보다 구글G스위트 같은 웹오피스에 더 공을 들이게 만들 것이다.

마이크로소프트가 카탈리스트로 작성된 런처를 통해 애저 의 가상머신에 컨테이너형태로 담은 오피스 앱을 선보일 수도 있다. 프로그레시브웹앱(PWA) 같은 방법이다. 애플의 앱스토어를 거치더라도 마이크로소프트가 소프트웨어 라이선스 제어권을 유지하는 것도 가능하다. 마이크로소프트는 앱스토어에서 원격데스크톱클라이언트와 같은 런처를 활용해 마이크로소프트365 계정로그인을 사용하도록 요구할 수 있다.

이같은 소프트웨어 배포 방법론은 순식간에 모든 개발자에게 확산될 수 있다. 앱스토어에 30%를 떼어주는 걸 꺼리는 어도비 같은 회사가 재빨리 마이크로소프트 뒤를 따를 가능성이 높다. 맥의 써드파티 앱이 웹기반 SaaS, PWA, 원격실행 등으로 변화할 수 있다.

미국 지디넷은 "ARM 맥 플랫폼의 등장은 마이크로소프트와 엔터프라이즈 소프트웨어 개발자가 전체 개발전략을 다시 고민하고, PWA와 Win32 API를 혼합한 하이브리드 클라우드 애플리케이션으로 이동을 가속할 것"이라고 예상했다.

또 "이같은 시나리오에서 애플리케이션 코드는 로컬보다 애저나 AWS, 구글클라우드 같은 클라우드에 유지되고 실행된다"며 "이는 다양한 캐싱 기술을 사용한다 해도 오프라인 상태에서 사용할 수 없게 되지만, 오늘날 통신을 해제한 방식으로 소프트웨어를 실행하는 건 비현실적이며 불가능하기도 하다"고 덧붙였다.