Claude Code를 쓰다 보면 이런 순간이 자주 옵니다.

"성공적으로 완료했습니다."

그런데 막상 테스트를 돌려보면 실패합니다. 린트를 돌려보면 에러가 남아 있고, 브라우저 검증을 해보면 UI가 깨져 있는 경우도 있죠. 문제는 여기서부터입니다. 사람이 다시 에러를 복붙해서 "이거 고쳐줘"를 반복해야 합니다. 이 귀찮은 루프를 Claude에게 조금 더 넘기려는 시도 중 하나가 Ralph Loop입니다.

이번 영상에서 설명하는 Ralph Loop는 단순히 "테스트까지 돌려줘" 같은 강한 프롬프트가 아닙니다. 더 정확히는, Claude가 끝났다고 판단하는 순간 다시 검사하고, 통과하지 못하면 같은 프롬프트를 다시 먹이는 반복 구조에 가깝습니다.

1. Ralph Loop의 핵심은 "끝났다고 한 순간 다시 물어보는 것"

영상에서 말하는 구조를 풀어 쓰면 이렇습니다.

1. Claude가 과제를 수행한다

2. Claude가 스스로 "끝났다"고 판단한다

3. \`stop hook\`이 개입한다

4. 우리가 정한 기준에 통과했는지 검사한다

5. 통과하지 못했으면 원래 프롬프트를 다시 먹인다

이 흐름이 중요한 이유는, Claude의 자기 판단을 그대로 믿지 않는다는 데 있습니다. 보통은 "끝났어요"라는 출력을 보면 사람이 직접 이어서 테스트를 돌리죠. Ralph Loop는 그 사이를 자동화합니다. "진짜 끝난 거 맞아?"를 한 번 더 묻고, 아니면 같은 일을 다시 시키는 구조입니다.

핵심은 더 똑똑한 답변을 받는 게 아니라, 완료 판단을 다시 검증 루프에 넣는 것입니다.

2. 왜 이름이 Ralph Loop인가

영상에서 이걸 랄프 위검 비유로 설명한 점이 인상적입니다. 랄프는 심슨에 나오는 순수한 캐릭터인데, 비유의 구조는 이렇습니다.

• 처음엔 그냥 만들어본다

• 다쳐 본다

• 표지판을 하나 더 붙인다

• 다시 시도한다

• 또 실패하면 규칙을 하나 더 추가한다

즉 처음부터 완벽한 놀이터를 설계하는 게 아니라, 실패한 데이터를 옆에서 보며 규칙을 더해 가는 방식입니다. Ralph Loop의 철학도 같습니다. 처음부터 완벽한 결과를 기대하기보다, 실패를 근거로 반복하면서 완성도를 끌어올리는 겁니다.

3. 진짜 중요한 옵션: max iteration과 completion prompt

이 구조에서 꼭 들어가야 하는 게 두 가지입니다.

max iteration

최대 몇 번까지 다시 시도할지 정하는 값입니다. 이게 없으면 무한 루프를 돌 수 있습니다. 영상에서도 이걸 넣지 않으면 토큰이 계속 녹는다고 경고합니다.

completion prompt

어떤 문구가 나왔을 때 진짜 종료로 볼지를 정하는 값입니다. 예를 들어 마지막에 \`DONE\` 같은 문구를 출력했을 때만 멈추게 만드는 식이죠. 이게 있어야 Claude가 애매한 자기 판단 대신, 우리가 준 종료 기준에 맞춰 멈추게 됩니다.

결국 Ralph Loop는 "많이 돌리면 언젠가 맞겠지"가 아닙니다. 반복 횟수와 종료 조건을 명확히 박아야만 통제 가능한 패턴이 됩니다.

4. local.md 같은 상태 기록이 왜 필요한가

영상에서는 루프 안에서 \`local.md\` 같은 기록 파일을 만들어두는 흐름도 보여줍니다. 여기에 적는 건 보통 이런 것들입니다.

• 처음 받은 프롬프트

• 현재 몇 번째 iteration인지

• 최대 iteration은 몇 개인지

• 어떤 문구가 나오면 종료할지

이게 중요한 이유는 Claude가 중간에 컨텍스트를 잃을 수 있기 때문입니다. 컨텍스트가 리셋돼도 이 파일을 다시 읽으면 "지금 내가 뭘 하고 있었는지"를 이어갈 수 있습니다. 즉 상태 기록은 부가 기능이 아니라, 반복 구조를 안정적으로 유지하는 장치에 가깝습니다.

5. 어떤 과제에 잘 맞나

이 부분이 실무에서 가장 중요합니다. Ralph Loop는 모든 문제에 좋은 패턴이 아닙니다. 오히려 성공 조건이 분명한 과제에만 강합니다.

잘 맞는 과제

• 테스트를 돌려서 통과/실패가 명확한 경우

• 린트 에러가 0개여야 하는 경우

• Playwright MCP 같은 브라우저 검증이 성공해야 하는 경우

• 명확한 체크리스트를 만족해야 하는 경우

이런 과제는 "됐는지 안 됐는지"가 기계적으로 갈립니다. 그래서 Claude가 실패 이유를 다시 읽고 수정 방향을 잡기 쉽습니다.

잘 안 맞는 과제

• A, B, C 여러 방향이 가능한 설계 문제

• 제품 판단이 필요한 UX 문제

• 사람 취향과 맥락이 중요한 글쓰기 방향성

• 무엇이 정답인지 모호한 개념 설계

영상에서도 이 점을 분명히 말합니다. 방향을 정확히 찔러 줄 수 있는 규칙이 있는 상황에서 쓰는 것이 좋고, 인간의 설계 판단이 많이 필요한 작업엔 맞지 않을 수 있습니다.

6. 실전 예시: REST API와 Playwright 검증

영상에서 보여주는 예시는 두 단계로 나뉩니다. 첫 번째는 간단한 할 일 목록 REST API를 만드는 예시입니다. Claude가 만들고, 끝났다고 판단하면 loop가 다시 검사하고, 정말 완성됐다고 판단할 때까지 반복하는 흐름을 보여줍니다.

두 번째는 한 단계 더 나아갑니다. 웹 서버를 만들고 서로 연동시키고, Playwright MCP 같은 검증 프로세스까지 넣어서 전부 통과했을 때만 종료하게 만드는 식입니다.

이 예시가 중요한 이유는 Ralph Loop를 "코드 자동 수정" 정도가 아니라, 검증 가능한 전체 작업 체인으로 확장해서 보여주기 때문입니다.

7. 결국 반복보다 더 중요한 건 검증 기준이다

Ralph Loop를 쓰는 사람들은 종종 "Claude가 알아서 계속 고친다"는 부분만 가져갑니다. 그런데 실제로 더 중요한 건 반복이 아닙니다. 더 중요한 건 다음 질문입니다.

• 무엇을 통과해야 끝났다고 볼 것인가?

• 무엇을 실패라고 정의할 것인가?

• 어느 시점에서 사람 개입이 필요한가?

이 기준이 없으면 loop는 그냥 같은 일을 여러 번 반복하는 구조가 됩니다. 반대로 이 기준이 선명하면, 테스트/린트/브라우저 검증 같은 일은 꽤 강력하게 자동화할 수 있습니다.

마치며

Claude가 "완료했습니다"라고 말하는 순간을 곧바로 믿지 않고, 다시 검사하고, 아니면 다시 시키는 구조. 이게 Ralph Loop의 본질에 더 가깝습니다. 그래서 Ralph Loop를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람보다, 성공 조건을 명확하게 적는 사람일 가능성이 큽니다.

테스트가 모두 통과해야 하는지, 린트 에러가 0개여야 하는지, Playwright 검증이 끝나야 하는지, 마지막에 어떤 문구가 찍혀야 종료할지. 이런 기준이 선명할수록 Claude는 "대충 끝난 척하는 도구"가 아니라, 반복 검증 구조 안에서 꽤 유용한 에이전트가 됩니다.

Ralph Loop를 써볼 생각이라면, 다음엔 프롬프트보다도 먼저 "내가 이 작업의 성공 조건을 얼마나 명확하게 적을 수 있나"부터 점검해보는 걸 추천합니다.