18년 된 버그를 잡은 건 '더 똑똑한 AI'가 아니라 '역학(epidemiology)'이었다

AI 회사가 아주 어려운 버그를 잡았다는 이야기를 들으면, 보통 "역시 똑똑한 AI가 순식간에 찾아냈겠지"라고 상상하게 돼요. 그런데 OpenAI가 최근 공개한 코어덤프 역학(core dump epidemiology) 사례는 정반대예요. 18년 묵은 버그를 잡은 열쇠는 더 강력한 모델이 아니라 문제를 바라보는 각도를 바꾼 것이었어요. 임상의가 아니라 역학자처럼 본 거죠. 저는 이 이야기가, 흔한 "AI가 다 한다" 서사보다 지금 AI가 개발에 실제로 기여하는 방식을 훨씬 정직하게 보여준다고 봐요.

무슨 일이 있었나

여러 보도를 종합하면 이래요. 몇 달 전 OpenAI는 Rockset 서비스 내부에서 이따금 크래시가 나는 걸 관찰했어요. Rockset은 ChatGPT 데이터 인프라의 일부로, 여러 데이터 플러그인과 대화 검색에 쓰이는 중요한 조각이에요. 크래시는 C++ 함수가 손상됐거나 NULL인 주소로 리턴하는 것처럼 보였는데, 워낙 드물어서 통제된 테스트로는 재현이 안 됐어요. 그래서 처음엔 단일 원인이라고 가정했고요.

여기서 팀이 방향을 틀었어요. 증거가 풍부한 개별 사례 하나를 파고드는 대신, 역학자처럼 집단 전체를 놓고 "한 건만 봐서는 안 보이는 패턴이 있나?"를 물었어요. 지난 1년간 Rockset이 남긴 모든 코어덤프를 내려받아 파싱하고 분류하는 자동 파이프라인을 만들었는데, 이 파이프라인의 일부는 ChatGPT가 작성했어요.

그렇게 인구집단을 보니 하나로 뭉쳐 보이던 미스터리가 서로 무관한 두 버그로 갈라졌어요. 하나는 하드웨어 문제였어요. 스택 정렬이 어긋나는 크래시들은 전부 한 지역에서 나왔고, 시작 시점이 뚜렷했고, 오래 돌던 노드에서는 안 났어요. 여러 Azure VM에 걸쳐 있었지만 패턴은 하드웨어가 망가진 물리 머신 한 대를 가리켰어요. 다른 하나는 소프트웨어였어요. GNU libunwind(C++ 예외 스택 되감기 라이브러리)에 18년간 숨어 있던 레이스 컨디션이었죠. 어셈블리 명령 하나가 목적지 명령 포인터를 읽기 전에 스택 포인터를 먼저 갱신하는데, 약 100피코초짜리 그 틈에 시그널이 도착하면 커널이 처리 중이던 컨텍스트를 덮어써 버리는 거였어요.

그래서 무엇을 말하나

이 사례에서 저는 두 가지가 인상적이었어요.

첫째, 결정적 도구는 알고리즘이 아니라 관점이었어요. 같은 크래시를 한 건씩 붙잡고 봤다면 영원히 "가끔 나는 이상한 메모리 손상"으로 남았을 거예요. 두 버그가 한 증상으로 겹쳐 보이니 재현도 안 되고 원인도 안 잡히는 게 당연했고요. 관점을 임상의(개별 환자)에서 역학자(인구집단)로 바꾸는 순간, 겹쳐 있던 두 신호가 분리됐어요. 시작 시점, 지역, 노드 수명 같은 분포를 보니 하드웨어 결함의 지문이 드러났고, 남은 크래시가 순수한 소프트웨어 레이스로 정제된 거예요. 이건 모델 성능 문제가 아니라 문제 재정의(reframing)의 승리예요.

둘째, 이 이야기에서 AI는 주인공이 아니라 도구였어요. ChatGPT는 18년 된 버그를 "발견"하지 않았어요. 1년치 코어덤프를 내려받고 파싱하고 분류하는 지루한 파이프라인을 짜는 데 쓰였을 뿐이에요. 그런데 저는 이게 폄하가 아니라고 봐요. 오히려 정반대예요. 그 지루한 대량 처리 파이프라인이 없었으면 역학적 관점 자체가 불가능했거든요. 통찰(집단으로 보자)은 사람이 냈고, 그 통찰을 실행 가능하게 만든 규모의 노동은 AI가 감당한 거예요. 통찰과 노동의 분업, 저는 이게 지금 AI가 엔지니어링에 기여하는 가장 현실적인 그림이라고 봐요.

이건 5월에 다룬 'K자형 생산성' 이야기와도 이어져요. AI는 문제를 어떻게 프레이밍할지 아는 사람의 손에서 배수기(amplifier)가 돼요. "코어덤프를 집단으로 보자"는 판단을 내린 사람에게 AI는 그걸 하루 만에 가능하게 해줬지만, 그 판단 자체를 대신 내려주진 않았어요. 오늘 같이 발행한 과학 벤치마크 글에서 최고 모델이 유전체학 문제를 31.5%밖에 못 풀었던 것과도 같은 메시지예요. 희소한 건 판단이지 처리량이 아니에요.

이렇게 볼 수도 있어요

물론 이건 OpenAI가 직접 쓴 포스트모템이라, 자기 팀의 접근을 멋지게 서술했을 가능성을 감안해야 해요. "AI가 파이프라인을 짰다"는 부분도 실제 기여 비중이 얼마인지는 글만으로 알 수 없고요. 그리고 이런 역학적 접근이 모든 버그에 통하는 것도 아니에요. 코어덤프처럼 대량의 구조화된 흔적이 쌓이는 문제라서 인구집단 분석이 먹힌 거지, 단서가 한 줌뿐인 버그엔 안 통해요.

그래도 저는 교훈이 분명하다고 봐요. 재현이 안 되는 희귀 버그를 만났을 때, "더 똑똑한 디버거"를 찾기 전에 "내가 지금 개별 사례를 보고 있나, 집단을 보고 있나"를 먼저 물어보라는 것. 관점을 바꾸는 게 도구를 바꾸는 것보다 먼저일 때가 많아요.

한국 개발자 입장에서

두 가지를 챙기면 좋겠어요. 첫째, 프로덕션에서 재현 안 되는 희귀 크래시에 시달린다면 로그·크래시덤프를 개별 티켓이 아니라 데이터셋으로 다뤄 보세요. 이 사례의 방법론이 그대로 실무 레시피예요. 일정 기간의 크래시를 전부 모아 시작 시점, 호스트/리전, 인스턴스 수명, 버전 같은 축으로 분포를 그려 보는 것. 하나로 보이던 장애가 사실 둘 이상일 수 있고, 그 분리가 원인 파악의 절반이에요. 요즘은 이런 수집·분류 파이프라인을 AI로 빠르게 스캐폴딩할 수 있으니, 진입 장벽도 예전보다 낮아졌고요.

둘째, AI를 어디에 쓸지에 대한 감을 여기서 얻을 수 있어요. AI에게 "이 버그 원인 찾아줘"라고 통째로 던지는 것보다, "이 통찰을 검증할 대량 처리 도구를 만들어줘"라고 맡기는 게 지금 단계에선 훨씬 잘 통해요. 판단은 내가 쥐고, 규모의 노동을 AI에 넘기는 것. 18년 된 버그를 잡은 팀이 실제로 한 게 딱 그거였어요.

---

근거가 된 소식: Core dump epidemiology: fixing an 18-year-old bug (OpenAI), Core dump epidemiology 정리 (ChipOS), OpenAI Engineers Trace 18-Year-Old Libunwind Race Bug (Let's Data Science)