“Apple Silicon”: Macintosh 역사상 네 번째의 아키텍처 대전환은 어떤 의미인가

Daniel Hong
18 min readJun 23, 2020

지난 새벽에 생중계된 WWDC 2020에서, 애플은 Macintosh의 역사상 네 번째의 아키텍처 전환을 발표했다. 첫 번째는 Motorola 68k에서 PowerPC, 두 번째는 Classic Mac OS에서 NeXT/UNIX 시스템 기반의 Mac OS X, 세 번째는 PowerPC에서 Intel (x86) 아키텍처의 전환이었다. 보통의 플랫폼 기업이라면 소프트웨어나 하드웨어, 둘 중 하나의 아키텍처도 전면적으로 변경하는 것은 결코 쉬운 일이 아니다 (Windows가 현재까지도 Win32 API의 레거시를 끌고 오고 있는 이유를 생각해보자). 하지만 애플은 이를 세 번이나 — 그것도 하드웨어와 소프트웨어에 걸쳐서 — 성공적으로 해냈고, 이제 네 번째의 아키텍처 대전환을 앞두고 있다. 바로 Intel (x86)에서 자체 개발한 ARM 프로세서, 즉 “Apple Silicon”으로의 프로세서 아키텍처 전환이다.

이를 두고 일각에서는 우려의 목소리가 나오고 있는데, 사실상 Mac이라는 “컴퓨터”를 “모바일” 위주의 칩으로 넘기면서 Mac 플랫폼만의 전문성과 미려함 등을 상실할 것이라는 예측이 주류인 듯하다. 더 이상 컴퓨터도 부품별로의 사양을 커스텀할 수 있는 것이 아닌, 마치 스마트폰을 고르듯 제조사가 제공하는 “제품”의 범주 내에서 머무르게 될 것이라는 우려도 있다.

하지만, 주류 플랫폼 공룡들의 탈-x86 움직임은 이미 수 년 전부터 분명했다. 단지 제대로 성공한 기업이 없었을 뿐이다. Microsoft도 최근 수십 년간 지속되어오던 “윈텔” 연합을 깨고 퀄컴 칩을 탑재한 Surface Pro X를 내놓았고, 그보다 한참 이전인 2012년에는 ARM 버전의 Windows 8인 Windows RT를 내놓아 지속적으로 인텔 칩에서 “탈출”하고자 하는 움직임을 보여왔다. 하지만 Windows RT는 처참하게 실패했고, Surface Pro X 또한 고전을 면치 못하고 있는 상태다. 원인은 단 하나, 앱 생태계였다.

현재 대부분의 “데스크탑” 레벨 앱들은 x86 아키텍처를 위해 빌드되어 있다. 지난 30년이 넘는 세월 동안 인텔과 x86이 시장의 절대 지배자였으며, PowerPC로 혼자 저항하던 애플마저 2005년 인텔 진영으로 투항하며 데스크탑 시장은 x86으로 사실상 통일된 상태였기 때문이다. 다른 프로세서 아키텍처로 코드를 이전하는 것에 들이는 노력에 비해 사용자가 그리 많지 않기 때문에, ARM 랩탑 및 PC 시장은 지난 8–9년 동안 거의 성장하지 못했다. 역시나 플랫폼의 닭과 달걀 문제에 빠져, 사용자가 필요로 하는 프로그램을 제대로 제공하지 못해 수요가 감소하고, 사용자의 수요가 감소하니 개발자들이 더욱 ARM 프로세서를 위한 프로그램을 개발할 동기를 느끼지 못하는 악순환이 반복되었다. 이를 해결하기 위해 Windows 10 for ARM에서는 Surface Pro X와 삼성 갤럭시 북 등의 ARM 탑재 랩탑을 위해 소프트웨어 x86 에뮬레이터라는 솔루션을 내놓았으나, 포토샵 같은 프로 앱은커녕 크롬 하나도 제대로 구동하지 못하는 모습을 보이면서 ARM의 데스크탑 진출 가능성에 의구심만 높이는 결과를 낳았다.

그렇다면, 애플은 이 난제를 어떤 방법으로 풀어나간다는 것인가? 애초에 인텔에서 ARM 아키텍처로 PC 시장을 넘기려는 의도는 무엇일까? 이 글에서는, 애플이 어제 발표한 최신 버전의 macOS인 Big Sur에서 어떠한 솔루션을 사용해 플랫폼의 닭과 달걀 문제를 극복하려 하는지 살펴보겠다.

“Performance per Watt”: 왜 굳이 전환하려 하는가

지금으로부터 15년 전, 애플의 WWDC 2005 행사에서 당시 애플의 CEO였던 스티브 잡스는 당시로서 다소 충격적이었던 발표를 한다.

“It’s time for a third transition, and yes, it’s true. We are gonna begin the transition from PowerPC to Intel processors, and we are gonna begin it for you now and for our customers next year.”

인텔로의 전환이 충격적이었던 이유는, 당시의 애플 팬들은 맥에 인텔 프로세서가 탑재된다는 것은 맥의 정체성을 잃어버리는 것이라고 생각했기 때문이다. 그도 그럴 것이, 인텔 칩과 표준 IBM 시스템은 애플의 맥을 제외한 모든 PC 제조사가 사용하고 있는 아키텍처였다. 애플마저 인텔 칩으로 넘어간다면, 맥이라는 제품에 남은 정체성이란 OS를 제외하고 무엇이 있단 말인가? (실제로 애플은 인텔판 Mac OS X이 “맥” 하드웨어에만 설치되도록 온갖 제한을 걸어놨지만, 해커들이 해킨토시(x86OSx)라는 이름으로 일반 x86 PC에 Mac OS X을 설치하는 것을 막지는 못했으며 이는 현재까지도 마찬가지다.)

이러한 반발을 누르기 위해 잡스는 Performance per Watt라는 개념을 들고 나왔다. 번역하자면 “전성비” 정도 되는 개념인데, 당시의 PowerPC 프로세서들은 개발 파트너였던 IBM과 모토로라의 개발 부진으로 인해 인텔 프로세서에 비해 모든 면에서 밀리고 있었다. 당시 최신이었던 G5 프로세서는 엄청난 발열로 인해 어마어마한 쿨링 시스템을 필요로 했으며 노트북에 G5를 넣는 것은 꿈도 꾸지 못했다. 공정, 전력 소모량, 발열, 성능 등 모든 면에서 인텔에게 밀리고 있는 상황이었기 때문에, 이를 “단순하게” 설명할 개념을 필요로 했던 것이다.

“전력 소모량당 성능”만큼 위의 모든 요소를 한꺼번에 압축해서 보여줄 수 있는 요소는 없다. 공정과 IPC가 뒤떨어지면 전력소모량과 발열이 늘어날 것이고, 발열이 늘어난다는 것은 성능 대비 전력효율성이 떨어진다는 뜻이며, 여기에 절대적인 성능까지 떨어지니 극적인 비교를 위해서는 이만한 기준이 없었던 것이다.

잡스는 이 그래프를 보여주며 인텔에게 PPC가 완패했다는 사실을 깔끔하게 인정했다.

어젯밤 애플이 들고 나온 것도 바로 이 Performance per Watt였다. ARM으로 이전하면 현재 인텔의 모바일 칩과 동등하거나 그 이하의 전력을 소모하면서, 인텔의 데스크탑 칩 이상의 성능을 보여줄 수 있다는 것이다.

이는 전혀 놀라운 사실이 아니며, 플랫폼 개발자라면 사실 누구나 이해하고 있는 점이기도 하다. ARM은 누구나 로열티만 내면 가져다 사용할 수 있는 “열린” ISA이다. 다시 말해, 하드웨어와 소프트웨어를 모두 개발하는 애플은 ARM 아키텍처를 수정하여 자신들의 소프트웨어에서 가장 잘 구동되는 하드웨어를 개발해낼 수 있다는 뜻이다. 또한, 본래 모바일 중심의 ISA로 출발한 ARM은 지난 수 년간 모바일 기기의 발전과 함께 비약적인 성능 발전을 보여 왔다. 칩에 가장 최신의 공정을 적용하는 곳은 더 이상 인텔이 아닌 애플과 퀄컴이다. 한술 더 떠서, 이미 애플의 아이패드 프로에 탑재되는 칩들은 싱글코어 절대 성능으로 이미 맥북 프로 16인치에 탑재되는 Core i9 제품군에 거의 근접했다. 이 점수에 아이패드에는 팬이 없고, 맥북 프로에는 팬이 있다는 사실 하나만 기억해 두자.

하이퍼쓰레딩을 사용해 멀티코어에서는 여전히 인텔이 앞서나가나, 애플 칩이 전성비를 앞세워 전력소비량과 발열을 조금 늘리는 대신 아키텍처를 데스크탑 전용으로 개조한다면 격차가 꽤 큰 차이로 벌어질 것이다

반면 인텔은 지난 5년 동안 14nm와 스카이레이크 아키텍처에서 거의 나아가지 못했으며, 거의 다 망해간다고 생각했던 같은 x86 진영의 경쟁사 AMD에도 밀리는 신세가 되었다. x86의 오래된 레거시도 또다른 골칫거리다. 1978년 출시된 인텔 8086의 명령어세트에 기반한 CISC 아키텍처를 현재까지 확장해 계속해서 새로운 옵코드를 붙여가며 사용하다 보니, 옵코드 디코딩 파이프라인이 지나치게 길고 복잡하다. 예전에는 압도적인 설계 우월성으로 RISC 아키텍처들을 제치고 절대성능과 전성비 모두에서 왕관을 차지할 수 있었지만, 아키텍처 개선과 공정 모두가 한계에 다다른 지금은 더 이상 그렇지 않다.

문제가 뭔지는 알았는데, 그렇다면 15년 동안이나 사용하던 — 그것도 다른 모든 제조사가 공용으로 사용하는 아키텍처를 — 어떻게 버리고 자체 칩으로 넘어갈 수 있다는 것인가? 재미있는 부분은 여기서부터 출발한다.

Universal 2와 Rosetta 2: 한 몸, 두 머리

2005년 애플은 맥을 PowerPC에서 인텔 칩으로 이전시킬 당시, 개발자들과 사용자들이 불편함 없이 새로운 아키텍처의 프로세서를 사용할 수 있도록 크게 두 가지의 솔루션을 내놓았다. Universal, 그리고 Rosetta다.

애플은 무려 15년 전에 처음 발표된 이들 솔루션의 이름을 관짝에서 꺼내, 각각 Universal 2와 Rosetta 2라는 이름을 붙이면서 맥의 “정통성”을 강조하는 전략을 사용했다. 다만, 15년이라는 세월의 차이가 있는 만큼 이 새로운 솔루션들은 기존의 UB/Rosetta보다 훨씬 더 앞선 방식으로 동작한다. 먼저 Universal 2부터 살펴보자.

Universal 2는 원래의 Universal과 마찬가지로, x86과 arm64 두 가지 종류의 바이너리를 모두 포함하는 단일 바이너리를 생성한다. 다만, 15년 전의 Universal과는 달리 다음과 같은 차이점이 있다.

  • Mac App Store를 통해 배포되는 앱의 경우, Universal 2 앱을 생성하면 Mac App Store가 자동으로 해당되는 프로세서 아키텍처의 바이너리만 골라 다운로드한다.
  • 다른 경로를 통해 배포되는 앱의 경우, 앱 파일 자체의 크기는 커지지만 macOS가 자동으로 해당사항이 없는 아키텍처의 바이너리를 청소한다.
  • 최신 API 타깃에 맞추어 개발된 Mac 앱의 경우, 앱 소스 코드 자체를 거의 수정할 필요 없이 대부분의 경우 재빌드만 해준다면 알아서 두 바이너리가 자동으로 생성된다.
  • LLVM 인프라를 기반으로 architecture-specific “binary slice”가 제공되는 방식이므로, 기존에 비해 바이너리 용량 부담이 크게 줄어든다.

3번의 경우, 15년 전 PPC/x86 전환 당시에도 Xcode 2.1에서 유사한 기능을 제공했지만 개발자가 어느 정도는 소스 코드를 수정해야만 했다. 반면 Universal 2에서는 소스 코드를 수정할 필요가 크게 줄어든다. 애플이 LLVM 컴파일러의 개발에 투자하며, 가상 머신 없는 네이티브 레벨에서의 플랫폼 독립성을 확보했기 때문이다. LLVM bitcode로 빌드되며 플랫폼 간 차이가 대부분 추상화되어 사라지므로, 로우 레벨 하드웨어에 접근하거나 완벽한 퍼포먼스 튜닝이 필요한 경우가 아니라면 대부분의 경우 코드를 거의 수정할 필요가 없다. 이와 관련해서는, 지난 3월에 LLVM 컴파일러와 bitcode, 그리고 애플의 App Store 바이너리 자동 재빌드 기법에 관련하여 작성했던 글에서 자세하게 서술한 바 있다.

x86 인텔 바이너리를 ARM 맥에서 구동할 수 있게 해 주는 Rosetta 2에서는 조금 더 이야기가 복잡해진다. Microsoft조차도 Windows 10에 x86-to-ARM Simulator를 집어넣었지만, 성능이 극도로 저하되는 문제로 사용자들의 외면을 받고 있는 처지이기 때문이다. 애플은 이 문제를 좀 더 똑똑하게 해결하는데, Universal 2와 마찬가지로 LLVM 컴파일러의 힘을 빌려 AOT (Ahead-of-Time)과 JIT (Just-in-Time) 기법을 모두 사용하는 것이다.

먼저 Mac App Store에서 배포되는 앱들은, ARM 맥이 본격적으로 출시되고 난 이후 시점부터는 Universal 2 바이너리의 형태로 강제로 ARM 바이너리를 지원해야 업데이트가 가능해질 것이기 때문에 크게 신경쓸 필요가 없다. 그럼 오랫동안 업데이트가 안 된 앱들은? 크게 두 가지 방법이 있다. App Store 서버에서 AOT Translation을 거쳐 ARM 바이너리를 생성해 제공하는 방법, 그리고 로컬에서 처리하는 방법이다. 서버에서의 AOT Translation은 재컴파일에 필요한 컴퓨팅 요구사항이 bitcode의 경우와는 달리 꽤나 크기 때문에, 실험적으로만 지원할 것으로 보이나 아직 확실치는 않다 (이와 관련된 상세한 내용들은 WWDC 이후 세션들에서 공개될 예정이므로, 상세 사항이 업데이트되는 대로 본 글을 수정할 예정이다).

App Store 바깥에서 배포되는 x86 앱들은, 마찬가지로 AOT Translation을 통해 설치 시 자동으로 ARM 바이너리로 변환된다. 다만 AOT 기법이 먹히지 않는 경우가 있으니, 바로 앱 그 자체가 JIT를 사용하는 경우다 (런타임, 가상화 등등). 이렇게 되면 바이너리 자체가 고정되지 않고, 프로세서에 전달하는 명령 옵코드가 매번 변경되기 때문에 사전에 ARM 바이너리를 생성하는 것이 불가능하다. 이러한 경우에만 제한적으로 실시간 x86 Translation을 사용하겠다는 것이다 (JIT를 위한 JIT). 즉 성능 저하가 상당히 있겠으나, 이런 류의 앱들의 경우 그 수가 많지는 않고 대부분 Universal 2를 통해 발빠르게 ARM 바이너리를 지원할 것이기 때문에 실제 ARM 맥이 소비자들에게 판매되는 시점에서는 크게 문제가 되지 않을 것으로 보인다.

…그런데, 대체 어떻게 이런 식의 AOT 전략을 매번 사용할 수 있었을까? 앞선 글에서도 언급했지만, LLVM은 단일 컴파일러가 아닌 컴파일러 인프라 프로젝트다. 즉 다시 말해, LLVM IR을 생성하는 프런트엔드와 백엔드만 있으면 사실상 출발지와 도착지에 제한이 없다는 뜻이다. 그렇다면, 필요한 프런트엔드 코드만 있다면 프런트엔드에서 x86 바이트코드를 받고, 백엔드에서 ARM 바이트코드를 반환해도 무방하다는 의미이다. LLVM의 빌드 절차를 그대로 따라가기 때문에 직접 번역하는 것보다 오히려 최적화 수준이 더 높다. 물론 LLVM만을 사용하는 것은 아니고 추가적인 최적화 기법을 더 사용하나, 결론적으로는 다른 기업의 솔루션과는 달리 성능 저하 거의 없이 ARM 맥에서 x86 앱을 사용할 수 있다는 것이다.

이렇게 해서, Universal 2와 Rosetta 2, 그리고 애플 특유의 플랫폼 장악력이 합쳐져, 사실상 x86 레거시 앱들을 ARM 맥에서 사용하고 네이티브 바이너리로 이전하는 데에는 거의 장애물이 없다고 보아도 무방하다. 사용자 입장에서는 아무것도 못 느낄 가능성이 높다. “It Just Works”가 이런 데서 빛난다.

가상화와 Windows 사용

일반적인 사용자 입장에서는 사용상의 거의 모든 문제가 해결되었다. 이제 남은 건 크게 두 가지다. Boot Camp와 개발자들이 사용하는 가상화다.

ARM 맥에서의 Windows 지원에 관해서는 현재까지 언급된 바가 전혀 없다. 이 또한 실제 ARM 맥이 시판되는 시점이 되어서야 구체적인 해결책이 나올 것으로 보인다. Microsoft 측에서 Windows 10 for ARM에 애플 ARM 칩의 비표준 아키텍처에 대한 지원을 추가해준다면 가능할 수도 있어 보이지만, 이렇게 해서 설치한 윈도우는 우리가 찾는 (특히 한국에서) “그” 윈도우가 아니라는 사실을 상기할 필요가 있다.

Apple Silicon Mac에서는 부트 정책에 더욱 더 엄격한 제한이 걸린다. iOS에서 사용되던 칩을 그대로 가져왔으니 못할 것도 없다. 듀얼 부팅을 어디까지 허용할지 또한 지켜보아야 할 것으로 보이나, 설사 듀얼 부팅 혹은 가상화를 통해 Windows를 설치했다 하더라도 현재 Windows 10 for ARM의 x86 바이너리 지원은 처참한 수준에 가깝다. 돌아가긴 하지만, 실시간 바이너리 변환이라 크롬 하나조차 버거워한다. 한국산 각종 플러그인이나, 아래아한글 같은 것들은 말할 것도 없다. 거기다 가상 머신 위에서 구동되는 Windows라면? x86 프로그램의 실행은 포기하는 것이 정신건강에 좋을 것이다. (…) 결론적으로, 아직까지 철저히 윈도우 위주인 한국의 인터넷 환경에서는 은행이나 공공기관 업무를 보기 위해 x86 Windows PC를 별도로 하나 마련해놓아야만 할 것으로 보인다. 과거 PowerPC 시절로 되돌아가는 것이다. 다만, 현재 한국 내 맥 사용자 수는 PowerPC 시절과 비교도 되지 않을 정도로 급증했기 때문에 목소리를 내기에는 과거보다 훨씬 수월할 것이고, 이를 통해 공공 인터넷 환경이 보다 개선되기를 기대해 보는 수밖에는 없겠다. 이 문제 때문에 인텔 맥에서 버티는 사람들도 꽤 있을 것으로 예상한다.

그렇다면, Linux 가상화나 Docker와 같은 컨테이너 솔루션은 어떨까? 아무 문제 없이 구동된다. 애플은 WWDC 키노트에서도 다음과 같이 Docker와, Parallels를 통한 리눅스 가상 머신이 아무 문제 없이 실행됨을 시연했다.

애플은 OS X Yosemite (10.10)부터 샌드박싱 내 환경에서 가상화를 지원하는 Hypervisor.framework라는 프레임워크를 지원해 왔다. 이를 사용하면 Mac App Store에서도 가상 머신을 실행할 수 있는 앱을 배포할 수 있다 (Parallels Desktop Lite 등이 이런 경우이다). 인텔 프로세서에서는 기본값으로 VT-x를 사용하지만, Apple Silicon에서는 직접 ARM의 가상화 명령어세트를 드러내지 않고 “공식적인” 경로인 Hypervisor.framework on Apple Silicon을 사용하도록 하고 있다. 즉 가상 머신 내에서 실행될 수 있는 위험한 코드가 샌드박스의 경계를 넘지 못하도록 강제하는 것인데, 이것은 다음에서 설명할 ARM 맥의 보안 정책과도 연관이 있다.

다만, ARMv8-A 이상에서는 AArch64/AArch32(like ARMv7-A execution state)의 네이티브 가상화만을 지원하기 때문에, 가상 머신 안에서 구동되는 OS와 Docker 이미지들도 당연히 ARM으로 컴파일된 버전이어야 한다. 아직 ARM 바이너리로 빌드되지 않은 리눅스 패키지들이 상당히 많기 때문에, 이 부분 또한 하루빨리 개선되어야 할 것으로 보인다.

iOS 앱 실행과 Apple Silicon에서의 신규 보안 정책

ARM 맥은 그 어느 때보다도 iOS 기기와 닮았다. 같은 아키텍처의 칩을 공유하고, App Store에서 배포되는 iOS나 iPadOS 앱을 그대로 실행할 수도 있다. (실제로 Developer Program 약관이 iOS 앱이 Mac에서 구동되는 것을 임의로 막을 수 없다는 내용이 추가되어 개정되었다.) 이는 기존의 Catalyst보다 한 단계 더 나아간 것으로, 애초에 같은 프로세서 아키텍처를 공유하기 때문에 App Store에서 배포되는 iOS 바이너리를 iOS Simulator처럼 UIKit 상에서 돌리기만 하면 그대로 구동된다.

또다른 변경사항은 iOS와 비슷한 수준의 하드웨어 레벨 샌드박싱이 적용되었다는 것이다. 기존 인텔 맥에서도 T2 칩이 서브시스템을 담당하면서 데이터를 보호했지만, T2가 직접 앱의 실행 과정에 관여할 수는 없었다. 이제부터는 애플 칩이 앱의 실행까지도 관장하기 때문에, 앱별로 macOS Security Policy를 분리해서 설정하고 하드웨어 레벨에서 메모리 접근을 차단하는 것이 가능하다.

보안 측면에서는 물론 환영할 만한 변화이지만, 맥의 iOS화가 점점 가속되면서 “데스크탑” OS에서의 자유를 점점 빼앗기는 것을 우려하는 목소리도 나오는 듯하다. 이와 관련한 사항도 직접 실제 제품을 조사해보아야 확실하게 알 수 있을 것으로 보인다.

결론: 강력한 컴파일러, 강력한 칩, 빼앗기는 자유

세간의 우려와는 달리, 애플의 프로세서 전환은 아무런 문제 없이 매끄럽게 이루어질 것으로 보인다. 컴파일러의 힘으로 x86 레거시에서의 전환을 매우 쉽게 만들었고, 특유의 플랫폼 장악력으로 하드웨어와 소프트웨어를 하나로 묶어 더 매끄러운 사용자 경험을 만들었으며, 인텔 칩보다 더 나은 성능을 제공하고 훨씬 더 현대적인 아키텍처로 이행할 수 있는 기반을 만들었다.

문제는 이 과정에서 사용자의 자유가 계속해서 구속된다는 점이고, 이와 관련하여 맥을 떠나가는 사용자도 상당수 있을 것으로 보인다. 데스크탑 PC의 프로세서 레벨에서 부트로더 코드서명을 체크하고, 메모리 접근권한을 직접 제어하고, 중요 시스템 파일에의 접근을 원천적으로 차단하는 것은 시스템 튜닝이 필수적인 전문가(특히 개발자나 해커)들의 원성을 살 가능성이 높기 때문이다.

결국 “PC란 정확히 무엇인가?”라는 질문이 다시 나와야 할 시점이 아닌가 싶다. 필요한 데스크탑-클래스 “앱들”만 구동되고 “앱들 사이”의 워크플로우만 원활하다면 그걸 데스크탑 PC라고 부를 수 있을까? 혹은 시스템을 마음대로 건드릴 수 있어야 데스크탑이고, 나머지는 스마트폰이나 태블릿 같은 임베디드 시스템에 가깝다고 불러야 할까? 현대적이고 모듈러하지만 사용자 제한적인 아키텍처가 반드시 모두에게 바람직할까?

PC가 모두에게 필수적인 도구가 되면서, 사용상의 목적을 달성하기만 한다면 전혀 불만을 가지지 않는 사람들이 전문가들을 포함한 PC 사용층의 대다수가 되었고, 커스텀을 통해 보다 많은 가능성을 끌어내고자 하는 사람들은 점점 소수로 전락하는 모양새다. 전자에게는 보다 엄격한 보안 환경이 워크플로를 지키는 데에 유리하겠지만 후자에게는 하드웨어의 가능성을 제한하는 족쇄일 뿐이고, 이러한 사람들을 위한 대안은 — PC가 점점 모바일의 영역으로 넘어가면서 — 계속해서 축소되고 있다.

iOS와 동일한 ARM 칩으로 전환하는 매킨토시 플랫폼의 구조를 리뷰하며, 어떤 사람들에게는 다소 암울할 수도 있는 컴퓨팅의 미래를 보고 온 것 같다.

--

--

Daniel Hong

🌈(🇰🇷,🏳️‍🌈) bitcoiner since 2008 | hobo @nonce_community | building universes