대부분의 사람들은 2005년의 Google을 사용하던 방식 그대로 AI를 사용합니다

• 무언가를 입력하고, 결과가 나오면 읽고, 다시 입력하는 방식

AI는 당신이 밀어붙이기 전까지 아무것도 하지 않은 채 가만히 있습니다. 당신이 엔진입니다. AI는 매 회전 사이에 집어 들었다가 내려놓는 렌치와 같습니다.

그 방식은 2년 동안은 괜찮았습니다. 하지만 이제는 통하지 않습니다.

현재 AI로부터 10배 더 많은 성과를 얻어내고 있는 사람들은 더 나은 프롬프트 (Prompt)를 작성하거나 비밀 모델을 사용하는 사람들이 아닙니다.

그들은 루프 (Loops)를 구축하고 있습니다. 그리고 이 아이디어를 무시할 수 없게 만든 사람은 바로 Andrej Karpathy입니다.

이 글에서는 다음 내용을 설명합니다:

1 - 루프가 무엇인지 기초부터 설명

2 - Andrej Karpathy가 사용하는 방식으로 루프를 사용하는 방법 제시

3 - 이 접근 방식을 5배 더 개선하는 방법 기술

4 - 시작을 위한 팁 제공

파트 1 · 기초

1.1 - 루프란 실제로 무엇인가?

**프롬프트 (Prompt)**는 하나의 지시사항입니다. 질문을 하고, 답변을 얻고, 다음에 무엇을 할지 결정합니다.

**루프 (Loop)**는 AI가 목표에 도달할 때까지 계속해서 작업해 나가는 목표입니다. 당신이 의자에 앉아 매 단계마다 프롬프트를 입력할 필요가 없습니다.

AI는 무엇을 해야 할지 발견하고, 어떻게 할지 계획하며, 작업을 수행하고, 결과를 확인합니다. 만약 아직 목표에 도달하지 못했다면, 결과를 다시 입력값으로 넣어 작업을 재개합니다. 당신은 목적을 단 한 번 정의합니다.

나머지는 루프가 처리합니다.

성패를 결정짓는 세 가지 요소는 다음과 같습니다:

• **검증기 (Verifier)**는 반복을 진보로 바꾸는 핵심 요소입니다. 결과에 대한 실질적인 확인이 없다면, 그것은 루프가 아니라 에이전트가 스스로의 의견에 반복적으로 동의하는 것에 불과합니다. 검증은 통과하거나 실패하는 테스트, 상승하거나 하락하는 지표(Metric), 혹은 컴파일되거나 충돌하는 빌드(Build)가 될 수 있습니다. 게이트(Gate)가 없다는 것은 에이전트가 스스로의 숙제를 스스로 채점하는 것과 같습니다.
• **상태 (State)**는 루프가 학습하게 만드는 요소입니다. 매 회차마다 AI는 자신이 이미 무엇을 시도했는지 알고 있어야 합니다. 이것이 없다면, 에이전트는 매 사이클마다 똑같은 실수를 반복합니다. 별도의 작은 파일에 무엇이 완료되었고, 무엇이 실패했으며, 다음 단계는 무엇인지 기록합니다. 내일의 실행은 제로(0)에서 시작하는 대신, 중단된 지점부터 재개됩니다.

**중단 조건 (Stop condition)**은 루프가 통제 불능 상태가 되는 것을 방지합니다. 탈출구가 없는 루프는 성공하거나, 깨지거나, 혹은 당신의 계좌 잔고를 다 써버릴 때까지 계속 실행됩니다. 제대로 작동하는 모든 루프에는 두 가지 중단 방식이 있습니다: 목표가 달성되었거나, 혹은

• 작업이 반복됩니다 - 최소한 매주 단위로 반복되어야 합니다. 그보다 빈도가 낮다면 설정 비용을 회수할 수 없습니다. 일회성 작업은 여전히 잘 작성된 프롬프트 하나로 처리하는 것이 더 낫습니다.
• 검증이 자동화되어 있습니다 - 테스트 스위트 (test suite), 타입 체커 (type checker), 린터 (linter), 빌드 (build) 등, 당신이 자리에 없어도 작업의 실패 여부를 판단할 수 있는 무언가가 있어야 합니다. 자동화된 체크가 없다면 당신은 다시 모든 디프 (diff)를 읽고 있어야 하며, 이는 루프가 제거하려고 했던 바로 그 작업입니다.
• 토큰 예산이 낭비를 감당할 수 있습니다 - 루프는 컨텍스트 (context)를 다시 읽고, 재시도하며, 탐색합니다. 이는 실행 결과물이 무엇이든 상관없이 토큰을 소모합니다. 이는 예산에 따라 규모가 달라지는데, 토큰이 무료인 사람들에게는 당연해 보일 수 있지만, 월 20달러 플랜을 사용하는 사람들에게는 무모해 보일 수 있습니다.
• 에이전트 (agent)가 실제 도구를 가지고 있습니다 - 로그 (logs), 재현 환경 (reproduction environment), 자신이 작성한 코드를 실행하고 무엇이 고장 나는지 확인할 수 있는 능력 등이 필요합니다. 이것이 없다면 루프는 눈을 감고 반복하는 것과 같습니다.

솔직한 견해: 루프 엔지니어링 (loop engineering)은 실재하며, 대부분의 사람들은 아직 헤비한 버전을 사용할 필요가 없습니다. 토큰이 제한된 소비자용 플랜을 사용 중이라면, 생산성 향상이 나타나기도 전에 헤비한 루프가 속도 제한 (rate limit)에 걸리거나 지갑을 털어버릴 것입니다.

파트 2 · Karpathy 루프

Karpathy가 프롬프팅을 멈추고 루핑을 시작한 방법

2026년 3월, Andrej Karpathy는 AutoResearch라는 GitHub 리포지토리 (repo)를 공개했습니다.

파일 3개. 코드 약 630줄.

한 달 만에 **66,000개 이상의 스타 (stars)**를 얻었으며, Fortune지는 이에 이름을 붙였습니다: Karpathy 루프 (The Karpathy Loop).

• karpathy autoresearch

설정은 거의 황당할 정도로 간단합니다:

• train.py - 학습 스크립트 (training script). 에이전트가 건드릴 수 있는 유일한 파일입니다.
• prepare.py - 모델의 점수를 매기는 평가기 (evaluator). 에이전트는 이 파일을 건드릴 수 없습니다. 만약 건드릴 수 있다면, 에이전트는 모델을 개선하는 대신 테스트를 더 쉽게 만들어버릴 것입니다.
• program.md - 에이전트에게 무엇을 탐색해야 하는지, 어떤 제약 사항을 준수해야 하는지를 알려주는 지침 (instructions).

에이전트는 루프 (loop) 내에서 실행됩니다:

코드 읽기 → 변경 사항 제안 → 5분 동안 학습 → 결과가 개선되었는지 확인 → 개선되었다면 커밋 (commit), 그렇지 않다면 롤백 (roll back) → 반복.

당신은 잠자리에 듭니다. 깨어나면 실험 로그와, 바라건대 더 나은 모델을 마주하게 됩니다.

인간은 절대 train.py를 건드리지 않습니다. 당신은 program.md를 작성합니다. 실행은 에이전트가 처리합니다.

• 결과:

Karpathy는 자신이 20년의 경험을 통해 수동으로 (by hand) 정교하게 튜닝해온 모델을 대상으로 이 방식을 적용했습니다. 그는 이 루프를 이틀 동안 실행했습니다.

• 에이전트는 700번의 실험을 수행했습니다.
• 그가 놓쳤던 20가지 개선 사항을 찾아냈습니다.
• 예를 들어, 어텐션 (attention)이 헤드(heads) 전체에 너무 분산되게 만들었던 어텐션 메커니즘 (attention mechanism) 내의 누락된 스칼라 승수 (scalar multiplier) 같은 것들입니다.
• 이는 퍼저 (fuzzer)가 잡아낼 수 있는 버그가 아니라, 주의 깊은 인간이라면 찾아낼 수도 있었지만 그러지 못했던 미묘한 최적화 (optimization)였습니다.

왜냐하면 인간은 실험 12번째 이후부터는 지치기 때문입니다. 에이전트는 전혀 지치지 않습니다.

Shopify의 CEO Tobi Lutke는 내부 모델에 대해 하룻밤 동안 이 방식을 시도해 보았습니다:

• 그는 19%의 품질 향상과 함께 잠에서 깨어났습니다.
• 최적화된 모델은 이전 모델의 절반 크기였습니다.
• 더 작은 모델이 더 큰 모델을 이겼습니다. 에이전트가

Claude Code, Codex, 또는 bash 스크립트로 구축하든, 모든 작동하는 루프 (loop)는 다섯 가지 요소로 구성됩니다.
Claude Code와 Codex는 현재 이 다섯 가지를 모두 제공합니다.

• 자동화 (Automation) - 심장 박동. 일정에 따라, 이벤트에 따라, 또는 트리거에 따라 루프를 실행하는 무언가입니다.

Claude Code에서는 주기적인 실행을 위한 /loop, 특정 조건이 충족될 때까지 실행하는 /goal이 있습니다. Codex에서는 자동화 (Automations) 탭이 있습니다. 심장 박동이 없다면, 스크립트를 한 번 실행하고 잊어버리는 것에 불과합니다. 그것은 루프가 아닙니다.

• 기술 (A skill) - 에이전트가 매 세션마다 추측하는 것을 멈출 수 있도록 프로젝트 지식을 저장합니다. 당신의 컨벤션 (conventions), 빌드 단계, 그리고 3개월 전 그 사건 때문에 하지 않는 바로 그 일 등을 포함합니다.

마크다운 (markdown) 파일에 한 번 작성하면, 매 실행 시마다 읽어 들입니다.

기술 (skills)이 없다면, 루프는 매 사이클마다 프로젝트의 전체 컨텍스트 (context)를 처음부터 다시 도출해야 합니다. 기술 (skills)이 있다면, 의도 (intent)가 축적됩니다.

• 하위 에이전트 (Sub-agents) - 제작자 (maker)와 검사자 (checker)를 분리합니다.

코드를 작성한 모델은 자신의 숙제를 채점할 때 너무 관대합니다.

다른 지침을 가진 두 번째 에이전트가 첫 번째 에이전트가 스스로를 설득하며 놓친 것들을 잡아냅니다. 작성자 (writer)는 빠르고 저렴하게, 검토자 (reviewer)는 느리고 엄격하게 설정할 수 있습니다. 그 분리가 품질의 대부분을 결정합니다.

• 커넥터 (Connectors) - 루프가 실제 환경 내부에서 작동하게 합니다. 이슈 트래커 (issue tracker)를 읽고, PR (Pull Request)을 열고, Slack에 알림을 보내고, Linear 티켓을 업데이트합니다.

"여기 수정 사항이 있습니다"라고 말하는 에이전트와, 수정 사항을 배포하고 아침에 당신에게 알려주는 루프 (loop) 사이의 차이입니다.

• 검증기 (A verifier) - 관문입니다. 잘못된 작업을 자동으로 거부하는 테스트 (test), 타입 체크 (type check), 또는 빌드 (build)입니다.

그 외의 모든 것은 배관 작업 (plumbing)에 불과합니다.

이 부분이 루프를 실질적으로 만드는 요소입니다. 이것이 없다면 당신은 에이전트가 밤새도록 자기 자신과 동의하는 비용을 지불하고 있는 셈입니다.

파트 4 · Karpathy 이후에 오는 것

이중 계층(The Bilevel) - 루프 위의 루프

• 여기서부터 정말 흥미로워집니다, 헤헤 xD

• 2026년 3월, 두 명의 연구자가 arxiv에 **"Bilevel Autoresearch: Meta-Autoresearching Itself"**라는 제목의 논문을 발표했습니다.

그들은 Karpathy의 루프를 가져와 간단한 질문을 던졌습니다:

만약 자동 연구 (autoresearch) 자체가 연구의 한 형태라면, 자동 연구를 자동 연구할 수 있을까?

이중 계층 자동 연구 (Bilevel Autoresearch)

그들은 첫 번째 루프 위에 두 번째 루프를 구축했습니다:

• 내부 루프 (Inner loop) - Karpathy의 원래 방식과 동일하게 작동합니다: 변경 사항 제안, 학습 (train), 평가 (evaluate), 유지 또는 폐기
• 외부 루프 (Outer loop) - 내부 루프가 작동하는 것을 관찰하고, 그 코드와 트레이스 (traces)를 읽으며, 탐색 과정 자체가 어디에서 막히고 있는지를 식별합니다. 그리고 내부 루프가 탐색하는 방식을 변경하는 새로운 Python 코드를 생성합니다. 그런 다음 그 코드를 주입하고 내부 루프를 다시 실행하게 합니다.

결과:

Karpathy의 GPT 사전 학습 (pretraining) 벤치마크에서:

• 표준 단일 루프 대비 5배 개선 (-0.045 대 -0.009 val_bpb)
• 5% 더 나은 것이 아닙니다. 5배 더 나은 것입니다.
• 두 루프 모두 동일한 LLM을 사용했습니다 - 메타 레벨을 위해 더 똑똑한 모델이 필요한 것은 아닙니다.
• 개선은 원시 지능 (raw intelligence)이 아닌 **아키텍처 (architecture)**에서 비롯되었습니다.

외부 루프가 실제로 찾아낸 것: 내부 루프가 계속해서 동일한 탐색 패턴에 빠진다는 점이었습니다. LLM은 어떤 최적화를 시도해야 하는지에 대한 사전 지식 (priors)을 가지고 있으며, 그 지식이 더 이상 작동하지 않을 때조차 계속해서 그 사전 지식으로 되돌아갑니다. 외부 루프는 모델의 본능이 피하는 방향으로 탐색을 강제함으로써 이러한 패턴을 깨뜨렸습니다.

이 논문은 깊이 새겨볼 만한 문장으로 끝을 맺습니다: "만약 자동 연구가 스스로를 메타 자동 연구할 수 있다면, 원칙적으로 측정 가능한 목표가 있는 무엇이든 메타 자동 연구할 수 있다."

파트 5 · 직접 시도해 보세요

지금 바로 루프를 실행해 보세요 - 도구는 필요 없습니다

이것이 어떻게 작동하는지 느끼기 위해 Claude Code나 Codex가 필요하지는 않습니다. 이 내용을 아무 LLM(Large Language Model)에나 붙여넣고 어떤 일이 일어나는지 지켜보세요:

당신은 작업이 기준을 충족할 때까지 루프(loop) 내에서 작업할 것입니다.

작업(TASK):
...

모델은 초안을 작성하고, 당신의 기준에 따라 자신의 작업물을 스스로 채점하며, 약점을 찾아내고, 다시 작성하며, 기준을 통과할 때까지 이 과정을 반복합니다.

이것이 바로 루프입니다. 당신은 방금 단 한 단락으로 루프를 구축했습니다.

물론 한계는 있습니다. 여전히 당신이 트리거(trigger) 역할을 해야 하며, 스케줄링이나 지속적인 상태(persistent state)가 없습니다. 탭을 닫으면 사라집니다. 하지만 이것은 핵심 메커니즘을 보여줍니다. 이것에서 완전한 자율 루프(autonomous loop)로 도약하는 방법은 자동화, 상태 파일(state file), 그리고 게이트(gate)를 추가하는 것입니다.

파트 6 · 솔직한 부분

루프가 해결하지 못하는 것

루프는 작업 방식을 변화시킵니다. 하지만 루프가 당신을 작업에서 삭제해주지는 않습니다.

그리고 루프가 더 정교해질수록(더 쉬워지는 것이 아니라), 두 가지 문제는 더욱 날카로워집니다: