루프 엔지니어링 — 프롬프트가 아니라 검증 루프를 설계하는 일

AI 에이전트를 쓰는 방식이 바뀌고 있다. 예전에는 “좋은 프롬프트를 어떻게 쓰느냐”가 핵심이었다. 이제는 점점 “프롬프트를 반복해서 보내는 구조를 어떻게 설계하느냐”가 핵심이 되고 있다.

PyTorchKR에 올라온 루프 엔지니어링 정리글은 이 전환을 잘 짚는다. 글에서 인용한 Peter Steinberger의 표현을 빌리면, 더 이상 코딩 에이전트에 프롬프트를 작성하는 것이 아니라 에이전트에 프롬프트를 보내는 루프를 설계해야 한다. Claude Code를 이끄는 Boris Cherny도 비슷한 취지로, 직접 Claude에 명령하는 대신 Claude가 무엇을 할지 파악하는 루프를 돌리고 있으며 자신의 일은 그 루프를 작성하는 것이라고 말했다.

이 말은 단순한 유행어가 아니다. 에이전트 시스템을 실제로 운영해 보면, 한 번의 프롬프트보다 중요한 것은 그 다음 단계다.

실패했을 때 무엇을 관찰할 것인가?
어떤 기준으로 성공과 실패를 판단할 것인가?
다시 시도할 때 무엇을 바꿀 것인가?
언제 멈추고 사람에게 넘길 것인가?
여러 에이전트가 동시에 움직일 때 충돌을 어떻게 막을 것인가?

이 질문들에 답하는 일이 루프 엔지니어링이다.

루프 엔지니어링이란 무엇인가

루프 엔지니어링은 AI 에이전트가 목표를 달성할 때까지 스스로 다음 사이클을 반복하도록 만드는 설계 방법론이다. 기본 사이클은 단순하다.

Discover: 목표와 현재 상태를 탐색한다.
Plan: 수집한 정보로 작업 계획을 세운다.
Execute: 코드를 작성하거나 문서를 만들거나 도구를 호출한다.
Verify: 결과가 목표와 기준을 충족하는지 확인한다.
Iterate: 실패하면 원인을 반영해 다시 반복한다.

기존의 프롬프트 기반 작업에서는 사람이 이 루프의 대부분을 맡았다. 개발자가 지시하고, 결과를 읽고, 실패를 판단하고, 다시 지시했다. 에이전트는 실행자였고 사람은 루프 컨트롤러였다.

루프 엔지니어링에서는 이 구조가 뒤집힌다. 사람은 목표와 경계 조건을 정하고, 시스템은 발견·계획·실행·검증·반복을 최대한 자동으로 수행한다. 사람의 역할은 “다음 프롬프트를 쓰는 사람”에서 “검증 가능한 작업 시스템을 설계하는 사람”으로 이동한다.

💡

루프 엔지니어링의 핵심은 에이전트를 방치하는 것이 아니다. 반복 조건, 검증 기준, 중단 조건, 권한 경계를 명시해 에이전트가 안전하게 반복할 수 있는 레일을 까는 일이다.

좋은 루프를 만드는 여섯 가지 구성 요소

PyTorchKR 글은 실제 루프를 만들기 위한 구성 요소를 여섯 가지로 정리한다. 이 분해가 실무적으로 꽤 유용하다.

1. Automations: 루프의 심장박동

루프는 언제 시작되는가? 사람이 버튼을 누를 때만 도는가, 일정 주기로 도는가, 특정 조건이 만족될 때까지 계속 도는가?

자동화는 이 심장박동을 정의한다. 예를 들어 다음과 같은 목표를 줄 수 있다.

test/auth의 모든 테스트가 통과하고 lint가 깨끗해질 때까지 수정한다.

이 목표가 주어지면 루프는 테스트 실행, 실패 분석, 수정, 재검증을 반복한다. 핵심은 “작업을 해줘”가 아니라 “이 검증 조건이 참이 될 때까지 반복해줘”라는 형태로 목표가 바뀐다는 점이다.

2. Worktrees: 병렬 실행의 충돌 방지 장치

여러 에이전트가 동시에 작업하면 파일 충돌이 바로 문제가 된다. 두 에이전트가 같은 파일을 수정하고, 서로의 변경을 덮어쓰고, 최종 상태가 꼬인다.

git worktree는 이 문제를 줄인다. 각 에이전트가 같은 저장소 이력을 공유하되, 자신만의 작업 디렉터리와 브랜치를 가진다. 그러면 여러 시도를 병렬로 돌리고, 가장 좋은 결과만 선택하거나 병합할 수 있다.

루프가 단일 실행에서 병렬 탐색으로 넘어가려면 물리적 격리가 필요하다. worktree는 에이전트 병렬화의 기본 단위에 가깝다.

3. Skills: 매번 처음부터 읽지 않게 하는 프로젝트 지식

에이전트는 매 실행마다 프로젝트를 처음 보는 것처럼 행동하기 쉽다. 빌드 방법, 테스트 절차, 금지된 패턴, 과거 장애의 교훈을 매번 다시 설명해야 한다면 루프의 효율은 급격히 떨어진다.

스킬은 이 문제를 줄인다. 프로젝트별 SKILL.md, VISION.md, ARCHITECTURE.md, RULES.md 같은 파일에 다음 내용을 저장해 둔다.

성공의 정의
기술 스택과 폴더 구조
빌드·테스트 절차
절대 하면 안 되는 일
과거 사고에서 얻은 교훈

좋은 스킬은 루프의 Discover 단계를 단축한다. 에이전트가 매번 저장소를 처음부터 추측하지 않고, 이미 합의된 운영 지식을 바탕으로 바로 작업을 시작할 수 있다.

4. Plugins and Connectors: 실제 세계와 연결되는 손

루프가 파일만 고치고 끝난다면 영향 범위는 제한적이다. 실제 업무 루프는 이슈 트래커, 데이터베이스, 스테이징 API, Slack, CI, 배포 시스템과 연결되어야 한다.

MCP 같은 플러그인·커넥터는 에이전트가 파일시스템 밖으로 나가 실제 환경에서 행동하게 만든다. 예를 들어 루프는 다음을 수행할 수 있다.

Linear나 GitHub Issue를 읽는다.
관련 코드를 수정한다.
테스트와 lint를 돌린다.
PR을 연다.
CI 결과를 확인한다.
통과하면 Slack에 알린다.

이때 중요한 것은 권한 경계다. 읽기, 쓰기, 배포, 외부 메시지 전송은 위험도가 다르다. 좋은 루프는 각 커넥터의 권한과 승인 조건을 분리한다.

5. Subagents: 만드는 AI와 평가하는 AI 분리

코드를 작성한 에이전트가 자신의 작업을 평가하면 관대해지기 쉽다. 사람도 자기 글의 오타를 잘 못 찾는다. 에이전트도 마찬가지다.

그래서 루프에는 maker와 checker를 분리하는 구조가 필요하다.

Explore 에이전트: 코드와 문제 범위를 탐색한다.
Implement 에이전트: 실제 변경을 만든다.
Verify 에이전트: 변경을 검증하고 반례를 찾는다.
Critic 에이전트: 설계의 허점과 회귀 위험을 본다.

중요한 점은 평가자가 생성자의 논리를 그대로 이어받지 않게 하는 것이다. 다른 프롬프트, 다른 역할, 때로는 다른 모델을 쓰는 편이 좋다. 에이전트 루프에서 독립 검증은 옵션이 아니라 안전장치다.

6. Memory: 루프의 지속성

모델은 실행이 끝나면 대부분을 잊는다. 하지만 실제 작업은 하루, 일주일, 한 달에 걸쳐 이어진다. 루프가 지속성을 가지려면 대화 바깥의 메모리가 필요하다.

메모리는 다음을 기록한다.

무엇을 시도했는가
무엇이 통과했는가
무엇이 실패했는가
어떤 결정을 내렸는가
다음 실행은 어디서 시작해야 하는가

이 메모리가 없으면 루프는 매번 같은 실수를 반복한다. 반대로 메모리가 잘 관리되면, 내일 아침의 루프는 오늘 멈춘 지점에서 다시 시작할 수 있다.

단일 루프와 플릿 루프

루프의 규모는 크게 두 가지로 나눌 수 있다.

단일 에이전트 루프

하나의 에이전트가 Discover, Plan, Execute, Verify, Iterate를 모두 수행한다. 단순한 버그 수정, 작은 리팩터링, 문서 작성처럼 범위가 좁은 작업에 적합하다.

장점은 단순함이다. 오케스트레이션 비용이 낮고, 컨텍스트가 흩어지지 않는다. 단점은 자기 검증의 한계와 탐색 다양성 부족이다.

플릿 루프

오케스트레이터가 목표를 여러 조각으로 나누고, 각 조각을 전문가 에이전트에게 할당한다. 구현자, 리뷰어, 테스터, 리서처가 각각 다른 역할을 맡는다.

플릿 루프는 복잡한 작업에 강하다. 여러 접근을 병렬로 탐색하고, 서로 다른 관점에서 검증할 수 있다. 대신 비용이 커지고, 상태 관리와 결과 통합이 어려워진다.

실무에서는 처음부터 플릿 루프를 만들기보다, 단일 루프로 시작한 뒤 병목이 명확해질 때 역할을 분리하는 편이 안전하다.

오픈 루프와 클로즈드 루프

또 하나의 중요한 구분은 오픈 루프와 클로즈드 루프다.

오픈 루프는 탐색적이다. 목표가 넓고, 성공 기준이 유동적이며, 에이전트가 여러 방향을 시도한다. 리서치, 기획, 아키텍처 탐색에 유용하다. 하지만 비용이 크고 결과 품질 편차가 크다.

클로즈드 루프는 경계가 명확하다. 성공 조건이 테스트, lint, 타입체크, 정량 점수처럼 비교적 분명하다. 코딩 작업, QA, 데이터 정제, 문서 포맷 검증에 적합하다.

현재 실무에서 더 안정적인 것은 클로즈드 루프다. 특히 다음처럼 검증 가능한 목표가 있을 때 강하다.

- npm run typecheck 통과
- npm run build 통과
- 특정 테스트 스위트 통과
- 새 API 응답이 스키마를 만족
- 문서 frontmatter가 규칙을 만족

루프 엔지니어링의 첫 단계는 거창한 자율 에이전트를 만드는 것이 아니다. 사람이 이미 반복하던 검증 가능한 작업 하나를 클로즈드 루프로 바꾸는 것이다.

비용은 마지막 장벽이다

루프 엔지니어링의 가장 큰 장벽은 아이디어의 난이도보다 비용이다. 루프는 반복한다. 반복은 토큰을 태운다.

PyTorchKR 글은 대략적인 규모를 이렇게 정리한다.

루프 유형	대략적인 토큰 규모
단일 에이전트 중간 규모 코딩 루프	50K ~ 200K tokens
오케스트레이터 + 전문가 3명의 플릿 루프	500K ~ 2M tokens
매일 실행되는 스케줄 루프	주간 수백만 tokens

매 재시도, 매 검증, 매 서브에이전트 호출, 매 컨텍스트 로딩이 비용이다. 그래서 루프 엔지니어링은 단순히 “에이전트를 더 많이 돌리자”가 아니다. 적절한 모델 선택, 컨텍스트 압축, 캐싱, 조기 중단 조건, 저렴한 검증기를 함께 설계해야 한다.

글에서는 DeepSeek, Kimi, MiniMax 같은 저비용 LLM이 이 장벽을 낮출 수 있다고 본다. 이 방향 자체는 맞다. 다만 특정 모델 스펙이나 가격은 빠르게 바뀌므로, 루프 설계에서는 모델 이름보다 비용 구조를 먼저 봐야 한다.

긴 컨텍스트가 필요한가?
출력이 매우 긴가?
도구 호출과 JSON 안정성이 중요한가?
검증자는 비싼 모델이어야 하는가, 싼 모델이나 deterministic checker로 충분한가?
실패율이 높을 때 몇 번까지 반복할 것인가?

좋은 루프는 토큰을 많이 쓰는 루프가 아니라, 검증 가능한 개선을 최소 비용으로 반복하는 루프다.

루프 엔지니어링을 실제로 시작하는 방법

실무에서 바로 적용한다면 다음 순서가 좋다.

1. 반복 작업 하나를 고른다

처음부터 “완전 자율 개발자”를 만들려고 하면 실패하기 쉽다. 대신 사람이 이미 반복하던 좁은 작업을 고른다.

실패한 테스트 고치기
문서 frontmatter 정리
린트 오류 자동 수정
PR 리뷰 코멘트 반영
특정 로그 패턴의 원인 분석

2. 완료 조건을 먼저 쓴다

프롬프트보다 먼저 필요한 것은 완료 조건이다.

완료 조건:
1. npm run typecheck 성공
2. npm run build 성공
3. 변경 파일이 content/posts 아래 MDX와 public/rss.xml로 제한됨
4. 외부 전송은 사람 승인 전 금지

이 조건이 없으면 루프는 언제 멈춰야 할지 모른다.

3. 관찰 가능한 로그를 남긴다

루프가 실패했을 때 사람이 봐야 할 것은 “에이전트가 열심히 했다”가 아니라 다음 정보다.

어떤 명령을 실행했는가
실패한 검증은 무엇인가
어떤 가설로 수정했는가
이전 시도와 무엇이 달라졌는가
다음 시도에서 무엇을 바꿀 것인가

로그가 없으면 루프는 디버깅할 수 없다. 디버깅할 수 없는 루프는 운영할 수 없다.

4. maker와 checker를 분리한다

작은 루프라도 검증은 별도로 둔다. 가능하면 deterministic checker를 먼저 쓰고, LLM 평가는 그 다음에 둔다.

1차 검증: 테스트, 타입체크, 빌드, 스키마 검사
2차 검증: 독립 reviewer 에이전트
3차 검증: 사람 승인

이 순서가 비용과 안전성 모두에서 낫다.

5. 권한을 단계별로 연다

처음부터 PR 생성, 배포, Slack 알림까지 열지 않는다. 읽기 전용으로 시작하고, 로컬 파일 수정, 브랜치 push, PR 생성, 외부 알림 순서로 권한을 확장한다.

루프는 성공했을 때보다 실패했을 때 더 위험하다. 권한은 루프의 실패 모드를 보고 천천히 늘리는 편이 맞다.

루프 엔지니어링과 하네스 엔지니어링

앞서 정리한 HarnessX 글과 연결해 보면, 루프 엔지니어링은 하네스 엔지니어링의 실무적 표현에 가깝다.

HarnessX는 프롬프트, 도구, 메모리, 제어 흐름, 평가기를 하네스라는 1급 객체로 만들고 실행 트레이스로 개선하자고 말한다. 루프 엔지니어링은 그 하네스를 실제 업무에서 어떻게 굴릴지에 대한 운영 언어다.

HarnessX의 trace는 루프의 관찰 가능성이다.
HarnessX의 AEGIS는 루프의 자동 개선기다.
HarnessX의 variant isolation은 태스크별 루프 분기와 라우팅이다.
HarnessX의 deterministic gate는 루프의 완료 조건과 회귀 방지 장치다.

결국 같은 방향을 가리킨다. AI 시스템의 레버리지는 모델 호출 한 번이 아니라, 호출 전후의 반복 구조로 이동하고 있다.

주의할 점: 루프는 무지를 가려주지 않는다

PyTorchKR 글의 마지막 경고가 중요하다. 같은 루프를 만든 두 사람이 완전히 다른 결과를 얻을 수 있다.

한 사람은 자신이 깊이 이해하는 작업을 더 빠르게 진행하기 위해 루프를 쓴다. 다른 사람은 작업 자체를 이해하지 않기 위해 루프를 쓴다. 루프는 그 차이를 모른다.

이것이 루프 엔지니어링을 프롬프트 엔지니어링보다 쉽게 만드는 것이 아니라, 오히려 더 어렵게 만드는 이유다. 좋은 루프를 만들려면 작업의 성공 기준을 알아야 하고, 실패 모드를 예측해야 하며, 검증기를 설계해야 한다. 도메인을 모르면 좋은 루프도 만들 수 없다.

⚠️

루프는 책임을 제거하지 않는다. 책임의 위치를 “매번 손으로 지시하는 사람”에서 “반복 구조와 검증 기준을 설계하는 사람”으로 옮긴다.

결론: 좋은 프롬프트보다 좋은 루프

프롬프트 엔지니어링은 여전히 중요하다. 하지만 에이전트가 실제 업무의 일부가 될수록, 더 중요한 것은 프롬프트 하나가 아니라 그 프롬프트가 놓이는 반복 구조다.

좋은 루프는 다음을 갖춘다.

명확한 목표
관찰 가능한 상태
검증 가능한 완료 조건
실패 시 반복 전략
maker와 checker의 분리
실행 간 이어지는 메모리
권한과 중단 조건
비용을 통제하는 모델 선택

2026년의 AI 엔지니어링에서 중요한 능력은 “AI에게 더 그럴듯하게 말하는 능력”이 아니라, AI가 스스로 발견하고 실행하고 검증하도록 만드는 시스템을 설계하는 능력에 가까워지고 있다.

하나의 신뢰할 수 있는 루프는 천 개의 멋진 프롬프트보다 가치 있다. 단, 그 루프를 만든 사람이 여전히 엔지니어로 남아 있을 때만 그렇다.

참고 자료

PyTorchKR: 루프 엔지니어링(Loop Engineering) 개념 및 이해를 위한 학습 자료
원문: Loops: What Every AI Engineer Needs to Know in 2026
Anthropic 문서: Claude Code