프로덕션 시스템을 망가뜨리는 6가지 AI 에이전트 루프 장애 모드

자동 도구 호출 실패: 에이전트가 아무것도 하지 않으면서 "성공"할 때

도구 호출이 빈 문자열이나 부드러운 "결과 없음" 메시지를 반환하면, 모델은 이를 유효한 결과로 해석하고 에이전트는 마치 단계가 성공한 것처럼 계속 진행하며, 실제로는 아무것도 하지 않으면서 성공하는 것처럼 보입니다. 수정은 모든 도구 반환에 대한 검증 게이트입니다: 모델이 보기 전에 출력을 스키마 검사 또는 유효성 검사하고, 빈 성공 대신 루프가 처리해야 할 실제 실패를 표시합니다.

이것은 아무것도 충돌하지 않기 때문에 교묘합니다. 프로덕션 에이전트의 자동 실패 모드를 설명하는 개발자 는 이를 직접적으로 표현했습니다: 모델은 일반적인 빈 문자열을 유효한 무작위로 해석하고 실패를 인식하지 못한 채 실행을 계속합니다. 연결이 끊겨서 행이 없이 반환된 데이터베이스 쿼리는 모델 입장에서 정상적으로 아무것도 찾지 못한 쿼리와 동일하게 보입니다. 그래서 에이전트는 "일치하는 레코드 없음"을 보고하고 넘어가며, 일주일 후에야 실행의 3분의 1이 조용히 깨져 있었다는 것을 알게 됩니다.

검증 게이트는 도구와 모델 사이에 위치합니다:

def gate_tool_result(tool_name: str, result):
    # Reject empties and soft errors before the model can rationalize them
    if result is None or (isinstance(result, str) and not result.strip()):
        raise ToolFailure(f"{tool_name} returned empty -- treat as failure, not no-op")
    if isinstance(result, str) and result.lower().startswith(("error", "exception")):
        raise ToolFailure(f"{tool_name} returned a soft error: {result[:120]}")
    return result  # validated -- safe to hand back to the model

요점은 정확한 검사가 아닙니다. 어떤 검사를 할지는 각 도구가 정상적으로 반환하는 것에 따라 다릅니다. 요점은 검증되지 않은 반환 값이 확률적 모델에 결정을 넘긴 것이며, 모델의 기본 동작은 계속 진행하는 것입니다.

검증되지 않은 도구 반환은 자동 실패가 기다리고 있는 것입니다. 호출을 신뢰하지 말고 출력을 검증하세요.

긴 컨텍스트에서의 추론 품질 저하: 에이전트가 오래 실행할수록 나빠질 때

하드 컨텍스트 한계 이하에 있더라도 컨텍스트가 늘어날수록 추론 품질이 저하됩니다. 이것이 "중간에서 길을 잃는" 효과로, 모델이 긴 컨텍스트의 시작과 끝에는 안정적으로 주의를 기울이지만 중간을 잃어버립니다. 수정은 고정 제약을 보존하는 루프 중간 압축입니다: 노이즈를 압축하고 핵심 지침을 보호합니다.

메커니즘에는 이름이 있습니다. Anthropic의 엔지니어링 블로그는 이를 컨텍스트 부패: "컨텍스트 창의 토큰 수가 증가함에 따라, 모델이 해당 컨텍스트에서 정보를 정확하게 회상하는 능력이 감소합니다." 왜냐하면 "모든 토큰이 다른 모든 토큰에 주의를 기울이기 때문에," n개의 토큰에 대해 n² 쌍별 관계가 생기고, 컨텍스트가 길어질수록 모델의 주의가 더 분산됩니다.

그 한정어, 핵심 지침 보호, 가 전체 핵심이며, 이것이 왜 중요한지를 보여주는 문서화된 사례가 있습니다. 한 보고된 사례, OpenClaw 에이전트가 컨텍스트 압축 중에 사용자의 받은 편지함을 대량 삭제했는데, 이는 주어진 안전 지침("내가 말할 때까지 조치를 취하지 마세요")이 히스토리가 압축될 때 활성 컨텍스트에서 제거되었기 때문입니다. 마지막까지 남아 있어야 할 제약이 일반 히스토리로 취급되어 요약되어 버린 것입니다.

따라서 순진한 "N 턴보다 오래된 모든 것을 요약" 방식은 위험합니다. 압축은 절대 삭제하면 안 되는 것이 무엇인지 알아야 합니다:

PINNED = {"system_constraints", "safety_instructions", "active_task_spec"}

def compress_history(messages):
    pinned = [m for m in messages if m.tag in PINNED]      # never summarized
    transient = [m for m in messages if m.tag not in PINNED]
    summary = summarize(transient)                          # lossy is fine here
    return pinned + [summary]                               # constraints survive intact

이것은 이전 섹션의 오버플로우 문제와 다릅니다. 오버플로우는 공간이 부족한 것이고, 품질 저하는 공간이 아직 남아 있는데 모델이 나빠지는 것입니다. 창의 60%에 있으면서도 이미 추론이 나빠질 수 있습니다.

재시작 시 상태 손실: 충돌이 처음부터 다시 시작을 의미할 때

재부팅, OOM 킬, 네트워크 연결 끊김 등으로 오래 실행되는 에이전트가 충돌할 때, 기본적으로 체크포인트에서 재개하는 기능이 없습니다. 루프는 처음부터 다시 시작합니다: 이미 완료한 작업을 다시 하고, 더 나쁜 경우 이미 수행한 작업(같은 이메일을 두 번 보내거나 유료 API 호출을 다시 실행하는 것)을 재실행할 수 있습니다. 수정은 체크포인팅입니다: 각 단계 후 루프 상태를 저장하여 재시작 시 처음부터 시작하는 대신 멈춘 곳에서 재수화합니다.

LangGraph에서 체크포인트 백엔드 선택은 개발과 프로덕션 사이의 선택입니다. LangGraph의 지속성 문서 설명에 따르면 SqliteSaver SQLite는 "실험 및 로컬 워크플로우에 이상적"이고 PostgresSaver Postgres는 "프로덕션에 이상적"이며, 후자는 LangSmith 자체가 실행되는 것입니다. 두 가지는 코드에서 의도적으로 병렬이므로 비교하기 쉽습니다:

# Development -- single file, no server, do not ship this
from langgraph.checkpoint.sqlite import SqliteSaver

# Production -- survives the box it runs on
from langgraph.checkpoint.postgres import PostgresSaver

사람들이 실수하는 두 가지 세부 사항이 있습니다. 첫째, 체크포인트 패키지는 핵심 LangGraph와 별도로 설치됩니다(langgraph-checkpoint-sqlite 및 langgraph-checkpoint-postgres 는 자체 의존성), 따라서 새 서버에는 패키지를 추가하기 전까지 Postgres 세이버가 없습니다. 둘째, 모든 체크포인트 작업에는 config에 thread_id가 필요합니다. thread_id 그 ID가 주어진 실행을 저장된 상태와 연결하며, 올바른 thread_id 없이 재시작하면 thread_id 아무것도 재수화되지 않습니다.

재시도 폭풍: 자체 에이전트가 다운된 서비스를 DDoS할 때

다운스트림 서비스가 다운되면, 단순한 실행별 재시도가 에이전트 플릿을 자해적 서비스 거부 공격으로 만들어버립니다. 수정은 두 부분으로 이루어집니다: 각 에이전트에 지터가 있는 지수 백오프를 적용해 재시도를 시간적으로 분산시키고, 공유 실패 임계값 이후 작동하여 명확히 다운된 서비스를 전체 무리가 공격하지 못하도록 막는 글로벌 서킷 브레이커를 추가합니다.

수학은 가혹합니다. 한 재시도 패턴 글 에서 설명하듯, 각각 열 번씩 재시도하는 열 개의 병렬 에이전트는 이미 쓰러진 서비스에 백 개의 요청을 보냅니다. 각 에이전트의 백오프가 실행별이지 글로벌이 아니기 때문입니다. 에이전트별 백오프만으로는 이 문제를 해결하지 못합니다. 각각이 정중하게 백오프하는 열 개의 에이전트도 모두 같은 시간에 시작했다면 동시에 백오프하므로, 동기화된 파도로 재시도합니다. 지터는 각 에이전트의 대기 시간을 무작위화하여 동기화를 깨뜨리고, 서킷 브레이커는 모든 에이전트에 걸쳐 하나의 실패 상태를 공유하여 무리를 억제합니다.

백오프 부분은 Python에서 해결된 문제입니다. tenacity tenacity 라이브러리가 지터가 있는 지수 방식을 깔끔하게 처리합니다:

from tenacity import retry, stop_after_attempt, wait_random_exponential

@retry(wait=wait_random_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_flaky_service(payload):
    return downstream.post(payload)

서킷 브레이커는 글로벌이어야 하는 부분입니다: 실행별로 재인스턴스화되는 것이 아니라 모든 에이전트에 걸쳐 공유되어야 합니다. 실패가 임계값을 초과하면 열리고, 모든 에이전트가 호출하는 대신 빠르게 실패하며, 쿨다운 후 서비스가 복구되었는지 테스트하기 위해 단일 프로브를 통과시킵니다. 각 에이전트의 자체 프로세스 내에 있는 브레이커는 아무것도 보호하지 않습니다. 공유되는 것이 없기 때문입니다. 다운된 서비스는 여전히 백 개의 요청을 모두 받게 됩니다.

실행별 백오프는 열 개의 에이전트가 다운된 서비스를 동시에 공격하는 것을 허용합니다. 서킷 브레이커는 무리를 멈추기 위해 글로벌이어야 합니다.

한눈에 보는 여섯 가지 실패

인프라 부분 이전에, 전체 목록을 한곳에 정리합니다: 실패 유형, 원인 메커니즘, 하네스 수정 방법, 그리고 각 프레임워크에서 관련 파라미터가 위치하는 곳입니다.

CrewAI, AutoGen, Dify, 또는 직접 만든 Python 루프를 사용하는 독자에게 한마디: 프레임워크 파라미터는 바뀌지만 여섯 가지 패턴은 바뀌지 않습니다. 중복 제거, 간격 요약, 스키마 검증, 제약 인식 압축, 체크포인팅, 글로벌 서킷 브레이커는 프레임워크에 독립적인 개념입니다. 여기의 LangGraph와 n8n 구체적인 내용은 구체적인 참고점이지, 패턴이 적용되는 범위의 경계가 아닙니다.

프로덕션 에이전트 배포 규모 결정

위의 모든 패턴은 프로세스 관리자, 데이터베이스, 재시작 동작을 직접 제어한다고 가정합니다. 충돌한 루프가 절대 다시 올라오지 않는다면 체크포인팅은 아무 소용이 없고, 글로벌 서킷 브레이커는 공유 상태를 유지할 장소가 필요합니다. 그 제어권이 바로 자체 호스팅이 주는 것이고 관리형 블랙박스가 주지 않는 것입니다. 그래서 마지막 결정은 24/7로 실행할 서버 규모를 결정하는 것입니다.

대부분의 단일 에이전트 배포(에이전트 하나, LLM 호출이 외부 API로 나가고, 기본 Postgres 체크포인팅)에는 소형 인스턴스로 충분합니다: 약 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. 무거운 컴퓨팅은 모델 제공자 측에 있습니다. 여러분의 서버는 오케스트레이션, 체크포인팅, 상태 보관을 하는 것이지 추론을 실행하는 것이 아닙니다. 단계가 많고 Postgres 체크포인팅에 Redis 세션 재수화가 추가된 상태 저장형 에이전트이거나, 호스트를 공유하는 동시 워크플로우를 실행할 때는 약 4 GB RAM, 2 vCPU, and 120 GB NVMe 로 업그레이드하세요.

이것이 제한된 플랫폼보다 직접 관리하는 VPS를 원하는 이유는 수정 방법이 애초에 작동하는 이유와 같습니다: root가 필요합니다. 체크포인팅을 위한 자체 Postgres, 세션 상태를 위한 자체 Redis, 그리고 루프가 죽으면 감독자가 재시작하고 처음부터 작업을 시작하는 대신 마지막 체크포인트에서 재수화되도록 하는 systemd 같은 실제 프로세스 관리자가 필요합니다. systemd or pm2, 루프가 죽으면 감독자가 재시작하고 처음부터 작업을 시작하는 대신 마지막 체크포인트에서 재수화되도록 합니다. 전체 복구 스토리는 프로세스 생명주기를 소유하는 것에 달려 있습니다.

저희가 자체 마켓플레이스에서 n8n을 원클릭 앱으로 운영하기 때문에, 그 부분의 설정은 저희 쪽에서 가장 빠른 경로입니다: Cloudzy VPS에 n8n 배포 하면 프로덕션 경로에 필요한 Postgres 기반 구성으로, 자체 Redis와 프로세스 감독을 추가할 root 액세스가 있는 인스턴스에서 실행됩니다. 이것은 위에서 설명한 동일한 자체 호스팅 환경입니다. 데이터베이스와 재시작 동작을 소유하고, 그것이 체크포인팅과 자동 복구가 실제로 작동하게 만드는 것입니다.

하네스 패턴은 실행되는 서버만큼만 신뢰할 수 있습니다. 프로세스가 절대 재시작되지 않는다면 체크포인팅은 아무 소용이 없습니다.

자주 묻는 질문