요즘 화제 인 loop engineering — 그런데 이 말 의 loop 가 정확히 뭘 가리키는지 는 사람 마다 다르게 쓴다. 나 도 헷갈려서 Fable 5 에게 두 해석 을 놓고 물었고, 지금까지 본 설명 중 가장 명쾌 한 답 을 받아서 기록 으로 남긴다.

질문 — loop engineering 의 loop 는 다음 중 어느 쪽 인가?

  1. cron 형 : 일정 간격 으로 깨어나 새 이슈·PR 을 찾고 → 선별 하고 → 컨텍스트 를 모으고 → 작업 하고 → 검증 하고 → 반영 하고 → 다음 루프 때 보강 할 것 을 기록 하는 반복
  2. ralph 형 : 완료 기준 이 주어지면 쉬지 않고 목표 에 가까워질 때 까지 계속 시도 하는 반복

결론 부터 — 경쟁 하는 정의 가 아니라, 같은 스택 의 다른 층

둘 은 양자택일 이 아니다. 굳이 고르면 “loop engineering” 이라는 신조어 가 새로 명명 한 실천 은 1번 에 가깝고, 2번(ralph) 은 1년 먼저 이름 붙은 원형 으로서 지금 은 그 시스템 안쪽 에서 도는 실행 프리미티브 로 흡수 됐다.

1. 계보 — ralph(2025) 가 먼저, loop engineering(2026) 이 나중

  • Ralph : Huntley 가 2024년 2월 발견, 2025년 7월 “Ralph 는 기법 이다. 가장 순수 한 형태 의 Ralph 는 Bash 루프 다” 라고 명명. 학술 문헌 의 정의 는 “성공 할 때 까지 반복 시도 하되, 성공 여부 는 에이전트 자신 이 아니라 외부 검증 이 결정 하는 루프”. 딱 질문 의 2번.
  • Loop engineering : 약 1년 뒤 인 2026년 6월 7일 — Steinberger 의 트윗(“코딩 에이전트 를 프롬프팅 하지 말고, 에이전트 를 프롬프팅 하는 루프 를 설계 하라”, 8.5M 조회), Cherny 의 무대 발언(“나는 더 이상 Claude 를 프롬프팅 하지 않는다. 루프 들 이 돌면서 Claude 를 프롬프팅 하고 뭘 할지 알아낸다. 내 일 은 루프 를 쓰는 것 이다”), 같은 날 Osmani 의 글 이 이 패턴 에 이름 을 붙이며 생긴 말. Cherny 본인 이 아니라 제3자 가 대중화 한 명칭 이라는 점 도 흥미 롭다.

2. 명명자 Osmani 원문 자체 가 두 해석 사이 에서 갈라져 있다

정의 문장 은 “루프 란 목적 을 정의 하면 AI 가 완료 될 때 까지 반복 하는 재귀적 목표(recursive goal)” — 2번 처럼 읽힌다. /loop(주기 재실행) 과 /goal(조건 충족 까지 지속) 을 구분 하며 후자 가 “이 글 이 말하려는 것 에 가깝다” 고 까지 한다.

그런데 본문 의 뼈대 는 반대 다. 다섯 블록 의 첫째 가 “스케줄 에 따라 스스로 발견·트리아지 하는 automations” 이고, 이것 이 루프 의 심장박동(heartbeat) 이라 한다. 대표 예시 도 — 매일 아침 automation 이 CI 실패·열린 이슈·최근 커밋 을 읽고 → 할 만한 건 격리 된 worktree 에서 서브에이전트 가 수정 하고 → 두 번째 서브에이전트 가 검증 하고 → PR 을 열고 → 상태 파일 이 오늘 멈춘 지점 을 기억 해 내일 이어받는 구조. 질문 의 1번 시나리오 와 거의 문장 단위 로 일치 한다.

이 내적 긴장 때문 에 커뮤니티 도 갈라졌다 — “차세대 추상화 계층” vs “cron job 에 모자 씌운 것(a cron job wearing a hat)”.

3. 결정적 단서 — “figuring out what to do”

Ralph 루프 는 목표 를 사람 이 주고 시작 한다. Cherny 의 루프 는 뭘 할지 스스로 찾는다 — GitHub·Slack 을 스캔 하고, PR 을 돌보고, 피드백 테마 를 추리고, CI 를 건강 하게 유지 하고, 다음 에 뭘 만들지 표면화 한다. 후속 정리 문서 들 도 그의 루프 를 “스케줄 에 따라, 또는 목표 조건 충족 까지” 도는 sense–decide–act–check 사이클 로 기술 한다. 트리거 는 시간 일 수도, 미완료 조건 일 수도 있다는 것.

4. 가장 깔끔 한 해소 — LangChain 의 4중 루프

2026년 6월 16일 LangChain 의 프레임 이 이 애매함 을 층 으로 정리 했다:

층 루프 하는 일 질문 매핑
① 안 agent loop 모델 이 상태 를 읽고 끝날 때 까지 도구 호출 2번
② verification loop 루브릭 채점 → 미달 이면 피드백 과 함께 되돌림 2번
③ event-driven loop 외부 신호(스케줄·웹훅·새 문서) 로 에이전트 발화 1번
④ 밖 hill-climbing loop 누적 실행 기록 을 읽어 다음 실행 을 개선 1번

안쪽 두 층 이 정확히 2번(ralph) 이고, 바깥 두 층 이 1번 이다.

5. 판정 을 정확 하게 만드는 세 가지 뉘앙스

① 1번 의 본질 은 “1시간 간격” 이 아니다. cron 은 여러 트리거 중 가장 흔한 심장박동 일 뿐. 정확 한 정의 는 “사람 대신 트리거 가 실행 을 개시 하는 바깥 제어 시스템” 이다 — 스케줄 이든 웹훅 이든 새 문서 도착 이든.

② 순수 한 2번(bare ralph) 은 그대로 승인 되지 않는다. 상한 없는 bare ralph 는 “루프 가 아니라 열린 청구서”. 실무 문헌 은 세 가드 를 요구 한다 — 반복 횟수 상한 · diff 가 더 안 변하면 죽이는 체크 · 토큰/달러 예산. 좋은 루프 = 명확 한 목표 + 유용 한 컨텍스트 + 작은 행동 + 신뢰 할 관찰 + 명시적 정지 규칙. 즉 loop engineering 은 ralph 를 부정 한 게 아니라, 정지 조건·검증 분리·예산 을 입혀 안쪽 층 으로 편입 한 것.

③ “다음 루프 때 보강 할 것 을 기록” — 이게 별도 의 이름 을 가진 층 이다. LangChain 은 이걸 hill-climbing loop 라 부르고, 앞 의 세 루프 가 일 을 자동화 한다면 이 넷째 는 개선 을 자동화 하는 — 어쩌면 가장 중요 한 — 루프 라 한다. 그러니 질문 의 1번 서술 은 그냥 cron 이 아니라, 4층 스택 을 전부 품은 완성형 loop engineering 의 서술 이었던 셈.

6. swyx 의 사다리 — “어느 쪽 이 진짜 루프냐” 는 어느 칸 을 보느냐 의 문제

swyx 는 AIEWF 기조연설 제목 을 아예 “Loopcraft: The Art of Stacking Loops” 로 잡고 “요즘 우리 는 전부 automation 얘기 다. cron job 과 루프 의 시대” 라며, 진화 경로 를 chat → tools → goals → automations 로 정리 했다.

이 프레임 에서 게임 의 규칙 은 이렇다 — 문제 가 생기면 아래 루프 로 내려가고(신뢰성), 모델 이 좋아지면 위 루프 로 올라간다(레버리지). 루프 를 얼마나 잘 쌓느냐 가 앞으로 의 승부 라는 것. 그러니 “cron 이냐 ralph 냐” 라는 질문 자체 가, 같은 사다리 의 어느 칸 을 보고 있느냐 의 문제 로 해소 된다.

7. 하네스 관점 — loop 는 시간 축 으로 확장 된 하네스, ralph 는 그 원형

Osmani 본인 이 loop engineering 을 harness engineering 의 한 층 위 — “타이머 로 돌고, 작은 헬퍼 들 을 낳고, 스스로 를 먹여 살리는 하네스” — 로 위치 시킨다. 한 줄 로:

loop = 시간 축 과 “일감 발견” 축 으로 확장 된 하네스. ralph 는 그 원형.

특히 /goal 조차 작업 한 모델 이 아닌 별도 의 작은 모델 이 완료 여부 를 판정 하게 한다 — maker 와 checker 의 분리 를 정지 조건 자체 에 적용 한 것. 결국 loop engineering 의 안전장치 는 전부 하네스 의 오래된 원칙(만든 자 가 채점 하지 않는다) 의 시간 축 버전 이다.

용어 를 구분 해 쓸 일 이 있으면 — 안쪽 은 agent/verification loop(또는 ralph loop), 바깥쪽 은 event-driven/hill-climbing loop 라는 LangChain 용어 를 빌리는 게 지금 문헌 과 가장 정합적 이다.

마무리 — 내 홈랩 도 이미 이 스택 위 에 있다

돌아보면 내 홈랩 도 이 층 들 을 이미 밟고 있다 — 텔레그램 지시 로 코드→CI→PR→ArgoCD→K3s 까지 가는 파이프라인 은 ①②(작업 과 검증), 5분 마다 ES 를 훑는 log-error-alerter 와 새벽 크론 들 은 ③(이벤트/스케줄 발화), 그리고 세션 이 남기는 메모리·운영 문서 가 다음 실행 을 고치는 ④(hill-climbing) 다. (AX 시대 의 백엔드 와 DevOps 에서 말한 루프 를 소유 하라 가 정확히 이 얘기 다.)

loop engineering 의 loop 는 cron 도 ralph 도 아니다. ralph 를 안쪽 에 품고, 트리거 가 심장박동 을 치고, 기록 이 다음 실행 을 개선 하는 — 4층 짜리 제어 시스템 이다. 개념 의 혈통 은 2번(ralph) 을 가리키지만, 2026년 6월 에 이 신조어 가 새로 명명 한 실천 — 스케줄 로 일 을 발견 하고, 두 번째 에이전트 로 검증 하고, 상태 를 파일 에 써서 내일 이 오늘 멈춘 곳 에서 재개 하는 — 은 1번 이다. 그리고 그 빌딩 블록 들 이 커스텀 스크립트 가 아니라 제품 안 에 내장 되면서 비로소 이름 이 붙었다.