pi-autoresearch: Karpathy의 AI 자율 실험 아이디어를 범용화한 오픈소스는 무엇인가

 

https://github.com/davebcn87/pi-autoresearch

GitHub - davebcn87/pi-autoresearch: Autonomous experiment loop extension for pi

 

pi-autoresearch를 한 줄로 정리하면 "Karpathy가 3월에 던진 autoresearch를 ML 훈련 바깥으로 끌어낸 범용판" 이다. 원조 karpathy/autoresearch는 공개 1주일 만에 깃헙 스타 3만 개를 넘기며 폭발적으로 확산됐는데, 문제는 이것이 "단일 H100에서 nanochat 훈련" 이라는 단일 시나리오에만 집중돼 있었다는 점이다. 그래서 "GPU도 없는 환경에서 저것을 어떻게 써먹을 수 있는가"라는 반응이 국내 개발자 커뮤니티에서 다수 등장했다. pi-autoresearch는 그 틈을 정확히 겨냥해 나온 오픈소스이다. 테스트 속도든, 번들 사이즈든, Lighthouse 점수든, 빌드 타임이든 — 숫자로 측정 가능한 것이라면 무엇이든 AI가 밤새 자율적으로 최적화 루프를 돌려주는 구조로 설계됐다. 이 글에서는 pi-autoresearch가 구조적으로 무엇을 하는 도구인지, 어떻게 운용하는지, 실제로 얻을 수 있는 것이 무엇인지를 하나씩 풀어본다.

Karpathy의 autoresearch부터 짚고 간다

pi-autoresearch를 이해하려면 원조부터 살펴봐야 한다. 그렇지 않으면 "왜 이런 식으로 만들어졌는가"라는 맥락이 잡히지 않는다.

630줄짜리 파이썬 스크립트가 일으킨 파장

Karpathy는 2026년 3월 6일 karpathy/autoresearch를 공개했다. 고작 630줄짜리 파이썬 스크립트이다. 그러나 이것이 1주일 만에 깃헙 스타 3만 개를 돌파했다. 역대 AI/ML 관련 오픈소스 중에서도 스타 증가 속도 상위권에 속하는 기록이다.

핵심 아이디어는 지극히 단순하다. 5분짜리 훈련을 돌리고, 결과를 측정하고, 개선됐으면 그 변경을 유지하고 그렇지 않으면 롤백하고, 이것을 밤새 반복하는 구조이다. 시간당 약 12회, 하룻밤이면 100회 가까운 실험이 돌아간다. 사람은 자고 일어나 "어제 무엇이 좋아졌는가" 로그만 확인하면 된다.

측정 대상은 val_bpb (validation bits per byte) 하나이다. 단일 NVIDIA GPU에서 nanochat이라는 미니 LLM을 훈련시키면서 이 숫자를 얼마나 떨어뜨리는지만 관찰한다. 하드웨어는 H100급 한 장이면 충분하다.

왜 이것으로 파장이 일었는가

이유는 두 가지다. 첫째, "AI 에이전트가 연구를 대신한다" 는 추상적 담론이 마침내 630줄짜리 돌아가는 코드로 증명됐다는 점이다. 둘째, 실사용 성과가 즉시 터졌다. Shopify CEO Tobi Lütke가 자사 내부에 이 아이디어를 적용해 자체 아키텍처 소형 모델의 val 점수를 19% 개선했다고 X(트위터)에서 공개했다. 수작업으로 튜닝한 더 큰 모델보다 성능이 역전되는 케이스까지 나왔다는 것이다.

여기에 "The New Stack", "VentureBeat", "MarkTechPost" 같은 매체가 일제히 가세하면서 "오버나잇 실험 패러다임" 자체가 업계 화두로 떠올랐다. 국내에서도 긱뉴스/클리앙 중심으로 번역 요약이 돌기 시작했지만, 딱 거기서 멈춘 것이 문제였다. 원조가 nanochat 하나에만 집중돼 있어서 "그래서 나는 무엇을 해야 하는가"라는 독자에게 제시할 답이 없었다.

그렇다면 pi-autoresearch는 무엇이 다른가

여기부터 본론이다. pi-autoresearch는 이 한계를 깨뜨리기 위해 등장한 오픈소스이다.

우선 pi부터 짚는다

pi-autoresearch를 이해하려면 먼저 pi가 무엇인지부터 알아야 한다. pi는 터미널에서 동작하는 AI 코딩 에이전트이다. 커서(Cursor), Claude Code, Aider 같은 계열의 도구라고 보면 대체로 맞다. 차이점은 pi가 "스킬"이라는 확장 구조를 갖추고 있어 슬래시 커맨드로 새 기능을 붙일 수 있다는 것이다. pi-autoresearch는 바로 이 스킬 시스템 위에 얹힌 익스텐션이다. 즉 단독 실행 스크립트가 아니라 "pi 에이전트에 설치하는 자율 실험 플러그인" 인 셈이다.

이것을 모르고 글을 읽으면 "왜 갑자기 /autoresearch 같은 슬래시 커맨드가 등장하는가" 하고 혼동하게 된다. 실제로 영문 레퍼런스 중에도 이 부분을 그냥 건너뛰는 글이 많다.

범용화의 핵심은 "임의의 숫자를 최적화 타깃으로 삼을 수 있다"는 점이다

Karpathy 원조와 pi-autoresearch의 차이를 한눈에 정리하면 다음과 같다.

항목	Karpathy autoresearch	pi-autoresearch
타깃 도메인	LLM 훈련 (val_bpb 하나)	임의 (테스트 속도, 번들 사이즈, 빌드 타임, Lighthouse, LLM 훈련 등)
실험 시간	고정 5분	벤치마크 스크립트 종료까지 가변
하드웨어	단일 H100급 GPU 필수	GPU-less도 가능 (유스케이스에 따라 상이)
수정 파일	train.py 한 개 고정	스코프 지정한 파일들 자유
메트릭 형식	val_bpb 단일	`METRIC name=number` 라인 여러 개
세션 복구	약함	`autoresearch.md` + `.jsonl`로 강함
사용 방식	Python 스크립트 직접 실행	`/autoresearch` 슬래시 커맨드

표에서 가장 큰 차이는 "메트릭 형식" 이다. 원조는 하드코딩된 val_bpb 하나만 봤지만, pi-autoresearch는 벤치마크 스크립트 stdout에 METRIC lighthouse=87, METRIC test_seconds=12.4 식의 라인만 찍히면 무엇이든 타깃으로 삼을 수 있다. 이것이 진정한 게임체인저이다. "측정 가능하면 최적화 가능" 을 범용 프로토콜로 승격시킨 것이다.

실전 유스케이스 5가지

이것이 왜 중요한가 하면, GPU 없는 사람도 활용할 수 있는 시나리오가 곧바로 나오기 때문이다.

• 테스트 속도 단축: pnpm test를 벤치마크로 잡고, 타깃은 실행 초 단위이다. pi가 테스트 파일을 수정하면서 parallel 설정, 불필요한 setup 코드 제거, mock 전략 조정 같은 것을 자율적으로 시도한다
• 번들 사이즈 다이어트: pnpm build && du -sb dist가 벤치마크다. tree-shaking 실패 지점, 중복 import, 큰 라이브러리 대체 후보를 에이전트가 밤새 탐색한다
• Lighthouse 점수 개선: 헤드리스 크롬으로 Lighthouse를 돌리고 점수만 stdout에 출력하면 된다. CLS, LCP 같은 개별 지표도 각각 METRIC 라인으로 분리 가능하다
• 빌드 타임 단축: Webpack/Vite 설정 파일 튜닝을 자율로 위임한다
• LLM 훈련: 원조 기능이므로 당연히 가능하다. 단일 GPU 환경이면 nanochat 스타일 훈련 루프도 그대로 붙일 수 있다

이 중에서도 번들 사이즈와 테스트 속도는 GPU가 전혀 필요 없다. 노트북만 있어도 밤새 돌릴 수 있는 유스케이스이다.

내부 동작 원리 — 어떻게 자율적으로 굴러가는가

"자율적으로 밤새 돈다"가 구호처럼 들릴 수 있지만, 실제 내부는 꽤 깔끔하게 설계돼 있다.

3개 핵심 도구

pi-autoresearch는 에이전트에게 3개의 도구를 추가로 제공한다.

• init_experiment: 세션 설정이다. 목표, 벤치마크 커맨드, 메트릭 이름, 스코프 파일을 등록한다
• run_experiment: 등록된 커맨드를 실제로 실행하고 stdout에서 METRIC name=number 라인을 파싱한다. 실행 시간도 함께 기록한다
• log_experiment: 결과를 append-only 로그에 기록하고, 개선됐으면 git commit까지 자동으로 찍는다

에이전트는 이 3개 도구를 반복 호출하면서 코드를 수정하고, 측정하고, 기록하는 루프를 돈다. 개선이 없으면 git 기반으로 자동 롤백되는 구조라 워크스페이스가 꼬일 일이 거의 없다.

두 개의 영속 파일이 핵심이다

pi-autoresearch가 Karpathy 원조 대비 확실한 우위를 점하는 지점이 바로 이 세션 복구 부분이다.

• autoresearch.md: 현재 세션의 목표, 측정 지표 정의, 지금까지 무엇을 시도했고 무엇이 성공했고 무엇이 실패했는지가 전부 기록되는 사람 읽기용 문서이다
• autoresearch.jsonl: 매 실험마다 한 줄씩 추가되는 머신 읽기용 append-only 로그이다

이 둘이 존재하기에 에이전트 컨텍스트 창이 폭발하거나, 프로세스가 죽거나, 이튿날 아침에 새 세션을 띄워도 pi가 이 파일 두 개만 읽으면 "여기부터 이어서 실험하면 되는구나"라고 판단해 그대로 재개할 수 있다. 오버나잇 실험에서 이것이 없으면 큰 문제가 된다. Karpathy 원조는 이 부분이 약해 세션이 끊기면 상태 복구가 상당히 까다롭다.

라이브 대시보드도 제공한다

터미널 안에서 상태를 보기 위해 로그 파일을 일일이 뒤질 필요가 없다. 단축키가 마련돼 있다.

• Ctrl+X: 인라인 대시보드 토글이다. 현재 메트릭 추이를 작게 보여준다
• Ctrl+Shift+X: 풀스크린 오버레이다. 경과 시간, 컨피던스 스코어, 최근 실험 히스토리까지 한 번에 표시된다
• /autoresearch export: 브라우저에서 깔끔한 대시보드를 열어준다. 퇴근하면서 휴대폰으로 확인하기 좋다

pi-autoresearch 실전 시작하기

설명은 여기까지 하고, 실제로 어떻게 시작하는지를 본다.

설치

davebcn87/pi-autoresearch 깃헙 레포로 가면 된다. pi 에이전트가 이미 설치돼 있다는 전제이며, 그 위에 스킬로 얹는 구조이다. pi가 없다면 먼저 pi부터 설치해야 한다. Windows 환경이라면 WSL2에서 구동하는 것을 권장한다 — git 자동 커밋 동작이 순수 Windows 경로에서 가끔 꼬이는 케이스가 보고돼 있다.

첫 세션 만들기

/skill:autoresearch-create를 실행하면 대화형으로 세팅이 시작된다. 질문은 대략 4개이다.

1. 목표가 무엇인가 (예: "테스트 실행 시간 절반으로 줄이기")
2. 벤치마크 커맨드가 무엇인가 (예: pnpm test)
3. 메트릭 이름은 무엇인가 (예: test_seconds, 낮을수록 좋음)
4. 수정해도 되는 파일 스코프가 어디까지인가 (예: src/*/.ts, vitest.config.ts)

이 네 가지에 답하면 autoresearch.md가 자동 생성되고 세션 준비가 완료된다.

주요 커맨드

• /autoresearch : 최적화 모드 진입이다. 컨텍스트에 힌트를 넣어주면 에이전트가 거기서부터 아이디어를 도출한다
• /autoresearch off: 루프 일시정지다. 이상한 방향으로 흘러가면 이것으로 멈추고 사람이 개입한다
• /autoresearch clear: 세션 리셋이다. md/jsonl 파일은 백업한 뒤 초기화된다
• /autoresearch export: 브라우저 대시보드 오픈

실행 전 반드시 점검할 사항

실제로 활용할 때 한 번씩 밟는 지뢰들이다.

• 워크스페이스를 git clean 상태로 시작한다: pi-autoresearch는 개선 발견 시 자동 커밋을 찍는다. 기존에 커밋되지 않은 변경이 섞여 있으면 에이전트 변경과 꼬이면서 롤백이 애매해진다
• 벤치마크 스크립트가 METRIC name=number 형식으로 stdout을 출력하는지 확인한다: 이 한 줄이 파싱되지 않으면 에이전트는 "실험이 실패했다"고 판단하고 계속 헤맨다
• 한 사이클이 너무 길면 실험 횟수가 급감한다: 원조처럼 5분 근처가 스윗 스팟이고, 아무리 길어도 30분을 넘기지 않는 편이 좋다. 1시간짜리 빌드를 타깃으로 잡으면 오버나잇에 8번밖에 돌지 못한다
• 한글 로케일 주의: 벤치마크 스크립트에서 한글 경로나 BOM이 섞이면 METRIC 파싱이 깨지는 경우가 있다. UTF-8 LF로 통일하는 것이 안전하다

실제 효과는 어느 정도인가

숫자 없이 "좋다"고만 말하면 허풍이다. 공개된 케이스를 짚어본다.

Shopify의 19% 개선 사례

Shopify CEO Tobi Lütke가 X에서 공개한 내용인데, 자체 소형 모델 아키텍처를 autoresearch 루프에 맡겼더니 val 점수가 19% 개선됐다는 것이다. 포인트는 두 가지다.

첫째, 이것이 초거대 모델이 아니라 "작은 모델"이었다는 점이다. 수동으로 튜닝한 더 큰 모델보다 자율 실험을 돌린 작은 모델 쪽 성능이 역전되는 케이스까지 나왔다. 둘째, 루프가 건드린 영역은 아키텍처 하이퍼파라미터 계열 — 레이어 수, head 수, lr 스케줄, dropout 등 — 이었다고 알려져 있다. 사람이 grid search를 돌리려면 1~2주 걸릴 탐색 공간을 밤새 자동으로 가지치기 한 것이다.

pi-autoresearch로 이것을 그대로 재현하려면 val 점수를 출력하는 벤치마크 스크립트만 있으면 된다. 하드웨어 요구사항만 충족되면 Shopify 수준은 아니어도 시도 자체는 충분히 해볼 만하다.

한계와 주의점

냉정하게 단점도 있다.

• 플랫폼별 타이밍 편차: 테스트 속도나 빌드 타임 같은 월클락 기반 메트릭은 동일 코드라도 머신마다 다르게 측정된다. CI에서 개선된 결과가 로컬에서는 악화될 수 있다
• 로컬 옵티마에 갇힌다: 에이전트는 "점수가 오르는 방향"으로만 전진한다. 구조를 갈아엎어야 나오는 혁신적 아이디어는 잘 찾지 못한다. 진짜 아키텍처 혁신은 아직 사람의 몫이다
• 토큰 비용이 만만치 않다: 오버나잇 루프 한 번이면 Claude/GPT API 비용이 수천~수만 원 발생하는 경우가 있다. 로컬 LLM으로 돌리려면 pi 설정을 변경해야 한다

유사 도구들과 비교하면

autoresearch 생태계가 한 달 사이에 상당히 빠르게 확산됐다. 주요 포지션만 빠르게 훑어본다.

• karpathy/autoresearch: 원조이다. ML 훈련 (nanochat) 한정이고 단일 H100이 전제다. 읽을거리로서의 가치가 크다
• drivelineresearch/autoresearch-claude-code: Claude Code 환경으로 포팅한 버전이다. pi를 사용하지 않는 사람에게 대안이 된다
• aiming-lab/AutoResearchClaw: 이것은 더 야심찬 프로젝트이다. "아이디어 발굴 → 실험 → 논문 초안"까지 자동화하려 한다. 학계 쪽에서 주목받는 중이다
• alvinreal/awesome-autoresearch: 큐레이션 리스트다. 관련 도구를 한 번에 훑고 싶을 때 편리하다

이 중에서 "코딩 에이전트 워크플로우에 자연스럽게 녹여 쓰고 싶다" 는 목적이라면 pi-autoresearch가 현재 가장 깔끔하다. 슬래시 커맨드 기반 사용성이 결정적 차이이다.

정리하면 다음과 같다

pi-autoresearch를 짧게 요약하면 이런 도구이다. 첫째, Karpathy autoresearch의 핵심 아이디어 — AI가 밤새 자율로 실험 루프를 돌리기 — 를 ML 훈련 밖 영역으로 범용화했다. 둘째, pi 에이전트가 집행자이며 슬래시 커맨드로 매끄럽게 세션을 운용할 수 있다. 셋째, METRIC name=number 프로토콜만 맞추면 테스트 속도든 번들 사이즈든 Lighthouse든 타깃이 될 수 있다. 넷째, autoresearch.md + .jsonl 이중 기록 구조 덕분에 세션이 끊겨도 복구가 강력하다. 다섯째, Shopify가 실제 사례로 19% 개선을 달성했고 숫자로 검증됐다.

개인적으로는 주말에 쉬면서 금요일 밤에 "테스트 스위트 속도 깎아보기" 세션 하나를 걸어두고 토요일 점심에 로그를 확인하러 오는 그림이 가장 매력적이라고 본다. 사람이 지루해하는 반복 튜닝을 에이전트에게 위임하고 사람은 방향성만 잡는 역할 분담이다. 이것이 돌아가는 방식을 한 번만 경험하면, 왜 1주일 만에 깃헙 스타 3만 개가 붙었는지 몸으로 이해된다. 깃헙 davebcn87/pi-autoresearch 레포와 karpathy/autoresearch 원조 둘 다 한 번씩 뜯어보는 것을 추천한다. 2026년 상반기 기준, pi-autoresearch는 "AI 자율 실험"을 일반 개발자의 일상 도구로 끌어내린 가장 실용적인 오픈소스이다.