Firefox가 Intel Raptor Lake에서 죽는 이유 - CPU 버그를 소프트웨어로 막는 법

잘 돌아가던 브라우저가 갑자기 죽기 시작했다

노트북이나 데스크톱에서 Firefox를 쓰는데 갑자기 크래시가 자주 발생한다면, 혹시 CPU가 Intel 13세대(Raptor Lake)나 14세대(Raptor Lake Refresh)인지 한번 확인해보세요. Mozilla가 최근에 패치한 Bug 1950764가 바로 이 문제를 다루고 있거든요. 그런데 흥미로운 건, 이게 Firefox의 버그가 아니라 CPU 자체의 하드웨어 버그라는 점이에요.

Intel Raptor Lake는 출시 직후부터 "고전력 상태에서 불안정하다"는 보고가 쏟아진 칩이에요. 게이밍 PC에서 갑자기 게임이 튕기거나, Unreal Engine 컴파일이 실패하거나, 심지어는 일정 시간 사용 후 영구적으로 성능이 저하되는 사례가 나왔죠. Intel은 결국 2024년에 마이크로코드 패치를 여러 차례 내놓으면서 "산화(oxidation) 문제와 전압 알고리즘 결함"을 인정했어요.

무슨 일이 벌어지고 있나

Mozilla가 추적한 크래시의 패턴이 특이해요. JavaScript JIT 컴파일러가 생성한 특정 코드가 실행될 때 CPU가 잘못된 결과를 내거나 아예 예외를 던지는 거예요. 같은 코드가 다른 CPU에서는 멀쩡히 돌아가는데 Raptor Lake에서만 죽어요.

원인은 CPU의 "부스트 클럭" 동작과 관련이 있는 것으로 보여요. CPU가 짧은 시간 동안 정상 주파수보다 훨씬 높게 동작할 때, 특정 명령어 조합에서 계산이 어긋나는 거죠. 특히 AVX 같은 벡터 명령어와 분기 예측이 얽힐 때 문제가 잘 터져요. JIT 컴파일러는 성능을 위해서 이런 명령어를 적극적으로 쓰니까 직격탄을 맞은 거예요.

Mozilla의 우회법

패치 내용을 보면 접근 방식이 실용적이에요. "CPU 버그를 우리가 고칠 수는 없으니, 버그를 안 건드리도록 코드를 바꾸자"는 전략이거든요.

구체적으로는 SpiderMonkey(Firefox의 JavaScript 엔진)의 JIT이 특정 명령어 시퀀스를 생성할 때, 문제가 되는 패턴을 피해서 다른 명령어로 대체해요. 예를 들어 특정 레지스터 조합이나 명령어 순서가 트리거가 된다면, 그 패턴이 나오지 않도록 코드 생성기를 살짝 비틀어요. 성능에는 약간 손해가 있지만, 크래시보다는 낫죠.

또 하나, CPU ID를 체크해서 Raptor Lake 계열에서만 이 우회법을 활성화해요. 다른 CPU에서는 원래 코드 그대로 돌리고요. CPUID 명령어로 "너 누구야"를 물어보고, 해당하면 안전 모드로 전환하는 거죠.

이게 왜 중요한가

소프트웨어 개발자 입장에서 보면, 이번 사건은 흥미로운 시사점을 던져요. 우리는 보통 CPU를 "명세대로 정확하게 동작하는 블랙박스"로 가정하잖아요. 1 + 1을 시키면 항상 2가 나온다고 믿고 코드를 짜요. 그런데 실제로는 CPU도 하드웨어 버그가 있고, 그게 사용자 환경에서 터지면 결국 애플리케이션이 책임을 져야 할 때가 있어요.

역사적으로도 비슷한 사례가 있었어요. 1994년 Intel Pentium의 FDIV 버그(부동소수점 나눗셈에서 잘못된 결과)는 너무 유명하죠. 더 최근에는 2018년 Spectre와 Meltdown이 있었고요. AMD도 Zen 1 시절에 segfault 버그가 있어서 GCC 컴파일 중에 죽는 일이 있었어요. 모든 CPU 제조사가 한 번씩은 겪는 일이에요.

다만 Raptor Lake가 특별히 주목받는 이유는, 문제의 범위가 넓고 영구적 손상까지 일으킬 수 있다는 점이에요. Intel이 결국 5년 보증으로 연장하면서 사실상 패배를 인정한 셈이죠.

다른 소프트웨어들의 대응

Firefox만 영향을 받는 게 아니에요. Chrome의 V8 엔진도 비슷한 보고가 있었고, Node.js 환경에서 빌드가 실패하는 사례도 보고됐어요. Linux 커널도 특정 워크로드에서 unexpected machine check를 받는 경우가 있고요. 게임 쪽에서는 특히 Unreal Engine 5로 만든 타이틀들이 셰이더 컴파일 중에 죽는 패턴이 잦아서, Epic이 직접 가이드를 낼 정도였어요.

각 소프트웨어 벤더마다 대응이 다른데, 대체로 "JIT/AOT 컴파일러의 코드 생성 패턴을 조정"하는 방향이에요. Firefox가 한 것과 비슷하죠.

한국 개발자에게

JIT을 직접 만들 일은 거의 없겠지만, 알아둘 가치는 충분해요.

첫째, 재현 안 되는 크래시 리포트가 올 때 CPU 모델을 의심해보는 습관이 필요해요. 사용자의 99%는 멀쩡한데 특정 하드웨어에서만 죽는다면, 이런 가능성도 고려해야 해요. Sentry나 Crashlytics 같은 도구로 CPU 정보를 같이 수집하면 좋아요.

둘째, BIOS와 마이크로코드 업데이트를 안내해야 할 수 있어요. 회사에서 데스크톱 앱을 배포한다면, 사용자에게 "BIOS 업데이트하세요"라고 안내하는 가이드가 있어야 할 수도 있어요.

셋째, 서버 인프라를 고를 때 클라우드 인스턴스의 CPU 세대를 확인하는 것도 의미가 있어요. AWS나 GCP에서 새 인스턴스 타입이 나오면 일정 기간은 안정성을 지켜보는 게 안전해요.

마무리

"버그 없는 코드를 짜자"는 우리의 목표지만, 코드 아래의 CPU도 버그가 있다는 사실은 가끔 잊게 돼요. 이번 Firefox 패치는 그 현실을 다시 일깨워주는 사례예요. 여러분은 하드웨어 레벨의 버그에 부딪혀본 경험이 있으세요? 혹시 Raptor Lake CPU 쓰시는 분들 중에 비슷한 증상 겪어본 분 계신가요?