루프 엔지니어링 - AI가 계속 일하게 만드는 법으로
조이
카테고리
- 개념정리
요즘 AI 개발 쪽에서 루프 엔지니어링(Loop Engineering) 이라는 말이 자주 보여요. 처음 들으면 좀 거창하게 들리는데, 핵심은 의외로 단순해요.
이제 중요한 건 "AI에게 한 번 잘 시키는 법"이 아니라, AI가 반복해서 일하고, 검증하고, 기록하고, 멈출 줄 아는 구조를 설계하는 법이다.
루프 엔지니어링이 뭔데?
지난 2년 동안 AI 코딩 에이전트를 쓰는 방식은 이랬어요. 좋은 프롬프트를 쓰고, 답을 읽고, 다음 프롬프트를 치고, 또 답을 읽고. 사람이 계속 옆에 붙어서 한 턴씩 손으로 돌리는 거죠. 도구를 손에 쥐고 있는 사람이 항상 나였어요.
루프 엔지니어링은 여기서 나를 그 자리에서 빼는 거예요.
"루프 엔지니어링은 에이전트에게 프롬프트를 넣는 사람을 나 자신에서 시스템으로 바꾸는 것이다."
즉 작은 시스템 하나를 만들어요. 그 시스템이 할 일을 찾고, 에이전트에게 넘기고, 결과를 확인하고, 무엇을 했는지 적어두고, 다음에 뭘 할지 정해요. 그러고는 그 시스템이 나 대신 에이전트를 쿡쿡 찔러요. 루프는 "목적을 정해두면 AI가 끝날 때까지 알아서 반복하는 재귀적 목표" 라고 생각하면 돼요.
이 흐름에 불을 붙인 건 2026년 6월 Peter Steinberger의 짧은 글이었어요. "이제 코딩 에이전트에 프롬프트를 넣지 마라. 에이전트에게 프롬프트를 넣어주는 루프를 설계하라."내 일은 루프를 짜는 것이다."
Claude Code를 만든 Anthropic의 Boris Cherny도 비슷하게 말했어요. "나는 더 이상 Claude에 프롬프트를 넣지 않는다. 루프를 돌려서 그게 Claude에 프롬프트를 넣고 뭘 할지 정하게 한다. 내 일은 루프를 짜는 것이다."
위 내용을 보니까, 반년전에 삽질했던 상세페이지 자동화가 생각났어요. 그때도 에이전트가 좋은 프롬프트를 작성하도록 하는 방법을 고민했었는데... (궁금하면👇)
프롬프트 → 컨텍스트 → 하네스 → 루프
루프 엔지니어링은 갑자기 튀어나온 게 아니에요. 설계의 대상이 점점 바깥으로 넓어진 흐름의 끝에 있어요.
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 — 토큰, 시간, 실행 횟수 제한.
안 정해두면 비용이 조용히 폭발해요.
여기서 자주 쓰이는 한 가지 요령이 만드는 에이전트와 검사하는 에이전트를 분리하는 거예요.믿을 수 있는 검사자가 있어야 마음 놓고 자리를 비울 수 있어요.
코드를 쓴 모델은 자기 숙제를 너무 후하게 채점해요. 다른 지시를 받은 두 번째 에이전트가 첫 번째가 스스로 넘어간 실수를 잡아내요. 루프는 내가 안 보는 동안 돌기 때문에, 믿을 수 있는 검사자가 있어야 마음 놓고 자리를 비울 수 있어요.
이 글도 보고가세요?
실제로 어떻게 써먹나
개발자만의 이야기가 아니에요. 일감을 찾고, 처리하고, 확인하고, 애매한 건 사람에게 넘기는 구조라면 어디든 적용돼요.
•
콘텐츠 루프: 자료 수집 → 초안 작성 → 사실 확인 → 발행 후보만 사람에게 보고.
•
리서치 루프: 새 글·논문 수집 → 요약 → 중복 제거 → 인사이트 추출 → 지식베이스 업데이트.
•
CS 루프: 문의 수집 → 유형 분류 → 답변 초안 → 위험한 케이스만 사람 승인.
•
개발 루프: 이슈 수집 → 작업 분해 → 코드 수정 → 테스트 → PR 초안.
Osmani가 자주 쓴다는 개발 루프 예시가 그림이 잘 그려져요.
매일 아침 자동으로 한 번 돌면서, 어제 실패한 테스트와 열린 이슈, 최근 커밋을 읽어요. 할 만한 일은 각각 격리된 작업 공간을 열어서 한 에이전트가 고치고, 다른 에이전트가 그 수정을 기존 테스트와 프로젝트 규칙에 비춰 검토해요. 통과한 건 PR을 열고 티켓을 업데이트하고, 처리 못 한 건 내 받은함에 쌓여요. 상태 파일이 척추 역할을 해서, 내일 아침엔 오늘 멈춘 지점부터 다시 시작해요.
여기서 핵심은 이거예요. 나는 그걸 한 번 설계했을 뿐, 저 단계들을 일일이 프롬프트로 친 적이 없어요.
과장하지는 말기
좋아 보이지만, 루프가 만능은 아니에요. 오히려 루프가 좋아질수록 더 날카로워지는 문제들이 있어요.
•
검증과 중단조건 없는 루프는 자동화가 아니라 자동 삽질이에요.
◦
실제로 한 회사에서 PR을 돌보는 루프가 하루에 커밋 43개를 만들었는데, 범위가 점점 번져서 원래 목적과 상관없는 곳까지 건드렸어요. 결과물은 거의 다 반려됐어요. 반대로 오래된 브랜치를 지우는 좁고 검증하기 쉬운 루프는 129개를 깔끔하게 정리했고요. 차이는 범위와 검증이에요.
•
토큰 비용이 폭발할 수 있어요.
◦
에이전트를 여럿 돌리고 검사자까지 붙이면 비용이 금방 불어나요. 실행 횟수, 최대 턴, 예산 한도를 꼭 걸어두세요.
•
사람이 판단해야 할 지점은 남겨야 해요.
◦
"다 했다"는 건 주장이지 증명이 아니에요. 내가 안 읽으면, 존재하는 것과 내가 이해하는 것 사이의 간격만 점점 벌어져요.
똑같은 루프를 두 사람이 만들어도 정반대 결과가 나올 수 있어요. 한 명은 깊이 이해한 일을 더 빨리 하려고 쓰고, 다른 한 명은 일을 이해하지 않으려고 써요. 루프는 그 차이를 몰라요. 아는 건 사람이에요.
정리하면
루프 엔지니어링은 작업이 쉬워졌다는 이야기가 아니에요. 지렛대의 위치가 옮겨갔다는 이야기예요. 좋은 문장을 쓰는 데서, 검증 가능한 일의 구조를 설계하는 데로요.
그래서 시작은 작게 하는 게 좋아요. 읽기만 하는 루프부터, 검증이 "아니오"라고 말할 수 있게 된 다음에 쓰기 권한을 주는 식으로요. 루프를 돌리기 전에 먼저 정할 건 자동화 여부가 아니라, 어디서 멈출 것인가 예요.
루프를 만들되, 그냥 시작 버튼을 누르는 사람이 아니라 끝까지 엔지니어로 남을 사람처럼 만들면 돼요.
참고자료
•
Addy Osmani — Loop Engineering: https://addyosmani.com/blog/loop-engineering/
•
Addy Osmani — 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/
•
GitHub — cobusgreyling/loop-engineering: https://github.com/cobusgreyling/loop-engineering
•
The New Stack — Loop Engineering: https://thenewstack.io/loop-engineering/
'zoeylog' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'zoeylog'을 구독하세요!
Slashpage에 가입하고 'zoeylog'을 구독하세요!
구독
