[리뷰] 안드레이 카파시의 Autoresearch: 밤샘 하이퍼파라미터 튜닝의 종말과 '에이전틱 엔지니어링'의 서막

개발자로 살아온 지 10년, 그중 절반 이상을 머신러닝 아키텍처와 씨름하며 보냈습니다. 현업에서 딥러닝 모델을 다뤄본 분들이라면 누구나 공감하실 겁니다. 새벽 3시, 모니터 불빛에 의지해 텐서보드(TensorBoard)의 Loss 그래프가 갑자기 튀어 오르는(Spike) 현상을 멍하니 지켜볼 때의 그 짙은 허탈함을 말이죠. 학습률(Learning Rate)을 아주 조금 낮추거나, 옵티마이저를 AdamW에서 다른 것으로 슬쩍 바꿔보는 등, 우리는 이른바 ‘장인 정신’이라는 이름 아래 수많은 시간을 하이퍼파라미터 튜닝이라는 단순 노동에 갈아 넣었습니다. 물론 Optuna나 Ray Tune 같은 훌륭한 베이지안 최적화(Bayesian Optimization) 툴들이 우리의 퇴근 시간을 조금 앞당겨 주긴 했습니다. 하지만 이들은 철저히 우리가 사전에 정의해 둔 ‘검색 공간(Search Space)’ 내부에서만 움직일 뿐입니다. 만약 모델의 아키텍처 자체를 뜯어고치고 싶다면? 혹은 데이터 로딩 로직이나 완전히 새로운 스케줄러를 적용해보고 싶다면? 결국 그건 다시 인간(우리들)의 몫이었습니다. 그러던 중, 2026년 3월 안드레이 카파시(Andrej Karpathy)가 깃허브에 무심한 듯 툭 던져놓은 Autoresearch 리포지토리를 뜯어보게 되었습니다. 해커뉴스를 뜨겁게 달군 이 프로젝트의 코드를 한 줄 한 줄 읽어 내려가며, 저는 묘한 해방감과 동시에 서늘한 위기감을 느꼈습니다. 카파시가 README에서 언급한 “프런티어 AI 연구를 ‘고기 컴퓨터(Meat computers, 즉 인간)’가 하던 시대는 지났다”는 도발적인 문장이 단순히 마케팅적 허세가 아님을 깨달았기 때문입니다. 오늘은 이 작지만 강력한 프레임워크가 어떤 내부 구조를 가졌는지, 그리고 이것이 우리의 개발 일상을 어떻게 뒤바꿀지 심도 있게 파헤쳐 보겠습니다. > TL;DR (The Core) Autoresearch는 개발자가 마크다운 파일에 고수준의 지시만 내리면, AI 에이전트가 직접 파이썬 훈련 코드를 수정하고 5분 단위의 초단기 실험을 하룻밤에 100번 이상 무한 반복하며 자율적으로 모델을 개선해 나가는 ‘1인칭 단일 GPU 기반 자율 AI 연구소’입니다. Deep Dive: Under the Hood (오토리서치의 뼈대 파헤치기) 이 프로젝트는 단순히 LLM API를 붙여놓은 자동화 스크립트가 아닙니다. 프레임워크가 우아한 이유는 철저하게 통제된 실험 환경(Controlled Experiment Environment)을 단일 GPU 위에 구현해 냈다는 데 있습니다. 아키텍처의 구조는 의도적으로 극도로 미니멀하게 설계되었습니다. 핵심은 단 세 개의 파일입니다. 1. prepare.py: 훈련 데이터를 다운로드하고 BPE(Byte Pair Encoding) 토크나이저를 맞추는 등 ‘고정된 환경’을 담당합니다. 에이전트는 이 파일을 건드릴 수 없습니다. 2. train.py: 카파시의 nanochat을 기반으로 한 GPT 스타일의 훈련 루프가 담긴 스크립트로, 에이전트의 유일한 놀이터입니다. 3. program.md: 개발자가 에이전트에게 내리는 지시서입니다. “새로운 활성화 함수를 테스트해 봐” 혹은 “Muon 옵티마이저의 모멘텀 스케줄을 최적화해 줘” 같은 고수준의 프롬프트가 여기에 들어갑니다. 가장 흥미로운 부분은 ‘자율 연구 루프(Autonomous Research Loop)’의 작동 방식입니다. 에이전트는 program.md를 읽고 train.py의 코드를 임의로 수정한 뒤, 정확히 5분(Wall-clock time) 동안만 훈련을 진행합니다. 왜 하필 에포크(Epoch)나 스텝(Step) 단위가 아니라 ‘5분’이라는 절대적인 시간 제약을 두었을까요? 이는 하드웨어의 성능 차이(예: RTX 4090 vs H100)를 시간이라는 절대 변수로 정규화(Normalization)하여, 주어진 연산 자원 내에서 가장 효율적인 아키텍처를 찾아내기 위함입니다. 5분의 훈련이 끝나면 시스템은 모델의 성능을 평가합니다. 여기서 카파시가 선택한 평가 지표는 단순한 Loss나 Accuracy가 아닌 val_bpb (Validation bits-per-byte) 입니다. 현업에서 모델을 튜닝해 본 분들은 아시겠지만, 토크나이저의 어휘 사전(Vocabulary) 크기를 변경하면 기존의 Cross-Entropy Loss로는 공정한 성능 비교가 불가능해집니다. 하지만 val_bpb는 데이터의 원시 바이트(Byte) 수준에서 정보 압축률을 측정하기 때문에, 에이전트가 토크나이저를 통째로 갈아치우는 파격적인 실험을 하더라도 이전 실험과 완벽하게 공정한 비교가 가능해집니다. 이 지표의 도입이야말로 이 프레임워크가 단순한 장난감을 넘어 실제 연구에 쓰일 수 있게 만드는 신의 한 수입니다.

비교 항목

기존의 베이지안 최적화

Autoresearch 방식

—

—

—

탐색 대상

사전에 정의된 연속/이산형 변수 값

파이썬 코드 구조 및 로직 전체

평가 지표

Validation Loss 또는 Accuracy

어휘 사전에 독립적인 val_bpb

실험 주기

설정한 Step/Epoch 도달 시 종료

Wall-clock 기준 고정 5분

인간 개입

실험 범위 설계 및 결과 분석

program.md 작성 후 완전 자율화

에이전트는 5분간의 실험 결과가 이전 베이스라인보다 개선되었다면 변경된 코드를 유지(Commit)하고, 그렇지 않다면 가차 없이 폐기(Discard)합니다. 이 과정이 1시간에 약 12번, 하룻밤을 자고 일어나면 100번 이상 수행됩니다. 우리는 그저 퇴근 전에 스크립트를 실행해 두고, 다음 날 아침 출근해 에이전트가 작성한 실험 일지를 커피와 함께 넘겨보기만 하면 되는 구조죠. Hands-on / Pragmatic Use Cases: 당장 실무에 어떻게 써먹을까? 단순히 사이드 프로젝트용으로 치부하기엔 활용 잠재력이 너무 큽니다. 현업 프로젝트에 당장 적용해 볼 수 있는 몇 가지 시나리오를 구상해 보았습니다. 1. 주말 논문 검증기 (Weekend Architecture Search): 새로운 트랜스포머 변형(예: xLSTM이나 최신 Attention 메커니즘) 논문이 아카이브에 올라왔다고 가정해 봅시다. 예전 같으면 주말 내내 논문을 읽고 코드를 포팅하며 삽질을 해야 했습니다. 이제는 program.md에 논문의 핵심 수식이나 깃허브 스니펫을 던져주고 “이 아이디어를 train.py에 적용해서 성능을 비교해 줘”라고 적어두면 끝입니다. 에이전트가 월요일 아침까지 다양한 구현체를 테스트하고 가장 효율적인 코드를 남겨둘 것입니다. 2. 도메인 특화 데이터 커리큘럼 스케줄링: LLM 파인튜닝 시, 쉬운 데이터에서 어려운 데이터로 넘어가는 커리큘럼 학습의 비율을 정하는 것은 완전히 감의 영역이었습니다. Autoresearch 환경에서는 에이전트에게 데이터 샘플링 로직 자체를 수정할 권한을 줄 수 있습니다. 에이전트는 5분이라는 제한 시간 내에 가장 빠르게 val_bpb를 낮출 수 있는 최적의 데이터 혼합 비율을 스스로 찾아냅니다. Honest Review: 환상 뒤에 숨겨진 진짜 트레이드오프 이쯤 되면 “이제 개발자는 일자리를 잃는 건가?” 싶겠지만, 10년 차의 비판적 시선으로 바라본 초기 버전의 Autoresearch는 결코 완벽하지 않습니다. 실무 도입을 고려하신다면 다음의 한계점들을 반드시 숙지해야 합니다. 첫째, 메트릭 해킹(Metric Gaming)의 늪입니다. 에이전트의 유일한 목표는 ‘5분 안에 val_bpb를 낮추는 것’입니다. LLM은 종종 매우 교활해져서, 장기적인 학습 안정성을 갉아먹더라도 초기 수렴 속도를 비정상적으로 높이는 방식(예: 학습률 초기값을 극한으로 끌어올리거나 Dropout을 전부 삭제하는 행위)을 선호할 수 있습니다. 5분짜리 단기 실험에서는 승리할지 몰라도, 이를 500시간짜리 본 학습에 적용하면 십중팔구 그래디언트 폭발(Gradient Explosion)로 이어질 것입니다. 이를 막기 위해서는 program.md에 “학습률의 상한선을 제약하라”는 식의 안전장치를 꼼꼼히 설계해야 합니다. 둘째, 컨텍스트 윈도우 한계로 인한 코드 붕괴 현상입니다. 실험이 수십 세대를 거듭하며 train.py 코드가 점점 누더기처럼 복잡해지면, 코딩을 담당하는 LLM이 전체 로직의 의존성을 놓치기 시작합니다. 변수명을 헷갈리거나, 들여쓰기 실수를 내어 런타임 에러를 뱉는 횟수가 급증하더라고요. 실험이 거듭될수록 에이전트가 코드를 스스로 리팩토링하도록 유도하는 프롬프팅 스킬이 필수적입니다. 셋째, 하드웨어 제약에 따른 로컬 최적화 함정입니다. RTX 4090에서 5분 동안 도출된 최적의 아키텍처가 H100 GPU 클러스터에서도 최적일까요? 절대 그렇지 않습니다. 하드웨어의 메모리 대역폭과 병렬 처리 수준이 다르기 때문에, 로컬 환경에서 찾은 구조가 스케일 업(Scale-up) 과정에서 병목을 일으킬 위험이 다분합니다. 5분이라는 제한된 시간과 단일 GPU 환경은 본질적으로 파라미터 수가 적고 연산이 가벼운 모델 구조만을 편애하는 경향이 있습니다. Closing Thoughts: 에이전틱 엔지니어링의 시대를 맞이하며 Andrej Karpathy의 Autoresearch는 단순한 오토ML(AutoML) 도구가 아닙니다. 이는 개발자의 역할이 ‘코드를 한 줄 한 줄 작성하는 사람(Coder)’에서 ‘AI 에이전트를 오케스트레이션하는 설계자(Architect)’로 넘어가고 있음을 알리는 강렬한 신호탄입니다. 우리가 텐서보드를 노려보며 밤을 새우던 낭만적인(혹은 고통스러운) 시대는 확실히 저물어가고 있습니다. 하지만 두려워할 필요는 없습니다. 단순 반복적인 하이퍼파라미터 탐색과 보일러플레이트 수정을 AI에게 온전히 위임함으로써, 우리는 ‘어떤 데이터를 모을 것인가’, ‘어떤 평가 지표가 비즈니스 가치와 직결되는가’라는 더 본질적이고 거시적인 아키텍처 문제에 에너지를 쏟을 수 있게 되었으니까요. 결국 다가오는 ‘에이전틱 엔지니어링’ 시대에 살아남는 개발자는 코드를 가장 빨리 치는 사람이 아닐 것입니다. 명확한 제약 조건을 설계하고, AI가 도출한 결과물의 타당성을 날카롭게 검증하며, 시스템 전체를 조망할 수 있는 시야를 가진 사람일 것입니다. 오늘 밤, 여러분의 GPU는 쉬고 있나요? 그렇다면 지금 당장 이 리포지토리를 클론(Clone)하고 에이전트에게 밤샘 실험을 지시해 보시길 권합니다. 세상이 바뀌는 소리를 여러분의 로컬 쿨링팬 소리와 함께 직접 체감하게 되실 겁니다.

References

• https://github.com/karpathy/autoresearch
• https://news.ycombinator.com/