앞에서 프롬프트, 컨텍스트, 하네스라는 세 시대를 따라왔습니다. 그런데 이 책을 쓰는 사이에도 업계는 움직여서, 2026년 6월에 루프 엔지니어링(Loop Engineering) 이라는 네 번째 용어가 등장했습니다. 이번에는 이 용어가 무엇을 말하는지, 앞의 세 가지와 어떤 관계인지 짧게 소개합니다. 지금은 "이런 흐름이 오고 있다"를 알아두는 정도면 충분하고, 본격적인 설계와 실습은 이 책의 마지막 8장에서 다룹니다.

1. 용어의 등장, 2026년 6월의 한 주

2026년 6월 7일, 오픈소스 개발자 Peter Steinberger가 짧은 글 하나를 올렸습니다.

"You shouldn't be prompting coding agents anymore."

"이제 코딩 에이전트를 직접 프롬프트하고 있으면 안 된다."

이 한 문장이 약 650만 조회수를 기록하며 화제가 됐고, 바로 다음 날 Google의 Addy Osmani가 Loop Engineering이라는 글에서 개념을 정리해 이름을 붙였습니다. 이 글은 이후 O'Reilly Radar에도 다시 실리면서 빠르게 공통 어휘가 됐습니다. 컨텍스트 엔지니어링이 2025년 6월의 한 주 사이에 자리 잡았던 것처럼, 루프 엔지니어링도 정확히 1년 뒤 비슷한 방식으로 태어났습니다.

Osmani의 정의는 한 문장입니다.

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

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

2. 루프 엔지니어링이란

지금까지는 사람이 부탁하고, AI가 답하고, 사람이 결과를 보고 다시 부탁하는 식이었습니다. 루프 엔지니어링은 이 반복 자체를 시스템에 맡깁니다. 목표와 멈춤 조건을 정해두면, 에이전트가 실행하고 → 결과를 관찰하고 → 다음 행동을 결정하고 → 다시 실행하는 순환을 스스로 돕니다. 사람은 매 바퀴마다 지시를 내리는 대신, 루프가 잘 돌게 설계하고 최종 결과를 검증하는 자리로 이동합니다.

일상 비유로 이어 보면 이렇습니다. 프롬프트가 잘 쓰인 이메일 한 통, 컨텍스트가 이메일에 챙겨 넣는 첨부파일, 하네스가 사무실 전체 설계라면, 루프는 그 사무실이 퇴근 후에도 스스로 돌아가게 만드는 근무 체계입니다.

기존 자동화와 다른 점도 여기에 있습니다. 자동화는 "매일 9시에 리포트 발송"처럼 정해진 조건에서 정해진 행동만 하고, 예상 밖 상황에서는 멈추거나 틀린 결과를 냅니다. 루프는 매 바퀴마다 에이전트가 상황을 보고 판단하기 때문에, 규칙에 없던 상황도 어느 정도 스스로 헤쳐 나갑니다.

잘 설계된 루프에는 공통적으로 이런 장치가 들어갑니다.

• 검증 가능한 멈춤 조건: "테스트가 전부 통과하면 종료"처럼 기계가 판정할 수 있는 조건
• 최대 반복 횟수와 예산 한도: 무한 루프를 막는 안전장치
• 진전 없음 감지: 같은 실수를 계속 반복하면 멈추고 사람을 부르는 탈출구
• 역할이 분리된 서브 에이전트: 만드는 에이전트와 검사하는 에이전트를 따로 두어, 자기가 짠 코드를 자기가 검사할 때 생기는 사각지대를 줄임

3. 하네스와의 관계, 대체가 아니라 한 겹 더

루프 엔지니어링은 하네스 엔지니어링을 대체하는 개념이 아닙니다. 앞에서 본 것처럼 세 시대가 포함 관계였듯, 루프도 그 위에 한 겹 더 얹힙니다. 하네스가 에이전트가 일할 환경(책상, 공구함, 안전 장비) 을 만드는 일이라면, 루프는 그 환경 안에서 에이전트가 언제 일을 시작하고, 언제 다시 돌고, 언제 멈추는지 그 순환을 설계하는 일입니다. 좋은 하네스 없이 루프만 돌리면 실수가 반복 증폭되고, 좋은 하네스가 있어도 사람이 매번 버튼을 눌러야 하면 자율성이 제자리입니다.

실제 도구에도 이미 들어와 있습니다. 이 책에서 사용하는 Claude Code에는 조건이 충족될 때까지 스스로 다음 턴을 시작하는 /goal, 정해진 간격으로 작업을 반복 실행하는 /loop, 시간표에 따라 에이전트를 깨우는 cron 스케줄, 특정 사건에 반응해 실행되는 hooks가 있습니다. Osmani는 여기에 병렬 작업 공간(worktree), SKILL.md로 정리된 작업 지식, MCP 연동, 실행 간 상태를 이어주는 영속 메모리를 더해 루프의 부품으로 꼽았습니다. 대부분 이 책의 뒷장에서 하네스의 부품으로 먼저 만나게 될 것들입니다. 같은 부품이 하네스에서는 "환경"으로, 루프에서는 "순환"으로 쓰입니다.

4. 그래도 사람이 잡고 있어야 하는 것

Anthropic에서 Claude Code를 만든 Boris Cherny는 "I don't prompt Claude anymore"(이제 Claude를 직접 프롬프트하지 않는다)라고 말했습니다. 그렇다고 사람이 할 일이 사라진 것은 아닙니다. Osmani는 에이전트가 안쪽 루프(조사하고, 구현하고, 검증하고, 반복하는 순환)를 돌더라도, 바깥 루프는 사람이 잡고 있어야 한다고 강조합니다. 결과의 품질을 검증하고, 내보낼지 말지를 판정하고, 그 결과에 책임지는 자리는 여전히 사람의 몫입니다.

그가 경고한 위험 두 가지도 기억해둘 만합니다.

• 이해 부채(comprehension debt): 루프가 만들어낸 결과물을 사람이 점점 이해하지 못하게 되는 것. 자동화가 늘수록 부채도 늘어납니다.
• 인지적 항복(cognitive surrender): 결과를 비판적으로 보지 않고 그냥 받아들이게 되는 것.

"Build loops like someone who intends to stay the engineer, not just the person who presses go."

"버튼만 누르는 사람이 아니라, 계속 엔지니어로 남을 사람처럼 루프를 만들어라."

루프 엔지니어링은 앞의 세 가지를 건너뛰고 바로 할 수 있는 일이 아닙니다. 프롬프트 → 컨텍스트 → 하네스로 쌓아온 기초가 그대로 루프의 재료가 됩니다. 좋은 프롬프트가 루프의 각 바퀴를 움직이고, 좋은 컨텍스트가 매 바퀴에 필요한 정보를 대주고, 좋은 하네스가 루프가 도는 환경을 받쳐줍니다. 그래서 이 책은 8장까지 순서를 지켜 올라간 뒤, 마지막에 루프를 한 겹 더 얹습니다.

이제 2장에서 작은 하네스를 직접 손으로 한 번 만들어 본 뒤, 3장에서 가장 기초인 프롬프트부터 시작합니다.