이제는 개발자도 CPU 아키텍처를 구분해야 합니다.

왜?

Intel 천지였던 PC 분야에 ARM이 광풍을 불기 시작한지 얼마 되지 않았습니다.
이에 개발자도 변화를 감지 하고 대응하기 위해 알아야 할 것들을 정리 했습니다.

그동안 암묵적으로 대부분의 서버 환경이 Intel 기반 이므로 달리 묻지 않고 사용 했습니다.
하지만, 이제 ARM 서버가 대중화 되고 있으므로 구분해서 사용 할 수 있어야 합니다.

CPU의 클럭 단위와 속도의 이해

Ghz (기가헤르츠) 라는 단위를 사용 하며 정확히는 주파수의 진동 횟수 입니다만,
다 빼고, 쉽게 말해 그냥 코드가 실행 되는 속도 이고 이 수치가 높을 수록 빠릅니다.

단일 코어 스피드는 기술 한계로 4Ghz 이상으로 쭉쭉 못가고 있으니까, 병렬로 늘리기 시작했죠.
그래서 언제부턴가 클럭 속도 보다 CPU 갯수로 수요를 커버 하고 있습니다.

대표적인 CPU 제조사

Intel

다들 아시는 인텔 인사이드 (파란 인간 모델) 회사로, PC용 으로 가장 많이 사용하고 가장 안정적(?) 입니다.

안정적이라는 의미는 Intel 에 맞춰 개발한 소프트웨어가 오래 사용되고 다양한 분야에서 검증되어 안정적이라는 뜻입니다. 하드웨어 자체의 안정성은 어느 제조사나 이제 다 비슷 비슷 하다고 생각 합니다.

Intel은 x86 아키텍처의 CPU를 만듭니다.

AMD

Intel 의 x86 호환 CPU를 만드는 회사

한때 인텔보다 클럭 속도가 더 빠르면서도 더 저렴한 CPU를 내놓았지만
아직도 Intel 을 이기지는 못한 회사 (힘내 암드야 ㅠㅠ ← 이거 어디서 한번씩 보신적 없으신가요?)

ARM

위 2개 회사 와는 다르게 ARM은 x86과 전혀 다른 아키텍처를 사용합니다.
과거의 ARM은 단순한 아키텍처와 함께 가격이 저렴하고 저전력을 갖춰 소형기기에 많이 사용 했습니다.

스마트폰 시대에 접어들면서 모바일 용으로 많이 쓰이다 보니 엄청난 발전으로
속도 면에서 이제 PC에 근접한 수준에 이르렀습니다. (엑시노스... 많이 들어봤죠? ← 삼성의 ARM CPU 입니다.)

반면에 저렴한 가격과 저전력은 유지했죠.
이로 인해 PC용 ARM을 사용하는 시도가 많아졌고

AWS가 자체 개발한 ARM CPU로 만든 서버인 Graviton 이라는 인스턴스를 내놓으면서 서버 시장에 불을 피우고, Apple이 자체 개발한 M1 CPU로 맥북을 내놓으며 PC시장에도 불이 붙었습니다.

ARM 이라는 회사가 존재 합니다만, 누구든지 ARM을 기반으로 커스텀한 칩을 직접 만들어서 팔아도 된다고 알고 있습니다. (할 수 있는 능력이 있다면 말이죠.)

Intel 호환을 만드는 AMD 같은 거죠. 하지만 인텔과 AMD는 상호 라이센스를 체결해서 두개 회사에서만 제조가 가능 합니다.
그러니까 M1 칩은 ARM이 만들어 준게 아니라, Apple이 만든 ARM 호환 CPU 입니다.

CPU 제조사? 아키텍처를 내가 왜 알아야 하는데?

x86 과 amd64(x86_64), arm과 arm64/v8 이런 글자들 어디서 보지 않았나요?

이것들은 CPU 아키텍처의 이름 입니다.

각 소프트웨어는 실행되려면 컴파일 되거나 동작 환경이 갖춰 져야 합니다.
요즘은 밑바닥부터 전부 다 스스로 만들지 않고 온갖 라이브러리를 쓰죠.

그런데, 대부분의 라이브러리는 특정 CPU 아키텍처에 맞게 사전 컴파일 되어 있는 것을 갖다가 씁니다.
Linux로 치면 *.so 라고 하는 Shared Object를 쓰고요. 윈도우라면 *.dll 이죠.

예전에는 서버라고 하면 전부 인텔이나 AMD를 쓰고 x86 이나 x86_64 를 사용 하니까
그냥 사전 컴파일 해서 배포해도 별 문제가 안됐는데요.

이제는 다릅니다. ARM 서버가 등장 했기 때문이죠.

아키텍처 종류

x86

• Intel 기반 32bit CPU 입니다.
• 현존 하는 PC 프로그램 대부분이 이 아키텍처를 지원 합니다.
• Windows, Linux, Mac OS (BigSur 까지)

x86_64 (amd64)

• amd64 라고도 합니다.
• Intel 기반 64bit CPU 이며, x86과 호환 됩니다.
• 사실상 AMD가 만들었는데 Intel 과 크로스 라이센싱 하여 둘 다 씁니다.
• Windows, Linux, Mac OS (BigSur 까지)

arm

• arm 기반 32bit CPU 입니다.
• x86 과 아예 달라서 둘이 전혀 호환이 안됩니다.
• Linux, Mac OS (Monterey 부터), Android, iOS, 기타 모든 쪼그만 기기에서 성능 내야하는 경우 (공유기도 해당)

arm64 (arm64/v8)

• arm 기반의 64bit CPU 입니다.
• 32bit arm 과 호환 됩니다.
• Linux, Mac OS (Monterey 부터), Android, iOS, 기타 모든 쪼그만 기기에서 성능 내야하는 경우 (공유기도 해당)

💡 Windows 도 ARM 버전을 개발 중이고 베타도 있습니다만... 여기까지 적겠습니다.

이제, 왜 모바일 앱이 PC에서 안돌아가는지 아시겠죠?

모바일 앱은 ARM 아키텍처로 만들어 집니다.
PC 는 M1 Mac 이 아니면 죄다 x86_64 죠.

그냥 실행이 안됩니다. 가끔 된다고 하는 것들은 전부 에뮬레이터를 쓴 겁니다.

반대로 M1 Mac 이 ARM 이니까... iOS 용 앱이 에뮬레이터 없이 돌아가겠네?
맞습니다. M1 Mac 에서는 iOS 앱들이 다 구동 됩니다.
(에뮬 없이, 네이티브 성능으로)

컴파일 머신의 CPU → 결과물의 아키텍처

프로그램은 결국 컴파일 된 바이너리 입니다. (스크립트 언어는 예외로 하죠)
이때, 이 컴파일을 어떤 CPU로 했는지에 따라 결과물이 정해집니다.

x86 머신에서 빌드한 라이브러리를 그냥 arm 에 가져오면 실행이 안됩니다.
반대의 경우도 마찬가지 입니다.

하지만 x86 에서 빌드한 라이브러리를 x86_64 에서는 가능 합니다.
x86_64 가 하위 호환을 지원 하기 때문이죠.

이런식 입니다.

따라서 내가 사용하고자 하는 라이브러리가 있다면,
우선 이 라이브러리를 실행할 서버의 아키텍처를 이제는 알아야만 합니다.

그에 맞게 라이브러리를 설치해야 하고요.

FAQ

Q. x86만 지원하는 라이브러리가 있는데, ARM 머신에서 쓰고 싶어요.

라이브러리의 소스코드가 공개되어 있고 직접 컴파일이 가능하다면 본인이 직접 ARM 머신에서 컴파일해서 쓰면 됩니다.
소스코드가 없고, ARM을 지원하지 않는다면 일단 불가능 합니다.

Q. M1 Mac 은 인텔용 프로그램 다 돌아가던데요?

Apple이 신의 한수를 써놨습니다만, 유저 입장에서는 좋죠.

M1 Mac 에서 Intel... 아 우리는 배웠으니 x86 이나 x86_64 으로 빌드된 프로그램을 실행 할 수 있는 이유는 Rosseta 라는 에뮬레이터가 있기 때문 입니다.

이것은 ARM 머신 내부에 x86 가상환경을 만들고 그 안에서 실행하는 방식 입니다.
에뮬레이터 라는게 다 그런거죠.

따라서 성능의 저하가 있습니다. (애플은 거의 없다고 하지만, 없을 수가 없죠.)
에뮬레이터는 우리가 말을 할때 번역기를 거치는 것과 같습니다.

Q. 도커 이미지는 intel cpu 만 지원하나요?

아니요. 도커도 이미지를 빌드하는 환경의 영향을 받아 그에 맞는 이미지가 만들어집니다.
다만, 도커 허브의 이미지들은 편의를 위해 다양한 아키텍처별로 같은 이미지 이름으로 업로드 되어있습니다.

mysql 도커 이미지의 예시인데, 이제 그동안은 잘 안보이던 회색 태그가 눈에 들어올 거에요.
Linux, x86-64, ARM 64 ....

같은 mysql:latest 를 pull 받더라도 내부적으로
그 머신의 CPU에 따라 맞는 아키텍처를 받는 것이 도커의 기본 동작 입니다.

만약, 특정 아키텍처의 이미지를 강제로 받으려면 옵션이 필요 합니다.

docker pull --platform=linux/arm64 mysql:latest 

이렇게 말이죠. 자세한 것은 도커 매뉴얼을 참고하세요.

Q. 언어에 따라서도 CPU가 상관이 있나요?

유명한 언어는 대부분 ARM, Intel 모두 지원 하므로 큰 상관 없습니다.
하지만, php 처럼 Linux 확장 모듈을 불러다 쓰는 기능이 있을 경우 문제가 됩니다.

java의 경우는 대부분 소스코드 형태의 라이브러리가 많기 때문에 CPU 아키텍처에서 대부분 자유롭다고는 합니다만 요즘은 반드시 100% java로 개발되지 않는 경우도 많아 면밀히 확인 해야 합니다.

node.js 의 경우는 수백만개의 npm 라이브러리 때문에 좀 문제가 됩니다.
라이브러리 중에는 linux 의 시스템 명령을 사용하는 것도 많고 gifsicle, imagemagick 등 이미지 처리를 위한 다른 모듈의 도움을 받는 경우도 많은데, 사전 컴파일 된 모듈이 필요한 경우 문제가 됩니다.

npm 을 가지고 직접 실험을 해보는 수 밖에 없어요.

결론

개발자는 그동안 Intel 아키텍처로 통일된 서버 환경에서 잘 살아왔지만... 이제는 ARM 서버 등장과 함께 CPU 아키텍처 를 명확히 구분할 수 있어야 합니다.

긴 글 읽어주셔서 감사합니다.

2022 매튜(@480)