# 루프 엔지니어링 - AI가 계속 일하게 만드는 법으로

요즘 AI 개발 쪽에서 **_루프 엔지니어링(Loop Engineering)_** 이라는 말이 자주 보여요. 처음 들으면 좀 거창하게 들리는데, 핵심은 의외로 단순해요.

> 이제 중요한 건 "AI에게 한 번 잘 시키는 법"이 아니라, AI가 반복해서 일하고, 검증하고, 기록하고, 멈출 줄 아는 구조를 설계하는 법이다.

## 루프 엔지니어링이 뭔데?

지난 2년 동안 AI 코딩 에이전트를 쓰는 방식은 이랬어요. 좋은 프롬프트를 쓰고, 답을 읽고, 다음 프롬프트를 치고, 또 답을 읽고. 사람이 계속 옆에 붙어서 한 턴씩 손으로 돌리는 거죠. **도구를 손에 쥐고 있는 사람이 항상 나였어요.**

**루프 엔지니어링은 여기서 나를 그 자리에서 빼는 거예요.** 

"루프 엔지니어링은 에이전트에게 프롬프트를 넣는 사람을 나 자신에서 시스템으로 바꾸는 것이다."

즉 작은 시스템 하나를 만들어요. 그 시스템이 할 일을 찾고, 에이전트에게 넘기고, 결과를 확인하고, 무엇을 했는지 적어두고, 다음에 뭘 할지 정해요. 그러고는 그 시스템이 나 대신 에이전트를 쿡쿡 찔러요. 루프는 **"목적을 정해두면 AI가 끝날 때까지 알아서 반복하는 재귀적 목표"** 라고 생각하면 돼요.

이 흐름에 불을 붙인 건 [2026년 6월 Peter Steinberger의 짧은 글](https://x.com/steipete/status/2063697162748260627)이었어요. "**이제 코딩 에이전트에 프롬프트를 넣지 마라. 에이전트에게 프롬프트를 넣어주는 루프를 설계하라.**"**내 일은 루프를 짜는 것이다.**"

Claude Code를 만든 Anthropic의 Boris Cherny도 비슷하게 말했어요. "나는 더 이상 Claude에 프롬프트를 넣지 않는다. 루프를 돌려서 그게 Claude에 프롬프트를 넣고 뭘 할지 정하게 한다. **내 일은 루프를 짜는 것이다.**"

위 내용을 보니까, 반년전에 삽질했던 상세페이지 자동화가 생각났어요. 그때도 에이전트가 좋은 프롬프트를 작성하도록 하는 방법을 고민했었는데... (궁금하면👇)

[클로드코드 멀티 에이전트로 상세페이지 현지화 자동화 #3 - 이미지 생성 삽질편 - zoeylog](https://zoey.day/claude-code-agent-product-page-localization-image)

## 프롬프트 → 컨텍스트 → 하네스 → 루프

루프 엔지니어링은 갑자기 튀어나온 게 아니에요. 설계의 대상이 점점 바깥으로 넓어진 흐름의 끝에 있어요.

```text
Prompt Engineering
→ Context Engineering
→ Agent Harness Engineering
→ Loop Engineering
```

- **프롬프트 엔지니어링**은 **한 번의 지시를 잘 쓰는 법**이에요. "어떻게 물어봐야 좋은 답이 나올까"를 고민하는 단계예요.

- **컨텍스트 엔지니어링**은 한 발 넓어져요. **필요한 배경, 자료, 예시, 규칙을 모델에게 잘 공급하는 법**이에요. 모델이 보는 정보 환경 전체를 챙기는 거죠.

- **에이전트 하네스 엔지니어링**은 모델 주변을 설계해요. 도구, 권한, 샌드박스, 테스트, 피드백, 그리고 실패했을 때 돌아올 복구 경로까지. **모델이 일을 한 번 제대로 끝내도록 감싸주는 작업 환경**이에요.

- **루프 엔지니어링**은 한 층 더 위예요. **사람이 매번 다음 프롬프트를 치지 않아도, 시스템이 목표를 반복 수행하고, 검증하고, 기록하고, 멈추는 법**이에요.

중요한 건 이 단계들이 서로를 대체하지 않는다는 거예요.**위로 쌓여요.** 좋은 프롬프트 위에 좋은 컨텍스트, 그 위에 좋은 하네스, 그 위에 루프가 올라가요.

**위로 쌓여요.** 좋은 프롬프트 위에 좋은 컨텍스트, 그 위에 좋은 하네스, 그 위에 루프가 올라가요.

## 하네스랑 뭐가 다른데?

여기서 헷갈리기 쉬워서 비유로 정리할게요.

- **평가 하네스는 채점기예요.** 결과물이 기준에 맞는지 점수를 매기는 장치죠.

- **에이전트 하네스는 작업장이에요.** 에이전트 한 명이 들어가서 일하는 공간. 연장도 있고, 작업 규칙도 있고, 망쳤을 때 되돌릴 장치도 있어요. 한 번의 작업을 잘 끝내게 해주는 게 목적이에요.

- **루프 엔지니어링은 자동 공정 라인이에요.** 그 작업장이 **타이머에 맞춰 알아서 돌고, 스스로 일감을 찾고, 일꾼을 나눠 보내고, 끝나면 다음 일감으로 넘어가는** 라인 전체를 설계하는 거예요.

그래서 Osmani도 "루프는 하네스보다 한 층 위에 있다"고 말해요. 하네스가 에이전트 한 명을 위한 환경이라면, 루프는 그 환경을 반복해서 돌리는 운영 체계예요.

## 루프는 그냥 ⏰cron 아니야?

가장 흔한 오해예요. "그거 그냥 정해진 시간에 자동 실행하는 거 아니야?" 아니에요.

cron은 **언제 실행할지**만 정해요. 

→ 7시에 돌려라, 끝. 

루프는 거기에 훨씬 많은 게 들어가요.

→ 무엇을 읽고 시작할지, 어디까지 손대도 되는지, 끝났다는 걸 무엇으로 확인할지, 무엇을 기억할지, 언제 멈추고 사람에게 넘길지까지요.

핵심은 **"아니오라고 말할 수 있는 무언가"** 예요. 테스트, 타입 체크, 진짜 에러, 리뷰 대기열, 예산 한도 같은 거죠. 이런 제동 장치가 없으면 루프는 그냥 **자기 자신과 빠른 속도로 맞장구치는 에이전트**가 돼버려요.

## 루프를 이루는 구성요소

루프를 설계할 때 챙겨야 할 것들을 쉽게 정리하면 이래요.

> **Purpose / Goal — 이 루프가 왜 존재하나.**

목적이 흐릿하면 나머지가 다 흔들려요. "뭔가 유용한 걸 해줘"는 루프가 아니에요.

> **Trigger — 언제 시작하나.** 

매일 아침 7시 같은 시간일 수도, Slack 메시지나 새 이슈 같은 이벤트일 수도 있어요.

> **Context — 무엇을 읽고 시작하나.** 

어제 기록, 열린 이슈, 최근 변경 같은 입력이요.

> **Action policy — 어디까지 해도 되나.** 

읽기만 할지, 글을 쓸지, PR까지 열지. 권한의 경계예요.

> **Verification — 끝났다는 주장을 무엇으로 확인하나.** 

루프가 "다 했어요"라고 말해도 그건 주장일 뿐 증명이 아니에요. 확인할 기준이 필요해요.

> **Memory / State — 다음 실행 때 무엇을 기억하나.** 

모델은 실행 사이에 다 잊어버려요. 그래서 기억은 대화가 아니라 디스크에 있어야 해요. 마크다운 파일 하나, 보드 하나면 충분해요. **에이전트는 잊어도 기록은 안 잊어요.**

> **Escalation / Stop condition — 언제 멈추고 사람에게 넘기나.** 

애매한 건 사람에게 올리는 출구가 있어야 해요.

> **Cost control — 토큰, 시간, 실행 횟수 제한.** 

안 정해두면 비용이 조용히 폭발해요.

> 여기서 자주 쓰이는 한 가지 요령이 **만드는 에이전트와 검사하는 에이전트를 분리**하는 거예요.**믿을 수 있는 검사자**가 있어야 마음 놓고 자리를 비울 수 있어요.

코드를 쓴 모델은 자기 숙제를 너무 후하게 채점해요. 다른 지시를 받은 두 번째 에이전트가 첫 번째가 스스로 넘어간 실수를 잡아내요. 루프는 내가 안 보는 동안 돌기 때문에, **믿을 수 있는 검사자**가 있어야 마음 놓고 자리를 비울 수 있어요.

이 글도 보고가세요?

[AI도 혼자 생각하면 틀린다? 이제는 토론하는 AI 시대 (Society of Thought) - zoeylog](https://zoey.day/society-of-thought)

## 실제로 어떻게 써먹나

개발자만의 이야기가 아니에요. 일감을 찾고, 처리하고, 확인하고, 애매한 건 사람에게 넘기는 구조라면 어디든 적용돼요.

- **콘텐츠 루프**: 자료 수집 → 초안 작성 → 사실 확인 → 발행 후보만 사람에게 보고.

- **리서치 루프**: 새 글·논문 수집 → 요약 → 중복 제거 → 인사이트 추출 → 지식베이스 업데이트.

- **CS 루프**: 문의 수집 → 유형 분류 → 답변 초안 → 위험한 케이스만 사람 승인.

- **개발 루프**: 이슈 수집 → 작업 분해 → 코드 수정 → 테스트 → PR 초안.

Osmani가 자주 쓴다는 개발 루프 예시가 그림이 잘 그려져요. 

> 매일 아침 자동으로 한 번 돌면서, 어제 실패한 테스트와 열린 이슈, 최근 커밋을 읽어요. 할 만한 일은 각각 격리된 작업 공간을 열어서 한 에이전트가 고치고, 다른 에이전트가 그 수정을 기존 테스트와 프로젝트 규칙에 비춰 검토해요. 통과한 건 PR을 열고 티켓을 업데이트하고, 처리 못 한 건 내 받은함에 쌓여요. 상태 파일이 척추 역할을 해서, 내일 아침엔 오늘 멈춘 지점부터 다시 시작해요.

여기서 핵심은 이거예요. **나는 그걸 한 번 설계했을 뿐, 저 단계들을 일일이 프롬프트로 친 적이 없어요.**

## 과장하지는 말기

좋아 보이지만, 루프가 만능은 아니에요. 오히려 루프가 좋아질수록 **더 날카로워지는** 문제들이 있어요.

- **검증과 중단조건 없는 루프는 자동화가 아니라 자동 삽질이에요.** 

    - 실제로 한 회사에서 PR을 돌보는 루프가 하루에 커밋 43개를 만들었는데, 범위가 점점 번져서 원래 목적과 상관없는 곳까지 건드렸어요. 결과물은 거의 다 반려됐어요. 반대로 오래된 브랜치를 지우는 좁고 검증하기 쉬운 루프는 129개를 깔끔하게 정리했고요. 차이는 범위와 검증이에요.

- **토큰 비용이 폭발할 수 있어요.** 

    - 에이전트를 여럿 돌리고 검사자까지 붙이면 비용이 금방 불어나요. 실행 횟수, 최대 턴, 예산 한도를 꼭 걸어두세요.

- **사람이 판단해야 할 지점은 남겨야 해요.** 

    - "다 했다"는 건 주장이지 증명이 아니에요. 내가 안 읽으면, 존재하는 것과 내가 이해하는 것 사이의 간격만 점점 벌어져요.

똑같은 루프를 두 사람이 만들어도 정반대 결과가 나올 수 있어요. **한 명은 깊이 이해한 일을 더 빨리 하려고 쓰고, 다른 한 명은 일을 이해하지 않으려고 써요. 루프는 그 차이를 몰라요. 아는 건 사람이에요.**

## 정리하면

루프 엔지니어링은 작업이 쉬워졌다는 이야기가 아니에요. **지렛대의 위치가 옮겨갔다**는 이야기예요. 좋은 문장을 쓰는 데서, 검증 가능한 일의 구조를 설계하는 데로요.

그래서 시작은 작게 하는 게 좋아요. 읽기만 하는 루프부터, 검증이 "아니오"라고 말할 수 있게 된 다음에 쓰기 권한을 주는 식으로요. 루프를 돌리기 전에 먼저 정할 건 자동화 여부가 아니라, **어디서 멈출 것인가** 예요.

루프를 만들되, 그냥 시작 버튼을 누르는 사람이 아니라 끝까지 엔지니어로 남을 사람처럼 만들면 돼요.

---

참고자료

- Addy Osmani — Loop Engineering: [https://addyosmani.com/blog/loop-engineering/](https://addyosmani.com/blog/loop-engineering/)

- Addy Osmani — Agent Harness Engineering: [https://addyosmani.com/blog/agent-harness-engineering/](https://addyosmani.com/blog/agent-harness-engineering/)

- SmartScope — What Is Loop Engineering? From Writing Prompts to Designing Agent Loops: [https://smartscope.blog/en/generative-ai/methodology/loop-engineering-agent-loops-2026/](https://smartscope.blog/en/generative-ai/methodology/loop-engineering-agent-loops-2026/)

- GitHub — cobusgreyling/loop-engineering: [https://github.com/cobusgreyling/loop-engineering](https://github.com/cobusgreyling/loop-engineering)

- The New Stack — Loop Engineering: [https://thenewstack.io/loop-engineering/](https://thenewstack.io/loop-engineering/)

For the site tree, see the [root Markdown](https://zoey.day/.md).