OpenAI, 코어 덤프 분석으로 18년 된 오픈소스 버그와 하드웨어 결함 규명

원인을 알 수 없는 C++ 충돌이 프로덕션 환경에서 반복되고 콜스택마저 망가져 있다면, 일반적인 디버깅 방식으로는 답을 찾기 어렵습니다. OpenAI 역시 최근 사내 데이터 인프라 서비스인 Rockset에서 이와 같은 기이한 충돌 현상에 부딪혔습니다. Rockset은 OpenAI가 2024년에 인수한 C++ 기반 실시간 검색 엔진으로, ChatGPT의 웹 검색과 플러그인, 작업 공간 데이터 동기화를 지탱하는 핵심 부품입니다.

증상은 상식 밖이었습니다. 정상적인 C++ 함수가 실행을 마치고 복귀하는 순간 유효하지 않은 메모리 주소를 가리키며 크래시가 났습니다. 반환 주소가 NULL로 비어 있거나, 스택 포인터 레지스터가 뜬금없이 8바이트 어긋나 있기도 했습니다. 일반적인 컴파일러가 만들어내는 코드에서는 일어날 수 없는 형태였습니다.

ChatGPT로 1년 치 코어 덤프를 역학 조사하다

단일 크래시를 붙잡고 씨름하던 엔지니어들은 개별 환자를 진료하는 의사 방식 대신, 전체 인구를 통계적으로 분석하는 역학 조사 기법으로 방향을 틀었습니다.

이들은 ChatGPT를 활용해 Azure에 저장된 지난 1년간의 프로덕션 코어 덤프를 자동으로 내려받고 분석하는 파이프라인을 구축했습니다. 스크립트가 각 덤프의 레지스터 상태를 추출하고 크래시 유형을 자동 분류하자, 하나의 유령 버그처럼 보였던 현상이 완전히 성격이 다른 두 개의 독립된 집단으로 나뉘었습니다.

계산 틀리는 CPU와 18년 묵은 오픈소스 버그

데이터가 분류되자마자 원인이 드러났습니다. 첫 번째 집단은 단 한 대의 특정 Azure 물리 서버에서만 발생하고 있었습니다. CPU가 기초적인 연산 자체를 틀리게 수행하는 극히 드문 하드웨어 무음 손상이 원인이었습니다.

두 번째 집단은 널리 쓰이는 오픈소스 라이브러리인 GNU libunwind에서 18년 동안 숨어 있던 레이스 컨디션 버그였습니다. Rockset이 쿼리 CPU 시간을 측정하기 위해 몇 밀리초마다 시그널을 보내는 고빈도 아키텍처를 쓰다 보니, 이 오래된 동시성 결함이 집중적으로 촉발된 것입니다. 해당 오픈소스 버그는 현재 패치가 완료되었습니다.

왜 중요한가

일반 사용자 입장에서는 ChatGPT의 검색 기능과 외부 데이터 연동이 한층 더 안정적으로 동작하게 되었다는 실질적인 이점이 있습니다.

우리가 보기에 이번 사례에서 가장 영리했던 부분은 디버깅 패러다임의 전환입니다. 복잡한 C++ 메모리 오염 문제를 만났을 때 개별 덤프에 매달리는 대신, LLM을 활용해 대규모 바이너리 분석 파이프라인을 빠르게 짜서 데이터셋 구축과 통계적 군집화로 해결했습니다.

동시에 현대 AI 인프라의 아슬아슬한 밑바닥도 잘 보여줍니다. 프론티어 AI 모델이 추론 시점에 방대한 데이터를 초고속으로 뒤지려면 결국 저수준 C++ 시스템에 의존할 수밖에 없습니다. 하지만 그 밑바닥에서는 수십 년 된 오픈소스 라이브러리의 맹점이나 클라우드 데이터센터의 미세한 하드웨어 결함이 언제든 터질 수 있습니다. AI 에이전트와 실시간 검색이 보편화될수록 이런 소프트웨어와 하드웨어 경계면을 모니터링하는 역량이 인프라 경쟁력의 핵심이 될 것으로 보입니다.