OpenAI가 ChatGPT 인프라에서 발생한 희귀 크래시를 코어 덤프 분석으로 해결하며 18년 된 소프트웨어 버그를 찾아낸 과정을 공개했습니다.
매일 수많은 질문을 처리하는 대규모 AI 서비스 뒤편에서는 눈에 보이지 않는 문제들이 조용히 쌓입니다. 서버 하나가 갑자기 멈추거나, 아주 가끔씩만 나타나는 오류가 대표적입니다. 이런 간헐적인 결함은 로그만 봐서는 원인을 찾기가 매우 까다롭습니다.
OpenAI에서 ChatGPT 인프라를 담당하는 엔지니어들도 비슷한 상황을 마주했습니다. 모델이 사용자의 질문에 답을 생각하는 순간, 그러니까 추론(inference)이 한창 진행되는 타이밍에 일부 데이터 서비스가 불규칙적으로 충돌하는 현상이 관찰된 겁니다.
원인을 파악하기 위해 엔지니어들이 주목한 건 ‘코어 덤프(core dump)’였습니다. 서버가 예기치 않게 멈출 때 메모리 상태를 통째로 저장해둔 파일인데, OpenAI는 이 덤프 파일 여러 개를 동시에 분석하는 방식으로 느린 수사가 아닌 ‘집단 역학 조사’를 시작했습니다.
충돌은 초당 수천 번의 질문 속에서 발생한다
문제가 발생한 서비스는 C++로 작성된 데이터 인프라의 일부입니다. C++은 시스템 자원을 세밀하게 제어할 수 있어 성능 최적화에 유리합니다. 대규모 트래픽을 감당하면서도 응답 속도를 극도로 끌어올려야 하는 AI 인프라에서는 여전히 중요한 선택지입니다.
하지만 메모리 안전성을 보장하지 않는 C++의 특성상, 잘못된 메모리 주소에 접근하다가 프로세스가 갑자기 종료되는 버그가 생길 수 있습니다. OpenAI의 설명에 따르면, 이번에 문제가 된 충돌은 가끔씩만 발생하는 희귀한 유형이었습니다. 평소에는 멀쩡히 작동하다가 특정 조건이 겹치는 순간에만 서비스가 멈췄습니다.
AI 서비스의 수요가 폭증하는 상황에서는 이런 간헐적 장애가 더 큰 위험으로 다가옵니다. 모델이 추론에 필요한 데이터를 실시간으로 검색해오는 구조에서, 데이터 파이프라인 일부가 예고 없이 꺼져버리면 사용자 경험에 직접적인 영향을 주기 때문입니다.
코어 덤프 하나가 아닌 ‘여러 개’를 모은 이유
보통 이런 문제를 추적할 때는 단일 크래시가 발생한 서버의 로그와 덤프를 분석합니다. 하지만 OpenAI 엔지니어들은 충돌이 발생한 여러 인스턴스의 코어 덤프를 한데 모아 통계적으로 접근했습니다. 마치 역학 조사관이 환자들의 공통점을 찾아내듯 말입니다.
이 방식을 통해 두 가지 상이한 근본 원인이 얽혀 있다는 사실을 발견했다고 합니다. 하나는 지속적으로 메모리 오류를 유발하는 하드웨어 결함이었습니다. 모든 충돌이 이 결함에서 비롯된 것은 아니었고, 하드웨어를 교체한 뒤에도 완전히 사라지지 않았습니다.
남은 충돌을 다시 분석한 결과, 아주 오래된 소프트웨어 버그가 숨어 있다는 점을 확인했습니다. 무려 18년 전에 작성된 코드에서 극히 드물게 메모리 접근 오류가 발생하고 있었던 겁니다. 모든 조건이 완벽하게 정렬됐을 때만 얼굴을 내미는 버그라 지금까지 살아남은 셈입니다.
원인을 둘로 나누자 고칠 것도 둘이었다
OpenAI가 이 과정에서 얻은 교훈은 진단 방식에 있습니다. 시스템 충돌이라는 현상 뒤에 반드시 단 하나의 원인만 있다고 가정할 수 없다는 점입니다. 먼저 하드웨어 오류를 수정하지 않았다면 나머지 소프트웨어 버그는 더 혼란스러운 패턴으로 나타났을 겁니다.
반대로 말하면, 소수의 서버에서만 발생하는 미스터리한 장애를 마주했을 때 ‘하드웨어 탓’ 또는 ‘코드 탓’ 중 하나로 단정 짓지 말아야 한다는 의미이기도 합니다. OpenAI 엔지니어들은 이번 사례를 ‘코어 덤프 역학 조사’라는 이름으로 정리하며, 대규모 분산 시스템을 운영하는 팀이라면 비슷한 진단 전략을 고려해볼 만하다고 조언합니다.
AI Log 관점에서 보면, 이번 사례는 LLM(대규모 언어 모델)의 추론 속도를 높이기 위해 저수준 언어를 활용하는 인프라 설계의 한 단면을 보여줍니다. 성능을 위해 C++ 같은 언어를 선택하면 그만큼 운영 복잡성도 동반된다는 점을 다시 확인시켜 줍니다.
AI 서비스가 커질수록 인프라 디버깅 능력이 중요해진다
이 이야기에서 독자들이 눈여겨볼 부분은 버그의 나이가 아니라 디버깅 접근법입니다. 대규모 언어 모델을 실서비스에 적용하는 회사들이 늘어나면서, AI 모델 자체의 성능뿐 아니라 그 밑단에서 데이터를 공급하는 인프라의 안정성이 점점 더 중요한 변수가 되고 있습니다.
추론 단계에서 실시간 데이터를 조회하는 RAG(검색 증강 생성) 구조가 확산될수록 이번 사례처럼 데이터 파이프라인의 작은 균열이 서비스 전체에 파급될 가능성이 커집니다. 초당 수천 건의 API 호출을 처리하면서도 지연 시간을 최소화해야 하는 환경에서는 단순히 로그를 수집하는 것만으로 충분하지 않을 수 있습니다.
OpenAI가 내부적으로 선택한 진단 방식은 그 자체로 하나의 방법론을 제시합니다. 단일 덤프 분석에 의존하지 않고 여러 충돌 사례를 통계적으로 비교·대조하는 접근은, 비슷한 수준의 분산 인프라를 운영하는 팀이라면 충분히 참고할 만합니다.
앞으로도 수사는 계속될 수밖에 없는 이유
이번 버그가 고쳐졌다고 해서 모든 문제가 사라지는 건 아닙니다. 대규모 C++ 코드베이스에는 아직도 수년, 혹은 수십 년 전에 작성된 코드가 남아있습니다. 모든 조건이 완벽하게 맞아떨어질 때만 모습을 드러내는 잠재적 결함은 앞으로도 새롭게 등장할 가능성이 있습니다.
특히 ChatGPT처럼 전 세계 사용자를 대상으로 하는 서비스에서는 이용 패턴이 다양해질수록 과거에는 드물었던 엣지 케이스(edge case)가 더 자주 발생합니다. 18년 동안 아무 문제 없던 코드가 특정 질문 패턴, 특정 데이터 조회 순서, 특정 시점의 메모리 상태와 만나면서 비로소 충돌을 일으키는 식입니다.
OpenAI 엔지니어들은 이번 경험을 공유하며 인프라 디버깅의 복잡성을 공개적으로 설명했습니다. 단일 공식 자료를 바탕으로 한 설명이지만, 대규모 AI 서비스를 운영하는 팀이라면 한 번쯤 고민해볼 만한 주제임은 분명해 보입니다.
참고
- 원문 링크: https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug
- OpenAI 공식 자료와 AI Log 리서치 노트를 바탕으로 작성한 단일 출처 기반 초안입니다.
- 발행 전 원문 확인이 필요합니다.
