AI 에이전트 무한 루프 방지: 비용·단계·행동을 런타임에서 제한하는 법

에이전트가 같은 검색을 반복하거나 실패한 도구 호출을 다시 시도할 때, 문제는 모델이 말을 잘 듣지 않는 데서 끝나지 않는다. 호출 수가 늘고 컨텍스트가 길어지며, 비용과 외부 시스템에 가하는 부하도 같이 커진다. 나는 8월 2일 Hacker News 새 글 목록에서 발견한 SteerPlane의 ‘결정론적 런타임 가드레일’ 제안을, 특정 도구의 홍보보다 더 기본적인 운영 신호로 읽는다. 에이전트의 안전은 “필요하면 멈춰”라는 프롬프트에 있지 않다. 각 실행 단계에서 비용·반복·권한을 측정하고, 기준을 넘으면 모델의 다음 문장을 기다리지 않고 중단하는 경계에 있다. 작은 팀도 단계 상한, 비용 상한, 금지 행동 세 가지만 분리해 두면 무한 루프의 폭발 반경을 크게 줄일 수 있다.

무한 루프는 오류 메시지보다 먼저 비용 그래프로 나타난다

에이전트 루프는 보통 while True 같은 명시적 버그로 시작하지 않는다. 검색 결과가 부족하다고 판단해 같은 검색어를 조금 바꿔 반복하거나, 권한 오류가 난 API를 다른 형식으로 재호출하거나, 하위 에이전트가 서로에게 보완 작업을 넘기면서 같은 목표를 되풀이하는 식이다. 개별 호출은 그럴듯해서 일반적인 성공·실패 모니터링만으로는 늦게 발견하기 쉽다.

SteerPlane README는 단일 행동 반복, 번갈아 나타나는 행동, 여러 단계 패턴을 슬라이딩 윈도로 감지하고 비용 상한과 단계 상한을 매 단계 확인하는 방식을 제시한다. 이 구현의 성능 수치나 제품 범위를 일반화할 이유는 없다. 다만 ‘루프를 모델의 자가 반성에 맡기지 않고 관측 가능한 실행 이벤트에서 판단한다’는 설계 원칙은 유효하다. 특히 비용 한도를 호출 전에만 검사하면 스트리밍이나 재시도로 예산을 넘길 수 있다. 호출 직후에도 누적 비용을 다시 확인하고, 상한을 넘었을 때 종료·대기·승인 중 무엇을 할지 미리 정해야 한다.

제한은 세 종류로 분리해야 한다

한 개의 ‘안전 모드’ 토글은 운영 중 원인을 설명하지 못한다. 제한을 아래 세 종류로 나누면 알림, 승인, 복구의 책임이 선명해진다.

1. 단계 제한: 작업 하나가 실행할 수 있는 도구 호출 또는 추론 단계를 정한다. 예를 들어 요약 작업이 30단계를 넘으면 품질 문제가 아니라 계획·입력·도구 실패를 먼저 의심해야 한다.
2. 비용 제한: 모델 가격표가 아니라 실제 실행 단위의 누적 비용으로 판정한다. 호출당 최대 비용과 실행 전체 예산을 함께 두고, 초과 시 다음 호출을 막는다.
3. 행동 제한: delete, 결제, 외부 발송, 권한 변경처럼 되돌리기 어렵거나 영향이 큰 행동은 명시적 허용 목록을 통과해야 한다. 비용이 낮다고 위험도 낮은 행동은 아니다.

LangChain의 가드레일 문서도 실행 전·후의 커스텀 가드레일, PII 탐지, human-in-the-loop을 분리해서 다룬다. 핵심은 한 가지 검사로 모든 위험을 판정하지 않는다는 점이다. 예산 초과는 자동 종료할 수 있지만, 외부 발송은 사람 승인으로 보낼 수 있고, 민감 데이터 탐지는 출력을 마스킹할 수 있다. 실패 유형에 따라 대응을 달리해야 안전 장치가 업무를 전부 멈추는 장애물로 변하지 않는다.

작은 팀을 위한 최소 실행 계약

아래는 특정 프레임워크 설정 파일이 아닌, 실제 구현 전에 팀이 합의할 수 있는 최소 계약이다. 숫자는 서비스의 정상 실행 기록을 보고 조정해야 하며, 처음부터 넉넉하게 잡아 무력화하지 않는 편이 좋다.

agent_runtime_policy:
  max_steps: 30
  max_cost_usd: 2.00
  loop_window: 6
  repeat_threshold: 3
  deny_actions: ["delete_*", "send_*", "payment_*"]
  on_budget_exceeded: "stop_and_record"
  on_loop_detected: "stop_and_record"
  on_denied_action: "require_human_approval"

이 계약에서 중요한 것은 값 자체보다 로그다. 중단 이벤트에는 실행 ID, 마지막 행동, 누적 단계·비용, 어떤 규칙이 작동했는지, 재개 권한자가 누구인지 남겨야 한다. 단, 프롬프트 원문, 인증 헤더, 개인 데이터는 넣지 않는다. 그래야 “에이전트가 실패했다”라는 알림이 run=...; rule=repeat_threshold; action=web_search; steps=18처럼 재현 가능한 운영 단서가 된다.

내 의견: 가드레일의 목표는 똑똑한 중단이 아니라 예측 가능한 손실 상한이다

내 의견은 분명하다. 루프 감지와 비용 제한은 에이전트를 더 지능적으로 만드는 기능이 아니라, 실패했을 때 잃을 수 있는 시간·돈·권한의 최대치를 정하는 운영 장치다. 가벼운 반론도 있다. 단계 상한이 낮으면 긴 조사나 복잡한 구현을 성급하게 끊을 수 있다. 맞다. 그래서 모든 작업에 같은 숫자를 강요하면 안 된다. 그러나 상한이 전혀 없는 장기 실행은 성과가 아니라 무제한 책임을 자동화하는 일이다. 작업 등급별 예산을 두고, 초과 작업은 더 큰 한도를 자동으로 받는 대신 사람의 승인과 새 실행 ID를 받게 하는 편이 낫다.

김덕환 운영자 관점

김덕환 운영자 관점에서 에이전트 자동화의 첫 배포 기준은 “성공률이 높은가”만이 아니다. 실패했을 때 어디에서 멈추고, 얼마를 쓰며, 어떤 행동이 끝내 사람에게 남는지 설명할 수 있어야 한다. 다음 자동화 하나에 먼저 max_steps, max_cost, deny_actions 세 필드를 붙여 보자. 이 작은 계약이 있어야 모델·도구가 바뀌어도 에이전트의 실패 비용은 운영자가 감당할 수 있는 범위 안에 남는다.

참고 자료

• SteerPlane GitHub README — 비용 상한, 단계 제한, 루프 감지, 정책 엔진
• Hacker News — Show HN: SteerPlane, 2026-08-01 게시
• LangChain Docs — Guardrails: 실행 전·후 가드레일과 human-in-the-loop