OpenAI가 공개한 “Core dump epidemiology”는 흔한 장애 회고가 아니다. ChatGPT 데이터 인프라의 일부인 Rockset 서비스에서 드문 segfault가 발생했고, 겉으로는 평범한 C++ 함수가 끝난 뒤 엉뚱한 주소로 return 하며 죽는 형태였다. 어떤 core dump에서는 saved return address가 NULL처럼 보였고, 어떤 경우에는 x86_64의 stack pointer인 %rsp가 8바이트 어긋난 듯했다.
이 증상이 까다로웠던 이유는 애플리케이션 코드만으로 설명하기 어려웠기 때문이다. saved return address만 정확히 망가뜨리는 stray write는 가능하지만 매우 드물다. inline assembly, setcontext, longjmp 같은 경로 없이 %rsp가 중간에 달라지는 것도 이상하다. 게다가 ASAN staging 환경에서도 잡히지 않았고, 로그의 stack trace 자체가 깨져 있어 일반적인 로그 쿼리로는 신뢰할 만한 전체 사례 목록을 만들기 어려웠다.
초기 접근은 전통적인 디버깅에 가까웠다. 코어 덤프 몇 개를 깊게 들여다보고 stack/register 상태를 복원하며 가설을 지워나갔다. 하지만 결정적인 전환은 개별 사례를 더 깊게 보는 대신, 전체 crash population을 분석 가능한 데이터셋으로 다루는 방식에서 나왔다. frame pointer, red zone, register 상태 같은 낮은 레벨의 단서를 체계적으로 추출하자 하나로 보였던 문제가 실제로는 둘이라는 사실이 드러났다.
첫 번째 원인은 특정 Azure host의 silent hardware corruption이었다. CPU가 계산을 제대로 하지 않는 종류의 장애다. 두 번째 원인은 GNU libunwind에 18년 동안 숨어 있던 race condition이었다. 예외 처리가 단순한 함수 호출 흐름이 아니라 동적인 control transfer라는 점, 그리고 single-instruction race window가 겹치면서 crash가 평범한 bad return처럼 보였다.
이 사례의 핵심은 “C++은 위험하다”보다 더 넓다. 대규모 AI 인프라에서는 모델, 데이터 시스템, 런타임 라이브러리, 운영체제 ABI, 하드웨어가 한 체인으로 연결된다. 희귀 crash 하나를 확대하면 미스터리처럼 보이지만, 전체 분포를 보면 원인군이 갈라질 수 있다. OpenAI의 글은 현대 AI 서비스의 신뢰성이 모델 평가만이 아니라 관찰 가능한 인프라를 얼마나 촘촘히 설계하느냐에 달려 있음을 보여준다.