Ralph Wiggum Loop — 에이전트가 같은 삽질을 반복할 때

코딩 에이전트한테 버그 수정을 시켰더니, 이런 일이 벌어진다:

1. 코드 수정
2. 테스트 실행 → 실패
3. 같은 코드를 약간 다르게 수정
4. 테스트 실행 → 같은 에러
5. 또 비슷하게 수정
6. ... (10번 반복, 토큰 $3 소모, 진전 0)

이게 Ralph Wiggum Loop다.

왜 발생하나

LLM은 "시도 횟수"를 세지 않는다: 메시지 히스토리에 실패 기록이 쌓여도, LLM은 "이미 5번 같은 접근을 했으니 다른 방법을 써야겠다"라고 스스로 깨닫지 못하는 경우가 많다.

컨텍스트 윈도우 한계: 히스토리가 길어지면 초기 시도의 실패 이유가 잘려나간다. LLM이 과거 시도를 "잊고" 같은 실수를 반복.

에러 메시지가 불충분: 테스트 에러가 "assertion failed"만 반환하면 LLM이 원인을 파악하기 어렵다. 정보 부족 → 같은 추측 반복.

도구 설계 문제: 도구가 "성공/실패"만 반환하고 맥락을 안 줌. LLM이 왜 실패했는지 판단할 재료가 없다.

감지 방법

반복 감지: 최근 N번의 도구 호출이 동일한 도구 + 유사한 파라미터면 루프 감지 → 개입.

토큰 예산: 하나의 태스크에 토큰 상한 설정. 초과하면 "이건 내가 해결하기 어렵다"고 솔직하게 보고하게.

진전 메트릭: 각 루프 이터레이션 후 "뭐가 변했나?"를 평가. 변화 없으면 루프 탈출.

방지 전략

시스템 프롬프트에 명시: "같은 접근을 2번 이상 실패하면 다른 전략을 시도하라" "해결이 어려우면 사용자에게 도움을 요청하라"

실패 히스토리 요약: 매 N번째 이터레이션에 "지금까지 시도한 것과 결과"를 요약해서 LLM에 주입. 맥락을 잃지 않게.

에스컬레이션 메커니즘: 일정 횟수 실패 → 사용자에게 "이 부분에서 막혔습니다. A, B, C를 시도했지만..."이라고 보고하고 판단을 맡기기.

도구 결과 개선: 에러 메시지에 가능한 원인, 관련 파일, 시도해볼 접근법 등의 맥락을 포함.