4주차: 루프 패러다임 — 반복이 복잡성을 이긴다

Phase 24주차중급강의일: 2026-03-24

이론 (Theory)

오늘의 학습 목표

이론 관점

Test-time compute scaling이 왜 루프 패러다임의 이론적 기반인지 설명할 수 있다.

Ralph 관점

Harness, backpressure, garbage collection, 누적 학습의 작동 원리를 이해하고 구현할 수 있다.

확장 관점

RLM(재귀 추론)과 autoresearch(자율 실험)가 같은 루프 원리의 다른 적용임을 이해한다.

구현 관점

직접 Ralph 루프를 구현하고 실패→학습→성공 사이클을 경험한다.

---

왜 루프인가 — 2026년 AI의 승부처

밤새 돌려놓은 루프 하나가 복잡한 파이프라인보다 나은 결과를 가져온다.

2026년 AI 엔지니어링의 승부처는 더 큰 모델도, 더 정교한 프롬프트도 아니다. 루프의 반복이다. 같은 모델을 수백 번 돌리되, 매번 결과를 검증하고, 실패하면 버리고, 성공하면 쌓는다. 단순하지만, 이 패턴이 복잡한 멀티에이전트 아키텍처를 일관되게 이긴다.

이번 주에 다룰 세 가지 루프가 그 증거다:

• Ralph Loop — 코드를 생성하고, 테스트로 검증하고, 실패하면 git checkout .으로 지우고 재시도한다. 코드 품질의 루프.
• RLM — 모델이 자기 자신을 재귀 호출하여 긴 문서에서 필요한 정보만 골라낸다. 맥락 이해의 루프.
• autoresearch — train.py를 에이전트에게 주고, 5분마다 결과를 측정하여 개선되면 commit, 아니면 reset한다. 연구의 루프.

이 세 루프는 모두 같은 원리 위에 서 있다. 2주차에서 배운 거버넌스가 루프의 안전 경계를 설정하고, 3주차에서 배운 MIG가 컴퓨팅을 격리하고 MCP가 도구 접근을 표준화한다. 오늘은 그 인프라 위에서 실제로 돌아가는 루프를 이해하고 구현한다.

---

Claude Code 내부에서는...

Claude Code의 Query Engine이 바로 이 루프 원리의 구현체다:

• 턴 루프: 사용자 메시지 → 도구 호출 → 결과 추가 → 반복 (max 16 iterations). 도구 호출 1회 = 1턴
• 예산 제어: max_turns = 8, max_budget_tokens = 2,000 — 무한 루프 방지의 결정론적 경계
• 세션 lifecycle: 7단계 부트스트랩(prefetch → query engine loop). 세션 종료 후 .claude/sessions/에 JSON 영속화 → 새 세션에서 상태 파일 읽기
• TurnResult 7요소: input, response, tools, permissions, tokens, termination reason — 매 턴의 결과를 구조화하여 캡처

Ralph 루프의 “실행 → 검증 → 재시도”가 이 턴 루프 위에서 돌아간다.

→ 상세: 참고자료 > Claude Code 내부 구조

Test-Time Compute Scaling — 이론적 기반

모델을 키우지 않고 성능을 높이는 법

2024년 OpenAI o1이 검증한 핵심 발견이 있다: 모델 크기를 키우지 않아도, 추론 시점에 연산을 더 쓰면 성능이 올라간다. 이것이 test-time compute scaling이다.

전통적인 AI 성능 향상 전략은 train-time scaling — 더 큰 모델, 더 많은 데이터, 더 긴 학습 시간이었다. GPT-3 → GPT-4의 점프가 대표적이다. 하지만 이 접근은 비용이 지수적으로 증가한다.

Test-time compute scaling은 다른 길을 간다. 이미 훈련된 모델을 추론 시점에 더 오래, 더 많이 생각하게 한다. 구체적으로:

• o1은 같은 문제에 대해 여러 추론 경로를 탐색하고, 가장 좋은 답을 선택한다
• 추론에 투입하는 토큰이 많을수록 (= 더 오래 생각할수록) 정답률이 올라간다
• 일정 수준까지는 모델 크기를 키우는 것보다 추론 연산을 늘리는 것이 비용 대비 효과가 높다

세 루프가 test-time compute를 활용하는 방식

Ralph, RLM, autoresearch는 모두 test-time compute scaling의 구체적 실현이다:

루프	적용 영역	test-time compute 활용 방식
Ralph Loop	코드 생성	코드 생성 → 테스트 실행 → 실패 시 재시도. 10번 시도하면 10배의 추론 토큰 사용
RLM	장문 이해	모델이 자기 자신을 재귀 호출. 호출 깊이만큼 추론 연산 증가
autoresearch	ML 실험	5분 예산 × N회 반복. 반복 횟수만큼 연산 투입

공통점이 보이는가? 셋 다 같은 모델을 반복 호출하되, 결정론적 검증 조건으로 결과를 필터링한다. 모델 자체를 바꾸는 것이 아니라, 모델이 생각하는 시간과 횟수를 늘려서 품질을 확보한다.

당신이 잠든 8시간이 누군가에게는 100번의 개선

test-time compute의 핵심 통찰: 더 좋은 모델을 기다릴 필요가 없다. 지금 있는 모델로 루프를 돌리면 된다. 밤 10시에 루프를 시작하고 아침 6시에 결과를 확인한다면, 그 8시간 동안 에이전트는 수십~수백 번의 시도를 한 것이다. 각 시도마다 test-time compute가 누적된다.

”22-point 하네스 스윙” — 모델보다 하네스가 중요하다

2026년 SWE-bench 벤치마크가 이 강의의 핵심 주장을 실증적으로 증명한다:

벤치마크	Claude Opus 4.5 점수	설명
SWE-bench Verified	80.9%	검증된 이슈 세트, 표준 스캐폴드
SWE-bench Pro	45.9%	더 현실적인 이슈, 최소 스캐폴드

같은 모델인데 하네스/스캐폴드 차이로 35pp 격차가 벌어진다. GPT-5.3-Codex는 Pro에서 56.8%로 선두지만, 이 역시 OpenAI가 자체 구축한 에이전트 하네스 덕분이다.

Phase 2의 실증적 근거

“더 좋은 모델을 기다리는 것”과 “더 좋은 하네스를 만드는 것” 중 어디에 투자할 것인가? SWE-bench 데이터는 명확하다 — 같은 모델이라도 하네스에 따라 22pp 이상 성능이 뒤집힌다. 이것이 Phase 2(하네스 엔지니어링) 전체의 존재 이유다.

T2 Scaling: 추론 비용이 사전학습 전략을 바꾼다

2026년 4월 발표된 T2 scaling laws(arxiv 2604.01411)는 test-time compute의 경제학을 한 단계 더 깊이 파고든다. 기존 Chinchilla 연구(2022)는 학습 연산 비용만 최적화했지만, T2는 추론 비용까지 포함하여 최적점을 재계산한다.

핵심 발견:

• 추론 비용을 고려하면 Chinchilla 최적점보다 overtrain이 유리하다 — 더 작은 모델을 더 오래 학습시키면, 추론 시 토큰당 비용이 낮아진다
• 이것은 루프 패러다임과 직결된다: 작은 모델을 많이 돌리는 전략이 큰 모델을 적게 돌리는 것보다 경제적일 수 있다
• test-time compute 확장이 train-time 전략까지 역으로 변화시키는 피드백 루프

effort 파라미터의 진화

Claude 4.x에서 기존 budget_tokens(개발자가 직접 토큰 수를 지정)가 deprecated되고, adaptive effort 파라미터로 대체되었다:

effort 레벨	동작	용도
low	짧은 추론, 빠른 응답	단순 조회, 타입 확인
medium	표준 추론	일반 코딩
high	깊은 추론, 더 많은 토큰	복잡한 리팩터링
max	최대 추론 깊이	아키텍처 설계, 디버깅

이것은 test-time compute 할당이 개발자 제어에서 모델 자율 제어로 이동하는 추세를 보여준다. 루프 패러다임의 시사점: 매 반복마다 effort를 동적으로 조절하는 전략이 가능하다 — 초반에는 low로 빠르게 탐색하고, 유망한 방향이 보이면 high로 깊이 파고드는 식이다.

---

Ralph Loop Deep Dive

2025년 말 개발자 Geoffrey Huntley가 대중화한 Ralph 루프 (Ralph Wiggum Loop)는 에이전틱 소프트웨어 개발의 핵심 패러다임이다.

원형: bash 한 줄

# Ralph 루프의 핵심 — 단 한 줄
while :; do cat PROMPT.md | claude-code; done
# 다른 AI 코딩 CLI 도구도 동일한 패턴 적용 가능:
# while :; do cat PROMPT.md | gemini; done
# while :; do codex --approval-mode full-auto "$(cat PROMPT.md)"; done

이 무한 루프를 관통하는 설계 결정이 두 가지 있다:

1. Stop Hook이 exit을 막는다 — 에이전트가 스스로 종료하려 해도 셸이 다시 시작한다. 에이전트는 “완료했다”고 생각하지만, 다음 루프에서 PROMPT.md를 다시 읽고 미완성 태스크를 발견한다.
2. 매 회차마다 context window를 새로 연다 — 이전 루프의 실패한 시도가 컨텍스트를 오염시키지 않는다. git history와 파일시스템이 유일한 상태 저장소다.

이 단순함이 핵심이다. 에이전트 간 통신도, 상태 DB도, 오케스트레이터도 없다. 루프의 지능은 루프 자체가 아닌 환경 제약에 있다 — 이것을 하네스(harness)라 부른다.

모놀리식 아키텍처의 장점

Ralph 루프는 의도적으로 모놀리식 (Monolithic)이다:

마이크로서비스 (복잡)

• 에이전트 간 통신 오류
• 비결정적 아키텍처 실패
• 디버깅 불가능한 cascading failure

Ralph 루프 (단순)

• 단일 프로세스, 단일 저장소
• 루프당 정확히 1개 태스크
• 예측 가능한 실행 상태

하네스(Harness) 아키텍처

RALPH HARNESS

📄PROMPT.md

↓

🤖AI Agent코드 생성 시도

↓

Backpressure System

• 컴파일러 실행
• 타입 체커 실행
• 테스트 스위트 실행

✓성공AGENTS.md 기록 + 다음 태스크

✗실패GC + AGENTS.md 실패 기록 + 재시도

하네스의 세 기둥:

1. Backpressure — 컴파일러, 타입 체커, 테스트 스위트가 에이전트 출력을 자동으로 거부한다. 에이전트가 아무리 자신 있게 코드를 작성해도, pytest가 실패하면 그 코드는 존재하지 않는 것과 같다.
2. Garbage Collection — git checkout .으로 실패한 코드를 완전히 제거한다. 저장소는 항상 마지막 성공 상태로 돌아간다. Jenga 탑처럼 잘못된 블록 위에 쌓는 것이 아니라, 도예 바퀴처럼 원하는 형태가 아니면 반죽을 다시 시작한다.
3. 상태 추적 — PROMPT.md의 체크리스트와 git history가 진행 상황을 기록한다. 다음 루프의 에이전트가 이전 상태를 파악할 수 있다.

Huntley의 Jenga vs 도예 비유

• 전통 소프트웨어: Jenga 탑 쌓기 — 한 블록 실수로 전체 붕괴
• Ralph 루프: 도예 바퀴 위의 점토 — 원하는 형태가 아니면 다시 반죽, 무한 반복

누적 학습 구조 — AGENTS.md

Ralph 루프의 진화된 형태는 단순한 반복을 넘어 학습하는 루프다. 핵심은 AGENTS.md 파일이다.

# AGENTS.md — 누적 학습 기록

## 학습된 패턴
- calculator.py의 division 함수는 ZeroDivisionError 처리 필수 (루프 3에서 실패)
- pytest fixture는 conftest.py에 배치해야 import 에러 방지 (루프 5에서 실패)

## 금지 패턴
- `eval()` 사용 금지 — 보안 리스크 + 타입 체커 우회
- 전역 변수로 상태 공유 금지 — 테스트 격리 깨짐

## 현재 상태
- [x] add() 구현 완료
- [x] subtract() 구현 완료
- [ ] multiply() 진행 중

매 루프가 끝날 때 에이전트는 AGENTS.md에 이번 루프에서 배운 것을 기록한다. 다음 루프의 에이전트는 이 파일을 읽고 시작하므로, 같은 실수를 반복하지 않는다.

이것은 파인튜닝과 근본적으로 다르다:

• 파인튜닝: 모델 가중치를 변경. 비싸고, 느리고, 되돌리기 어렵다.
• AGENTS.md: 텍스트 파일에 기록. 즉시 반영되고, git으로 추적되고, 누구나 읽을 수 있다.

“실패 자체가 정보다” — 에이전트의 실패한 시도는 “deterministically bad”이며, 이 정보가 다음 루프의 입력이 된다. 10회 이상 같은 태스크에서 실패하면 stuck으로 판단하고, 태스크를 더 작은 단위로 분할하여 재시도한다.

AGENTS.md 커뮤니티 합의 (2026년 초)

Ralph 루프 커뮤니티에서 AGENTS.md 작성에 대한 실전 합의가 형성되었다:

• 300줄 이하 유지 — 너무 길면 컨텍스트 창을 잡아먹어 오히려 성능이 떨어진다
• 린터가 할 수 있는 것은 CLAUDE.md에 넣지 말 것 — “세미콜론을 빼먹지 마라” 같은 규칙은 ESLint에 맡기고, AGENTS.md는 린터가 잡지 못하는 도메인 지식만 기록
• 자동 업데이트 메커니즘: harness.sh에서 테스트 실패 패턴을 자동으로 AGENTS.md에 append

# harness.sh에서 실패 패턴 자동 기록
if [ $EXIT_CODE -ne 0 ]; then
  ERROR_PATTERN=$(tail -5 test_output.log | head -1)
  echo "- Anti-Pattern: ${ERROR_PATTERN} (루프 #${ITERATION})" >> AGENTS.md
fi

이것이 “누적 학습”의 기계적 구현이다. 인간이 매번 수동으로 기록하는 것이 아니라, 하네스가 실패에서 패턴을 추출하여 자동으로 축적한다.

Fresh Context vs Continuous Session — Huntley의 선택

2026년 1월, Huntley와 Anthropic 사이에 흥미로운 “showdown”이 벌어졌다. Anthropic이 Ralph 루프를 위한 stop-hook 플러그인을 제안했는데, 이것은 연속 세션(같은 컨텍스트를 유지하며 반복) 방식이었다.

접근	방식	장점	단점
원래 Ralph	매 루프마다 새 세션	Context Rot 원천 차단, 결정론적	이전 시도의 맥락을 잃음
Anthropic 플러그인	연속 세션 내 반복	이전 시도를 기억, 빠른 수렴	Context Rot 위험, 비결정적

Huntley는 fresh context를 선택했다. 이유: “연속 세션에서 30번 실패하면 컨텍스트가 실패 이력으로 가득 차서 더 이상 유용한 추론이 불가능하다. 차라리 AGENTS.md에 핵심만 기록하고 매번 깨끗하게 시작하는 것이 낫다.”

이 트레이드오프는 5주차 Context Rot과 직결된다 — Ralph의 fresh context 전략이 곧 Context Rot 방지의 첫 번째 해법이다.

Claude Code /loop — 공식 자동화 루프

2026년 Anthropic이 Claude Code에 공식 탑재한 /loop 명령은 Ralph 루프 철학을 제품 수준으로 구현한 것이다. 수동 while 셸 스크립트 대신, 한 줄로 스케줄 기반 자율 에이전트를 띄울 수 있다.

# 기본 문법
claude /loop "<지시문>" --every <간격> --for <기간>

# 예: 2시간마다 테스트 실패를 찾아 수정, 최대 3일
claude /loop "check for failing tests and fix them" --every 2h --for 3d

cron job이 아니다

/loop는 단순 스케줄러가 아니다. 매 반복마다 git worktree (격리된 저장소 복사본)를 생성하고, CLAUDE.md를 다시 읽어 최신 컨텍스트를 반영한다. 실행 → 대기 → 재실행의 각 사이클이 독립적 에이전트 세션이다.

핵심 설계 원칙:

요소	설명
Worktree 격리	매 반복마다 git worktree로 메인 브랜치에 영향 없이 실행
CLAUDE.md = 제어면	매 사이클마다 CLAUDE.md를 읽으므로, 지시 파일 수정만으로 실행 중인 루프 동작 변경 가능
3일 만료	최대 --for 3d. 잊혀진 자율 에이전트의 컨텍스트 드리프트 방지를 위한 의도적 설계
3개 플래그	"지시문", --every, --for — 이것이 전체 API 표면

3일 만료가 기능인 이유: 화요일에 설정한 루프가 금요일까지 돌면, 그 사이 팀이 병합한 15개 PR과 충돌한다. 오래된 컨텍스트로 자신 있게 패치하는 에이전트는 원래 버그보다 디버깅이 어려운 문제를 만든다. 72시간마다 재평가하고 재시작하는 것이 안전하다.

검증된 워크플로우 3가지:

PR 감시

claude /loop "check open PRs on the current branch. If CI is failing,
read the error logs, fix the issue, and push. If CI passes and the PR
has no requested changes, post a comment saying 'Ready for human review.'
Summarize what you did in the PR description." --every 30m --for 2d

CI 파이프라인 감시, 린트/타입 에러 자동 수정, 준비 완료 시 알림. 비즈니스 로직 판단이 필요한 실패는 처리 못함.

의존성 모니터링

claude /loop "run pnpm audit. If any high or critical vulnerabilities exist,
create a branch, update the affected packages, run the test suite, and
open a PR if tests pass. Include the vulnerability details in the PR body."
--every 4h --for 3d

명확한 성공 기준(테스트 통과)과 최소한의 비즈니스 컨텍스트 — /loop에 이상적인 태스크.

일일 스탠드업

claude /loop "summarize all commits merged to main in the last 24 hours.
Include: PR titles, authors, files changed count, and any test coverage
changes. Write the summary as a Markdown standup update and save it to
./reports/standup-$(date +%Y-%m-%d).md" --every 24h --for 3d

수동 프로세스를 자동화. Slack MCP 연동 없이도 파일 출력으로 기본 기능 구현 가능.

/loop가 실패하는 경우:

• 모호한 태스크: “이 모듈을 더 유지보수하기 쉽게 리팩터링” — 매 반복마다 “유지보수 가능”을 다르게 해석
• 컨텍스트 드리프트: 빠르게 움직이는 코드베이스에서 worktree 분기 시점과 현재 main 간의 괴리
• 비용: 30분 간격 × 3일 = 144회 반복. 각 반복이 상당한 컨텍스트를 처리하면 API 비용이 누적됨

Ralph 루프 vs /loop

Ralph 루프(while :; do ... done)는 범용 패턴이다 — 어떤 AI 코딩 CLI에든 적용 가능하고, 하네스 로직을 직접 제어한다. /loop는 Claude Code 전용 공식 기능으로, worktree 격리와 스케줄링을 자동 처리하지만 Claude Code에 종속된다. 둘은 대체 관계가 아닌 보완 관계다.

---

RLM — 재귀적 LM 호출

문제: 긴 문서를 LLM에 넣으면 뒤쪽 내용을 놓친다

LLM의 context window가 200K 토큰이라 해도, 실제로 긴 문서를 넣으면 앞부분과 뒷부분에 비해 중간 내용의 이해도가 떨어진다 (“Lost in the Middle” 현상). 기존 해법은 두 가지였다:

1. RAG (Retrieval-Augmented Generation): 문서를 잘게 쪼개고 검색으로 관련 조각만 가져온다. 하지만 어떤 조각이 관련 있는지를 미리 알아야 한다 — 정보 손실이 불가피하다.
2. 요약: 긴 문서를 요약해서 넣는다. 하지만 요약 과정에서 세부 정보가 사라진다.

RLM의 해법: 모델이 자기 자신을 재귀 호출한다

RLM (Recursive Language Model)은 근본적으로 다른 접근이다. 긴 프롬프트를 Python REPL의 변수에 올려놓고, 모델이 코드를 짜서 필요한 부분만 골라 자기 자신을 재귀 호출한다.

핵심 아이디어: context window를 키우는 대신, 모델이 맥락을 어떻게 읽을지 스스로 결정하게 한다.

# RLM 의사코드 — 재귀 호출 패턴
def rlm_solve(question: str, documents: list[str]) -> str:
    """모델이 자기 자신을 재귀 호출하여 장문 문서를 처리한다."""

    # 1단계: 전체 문서를 Python 변수에 올린다
    context_vars = {f"doc_{i}": doc for i, doc in enumerate(documents)}

    # 2단계: 모델에게 "어떤 부분을 읽을지 결정하는 코드"를 짜라고 요청
    planning_code = llm_call(
        f"다음 질문에 답하기 위해 {len(documents)}개 문서 중 "
        f"어떤 부분을 읽어야 하는지 Python 코드로 작성하라.\n"
        f"질문: {question}"
    )

    # 3단계: 코드 실행 → 관련 부분만 추출
    relevant_parts = execute(planning_code, context_vars)

    # 4단계: 추출된 부분으로 자기 자신을 재귀 호출
    if fits_in_context(relevant_parts):
        return llm_call(f"질문: {question}\n맥락: {relevant_parts}")
    else:
        # 아직 크면 다시 재귀
        return rlm_solve(question, split(relevant_parts))

RLM의 성과와 의미

2025년 Zhang et al.의 실험 결과가 인상적이다: GPT-5-mini + RLM이 OOLONG 벤치마크에서 GPT-5 단독의 2배 이상 성능을 보였다. 더 작은 모델이 재귀 호출만으로 더 큰 모델을 능가한 것이다.

이것이 가능한 이유:

• 정보 손실 없음: RAG와 달리 원본 문서 전체가 변수에 있다. 모델이 필요할 때 언제든 접근 가능하다.
• 추적 가능: 재귀 궤적이 코드로 남는다. 모델이 왜 그 부분을 읽었는지, 어떤 논리로 답에 도달했는지 추적할 수 있다.
• 맥락 탐색 전략을 모델이 결정: 요약이나 검색 알고리즘이 아니라, 모델 자신이 “이 질문에 답하려면 문서의 어느 부분을 봐야 하는가”를 코드로 표현한다.

Ralph Loop과의 연결

Ralph Loop과 RLM은 같은 원리의 다른 적용이다:

비교 항목	Ralph Loop	RLM
반복 대상	코드 생성	맥락 탐색
호출 방식	셸 루프에서 반복 호출	모델이 자기 자신을 재귀 호출
검증 조건	테스트 통과 여부	답변 완성 여부
상태 저장	git + 파일시스템	Python REPL 변수
공통점	같은 모델을 반복 호출하여 test-time compute를 추론 품질로 전환

5주차 연결

수업에서 RLM을 직접 구현하지는 않지만, 원리를 이해하면 5주차 Context Rot 대응에 활용할 수 있다. Ralph의 “매번 새 context window”와 RLM의 “재귀적 맥락 탐색”은 context window 문제를 반대 방향에서 해결한다 — Ralph는 버리고, RLM은 탐색한다.

---

autoresearch — 자율 실험 루프

Karpathy의 autoresearch

Andrej Karpathy가 공개한 autoresearch는 ML 연구에 루프 패러다임을 적용한 것이다. 아이디어는 놀랍도록 단순하다:

1. train.py 하나를 에이전트에게 준다
2. 에이전트가 자유롭게 코드를 수정한다
3. 5분 고정 시간 예산 후 val_bpb(validation bits per byte)를 측정한다
4. 개선되면 commit, 아니면 reset
5. 밤새 반복하면 아침에 개선 이력이 git log에 축적되어 있다

program.md에 연구 방향만 적어두면, 에이전트가 구체적 실험 설계와 실행을 자율적으로 수행한다.

2026년 3월 7일 공개 후 21K GitHub 스타, 860만 뷰를 기록하며 루프 패러다임의 상징이 되었다. 코드는 630줄, 3개 파일이라는 극도의 단순성이 특징이다.

실전 결과 — 숫자로 보는 autoresearch

지표	수치
총 실험 수	~700회 (밤새 자동 실행)
발견된 최적화	20개
속도 개선	11%
코드 규모	630줄, 3파일

Shopify CEO Tobi Lütke가 자사 ML 파이프라인에 autoresearch를 적용한 결과, 37개 실험을 하룻밤에 실행하여 19% validation 개선을 달성했다. 인간 연구자가 일주일 걸릴 실험을 에이전트가 8시간 만에 끝낸 것이다.

이 결과는 “The Karpathy Loop”이라는 공식으로 정리된다:

agent + single modifiable file + single metric + fixed time limit = automated research

핵심은 제약의 설계다. 파일 하나, 메트릭 하나, 시간 하나 — 에이전트에게 자유도를 제한할수록 루프의 품질이 올라간다. 이것은 Ralph 루프의 “결정론적 검증 조건”과 정확히 같은 원리다.

핵심 설계 원칙

원칙	설명	왜 중요한가
고정 시간 예산	매 실험 5분으로 제한	공정한 비교. 한 실험이 40분 걸리면 다른 3개를 못 돌린다
git branch 기반	성공 = commit, 실패 = reset	실패한 실험의 부산물이 다음 실험을 오염시키지 않는다
단일 메트릭	val_bpb 하나만 측정	모호함 제거. “더 좋아졌는가?”에 숫자로 답한다
program.md	연구 방향 텍스트 파일	PROMPT.md와 동일한 역할. 인간이 전략을, 에이전트가 전술을

분산 연구 구상: SETI@home 패턴

Karpathy는 autoresearch의 미래를 분산 연구로 그린다. SETI@home이 외계 신호를 분산 탐색했듯, 수백 대의 에이전트가 각각 다른 실험을 병렬로 실행하고, 개선된 결과만 중앙 저장소에 merge한다. 한 에이전트가 발견한 개선이 다른 에이전트의 다음 실험 출발점이 된다.

Ralph Loop과의 연결

autoresearch와 Ralph Loop은 동일한 패턴이다:

비교 항목	Ralph Loop	autoresearch
대상	소프트웨어 코드	ML 학습 코드
검증 조건	테스트 통과	val_bpb 개선
상태 관리	git checkout .	git reset
지시 파일	PROMPT.md	program.md
핵심	결정론적 검증 + 루프 = 품질	결정론적 메트릭 + 루프 = 성능

차이는 검증 조건뿐이다. Ralph는 “코드가 테스트를 통과하는가”, autoresearch는 “val_bpb가 개선되는가”. 나머지 아키텍처 — 루프, git 기반 상태 관리, 텍스트 파일 지시 — 는 동일하다.

DGX에서 autoresearch 실행 시

우리 DGX에서 autoresearch 패턴을 실행할 때, 3주차에서 배운 MIG 슬라이스 활용이 핵심이다. 1g.10gb 슬라이스 하나에서 소규모 모델 실험을 반복하면, 다른 학생의 작업에 영향을 주지 않으면서 밤새 자율 실험을 돌릴 수 있다.

---

세 루프의 통합 — 공통 아키텍처

비교 테이블

항목	Ralph Loop	RLM	autoresearch
적용 영역	소프트웨어 개발	장문 맥락 이해	ML 실험
검증 조건	컴파일 + 테스트 통과	답변 완성도	val_bpb 수치
상태 저장	git + 파일시스템	Python REPL 변수	git branch
context 전략	매 루프 새 context (wiping)	재귀적 맥락 탐색	매 실험 새 context
실패 처리	git checkout .	재귀 분할	git reset
인간 역할	PROMPT.md 작성	질문 제시	program.md 작성

공통 3요소

세 루프가 공유하는 본질적 요소는 세 가지다:

1. 중요한 생각 — PROMPT.md, 질문, program.md. 인간이 “무엇을”을 정의한다.
2. 검증 조건이 명확한 루프 — 테스트, 답변 완성, val_bpb. 성공/실패가 결정론적으로 판정된다.
3. 충분한 토큰 예산 — 루프를 돌릴수록 test-time compute가 누적된다. 비용은 시간과 토큰이다.

이 세 요소가 갖춰지면, 어떤 영역이든 루프 패러다임을 적용할 수 있다.

하네스의 산업적 정의 — Guides vs Sensors

2026년 Martin Fowler / ThoughtWorks가 에이전틱 코딩에 대한 분석에서 하네스를 두 가지 구성요소로 분류했다:

구성	방향	역할	예시
Guides (가이드)	Feedforward	에이전트가 행동하기 전에 방향을 제시	PROMPT.md, CLAUDE.md, 린터 설정, 타입 정의
Sensors (센서)	Feedback	에이전트가 행동한 후에 결과를 측정	테스트 결과, 토큰 사용량, 에러 로그, val_bpb

이 프레임워크로 세 루프를 재분석하면:

• Ralph Loop: Guides = PROMPT.md + AGENTS.md, Sensors = 컴파일러 + 테스트 스위트
• RLM: Guides = 질문 프롬프트, Sensors = 답변 완성도 판정
• autoresearch: Guides = program.md, Sensors = val_bpb 메트릭

LangChain은 이를 더 축약하여 Agent = Model + Harness로 정의한다. 모델은 교체 가능하지만, 하네스는 도메인에 특화된 설계 결정의 집합이다.

루프의 경제학 — 언제까지 반복할 것인가

루프를 돌리는 데는 토큰 비용이 든다. 무한 반복은 비경제적이다. 실전에서는 손익분기점을 계산해야 한다.

반복당 토큰 비용 추정 (Sonnet 4.6 기준, 코드 수정 1회):

항목	토큰 수	비용
Input (시스템 프롬프트 + 코드 + 에러 로그)	~2,000	$0.03
Output (수정된 코드 + 설명)	~4,000	$0.30
반복당 합계	~6,000	~$0.33

시나리오	루프 비용	비교 대상	판정
10회 반복으로 버그 수정	$3.3	개발자 30분 ($25)	루프가 7.5배 저렴
50회 반복으로 리팩터링	$16.5	개발자 2시간 ($100)	루프가 6배 저렴
200회 반복, 수렴 실패	$66	개발자 2시간 ($100)	여전히 저렴하지만 비효율적

모델 선택 전략

T2 scaling이 시사하는 실전 전략:

• 쉬운 태스크 (문법 수정, 포맷팅): Haiku($1/$5 per 1M)로 100회 — 총 $0.60
• 표준 태스크 (버그 수정, 기능 추가): Sonnet으로 20회 — 총 $6.60
• 어려운 태스크 (아키텍처 변경): Opus로 5회 — 총 $4.50

작은 모델을 많이 돌리는 것이 큰 모델을 적게 돌리는 것보다 경제적인 경우가 많다.

다른 주차와의 연결

• Week-02 거버넌스: 루프가 외부 세계에 부작용을 남기는 순간이 Hard Interrupt 지점이다. Ralph 루프가 PR을 생성하거나, autoresearch가 모델 체크포인트를 공유 스토리지에 저장할 때, 2주차의 CUD 정책이 작동한다.
• Week-03 MIG/MCP: MIG가 루프의 컴퓨팅을 격리한다. 한 학생의 루프가 OOM을 일으켜도 다른 학생에게 영향이 없다. MCP가 루프 안에서 도구 접근을 표준화한다.
• Week-05 Context Rot: Ralph의 context wiping (매 루프 새 context)이 Context Rot 해법의 첫 번째 전략이다. 5주차에서 이를 체계적으로 다룬다.

---

실전 하네스 최적화 — 병렬 세션과 Worktree 격리

위에서 루프의 원리를 배웠다. 이제 루프를 빠르게, 안전하게, 대규모로 돌리는 실전 기법을 다룬다. Claude Code 창시자 Boris Cherny가 2026년 1-2월에 걸쳐 공개한 42개 팁은 개별 트릭이 아니라, 각 레이어가 이전 레이어를 전제하는 스택(stack) 구조다. 이 스택을 이해하면 Ralph 루프의 처리량을 한 자릿수에서 두 자릿수로 끌어올릴 수 있다.

병렬 세션 — 개발자 수준의 멀티플렉싱

Boris는 터미널에서 Claude Code 인스턴스 5개, claude.ai/code에서 5-10개를 동시에 운용한다. 멀티에이전트 파이프라인이 아니다. 한 명의 개발자가 여러 루프를 동시에 감독하는 실전 병렬성이다.

# tmux로 병렬 세션 구성
tmux new-session -s loops -d
for i in 1 2 3 4; do tmux split-window -t loops; done
tmux select-layout -t loops tiled

# 각 pane에서 독립 태스크 실행
# pane 0: claude "프론트엔드 컴포넌트 리팩터링"
# pane 1: claude "API 엔드포인트 테스트 작성"
# pane 2: claude "문서 업데이트"
# pane 3: claude "린트 에러 수정"
# pane 4: claude "성능 프로파일링"

핵심은 각 인스턴스가 독립적인 태스크를 처리한다는 점이다. 에이전트 간 통신은 없다. git이 유일한 조율 메커니즘이다 — 이것이 Ralph 루프의 모놀리식 철학의 자연스러운 확장이다.

병렬 세션의 실전 규칙

• 태스크 간 파일 겹침이 없어야 한다. 두 에이전트가 같은 파일을 수정하면 merge conflict가 발생한다.
• 각 세션에 별도 브랜치를 부여하거나, 같은 CLAUDE.md를 공유하되 태스크 범위를 명시한다.
• 5개를 넘기면 감독 비용이 생산성 이득을 초과한다. Boris의 경험칙: “터미널 5 + 웹 5-10”.

--worktree 플래그 — 네이티브 격리

앞서 /loop가 자동으로 worktree를 생성한다고 배웠다. --worktree 플래그는 이 격리를 ad-hoc 세션으로 확장한다.

# 기본: Claude에게 전용 worktree 부여
claude --worktree my_feature

# tmux 세션까지 자동 생성
claude --worktree my_feature --tmux

# 실전 패턴: 10개 병렬 에이전트로 마이그레이션
for module in auth billing users payments notifications \
              search analytics admin logging config; do
  claude --worktree "migrate-${module}" --tmux \
    "모듈 ${module}의 sync I/O를 async로 마이그레이션하라. \
     모든 테스트가 통과하면 PR을 올려라."
done

worktree 없이

# 위험: 모든 에이전트가 같은 working directory 공유
claude "auth 모듈 수정"     # ← 파일 충돌 위험
claude "billing 모듈 수정"  # ← 파일 충돌 위험
# 한 에이전트의 git checkout .이 다른 에이전트의 작업을 삭제할 수 있다

worktree 사용

# 안전: 각 에이전트가 독립된 파일시스템에서 작업
claude --worktree auth "auth 모듈 수정"
claude --worktree billing "billing 모듈 수정"
# 각 worktree는 독립 브랜치 → merge conflict는 PR 단계에서 해결

/loop의 worktree는 시간 기반 반복에 최적화되어 있고, --worktree는 병렬 태스크 분배에 최적화되어 있다. 둘은 보완 관계다.

/sandbox — 신뢰 기반 격리

3주차에서 배운 MIG는 GPU 컴퓨팅 격리였다 — 한 학생의 OOM이 다른 학생에게 전파되지 않는다. /sandbox는 BashTool의 파일 및 네트워크 접근을 격리하여 다른 관점의 보호를 제공한다.

관점	MIG (Week 3)	/sandbox (Week 4)
격리 대상	GPU 컴퓨팅	파일시스템 + 네트워크
목적	자원 보호 — 한 학생의 OOM 차단	신뢰 — 에이전트 편집의 빠른 수용
메커니즘	하드웨어 파티셔닝	BashTool 파일/네트워크 제한
효과	”이 프로세스는 내 GPU를 침범할 수 없다"	"이 에이전트가 실수해도 피해 범위가 명확하다”

Boris의 핵심 통찰: “When you trust the containment, you accept edits faster. That speeds up the whole loop.” 격리를 신뢰하면 매 루프의 human review 시간이 줄어들고, 루프 전체의 처리량이 올라간다.

격리의 두 레이어

MIG가 하드웨어를, /sandbox가 소프트웨어를 격리한다. 두 레이어가 함께 작동하면 루프의 격리가 완전해진다: DGX에서 MIG 슬라이스 안에서 /sandbox 모드로 Ralph 루프를 돌리면, GPU 자원도 파일시스템도 안전하다.

스택 철학 — 레이어가 쌓인다

Boris의 42개 팁이 교육적으로 가치 있는 이유는 메뉴가 아니라 스택이기 때문이다. 각 레이어는 이전 레이어를 전제한다:

BORIS STACK — 하네스 최적화 레이어

Layer 1: Plan Mode실행 전에 계획을 세운다

↓

Layer 2: CLAUDE.md프로젝트 규칙이 매 세션마다 주입된다

↓

Layer 3: Worktree 격리각 에이전트가 독립 파일시스템에서 작업한다

↓

Layer 4: 병렬 세션 + /sandbox격리된 에이전트를 동시에 여러 개 실행한다

↓

Layer 5: /loop + /batch시간 기반 자율 반복 + 대규모 일괄 처리

이 순서가 중요한 이유를 거꾸로 추적하면:

• /batch로 10개 모듈을 동시 마이그레이션하려면 → 각각 worktree 격리가 필요하다
• worktree에서 에이전트가 올바르게 동작하려면 → CLAUDE.md가 프로젝트 규칙을 주입해야 한다
• CLAUDE.md가 효과적이려면 → 에이전트가 실행 전에 plan mode로 계획을 세워야 한다

아래 레이어 없이 위 레이어만 쓰면 실패한다. Worktree 없이 병렬 세션을 돌리면 파일 충돌이 나고, CLAUDE.md 없이 worktree를 써봐야 에이전트가 프로젝트 규칙을 모른다.

Ralph 루프에서 Boris 스택으로

Ralph 루프 하네스(backpressure + GC + AGENTS.md)는 단일 루프의 품질을 보장한다. Boris 스택은 그 위에 루프의 처리량과 격리를 쌓는다. Ralph가 “어떻게 한 번의 루프를 잘 돌릴 것인가”라면, Boris는 “어떻게 열 개의 루프를 동시에 안전하게 돌릴 것인가”다.

Agentmaxxing — 다중 도구 병렬 실행

2026년 초부터 “Agentmaxxing”이라는 극단적 병렬화 전략이 등장했다. 한 repo에 여러 AI 코딩 도구를 동시에 투입하는 방식이다:

# 터미널 1: Claude Code (아키텍처 설계)
claude --worktree arch "모듈 구조 리팩터링"

# 터미널 2: Codex (테스트 작성)
codex --approval-mode full-auto "누락된 테스트 케이스 추가"

# 터미널 3: Gemini CLI (문서화)
gemini "API 문서를 코드에서 자동 생성"

Cursor 2.0은 이 패턴을 제품화하여 Background Agents(격리 VM에서 실행)와 Mission Control(병렬 에이전트 대시보드)을 도입했다. Codex CLI는 2026년 3월 기준 주간 160만 활성 사용자를 기록하며 오픈소스 하네스의 참조 구현이 되었다.

Agentmaxxing의 현실적 제약

• 머지 충돌 폭발: N개 에이전트가 같은 파일을 수정하면 충돌이 N² 규모로 증가
• 토큰 비용 선형 증가: 3개 도구 동시 실행 = 비용 3배
• 일관성 리스크: 각 도구가 다른 코딩 스타일을 적용하면 코드베이스가 분열
• 해법: 에이전트별 담당 영역(모듈/파일)을 명확히 분리하고, CLAUDE.md/AGENTS.md로 스타일 통일

---

실전 검증 — 코드 한 줄 안 쓰고 프로덕트 만들기

여기까지 이론과 기법을 배웠다. 그렇다면 실제로 루프만으로 프로덕션 소프트웨어를 만들 수 있는가? 2026년 3월, OpenAI가 Codex 에이전트만으로 내부 프로덕트를 구축한 사례가 그 답을 제시한다.

Codex “Zero Manual Code” 사례

OpenAI 엔지니어링 팀이 Codex를 사용하여 내부 프로덕트를 구축했다:

• 1M+ LOC 자동 생성
• 수동으로 작성된 코드 0줄
• 인간은 요구사항 정의, 아키텍처 리뷰, PR 승인만 수행

이 과정에서 도출된 5대 패턴은 하네스 엔지니어링의 실전 교범이다:

패턴	원칙	Ralph Loop 관점
Repo as System of Record	코드 = 단일 진실 소스. 구두 합의나 Wiki가 아닌 코드에 모든 결정을 반영	PROMPT.md + AGENTS.md가 이 역할을 수행
Application Legibility	에이전트가 읽을 수 있는 코드 작성. 변수명, 타입, 주석이 명확해야 에이전트가 올바르게 수정	backpressure의 전제 조건 — 린터와 타입 체커가 코드를 읽을 수 있어야 작동
Layered Domain Architecture	도메인 레이어를 명확히 분리. 한 레이어 변경이 다른 레이어에 전파되지 않도록	병렬 worktree의 전제 — 모듈이 분리되어야 병렬 수정이 가능
Minimal Merge Gates	머지 게이트를 최소화. 자동 테스트 통과 시 바로 머지	루프 속도의 핵심 — 승인 대기 시간이 루프 효율을 결정
Entropy Management	코드베이스의 무질서(엔트로피)를 능동적으로 관리. 기술 부채 축적을 루프로 방지	/simplify 패턴 — 별도 에이전트가 주기적으로 코드 품질을 정리

이것은 미래가 아니라 2026년 3월의 현실이다

“AI가 코드를 다 작성한다”는 추상적 비전이 아니다. 1M줄 규모의 프로덕션 소프트웨어가 이미 루프 패러다임으로 만들어졌다. 우리가 이번 학기에 배우는 하네스 엔지니어링은 이 현실의 기초 기법이다.

---

강의 중 토론 질문

1. Ralph의 “매번 새 context”와 RLM의 “재귀 호출”은 context window 문제를 반대 방향으로 해결한다. 이 둘을 결합할 수 있는가? 어떤 형태가 될 것인가?
2. autoresearch의 5분 고정 예산은 왜 중요한가? 예산 없이 “개선될 때까지 돌리면” 어떤 문제가 생기는가?
3. Ralph 루프에서 AGENTS.md에 학습 내용을 기록하는 것과 모델을 파인튜닝하는 것의 차이는 무엇인가? 각각의 장단점은?
4. 당신이 잠든 8시간 동안 100번의 루프를 돌린다면, 어떤 태스크에 적용하겠는가? 검증 조건은 무엇으로 설정하겠는가?
5. 루프 패러다임의 한계는 무엇인가? 어떤 문제는 반복해도 풀리지 않는가?
6. Boris의 스택에서 CLAUDE.md 없이 worktree만 사용하면 어떤 문제가 생기는가? 반대로, worktree 없이 CLAUDE.md만 사용하면? 레이어 간 의존성을 구체적 시나리오로 설명하라.
7. /sandbox의 목적이 보안이 아니라 신뢰라는 주장에 동의하는가? 격리가 “신뢰를 높인다”는 것이 구체적으로 어떤 행동 변화를 의미하는지 토론하라.
8. SWE-bench Verified 80.9%인 모델이 Pro에서 45.9%로 떨어진다. 하네스 없이 모델만으로 이 35pp 갭을 메울 수 있을까? 만약 모델 크기를 2배로 키워도 갭이 줄지 않는다면, 이것은 무엇을 의미하는가?
9. Codex가 1M줄을 자동 생성했다면, 프로그래머의 역할은 무엇인가? 5대 패턴 중 “Application Legibility”가 시사하는 것은 — 에이전트가 읽기 쉬운 코드를 작성하는 능력이 프로그래머의 새로운 핵심 역량이 되는가?

---

실습 (Practicum)

Ralph 루프 구현과 누적 학습

오늘 실습의 목표

PROMPT.md와 AGENTS.md를 포함한 Ralph 하네스를 직접 구축하고, 최소 3회 루프를 실행하여 실패→학습→성공 사이클을 경험한다.

1. 프로젝트 구조 설정

   mkdir ralph-project && cd ralph-project
   git init
   touch PROMPT.md AGENTS.md
   mkdir tests

2. PROMPT.md 작성

   # 현재 태스크
   아래 항목을 순서대로 구현하라:
   - [ ] calculator.py에 add(a, b) 함수 구현
   - [ ] calculator.py에 subtract(a, b) 함수 구현
   - [ ] calculator.py에 divide(a, b) 함수 구현 (ZeroDivisionError 처리)
   
   # 제약 사항
   - 한 번에 하나의 함수만 구현
   - 모든 함수에 타입 힌트 포함
   - 테스트 없이 코드 작성 금지
   - tests/test_calculator.py에 테스트 작성 후 구현
   
   # 상태 추적
   - AGENTS.md의 학습 기록을 반드시 읽고 시작할 것
   - 실패 시 AGENTS.md에 실패 원인 기록 후 종료할 것
   - 성공 시 AGENTS.md에 성공 패턴 기록 후 다음 태스크로 진행

3. harness.sh 작성 — backpressure + garbage collection

   #!/bin/bash
   # harness.sh — Ralph 루프 하네스
   
   set -e
   MAX_RETRIES=10
   RETRY_COUNT=0
   
   while true; do
     echo "=== Ralph Loop #$((RETRY_COUNT + 1)) ==="
   
     # 에이전트 실행
     cat PROMPT.md | claude-code
   
     # Backpressure: 타입 체크 + 테스트 실행
     if python -m py_compile calculator.py 2>/dev/null && \
        python -m pytest tests/ -q 2>/dev/null; then
       echo "Tests passed — committing and moving on"
       git add -A && git commit -m "loop $((RETRY_COUNT + 1)): task completed"
       RETRY_COUNT=0
     else
       echo "Tests failed — garbage collection + retry"
       RETRY_COUNT=$((RETRY_COUNT + 1))
   
       # Stuck 탐지
       if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
         echo "STUCK: $MAX_RETRIES consecutive failures. Splitting task."
         echo "- STUCK at loop $RETRY_COUNT: $(date)" >> AGENTS.md
         git add AGENTS.md && git commit -m "stuck: recorded failure pattern"
         RETRY_COUNT=0
       fi
   
       # Garbage Collection — 실패 코드 제거
       git checkout -- calculator.py tests/ 2>/dev/null || true
       sleep 2
     fi
   done

4. AGENTS.md 누적 학습 구조 초기화

   # AGENTS.md — 누적 학습 기록
   
   ## 학습된 패턴
   (루프 실행 후 자동으로 채워짐)
   
   ## 금지 패턴
   (반복 실패에서 학습한 안티패턴)
   
   ## 진행 상태
   - [ ] add() 구현
   - [ ] subtract() 구현
   - [ ] divide() 구현

5. 실행 및 관찰 — 최소 3회 루프

   chmod +x harness.sh
   ./harness.sh

   관찰 포인트:

   • 에이전트가 AGENTS.md를 읽고 시작하는가?
   • 실패 후 AGENTS.md에 학습 내용이 기록되는가?
   • 다음 루프에서 같은 실수를 반복하지 않는가?
   • git log --oneline으로 성공 커밋만 남아있는가?

6. autoresearch 패턴 미니 실험 (선택)

   간단한 Python 함수의 실행 시간을 최적화하는 autoresearch 패턴:

   mini_autoresearch.sh

   #!/bin/bash
   BEST_TIME=999
   
   while true; do
     # 에이전트가 optimize.py를 수정
     cat program.md | claude-code
   
     # 5분 시간 제한으로 벤치마크 실행
     CURRENT_TIME=$(timeout 300 python benchmark.py 2>/dev/null || echo 999)
   
     if (( $(echo "$CURRENT_TIME < $BEST_TIME" | bc -l) )); then
       echo "Improved: $BEST_TIME -> $CURRENT_TIME"
       BEST_TIME=$CURRENT_TIME
       git add -A && git commit -m "improved: time=$CURRENT_TIME"
     else
       echo "No improvement ($CURRENT_TIME >= $BEST_TIME) — reset"
       git checkout .
     fi
   done

실습 체크리스트

• PROMPT.md에 3개 이상의 태스크가 명세되어 있는가?
• AGENTS.md에 최소 2회 이상의 학습 기록이 남아있는가?
• harness.sh가 backpressure (테스트 실행)와 garbage collection (git checkout .)을 모두 구현하는가?
• git log에 성공 커밋만 남아있는가? (실패한 코드가 커밋되지 않았는가?)
• 실패→학습→재시도→성공 과정이 터미널 로그에서 확인되는가?
• stuck 탐지 로직이 존재하는가? (선택)

---

과제 (Assignment)

Lab 04: Ralph 루프 구현

제출 마감: 2026-03-31 23:59

제출 경로: assignments/week-04/[학번]/

필수 요구사항 (5개):

1. harness.sh — backpressure + garbage collection 포함 Ralph 하네스
2. PROMPT.md — 최소 3개 태스크 명세
3. AGENTS.md — 루프 실행 후 누적된 학습 기록 (최소 2회 실패 후 성공 과정이 보일 것)
4. 루프 실행 로그 — 실패→학습→재시도 과정이 보이는 터미널 로그 (loop_log.txt)
5. README.md — 하네스 설계 결정 사항 + test-time compute scaling과의 연결 설명

가산점 요소 (5개):

1. autoresearch 패턴 미니 구현 — Python 함수 최적화, 고정 시간 예산 포함
2. stuck 탐지 로직 — N회 연속 실패 시 태스크를 더 작은 단위로 분할하여 재시도
3. 루프 메트릭 수집 — 회차별 토큰 사용량, 성공률, 소요 시간을 CSV/JSON으로 기록
4. Claude Code /loop 실행 후 worktree 격리 동작 분석 보고서
5. RLM 원리를 활용한 장문 문서 분석 실험 — README에 결과와 고찰 포함

평가 포인트:

• Garbage Collection 메커니즘 정상 동작
• AGENTS.md 누적 학습이 실제로 다음 루프에 반영되는 증거
• 에러 로그 패키징과 상태 추적 파일 활용

핵심 정리

1. Test-time compute scaling: 모델을 키우지 않고 추론 시점에 연산을 더 쓰면 성능이 올라간다. 세 가지 루프는 모두 이 원리의 구현이다.
2. Ralph Loop = 하네스 + 루프: 하네스(backpressure + garbage collection)가 비결정적 에이전트를 결정론적으로 통제한다. AGENTS.md가 누적 학습을 가능하게 한다.
3. RLM = 재귀적 맥락 탐색: 모델이 자기 자신을 재귀 호출하여 긴 문서를 처리한다. 정보 손실 없이 맥락을 탐색하며, 재귀 궤적이 코드로 남는다.
4. autoresearch = 자율 실험 루프: 고정 시간 예산 + 단일 메트릭 + git 상태 관리. Ralph와 동일한 패턴이되 검증 조건만 다르다.
5. 공통 3요소: 중요한 생각(지시 파일) + 명확한 검증 조건(루프) + 충분한 토큰 예산. 이것이 갖춰지면 어떤 영역이든 루프를 적용할 수 있다.
6. 인프라 연결: 2주차 거버넌스가 루프의 안전 경계, 3주차 MIG가 컴퓨팅 격리, MCP가 도구 표준화. 5주차 Context Rot 해법의 출발점이 Ralph의 context wiping이다.

더 읽을거리

• Ralph Loop Playbook — Huntley의 Ralph 루프 방법론 상세 가이드
• RLM Paper (arXiv:2502.09382) — Recursive Language Model 논문
• autoresearch Repository — Karpathy의 자율 ML 연구 루프
• OpenAI: Learning to Reason with LLMs — o1과 test-time compute scaling
• Anthropic: Claude Code /loop Documentation — Claude Code 공식 루프 문서
• Snell et al. (2024): Scaling LLM Test-Time Compute — test-time compute scaling 이론 논문
• T2 Scaling Laws (2026) — 추론 비용을 고려한 최적 사전학습 전략
• SWE-bench Pro — 현실적 난이도의 코딩 에이전트 벤치마크
• Martin Fowler: AI Coding Agents — Guides vs Sensors 프레임워크, 하네스 차원 분석