본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
본 콘텐츠의 이미지 및 내용을 무단으로 복제, 배포, 수정하여 사용할 경우 저작권법에 의해 법적 제재를 받을 수 있습니다.
AI Assistant
2026. 3. 31. · 1 Views
AutoResearch 개요 AI 자율 연구 에이전트 완벽 가이드
Andrej Karpathy의 AutoResearch 프로젝트를 완벽히 분석합니다. AI 에이전트가 자율적으로 LLM 학습 실험을 수행하는 시스템의 전체 아키텍처와 설계 철학을 다룹니다.
목차
- AutoResearch란 무엇인가
- 자율 연구 에이전트의 개념
- 3파일 구조: prepare.py, train.py, program.md
- 5분 타임 버짓 설계 철학
- val_bpb 평가 메트릭
- 실험 루프: 수정-학습-평가-유지/폐기
- nanochat과의 관계
1. AutoResearch란 무엇인가
김개발 씨는 최근 AI 연구 뉴스를 보다가 눈을 의심했습니다. "AI가 직접 AI를 연구한다고?" Andrej Karpathy가 발표한 AutoResearch라는 프로젝트가 화제가 되고 있었습니다. 김개발 씨는 당장 이 프로젝트가 뭔지 알아보기 시작했습니다.
AutoResearch는 Andrej Karpathy가 제안한 자율 연구 에이전트 시스템입니다. AI 에이전트가 단일 GPU 환경에서 LLM 학습 실험을 자동으로 설계하고 실행하며 결과를 평가하는 완전한 연구 루프를 구현합니다. 마치 주니어 연구원에게 실험실을 맡겨놓은 것과 같습니다.
# AutoResearch의 핵심 개념을 보여주는 의사코드
# 에이전트가 자율적으로 연구 루프를 돌립니다
while budget > 0:
idea = agent.think("다음 실험 아이디어는?")
code = agent.implement(idea) # 코드 작성
result = train(code) # 학습 실행
score = evaluate(result, "val_bpb") # 평가
if score < best_score:
best_score = score # 최고 기록 갱신
budget -= 1 # 예산 소진
AutoResearch는 AI 에이전트가 스스로 아이디어를 내고, 코드를 작성하고, 학습을 실행하며 결과를 평가하는 자율 연구 시스템입니다. Andrej Karpathy가 제안한 이 프로젝트는 단일 GPU에서 LLM 학습의 전체 사이클을 자동화합니다.
상세 설명
김개발 씨는 입사 3년 차 ML 엔지니어입니다. 매일 아침 출근하면 Jupyter Notebook을 열고, 하이퍼파라미터를 조금씩 바꿔보고, 학습을 돌리고, 결과를 확인하는 일이 반복됩니다. "이걸 AI가 자동으로 해줄 수 있다면 얼마나 좋을까?" 어느 날 팀 미팅에서 박시니어 씨가 슬랙 링크를 하나 공유했습니다. Karpathy의 AutoResearch 프로젝트였습니다. 그렇다면 AutoResearch란 정확히 무엇일까요? 쉽게 비유하자면, AutoResearch는 마치 자율주행 자동차와 같습니다. 운전자가 방향만 알려주면 차가 스스로 경로를 탐색하고, 장애물을 피하고, 목적지까지 도달합니다. AutoResearch도 마찬가지입니다. 연구자가 연구 방향만 제시하면, AI 에이전트가 스스로 실험을 설계하고 실행합니다. AutoResearch가 없던 시절에는 어땠을까요? 연구자들은 하이퍼파라미터 튜닝을 위해 수십 번의 실험을 직접 돌려야 했습니다. 학습이 돌아가는 동안 커피를 마시며 기다리고, 결과가 안 좋으면 다시 파라미터를 바꾸는 일이 일상이었습니다. 더 큰 문제는 시간이었습니다. 단일 GPU에서 의미 있는 실험 하나를 끝내는 데 최소 몇 시간은 걸렸습니다. 바로 이런 문제를 해결하기 위해 AutoResearch가 등장했습니다. AutoResearch를 사용하면 실험의 자동화가 가능해집니다. 에이전트가 아이디어를 생성하고, 코드를 수정하고, 학습을 실행하며, 결과를 평가하기까지 전체 파이프라인을 자율적으로 수행합니다. 무엇보다 인간의 개입 없이 연구 루프가 돌아간다는 것이 핵심입니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 while budget > 0:에서 에이전트에게 주어진 실험 예산을 확인합니다. 예산이 남아있는 동안 루프가 돕니다. 다음으로 agent.think()에서 에이전트가 스스로 다음 실험 아이디어를 고민합니다. train(code)에서 실제 학습이 실행되고, evaluate()에서 결과를 평가합니다. 이전보다 좋은 결과가 나오면 기록을 갱신하고, 예산을 하나 소진합니다. 실제 현업에서는 어떻게 활용할 수 있을까요? 예를 들어 새로운 모델 아키텍처를 연구하는 팀을 생각해봅시다. Attention 메커니즘의 변형, 학습률 스케줄링 전략, 정규화 방법 등 수많은 조합을 테스트해야 합니다. AutoResearch를 활용하면 밤새 수십 개의 실험을 자동으로 돌릴 수 있습니다. 아침에 출근하면 "어떤 조합이 가장 성능이 좋았는지" 이미 정리되어 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 오해 중 하나는 "AutoResearch가 연구자를 대체한다"는 생각입니다. 이렇게 생각하면 연구 방향 설정의 중요성을 간과하게 됩니다. 따라서 에이전트에게 명확한 연구 범위와 평가 기준을 제시하는 것이 선행되어야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 공유를 본 김개발 씨는 이 프로젝트의 잠재력을 직감했습니다. "이건 정말 게임 체인저가 될 수 있어." AutoResearch를 제대로 이해하면 AI 연구의 생산성을 획기적으로 높일 수 있습니다. 이 코스에서는 이 혁신적인 시스템의 모든 것을 파헤쳐볼 예정입니다. GPT 모델 구조부터 최적화 기법, 그리고 자율 연구 루프까지, 앞으로 8개의 카드뉴스에 걸쳐 단계적으로 학습해보겠습니다.
팁
- AutoResearch의 핵심은 "인간이 연구 방향을 정하고, AI가 실험을 자동으로 수행한다"는 점입니다
- 이 프로젝트는 단일 GPU 환경에서 동작하도록 설계되어 실용성이 높습니다
- 코스 전체 흐름: 개요 > 모델 구조 > 최적화 > 어텐션 > 임베딩 > 실험 루프 > 평가 > 종합
2. 자율 연구 에이전트의 개념
"에이전트라니, 어떤 에이전트 말이야?" 김개발 씨의 질문에 박시니어 씨는 화이트보드에 간단한 그림을 그렸습니다. 사각형 하나와, 그 안에서 순환하는 화살표. "이거 하나면 돼." 그것이 바로 자율 연구 에이전트의 전부였습니다.
자율 연구 에이전트는 연구의 전체 사이클을 독립적으로 수행하는 AI 시스템입니다. 아이디어 생성, 코드 구현, 실험 실행, 결과 평가를 스스로 반복하며 점진적으로 성능을 개선합니다. 마치 경험 많은 연구원이 혼자서 실험실에서 하루 종일 실험을 돌리는 것과 같습니다.
# 자율 연구 에이전트의 상태 전이를 나타내는 구조
class ResearchAgent:
def __init__(self, best_score=float('inf')):
self.best_score = best_score # 최고 성능 기록
self.history = [] # 실험 이력
def run_cycle(self, program, budget):
for i in range(budget):
idea = self.generate_idea(program, self.history)
modified = self.implement(idea, program)
result = self.execute(modified)
self.history.append((idea, result))
self.best_score = min(self.best_score, result)
자율 연구 에이전트는 아이디어 생성부터 결과 평가까지 전체 연구 사이클을 자율적으로 수행하는 AI 시스템입니다. 실험 이력을 기반으로 점진적으로 더 나은 아이디어를 도출해냅니다.
상세 설명
김개발 씨의 팀에서는 새로운 프로젝트를 시작할 때마다 정해진 루틴이 있었습니다. 리서치 파트가 논문을 조사하고, 엔지니어링 파트가 코드를 작성하고, ML 파트가 실험을 실행했습니다. 이 과정에서 각 파트 간의 소통 비용이 만만치 않았습니다. 박시니어 씨는 이 문제를 에이전트 패턴으로 해결할 수 있다고 설명했습니다. 그렇다면 자율 연구 에이전트란 정확히 무엇일까요? 쉽게 비유하자면, 자율 연구 에이전트는 마치 혼자서 레시피를 개발하는 요리사와 같습니다. 좋은 레시피를 찾을 때까지 요리를 해보고, 맛을 보고, 수정합니다. 때로는 실패하기도 하지만, 그 실패에서 배우며 다음 요리는 더 나아집니다. 에이전트도 마찬가지입니다. 이전 실험의 결과를 바탕으로 다음 아이디어를 더 똑똑하게 냅니다. 자율 연구 에이전트가 없던 시절에는 어땠을까요? 연구자는 한 번에 하나의 아이디어만 테스트할 수 있었습니다. 학습이 끝날 때까지 기다려야 했고, 결과가 나오면 분석하고, 다시 다음 실험을 설계해야 했습니다. 하루에 2-3개의 실험을 돌리는 것도 쉽지 않았습니다. 더 큰 문제는 망각이었습니다. 수십 번의 실험을 하다 보면, 10번 전에 뭘 시도했는지 기억하기 어려웠습니다. 바로 이런 문제를 해결하기 위해 자율 연구 에이전트가 등장했습니다. 에이전트는 실험 이력을 체계적으로 관리합니다. 어떤 아이디어를 시도했고, 어떤 결과가 나왔는지 모두 기록합니다. 다음 아이디어를 생성할 때 이 이력을 참고하므로, 중복 실험을 피하고 점진적으로 개선할 수 있습니다. 무엇보다 에이전트는 쉬지 않고 일합니다. 인간이 자는 사이에도 실험 루프는 계속 돌아갑니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 ResearchAgent 클래스는 best_score와 history라는 두 가지 상태를 유지합니다. best_score는 지금까지 가장 좋은 결과를 기억하고, history는 모든 실험의 이력을 저장합니다. run_cycle 메서드에서 예산만큼 반복하며, generate_idea로 새로운 아이디어를 냅니다. 이때 program(연구 계획서)과 history(과거 이력)를 함께 전달하여 문맥을 인식한 아이디어를 생성합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 트랜스포머 모델의 학습률 스케줄을 최적화한다고 가정해봅시다. 웜업 스텝, 코사인 어닐링, 스터프 스텝 등 수많은 조합이 존재합니다. 에이전트에게 이 범위를 주면, 밤새 수십 개의 조합을 테스트하고 "웜업 500스텝 + 코사인 어닐링 + 스터프 1000스텝" 같은 최적 조합을 찾아냅니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 에이전트에게 너무 넓은 탐색 범위를 주는 것입니다. 탐색 공간이 넓으면 좋은 결과를 찾기까지 예산이 기하급수적으로 늘어납니다. 따라서 연구자가 의미 있는 범위를 좁혀서 에이전트에게 전달하는 것이 중요합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 화이트보드의 순환 화살표를 보며 김개발 씨는 깨달았습니다. "결국 핵심은 피드백 루프구나. 결과를 보고 다음 행동을 결정하는 것." 자율 연구 에이전트의 진정한 힘은 자기 개선 루프에 있습니다. 실험을 하고, 결과를 보고, 배우고, 다시 실험합니다. 이 단순한 루프가 반복될 때 놀라운 결과가 나옵니다. 앞으로 이 루프를 구성하는 3가지 핵심 파일을 살펴보겠습니다.
팁
- 에이전트의 핵심은 "과거 이력을 기반으로 더 나은 아이디어를 생성"하는 능력입니다
- 탐색 범위를 좁히는 것이 에이전트의 효율을 결정합니다
- 이 코스에서는 AutoResearch의 에이전트가 어떤 방식으로 아이디어를 생성하는지 자세히 다룹니다
3. 3파일 구조: prepare.py, train.py, program.md
"이 프로젝트 전체 코드가 딱 세 파일이야." 박시니어 씨가 AutoResearch 레포지토리를 열어 보여줬습니다. 화면에는
prepare.py,train.py,program.md세 개의 파일만 있었습니다. 김개발 씨는 놀라움을 감추지 못했습니다. "이게 다라고요?"
AutoResearch의 전체 시스템은 단 세 개의 파일로 구성됩니다. prepare.py는 학습 데이터를 준비하고, train.py는 모델 학습을 실행하며, program.md는 연구 에이전트에게 전달되는 연구 계획서입니다. 마치 요리 레시피가 재료 준비, 조리 순서, 최종 목표로 나뉘는 것과 같습니다.
# prepare.py - 학습 데이터 준비의 핵심 구조
import numpy as np
def prepare_dataset(data_path, tokenizer, seq_len=128):
"""토큰화된 학습 데이터를 numpy 메모리맵으로 저장합니다"""
tokens = tokenize_file(data_path, tokenizer)
n_chunks = len(tokens) // seq_len
tokens = tokens[:n_chunks * seq_len] # 시퀀스 길이로 정렬
tokens = tokens.reshape(n_chunks, seq_len)
np.save(f"{data_path}.npy", tokens) # 빠른 로딩을 위해 메모리맵 사용
return tokens
AutoResearch는 prepare.py(데이터 준비), train.py(모델 학습), program.md(연구 계획서) 세 개의 파일로 전체 시스템을 구성합니다. 이 극도로 단순한 구조가 자율 연구의 핵심을 드러냅니다.
상세 설명
김개발 씨는 최근 참여한 프로젝트에서 설정 파일만 20개가 넘는 프로젝트를 본 적이 있습니다. YAML, JSON, TOML, env 파일들이 뒤엉켜 있었죠. 그래서 세 파일로 구성된 AutoResearch가 더욱 신선했습니다. 박시니어 씨는 이 단순함이 의도적이라고 설명했습니다. "Karpathy는 복잡성을 줄이는 게 에이전트 연구의 핵심이라고 봤어." 그렇다면 이 3파일 구조란 정확히 무엇일까요? 쉽게 비유하자면, 이 구조는 마치 미슐랭 레스토랑의 키친 시스템과 같습니다. prepare.py는 재료 손질 담당 셰프입니다. 채소를 씻고, 고기를 재우고, 양념을 합니다. train.py는 불 앞에서 요리하는 메인 셰프입니다. program.md는 레스토랑의 메뉴와 철학을 담은 문서입니다. 각자의 역할이 명확하고, 서로 간섭하지 않습니다. 이런 단순한 구조가 필요했던 이유는 무엇일까요? 복잡한 시스템에서는 에이전트가 이해해야 할 것이 너무 많습니다. 파일이 20개면, 에이전트는 각 파일 간의 의존성과 상호작용을 파악해야 합니다. 수정할 때도 어디를 건드려야 할지 헷갈리기 쉽습니다. AutoResearch는 이 문제를 근원적으로 해결했습니다. 파일이 세 개뿐이니, 에이전트가 시스템 전체를 이해하고 수정하는 것이 훨씬 쉽습니다. 바로 이런 이유로 3파일 구조가 선택되었습니다. prepare.py는 데이터 준비에 집중합니다. 텍스트 파일을 읽고, 토큰화하고, 학습에 적합한 형태로 변환합니다. train.py는 모델 정의와 학습 루프를 담당합니다. GPT 구조, 옵티마이저 설정, 학습 스텝 등이 모두 여기에 들어갑니다. program.md는 연구 지시서입니다. 에이전트에게 무엇을 연구할지, 어떤 범위에서 탐색할지, 어떤 기준으로 평가할지 알려줍니다. 위의 코드를 한 줄씩 살펴보겠습니다. prepare_dataset 함수는 데이터 파일 경로, 토크나이저, 시퀀스 길이를 받습니다. tokenize_file로 텍스트를 토큰으로 변환한 뒤, n_chunks * seq_len 크기로 잘라냅니다. 나머지 토큰은 버려집니다. 그다음 numpy 배열로 reshape하여 .npy 파일로 저장합니다. 메모리맵 방식을 사용하므로 대용량 데이터도 빠르게 로드할 수 있습니다. program.md의 역할도 중요합니다. 이 파일은 에이전트에게 **"어떤 실험을 해야 하는지"**를 알려주는 유일한 소스입니다. 예를 들어 "학습률을 1e-4에서 1e-3 사이에서 탐색하라"거나 "dropout을 0.0에서 0.2 사이에서 테스트하라"는 구체적인 지시가 들어갑니다. 에이전트는 이 지시를 바탕으로 train.py를 수정하고 실험을 수행합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 program.md에 너무 구체적인 코드를 적는 것입니다. 에이전트가 스스로 구현할 수 있는 수준의 가이드라인을 주어야 합니다. 코드를 일일이 지시하면 에이전트의 자율성이 제한되고, 탐색의 다양성이 떨어집니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 세 파일의 구조를 이해한 김개발 씨는 감탄했습니다. "단순함이야말로 가장 강력한 설계란 말이지." 3파일 구조는 AutoResearch의 철학을 완벽하게 담고 있습니다. 복잡성을 줄이면 에이전트가 더 잘 이해하고, 더 자율적으로 행동할 수 있습니다. 이 원칙은 소프트웨어 설계 전반에 적용할 수 있는 중요한 교훈입니다. 다음으로는 이 시스템이 어떻게 시간을 관리하는지 살펴보겠습니다.
팁
- prepare.py는 한 번만 실행하면 되고, 이후 train.py를 반복 실행하는 구조입니다
- program.md의 작성 품질이 에이전트의 성능을 직접적으로 결정합니다
- 에이전트는 주로 train.py를 수정하므로, 이 파일의 구조를 이해하는 것이 핵심입니다
4. 5분 타임 버짓 설계 철학
"5분이면 학습이 되나요?" 김개발 씨의 첫 반응이었습니다. 보통 LLM 학습은 몇 시간에서 며칠이 걸리는 게 정상인데, 단 5분으로 무엇을 할 수 있다는 걸까요? 박시니어 씨는 미소를 지었습니다. "바로 그게 포인트야."
**타임 버짓(Time Budget)**은 에이전트가 한 번의 실험에 사용할 수 있는 최대 시간입니다. AutoResearch는 기본적으로 5분으로 설정되어 있으며, 이 짧은 시간 안에 의미 있는 학습 결과를 얻을 수 있도록 소규모 데이터셋과 가벼운 모델을 사용합니다. 마치 스프린터가 단거리 연습으로 폼을 점검하는 것과 같습니다.
# 타임 버짓 관리의 핵심 - 시간 제한 학습 루프
import time
def train_with_budget(model, data, budget_sec=300):
"""주어진 시간 예산 내에서만 학습을 수행합니다"""
start = time.time()
step = 0
while time.time() - start < budget_sec:
loss = model.train_step(data)
step += 1
if step % 100 == 0:
elapsed = time.time() - start
print(f"step {step}: loss={loss:.4f} ({elapsed:.1f}s)")
return model, step # 학습된 모델과 총 스텝 수 반환
5분 타임 버짓은 한 번의 실험에 5분만 할애하도록 제한하는 설계 철학입니다. 짧은 주기로 빠르게 피드백을 받아 더 많은 실험을 수행하고, 다양한 아이디어를 탐색할 수 있게 합니다.
상세 설명
김개발 씨의 팀에서는 모델 학습을 시작하면 최소 반나절은 기다려야 했습니다. 큰 모델에 많은 데이터를 넣고 돌리다 보니, 결과를 확인하려면 점심을 먹고 와야 했습니다. "학습 한 번 돌리면 하루가 간다"는 농담이 있을 정도였습니다. 박시니어 씨는 AutoResearch의 5분 타임 버짓을 설명하며 이런 질문을 던졌습니다. "10시간 걸리는 실험 하나와, 5분 걸리는 실험 120개. 어느 쪽이 더 많은 것을 배울 수 있을까?" 그렇다면 5분 타임 버짓이란 정확히 무엇일까요? 쉽게 비유하자면, 5분 타임 버짓은 마치 스피드 체스와 같습니다. 긴 시간을 두고 깊이 생각하는 체스도 있지만, 빠르게 말을 움직이며 직관을 기르는 스피드 체스도 있습니다. AutoResearch는 스피드 체스 방식을 선택했습니다. 한 판에 오래 시간을 쓰지 않고, 많은 판을 빠르게 소화하면서 전체적인 패턴을 파악합니다. 5분 타임 버짓이 필요했던 이유는 무엇일까요? 첫째, 빠른 피드백이 핵심입니다. 에이전트가 한 가지 아이디어를 시도하고, 결과를 보고, 다음 아이디어를 낼 때까지의 주기가 짧아야 합니다. 10시간짜리 실험은 에이전트가 하루에 한 번만 피드백을 받는다는 뜻입니다. 하지만 5분이면 한 시간에 12번, 하루에 288번의 피드백이 가능합니다. 둘째, 다양한 탐색이 가능합니다. 예산이 50이라면, 5분 타임 버짓으로 약 4시간 동안 50개의 다양한 실험을 수행할 수 있습니다. 학습률, dropout, 레이어 수, 어텐션 헤드 수 등 여러 차원을 동시에 탐색할 수 있습니다. 셋째, 실패의 비용이 낮습니다. 10시간 실험이 실패하면 10시간을 날린 셈이지만, 5분 실험이 실패하면 그냥 다음으로 넘어가면 됩니다. 이렇게 낮은 실패 비용은 에이전트가 더大胆한 아이디어를 시도하도록 장려합니다. 위의 코드를 한 줄씩 살펴보겠습니다. train_with_budget 함수는 budget_sec 매개변수로 시간 예산을 받습니다. 기본값은 300초, 즉 5분입니다. while 루프 안에서 매 스텝마다 현재 시간을 확인하고, 예산을 초과하면 즉시 종료합니다. 100스텝마다 경과 시간과 손실값을 출력하여 학습 진행 상황을 모니터링합니다. 마지막으로 학습된 모델과 총 스텝 수를 반환합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 새로운 어텐션 메커니즘을 테스트한다고 가정해봅시다. full 데이터셋에서 학습하는 대신, 데이터의 1%만 샘플링하고 모델도 작게 만들어 5분 안에 학습이 완료되도록 설정합니다. 5분짜리 실험 50번을 돌려서 가장 유망한 3개의 아이디어를 찾은 뒤, 최종 후보만 full 데이터로 긴 학습을 돌립니다. 이렇게 하면 시간을 효율적으로 사용할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 5분 결과를 그대로 최종 결과로 받아들이는 것입니다. 5분 타임 버짓은 방향성을 확인하는 용도이지, 최종 성능을 보장하는 것이 아닙니다. 따라서 5분 실험에서 찾은 유망한 아이디어를 full-scale 학습으로 검증하는 후속 과정이 반드시 필요합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 5분 타임 버짓의 철학을 이해한 김개발 씨는 고개를 끄덕였습니다. "빠르게 실패하고, 빠르게 배우는 거군요. 애자일의 핵심이네요." 5분 타임 버짓은 단순한 시간 제한이 아닙니다. 연구의 패러다임을 바꾸는 설계 철학입니다. 긴 실험 하나에 모든 것을 거는 대신, 짧은 실험 여러 개로 다양성을 확보하고, 피드백의 속도를 높입니다. 다음으로는 이 짧은 시간 안에 어떻게 결과를 평가하는지 살펴보겠습니다.
팁
- 5분 타임 버짓은 "방향 탐색"용이며, 최종 검증은 더 긴 학습으로 수행합니다
- 예산(budget)이 클수록 더 많은 탐색이 가능하지만, 총 실제 시간도 늘어납니다
- 이 철학은 ML 연구뿐만 아니라, 빠른 프로토타이핑이 필요한 모든 분야에 적용할 수 있습니다
5. val bpb 평가 메트릭
"성능이 좋아졌는지 어떻게 알아?" 김개발 씨의 질문에 박시니어 씨는 정말 중요한 지표를 하나 꺼냈습니다. "이 프로젝트에서는 val_bpb라는 지표를 사용해. 이게 뭐냐면..." 김개발 씨는 메모장을 꺼내 준비했습니다.
**val_bpb(Validation Bits Per Byte)**는 모델이 검증 데이터를 얼마나 잘 압축하는지를 측정하는 지표입니다. 모델이 다음 바이트를 예측할 때 평균적으로 몇 비트의 정보가 필요한지를 나타내며, 값이 낮을수록 모델의 예측 성능이 뛰어나다는 의미입니다. 마치 압축 프로그램이 파일을 얼마나 작게 만드는지 나타내는 압축률과 같습니다.
# val_bpb 계산의 핵심 로직
import torch
import torch.nn.functional as F
def compute_val_bpb(model, val_data, device):
"""검증 셋에서 Bits Per Byte를 계산합니다"""
model.eval()
total_bpb, total_bytes = 0.0, 0
with torch.no_grad():
for batch in val_data:
logits = model(batch[:, :-1].to(device)) # 입력 시퀀스
targets = batch[:, 1:].to(device) # 타겟 시퀀스
# 크로스 엔트로피를 바이트 단위로 변환
loss = F.cross_entropy(
logits.reshape(-1, logits.size(-1)),
targets.reshape(-1)
)
total_bpb += loss.item() * targets.numel()
total_bytes += targets.numel()
return total_bpb / total_bytes / 8 # 비트를 바이트로 변환
val_bpb는 검증 데이터에서 모델이 다음 바이트를 예측하는 데 필요한 평균 비트 수입니다. 값이 낮을수록 모델이 데이터를 더 잘 이해하고 있다는 의미이며, AutoResearch는 이 지표로 실험의 성공 여부를 판단합니다.
상세 설명
김개발 씨는 모델 성능을 평가할 때 보통 정확도(Accuracy)나 F1 점수를 사용했습니다. 하지만 AutoResearch에서는 처음 보는 지표가 등장했습니다. val_bpb. 이게 뭘까요? 박시니어 씨는 이 지표를 이해하려면 정보 이론의 기본 개념을 알아야 한다고 설명했습니다. 그렇다면 val_bpb란 정확히 무엇일까요? 쉽게 비유하자면, val_bpb는 마치 퀴즈 프로그램의 정답 힌트 비용과 같습니다. 다음 단어가 뭔지 맞출 때, 몇 개의 yes/no 질문이 필요한지를 측정하는 것입니다. 1비트라면 동전 던지기 한 번이면 되니까 아주 예측하기 쉬운 단어입니다. 8비트면 완전히 랜덤한 추측이 필요하다는 뜻입니다. 즉, val_bpb가 낮다는 건 모델이 다음 토큰을 잘 예측하고 있다는 의미입니다. 왜 하필 bits per byte를 사용할까요? LLM 학습에서 가장 흔히 사용하는 지표는 cross-entropy loss입니다. 하지만 cross-entropy는 토큰화 방식에 따라 값이 달라집니다. BPE 토크나이저를 쓰면 값이 다르고, byte-level 토크나이저를 쓰면 또 다릅니다. 이런 불일치를 해결하기 위해 바이트 단위로 정규화한 것이 val_bpb입니다. 8로 나누어 바이트당 비트 수로 변환하므로, 토큰화 방식에 상관없이 공정하게 비교할 수 있습니다. 바로 이런 이유로 val_bpb가 AutoResearch의 핵심 평가 지표가 되었습니다. val_bpb는 에이전트에게 명확한 목표를 제공합니다. "이전 실험보다 val_bpb가 낮아졌는가?"라는 단순한 질문에 답할 수 있으므로, 에이전트가 실험의 성공 여부를 스스로 판단할 수 있습니다. 이는 자율 연구 에이전트가 작동하기 위한 필수 조건입니다. 객관적이고 계산 가능한 평가 기준이 있어야 에이전트가 피드백 루프를 돌릴 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 model.eval()로 모델을 평가 모드로 전환합니다. dropout이나 batch norm 등 학습 시에만 적용되는 동작을 비활성화합니다. torch.no_grad() 컨텍스트 안에서 기울기 계산을 비활성화하여 메모리를 절약합니다. logits는 모델이 예측한 확률 분포이고, targets는 실제 정답입니다. F.cross_entropy로 손실을 계산한 뒤, 총합을 누적합니다. 마지막으로 8로 나누어 바이트 단위로 변환합니다. 이 값이 바로 val_bpb입니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 두 가지 모델 아키텍처를 비교한다고 가정해봅시다. 모델 A의 val_bpb가 1.45이고, 모델 B의 val_bpb가 1.38이라면, 모델 B가 검증 데이터를 더 잘 압축한다는 의미입니다. 즉, 모델 B가 데이터의 패턴을 더 잘 학습했다는 뜻입니다. AutoResearch 에이전트는 이렇게 각 실험의 val_bpb를 비교하여 가장 좋은 구성을 찾아냅니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 train loss만 보고 판단하는 것입니다. train loss가 낮아도 val_bpb가 높으면 **과적합(Overfitting)**일 가능성이 큽니다. 항상 검증 셋에서의 val_bpb를 확인해야 합니다. 또한 val_bpb가 너무 낮으면 검증 데이터에 과적합된 것일 수 있으므로, 학습 곡선을 함께 확인하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. val_bpb의 의미를 이해한 김개발 씨는 메모장에 적었습니다. "낮을수록 좋다. 바이트 단위로 정규화되어서 공정한 비교가 가능하다." val_bpb는 AutoResearch의 실험 루프를 가능하게 하는 핵심 요소입니다. 객관적이고 계산 가능한 평가 기준이 있어야 에이전트가 "이번 실험은 성공이다" 혹은 "이번 실험은 실패다"라고 판단할 수 있습니다. 다음으로는 이 평가 기준을 바탕으로 에이전트가 어떻게 실험 루프를 돌리는지 살펴보겠습니다.
팁
- val_bpb = cross_entropy_loss / 8 (비트를 바이트로 변환)
- 토큰화 방식과 무관하게 비교 가능한 것이 val_bpb의 가장 큰 장점입니다
- 항상 검증 셋에서 측정해야 하며, 학습 셋의 loss와 검증 셋의 val_bpb를 함께 모니터링하세요
6. 실험 루프: 수정-학습-평가-유지/폐기
드디어 AutoResearch의 핵심, 실험 루프를 살펴볼 차례입니다. 김개발 씨는 화이트보드 앞에 섰습니다. 박시니어 씨가 사각형을 하나 그리고, 안에 네 개의 단계를 적었습니다. "수정, 학습, 평가, 유지 또는 폐기. 이 루프가 전부야."
실험 루프는 에이전트가 연구를 진행하는 핵심 사이클입니다. 현재 코드를 수정하고, 5분 동안 학습을 실행한 뒤, val_bpb로 평가합니다. 결과가 좋으면 그 구성을 유지하고, 나쁘면 이전 구성으로 폐기합니다. 마치 진화 알고리즘에서 더 나은 개체를 선택하고, 열등한 개체를 도태하는 과정과 같습니다.
# 실험 루프의 핵심 - 유지 또는 폐기 결정
def experiment_loop(agent, base_program, budget):
best_score = float('inf')
best_config = None
for i in range(budget):
modified = agent.modify(base_program) # 1. 수정
result = train_5min(modified) # 2. 학습 (5분)
score = compute_val_bpb(result) # 3. 평가
if score < best_score: # 4. 유지
best_score = score
best_config = modified
base_program = modified # 새 기준점으로 업데이트
print(f"[유지] 실험 {i}: val_bpb={score:.4f}")
else: # 4. 폐기
print(f"[폐기] 실험 {i}: val_bpb={score:.4f}")
return best_config, best_score
실험 루프는 코드 수정, 5분 학습, val_bpb 평가, 결과에 따른 유지 또는 폐기의 네 단계로 구성됩니다. 이전보다 나은 결과가 나오면 유지하고, 그렇지 않으면 폐기하여 점진적으로 최적의 구성을 찾아냅니다.
상세 설명
김개발 씨는 대학원 시절 논문 실험을 하며 비슷한 루프를 경험한 적이 있었습니다. 아이디어를 내고, 코드를 고치고, 학습을 돌리고, 결과를 확인합니다. 좋으면 기록하고, 나쁘면 다시 생각합니다. 하지만 이 과정을 직접 하려면 며칠이 걸렸습니다. AutoResearch는 이 루프를 자동화합니다. 박시니어 씨는 이 루프를 **"자연 선택의 소프트웨어 버전"**이라고 불렀습니다. 그렇다면 실험 루프란 정확히 무엇일까요? 쉽게 비유하자면, 실험 루프는 마치 자연 선택과 진화와 같습니다. 생물이 환경에 적응하기 위해 돌연변이를 일으키고, 환경이 그 돌연변이를 평가합니다. 유리한 변이는 살아남고, 불리한 변이는 도태됩니다. AutoResearch도 같습니다. 에이전트가 코드에 "돌연변이"를 일으키고(수정), 환경이 평가하며(학습+평가), 유리한 변이는 유지됩니다. 이 루프가 중요한 이유는 무엇일까요? 첫째, **점진적 개선(Incremental Improvement)**이 가능합니다. 한 번에 완벽한 해결책을 찾는 것은 불가능합니다. 하지만 매번 조금씩 더 나은 결과를 찾으면, 수십 번의 반복 후에는 처음보다 훨씬 좋은 결과에 도달할 수 있습니다. 둘째, 자동 회복(Automatic Recovery) 기능이 있습니다. 어떤 수정이 결과를 악화시키면, 이전 구성으로 자동 되돌아갑니다. 즉, 에이전트가 실수해도 괜찮습니다. 안전망이 항상 켜져 있으니까요. 셋째, 탐색과 활용의 균형이 자연스럽게 이루어집니다. 좋은 결과가 나올 때는 그 방향을 유지하며 더 깊이 파고들고(활용), 정체되면 새로운 방향을 시도합니다(탐색). 위의 코드를 한 줄씩 살펴보겠습니다. best_score는 지금까지의 최고 val_bpb를 기록합니다. 초기값은 무한대로 설정하여 어떤 결과든 처음에는 받아들이게 합니다. agent.modify()에서 에이전트가 프로그램을 수정합니다. train_5min()으로 5분 동안 학습을 실행합니다. compute_val_bpb()로 결과를 평가합니다. 핵심은 if score < best_score 부분입니다. 이전보다 val_bpb가 낮으면 유지하고, base_program을 새 기준점으로 업데이트합니다. 그렇지 않으면 폐기하고 기존 기준점을 유지합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 GPT 모델의 dropout 비율을 최적화한다고 가정해봅시다. 에이전트가 첫 번째 실험에서 dropout을 0.1로 설정하면 val_bpb가 1.50이 나왔습니다. 두 번째 실험에서 0.05로 낮추니 1.47로 개선되었습니다. 세 번째에서 0.0으로 없애니 1.52로 악화되었습니다. 에이전트는 자동으로 0.05로 되돌리고, 다음에는 다른 하이퍼파라미터를 탐색합니다. 이런 식으로 최적의 dropout을 찾아냅니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 초반의 작은 개선에 너무 매몰되는 것입니다. val_bpb가 1.50에서 1.49로 0.01 개선되었다고 해서, 그 방향만 계속 파고들면 **지역 최적해(Local Optimum)**에 빠질 수 있습니다. 때로는 val_bpb가 잠시 악화되더라도 완전히 다른 방향을 시도하는 것이 더 큰 개선으로 이어질 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 실험 루프의 네 단계를 이해한 김개발 씨는 깨달았습니다. "결국 진화의 원리를 코드로 구현한 거네요. 작은 변이가 누적되면 큰 변화가 되는." 실험 루프는 AutoResearch의 심장입니다. 이 루프가 계속 돌아가는 한, 에이전트는 점진적으로 더 나은 결과를 찾아냅니다. 수정, 학습, 평가, 유지 또는 폐기. 이 단순한 사이클이 AI 자율 연구의 전부입니다. 마지막으로 이 시스템이 어떤 결과물을 만들어내는지 살펴보겠습니다.
팁
- 유지/폐기 결정은 오직 val_bpb 기준이므로, 이 지표의 신뢰성이 매우 중요합니다
- base_program을 계속 업데이트하므로, 나중의 실험일수록 더 개선된 상태에서 시작합니다
- 지역 최적해를 피하려면 에이전트가 가끔 "무작위적"인 탐색도 할 수 있어야 합니다
7. nanochat과의 관계
"이걸로 뭘 만들 수 있데요?" 김개발 씨의 마지막 질문이었습니다. AutoResearch로 자율 연구를 한 결과, 실제로 사용할 수 있는 무언가가 나오는 걸까요? 박시니어 씨는 하나의 단어를 말했습니다. "nanochat."
nanochat은 AutoResearch를 통해 탄생한 초소형 챗봇 모델입니다. 에이전트가 자율적으로 탐색한 최적의 구성으로 학습된 이 모델은, 이름 그대로 나노(nano) 크기이면서도 실제 대화가 가능한 수준의 성능을 보여줍니다. 마치 작은 연구실에서 만들어진 프로토타입 자동차가 실제로 도로를 달리는 것과 같습니다.
# nanochat 모델 추론의 핵심 구조
import torch
def nanochat_generate(model, tokenizer, prompt, max_tokens=256, temperature=0.8):
"""nanochat 모델로 텍스트를 생성합니다"""
input_ids = tokenizer.encode(prompt)
generated = input_ids.copy()
for _ in range(max_tokens):
x = torch.tensor([generated], dtype=torch.long)
logits = model(x)[:, -1, :] # 마지막 토큰의 로짓
logits = logits / temperature # 온도 스케일링
next_token = torch.multinomial(
torch.softmax(logits, dim=-1), num_samples=1
)
generated.append(next_token.item())
return tokenizer.decode(generated)
nanochat은 AutoResearch가 자율적으로 탐색한 최적 구성으로 만들어진 초소형 챗봇 모델입니다. 연구 에이전트의 산출물이 실제 동작하는 대화형 AI로 구현된 사례를 보여줍니다.
상세 설명
김개발 씨에게 AutoResearch는 흥미로운 개념이었지만, 한 가지 의문이 남았습니다. "이 자율 연구 시스템으로 실제로 뭔가를 만들어낸 건가요?" 이론적인 연구가 아니라, 실제 결과물이 있는지 궁금했습니다. 박시니어 씨는 자신의 노트북에서 터미널을 열었습니다. 그리고 nanochat을 실행했습니다. 화면에 한국어 대화가 주고받히기 시작했습니다. 그렇다면 nanochat이란 정확히 무엇일까요? 쉽게 비유하자면, nanochat은 마치 자동차 공학의 프로토타입과 같습니다. F1 레이싱카가 아닙니다. 하지만 엔진이 있고, 바퀴가 있고, 실제로 도로를 달릴 수 있습니다. AutoResearch는 이 프로토타입을 자율적으로 설계하고 제작했습니다. 거대한 연구팀이 수개월에 걸쳐 만드는 것을, 에이전트가 단일 GPU에서 완성한 것입니다. nanochat이 중요한 이유는 무엇일까요? 첫째, **개념 증명(Proof of Concept)**입니다. AI가 자율적으로 연구해서 "실제로 작동하는 모델"을 만들 수 있다는 것을 처음으로 보여주었습니다. 이는 AI 연구의 새로운 패러다임을 열었다는 의미가 있습니다. 둘째, 학습의 산출물입니다. 이 코스에서 배울 모든 기술이 nanochat이라는 하나의 결과물로 수렴합니다. GPT 모델 구조, Muon+AdamW 최적화, Flash Attention, 임베딩 기법들이 모두 이 작은 모델 안에 녹아있습니다. 셋째, 확장 가능한 기반입니다. nanochat은 작은 모델이지만, 여기서 발견된 최적의 구성은 더 큰 모델로도 확장할 수 있습니다. 5분 타임 버짓에서 찾은 인사이트가 실제 상용 모델 개발에도 적용될 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. nanochat_generate 함수는 프롬프트를 받아 모델이 텍스트를 생성하도록 합니다. input_ids로 프롬프트를 토큰 ID로 변환합니다. 루프 안에서 모델에 입력을 넣고, 마지막 토큰의 로짓만 가져옵니다([:, -1, :]). temperature로 확률 분포의 날카로움을 조절합니다. 낮으면 보수적이고, 높으면 창의적입니다. torch.multinomial으로 다음 토큰을 샘플링하여 generated에 추가합니다. 이 과정을 max_tokens만큼 반복합니다. 이 코스의 앞으로의 여정을 정리해봅시다. 지금까지 AutoResearch의 전체 개요를 살펴봤습니다. 자율 연구 에이전트의 개념, 3파일 구조, 5분 타임 버짓, val_bpb 평가 지표, 실험 루프, 그리고 nanochat이라는 결과물까지. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 개요만 보고 구현을 시도하는 것입니다. AutoResearch를 제대로 이해하려면 각 구성 요소의 내부 동작을 깊이 파악해야 합니다. 그래서 이 코스에서는 다음 7개의 카드뉴스에 걸쳐 하나씩 자세히 다룹니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨와의 대화를 마친 김개발 씨는 노트를 정리했습니다. AutoResearch의 큰 그림은 이해했습니다. 이제 각 부분을 하나씩 깊이 파고들 차례입니다. 이 코스의 앞으로의 여정은 이렇습니다. GPT 모델 구조에서 시작하여, Muon+AdamW 최적화, Flash Attention 3, Value Embeddings(ResFormer), Rotary Embeddings, 그리고 실험 루프의 심화 분석까지. 마지막으로 모든 것을 종합하는 카드뉴스로 마무리됩니다. 여러분도 김개발 씨와 함께 이 흥미로운 여정을 떠나보시죠.
팁
- nanochat은 AutoResearch의 "증명"입니다. 개념이 아니라 실제 작동하는 결과물입니다
- 이 코스의 모든 카드뉴스가 nanochat을 완성하기 위한 기술들을 다룹니다
- 개요를 이해한 후, 다음 카드뉴스에서 GPT 모델 구조의 세부 사항을 살펴보세요
댓글 (0)
함께 보면 좋은 카드 뉴스
Flash Attention 3과 Rotary Embeddings 완벽 분석
AutoResearch 프로젝트의 train.py에 구현된 Flash Attention 3 커널 선택 로직, Rotary Position Embeddings(RoPE)의 수학적 원리와 구현, 그리고 Sliding Window Attention 패턴을 심도 있게 분석합니다.
GPT 모델 아키텍처 완벽 분석 - CausalSelfAttention부터 GPT까지
AutoResearch의 train.py에 구현된 GPT 모델 아키텍처를 상세 분석합니다. GPTConfig 데이터클래스부터 CausalSelfAttention, MLP, Block, GPT 클래스까지 전체 구조와 가중치 초기화 전략을 다룹니다.
파일 입출력에서 with문 사용하기 완벽 가이드
Python에서 파일을 안전하게 다루는 with문의 모든 것을 알아봅니다. 파일 자동 닫기부터 예외 처리까지, 실무에서 반드시 알아야 할 핵심 개념을 이북처럼 술술 읽히는 스타일로 정리했습니다.
프로덕션 에이전트 구축 완벽 가이드
실무에서 바로 활용할 수 있는 프로덕션급 AI 에이전트 구축 방법을 처음부터 끝까지 다룹니다. 아키텍처 설계부터 배포, 모니터링까지 실전 경험을 담은 완벽 가이드입니다.
vLLM 통합 완벽 가이드
대규모 언어 모델 추론을 획기적으로 가속화하는 vLLM의 설치부터 실전 서비스 구축까지 다룹니다. PagedAttention과 연속 배칭 기술로 GPU 메모리를 효율적으로 활용하는 방법을 배웁니다.