루프 엔지니어링

갱신 2026-08-09

한눈에 요약

• 사람이 "이것도 고쳐 줘"라고 반복해서 시키는 그 일까지 AI에게 넘긴다. 결과물이 기준에 닿을 때까지 스스로 돌게 만드는 기술이다.
• 앞 단계 기법들이 AI가 무엇을 보고 무엇을 지킬지를 정했다면, 여기서는 몇 번 더 돌릴지 판단하는 몫까지 자동화한다.
• 없애려는 건 첫 프롬프트가 아니다. 결과가 아쉬워서 넣는 두 번째, 세 번째 개선 프롬프트다.
• 사람이 안 끼어드는 만큼 어디서 멈출지, 무엇으로 합격을 판정할지 미리 정해 두는 일이 중요해진다.
• 작은 프로젝트에는 과하다. 한 번에 끝낼 일을 루프로 돌리면 시간과 토큰만 쓴다.

무엇을 자동화하나

루프 엔지니어링은 사람의 반복 프롬프트조차 AI에게 대체시켜, 하나의 기능을 사람 개입 없이 끝까지 완성도를 끌어올리는 기술이다 25. 진화 서사 프롬프트 → 컨텍스트 → 하네스 → 루프에서 네 번째 축으로 소개된다. 2026년에는 그 뒤에 그래프 엔지니어링이라는 다섯 번째 이름이 하나 더 붙었다 30.

정의가 하나가 아니다

같은 말을 두 자료가 조금 다르게 잡는다. 어느 쪽이 틀린 게 아니라 보는 층위가 다르다.

세 번째 관점도 있다. 루프는 AI가 어떻게 반복해서 행동하는지를 설계하는 단계이고, 그 위의 그래프 엔지니어링은 여러 AI가 어떤 구조 안에서 함께 움직이는지를 설계한다는 정리다. 이 관점에서 그래프는 루프를 밀어내지 않는다. 노드 하나하나 안에 루프를 넣거나, 몇 개의 노드와 엣지를 묶어 독립적인 루프로 굴릴 수 있다 31.

두 번째 정의에서는 휴먼 인 더 루프를 빼고 말한다. 한 바퀴 돌 때마다 사람이 개입하는 것은 여기서 말하는 루프에 넣지 않는다. 대표 사례로 꼽히는 Goal이 사람의 개입 없이 돌기 때문이다 30.

정확한 하네스와 지침과 계약으로 만들어진 "일인분 에이전트"들을 모아, 그 시스템이 자율적으로 굴러가게 하는 데까지 가는 것 — 이것이 두 번째 정의가 말하는 루프 엔지니어링이다. 만드는 사람이 아니라 쓰는 사람 입장의 엔지니어링이라는 단서가 붙는다 30.

루프 4종 — 검증, 이벤트, 힐 클라이밍

LangChain이 정리한 구성은 이렇다. 먼저 에이전트를 만들고, 그 위에 세 종류의 루프를 얹는다 30.

쉽게 말하면 이벤트 드리븐은 이벤트 리스너에 가깝고, 힐 클라이밍은 개선을 자동화하는 층이다. 매일 뉴스를 모아 오는 에이전트를 예로 들면, 트윗 하나가 이벤트가 되고, 결과물을 그레이더가 평가하고, 별로면 그 피드백이 스킬 수정으로 돌아간다 30.

다만 이벤트 드리븐은 결이 조금 다르다. 만드는 단계가 아니라 만들어 놓고 운영하는 단계의 이야기라, 일반적인 코딩 작업보다 서비스 쪽 문제에 가깝다 30.

핵심: 대립이 아니라 중첩

라프(Ralph) 루프 → 하네스 엔지니어링 → 루프 엔지니어링은 서로 대립하는 게 아니라 중첩되는 흐름이다 25.

• 라프 루프 (가장 먼저, 작년경) — 롱러닝 에이전트 개념이 없던 시절의 단순·무식한 기법이다. PRD나 체크포인트를 만들고 매 작업 후 사람이 끼어들어야 했다. 그 중간 개입을 없애려 "알아서 계속 반복해라"는 식으로 만들어졌다. 컨텍스트가 차면 성능이 떨어지는 "니들 인 헤이스택" 문제 때문에, 작업을 잘게 쪼개 결과만 디스크에 저장하고 새 컨텍스트의 새 에이전트로 다음 작업을 이어갔다. 완성도가 아니라 0→10 진행(progress)에 초점이 있었다 25.
• 하네스 엔지니어링 (그다음) — 정해진 스코프 안에서 무엇을 하고 하면 안 되는지를 정의하는 제약 방식이다 25.
• 루프 엔지니어링 (가장 최근) — 프롬프팅하는 나 자신을 줄이는 것이다.

무엇을 줄이는가: n번째 프롬프트

여기서 헷갈리기 쉽다. "프롬프트하지 마라"는 첫 번째 프롬프트를 없애라는 게 아니다. 첫 프롬프트는 반드시 있어야 한다.

줄이라는 건 그다음이다. A라는 기능을 만들었는데 결과가 아쉬워서 개선 프롬프트를 다시 넣는다. 그 두 번째, 세 번째, n번째 프롬프트를 자동화하라는 뜻이다 25.

동작 패턴은 "행동(Act) → 관찰(Observe) → 결정(Decide) → 반복(Repeat)"이다. 루프가 돌 때마다 기능의 완성도가 계속 올라간다. 무에서 유를 창조하는 게 아니라 정해진 하나의 목표의 완성도를 높여 가는 방식이다 25.

데모로는 고양이 이미지를 순수 HTML 캔버스와 자바스크립트로 모사하는 루프가 제시된다. 매 회차 직전 최고 결과에 비평을 반영해 수정하고, 헤드리스 렌더링으로 관찰하고, 원본과 유사도 점수(0~100)를 재고, 비평을 JSON에 기록한 뒤 반복한다. 유사도 90%를 통과 기준으로 두고 23회차까지 돌리니 입체감과 완성도가 크게 올라갔다 25.

모두에게 맞는 건 아니다 (스코프 경고)

말이 퍼진 계기는 거의 같은 날 겹친 두 가지였다. "이제 코딩 에이전트에 프롬프팅을 하면 안 된다, 루프를 만들어야 한다"는 글이 크게 화제가 됐고, 보리스 체르니도 "이제 우리는 클로드 코드에 프롬프팅을 하지 않는다"고 말했다. 이 둘이 루프 엔지니어링이라는 말의 시작이 됐다 30.

보리스 체르니가 "My job is loops"라 했다고 언급된다. 다만 직함과 발언 주체가 자막상 불명확하다. 자막은 "Vercel CEO"·"보리스 체니" 등으로 혼동해 표기한다.

그는 Claude Code처럼 어마어마하게 큰 프로젝트를 다룬다. 큰 프로젝트에서는 새 피처가 기존 기능과 잘 융화되고 다른 걸 깨지 않는지 판단하는 일이 매우 중요하고 반복적이다. 루프 엔지니어링이 빛나는 자리다 25.

반대로 사이드 프로젝트, MVP, PMF 탐색 단계의 작은 프로젝트는 다르다. 프론티어 모델 성능이 워낙 좋아 한 번에 ultra code나 max로 끝낼 수 있다. 이걸 굳이 루프로 반복하면 루프 짜는 시간, 도는 시간, 토큰만 낭비된다.

SVG처럼 한 번에 그릴 수 있는 걸 루프로 돌리는 건 말이 안 된다. 작업 규모와 본인 이해도에 맞는 기법을 써야 한다(right tool for the right job) 25.

다시 하네스로 회귀

피터 스타인버거(자막상 표기, 피터 슈타인버거 / 오픈클로 창업자로 언급)도 결국 "루프를 디자인하는" 단계로 간다고 한다. 나아가 여러 에이전트의 함대(fleet)를 다루는 단계다.

그런데 루프를 디자인하려면 무엇을 하고 하면 안 되는지의 룰을 정확히 정의해야 한다. 그게 곧 다시 하네스 엔지니어링으로 돌아오는 것이다 25.

영상의 조언은 이렇다. "새 개념들은 사실 앱스트랙션이 높아진 것일 뿐 완전히 새로 생긴 건 많지 않다." 트렌드에 휩쓸리지 말고 자기 작업 규모에 맞춰 기법을 도입하라는 것이다 25.

함께 읽기

• 하네스 엔지니어링 — 루프 설계가 회귀하는 종착점
• 그래프 엔지니어링 — 루프가 넓힌 자율성을 되감으려는 반대 방향
• 에이전트 계약 — 사람이 안 보는 동안 지켜져야 할 규칙
• 다이나믹 워크플로우 — ultra code로 동적 하네스를 생성하는 기능
• 컨텍스트 부패 — 라프 루프가 작업을 잘게 쪼갠 이유