Autoresearch: AI가 직접 수정하면서 LLM 실험을 밤새 반복하는 방식

연구자가 하던 일을 에이전트가 대신하는 시대가 정말 오고 있다.
그런데 이 저장소가 흥미로운 이유는 “논문을 요약하는 AI”가 아니라, 실제로 코드를 수정하고 학습을 돌리고 성능이 좋아졌는지 판단한 뒤 다음 실험으로 넘어가는 AI 연구 루프를 아주 작은 형태로 보여주기 때문이다.

autoresearch는 거대한 플랫폼이 아니다. 오히려 반대다.
파일 몇 개, 단일 GPU, 5분짜리 실험, 하나의 평가 지표. 이 단순한 제약 안에서 “AI가 연구를 수행하게 하려면 무엇을 고정하고 무엇을 열어둬야 하는가”를 굉장히 영리하게 보여준다. 저장소 설명 그대로 핵심은 에이전트에게 작은지만 실제적인 LLM 학습 환경을 주고, train.py를 바꾸며 성능 향상을 탐색하게 하는 것이다. 2026년 3월 19일 기준 이 저장소는 약 4.2만 개 이상의 스타를 받으며 빠르게 확산되고 있다. (GitHub)

 

GitHub - karpathy/autoresearch: AI agents running research on single-GPU nanochat training automatically

 

프로젝트 소개

autoresearch는 Andrej Karpathy가 공개한 오픈소스 실험 저장소로, 단일 GPU 위에서 AI 에이전트가 LLM 학습 코드를 자동으로 바꾸고 실험을 반복하도록 설계된 최소 연구 환경이다. 사람이 직접 파이썬 코드를 계속 수정하는 대신, 사람은 에이전트에게 줄 연구 지침을 program.md에 적고, 에이전트는 그 지침에 따라 train.py를 수정하며 반복 실험을 수행한다. (GitHub)

이 프로젝트의 구조는 의도적으로 작다. README는 실제로 중요한 파일을 거의 세 개로 압축한다.

• prepare.py: 데이터 준비, 토크나이저, 데이터로더, 평가 로직
• train.py: 모델/옵티마이저/학습 루프, 에이전트가 수정하는 대상
• program.md: 에이전트를 움직이는 연구 운영 문서

즉, 이 저장소는 “더 좋은 모델을 만드는 코드”라기보다, AI가 연구를 수행하기 좋은 인터페이스를 어떻게 설계할지에 더 가깝다. 요구 환경은 Python 3.10+, uv, 그리고 현재 기준 단일 NVIDIA GPU이며 README에서는 H100에서 테스트했다고 명시한다. (GitHub)

왜 이 프로젝트가 등장했을까

기존의 모델 연구는 대체로 다음 순서로 진행된다.

1. 연구자가 가설을 세운다.
2. 하이퍼파라미터나 아키텍처를 바꾼다.
3. 학습을 돌린다.
4. 로그를 읽는다.
5. 성능이 나아졌는지 확인한다.
6. 안 좋으면 되돌리고, 좋으면 다음 실험으로 넘어간다.

문제는 이 과정이 굉장히 반복적이라는 점이다. 더구나 LLM 시대에는 코드 수정 범위가 넓고, 성능 비교를 공정하게 하려면 평가 기준도 고정돼야 한다. autoresearch는 바로 이 지점을 찌른다. 사람은 실험의 철학과 운영 원칙만 제공하고, 코드 수정과 반복 실행은 에이전트에게 위임한다. README는 사람이 더 이상 파이썬 파일을 직접 만지지 않고, 대신 program.md 같은 문서로 “연구 조직”을 프로그래밍한다는 발상을 전면에 내세운다. (GitHub)

이 접근이 중요한 이유는 단순 자동화가 아니기 때문이다.
핵심은 탐색 공간을 잘 고정한 자동 연구 루프다.

• 수정 가능한 대상은 train.py 하나로 제한
• 평가 기준은 prepare.py의 evaluate_bpb로 고정
• 실험 시간은 300초로 고정
• 지표는 val_bpb 하나로 단순화

이렇게 해야 에이전트가 “편법” 대신 실제 성능 개선을 찾도록 만들 수 있다. 다시 말해, autoresearch는 AI 에이전트를 잘 쓰기 위한 기술보다 먼저, AI가 속이기 어려운 연구 문제를 어떻게 설계할 것인가를 보여주는 저장소다. (GitHub)

핵심 기능

1. 에이전트가 직접 수정하는 대상이 하나뿐이다

이 저장소에서 에이전트가 건드리는 파일은 기본적으로 train.py 하나다. program.md는 에이전트의 작업 지침이고, prepare.py는 읽기 전용에 가깝다. 이 설계는 매우 중요하다. 수정 범위를 한 파일로 좁히면 에이전트의 diff가 작아지고, 실패했을 때 되돌리기도 쉽다. README도 이 점을 “single file to modify”라는 설계 선택으로 강조한다. (GitHub)

개발자 관점에서 보면 이건 자유도를 줄인 대신 반복 속도와 검토 가능성을 극대화한 구조다. 에이전트에게 모든 걸 열어두면 똑똑해 보이지만, 실전에서는 디버깅이 훨씬 어려워진다.

2. 5분 고정 예산으로 실험을 비교한다

prepare.py에는 TIME_BUDGET = 300이 박혀 있고, README도 학습이 5분 기준으로 돌아가도록 설계됐다고 설명한다. 이건 단순한 편의 기능이 아니다. 모델 크기, 배치 크기, 윈도우 패턴, 옵티마이저를 바꾸더라도 각 실험이 같은 시간 예산 안에서 경쟁하게 만든다. (GitHub)

이 방식의 장점은 분명하다.

• 긴 학습을 기다리지 않아도 된다.
• 아키텍처 변경과 하이퍼파라미터 변경을 같은 기준으로 비교할 수 있다.
• 플랫폼 위에서 “이 5분 안에 가장 잘 배우는 모델”을 찾게 된다.

즉, 이 저장소는 절대적 성능보다 제한된 시간 안에서의 연구 생산성을 최적화한다.

3. 평가 기준이 val_bpb 하나로 고정된다

최종 평가는 train.py에서 evaluate_bpb(model, tokenizer, DEVICE_BATCH_SIZE)를 호출해 수행한다. prepare.py의 evaluate_bpb는 bits per byte를 사용하며, README는 이 지표가 vocab size에 덜 의존적이라 아키텍처 변경을 더 공정하게 비교할 수 있다고 설명한다. (GitHub)

이건 매우 좋은 선택이다.
에이전트에게 여러 지표를 주면 보통 한쪽을 희생하면서 다른 쪽을 올리는 식의 혼란이 생긴다. 반대로 단일 지표를 주면 의사결정이 단순해진다.

4. 결과를 keep/discard/crash로 단순 관리한다

program.md는 실험 결과를 results.tsv에 기록하도록 지시하고, 상태를 keep, discard, crash 세 가지로 관리한다. 개선되면 브랜치를 전진시키고, 아니면 git reset으로 되돌린다. (GitHub)

이 구조는 사실상 진화 알고리즘의 매우 실용적인 Git 버전이다.

• mutation: train.py 수정
• evaluation: uv run train.py
• selection: val_bpb 비교
• survival: 개선된 커밋만 유지

복잡한 오케스트레이터 없이도 꽤 강력한 실험 루프가 된다.

프로젝트 아키텍처 분석

이 저장소의 아키텍처는 화려하지 않다. 대신 역할 분리가 아주 명확하다.

이 구조를 개발자 관점에서 다시 해석하면 다음과 같다.

• program.md는 프롬프트가 아니라 연구 운영체계
• prepare.py는 라이브러리가 아니라 변경 불가 심판
• train.py는 모델 코드이면서 동시에 실험 표적
• Git 브랜치는 버전 관리이면서 동시에 선택 압력의 기록 장치

즉 autoresearch는 AI 에이전트 시스템에서 자주 보이는 “도구 호출” 중심 구조보다, 제약된 코드베이스 안에서 반복 실험을 수행하는 자율 연구 루프에 더 가깝다. (GitHub)

내부 동작을 코드 레벨에서 보면

1. prepare.py는 고정된 실험 환경이다

prepare.py에는 MAX_SEQ_LEN = 2048, TIME_BUDGET = 300, EVAL_TOKENS = 40 * 524288 같은 상수가 들어 있다. 또한 캐시 경로, Hugging Face 데이터셋 URL, validation shard, tokenizer 관련 설정도 이 파일이 관리한다. 토크나이저 vocab size는 8192로 고정돼 있다. (GitHub)

특히 데이터로더는 BOS 정렬과 best-fit packing을 사용해 패딩 없이 100% 활용을 지향하고, 평가 함수는 bits per byte 계산을 담당한다. 이 말은 곧 학습 효율과 평가 방식이 이미 정해져 있으니, 에이전트는 그 위에서 모델 구조와 학습 전략만 탐색하라는 뜻이다. (GitHub)

2. train.py는 진짜 실험장이 맞다

train.py는 single-GPU single-file pretraining script다. 코드 초반에는 GPU capability를 보고 Flash Attention 3 커널 소스를 선택한 뒤, prepare.py에서 상수와 토크나이저, 데이터로더, 평가 함수를 가져온다. (GitHub)

모델도 생각보다 단순한 GPT 복제본이 아니다.

• CausalSelfAttention
• Block
• GPT
• rotary embedding
• value embeddings
• 레이어별 residual scaling 파라미터
• sliding/full window 혼합 패턴

같은 요소들이 들어 있다. 예를 들어 WINDOW_PATTERN = "SSSL"은 일부 레이어는 sliding window, 일부는 full attention을 쓰도록 설계된 패턴이다. 또 GPT 내부에는 resid_lambdas, x0_lambdas, value_embeds 같은 추가 파라미터 구조가 보인다. (GitHub)

즉 이 프로젝트는 장난감이 아니다.
에이전트가 만지는 대상은 “아주 작은 데모 모델”이 아니라, 꽤 현실적인 최적화 포인트가 살아 있는 소형 연구 코드다.

3. 옵티마이저도 에이전트 실험에 맞게 설계됐다

train.py에는 MuonAdamW라는 결합 옵티마이저가 들어 있고, 2D matrix 파라미터에는 Muon, 나머지에는 AdamW를 쓰도록 되어 있다. 하이퍼파라미터도 코드 상단에서 직접 수정하는 방식이다. EMBEDDING_LR, UNEMBEDDING_LR, MATRIX_LR, SCALAR_LR, WEIGHT_DECAY 등이 모두 노출되어 있다. (GitHub)

이 설계가 좋은 이유는 에이전트가 CLI 옵션을 조합하는 대신, 코드의 의미 단위로 변경할 수 있기 때문이다. 예를 들어 단순히 learning rate만 바꾸는 것이 아니라,

• matrix 계열만 공격적으로 조정하거나
• embedding 계열만 따로 제어하거나
• 레이어 스칼라만 별도 tuning

하는 식의 실험이 가능하다.

4. 고정 시간 예산을 실제 코드로 강제한다

학습 루프는 grad_accum_steps를 계산한 뒤 반복하고, step이 충분히 진행된 상태에서 total_training_time >= TIME_BUDGET이면 종료한다. 마지막에는 val_bpb, training_seconds, peak_vram_mb 등을 출력한다. (GitHub)

이 출력 형식이 중요한 이유는, 에이전트가 로그를 읽고 다음 결정을 내릴 수 있어야 하기 때문이다. 즉 사람을 위한 예쁜 대시보드보다, 에이전트가 grep 하기 쉬운 출력 구조가 더 중요하다.

이 저장소가 진짜 영리한 이유

많은 “AI 자동화” 프로젝트는 결국 프롬프트 엔지니어링 시연으로 끝난다.
하지만 autoresearch는 달라 보인다. 이유는 세 가지다.

첫째, 문제 정의가 선명하다.
좋은 연구 자동화는 모델이 똑똑한가보다, 문제를 얼마나 잘 고정했는가에 달려 있다. 이 저장소는 수정 대상, 평가 지표, 시간 예산을 모두 고정했다.

둘째, 실패를 자연스럽게 받아들인다.
keep/discard/crash라는 단순 분류는 자율 탐색에 딱 맞다. 모든 실험이 성공할 필요가 없다. 오히려 실패가 싼 구조가 중요하다.

셋째, 사람의 역할을 없앤 게 아니라 바꿨다.
사람은 더 이상 train.py를 직접 고치는 사람이 아니라, program.md를 통해 연구 전략을 설계하는 사람이 된다. README도 인간이 Python이 아니라 Markdown을 통해 연구 조직을 프로그래밍한다는 아이디어를 강조한다. (GitHub)

실제로 어떻게 사용할 수 있을까

사용 시나리오 1: 소규모 모델 연구 자동화

작은 연구팀이나 개인 개발자가 단일 GPU 환경에서 다음을 자동화하고 싶을 때 적합하다.

• learning rate / batch size 탐색
• attention window 패턴 탐색
• residual scaling 구조 변경
• value embedding 같은 구조적 실험
• optimizer group 재구성

예를 들어 이런 식으로 생각할 수 있다.

# train.py 안에서 에이전트가 바꿀 만한 포인트 예시
WINDOW_PATTERN = "LLLL"
DEPTH = 6
TOTAL_BATCH_SIZE = 2**18
MATRIX_LR = 0.03
WEIGHT_DECAY = 0.1

이후 실험 결과가 나빠지면 버리고, 좋아지면 유지한다.

사용 시나리오 2: 에이전트 기반 MLOps 실험실

이 프로젝트는 그 자체로 완성형 플랫폼은 아니지만, 다음 시스템의 출발점이 되기 좋다.

• AI coding agent
• Git branch per run
• experiment registry
• automatic rollback
• scoring harness

즉 사내 연구 플랫폼을 만들 때 “가장 작은 형태의 autonomous research loop” 참고 구현으로 볼 수 있다.

사용 시나리오 3: LLM 에이전트 설계 학습용

개인적으로는 이것이 가장 흥미롭다.
이 저장소는 AI 에이전트에게 일을 맡길 때 어떤 인터페이스가 좋은지 보여준다.

• 수정 가능 범위를 좁혀라
• 평가 기준을 바꾸지 못하게 하라
• 출력은 기계가 읽기 쉽게 하라
• 실패 비용을 낮춰라
• 사람이 개입하는 지점을 전략 레벨로 올려라

이 원칙은 코드 연구뿐 아니라, 배치 잡 튜닝, 데이터 파이프라인 최적화, 추론 성능 실험에도 그대로 응용할 수 있다.

간단한 실행 흐름 예시

README 기준으로 기본 흐름은 매우 단순하다.

uv sync
uv run prepare.py
uv run train.py

그리고 에이전트에게는 대략 이런 식으로 일을 맡긴다.

program.md를 읽고 새 실험을 시작해.
먼저 baseline을 측정하고,
그 다음에는 train.py만 수정해서 val_bpb를 낮추는 방향으로 반복해.
prepare.py는 건드리지 마.

실제로 program.md는 baseline을 먼저 잡고, 실험 결과를 TSV에 기록하고, 좋아지지 않으면 reset 하며, 사람이 멈출 때까지 계속 돌라고 지시한다. (GitHub)

이 프로젝트의 한계도 분명하다

좋은 프로젝트일수록 어디까지가 장점이고 어디서부터 한계인지 선명해야 한다.

1. 플랫폼 범위가 아직 좁다

README는 현재 단일 NVIDIA GPU가 필요하고 H100에서 테스트했다고 밝힌다. macOS, Windows, AMD용 포크들이 소개되지만, 본 저장소의 기본 경험은 여전히 NVIDIA 중심이다. (GitHub)

2. 비교 가능한 것은 “같은 머신 위 5분 실험”이다

README도 명시하듯, 고정 시간 예산 방식은 내 머신에서는 유효하지만 다른 사람 결과와 절대 비교하기 어렵다. 이건 단점이면서 동시에 설계 선택이다. (GitHub)

3. 연구 공간이 넓지만 완전 자율은 아니다

에이전트가 train.py를 고칠 수 있다고 해서 연구를 완전히 대체하는 것은 아니다. 실제로는 어떤 방향을 탐색해야 하는지, 실패를 언제 포기해야 하는지, 단순성과 성능 향상을 어떻게 균형 잡을지는 여전히 program.md를 쓰는 사람의 역량에 달려 있다. program.md도 “복잡성이 늘어나는 아주 작은 개선은 가치가 없을 수 있다”는 식의 단순성 기준을 직접 넣고 있다. (GitHub)

개발자에게 주는 시사점

autoresearch를 보면 “AI 에이전트란 무엇인가”에 대한 관점이 조금 바뀐다.

보통 우리는 에이전트를 이렇게 생각한다.

• 여러 도구를 호출한다
• 검색한다
• 요약한다
• 계획을 세운다

하지만 이 저장소가 보여주는 에이전트는 다르다.

• 코드를 수정한다
• 실행한다
• 수치로 평가한다
• Git으로 되돌린다
• 더 좋은 상태만 축적한다

즉 이 프로젝트의 본질은 채팅형 AI가 아니라, 실험 가능한 상태 공간 위를 이동하는 최적화 시스템이다.

그래서 이 저장소는 단순한 GitHub 밈이 아니라, 앞으로 등장할 수많은 “AI가 직접 개선하는 소프트웨어 시스템”의 축소판처럼 보인다.

마무리

autoresearch는 거대한 기능을 가진 프레임워크가 아니다.
그 대신 아주 날카로운 질문 하나를 던진다.

“연구를 자동화하려면 AI를 더 똑똑하게 만드는 게 먼저일까, 아니면 연구 문제를 AI가 다루기 좋게 재설계하는 게 먼저일까?”

이 저장소의 답은 분명하다.
먼저 문제를 재설계해야 한다.

• 수정할 곳은 하나로 줄이고
• 평가는 고정하고
• 시간 예산을 고정하고
• 실험 결과만 남기고
• 사람은 전략을 설계한다

이렇게 보면 autoresearch는 단순히 LLM 학습 자동화 저장소가 아니다.
AI 에이전트 시대의 연구 인터페이스를 설계하는 방식 자체를 보여주는 프로젝트다. (GitHub)