오픈AI가 80년 된 수학 문제를 해결했다고 주장 — 이번엔 진짜

OpenAI는 자사의 추론 모델(reasoning model)이 1946년부터 미해결로 남아 있던 기하학 추측을 반증(disprove)했다고 발표했다. 이전에 비슷한 주장이 수학자들에 의해 반박당해 큰 망신을 산 적이 있는데, 이번에는 검증을 맡았던 수학자들이 결과를 인정했다는 점이 핵심이다. 기술적으로 이 작업은 단순한 패턴 매칭이 아니라, 모델이 긴 사고 사슬(chain-of-thought)을 통해 반례(counterexample)를 구성하는 방식으로 이루어진다. 추론 모델은 후보 구조를 생성하고, 자체 검증 단계에서 조건을 위반하지 않는지 확인하며, 실패한 경로를 폐기하고 다시 탐색하는 식의 강화학습 기반 탐색 과정을 거친다. 이는 정리 증명(theorem proving)이 아니라 "추측을 깨는 구체적 사례 찾기"에 가까운 문제로, LLM의 광범위한 지식과 수치/기호 조작 능력이 결합될 때 인간 수학자가 80년간 발견하지 못한 구성도 찾아낼 수 있음을 시사한다.

개발자/엔지니어 관점에서 이 사건은 두 가지 의미를 가진다. 첫째, 추론 모델의 능력이 "코딩 보조" 수준을 넘어, 검증 가능한 정답이 존재하는 문제 영역(수학, 알고리즘 설계, 형식 검증, 컴파일러 최적화, SAT/SMT 솔버 보조 등)에서 실질적 도구로 활용될 수 있는 단계에 접어들었다는 신호다. 특히 분산 시스템의 invariant 위반 시나리오 탐색, 보안 취약점 PoC 생성, 복잡한 알고리즘의 경계 조건 반례 찾기처럼 "기존 가정을 깨는 사례"를 만들어야 하는 작업에서 직접적인 활용 가능성이 높다. 둘째, 이전 OpenAI의 비슷한 발표가 망신으로 끝났던 사례에서 보듯 "AI가 풀었다"는 주장은 외부 전문가의 독립 검증을 거치기 전까지는 신뢰할 수 없다는 점이 다시 확인됐다. 출력에 대한 검증 파이프라인을 갖추지 않은 AI 도입은 오히려 위험을 키울 수 있다.

실무에서 당장 취할 수 있는 액션은 다음과 같다. (1) 추론 모델(o-시리즈, Claude Opus의 extended thinking 등)을 사용할 때, 단순 생성보다는 "후보 출력 + 자동 검증기" 구조로 파이프라인을 구성할 것 — 본 사례처럼 모델이 만든 답을 외부 검증기(테스트, 타입체커, 정형 명세, 또는 별도 LLM 리뷰어)로 반드시 거르는 흐름이 정답률을 비약적으로 끌어올린다. (2) 자신의 도메인에서 "검증은 쉽지만 생성은 어려운" 문제(NP 구조의 작업)를 식별해 우선순위를 두고 AI를 투입하라. 반대로 검증 자체가 모호한 문제(주관적 디자인, 비즈니스 판단)는 여전히 사람이 결정 주체로 남아야 한다. (3) 마케팅성 발표에 휘둘리지 말고, 실제 성능은 자신의 워크로드에서 A/B로 측정할 것. 80년 묵은 수학 추측을 깬 모델이 우리 회사의 레거시 자바 코드에서도 같은 수준으로 동작한다는 보장은 없으며, 도메인 특화 평가셋 없이 도입을 결정하는 것은 위험하다.