루프 엔지니어링 — 프롬프트를 반복하는 대신 루프를 설계한다

루프 엔지니어링은 새 기술이 아니다. 내가 매번 AI에게 다시 치던 “이번엔 이렇게 고쳐줘”를 시스템 안으로 옮긴 것이다. RAG Loop, 하네스, 루프 엔지니어링 — 세 단어는 경쟁이 아니라 한 줄로 이어진 발전이다.

이 글은 코드팩토리 유튜브 요즘 유행하는 루프 엔지니어링(2026.6.22)을 lilys.ai로 정리한 노트에서 출발했다. 다만 용어의 출처부터 짚고 가는 게 솔직하다. “루프 엔지니어링”이라는 말을 알린 건 Addy Osmani(오랜 기간 Google Chrome 엔지니어링 리드)다. 그의 정의는 간결하다 — “replacing yourself as the person who prompts the agent. You design the system that does it instead.” 에이전트에게 프롬프트를 치는 ‘나’를 대체하고, 그 대신 그 일을 하는 시스템을 설계한다는 뜻이다. Addy가 이 말을 꺼내고 Boris Cherney·Peter Steinberger가 확장하면서 업계로 번졌으며, 코드팩토리 영상은 그 흐름을 RAG Loop·하네스·루프 세 단어의 발전 관계로 풀어낸다. lilys.ai는 요약 도구로 썼고 원본은 그 영상이다. 요약을 그대로 옮기지 않고, Addy의 원래 정의와 내가 실제로 돌리고 있던 루프에 대입해 다시 썼다.

세 단어는 경쟁이 아니다

영상이 놓인 출발점이 좋았다. 세 단어를 “어느 것이 이기나”로 보지 않고, 겹치고 발전하는 관계로 본다.

하네스까지는 프롬프트에서 하네스까지 — Ouroboros, Ralph Loop에서 다뤘다. 이 글은 그 다음이다. 하네스가 정적 제약이라면, 루프 엔지니어링은 동적 반복으로 통제를 옮긴다.

RAG Loop — 왜 결과를 디스크에 저장하는가

RAG Loop가 풀고자 한 건 컨텍스트 디그라데이션(Context Degradation)이다. 에이전트를 한 번에 오래 돌리면, 대화가 길어지면서 앞부분의 맥락이 흐려진다. 처음에 준 규칙도, 중간 결과도, 결국 흐릿해진다.

RAG Loop의 답은 단순했다. 오래 돌리지 말고, 결과를 디스크에 저장한 뒤 컨텍스트를 비우고 새 에이전트에서 이어서 한다. 진행 상황(progress)은 파일로 남기고, 에이전트는 가벼운 상태로 다음 단계만 본다.

이건 내가 지식베이스에서 하던 일과 같았다. 원문과 요약과 “이제 써도 되는 지식”을 한 층에 두지 않고, inbox → sources → context로 나누고, 상태는 Git으로 보존한다. 컨텍스트가 무너지기 전에 디스크(파일)로 옮겨 놓는 것. RAG Loop라는 이름을 몰랐을 뿐, 같은 문제를 같은 방향으로 풀고 있었다.

하네스에서 루프로 — 왜 정적 제약을 줄이는가

하네스 엔지니어링은 “0에서 100까지 가는 동안 무엇을 하고 하지 말아야 하는가”를 정의한다. AGENTS.md, CLAUDE.md, 빌드를 실패하게 만드는 게이트 — 전부 미리 정해두는 정적 제약이다.

그런데 영상은 흥미로운 지점을 짚는다. 최근엔 Ultra Code 같은 도구가 하네스를 동적으로 생성한다. 그러니 정적 하네스를 빽빽하게 설계하는 대신, “환경을 제공”하는 데 집중하는 추세라고.

이유를 생각하면 자연스럽다. 정적 하네스는 미리 알 수 있는 규칙에만 강하다. “3-티어 계층을 우회하지 마라”는 정해둘 수 있지만, “이 고양이 그림을 목표와 90% 비슷하게 만들어라”는 매 단계마다 평가가 달라진다. 정적으로 다 정의할 수 없는 완성도 문제는, 제약(하네스)이 아니라 반복(루프)으로 푼다.

즉 하네스와 루프는 대립이 아니라 분업이다. 정해진 길을 이탈하지 않게 하는 것은 하네스가, 한 걸음씩 완성도를 끌어올리는 것은 루프가 맡는다.

루프 엔지니어링의 작동 — 한 목표, 반복 평가

루프 엔지니어링의 작동 원리는 영상의 고양이 예시가 잘 보여준다.

목표는 하나다. 어떤 고양이 이미지를 순수 HTML 캔버스와 자바스크립트로 “최대한 비슷하게” 그리기. 유사도 90%가 목표다.

루프는 이렇게 돈다.

생성 → (목표 이미지와 비교·점수 매김) → (점수를 올리기 위한 비평 생성) → 수정 → 반복

AI가 스스로 결과물을 관찰(observe)하고, 점수를 매겨(decide) 무엇이 부족한지 비평하고, 그 비평을 다음 생성(action)에 반영한다. 사람은 끼어들지 않는다. 23번째 반복에서는 첫 결과물과 비교해 눈·얼굴·고개 각도가 확연히 좋아졌다.

여기서 영상이 짚는 핵심이 있다. 루프 엔지니어링은 무에서 유를 창조하는 게 아니다. 주어진 목표를 반복 개선으로 달성하는 일이다. 그래서 고양이를 그리기로 했으면, 갑자기 강아지나 기린을 기대하면 안 된다. 그건 루프의 범위를 벗어난다.

그리고 결정적인 한 줄. 만약 원본이 이미 SVG로 그려진 고양이였다면, 루프 없이 한 번에 복제할 수 있었을 것이다. 그런데 루프를 돌리면 비효율이다.

이 한 줄이 이 영상에서 가장 중요하다고 본다.

영상이 공개한 실제 메타프롬프트

고양이 예시가 끝에서 그치지 않는다. 영상은 그 예시를 돌리는 실제 메타프롬프트를 화면에 공개한다. lilys.ai 요약에는 빠져 있던 부분인데, 루프 엔지니어링의 실체가 이 코드블록에 있다.

[종료 조건]
- THRESHOLD = 90   (유사도 0~100, 이 점수 이상이면 통과)
- MAX_ITER = 12    (완전 상한일 뿐, 주된 종료 조건은 아니다)
- 디스크가 너의 유일한 기억이다. 매 단계 상태를 파일로 남겨,
  언제 중단돼도 이어갈 수 있게 하라.

[산출물 — 파일 구조]
- assets/target.png          : 입력 (사용자가 제공한 목표 이미지)
- iterations/NN/art.html     : 그 회차 캔버스 코드 (외부 네트워크 금지, 난수 시드 고정)
- iterations/NN/shot.png     : art.html을 렌더한 스크린샷
- iterations/NN/review.json  : { "iter":N, "score":0-100, "critique":"...", "passed":bool }
- state.json                 : { "best_iter", "best_score", "last_critique", "done":false, "history":[...] }
- index.html (+css/js)       : 진행을 보여주는 뷰어

[반복 절차 — act → observe → decide]
각 반복 N에서:
1. 복원 — state.json과 가장 최근 review.json을 읽어 현재 점수·직전 비평을 파악한다 (기억은 오직 디스크).
2. 행동(act) — 1회차는 처음부터, 이후엔 직전 art.html에 비평을 반영해 수정 → iterations/NN/art.html 저장.
3. 관찰(observe) — art.html을 헤드리스로 렌더해 shot.png로 저장한다.
   (Playwright MCP가 있으면 사용. 없으면 설치 후 캔버스가 다 그려질 때까지 기다렸다 스크린샷.)
4. 검증(verify) — 검증자로서 target.png와 shot.png를 직접 보고 0~100 유사도 점수와
   "무엇을 바꿨으며 점수가 오를지" 구체적 비평(1~3줄)을 review.json에 적는다.
   점수가 직전 회차보다 낮으면 이번 결과는 버리고 직전 코드를 기준으로 다음 반복. state.json 갱신.
5. 갱신 — 뷰어(index.html)를 이번 회차까지 반영한다.

[종료 게이트]
- best_score ≥ THRESHOLD → 최종 리뷰어로 target.png·shot.png를 한 번 더 비교해 진짜 통과인지 확인.
  통과면 state.json의 done을 true로 쓰고, <promise>DONE</promise>과 최종 요약(총 반복 수·최종 점수·점수 추이) 출력.
- best_score < THRESHOLD 인 채 MAX_ITER 도달 → 멈추고 현재 코드와 함께 "왜 임계치에 못 미쳤는지" 보고.

이 프롬프트가 매력적인 이유는, “루프를 돌려라”라는 추상 조언에서 끝나지 않고 재현 가능한 명세로 내려온 데 있다. 세 가지가 눈에 띈다.

첫째, 종료 조건을 숫자로 고정한다. THRESHOLD = 90, MAX_ITER = 12. “충분히 좋아질 때까지”가 아니라 90점, 최대 12회다. 루프가 끝나지 않는 병리(무한 루프)를 막는 안전장치다.

둘째, “디스크가 너의 유일한 기억이다”. 앞서 RAG Loop에서 말한 컨텍스트 디그라데이션 해법이 한 줄로 들어있다. 매 회차의 점수·비평·최고 결과를 state.json에 남기고, 다음 회차는 그 파일부터 읽어 복원한다. 컨텍스트 창이 무너져도, 머신이 재시작돼도, 디스크만 있으면 이어서 한다. 이게 RAG Loop를 루프 엔지니어링 안에서 회수하는 지점이다.

셋째, 자기 검증(verify)에 롤백을 붙였다. AI가 직접 두 이미지를 비교해 점수를 매기되, 점수가 직전보다 낮으면 이번 결과를 버리고 직전 코드로 돌아간다. 자기 평가의 환각 위험을 ‘이전보다 나아졌는가’라는 단순 비교와 롤백으로 방어하는 구조다.

정리하면 이 메타프롬프트는 하네스와 루프의 결합이다. 파일 구조·종료 조건·상태 보존은 정적 제약(하네스)이고, 그 안에서 도는 act-observe-verify는 동적 반복(루프)이다. 영상이 “정적 하네스를 줄이고 통제를 루프 안으로”라고 한 말의 실제 모습이 이 코드블록이다.

내가 이미 돌리던 루프들

영상을 보다가 멈칫했다. 내가 블로그를 발행하며 돌리는 파이프라인이, 사실상 루프 엔지니어링이었다.

3개 AI Family가 내 블로그를 검수한다에서 만든 구조를 떠올려 보자.

초안 → (6개 Critic이 각기 다른 항목으로 평가) → (Synthesis가 충돌 중재) → Veto 통과? → 아니면 재수정 → 반복(최대 2라운드)

내가 매번 AI에게 “이번엔 가독성을 봐줘”, “이번엔 코드가 맞는지 봐줘”, “반론을 찾아줘”라고 따로 따로 치던 프롬프트를, 각기 다른 평가 범위를 가진 Critic 6개로 쪼개고, 충돌은 중재자가 풀게 했다. 사람이 라인 단위로 고치던 검수를, 에이전트들이 구조화된 항목으로 반복 평가하게 옮긴 것이다. 2라운드까지 가면 평균이 7.6에서 8.4로 올라간다. 고양이 캔버스의 유사도가 반복마다 올라가는 것과 같은 구조다.

커버 이미지도 마찬가지였다. 첫 프롬프트로 낸 이미지가 시리즈 톤과 어긋났을 때, 원인(추상 묘사 vs 구체 기술 요소)을 진단하고 프롬프트를 고쳐 다시 생성하는 과정을 여러 번 돌렸다. 결국 그 과정을 ‘커버 프롬프트 가이드’라는 파일로 남겼다. 매번 다시 치던 프롬프트를 시스템으로 옮긴 것이다.

영상이 “루프 엔지니어링은 새 기술이 아니라 추상화 수준이 올라간 과정”이라고 한 말이, 이 대목에서 와닿는다.

루프가 비효율이 되는 순간

영상이 “신격화하지 말라”고 반복해서 강조한 대목을 옮기고 싶다.

루프 엔지니어링은 복잡한 대규모 프로젝트나 완성된 프로젝트에 새 기능을 추가하는 작업에서 효율적이다. 기존 기능과의 융합, 다른 기능 손상 여부를 반복 평가로 따져야 할 때 빛을 발한다.

반대로 이런 경우엔 비효율이다.

• 사이드 프로젝트, MVP, PMF를 찾는 작은 프로젝트 — 한 번에 끝낼 수 있는 일을 루프로 돌리면 시간·토큰·비용만 낭비한다
• 이미 정답이 정해진 복제 작업 — SVG 고양이를 그대로 옮기는 일이라면, 루프 없이 한 번에 하는 게 맞다
• 스코프가 다른 문제 — 자기 프로젝트 규모에 맞는 기법을 골라야 최대 효율이 나온다

영상이 콘텐츠 제작자들을 향해 던진 말도 있다. 조회수를 위해 트렌드를 과장해서 전달하는 경향이 있는데, 그 과장에 휩쓸리지 말고 내 페인포인트를 해결할 수 있는 기법을 찾아 적용하라는 것.

내 경우에도 멀티 모델 리뷰 파이프라인은 “적합하지 않은 경우”를 따로 적어뒀다. 발행 빠른 팀 블로그, 짧은 뉴스 요약, 프롬프트 유지보수 여력이 없는 경우엔 6개 Critic이 과도하다. 루프가 만능이 아니라는 점은, 루프를 쓰는 쪽이 가장 솔직하게 인정해야 한다.

미래 — 하네스 + 루프, 그리고 Fleet

영상은 루프 엔지니어링을 끝이 아니라 본다. 모델 완성도가 높아지면, 하네스와 루프를 조합하는 방향으로 간다.

Peter Steinberger는 미래엔 Fleet, 즉 여러 에이전트의 함대를 디자인하는 하네스 엔지니어링이 중요해질 거라고 했다. 이유가 분명하다. 루프가 특정 기능의 완성도에 집중한다면, 창조적인 영역으로 나아가려면 롱러닝 태스크의 실행 규칙을 정의하는 하네스가 필수다.

결국 AI 사용은 추상화 수준이 올라가는 과정이라는 게 영상의 결론이다. 프롬프트 → 컨텍스트 → 하네스 → 루프로, “내가 직접 하는 일”이 한 단계씩 “시스템이 대신하는 일”로 올라가는 흐름. 완전히 새로운 개념이 아니라, 기존 개념의 발전이라는 이야기다.

지금의 판단

루프 엔지니어링이라는 말이 2026년 중반 트렌드로 떠올랐지만, 속을 들여다보면 “사람이 매번 끼어들던 개입을 자동화한다”는 낯익은 생각이다. 새 기법을 신격화하기보다, 내가 실제로 반복하던 작업 중 루프로 옮길 수 있는 게 무엇인지 먼저 보는 게 맞다.

정리하면 이렇다.

• RAG Loop·하네스·루프 엔지니어링은 발전 관계다. 각각 다른 문제(컨텍스트 붕괴, 이탈 제어, 완성도 반복)를 풀고, 조합해서 쓴다
• 루프는 한 목표를 반복 평가로 달성한다. 고양이 캔버스 예시처럼, 무에서 유가 아니라 주어진 목표를 점점 가깝게 만드는 일이다
• 정답이 정해진 작업엔 루프가 비용이다. SVG 고양이는 한 번에 옮기는 게 맞다. 프로젝트 규모에 맞춰 기법을 골라야 한다
• 하네스 + 루프 + Fleet으로 간다. 정적 제약과 동적 반복을 분업하고, 결국 에이전트 함대를 설계하는 쪽으로

이 영상이 트렌드 용어라 빨리 낡을 수 있다는 점은 솔히 인정한다. 다만 “매번 다시 치던 프롬프트를 루프로 옮긴다”는 핵심은, 용어가 바뀌어도 남을 생각이다.

뱀은 같은 것을 반복하지 않는다 — 진화한다. 이 말을 빌려 오면, 루프는 반복이 아니라 매번 결과가 다음 입력으로 들어가는 진화다.