Stop Using The Ralph Loop Plugin

요즘 Claude Code 커뮤니티에서 RALF Wiggum 플러그인이 화제다. YouTube 영상마다 "AI가 혼자서 태스크를 10번씩 반복해서 끝내준다!"는 식의 소개가 넘쳐나고 있다. 

그런데, 재미있는 유투브 영상을 하나 찾았다. Claude Code의 RALF 루프를 사용하지 말라는 건데, 내용을 보면 다음과 같다. 

 

 

지금 사람들이 열광하는 그 Claude Code 플러그인은 진짜 RALF Loop가 아니다.

RALF 프레임워크를 만든 창시자 본인이 Twitter와 YouTube에서 며칠째 이 점을 직접 지적하고 있다. 원본 RALF Loop와 Claude Code의 RALF Wiggum 플러그인은 겉으로는 비슷해 보이지만, 핵심 동작 방식에서 중요한 차이가 있다고 말이다.

그렇다면, 진짜 RALF Loop란 무엇이고 Claude Code 플러그인은 어디서 어긋나는 걸까? 그리고 진짜 RALF Loop를 직접 구현하려면 어떻게 해야 할까?

RALF Loop란 무엇인가

창시자의 블로그에서 직접 설명하길, "RALF는 테크닉이고, 가장 순수한 형태로는 bash loop다"라고 한다. 핵심을 한 줄로 정리하면 이렇다.]

AI 시스템이 동일한 태스크를 성공할 때까지 반복적으로 시도하게 만드는 while loop

코드 한 줄로 표현할 수 있을 만큼 개념 자체는 단순하다. 하지만 그 구현 방식에 모든 차이가 있다.

RALF Loop의 동작 흐름

전체 흐름은 이렇게 된다. 먼저 아이디어에서 시작해서 PRD(Product Requirements Document)를 만든다. Claude Code와 대화하면서 만들고 싶은 것을 prd.md 파일로 구체화하는 것이다. 단순한 아이디어를 feature 목록으로 쪼개고, 각 feature를 다시 discrete task 단위로 분해한다. 예를 들어 "칸반 보드를 만들고 싶다"는 아이디어가 있다면, task 1은 "편집 버튼", task 2는 "삭제 버튼", task 3은 "드래그앤드롭" 식으로 구체적인 단위로 나눈다.

PRD가 준비되면 RALF Loop가 시작된다. 동작 방식은 이렇다.

• Task 단위 실행: PRD에서 아직 완료되지 않은 첫 번째 task를 찾아 작업을 시작한다.
• 완료 시: PRD에 해당 task를 완료 표시([x])하고, progress.md에 "이번 session에서 A, B, C를 했다"는 내용을 기록한다.
• 실패 시: progress.md에 "A, B, C를 시도했고 에러 1, 2, 3이 났다"고 기록한 뒤, 다음 iteration에서 이 맥락을 참고해 D, E, F를 시도한다.
• 반복: 기본값 10 iteration까지 자동으로 반복한다.

그런데 이 전체 흐름에서 가장 중요한 부분이 하나 있다. 바로 매 iteration마다 새로운 session을 시작한다는 것이다. 이게 핵심이다. 그리고 바로 여기서 플러그인과 원본의 길이 갈린다.

Context Rot: 왜 새 Session이 그렇게 중요한가

RALF Loop의 진짜 힘은 반복 자체가 아니다. 매 iteration마다 새로운 Claude Code 인스턴스를 띄워서 완전히 fresh한 context window에서 시작한다는 것이다.

왜 이게 중요할까? Context rot 때문이다.

Context rot란, LLM이 대화가 길어질수록, 즉 context window가 채워질수록 성능이 점점 떨어지는 현상이다. 여러 LLM을 대상으로 한 연구에서 반복적으로 확인된 사실이다. 특정 드롭오프 지점이 딱 정해져 있지는 않지만, Claude Code 기준으로 대략 100,000 token을 넘어서면 성능이 눈에 띄게 나빠지기 시작한다. 전체 context window가 200k token이니, 절반 지점부터는 이른바 "멍청한 구간"에 접어든다고 보면 된다.

그래서 RALF Loop는 각 task를 항상 0 token에서 시작한다. 이전 session의 맥락은 LLM의 기억이 아니라 progress.md 파일에 텍스트로 기록해서 전달한다. LLM의 메모리가 아니라 파일이 상태를 관리하는 셈이다. 항상 context window의 "똑똑한 구간"에서만 작업하는 것이다.

마치 긴 회의를 한 번에 끝내는 게 아니라, 매 회의마다 이전 회의록을 보고 다시 시작하는 방식과 비슷하다. 사람도 오래 앉아 있으면 집중력이 떨어지듯이, LLM도 context가 쌓이면 성능이 떨어진다.

Claude Code 플러그인은 무엇이 다른가

그렇다면 플러그인은 어떻게 동작하는가. Claude Code의 RALF Wiggum 플러그인 소스코드를 보면 명시적으로 이렇게 동작한다.

Claude Code가 task를 작업하다가 exit를 시도하면, 플러그인이 그 exit를 막고 같은 session에서 계속 작업을 이어간다.

즉, 새 session을 시작하지 않는다. 결과적으로 매 iteration마다 context window가 계속 누적된다. 한 session에서 계속 작업하다가 150,000 token쯤에서 auto compact가 발동하고, 그때서야 context가 정리된다.

당연히 단점도 있다. 각 iteration을 fresh한 context로 시작한다는 RALF의 핵심 장점이 사라진다. 멍청한 구간에서 더 오래 작업하게 되고, context rot의 영향을 고스란히 받는다.

반복 횟수(10번)가 힘이 아니다. Fresh context window가 힘이다. 플러그인은 반복은 하지만 fresh context는 포기한 셈이다. 10번 반복이 의미 있으려면, 매번 새롭고 명확한 두뇌로 시작해야 한다.

Claude Code에서 진짜 RALF Loop 구현하기

그렇다면 플러그인 없이 원본 RALF Loop를 구현하려면 어떻게 해야 할까? 필요한 것은 두 가지다.

• ralf.sh: 새 Claude Code 인스턴스를 반복 실행하는 bash 스크립트
• prd.md: 완료 여부가 표시된 task 목록 파일

두 파일 모두 커뮤니티를 통해 공유되고 있으니, 직접 구하거나 Claude Code를 통해 생성하면 된다.

PRD 파일 만들기

PRD 파일 형식이 중요하다. 스크립트가 체크박스 상태를 보고 다음에 작업할 task를 결정하기 때문이다. 아래와 같이 체크박스 형식으로 task를 나열하면 된다.

## Tasks

- [ ] Task 1: 프로젝트 초기화 및 데이터베이스 설정
- [ ] Task 2: 칸반 보드 UI 구현
- [ ] Task 3: 드래그앤드롭 기능 추가

완료된 task는 스크립트가 자동으로 체크 표시를 채운다.

- [x] Task 1: 프로젝트 초기화 및 데이터베이스 설정
- [ ] Task 2: 칸반 보드 UI 구현

Claude Code의 /prd skill을 이용하면 대화를 통해 PRD를 자동으로 생성해준다. 아니면 plan mode에서 직접 만들어도 된다. 중요한 건 파일명이 반드시 prd.md여야 하고, 명확한 체크박스 task 목록이 있어야 한다는 것이다.

progress.md 파일도 필요하다. 처음에는 빈 파일이어도 된다. 각 session이 끝날 때 스크립트가 진행 상황을 여기에 기록한다.

스크립트 실행

스크립트를 프로젝트 폴더에 넣고 새 터미널을 열어서 실행하면 된다.

bash ralf.sh

기본값은 10 iteration이다. task가 많아서 더 많이 돌리고 싶다면 숫자를 뒤에 붙여주면 된다.

bash ralf.sh 50

실행하면 이런 식으로 진행 상황이 출력된다.

Starting RALF - max 10 iterations
Iteration 001 complete. 44 tasks remaining.
Iteration 002 complete. 43 tasks remaining.
...

실제 진행 상황의 source of truth는 prd.md다. 체크박스가 하나씩 채워지는 걸 보면 된다. 이후로는 그냥 자리를 비워도 된다. 스크립트가 PRD 끝까지 알아서 돌아간다.

한 가지 주의할 점이 있다. iteration 수는 "task 개수"가 아니라 "총 시도 횟수"다. task가 20개인데 iteration을 10으로 설정하면, 모든 task가 한 번에 성공한다고 가정하더라도 10개밖에 처리를 못한다. task가 많다면 iteration 수를 넉넉하게 잡아야 한다.

GSD vs RALF, 무엇을 쓸까

비슷한 컨셉으로 GSD(Get Shit Done) 방식도 있다. 둘 다 task를 discrete하게 쪼개고 fresh context window를 활용한다는 기본 철학은 같다. 차이라면 GSD는 사용자가 중간에 직접 개입해서 테스트하고 확인하는 과정이 더 많이 포함된다.

URL : https://github.com/gsd-build/get-shit-done

GitHub - gsd-build/get-shit-done: A light-weight and powerful meta-prompting, context engineering and spec-driven development sy

개인적으로는 GSD가 좀 더 손에 잡히는 느낌이다. 완전한 자동화를 바로 믿기보다 중간중간 눈으로 확인하면서 가고 싶은 사람이라면 GSD가 더 맞을 수 있다. RALF Loop는 진짜로 자리를 비워두고 싶을 때 쓰기 좋다. 어느 쪽이든 크게 틀리지 않는다. 어떤 방식을 선택하든 context window를 관리한다는 핵심 철학을 공유하고 있기 때문이다.

정리하며

RALF Wiggum 플러그인이 쓸모없다는 뜻이 아니다. 다만 한계를 알고 쓰는 것과 모르고 쓰는 건 다르다. 플러그인은 반복을 해주긴 하지만, RALF의 진짜 힘인 fresh context window를 포기했다는 점은 알고 있어야 한다.

결국 context window 관리가 곧 LLM 코딩의 퀄리티 관리다. 아무리 좋은 모델도 context가 반쯤 차면 성능이 떨어진다. 이 점을 이해하면 왜 RALF Loop 같은 접근이 의미 있는지 자연스럽게 납득이 된다.