루프 엔지니어링 — 더 이상 에이전트에게 프롬프트하지 마라

2026년 6월, 개발자들의 타임라인이 한 문장으로 술렁였습니다.

"이제 코딩 에이전트에게 프롬프트하면 안 됩니다. 에이전트를 프롬프트하는 루프를 설계해야 합니다." — Peter Steinberger

여기에 Anthropic에서 Claude Code를 이끄는 Boris Cherny가 못을 박았습니다.

"저는 더 이상 Claude에게 프롬프트하지 않습니다. Claude에게 프롬프트하고 무엇을 할지 정하는 루프를 돌리고 있죠. 제 일은 루프를 작성하는 것입니다." — Boris Cherny

그리고 Google Chrome의 엔지니어링 리드 Addy Osmani가 이 흐름을 한 편의 글로 정리하며 이름을 붙였습니다. 루프 엔지니어링(Loop Engineering). 정의는 한 문장으로 압축됩니다.

"루프 엔지니어링은 에이전트에게 프롬프트하는 사람을 당신 자신으로 두던 자리를 대체하는 일이다. 대신 그 일을 해주는 시스템을 당신이 설계한다." — Addy Osmani

낯선 말처럼 들리지만, 사실 우리가 지난 4년간 걸어온 길의 가장 최근 한 걸음입니다. 이 글은 왜 이런 개념이 나왔는지를 역사와 논문에서부터 따라가, 루프가 실제로 무엇으로 이루어지는지, 그리고 2026년 지금 이 기술이 어떤 역할을 하는지까지 쉽고 자세하게 풀어냅니다. 용어가 생소해도 괜찮습니다. 비유와 그림, 그리고 직접 만져볼 수 있는 시뮬레이터로 하나씩 짚어가겠습니다.

이 글에서 다룰 것

1. 루프 엔지니어링이 정확히 무엇인가 — "추상화의 사다리"
2. 왜 나왔나 — ReAct(2022)에서 시작된 5년의 역사
3. 아키텍처 — 논문 속 그림으로 보는 ReAct와 Reflexion
4. 루프를 이루는 5가지 빌딩블록 (+ 메모리)
5. 실전 — 자율 루프 하루의 삶
6. 비용과 위험 — 같은 루프, 정반대 결말
7. 2026년, 그리고 균형

1. 루프 엔지니어링이란? — 추상화의 사다리

먼저 가장 큰 그림부터. 지난 몇 년간 "사람이 AI를 다루는 단위"는 계속 커져 왔습니다. Osmani는 이를 네 칸짜리 사다리로 정리합니다.

이 사다리를 한 줄로 읽으면 이렇습니다. 프롬프트는 한 문장, 컨텍스트는 창 전체, 하니스는 에이전트의 환경, 루프는 그 환경을 타이머에 걸어 스스로 돌게 만든 시스템. 루프는 하니스보다 한 단계 위의 추상화입니다. Osmani의 표현을 빌리면, 루프는 "타이머에 맞춰 돌고, 도우미를 스스로 불러내고, 자기 자신을 지탱하는" 무언가입니다.

가장 중요한 전환은 누가 다음 프롬프트를 입력하는가입니다.

왼쪽이 우리가 지금까지 해온 방식입니다. "한 줄 치고, 답을 읽고, 다음 줄을 친다." 오른쪽이 루프입니다. 그 "한 줄 치는 사람"의 자리에 당신이 한 번 설계한 시스템이 들어앉습니다.

핵심 개념을 한 단어로 정리하면 재귀적 목표(recursive goal)입니다. 당신은 목적과 완료를 확인할 수 있는 조건을 정의하고, AI는 그 조건이 참이 될 때까지 스스로 반복합니다. 루프 엔지니어링이 빛을 발하는 조건도 여기서 나옵니다 — 반복적이고, 오래 걸리고, 사람이 지켜보지 않아도 되는 일이면서, "끝났다"를 기계가 확인할 수 있는 일일 때입니다.

2. 왜 이 개념이 나왔나 — 5년의 역사

루프 엔지니어링은 어느 날 갑자기 튀어나온 유행어가 아닙니다. "LLM을 한 번 부르는 것으로는 부족하다. 생각하고-행동하고-관찰하는 고리(loop)로 묶어야 한다"는 깨달음은 2022년부터 차곡차곡 쌓여 왔습니다. 이정표를 따라가 봅시다.

이 타임라인의 가장 중요한 굴곡은 2023년 봄의 AutoGPT 좌절입니다. "목표만 주고 풀어놓으면 알아서 다 해준다"는 꿈은, 같은 행동을 끝없이 반복하는 무한 루프와, 완료를 모르고 멈추지 못하는 종료 조건 부재, 그리고 지갑을 태우는 비용 앞에서 무너졌습니다. 교훈은 분명했습니다. "루프 자체를 공학적으로 설계해야 한다." 루프 엔지니어링이라는 말은 바로 이 교훈의 2026년 버전입니다.

한 문장 요약: 프롬프트(2022) → 컨텍스트(2025) → 하니스(2026 초) → 루프(2026 중). 다루는 단위가 문장 → 창 전체 → 환경 → 스스로 도는 시스템으로 커져 왔습니다.

3. 아키텍처 — 논문 속 그림으로 보는 루프의 뿌리

루프가 왜 그렇게 강력한지 이해하려면, 모든 것의 원형인 ReAct의 구조를 봐야 합니다. 용어가 생소할 텐데, 그림과 함께 천천히 풀어가겠습니다.

3-1. ReAct — 생각하고, 행동하고, 관찰하라

ReAct는 "Reasoning + acting", 즉 추론과 행동을 합친 것입니다. 이전까지 LLM을 쓰는 방식은 두 갈래였습니다.

ReAct 논문의 그 유명한 Figure 1은 같은 질문(HotpotQA의 한 문제)을 네 가지 방식으로 푸는 모습을 나란히 보여줍니다.

핵심은 (d)입니다. ReAct는 생각(Thought) → 행동(Action) → 관찰(Observation)을 한 단위로 묶어 반복합니다.

이 고리가 다시 "그럼 X에 대해 한 번 더 찾아보자"는 다음 생각으로 이어집니다. 그래서 ReAct는 환각을 줄이고(매 단계 실제 도구로 사실을 확인하니까), 사람이 따라 읽기 쉬운(생각이 글로 남으니까) 풀이 과정을 만듭니다. 이 단순한 패턴이 이후 AutoGPT, LangChain의 에이전트, 그리고 오늘날 Claude Code·Codex의 밑바탕 골격이 되었습니다.

루프 엔지니어링의 "루프"는 바로 이 생각-행동-관찰 고리의 직계 후손입니다. ReAct가 한 작업 안의 작은 루프라면, 루프 엔지니어링은 여러 작업·여러 날에 걸친 큰 루프입니다.

아래 시뮬레이터로 자율 루프가 한 바퀴 도는 모습을 직접 돌려보세요. 각 단계가 어떤 빌딩블록(다음 장에서 설명)에 해당하는지도 함께 표시됩니다.

3-2. Reflexion — 실패를 말로 복기하는 루프

ReAct가 "도구를 쓰며 생각하기"였다면, Reflexion(2023)은 한 발 더 나아갑니다. "이번에 왜 틀렸지?"를 스스로 말로 적어 다음 시도에 반영하는 루프입니다. 놀라운 점은 모델의 가중치를 전혀 바꾸지 않는다는 것입니다. 오직 언어로 된 피드백만으로 성능을 끌어올립니다(그래서 "언어적 강화학습"이라 부릅니다).

Reflexion의 아키텍처는 세 개의 역할로 나뉩니다. 이 분업 구조가 바로 오늘날 루프의 "서브에이전트 분리"의 조상입니다.

이 세 역할이 만든 핵심 원칙이 하나 있습니다. 답을 쓴 모델이 자기 답을 채점하게 두지 마라. 코드를 작성한 모델은 자기 숙제에 너무 후한 점수를 줍니다. Reflexion은 평가를 분리해 이 편향을 깼고, 그 결과 HumanEval 코딩 벤치마크에서 91% 수준까지 올라갔습니다.

이 두 논문이 루프 엔지니어링에 남긴 유산

• ReAct → 생각-행동-관찰 고리 = 루프의 기본 박동
• Reflexion → 메이커와 체커의 분리 + 외부 메모리 = 신뢰할 수 있는 자율 운영의 핵심

4. 루프를 이루는 5가지 빌딩블록 (+ 메모리)

이제 본론입니다. Osmani는 작동하는 루프에 5가지 구조적 요소가 필요하다고 정리합니다. 그리고 모든 것을 떠받치는 여섯 번째, 메모리가 있습니다. 중요한 점 — Claude Code와 Codex 둘 다 지금 이 다섯 가지를 전부 갖췄습니다. 그래서 지금이 루프 엔지니어링의 시대인 것입니다.

① 오토메이션 — 루프의 심장박동

오토메이션은 정해진 일정에 따라 스스로 깨어나 일감을 발견·분류하는 메커니즘입니다. 루프의 심장박동이죠.

• Codex: Automations 탭에서 프로젝트·프롬프트·주기·실행 위치(로컬 또는 백그라운드 워크트리)를 설정. 결과는 트리아지 인박스로 가고, 성과 없는 실행은 자동 보관됩니다.
• Claude Code: /loop(주기마다 재실행), /goal(조건이 참이 될 때까지 실행), cron 작업, GitHub Actions 훅.

여기서 가장 중요한 원시 명령이 /goal입니다. 핵심 설계는 이렇습니다 — 매 턴이 끝날 때마다 별도의 작은 모델이 "끝났는가?"를 검증합니다. 즉, 코드를 쓴 에이전트가 자기 완료를 판정하지 않습니다. Reflexion의 평가자 분리가 여기서 제품 기능으로 부활한 셈입니다. OpenAI 내부에서도 일일 이슈 분류, CI 실패 요약, 커밋 브리핑 작성, 버그 사냥 같은 일에 이런 오토메이션을 쓴다고 합니다.

② 워크트리 — 부딪히지 않고 동시에 일하기

여러 에이전트를 동시에 돌리면 같은 파일을 서로 덮어쓰는 충돌이 생깁니다. git worktree가 이를 해결합니다. 같은 저장소 히스토리를 공유하되, 별도의 브랜치·별도의 작업 디렉터리를 만들어 각 에이전트를 격리합니다.

• Codex: 워크트리 내장 지원
• Claude Code: git worktree, 세션 격리용 --worktree 플래그, 서브에이전트의 isolation: worktree 설정

다만 Osmani는 솔직한 한계를 짚습니다. "몇 개를 실제로 돌릴 수 있는지는 도구가 아니라 당신의 리뷰 대역폭이 정한다." 10개를 병렬로 돌려도, 그 결과를 검토할 사람의 시간이 병목입니다.

③ 스킬 — 매번 처음부터 설명하지 않기

에이전트는 매 세션을 차갑게(cold) 시작합니다. 그리고 의도에 빈틈이 있으면 자신만만한 추측으로 그 구멍을 메웁니다. 이걸 Osmani는 의도 부채(intent debt)라고 부릅니다 — 같은 맥락을 반복해서 다시 설명하는 비용이죠.

스킬은 이 부채를 갚는 장치입니다. SKILL.md 파일(설명·메타데이터, 필요하면 스크립트·참고자료·에셋 포함)에 프로젝트의 관례, 빌드 절차, 프로젝트별 결정을 적어둡니다. 그러면 루프가 매 사이클 프로젝트를 처음부터 다시 추론하지 않고, 학습을 복리로 쌓습니다. $skill-name 또는 /skills로 부르거나, 작업 설명이 스킬 목적과 맞으면 자동 발동됩니다. 형식은 Codex와 Claude Code가 표준화되어 있어 이식도 됩니다. (스킬에 커넥터까지 묶으면 팀이 통째로 설치하는 플러그인이 됩니다.)

④ 커넥터 — 실제 환경 안에서 행동하기

커넥터(connectors)는 MCP(Model Context Protocol) 위에 만들어져, 에이전트가 외부 시스템을 보고 만지게 해줍니다. 이슈 트래커, 데이터베이스, 스테이징 API, 메신저… 이게 있어야 루프가 파일시스템만 보는 것을 넘어 실제 환경 안에서 행동합니다.

커넥터 덕분에 루프는 "CI가 초록불이 되면 스스로 PR을 열고, Linear 티켓을 연결하고, 채널에 핑을 보낸다."

⑤ 서브에이전트 — 만드는 자와 검사하는 자

루프의 신뢰도를 떠받치는 마지막 기둥. 한 에이전트는 탐색하고 구현하고(메이커), 다른 에이전트는 스펙·테스트·스킬에 맞춰 검증합니다(체커).

• Codex: .codex/agents/의 TOML 파일 — 이름·설명·지시·(선택)모델·추론 강도
• Claude Code: .claude/agents/ — 작업을 순차로 넘기는 에이전트 팀도 지원

Osmani의 한 줄이 이유를 다 말해줍니다.

"코드를 쓴 모델은 자기 숙제를 채점할 때 너무 후하다."

토큰은 더 들지만, 사람이 지켜보지 않는 자율 운영에서는 이 검증 분리가 신뢰의 값을 합니다.

⑥ 상태 / 메모리 — 모든 것의 토대

마지막으로, 모든 빌딩블록을 떠받치는 외부 메모리입니다. 모델은 실행과 실행 사이에 모든 것을 잊습니다. 그래서 완료한 일, 시도한 접근, 다음 할 일을 마크다운 파일이나 Linear 보드 같은 대화 바깥에 적어둡니다. 그래야 다음 사이클이 "처음부터"가 아니라 "여기서부터" 이어집니다. Boris Cherny가 CLAUDE.md를 세션을 가로지르는 영구 기억으로 쓰는 것도, "미래의 세션이 과거의 실수를 반복하지 않도록" 하기 위함입니다.

5. 실전 — 자율 루프 하루의 삶

빌딩블록들이 어떻게 한 편의 작동하는 루프로 엮이는지, Osmani가 든 대표 사례를 단계로 풀어보겠습니다.

그리고 이 사례의 핵심 한 줄.

"당신은 이걸 한 번 설계했다. 위 단계 중 어느 것도 당신이 직접 프롬프트하지 않았다."

이것이 "에이전트를 프롬프트하는 시스템을 설계한다"는 말의 실체입니다.

6. 비용과 위험 — 같은 루프, 정반대 결말

여기서 솔직해질 차례입니다. 루프는 마법이 아닙니다. Osmani 본인이 가장 길게 경고하는 부분이기도 합니다.

위험 1 — 검증은 여전히 사람의 몫

"지켜보지 않고 도는 루프는, 지켜보지 않고 실수도 하는 루프다."

메이커·체커 분리가 신뢰를 높이지만, 사람의 책임을 없애지는 못합니다. 루프가 잘못된 방향으로 자신만만하게 달리면, 그 결과물도 자신만만하게 틀립니다.

위험 2 — 토큰 비용 폭주

루프는 연산을 많이 씁니다. 그것도 예측하기 어렵게.

단일 에이전트는 채팅의 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰을 씁니다. AutoGPT 시절의 악몽도 잊으면 안 됩니다 — 한 사례에서는 에이전트가 망가진 도구를 5분 동안 400번 호출하기도 했습니다. 그래서 루프에는 하드 반복 상한, 토큰 예산, 진척 없음 감지, 서킷 브레이커, 그리고 시작 전에 못 박아둔 검증 가능한 종료 조건이 반드시 필요합니다.

위험 3 — 이해 부채와 인지 항복

가장 미묘하고 가장 위험한 함정입니다. 루프가 당신이 이해하는 속도보다 빠르게 코드를 출하할수록, 존재하는 코드와 당신이 실제로 아는 것 사이의 간격이 벌어집니다. 이걸 이해 부채(comprehension debt)라 합니다. 여기에 더 무서운 게 따라옵니다 — 인지 항복(cognitive surrender).

"편안한 자세가 가장 위험한 자세다. 루프가 스스로 돌면, 의견을 갖기를 멈추고 싶은 유혹이 너무 크다."

그래서 Osmani의 결론은 강렬합니다. 두 사람이 똑같은 루프를 만들어도, 정반대 결과를 얻을 수 있습니다.

"한 사람은 그것으로 자기가 깊이 이해하는 일을 더 빨리 한다. 다른 사람은 그것으로 일을 이해하는 것 자체를 회피한다."

아래 슬라이더로 그 갈림길을 직접 밀어보세요. 두 사람의 루프는 완전히 똑같습니다. 사이클이 돌수록 격차만 벌어집니다.

7. 2026년, 그리고 균형

자, 그래서 2026년 지금 이 기술은 어떤 자리에 서 있을까요? 사람의 역할이 어떻게 이동해 왔는지 한눈에 보면 흐름이 분명해집니다.

레버리지의 지점이 프롬프트 문장 다듬기에서 시스템 아키텍처 설계로 옮겨갔습니다. 하지만 — 그리고 이게 가장 중요한데 — 사람이 사라지는 게 아닙니다. 판단하고, 검증하고, 이해를 유지하는 역할은 오히려 더 중요해집니다. 추상화의 사다리를 올라갈수록, 한 번의 설계가 미치는 영향이 커지기 때문입니다.

그래서 이 글은 두 가지를 함께 권합니다. 루프를 세우되, 직접 프롬프트하는 것도 여전히 효과적이라는 걸 잊지 마세요. 무엇을 자동화하고 무엇을 손에 쥘지 — 균형을 찾는 게 핵심입니다. 반복적이고 검증 가능한 일은 루프에 맡기고, 새롭고 미묘하고 판단이 필요한 일은 직접 손을 대는 식으로요.

마지막은 Osmani의 문장으로 닫는 게 가장 좋겠습니다. 이 한 줄이 루프 엔지니어링의 정신을 모두 담고 있습니다.

"루프를 만들어라. 단, '시작 버튼만 누르는 사람'이 아니라 '계속 엔지니어로 남을 작정인 사람'처럼 만들어라." — Addy Osmani

핵심 요약

함께 읽으면 좋은 글 루프의 한 단계 아래, 에이전트가 도는 환경을 다루는 하니스(Harness) — AI가 스스로 일하는 방식을 설계하다와, 그 모든 것의 원형인 ReAct — 추론과 행동을 합치다를 이어 읽으면 그림이 완성됩니다.

참고 자료: Addy Osmani, "Loop Engineering"(addyosmani.com, 2026.06) · Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models"(arXiv 2210.03629, 2022) · Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning"(arXiv 2303.11366, 2023) · Boris Cherny, Peter Steinberger 공개 발언 · Claude Code / OpenAI Codex 공식 문서.