맥 CPU가 ARM으로 바뀌면 앱은 어떤 형태로 바뀔까

2020. 8. 7. 11:23애플 스페셜, 특집





요즘 맥 사용자 사이에서는 ARM으로의 전환 이슈로 떠들썩합니다. 맥 CPU 아키텍처가 ARM/애플 실리콘 (Apple Silicon)으로 변경된다는 건 그리 단순한 이야기가 아니기 때문이죠. 장기적인 처지에서 보자면 지금까지 분산되어 있던 보조 프로세서, 보안 칩을 통합하거나 자체 개발 CPU 탑재에 의한 장점을 끌어낼 수 있을 텐데요. ARM으로 이주 시 당장 네이티브 앱이 부족해질 것이라는 건 뻔합니다.

애플은 로제타(Rosetta)와 개발자 지원으로 문제없을 거라고 자신하고 있지만, 이전부터 맥을 사용해오던 분들이라면 애플 실리콘 맥에 다소 불안감을 가지고 있을 겁니다. 맥 사용자들은 이전 PowerPC에서 인텔 프로세서로 전환할 때 로제타를 한 번 경험했었는데요. 사실 그때와 현재 사정이 좀 다르거든요. 당시에는 인텔 프로세서 뒤를 PowerPC가 쫒아가는 형국이라 전 세계 맥 사용자들은 낙관적으로 바라보는 시각이 더 컸는데 이번에는 살짝 우려스러운 모습도 보입니다. 당장 현재 성능만 보면 x86_64쪽이 여러모로 유리하기 때문이지요.

그러나 ARM/애플 실리콘에는 이전과는 다른 기대가 있습니다. 바로 '방대한 iOS 앱 인프라'입니다. iOS와 같은 CPU 아키텍처를 도입하여 앱 개발 시 많은 부분에서 공용화가 진행될 것이라고 봐도 되며, 양적으로 맥을 크게 웃도는 플랫폼으로 성장한 iOS의 장점을 누릴 가능성이 있기 때문이죠. ARM으로 이주해도 개발자가 iOS 앱을 손보지 않는다면 바로 사용할 수 있게 되는 건 아니지만, 분명한 건 맥의 앱 생태계 기반이 정비된다는 건 확실한 플러스 요인입니다.

앱을 둘러싸고 있는 환경에서도 새로운 변화가 예측되는데요. 지난 WWDC 이벤트에서는 언급되지 않았지만, 이미 앱 스토어에 도입된 비트코드(Bitcode)에 대한 이야기입니다. 

프로그램을 만들 때 프로그래머는 사람이 읽을 수 있는 언어로 코드를 작성합니다. 하지만 기계는 이 언어를 이해할 수 없으므로 컴파일러가 기계어로 변환을 합니다. 비트코드란 사람이 읽을 수 있는 언어도 아니고 그렇다고 기계어도 아닙니다. 중간 단계의 표현이라고 보면 됩니다. 

비트코드가 적용되지 않으면 어떻게 앱을 개발할까요? 개발자가 아이폰, 아이패드뿐만 아니라 32비트, 64비트, arm7s, arm64 등 모든 기기와 프로세서에 대해 바이너리를 생성한 뒤 이를 하나의 파일로 합쳐 팻 바이너리 (fat binary)라는 걸 만들게 되는데요. 말 그대로 뚱뚱해집니다. 지금은 비트코드로 업로드 하면 사용자가 어떤 기기에서 앱을 받는가에 따라 앱 스토어 차원에서 재컴파일한 뒤 사용자 기기에 최적화된 상태로 설치가 됩니다. 

실제로 2013년 아이폰 5에서 64비트 칩셋으로 바뀔 때는 비트코드가 적용되지 않았었는데요. 앱 개발자들은 코드를 수정하고 다시 컴파일해서 앱 스토어에 제출해야만 했습니다. 이 당시 비트코드가 적용되었다면 어땠을까요? 개발자는 아무것도 안 해도 새로운 CPU 아키텍처에 맞게 앱 스토어가 알아서 컴파일하고 최적화를 해줬을 겁니다.


앱 설치 시 앱 스토어에서 앱 구성 요소를 기기에 따라 재구성(App Slicing)하여 내려받게 된다. (WWDC 2015)


현재 macOS를 제외하고 iOS, tvOS 등에서는 기본 옵션으로 활성화되어 있고 앱 스토어에 비트코드로 업로드하도록 이뤄지고 있습니다. 여기서 이런 최적화가 앱 스토어 차원에서 이미 마련되어 있다는 게 포인트인데요. 사용자가 설치하는 기기와 스펙에 따라 바이너리 코드와 이미지 크기를 최적화함으로써 앱 성능 향상과 용량을 좀 더 컴팩트하게 유지할 수 있습니다.

향후 맥에서는 ARM/ 실리콘으로 전환 시 비트코드 단에서 앱이 배포될 것으로 조심스럽게 생각할 수 있습니다. 그 이유를 몇 가지쯤 생각해볼 수 있는데요.

먼저 앱 스토어의 영향력 확대입니다. 맥 사용자 모두가 알고 있는 사실이지만, 앱 스토어에 등록된 앱은 애플이 직접 검수를 하므로 인터넷에서 배포되는 앱과 비교하면 보안 면에서는 매우 유리합니다. 애플은 지금까지 실제 의도가 어떠하든 일단은 보안성 향상이라는 목적을 내세워 맥 사용자가 앱 스토어에서 앱을 내려받을 수 있도록 유도해왔습니다.

여기서 비트코드는 큰 역할을 하게 될 것으로 보입니다. 개발자가 생성한 바이너리를 그대로 사용자에게 실행시키는 게 아니라 앱 스토어에서 바이너리를 생성하게 되면 보안 수준이 향상되는 건 분명하기 때문입니다.

게다가 최적화라는 부분도 생각해볼 수 있습니다. 기기마다 디스플레이 해상도와 CPU 아키텍처(armv7, arm64, arm64e 등)가 다른 아이폰 아이패드 OS 앱과 비교해본다면 맥은 모델마다 앱 최적화가 잘 되어 있다고 할 수 없습니다. 아마도 ARM/ 실리콘으로 전환 이후 아이폰과 아이패드와 비슷하게 앱 스토어의 비트코드에서 최적화된 바이너리를 생성하여 설치되는 형태로 변화하여도 전혀 이상하지 않을 것입니다. 
사실 macOS만 제외하고 iOS나 tvOS 등에서는 이미 그렇게 배포되고 있으니 언제까지고 맥만 예외가 지속한 채로 유지되는 게 더 이상하지요.

그리고 하나 더 언급하자면 '유니버셜 앱'을 들 수 있습니다. 요즘 유니버셜 앱이라고 하면 아이폰, 아이패드에서 모두 동작하는 앱을 지칭하는데요. 앞으로는 ARM 아키텍처를 사용하는 맥도 포함될 가능성이 제기됐습니다. 

macOS Big Sur에서는 UIKit을 확장하는 형태로 macOS, iOS 사이에 호환 레이어가 구현된다.


물론 아이폰/ 아이패드와 맥은 접근 가능한 하드웨어, 센서, 화면 크기 등에서 큰 차이를 보이고 동화되기 어려운 점은 분명히 있지만, WWDC 기조연설 슬라이드에서 보면 macOS Big Sur에서는 UIKit을 확장하는 형태로 macOS, iOS 사이에 호환 레이어가 구현되는 걸 알 수 있습니다.

이렇게만 보고 나면 ARM/ 실리콘으로 이주 시 당장이라도 비트코드를 활용하는 맥용 유니버셜 앱이 등장할 것으로 보이지만, 그렇지도 않습니다. macOS의 경우 비트코드를 지원하지 않는 서드파티 라이브러리를 사용하는 경우도 많은데 이 경우 iOS, padOS를 지원하지 않거든요. 맥용 유니버셜 앱이 등장한다 해도 앱 종류는 제한될 것입니다. 

이런 형태라면 맥에서는 유니버셜 앱과 맥 전용 앱을 사용할 수 있게 되어 마치 아이패드 상위 호환 취급받는 것처럼 보이기도 하는데요. 실제 이렇게 될 지 아니면 독자 포지션을 유지할지는 두고 봐야 할 것 같습니다.

이제 유니버셜 앱은 아이폰, 아이패드, 맥 모두 동작하는 앱을 지칭하는 게 되는 게 아닐까 싶기도...