나의 Apple M1, 사용기(MacBook Air, 16G)

나의 Apple M1, 사용기(MacBook Air, 16G)
나는 램 덕후...
  • updated, 2021년 8월 17일
    • 2020년 12월 ~ 2021년 8월까지 장기간(long term) 사용기 추가
    • 오타 수정

tl;dr

  • 가벼운 무게, 긴 사용 시간, 적당한 성능
  • 개발 및 관련 직군(데이터 분석/처리 등)과 관련된 학습을 진행중이라면 최고의 선택
  • 개발 직군으로 현업에서 사용하고자 한다면 회사에서 사용하는 3rd-party 라이브러리에 영향을 받음

사용해야 되는 노트북이 무거우며, 무게를 줄일 생각하지 말고 근육을 키우면 된다. // 어느 DC인의 조언...

MacBook Air를 구매하기 까지...

개발자에게 휴식이란 컴퓨터를 끄는 일이고, 누군가에게 휴식이란 컴퓨터를 켜는 일이다.

온 종일 개발을 하고 집으로 돌아오면, 쇼파에 누워서 뒹굴 뒹굴 거렸다. 핸드폰도 책상위에 던져두고 Github, Hacker NewsReddit과 연결을 종료했다. 지금은 개발 업무를 진행하지 않기 때문에 문서 작성이나 교안 등을 만들기 때문에 고성능의 컴퓨터를 필요로 하진 않는다. 그래서 넷플릭스를 보거나 콘솔 게임등을 할 때 옆에 두고 사용할 간단한 노트북 정도만 집에서 사용한다.

개인 혹은 업무 외적으로 개바을 진행할 때는 MacBook Pro 16"iMac 2017에서 진행하고 있다. MacBook Pro 16"은 기업의 최고 기술 책임자(CTO) 버전으로 구매했기 때문에 집에 새로운 macOS 기기를 더 구매할 일이 있을까 싶었다.

MacBook Pro 16"의 경우 성능이 좋고, iMac 2017은 아직은 인테리어로 사용하기에 충분하기 때문에 더 이상 Unix like system를 구매할 일이 있을까 싶었다. 더욱이 회사 업무에 필요한 HWP(대한민국 표준을 당당하게 무시하지만, 대한민국 정부에서 엄청나게 사용하는)를 사용해야 하기 때문에 가벼운 윈도우 노트북이 필요한 정도였다.

Cliché

그러던 어느날, ARM 기반 MacBook 성능이 기존 Intel 기반 MacBook Pro 16" 보다 좋거나 비슷할것 같다는 루머를 접했다. 내가 MacBook Pro 16"를 가지고 있어서 그럴 수도 있지만, 순전히 루머라 생각했다.

설마 ARM이 Intel을 능가할까?

MacRumors에서 제공하고 있는 2020년 11월 11일 기사는 믿기 쉽진 않았다. 기사는 나름의 설득력을 가진 벤치마크를 공개했지만, MacRumors의 벤치마크를 마냥 믿을 순 없지만, 벤치마크의 수치는 쉽게 무시할 수 없었다.

루머가 돌던 당시엔 Intel의 CPU 성능에 많은 의문이 제기되고 있었다. CPU의 생산 원가 절감, 공정을 개선하는 과정에서 발생한 기술적인 문제 혹은 설계 오류 등 Intel에 대한 많은 우려가 공존했다. 이 모든 우려의 시작은 Intel의 CPU 성능이 생각만큼 좋지 않다는 것이다.

Intel CPU의 성능이 좋지 않다고 하지만, ARM 보다 성능이 떨어질 것으로 누구도 예상하고 있진 않았다. ARM의 경우 저전력에 초점을 맞춰져 있었기 때문에 '고성능'이라는 단어가 어울리지 않는 조합이었다. 그리고 MS의 경우 ARM 기반 하드웨어와 OS를 출시했지만 호환성 문제로 인해서 실용성이 낮다는 평가가 지배적이었다.

무엇보다 Apple에서 만든 CPU가 Apple Silocn M1이다. 이름에서 유추할 수 있듯이 1세대라는 점을 고려해보면 높은 성능을 기대하긴 무리가 있었다. 기존의 macOSx86-64기반이라서 ARM에서 잘 작동할지 의문이 많았다.

Apple에서 만드는 대부분의 1세대 제품은 사용자/구매자를 혼란스럽게 만든다. Apple에서 출시하는 대부분의 1세대 제품은 놀랍긴 하지만 원숙하진 않다. 그래서 많은 Apple 사용자들이 우스개 소리로 "1세대는 거른다"라고 말하면서 구매한다. 기존의 Apple 행보와 사용자/구매자의 적당한 펜심이 결합하면 아래와 같은 의식의 흐름이 예상된다.

  1. 듣기 좋은 루머와 각 종 유출 정보를 통해 약간의 기대감을 높임
  2. 자신도 모르게 결제가 진행되고, 배송이 완료되고 조금 있으면 2세대 루머가 돌기 시작
  3. "역시, 1세대는 걸렀어야 해!"라고 외치면서 1세대 제품에 적응
  4. "나도 모르게" 적응 했기 때문에 2세대에 대해서 환상을 가지고 다시 기대감을 높여감
  5. "역시 2세대부터지!"라고 말하며, 다시 [1]을 반복하고, n+1세대를 기다림

Apple의 1세대 제품은 정말로 '관망'하고 구매해야 한다는 것을 경험적으로 알지만, 그 경험을 뛰어넘는 '호기심'이 있다. 애플워치가 그랬고, iPod이 그랬다.

하지만...

너무 좋은데? 정말이야?

2020년 11월 11일에 올라온 기사를 기반으로 이야기를 풀어가자면, MacBook Air는 싱글 코어 약 1,700점, 멀티 코어 약 7,400점이다. 싱글코어 기준 기존 iMac 27", MacBook Pro 16" 보다 무려 400점 이상 더 높은 수치다. 단순히 400점이지만, 비율로 따지자면 약 30%이상의 성능 향상이다. 전혀 다른 아키텍처를 사용하는 x86-64 CPU라는 점을 무시한다고 해도, M1의 성능이 Intel에 비해서 매우 높다는 점은 확실하다.

혹시 벤치마크 프로그램에 오버피팅(overfitting) 한걸까? 하는 의구심이 들었다. 심지어 다른 벤치마크에선 AMD Ryzen 5600X와 싱글코어 점수가 비슷하다. 벤치마크 프로그램의 오류가 아닐까? 생각했다. 더욱이 1세대라서 그럴리 없다라는 약간의 심증을 가지고 벤치마크를 보고 있으면 뭔가 마뜩치 않은 지점이 가득했다. 마뜩치 않았던 가장 큰 이유는 심리적인 것으로 '1세대가 이렇게 좋을리 없다'라는 논리적으로 말할 순 없지만, 경험적으로 알게된 어떤 것이 내 마음속에 회전회오리슛을 날리고 있었다.

이후, YouTube를 통해서 언박싱이 올라오고 1~2주 실제 사용한 사용기들이 업로드 되면서 M1에 대한 루머가 사실로 밝혀졌다. 대부분이 벤치에서 보여준 드라마틱한 성능 향상은 아닐 수 있다고 했지만, 우리가 생각하는 것보다는 충분히 높은 성능을 보장한다고 했다. 무엇보다 실제 사용에 관한 체감 속도를 극찬했다. 램은 8기가로 충분하다는 사용기도 올라왔다.

뭐지? 이 벤치마크는? 팀킬한거야?

무게와 성능은 등가교환이다.

Intel에 비해서 "성능이 약간(?) 부족"하다는 것을 단점으로 부각하기엔, MacBook Air의 무게와 사용시간으로 충분히 상쇄하고 남을 정도였다. 국내보다 먼저 배송을 받았던 많은 사용자들의 사용기와 나같은 신도들의 간증이 커뮤니티에 소용돌이 치고 있었다. 일단 사용시간이 14시간이고, 펜(fan)이 없어서 조용하고, 발열도 생각만큼 높지 않다고 했다.

MacBook Pro 16"는 사용시간이 3시간 남짓이고, 펜(fan)이 많아서 그런지 자신의 존재감을 언제나 드러낸다. Android Studio만 실행해도 날자. 날자. 날자. 한번만 더 날자꾸나를 외치는 거대한 친구다. 무엇보다 MacBook Pro 16"를 휴대하기엔 너무 무거웠다. 사과마크에 불도 안 들어오는데, 왜 이렇게 무거운지 이해가 안 갈 정도다. 3Kg 알류미늄을 들고 다니는 입장에서 허약한 나의 근력이 버텨주질 못했다. 무거워서 좋은건 스피커와 노트북밖에 없는데, 두 개의 결정적인 차이는 스피커는 들고 다니지 않고, 노트북은 들고 다닌다는 점이다.

모든 것을 고려해 봤을 때, MacBook Air는 매력적인 친구였다. 가볍고, 오래간다. 그리고 Intel에 비벼볼만하다. 그렇다! 이거다!

스피커와 노트북은 무거울수록 성능이 좋다.

이유를 만들자. 사야되니까.

가벼운 무게를 기반으로 오래 사용할 수 있는 macOS 제품이라는 점은 굉장히 매력적이다. M1이 Intel 기반의 x86-64가 아니라는 점에서 오는 약간의 불편함(혹은 내면의 두려움)은 예상되었다. 당연히 해결책이 있을 것으로 기대했는데, 그것이 Rosetta 2라는 것이다.

예전에 나는 IBM에서 만든 CPU를 사용한 PowerBook 이라는 전혀 파워롭지 않은, 문자그대로 거지같은 노트북을 사용했었다. 그러던 어느날, Apple이 갑자기 CPU를 IBM에서 Intel로 변경하면서 나에게 제시한 것이 Rosetta라는 제품이었다. Rosetta는 빅 엔디안(big endian)-스몰 엔디안(small endian) 문제로 x86에서 실행 불가능한 PowerPC용 프로그램을 실행시켜준다. 실행만 시켜주는 것이 목적인 것처럼 실행 속도는 전혀 신경쓰지 않은 제품인데, OS X Lion에서 삭제된다. Rosetta를 계승했다는 생각에 처음에는 돈을 불지르고 있는건 아닌지 걱정되었다. 'brew' 없이는 프로그램 설치도 못하는 입장에서 x86을 지원하지 않는다는 점은 개발에 사용이 불가능하다는 뜻이다.

그런데, Reddit에서 보이는 대부분의 글타래는 Rosetta 2에 대해서 다들 우호적이었다. x86 애플리케이션을 '거의' 완벽하게 실행할 수 있고, 대부분의 소프트웨어가 속도 저하를 느낄 수 없다고 했다. 형님/누님들의 말씀을 다 믿을 순 없는데 대부분의 사람들이 괜찮다고 하니 믿을 수 밖에 없었다. 삼인성호(三人成虎)라고, 다들 그렇게 말하니 믿지 않을 수 없었다.

x86-64와 ARM은 친해지기 힘들었던 것 아니야?

그래서 생각을 하기 시작했다. 왜냐하면 구매할 명분을 만들어야 되니까.

  1. 16" 친구에겐 미안하지만, 도저히 들고 다닐 근력이 없음
  2. (사고 싶은 마음이 가득해서 생각해보니) 크롬만 돌아가도 충분할 것 같음(새빨간 거짓말이지만 마음만은 그러함)
  3. 로제타가 2는 x86를 실행도 할 수 있고, 실행 속도도 보장한다 함

그리하여, 2020년 12월 23일에 BC카드사 협찬으로 크리스마스 선물을 받았다. 협찬의 댓가는 말하지 않겠다.

왔다! 왔어!

[MacBook의 시시각각] 한 달 후, MacBook Air

이건 그냥 현실이다. 매일 매일 일어날 일이다.

Terminal.appRosetta를 적용하자

처음에 해당 제품을 받고, 설정을 시작했다. 언제나 그렇듯이 Xcode를 먼저 설치한다. 윈도우 설치하고 누군가는 Steam/Epic/Origin launcher 설치 할 때 난 Visual Studio/Visual Studio Code/IntelliJ 를 설치한다. macOS를 설정할 때, 습관처럼 Xcode를 설치한다. Xcode를 설치하니 용기가 하이브리드샘이솟아서 당장에 brew를 설치하려고 Terminal을 실행했다.

처음부터 안될지 몰랐다. 화면에 오류에 관한 내용만 출력되기 시작했다. 일단 뭔가 안된다는데 왜 안되는지 모르겠고, 설치하겠다는데 아니오를 누르면 화를 내면서 너 두고보자 이렇게 말하는 것 같았다. 이런 상황에서, PC방 사용 경험(PUX)을 살려서 예, 예, 예를 누르기 시작하니 이젠 평온한 말투로 에러가 난다.

묻지말고 설치해!

거친생각과 불안한 눈빛으로 화면을 보고 생각이란걸 하기 시작했다. 일단 brew 없이는 Python 없고, Python 없이는 Django/flask도 없다. 그리고 brew 없이는 ruby(>=3.0)도 설치가 안되고, 더 나아가서는 Node.js와 Java(>= 16)도 설치를 못한다.

모든 툴체인의 시작은 brew다. brew가 설치가 안되면 일단 iTerm2가 설치가 안되기 때문에 터미널조차 불편하다. 그렇다고 서버를 Swift로 작성할 순 없는 일이다. 내가 이 컴퓨터로 할 수 있는게 SwiftUI 밖에 없다는 생각에 허망했지만 해결책을 찾았다.

생각먼저하자

이런 문제가 발생한 이유는 Rosetta 2가 작동하지 않았기 때문이다. '그렇다! 로제타는 왜 작동하지 않는가?' 구글에 물어보니 해당 프로그램을 로제타로 사용하도록 설정해야 된다고 했다. '그냥 알아서 실행 좀 하지!'라고 생각했다. 하지만 "내 마음속의 진심이 Apple에 닿을리가 없기"에 직접 설정했다.

그럼에도 불구하고, 이걸 내가 설정하는게 말이되나 싶었지만, 받아들였야 했다. 괜히 1세대가 아니다. 여튼, 찾고 찾아서 터미널에 로제타를 적용하는 방법을 접하고 아래 그림과 같이 로제타를 사용할 수 있도록 옵션을 설정하였다.

터미널의 종류에 대해서...

동작한다!

드디어 brew를 설치하였고, 내가 작성한 블로그 기사 중에서 미래의 나를 위해서 만들어 둔 개발자를 위한 macOS(>= Big Sur) 설정을 보고 따라하기 시작했다.

일단 내가 사용하는 대부분의 프로그램이 문제없이 작동하는 것을 확인했다. 90년대는 위스키, 브랜디, 블루진, 하이힐, 콜라, 피자, 발렌타인이였다면, 21세기는 Rust, Python, Haskell, C#가 대세라 생각하고 당당하게 rust, pyenv, stack, dotnet부터 설치했다.

Haskell도 M1에서 문제 없이 동작한다. 이상하게 잘 동작하는 것 같아서, 의심스러웠지만 잘 되는걸로 봐서는 잘 되나보다 싶었다(잘 되면 고민하지 않기로 했다. 잘 되니까!).

App? 걱정하지 말자

사용하는 프로그램도 문제없이 작동한다. M1 기반으로 동작하지 않는 프로그램도 별다른 걱정없이 사용할 수 있다. 대부분의 프로그램을 걱정없이 사용할 수 있다. 내가 사용하는 프로그램 중에서 가장 마이너한 친구들인 LaTeX 편집기도 잘 작동한다.

알고보면 전부 Intel임

'잘'은 모르겠지만, 작동한다.

누군가 모든 프로그램이 M1에서 잘 동작하느냐 묻는다면 글쎄요? 라고 말하겠지만, 작동하는냐? 라고 묻는다면 라고 답하고 싶다. 작동한다. 최소한 내가 사용하는 범위에선 전혀 문제가 없다.

가끔 '이 프로그램은 왜 M1을 지원하지 않을까?'라고 말한다. M1의 경우 Rosetta 2의 성능이 좋아서 굳이 M1을 지원하지 않아도 잘 작동하기 때문이다. 그리고 M1 사용자가 늘어난다면 자연스럽게 지원될 것으로 예상된다.

근력없는 개발자들이여, MacBook Air를 구매해도 좋다. 단,JVM을 기반으로 한 언어를 사용한다면 아래 글을 계속 읽어보자.

문제는 JVM이 아니라 Android Studio다.

JVM 관련 언어도 잘 작동한다. 일단 JVM이 문제 없이 작동하기 때문에 걱정은 없었다. 하지만 초기 JetBrain의 프로그램들은 사용이 힘들만큼 이상하게 작동한다. 인형의 꿈도 아닐텐데, 키보드 입력이 항상 한 걸음 뒤에 있는 것 같았다. 입력 딜레이가 심해서 사용히 힘들었다. 어느날 Toolbox가 업데이트 되더니, 갑자기 M1을 지원하기 시작했다. 마법같이 모든 것이 잘 작동하기 시작했다. Spring Boot도 잘 동작했고, Kotlin도 잘 동작했다. Scala라도 문제 없는데, PyCharm, DataGrip도 당연히 문제가 없었다. 당연히 생각했다.

Screen-Shot-2021-05-09-at-10.37.44-PM

그런데 뭔가 허전했다. 고민끝에 임포스터를 찾았다. 우리의 친구, Android Studio가 M1을 지원하지 않고 있다. 여러가지 사정에 의해서 아직 M1을 지원하지 않는듯 했다. IntellJ 버전을 조금만 높이면 충분히 지원은 할 수 있는 것 같았고, 에뮬레이터 문제는 해결 중인 것으로 확인되었다.

없네?

[MacBook의 시시각각] 여덟 달 후, MacBook Air

어느덧 '거의' 완벽에 가까워진 나의 MacBook Air 사용기

iPad 게임이 실행된다!

iPad 게임이 검색이 되네?

몇 해 전에 발더스 게이트 II를 구매했었다. 아이패드에서 실행되기 때문에 UI가 조금 불편했지만 들고 다니면서 어릴적 재미있게 하던 게임을 할 수 있어서 좋았다(지하철에서 게임을 하고 있으면, 많은 사람들과 함께 모험을 할 수 있는 기분을 느낄 수 있음).

발더스 게이트 II

MacBook Air에도 발더스 게이트 II를 실행 할 수 있다. 원래 iPad에서 실행되는 게임이라서 이게 뭔가 싶었는데, 생각해보니 CPU가 같아서(정확히는 ARM 호환) 별다른 포팅 과정없이 실행되는 것 같았다. 그래서 카페 등에서 잠시 쉴 때 가볍게 게임을 할려고 설치해 두었는데, 2시간 넘게 발더스 게이트 II만 하고 있었다. 혹시나 해서 Square Enix에서 출시한 게임을 설치해볼까 했는데 실패했다. 외부 프로그램을 사용해서 IPA를 추출해서 실행하는 방법이 있다고 하지만, 귀찮아서 진행해보진 않았다.

발더스 게이트 II는 검색되고, 파이널 판타지드래곤 퀘스트는 검색되지 않는지 모르겠다. 기존의 iPad에서 실행되는 게임을 M1 기반 macOS에서 사용할 수 있다는 것은 생각하지 못한 장점 중 하나다. 기존의 모든 iPad 게임이나 앱을 지원하진 않지만, iPad나 iPhone에서 구매한 게임이나 앱을 실행할 수 있다는 점에서 M1 기반 macOS의 사용성에 대해서 높게 평가하게 된다. 그리고 Apple이 만들어갈 애플리케이션 생태계도 기대된다. 1세대 MacBook Air에선 기대하기 힘들겠지만, 만약(정말 만약에) Apple이 M1 관련 생태계를 잘 만들어준다면 macOS의 활용도가 더 높아지지 않을까 싶었다(그러니 SwiftUI 등은 미리미리 배워둡시다).

개발 환경의 마지막 조각 Google, 드디어 일하다!

Android Studio

2021년 7월, Android Studio2020.3.1로 업데이트 되었다. Jetbrains Toolbox를 통해서 업데이트 알림이 울렸고, 업데이트를 진행하였다. 몇가지 사소한 문제가 있지만, 기존에 작성하고 있던 대부분의 코드는 문제 없이 작동했다. 올해 1월 부터 Kotlin과 Jetpack만 사용해서 토이 프로그램을 연습하고 있었다. 기존에 사용하던 것 중에서 ROOM에서 문제가 발생했지만 쉽게 해결되었다.

이쯤되면 M1 기반 MacBook에서 대부분의 개발 환경을 구성하는데 큰 어려움이 없을 것으로 착각할 수 있는데, 주의사항이 있다.

우리는 3rd-party에 대해서 얼마나 알고 있는가?

ROOM에서 에러가 발생했을 때, 내가 했던 첫번째 질문은 "ROOM에서 왜 문제가 발생했던 걸까?"였다. 원인을 찾아보니 M1용 Native SQLite 드라이버 문제인 것으로 확인되었다. 해결 방법은 M1을 지원하는 SQLite 드라이버를 사용 하면 된다는 것이다. 질문에 대한 해결책이 매우 간단하다. 다시 정리하면 문제는 M1을 지원하지 않는다는 것이고, 해결책은 M1을 지원하는 라이브러리로 변경하면 된다는 것이다.

대부분의 현업 개발자는 이쯤되면, 이 문제는 심각할 수 있다는 것을 본능적으로 알게된다. 왜냐하면 문제가 발생하는 지점이 3rd-party 라이브러리라는 점 때문이다. 예를 들어 내가 현재 사용하고 있거나 관심 있어서 설치해둔 컴파일러나 인터프리터 혹은 개발 관련 프로그램은 아래와 같다. 아래 목록을 보면 느낄 수 있지만 현업에서 사용할 수 있는 대부분의 컴파일러나 인터프리터는 문제 없을 것으로 판단된다.

  • Xcode(with Cocoapods, SwiftPM)
    • Ruby(with rbenv) for CocoaPods
  • Haskell(with Stack)
  • Python(With miniconda)
  • Node.js(with nvm)
  • DotNet Core
  • Rust

대부분의 문제는 컴파일러나 인터프리터가 아닌 3rd-party 라이브러리에서 발생한다. 예를 들어서, Python에서 사용하는 대부분의 라이브러리는 문제가 없다. 그런데 scikit-learn을 설치하면 아래와 같은 에러를 확인할 수 있다.

error: Command "clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -
...
build/temp.macosx-11.5-arm64-3.9/numpy/core/src/multiarray/alloc.o -MMD -MF build/temp.macosx-11.5-arm64-3.9/numpy/core/src/multiarray/alloc.o.d -faltivec -I/System/Library/Frameworks/vecLib.framework/Headers" failed with exit status 1

에러 내용을 확인해보면 쉽게 유추할 수 있겠지만 컴파일 과정에서 ARM을 지원하지 않아서 발생하는 문제다. 문제는 내가 설치하고자 하는 것은 scikit-learn인데, 에러는 Numpy에서 발생한다는 점이다. Node.js, Haskell, Swift 등 대부분의 언어는 Apple silcon를 지원하지만 3rd-party에서 지원하지 않고 그 조차도 의존성이 있는 몇몇 라이브러리에서 오류가 발생한다. Android의 'ROOM'의 경우 대안이 있기 때문에 쉽게 해결할 수 있다. Node.js도 버전을 높이면 대부분 문제는 해결된다. 그리고 대부분의 유명한 라이브러리는 현재 Apple silcon과 관련된 문제를 해결하기 위해서 많은 PR이 진행되고 있다. 그럼에도 불구하고 Python의 경우 해당 문제(Numpy 에러)는 해결이 안되기 때문에 다른 방법을 사용해야 한다.

MacBook Air에서 Miniconda는 필수!

개인적으로 Python에서 제공하는 가상화 모듈인 venv을 사용하는 것을 선호한다. 그리고 될 수 있으면 Python 최신버전 사용하는 것을 원칙으로 하고 있다. Python의 최신 버전을 우선적으로 사용하겠다는 결정은 Python을 프로덕션(production)으로 사용하지 않기 때문에 가능하다. Python 언어를 학습하고, 내부를 뜯어보는 것을 즐겨하기 때문에 생긴 하나의 '습관'이라 할 수 있다. 그래서 Python 버전을 비교하기 위해서 pyenv와 같은 버전 관리도구를 함께 활용한다.

나는 데이터 분석을 전문으로 하는 절친한 동료가 즐겨사용하던 Anaconda 환경을 좋아하지 않는다. 왜냐하면 나도 모르는 패키지가 무작정 잔뜩 설치되는 것을 선호하지 않고, venv를 사용하지 않고 별도의 격리 도구를 사용해야 하며, 무엇보다 Anaconda를 사용하면 서비스 배포에 몇가지 제약이 생기기 때문이다. 3rd-party 보다는 기본으로 제공하는 라이브러리/모듈을 선호한다. 하지만 MacBook Air에서 Python을 사용하기 위해선 어쩔 수 없이 Anaconda 기반의 miniconda를 사용해야 한다. 정확히는 사용이 강제될 것이다.

우리는 3rd-party에 대해서 얼마나 알고 있을까?

miniconda를 사용하기 싫어서 Numpy를 직접 컴파일도 해봤지만, 결국에는 miniconda를 사용할 수 밖에 없었다. 왜냐하면 Metal기반으로 작동하는 Tensorflow(TF) 때문이다. M1의 GPU를 가속할 수 있는 Metal 기반 TF를 설치하기 위한 방법을 Apple에서 별도로 제공한다. 그런데 해당 가이드라인에서 miniconda를 설치할 것을 전제로 한다. 시스템에 Python 개발 환경을 무작정 늘릴수는 없기 때문이다. 데이터분석은 miniconda를 사용하고, Django는 venv를 사용하는 것은 어리석은 짓이기 때문이다. 이 거대한 변화의 시작은 3rd-party 관련 문제를 해결하기 위해서 였다.

3rd-party 관련해서 면밀하게 검토하지 않고 실무에 적용하지 않기를 바란다. 실무에서 사용하고자 한다면 자신이 사용하는 3rd-party 라이브러리에 대해서 반드시 점검하길 바란다. 생각보다 복병이 많으니 조심히 강을 건너자. 무엇보다 기존의 사용 습관이나 개발 환경을 변경해야 하기 때문에 자신의 개발 습관 및 팀 커뮤니케이션, 배포 환경 등 모든 것을 고려해야 한다.

학습자의 경우는 이 모든 논의가 어떤 의미가 있겠는가 싶겠지만, 결론적으로 말해서 여러분이 학습하고자 하는 것 중에서 어떤 것이 제대로 동작하지 않을 가능성이 있으니 주변에 해당 분야의 전문가를 섭외해두거나, 지역 커뮤니티 또는 관련 커뮤니티를 잘 찾아두길 권한다.

머신러닝 배우신다구요? PyTorch만 아니시라면...

Apple에서 Tensorflow(TF) 관련해서 Apple silcon 관련해서 별도의 지원을 하고 있다. Apple에서 제공하는 Metal 기반 TF를 사용하면, M1 GPU를 활용 할 수 있다. 정확하진 않지만 대략적인 성능은 Nvidia 1050~1060 정도로 예측된다. 실무에서 TF를 기반으로 한 모델링의 경우는 사실상 불가능한 성능이지만(VRAM이 너무 작다), 개인 사용자가 딥러닝을 공부하는데는 큰 무리가 없을 것으로 생각된다. Nvidai 3080 TI 가격을 고려한다면 MacBook Air가 그렇게 나쁜 선택은 아닐 듯 싶다.

Screen-Shot-2021-08-11-at-5.11.17-PM

Apple에서 Metal에 대한 지원이 좋아지면 AMD 관련 그래픽 카드를 활용할 수 있는 여지도 생긴다. Apple이 나름 열심히 하고 있는 것 같다. 병렬 연산에 관련된 가속 기능을 Metal 기반을 지원하는 것으로 가닥을 잡을지, Apple silcon의 명령어셋 개선으로 진행할지는 미지수다. 명령어셋도 아직은 발전 가능성이 많기 때문에 충분히 기대해볼만 하다. 현재는 TF를 주력으로 지원하고 있다. 연구자의 경우 PyTorch를 주로 사용할텐데, PyTorch 사용자는 이 링크를 참고하자.

결론

  1. 가벼운 무게와 장시간 사용을 필요로하는 분들에게 적합하며, HWP를 사용하지 않는다고 전제한다면 문서 작성, 가벼운 컨텐츠 생산과 같은 형태에 이 정도 금액에 이 만한 성능을 가진 제품이 없기 때문에 강추한다. 윈도우 사용에 대한 의존도가 높지 않다면 대부분의 업무는 Air에서 충분히 진행할 수 있다.

  2. 학습자의 경우 MacBook Air의 한계가 있음을 인지하고 자신이 학습하고자 하는 분야에서 주로 사용하는 도구들이 MacBook Air에서 작동하는지, 혹은 관리되는지 미리 확인하자. 만약, 데이터분석이나 머신러닝 등과 같은 것을 위주로 학습하고 있다면 충분하다. 그런데 OpenCV, C++기반의 Unreal 엔진 등을 학습하고 있다면 고민이 필요하다.

  3. 현업에서 사용하고 있는 3rd-party 라이브러리를 지배하고 있다면, MacBook Air를 실무에서 사용 가능하다. 만약, 그게 아니라면 Intel 기반으로 방향을 잡자(연봉과 여러분의 시간당 생산성을 고려했을 때 MacBook Air를 사용하기 위해서 3rd-party를 수정하고 컴파일하고 PR하는게 어떤 가치가 있을지 고민이 필요하다).