Jerry Tworek: AI lab 자동화와 eval의 끝 (AGI House)

Jerry Tworek는 이제 단일 benchmark 점수만으로 frontier model을 판단하는 시대가 거의 끝났다고 봄
이유는 단순함. 새 eval을 만들면 처음에는 50% 근처에서 시작해도, 몇 번의 모델 세대 뒤에는 90%까지 빨리 올라가고, 곧 모델 학습 목표의 일부처럼 되어버림
그래서 진짜 평가는 “어제보다 오늘 실제 일을 더 잘 자동화했는가”에 가까워짐. trading에서 backtest만 믿지 않고 live test를 보는 것과 비슷함
o1, o3 같은 reasoning model의 어려움도 알고리즘 하나보다 tool 호출, VM, 동기화, 데이터 이동 같은 시스템 문제에 더 가까웠다고 설명함
OpenAI에서 Codex, o1, o3, GPT-5 reasoning 쪽을 이끌었던 Jerry Tworek가 AGI House에서 Core Automation의 AI lab 자동화 구상을 설명한 대담

왜 code가 reasoning model의 첫 실험장이었나?

Jerry가 OpenAI에서 code model에 집중한 이유는 code가 “맞았는지”를 비교적 분명히 볼 수 있기 때문
GPT-2나 GPT-3 시절의 일반 텍스트는 좋은 답인지 아닌지 애매한 경우가 많았음. 반면 code는 실행해보고 test가 통과하는지 볼 수 있음
이 구조가 model에게 긴 문제를 풀게 하고, 여러 시도를 하게 하고, 결과를 자동으로 채점하는 길을 열어줌
Codex와 GitHub Copilot 경험은 나중에 reasoning model로 이어짐. 모델이 답을 바로 쓰는 게 아니라, 문제를 쪼개고, tool을 쓰고, 결과를 확인하는 흐름이 중요해졌기 때문
Jerry는 이 과정에서 “모델을 더 크게 만드는 일”과 “모델 주변의 harness를 더 잘 만드는 일”이 같이 굴러가야 한다고 봄

eval의 시대가 끝났다는 말은 무슨 뜻인가?

여기서 말하는 “끝”은 평가가 필요 없다는 뜻이 아님. static benchmark 하나를 신뢰의 중심에 놓기 어렵다는 뜻
좋은 eval은 한동안 유용함. 하지만 모델 회사들이 그 benchmark를 의식하기 시작하면, 점수는 빠르게 오르고 실제 제품 품질과의 거리는 벌어질 수 있음
Jerry가 trading을 예로 드는 이유도 이 때문. 과거 데이터에서 좋아 보이는 전략은 많지만, 진짜 검증은 미래 데이터와 실제 시장에서 해야 함
AI도 비슷함. 과거 task로 만든 benchmark, 미래에 새로 들어오는 업무, 실제 사용자 배포를 나눠서 봐야 함
synthetic task는 많이 만들고 반복 실험하기 좋음. 하지만 verifier가 허술하면 모델은 실제 일을 배운 게 아니라 점수 따는 요령만 배울 수 있음
real data와 live deployment는 느리고 다루기 어렵지만 최종 기준에 가까움. 사용자가 실제로 일을 끝냈는지, 사람이 고치는 시간이 줄었는지, 실패가 다시 줄어드는지를 봐야 함

구분	무엇을 보나	한계
synthetic task	대량 반복 실험과 verifier 점검	실제 업무와 멀어지거나 reward hacking이 생길 수 있음
static benchmark	정해진 문제의 점수	금방 포화되고 학습 목표가 되기 쉬움
fresh data	과거 학습 뒤 새로 들어온 문제	데이터 누수를 막기 어려움
제품 로그	실제 사용자가 끝낸 일	통제된 비교가 어려움
live eval	새 업무에서의 성공률과 수정 비용	만들고 유지하는 비용이 큼
lab automation loop	연구와 제품 개선 자체의 속도	조직의 workflow까지 바꿔야 함

o1에서 o3로 갈 때 무엇이 어려웠나?

o1은 Jerry 표현에 가깝게 말하면 퍼즐을 잘 푸는 기술 데모에 가까웠고, o3는 실제 사용 가능한 tool로 만드는 단계였음
큰 차이는 reasoning loop 안에 tool call이 들어간다는 점. 모델이 생각만 하는 게 아니라 code 실행, 파일 접근, 웹 조작, 검증을 섞어야 함
Jerry는 이런 tool use scaling을 “99% systems, 1% algorithm”에 가깝게 설명함
수많은 agent가 VM 위에서 돌고, 중간 결과를 저장하고, 동기화하고, 실패를 복구해야 함. 단순 웹 서비스보다 더 험한 분산 시스템 문제가 됨
test-time compute도 무한히 좋은 건 아님. serial reasoning은 강하지만 latency가 길어지고, parallel subagent는 빠를 수 있지만 token 비용과 품질 문제가 생김

Core Automation은 왜 continual learning에 베팅하나?

Jerry가 만든 Core Automation의 출발점은 AI lab 자체를 자동화하는 것
기존 eval은 제품 밖에 따로 있는 시험지에 가까움. Core Automation이 보는 방향은 “lab이 곧 eval”이 되는 구조임
예를 들어 연구 아이디어를 만들고, 실험을 돌리고, 실패 trace를 보고, 다음 실험을 고치는 과정을 agent가 계속 수행하게 만드는 식
이 관점에서는 모델이 한 번 정답을 맞히는지보다, 매일 반복되는 연구와 운영 process가 얼마나 빨리 좋아지는지가 더 중요해짐
그래서 synthetic data는 연습장을 만드는 데 필요하지만, loop의 최종 기준은 real data와 live feedback이어야 함. 실제 업무 로그가 다시 task, verifier, RL environment 개선으로 돌아와야 학습 루프가 생김
Jerry는 markdown memory나 긴 context window만으로는 learning이 생기지 않는다고 봄. 모델이 실제 배포 환경에서 계속 배우도록 학습 방식 자체가 바뀌어야 한다는 주장
많은 회사는 “우리 데이터로 fine-tuning한 모델”을 원하지만, Jerry는 사람들이 진짜 원하는 건 한 번의 fine-tuning보다 계속 배우는 모델에 가깝다고 봄
회사마다 업무, 고객, 문서, 규칙, 실패 패턴이 다르기 때문. 범용 모델이 처음부터 그 조직의 세부 맥락을 모두 알기는 어려움
test-time training이나 continual learning이 가능해지면, 각 회사는 자기 환경 안에서 계속 적응하는 모델을 갖게 될 수 있음
중요한 점은 데이터 통제임. 기업은 민감한 데이터를 외부로 보내지 않고도, 자기 배포 환경 안에서 모델이 배우기를 원함
이 구조가 자리 잡으면 “모두가 같은 frontier model을 API로 빌려 쓰는 시장”에서 “각 enterprise가 자기 model, benchmark, eval, RL environment를 갖는 시장”으로 이동할 가능성이 있음

AI eval은 이제 쓸모없나요?

쓸모없다는 뜻은 아님. 다만 하나의 공개 benchmark 점수만 보고 모델 선택을 끝내기 어렵다는 뜻임. 실제 제품에서는 latency, 실패 복구, tool 사용, 사람의 수정 시간까지 같이 봐야 함.

test-time training은 fine-tuning과 무엇이 다른가요?

fine-tuning은 보통 특정 시점의 데이터로 모델을 한 번 더 학습시키는 방식에 가까움. test-time training이나 continual learning은 배포된 환경에서 새 경험을 계속 반영하는 쪽에 가까움. Jerry는 enterprise가 원하는 것도 결국 이 지속 학습에 더 가깝다고 봄.

Core Automation은 어떤 회사를 만들려 하나요?

AI 연구소의 반복 업무를 agent가 직접 수행하게 만드는 회사에 가까움. 단순히 연구자를 돕는 copilot이 아니라, 실험 설계, 실행, 평가, 다음 개선까지 이어지는 lab automation loop를 만들려는 방향임.

1인기업 관점

이 얘기는 1인기업에게도 꽤 직접적인 듯함. OpenAI식 거대한 eval을 따라 만들기보다, 내 제품에서 실제로 반복되는 업무가 어제보다 오늘 더 잘 자동화되는지를 보는 작은 live eval을 만들어야 할 것 같음.

Jerry Tworek: AI lab 자동화와 eval의 끝 (AGI House) (youtube.com) ↗