AI 에이전트 무한 루프 진단: 반복·시간·비용 중단 조건

같은 오류를 다시 만나는 실행과 자료를 더 찾으며 전진하는 실행은 중단 기준이 다릅니다. 진척 신호와 호출·시간·비용 한도를 함께 두고, 끝날 때 남길 상태와 인계 정보를 정합니다.

에이전트가 같은 검색을 되풀이하거나 같은 오류 뒤에 다시 도구를 호출하면, 한도를 늘리기 전에 실행 경로와 얻은 결과를 대조할 수 있습니다. LangGraph의 단계 한도 오류 설명은 종료 조건에 도달하기 전에 최대 단계 수에 걸리는 경우를 설명하며, 잘못된 순환뿐 아니라 복잡한 정상 그래프도 한도에 도달할 수 있다고 밝힙니다. 단계 한도에 걸렸다면 정상적인 긴 실행인지 잘못된 순환인지 확인할 수 있습니다.

횟수·시간·성과는 서로 다른 종료 신호입니다

완료 조건은 업무 결과로 정합니다. 필요한 항목을 조사했는지, 파일이 실제로 만들어졌는지, 검증 결과가 요구 조건을 만족하는지가 해당합니다. 모델이 ‘완료했습니다’라고 말했거나 프로그램이 정상 종료됐다는 기록만으로는 이 조건을 확인하기 어렵습니다. 결과를 검사할 자료와 확인 절차를 실행 시작 전에 정하면 종료 때 대조할 수 있습니다.

자원 한도는 목표를 아직 달성하지 못했더라도 더 진행할 수 있는 범위를 정합니다. 최대 도구 호출, 전체 경과 시간, 모델·도구 사용 예산처럼 서로 다른 제한을 둘 수 있습니다. 한도에 걸려 끝난 결과에는 미완료 항목이 남을 수 있으므로 업무 완료와 다른 상태로 표시합니다.

진척 없는 반복은 한도에 다다르기 전에도 나타납니다. 새 정보를 얻지 못한 채 표현만 바꿔 검색하거나, 수정하지 않은 입력으로 같은 오류를 반복하는 경우입니다. 이때는 횟수가 남아 있어도 다음 시도에 성공할 근거가 생겼는지 확인할 수 있습니다. 반대로 필수 항목을 하나씩 확인하는 실행은 단계가 많아도 진척을 보일 수 있습니다.

세 신호는 따로 기록합니다. 완료가 확인됐으면 남은 예산을 소진할 이유가 없고, 완료가 확인되지 않았어도 권한 부족이나 허용 범위 밖 작업 때문에 멈출 수 있습니다. 정한 단계 수를 모두 사용했다는 사실을 완료율로 바꾸면 중단된 업무가 성공으로 집계됩니다.

같은 오류·같은 행동·달라지지 않는 결과를 연결합니다

반복을 찾을 때는 호출 문장뿐 아니라 대상과 결과를 함께 봅니다. 도구 이름, 핵심 입력, 접근 대상, 오류 종류, 결과의 식별값을 연결하면 같은 동작이 되풀이되는 구간을 찾을 수 있습니다. 시간값이나 표현의 작은 차이만 달라진 기록을 서로 다른 진척으로 세지 않도록 비교할 항목을 정합니다.

문자열이 같다는 사실만으로 불필요한 반복이 되지는 않습니다. 외부 작업의 처리 상태를 간격을 두고 확인하는 대기는 같은 조회를 반복할 수 있습니다. 이 경우에는 기다릴 이유, 재조회 시각, 전체 대기 기한이 정해져 있는지 확인합니다. 기한 없이 같은 상태를 조회하는 실행과 완료를 기다리는 유한한 대기를 나눌 수 있습니다.

서로 다른 문장을 만들어도 같은 결론을 오가면 진척이 없을 수 있습니다. 검색어가 달라졌어도 이미 읽은 자료만 다시 나오거나, 수정과 검증이 같은 결함을 없애지 못한 채 반복되는 경우입니다. 새 근거의 추가, 필수 항목의 해결, 오류 원인 제거처럼 업무에 맞는 변화량을 정하면 이 반복을 살필 수 있습니다.

다음 시도에는 바뀐 조건을 적습니다. 새 자료에 접근하게 됐는지, 잘못된 입력을 고쳤는지, 일시 오류의 대기 시간이 지났는지가 그 근거가 됩니다. 아무 조건도 달라지지 않았고 유효한 대안도 없다면 같은 행동을 다시 보내는 대신 미해결 이유를 남겨 인계하는 판단을 할 수 있습니다.

재시도 횟수와 전체 실행 한도를 함께 둡니다

도구가 오류를 돌려줬을 때는 오류 종류에 맞춰 재시도를 정합니다. 아마존의 Step Functions 오류 처리 문서는 Retry에서 오류를 고르고, MaxAttempts로 재시도 횟수, IntervalSeconds와 BackoffRate로 대기 간격을 정하는 방식을 설명합니다. 같은 문서의 Catch는 처리할 오류를 다른 상태로 보내는 경로를 제공합니다.

이 방식에서 가져올 원리는 오류별로 허용한 다음 행동이 다르다는 점입니다. 일시적인 연결 문제에는 대기 후 재시도를 둘 수 있지만, 접근 권한이 없거나 필수 입력이 틀렸다면 조건을 바꾸는 조치가 필요합니다. 상위 에이전트가 ‘다시 시도한다’고 판단할 때도 하위 도구가 이미 수행한 시도와 대기를 포함해 실제 실행량을 셉니다.

개별 도구의 제한과 전체 작업의 제한을 분리합니다. 도구 호출이 끝나지 않으면 다음 단계의 횟수 검사까지 도달하지 못할 수 있어 도구별 시간 제한이 필요합니다. 전체 작업 기한은 정상 응답이 계속 돌아오더라도 너무 오래 탐색하는 실행을 멈추는 기준입니다. 상태 확인을 위해 기다린 시간과 사람의 승인을 기다린 시간도 어떤 기한에 포함할지 정합니다.

분업하는 실행에서는 하위 에이전트의 사용량도 전체 작업에 연결합니다. 작업자마다 각각 한도를 지켜도 합계가 전체 예산을 넘을 수 있습니다. 새 하위 작업을 만들기 전에 남은 범위와 예산을 확인하고, 전체 중단 신호가 전달됐을 때 새 호출이 더 생기지 않는지 살펴볼 수 있습니다.

비용 한도는 보고된 사용량과 아직 끝나지 않은 호출을 함께 고려합니다. 완료된 사용량만 더하면 동시에 진행 중인 호출 비용은 뒤늦게 반영될 수 있습니다. 다음 호출의 예상 사용량을 보수적으로 잡고 결과 확인에 필요한 여유도 남기는 방식으로 설계할 수 있습니다. 추정 비용과 실제 청구 금액은 구분해 기록합니다.

이 제한은 모델 밖 실행 제어에서 검사합니다. 프롬프트에 정한 횟수만 적는 것과 실제 도구 요청을 보내기 전에 카운터·기한·권한을 검사해 차단하는 것은 강제력이 다릅니다. 단계 수만으로 모델 호출 수나 사용 금액을 알 수 없으므로, 쓰는 실행 도구가 무엇을 한 단계로 세는지도 확인 대상입니다.

실패 유형에 따라 중단·대기·인계를 나눕니다

다음 표는 업무 기록용 상태 이름을 붙인 가상 판단표입니다. 실제 서비스 장애의 재현 결과나 보편적인 재시도 횟수·금액 기준을 제시하지 않습니다.

관찰한 상황	계속할 수 있는 조건	멈추거나 전환할 기준	기록 상태
같은 입력에서 같은 오류 반복	입력·환경을 고친 근거가 있음	바뀐 조건도 허용 대안도 없음	인계: handoff
외부 처리 상태가 아직 대기	다음 조회 시각과 대기 기한이 남음	정한 대기 기한 도달	대기: waiting → 중단: stopped
필수 도구가 일시 실패	오류별 재시도와 전체 한도 안에 있음	필수 단계 실패 후 허용 경로 소진	실패: failed
권한이나 요청 범위가 불명확	담당자가 범위를 확인함	확인 없이 새 실행이 필요함	인계: handoff
전체 시간·횟수·예산 한도 도달	새 승인·배정으로 재개 조건이 바뀜	기존 한도 안에서는 더 실행 불가	중단: stopped
외부 변경 결과를 모름	조회로 실제 상태를 대조함	중복 변경 가능성을 배제 못 함	확인을 위한 인계: handoff
목표와 검증 조건을 모두 충족	추가 실행 필요 없음	완료 근거를 보존함	완료: completed

완료는 목표 조건을 확인한 상태이고, 중단은 한도나 취소 등으로 실행을 끝낸 상태로 둡니다. 실패는 필요한 단계를 마치지 못하고 허용한 처리 경로를 소진한 상태입니다. 인계는 다음 판단을 담당자에게 넘긴 상태이며, 대기는 정한 조건이나 시각까지 새 행동을 보류한 상태로 구분합니다.

중단 뒤 인계할 수도 있으므로 종료 상태와 종료 이유를 별도 값으로 남길 수 있습니다. 상태가 인계라면 누가 무엇을 결정해야 하는지, 이유가 예산 소진이라면 사용량과 미완료 범위가 무엇인지 함께 적습니다. 담당자·기한·다음 판단이 없는 인계 문구만 남기면 작업이 어디서 멈췄는지 다시 조사하게 됩니다.

이미 외부 변경이 일어났는지 알 수 없는 경우는 새 변경을 멈추고 확인으로 전환합니다. 저장 상태 대조와 중복 실행을 피하는 재개 방법은 저장 뒤 멈춘 AI 자동화의 재개 기준에서 이어 볼 수 있습니다. 실행 중 중단 판단과 중단 후 재개 절차를 별도로 두면 같은 작업을 처음부터 반복할지 결정하는 오류를 줄일 수 있습니다.

멈춘 뒤에는 다음 판단에 필요한 정보를 남깁니다

인계 기록에는 원래 목표와 허용 범위, 실제 완료한 부분, 남은 부분, 마지막으로 확인한 관찰, 실행한 시도, 멈춘 이유를 남깁니다. 가상 조사 업무라면 ‘문서 조사 중’보다 ‘필수 항목 가운데 보관 지역의 근거를 찾지 못했고, 접근 가능한 공식 문서는 모두 같은 비공개 안내로 연결됐다’가 다음 행동을 고르기 쉽습니다. 실제 조사 결과가 아닌 기록 방식의 비교 예시입니다.

이어서 다음에 허용할 행동과 재개 조건을 적습니다. 담당자가 자료 접근권을 제공하면 이어갈 수 있는지, 요청 범위를 줄여야 하는지, 외부 상태를 확인한 뒤에만 변경할 수 있는지를 구분합니다. ‘시간이 더 필요하다’는 설명만으로 새 실행을 시작하면 같은 장애를 다시 만날 수 있습니다.

한도 값은 일반 사례의 실행량만 보고 정하지 않습니다. 예외를 해결하는 데 필요한 정상 경로와 검증 구간을 포함하고, 일부러 종료 조건에 도달하지 못하는 입력도 제한된 시험에 넣어 볼 수 있습니다. 이때 시험의 목표는 필요한 작업을 마칠 기회와 무의미한 실행을 끊는 경계를 확인하는 것입니다.

처음에는 실행 제어에 명시적인 한도를 두고, 한도 도달 사례를 진척 있음·진척 없음·확인 필요로 분류해 조정하는 편이 좋습니다. 진척이 확인되는 긴 작업에는 필요한 범위를 다시 배정할 수 있고, 조건이 바뀌지 않은 실패에는 같은 실행을 추가하지 않을 근거가 생깁니다. 조정 뒤에도 완료 검사와 중단 사유를 따로 남기면 한도를 늘려 숨겨진 실패를 성공으로 바꾸는 일을 피할 수 있습니다.

자료 확인 기준: 2026년 10월 28일 UTC. 구현별 단계 계산·재시도·사용량 보고 방식은 적용 버전에서 확인합니다.

블로그AI 에이전트