세미나 · 특별편

AutoResearch 심층 분석

Karpathy 의 AutoResearch 가 컨텍스트 엔지니어링과 하네스 엔지니어링을 결합해 작동하는 원리, AI Builds AI 생태계, 그리고 직접 실행하는 실습까지 — 55개 소스 기반 40–60분 세미나 자료입니다.

2026년 3월, Andrej Karpathy(전 Tesla AI 총괄, OpenAI 창립 멤버)가 630줄의 파이썬 스크립트를 GitHub 에 올리고 잠자리에 들었습니다. 이 스크립트는 작은 언어 모델(GPT-2 수준)을 학습시키는 코드였습니다. 아침에 일어나니 AI 에이전트가 밤새 700번의 실험을 돌려 20가지 개선점을 발견해 놓았습니다. Karpathy 본인이 수개월간 손으로 튜닝하면서 놓친 버그까지 찾아냈습니다.

이 이야기는 단순한 자동화가 아닙니다. AI 가 스스로 코드를 고치고, 결과를 측정하고, 좋아졌으면 유지하고 나빠졌으면 되돌리는 과정을 쉬지 않고 반복한 것입니다. 이러한 시도→측정→개선의 반복 구조를 이 글에서는 목표달성 루프라 부릅니다. 이 글은 그 루프가 어떻게 작동하고, 왜 효과가 있으며, 어디까지 확장될 수 있는지 전체 지도를 그립니다.

패러다임의 전환 — 바이브에서 하네스까지

AI 를 활용한 소프트웨어 개발은 18개월 만에 세 번의 패러다임 전환을 겪었습니다. 2025년 초만 해도 대부분의 개발자는 ChatGPT 나 Copilot 에 코드 조각을 요청하고, 결과를 복사-붙여넣기하는 수준이었습니다. 그러나 2025년 말부터 Claude Code, Cursor, Codex 같은 코딩 에이전트가 등장하면서 “에이전트에게 작업을 맡기고, 인간은 감독한다” 는 패턴이 빠르게 확산되었습니다. 문제는 에이전트가 장시간 작업할수록 초기 규칙을 점점 잊어버리거나(Context Drift — 대화가 길어지면 처음 지시를 놓치는 현상), 에러가 나면 엉뚱한 방향으로 폭주하거나, 심지어 평가 기준 자체를 속이는(Reward Hacking — 점수를 올리기 위해 정당하지 않은 편법을 쓰는 행위) 행동이 발생한다는 것이었습니다. 이 구조적 문제를 해결하기 위해 하네스 엔지니어링이 등장했습니다.

“루프 밖”이란 인간이 AI 출력을 받아서 직접 판단하는 위치이고, “루프 안”이란 인간이 에이전트와 함께 작업 과정에 참여하는 위치입니다. “루프 위”란 인간이 직접 코드를 쓰거나 감독하는 대신, 에이전트가 작동하는 환경 자체(규칙, 테스트, 피드백 장치)를 설계하는 위치를 뜻합니다.

Mitchell Hashimoto(Terraform 창시자)가 명명한 하네스 엔지니어링의 핵심 원칙은 한 줄입니다 — “에이전트가 실수할 때마다, 다시는 그 실수를 반복하지 못하도록 시스템을 설계하라.”

AutoResearch — 목표달성 루프의 원형

공식 레포: github.com/karpathy/autoresearch (75k+ stars). 630줄 Python + 1개 마크다운 파일. 단일 NVIDIA GPU, Python 3.10+, uv. Fortune 지는 이 방법론을 “The Karpathy Loop” 이라 명명했습니다.

3-파일 아키텍처

AutoResearch 의 설계에서 가장 영리한 부분은 “누가 무엇을 수정할 수 있는가”를 파일 단위로 엄격히 분리한 것입니다. 이 분리가 중요한 이유는 세 가지입니다. 첫째, 에이전트가 채점 기준을 고쳐서 점수를 부풀리는 부정행위(학생이 시험 답안지의 채점 기준을 바꾸는 것과 같습니다)를 구조적으로 차단합니다. 둘째, 에이전트가 건드릴 수 있는 범위를 630줄 단일 파일로 한정합니다. 현재 AI 는 한 번에 읽을 수 있는 분량에 한계가 있는데, 630줄은 그 한계 안에 여유 있게 들어오므로 AI 가 전체 코드를 빠짐없이 파악할 수 있습니다. 셋째, 인간의 역할을 “코드를 직접 쓰는 것”에서 “방향과 전략을 정하는 것”으로 전환시킵니다.

인간은 .md 를 프로그래밍하고, 에이전트는 .py 를 프로그래밍합니다.

9단계 실행 루프

program.md 에 정의된 실행 루프는 코드가 아니라 영어 문장으로 적혀 있습니다. 에이전트는 이 파일을 읽고 지시를 따릅니다. 특별한 데이터베이스나 복잡한 기억 장치가 필요 없습니다 — 에이전트는 Git(코드 변경 이력을 추적하는 도구)의 기록을 보고 “이전에 무엇이 효과가 있었는지”를 파악하고,results.tsv파일(실험 결과를 한 줄씩 기록한 표)을 보고 “이미 시도한 것”을 확인합니다. 아침에 일어나면 성공한 변경만 남은 깨끗한 코드와, 실패를 포함한 전체 실험 이력이 기다리고 있습니다.

1. program.md 읽기 → 연구 우선순위 파악
2. train.py + results.tsv 검토
3. 가설 제안 (아키텍처 / 옵티마이저 / 학습)
4. train.py 수정
5. git commit
6. 5분간 학습 실행 (고정 벽시계 시간)
7. 실패 시 → 로그 확인, 수정 또는 포기
8. val_bpb + 메모리 측정, results.tsv 기록
9. 개선됨? → git keep | 안 됨? → git reset HEAD~1

이 루프는 무한 반복됩니다. 시간당 약 12회, 하룻밤에 약 100회 실험이 실행됩니다.

실제 소스코드 — program.md 핵심 발췌

**What you CAN do:**
- Modify train.py — this is the only file you edit.
  Everything is fair game: architecture, optimizer,
  hyperparameters, training loop, batch size, model size.

**What you CANNOT do:**
- Modify prepare.py. It is read-only.
- Install new packages or add dependencies.
- Modify the evaluation harness.

**Simplicity criterion**: simpler is better.
A 0.001 val_bpb improvement that adds 20 lines of
hacky code? Probably not worth it.
A 0.001 improvement from deleting code? Definitely keep.

**NEVER STOP**: The human might be asleep.
You are autonomous. If you run out of ideas,
think harder — read papers referenced in the code,
try combining previous near-misses,
try more radical architectural changes.
The loop runs until the human interrupts you, period.

실제 소스코드 — train.py GPTConfig

from prepare import (MAX_SEQ_LEN, TIME_BUDGET,
                     Tokenizer, make_dataloader, evaluate_bpb)

@dataclass
class GPTConfig:
    sequence_len: int = 2048
    vocab_size: int = 32768
    n_layer: int = 12      # ← 에이전트가 변경 가능
    n_head: int = 6
    n_kv_head: int = 6
    n_embd: int = 768
    window_pattern: str = "SSSL"  # S=Sliding, L=Full

from prepare import ... evaluate_bpb — 평가 함수는 prepare.py 에서 import 합니다. 수정 금지의 신뢰 경계입니다. 전체 630줄이 단일 파일이므로 LLM 컨텍스트 윈도우 안에서 전체 흐름을 한눈에 파악할 수 있습니다.

val_bpb — 왜 이 메트릭인가

val_bpb(validation bits-per-byte)는 “모델이 텍스트를 얼마나 효율적으로 압축하는가”를 측정하는 점수입니다. 비유하면, 100페이지짜리 책을 ZIP 파일로 압축할 때 얼마나 작아지는지를 재는 것과 비슷합니다. 잘 이해한 텍스트일수록 더 작게 압축할 수 있으므로, val_bpb 숫자가 낮을수록 좋은 모델입니다.

왜 다른 점수(loss, perplexity)가 아니라 val_bpb 를 선택했을까요? AI 모델은 텍스트를 처리할 때 먼저 글자를 “토큰”이라는 조각으로 나눕니다. 예를 들어 “안녕하세요”를 [안녕, 하세요]로 나눌 수도 있고 [안, 녕, 하, 세, 요]로 나눌 수도 있습니다. 일반적인 loss 나 perplexity 는 이 토큰 단위로 계산되기 때문에, 나누는 방식이 바뀌면 점수도 바뀝니다. 에이전트가 토큰 분리 방식을 바꾸면 점수가 올라간 것처럼 보이지만 실제로는 모델이 나아진 것이 아닙니다 — 자의 눈금만 바꾼 셈입니다. val_bpb 는 토큰이 아닌 바이트(원본 글자 데이터) 기준으로 측정하므로, 토큰 분리 방식과 무관합니다. 에이전트가 구조를 어떻게 바꾸든 같은 자로 공정하게 비교할 수 있습니다. 실제 코드에서도 prepare.py 에 evaluate_bpb 함수가 고정되어 있어 에이전트가 채점 기준을 건드릴 수 없습니다.

판단 기준도 극도로 단순합니다 — 숫자가 낮아지면 유지, 높아지면 되돌리기. 에이전트가 “이번 실험이 성공인지 실패인지” 헷갈릴 여지가 전혀 없습니다. 이 단순함이 야간 자율 실행의 핵심 전제입니다.

5분 고정 예산 — 왜 시간을 제한하는가

prepare.py 에는 TIME_BUDGET = 300(300초 = 5분)이 상수로 박혀 있습니다. 모든 실험이 똑같이 5분 동안 실행되므로, 어떤 설정이든 동일한 시간 안에서 직접 비교가 가능합니다.

이 제약이 왜 중요한지 구체적인 예로 설명하겠습니다. 큰 모델(1.6B 파라미터)은 한 번 계산하는 데 시간이 오래 걸립니다. 5분 안에 100번 학습할 수 있다고 가정하겠습니다. 반면 작은 모델(0.8B 파라미터)은 계산이 빠르므로 같은 5분 안에 500번 학습할 수 있습니다. 반복 횟수가 5배 많으면, 작은 모델이 더 많은 데이터에서 패턴을 배울 수 있습니다. Shopify CEO Tobi Lütke 가 이것을 직접 실험했습니다 — 에이전트가 밤새 37회 실험을 돌린 결과, 0.8B 모델이 수동으로 튜닝한 1.6B 모델을 19% 앞질렀습니다. 절반 크기의 모델이 더 좋은 성능을 낸 것은 “무조건 크면 좋다”는 상식이 아니라,주어진 GPU 와 시간 안에서 가장 효율적인 설정을 찾는 것이 핵심이라는 것을 보여줍니다. 5분 제약이 에이전트를 이 방향으로 강제한 것입니다.

700회 실험의 구체적 결과

Karpathy 는 12층짜리 nanochat 모델을 대상으로 이틀 동안 약 700회의 실험을 진행했습니다. 에이전트가 발견한 최적화 중 특히 주목할 만한 것은 QK-Norm 구현의 버그입니다. 어텐션 메커니즘(모델이 입력의 어떤 부분에 집중할지 결정하는 장치)에서 선명도를 조절하는 스칼라 승수가 빠져 있었습니다. 이 버그는 Karpathy 본인이 수개월간 직접 코드를 검토하면서도 놓친 것인데, 에이전트가 야간 실험 중에 발견했습니다. 이 사례가 중요한 이유는, 에이전트가 단순히 숫자(학습률, 배치 크기 등)를 이리저리 바꿔보는 수준이 아니라 코드 자체의 구조적 결함을 찾아낼 수 있다는 것을 보여주기 때문입니다.

Shopify CEO Tobi Lutke 의 적용 결과

쿼리 확장 모델(사용자가 검색어를 입력하면 관련 키워드를 자동으로 추가해 주는 AI) — Lütke 가 잠들기 전에 에이전트를 실행하고, 8시간 뒤 일어났을 때 37회 실험이 완료되어 있었습니다. 검증 점수가 19% 향상되었고, 에이전트가 최적화한 0.8B 모델이 수동 튜닝 1.6B 모델을 능가했습니다.

Liquid 템플릿 엔진(Shopify 의 모든 온라인 상점 페이지를 생성하는 핵심 소프트웨어) — 에이전트가 93번 코드를 자동으로 수정한 결과, 페이지 생성 속도가 53% 빨라지고, 메모리 사용량이 61% 줄었습니다.

왜 작동하는가 — 제약이 혁신입니다

AutoResearch 의 혁신은 에이전트의 지능이 아니라, 에이전트를 감싸는 제약의 탁월함입니다.

직관에 반하는 진실이 있습니다 — 에이전트의 자유를 제한할수록 생산성이 올라갑니다. AutoResearch 에서 에이전트가 할 수 있는 일은 딱 세 가지로 제한됩니다: (1) 630줄짜리 파일 하나만 수정할 수 있고, (2) 실험 한 번에 5분만 쓸 수 있고, (3) val_bpb 라는 숫자 하나만 낮추면 됩니다. 강력한 모델에게 절대적 자유를 주면 어떻게 될까요? 모델은 막대한 컴퓨팅을 사용해 쓸모없는 변형을 탐색하고, 불필요한 설정을 조정하고, 잘 작동하던 구조를 부수는 데 시간을 낭비합니다. 반대로, 선택지를 극단적으로 줄이면 — 모델은 남은 공간 안에서 정말로 의미 있는 개선에만 집중하게 됩니다.

AutoGPT 는 왜 실패하고 AutoResearch 는 왜 성공했는가

2023년에 등장한 AutoGPT 는 “자율적으로 작업을 수행하는 AI 에이전트” 라는 비전으로 큰 주목을 받았지만, 실제로는 대부분의 사용자가 유의미한 결과를 얻지 못했습니다. 핵심 원인은 에이전트에게 너무 많은 자유도를 부여한 것입니다. 인터넷 검색, 파일 생성, 코드 실행, 자기 프롬프트 수정까지 모두 가능하니, 에이전트는 방향을 잡지 못하고 같은 실패를 반복하거나 컨텍스트 윈도우를 소진했습니다. AutoResearch 는 이 모든 자유를 제거하고 “이 파일 하나만 수정하라, 이 숫자 하나만 낮춰라” 로 한정한 것입니다.

Fowler/Böckeler 프레임워크로 본 AutoResearch

Martin Fowler 사이트에 발표된 Birgitta Böckeler(ThoughtWorks)의 프레임워크는 에이전트를 통제하는 수단을 두 종류로 나눕니다 — 행동 전에 방향을 알려주는 가이드(Feedforward)와, 행동 후에 결과를 측정하여 되돌릴지 유지할지를 판단하는 센서(Feedback)입니다. AutoResearch 의 모든 구성 요소가 이 두 범주로 깔끔하게 분류됩니다.

AutoResearch 가 증명한 것: 가이드와 센서, 둘 중 하나만으로는 부족합니다. program.md(가이드)만 있고 prepare.py(센서)가 없다면 어떻게 될까요? 에이전트가 “개선되었다”고 스스로 판단하지만 실제로는 채점 기준을 우회한 것일 수 있습니다. 반대로 prepare.py 만 있고 program.md 가 없다면? 에이전트가 점수는 측정할 수 있지만 어떤 방향으로 개선해야 하는지 모르고 무작위로 탐색합니다. 둘이 결합되어야 — 방향을 알려주고, 결과를 기계적으로 측정하고, 실패하면 자동으로 되돌리는 — 인간이 자는 동안 700번 실험이 가능해집니다.

하네스 엔지니어링 — 왜 88%가 실패하는가

Gartner, McKinsey, IDC 의 조사를 교차 분석한 결과, AI 에이전트 프로젝트의 88%가 프로덕션에 도달하기 전에 실패합니다. 실패 원인은 모델의 지능 부족이 아니라, 하네스의 부재입니다 (miraflow.ai). 구체적으로 실패의 4대 원인은 다음과 같습니다. 첫째, 가이드 부재 — AGENTS.md 같은 방향 문서가 없어 에이전트가 매번 처음부터 추측합니다. 둘째, 센서 부재 — 에이전트의 출력을 자동으로 검증하는 장치(테스트, 린터, 빌드 검사)가 없어 오류가 조용히 누적됩니다. 셋째, 늦은 거버넌스 — 데모 환경에서는 잘 작동하지만, 프로덕션의 복잡성(동시 요청, 예외 상황, 보안)을 만나면 무너집니다. 넷째, 과잉 엔지니어링 — 반대로 제약을 너무 많이 걸면 에이전트가 유의미한 작업을 할 여지가 없어집니다.

LangChain Terminal Bench — 하네스의 증거

이 주장이 과장이 아니라는 것을 가장 극적으로 증명한 사례가 LangChain 의 Terminal Bench 실험입니다. Terminal Bench 2.0 은 ML, 디버깅, 생물학 등 89개 작업으로 구성된 코딩 에이전트 벤치마크입니다. LangChain 팀은 모델을 gpt-5.2-codex로 고정한 채, 하네스만 개선했습니다. 자가 검증 루프(에이전트가 종료를 선언하기 전에 반드시 테스트를 실행하도록 강제), 둠 루프 감지(같은 파일을 N 번 수정하면 접근 방식 재고를 주입), 그리고 추론 예산 관리(계획과 검증에는 높은 추론, 중간 실행에는 낮은 추론)를 적용했습니다. 결과: 52.8% → 66.5% (+13.7 포인트), 순위 30위 → 5위.

같은 모델. 다른 하네스. 극적으로 다른 결과.

OpenAI Codex 100만 줄 실험

OpenAI 내부 팀이 5개월간 수행한 이 실험은 하네스 설계의 위력을 가장 극적으로 보여줍니다. 소규모 엔지니어 팀이 거대한 프롬프트 대신 저장소 자체를 진실의 원천(Source of truth)으로 활용했습니다. 엔지니어는 코드를 직접 쓰는 대신, 의도를 명확히 정의하고 구조화된 피드백을 제공하는 역할을 맡았습니다. Codex 에이전트가 코드를 작성하고, 테스트를 생성하고, PR 을 열고, 변경 사항을 검증하는 과정을 자율적으로 반복했습니다. 아키텍처 경계(Types → Config → Repo → Service → Runtime → UI)를 린터와 구조적 테스트로 기계적으로 강제하되, 각 계층 안에서의 구현은 에이전트에게 자유를 주었습니다. 코드가 쌓이면서 불필요한 코드가 늘어나는 것을 막기 위해 가비지 컬렉션 전담 에이전트도 도입했습니다 (InfoQ).

생성과 검토의 비대칭

AI 는 코드를 쓸 때와 검토할 때 전혀 다른 성능을 보입니다. “Broken by Default” 연구(arXiv 2604.05292)는 7개 주요 LLM 이 5개 CWE(보안 취약점 분류) 카테고리에서 생성한 코드 3,500개를 수학적 증명 도구(Z3 솔버)로 검증했습니다. 결과는 놀랍습니다 — AI 는 코드를 쓸 때 55.8%의 보안 취약점을 만들지만, 같은 AI 에게 “이 코드에 문제가 있는가?”라고 물으면 78.7%를 정확히 찾아냅니다. 즉, AI 는 안전한 코드를 쓸 능력은 있지만 쓰는 순간에는 그 능력을 발휘하지 못합니다.

왜 이런 비대칭이 발생할까요? AI 가 코드를 쓸 때는 “자연스럽고 간결한 코드”를 우선하지만, 검토 역할을 맡으면 “보안 패턴 매칭”에 집중하기 때문입니다 — 같은 모델이라도 프롬프트(역할)가 바뀌면 주목하는 패턴이 달라집니다. 코드를 쓰는 역할과 검토하는 역할을 분리하는 것이 하네스에서 필수적인 이유입니다.

더 충격적인 것은 ESLint, Bandit 같은 기존 정적 분석 도구의 탐지율이 2.2%에 불과하다는 점입니다. 이 도구들은 AI 가 등장하기 전부터 코드 품질을 지키는 1차 방어선이었는데, AI 가 생성하는 새로운 유형의 취약점 앞에서는 97.8%를 놓칩니다. 그래서 하네스에는 두 가지 방어선이 모두 필요합니다 — AutoResearch 의 prepare.py 처럼 코드가 자동으로 채점하는 장치와, AI 에게 “방금 네가 쓴 코드를 검토하라”고 지시하는 역할 분리 장치입니다. 같은 AI 라도 “코드를 쓰는 역할”에서 “코드를 검토하는 역할”로 바꾸기만 하면 78.7%의 취약점을 스스로 걸러낼 수 있습니다.

LangChain Deep Agents — 독립적 수렴의 증거

흥미로운 점은, AutoResearch 와 LangChain 이 독립적으로 같은 결론에 도달했다는 것입니다. LangChain 의 하네스 엔지니어링 블로그(2026.2.17)는 AutoResearch(2026.3.7) 보다 약 3주 먼저발표되었습니다. 두 프로젝트는 서로를 참조하지 않았지만, 동일한 원리 — “모델이 아니라 하네스가 성능을 결정한다” — 에 수렴했습니다.

LangChain 의 Deep Agents는 2025년 7월에 최초 공개된 범용 에이전트 하네스로, Harrison Chase 가 Claude Code 의 핵심 패턴을 분석하여 만들었습니다. 2026년 3월 메이저 업데이트에서 5시간 만에 9.9k stars 를 기록했으며, 현재 21k+ stars 입니다. LangChain 은 자사 생태계를 세 계층으로 공식 구분합니다 — LangChain(프레임워크), LangGraph(런타임), Deep Agents(하네스).

Harrison Chase 가 Claude Code 에서 영감을 받아 도입한 핵심 패턴은 세 가지입니다. 첫째, Todo 도구를 아무것도 안 하게 만듭니다. Claude Code 의 write_todos도구는 실제로 어디에 저장하지 않습니다 — AI 가 “할 일 목록을 쓴다”는 행위 자체가 대화 맥락 안에 체계적인 계획을 남기는 것이 목적입니다. 마치 시험 전에 풀이 계획을 먼저 적으면 실수가 줄어드는 것과 같습니다. 둘째, 파일시스템을 공유 작업 공간으로 활용합니다. 에이전트가 임시 파일에 중간 결과를 쓰고, 서브에이전트가 그 파일을 읽는 방식으로 컨텍스트 윈도우의 한계를 우회합니다. 메모리가 아니라 디스크가 에이전트 간 통신 채널이 됩니다. 셋째, 대화가 길어지면 자동으로 요약합니다. AI 가 기억할 수 있는 분량(컨텍스트 윈도우)이 포화에 가까워지면, 과거 대화를 자동 압축하여 최신 내용만 남깁니다. 이 세 패턴이 결합되면 에이전트가 수 시간 동안 맥락을 잃지 않고 작업을 지속할 수 있습니다.

State of Agent Engineering 2026

LangChain 의 1,340명 대상 서베이 결과, 에이전트 프로덕션 배포율은 57.3%로 전년(51%) 대비 상승했습니다. 품질이 최대 장벽(32%)이며, 비용은 오히려 하락했습니다. 관측성(observability) 도입률은 89%에 도달했습니다. 10,000명 이상 조직에서는 67%가 이미 프로덕션에 에이전트를 운영 중입니다 (langchain.com).

AI Builds AI — 자기개선 생태계

AutoResearch 도메인 적용 — ML 을 넘어서

자기개선 AI 프레임워크 비교

AI Scientist-v2 — 에이전트 기반 트리 탐색으로 논문 작성

Sakana AI 의 AI Scientist-v2 는 AutoResearch 의 단일 루프를 에이전트 기반 트리 탐색(agentic tree search)으로 확장합니다. 하나의 가설에서 시작하여 여러 갈래로 분기하고, 각 갈래의 실험 결과를 평가하여 가장 유망한 경로를 깊이 탐색합니다. 실험 결과를 바탕으로 LaTeX 논문까지 자동 생성하며, ICLR 워크숍피어리뷰에서 인간 평균 수락 점수를 초과한 논문이 나왔습니다 (arXiv 2504.08066). AutoResearch 가 “하나의 메트릭을 개선하는 직선”이라면, AI Scientist-v2 는 “연구 공간 전체를 탐색하는 나무”입니다.

Darwin Gödel Machine — 자기 코드를 수정하는 AI

같은 Sakana AI 의 Darwin Gödel Machine(DGM)은 한 단계 더 나아갑니다. AutoResearch 에서 에이전트는 train.py 만 수정하지만, DGM 에서 에이전트는 자기 자신의 추론 코드까지 수정합니다. “연구하는 AI” 가 아니라 “스스로 진화하는 AI”입니다. 개방형 진화(open-ended evolution)를 채택하여, 사전에 정의된 메트릭 없이도 다양성과 신기함(novelty)을 기준으로 자기 개선 방향을 탐색합니다. 이 접근법의 위험성은 안전성 섹션에서 다룹니다.

AlphaEvolve — 진화적 코딩으로 수학 문제 해결

DeepMind 의 AlphaEvolve 는 코드 변이(mutation)와 선택(selection)을 반복하는 진화적 접근법을 사용합니다. LLM 이 코드 변이를 제안하고, 자동 평가기가 적합도를 측정하고, 상위 후보만 다음 세대로 전달합니다. 이 방법으로 새로운 활성화 함수를 발견하고 행렬 곱셈 알고리즘을 개선한 사례가 보고되었습니다. AutoResearch 의 “수정-측정-선택” 루프와 동일한 원리를 집단 수준에서 적용한 것입니다.

AutoSOTA — 8-에이전트 파이프라인

AutoSOTA(arXiv 2604.05550)는 가장 야심적인 시스템입니다. 8개의 전문화된 에이전트(PaperReader, DatasetCollector, AgentCoder, TrainRunner, BenchmarkEvaluator, AgentDebugger, AgentReflector, AgentSupervisor)가 논문에서 아이디어를 읽고 → 데이터셋을 수집하고 → 코드를 작성하고 → 학습하고 → 벤치마크를 측정하고 → 디버깅하고 → 반성하고 → 감독합니다. AgentSupervisor 가 Red Line System으로 7가지 치팅 패턴을 차단합니다. 특히 R1(메트릭 변경 금지)과 R3(출력 하드코딩 금지)은 AutoResearch 의 prepare.py 불변 원칙과 정확히 같은 철학입니다.

안전성 — 목표달성 루프의 어두운 면

재귀적 자기개선의 가장 큰 위험: 성능이 10% 올라도 진실성이 15% 하락하면 그것은 개선이 아니라 퇴화입니다. 자기개선 사이클이 반복될수록 초기에는 표류 없이 저비용으로 높은 품질 향상이 일어나지만, 후반 사이클(2~3회 이후)로 갈수록 품질을 올리기 위해 더 큰 표류를 감수해야 합니다. 유창성(Fluency)과 사실성(Factuality) 사이에 도메인 특화적 긴장이 발생하기도 합니다. AutoSOTA 의 AgentSupervisor 가 Red Line System 으로 치팅을 차단하는 것도 이 문제 때문입니다 — 메트릭 변경 금지(R1), 출력 하드코딩 금지(R3), 데이터셋 누출 금지(R6) 등 7가지 규칙을 위반하는 어떤 최적화도 과학적으로 무가치한 것으로 간주됩니다.

SAHOO 프레임워크(안전한 고차 최적화를 위한 정렬 보호 체계)는 이러한 방향 이탈을 수학적으로 통제하기 위해 세 가지 안전장치를 제시합니다. 첫째, 목표 이탈 지수(GDI)— “원래 목표에서 얼마나 벗어났는가?”를 숫자로 측정합니다. 둘째, 규칙 보존 검사— “절대 깨뜨리면 안 되는 규칙을 위반했는가?”를 자동 확인합니다. 셋째, 퇴보 위험 측정— “이전에 이룬 성과를 되돌리고 있는가?”를 감지하여 멈출 시점을 알려 줍니다 (arxiv.org, 2603.06333).

트레이드오프의 한계선 — 언제 멈춰야 하는가

자기개선 루프를 반복하면 “득과 실의 경계선”이 나타납니다. 처음 1~2회 사이클에서는 적은 부작용으로 큰 성능 향상을 얻을 수 있습니다. 그러나 사이클이 반복될수록 성능을 1% 올리기 위해 원래 목표에서 10%나 벗어나야 하는 영역에 진입합니다. 이 지점이 “더 이상 개선이 아니라 악화”인 순간이며, SAHOO 의 퇴보 위험 측정이 이 임계점을 자동으로 감지합니다.

AutoResearch 는 이 문제를 우아하게 회피합니다. val_bpb 는 단일 스칼라 메트릭이므로 “정렬 표류” 차원이 존재하지 않습니다 — 숫자가 낮아지면 무조건 좋고, 높아지면 무조건 revert 합니다. 그러나 이 접근법을 다차원 문제(예: 코드 품질 + 보안 + 성능)에 적용하면 하나의 점수를 올리다가 다른 점수가 떨어지는 “풍선 효과”(풍선의 한쪽을 누르면 다른 쪽이 부풀어 오르는 것)가 발생합니다. 실무에서는 메인 점수 1개 + “이것만은 지켜라” 제약 N개를 조합하는 것이 권장됩니다. 예를 들어, 메인 점수는 pytest 실행 시간(빠를수록 좋음), 제약은 테스트 전부 통과 + 코드 경고 0건입니다.

컨텍스트 엔지니어링 — 올바른 토큰을 공급하는 기술

Karpathy 는 “프롬프트 엔지니어링”이라는 용어가 오해를 유발한다고 지적했습니다. 실제로 중요한 것은 단일 프롬프트를 다듬는 것이 아니라, AI 가 한 번에 읽을 수 있는 범위(컨텍스트 윈도우)에 올바른 정보를 올바른 순서로 공급하는 전체 시스템을 설계하는 것입니다. 이것이 컨텍스트 엔지니어링입니다.

AutoResearch 에서 컨텍스트 엔지니어링이 어떻게 작동하는지 구체적으로 살펴보겠습니다. 에이전트가 매 실험 사이클마다 읽는 정보량은 다음과 같습니다: (1) program.md 전략 지시(약 2,000 토큰 — A4 1장 분량), (2) train.py 전체 소스(약 3,000 토큰 — 630줄이므로 한눈에 파악 가능), (3) results.tsv 최근 실험 이력(약 500 토큰), (4) git log 최근 커밋 메시지(약 300 토큰). 합계 약 6,000 토큰이면 에이전트가 전체 상황을 완벽히 파악합니다. AI 가 한 번에 읽을 수 있는 분량(200K 토큰)의 고작 3%만 사용하므로, 대화가 길어져서 앞의 내용을 잊어버리는 문제가 원천적으로 발생하지 않습니다.

이것을 범용 에이전트와 비교하면 차이가 극명합니다. 대규모 코드베이스를 다루는 에이전트는 수만 줄의 코드를 읽어야 하고, 컨텍스트 윈도우가 빠르게 포화되어 초기 지시를 잊기 시작합니다. Deep Agents 가 컨텍스트 포화 시 자동 요약을 구현한 것도 이 문제 때문입니다. AutoResearch 의 630줄 제약은 단순한 편의가 아니라, 컨텍스트 엔지니어링의 핵심 설계 결정입니다.

프롬프트 엔지니어링이라고 부르지 마십시오. 실제로 하고 있는 것은 컨텍스트 엔지니어링입니다.

실습 — AutoResearch 직접 실행하기

Step 1 — 준비물 확인

Step 2 — 레포 클론 & 환경 설정

# NVIDIA GPU
git clone https://github.com/karpathy/autoresearch.git
cd autoresearch && uv sync

# Mac (Apple Silicon MLX)
git clone https://github.com/trevin-creator/autoresearch-mlx.git
cd autoresearch-mlx && uv sync

Step 3 — 데이터 준비

uv run prepare.py
# → ~/.cache/autoresearch/ 에 데이터 샤드 + 토크나이저 생성
# → 수 분 소요 (첫 실행만)

Step 4 — 베이스라인 측정 (수동 1회)

uv run train.py > run.log 2>&1
grep "^val_bpb:" run.log
# → val_bpb: 0.997900  ← 이것이 베이스라인입니다

Step 5 — AI 에이전트 실행 (자율 루프 시작)

# Claude Code 실행
claude

# 프롬프트:
"Read program.md and begin the autoresearch
 experiment loop. Start with a baseline run,
 then iterate autonomously."

# program.md 가 모든 지시를 포함하므로
# "Start autoresearch" 한 줄이면 충분합니다

Step 6 — 결과 확인

git log --oneline          # 성공한 실험만 남은 커밋
cat results.tsv            # 전체 이력 (성공 + 실패 + 크래시)
uv run train.py > final.log 2>&1
grep "^val_bpb:" final.log # 최종 점수 확인

Step 7 — ML 외 도메인에 적용하기

AutoResearch 의 패턴은 ML 학습에만 국한되지 않습니다. 이미 Shopify 의 Liquid 템플릿 엔진(53% 속도 향상), Pytest 테스트 스위트(295초→71초), Rust 스도쿠 솔버(312실험으로 4/6 벤치 1위), SQLite 데이터 수집(588배 속도 향상), 브라우저 에이전트(Mind2Web 97% 도달) 등 다양한 도메인에서 동일한 패턴이 성공적으로 적용되었습니다.

커뮤니티에서는 이 패턴을 “The Karpathy Loop” 공식으로 정리합니다: AGENT + CONSTRAINED_SCOPE + SCALAR_METRIC + FAST_VERIFICATION = AUTONOMOUS_IMPROVEMENT. 아래 세 가지만 준비하면 어떤 도메인이든 적용할 수 있습니다.

1. Editable Asset  — 에이전트가 수정할 파일
   예: strategy.py, config.yaml, test_suite.py

2. Scalar Metric   — 자동 계산 가능한 성공 지표
   예: pytest 실행 시간, 렌더링 속도, 점수

3. Time-boxed Cycle — 실험당 고정 시간
   예: 5분, 10분 (도메인에 따라 조정)

cargo install autoresearch-cli
autoresearch run --metric "pytest duration" \
                 --file "tests/" --budget 300

조직 성숙도 자가 진단

레벨 2→3 실천 가이드: 첫 번째 하네스 만들기

대부분의 팀이 레벨 2(채팅 복붙)에 머물러 있습니다. 레벨 3으로 올라가려면 AGENTS.md파일 하나만 작성하면 됩니다. 이 파일에 “이 저장소의 테스트는 반드시 pytest로 실행한다”, “Python 파일은 ruff format을 적용한다” 같은 규칙을 산문으로 적습니다. 그 다음, 에이전트가 PR 을 올릴 때 자동으로 pytest와 ruff check를 실행하는 CI 훅을 추가합니다. 이것만으로 에이전트의 출력 품질이 극적으로 향상됩니다.

레벨 3→4 실천 가이드: 센서 추가

레벨 3 에서 레벨 4 로 올라가는 핵심은 “인간의 전수 리뷰”를 “자동화된 센서”로 대체하는 것입니다. 구체적으로: (1) 타입 체크(tsc --noEmit), (2) 린터(eslint), (3) 단위 테스트(jest/pytest), (4) 빌드 검증(next build)을 에이전트의 작업 완료 조건으로 강제합니다. 에이전트가 이 네 가지를 모두 통과하지 않으면 커밋할 수 없도록 하는 것입니다. AutoResearch 의 prepare.py 가 하는 역할과 정확히 동일합니다.

레벨 4→5 실천 가이드: 플라이휠

레벨 5 는 에이전트가 하네스 자체를 개선하는 단계입니다. 예를 들어, 에이전트가 반복적으로 같은 유형의 버그를 만든다면, 리뷰어 에이전트가 이 패턴을 감지하고 AGENTS.md 에 새 규칙을 제안합니다. 인간은 이 제안을 승인만 하면 됩니다. 이것이 바로 “모델이 좋아져서가 아니라 시스템이 학습하기 때문에” 에이전트 품질이 올라가는 구조입니다. 현재 이 수준에 도달한 조직은 전체의 약 5% 미만으로 추정됩니다.

핵심 메시지

참고 자료

GitHub 레포

• karpathy/autoresearch — 75k+ stars (원본) ↗
• davebcn87/pi-autoresearch — 3.6k+ stars (가장 인기 있는 파생 프로젝트) ↗
• trevin-creator/autoresearch-mlx — 1.5k stars (Apple Silicon MLX 포트) ↗
• yibie/awesome-autoresearch — 파생 생태계 큐레이션 ↗
• SakanaAI/AI-Scientist-v2 ↗
• SakanaAI/AI-Scientist v1 — Nature 게재 (12k stars) ↗
• EvoAgentX/EvoAgentX — 자기진화 멀티 에이전트 ↗
• kayba-ai/recursive-improve — 재귀적 자기개선 ↗
• aiming-lab/AutoHarness — 자동 하네스 생성 ↗

핵심 아티클

• Martin Fowler — Harness Engineering (가이드/센서 프레임워크) ↗
• LangChain — Terminal Bench 30위→5위 기법 ↗
• The New Stack — Karpathy 630-line Script ↗
• PJFP — Karpathy No Priors Interview ↗
• DataCamp — Guide to AutoResearch ↗
• InfoQ — OpenAI Codex 100만줄 ↗
• SoftMax — Why AutoResearch Works ↗
• LangChain — Deep Agents (2026.03) ↗
• LangChain — The Anatomy of an Agent Harness (2026.03) ↗
• LangChain — State of Agent Engineering 2026 ↗

학술 논문

• AutoSOTA — 8-에이전트 자동 SOTA (arXiv 2604.05550) ↗
• SAHOO — 정렬 안전장치 (arXiv 2603.06333) ↗
• Broken by Default — AI 코드 55.8% 취약점 (arXiv 2604.05292) ↗
• VeRO — 에이전트가 에이전트를 최적화 (arXiv 2602.22480) ↗
• Darwin Gödel Machine (Sakana AI) ↗
• AI Scientist-v2 (Sakana AI) ↗

영상 & 한국어

• Karpathy on AutoResearch (YouTube) ↗
• GPTers — 하네스 엔지니어링 완벽 정리 ↗
• GeekNews — Karpathy AutoResearch ↗

다른 방법론 글도 있습니다 → Karpathy 방법론 · Ralph Loop · Eval-Driven Development · Context Engineering · Agent Teams · Self-Improving Systems