올해 저는 프리프린트(preprint) — When a Verified World Model Still Loses를 발표했습니다. 혼자서 약 2주가 걸렸습니다. AI를 사용하기 수년 전, 저는 첫 번째 논문인 수학 학위 논문을 발표했습니다. 정리(theorem), 증명(proof), 그리고 대학교 및 지원금을 받는 프로젝트와 함께한 2년 이상의 작업이 담긴 논문이었습니다.

그 대조적인 상황이 솔직한 시작점입니다. 이를

• 아이디어는 읽기에서 비롯되었습니다. "논문을 써줘"라는 프롬프트에서 나온 것이 아니라, 구체적으로 DeepMind의 _Code World Models for General Game Playing_를 AI의 도움을 받아 읽는 과정에서 나왔습니다. "왜 이 단계가 다음에 오는가?"라는 질문에 즉각 답할 수 있는 모델과 함께 밀도 높은 논문을 파헤치는 것은 혼자 읽는 것과는 전혀 다른 활동입니다. 바로 그 지점에서 제 프리프린트 (preprint)가 된 질문이 처음 형체를 갖추었습니다.
• 에이전트(Agents)에 의해 실행된 실험. 합성 파이프라인 (synthesis pipelines), 스윕 (sweeps), 아레나 (arenas) — 제가 조종하며 에이전트들이 설정하고 실행했습니다.
• 모든 강력한 주장(strong claim)에 대해 제가 고수했던 원칙: '증명 가능한 것(demonstrable)'과 '측정된 것(measured)'을 분리하고, 각각 무엇인지 밝히는 것. 식별 가능성 정리 (identifiability theorem)나 커버리지 경계 (coverage bound)처럼 문장으로 '이겨낼 수 있는(won)' 부분에서는 직접 가서 증명했습니다. 오직 측정될 수 있는 부분에 대해서는 구간 (intervals)과 함께 측정된 것으로 보고하고 그 단계에서 멈췄습니다.

그러니 네, AI가 논문을 썼습니다. 하지만 글쓰기는 결코 병목 현상 (bottleneck)이 아니었습니다. 이는 기술자들이 빠르고, 지치지 않으며, 때로는 흥미로운 방식으로 틀리기도 하는 작은 실험실을 운영하는 것에 더 가깝습니다. 그리고 제가 더하는 가치는 타이핑이 아닙니다.

모델의 지능이 나타나는 지점

제가 가진 가장 날카로운 사례는 아직 출판되지 않은 두 번째 논문 — 연속 제어 (continuous-control) 설정 — 에서 나오므로, 다음에 이어지는 내용은 결과가 아닌 과정에 대한 기록입니다.

작업을 진행함에 따라 제가 사용하는 모델들이 변했으며, 그 순서는 중요합니다. 저는 계획 수립 (planning)을 위해 Opus 4.8을, 보조 독자로는 GPT-5.5를 사용하여 시작했습니다. 효과는 있었지만, 저의 수많은 질문과 수정 과정을 거쳐야 했습니다. Fable 5가 출시되자마자 저는 모델을 교체했고, 그것은 빠르게 저의 기본 모델이 되었습니다. 일상적인 계획 수립이 더 유연해졌고, 수정 횟수도 줄었으며, 단순히 제 명령을 실행하는 대신 진정으로 유용한 방향을 자발적으로 제시했습니다. 제가 여전히 마주하는 유일한 벽은 Fable의 구독 제한입니다. 그러다 GPT-5.6이 등장했고, 훨씬 더 나은 두 번째 검토자 (reviewer)가 되었습니다. Fable의 사용량을 다 썼을 때 정확히 저를 구해주는 모델인데, 실제로 저는 이 둘을 서로 교체하며 사용할 수 있기 때문입니다. 이 모델의 리뷰는 실제 동료 검토 (peer review)처럼 읽힙니다.

GPT-5.6의 리뷰 단계 중 하나는 "계획 과학 (planning science)"이 하나의 능력으로서 무엇을 의미하는지를 보여주는 제가 가진 가장 명확한 단일 사례입니다. 여기서 두 가지 주목할 점이 발견되었습니다.

모델이 다른 모델의 실수를 수정하는 과정

계획을 세우는 동안, 저는 Opus 4.8 에이전트에게 나중에 잊어버리지 않도록 향후 방향성 — 고차원에서의 위상수학 (topology) 활용 확대 — 을 메모해 두라고 요청했습니다. 그런데 에이전트가 메모를 엉망으로 작성했습니다. 특정 2D 도형(링 — 구멍이 있는 영역)이 고차원 상태로 이동해야 한다고 적은 것입니다. 이는 틀린 내용입니다. 링은 평면에서도 완벽하게 존재하며 이미 비자명한 위상 (non-trivial topology)을 가지고 있습니다. 저는 제 분야이기에 이를 알고 있습니다. 하지만 그것을 작성한 것은 제가 아니라 모델이었으며, 제가 요청한 내용을 잘못 읽는 과정에서 오류를 범했습니다.

이 오류를 잡아낸 것은 다른 모델이었습니다. GPT-5.6이 계획을 검토했을 때, 가장 먼저 지적한 것이 바로 이것이었습니다:

링은 2D에서도 완벽하게 존재하며 비자명한 호몰로지 (non-trivial homology)를 가집니다. 상태의 차원을 높일 필요가 없습니다.

약한 모델은 제 의도를 오해하여 개념적 오류를 범했지만, 더 강력한 모델은 읽는 과정에서 이를 잡아냈습니다. 이것이 작고 명확하게 읽히는 사례입니다. 다음 사례가 더 중요합니다.

스스로 질문에 답할 수 없었던 실험

이 실험의 핵심 목적은 하나의 변수 — 경계의 곡률 (curvature) — 를 격리하고, 모델이 샘플링된 데이터로부터 이를 얼마나 잘 재구성할 수 있는지 측정하는 것이었습니다. 계획안은 특정 수치(무작위 데이터가 해당 영역에 닿는 빈도)를 고정함으로써,

— 그리고 그 계획이 첫 번째 요인만을 제어하고 있다는 점을 지적했습니다. 쉽게 말해, 설계된 대로라면 해당 실험은 스스로의 질문에 답할 수 없었다는 뜻입니다. 이것은 문장 교정이 아닙니다. 이것은 계획 과학 (planning science)이며, 모델 품질의 도약이 실제로 당신에게 가져다주는 능력입니다.

심지어 모델은 제가 계획하지 않았던 실험 하나를 제안하기도 했습니다. 바로 "데이터에 충분한 정보가 없는 것"과 "모델이 이를 표현할 수 없는 것"을 명확하게 분리하는 오라클 베이스라인 (oracle baseline) 이었습니다. 세 번째 논문은 이미 제 로드맵에 있었습니다. 이 모든 일이 일어나기 전에 기록해 둔 저의 아이디어였으며, 저는 모델에게 현재 계획에 억지로 끼워 넣기보다는 그 방향에 부합하는 피드백이 있다면 그곳에 남겨달라고 요청했습니다. 모델은 실제로 그렇게 했고, 실제 인용 (citations)을 곁들여 수행했습니다. 눈앞의 과업을 탈선시키는 대신 자신의 좋은 아이디어를 당신의 향후 연구에 배치하는 리뷰어라면, 제대로 된 역할을 수행하고 있는 것입니다.

Git에서 그 전후 차이를 확인할 수 있습니다. 수정 커밋 메시지는 토씨 하나 틀리지 않고 다음과 같습니다: "전문가 리뷰에 따른 repair-vs-geometry 재설계 — 인수분해 (factorization), 그래프 경계 (graph boundaries), 대칭 메트릭 (symmetric metrics), 오라클 베이스라인 (oracle baseline), 위상 수정 (topology fix)." 문서의 거의 절반이 다시 작성되었습니다.

항상 더 똑똑한 모델 때문만은 아닙니다 — 때로는 두 번째 눈이 필요할 뿐입니다

모든 이득이 순수한 능력 (raw capability)에서 오는 것은 아닙니다. 때로는 그 가치가 단순히 두 번째의, 다른 관점의 눈 — 즉 다른 모델이나 저 자신 — 이 첫 번째 시도에서 놓친 것을 잡아내는 데서 오기도 합니다. 첫 번째 논문으로 돌아가 보면, Git 히스토리의 커밋 메시지 자체에 이러한 과정이 가득 기록되어 있습니다:

• 파이프라인 출력값을 전달하던 Claude 에이전트가 실패 데이터가 잘린 것 같다고 불평했습니다. 그 말이 맞았습니다. 로깅 (logging) 단계에서 모델이 확인해야 할 바로 그 숫자들을 잘라내고 있었습니다. 그 단 하나의 불평이 혼란 변수 (confound)를 찾아냈고, 이를 수정하자 불안정했던 발견이 이후 두 개의 다른 모델 제품군 (model families)에서도 재현 가능한 결과로 바뀌었습니다.
• Codex의 검토를 통해 이전 편집 과정에서 살아남았던 과장된 주장 하나를 잡아냈습니다. 바로 파이프라인이 "동일한 플레이 비용을 재현한다"는 문장이었는데, 바로 뒤에 나오는 신뢰 구간 (confidence intervals)은 그와 상반된 내용을 나타내고 있었습니다.
• 그리고 모두가 걱정하는 환각 인용 (hallucinated-citation) 문제와는 정반대의 사례도 있었습니다. 모델이 가지고 있지 않은 참고 문헌을 요청받았을 때, URL을 허위로 만들어내는 대신 "저자가 제공할 URL (URL to be supplied by the author)"_라고 남겨두며 거절한 것입니다.

이러한 포착 중 상당수는 저 자신의 몫이기도 했습니다. 핵심은 모델이 검토자 (reviewer)를 대체한다는 것이 아니라, 주장이 출판되기 전까지 통과해야 하는 독립적인 검토 횟수를 배가시킨다는 점입니다. 저는 이러한 상호 보완성 — 즉, 두 AI 도구가 어떻게 생산적으로 의견 차이를 보이는지 — 에 대해 Writing an Essay with AI: Codex vs Claude Code에서 더 자세히 다루었습니다.

솔직한 부분: AI 때문만은 아니었습니다

다시 그 '2년 대 2주'의 대비로 돌아가 보겠습니다. AI 외에도 그 격차를 설명할 수 있는 몇 가지 요소가 있으며, 이 모든 것을 AI의 배가 효과로만 돌리는 것은 정직하지 못한 일일 것입니다.

• 순수 수학 vs 경험적 머신러닝 (empirical ML). 정리를 증명하는 것은 경험적 머신러닝 (empirical ML) 프리프린트 (preprint)를 작성하는 것보다 본질적으로 더 느리고 어렵습니다. 이들은 서로 다른 종류의 작업입니다.
• 추상화와 몰입. 순수 수학의 대상은 더 추상적입니다. 그 대상에 깊이 몰입하는 데는 단순히 더 많은 시간이 걸립니다. 그리고 당시의 저에게는 그 몰입을 가속화할 AI가 없었으며, 이 또한 오늘날 프로세스가 배가되는 지점 중 하나입니다.
• 길이. 제 수학 논문은 대략 두 배 정도 더 깁니다.
• 제도적 오버헤드 (Institutional overhead). 자금이 지원되는 대학 프로젝트는 개인의 프리프린트 (preprint)에는 없는 프로세스 — 회의, 조정, 수정 주기 — 를 수반합니다.

그 모든 요소를 고려하여 정규화(Normalize)하더라도 그 격차는 여전히 실재하지만, 그것은 능력을 대체하는 것이 아니라 이미 그 일을 수행할 수 있었던 사람에게 적용되는 승수(multiplier)입니다. 순수 수학에서 응용 머신러닝 (Applied ML)으로 향하는 그 축은 제 커리어의 이동 경로이기도 하며, 이 프로젝트는 바로 그 지점에 위치합니다.

내가 실제로 얻은 교훈

• AI는 어려운 부분을 제거한 것이 아니라, 그 어려운 부분이 존재하는 위치를 옮겼습니다. 저에게 있어 그것은 "내가 이것을 쓰고 실행할 수 있는가"의 문제에서 "이것이 올바른 실험인가, 그리고 이 주장이 검토(scrutiny)를 견뎌낼 수 있는가"의 문제로 변했습니다.
• 그 어려운 부분에 있어서, 모델의 역량 (capability)이 결합 제약 (binding constraint)입니다. 과학을 계획할 수 있는 모델 — 즉, 스스로의 질문에 답하는 실험을 설계하고, 동료 검토 (peer review)처럼 주장을 검토할 수 있는 모델 — 과 그렇지 못한 모델 사이의 격차는, 정체되는 논문과 더 멀리 나아가는 논문 사이의 격차입니다. 이것이 제가 Fable 5를 기본으로 사용하고 GPT-5.6을 제가 선택한 검토자로 삼는 이유입니다.
• 역량이 유일한 지렛대는 아닙니다. 다른 모델이나 저와 같은 두 번째의, 서로 다른 시각은 첫 번째 단계에서 놓친 것을 포착합니다. 다양성 그 자체가 하나의 지능입니다.
• 자동화되지 않는 것은 연구자의 판단력입니다. 연구자였다는 경험이 여기서 무게감을 갖는 부분입니다. 즉, 엄격함 (rigor), 면밀한 검토 (scrutiny), 깔끔한 결과조차 불신하는 반사 신경, 주장이 유지되거나 무너질 때까지 검토하는 습관, 그리고 어떤 것이 단순히 "측정 (measured)"되는 것인지 아니면 "증명 (proven)"되는 것인지 아는 능력 말입니다. 이는 연구 기관이 제공하는 기능 — 동료 검토, 비판적인 지도 교수, 당신과 논쟁하는 실험실 — 과 동일하지만, 더 적은 중개자와 행정 절차를 거치며 모든 유용한 단계에서 더 민첩하게 실행됩니다.

첫 번째 논문인 "When a Verified World Model Still Loses"는 arXiv에서 확인할 수 있으며, 저의 이전 수학 프리프린트 (preprint)는 여기에 있습니다. 검증 가능한 것과 검증할 수 없는 것을 분리하는 방법에 대해서는 다음을 참고하세요: Results-Oriented Programming 및 How Much Should You Still Know?.

AI 에이전트 (AI agent) 아키텍처에 관심이 있으신가요? 연락해 주세요.

원문은 javieraguilar.ai에 게시되었습니다.

더 많은 AI 에이전트 프로젝트를 보고 싶으신가요? 멀티 에이전트 시스템 (multi-agent systems), MCP 개발, 그리고 컴플라이언스 자동화 (compliance automation)를 소개하는 저의 포트폴리오를 확인해 보세요.