오래된 맥에서 최신 CLI가 죽는 이유: AVX2와 Illegal instruction: 4
오래된 맥에서 최신 CLI가 Illegal instruction: 4로 죽는 이유를 AVX2 명령어 세트로 설명하고, sysctl로 진단하는 법과 실측 해결 과정을 정리합니다.
설치 중 딱 한 줄 남기고 죽었습니다
오래된 맥에서 최신 CLI를 설치하다가 프로세스가 통째로 멈춘 적이 있습니다. 로그도 스택트레이스도 없었습니다. 그냥 설치 스크립트가 돌다가 딱 한 줄을 남기고 죽었습니다.
Illegal instruction: 4
처음에는 제 실수인 줄 알았습니다. 권한 문제인가, 경로가 꼬였나, 아니면 캐시가 깨졌나. 지우고 다시 깔았습니다. 같은 자리에서 같은 줄을 남기고 또 죽었습니다. 몇 번을 반복해도 결과가 똑같으면, 그건 우연이 아니라 구조적인 이유가 있다는 뜻이었습니다.
이 글은 그 한 줄이 무엇을 의미하는지, 왜 코드가 아니라 CPU의 문제인지, 그리고 제가 실제로 어떻게 확인하고 넘겼는지를 정리한 기록입니다. 지난 7월 16일 스레드에 짧게 올렸던 내용이 도달 1800을 넘기며 의외로 같은 문제를 겪는 사람이 많다는 걸 알았고, 그래서 좀 더 파고든 심화판입니다.
원인: CPU가 모르는 명령을 만나면 즉사합니다
Illegal instruction은 이름 그대로입니다. 프로그램이 CPU에게 어떤 명령을 실행하라고 시켰는데, CPU가 “그런 명령은 내 사전에 없다”고 대답한 상황입니다. 그러면 운영체제는 그 프로세스를 더 진행시키지 않고 바로 종료합니다. 버그로 인한 크래시가 아니라, 애초에 실행 불가능한 명령을 만난 즉사에 가깝습니다.
핵심은 AVX2라는 명령어 세트입니다. AVX2는 한 번에 여러 데이터를 묶어서 처리하는 확장 명령들인데, 2013년 하스웰(Haswell) 세대 이후의 인텔 CPU부터 들어갔습니다. 최신 CLI 도구들이 성능을 위해 네이티브 바이너리를 이 명령어 세트 위에서 컴파일하는 경우가 있습니다.
문제는 여기서 갈립니다.
- AVX2가 있는 CPU: 바이너리가 요구하는 명령을 그대로 실행 → 정상 동작
- AVX2가 없는 오래된 CPU: 바이너리가 그 명령을 실행하려는 순간 → CPU가 모름 →
Illegal instruction: 4
즉 소프트웨어 버전 문제도, 설정 문제도 아니었습니다. 하드웨어가 그 명령을 물리적으로 지원하지 않는데 바이너리는 있다고 가정하고 만들어졌기 때문에, 그 명령을 처음 밟는 순간 죽는 것이었습니다. 그래서 아무리 재설치해도 똑같은 자리에서 죽었던 겁니다.
진단: sysctl 한 줄이면 끝납니다
원인을 의심했으면 확인은 간단합니다. 내 맥의 CPU가 AVX2를 지원하는지 딱 한 줄로 볼 수 있습니다.
sysctl -a | grep avx2
결과 해석은 이렇게 나뉩니다.
# AVX2가 있는 경우
hw.optional.avx2_0: 1
# AVX2가 없는 경우
(아무 것도 출력되지 않음 — 값이 비어 있음)
hw.optional.avx2_0: 1이 보이면 CPU가 AVX2를 지원한다는 뜻이고, 이 경우라면 크래시의 원인은 다른 데 있습니다. 반대로 명령을 쳤는데 아무 줄도 나오지 않고 그냥 프롬프트로 돌아온다면, 그 맥에는 AVX2가 없는 것입니다. 제 오래된 맥이 정확히 후자였습니다. 값이 비어 있었고, 그걸 보고 나서야 재설치를 멈췄습니다.
이 확인의 좋은 점은 추측을 끝내준다는 것입니다. Illegal instruction: 4를 보고 로그를 뒤지거나 스크립트를 의심하는 대신, sysctl 한 줄로 “이 하드웨어에서는 원래 안 되는 일”임을 확정할 수 있습니다.
해결: AVX2가 있는 머신으로 옮겼습니다
진단이 끝나면 선택지는 명확해집니다. 하드웨어에 없는 명령어를 소프트웨어 설정으로 만들어낼 수는 없으니, AVX2를 지원하는 CPU로 가는 것이 정공법입니다.
제 경우가 그대로 그랬습니다.
- 2012년 맥: AVX2 없음 → 설치 시도 실패,
Illegal instruction: 4 - 2018년 서버: AVX2 있음 → 같은 도구, 같은 절차로 설치 성공
바이너리도 절차도 바꾸지 않았습니다. 오직 실행되는 CPU만 바꿨을 뿐인데 실패가 성공으로 뒤집혔습니다. 이게 원인이 하드웨어였다는 가장 확실한 증거였습니다.
여기서 솔직하게 밝혀둘 부분이 있습니다. AVX2가 없는 맥에서도 끝까지 버텨보는 우회로가 이론상 없지는 않습니다. Rosetta를 통한 실행이나, AVX2를 요구하지 않는 구버전 바이너리 설치 같은 후보가 떠오릅니다. 다만 저는 이 두 가지를 직접 시도하지 않았습니다. 머신을 옮기는 쪽이 더 빠르고 확실했기 때문입니다. 그래서 이 우회로들이 실제로 통한다고는 말하지 않겠습니다. 해봤다고 쓸 수 있는 건 여기까지입니다.
정리: 재설치를 멈추는 기준
같은 자리에서 Illegal instruction: 4를 두 번 이상 봤다면, 그때부터는 재설치가 아니라 진단을 해야 합니다. 판단 순서는 짧습니다.
- 크래시가 항상 같은 지점에서 나는가 → 우연이 아니라 구조적 원인 의심
sysctl -a | grep avx2실행 → 값이 비어 있으면 AVX2 없음 확정- AVX2가 없으면, AVX2가 있는 머신으로 이동
오래된 하드웨어는 그 자체로 잘못이 아닙니다. 다만 최신 네이티브 바이너리가 요구하는 명령어를 못 가진 것뿐이고, 그건 재설치로 메울 수 있는 종류의 간극이 아닙니다. 저는 이걸 늦게 깨달아 몇 번을 헛으로 다시 깔았습니다. 이 글을 여기까지 읽으셨다면, 같은 반복은 sysctl 한 줄에서 멈추시길 바랍니다.
자주 묻는 질문
맥에서 CLI 설치 중 Illegal instruction: 4가 뜨는 이유는 뭔가요?
네이티브 바이너리가 CPU에 없는 명령어를 실행하려 할 때 나는 에러입니다. 최신 도구가 AVX2 같은 명령어 세트를 요구하는데 오래된 맥의 CPU가 이를 모르면, 실행하는 순간 즉시 죽습니다. 코드 문제가 아니라 CPU가 명령을 이해하지 못해서 나는 신호입니다.
AVX2는 어떤 CPU부터 지원하나요?
AVX2는 2013년 하스웰(Haswell) 세대 이후의 인텔 CPU부터 지원합니다. 그보다 오래된 맥은 하드웨어 자체에 이 명령어가 없어서, 소프트웨어 업데이트로는 해결되지 않습니다.
내 맥에 AVX2가 있는지 어떻게 확인하나요?
터미널에서 sysctl -a | grep avx2 를 실행하면 됩니다. hw.optional.avx2_0: 1 이 나오면 지원하는 것이고, 아무 값도 나오지 않고 비어 있으면 AVX2가 없는 CPU입니다.
AVX2가 없는 맥에서 최신 CLI를 꼭 써야 한다면 방법이 있나요?
AVX2를 지원하는 다른 머신으로 옮기는 것이 가장 확실합니다. 저는 2012년 맥에서 실패하고 2018년 서버로 옮겨 성공했습니다. Rosetta나 구버전 설치 같은 우회는 이론상 후보지만 저는 직접 시도하지 않았으므로 된다고 단정하지 않겠습니다.