긴 에이전트 작업을 하다 보면 사람이 계속 재촉하게 된다.

테스트가 실패했다. “계속해.”

다시 고쳤다. 또 실패했다. “계속해.”

글을 고쳤다. 검사가 실패했다. “계속해.”

/goal, /loop, Ralph Loop는 모두 이 재촉 비용을 줄이려는 장치처럼 보인다. 그래서 처음 보면 같은 종류의 자동화처럼 느껴진다.

하지만 실제로 쓸 때 중요한 차이는 명령 이름이 아니다.

핵심은 “다음 턴(turn)을 무엇이 시작시키고, 끝났다는 판단을 누가 어떻게 하는가”다.

Claude Code에도 목표를 붙이는 /goal이 있다. 여기서는 이름이 비슷해서 자주 섞이는 Codex의 목표 모드, Claude의 주기 실행, Ralph Loop 플러그인(plugin)을 작업 성격 기준으로 나눠 본다. Ralph Loop가 낯선 독자를 위해 먼저 세 방식을 비교하고, 자동 반복이 어디서 실패하는지에 초점을 둔다.

Codex 목표 모드, Claude Loop, Ralph Loop가 순서가 아닌 세 방식으로 종료 증거를 비교하는 구조.

비슷해 보이는 반복 명령도 종료 조건을 보면 다르게 보인다. 증명 가능한 목표인지, 주기적으로 다시 확인할 일인지, 같은 프롬프트를 계속 밀어붙일 일인지 먼저 나눠야 한다.

나는 세 방식을 이렇게 나눠 본다.

  • Codex /goal: 다음 turn은 목표 조건이 아직 남아 있을 때 이어지고, 끝났다는 판단은 검증 증거가 조건을 충족하는지에 달려 있다.
  • Claude /loop: 다음 실행은 시간 간격이나 Claude가 고른 지연 시간으로 시작된다. 고정 간격 loop는 사용자가 멈추거나 만료될 때까지 돌고, self-paced loop는 Claude가 충분히 끝났다고 판단하면 다음 wakeup을 잡지 않을 수 있다.
  • Ralph Loop: 종료 차단 훅(Stop hook)이 session exit를 막고 같은 프롬프트를 다시 넣는다. 끝 기준은 completion promise나 반복 한도에 더 가깝다.

세 명령은 모두 귀찮은 재촉을 줄인다

일반적인 AI agent 작업은 한 turn 단위로 끊긴다.

에이전트가 코드를 고친다. 테스트를 돌린다. 실패를 본다. 그다음 사용자가 “계속해”라고 말해야 한다. 작은 작업이면 괜찮지만, 테스트 실패를 고치거나 글을 발행 준비 상태까지 밀어야 할 때는 이 재촉 비용이 커진다.

/goal, /loop, Ralph Loop는 모두 이 문제를 줄이려는 장치다.

다만 줄이는 방식이 다르다.

  • /goal은 목표 조건이 만족될 때까지 다음 turn을 이어간다.
  • /loop는 일정 시간이나 반복 조건에 따라 같은 확인을 다시 실행한다.
  • Ralph Loop는 종료하려는 순간을 hook으로 막고 같은 프롬프트를 다시 넣는다.

이 셋을 “계속 돌리는 명령”으로만 보면 위험하다. 계속 도는 이유가 다르기 때문이다.

Codex /goal은 완료 조건을 붙이는 방식이다

Codex의 /goal은 persistent target, 즉 계속 추적할 목표를 붙이는 명령이다.

예를 들면 이런 식이다.

/goal 로그인 오류가 재현 테스트와 회귀 테스트를 통과하고, 변경 파일이 인증 모듈 안에만 남는다

여기서 중요한 것은 “로그인 오류를 고친다”로 끝내지 않는 것이다. 끝났다고 말하려면 어떤 테스트가 통과해야 하는지, 변경 범위가 어디까지인지까지 같이 들어간다.

이 문장은 그냥 “계속해”가 아니다. 끝났다고 말하려면 무엇을 보여줘야 하는지까지 포함한다.

Codex 문서도 /goal을 큰 작업이 진행되는 동안 붙어 있는 persistent target으로 설명한다. CLI에서는 /goal로 목표를 설정하고 보고하며 pause, resume, clear로 관리한다. 중요한 점은 목표가 비어 있으면 안 되고, 너무 긴 지시는 별도 파일에 두는 편이 낫다는 것이다.

실무에서 좋은 /goal은 아래 세 가지를 가진다.

  • 하나의 측정 가능한 끝 상태
  • 그 상태를 증명할 검사
  • 작업 중 지켜야 할 제약

예를 들어 “댓글 기능 고쳐줘”보다 아래가 낫다.

/goal 결제 취소 버튼이 주문 상세 화면에 보이고, 취소 API 실패 시 오류 메시지가 뜨며, npm run test와 npm run build가 통과한다

이렇게 쓰면 에이전트도 더 잘 움직인다. “무엇을 하면 끝인가”가 보이기 때문이다.

Claude /loop는 주기적으로 다시 묻는 방식이다

Claude Code에는 /loop도 있다.

이 명령은 이름 때문에 Ralph Loop와 특히 헷갈린다. 하지만 공식 문서에서 /loop는 schedule로 설명된다. 세션이 열려 있는 동안 prompt를 반복 실행하거나, 배포 상태처럼 나중에 다시 확인해야 할 일을 주기적으로 본다.

예를 들면 이런 식이다.

/loop 5m check if the deploy finished

여기에는 “끝날 때까지 기능을 완성해”보다 “5분마다 배포가 끝났는지 봐”가 잘 맞는다.

그래서 /loop는 polling에 잘 맞는다. 배포 상태, 긴 빌드, PR 상태, 외부 작업 완료 여부처럼 시간이 지나야 바뀌는 것을 확인할 때 자연스럽다.

다만 “확인 대상이 바뀌면 끝난다”라고 단정하면 약하다. Claude Code 문서는 /loop를 반복 prompt와 scheduled task로 설명하고, fixed interval loop는 사용자가 멈추거나 7일 만료가 오기 전까지 계속된다고 말한다. self-paced loop에서는 Claude가 작업이 충분히 끝났다고 판단하면 다음 wakeup을 잡지 않기도 하지만, 이 역시 대화에 드러난 증거와 설정된 schedule에 기대는 방식이다.

반대로 테스트가 깨진 원인을 찾아 계속 고치게 만드는 용도라면 /loop만으로는 애매하다. 시간이 지났다고 더 나은 다음 행동이 생기는 것은 아니기 때문이다. 이때는 목표 조건을 붙이는 /goal이나 더 강한 반복 구조가 필요하다.

Ralph Loop는 같은 프롬프트를 다시 넣는 방식이다

Ralph Loop는 더 직접적이다.

Anthropic의 Ralph Loop plugin 설명을 보면, 이 방식은 Claude가 같은 작업을 반복해서 보도록 만든다. plugin은 Stop hook으로 session exit를 가로채고, 같은 prompt를 다시 넣는다. 파일 수정과 git history는 남아 있기 때문에 다음 반복은 이전 시도의 결과를 보고 다시 개선한다.

예시는 대략 이런 모양이다.

/ralph-loop "Build a todo API. Run tests. Output COMPLETE only when done." --max-iterations 10 --completion-promise "COMPLETE"

핵심은 두 가지다.

첫째, 같은 프롬프트가 다시 들어간다.

둘째, 이전 반복의 파일 변경과 git history가 남는다.

그래서 Ralph Loop는 “한 번에 못 끝내도 계속 부딪혀 보는 실험”이다. 테스트를 돌리고, 실패를 보고, 고치고, 다시 돌리는 greenfield 작업에 잘 맞는다.

하지만 이 방식은 꽤 거칠다. 같은 프롬프트를 계속 넣는다고 자동으로 좋은 판단이 생기지는 않는다. 잘못된 방향으로 고쳐도 반복은 계속된다. 완료 신호를 너무 쉽게 쓰면 실제로는 덜 끝났는데 loop가 끝난다. 반대로 완료 조건이 모호하면 의미 없는 반복이 길어진다.

그래서 Ralph Loop 쪽 문서도 --max-iterations 같은 안전망과 명확한 completion promise를 강조한다. 나는 이 부분을 가장 중요하게 본다.

반복을 자동화할수록,
멈출 조건은 더 기계적으로 써야 한다.

가장 쉬운 구분은 다시 시작과 종료 조건이다

세 방식을 다시 시작 조건과 종료 조건으로 나눠 보자.

검증 가능한 수정에는 /goal을 쓴다. 다시 시작 트리거는 남은 목표 조건이고, 멈춤 조건은 테스트, 빌드, 화면 증거처럼 대화에 남은 완료 증거다. 목표가 흐리면 끝을 못 본다.

기다리는 확인에는 /loop를 쓴다. 다시 시작 트리거는 시간, 반복 간격, 또는 Claude가 고른 지연 시간이다. 사용자가 취소하거나, 시간이 만료되거나, 충분히 끝났다고 판단해 다음 wakeup을 잡지 않을 때 멈춘다. 바뀌지 않는 상태를 같은 방식으로 계속 확인하지 않도록 주의한다.

반복 구현 실험에는 Ralph Loop를 쓴다. 다시 시작 트리거는 종료 차단 훅이고, 멈춤 조건은 완료 문구와 반복 한도다. 잘못된 방향으로 변경이 누적되는 것이 주요 위험이다.

이 표에서 중요한 부분은 “잘 맞는 일”보다 “무엇을 보고 다시 시작하고, 무엇을 보고 끝내나”다.

AI agent는 작업을 시작하는 것보다 멈추는 기준이 더 어렵다. 그래서 반복 명령을 고를 때는 먼저 이렇게 물어야 한다.

끝났다는 증거가 무엇인가?

테스트 결과나 build exit code처럼 증거가 분명하면 /goal이 좋다. 외부 상태가 바뀌기를 기다리는 일이면 /loop가 맞다. 같은 프롬프트를 여러 번 통과시키며 개선을 누적하는 실험에는 Ralph Loop를 검토한다.

내가 쓰는 선택 기준

나는 지금 이렇게 나눠서 쓴다.

첫째, 현재 repo에서 검증 가능한 끝 상태가 있으면 /goal을 먼저 본다.

예를 들어 “취소 버튼이 화면에 보이고, 실패 응답에서 오류 메시지가 뜨며, test와 build가 통과한다”는 goal로 적는다. 완료 증거가 화면, 명령 결과, 실제 route 확인으로 남기 때문이다.

둘째, 기다리는 일이면 /loop를 본다.

배포가 끝났는지, 외부 check가 바뀌었는지, 일정 시간이 지난 뒤 다시 볼 일이 있는지 확인하는 데 좋다. 이건 작업을 계속 고치는 것보다 상태를 다시 확인하는 쪽이다.

셋째, Ralph Loop는 더 조심해서 쓴다.

작업이 잘게 나뉘어 있고, 테스트나 lint처럼 자동 검증이 있으며, 실패가 다음 반복의 입력으로 의미가 있을 때만 후보가 된다. 반대로 사람의 디자인 판단, 공개 발행, 운영 DB 변경, 비용이 드는 외부 작업에는 그대로 맡기지 않는다.

이 기준은 보수적이다. 하지만 반복 명령은 보수적으로 보는 편이 낫다. 한 번 더 묻는 비용보다, 잘못된 반복이 조용히 계속되는 비용이 더 크기 때문이다.

비슷해 보이는 이유도 있다

그래도 둘이 비슷하게 느껴지는 이유는 분명하다.

둘 다 사용자의 “계속해”를 줄인다. 둘 다 긴 작업을 한 번의 요청으로 더 멀리 밀어준다. 둘 다 잘 쓰려면 완료 조건을 잘 써야 한다.

그래서 글로 설명할 때도 “완전히 다르다”라고 말하면 오히려 틀린다. 운영 감각은 비슷하다.

다만 구현 방식과 실패 모드가 다르다.

/goal의 실패는 보통 목표가 흐릿할 때 생긴다. “좋은 글로 만들어줘”처럼 평가 기준이 애매하면 완료 판단 기준이 약해진다.

/loop의 실패는 반복 주기가 작업 성격과 안 맞을 때 생긴다. 시간이 지나도 바뀌지 않는 문제를 계속 물으면 같은 답이 반복된다.

Ralph Loop의 실패는 completion promise와 iteration limit이 약할 때 생긴다. agent가 빠져나가고 싶어서 완료 신호를 너무 빨리 쓰거나, 반대로 불가능한 조건을 오래 반복하기도 한다.

재촉 비용을 줄이는 장치다

다음 작업에서 한 문장만 남긴다면 이렇다.

검증 가능한 끝 상태가 있으면 /goal.
시간이 지나야 확인할 일이면 /loop.
같은 프롬프트를 반복해 개선을 누적할 실험이면 Ralph Loop.

자동 반복은 에이전트를 똑똑하게 만드는 장치라기보다, 반복 비용을 줄이는 장치다. 반복 비용을 줄이려면 먼저 멈춤 기준을 써야 한다.

내 기준에서는 이게 /goal과 Ralph Loop를 나누는 가장 쉬운 문장이다.

/goal은 "끝났다는 조건"을 계속 확인하는 방식이고,
Ralph Loop는 "같은 시도"를 계속 다시 넣는 방식이다.

비슷해 보이는 명령일수록 이 차이를 먼저 보면 된다.

시리즈 연결

확인한 기준