Loop Engineering은 에이전트 런타임의 설계 단위다

LLM 에이전트를 운영할 때 실패하는 지점은 대개 모델 호출 하나가 아니다. 실패는 루프의 경계가 흐릴 때 생긴다. 무엇을 관측했는지, 어떤 상태에서 다음 행동을 골랐는지, 실행 결과를 어떻게 검증했는지, 실패 시 어디로 되돌아가는지가 코드와 로그에 남지 않으면 에이전트는 디버깅할 수 없는 자동화가 된다.

프롬프트가 아니라 상태 전이가 운영 단위다

단발 프롬프트는 입력과 출력만 가진다. 운영 가능한 에이전트는 반복 가능한 상태 전이를 가진다.

flowchart TD
  observed[Observed] --> planned[Planned]
  planned --> executed[Executed]
  executed --> verified[Verified]
  verified --> done[Done]
  verified --> retry[Retry]
  verified --> escalate[Escalate]
  verified --> stop[Stop]
  retry --> planned

이 구조가 명시돼야 비용, 지연, 실패율, 검증 누락을 측정할 수 있다. 그래서 loop engineering의 핵심은 “더 긴 프롬프트”가 아니라 반복 가능한 제어 구조다. 모델은 다음 행동을 제안할 수 있지만, 루프는 언제 실행하고 언제 멈출지를 결정해야 한다.

좋은 루프에는 중단 조건이 있다

자동화는 계속 돌 수 있다는 점 때문에 위험하다. 좋은 루프는 다음 조건을 코드로 가진다.

• 성공 판정: 산출물이 어떤 테스트나 관측값을 만족해야 하는가.
• 실패 판정: 어떤 오류는 재시도하지 않고 즉시 중단해야 하는가.
• 예산: 토큰, 시간, 도구 호출 수, 외부 API 비용의 상한은 얼마인가.
• 변화 감지: 같은 수정이 반복되거나 diff가 더 좋아지지 않을 때 멈추는가.
• 승인 경계: 파일 삭제, 배포, 결제, 권한 변경처럼 사람이 봐야 하는 작업은 무엇인가.

이 조건이 없으면 에이전트는 “열심히 일하는 것처럼 보이는” 무한 재시도 장치가 된다. 특히 자기 결과를 자기 기준으로만 통과시키는 루프는 실패를 학습하는 것이 아니라 실패를 반복한다.

검증 루프는 실행 증거를 요구한다

루프의 품질은 마지막 답변이 아니라 검증 방식에서 갈린다. 코드 수정 에이전트라면 “수정했다”가 아니라 빌드, 테스트, 브라우저 조작, 로그 확인 같은 실행 증거를 남겨야 한다. 문서 작성 에이전트라면 원문 요약을 복사하지 않았는지, 주장과 근거가 분리되어 있는지, 독자가 적용할 기준이 있는지 확인해야 한다.

실무에서는 maker와 checker를 분리하는 편이 안전하다.

maker: 초안 작성 또는 코드 수정
checker: 독립 검증, 실패 사례 탐색, 공개 품질 점검
director: 목표, 예산, 중단 조건, 승인 경계 관리

한 모델이 세 역할을 모두 맡을 수는 있지만, 역할을 코드와 로그에서 분리해야 나중에 실패 원인을 추적할 수 있다.

반복 작업은 바깥 루프와 안쪽 루프를 나눈다

주기적으로 들어오는 작업은 바깥 루프가 발견한다. 개별 작업의 완료 여부는 안쪽 루프가 판단한다. 예를 들어 매시간 새 이슈를 확인하는 자동화라면 바깥 루프는 “작업을 찾는 일”을 맡고, 안쪽 루프는 “이번 이슈가 재현되고 수정되고 검증됐는가”를 맡는다.

이 둘을 섞으면 문제가 생긴다. 작업이 없는데도 계속 수정하거나, 작업 하나가 실패했는데 전체 루틴이 멈추거나, 실패한 검증 기준이 다음 실행에 반영되지 않는다. 장기 운영 루프는 매 실행에서 배운 실패를 프롬프트, 도구, 테스트, 체크리스트 중 하나에 반영해야 한다.

결론

에이전트 시스템의 최소 운영 단위는 모델 호출이 아니라 루프다. 루프를 명시하면 실패를 재현할 수 있고, 검증을 자동화할 수 있고, 사람이 개입해야 하는 경계를 코드로 남길 수 있다. 좋은 루프는 더 오래 도는 루프가 아니라, 성공·실패·중단을 더 분명하게 판단하는 루프다.