7장까지 우리는 하네스를 만들고, 팀에 옮기고, 다른 산출물로 넓혀 봤습니다. 그런데 그 하네스는 여전히 사람이 시작 버튼을 눌러야 돌아갑니다. 이 장은 그 버튼을 시스템에 넘기는 이야기입니다. 1장에서 이름만 소개했던 루프 엔지니어링을, 이번에는 설계와 실습까지 들어갑니다.

1. 하네스를 다 갖추고도 사람이 붙어 있는 이유

2장에서 만든 글쓰기 하네스를 떠올려 봅니다. CLAUDE.md에 톤이 적혀 있고, SKILL.md에 작업 순서가 적혀 있고, 사수 카드 두 장이 역할을 나눠 갖고 있습니다. 환경은 충분히 잘 갖춰져 있습니다.

그런데 한 절을 쓸 때마다 실제로 벌어지는 일은 이렇습니다.

사람: "이 주제로 한 절 써줘"
AI:   (초안을 만든다)
사람: (읽어본다) "분량이 좀 짧네, 늘려줘"
AI:   (다시 쓴다)
사람: (읽어본다) "Windows 안내가 빠졌어"
AI:   (다시 쓴다)
사람: (읽어본다) "좋다, 여기까지"

같은 장면이 랜딩 페이지 하네스에서도 반복됩니다. 브리프를 던지고, 열어보고, 어색한 자리를 지적하고, 다시 뽑고. 환경은 자동인데 순환은 수동입니다. 사람이 매 바퀴마다 "다시", "이번엔 이렇게", "여기까지"를 말해줘야 다음 바퀴가 돕니다.

이게 왜 문제인지는 숫자로 보면 분명합니다. 한 절에 세 바퀴가 돌고 한 바퀴에 사람이 3분씩 붙는다면, 절 하나에 사람 시간 9분입니다. 절이 40개인 책이면 6시간이고, 페이지가 매주 나오는 팀이면 매주 반복되는 고정비입니다. 그리고 이 시간의 대부분은 판단이 아니라 확인과 재요청입니다. "분량이 짧다"는 사람이 아니라 wc -l도 알 수 있는 사실입니다.

붉게 칠한 두 칸이 사람 자리입니다. 루프 엔지니어링은 이 중 위쪽 칸을 시스템에 넘기고, 아래쪽 칸을 사람에게 남기는 일입니다.

2. 용어의 뜻을 다시 한 번

1장에서 봤듯이, 이 용어는 2026년 6월에 자리 잡았습니다. Peter Steinberger가 "You shouldn't be prompting coding agents anymore"(이제 코딩 에이전트를 직접 프롬프트하고 있으면 안 된다)라고 문제를 제기했고, 다음 날 Google의 Addy Osmani가 Loop Engineering이라는 글로 이름을 붙였습니다.

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

"루프 엔지니어링은 에이전트를 프롬프트하는 사람 자리에서 나를 빼는 것이다. 대신 그 일을 해주는 시스템을 설계한다."

여기서 오해하기 쉬운 지점이 하나 있습니다. "나를 뺀다"는 말이 "손을 떼고 결과를 안 본다"는 뜻이 아닙니다. 빠지는 자리는 매 바퀴마다 다음 바퀴를 시작시키는 자리이고, 남는 자리는 목표를 정하고 최종 결과를 판정하는 자리입니다.

Osmani가 안쪽 루프(inner loop)와 바깥 루프(outer loop)로 나눈 그림입니다. 안쪽은 조사하고, 만들고, 검증하고, 다시 조사하는 순환입니다. 여기는 에이전트가 스스로 돌아도 됩니다. 바깥은 "무엇을 만들 것인가", "어디까지가 완료인가", "이걸 내보내도 되는가"입니다. 여기는 사람이 잡고 있어야 합니다.

3. 자동화와 무엇이 다른가

"정해진 시간에 자동으로 돈다"는 말만 들으면 예전부터 있던 자동화, 즉 cron이나 CI와 같아 보입니다. 실제로 겹치는 부분이 많고, 루프의 부품 중 절반은 오래된 자동화 기술 그대로입니다. 다만 결정적인 차이가 한 칸에 있습니다.

핵심은 두 번째 줄과 마지막 줄입니다. cron은 매 바퀴 같은 일을 하고, 루프는 매 바퀴 다른 일을 합니다. 테스트가 깨졌으면 고치는 일을 하고, 다 통과했으면 다음 항목으로 넘어가고, 세 번째 실패에서 같은 에러가 반복되면 멈추고 사람을 부릅니다. 이 판단이 매 바퀴 새로 일어난다는 점이 자동화와 다른 자리입니다.

그리고 고치는 자리도 다릅니다. cron이 잘못 돌면 스크립트를 고치지만, 루프가 잘못 돌면 대개 멈춤 조건이 모호했거나, 검증이 허술했거나, 하네스에 정보가 빠져 있던 것입니다. 1장에서 본 Mitchell Hashimoto의 문장이 여기서도 그대로 적용됩니다. 실수를 손으로 고치지 말고, 그 실수가 구조적으로 일어날 수 없게 환경을 손봅니다.

4. 잘 설계된 루프의 다섯 부품

루프를 돌려보면 거의 항상 같은 다섯 가지에서 사고가 납니다. 그래서 이 다섯 개를 루프의 기본 부품으로 봐도 됩니다. 5장에서 하네스를 다섯 부품(도구·워크플로우·가드레일·오케스트레이션·평가)으로 나눠 본 것과 같은 방식입니다.

4.1 검증 가능한 멈춤 조건

루프에서 가장 중요한 한 줄입니다. 기계가 판정할 수 있어야 합니다.

나쁜 멈춤 조건: "글이 좋아질 때까지"
좋은 멈춤 조건: "테스트가 모두 통과하고 lint가 깨끗할 때까지"

"좋아질 때까지"는 판정하는 쪽도 모델이라 매 바퀴 기준이 흔들립니다. 반면 "npm test가 0으로 끝날 때까지"는 흔들릴 자리가 없습니다. 글쓰기처럼 본래 주관적인 작업이라도, 판정할 수 있는 대리 지표로 바꿔 쓸 수 있습니다. "본문이 180줄 이상이고, 코드 블록이 2개 이상이고, 금지 표현이 0개일 때까지" 같은 식입니다.

4.2 예산과 횟수 상한

루프에는 무한히 돌 수 있는 능력이 있습니다. 그래서 반드시 천장을 씌워야 합니다. 최소한 세 가지 중 하나는 걸어둡니다.

• 최대 반복 횟수 (예: 10바퀴)
• 최대 시간 (예: 30분)
• 최대 비용 (예: 5달러)

1장에서 본 OpenAI 팀의 하루 토큰 비용이 2,000~3,000달러였다는 숫자를 떠올리면, 상한이 없는 루프가 하룻밤 사이에 얼마를 쓸 수 있는지 짐작할 수 있습니다.

4.3 진전 없음 감지

가장 자주 놓치는 부품입니다. 루프가 같은 에러를 세 번 연속 만나면, 네 번째 시도도 같은 결과가 나옵니다. 답이 안 나오는데도 계속 도는 상태가 루프에서 가장 비싸고 가장 흔한 실패입니다.

그래서 "몇 바퀴 연속으로 상태가 그대로면 멈추고 사람을 부른다"는 탈출구가 필요합니다. 사람에게 넘길 때는 "무엇을 시도했고 무엇이 막혔는지"를 같이 남겨야 넘겨받은 사람이 바로 이어받을 수 있습니다.

4.4 만드는 쪽과 검사하는 쪽의 분리

5장의 Evaluator-Optimizer 패턴이 루프에서는 필수 부품이 됩니다. 자기가 만든 것을 자기가 검사하면 사각지대가 그대로 남습니다. 2장에서 목차 짜는 사수와 본문 쓰는 사수를 나눴던 이유와 같습니다.

검증하는 쪽은 가능한 한 기계 검사를 먼저 쓰는 게 좋습니다. 7장에서 만든 grep 기반 검사처럼 결정론적으로 판정되는 항목은 모델에게 물어볼 필요가 없습니다. 모델 판정은 기계가 못 보는 자리(톤, 설득력, 읽기 흐름)에만 씁니다.

4.5 바퀴 사이를 잇는 상태

한 바퀴가 끝나고 다음 바퀴가 시작될 때, 지난 바퀴에서 알아낸 것이 사라지면 루프는 같은 실수를 반복합니다. 3장에서 본 "긴 대화는 산만해진다" 문제와, 4장의 컨텍스트 관리가 여기서 다시 나옵니다.

그렇다고 대화 전체를 계속 이어 붙이면 컨텍스트가 부풀어 품질이 떨어집니다. 실무에서 잘 통하는 절충은 바퀴 사이의 기억을 파일로 남기는 것입니다.

progress.md      ← 지금까지 무엇을 끝냈는가
blockers.md      ← 무엇이 막혔고 무엇을 시도해봤는가
decisions.md     ← 왜 이렇게 하기로 했는가

이렇게 두면 컨텍스트를 새로 시작해도 이 세 파일만 읽으면 이어받을 수 있습니다. 4장에서 본 Just-in-Time 컨텍스트를 루프에 적용한 모양입니다.

5. 하네스와의 관계

정리하면 이렇습니다. 하네스는 에이전트가 일할 자리를 만들고, 루프는 그 자리에서 언제 일이 시작되고 언제 끝나는지를 정합니다. 둘은 대체가 아니라 겹입니다.

첫 줄이 특히 중요합니다. 하네스가 부실한 상태에서 루프를 켜는 것이 가장 위험합니다. 사람이 매 바퀴 보고 있으면 두 번째 바퀴에서 잡혔을 실수가, 루프에서는 열 번째 바퀴까지 쌓입니다. 그래서 이 책이 하네스를 6장과 7장에 걸쳐 다룬 뒤에야 루프로 넘어온 것입니다.

이어서 Claude Code가 이 다섯 부품을 어떤 기능으로 제공하는지 하나씩 짚어봅니다. 그다음 8-3에서 직접 돌려보고, 8-4에서 안전하게 운영하는 방법을 봅니다.