2026년 6월 7일, Steinberger 의 트윗 하나 가 조회수 8.5M 을 찍었다 — “코딩 에이전트 를 프롬프팅 하지 말고, 에이전트 를 프롬프팅 하는 루프 를 설계 하라.” 같은 날 Osmani 가 이 실천 에 loop engineering 이라는 이름 을 붙였고, Cherny 는 무대 에서 이렇게 말했다: “나는 더 이상 Claude 를 프롬프팅 하지 않는다. 루프 들 이 돌면서 Claude 를 프롬프팅 하고 뭘 할지 알아낸다. 내 일 은 루프 를 쓰는 것 이다.”

한 달 이 지난 지금(2026년 7월), 이 말 은 에이전트 판 에서 가장 뜨거운 키워드 가 됐다. 이 글 은 무엇 이고 · 왜 지금 이고 · 어떻게 시작 하나 를 해부 한다. (용어 의 계보 논쟁 — cron 이냐 ralph 냐 — 는 어제 글 에서 깊게 다뤘다.)

1. 무엇 인가 — 프롬프트 에서 루프 로, 단위 의 이동

지금까지 우리 는 에이전트 에게 한 번 의 일 을 시켰다. “이 버그 고쳐 줘” — 세션 이 끝나면 끝. 다음 날 또 처음 부터.

Loop engineering 은 일 의 단위 를 바꾼다. 사람 이 설계 하는 건 개별 지시 가 아니라 계속 도는 시스템 이다:

발견(스캔) → 선별(트리아지) → 컨텍스트 수집 → 실행 → 검증 → 반영 → 기록 → (다음 실행 이 이어받음)

핵심 차이 는 마지막 두 칸 이다. 상태 를 파일 에 남겨서, 내일 실행 이 오늘 멈춘 곳 에서 재개 한다. 세션 은 죽어도 루프 는 산다. 에이전트 가 대화 상대 에서 장기 실행 시스템 으로 바뀌는 지점 이 정확히 여기 다.

2. 왜 지금 인가 — 두 곡선 이 교차 했다

이 아이디어 자체 는 새롭지 않다 (bash 무한 루프 로 에이전트 를 돌리는 ralph loop 는 2025년 에 이미 명명 됐다). 2026년 여름 에 터진 이유 는 두 가지 가 겹쳐서 다:

① 모델 이 충분히 좋아졌다. 루프 는 사람 없이 도는 시간 이 길다 — 실수 가 누적 되면 루프 가 쓰레기 를 양산 한다. 한 판 을 안정적 으로 이길 만큼 모델 이 좋아진 게 전제 조건.

② 빌딩 블록 이 제품 안 으로 들어왔다. 예전 엔 cron + bash + 커스텀 스크립트 로 짜야 했던 것들 — 스케줄 실행(automations), 격리 작업공간(worktree), 검증용 서브에이전트, 외부 연동(connectors), 상태 저장 — 이 에이전트 제품 의 기본 기능 이 됐다. 커스텀 인프라 없이 누구나 루프 를 조립 할 수 있게 되자 이름 이 붙고 폭발 했다.

swyx 는 AIEWF 기조연설 “Loopcraft: The Art of Stacking Loops” 에서 이 진화 를 chat → tools → goals → automations 로 정리 했다. 우리 는 지금 네 번째 칸 에 진입 하는 중 이다.

3. 좋은 루프 의 해부 — 다섯 요소

문헌 이 수렴 하는 좋은 루프 의 조건 은 다섯 이다:

요소 뜻 없으면
명확한 목표 무엇 이 “완료” 인지 기계 가 판정 가능 영원히 돈다
유용한 컨텍스트 이번 판 에 필요한 것 만 주입 헤매거나 엉뚱한 걸 고침
작은 행동 한 판 에 작은 단위 (한 이슈 · 한 PR) 실패 시 되돌릴 수 없음
신뢰 할 관찰 테스트 · 빌드 · 외부 검증 으로 결과 확인 자기 채점 = 후한 채점
명시적 정지 규칙 언제 멈출지 를 코드 로 루프 가 아니라 열린 청구서

특히 검증 은 작업 한 에이전트 가 아닌 별도 에이전트(maker/checker 분리) 가 한다 — 멀티 에이전트 글 에서 다룬 그 원칙 이다.

4. 가드레일 — bare loop 는 승인 되지 않는다

상한 없는 무한 루프 에 대한 실무 문헌 의 경고 는 명확 하다. 세 가드 없이는 돌리지 말 것:

  1. 반복 횟수 상한 — N판 안 에 못 끝내면 사람 에게 에스컬레이션
  2. no-diff kill — 최근 실행 에서 diff 가 더 이상 변하지 않으면 (제자리 걸음) 죽인다
  3. 토큰 · 달러 예산 — 지출 상한 도달 시 정지

토큰 이 곧 돈 인 시대 에, 정지 조건 없는 루프 는 기능 이 아니라 사고 다. 이 감각 은 기술 도입비용 글 의 저울 과 같다 — 루프 가 만드는 가치 > 루프 가 태우는 비용 이어야 한다.

5. “cron job 에 모자 씌운 것 아니냐” — 가장 좋은 반론 에 답하기

커뮤니티 의 유명한 비아냥 이 있다: “a cron job wearing a hat.” 절반 은 맞다 — 트리거 는 실제 로 cron 이 가장 흔하다. 그런데 cron job 과 갈라지는 결정적 두 가지 가 있다:

  • 일감 을 스스로 찾는다. cron job 은 정해진 일 을 반복 하지만, 루프 는 스캔(이슈 · CI 실패 · 피드백) 으로 오늘 뭘 할지 를 발견 한다. Cherny 표현 으로 “figuring out what to do”.
  • 스스로 를 개선 한다. 매 실행 이 남긴 기록 을 다음 실행 이 읽는다 — 실패 한 접근 은 피하고, 통과 한 패턴 은 굳힌다. LangChain 이 hill-climbing loop 라 부르는, 어쩌면 가장 중요한 층.

발견 과 자기 개선 이 없으면 cron job 이 맞다. 있으면 — 그때 부터 loop engineering 이다.

6. 시작 하는 법 — 내일 아침 첫 루프

거창 할 필요 없다. 문헌 의 공통 조언 은 아침 트리아지 루프 하나 로 시작 하라 는 것:

  1. 매일 아침 스케줄 로 에이전트 를 깨운다
  2. 어제 의 CI 실패 · 열린 이슈 · 새 피드백 을 읽게 한다
  3. 고치게 하지 말고, 발견 사항 을 마크다운 으로 기록 만 하게 한다 (읽기 전용 = 안전)
  4. 일주일 치 기록 이 쓸 만하면 → 가장 자신 있는 유형 하나 만 수정 + PR 까지 허용
  5. 검증 은 별도 에이전트 + CI 가, 머지 는 사람 이

읽기 전용 루프 → 제안 루프 → 실행 루프 순 으로 신뢰 를 단계적 으로 이양 하는 것. 권한 을 한 번에 다 주는 게 아니라.

마무리 — 내 결론

내 홈랩 에는 이미 루프 의 조각 들 이 돌고 있다 — 5분 마다 로그 를 훑어 에러 를 알리는 크론, 배포 후 운영 도메인 을 때리는 E2E, 세션 이 남기는 메모리 가 다음 세션 을 고치는 기록. loop engineering 은 이 조각 들 을 하나 의 설계 언어 로 묶어 준 이름 이라고 생각 한다.

2026년 7월 의 진짜 변화 는 “AI 가 코딩 을 한다” 가 아니다. “AI 에게 일 을 시키는 단위 가 — 프롬프트 에서 루프 로 — 바뀌었다” 는 것 이다. 그리고 루프 를 설계 하는 능력 은, 결국 문제 를 정의 하는 능력 의 시간 축 버전 이다.