🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AI 코딩에서 “루프”란 사람이 계속 프롬프트를 입력하는 대신, 에이전트를 반복 실행·검증·중단시키는 작은 자동화 시스템을 설계하는 방식이며, 핵심은 모델보다 피드백과 통제 구조에 있다.

📌 핵심 요약

• Peter Steinberger의 “프롬프트하지 말고 에이전트를 프롬프트하는 루프를 설계하라”는 문장이 AI 코딩 담론의 중심이 됐다.
• Boris Cherny는 루프를 “Claude에게 직접 프롬프트하지 않고, Claude를 프롬프트하고 다음 행동을 결정하는 프로그램”으로 설명한다.
• 루프의 계보는 ReAct, AutoGPT, ralph loop, /goal, /loop를 거쳐 다중 에이전트 오케스트레이션으로 이어진다.
• 루프는 단순한 cron job과 닮았지만, 핵심 차이는 고정 스크립트가 아니라 모델이 현재 상태를 보고 다음 행동을 결정한다는 점이다.
• 실제 운영에서 중요한 것은 자동 실행 자체보다 검증, 중단 조건, 비용 상한, 재사용 가능한 skill이다.
• 저자의 결론은 “루프가 본질이 아니라 루프 안에서 호출되는 검증된 skill이 장기 자산”이라는 쪽에 가깝다.

🧩 주요 포인트

1. “루프”라는 표현은 널리 퍼졌지만, 많은 사람이 실제 의미를 명확히 설명하지 못한다.
2. Boris Cherny가 말하는 루프는 사람이 프롬프트를 반복하는 구조에서 벗어나, 프롬프트와 판단을 자동화한 상위 추상화다.
3. 기존의 ReAct나 AutoGPT, ralph loop와 달리 2026년식 루프는 동시 실행, 스케줄링, 내구성, 상태 복구를 포함한다.
4. 루프는 cron처럼 주기적으로 돌 수 있지만, 본질은 “타이머”가 아니라 “상태 기반 의사결정”이다.
5. 실무에서 루프의 신뢰도는 자체 검증, 리뷰, 테스트, 피드백 루프에 달려 있다.
6. 비용과 실패를 막기 위해 최대 반복 횟수, 진전 없음 감지, 토큰·달러 예산 제한이 필수다.

🧠 상세 정리

1. 논쟁의 출발점: “프롬프트가 아니라 루프를 설계하라”

원문은 Peter Steinberger가 올린 한 문장에서 출발한다. 그는 “이제 코딩 에이전트에게 프롬프트를 입력하지 말고, 에이전트에게 프롬프트를 입력하는 루프를 설계해야 한다”고 말했다. 이 문장은 큰 관심을 받았지만, 동시에 많은 사람이 “그래서 실제로 무엇을 하라는 뜻인가”를 두고 논쟁했다. 저자는 이 현상이 단순한 유행어의 확산이 아니라, AI 코딩 방식이 변하고 있음을 보여주는 신호라고 본다. 다만 핵심은 “프롬프트 엔지니어링이 죽었다”는 식의 과장된 결론이 아니다. 오히려 프롬프트를 사람이 계속 입력하는 방식에서, 프롬프트를 생성하고 실행 결과를 판단하는 구조 자체를 설계하는 쪽으로 역할이 이동했다는 점이 중요하다.

2. Boris Cherny의 정의: 모델은 하위 루틴이 되고, 사람은 루프 작성자가 된다

Boris Cherny는 Claude Code를 만든 인물로 소개되며, 원문은 그가 루프를 가장 명확히 설명했다고 본다. 그의 설명에 따르면 이제 그는 Claude에게 직접 프롬프트하지 않는다. 대신 Claude를 호출하고, 결과를 읽고, 다음에 무엇을 할지 결정하는 루프를 작성한다. 즉 모델은 독립적인 작업자가 아니라 루프 안에서 호출되는 하위 루틴이 된다. 이 변화는 개발자의 역할을 없애는 것이 아니라 추상화 수준을 올리는 것으로 설명된다. 예전에는 코드를 직접 작성했고, 그다음에는 여러 Claude 세션을 병렬로 띄워 각각 프롬프트했으며, 이제는 그 세션들을 작동시키는 루프를 쓴다는 것이다. 원문은 이 지점을 “코드를 쓰는 일에서 코드를 쓰는 것을 쓰는 일로 이동했다”고 정리한다.

3. 루프의 계보: ReAct, AutoGPT, ralph, /goal, 그리고 오케스트레이션

원문은 “루프”라는 단어가 여러 층위를 섞어 부르기 때문에 논쟁이 혼란스러워졌다고 본다. 첫 번째 층위는 2022년 ReAct 논문에서 정리된 형태다. 모델이 추론하고, 도구를 호출하고, 결과를 읽고, 다시 반복하는 구조다. 두 번째는 2023년 AutoGPT처럼 목표를 주고 모델이 스스로 프롬프트를 이어가게 한 방식이다. 세 번째는 Geoffrey Huntley의 ralph loop다. 이는 같은 프롬프트 파일을 반복적으로 에이전트에 입력하는 단순한 구조지만, 매번 고정된 anchor file로 컨텍스트를 재설정한다는 점이 중요했다. 네 번째는 Codex와 Claude Code의 /goal처럼 이런 반복 구조를 제품 기능으로 만든 단계다. 다섯 번째, 원문이 Boris와 Steinberger가 실제로 말한다고 보는 단계는 다중 루프와 다중 에이전트를 감독하고 스케줄링하는 오케스트레이션 루프다.

4. 기존 방식과의 차이: 단일 작업 반복이 아니라 운영 단위가 루프가 된다

원문이 말하는 최신 의미의 루프는 단순히 한 작업을 끝날 때까지 반복하는 장치가 아니다. 루프 자체가 작업 단위가 되고, 여러 루프를 감독하며, 정해진 시간에 자동으로 실행되고, 장애가 나도 상태를 복구할 수 있어야 한다. 이 점에서 “터미널을 열어둔 채 반복 실행하는 ralph loop”와 “인프라 위에서 계속 살아 있는 오케스트레이션 루프”는 다르다. 이 차이가 중요한 이유는 AI 코딩이 일회성 상호작용에서 배경 작업으로 이동하고 있기 때문이다. 사용자가 “이 파일 고쳐줘”라고 말하고 기다리는 방식이 아니라, 루프가 pull request를 감시하고, 빌드 실패를 고치고, 댓글이 달리면 worktree agent를 실행하는 식의 운영 구조가 된다. 사람의 주의력 대신 인프라 시간이 작업의 리듬을 정한다.

5. “그냥 cron job 아닌가?”라는 반론과 그 한계

원문은 회의적인 반응도 중요하게 다룬다. 누군가는 루프를 두고 “cron job이 재브랜딩된 것”이라고 비판했다. 저자는 이 반론이 절반은 맞다고 본다. 실제로 Boris도 cron을 사용하고, Claude Code의 /loop 역시 cron을 밑에서 활용한다. 주기적으로 무언가 실행한다는 점에서는 오래된 자동화와 닮았다. 하지만 원문은 cron과 루프의 핵심 차이를 “중간에 있는 의사결정자”에서 찾는다. cron job은 고정된 스크립트를 실행한다. 반면 루프는 모델이 현재 상태를 읽고, 다음 행동을 고르고, 결과를 확인한 뒤 계속할지 멈출지 판단한다. 따라서 정직한 설명은 “루프는 완전히 새로운 마법”도 아니고 “그냥 cron”도 아니다. cron 위에 모델 기반 의사결정을 넣고, 그 결정이 위험하게 흘러가지 않도록 감싸는 엔지니어링이 핵심이다.

6. 실제 구축에서 핵심은 실행보다 검증이다

Boris가 제시한 입문 예시는 /loop 명령으로 pull request를 감시하고, 빌드 문제를 자동 수정하고, 댓글이 오면 worktree agent로 고치게 하는 식이다. 원문은 이를 통해 사람이 세부 절차를 다 쓰는 것이 아니라, 의도와 종료 조건을 적고 루프가 매 tick마다 에이전트를 프롬프트하는 구조라고 설명한다. 하지만 저자가 반복해서 강조하는 것은 자동 실행 자체보다 자기 검증이다. 루프가 코드를 빠르게 작성할 수 있어도, 잘못된 커밋은 빠르게 누적될 수 있다. 그래서 roborev처럼 백그라운드에서 모든 커밋을 리뷰하고, 그 결과를 다시 에이전트에 전달하는 도구가 중요하게 등장한다. 원문 기준에서 “작동하는 루프”란 쓰고, 실행하고, 결과를 읽고, 수정하는 피드백을 포함한 구조다.

7. 비용의 이동: 코드를 쓰는 비용보다 루프를 관리하는 비용이 커진다

원문은 루프 담론이 철학이 아니라 비용 문제로 이어진다고 본다. 한 엔지니어는 올해 자신이 배포한 에이전트는 결국 for-loop, LLM 호출, JSON parsing용 try/catch였고, 가장 agentic한 것은 월말 Anthropic 청구서였다고 비꼰다. 이 농담은 루프가 실제 비용을 만든다는 점을 드러낸다. 원문은 Uber가 Claude Code와 Cursor 사용량에 대해 엔지니어 1인당 월 1,500달러 한도를 설정했다는 사례를 언급한다. 모델이 코드를 쓰는 비용이 낮아질수록, 비용은 루프를 얼마나 오래, 얼마나 자주, 얼마나 무분별하게 돌리느냐로 이동한다. 따라서 최대 반복 횟수, 진전 없음 감지, 토큰 또는 달러 예산 상한은 선택 사항이 아니라 운영 조건이 된다.

8. 저자의 핵심 thesis: 루프보다 중요한 것은 루프 안의 skill이다

글의 마지막에서 저자는 자신의 입장을 분명히 한다. 루프는 배관이고, 진짜 자산은 루프가 호출하는 skill이라는 것이다. 반복해서 하는 일은 자동화된 skill로 만들고, 어려운 일을 한 번 해결했다면 다음에 재사용할 수 있도록 skill로 정리해야 한다는 Steinberger의 다른 주장에 더 무게를 둔다. 이 관점에서 루프만 있고 재사용 가능한 skill이 없다면, 그것은 낯선 모델을 while-true로 감싼 것에 가깝다. 반대로 검증되고 이름 붙은 skill 라이브러리를 호출하는 루프는 시간이 갈수록 복리처럼 쌓일 수 있다. 원문의 결론은 루프가 유행어라는 데서 멈추지 않는다. 사람은 루프 안에서 프롬프트를 반복하는 존재가 아니라, 루프·skill·검증·중단 조건을 설계하는 존재가 되어야 한다는 것이다.

🧾 핵심 주장 / 시사점

• AI 코딩의 변화는 “더 좋은 프롬프트”에서 “프롬프트를 반복·검증·중단하는 시스템 설계”로 이동하고 있다.
• 루프의 새로움은 단순 반복이 아니라, 모델 기반 의사결정과 다중 에이전트 오케스트레이션, 내구성 있는 상태 관리에 있다.
• 루프의 성패는 모델 성능만이 아니라 검증 루틴, 리뷰 루프, 예산 제한, 종료 조건에 의해 좌우된다.
• 실무적으로 가장 축적 가치가 큰 단위는 개별 프롬프트가 아니라 재사용 가능한 skill이다.
• “루프를 설계하라”는 말은 개발자가 사라진다는 뜻이 아니라, 개발자의 작업 고도가 올라간다는 주장에 가깝다.

✅ 액션 아이템

• Boris Cherny가 언급한 /loop와 /goal 사용 방식이 실제 Claude Code 워크플로에서 어떤 차이를 갖는지 확인한다.
• Peter Steinberger의 “반복 작업은 skill로 만들라”는 주장과 루프 설계 주장을 함께 묶어 내부 자동화 후보를 정리한다.
• 현재 AI 코딩 워크플로에 최대 반복 횟수, no-progress detection, 토큰·비용 상한이 있는지 점검한다.
• PR 자동 수정, 빌드 실패 대응, 리뷰 피드백 반영처럼 self-verification이 가능한 작은 루프부터 실험한다.

❓ 열린 질문

• Boris Cherny가 말한 “수백 개 에이전트가 GitHub, Slack, Twitter를 읽고 다음 작업을 결정한다”는 구조에서 실제 우선순위 판단은 어디까지 자동화되어 있는가?
• 루프 안에서 호출되는 skill은 어느 수준까지 일반화해야 재사용성과 안전성을 동시에 확보할 수 있는가?
• 다중 에이전트 오케스트레이션 루프가 비용과 오류 누적을 넘어서 실제 생산성 향상으로 이어지는 조건은 무엇인가?