애플에 관심이 많은 분들은 이미 다 아는 내용 일 겁니다.  

그래서 이 글의 내용은 100% 뒷북 내용이고 신선한건 없을 겁니다.

제 생각이 꽤 많이 들어 갔을 뿐 입니다. 뻘글임을 감안해주세요.

 

 

---

 

서로 다른 ISA를 가진 프로세서가 있을 때 특정 프로세서 전용으로 작성된 소프트웨어 바이너리는 다른 종류의 프로세서에서 작동하지 않는 호환성 문제가 있습니다. MS는 Surface Pro X라는 녀석으로 쓴 맛을 좀 많이 봤습니다. 왜냐하면 ARM에선 수많은 윈도우즈 레거시 프로그램과 호환되지 않았고 드라이버도 터지고 ARM64 지원하는 프로그램도 적었습니다. 예뮬레이션은 느렸고 윈도우즈 폰이 이미 고인이라 MS도 손놨고 그저 Surface Pro X을 장난감삼아 학대하려는 변태들만이 있을 뿐이죠. 윈도우즈 폰이 망하지 않았으면 MS도 잘했을 겁니다. 이제 애플 이야기를 좀 해보죠. 애플이 주제니까요.

 

 

1994 - 1996	모토로라->	PowerPC
2001 - 2003	Mac OS 9->	Mac OS X
2006 - 2007	PowerPC->	Intel

 

애플은 이미 3차례나 변환을 해봤습니다. 모토로라에서 PowerPC 프로세서로 전환할 때는 M68K용 에뮬레이터가 있었고 PowerPC에서 인텔x86으로 전환할 때는 그보다 많은 준비와 노력이 있었습니다. 인텔로 변환할 때 로제타(Rosetta)가 가장 중요할 것 입니다. 애플은 크로스 플랫폼과 관련된 기술을 가진 Transitive이라는 스타트업과 협업끝에 애플은 그 회사 기술(QuickTransit)에 로제타(Rosetta)라는 이름을 붙였습니다. 에뮬레이션 환경을 통해 PowerPC와 인텔간 호환성 문제를 어느정도 해결했죠. 당연하게도 에뮬레이션을 해야 된다는 점에서 프로세서가 바로 구동하는 것 보다 느리지만, 만들기 까다로운 동적 변환 기법을 통해 어느정도 쓸만한 성능을 얻을 순 있었습니다. Fast (enough). 그 당시에 저 정도면 꽤 성공적이라고 말할 수 있죠. 그래서 사람들이 성공적이라고 평가합니다. 또 9에서 X으로 변환할 땐 Classic 이라는 녀석을 통해 Mac OS X 상에서 OS 9 레거시 앱을 사용할 수 있었습니다. PPC 프로세서 기반 맥들은 Mac OS X Tiger 10.4 까지 지원했습니다.

 

 

애플은 인텔 프로세서를 버리고 ARM 아키텍쳐로 한 차례 더 변환을 하려고 합니다. 앞서 에뮬레이션을 통해 프로그램을 실행할 수 있고 그게 당시엔 쓸만 했지만 실행이 가능하다는 것이지 기기 퍼포먼스에 최적화됐다는 의미가 아니라는 것을 봤습니다. 따라서 진정한 의미의 통합이라고 할 수 없고 진정한 의미의 통합이란 에뮬레이션이랑은 성격이 다를 것 입니다. 이번에 애플이 하려는건 대충 에뮬레이션이나 만들어 넣은 다음에 아이패드 앱이 Mac에서 잘 돌아갑니다! 따위 수준이 아닙니다. 

 

 

제가 알기로 아마 WWDC 2015에 애플전용 IR이 생겼습니다. 이것이 bitcode 입니다. iOS 9부터 앱을 올릴 때 bitcode를 제출하면 애플 서버 측에서 프로세서 호환성에 알맞는 바이너리를 알아서 제공해줍니다. ARM 아키텍쳐 간 이동이 자동으로 이루어진다는 말은 ARM과 x86 간의 이동도 가능하다는 것 입니다. iOS 뿐 아니라 Mac OS는 LLVM 으로의 이전이 끝난상태입니다. LLVM을 통해 어떤 플랫폼으로도 빌드할 수 있습니다. 레거시를 포함한 모든 종류의 앱들 까지 죄다 완벽 호환은 아니지만 결국 현 시점 앱스토어에서 받을 수 있는 앱들은 무리없이 높은 호환성을 보장할 것 이라는게 제 생각입니다. 이게 이렇게 간단한거였어? 가 아니라 LLVM 덕이며 앱스토어로 통제하고 폐쇄적으로 꽉 잡고 있는 애플이라서 가능한 겁니다. 

 

 

이제 저런면을 염두해두고 다른 이야기를 해볼게요. 이것도 역시나 전부 다 이미 아는 내용들 일 겁니다.

 

맥북 노트북에 프로세서가 인텔에서 ARM로 바뀐다. 그럼 하위 호환성은 어쩔거냐? 의 문제는 사실 위에 설명했듯 애플 입장에서는 별로 큰 문제는 아닙니다. 고려를 안하거든요. 일각에선 맥북과 아이패드가 합쳐진다? 터치스크린이 생기는건가? 라곤 하는데 애플은 노트북과 태블릿을 어거지로 합치지 않고 맥북은 맥북, 아이패드는 아이패드로 철저히 구분하려고 합니다.

 

통합적인 의미에 있어서 진짜 문제는 소프트웨어 통합과 사용자 환경에 관한 겁니다.

 

애플 애플리케이션 UI 개발에는 플랫폼 형태와 사용 방법에 따라서 프레임워크가 제공하는 기능이 다르게 주어집니다. Mac 용 애플리케이션의 GUI는 AppKit로, iOS 앱의 GUI는 UIKit로 개발합니다.(애플 시계들은 WatchKit) 사실 통합하는데 이것부터가 문제점입니다. 하드웨어가 있는데 하나는 노트북이고 하나는 태블릿입니다. 키보드+마우스 환경 앱 만드는거 따로, 터치 인터페이스 앱 만드는거 따로 만들어야죠. 둘은 구분됐고 게다가 애플 생태계에선 Mac보다 훨씬 더 막강한 모바일 생태계가 있기 때문에 애초에 아주 큰 회사가 아니라면 Mac 용도로 만들 생각도 안합니다. 그렇게 Mac OS 생태계는 소외됩니다.

 

따라서 진정한 의미의 통합에 있어 애플이 직면한 문제는 어떻게 개발 생산성을 올려줄 것이냐에 대한 문제고 따라서 애플은 개발자와 사용자 모두에게 더 나은 통합 환경을 제공하기 위해, WWDC 2018에서 각 프레임워크의 객체를 싸잡아 통합한 SwiftUI을 공개하고 가이드라인을 제시한 바 있습니다. SwiftUI의 컨셉은, 앱 하나 개발할 때 Mac 용, 아이패드 용, 아이폰 용 한방에 다 찍어내라는 컨셉이었는데 중요한 건 뭐냐면 결국 그래봐야, 대규모의 작업용 소프트웨어가 아니고서야 여전히 Mac용 앱들은 소외당했습니다. 잘 안만들어요. 왜냐면 아이패드용 앱 만드는게 더 낫거든요.

 

아이패드 앱 만드는게 더 나으니까 애플은 생각을 다르게 해봅니다. 그러면 프론트엔드는 똑같으니까 백엔드만 Mac 환경에 맞게 바꾸면 되잖아?라는 생각이요. 아이패드 앱 가지고 Mac OS 환경에 알맞게 되도록 바꿔주기만 하면 되잖아. 그게 마지팬(Marzipan)의 시작입니다. 그 Marzipan이 진화한게 카탈리스트(Catalyst) 입니다. 카탈리스트는 꽤 의미심장 합니다. 이건 소프트웨어 개발 측면에서 장벽.. 장벽 까진 아니고 귀찮은 벽을 무너뜨리는 행위입니다. 물론 애플이 최초는 아닙니다. 유니버설 윈도우 플랫폼(UWP)도 있죠. 윈도우즈 폰이 관짝행이라서 그렇지만요.

 

제 생각에 만약 카탈리스트가 제대로 자리잡으면 맥북에 굳이 뜨겁고 전기도 많이 먹는 불덩어리 x86이 들어 갈 이유가 하나 더 없어집니다. 수 많은 아이패드 앱들이 Mac 환경에 적합한 인터페이스를 가지고 대규모로 유입 될거라 생각합니다. 즉 애플이 취하는 이 전략은 요즘 대세인 크로스 플랫폼이죠. 애플만의 이야기가 아닙니다. 아 물론 한계도 있죠. 레거시 지원은 개나 줘라 입니다. 애플은 레거시 신경 안씁니다. 레거시 신경 쓸 바에 기기 한대라도 더 팔아먹고 싶은 회사라. 그리고 애초에 저러한 행보들이 레거시 지원은 개나 줘라를 전제로 하기 때문에 가능한거죠.

 

 

 

 

 

여기까지가 애플의 행보였고 시대별로 정리 해봤습니다.

생략된 것도 많고 설명도 두서없지만 여기서 더 길게 썼다간 지루해져서 이 정도로만 하겠습니다.

 

하여튼 읽어주셔서 감사합니다.

 

결론적으로 애플은 생각보다도 더 강력한 소프트웨어 회사가 맞습니다.