Navier–Stokes 발표로 본 Agentic AI: 탐색을 증명으로 연결하는 하네스

2026년 9월 8일, OpenAI는 매끄러운 외력이 있는 3차원 Navier–Stokes 방정식에서 유한시간 특이점을 구성하는 해법을 발표했다. 밀레니엄 문제의 공식 해결 경로인 C·D를 겨냥한 결과이며, 논문과 Lean 형식화가 함께 공개됐다. OpenAI 발표

이 사례를 이해하려면 수학적 결과와 그 결과를 찾은 작업 방식을 함께 살펴야 한다. 여러 접근을 탐색하는 agent, 중간 결과를 모으는 과정, 인간의 방향 조정, 그리고 형식 검증이 하나의 연구 과정에 등장했기 때문이다.

이번 글에서는 Navier–Stokes 방정식과 발표된 정리를 먼저 설명하고, 여러 agent의 탐색을 검증 가능한 산출물로 연결하는 **하네스(harness)**의 역할을 살펴본다.

이 글은 2026년 9월 16일까지 공개된 자료를 기준으로 작성했다. 발표 내용과 공개 코드의 구조를 분석하며, 논문 전체의 독립 검증이나 Lean 전체 빌드 재현을 보고하는 글은 아니다.

1. Navier–Stokes 방정식과 이번 발표의 수학적 범위

유체의 속도는 무엇에 의해 바뀌는가?

밀도가 일정한 3차원 비압축성 유체를 생각하자. 압력을 밀도로 나누어 정규화하면 Navier–Stokes 방정식은 다음과 같이 쓸 수 있다.

$$ \partial_t u+(u\cdot\nabla)u = -\nabla p+\nu\Delta u+f, \qquad \nabla\cdot u=0.  $$

여기서 각 변수는 다음을 의미한다.

• $u(x,t)$: 위치 $x$, 시간 $t$에서의 속도 벡터
• $p(x,t)$: 밀도로 정규화한 압력
• $\nu>0$: 동점성계수
• $f(x,t)$: 단위 질량당 외력

방정식의 각 항을 보면 물리적 의미가 조금 더 선명해진다.

왼쪽 두 항을 합치면 움직이는 유체 입자의 가속도가 된다. 오른쪽은 그 가속도를 만드는 압력, 점성, 외력의 효과다.

점성은 움직임을 매끄럽게 하는 효과를 갖는다. 하지만 비선형 항과 상호작용하는 모든 상황에서 특이점을 막을 수 있는지는 별개의 수학적 질문이다.

매끄러운 초기조건에서 시작한 해가 계속 매끄럽게 존재하는가? 아니면 유한한 시간 안에 그 성질이 무너질 수 있는가?

이것이 존재성과 매끄러움 문제의 핵심이다. 모든 유동을 계산하는 일반적인 닫힌 형태의 공식을 찾는 문제와는 구분해야 한다. Clay 공식 문제 정의

OpenAI 논문은 무엇을 증명했다고 주장하는가?

논문 정리 1.1의 핵심은 다음과 같다. 모든 양의 점성계수 (\nu>0)에 대해,

$$ f\in C_c^\infty \left(\mathbb{R}^3\times(0,\infty);\mathbb{R}^3\right) $$

인 외력과, $0\le t<1$ 에서 매끄러운 속도·압력 $u,p$ 를 구성해 다음을 만족시킨다는 주장이다. 앞의 방정식을 항만 옮겨 적으면,

$$ \partial_tu+(u\cdot\nabla)u-\nu\Delta u+\nabla p=f, \qquad \nabla\cdot u=0, \qquad u(x,0)=0. $$

여기에 두 조건이 동시에 성립한다.

$$ \sup_{0\le t<1} |u(\cdot,t)|_{L^2(\mathbb{R}^3)} <\infty, $$

$$ \limsup_{t\uparrow1} |u(\cdot,t)|_{L^\infty(\mathbb{R}^3)} =\infty. $$

$C_c^\infty$는 무한히 미분 가능하고 compact support를 갖는다는 뜻이다. 외력을 공간·시간의 유한한 범위에 가두면서, 정지 상태에서 출발한 속도가 유한시간 안에 발산하도록 구성한다.

$L^2$ 노름의 제곱은 운동에너지에 비례한다. $L^\infty$ 노름은 속도 크기의 본질적 상한을 나타낸다. 즉 총에너지는 유계지만 속도의 최댓값은 발산한다.

논문은 이 구성을 같은 초기값과 외력에 대한 전역 매끄러운 유계에너지 해의 부재로 연결한다. 여기에는 구성한 해와 다른 전역 해가 함께 존재할 수 없음을 보이는 비교 논증도 필요하다. 전공간 결과는 정리 1.1에, 주기 영역 결과는 따름정리 10.6에 제시돼 있다. 논문 원문

속도가 발산하는데 에너지는 어떻게 유한할까?

최댓값과 공간 전체의 적분은 서로 다른 양이다. 큰 속도가 충분히 작은 영역에 집중되면 최댓값이 증가해도 총에너지는 유계로 남을 수 있다.

이를 실제 증명과 별개의 단순한 예로 생각해 보자. 속도의 크기가 $M$ 정도인 영역의 부피가 $M^{-3}$ 이라면, 그 영역의 에너지 기여는 대략

$$ M^2\times M^{-3}=M^{-1}  $$

이다. $M$이 커질수록 속도는 증가하지만 이 에너지 기여는 오히려 줄어든다.

물론 이 예가 Navier–Stokes 방정식을 만족한다는 뜻은 아니다. 속도 최댓값의 발산과 유한한 에너지가 논리적으로 양립할 수 있다는 점을 보여주는 설명이다.

외력이 있어도 밀레니엄 문제인가?

그렇다. Clay의 공식 문제는 다음 네 가지 대안 중 하나의 증명을 요구한다.

이번 발표의 대상은 C·D다. 따라서 외력이 있다는 이유로 공식 문제와 무관하다고 말할 수 없다. 동시에 외력 없는 경우까지 해결했다고 말해서도 안 된다. 외력을 허용하는 C는 외력 없는 A의 단순한 논리적 부정이 아니다. 공식 문제의 A–D 진술

2. 특이점은 만들되, 외력은 매끄럽게 유지하기

임의의 유동을 정하고 방정식의 나머지를 외력으로 정의하는 것만으로 문제는 풀리지 않는다. 그 외력이 함께 발산하면 조건을 위반하기 때문이다.

논문은 수축하는 소용돌이의 배경 유동을 구성하고, 진동성 펄스의 평균 운동량 흐름으로 특이한 잔차를 상쇄한다. 고차 보정과 국소화를 통해 외력이 특이점 시각을 지나서도 매끄럽게 이어지도록 한다. 이는 논문의 증명 개요를 요약한 설명이다. 논문 §2–3

이 지점에서 탐색과 증명의 차이가 드러난다. 흥미로운 속도장을 제안하는 것으로 작업이 끝나지 않는다. 그 구성이 방정식, 초기조건, 외력의 매끄러움, 에너지 조건을 모두 만족함을 보여야 한다.

AI 시스템에도 같은 구분이 필요하다. 후보를 찾는 과정과 후보에 남아 있는 증명 의무를 해결하는 과정은 서로 다른 작업이다.

3. 여러 agent의 탐색은 어떻게 하나의 연구로 이어졌나?

하네스는 모델에 작업과 도구를 제공하고, 중간 결과와 실행 상태를 관리하며, 다음 작업과 검사를 연결하는 실행 체계다.

모델이 개별 추론을 수행한다면, 하네스는 그 추론을 지속적인 작업으로 연결한다. 여기에는 작업 배정, 도구 사용, 결과 전달, 실행 제어, 검사 절차 등이 포함될 수 있다.

공개된 workflow

OpenAI의 설명을 바탕으로 아래 흐름을 재구성했다. 실제 내부 소프트웨어 구조도는 아니다. 마지막 재검증 경로는 공개 저장소가 제공하는 절차이며, 독립 검증 완료를 뜻하지 않는다.

OpenAI의 공개 설명을 바탕으로 재구성한 workflow. 실제 내부 소프트웨어 구조도가 아니다.

3.1 문제 진술을 나눠 탐색한다

그룹별로 A·B와 C·D 등 다른 문제 변형을 배정하고, 다양한 접근을 탐색하도록 했다. 도구로는 캐시된 인터넷 읽기와 코드 실행이 제공됐고, 그룹 내부 통신이 가능했다.

설계 관점에서는 모든 작업이 같은 출발점과 가정에 집중되지 않도록 탐색을 분산한 것으로 읽을 수 있다. 다만 세부 역할표와 통신 구조는 공개되지 않았다.

3.2 연관 문제의 성과를 후속 탐색에 전달한다

별도 탐색에서 외력 없는 Euler 성과가 나오자 인간 연구진은 Navier–Stokes에 자원을 집중하고, 그 결과를 후속 프롬프트에 제공했다. 실행 중 추가 학습된 모델로 업데이트도 했다.

Euler는 점성이 없는 방정식이며 별도의 정리다. 연관 문제의 성과를 다음 탐색의 입력으로 사용하는 연구 전략으로 이해해야 한다.

3.3 그룹의 발견을 통합하고 다시 투입한다

Codex로 그룹별 유용한 발견을 정리해 후속 프롬프트로 전달했다. 성공한 그룹도 이 과정을 거쳤다고 보고한다.

이는 중간 결과를 다음 작업이 이어받을 자산으로 취급하는 방식이다. 실제 저장 형식, 자동화 수준, 선택 기준은 확인되지 않았다.

3.4 후보 증명을 형식화한다

탐색에는 비공개 내부 모델을 사용했다. 이후에는 GPT‑6 Astra로 형식화 작업을 진행했으며, 논리적 검사는 Lean 검증 체계의 역할이다.

이 수치와 운영 과정은 회사의 자체 보고다. OpenAI의 탐색 과정 설명

이 workflow에서 무엇을 배울 수 있을까?

이 흐름을 시스템 설계 관점에서 읽으면 세 가지 작업 단위가 보인다.

첫째는 탐색 단위다. 개별 작업은 특정한 문제 진술이나 접근을 맡고, 후보 논증과 중간 결과를 만든다.

둘째는 통합 단위다. 여러 작업에서 나온 결과를 다음 탐색에 사용할 수 있도록 정리한다. 이때 결론뿐 아니라 그 결론이 의존하는 가정과 아직 해결하지 못한 부분도 중요하다.

셋째는 검증 단위다. 후보가 나왔다는 사실과 요구 조건을 만족하는 결과가 나왔다는 사실을 구분한다.

이 구분은 공개된 운영 과정을 이해하기 위한 분석 틀이다. 실제 내부에 이 이름의 agent나 모듈이 존재했다고 주장하는 것은 아니다.

또한 이번 사례만으로 agent 수, 모델, 인간 개입 각각의 기여도를 분리할 수 없다. 1만 개 agent가 필요했다거나, 같은 구성을 복제하면 다른 난제에서도 성공한다는 결론은 성립하지 않는다.

하네스 전체의 구현도 공개된 것이 아니다. GitHub 저장소는 발견 과정의 재현 코드가 아니라 수학적 결과의 형식화다. 결과의 공개성과 발견 과정의 재현 가능성은 구분해야 한다. 공개 저장소

4. Lean과 Comparator: 답을 만드는 과정과 답을 확인하는 과정

Lean의 커널 검사는 형식화된 증명을 검사한다. 하지만 형식화한 명제가 원래 문제와 다르면 원하는 문제를 풀었다는 결론은 나오지 않는다.

예를 들어 어떤 명제를 증명해야 하는데, 형식화 과정에서 결론을 가정으로 넣거나 필요한 조건을 약하게 바꿨다면 어떨까. 바뀐 명제의 증명이 통과해도 원래 문제에 대한 답은 되지 않는다.

이번 저장소의 Comparator 설정은 기준 문제와 해답 모듈, 최종 정리, 허용 공리를 지정하고 nanoda 검사도 활성화한다. 이는 공개된 검증 설정이지 이 글에서 실행한 결과는 아니다. 실제 설정

Comparator는 신뢰하는 기준 명제와 제출 정리의 일치, 허용 공리, 커널 수용을 확인하도록 설계됐다. 검증 도구와 환경에 관한 전제는 남는다. Comparator 공식 설명

기준 진술은 Google DeepMind의 Formal Conjectures 정의를 수정해 사용했다. 따라서 기준 진술 자체에 대한 검토도 필요하다. 프로젝트의 검증 안내

메타데이터는 주요 결과의 sorry 수가 0이며, propext, Classical.choice, Quot.sound만 사용한다고 보고한다. 검토 상태는 자체 평가다. 공개된 증명 코드와 독립적인 전체 감사 완료는 구분해야 한다. 형식화 메타데이터

이 구조는 agent 시스템 전반에도 적용할 질문을 남긴다. 결과를 평가할 때 모델의 설명이 설득력 있는지만 보는가, 아니면 요구한 조건을 만족하는지 별도의 절차로 확인하는가?

5. 선행 연구와 다른 수학 AI 사례가 보여주는 차이

인간의 연구 맥락 안에서 이해하기

Córdoba와 Martínez-Zoroa는 외력이 있는 유체 방정식의 특이점 구성 연구를 발전시켰다. Alpöge와 Buckmaster는 이 프로그램에서 출발해 LLM의 도움으로 외력이 있는 Euler 등의 결과를 얻었다고 설명한다. 2024년 IPM 논문, Buckmaster의 설명

OpenAI의 외력 없는 Euler 결과는 이와 다른 정리다. 또한 이번 Navier–Stokes 결과에서 각 양의 점성계수마다 구성을 얻는다는 주장만으로, 점성이 0인 Euler 결과가 따라오지는 않는다. OpenAI의 Euler 결과

Tao의 9월 7일 글은 Alpöge–Buckmaster의 선행 아이디어와 확장 가능성을 설명한다. 이후 공개된 OpenAI 논문 전체를 검증한 자료로 인용할 수는 없다. Tao의 해설

연구 우선권과 데이터 처리에 관한 논쟁도 있다. 이는 수학적 정확성과 별개의 사안이며, 당사자들의 공개 설명을 구분해 읽어야 한다. Buckmaster의 입장, OpenAI의 입장

AI의 연구 성과를 설명할 때는 최종 결과와 함께 어떤 선행 아이디어를 이어받았고, 어떤 부분에서 새로운 구성이 필요했는지도 남겨야 한다.

시스템마다 생성하는 대상과 평가기가 다르다

다른 수학 AI와 비교할 때도 “AI가 풀었다”는 표현보다, 무엇을 생성하고 무엇으로 평가하는지를 살펴보는 편이 유용하다.

FunSearch는 프로그램 평가를 활용한 탐색을, Aletheia는 생성기·검증기·수정기를 포함한 구성을 보고했다. 자연어 논증을 검토하는 과정과 형식 증명을 검사하는 과정은 같은 보장을 주지 않는다. FunSearch 논문, Aletheia 논문

이 차이는 평가기가 문제의 성격에 맞아야 한다는 점을 보여준다. 실행해서 점수를 계산할 수 있는 문제와, 긴 논증의 모든 조건을 확인해야 하는 문제는 서로 다른 작업 흐름을 요구한다.

6. 기업의 agent 시스템에 가져올 설계 질문

기업의 작업에는 Lean처럼 강력한 검증기를 붙일 수 없는 경우도 많다. 그래서 어떤 부분을 테스트·실행 결과·데이터 대조로 확인하고, 어디에 사람의 판단을 남길지 정해야 한다.

다음은 이번 사례에서 도출한 설계 제안이다. OpenAI의 실제 내부 구현을 설명하는 목록은 아니다.

작업과 완료 조건을 함께 정의한다

“분석하라”는 지시만으로는 완료 여부를 판정하기 어렵다. 어떤 산출물을 만들고, 어떤 조건을 만족해야 다음 단계로 넘어갈지 함께 정해야 한다.

예를 들어 코드 수정 작업이라면 수정 파일뿐 아니라 재현 조건과 테스트 결과가 필요할 수 있다. 조사 작업이라면 결론뿐 아니라 출처와 미확인 사항이 필요하다.

중간 결과에 근거와 검증 상태를 붙인다

다음 agent가 결론만 이어받으면, 아직 확인되지 않은 가정까지 사실로 취급할 수 있다. 중간 산출물에는 적어도 다음 정보가 필요하다.

이 표는 구현을 위한 제안이다. 저장 형식은 문서, 구조화된 데이터, 작업 추적 시스템 등 환경에 맞게 선택할 수 있다.

생성과 검사를 구분한다

가능하면 생성 모델의 자기평가와 별개인 검사 수단을 둔다. 코드라면 테스트와 실제 실행, 데이터 작업이라면 원본 대조와 일관성 검사, 계산이라면 독립적인 재계산이 그 역할을 할 수 있다.

별도 모델의 검토도 도움이 될 수 있지만, 검토 모델의 동의가 곧 객관적인 검증은 아니다. 각 검사 방식이 보장하는 범위를 알아야 한다.

실패를 기록하고, 비용을 포함해 효과를 측정한다

실패한 접근을 기록하면 같은 시도를 반복하는 비용을 줄이고, 나중에 다른 조건에서 재검토할 근거를 남길 수 있다.

Agent 수와 실행 시간을 늘릴 때도 성공률만 볼 수는 없다. 비용, 지연시간, 재작업 비율까지 함께 측정해야 어떤 구성이 실제로 유용한지 알 수 있다.

사람이 방향을 조정하는 지점을 정한다

사람은 목표를 바꾸고, 유망한 중간 결과를 선택하고, 자원을 재배분할 수 있다. 이 역할을 실행 흐름 안에 명시하면 언제 판단이 필요한지와 그 판단이 후속 작업에 어떻게 반영되는지가 분명해진다.

Navier–Stokes 발표는 강력한 모델과 대규모 탐색, 인간의 연구 판단, 형식 검증이 함께 사용된 사례다. 각 요소가 성공에 기여한 정도는 공개 자료만으로 분리되지 않는다.

그럼에도 agent 시스템을 설계할 때 던져야 할 질문은 구체적이다.

무엇을 생성하는가. 그 결과가 맞는지는 무엇으로 확인하는가. 실패와 중간 성과는 다음 시도에 어떻게 전달하는가.

하네스의 설계는 이 질문들에 실행 가능한 답을 주는 일이다.