Loop engineering

Loop engineering은 코딩 agent를 한 번의 프롬프트로 움직이는 대신, 반복 실행·검증·재시도·상태 저장·관찰 가능성을 갖춘 작업 루프로 설계하는 관점입니다. “agent에게 더 좋은 문장을 쓰는 법”이라기보다, agent가 실패하고 다시 시도하고 멈출 수 있는 실행 구조를 만드는 일에 가깝습니다.

iii의 글은 이 유행어를 조금 차갑게 번역합니다. loop engineering이 새 이름으로 부르는 많은 요소는 이미 오래된 소프트웨어 엔지니어링의 문제, 특히 분산 시스템과 작업 큐의 문제라는 것입니다. agent loop는 queue-backed worker처럼 볼 수 있고, memory는 외부 상태 저장소, verifier는 재시도 정책을 가진 소비자, 멈춤 조건은 회로 차단기와 자원 예산, trace는 관찰 가능성 파이프라인으로 볼 수 있습니다.

한 줄로 말하면

Loop engineering은 LLM agent를 프롬프트 묶음이 아니라, 상태와 재시도와 검증을 가진 실행 시스템으로 다루는 설계 방식입니다.

왜 이 말이 나왔나

초기 AI 코딩 경험은 “모델에게 무엇을 어떻게 말할 것인가”에 집중했습니다. 하지만 실제 작업을 오래 돌리면 문제가 달라집니다.

• agent가 중간에 실패했을 때 어디서 다시 시작할 것인가
• 산출물이 기준을 통과하지 못하면 몇 번까지 재시도할 것인가
• verifier가 영원히 불만족하면 어떻게 멈출 것인가
• 긴 작업 상태를 대화창 밖에 어떻게 저장할 것인가
• 여러 sub-agent가 서로의 맥락과 권한을 침범하지 않게 하려면 어떻게 나눌 것인가
• 어떤 도구 호출이 왜 실패했는지 나중에 어떻게 관찰할 것인가

이 질문들은 프롬프트 문장만으로 풀기 어렵습니다. 그래서 “agent가 agent를 다시 호출하는 loop”, “검증 agent가 maker agent를 고치는 loop”, “실행 trace가 다음 설정을 고치는 loop” 같은 구조가 등장합니다.

기존 소프트웨어 엔지니어링으로 번역하면

Loop engineering에서 말하는 주요 요소는 다음처럼 번역할 수 있습니다.

Loop engineering 표현	소프트웨어 엔지니어링 표현
agent loop	작업 큐를 소비하는 worker
memory outside the conversation	외부 상태 저장소 또는 key-value store
verifier loop	검증 consumer와 재시도 정책
scheduled automation	스케줄러 trigger
sub-agent isolation	권한이 제한된 별도 worker/session
trace-based improvement	관찰 가능성 파이프라인
dead work triage	dead-letter queue 또는 triage inbox
loop stopping condition	회로 차단기, timeout, budget, backpressure
connector / tool integration	webhook, idempotent delivery, middleware

이 번역이 중요한 이유는 단순합니다. 새 용어를 쓰면 새 문제처럼 보이지만, 실제 실패 양식은 이미 익숙한 시스템 장애와 비슷합니다. 무한 재시도, 중복 실행, 상태 손실, 권한 경계 붕괴, 관찰 불가능한 실패는 LLM 이전에도 있던 문제입니다.

좋은 loop는 무엇을 갖춰야 하나

1. 외부 상태

대화창 안의 문맥만으로 긴 작업을 버티기 어렵습니다. 작업 진행 상황, 다음 할 일, 검증 결과, 실패 원인을 외부에 저장해야 합니다. 이 지점은 Agent memory consolidation과 연결되지만, memory가 단순 요약으로 바뀌며 불확실성을 잃지 않도록 조심해야 합니다.

2. 멈춤 조건

검증 loop가 “아직 충분하지 않다”고 계속 판단하면 agent는 비용만 쓰고 전진하지 못할 수 있습니다. 그래서 최대 반복 횟수, 시간 제한, 실패 횟수, 사람 검토로 넘기는 조건이 필요합니다. loop engineering에서 가장 위험한 실패는 똑똑하지 않은 답이 아니라, 멈추지 않는 실행입니다.

3. 관찰 가능성과 감사 가능성

agent가 어떤 도구를 호출했고, 어떤 근거로 다음 행동을 골랐고, 어디서 실패했는지 보이지 않으면 개선할 수 없습니다. trace와 log는 단순 운영 편의가 아니라 agent 시스템의 안전장치입니다. 특히 agent가 실제 업무 도구와 연결될수록 AI 시스템의 감사 가능성이 중요해집니다. 나중에 문제가 생겼을 때 어떤 입력, 권한, 승인 절차, tool call이 결과를 만들었는지 추적할 수 있어야 하기 때문입니다.

4. 권한과 격리

sub-agent를 많이 띄운다고 자동으로 안전해지지 않습니다. 각 agent가 어떤 도구를 쓸 수 있는지, 부모 작업의 권한을 어디까지 물려받는지, 동시에 몇 개까지 실행될 수 있는지 제한해야 합니다. “maker와 checker를 나눈다”는 말은 실제 구현에서는 session, permission, queue, budget 설계가 됩니다. Managed agents 관점에서는 이 경계를 brain, hands, session의 분리로 더 명확히 설계합니다. 보안 관점에서는 Agent containment가 이 권한과 실행 경계를 사고가 나도 피해가 번지지 않는 구조로 좁혀 줍니다.

5. 중복 실행 방지

외부 도구와 연결되는 agent는 같은 요청을 두 번 보낼 수 있습니다. 네트워크 재시도나 이벤트 재전달 때문에 같은 작업이 반복될 수 있으므로, idempotency key 같은 중복 방지 장치가 필요합니다. 특히 결제, 주문, 배포, 메시지 전송처럼 부작용이 있는 도구에서는 필수입니다.

왜 투자·산업 관점에서도 중요한가

AI agent 제품을 볼 때 “모델이 얼마나 똑똑한가”만 보면 부족합니다. 실제 기업 환경에서 agent가 쓰이려면 모델 위에 실행 인프라가 필요합니다. 작업 큐, 상태 저장소, 권한 관리, audit trail과 감사 가능성, 관찰 가능성, 비용 제어, 실패 triage가 제품의 품질을 좌우합니다.

그래서 loop engineering은 개발자 유행어인 동시에 산업 구조 신호이기도 합니다. agent 시대의 경쟁력은 모델 호출 API만이 아니라, 그 호출을 안전하고 반복 가능하고 감사 가능한 업무 시스템으로 바꾸는 인프라에서 생길 수 있습니다.

헷갈리지 말아야 할 점

Loop engineering은 프롬프트 엔지니어링을 완전히 대체하는 말이 아닙니다. 좋은 instruction과 좋은 context는 여전히 중요합니다. 다만 생산 환경에서는 프롬프트보다 실행 구조가 더 큰 병목이 될 수 있다는 뜻에 가깝습니다.

또한 loop를 만든다고 agent가 자동으로 믿을 만해지는 것도 아닙니다. 잘못 설계된 loop는 같은 오류를 더 빠르게 반복할 수 있습니다. 특히 verifier가 약하거나, memory가 불확실성을 잃거나, 멈춤 조건이 없으면 구조가 복잡해질수록 위험도 커집니다.

마지막으로 “새로운 agent 패러다임”이라는 표현에 속아 기존 시스템 설계 원칙을 버리면 안 됩니다. 오히려 좋은 loop engineering은 오래된 소프트웨어 엔지니어링 원칙을 agent 실행 환경에 다시 적용하는 일에 가깝습니다.

관련 문서

• Agent memory consolidation
• Agent memory의 epistemic status
• Managed agents
• Agent containment
• AI 시스템의 감사 가능성
• 모델 아키텍처와 Agent Memory의 차이
• AI agent runtime과 AI capex cycle의 차이