Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide)

3줄 요약

1. 이 글은 Data Science Dojo가 2026년 6월 9일 올린 개괄 가이드로, “에이전트 루프"라는 개념과 “루프 엔지니어링"이라는 실천을 처음부터 끝까지 한 번에 훑는다. 발단은 두 사람의 발언이다 — Anthropic에서 Claude Code를 만든 Boris Cherny가 “나는 더 이상 Claude에 프롬프트하지 않는다, 루프를 짠다"고 했고, OpenClaw 창업자 Peter Steinberger가 “코딩 에이전트에 프롬프트하지 말고 에이전트에 프롬프트하는 루프를 설계하라"고 한 글이 하루 만에 500만 조회를 넘겼다.
2. 에이전트 루프는 단 두 가지로 정의된다 — 트리거(루프를 시작시키는 것)와 검증 가능한 목표(도달해야 할 종료 상태). 에이전트는 다음 메시지를 기다리지 않고, 시작하고 돌리고 목표 달성 여부를 점검하고 아니면 다시 돈다. 이것이 프롬프트 엔지니어링과 갈리는 지점이다.
3. 글은 ReAct(2022)부터 Ralph 루프·/goal(2026)까지 루프 열 가지를 4세대로 나눠 계보를 그리고, 실패 양상(무한 루프·목표 드리프트·토큰 폭발)과 그것을 막는 가드레일을 정리한다. 결론은 하나다 — 지금 앞서가는 개발자는 더 나은 프롬프트를 쓰는 사람이 아니라 루프 엔지니어링을 익히는 사람이다.

이 글은 “루프 엔지니어링” 연재의 여섯 번째 편이다. 앞선 다섯 편이 각각 한 저자·한 조직의 1차 사료였다면 — 1편(Addy Osmani)이 “루프를 설계하라"는 선언을, 2편(Firecrawl)이 그 실천 노트를, 3편(Oracle)이 ReAct에서 출발한 에이전트 루프의 계보를, 4편(OpenAI)이 하네스를 직접 짠 생산자의 사례를, 5편(Böckeler/Fowler)이 그 하네스를 사용자 관점의 멘탈 모델로 정리했다면 — 이 6편은 그 모두를 한 장의 지도 위에 올리는 개관이다. 특히 3편이 짚은 ReAct 계보를 더 넓게 펼쳐, 학술 프레임워크부터 실무자의 루프 엔지니어링까지 4세대를 한눈에 비교한다. 연재 전체를 묶어 읽는 좌표계로 삼기 좋은 편이다.

에이전트 루프란 무엇인가

에이전트 루프는 이름보다 단순하다. 두 가지만 있으면 된다.

1. 트리거 — 루프를 시작시키는 무언가 (PR이 열리거나, 스케줄이 돌거나, 사람이 “가"라고 말하거나).
2. 검증 가능한 목표 — 에이전트가 향해 가는, 정의된 종료 상태.

에이전트는 다음 메시지를 기다리지 않는다. 시작하고, 돌리고, 목표에 닿았는지 점검하고, 아니면 닿을 때까지 — 또는 정지 조건이 켜질 때까지 — 다시 돈다.

에이전트에게 프롬프트가 아니라 목표를 준다. 에이전트가 단계를 스스로 짜고, 실행하고, 자기 일을 점검하고, 계속 나아간다.

결정적 목표는 쉽다 — 모든 테스트 통과, CI 초록, 함수가 오류 없이 실행. 어려운 쪽은 “이 기능을 만들어라"처럼 완료가 무엇인지 정의하는 데 전체 명세를 미리 써야 하는 목표다. 바로 그 점이 루프 엔지니어링을 어렵게, 그래서 값지게 만든다.

루프와 자동화는 어떻게 다른가

헷갈리기 쉬워 짚고 넘어간다.

자동화는 일련의 단계를 실행한다. 스크립트를 돌리고 레시피를 따른다. 아무것도 결정하지 않는다.

루프는 그 안에 의사결정이 있다. 에이전트가 목표에 닿았는지 아닌지를 능동적으로 판단한다. 그저 실행하는 게 아니라 평가하고, 돌고, 발견한 것에 맞춰 조정한다. 핵심 차이는 목표 검증 단계가 있느냐다.

세 가지 트리거 유형

모든 에이전트 루프는 트리거로 시작한다. 종류는 셋뿐이다.

• 이벤트 기반 — 무언가 일어난다: PR이 열리고, 파일이 바뀌고, API 호출이 끝난다.
• 스케줄 — cron이 켜진다: 30분마다, 한 시간마다, 하루마다.
• 사람 시작 — 사람이 목표를 입력하고 “가"라고 한다.

Claude Code의 /loop 명령이 가장 단순한 사람 시작 유형이다 — /loop every 5 minutes, compare what we have built with our full spec and continue building until we complete it.

에이전트 루프는 내부에서 어떻게 도는가

모든 에이전트 루프는 다섯 단계를 거쳐, 정지 조건이 만족될 때까지 반복한다.

1. 인식(Perceive) — 입력을 받는다: 사용자 목표, 도구 결과, API 응답, 또는 직전 행동의 오류.
2. 추론(Reason) — 입력이 뜻하는 바, 이미 아는 것, 아직 필요한 것, 가진 선택지를 따져 본다.
3. 계획(Plan) — 다음에 무엇을 할지 고른다. 단순한 루프는 한 단계를, 복잡한 아키텍처는 전체 작업 분해를 낸다.
4. 행동(Act) — 실행한다: 도구를 부르고, 파일을 쓰고, 코드를 돌리고, DB를 질의하고, 다른 에이전트를 조율한다.
5. 관찰(Observe) — 결과를 받아 이해를 갱신한다. 성공은 전진시키고, 실패는 “왜"에 대한 추론을 촉발한다.

그리고 1단계로 되돌아간다. 이 구조는 강화학습과 직접 닮았다 — 루프에는 검증 가능한 보상 신호, 곧 목표 도달 여부를 아는 장치가 필요하다. 그 보상은 결정적(테스트 통과·타입 오류 없음)일 수도, 비결정적(LLM이 출력의 목표 부합을 평가)일 수도 있다.

루프는 언제 멈추는가

LLM에는 “완료"라는 내장 개념이 없다. 명시적 정지 조건이 없으면 루프는 돈이 떨어질 때까지 돈다. 모든 프로덕션 에이전트 루프에는 다음이 필요하다.

• 하드 반복 상한
• 실행당 토큰·비용 예산
• 무진전 탐지 (반복 사이에 아무것도 안 바뀌면 종료)
• 검증 가능한 기준에 대고 하는 목표 달성 점검
• 작업 수준·개별 도구 호출 수준 양쪽의 타임아웃

“에이전트가 알아서 끝낼 때를 정하게 두자"는 전략은 생각보다 빨리 토큰 한도를 소진시킬 수 있다. 아래의 모든 루프 유형은 부분적으로 이 문제를 풀려고 만들어졌다.

에이전트 루프 유형 전부 — 4세대 계보

1세대: 개념 증명 (2023)

AutoGPT — 2023년 3월 30일 공개. 수백만 개발자 앞에 루프 개념을 처음 들이민 사건이다. GPT-4에 고수준 목표를 주면 하위 작업으로 쪼개고, 웹 브라우징·파일 관리 같은 도구로 실행하고, 결과를 성찰하며 루프를 돈다. 몇 달 만에 깃허브 별 10만 개를 모아 수요가 진짜임을 증명했다. 다만 비싸고 불안정해 일상 사용자에게 널리 받아들여지진 못했다 — 무한 루프에 빠져 막대한 API 청구서를 만든다는 불평이 잦았다. 흥미로운 기술 실험이었지 믿을 만한 생산성 도구는 아니었다.

2세대: 학술 프레임워크 (2022-2023)

ReAct — 2022년 10월 6일, AutoGPT보다 다섯 달 앞서 프린스턴·구글 리서치가 발표했다. Reasoning + Acting의 약자로, 매 단계 에이전트가 둘을 낸다 — 추론 흔적(“이 엔드포인트를 부르기 전에 API 레이트 리밋을 확인해야 한다”)과 구체적 행동(실제 도구 호출). 각 행동의 관찰이 다음 추론으로 들어가, 예상 밖 결과가 오면 맹목적 재시도 대신 “왜"를 추론한다. ALFWorld에서 34%, WebShop에서 10%(행동만 하는 방식 대비) 개선했다. LangChain AgentExecutor와 대부분의 프로덕션 코딩 에이전트 안에 들어 있는 패턴이며, 루프 엔지니어링의 기본 출발점이다.

Reflexion — NeurIPS 2023. ReAct에 자기 평가 층을 더했다. 작업을 마치거나 실패한 뒤 무엇이 잘못됐는지 비평을 만들어 메모리에 저장하고, 다음 시도의 컨텍스트에 주입한다. ReAct보다 비싸지만(성찰용 LLM 호출 추가) 디버깅·낯선 코드베이스·창의적 문제 같은 시행착오 과제에서 낫다. 단순 검색에는 보통 오버헤드만큼의 값을 못 한다.

Plan-and-Execute — 생각과 실행을 분리한다. 플래너가 전체 작업 분해를 미리 내고, 실행자가 단계를 밟고, 리플래너가 실행이 계획에서 벗어나면 조정한다. LangChain의 LLMCompiler는 독립 단계를 병렬로 돌려 순차 ReAct 대비 3.6배 속도를 보고했다(Kim et al., ICML 2024). 절충점은 초기 단계가 예상 밖 결과를 낼 때 덜 적응적이라는 것 — Plan-and-Execute는 계획에 헌신하고, ReAct는 매 단계 재조정한다.

3세대: 아키텍처 패턴 (2024)

OODA 루프 — 미 공군 대령 John Boyd에게서 왔다: 관찰(Observe)·정향(Orient)·결정(Decide)·행동(Act). 독특한 기여는 정향 단계다. 대부분의 루프가 관찰에서 결정으로 바로 뛰는데, OODA는 그 사이에 맥락화 단계를 넣는다 — 결정 전에 날 관찰을 목표·제약·사전 지식에 비춰 처리한다. 복잡하고 빠르게 변하는 환경의 에이전트에게 이 한 단계가 결정 품질을 측정 가능하게 높인다.

내부/외부 이중 루프 — 마이크로소프트 Magentic-One 아키텍처. 외부 루프는 전략 계획을 세우고 원래 목표 대비 진척을 감시하며, 내부 루프는 현재 전략 안에서 단계별 실행을 맡는다. 내부 루프가 막히면 외부 루프가 현재 단계만 재시도하는 게 아니라 전체 전략을 리셋한다. 물러설 장치가 없어 깨진 접근을 반복하는 “고집스러운 실패” 패턴을 막는다.

멀티에이전트 오케스트레이션 — 감독자(supervisor)가 전문화된 하위 에이전트들(플래너·실행자·연구자·검증자)에게 일을 배분한다. 감독자는 실행하지 않고 조율한다. 숫자가 말한다 — Anthropic의 멀티에이전트 연구 시스템은 내부 평가에서 단일 에이전트보다 90.2% 앞섰다. 다만 단일 에이전트가 일반 챗 대비 토큰을 약 4배, 멀티에이전트는 약 15배 쓴다. 병렬 탐색이나 한 컨텍스트 창을 넘는 진짜 복잡성이 필요한 과제에 맞고, 대부분의 과제엔 과하며, 그 비용은 정당화돼야 한다.

4세대: 실무자의 루프 엔지니어링 (2025-2026)

Ralph 루프(Ralph Wiggum 기법) — Geoffrey Huntley가 2025년 7월 고안했다. 문틀에 부딪히며 “나 돕고 있어!“라고 외치는 심슨 캐릭터에서 이름을 땄다. 의도적으로 단순한데 놀랍도록 효과적이다. 코딩 에이전트가 무한 셸 루프 안에서 돌고, 매 반복마다 디스크의 같은 프롬프트 파일을 읽고, 코드베이스를 고치고 종료하면, 새 컨텍스트 창으로 루프가 다시 시작한다. 상태는 파일 시스템에 산다 — 코드베이스·TODO 파일·git 이력. 이 단순함이 두 문제를 푼다.

1. 컨텍스트 오버플로 — 긴 세션은 컨텍스트 창이 차며 성능이 저하된다. Ralph 루프는 매 반복 컨텍스트를 리셋하고, 새 세션이 디스크에서 현재 상태를 읽는다.
2. 조기 종료 — LLM은 주관적으로 완료라 판단하면 멈춘다. Stop Hook이 종료 시도를 가로채 완료 기준(테스트 초록·커버리지 임계·타입 체크 통과)이 실제로 충족됐는지 점검하고, 아니면 작업 프롬프트를 다시 주입한다.

해커톤에서 나왔지만 반년도 안 돼 표준 패턴이 됐다.

/goal 명령과 /loop — 지속적 루프 엔지니어링을 AI 코딩 도구에 직접 내장한 두 구현이다. **Claude Code /goal**은 2026년 5월 12일 버전 2.1.139에 실렸다. 완료 조건을 정하면 Claude가 충족될 때까지 여러 턴에 걸쳐 자율로 일하며 경과 시간·턴·토큰을 추적한다. 핵심 기제는 별도 평가자 모델이 매 턴 끝에 목표 조건 충족 여부를 점검해, 통과할 때만 루프를 멈춘다는 것이다. Codex CLI /goal(v0.128.0)은 같은 개념의 Codex판으로, 세션 단절을 견디는 지속 목표를 설정한다. 한 기록된 실험에서는 25시간 무중단, 토큰 1,300만 개, 코드 3만 줄을 냈다. 둘 다 목표를 미리 명시해야 하며, 목표가 추상적일수록 루프는 더 비싸고 예측 불가해진다.

Boris Cherny의 병렬 루프 워크플로 — 루프 엔지니어링을 주류 개발자에게 보이게 만든 작업 방식이다. 터미널에 탭 번호로 구분한 Claude Code 인스턴스 5개, 브라우저에 동시 5~10개 세션, 에이전트가 입력을 요구할 때만 확인하게 하는 시스템 알림, 로컬과 클라우드 사이에 컨텍스트를 넘기는 “텔레포트” 명령, 그리고 모든 새 세션이 시작 때 읽는 영속 지시 층 CLAUDE.md. 핵심 통찰은 CLAUDE.md다 — 에이전트가 저지른 실수마다 교정을 CLAUDE.md에 넣어, 다음 세션이 그 실수를 되풀이하지 않게 한다. 컨텍스트 리셋을 견디고 누적되는 프로젝트 지식의 기록이 된다.

에이전트 루프 안의 메모리

메모리는 학습하는 루프와 그저 반복하는 루프를 가른다. 메모리가 없으면 매 반복이 눈먼 채 시작한다. 프로덕션에서 쓰는 네 종류는 이렇다.

• 에피소드 메모리 — 이전 행동과 결과의 기록. 특정 접근이 실패했음을 떠올려 반복을 피한다.
• 시맨틱 메모리 — 구조화된 도메인 지식: 아키텍처 결정, 명명 규칙, API 문서.
• 벡터 메모리 — 유사도 기반 검색. 저장 방식과 요청 방식이 달라도 관련 컨텍스트를 찾는다.
• 파일 기반 메모리 — Ralph 루프 방식. 상태가 파일 시스템에 산다. 코딩 작업에는 벡터 스토어보다 단순하고 믿을 만하다.

CLAUDE.md는 사람이 큐레이션한 시맨틱 메모리다. 무엇을 넣을지 사람이 정하므로 자동 생성 메모리보다 믿을 만하다. 루프가 실행 도중 외부 지식을 검색하면 그것은 에이전틱 RAG 패턴 — 한 번에 미리 검색하는 게 아니라 언제 무엇을 검색할지 동적으로 정하는 — 을 도는 것이기도 하다.

실패 양상

다음은 전부 프로덕션에서 실제로 나타난다.

• 무한 루프 — 객관적 목표 검증이 없다. 에이전트는 늘 개선할 거리를 찾아낼 수 있어 끝없이 다듬는다. 2023년 AutoGPT 사건이 교과서적 예다.
• 목표 드리프트 — 에이전트가 관련은 있되 다른 목표를 좇는다. 모호한 명세나 옆으로 끌고 가는 도구 결과가 원인이다.
• 컨텍스트 오버플로 — 긴 세션이 컨텍스트 창을 채워 추론이 저하된다. Ralph 루프는 이걸 풀려고 존재한다.
• 조용한 실패 — 에이전트가 자신감 있는 출력을 내면서 실제로는 아무 진전이 없다. 도구 호출은 일어나는데 바뀌는 게 없다. 가장 잡기 어렵다.
• 토큰 비용 폭발 — 단일 에이전트가 표준 챗의 약 4배, 멀티에이전트가 약 15배. Steinberger는 한때 월 토큰 사용액 130만 달러를 인정했다. 한 기록된 사건에서는 에이전트가 깨진 도구를 5분간 400번 불렀다.
• 오류 전파 — 루프 초반의 한 번의 잘못된 결정이 이후 모든 단계로 복리처럼 불어난다. 끝에서만이 아니라 매 단계에서 검증해야 한다.

루프 엔지니어링 — 가드레일

루프 엔지니어링과 그냥 루프를 돌리는 것의 차이는 가드레일이다. 이건 선택이 아니다.

• 하드 반복 상한 — 에이전트가 멈추고 현재 상태를 보고하기 전 최대 사이클 수.
• 토큰·비용 예산 — 실행당 하드 지출 한도를 첫날부터 넣는다.
• 무진전 탐지 — 반복 사이에 출력 상태가 안 바뀌면 종료.
• 서킷 브레이커 — 도구 호출 재시도 한도, 정해진 횟수 후 명확한 실패 보고.
• 종료 기준 — 루프 시작 전에 “완료"를 정의하되, 에이전트의 자기 평가가 아니라 검증 가능한 자동 점검으로.
• 사람 개입 체크포인트 — 되돌릴 수 없는 행동(DB 쓰기·배포·외부 API 호출) 전 필수 검토.

목표는 자율을 없애는 게 아니라 경계 짓는 것이다.

어떤 루프를 고를까

가장 단순한 루프부터 시작하고, 개선을 측정할 수 있을 때만 복잡성을 더한다.

도구 네 개를 가진 단일 ReAct 에이전트가 실제 작업의 대부분을 처리한다. 멀티에이전트는 세션당 약 15배 비싸고, 그 비용은 산출로 정당화돼야 한다.

지금 모두를 위한 것인가

솔직한 답은 “아니다"이다. 루프 엔지니어링은 진짜 강력하지만 토큰 비용도 진짜다. 단일 에이전트가 약 4배, 멀티에이전트가 약 15배를 쓴다. Cherny와 Steinberger처럼 여러 세션에 걸쳐 병렬 루프를 돌리려면, 지금으로선 소수 기업만 엔지니어에게 무제한으로 주는 종류의 토큰 예산이 필요하다. 두 사람 모두 그 예산이 사실상 제약이 아닌 회사(각각 Anthropic·OpenAI)에서 일한다. 비용은 진짜고 기법도 진짜인데, 그 둘 사이의 간극에 대부분의 개발자가 서 있다.

그 간극은 닫힐 것이다. 컴퓨트는 늘 그래 왔다. 오늘 큰돈이 드는 것이 몇 해 뒤엔 일상 인프라가 된다. 지금 경제성이 맞지 않더라도 루프 엔지니어링은 지금 이해해 둘 가치가 있다.

다음에 올 것

• 에이전트 하네스가 으뜸 개발 도구가 되고 있다 — 오케스트레이션 로직, 메모리 관리, 비용 통제, 그리고 루프 엔지니어링을 규모에서 믿을 만하게 만드는 관측 가능성.
• 감사 가능성(auditability)이 협상 불가가 되고 있다. 루프가 더 긴 시간 지평에서 중대한 행동을 하기 때문이다.
• 자기 최적화 루프 — 자기 토큰 사용을 추적해 접근을 조정하는 루프 — 가 실험에서 프로덕션으로 넘어오고 있다.
• 사람의 역할이 옮겨 간다: 코드 쓰기 → 프롬프트 쓰기 → 루프 설계 → 루프를 돌리는 공장 짓기.

사람이 끝내 루프에서 완전히 빠질지는 열린 질문이다. 지금은 여전히 필요하다. 하지만 방향은 분명하다.

가장 곱씹은 대목

내가 가장 오래 머문 것은 이 글이 지도라는 사실 자체다. 앞선 다섯 편이 저마다 한 지점을 깊이 팠다면, 이 글은 그 지점들이 어디에 놓이는지 알려 주는 좌표계를 깐다. ReAct(2022)를 원점에 두고 4세대를 한 축에 늘어놓으면, “Ralph 루프냐 /goal이냐 멀티에이전트냐"로 흩어지던 이름들이 계보로 정렬된다. 흥미로운 건 그 계보가 한 방향으로만 흐르지 않는다는 점이다 — 가장 정교한 4세대 기법(Ralph 루프)이 가장 단순한 무한 셸 루프로 회귀하고, 가장 화려한 멀티에이전트가 가장 비싼 청구서를 낸다. 진화가 곧 복잡화는 아니라는 것.

또 하나 눈여겨본 것은 글이 끝에서 그린 역할의 사다리다 — 코드 쓰기에서 프롬프트 쓰기로, 다시 루프 설계로, 끝내 “루프를 돌리는 공장 짓기"로. 이 연재가 1편부터 되풀이해 온 명제 — 프롬프트가 아니라 루프를 설계하라 — 가 여기서 한 칸 더 나아간다. 루프조차 손으로 짜는 게 아니라, 루프를 찍어 내는 공장을 짓는 단계. 가드레일 목록(반복 상한·비용 예산·무진전 탐지·서킷 브레이커)이 그토록 건조하게 나열된 이유도 거기 있다. 자율을 없애는 게 아니라 경계 짓는 일이야말로, 공장의 설계도에 가장 먼저 들어가는 항목이기 때문이다.

출처

Data Science Dojo Staff, “Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide)”, Data Science Dojo, 2026년 6월 9일. 본문 도식 3점은 원문에서 인용했다. 원문: https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/