Ralph Loop, OpenClaw - 새로운건 없었다

Claude Code가 "구현을 완료했습니다"라고 해놓고 절반만 되어 있는 일에 짜증이 나던 밤, Ralph Loop를 발견한 데서 시작한다. 에이전트가 끝났다고 해도 같은 프롬프트를 다시 넣어 진짜로 끝날 때까지 무한 반복하는 기법이다. 이 기법과 OpenClaw의 자율 에이전트 구조를 뜯어본 뒤, 채널톡의 FrontALF 엔진이 결국 같은 구조였음을 확인하면서도 고객 응대라는 상황이 요구하는 차이를 짚는다.

핵심 포인트

Ralph Loop는 진행 상황을 컨텍스트가 아니라 파일과 git에 저장해 컨텍스트 오염을 우회한다. 컨텍스트가 차면 새 에이전트가 파일시스템 상태를 읽고 이어서 작업한다.
Y Combinator 해커톤에서 한 팀이 이걸 인스턴스에 올려두고 잠들었더니 아침에 6개 레포에 1,100개 커밋이 찍혔고 비용은 800달러였다.
프로덕션에서 자율 루프를 돌리려면 코딩 도구에는 없던 문제들이 쏟아진다. 채널을 넘나드는 동일인 식별, 임의 결제 방지, 무한 반복 비용, 멱등성 같은 것들이다.
에이전트 루프라는 이름을 빼면 LLM 호출과 도구 실행, 종료 조건 분기로 이뤄진 전통적 재시도 패턴과 크게 다르지 않다.
고객 응대에서는 끈질김만큼이나 언제 어떤 이유로 종료되는지가 중요하다. 10분째 검색을 반복하면 정확한 답이 나와도 고객은 이미 떠났다.

상세 정리

이름의 유래: 심슨 캐릭터 Ralph Wiggum에서 따왔으며 똑똑하진 않지만 끈질기게 포기하지 않는 캐릭터라는 점에서 붙였다.
파생 생태계: 수천 개 star를 받은 파생 프로젝트들이 나왔고 일부 도구는 슬래시 명령으로 이 루프를 내장하고 있다.
OpenClaw 분석: PDF SDK를 13년 운영하고 매각한 개발자가 만든 개인 AI 비서로, 12개 이상 채널을 연결하고 Mac에서 로컬 실행되며 비행기 체크인이나 이메일 요약, 캘린더 관리를 자율적으로 한다.
프로덕션 자율 루프의 문제들을 OpenClaw는 에이전트의 성격과 행동 원칙을 정의한 soul document, Gateway 기반 세션 라우팅, 사용량 모니터링으로 하나씩 풀었다.
코드가 커서 핵심 패턴을 뽑기 어려웠는데, 같은 구조를 4,600줄로 구현한 다른 오픈소스 프로젝트로 대신 뜯어봤다고 밝힌다.
구조의 정체: LLM을 호출하고 도구 호출이 있으면 실행하고 없으면 종료하는 while문과 상태 누적, 종료 조건이다. 그 눈으로 자사 FrontALF 엔진을 다시 열어보니 같은 구조인 부분이 꽤 있었다.
상황의 차이: 개인 프로젝트나 개발 도구라면 루프가 오래 돌고 비용이 좀 나와도 결과만 좋으면 되지만, 고객 응대는 다르다. 환불 처리를 자동화했는데 API 호출 실패로 무한 재시도하면 같은 환불이 두 번 처리될 수도 있다.
두 패턴으로 나눈 이유: 고객 질문에 답변하는 것과 환불 같은 실제 액션을 처리하는 것은 요구사항이 너무 달랐다.
Agent Loop: RAG로 고객사의 FAQ·제품 정보·정책을 검색해 답변을 만들며, 상태는 컨텍스트에만 쌓이고 세션이 끝나면 사라진다. 단순하고 빠르다.
Task: 사람이 반드시 해야 했던 액션까지 위임하는 패턴으로, Start부터 Code·Function·Message·End까지 여러 노드를 거치며 상태를 저장한다. 중간에 실패해도 해당 노드부터 재실행할 수 있고 민감한 작업은 사람 승인을 기다릴 수 있다.
한마디로 Agent Loop는 한 번에 끝내기, Task는 나눠서 진행하기다.
공통 안전장치: 아무리 복잡해도 10턴 안에 끝내든지 아니면 별도 에이전트가 지금까지의 작업을 정리한다. 그 에이전트의 역할은 무엇을 했고 사용자가 다음에 뭘 할 수 있는지 알려주는 것 하나다.
이 설계의 근거는 묵묵히 끊기는 것과 "여기까지 했고 이렇게 이어가시면 됩니다"라고 정리해 넘기는 것이 사용자 경험에서 완전히 다르다는 점이다.
저자는 10이라는 숫자가 최적인지는 아직 모른다고 인정한다. 단순 질문은 3턴이면 충분한데 복잡한 워크플로우는 10턴도 빠듯할 때가 있어 동적 조절이 다음 과제다.
Agent Loop 실제 흐름: "배송비 환불 받을 수 있어?"라는 단순해 보이는 질문에도 정확한 답에는 3턴이 필요하다. Turn 1의 RAG Handler는 단순 검색이 아니라 키워드를 추출하고 쿼리를 재생성해 다시 검색하는 미니 루프를 내부에서 돈다.
첫 검색으로 2건밖에 못 찾으면 쿼리를 바꿔 다시 검색하고, 그 결과가 쌓여 Turn 2에서 5건을 한꺼번에 보고 답변을 만든다. Ralph Loop의 "끝날 때까지 반복"이 여기서는 "충분한 검색 결과를 찾을 때까지 반복"으로 나타난다.
Task 실제 흐름: 주문 취소와 환불 요청은 고객사마다 정책이 다르고 배송 전후에 따라 처리가 달라지며 부분·전체 환불 계산도 필요하다. 무엇보다 돈이 오가는 작업이라 실수가 허용되지 않아 이전에는 반드시 사람이 처리했다.
Task는 노드를 거치며 정책 판정 결과와 환불 금액·수단 같은 중간 상태를 메모리에 저장해 나간다.