소프트웨어 엔지니어로서 우리는 보통 하드웨어를 ‘절대적인 진실(Ground Truth)‘로 가정하고 코드를 짭니다. “내 코드가 틀렸겠지, CPU가 덧셈을 틀렸을 리는 없어”라는 믿음이죠. 하지만 경력이 쌓이고, 로우 레벨 디버깅의 늪에서 며칠 밤을 새우다 보면 깨닫게 됩니다. 하드웨어 엔지니어들도 결국 사람 이고, 그들이 짜는 Verilog나 VHDL도 결국 버그가 있는 코드라는 사실을요.

최근 Hacker News와 기술 블로그에서 화제가 된 A few CPU hardware bugs라는 글을 읽으면서 쓴웃음을 지을 수밖에 없었습니다. 인텔(Intel) 같은 거대 기업조차 피해 갈 수 없는 ‘오타’부터, 임베디드 칩의 황당한 파이프라인 버그까지, 흥미로운 사례들을 엔지니어링 관점에서 뜯어보겠습니다.

1. GenuineIotel: 비트 플립인가, 합성 오류인가?

CPUID 명령어는 x86 프로세서의 신분증과 같습니다. 벤더 ID 문자열로 GenuineIntel이 리턴되는 것은 업계의 상식이죠. 하지만 Xeon E3-1231 v3 같은 일부 프로세서에서는 이 문자열이 GenuineIotel로 리턴되는 사례가 보고되었습니다.

처음에는 단순한 가짜 CPU(Fake CPU)라고 생각하기 쉽지만, 이 현상은 정품에서도 발생합니다. 기술적으로 흥미로운 점은 ‘n’과 ‘o’의 차이입니다.

• GenuineIntel: …01101110 (n)
• GenuineIotel: …01101111 (o)

정확히 LSB 1비트 차이 입니다. 제조 공정상의 결함으로 특정 트랜지스터가 Stuck-at-1 결함을 일으켰을 가능성이 높습니다. 하지만 Hacker News의 한 유저는 “단순한 물리적 결함이라기엔 너무 널리 퍼져 있다, 로직 합성(Logic Synthesis) 과정에서의 버그일 수도 있다”는 의혹을 제기하기도 했습니다. 어느 쪽이든, 수억 개의 트랜지스터 중 단 하나가 삐끗하면 내 CPU는 평생 자신의 이름을 오타 낸 상태로 살아야 합니다.

2. ore i5: 펌웨어 엔지니어의 실수?

더 황당한 건 Core i5-1245U 에서 발견된 Intel(R) ore(TM) i5-1245U라는 브랜드 문자열입니다. ‘Core’에서 ‘C’가 빠져서 ‘ore(광석)‘가 되어버렸습니다.

단순히 사용자가 타이핑을 잘못한 게 아닙니다. 우분투(Ubuntu) 인증 하드웨어 리스트의 델(Dell) 노트북에서도 확인된 내용입니다. CPUID 정보는 보통 마이크로코드나 시스템 펌웨어(BIOS/UEFI)에서 주입되는데, 이건 십중팔구 휴먼 에러 입니다. 누군가 펌웨어 스트링 테이블을 작성하다가 실수로 백스페이스를 한 번 더 눌렀고, 그게 QA를 통과해서 전 세계로 출하된 것이죠.

Principal Engineer로서 이런 걸 보면 등골이 서늘해집니다. “저런 사소한 문자열 검증도 놓쳤는데, 과연 복잡한 캐시 일관성(Cache Coherency) 로직은 완벽할까?”라는 의심이 들기 때문입니다.

3. 11월은 31일까지 있다 (Rockchip RK808)

Hacker News 댓글에서 발견한 또 다른 보석 같은 버그는 Rockchip의 RK808 RTC(Real Time Clock)입니다. 이 칩의 하드웨어 엔지니어들은 11월이 31일까지 있다고 생각하고 회로를 설계 했습니다.

이 때문에 리눅스 커널에는 RK808의 날짜를 그레고리력으로 변환하는 패치가 존재합니다. 하드웨어 버그를 소프트웨어로 땜질하는 전형적인 예시입니다. 시간이 지날수록 실제 시간과 칩 내부의 시간이 벌어지기 때문에, OS 레벨에서 이를 보정해줘야 합니다. 임베디드 개발을 하다 보면 이런 ‘Spec 위반’ 하드웨어를 자주 마주치게 되는데, 그때마다 제조사 데이터시트를 믿었던 과거의 자신을 원망하게 됩니다.

4. ITE IT81202: 파이프라인 해저드의 공포

앞선 예시들이 웃어넘길 수 있는 수준이라면, ITE의 IT81202(RISC-V 기반 임베디드 컨트롤러) 버그는 치명적(Critical) 입니다.

이 칩에는 심각한 파이프라인 버그가 있습니다. 곱셈 명령어(mul) 바로 뒤에 레지스터를 수정하는 명령어가 오면, 그 명령어가 무시되거나 오작동 합니다. 전형적인 파이프라인 해저드(Pipeline Hazard) 처리가 누락된 하드웨어 설계 오류입니다. 보통은 하드웨어 레벨에서 Stall을 걸거나 Forwarding을 해줘야 하는데, 그게 빠진 겁니다.

해결책은? 컴파일러에게 “이 CPU는 곱셈을 할 줄 모른다”고 거짓말을 해서 소프트웨어적으로 곱셈을 처리하게 하거나, mul 뒤에 강제로 NOP을 삽입해야 합니다. 성능 저하는 덤입니다.

결론: 맹신하지 말고 검증하라

우리는 추상화의 탑 위에서 살고 있습니다. 하지만 그 바닥을 지탱하는 실리콘조차 완벽하지 않습니다. 인텔 같은 거인도 오타를 내고, 임베디드 칩들은 달력을 창조하거나 파이프라인을 꼬아버립니다.

시스템이 도저히 설명할 수 없는 이유로 크래시가 나거나 데이터가 오염된다면, 한 번쯤은 의심해 볼 만합니다. “혹시 내 CPU가 거짓말을 하고 있나?”

물론 99.9%는 우리 코드의 버그겠지만, 그 0.1%의 가능성을 알고 있는 엔지니어와 모르는 엔지니어의 디버깅 깊이는 다를 수밖에 없습니다.