개발자 입장에서 가볍게 써보는 M1 맥 미니 사용기

애플이 자체 M1 칩을 탑재한 M1 맥 미니를 발표하고 미국 동부 표준시 기준 당일 저녁에 바로 주문을 넣고 11/28(토)에 M1 맥 미니를 집에서 수령하게 되어 지금까지 사용해본 후기를 남겨보려 합니다.

주의: 졸린 상태에서 쓴 글이라 의식의 흐름대로 작성했습니다.‌‌
우선 맥 미니를 산 이유를 말씀드리면: 모니터 2개 연결하려고요.‌
램을 왜 16기가로 올렸냐면: 평소 인텔 맥에서도 램을 20기가 넘게 써서요.

성능

아마 많은 분들이 가장 많이 궁금해하시는 부분이 바로 이 '성능' 부분이 아닐까 생각합니다. 인터넷에 이미 많은 벤치마크가 올라와 있으니 이 글에서는 '체감 성능'을 이야기해보겠습니다.

일단 개발 업무를 많이 하다 보니 평소 띄워져 있는 프로그램은 다음과 같습니다:

• 슬랙 (Workspaces 4개)
• Bear (노트 앱)
• ElasticMQ Server (AWS SQS 호환 서버)
• Redis Server
• Postgresql Server
• Spark (이메일 앱)
• WireGuard (VPN 앱)
• Sublime Merge (Git GUI 클라이언트)
• Visual Studio Code (가벼운 작업용)
• WebStorm (node 작업용, 프로젝트 3개 오픈)
• 기타 개인 메신저: 카카오톡, Telegram, LINE, Discord

위에 적어둔 프로그램과 웹 브라우저(Safari)까지 띄워두면 보통 10GB+ 정도의 메모리를 사용합니다.

메모리 업그레이드가 최대 16기가까지 가능한 것을 보고 인텔 맥에서 16기가 메모리를 쓰면 굉장히 부족하게 느껴졌던 그 경험 때문 + 그래픽 메모리까지 통합되어 있어 외장 모니터까지 연결하면 성능이 어마어마하게 떨어지지는 않을까 걱정을 많이 했었는데요. 실제로 사용했을 때의 느낌은 예상과 전혀 달랐습니다. 평소 집에서 4K 모니터 두 대에 연결하여 Looks like 2560x1440 (실제 렌더링 해상도: 5120x2880, 5K)로 사용하는데 맥북 프로 16인치에 있는 RX5300M dGPU와 RX570 eGPU를 모두 사용해도 뜨겁게 달아오르고, 이륙하고, WindowServer 점유율이 치솟으며 GUI가 버벅였는데 M1 맥은 4K 두대를 같은 모드(5K x 2)로 사용해도 전혀 버벅임이 느껴지지 않았으며 칩의 온도는 꾸준히 30~40도를 유지하고 팬 소음도 전혀 들리지 않았습니다. 팬 소음은 약간 과장 보태서 샤오미 공기청정기 2s를 최저 회전속도로 두었을 때의 소음과 비슷하거나 더 적은 수준입니다.

더 놀라웠던 부분은 Unified Memory로 바뀌어서인지 모니터를 추가로 연결해도 기존 모니터가 깜빡이지도 않고, 모니터 해상도를 바꾸어도 깜빡임이나 버벅임 없이 정말로 즉시(immediately) 화면이 바뀌는 부분이 굉장히 인상적이었습니다. 이 부분은 아래 영상으로 대신 설명해봅니다.

via GIPHY

벤치마크 성능상으로는 싱글코어는 젠3와 동급 또는 약간 낮은 수준, 멀티코어는 모바일 젠2 라이젠과 비슷한 수준인데 이게 정말 벤치마크로 이야기할 수 없는 무언가가 있습니다. 빠릿함이라던가, 앱 실행 속도, 컴파일 속도, 영상 재생 능력 등이요.

개발자다보니. IntelliJ는 아직 JBR이 준비 중인 상태라 Rosetta 2로 돌려야 해서 성능이 많이 떨어지는 탓 – JVM JIT 때문인지 성능이 못써먹을 정도로 느립니다 – 에 VSCode를 잠시 사용하고 있는데요. VSCode 실행 속도는 아래 영상으로 대신 설명합니다. 둘 다 모두 동일하게 103개의 확장 플러그인이 설치되어 있으며 같은 설정이 되어있는 상태입니다:

via GIPHY

이외에도 arm64 대응이 되어있는 Slack Beta, Notion 등의 앱의 속도 또한 위 VSCode 실행 속도 비교와 비슷하게 기존 인텔 맥과 비교도 안되는 속도를 보여줍니다.

Rosetta 2 & ARM Ecosystem

미리 요약해서 말씀드리면, 정말 Seamless합니다. 호환성 걱정할 필요가 없어요. 웬만한 앱은 다 잘 돌아갑니다. 심지어 Rosetta 2로 번역하는 과정을 거치는데도 불구하고 인텔 맥에서보다 체감상 더 빠르게 돌아가는 앱도 많습니다. 단 SBT(Static Binary Translation) 앱에 한해서만 인텔 맥과 크게 차이 안 나는 성능을 보여주고, DBT(Dynamic Binary Translation, 예로 JVM JIT/V8 JIT/luajit 등)가 필요한 경우에는 실시간으로 번역하는 과정을 거치기 때문에 속도 하락이 꽤 체감되기도 합니다.

ARM 대응은 크게 걱정할 필요 없을 것 같습니다. 애플이 LLVM에 어마어마한 투자를 하기도 했고(2020년 현재 LLVM을 제일 잘 알고 제일 잘 다루는 회사는 애플이 유일합니다.) 요즘은 Electron(Chromium) 기반 앱이 굉장히 많을 뿐더러, 네이티브 앱 또한 arm64/arm64e용으로 다시 빌드하는 데 큰 어려움도 없습니다. 애플이 WWDC에서 설명한 대로 대부분의 앱은 Xcode로 열고 코드 몇 줄만 수정하고 Build target을 Universal 또는 Apple Silicon으로 바꿔주면 오류 없이 바로 빌드되는 경우가 많았습니다.

실제 업무를 보는 개발자면 약간 걱정을 할 수도 있겠습니다. 아무래도 기존에 있던 네이티브 라이브러리라던가 언어라던가.. 생태계가 x86_64(또는 x86)에 맞추어져 있는 경우가 많았으니까요. Homebrew의 경우도 그렇고요. (Formula가 x86_64를 사용하는 것을 가정하고 만들어졌습니다.)‌‌Homebrew의 경우 /opt/homebrew 경로에는 arm64용 homebrew를, /usr/local (기존 homebrew 기본 경로)에는 rosetta 2용 homebrew를 설치해서 alias로 command만 분리해주면 아무 문제없이 기존 개발 생태계를 seamless하게 이용하실 수 있습니다.

저는 위와 같이 brew는 arm64 용으로, ibrew는 x86_64 용으로 사용하고 있습니다.‌‌문제가 생길 수 있는 부분이라면 딱 한 가지. homebrew formula에 있는 bottle(미리 빌드된 바이너리)이 x86_64용으로 고정되어 있다는 건데요. 따라서 arm64에서 homebrew를 돌리면 소스 코드를 내려받아 직접 빌드 스크립트를 실행(configure && make)해 설치하는 경우가 많습니다. 이때 기존 코드에서 arm64 빌드를 막아두었거나 arm64를 위해 코드 수정이 필요한 경우 별도의 git patch 파일을 내려받아 patch를 apply한 후 소스코드를 빌드하는 방식을 사용하고 있습니다 (아마 arm64 생태계가 완전히 자리잡기 전까지는 이 방식을 계속 유지하게 될 것 같습니다.)‌‌이때 만약 소스코드 빌드에 실패한다면 그냥 ibrew로 x86_64 앱을 설치해서 사용하면 약간 성능은 떨어지지만 아무 문제 없이 기존 패키지를 그대로 활용할 수 있습니다.

메모리

메모리 속도와 디스크 속도의 환상적인 조합이라고 해야 할까요. Unified 메모리의 효과라고 해야 할까요. OS 최적화의 힘이라고 해야 할까요.

인텔 맥에서 솔직히 램 32기가 쓸 때도 쾌적하다고 느껴지지는 않았는데 – 16기가는 항상 부족해서 버벅이고 재부팅하고 하는 것이 일상이었습니다 – M1 칩을 단 맥에서 쓰는 램 16기가는 정말 기존 인텔 맥과 차원이 다릅니다. 일단 OS 정책이라 해야 할까요? 메모리가 충분히 남아있는데도 불구하고 대부분의 앱을 스왑 공간으로 보내버립니다. 사파리의 경우 안 쓰는 탭은 거의 즉시 스왑 공간으로 보내고 해당 탭을 소환했을 때 다시 메모리로 꺼내오는데 이 딜레이가 정말로 거의 체감이 안 되는 수준입니다. 오히려 램에 남아 있어도 인텔 맥보다 빠릅니다. '아무리 그래도 물리적 크기가 있는데 이걸 거스를 수는 없겠지'라고 생각했었는데 정말로 M1은 이 고정관념을 뒤엎어버립니다. 어떻게 보면 SSD 수명을 희생해서 이런 동작이 가능한 거겠지만 사실상 요즘 시대에 낸드 수명 걱정할 바에 낸드 컨트롤러가 사망하는 것을 걱정해야...

램 업그레이드가 최대 16기가까지 가능해서 저도 이걸 정말로 구입해야할까 고민을 많이 했는데. 단언컨대 인텔 맥에서 램 16기가 쓰는 그런 생각 하시면 절대 안 됩니다. 체감상으로는 인텔 32기가와 비슷하고 오히려 M1 퍼포먼스 덕분에 인텔 32기가보다 쾌적하게 느껴집니다. 심지어 더 놀라운 건 GPU와 그래픽 메모리를 공유함에도 불구하고 이렇게 쾌적하게 사용이 가능하단 거였습니다. 기존에 집에서 인텔 맥북 프로1 6인치를 사용할 때 dGPU(RX 5300M)에 4K 모니터 1대, eGPU(RX570)에 4K 모니터 1대를 연결하여 (더 넓은 workspace를 원하다보니) looks like 2560x1440 (실제 렌더링 해상도 = 5K) 모드로 사용했었는데 오히려 이렇게 dGPU + eGPU 조합으로 사용할 때보다 M1 내장으로 4K 모니터 2대 연결하여 사용하는 지금이 넘사벽급으로 훨씬 쾌적합니다.

온도

맥 미니를 구입하고 컴파일도 돌려보고 빌드도 돌리고 하루 종일 개발 툴 돌리고 하는 동안 정말로 쿨러 소리 들어본 적이 단 한 번도 없습니다. 온도도 30~40도 이상으로 잘 안 올라가는 편입니다. 근데 저기 표기되는 온도는 M1 칩 안에 있는 센서로 측정된 온도라 실제 맥 미니 알루미늄 표면 온도는 저 온도보다 더 낮습니다. 손으로 직접 만졌을 때는 미지근하네요. 맥 미니의 경우 아무래도 팬도 달려있다 보니 하드하게 빌드를 동시에 여러개 돌리거나 해도 온도가 40도 이상으로는 잘 안 올라갑니다. 온도가 잘 안 올라가다보니 쓰로틀링도 걸릴 일이 없고요.

더욱 신기했던 부분은 빌드를 돌려도 이륙 안 하는 건 기본이요, 빅 코어(Apple M1 Firestorm Core)와 리틀 코어(Apple M1 Icestorm Core)를 아주 잘 활용하여 빌드 도중에 웹 서핑을 하거나 4K 영상을 봐도 버벅임이 거의 느껴지지 않습니다.

온도는 그냥 뭐 더 할 말이 없네요. 정말로 이제 이륙 안 하고, 안 뜨겁고, 그러면서도 고성능인 맥이 나왔습니다. :)

전력 소모

자세한 설명은 하지 않겠습니다. 18W까지 올라가는 것 봤었네요. 인텔/AMD 따위랑 비교 불가입니다.

iOS 앱 구동

아 이건 진짜 편합니다. 맥으로 배달 앱 사용하고 스타벅스 주문하고.. 기기명이 iPad Pro 3 로 뜨는데 iPad 해상도 대응이 되어있는 앱이라면 iPad 사이즈로 뜨게 되고 대응이 안되어있는 앱이라면 iPhone 앱 크기로 뜹니다. 어떤 앱은 리사이징이 되고 어떤 앱은 리사이징이 안되는데 제가 iOS 개발은 해본적이 없어서.. 이유를 모르겠네요.

참고로 증권사 앱, 뱅킹 앱, 넷플릭스 앱 등 보안상 민감한 앱은 켜자마자 앱이 튕기도록 되어있는 것이 많습니다. 그 외에는 대부분 정상 작동하고 iPhone Handoff가 설정되어 있다면 (iPhone/Safari에서 지원하는 것과 완전히 동일하게) 문자 메시지 자동 입력도 지원하고 푸시도 잘 오며 앱 뱃지도 잘 붙습니다.

결론

애플이 괴물을 만든 것이 틀림없습니다. 안그래도 어제 Apple M1칩은 왜 그렇게 빠를까? 라는 글의 번역이 올라와 쭉 읽어보았는데 아무래도 애플 주식을 더 사야..

아무래도 Big Sur가 아직 불안정하기도 하고 몇몇 버그도 있고 WiFi/Bluetooth 끊김 이슈도 있고 안 돌아가는 앱도 간혹 있어 지금 구입하면 베타 테스터라는 이미지가 들긴 합니다만 저는 M1 맥이 100만원의 금액을 지불하고 베타 테스트를 할만한 충분한 가치가 있다고 생각합니다. 일단 쾌적함 자체가 달라요 쾌적함 자체가.. 앱 켜는 순간 하나하나가 모두 즐겁고, 안 돌아가는 앱을 돌아가게 만드는 과정 또한 너무나 즐겁습니다(?).

안그래도 AWS도 Graviton 2를 이용해 ARM64 생태계를 확장하려는 시도를 하고 있고 – 사실 ElastiCache, RDS 등의 PaaS/SaaS 앱의 경우 당장 ARM64 인스턴스를 사용해도 개발자 입장에서는 아무런 대응을 할 필요가 없습니다 – 애플까지 이렇게 나와버리니 향후 짧게는 5년, 길게는 10년 IT 생태계가 어떻게 바뀔지 너무나 기대됩니다. 일부 인터넷 커뮤니티에서는 그래봐야 애플만 바뀐다고 이야기하지만 저는 애플의 이런 transition을 시작으로 arm 생태계가 굉장히 클 수 있게 될 것이라고 확신해보는 입장입니다.

끝.