Karpathy의 autoresearch — AI 에이전트가 자고 있는 동안 100번 실험하는 자율 연구 시스템
Karpathy의 autoresearch — AI 에이전트가 자고 있는 동안 100번 실험하는 자율 연구 시스템
Karpathy의 autoresearch는 AI 자율 연구 시스템의 새로운 기준을 제시합니다. 단 3개의 파일과 5분이라는 고정 budget으로 인간이 자는 동안 밤새 100번의 실험을 돌리는 이 레포가 2026년 3월 공개 이후 79,838개의 stars를 모은 이유를 분석합니다.
TL;DR
- autoresearch는 AI 에이전트가 자율적으로 LLM 훈련 실험을 반복하는 시스템으로, Andrej Karpathy가 2026년 3월 공개했습니다.
- 핵심 구조는 단 3개 파일(train.py / prepare.py / program.md)이며, 에이전트는 5분 wall-clock budget 안에서 실험하고 결과를 평가합니다.
- program.md의 "NEVER STOP" 철학은 인간의 awakeness를 병목에서 제거하는 자동화의 본질을 보여주며, 1인 기업 자동화에도 그대로 적용됩니다.
AI가 AI를 연구하는 시대의 시작
Karpathy는 README를 이렇게 시작합니다.
"한때 frontier AI 연구는 고기 컴퓨터(meat computers)들이 자고 먹고 노는 사이에 하던 일이었다. 그 시대는 이미 갔다. 이제 연구는 하늘 위 컴퓨팅 메가구조에서 작동하는 AI 에이전트 swarm의 영역이다... 에이전트들은 우리가 지금 코드의 10,205세대에 있다고 주장한다. 누구도 그게 맞는지 틀린지 모른다. '코드'는 이미 인간 이해를 넘어선 자기-수정 바이너리가 됐기 때문이다. 이 레포는 모든 것이 시작된 이야기다. —@karpathy, March 2026"
SF처럼 읽히지만 이건 픽션이 아닙니다. 이 도입부는 현재 AI 연구의 실제 방향을 압축한 메타포입니다. "meat computers", 즉 인간 연구자가 수면과 식사로 실험을 중단하는 동안, AI 에이전트는 멈추지 않습니다. autoresearch는 바로 그 간격을 메우는 시스템입니다.
nanoGPT와 llm.c로 AI 교육 콘텐츠의 기준을 세우고 Neural Networks Zero to Hero 시리즈로 수백만 명을 가르친 Karpathy가 이번엔 "AI가 AI를 연구하는 시스템"을 오픈소스로 공개했습니다. 공개 후 2개월도 안 되어 79,838 stars, 11,631 forks를 기록한 것은 이 아이디어가 얼마나 많은 연구자와 실무자의 공감을 얻었는지를 보여줍니다.
autoresearch의 본질: 3개 파일과 1개 메트릭
autoresearch의 구조는 의도적으로 단순합니다. 에이전트가 다루는 파일은 단 3개입니다.
train.py — 에이전트가 유일하게 수정하는 파일 (26KB)
GPT 모델 정의, Muon + AdamW 옵티마이저, 훈련 루프 전체가 담긴 파일입니다. 에이전트는 이 파일 안에서 아키텍처, 하이퍼파라미터, 옵티마이저, 배치 크기, 모델 크기 등 모든 것을 자유롭게 변경합니다. 단 하나의 파일만 건드리게 제한한 이유는 명확합니다. diff가 reviewable한 scope 안에 있어야 하기 때문입니다. 변경이 어디서 왔는지 추적할 수 없으면 실험이 아니라 혼돈입니다.
prepare.py — 변경 금지 파일 (15KB)
데이터 준비, BPE 토크나이저 훈련, 데이터로더, 그리고 핵심인 evaluate_bpb 함수가 들어 있습니다. 이 파일은 read-only입니다. 에이전트도, 인간도 건드리지 않습니다. 왜냐하면 이 파일이 "ground truth"이기 때문입니다. 평가 기준 자체가 실험에 따라 바뀌면 비교가 불가능해집니다. val_bpb(validation bits per byte)라는 단일 메트릭이 모든 실험의 공정한 기준입니다. vocab 크기에 독립적이라 아키텍처를 완전히 바꿔도 동일한 기준으로 비교할 수 있습니다.
program.md — 연구 조직을 자연어로 프로그래밍하는 파일 (7KB)
이 파일에 대해서는 다음 섹션에서 깊이 다룹니다.
autoresearch의 작동 루프: git state 확인 → train.py 수정 → git commit → uv run train.py 실행(5분) → val_bpb 추출 → results.tsv 기록 → 개선이면 advance, 아니면 git reset. 이 사이클이 밤새 반복됩니다. 약 12 실험/시간, 약 100 실험/밤(8시간 수면 기준).
program.md — 진짜 혁명은 여기에 있다
Karpathy는 program.md를 두 가지로 표현합니다.
첫째, "super lightweight skill." 둘째, "research org code."
"연구 조직의 코드"라는 표현이 핵심입니다. 보통 "코드"라고 하면 Python이나 CUDA를 떠올립니다. 그런데 Karpathy는 7KB짜리 마크다운 파일을 "코드"라고 부릅니다. 연구 조직이 어떻게 실험하고, 어떤 기준으로 판단하고, 언제 멈추지 않는지를 자연어로 명문화한 것이 곧 코드라는 의미입니다.
비유하자면, 연구소의 운영 매뉴얼이 그 연구소의 실질적인 '운영 코드'인 것과 같습니다. 어떤 실험을 언제 폐기할지, 어떤 기준으로 개선을 판단할지, 에이전트가 막혔을 때 어떻게 돌파할지가 모두 여기에 담깁니다.
이 패턴은 낯설지 않습니다. Claude Code의 SKILL.md, Claude.md, agents/ 폴더의 에이전트 정의 파일들이 정확히 같은 역할을 합니다. AI 시대 자동화의 본질은 파이썬 코드가 아니라 "역할, 제약, 판단 기준의 자연어 명문화"입니다.
5분 budget의 의미: 비교 가능성의 비밀
왜 하필 5분일까요? 단순히 빠르게 돌리기 위해서가 아닙니다.
5분 wall-clock budget의 핵심은 공정성입니다. 모델을 두 배로 키워도, 배치 크기를 절반으로 줄여도, 아키텍처를 완전히 바꿔도 — 모두 5분 안에 돌아야 합니다. Karpathy의 표현을 빌리면, "autoresearch will find the most optimal model for your platform in that time budget." 즉, 5분이라는 동일한 자원 내에서 가장 좋은 성능을 내는 방향으로 에이전트가 최적화합니다.
이 원칙은 1인 기업 자동화 도입에도 그대로 적용됩니다. 자동화 도구 A와 B를 비교할 때 같은 단위로 측정해야 의사결정이 가능합니다. "이 도구가 좋다"가 아니라 "동일한 1시간 투자 대비 어느 쪽이 더 많은 가치를 만드는가"가 진짜 질문입니다.
results.tsv가 5컬럼으로 정확히 기록하는 이유도 같습니다: commit | val_bpb | memory_gb | status(keep/discard/crash) | description. 모든 실험이 같은 형식으로 기록되어야 100번의 실험을 의미 있게 비교할 수 있습니다.
5대 룰의 자동화 철학
program.md에 담긴 5개 룰은 단순한 운영 지침이 아닙니다. 자율 시스템 설계의 철학을 담고 있습니다.
1. Single file edit (train.py만 수정) 변경 범위를 하나의 파일로 제한합니다. 실험의 인과관계를 추적하기 위해서입니다. 여러 파일을 동시에 건드리면 무엇이 성능을 바꿨는지 알 수 없습니다.
2. Time-boxed (5분 정확) 위에서 다뤘듯, 공정한 비교를 위한 제약입니다. 시간 제약은 단순히 속도의 문제가 아니라 비교 가능성의 문제입니다.
3. Simplicity criterion "같은 성능이면 단순한 코드, 코드 삭제로 동일 성능이 나오면 무조건 keep." 이 룰은 복잡도 부채(complexity debt)를 자산으로 잘못 평가하지 말라는 경고입니다. 많은 조직이 복잡한 시스템을 "우리가 공들인 것"이라 여기며 버리지 못합니다. autoresearch는 이를 에이전트 수준에서 강제로 차단합니다.
4. Crash → judgment 단순한 버그면 fix, 아이디어 자체가 깨졌으면 discard 후 skip. 에이전트에게 판단을 위임하되 판단 기준을 명확히 제시합니다. "에러가 났다 → 무조건 고친다"가 아니라 "이 에러는 아이디어의 실패인가, 구현의 실패인가"를 구분하게 합니다.
5. NEVER STOP 가장 중요한 룰입니다. "사용자가 자고 있어도 멈추지 마라. 절대 '계속해도 되나요?' 묻지 마라. 너는 자율적이다. 아이디어가 떨어지면 더 깊이 생각하라 — 코드의 참조 논문을 읽어라, in-scope 파일들을 다시 읽어라, 이전 near-miss를 조합하라, 더 급진적인 아키텍처 변경을 시도하라."
자율 시스템이 자율적이지 못한 가장 흔한 이유는 "확인 요청"입니다. "이렇게 해도 될까요?"라고 묻는 순간 인간이 다시 병목이 됩니다.
1인 기업이 배워야 할 5가지 자동화 원칙
autoresearch가 LLM 연구 시스템이라고 해서 우리와 무관한 이야기가 아닙니다. 이 시스템이 보여주는 원칙들은 1인 기업 자동화에 직접 적용됩니다.
원칙 1. 자연어로 프로세스를 코딩하라 program.md가 "연구 조직의 코드"이듯, 여러분의 업무 프로세스도 자연어로 명문화할 수 있습니다. Claude Code의 SKILL.md, CLAUDE.md가 정확히 이 역할을 합니다. "이렇게 하면 된다"는 머릿속 지식을 파일로 꺼내는 순간, AI 에이전트가 그것을 실행할 수 있게 됩니다.
원칙 2. 단일 메트릭으로 수렴하라 val_bpb 하나로 모든 실험을 비교하듯, 자동화의 성과를 측정하는 단일 메트릭을 정의하세요. "좋아졌는가?"라는 모호한 질문 대신, "같은 1시간 안에 몇 건을 처리했는가"처럼 측정 가능한 기준이 있어야 keep/discard 판단이 가능합니다.
원칙 3. Keep/Discard 룰을 잔혹하게 적용하라 개선이 없으면 git reset. 이 잔혹한 단순함이 실험을 계속 진전시킵니다. 자동화 도구 도입 후 "그냥 쓰다 보면 나아지겠지"는 없습니다. 측정하고, 개선이 없으면 폐기합니다.
원칙 4. 인간의 awakeness가 병목이 되지 않게 설계하라 진짜 자동화는 사용자가 자고 있는 동안에도 가치를 만드는 시스템입니다. "이렇게 해도 될까요?"라는 확인 요청이 필요 없도록 판단 기준을 미리 명문화해야 합니다.
원칙 5. 단순한 스택이 항상 이긴다 Simplicity criterion은 연구 코드에만 적용되는 게 아닙니다. 자동화 스택도 마찬가지입니다. 기능이 줄어도 단순해지는 방향이 장기적으로 유지 비용이 낮고 실패 지점이 적습니다.
마무리: 자동화의 본질은 코드가 아니다
autoresearch가 79,838 stars를 받은 이유는 H100 GPU나 PyTorch 코드 때문이 아닙니다. 7KB짜리 program.md가 보여주는 패러다임 때문입니다.
연구 조직을 어떻게 운영할지, 어떤 기준으로 실험을 판단할지, 언제 멈추지 않을지를 자연어로 명문화하면 AI 에이전트가 그것을 실행합니다. "연구 조직의 코드"는 Python이 아니라 자연어입니다.
이 원칙은 AI 연구실이 아닌 1인 기업에도 동일하게 적용됩니다. 여러분의 업무 중 반복적으로 판단이 필요한 것들 — 콘텐츠 생성, 고객 응대, 데이터 정리 — 을 program.md처럼 명문화해보세요. 판단 기준이 명확해지면 자동화가 가능해지고, 자동화가 가능해지면 인간의 awakeness가 병목에서 빠집니다.
Karpathy의 에이전트가 밤새 100번 실험하는 동안, 우리의 자동화 시스템도 조용히 가치를 만들어야 합니다.
관련 글: 자율 에이전트 시스템 구축에 관심 있으시다면 실제 운영 중인 콘텐츠 자동화 파이프라인 사례를 확인해보세요.
자주 묻는 질문 (FAQ)
Q: autoresearch를 H100 없이도 사용할 수 있나요?
네, 가능합니다. Karpathy가 H100을 레퍼런스 환경으로 사용하지만, 커뮤니티에서 macOS(miolini/autoresearch-macos), macOS MLX(trevin-creator/autoresearch-mlx), Windows RTX(jsegov/autoresearch-win-rtx), AMD ROCm(andyluo7/autoresearch) 환경으로 포팅한 fork들이 이미 존재합니다. 하드웨어에 맞는 fork를 선택하면 됩니다.
Q: program.md는 누가 작성하나요?
인간이 작성합니다. 에이전트가 실험하는 방법(train.py)과 평가 기준(prepare.py)은 시스템이 관리하지만, "어떤 전략으로 실험할지, 어떤 판단 기준을 따를지"를 담은 program.md는 연구자가 작성하는 자연어 명세입니다. 이것이 "research org code"의 의미입니다.
Q: val_bpb가 유일한 평가 메트릭인 이유는 무엇인가요?
val_bpb(validation bits per byte)는 vocab 크기에 독립적이기 때문입니다. 아키텍처를 완전히 바꿔 vocab 크기가 달라져도 동일한 기준으로 비교할 수 있습니다. 단일 메트릭으로 수렴해야 100번의 실험이 의미 있게 누적되고, 에이전트가 방향을 잃지 않습니다.
Q: "5분 budget"이 너무 짧지 않나요?
5분은 단순히 빠른 실험을 위한 제약이 아닙니다. 모든 실험을 동일한 자원(5분) 안에서 평가함으로써 공정한 비교를 가능하게 합니다. 더 큰 모델도, 더 복잡한 아키텍처도 같은 5분 안에 최선을 다해야 합니다. 이것이 플랫폼에 최적화된 모델을 찾는 방법입니다.
