Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops

3줄 요약

1. 이 글은 Firecrawl의 Hiba Fathima가 2026년 6월 11일에 쓴 실무자용 해설로, Peter Steinberger의 여섯 단어짜리 트윗(“에이전트에게 프롬프트하지 말고, 에이전트를 프롬프트하는 루프를 설계하라”)이 일으킨 논쟁을 출발점으로 삼는다.
2. 루프는 act → observe → reason → repeat의 네 단계 사이클이 본체이고, 그 둘레를 트리거·워크트리 격리·스킬·서브에이전트 분업·커넥터·플러그인·기억 일곱 조각이 감싼다. Codex와 Claude Code 양쪽에 이 부품들이 이미 제품으로 들어와 있다.
3. 루프 엔지니어링의 진짜 일은 루프를 멈추게 하는 것이다. 반복 상한·무진전 감지·예산 상한 세 가드가 없으면 그건 루프가 아니라 청구서고, 검증과 취향(taste)은 끝까지 사람 몫으로 남는다.

이 글은 “루프 엔지니어링” 연재의 두 번째 편이다. 첫 편(Addy Osmani의 원형 정의)이 개념을 세운 글이라면, 이번 Firecrawl 글은 같은 개념을 실무 부품과 비용 문제, 그리고 웹 데이터 피드백이라는 각도에서 다시 본다. 흥미롭게도 이 글은 Osmani의 층위 비유를 직접 빌려 쓴다.

발단 — 여섯 단어의 트윗

Peter Steinberger가 2026년 6월 7일에 올린 문장 하나가 그달 내내 기술 트위터를 붙들었다.

더 이상 코딩 에이전트에게 프롬프트해서는 안 된다. 에이전트를 프롬프트하는 루프를 설계해야 한다.

이 트윗은 220만 조회를 넘겼고, 답글은 그게 무슨 뜻이냐를 두고 난투극이 됐다. 트위터 밖 반응도 똑같이 갈렸다. “루프 엔지니어링이 다음 AI 개발 유행어냐"를 묻는 레딧 스레드에서 개발자들은 “이건 진짜 다음 추상화 계층이다"와 “모자만 쓴 cron job이다” 사이를 오갔다.

루프 엔지니어링이 다음 추상화 계층인지, 이름만 바꾼 cron job인지를 두고 개발자들의 의견이 갈렸다. (출처: Firecrawl 블로그)

Claude Code를 만든 Boris Cherny는 이틀 앞서 무대에서 같은 생각을 가장 깔끔하게 정리했다.

나는 더 이상 Claude에게 프롬프트하지 않는다. 돌아가는 루프들이 있다. 그것들이 Claude에게 프롬프트하고 무엇을 할지 판단한다. 내 일은 루프를 쓰는 것이다.

루프 엔지니어링이란 무엇인가

지난 2년간 코딩 에이전트와 일하는 경험은 고강도 탁구에 가까웠다. 지시문을 다듬고, 기다리고, 돌아온 것을 훑고, 조정해서 다음 지시를 보낸다. 엔진은 사람의 주의력이다. 키보드에서 손을 떼면 에이전트는 턴 중간에 얼어붙는다.

루프 엔지니어링은 사람이 엔진이기를 그만두는 수다. 작은 프로그램(짧은 셸 루프일 때도, 호스팅된 태스크일 때도, 수백 줄짜리 TypeScript일 때도 있다)을 쓰고, 그 프로그램이 모델과 대화한다. 다음 태스크를 고르고, 보내고, 돌아온 결과를 채점하고, 결과를 로그에 남기고, 한 번 더 돌릴지 판단한다. 모델은 더 이상 채팅창 건너편의 협업자가 아니라, 프로그램이 while 안에서 호출하는 함수다.

여기서 Addy Osmani의 층위 비유가 유용하다. 프롬프트 엔지니어링이 한 층이라면, 에이전트 하네스 엔지니어링(에이전트 하나가 돌아가는 환경을 설계하는 일)이 그 위층이고, 루프 엔지니어링은 하네스보다 한 층 더 위에 앉는다. 하네스는 여전히 중요하다. 루프는 그 위에서, 스케줄에 따라, 도우미를 띄우고 자기 자신에게 먹이를 주며 돈다.

Shann Holmberg는 이 패턴이 나타나는 두 규모를 짚는다. 작은 쪽에서는 단일 에이전트가 리서치·초안·자기검토·수정을 결과물이 기준을 넘을 때까지 반복한다. 큰 쪽에서는 오케스트레이터가 목표를 조각으로 나눠 각 전문가에게 맡기고, 그 전문가들이 다시 자기 도우미에게 기댄다. 메커니즘은 동일하고, 바뀌는 건 머릿수뿐이다.

어떤 루프든 중심에는 같은 4단계 사이클이 있다. act, observe, reason, repeat. 에이전트가 무언가를 하고, 돌아온 것을 읽고, 그게 목표에 비춰 무슨 의미인지 판단하고, 한 번 더 갈지 결정한다. 나머지(스케줄·워크트리·서브에이전트·상태 파일)는 전부 이 사이클을 둘러싼 골조다.

세 용어의 차이

프롬프트 엔지니어링, 에이전틱 워크플로우, 루프 엔지니어링은 서로 바꿔 쓰이지만 그래선 안 된다. 글이 정리한 차이는 이렇다.

내 작업이 정말 루프 모양인가

범주를 아는 것과 내 작업이 거기 속하는지를 아는 것은 별개다. 루프를 짓기 전에 후보를 세 검사로 거른다.

• 반복적인가(Repetitive). 시스템을 설계하는 비용을 갚을 만큼 자주 하는 일인가.
• 검토 가능한가(Reviewable). “완료"를 에이전트나 검증 서브에이전트가 실제로 돌릴 수 있는 체크로 표현할 수 있는가. 통과가 무엇인지 정의할 수 없으면 루프는 언제 멈춰야 할지 모른다.
• 가치 있는가(Valuable). 산출물이 토큰값을 하는가. 루프에는 시간과 돈의 바닥 비용이 있다. 사소한 일은 그 문턱을 넘지 못한다.

셋을 다 갖추면 그 일은 루프를 원한다. 하나라도 빠지면 손으로 프롬프트하거나 평범한 스크립트를 쓰는 편이 낫다.

돌아가는 루프의 해부학

프로덕션에서 살아남는 루프는 같은 문제 묶음을 푼다. 언제 돌지, 동시에 도는 에이전트들이 어떻게 서로를 피하는지, 어떤 지식을 들고 오는지, 일을 어떻게 나누고 검증하는지, 나머지 스택에 어떻게 닿는지, 동료에게 어떻게 넘기는지, 실행 사이에 무엇을 기억하는지. Codex와 Claude Code는 이 부품들에 다른 이름을 붙이지만 책임은 일치한다.

• 트리거(The trigger). 사람이 타이핑하지 않는 무언가가 실행을 시작해야 한다. Codex에서는 Automations 탭(리포·프롬프트·스케줄·샌드박스를 고르면 결과가 Triage에 쌓인다), Claude Code에서는 /loop·/goal·예약 태스크·훅·GitHub Actions의 조합이다. 트리거는 정지 조건과 묶여서 와야 한다.
• 동시 에이전트 간 격리. 두 에이전트가 같은 체크아웃을 동시에 건드리면 조용한 덮어쓰기 아니면 요동치는 머지 중 하나가 난다. Git 워크트리가 각 에이전트에게 자기 브랜치와 작업 사본을 주되 같은 리포로 뒷받침해 이 문제를 푼다. 워크트리 없이 병렬로 돌리면 경쟁 상태를 지은 것이다.
• 에이전트가 다시 발견하지 않아도 되도록 성문화된 컨텍스트. 스킬(SKILL.md 한 장과 필요한 스크립트·픽스처를 담은 폴더)은 프로젝트별 지식이 실행 사이를 건너 살아남는 방식이다. 에이전트는 frontmatter의 설명이 작업과 맞을 때 스킬을 로드하는데, 대부분이 망치는 게 바로 그 설명이다. 선언문이 아니라 태그라인처럼 써라.
• 서브에이전트 간 분업. 가장 빨리 본전을 뽑는 루프 패턴은 작성자와 검토자를 가르는 것이다. 한 에이전트(또는 서브에이전트 체인)가 변경을 만들고, 별도의 에이전트(흔히 더 가벼운 모델)가 프로젝트 규칙과 돌릴 수 있는 테스트에 비춰 채점한다. 채점자가 작성자보다 똑똑할 필요는 없다. 그저 자기 지시와 자기 루브릭을 가진 다른 존재이기만 하면 된다.
• 커넥터(Connectors). 작업 디렉토리 안에 갇힌 루프는 거창한 스크립트일 뿐이다. 커넥터는 루프가 이슈 트래커·스테이징 API·데이터 웨어하우스·Slack·모니터링·라이브 웹에 닿는 통로다. 이들은 MCP 위에서 돌고, Codex와 Claude Code가 둘 다 MCP를 말하므로 한 하네스에 맞춘 커넥터가 거의 그대로 다른 쪽에 끼워진다. 패치를 건네는 에이전트와, PR을 열고 Linear 티켓을 걸고 #engineering에 글을 올리고 CI를 스스로 기다리는 루프를 가르는 선이 여기다.
• 플러그인(Plugins). 플러그인은 커넥터보다 한 단계 위로, 커넥터 묶음과 그것을 쓸 줄 아는 스킬을 함께 싸서, 동료가 리포에서 역설계하는 대신 단 한 번의 명령으로 루프 전체를 설치하게 한다. 커넥터가 배선이라면 플러그인은 배선에 설명서를 더한 것이다.
• 프로세스보다 오래 사는 기억. 위의 어느 것도 루프가 어제 한 일을 기억하지 못하면 소용없다. 형태는 일부러 따분하다. 리포 안의 마크다운 체크리스트, 그 옆의 JSON 파일, Linear 보드, SQLite 데이터베이스 중 하나를 골라 매 실행이 시작할 때 읽고 끝날 때 덧붙이게 한다. 크래시·컨텍스트 리셋·새벽 3시의 프로세스 종료를 루프가 견디는 방식이다.

열린 루프 vs 닫힌 루프

Holmberg는 루프 모양을 고르는 가장 쓸모 있는 축으로 열림/닫힘 구분을 그린다.

• 열린 루프(Open loops) 는 구조를 표면적과 맞바꾼다. 목표와 가드레일을 주고 에이전트가 스스로 길을 고르게 한다. 프로토타이핑이나 미지의 지형에 좋다. 함정은, 프로젝트 기준이 모호하면 산출물 대부분이 소음이라는 것이다.
• 닫힌 루프(Closed loops) 는 계약을 뒤집는다. 각 단계가 무엇을 하고 어떻게 검사되며 언제 멈출 수 있는지 길을 먼저 그리고, 에이전트는 그 골조 안에서 반복한다. 실행 비용이 예측 가능하고, 매 실행이 같은 루브릭으로 채점되므로 결과가 시간이 갈수록 나아진다.

프로덕션에서는 닫힌 쪽이 기본값으로 이긴다. 루프 하나가 목표를 책임지게 하고, 단계는 전담 전문가에게 주고, 좁은 잡일은 서브에이전트로 내리고, 자동 검사가 무엇을 통과시킬지 결정하게 한다. 열린 루프는 일이 무엇인지 아직 알아내는 중이거나, 토큰을 태우는 게 목적인 사이드 프로젝트에서 돌릴 만하다.

루프를 멈추게 하는 것이 가장 어렵다

루프 엔지니어링의 낭만적 버전은 루프를 쓰면 천 마리 에이전트가 밤새 회사를 짓는다는 것이다. 프로덕션 버전은, 루프를 쓰되 일의 대부분이 그것을 확실히 멈추게 하는 것이다.

이 주제의 어느 스레드든 들어가 보면 개발자들이 가장 먼저 꺼내는 걱정은 아키텍처가 아니라 토큰이다. 같은 레딧 스레드에서 가장 큰 목소리는 폭주하는 지출이다. 하룻밤에 조용히 수백 달러를 먹어 치운 루프의 영수증을 공유하며, 회사 경비 계정 없이 이걸 어떻게 감당하느냐고 묻는다.

루프에 관해 대부분의 개발자가 가장 먼저 알고 싶어 하는 것은 어떻게 짓느냐가 아니라 어떻게 계정을 비우지 않게 하느냐다. (출처: Firecrawl 블로그)

그 걱정은 옳고, 해법은 멋이 없다. 모든 루프는 단단한 가드와 함께 출하되거나 출하되지 않는다. Uber는 연간 AI 예산을 넉 달 만에 태운 뒤 Claude Code와 Cursor에 대해 1인당·도구당·월 1,500달러로 엔지니어를 제한했다. 비용이 코드를 쓰는 데서 코드를 쓰는 것을 돌리는 데로 옮겨 간 것이다. 올해의 실무 기록들은 같은 가드 셋으로 수렴한다.

• 막힌 루프가 계속 돌지 못하도록 하는 반복 횟수 하드 상한.
• 최근 몇 번의 패스가 아무것도 바꾸지 않으면 실행을 죽이는 diff 검사.
• 청구가 끝내기 전에 실행을 끝내는, 토큰이나 달러 단위의 지출 상한.

셋이 다 없으면 돌리는 건 루프가 아니라 열린 청구서다.

두 번째 위험은 더 조용하고 더 크다. 루프가 내가 쓰지 않은 코드를 빨리 출하할수록, 리포에 존재하는 것과 내가 실제로 이해하는 것 사이 간격이 벌어진다. Addy Osmani는 이를 이해 부채(comprehension debt)라 부른다. 루프가 잘 돌수록 누군가 지나가는 diff를 실제로 읽지 않는 한 부채는 더 빨리 쌓인다. 검증은 내 몫이다. “완료"는 증명이 아니라 주장이다.

세 번째 위험은 아무도 먼저 깃발을 들지 않는다. 취향(taste) 없는 루프다. Greg Brockman이 더 넓은 버전을 짚었다. 모델이 계속 유능해질수록 산출의 병목은 모델이 아니라 그것을 지휘하는 사람의 취향이 된다. 루프에도 거의 글자 그대로 적용된다. 루프는 루브릭·스킬·검증 단계에 넣은 판단을 무엇이든 증폭한다. 그 셋이 진짜 취향(내 코드베이스에서 “좋음"이 무엇인지, 어떤 엣지 케이스가 실제로 중요한지, 무엇이 기술적으로 통과한 것과 진짜 출하 준비된 것을 가르는지)을 반영할 때 루프는 옳은 방향으로 복리가 된다. 그렇지 않으면, 할 가치가 없던 일을 더 빠르게 출하하는 기계를 지은 셈이다. 루프는 기계 속도로 틀릴 수 있게 한다. 루프 엔지니어링은 이미 취향을 가진 사람에게 보상한다. 하네스는 베끼기 쉬운 부분이고, 그 안의 루브릭이야말로 진짜 내 것이다.

Firecrawl은 루프의 어디에 끼는가

모든 돌아가는 루프에 거듭 나타나는 패턴은 같다. 루프는 그 안의 피드백만큼만 좋다. 피드백 없이 코드를 쓰는 열린 루프는 자신만만한 오류를 생산하는 기계다.

웹에 닿는 루프(그리고 대부분의 프로덕션 루프는 결국 닿는다)에서 피드백 계층은 웹 데이터다. 카피를 쓰기 전 경쟁사를 조사해야 하고, 빠르게 바뀌는 API에 맞춰 코드를 짜기 전 문서 페이지를 끌어와야 하고, 재시도 전 상태 페이지를 확인해야 하고, 어느 항목에 손댈지 정하기 전 디렉토리에서 구조화된 데이터를 뽑아야 한다.

Firecrawl은 그 단계를 위해 만들어졌다. 세 엔드포인트가 루프가 필요로 하는 대부분을 덮는다.

• search — 제목·스니펫이 아니라 질의에 대한 전체 페이지 내용을 돌려준다.
• scrape — 자바스크립트로 렌더된 페이지를 포함해, 어떤 URL이든 에이전트가 추론할 수 있는 깨끗한 마크다운으로 변환한다.
• crawl — 사이트의 한 섹션 전체를 한 번에 끌어온다.

루프 안에서 부르는 방법은 둘이다. Firecrawl MCP 서버는 커넥터로 Codex·Claude Code에 끼우고, Firecrawl CLI는 셸 단계에서 같은 엔드포인트를 바로 친다. 어느 쪽이든 Firecrawl은 루프가 손 뻗을 수 있는 또 하나의 도구로 나타난다.

특별히 짚을 두 모양이 있다. 첫째는 야심 찬 목표 루프다. Claude Code나 Codex의 /goal에 진짜 어려운 일을 주고 돌린다. 예: “우리 범주의 모든 공개 경쟁사를 찾아 다섯 차원으로 점수 매기고 포지셔닝 브리프를 써라”, “우리가 의존하는 SDK의 최근 6개 마이너 릴리스의 모든 breaking change에 우리 문서를 대조 감사하라.” 에이전트는 루브릭이 충족될 때까지 검색·스크랩·읽기·수정을 이어 가고, Firecrawl은 그 실행을 모델 기억이 아니라 라이브 데이터에 묶어 두는 보급선이 된다.

둘째는 Firecrawl 자체를 트리거로 쓰는 것이다. monitor 엔드포인트는 URL 한 개나 묶음을 지켜보다 내용이 바뀌면 발화한다. 이걸 Claude Code 훅이나 Codex Automation에 엮으면 심장박동이 라이브 웹인 루프가 된다. 가격 페이지 변경이 경쟁 대응 루프를 켜고, API 체인지로그 갱신이 문서 재작성 파이프라인을 트리거하고, 상태 페이지 사고가 온콜 에이전트를 깨운다. 루프는 고정된 스케줄로 폴링하지 않고, 반응할 새로운 것이 실제로 있을 때 돈다.

가장 눈여겨본 지점

이 글이 1편(Osmani)과 갈라지는 대목은 “취향"을 비용 문제 바로 옆에 둔 배치다. 1편이 루프의 부품과 위험을 개념으로 펼쳤다면, 이 글은 Uber의 1,500달러 상한이라는 실제 영수증과 Greg Brockman의 “병목은 취향"을 한 문단 안에서 부딪친다. 루프가 잘 돌수록 두 가지가 동시에 빨라진다는 것이다. 옳은 방향이면 복리로 좋아지고, 취향이 없으면 “할 가치 없던 일을 기계 속도로 출하"한다. 같은 도구가 사람에 따라 정반대 결과를 낸다는 1편의 결론을, 이 글은 “하네스는 베끼기 쉽고 루브릭이 진짜 내 것"이라는 한 문장으로 더 날카롭게 깎아 둔다.

물론 이 글은 Firecrawl의 제품 글이고, 마지막 섹션은 명백히 자사 엔드포인트 영업이다. 그럼에도 “피드백 없는 열린 루프는 자신만만한 오류를 생산하는 기계"라는 진단은 영업 너머에서 유효하다. 루프의 품질이 그 안의 검증과 외부 컨텍스트의 신선도에 달렸다는 말은, 어떤 웹 데이터 도구를 쓰든 남는다.

출처

Hiba Fathima (Growth Marketing Lead, Firecrawl), 2026년 6월 11일 발행. 원문: https://www.firecrawl.dev/blog/loop-engineering