OpenAI''s AI Wrote 722 Math Papers. Who Checks Them?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenAI AI가 쓴 수학 논문 722편의 핵심 쟁점은 생산량이 아니라, 증명과 논문의 주장이 일치하는지 누가 독립적으로 검증하고 책임질 것인가다.

📌 핵심 요점

1. 영상에 따르면 OpenAI는 이름을 공개하지 않은 내부 모델에 약 4,000개 문제를 제시하고, 결과를 372개 계열의 논문 722편으로 공개했다. 공개된 것은 논문이며 모델 자체는 이용할 수 없다고 설명한다.
2. 가장 주목받는 사례는 제타함수 영점의 범위를 좁히는 준 리만 가설 관련 결과다. 리만 가설 자체를 해결했다는 주장은 아니며, 전문가가 주로 읽은 짧은 논문과 Lean 증명이 있는 긴 논문도 구분해야 한다.
3. 수학계의 반발은 대량 공개에 따른 검토 부담, 읽기 어려운 서술, 저자의 설명 책임에 집중된다. 영상은 성과를 높이 평가하는 견해와 공개 방식에 대한 비판을 함께 소개한다.
4. Lean은 코드로 작성한 명제에 대한 증명을 검사한다. 그러나 그 명제가 논문의 주장과 같은지까지 자동으로 보장하지 않으므로, 형식 검증과 전문가의 의미 검토가 모두 필요하다.
5. 영상이 인용한 형식화 비율은 주요 결과 719개 중 300개, 약 42%다. 집계 기준과 최신 수치가 불명확한 가운데 부호 오류로 논문 3편이 철회됐으며, 발표자는 이를 코딩 에이전트에도 적용되는 검증 병목으로 해석한다.

🧩 배경과 문제 정의

영상은 OpenAI가 AI 생성 수학 논문 722편을 공개했다는 사건을 통해, 결과를 만드는 속도가 사람이 검토하는 속도를 넘어설 때 생기는 문제를 다룬다. 기존 수학 평가 문제가 포화되자 공개 연구 문제로 평가를 확장했다는 OpenAI의 설명과 함께, 주목할 성과·검토 부담·오류 사례를 제시한다.

핵심 구분은 증명의 기계적 유효성, 형식 명제와 논문 주장의 일치, 인간의 이해다. Lean은 첫 번째를 엄격히 검사할 수 있지만 나머지까지 자동으로 해결하지는 못한다. 발표자는 이 구조를 코딩 에이전트의 명세·테스트·독립 리뷰에 연결한다.

🕒 시간순 섹션별 상세정리

1. 논문 722편 공개와 검증 책임의 등장

• 영상은 AI가 GitHub에 대량의 수학 논문을 올린 뒤 약 하루 만에 부호 오류로 3편이 철회됐다는 사례로 시작한다. 약 4,000개 문제에서 논문 722편과 결과 계열 372개가 나왔으며, 형식화되지 않은 나머지를 누가 검토할지 묻는다. [00:41]
• OpenAI/Math 저장소는 영상에서 설명하는 10월 6일 공개됐다. OpenAI는 기존 수학 평가가 포화돼 연구 문제로 범위를 넓혔다고 설명하며, 모델은 공개하지 않은 내부 모델로 묶인다. [01:59]
• 하드비거 추측, 유리수 위의 힐베르트 열 번째 문제, 지수시간 가설 관련 주장도 나온다. 발표자는 이를 확정된 해결이 아닌 검토 대상인 주장으로 다뤄야 한다고 강조한다. [02:33]

2. 준 리만 가설 관련 성과와 서로 다른 검증 대상

• 제타함수의 영점과 소수 분포의 관계를 설명한 뒤, 실수부가 7/8보다 큰 곳에는 영점이 없다는 논문의 주장을 보여준다. 리만 가설 자체보다 약한 결과라는 점을 분명히 한다. [03:34]
• 199쪽 논문은 7/8 경계를, 49쪽 논문은 더 약한 11/12 경계를 제시한다. 영상에 따르면 짧은 논문은 전체 722편 중 사람이 가독성을 위해 편집한 유일한 논문이다. [03:59]
• 전문가들은 성과를 높이 평가하면서도 서술을 비판한다. 주로 사람이 검토한 것은 짧은 논문이고 Lean 증명이 있는 것은 긴 논문이므로, 인간 검토와 기계 검증이 동일한 문서에 적용됐다고 보면 안 된다. [04:53]

3. 수학계의 반발과 공개를 지지하는 논리

• 테런스 타오는 공개 직전 대규모 문제 해결 방식의 지속 가능성을 비판한 것으로 묶인다. 인간 수학 협회는 700개가 넘는 파일의 동시 공개를 학술 활동보다 힘의 과시라고 표현하며 OpenAI와의 협력 중단을 촉구한다. [05:56]
• 영상은 타오가 해당 성명을 재게시했지만 서명자나 회원은 아니라고 구분한다. 다른 비판자들은 논문이 사람이 검증할 수 있는 증명과 거리가 있거나, 공동체에 정리를 떠넘기는 초고처럼 보인다고 지적한다. [06:29]
• 반대로 성과의 역사적 의미와 연구 공개의 가치를 강조하는 견해도 묶인다. 발표자는 양측 논쟁이 결국 이 모든 결과를 누가 검토하느냐는 질문으로 모인다고 정리한다. [07:09]

4. Lean의 검사 방식과 명제 일치의 한계

• Lean에서는 명제를 코드로 적고 별도 증명을 제공한다. 영상은 Mathlib을 활용한 제타함수 명제, 증명이 채워야 할 자리인 sorry, 약 2,900개 파일과 거의 50만 줄에 이르는 증명 규모를 보여준다. [08:08]
• 작은 신뢰 커널이 증명의 각 단계를 검사한다. 저장소의 comparator는 도전 명제와 해답의 일치, 추가 공리 제한, 커널의 수용을 확인하지만, 이 과정이 199쪽 논문 자체를 검사하는 것은 아니다. [09:01]
• 형식 명제가 논문의 주장과 같은지는 전문가가 확인해야 한다. 일부 형식화가 더 약한 주장이나 일부 내용만 다룬다는 우려에는 직접 확인되지 않았다는 단서가 붙으며, 제타함수 결과의 후반 응용이 형식화 범위 밖이라는 안내도 묶인다. [09:49]

5. 42%의 분모와 실제 철회 사례

• 영상이 인용한 10월 7일 수치는 주요 결과 719개 중 300개가 형식화됐다는 것이다. 이후 형식화가 추가됐어도 새 비율은 없으며, 주요 결과의 정의가 불명확해 발표자가 외부에서 같은 집계를 재현하지 못했다고 보여준다. [10:35]
• 저장소의 검토 상태가 미확인으로 표시됐다는 것은 기계 검사를 하지 않았다는 뜻과 다르다. 영상은 형식 명제와 논문 내용의 일치에 대한 검토 보고가 없다는 의미로 설명하고, Lean 명제의 기술적 문제도 일부 발견됐다고 전해진다. [10:58]
• 한 논문의 부호가 +1에서 -1이어야 했고, 이에 의존한 두 논문까지 총 3편이 철회됐다. 세 논문에는 Lean 형식화가 등록돼 있지 않았으며, 같은 주 다른 원고 14편도 증명 수리와 명제 수정이 이뤄졌다고 보여준다. [11:37]

6. 코딩 에이전트에 적용하는 검증 원칙

• 발표자는 AI의 작성량이 인간의 검토 능력을 넘으면 검증 자체가 일이 된다고 해석한다. 형식 명제는 작업 전 명세와 수용 테스트에, 커널은 매번 실행되는 지속적 통합 검사에 대응시킨다. [12:15]
• sorry는 건너뛴 테스트나 미완성 구현에, 약한 명제는 올바른 값 대신 무언가를 반환하는지만 보는 테스트에 비유된다. comparator처럼 평가 기준을 고정하고, 모델이 스스로 채점하지 않도록 숨겨진 테스트를 쓰는 방식도 제시한다. [12:44]
• 작성자와 분리된 검토자가 변경 사항뿐 아니라 명세를 읽어야 한다고 강조한다. 테스트가 모두 통과해도 잘못된 테스트일 수 있으며, 병합 결과에 책임지는 주체는 에이전트를 운영하는 사람이라고 드러낸다. [13:25]

7. 증명 뒤에 오는 이해와 검증기를 먼저 만들라는 제안

• 과거에는 문제를 풀며 이해가 따라왔지만 이제는 증명이 먼저 도착할 수 있다고 보여준다. 제타함수 논문을 수업에서 연구하고 논증을 짧게 재구성하는 사례를 통해 인간의 이해가 뒤따르고 있다고 보여준다. [13:44]
• 시먼스 재단·Anthropic·OpenAI가 수학자 지원에 합산 1,500만 달러 규모의 자금과 자원을 제공한다고 전해진다. 발표자는 이러한 순서 변화 때문에 만드는 사람에게는 검증기를 먼저 마련하는 일이 중요하다고 결론짓는다. [14:04]
• 읽을 수 없는 풀 리퀘스트 700개를 병합하겠느냐고 묻고, 시청자에게 에이전트 코드의 승인 기준을 생각하도록 권하며 영상을 마친다. [14:14]

🧾 결론

• 논문 수, 형식화 비율, 전문가의 검토 완료 여부는 서로 다른 지표다. 하나의 숫자로 전체 연구의 신뢰도를 판단하기 어렵다.
• 기계가 증명을 통과시켰더라도 무엇을 증명했는지, 논문의 어느 범위까지 다루는지 확인해야 한다.
• 대량 생성 환경에서는 명세를 먼저 정하고, 작성자와 분리된 검토자가 결과와 명세의 일치를 확인하는 일이 핵심 업무가 된다.
• 영상의 마지막 제안은 검증기를 먼저 만들라는 것이다. 결과물을 받아들이는 최종 책임은 이를 승인하는 사람에게 남는다.

📈 투자·시사 포인트

• 영상에서 도출할 수 있는 기술 평가 기준은 생성량보다 검증 가능한 성과의 범위와 독립 검토 여부다. AI 연구 성과를 비교할 때도 이 구분이 필요하다.
• 코딩 에이전트를 운영하는 조직에는 수용 기준, 지속적 통합 검사, 수정할 수 없는 평가 테스트, 독립 리뷰를 함께 설계해야 한다는 시사점이 있다.
• 형식 검증 도구와 전문가의 의미 검토는 서로 보완한다. 검사 도구만 도입하거나 사람의 검토에만 의존하는 방식으로는 영상이 지적한 간극을 모두 다루기 어렵다.
• 영상은 수익성·기업가치·주가 영향을 제시하지 않는다. 여기서 직접 뒷받침되는 판단은 검증 체계의 중요성이며, 특정 기업의 투자 수익 전망까지 확장할 근거는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 42%는 영상이 인용한 OpenAI의 주요 결과 집계에 따른 수치다. 주요 결과의 정의가 명확하지 않고, 발표자는 저장소 파일을 세 방식으로 세어도 300이라는 수치를 재현하지 못했다고 말한다.
• 형식화된 명제가 논문보다 약하거나 일부만 다룬다는 우려는 소개되지만, 해당 전문가가 이를 직접 확인한 것은 아니라고 영상도 단서를 붙인다. 모든 형식화에 문제가 있다는 결론으로 확대하면 안 된다.
• 준 리만 가설 관련 결과는 전문가들이 대체로 옳다고 평가한 것으로 소개된다. 다만 인간이 모든 세부를 확인하고 이해하는 절차까지 끝났다는 뜻은 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 개별 논문을 평가할 때 논문 주장, 형식 명제, 증명 파일, 형식화 범위 안내, 검토 상태를 나란히 확인한다.
• 형식 검증 결과를 인용하기 전에 대상 명제의 일치 여부, 허용 공리, 미완성 증명 표시인 sorry의 잔존 여부를 확인한다.
• 42%라는 수치를 재사용할 때 기준 시점과 분모를 함께 적고, 최신 집계와 주요 결과의 정의가 공개됐는지 확인한다.
• 코딩 에이전트 작업을 시작하기 전에 사람이 읽을 수 있는 명세와 수용 기준을 작성하고, 평가용 테스트를 에이전트가 임의로 바꾸지 못하게 한다.

❓ 열린 질문

• 공개된 전체 결과의 의미 검토는 누가 맡고, 그 비용과 설명 책임은 누가 부담해야 하는가?
• 형식화 비율을 재현 가능하게 계산하려면 주요 결과와 검증 범위를 어떻게 정의해야 하는가?
• 기계 검증과 독립 전문가의 확인이 각각 어느 수준에 도달해야 결과를 정리나 신뢰할 수 있는 코드로 받아들일 수 있는가?