요즘 Apple silicon을 탑재한 맥에 대한 시장의 반응이 좋은것 같습니다. 저 또한 주변의 극한의 애플 까 친구들이 이번 맥에만큼은 호의적인 반응을 보이는 현상을 목격했구요. 애플이 Arm mac을 출시한 것은 수년 전 Power PC에서 Intel로 이주했을때 이상의 파괴력을 보여주고 있다고 봅니다. 그동안 애플이 시장에서의 위상이 높아진 것도 한 몫 했겠지만, 통합적으로 하드웨어 아키텍쳐 전반을 설계하는 회사로까지 거듭난 애플의 다음 행보에 대한 기대감도 당연히 큰 비중을 차지한다고 봅니다.
저는 이 시점에 Apple의 앞으로의 행보를 예측해 봤습니다. 전문성은 하나도 없고, 저의 좁은 식견과 관심사 안에서만 쓰여진 글이라는 것을 감안하고 읽어주시면 감사하겠습니다. 당연히 태클과 비판은 환영입니다!
0. 먼저, TL;DR
1. Apple은 이름으로 권력을 유지하는 회사다.
위에서 말씀드린 극한의 애플 까 친구들이 항상 하는 이야기 중에 하나가 이겁니다.
왜 애플은 항상 자기만의 이름을 붙이는 거냐, 이거 완전 감성 마케팅으로만 승부하는 거 아니냐
뭐... 나름 의미가 있는 지적입니다. 사실 시장에서 흔히 쓰이는 메인보드, 웹캠, 해상도-디스플레이 종류와 같은 세부 하드웨어 네이밍을 쓸수도 있는데 애플은 항상 지독하리만치 자신들의 명명법을 유지해 왔죠. 이를테면 웹캠이 아니라 FaceTime camera, 메인보드 대신 Logic Board, SSD가 아니라 플래시 스토리지, 고해상도 디스플레이가 아니라 Retina display와 같은 것들이 있습니다(가만 보면 로직보드는 최근에 들어본 일이 별로 없는 것 같기도 하네요).
여기서 중요하게 봐야할 것은 '그 효과가 무엇이냐'일 것입니다. 먼저 감성적인 부분 또한 분명히 존재하는 효과고 무시할 수 없는 부분이겠죠. 저는 '감성 마케팅'이라는 비하적인 수식어를 '거부감 감소' 와 '직관성' 이라는 이름으로 고쳐 쓰고 싶습니다. 소비자들에게, 특히 전 세대의 Apple 디바이스를 갖고 있는 소비자들에게 새로운 세대의 하드웨어를 판매하기 위해서는 이전에 비해서 무엇이 좋아졌는지 어필해야 하고, 그러다 보면 필연적으로 하드웨어에 대한 말 또한 피할수 없다고 봅니다. 여기서 기존의 하드웨어 명명법을 사용하는 것은 도움이 되지 않는다고 봅니다. Apple 제품을 마케팅하기 위해서 소셜 서비스에서의 영상, Apple 브랜딩 페이지는 지금과 같은 공공보건이 위협받는 시대에 더더욱 중요해졌죠. 소비자들의 눈길을 끌어야 하는 곳에 이런 저런 복잡한 외계어에 가까운 단어로 점철된 브랜딩은 이목을 끌기 힘들 것입니다. 오히려 거부감을 불러일으키겠죠. 조금 더 친숙한 단어들로 개념을 표현하고, 그에 걸맞는 이미지를 배치함으로서 소비자들에게 표현해 이해를 도모하고, 노출의 기회를 최대한 잘 활용하는 데서 의미가 깊다고 봅니다. 예컨대 Retina display는 '고해상도'라는 추상적인 단어 대신 '망막' 이라는 간접적이지만 구체적인 이미지를 끌고 들어왔고, '망막'이 '자연'의 '이미지 장치'라는 것은 이성적으로는 떠올리기 힘들지만 본능적으로 떠오르는 관념입니다. 애플은 이를 통해서 추상적인 수치 제시 없이도 '고해상도'라는 관념 자체를 소비자한테 전달하는 데 성공합니다.
두 번째 이유부터가 지금 쓰는 글의 핵심적 주제로 넘어가는 도약인데, 그것은 이 문단의 제목으로도 설정한 '권력 유지'입니다.
애플은 하드웨어와 그 위에 올라가는 소프트웨어 솔루션, 이를 바탕으로 한 서비스로 수익을 얻는 회사죠. 소프트웨어와 서비스는 본인들이 직접 만드는 것이니 당연히 외부 회사에 휘둘릴 일이 거의 없지만, 하드웨어는 이야기가 다르죠. 별다른 물질적 투자 없이도 만들 수 있는 소프트웨어와 서비스에 비해 하드웨어는 생산 라인의 필요, 회사별로 갖는 기술의 차이 등의 문제로 인해 현실적으로 애플 혼자만이 개발하기가 함들죠(소프트웨어가 뚝딱 만들어지는 것이다로 오독하지는 말아주세요! 소프트웨어와 하드웨어 사이에 생산 방법론의 차이가 있다는 것만 말씀드리는 것입니다). 그래서 애플은 좋든 싫든 다른 회사들과 협력을 이뤄야 하고, 별 수 없이 슈퍼 을이 될지도 모르는 기업들과의 관계라는 리스크를 져야 합니다. 당연히 애플 입장에서는 이런 위험을 최소화하고 싶겠죠.
여기서 문제가 발생합니다. 별 수 없이 다른 기업과 관계를 맺을 수 밖에 없는데 그 리스크를 최소화하고 싶다. 애플은 어떻게 이 문제를 해결할까요? 저는 놀랍게도 그 답 중 하나가 애플의 명명법에 있다고 봅니다.
애플에 그래도 어느정도 관심있는 사람들이라면, 혹은 심지어 일반인이라도 레티나 디스플레이, A칩셋 등은 어느 정도 들어 본 작명입니다. 또 새로운 아이폰 시리즈에는 재생 알루미늄을 사용했다는 것 또한 유명한 사실이죠. 하지만 레티나 디스플레이가 매번 어떤 회사에서 만들어지는가, 혹은 애플의 A시리즈 생산라인은 어떤 회사의 것을 사용하는가, 재생 알루미늄을 개발한 회사가 포스코라는 사실까지 아는 일반인은 흔치 않습니다. 이 정도 기술력은 애플조차도 쉽사리 자체 생산라인 안에 끌고 들어오기 힘듭니다. 애플은 대안적으로 이들을 자사 제품들의 브랜딩에서 철저히 배제함으로서 '대체 가능성'을 확보했다고 봅니다. 조금 쉽게 이야기하면 '맘에 안 들면 언제든 갈아치울 수 있는 소비재'로 전환한 것이죠. 특히 애플이 이런 전략을 취한 제품들이 In sourcing으로 경영을 더 효율화하기 힘든 부문 디스플레이나 금형 등의 부문에 대해서만 수행한다는 것도 눈여겨볼 사항입니다. Apple이 요구하는 기술 혁신과 가격 최적화의 기준이 높기는 하지만, 애플 제품 판매의 한 부분이 됨으로서 얻게 될 수익을 내걸고 수많은 회사들이 경쟁하게 할 수 있는 부문이요. 실제로 낮은 재생 알루미늄의 수율을 끌어 올리고 가격을 최적화하기 위해 포스코는 어마어마한 기술 혁신을 해 냈죠. 하지만 애플은 끝끝내 포스코가 브랜딩 권력을 갖게 하는 것은 불허합니다. 이것은 곧 애플이 추후에 가격 협상력 등에서 디스어드밴티지를 감수해야 한다는 것을 의미하니까요. 회사 간 권력 싸움에서 절대로 불리한 틈새를 허용하지 않은 것입니다.
제가 그래서 애플을 싫어한다고 생각지는 말아주십시오(참고로 저는 MacBook Pro 16', Apple watch Series 5, iPhone XS, iPad Pro 4'th gen, AirPods Pro등을 사용하고 있습니다). 저는 애플의 기업으로서의 전략을 보는 것이 무척 흥미롭고, 그들이 취한 전략이 무척 영리하다고 느낍니다. 무엇보다 브랜딩을 통해 전략적 위험을 분산하고 약점을 최소화한 점이 그렇다고 느낍니다. 물론 지금까지의 제 가설이 맞다는 가정 하에서지만요.
아무튼, Intel은 몇년째 CPU 부문에서 죽을 쑤고 있었습니다. 차세대 공정으로의 전환은 실패했고, 특히 모바일에서 중요한 전력과 발열 관리에서도, 성능 향상에도 실패했으며 더욱이 아키텍쳐 설계상의 결함으로 인한 보안 문제와 이로 인해 소프트웨어 단에서 추가적으로 성능을 하락시킬 수 밖에 없는 조치를 강제로 취해 이미지에 스스로 쐐기를 박아버렸습니다. 애플의 전략에 비춰 봤을 때에 자신들의 브랜딩을 애플 제품에 남긴 몇 안되는 회사인데도 불구하고(심지어 본인들의 i시리즈 세그먼트 브랜딩과 세대 구분을 허용받은 회사였는데도 말이죠), Intel은 본인들의 문제에서 비롯된 문제건 아니건 점점 애플의 요구사항인 저전력화, 특수기능 지원 등에 있어서도 점점 소극적인 자세로 바뀌었습니다. 애플 입장에서는 자사의 브랜딩으로 전환하지 못한 마지막 고리가 점점 득보다 실이 커진다고 느꼈을 겁니다. 그래서 이번 세대에서 마침내 이들을 전환하죠. 기존에 이미 존재하던 브랜딩에 Apple Silicon이라는 새로운 카테고리를 추가하면서 말입니다.
2. 왜 Apple Silicon을 신설했나.
사실 애플은 이미 본인들의 칩 브랜딩을 갖고 있었죠. 아이폰과 아이패드에 쓴 A 시리즈, 애플 워치의 S 시리즈, 음향기기를 위한 W 시리즈와 그 후속작 H 시리즈, 타 진영에서 TPM이 수행하던 기능을 확장 수행하는 T 시리즈 등. 애플은 여기에 맥에 쓰이는 M 라인업을 추가했습니다. 고작 라인업 하나가 더 추가되었을 뿐인데 애플은 자체 칩셋 전체를 Apple Silicon이라는 별도 카테고리로 정리했습니다. 왜 그랬을까요?
결국 애플이 명백히 답을 내놓은 것이 없으니 추론할 수 밖에 없습니다. 먼저 Intel과의 결별 자체에 모멘텀을 주기 위해서라는 해석이 가능합니다. 애플이 지금까지 아키텍쳐를 갈아치운 전례를 보면, 이전 아키텍쳐의 비효율성을 어마어마하게 비판하면서 본인들과 선을 긋습니다. 그러면서 새로운 라인업에 엄청난 칭찬을 합니다(이전에 x86으로 전환할 때 애플에게 그렇게 전성비 등에서 인텔이 칭찬받았단 걸 생각하면 아이러니하네요). 기업 입장에서 신제품을 홍보하는 것은 당연한 전략입니다. 다만 성능 향상만 칭찬하면 되었고 생산 주체가 달라지지 않았던 아이폰 등의 타 제품의 칩셋에 비해, M 시리즈에서는 다시 한 번 애플의 제품임을 강조하고 타사와의 결별을 선언하는 데 힘을 줄 필요가 있습니다. 애플의 향상된 시장에서의 지위를 생각한다면 더더욱 그렇죠. 그래서 인텔과의 결별을 강조하고, 새 제품이 잘 뽑히기도 했으니 기존 애플 칩셋들도 새로운 브랜딩을 적용해 개별 칩셋으로 분산된 이해가 필요한 라인업을 Apple Silicon이라는 브랜딩 하에서 역할에 따라 Naming에 Prefix를 부여하는 것으로 전체 브랜드를 재정립하고 시너지 효과를 노린다는 것 하나로도 사실 충분히 설명이 됩니다.
그런데 여기서 한 가지 납득되지 않는 사실이 있습니다. 애플이 차세대 칩 전략으로 자체 생산을 택했다면 이해되지 않는 사실 말이죠. 몇몇 분들은 Catalina에서부터 점점 AMD 칩셋의 코드들이 macOS에서 발견되고 있다는 사실을 아실 겁니다. 사실 GPU라인업 코드들만 추가되는 것이라면 CPU와는 별개로 볼 수도 있지만, CPU에 관련한 코드들도 점점 추가되고 있죠. 점점 AMD CPU를 쓰는 맥들의 해킨이 쉬워지는 추세도 이와 무관하지 않다고 봅니다(물론 세부 사항은 저도 더 읽어보지 않았지만...). 이런 변화 기조는 사실 Apple Silicon으로의 전환과 밀접한 관련이 있는 Big Sur에서도 유지되고 있죠. Big sur에서의 Navi 시리즈 칩에 대한 정보 추가는 사실 어느 정도는 예견되었지만, 그렇다면 Cezanne APU 관련 코드는 발견될 필요가 없었거든요. CPU, 혹은 호스트 프로세서는 필요가 없을 테니 말입니다. 왜, AMD CPU에 관련한 코드도 계속해서 추가되고 있는 것일까요?
애플이 Apple Silicon 이라는 네이밍을 선택한 데에 힌트가 있다고 봅니다. 저는 애플의 브랜드 네이밍 전략이 권력 유지와 밀접한 연관이 있다고 앞서 분석했습니다. 애플은 놀라울 정도로 자신들의 새 Mac 칩에 대해 ARM이라는 아키텍쳐를 직접적으로 언급하는 것을 의도적으로 피하고 있습니다. 혹시 WWDC 발표에서 애플이 'ARM 칩'이라는 단어 언급하는 거 들은 기억 있으신 분 있나요? One More Thing 행사에서는요? ARM 칩을 사용한다는 소식을 재생산하는 것은 IT 언론과 대중입니다. 애플 자신이 아니라요. 물론 대중의 이해를 위해서라는 해석도 가능합니다만, x86 아키텍쳐와 결별을 선언하고 이것이 기업에게도 사실 중요한 전략이 될 수 있음에도 불구하고, 이를 언급하는 것이 분명히 시장에서의 효과가 있을 것임에도 불구하고(특히 개발자들을 대상으로 한 문서 등에서는 더더욱요), 애플은 이것을 피하고 있습니다.
저는 이것이 의도된 바라고 생각합니다. 애플은 x86 아키텍쳐와의 결별을 택한 것이 아니라고 분석하고 있습니다. 정확히는 Intel과 결별했죠. One More Thing 행사에서 애플은 Intel을 맹비난했습니다. 그들의 전력낭비를 비판했고, 잠자기-깨어나기 간의 비효율성, I/O 속도의 느려터짐 등을, 자사 제품 담당의 치프들을 앞세워 영상으로 정성들여 시각화했죠. 그리고 아예 Intel이라는 단어를 대놓고 화면에 띄워버립니다. 저는 기업이 자사 제품을 대중 앞에서 선보이는 데 이 정도의 마케팅을 했다면 그건 타사 면전에 대고 쌍욕한거나 다름 없는 수준이라고 생각합니다. 실제로 애플 입장에서는 자신들의 약점이었고 걸림돌이었던 Intel을 털어낸 것이 무척 후련하기도 했을 겁니다. 그런데, 우리 여기서 잊지 말아야 할 것은 Apple이 냉혹할 정도로 시장에서 현명하게 움직이는 기업이라는 사실입니다. 애플이 단지 후련해서, 마냥 Intel을 욕하고 싶어서 그랬을까요?
가설을 하나 세우겠습니다. Apple이 필요에 따라 ARM, x86 칩을 병행하며, 대규모의 사양이 중요한 제품에는 AMD에서 생산한 x86 제품을 사용하며, 전력공급이 제한되어 전성비가 중요한 제품군에는 ARM 명령어 셋을 기반으로 설계한 하드웨어를 사용하고, 이들 전체에 Apple Silicon이라는 브랜딩을 부여한다는 전략을 검토중이라는 가설입니다. AMD가 지금에나 되어서야 리사 수라는 걸출한 경영자를 다시 한번 더 만나 시장에서 찬사받고 있다고 하지만, 브랜딩 관점에서 보면 인텔과 같이 직관적인 i 시리즈와 같은 네이밍 전략도 없고, 하이테크 칩을 생산함을 바로 인식시킬 수 있는 로고도, 인텔과 같이 수없이 대중에게 노출된 시그널 사운드도 없습니다. 제품은 충분히 훌륭하지만, 하드웨어에 큰 관심이 없는 일반 대중의 인식이 그에 걸맞진 않죠. 놀랍게도, 애플의 입맛에 딱 맞는 회사입니다. 좋은 기술력을 가졌으며, 최근의 성과는 훌륭한데 비해 브랜드 권력은 약한 편이라 자신들의 브랜딩 하에 둘 수 있는 기업 말이죠. Super Retina Display와 삼성 간의 관계와, Apple Silicon과 AMD 사이의 관계를 유사하게 설정할 수 있다고 봅니다.
여기에는 최근 AMD의 전략 또한 연결된다고 봅니다. 최근 AMD는 Microsoft(Surface, Xbox), Sony(PlayStation), Google(Stadia), 이미 위에서 이야기 해 온 Apple(Mac GPU)에 각각 CPU, GPU, 혹은 APU를 다양한 제품군에 제공하고 있고, 각 회사의 요구사항에 맞춰 커스터마이징도 훌륭하게 잘 해 줬죠. Nvidia도 충분히 훌륭한 회사지만 애플이 Nvidia와 결별한 데에는 단순한 하드웨어 전략의 격차 뿐 아니라 서드파티와 소프트웨어 플랫폼에 대한 영향력까지 전반적으로 고려한 이유가 있다고 봅니다. Nvidia는 잘 아시듯 CUDA를 자신들의 차세대 사업 전략으로 밀고 전력투구해 왔습니다. 그래픽카드에 탑재되는 그래픽 전문 처리장치 GPU에, CPU에서는 상상도 못할 데이터 처리를 맡기는 기술 GPGPU의 가능성을 시장에 사실상 최초로 납득시킨 기업이며(여기서 현대적인 인공지능 시장이 열렸죠. 혹시 모르실 분들을 위해 알파고와 구글 검색 등의 제품도 GPGPU 없었으면 태어나지 못했을거라고 말씀드리면, 그 위상이 짐작되리라 생각됩니다), Geforce NOW로 일반 대중에게 제공하는 최종 서비스도 준비하고 있죠. 반면 애플이 자사의 게임 전략들에 필요하다고 생각하는 Metal API에 대한 커스터마이징 요구에 회의적이었습니다. 대조적으로 AMD는 Nvidia가 성공한 모든 차기 플랫폼 사업부문에서 실패했고, 결과적으로 하드웨어와 밀접한 연관이 있는 소프트웨어 플랫폼에 대해서는 위 회사들에 일임하고, 본인들은 자신들만이 해결할 수 있는 문제에 집중했고 재기에 성공했습니다. Apple Arcade와 같은 서비스를 장기적으로 준비하던 애플 입장에서는, 다른 회사에 비춰봤을 때도 본인들의 전략을 더 잘 수용할 가능성이 큰 AMD로 전환하는 것이 당연하고도 합리적인 전략이었겠죠. 이렇게 봐야 Apple이 자체 내장이야 그렇다손 쳐도 eGPU 시장을 고려하면 Nvidia에서 매 제품에 대해 인증비용 받으면서 서드파티 그래픽 드라이버 열어주는 것도 수익 측면에서 나쁘지 않음에도 불구하고 계속 Nvidia의 그래픽 드라이버를 허용하지 않는 이유가 합리적으로 설명된다고 생각합니다. 그리고 ARM이 전통적으로 저전력 환경에서의 전성비라는 기저 내에서 성능을 올렸지만, x86은 가능한 최대의 성능을 이끌어내는 것을 기본 방향으로 삼는다는 것을 보면, 이런 전략이 나름대로 합리적이라고 생각합니다.
3. 그게 가당키나 한 일일까? 그리고, 효율적인 일일까?
컴퓨터에 대해서 잘 아시는 분들일수록 머리 속에서 물음표가 뜰 것이라고 생각합니다. 어떤 회사건 서로 다른 하드웨어 아키텍쳐를 품는 일은 쉬운 일이 아니고, x86과의 고성능 중심 제품에서의 성능격차는 시간이 해결할 것이며, Apple 입장에서 추후에 다시 한번 자신들의 약점이 될 가능성이 있는 타사를 확실하게 잘라내는 것이 더 안정적이지 않은지 충분히 생각하실 수 있습니다. 매우 합리적인 지적입니다. 그리고 이에 대한 제 반론도 지금부터 제시하겠습니다.
첫 번쨰로, 하드웨어 중립적인 아키텍쳐에 대한 부분입니다. x86과 ARM 아키텍쳐 병행이 지극히 비효율적일 것이라는 비판이죠. 사실 가장 결정적이고도 합리적인 질문인데, 애플은 이에 대한 해결책을 이미 갖고 있고, 이는 놀랍게도 모바일 경쟁사인 구글도 동등하게 가진 해결책입니다.
저는 앱 배포체계 제한과 LLVM 채용이 결정적인 해결책이라고 봅니다
저 위 두 가지를 설명하기 위해서는 macOS 10.7 시절부터의 이야기와, 애플과 GNU 진영 간의 해묵은 갈등까지 끌고 들어와야 합니다. 자, 안그래도 분량 폭발하는 글이 더 길어질 테니 침착하게 물을 한잔 하고 오셔도 좋습니다(다시 한번 죄송합니다!).
애플이 OS X 10.7 Lion 에서 iOS의 앱 스토어 정책을 맥으로도 갖고 오신거 기억나시나요? 그 당시에야 여전히 맥은 개발자나 진짜 애플 팬들, 일상적인 업무 처리하는 사람들이나 쓰는 제품인데 거기서 새 앱 플랫폼을 여는 건 너무 나간 정책 아니냐는 지적도 받았죠. 실제로 그 지적이 무색하기만 한 건 아니었다고 봅니다. iOS의 App Store에는 200만개 수준의 앱이 있는데 Mac App Store에는 여전히 10만을 넘어서지 못하는 앱들이 있었으니까요. 하지만 이후로 macOS의 운영체제 보안 모델이 변화하는 것을 보면 당시 애플이 다소 무리를 해서라도 App store를 맥에까지 끌고 들어왔는지 추리할 수 있습니다.
애플은 맥에 차근차근 시스템에서 허용할 앱의 출처(즉 사이닝), Rootless, 앱별 권한 설정, 보안 칩과 같은 기능들도 추가해 왔습니다. 소비자들을 malicious한 앱으로부터 보호한다는 목적을 위해서도 타당하지만(물론 Rootless나 T2와 같은 정책은 여전히 실효성과 권한 남용에 대해 논쟁이 있는 정책이긴 하지만요. 이것도 추후에 기회가 닿으면 풀어 보겠습니다), App store로 Mac의 앱 배포체계를 통합한다는 목적이 있다면 여기에도 굉장히 합리적인 방법론입니다. 여기서 애플은 중요한 권한 하나를 더 갖게 되는데, iOS 뿐 아니라 macOS에도 본인들의 입맞에 맞는 정책을 밀어붙일 수 있는 권한이 바로 그것입니다. 뭐 애플 아케이드나 macOS의 생체인식 기술(keychain-T2에 기반하는)도 물론 충분히 이 권한으로 밀어붙일 만한 정책이지만, 최근 애플이 개발자들에 요구하는 정책과 LLVM을 살펴본다면 새로운 가능성이 열립니다.
드디어 LLVM 이야기입니다. 오늘 한 이야기 중에서 가장 난이도 높은 챕터로 들어가네요. 전통적으로 프로그래머의 코드를 실행가능한 앱으로 변환하는 컴파일러로 많이 쓰인 것은 GCC였습니다. 애플도 LLVM 이전에는 GCC를 사용하고 있었습니다. 그런데 GCC는 GNU라는 진영의 작품이고, 해당 진영은 상당히 Free Software적 정신이 강한 진영입니다. 프로그래머들이 해결해야 할 공통의 문제를 가장 빠르게 해결하는 것은 코드를 공유하는 것이라는 실용주의 노선에서의 개방을 강조하는 Open Source 진영의 개방성보다 좀 더 정치적인 논조가 강한, 소유라는 악에 저항하는 시대정신으로서 소프트웨어 코드 공유를 주장합니다. 이들의 정신을 가장 잘 담는 것이 GNU 진영의 소프트웨어 코드에 적용되는 GPL이라는 라이선스인데, 핵심만 말하자면 이 코드를 가져다쓴 프로젝트는 모든 소스코드를 풀어야 하며, 해당 프로젝트에는 자동으로 GPL이 다시 적용되는 라이선스입니다. GNU 진영의 수장 리처드 스톨만의 작품이죠. 애플은 해당 라이선스로 업데이트된 GCC를 보이는 버전만 몰래 수정한 채 OS X에 탑재하면서 리처드 스톨만이 모르기를 간절히 기도했지만, 안타깝게도 이 일은 애플을 거대한 송사에 휘말리게 합니다. 결국 애플은 자사 개발 플랫폼 정부의 일부를 공개할 수 밖에 없었고, 애플은 GCC를 대체할 컴파일러를 찾아 나서게 되고 결과적으로 LLVM을 발견하게 됩니다.
LLVM은 컴파일러의 핵심 구조입니다. 그 자체로 C나 C++, Swift, Kotlin 같은 언어를 컴파일하는 것이 아니라, 훨씬 낮은 레이어에서 중간 기계어를 다루는 컴파일러의 핵심 구조이자 체계입니다. 각 언어의 개발자는 컴파일러에서 Swift, Kotlin과 같은 고급 언어를 LLVM이 사용하는 중간 기계어로 변환하는 부분만을 만들면 되고, Intel이나 Arm과 같은 회사는 이 중간 기계어를 각 회사에서 규정하는 기계어로 변환하는 부분만 작성하면 됩니다. 눈치채셨을지 모르겠지만, Java와 같은 언어에서 주창한 JVM의 개념과 다소 비슷한 면이 있습니다. 차이가 있다면 LLVM은 그걸 앱 실행 전에 컴파일하는 시점에 다 끝내버린다는 거고, JVM은 기본적으로 앱을 돌리는 와중에 그 작업을 한다는 점이구요. 애플은 이 프로젝트를 UIUC 대학원 연구실에서 찾았고, 그 연구자들과 함께 이걸 오픈소스로 풀었으며(GCC를 쳐부순다는 야망과 함께 말이죠), 그 결과 현재 새로 시작되는 언어 프로젝트는 거의 LLVM을 중심으로 돌아가고 있습니다. 심지어 애플과 결별한 Nvidia도 CUDA를 위한 컴파일러는 이걸 써서 만들어요. 그리고 무려 Google도 Android 용 앱 개발환경으로 최근에 LLVM을 사용합니다.
이 이야기를 왜 하는지 궁금하실 수 있습니다. 바로 iOS 앱을 최종적으로 Xcode로 애플에 전송할 때 바로 이 LLVM 중간 명령어를 전송하기 때문입니다. 모바일 하드웨어가 데스크톱에 비해 얼마나 빠르게 발전하는지 다들 보셨잖아요. 당연히 수많은 파편화와 레거시가 등장했습니다(심지어 애플도 말입니다!). 이걸 핸들링하기 위해서 애플과 구글 모두 LLVM 바이트코드(위에서 말한 중간 기계어입니다)를 각 회사의 앱 처리 서버에 개발자들이 제출하도록 하고, 최종 사용자의 장치에 처리할 때 각 CPU의 기계어로 다시 한 번 컴파일하는 과정을 거칩니다. 실제로 이 작업은 거의 1:1 변환이라 개발자가 컴파일하는 것 만큼 오래 안 걸려요. 물론 각 회사의 앱 처리 서버에서 미리 처리하는 것도 가능하구요. 아, 참고로 애플은 이 중간 기계어에도 Bitcode라는 별도의 이름을 붙입니다. 안드로이드는 각 CPU 아키텍쳐에 대응하는 중간 기계어, 라이브러리와 해상도에 대응하는 그래픽 자원들을 통합해 App Bundle이라는 이름을 부여했지만, 애플은 중간 기계어에 Bitcode, 라이브러리와 해상도를 통합해 제출한 다음 사용자 디바이스에 필요한 자원만 보내는 전체 과정 자체에 App Thining이라는 이름을 부여합니다. 눈치 채셨겠지만, 이미 프로그래밍 언어 -> Bitcode는 Swift, Objective C를 통한 애플 플랫폼에서의 개발을 위해 준비되어 있고, Bitcode -> x86과 Bitcode -> Arm 모두 당연히 개발되어 있습니다. 남은 것은 macOS와 iOS의 기본 기능성 차이에서 오는 운영체제 내장 API 정도인데, 이걸 통합하는 것 또한 App Store를 통해 정책을 강제하고 운영체제 제작사의 지위를 활용해 솔루션도 제공할 수 있습니다. 이 전체 솔루션이 Rosetta 2, Universal Binary 2라고 보면 얼추 맞을 것 같습니다. 길게 말씀드렸지만 요약하자면 애플은 이미 여기에 대한 솔루션을 갖고 있다 정도로 요약할 수 있을것 같습니다.
다음으로, Apple 정도 되는 회사라면 Arm 아키텍쳐와 x86 아키텍쳐 간의 성능 규모 차도 극복할 수 있지 않겠느냐는 지적인데, 저는 그래도 이건 좀 힘들다고 봅니다. 하드웨어 아키텍쳐를 규정하는 것은 애플이 이미 사실상 재설계한 부분인 하드웨어 설계이기도 하지만, 그 하드웨어 위에서 돌아가는 기계어이기도 하거든요. 그런데 애플도 라이선싱해 쓰고 있는 Arm에서는 명령어를 함부로 수정하는 것 만큼은 불허합니다. 그런데 Arm은 앞서 말씀드렸다시피 근본부터 전성비에 근간을 두고 나온 아키텍쳐거든요. 하드웨어에서 구동되는 명령어와 메모리를 다루는 방식에서도 당연히 x86과 방법론에 차이가 있습니다. 지금에야 와서야 서버시장도 넘본다고 하지만 그렇다고 모바일 시장을 버릴 수도 없습니다. 따라서 근본적 격차를 해결하기가 힘들기 때문에 저는 이 방법론도 다소 힘들다고 봅니다. 거기다 애플에 협력할 리가 만무한 Nvidia가 Arm의 모기업이 된 걸 생각한다면 더더욱요. 애플이 하드웨어 기계어부터 재설계하면 되지 않겠냐고 말씀하실 수 있겠지만, 그게 더 효율적이라고 판단했다면 애플은 진작에 Arm에서 기계어만 쓰고 하드웨어는 재설계할 능력이 있는데 자사 아키텍쳐를 사용했겠죠. 아마 기업 입장에서 효율성이 높지 않을 겁니다.
마지막으로 AMD가 애플의 또 다른 약점이 될 수도 있지 않냐는 지적에는, 그럼에도 애플이 Arm이라고 하는 협박용 카드를 갖고 있다는 것과 AMD가 그동안 보여준 역사로 설명을 대신할 수 있을 것 같습니다. 물론 애플이 아직 확답을 낸 건 없고, 검토 단계에서만의 이야기로 설레발을 친 것일 수도 있지만, 최근 애플이 낸 Apple Silicon mac에서 저사양 라인업까지만 출시하고, Mac Pro나 Macbook Pro 16인치야 출시주기상 그렇다 쳐도 iMac Pro 발표도 안 한 것에 대해서도 좀 더 납득할만한 설명을 제공한다고 생각합니다. 이것으로 긴 글을 마침내 끝낼 수 있겠네요. 오랜만에 돌아와서 x86 글 열람 권한이나 다시 받아야겠다 생각하고 잠깐 두들긴 타자가 이렇게 길어질 줄은 몰랐습니다. 다음에 좀 더 가벼운 글로 돌아올 수 있었으면 좋겠네요. 다들 코로나 안 걸리고 건강하게 지내시길 바랍니다. 좋은 하루 되세요!
저도 AMD가 최근에 라이젠으로 브랜딩을 정리하면서 브랜딩에도 신경을 신경쓰기 시작했고, ryzen에 각 세대 브랜딩, 세대 내 라인업 정리도 해 냈다고 생각합니다. 다만 여기서 말한 일반 소비자는 지포스가 뭔지 모르고, 라데온이 뭔지도 모르는 말 그대로의 일반 소비자를 대상으로 한 것입니다. 그리고 소비자 인식이 별로라는 이야기는, 부정적 이미지가 있다기 보다 일반 소비자가 아예 존재 자체를 모른다 쪽에 더 가깝습니다. 저는 여전히 intel이 그래도 이 부분에서는 잘 했다고 생각합니다(엔지니어링을 말아먹은것과는 벌개로요). 그리고 오해하실지도 몰라 미리 말씀드리면, 최근에 친구 컴퓨터는 전부 다 AMD CPU 제품으로 넣을 정도로 AMD를 긍정적으로 평가중이랍니다.
좋은 견해 감사드립니다!
엄청난 식견 공유에 감사 드립니다. 실제로 시절이 지나서 말씀 하신 방향으로 갈지 아닐지 모르지만 저는 고개를 끄떡이며 보았네요.
몰랐던 과거 내용도 알게 되어 좋았습니다. 캬!!!
어조가 정말 애플이랑 똑같으시네요. 공식 홈페이지에 애플에서 발표한 글이라고 해도 믿을 것 같습니다.
다만, 이렇게 될 가능성이나 그렇게 이상적일 가능성은 높지 않을 거 같네요. LLVM은 요술봉이 아니고, 네이밍 브랜딩은 광고에나 애플체라는 말투로 등장하며, 이미 항상 그래왔던 것처럼 레거시는 다 버려질 겁니다. 아마 아무리 애플이 디자이너 우위, 개발자 학대(?) 기업이더라도 그런 미친 짓을 하기엔 쉽지 않지 않을까요.
컴파일과 에뮬레이팅, 아키텍처 등을 혼동하시는 것 같은데, 하드웨어, OS라는 레이어 위에서 돌아가는 응용 프로그램 계층이야 로제타2라는 에뮬레이터와 LLVM 컴파일러 수준의 최적화로도 문제 없기 때문에 이기종 타아키텍처에 이식하는게 그렇게 죽을 만큼 어렵지는 않습니다. 그러나 애플 입장에서는 이야기가 전혀 달라집니다. 왜냐하면 애플은 OS를 만들어야 하기 때문입니다. 현대 운영체제들은 성능을 조금이라도 높이기 위해서 아키텍처마다 종류, 이름, 작동방식이 다른 어셈블리 코드로 최적화하는데, 동일한 OS를 다른 아키텍처에 업데이트때마다 포팅하라고 하면 개발자들이 반란 일으켜서 애플이 망할 겁니다.
그나마 드는 생각은 차라리 ProOS쯤 되는, AMD 고성능 프로세서를 장착한 워크스테이션/서버 전용 운영체제 라인을 신설할 것 같다는 생각이 드네요. 이게 훨씬 현실적입니다.
"님의 댓글"
이 댓글을 신고 하시겠습니까?
제목 | 조회 수 | 날짜 | 글쓴이 |
---|---|---|---|
Apple macOS UniversalMac_Sequoia 15.2 beta2(24C5057p) 24/10/2... | 28 | 24.10.2413:18 | 제로섬 |
Apple Release Candidates 소식 24/10/21일자 | 298 | 24.10.2204:03 | 제로섬 |
Apple public update Releases 소식 (10/04일자) | 459 | 24.10.0409:21 | 제로섬 |
비 지원 맥용 OpenCore-Legacy-Patcher 2.0.2 다운로드(24/09/29... +6 | 2.7만 | 23.06.0413:37 | 제로섬 |
Safari_18.1_for_macOS_Sonoma(619B22)&Ventura_beta_4(619B2... +2 | 337 | 24.09.2014:03 | 제로섬 |
windows & macOS / Install macOS Sequoia beta7 15.1_24B50... | 340 | 24.09.2005:24 | 제로섬 |
세퀘이아 15.0.1 정식(24A348) 전체 프로그램(24/10/04일자) up +4 | 564 | 24.09.1704:38 | 제로섬 |
windows & macOS / Install macOS Sequoia 정식 15.0.1_24A34... | 1005 | 24.07.1806:01 | 제로섬 |
Apple macOS UniversalMac_15.0.1 정식 (24A348)복원IPSW (24/10/... +3 | 476 | 24.09.1020:58 | 제로섬 |
macOS Sonoma 14.7.1 RC3 (23H221) 전체 프로그램 다운로드(24/10... +2 | 708 | 24.08.3015:43 | 제로섬 |
macOS Ventura 13.7.1 RC3 (22H220) 전체 프로그램 다운로드(24/1... | 493 | 24.08.3016:24 | 제로섬 |
windows & macOS / Install macOS Sonoma RC3 14.7.1_23H221... +1 | 5222 | 23.10.1211:27 | 제로섬 |
windows & macOS / Install macOS Ventura RC3 13.7.1_22H220... +1 | 8093 | 23.10.1213:08 | 제로섬 |
Apple M1/M2/M3 macOS Sequoia 15.1 RC (24B82)복원IPSW (24/10/2... | 420 | 24.08.1320:14 | 제로섬 |
Apple Public Releases for 소식 24/08/07일자 | 446 | 24.08.0809:53 | 제로섬 |
macOS Sonoma 14.6.1 정식 (23G93) 전체 프로그램 다운로드(24/08... +4 | 1073 | 24.07.3018:28 | 제로섬 |
macOS Ventura 13.6.9 정식 (22G830) 전체 프로그램 다운로드(24/... | 535 | 24.07.3018:21 | 제로섬 |
macOS Monterey 12.7.6 정식 (21H1320) 전체 프로그램 다운로드 (... +2 | 532 | 24.07.3018:04 | 제로섬 |
Apple Public Releases for 소식 24/07/29일자 +3 | 359 | 24.07.3014:14 | 제로섬 |
Apple, macOS 15 Sequoia 공개 정보 +2 | 3288 | 24.07.0716:59 | 제로섬 |
Safari_18.0.1_정식 설치프로그램_macOS_Sonoma(619A64a)&Ven... +1 | 2695 | 24.07.0619:09 | 제로섬 |
Apple M1/M2/M3 macOS Sonoma 14.6.1 정식 (23G93)복원IPSW (24/0... | 2574 | 24.06.1811:51 | 제로섬 |
Safari_17.6_for_Ventura&Monterey 정식 설치 프로그램 24/07... +1 | 4048 | 24.04.0717:28 | 제로섬 |
windows & macOS / Install macOS Sonoma 정식 14.6.1_22G93.... +1 | 3981 | 24.04.0520:26 | 제로섬 |
windows & macOS / Install macOS Ventura 정식 13.6.9_22G83... | 3766 | 24.04.0521:40 | 제로섬 |
windows & macOS / Install macOS Monterey 정식 12.7.6_21H1... | 3808 | 24.04.0522:27 | 제로섬 |
윈도우 11 23H2 ISO 다운로드 가능 +2 | 1.6만 | 23.11.0423:27 | Mactopia |
Windows에서 macOS 부팅 가능한 USB를 만드는 방법 +16 | 1.9만 | 23.10.0711:52 | 제로섬 |
windows & macOS / Install macOS Big Sur 11.7.10_20G1427.d... | 2.2만 | 23.07.2512:50 | 제로섬 |
여친 없는 엑팔인들을 위한 스팀 게임 몇 가지 나눔 합니다. +27 | 6.7만 | 23.03.0220:10 | 잠퉁이 |
최신 Windows 다운로드 +12 | 4.6만 | 21.10.1703:35 | Dokdo |
윈도우 필수 유틸 #1 - Hoax Eliminator 구라 제거기 +4 | 4.5만 | 21.08.1017:08 | Mactopia |
우분투 서버 설치하기 +3 | 3.5만 | 21.06.0404:29 | 매킨어렵 |
39 | 24.10.2404:44 | 잠퉁이 | |
39 | 24.10.2401:11 | 잠퉁이 | |
38 | 24.10.2401:09 | 잠퉁이 | |
19 | 24.10.2400:59 | 잠퉁이 | |
28 | 24.10.2413:18 | 제로섬 | |
46 | 24.10.2301:14 | 잠퉁이 | |
85 | 24.10.2300:56 | 잠퉁이 | |
54 | 24.10.2300:53 | 잠퉁이 | |
73 | 24.10.2203:47 | 잠퉁이 | |
70 | 24.10.2203:42 | 잠퉁이 | |
298 | 24.10.2204:03 | 제로섬 | |
71 | 24.10.2102:59 | 잠퉁이 | |
51 | 24.10.2102:57 | 잠퉁이 | |
63 | 24.10.2023:18 | 잠퉁이 | |
94 | 24.10.2000:56 | 잠퉁이 | |
90 | 24.10.2000:52 | 잠퉁이 | |
55 | 24.10.1900:55 | 잠퉁이 | |
170 | 24.10.1902:01 | 잠퉁이 | |
52 | 24.10.1901:58 | 잠퉁이 | |
51 | 24.10.1900:36 | 잠퉁이 | |
59 | 24.10.1900:30 | 잠퉁이 | |
71 | 24.10.1900:27 | 잠퉁이 | |
66 | 24.10.1802:23 | 잠퉁이 | |
82 | 24.10.1802:20 | 잠퉁이 | |
52 | 24.10.1802:17 | 잠퉁이 | |
93 | 24.10.1802:15 | 잠퉁이 | |
108 | 24.10.1800:04 | 잠퉁이 | |
75 | 24.10.1800:00 | 잠퉁이 | |
66 | 24.10.1701:42 | 잠퉁이 | |
58 | 24.10.1701:40 | 잠퉁이 | |
77 | 24.10.1701:37 | 잠퉁이 | |
79 | 24.10.1701:35 | 잠퉁이 | |
79 | 24.10.1608:47 | 잠퉁이 | |
207 | 24.10.1612:14 | 제로섬 | |
69 | 24.10.1600:07 | Dokdo | |
108 | 24.10.1501:02 | 잠퉁이 | |
74 | 24.10.1402:49 | 잠퉁이 | |
78 | 24.10.1402:46 | 잠퉁이 | |
80 | 24.10.1402:42 | 잠퉁이 | |
88 | 24.10.1302:48 | 잠퉁이 | |
105 | 24.10.1302:05 | 잠퉁이 | |
68 | 24.10.1212:19 | Nelson | |
133 | 24.10.1201:46 | 잠퉁이 | |
102 | 24.10.1201:40 | 잠퉁이 | |
72 | 24.10.1122:06 | 잠퉁이 | |
108 | 24.10.1104:53 | 잠퉁이 | |
74 | 24.10.1104:43 | 잠퉁이 | |
65 | 24.10.1104:47 | 잠퉁이 | |
70 | 24.10.1104:35 | 잠퉁이 | |
71 | 24.10.1103:23 | 잠퉁이 | |
74 | 24.10.1103:21 | 잠퉁이 | |
68 | 24.10.1103:19 | 잠퉁이 | |
92 | 24.10.1003:28 | 잠퉁이 | |
100 | 24.10.1000:50 | 잠퉁이 | |
104 | 24.10.1000:47 | 잠퉁이 | |
82 | 24.10.1000:45 | 잠퉁이 | |
73 | 24.10.1000:41 | 잠퉁이 | |
78 | 24.10.1000:35 | 잠퉁이 | |
73 | 24.10.0904:41 | 잠퉁이 | |
92 | 24.10.0902:02 | 잠퉁이 | |
63 | 24.10.0901:59 | 잠퉁이 | |
51 | 24.10.0901:56 | 잠퉁이 | |
69 | 24.10.0901:54 | 잠퉁이 | |
52 | 24.10.0818:43 | 잠퉁이 | |
38 | 24.10.0818:42 | 잠퉁이 | |
81 | 24.10.0800:35 | 잠퉁이 | |
67 | 24.10.0800:33 | 잠퉁이 | |
69 | 24.10.0800:31 | 잠퉁이 | |
114 | 24.10.0805:25 | 제로섬 | |
77 | 24.10.0701:02 | 잠퉁이 | |
51 | 24.10.0700:57 | 잠퉁이 | |
65 | 24.10.0700:48 | 잠퉁이 | |
47 | 24.10.0700:52 | 잠퉁이 | |
52 | 24.10.0700:45 | 잠퉁이 | |
38 | 24.10.0700:41 | 잠퉁이 | |
82 | 24.10.0600:37 | 잠퉁이 | |
54 | 24.10.0600:34 | 잠퉁이 | |
65 | 24.10.0504:02 | 잠퉁이 | |
70 | 24.10.0503:59 | 잠퉁이 | |
94 | 24.10.0503:57 | 잠퉁이 |
세줄요약
1. 애플에서는 애플실리콘을 ARM이라고 언급하지 않았다
2. 인텔을 버린거지 x86아키텍쳐를 버린게 아니다
3. AMD는 인텔i시리즈 같은 자신들만의 확고한 네이밍이 없는,애플의 입맛에 맞는 회사다
대충 이런것 같은데 최근 3년간 라이젠을 밀고오면서 라이젠 3, 5, 7, 9 라인업을 널리 알렸습니다
견적짤때도 보면 ‘라이젠 5정도 쓰시면 됩니다’라던가 ‘그래도 작업하시는데엔 라이젠7정도는 쓰셔야죠’같은 말들이 이제는 거부감 없이 받아들여지고 있습니다
게다가 Zen2아키텍쳐부터는 상위라인업에 엄청난 코어를 때려박으면서 컨슈머용 시스템에서는 최강이란 소리도 듣고있구요
인텔이 8코어 넣고있을때 AMD는 16코어를 넣었으니...
그런면에서 봤을때 AMD가 브랜딩 전략이 약하다거나 제품에 비해 소비자 인식이 별로라는 부분은 공감이 되지 않네요
라이젠 알바 아닙니다
저도 인텔씁니다ㅎㅎ