도입: ARM64면 다 똑같은 거 아니었어?
요즘 애플 M 시리즈 맥, 라즈베리파이, 그리고 거의 모든 스마트폰이 ARM64(공식 명칭 AArch64) 칩을 써요. 그런데 "같은 ARM64니까 어셈블리도 똑같겠지"라고 생각했다면 살짝 함정이 있어요. 명령어 자체는 표준이라 같지만, 그 어셈블리 코드를 어떻게 적어야 운영체제와 어셈블러가 받아들이는지는 환경마다 미묘하게 다르거든요. 리눅스, macOS, 그리고 서로 다른 어셈블러(GNU as vs LLVM)를 넘나들며 동작하는 "이식 가능한(portable) ARM64 어셈블리"를 짜는 법을 다룬 글을 소개해볼게요.
핵심 내용: 명령어는 같은데 왜 안 돌아갈까
가장 큰 골칫거리는 심볼 이름과 재배치(relocation) 표기법이에요. 이게 뭐냐면, 어셈블리에서 함수나 전역 변수의 주소를 가져올 때 쓰는 문법인데, 이게 OS마다 달라요. 예를 들어 macOS(Mach-O 형식)에서는 심볼 앞에 밑줄(_)을 붙이고, 주소 계산에 @PAGE, @PAGEOFF 같은 표기를 써요. 반면 리눅스(ELF 형식)에서는 밑줄을 안 붙이고 :lo12:, #:got: 같은 전혀 다른 표기를 쓰죠. 그래서 같은 "전역 변수 주소 좀 레지스터에 넣어줘"라는 동작인데도 코드 모양이 완전히 달라져요.
글에서는 이런 차이를 매크로와 조건부 컴파일로 흡수하는 기법을 보여줘요. 쉽게 말하면, #ifdef로 "맥이면 이렇게, 리눅스면 저렇게"를 한 군데 모아두고, 본문에서는 깔끔한 매크로 이름만 호출하는 식이에요. 그러면 코어 로직은 한 벌만 유지하면서 여러 플랫폼을 지원할 수 있죠.
또 다른 포인트는 함수 호출 규약(calling convention)과 스택 정렬, 그리고 함수의 시작·끝을 표시하는 디렉티브예요. ARM64는 스택 포인터를 16바이트 단위로 맞춰야 한다는 규칙이 있는데, 이걸 어기면 어떤 환경에서는 그냥 죽어버려요. 또 디버거가 호출 스택을 제대로 그리려면 함수 경계 정보를 알려주는 지시문이 필요한데, 이 문법도 어셈블러마다 다르고요. 글은 이런 자잘하지만 치명적인 차이들을 하나하나 짚으면서, 어떻게 하면 "한 번 짜서 여러 곳에서 빌드되는" 어셈블리를 만들 수 있는지 실용적인 패턴을 제시해요.
업계 맥락: 왜 지금 이게 중요해졌나
예전엔 어셈블리 짤 일이 거의 x86 리눅스 한 곳에 몰려 있었어요. 그런데 애플이 인텔을 버리고 자체 ARM 칩으로 갈아타면서, 그리고 클라우드에서도 AWS Graviton 같은 ARM 서버가 흔해지면서, 같은 저수준 코드를 x86과 ARM64 양쪽에서 굴려야 하는 상황이 폭발적으로 늘었어요. 암호화 라이브러리, 코덱, 가상머신 같은 성능이 생명인 프로젝트들은 손으로 최적화한 어셈블리를 품고 있는데, 이게 이제 macOS-ARM, Linux-ARM, Linux-x86을 다 지원해야 하니까요.
그래서 OpenSSL, 각종 멀티미디어 코덱 프로젝트들이 실제로 이런 이식성 문제와 매일 씨름하고 있어요. 이 글이 다루는 내용은 바로 그 현장의 축소판인 셈이에요.
한국 개발자에게 주는 시사점
대부분의 앱 개발자는 어셈블리를 직접 쓸 일이 없어요. 하지만 "내가 짠 C/C++ 코드가 ARM64에서 왜 다르게 동작하지?" 같은 디버깅 상황이나, 성능 핫스팟을 인트린식(intrinsic)으로 최적화할 때, 이 바닥의 원리를 알면 문제 해결 속도가 확 달라져요. 특히 M 시리즈 맥으로 개발하고 리눅스 ARM 서버에 배포하는 분들이라면 "같은 아키텍처인데 빌드가 깨지는" 경험을 한 번쯤 하게 되는데, 그 원인이 바로 이 심볼·재배치 차이일 때가 많거든요.
저수준을 한 단계만 이해해둬도, 크로스 컴파일이나 CI에서 멀티 플랫폼 빌드를 구성할 때 훨씬 침착하게 대응할 수 있어요.
마무리
"ARM64 명령어는 표준이지만, 그걸 적는 방식은 OS와 도구마다 다르다"는 게 이 글의 핵심이에요. 이식성은 명령어가 아니라 그 주변의 규약에서 결정되는 거죠.
여러분은 애플 실리콘으로 넘어오면서 빌드가 깨졌던 경험이 있나요? 저수준 어셈블리, 알아둘 가치가 있다고 보시나요?
🔗 출처: Hacker News