솔직히 처음 이 저장소를 봤을 때 “이게 된다고?” 했습니다.
GitHub에 karpathy/autoresearch라는 이름의 저장소가 올라왔는데, 설명이 이겁니다. “AI agents running research on single-GPU nanochat training automatically.” 자고 일어나면 AI가 알아서 LLM 학습 실험을 돌려놓는다는 거예요.
autoresearch란? Andrej Karpathy가 2026년 3월 공개한 오픈소스 프로젝트로, AI 에이전트가 단일 GPU에서 LLM 학습 코드(train.py)를 스스로 수정하고, 고정 5분 예산 내에서 실험을 반복 수행하며, 결과를 keep/discard로 판정하는 자율 연구 루프입니다. GitHub 스타 7,700개를 넘겼습니다(2026년 3월 기준).
7,700개 스타를 하루 만에 찍었다는 건, 이 아이디어가 단순히 “신기하다”를 넘어서 많은 개발자들이 “나도 이거 원했다”고 느꼈다는 뜻이겠죠.
저는 Obsidian 볼트에서 AI 에이전트 시스템을 1년 넘게 구축해온 사람입니다. 에이전트 17개, 스킬 33개, 매일 돌리는 RALPH 루프까지. 근데 솔직히요, 그 중에 “밤새 알아서 돌아가는” 에이전트는 하나도 없었어요. 전부 제가 트리거해야 움직이는 구조였거든요. autoresearch를 보고 나서 “아, 진짜 자동화는 이런 거구나” 싶었습니다.
autoresearch가 나온 배경 — Karpathy는 왜 이걸 만들었을까
Karpathy는 2026년 2월 26일, 이런 말을 했습니다.
“I’ve never felt this much behind as a programmer.”
20년 경력의 프로그래머가 “이렇게 뒤처진 느낌은 처음”이라고요. 에이전트, 서브에이전트, 프롬프트, MCP, 플러그인, 스킬, 후크… 갑자기 마스터해야 할 새로운 추상화 레이어가 폭발적으로 늘었다는 겁니다. 그는 이걸 “매뉴얼 없이 건네진 강력한 외계 도구”라고 표현했어요.
그리고 같은 달 말, 더 놀라운 경험을 공유합니다. SSH 키 설정, 비전 모델 다운로드와 벤치마크, 비디오 분석 대시보드 구축, 시스템 서비스 설정, 리포트 작성까지 — 이 모든 걸 AI 에이전트에게 맡겼더니 30분 만에 끝났다고요. “3개월 전이었으면 주말 프로젝트였을 것”이라면서요.
이 맥락에서 autoresearch가 나옵니다. AI 에이전트가 이미 “주어진 작업”을 잘 해내니까, 이제 “연구 자체”를 맡겨보자는 거예요. 사람이 자는 8시간 동안, AI가 알아서 가설을 세우고, 코드를 고치고, 실험을 돌리고, 결과를 기록하게 만드는 겁니다.
3파일 구조 뜯어보기 — 놀랍도록 단순합니다
이 저장소가 충격적인 이유는 구조가 너무 작다는 겁니다. 핵심 파일이 딱 3개예요.
| 파일 | 역할 | 누가 건드리나 |
|---|---|---|
prepare.py | 데이터 준비 + 유틸리티 | 사람 (초기 세팅) |
train.py | LLM 학습 코드 | AI 에이전트 (자동 수정) |
program.md | 연구 조직 규칙/지시문 | 사람 (연구 방향 설정) |
여기서 핵심을 잡아야 합니다. 코드보다 program.md가 더 중요합니다.
program.md는 “사람이 AI에게 주는 연구 방향서”예요. “어떤 가설을 세워라”, “어떤 방식으로 실험해라”, “기준 지표는 이거다” — 이런 내용을 자연어로 적어놓은 문서입니다. AI 에이전트는 이 문서를 읽고, train.py를 수정하고, 실험을 돌리고, 결과를 판단합니다.
이게 왜 중요하냐면요. 전통적인 ML 연구에서는 코드가 곧 연구였어요. 학습률 바꾸고, 모델 아키텍처 수정하고, 데이터 전처리 파이프라인 고치고 — 이 모든 게 코드 수정이었습니다. 근데 autoresearch에서는 코드 수정을 AI에게 위임하고, 사람은 “방향”만 잡습니다. 연구 방법론 자체의 전환이에요.
전에 Cursor Automations 포스트에서 “트리거 기반 자동화”를 다뤘었는데, autoresearch는 한 단계 더 나갑니다. 트리거조차 필요 없어요. 그냥 돌려놓으면 알아서 반복합니다.
5분 실험 루프 — 이게 전부입니다
autoresearch의 실험 루프는 놀랍도록 단순합니다.
LOOP FOREVER:
1. train.py의 현재 상태를 읽는다
2. 가설을 세운다 ("learning rate를 올려볼까?")
3. train.py를 수정한다
4. git commit (실험 기록)
5. 5분 동안 학습을 돌린다 (고정 예산)
6. val_bpb(검증 손실) 추출
7. 개선됐으면 → keep (브랜치 전진)
같거나 나빠졌으면 → revert (원복)
8. results.tsv에 기록
9. 멈추지 않는다 — 사람이 중단할 때까지
이 디자인에서 가장 영리한 부분은 고정 5분 예산입니다. 왜 5분이냐고요?
모델 크기가 다르고, 배치 사이즈가 다르고, 학습률이 다른 실험들을 공정하게 비교하려면 뭔가 고정해야 합니다. autoresearch는 “시간”을 고정시킵니다. 5분 안에 얼마나 val_bpb를 낮출 수 있느냐. 이렇게 하면 모델이 크든 작든 동일한 컴퓨팅 예산 안에서 비교가 됩니다.
결과는 TSV(탭 구분) 파일로 쌓입니다. 대시보드도 없고, 데이터베이스도 없고, 인프라도 없어요. 진짜 파일 하나에 한 줄씩 쌓이는 겁니다.
commit metric_1 metric_2 status description a1b2c3d 0.9979 44.0 keep baseline b2c3d4e 0.9932 44.2 keep increased learning rate to 0.04 c3d4e5f 1.0050 44.0 discard switched to GeLU activation d4e5f6g 0.0000 0.0 crash doubled model width (OOM)
8시간 자는 동안 5분씩 돌리면? 약 100개의 실험이 완료됩니다. 자고 일어나면 결과 테이블이 100줄 채워져 있는 거예요. 그 중에서 keep만 골라보면 어떤 변경이 실제로 성능을 올렸는지 한눈에 보입니다.
autoexp — 나도 쓸 수 있게 일반화된 버전
autoresearch가 공개되고 이틀 만에(2026년 3월 7일) 누군가가 이걸 일반화했습니다. autoexp라는 이름으로요.
autoexp란? Karpathy의 autoresearch 패턴을 ML 학습뿐 아니라 측정 가능한 모든 프로젝트에 적용할 수 있도록 일반화한 자율 실험 루프 프레임워크입니다.
핵심은 4가지 구성요소를 정의하면 어떤 도메인에서든 이 패턴을 쓸 수 있다는 겁니다.
| 구성요소 | 설명 | 예시 |
|---|---|---|
| Target file | 에이전트가 수정하는 단 하나의 파일 | train.py, prompt.txt, config.yaml |
| Eval harness | 결과를 측정하는 불변 스크립트 | evaluate.py, run_bench.sh |
| Metric | 1-2개 스칼라 값 | val_bpb ↓, accuracy ↑ |
| Budget | 시간/비용 상한 | 5분/회, 최대 100회, $10 |
이 구조가 적용 가능한 영역이 놀랍도록 넓습니다.
| 도메인 | 수정 대상 | 측정 지표 |
|---|---|---|
| ML 학습 | train.py | val_loss ↓ |
| 프롬프트 엔지니어링 | prompt.txt | 평가 정확도 ↑ |
| RAG 파이프라인 | config.yaml | 검색 정밀도 ↑ |
| API 최적화 | handler.py | p99 레이턴시 ↓ |
| 시스템 프롬프트 | system.md | 태스크 점수 ↑ |
| SQL 쿼리 | query.sql | 실행 시간 ↓ |
| 인프라 비용 | terraform.tf | 시간당 비용 ↓ |
프롬프트 엔지니어링에 적용하면 이런 겁니다. prompt.txt 하나를 에이전트가 밤새 수정하면서, 평가 세트로 정확도를 측정하고, 올라가면 keep, 떨어지면 discard. 자고 일어나면 최적화된 프롬프트가 남아있는 거예요.
이 아이디어가 작동하는 전제 조건은 명확합니다.
- 측정 가능한 지표가 있어야 함 — 주관적 품질은 불가
- 빠른 피드백 루프 — 실험당 초~분 단위여야 함
- 단일 파일 수정 — 멀티 파일 리팩토링은 위험
- 불변 평가 하니스 — 기준이 바뀌면 비교 불가
“에이전트가 우주를 리팩토링하는 것”을 막는 제약 조건이 바로 이 4가지예요. 제약이 있어야 탐색이 효율적이 됩니다.
Karpathy의 8-Agent 연구조직 실험 — 그리고 솔직한 실패
autoresearch만으로 안 끝납니다. Karpathy는 더 야심 찬 실험도 했어요.
Claude 4개, Codex 4개, 총 8개 에이전트를 투입해서 nanochat 연구 조직을 만들었습니다. GPU 한 대씩 배정하고, git 브랜치로 격리하고, tmux 그리드로 모니터링하는 구조였어요. Docker도 VM도 없이, git worktree와 파일 기반 커뮤니케이션만 썼습니다.
결과요? 실패였습니다.
에이전트들은 코드 구현 능력은 뛰어났어요. 시키는 건 잘합니다. 근데 실험 설계에서 무너졌습니다.
- 기준선(baseline)을 제대로 안 잡았습니다
- 변인 통제(ablation)를 안 했습니다
- 계산량(FLOPs)을 통제하지 않았습니다
- 한 에이전트는 네트워크 크기를 늘려서 성능이 올랐는데, 학습 시간이 같이 늘어난 걸 무시했습니다 — 전형적인 교란 변수 실수
이 실험에서 Karpathy가 내린 결론은 명확합니다.
“Multi-agent LLM research orgs currently require human PI oversight for hypothesis generation and experimental rigor.”
AI가 코드를 짜고, 실험을 돌리고, 결과를 기록하는 건 잘합니다. 근데 **”어떤 실험을 해야 하는가”**를 결정하는 건 아직 사람의 몫이라는 거예요. 연구의 “방향타”는 사람이 잡아야 합니다.
이게 바로 autoresearch에서 program.md가 핵심인 이유이기도 해요. AI에게 “알아서 해봐”라고 하면 교란 변수를 무시하고 엉뚱한 결론을 내는 일이 벌어집니다. “이 방향으로 탐색해봐, 단 이건 건드리지 마”라고 명확히 지시해야 합니다.
내가 느낀 점
솔직히 autoresearch를 보면서 두 가지 감정이 동시에 들었습니다.
하나는 흥분이었습니다. “와, 이제 AI가 밤새 실험을 돌려준다고?” 프롬프트 최적화, RAG 파이프라인 튜닝, 시스템 프롬프트 개선 — 이런 걸 자는 동안 자동으로 돌릴 수 있다면? 하루가 문자 그대로 두 배가 되는 거잖아요.
다른 하나는 자괴감이었습니다. 저는 AI 에이전트 시스템을 1년 넘게 만들어왔거든요. 에이전트 17개, 스킬 33개, RALPH 루프까지 있어요. 근데 이 모든 게 “사람이 트리거해야 돌아가는” 구조예요. Karpathy가 보여준 건 “사람이 자고 있어도 돌아가는” 구조입니다. 차이가 큽니다.
에이전트를 많이 만드는 게 중요한 게 아니라, 에이전트가 자율적으로 돌아가게 만드는 게 진짜 자동화라는 걸 autoresearch가 보여줬습니다.
솔직한 마음
불안한 부분도 있습니다.
autoresearch는 NVIDIA GPU(H100)가 있어야 의미가 있어요. 맥북 로컬에서 돌리기에는 한계가 명확합니다. 그리고 “측정 가능한 스칼라 지표”가 있어야 한다는 전제도 모든 작업에 해당하는 건 아닙니다. 블로그 글쓰기 품질이나 UI 디자인 같은 건 숫자로 환원할 수 없으니까요.
8-agent 실험이 실패했다는 것도 무시할 수 없어요. AI가 코드를 잘 짜는 것과, AI가 “좋은 질문을 던지는 것”은 완전히 다른 능력입니다. autoresearch가 잘 작동하는 건, program.md에서 사람이 방향을 잡아줬기 때문이에요. 방향 설정 없이 “자유 연구해봐”라고 하면 교란 변수를 무시하고 엉뚱한 결론을 내는 일이 벌어집니다.
근데 방향은 보입니다. “모든 작업을 자동화”하려는 대신, “측정 가능한 작업”만 골라서 자동화하면 됩니다. 전부 다 할 필요 없어요.
앞으로 할 것들
autoresearch에서 가져올 수 있는 패턴을 정리했습니다.
1. 즉시 적용 가능: 프롬프트 자동 최적화 루프
Target: system-prompt.md (에이전트 시스템 프롬프트) Eval: 고정된 테스트 케이스 10개 Metric: 정답률 ↑ Budget: 실행당 30초, 최대 50회
제 에이전트 스킬 중 하나를 골라서, 밤새 프롬프트를 최적화하는 루프를 돌릴 수 있습니다. 자고 일어나면 정답률이 올라간 프롬프트가 있는 거예요. 이건 GPU가 없어도 API 토큰만 있으면 됩니다.
2. 이번 주 시도: autoexp 패턴 로컬 이식
autoresearch 자체를 돌리기보다, autoexp의 “단일 파일 수정 + 고정 예산 + keep/discard” 패턴을 로컬 자동화 워크플로우에 이식하는 게 현실적입니다. git 브랜치에서 돌리면 본체는 안전하고, TSV로 결과가 쌓이니 별도 인프라도 필요 없어요.
3. 보류/관찰: 멀티에이전트 연구 조직
8-agent 실험이 실패한 건 “아직”이라고 봅니다. Karpathy가 지적한 문제 — baseline 미설정, ablation 누락, FLOPs 미통제 — 이건 program.md에 “실험 위생 규칙”을 넣으면 개선 가능합니다. 다만 지금 당장은 시기상조예요.
FAQ
Q1. autoresearch를 맥북에서 돌릴 수 있나요?
공식 저장소는 NVIDIA GPU(H100 기준)와 Python 3.10+, uv 패키지 매니저가 필요합니다. 커뮤니티 포크인 miolini/autoresearch-macos가 맥OS 지원을 시도하고 있으니 확인해볼 만합니다. autoexp 패턴 자체는 GPU 없이도 프롬프트 최적화 등에 적용 가능합니다.
Q2. program.md에 뭘 써야 하나요?
연구 방향, 가설 생성 규칙, 실험 예산, 평가 지표를 자연어로 적습니다. “learning rate 0.001~0.1 범위에서 탐색하라”, “모델 크기는 변경하지 마라” 같은 제약 조건이 핵심입니다. 제약이 명확할수록 에이전트가 더 효율적으로 탐색합니다.
Q3. autoexp는 어떤 프로젝트에 적용하면 좋나요?
측정 가능한 지표가 있고, 피드백 루프가 빠른(초~분 단위) 프로젝트면 뭐든 됩니다. 프롬프트 엔지니어링, RAG 파이프라인 튜닝, SQL 쿼리 최적화, 컴파일러 플래그 조정 등이 좋은 시작점이에요. 주관적 판단이 필요한 작업(UI 디자인, 글쓰기 품질)에는 맞지 않습니다.
Q4. 8-agent 연구 조직은 왜 실패했나요?
에이전트들의 코드 구현 능력은 충분했지만, 실험 설계 역량이 부족했습니다. 기준선 없이 비교하고, 교란 변수를 통제하지 않는 등 “과학적 연구의 기본기”가 빠져있었어요. Karpathy는 이를 “Human PI oversight가 필요하다”고 정리했습니다.
Q5. keep/discard 외에 다른 판정 기준은 없나요?
autoexp는 3가지 상태를 씁니다: keep(개선됨, 유지), discard(같거나 나빠짐, 원복), crash(실행 실패). 두 개 지표를 동시에 쓸 때는 Primary/Secondary, Pareto, Weighted 세 가지 방식으로 우열을 판단할 수 있습니다.
Q6. 비용은 얼마나 드나요?
GPU 기반 autoresearch는 GPU 시간 비용이 듭니다(H100 클라우드 기준 시간당 $2~3). LLM API 기반 autoexp는 토큰 비용이 들어요. autoexp 가이드는 실험 50회, 최대 $10 같은 예산 캡 설정을 권장합니다. 밤새 100회 프롬프트 최적화 기준 $5~20 정도 예상됩니다.
결론
Karpathy의 autoresearch가 보여준 건 단순한 오픈소스 프로젝트가 아닙니다.
“AI 에이전트에게 코드를 시키는 시대”에서 **”AI 에이전트에게 연구를 시키는 시대”**로 넘어가는 전환점이에요. 그리고 그 전환의 핵심은 놀랍게도 코드가 아니라 program.md — 사람이 쓴 자연어 지시문입니다.
자는 동안 AI가 100개의 실험을 돌려놓는다. 이건 더 이상 SF가 아니라, GitHub에서 git clone할 수 있는 현실입니다.
다만 기억해야 할 건, Karpathy 자신이 8-agent 실험에서 배운 교훈이에요. “어떤 실험을 할 것인가”를 결정하는 건 여전히 사람의 일입니다. AI에게 삽을 쥐어줄 수는 있지만, 어디를 팔지는 우리가 정해야 합니다.
참고 자료
- karpathy/autoresearch GitHub — 공식 저장소 (★7,700+)
- autoexp: Autonomous Experimentation Loop — autoresearch 일반화 버전
- Karpathy 8-Agent Nanochat Research Org 분석 — 멀티에이전트 실험 결과
- karpathy/nanochat GitHub — nanochat 프로젝트
- Karpathy의 프로그래밍 변화 발언 — 에이전트 시대 관점