Hacker News 2026.04.28 23

수수께끼의 CPUID 비트 — 인텔이 문서에 안 적은 그 한 칸의 정체

무슨 일이 있었냐면요

OS/2 박물관(os2museum.com)이라는 클래식 컴퓨팅 블로그에 재밌는 추적기가 올라왔어요. 인텔 CPU의 CPUID 명령어가 돌려주는 비트들 중에 "공식 문서 어디에도 설명이 없는 한 칸"이 있는데, 그 정체를 파헤쳐 본 이야기예요. 작은 디테일 같지만 저수준 시스템 프로그래밍을 좋아하시는 분들에겐 진짜 재밌는 수사물이에요.

잠깐, CPUID가 뭐냐면요. 우리가 쓰는 인텔/AMD CPU에는 "너 누구야? 무슨 기능 지원해?"라고 물어보는 명령어가 있어요. 그게 CPUID예요. 이걸 호출하면 EAX, EBX, ECX, EDX 레지스터에 비트별로 "SSE 지원함", "AVX 지원함", "가상화 지원함" 같은 정보가 쫙 채워져 돌아오죠. 운영체제와 컴파일러가 "이 CPU에서 어떤 최적화를 켤까"를 결정할 때 무조건 보는 정보예요.

미스터리 비트의 정체

글쓴이가 옛날 CPU들을 하나하나 돌려가며 CPUID 결과를 비교하다가, 인텔 매뉴얼에는 "reserved"(예약됨, 즉 쓰지 마세요)라고만 적힌 한 비트가 특정 모델에서는 1로 켜져 있고, 어떤 모델에서는 0인 걸 발견했어요. "reserved면 항상 0이어야 하는 거 아닌가?" 하는 의문에서 추적이 시작된 거죠.

과거 자료를 뒤지다 보니, 그 비트는 옛날 어떤 시점에는 특정 기능 — 예를 들면 특정 마이크로아키텍처에서만 의미 있던 캐시 동작 플래그나 디버그 지원 같은 것 — 을 의미했던 것으로 보여요. 그런데 인텔이 어느 순간부터 그 기능을 쓰지 않거나 다른 비트로 옮기면서, 매뉴얼에서 설명만 빠지고 비트 자체는 회로에 남아 있는 상태가 된 거예요. 일종의 "문서화되지 않은 화석"이죠.

이게 왜 흥미롭냐면요. CPU 같은 하드웨어는 한 번 만들어진 회로를 쉽게 바꿀 수 없어서, 호환성 때문에 "의미는 사라졌지만 비트는 남아 있는" 영역이 종종 생겨요. 그리고 옛날 운영체제들이 이런 비트에 의존해서 동작하는 경우도 있기 때문에, 인텔도 함부로 0으로 만들 수 없는 거예요. 결과적으로 매뉴얼은 "reserved"라고 적어두고 침묵하는 길을 택한 거죠.

왜 이런 일이 생기는 걸까

CPU 설계는 수십 년에 걸쳐 누적된 결과물이에요. 1978년 8086부터 시작해서 지금 12세대, 14세대 코어까지 이어지는데, 그 사이사이에 들어왔다가 사라진 명령어와 플래그가 정말 많아요. 어떤 건 너무 안 쓰여서 조용히 비활성화됐고, 어떤 건 "이걸 0으로 만들면 누군가의 부팅이 안 될지도" 하는 두려움 때문에 그대로 남아 있어요.

비슷한 이야기로 인텔의 A20 게이트라는 게 있어요. 8086 시절 메모리 주소 라인의 한계 때문에 생긴 회로인데, 30년 넘게 "호환성 때문에" 그대로 남아 있다가 비교적 최근에야 정리됐죠. 또 x86 어셈블리의 AAA, AAS 같은 BCD 산술 명령어도 거의 아무도 안 쓰지만 회로에는 여전히 자리를 차지하고 있어요. 이런 게 시스템 프로그래밍의 묘미예요. 추상화 아래에는 항상 역사가 깔려 있다는 거.

업계 맥락

요즘 ARM이나 RISC-V가 뜨는 이유 중 하나가 이런 "역사적 짐"이 적기 때문이에요. ARM은 그래도 30년 넘었지만 x86보다는 한결 깔끔하고, RISC-V는 아예 새로 시작한 ISA(명령어 집합)라 reserved 비트의 화석 같은 게 거의 없어요. 애플이 M 시리즈로 ARM에 올인한 것도, 구글과 아마존이 자체 ARM 칩을 만드는 것도, 결국 "x86의 누적된 복잡도가 너무 비싸다"는 판단이 깔려 있어요.

반대로 말하면, x86은 그 누적 자산 덕에 "옛날 게임도 윈도우 95 시절 드라이버도 어떻게든 돌아간다"는 강력한 호환성을 갖고 있어요. 이게 기업용 시장에선 여전히 큰 무기예요.

한국 개발자에게는

웹/앱 개발만 하시는 분들에겐 직접적인 영향은 없어요. 그런데 두 가지를 짚어볼 가치가 있어요.

첫째, 추상화는 공짜가 아니에요. 우리가 printf나 console.log만 써도 돌아가는 건, 누군가 이런 비트 단위의 화석들을 다 신경 써서 OS와 컴파일러를 만들어주기 때문이에요. 가끔 위쪽이 이상하게 동작할 때 "혹시 아래쪽 어딘가에 이상한 게 있을 수도 있다"는 감각을 갖고 있는 것과 없는 것은 디버깅 실력에서 큰 차이를 만들어요.

둘째, 레거시 코드와 사는 법. 우리 회사 코드베이스에도 "왜 있는지 모르겠지만 지우면 뭔가 망가질 것 같은" 코드가 다들 있잖아요. 인텔이 reserved 비트를 그대로 두는 것과 똑같은 이유예요. 무작정 정리하기보다 "왜 남아 있는지"를 기록하고, 안전하게 옮길 수 있을 때 옮기는 신중함이 필요해요.