Ralph Loop - AI 코딩 에이전트를 Bash 루프에 넣었더니 자고 일어나면 코드가 완성돼 있다

요즘 AI 코딩 도구 얘기가 많다. Claude Code, Cursor, Windsurf, Copilot. 다 써봤고, 다 좋다. 근데 이걸로 뭘 하냐가 문제다.

대부분 이렇게 쓴다.

1. 프롬프트 입력
2. 결과 확인
3. 수정 요청
4. 다시 확인
5. 반복

사람이 루프의 일부다. 내가 확인하고, 내가 판단하고, 내가 다시 지시한다. 이걸 자동화하면 어떨까?

2024년 2월, 호주의 개발자 Geoffrey Huntley가 정확히 그걸 했다.

while :; do cat PROMPT.md | claude-code ; done

이게 전부다. Bash 루프 한 줄.

이 기법 이름이 Ralph Loop이다. (정식 명칭은 Ralph Wiggum Loop)

 

이름의 유래

Ralph Wiggum은 심슨 가족에 나오는 캐릭터다. 좀 멍청하고, 좀 엉뚱하고, 근데 절대 포기하지 않는다.

Huntley가 이 기법을 처음 발견했을 때, 업계의 미래가 보여서 구역질이 났다고 한다. 영어로 구역질하다가 "ralph"다. 거기서 이름을 따왔다.

좀 멍청하고, 좀 엉뚱하고, 절대 포기 안 하는 AI 에이전트. 그리고 이걸 발견했을 때의 구역질. 이중 의미다.

 

어떻게 동작하나

핵심 개념은 간단하다.

1. 스펙 문서(PROMPT.md)를 작성한다
2. AI 코딩 에이전트(Claude Code, Amp 등)에 넣는다
3. 에이전트가 작업을 하나 수행한다
4. 컨텍스트 윈도우를 리셋한다
5. 같은 스펙을 다시 넣는다
6. 반복

매 루프마다 새로운 컨텍스트 윈도우로 시작한다는 게 핵심이다.

왜 이게 중요하냐. LLM에는 "컨텍스트 부패(context rot)"라는 문제가 있다. 대화가 길어지면 모델의 주의력이 분산된다. 초반에 했던 말을 잊어버리고, 엉뚱한 방향으로 빠진다. 코드 품질이 떨어진다.

Ralph Loop는 이걸 우회한다. 매번 깨끗한 상태에서 시작하니까. 마치 개발자가 집중력 높은 상태로 짧은 세션만 반복하는 것과 같다.

차이점은 AI는 피로하지 않는다는 것

 

핵심 원칙: 루프당 하나

Huntley가 반복적으로 강조하는 게 있다.

루프당 작업 하나. 딱 하나.

컨텍스트 윈도우는 약 170K 토큰이다. 스펙 문서를 로드하면 그만큼 잡아먹는다. 여기에 작업을 여러 개 넣으면 윈도우가 빡빡해지고, 품질이 떨어진다.

그래서 하나만 시킨다. 대신 뭘 할지는 에이전트가 판단한다. 프롬프트에 이렇게 쓴다.

Follow the @fix_plan.md and choose the most important thing.

 

"가장 중요한 걸 골라서 해." LLM이 생각보다 이런 판단을 잘한다.

 

스펙이 코드보다 중요하다

Ralph Loop에서 진짜 자산은 코드가 아니라 스펙 문서다.

프로젝트 시작 전에 LLM과 대화하면서 요구사항을 정리한다. 구현을 시키는 게 아니라, 요구사항에 대한 깊은 대화를 한다. 그 결과물을 파일별로 쪼개서 specs 디렉토리에 저장한다.

매 루프마다 이 스펙을 컨텍스트에 할당한다. Huntley는 이걸 "결정적 컨텍스트 할당(deterministic context allocation)"이라고 부른다. 매 루프의 시작 상태가 동일하다는 뜻이다.

코드는 도자기 물레 위의 점토다. 마음에 안 들면 다시 빚으면 된다. 하지만 스펙은 유지된다.

 

실제 성과

Huntley는 이 기법으로 이런 걸 했다.

• HashiCorp Nomad를 클론했다. 소스 코드를 스펙으로 변환하고, 그 스펙으로 기능적으로 동등한 구현체를 재생성했다. 며칠 만에.
• Tailscale을 재구축했다.
• "CURSED"라는 새로운 프로그래밍 언어를 만들었다. 컴파일러 포함. LLM 학습 데이터에 없는 언어를 만들고, 그 언어로 프로그래밍까지 시켰다.
• 누군가는 5만 달러짜리 외주 계약을 Ralph Loop로 297달러에 납품했다.

비용? Sonnet 모델 기준으로 시간당 약 10달러. 최저임금보다 싸다.

 

프론트엔드 개발자 입장에서

이전에 작성한 "모바일 청첩장" 글에서 Lighthouse 점수 최적화하느라 이미지 포맷 변환, 레이지 로딩, 폰트 최적화 같은 작업을 수동으로 하나씩 했다. 이런 종류의 반복적인 최적화 작업이 Ralph Loop의 좋은 활용 사례다.

예를 들어 리팩토링. 코딩 표준 문서를 작성하고, "이 코드베이스를 표준에 맞춰"라는 프롬프트로 Ralph를 돌리면 된다. 실제로 HumanLayer의 Dex Horthy는 REACT_CODING_STANDARDS.md를 작성한 뒤 6시간 동안 Ralph를 돌려서 전체 프론트엔드 코드를 리팩토링했다.

FSD 아키텍처처럼 레이어 간 의존성 규칙이 엄격한 구조에서는 특히 유용할 수 있다. 위반 사항을 찾아서 고치는 반복 작업을 루프에 맡길 수 있으니까.

 

주의할 점

Ralph는 만능이 아니다.

보안: Ralph는 자율적으로 돌아가려면 --dangerously-skip-permissions가 필요하다. 이름에서 느껴지듯이 위험하다. 반드시 격리된 환경(Docker, Fly Sprites 등)에서 돌려야 한다. 자기 로컬 머신에서 sudo 권한으로 돌리면 안 된다.

품질 관리:. Huntley의 표현을 빌리면 Ralph는 "결정적으로 나쁘다(deterministically bad)." 매번 같은 패턴으로 실패한다. 그래서 실패 패턴을 관찰하고, 프롬프트에 가드레일을 추가하는 튜닝 과정이 필수다. 기타 튜닝하듯이.

기존 코드베이스: 그린필드(새 프로젝트)에서 가장 잘 동작한다. 기존 코드베이스에서는 변경 범위를 작게 유지해야 한다. 밤새 돌려서 50개 리팩토링 PR이 쌓이면 오히려 감당이 안 된다. 하루에 작은 리팩토링 하나씩 쌓이는 게 낫다.

 

"소프트웨어 개발"과 "소프트웨어 엔지니어링"

Huntley는 이 둘을 명확히 구분한다.

• 소프트웨어 개발(Development): 키보드로 코드를 타이핑하는 것. 스펙을 구현하는 것. JIRA 티켓을 처리하는 것.
• 소프트웨어 엔지니어링(Engineering): 시스템을 설계하는 것. 실패 시나리오를 관리하는 것. 에이전트가 안전하게 동작할 수 있는 환경을 만드는 것.

Ralph Loop가 보여주는 건 전자가 자동화 가능하다는 것이다. 후자는 오히려 더 중요해진다.

에이전트가 4만 줄짜리 PR을 몇 시간 만에 생성하면, 전통적인 코드 리뷰는 불가능하다. 그래서 자동화된 테스트, 린터, 타입 시스템 같은 피드백 루프를 설계하는 게 엔지니어의 일이 된다.

 

정리

Ralph Loop는 기법이지 도구가 아니다.

어떤 AI 코딩 도구든 Tool call 제한이 없으면 쓸 수 있다. Claude Code, Amp, 뭐든

핵심은 세 가지다.

1. 매 루프마다 깨끗한 컨텍스트로 시작한다 (context rot 방지)
2. 루프당 작업 하나만 시킨다 (컨텍스트 효율)
3. 스펙 문서가 코드보다 중요하다 (결정적 할당)

복잡한 멀티 에이전트 아키텍처가 아니다. Bash 루프 한 줄이다.

Huntley의 말처럼 "멍청한 것도 놀라울 정도로 잘 동작할 수 있다면, 똑똑한 버전은 어떨까?"

이 기법이 의미하는 바는 꽤 크다. 다만 Ralph Loop 하나만으로는 부족한 부분이 있다. 매 루프에서 얻은 학습을 다음 루프에 어떻게 전달할 것인가, 에이전트가 생성한 코드의 품질을 어떻게 체계적으로 보장할 것인가 같은 문제가 남아 있다. 이런 문제를 다루는 방법론이 Compound Engineering과 Harness Engineering이다.

 

참고:

• Geoffrey Huntley 블로그: https://ghuntley.com/ralph/
• Ralph Loop 공식 가이드: https://github.com/ghuntley/how-to-ralph-wiggum
• snarktank/ralph 구현체: https://github.com/snarktank/ralph