루프 엔지니어링은 왜 생겼나: 프롬프트가 아니라 운영 단위의 문제

AI 에이전트를 쓰다 보면 어느 순간 같은 일을 반복하고 있다는 느낌이 듭니다. 에러를 붙여 넣고, 다시 실행하고, 로그를 읽고, 실패 이유를 설명하고, 수정하게 하고, 또 테스트합니다. 처음에는 이 반복이 사람이 AI를 잘 쓰는 방법처럼 보입니다. 다만 작업이 커질수록 사람이 운전대를 계속 잡는 구조가 병목이 됩니다.

루프 엔지니어링은 이 병목에서 나왔습니다. Addy Osmani는 2026년 6월 글에서 루프 엔지니어링을 "에이전트에게 프롬프트를 주는 사람의 자리를 시스템으로 대체하는 일"로 설명했습니다. 그의 글은 Peter Steinberger와 Boris Cherny가 말한 흐름을 묶어, 이제는 사람이 매 턴 프롬프트를 쓰는 대신 루프가 에이전트를 부르는 단계로 넘어간다고 봅니다.

이 표현이 중요한 이유는 단어가 새로워서가 아닙니다. 문제의 단위가 바뀌었기 때문입니다. 예전에는 "이번 프롬프트를 어떻게 잘 쓸까"가 중심이었습니다. 지금은 "어떤 시스템이 일을 찾고, 맡기고, 검증하고, 기억하고, 다음 일을 고를까"가 중심입니다. 프롬프트는 루프 안의 부품이 됩니다.

핵심 정리

1. 01루프 엔지니어링은 수동 프롬프팅을 더 빠르게 하는 기술이 아니라, 반복 판단을 시스템에 맡기는 설계입니다.
2. 02탄생 배경에는 긴 작업의 피로, 세션 기억의 한계, 병렬 에이전트의 충돌, 검증 비용 증가가 있습니다.
3. 03루프에는 일감 발견, 작업 분배, 실행, 검증, 기록, 다음 행동 결정이 모두 필요합니다.
4. 04좋은 루프는 사람을 제거하지 않습니다. 사람을 매 턴 입력자에서 루프 설계자와 승인자로 옮깁니다.

용어 정리

수동 프롬프팅

사람이 매번 다음 지시를 입력하고 결과를 읽은 뒤 다시 지시하는 방식입니다.

manual

루프

목표, 실행, 검증, 기록, 다음 행동 선택이 반복되는 작업 단위입니다.

cycle

하네스

에이전트가 안전하게 일하도록 감싸는 실행 환경과 검증 구조입니다. 루프는 이 하네스를 반복 운영으로 확장합니다.

harness

외부 기억

대화창이 아니라 파일, 이슈, 보드, 데이터베이스에 남는 상태입니다. 다음 실행이 여기서 출발합니다.

memory

좋은 프롬프트의 시대가 끝난 것은 아닙니다

루프 엔지니어링이 등장했다고 해서 프롬프트가 중요하지 않다는 뜻은 아닙니다. 오히려 루프 안에서는 프롬프트가 더 중요해집니다. 다만 사람이 매번 손으로 쓰는 문장이 아니라, 시스템이 상황에 맞게 재사용하는 작업 계약이 됩니다. "이 일을 해줘"가 아니라 "이 상태를 읽고, 이 기준으로 판단하고, 이 검증을 통과할 때까지 진행하라"에 가까워집니다.

수동 프롬프팅은 작은 작업에서 여전히 빠릅니다. 아이디어를 스케치하거나, 오류 하나를 설명하거나, 짧은 문서를 고치는 데는 사람이 직접 말하는 편이 낫습니다. 문제는 반복이 생기는 순간입니다. 로그를 읽고 고치는 과정이 10번 반복되거나, 예약 글 7편을 같은 기준으로 쓰거나, 매일 아침 이슈를 분류해야 한다면 사람의 입력이 병목이 됩니다.

여기서 많은 팀이 착각합니다. 더 긴 프롬프트를 쓰면 해결될 거라고 생각합니다. 다만 긴 프롬프트는 한 번의 실행을 돕는 도구입니다. 루프는 여러 번의 실행을 이어 붙이는 구조입니다. 실패하면 무엇을 다시 읽을지, 어디까지 완료로 볼지, 다음 실행이 무엇을 기억할지가 정해져야 합니다.

Simon Willison이 말한 agentic engineering과 vibe coding의 경계도 이 문제와 닿아 있습니다. 에이전트가 코드를 쓰고 실행할 수 있게 되면, 사람이 코드를 다 보지 않는 순간도 늘어납니다. 그렇다면 더 중요한 것은 모델을 믿는 용기가 아니라 모델을 제한하고 검증하는 구조입니다. 루프는 그 구조를 반복 가능한 단위로 끌어올립니다.

루프가 필요해진 네 가지 압력

첫 번째 압력은 피로입니다. 긴 에이전트 작업은 사람에게 생각보다 많은 집중을 요구합니다. 결과를 읽고, 다음 지시를 고르고, 실패를 해석하고, 같은 말을 조금씩 바꿔 다시 넣는 과정은 자동화처럼 보이지만 실제로는 사람의 인지 노동입니다. 모델이 빨라질수록 사람은 더 자주 판단해야 하고, 그 판단이 하루의 에너지를 갉아먹습니다.

두 번째 압력은 기억입니다. 대화창은 길어질수록 흐려지고, 세션이 끝나면 맥락이 사라집니다. 이 때문에 루프는 상태를 밖에 둬야 합니다. 파일과 이슈가 대표적입니다. 체크리스트와 데이터베이스도 필요합니다. D1 row와 Linear ticket처럼 다음 실행이 읽을 수 있는 형태도 좋습니다. Addy Osmani가 루프의 구성요소 끝에 memory를 따로 둔 이유도 여기에 있습니다.

세 번째 압력은 병렬성입니다. 에이전트가 하나일 때는 사람이 운전대를 잡고 있어도 됩니다. 둘 이상이 동시에 움직이면 이야기가 달라집니다. 같은 브랜치를 만지고, 같은 파일을 고치고, 같은 테스트를 돌리면 충돌이 납니다. 루프에는 worktree와 역할 분리가 필요합니다. 결과 병합과 교차 검증 같은 운영 규칙도 있어야 합니다.

네 번째 압력은 검증입니다. AI가 만든 결과가 많아질수록 사람이 눈으로 다 보는 방식은 오래가지 않습니다. 테스트와 lint는 기본입니다. 빌드와 스크린샷이 남아야 합니다. D1 seed, R2 업로드, 라이브 smoke처럼 완료 기준도 기계적으로 남아야 합니다. 루프는 단순히 에이전트를 다시 부르는 자동화가 아니라, 검증 결과를 보고 다음 행동을 선택하는 구조입니다.

루프는 한 번 더 돌리는 자동화가 아닙니다

나쁜 루프는 단순한 재시도입니다. 실패하면 같은 명령을 다시 돌리고, 또 실패하면 다시 돌립니다. 이런 구조는 금방 비용을 태웁니다. 더 나쁜 경우에는 모델이 같은 오답을 다른 말로 반복합니다. 루프라는 이름을 붙였지만 실제로는 무한 재시도에 가깝습니다.

좋은 루프는 매번 상태가 바뀝니다. 실패하면 실패 로그가 다음 입력에 들어갑니다. 검증이 통과하면 완료 목록에 기록됩니다. 같은 실패가 세 번 반복되면 중단하고 사람에게 넘깁니다. 비용이 일정 기준을 넘으면 멈춥니다. 다음 실행은 이전 실행이 남긴 증거를 읽고 출발합니다.

이 때문에 루프 설계에는 완료 기준이 먼저 필요합니다. "좋게 만들어줘"는 루프가 아닙니다. "빌드가 통과하고, raw markdown table이 없고, body image가 CDN 200이고, D1 seed가 성공하면 완료"는 루프가 될 수 있습니다. 루프는 모델의 의도를 믿는 구조가 아니라, 결과의 증거를 읽는 구조입니다.

또 하나 중요한 점은 사람이 사라지지 않는다는 사실이다. 사람은 매번 키를 누르는 자리에서 빠질 뿐입니다. 대신 루프의 목표와 한계를 설계합니다. 예산, 중단 조건, 최종 승인 기준도 사람의 몫입니다. 수동 프롬프팅이 운전대를 잡는 일이라면, 루프 엔지니어링은 건조기를 설계하는 일에 가깝습니다. 옷을 한 장씩 비비는 대신, 어떤 조건에서 돌고 멈출지 정합니다.

1. 01일감 발견
2. 02컨텍스트 구성
3. 03에이전트 실행
4. 04검증
5. 05기록
6. 06다음 행동 선택

왜 지금인가

루프와 비슷한 생각은 오래전부터 있었습니다. CI도 루프이고, cron도 루프이고, 테스트 자동화도 루프입니다. 그런데 2026년에 이 단어가 갑자기 힘을 얻은 이유는 에이전트 도구의 기본 부품이 갖춰졌기 때문입니다. 스케줄 실행과 worktree가 제품 안으로 들어오기 시작했습니다. subagent와 hook도 같은 흐름에 있습니다. skill, connector, memory도 제품 안으로 들어옵니다.

예전에는 루프를 만들려면 개인 bash 스크립트와 glue code를 직접 유지해야 했습니다. 그 방식은 강하지만 개인화되어 있었습니다. 지금은 Codex, Claude Code 같은 도구 안에서 비슷한 부품이 보입니다. 그러면 설계 관심사는 "이 도구가 되냐"에서 "어떤 루프 구조가 도구가 바뀌어도 유지되냐"로 이동합니다.

이 변화는 작은 팀에게 특히 큽니다. 사람을 더 뽑지 않고도 반복 운영을 만들 수 있기 때문입니다. 다만 위험도 같이 커집니다. 루프가 잘못 설계되면 잘못된 일을 빠르게 반복합니다. 이 때문에 루프 엔지니어링의 핵심은 더 많이 자동화하는 것이 아니라, 더 일찍 멈추고 더 분명히 검증하는 구조를 만드는 것입니다.

앞으로 좋은 팀의 차이는 "AI를 쓰는가"에서 갈리지 않을 가능성이 큽니다. 거의 모두가 씁니다. 차이는 어떤 반복을 시스템에 맡겼고, 어떤 판단은 사람에게 남겼고, 실패했을 때 어디서 멈추게 했는지에서 생깁니다. 루프 엔지니어링은 프롬프트 기술의 다음 이름이 아니라, AI 작업을 운영 단위로 재설계하려는 이름입니다.