10년 전만 해도 모델 학습을 돌려놓고 퇴근한 뒤, 다음 날 아침에 터져있는 Loss 그래프를 보며 좌절하는 게 ML 엔지니어들의 일상이었습니다. 하이퍼파라미터 몇 개 바꾸고 다시 하루를 기다리는 지루한 과정의 연속이었죠. 그런데 최근 Andrej Karpathy가 이 과정을 통째로 AI에게 넘겨버리는 흥미로운 실험 결과물을 공개했습니다. 바로 autoresearch 프로젝트입니다.

솔직히 처음 이 레포지토리를 봤을 때 “또 뻔한 AutoGPT 류의 장난감인가?” 싶었습니다. 하지만 코드를 뜯어보고 Karpathy가 설계한 제약 조건들을 살펴보니, 시니어 엔지니어로서 꽤 무릎을 탁 치게 만드는 우아한 엔지니어링 포인트들이 있었습니다.

오늘은 이 프로젝트가 어떻게 동작하는지, 그리고 Hacker News에서 벌어진 흥미로운 논쟁들을 바탕으로 이것이 단순한 장난감인지 아니면 미래 연구 방법론의 프리뷰인지 제 생각을 정리해 보겠습니다.

극단적으로 제한된 샌드박스: 3개의 파일과 5분의 시간

이 프로젝트의 핵심은 제약 에 있습니다. AI Agent에게 전체 코드베이스를 던져주고 “알아서 개선해”라고 하면 십중팔구 코드를 망가뜨리거나 무한 루프에 빠집니다. Karpathy는 이를 방지하기 위해 환경을 극단적으로 단순화했습니다.

• prepare.py: 데이터 다운로드, 토크나이저 학습 등 런타임 유틸리티입니다. Agent는 이 파일을 절대 수정할 수 없습니다.
• train.py: 모델 아키텍처, 옵티마이저, 학습 루프가 들어있는 단일 파일입니다. Agent의 유일한 놀이터입니다.
• program.md: Agent에게 주어지는 베이스라인 인스트럭션 파일입니다.

엔지니어링 관점에서 가장 인상 깊었던 부분은 5분이라는 고정된 Time budget 입니다.

Agent가 train.py 코드를 어떻게 수정하든 (배치 사이즈를 키우든, 레이어를 깎든) 무조건 5분 동안만 학습을 진행합니다. 그리고 val_bpb (validation bits per byte)라는 단일 지표로 성능을 평가하죠.

과거 우리가 NAS(Neural Architecture Search)나 AutoML을 구축할 때 가장 골치 아팠던 문제가 바로 하드웨어 환경에 따른 평가의 일관성이었습니다. Karpathy는 Wall-clock 기준으로 5분을 강제함으로써, 하룻밤 자고 일어나면 정확히 100개 남짓의 독립적이고 비교 가능한 실험 결과가 쌓이도록 파이프라인을 설계했습니다. 아주 실용적이고 영리한 접근입니다.

이것은 단순한 하이퍼파라미터 튜닝인가?

Hacker News에서 가장 뜨거웠던 논쟁 중 하나는 “이게 기존의 BayesOpt 같은 HPO(Hyperparameter Optimization)랑 다를 게 뭐냐?”는 것이었습니다. 실제로 Agent가 밤새 만들어낸 개선점들을 보면 대부분 Learning rate를 조절하거나 배치 사이즈를 만지작거린 수준이었습니다.

하지만 여기에 Karpathy 본인이 직접 등판해서 남긴 답변이 꽤 흥미롭습니다. 그는 이것이 기존 HPO와 세 가지 측면에서 다르다고 강조했습니다.

1. 단순한 파라미터 조정을 넘어 코드 자체를 임의로 수정 할 수 있습니다. (예: 활성화 함수를 통째로 교체)
2. 병렬로 자원을 낭비하는 Sweep 방식이 아니라, LLM이 이전 실험 결과를 보고 순차적으로 방향을 좁혀가는 탐색이 가능합니다.
3. Human in the loop가 전혀 필요 없습니다.

제가 깊이 공감했던 부분은 LLM의 현재 한계에 대한 그의 솔직한 평가였습니다. 그는 현재의 LLM 모델들이 너무 열린 결말의 문제를 주면 굉장히 조심스럽고(cagy) 겁먹은(scared) 상태가 되어 창의적인 연구를 주저한다고 언급했습니다.

이는 실제 현업에서 LLM을 이용해 코드 리팩토링이나 아키텍처 설계를 시켜본 분들이라면 100% 공감할 겁니다. 모델은 안전한 길(기존 파라미터 미세조정)을 택하려는 관성이 강합니다. Karpathy는 이를 해결하기 위해 Chief Scientist 페르소나를 부여해 논문을 검색하고 실험 계획만 짜게 한 뒤, 주니어 엔지니어 Agent들이 tmux 세션에서 이를 실행하게 하는 구조를 테스트해 보았다고 합니다. 이 접근법은 당장 우리 회사 내부의 개발 파이프라인에도 적용해 볼 만한 훌륭한 아이디어입니다.

커뮤니티의 반응과 나의 생각

HN 커뮤니티의 반응은 엇갈렸습니다. “Anthropic 내부에서는 이미 Claude를 이렇게 쓰고 있을 것”이라는 기대감 섞인 반응도 있었고, 반대로 “비싼 Claude 토큰을 태워서 고작 Tiny LLM 성능 쥐꼬리만큼 올리는 게 무슨 의미냐, 진짜 Breakthrough가 나오면 깨워달라”는 냉소적인 비판도 있었습니다. (Y축이 0부터 시작하지 않는 그래프로 성과를 과장했다는 예리한 지적도 있었죠.)

제 개인적인 결론을 말씀드리자면, 이 프로젝트는 당장 프로덕션 레벨의 모델을 개선할 수 있는 마법의 지팡이는 아닙니다. 아직은 값비싼 토큰을 태우는 우아한 장난감에 가깝습니다.

하지만 이 코드는 우리가 2026년 즈음에 맞이할 AI 엔지니어링 워크플로우의 명확한 프리뷰 를 보여줍니다. 우리는 더 이상 파이토치 학습 루프를 한 줄 한 줄 디버깅하지 않을 것입니다. 대신 program.md 파일에 어떤 컨텍스트를 주입할지, Agent의 Time budget을 어떻게 설정할지, 그리고 Chief Scientist Agent에게 어떤 제약 조건을 줄 것인지를 고민하는 시스템 설계자 로 역할이 바뀔 것입니다.

이번 주말, 남는 GPU가 있다면 이 작은 샌드박스를 한번 돌려보시길 권합니다. AI가 당신을 대신해 밤새 실패하고, 배우고, 코드를 수정하는 로그를 아침에 커피 한잔과 함께 읽어보는 경험은 꽤나 신선한 충격이 될 것입니다.

---

References

• Original Repository: karpathy/autoresearch
• Hacker News Thread: News YCombinator