The Karpathy Loop - autoresearch

작성일: 2026년 4월 3일 작성자: 하효정

1. 배경

안드레아 카르파티(Andrej Karpathy)는 OpenAI 공동창립자이자 테슬라 AI 총괄을 역임한 AI 분야의 저명한 연구자입니다.

그가 2026년 3월 autoresearch 라는 프로젝트를 공개했습니다. 이 프로젝트는 공개 직후 큰 관심을 받았고, Fortune 등 일부 해설에서는 이 반복 실험 구조를 “The Karpathy Loop”라고 부릅니다. (https://fortune.com/2026/03/17/andrej-karpathy-loop-autonomous-ai-agents-future/?utm_source=chatgpt.com)

본 문서는 해당 방법론에 대한 간략한 설명과 실무에 적용할 수 있는 범위에 대해 다룹니다.

2. autoresearch란?

autoresearch는 Andrej Karpathy가 공개한 오픈소스 프로젝트 이름입니다.

이 프로젝트는 AI 연구 분야에서 AI 에이전트가 스스로 실험을 반복하며 성능을 개선해 나가는 루프 구조를 실제로 구현한 사례입니다.

여기서 중요한 점은, autoresearch를 곧바로 완성된 범용 도구나 이미 정립된 일반 이론으로 이해하면 오해가 생길 수 있다는 것입니다. Fortune도 Karpathy가 자신이 만든 이 시스템을 autoresearch라고 불렀다고 설명하면서, 이 구조를 계기로 반복 연구 자동화에 대한 논의가 커졌다고 전합니다.

이 문서에서 autoresearch를 먼저 설명하는 이유는 우리가 이 프로젝트 자체보다, 이 프로젝트가 담아내고 있는 구조에 집중하는 것이 중요하기 때문입니다.

1) 프로젝트의 배경

AI 연구 분야에 있어 기존 연구원들의 업무 방식은 다음과 같았습니다.

아이디어 → 코드 수정 → 실험 → 결과 측정
							                   ↓
										         개선됐으면 → 채택하고 다음 아이디어로
										         나빠졌으면 → 원래대로 되돌리고 다음 아이디어로

AI 연구원에게 있어 무수히 많은 실험과 측정은 피할 수 없는 반복 노동이었습니다. 그동안 이를 사람이 맡았던 이유는 실험 결과를 보고 코드를 수정하는 판단 자체가 AI가 할 수 없는 영역이라고 여겨졌기 때문입니다. Andrej Karpathy는 AI 에이전트가 코드를 직접 읽고 수정할 수 있는 수준에 이른 지금, 이 반복 작업을 사람이 할 일과 AI가 할 일로 나누어 재설계할 수 있다는 것을 실제로 구현해 보였습니다.

2) 프로젝트의 의의 - 사람의 역할 변화

기존에는 연구자가 코드를 직접 수정하며 실험을 진행했다면, 이 구조에서 사람의 역할은 program.md라는 문서를 작성하는 것으로 바뀝니다.

이 문서는 AI 입장에서는 일종의 연구용 헌법의 역할을 합니다. "어떤 방향으로 실험할지", "무엇은 건드리지 말지", "성공의 기준은 무엇인지"를 이 문서를 기준으로 판단하는 것입니다.

→ 이 구조는 단순한 자동화가 아닙니다. 연구자의 역할 자체가 반복작업자에서 기준 설계자로 바뀐다는 점에서 패러다임의 전환으로 주목받고 있습니다.

3. The Karpathy Loop 의 핵심 개념

1) 핵심 정의

AI가 스스로 최적화 루프를 돌리는 것
사람은 목적, 방향성, 평가 기준을 설계하고 감독하는 역할을 수행

→ 숫자로 측정 가능한 목표와 AI가 수정할 수 있는 파일, 이 두 가지가 갖춰진 업무라면 업무 영역에 관계없이 적용 가능성을 검토해볼 수 있습니다. 다만 전제 조건을 충족하는 것이 생각보다 까다롭기 때문에, 모든 업무에 바로 적용할 수 있는 것은 아닙니다.

2) 전제 조건

수정 대상이 명확해야 합니다. AI 에이전트가 손댈 수 있는 범위가 하나의 파일이나 설정으로 명확하게 한정되어야 합니다. 범위가 흐릿하면 AI가 의도하지 않은 부분까지 건드릴 수 있습니다.
자동으로 좋고 나쁨을 판단할 수 있는 객관적 기준이 있어야합니다. 사람의 판단 없이 자동으로 측정되는 기준이 있어야 루프가 스스로 돌아갑니다. 이 기준은 단일 숫자 하나일 수도 있고, 여러 지표의 조합일 수도 있습니다. 이것을 잘 설계하는 것이 사실상 전체 작업에서 가장 어려운 부분입니다.
실험 한 번이 빠르게 끝나야 합니다. 실험 1회에 수 시간이 걸린다면 루프의 의미가 약해집니다. 수분에서 수십분 안에 결과가 나올 수 있어야 합니다. 그런 단위로 업무를 나누어 설계할 수 있는 사람의 역량이 필요합니다.

3) 사람에게 남겨진 일

루프가 자동으로 돌아간다고 해서 사람이 빠지는 것은 아닙니다. 오히려 사람이 해야 하는 일의 성격이 바뀝니다.

어떤 문제를 풀 것인지 정의하는 일
무엇이 좋은 결과인지 측정 기준을 설계하는 일
루프가 잘못된 방향으로 흐를 때 감지하고 수정하는 일

이 세 가지는 AI가 대신하기 어렵습니다. 루프의 품질은 결국 이 역할을 얼마나 잘 수행하느냐에 달려 있습니다.

4. 이 방법론을 우리 것으로 만들수 있을까?

이제 이 방법론을 조금 더 실무영역에서 들여다 보겠습니다.

autoresearch GitHub 저장소는 The Karpathy Loop라는 방법론을 LLM 모델 학습이라는 특정 영역에 적용해 구현한 오픈소스 프로젝트입니다. 공개 직후 기술 커뮤니티에서 큰 관심을 받았고, 다양한 실험적 논의가 이어지고 있습니다. 다만 이 저장소가 전제하는 사용 맥락이 있기 때문에, 우리 조직에 적용하려면 두 가지 경로 중 어느 쪽인지를 먼저 따져봐야 합니다.

1) 저장소를 그대로 가져다 쓰는 경우

저장소 코드를 그대로 실행하는 것은 LLM 모델을 직접 학습시키고, 그 학습 코드를 AI가 자동으로 개선하게 하겠다는 의미입니다. 원래 설계 목적 그대로 쓰는 경우입니다.

실무에서 이에 해당하는 작업은 다음과 같습니다.

사내 전용 챗봇이나 요약 모델을 자체 데이터로 직접 훈련시키는 경우
특정 도메인(예: 게임 설명, 상품 소개)에 특화된 소형 언어 모델을 만드는 경우
외부 API 없이 사내 서버에서 독립적으로 구동되는 AI 모델이 필요한 경우

→ 즉, "우리만의 AI 모델을 직접 만들겠다"는 목적이 있을 때 해당됩니다.

이 경우 다음이 필요합니다.

하드웨어: 저장소는 단일 NVIDIA GPU 환경을 전제로 하며, 공개 예시는 H100에서 테스트되었습니다. 따라서 실제 활용에는 GPU 환경이 필요하며, 사양에 따라 실험 속도와 범위에 큰 차이가 날 수 있습니다. GPU 구매 또는 클라우드 임대 비용이 필요합니다.
인력: 모델 학습 과정을 이해하는 ML 엔지니어가 필요합니다. program.md를 작성하고 결과를 해석하려면 딥러닝 도메인 지식이 전제되어야 합니다. 저장소를 복제해서 실행하는 것과, 의미 있는 실험 방향을 설계하는 것은 전혀 다른 역량입니다.

우리 회사의 현재 업무 맥락에서 LLM 모델을 직접 학습시킬 필요가 있는지부터 검토가 필요합니다. 해당 필요가 없다면 이 경로는 현시점에서 우리에게 해당하지 않습니다.

2) 방법론만 가져와서 다른 영역에 응용하는 경우

The Karpathy Loop의 핵심 구조 — 수정 → 실험 → 측정 → 채택/롤백 → 반복 — 는 LLM 학습에만 국한되지 않습니다. 전제 조건만 만족한다면 어떤 영역에도 이 방법론을 적용할 수 있습니다.

이 경우 저장소 코드는 직접 쓰지 않고 구조만 응용하는 방식이며, 별도의 고성능 GPU 인프라가 반드시 필요한 것은 아닙니다. 다만 사용 방식에 따라 외부 LLM API나 별도 연산 자원이 필요할 수 있습니다. 대신 기본전제 조건에 더하여 추가로 다음 조건들이 갖춰져야 방법론이 제대로 작동합니다.

안전한 실험 환경이 필요합니다. AI가 파일을 수정하고 실행하는 과정이 실서비스나 운영 시스템에 영향을 주지 않도록 격리된 환경이 갖춰져야 합니다. 실험이 잘못됐을 때 되돌릴 수 있는 버전 관리 체계도 필수입니다.
방향을 설계하고 결과를 해석할 수 있는 담당자가 있어야 합니다. 완전 자율 운용은 현 단계에서 현실적이지 않습니다. AI가 잘못된 방향으로 수렴하고 있을 때 감지하고 조정하는 역할을 맡을 사람이 필요합니다. GPU 대신 이 사람의 판단력이 핵심 자원입니다.

→ 인력 구성: 루프 환경 구축에 개발 역량(Python 또는 서버)이 있는 인력이 초기에 필요하고, 이후에는 방향 문서 작성과 로그 리뷰를 주기적으로 담당할 사람이 필요합니다. 상시 전담 인력이 아니라 겸직 형태로도 운용 가능한 구조입니다.

5. 조건이 갖춰진 이후 적용 가능한 예시— 프롬프트 자동 최적화

조건이 모두 갖춰진다는 가정 아래, 당사 업무에 가장 현실적으로 적용 가능한 시나리오 하나를 예시로 들어보겠습니다. 프롬프트 자동 최적화 루프입니다.

1) 개념

autoresearch에서 AI 에이전트가 train.py(학습 코드)를 수정하듯, 여기서는 AI 에이전트가 프롬프트 파일을 수정합니다. 각 실험 후 자동 평가 점수를 지표로 삼아, 더 나은 프롬프트는 채택하고 나빠진 프롬프트는 버리는 구조입니다.

2) 동작 구조 (예시)

1. AI 에이전트가 현재 프롬프트 파일을 읽는다
2. 개선 아이디어를 적용해 프롬프트를 수정한다
3. 수정된 프롬프트로 테스트 케이스 N건을 실행한다
4. LLM이 주어진 채점표를 기준으로 출력 품질을 자동 채점한다
5. 점수가 오르면 → 채택 / 내리면 → 버림
6. 위 과정을 반복한다.

3) 이 구조의 한계

자동 지표가 실제 품질을 완전히 반영하지 못할 수 있습니다. AI가 지표 점수만 높이는 방향으로 수렴하되 실제 사용 품질은 저하되는, 이른바 '굿하트의 법칙(Goodhart's Law)' 문제가 발생할 수 있습니다.

→ 자동 평가와 주기적인 인간 검수의 병행이 필요합니다.

※ 조금 더 알아보기

Q. 그냥 사람이 프롬프트를 직접 개선하는 것과 뭐가 다른가요?

속도와 일관성입니다. 숙련된 담당자가 직접 수행할 경우에는 반복 횟수와 비교 일관성에 한계가 있습니다. 자동화 루프는 동일한 조건으로 훨씬 더 많은 반복 실험을 수행할 수 있다는 점에서 차이가 있습니다. 또한 사람은 직전 실험 결과에 심리적으로 영향을 받지만, 루프는 지표만을 기준으로 판단합니다.

Q. AI가 잘못된 방향으로 계속 실험을 이어가면 어떻게 되나요?

program.md(실험 방향 문서)로 기준을 설정하고, 주기적으로 담당자가 로그를 리뷰하며 방향을 수정합니다. 완전 무감독 자율 운용은 현 단계에서 권장되지 않으며, '자율 실행 + 인간 감독'의 병행 구조가 현실적입니다.

Q. 비슷한 개념을 구현한 상용 도구는 없나요?

DSPy, PromptFoo, LangSmith 등 프롬프트 최적화와 평가를 지원하는 도구들이 이미 존재합니다. 다만 Karpathy Loop의 차별점은 "평가 후 자동 롤백·채택"까지 포함한 완전 자율 루프라는 점이며, 상용 도구들은 아직 이 수준의 자율성을 완전히 지원하지는 않습니다. 두 접근을 병행하거나 단계적으로 이행하는 방식도 검토 가능합니다.

Q. 이 방법론이 실제 현장에서 검증된 건가요?

공개 시점(2026년 3월) 기준으로 Karpathy가 제시한 실험 환경에서 동작 가능성이 확인된 상태이며, 일반 업무 영역으로의 확장 적용은 아직 초기 단계로 보는 것이 적절합니다.

→ 사내 적용 시에는 소규모 파일럿 형태의 검증 과정이 선행되어야 한다고 판단됩니다.