무한 재시도 함정: 루프가 끝나지 않을 때

AI 도구 사용(tool-use) 파이프라인에서 가장 흔하면서도 교활한 실패 모드 중 하나는 무한 재시도 함정(infinite retry trap)입니다. 이는 에이전트가 중단 조건(stop conditions)이 누락되었거나 결함이 있어 종료되지 않는 루프에 진입할 때 발생합니다. 에이전트는 작업이 완료되었을 때나 추가 시도가 무의미할 때를 인식하는 대신, 동일한 행동이나 시퀀스를 끝없이 반복합니다. 이는 자원 고갈, 비용 증가, 시스템 신뢰성 저하로 이어질 수 있습니다.

이 문제의 핵심 메커니즘은 루프 로직 내에 명시적인 종료 기준(termination criteria)이 부족하다는 점입니다. 에이전트는 일반적으로 작업을 수행하는 방법은 배우지만, 언제 포기해야 하는지는 배우지 못합니다. 명확한 중단 규칙이 없으면, 에이전트는 모든 실패를 중단 신호가 아닌 일시적인 차질로 해석할 수 있습니다. 이는 에이전트의 피드백 루프가 불확실하거나 불완전한 신호에 기반하는 환경에서 특히 문제가 되며, 이로 인해 에이전트가 진행 상황이나 추가 재시도의 필요성을 잘못 판단할 수 있습니다.

구체적인 예로 외부 API로부터 정보를 가져오려는 AI 시스템을 들 수 있습니다. 만약 API가 에러를 반환하거나 타임아웃(timeout)이 발생하면, 에이전트는 제한 없이 자동으로 재시도할 수 있습니다. 시간이 지나면서 이는 시스템의 응답 불능이나 과도한 토큰 소비로 이어질 수 있습니다. 예를 들어, Leviathan 시나리오에서 에이전트는 데이터 소스를 사용할 수 없거나 추가 시도가 무의미하다는 것을 인식하지 못한 채 반복적으로 데이터 업데이트를 요청할 수 있습니다. 이러한 패턴은 에이전트가 모든 실패를 중단 신호가 아닌 일시적인 문제로 취급하려는 경향 때문에 더욱 악화되는 경우가 많습니다.

Fiddler AI Blog에 따르면, AI 에이전트는 실제 환경에서 70%에서 95%의 확률로 실패합니다. 이러한 높은 실패율은 끝없는 루프를 방지하기 위한 강력한 종료 로직(termination logic)의 중요성을 강조합니다.

실패 모드(Failure modes)는 반응이 없거나 멈춰버린 에이전트의 형태로 가시적으로 나타나며, 로그에는 진전 없이 반복되는 시도들이 기록됩니다. 실제로 이러한 루프는 시스템 충돌, 운영 비용 증가, 사용자 경험 저하를 초래할 수 있습니다. 이러한 함정을 탐지하려면 비정상적으로 높은 재시도 횟수나 시간이 경과함에 따라 진전이 없는 상태를 모니터링해야 합니다.

타임아웃(timeout) 메커니즘에만 의존하는 방식과 비교했을 때, 명시적인 중단 조건(explicit stop conditions)은 도메인 지식과 문맥적 신호(contextual signals)를 통합하기 때문에 더 신뢰할 수 있습니다. 타임아웃 기반 방식은 타임아웃 설정이 너무 길거나 짧을 경우 여전히 실패할 수 있는 반면, 잘 설계된 중단 기준은 작업의 성격에 맞춰 적응합니다.

끝없는 재시도의 비용이 지속성(persistence)의 이점보다 커지는 경우, 명확한 종료 조건을 구현하기로 선택하는 것은 매우 중요합니다. 이 전략은 자원 제약과 시스템 안정성이 최우선인 프로덕션 환경(production environments)에서 특히 유효합니다. 명시적인 종료 기준을 갖춘 적절히 설계된 루프는 AI 시스템이 다양한 조건에서도 회복 탄력성(resilient)과 예측 가능성(predictable)을 유지할 수 있도록 돕습니다.

스키마 오류 연쇄(Schema-Error Cascades): 잘못된 데이터의 전파

도구가 잘못된 형식(malformed)이거나 예상치 못한 데이터를 반환할 때, 해당 데이터를 소비하는 다운스트림 로직(downstream logic)은 종종 데이터가 잘 형성된 스키마(well-formed schema)를 따를 것이라고 가정합니다. 만약 이 가정이 실패하면, 에이전트는 손상된 페이로드(payload)를 유효한 것으로 취급하여 오류를 조용히 전파할 수 있습니다. 이러한 침묵의 전파(silent propagation)는 연쇄적인 오류, 토큰 낭비, 그리고 궁극적으로 잘못된 최종 출력으로 이어질 수 있는 미묘한 실패 모드입니다.

문제의 근본 원인은 도구(tool)의 출력 형식과 에이전트(agent)의 내부 상태 머신(state machine) 사이의 긴밀한 결합에 있습니다. 대부분의 LLM 기반 파이프라인은 모델이 생성하도록 훈련된 단일 "응답 스키마 (response schema)"에 의존합니다. API가 429 오류를 반환하거나 잘못된 형식의 JSON을 반환할 때, 모델은 여전히 예상된 형태와 일치하지만 자리 표시자(placeholder)나 기본값(default values)을 포함하는 응답을 생성할 수 있습니다. 그러면 에이전트는 해당 데이터가 신뢰할 수 있다고 믿고 다음 단계로 진행합니다. 오류가 전혀 드러나지 않았기 때문에, 후속 도구 호출은 동일하게 손상된 입력을 받게 되며, 에이전트가 토큰 예산을 모두 소진하거나 강제 중단(hard stop)에 도달할 때까지 루프가 계속됩니다.

구체적인 예로, 추출된 엔티티(entity)의 JSON 리스트를 반환하는 파일 분석 도구가 있습니다. 만약 API가 요청을 제한(throttle)하여 429 오류를 반환하면, 모델은 여전히 빈 문자열이 포함된 JSON 배열을 출력할 수 있습니다. 다음 단계인 요약 도구는 이 배열을 전달받아 존재하지 않는 엔티티를 참조하는 요약을 생성하게 되고, 결국 터무니없는 보고서로 이어집니다. 스키마 자체는 유효해 보이기 때문에 에이전트는 이러한 불일치를 전혀 알아차리지 못합니다.

이를 완화하기 위해 엔지니어는 데이터를 다운스트림(downstream) 도구로 전달하기 전에 명시적인 스키마 검증(schema validation)을 구현해야 합니다. 가벼운 JSON 스키마 체크를 통해 잘못된 페이로드(payload)를 거부하고, 백오프(back-off) 전략과 함께 재시도를 트리거할 수 있습니다. 또한, 에이전트의 상태에 페이로드의 체크섬(checksum)이나 해시(hash)를 포함하면 의도하지 않은 수정을 감지하는 데 도움이 될 수 있습니다. 검증 실패가 발생하면 에이전트는 해당 사건을 로그에 기록하고, 운영자에게 알리며, 선택적으로 이전의 안정적인 상태로 롤백(roll back)해야 합니다.

스키마 오류를 무시하는 비용은 매우 높습니다. 단 하나의 손상된 페이로드가 전체 파이프라인을 무효화하여, 에이전트가 중복된 호출에 수천 개의 토큰을 낭비하게 만들 수 있습니다. 반면, 간단한 검증 단계는 무시할 수 있을 정도의 지연 시간(latency)만을 추가하면서, 루프를 통해 오직 잘 형성된(well-formed) 데이터만이 전파되도록 보장합니다.

Braintrust 블로그에 따르면, 루프는 모든 모델 호출(model calls)에 대해 99.97%의 성공률을 보입니다. 이는 대부분의 호출은 성공하지만, 소수의 실패가 검증 없이 전파될 경우 매우 큰 영향을 미칠 수 있음을 나타냅니다.

“재시도 루프(Retry loops)가 가장 단순합니다. 에이전트가 오류를 맞닥뜨리면 정확히 동일한 요청을 재시도합니다. API가 429(Too Many Requests)를 반환하면, 에이전트는 다시 시도하고, 또 다른 429를 받으면 다시 시도합니다.” – AI Agent Failure Modes: What 1,600 Traces Reveal About Loops, Token Waste, and Detection

부분 출력 모호성(Partial‑Output Ambiguity): 불완전한 결과의 디코딩

도구 사용 루프(Tool-use loops)가 올바르게 작동하려면 구조화된 출력(structured outputs)에 의존해야 합니다. LLM이 도구 호출(tool call)을 생성할 때, 일반적으로 함수 이름과 인자(arguments)를 정의하는 JSON 블록을 방출합니다. 만약 모델이 토큰 제한(token limit)에 걸리거나 스트림 중간에 중단된다면, 해당 JSON은 불완전할 수 있습니다. 이 경우 다운스트림 파서(downstream parser)는 실패하게 되지만, 이러한 실패 모드는 종종 침묵하거나 모호하게 나타납니다. 시스템은 잘린 문자열을 유효하지만 잘못된 값으로 해석할 수도 있고, 근본 원인을 해결하지 못한 채 재시도 루프를 트리거하는 일반적인 오류를 던질 수도 있습니다.

이러한 모호성은 에이전트가 좀비 상태(zombie state)에 빠지는 특정 유형의 실패를 초래합니다. 에이전트는 망가진 출력을 복구하려고 시도하는 동안 계속해서 리소스를 소비합니다. 이러한 침묵하는 실패(silent failures)의 비용은 단순히 지연 시간(latency)뿐만 아니라 실제 컴퓨팅 자원의 낭비(compute waste)로 이어집니다. 시스템이 충돌(crash)하는 것이 아니라, 그저 헛바퀴를 돌게(spins) 되는 것입니다.

정상적으로 작동하는 상태의 에이전트는 분당 200개의 토큰을 소비할 수 있습니다. 하지만 루프에 갇힌 에이전트는 예외(exception)를 발생시키거나 오류 로그를 생성하지 않고도 분당 40,000개의 토큰까지 급증할 수 있습니다. AI Agent Failure Modes: What 1,600 Traces Reveal About Loops, Token Waste, and Detection, octopodas.com

엔지니어링 커뮤니티는 이러한 위험성을 매우 예리하게 인식하고 있습니다. 도구 사용 (tool-use) 아키텍처에 대한 강도 높은 정밀 조사는 견고한 파싱 (parsing)이 얼마나 중요한지를 강조합니다. 예를 들어, 이러한 루프 (loops)의 효과성에 관한 논의는 최근 상당한 관심을 끌었으며, 이 패턴이 강력한 동시에 운영상의 위험 (operational peril)으로 가득 차 있다는 것을 증명했습니다.

최근 Hacker News에서 이루어진 도구 사용 패턴에 대한 분석은 이 아키텍처에 대한 커뮤니티의 강렬한 관심을 보여줍니다. sketch.dev에 따르면, 도구 사용을 동반한 LLM 에이전트 루프 (agent loops)의 비합리적인 효과성을 상세히 다룬 특정 게시물은 Hacker News에서 447점을 받았습니다.

이를 완화하기 위해 엔지니어들은 엄격한 스키마 검증 (schema validation)과 부분 문자열 버퍼링 (partial string buffering)을 구현해야 합니다. 닫는 구분자 (closing delimiter)가 확인될 때까지 스트림 (stream)을 파싱하려고 시도하지 마십시오. 만약 출력이 잘렸다면, 이를 잘못된 형식의 입력 (malformed input)이 아닌 하드 스톱 (hard stop)으로 취급해야 합니다. 이는 파서 (parser)가 구조를 환각 (hallucination)하는 것을 방지하고, 예산을 소진하기 전에 루프를 중단시킵니다. 표준 재시도 로직 (retry logic)이 맹목적으로 추측하게 두는 대신, 부분적인 출력을 완료하라는 프롬프트와 함께 컨텍스트 (context)에 다시 입력함으로써 "불완전한 (incomplete)" 상태를 명시적으로 처리해야 합니다. 구문 오류 (syntax error)와 절단 이벤트 (truncation event) 사이의 이러한 구분이야말로 회복 탄력성이 있는 시스템과 돈 낭비 (money pit)를 가르는 차이점입니다.

‘딱 한 번의 도구 호출만 더’ 안티 패턴 (Anti‑Pattern)

메커니즘은 단순하지만 교활합니다. LLM은 도구를 실행하고, 출력을 검사한 뒤, 사소한 불완전함이나 누락된 세부 사항을 식별합니다. 결과를 수용하거나 최종 답변을 합성하는 대신, 추가적인 도구 호출 (tool call)이 그 간극을 메울 것이라고 결정합니다. 이는 시스템 프롬프트 (system prompt)가 명확한 중단 조건 (stopping condition)을 정의하지 않은 채 철저함만을 강조할 때 자주 발생합니다. 모델은 각 단계가 이론적으로는 상태를 개선하지만 실제로는 지연 시간 (latency)과 비용을 유발하는 개선의 반응형 루프 (reactive loop)에 진입합니다. 모델은 도구 출력을 최종 결과물 (final deliverable)이 아닌 추가 작업을 위한 프롬프트 (prompt)로 취급합니다.

디버깅 워크플로우를 생각해 봅시다. 모델이 코드를 생성하고, 린터 (linter)를 실행했는데 사용되지 않는 변수에 대한 경고를 받습니다. 모델은 이를 수정하려고 시도하고, 다시 린터를 실행하지만 스타일 오류 (style error)를 발생시킵니다. 스타일을 수정하고 세 번째로 린터를 실행한 뒤, 유닛 테스트 (unit tests)를 실행하기로 결정합니다. 테스트가 실패하면서 또 다른 코드 생성 사이클이 트리거됩니다. 단 한 번의 생성 및 검증 단계로 끝났어야 할 작업이 5~6번의 상호작용 체인으로 변질됩니다. 사용자는 기다려야 하고, 토큰 비용은 늘어납니다.

이러한 실패 모드는 수확 체감 (diminishing returns)의 형태로 나타납니다. 지연 시간 (latency)은 선형적으로 누적되는 반면, 각 후속 호출의 한계 효용 (marginal utility)은 급격히 떨어집니다. 프로덕션 시스템 (production systems)에서는 이것이 요청 시간 초과 (timeout) 또는 단순한 쿼리에 대한 비용 폭증으로 나타납니다. 또한 모든 도구 호출 (tool call)이 잠재적인 실패 지점이나 스키마 불일치 (schema mismatch)의 원인이 될 수 있으므로 오류 발생 가능 영역 (surface area)을 넓힙니다. 모델은 전역적 효율성 (global efficiency)을 희생하면서 국소적 정확성 (local correctness)을 최적화하며, 핵심 문제를 해결하기보다는 종종 "만지작거리는 (tinkering)" 상태에 빠지게 됩니다. Leviathan과 같은 플랫폼을 기반으로 구축하는 엔지니어들은 외부 API를 통합할 때 이러한 현상을 자주 겪으며, 이때 모델은 실제로 유효한 응답을 오히려 "수정"하려고 시도하곤 합니다.

대안은 엄격한 깊이 제한 (depth limiting) 또는 배치 계획 (batch planning)입니다. 모델이 반응적으로 도구를 체이닝 (chaining)하도록 허용하는 대신, 단 한 번의 추론 패스 (reasoning pass) 내에서 필요한 모든 단계를 계획하도록 강제하십시오. 만약 아키텍처상 체이닝이 필요하다면, 순차적 호출 횟수에 엄격한 상한선(hard cap)을 설정하십시오. 이상적으로는 2~3회 정도가 적당합니다. 이 패턴은 상태를 반복적으로 확인해야 하는 복잡한 API와의 상호작용처럼, 작업의 복잡도가 진정으로 다단계 분해 (multi-step decomposition)를 요구할 때만 사용하십시오. 대부분의 검색 (retrieval) 및 생성 (generation) 작업에서는 호출 횟수가 적을수록 좋습니다.

토큰을 절약하는 검증기 전략 (Verifier Strategies)

도구 사용 루프(tool-use loop)가 모든 출력에 대해 모델을 맹목적으로 재호출하는 검증기(verifier)와 결합될 때, 토큰 예산(token budget)이 데이터 흐름보다 더 빠르게 고갈될 수 있습니다. 절제된 검증기 전략은 먼저 가벼운 체크를 적용하고, 필요한 경우에만 전체 모델 재생성(re-generation)으로 격상함으로써 이를 완화합니다. 다음 관행들은 정확성을 유지하면서 토큰 소비를 줄여줍니다.

점진적 신뢰도 점수 (Incremental Confidence Scores)

검증기는 모델에게 신뢰도 점수(confidence score)나 불리언 플래그(boolean flag)만을 반환하도록 요청할 수 있습니다. 이 짧은 토큰 시퀀스는 주변 코드에 의해 해석됩니다. 점수가 임계값(threshold)을 초과하면 결과가 수락되고, 그렇지 않으면 타겟팅된 재실행(re-run)이 트리거됩니다.

선택적 재실행 트리거 (Selective Re-Run Triggers)

모든 실패 시마다 재호출하는 대신, 검증기는 실패 모드(failure modes)의 이력을 유지합니다. 특정 오류 유형이 반복되면, 루프는 재실행을 건너뛰고 해당 입력을 수동 검토 대상으로 표시할 수 있습니다. 이는 오류가 환각(hallucination)이 아닌 프롬프트 형식(prompt formatting)에서 기인할 때 불필요한 호출을 줄여줍니다.

캐싱 및 메모이제이션 (Caching and Memoization)

주어진 입력에 대한 결정론적(deterministic) 도구 결과는 캐싱될 수 있습니다. 동일한 프롬프트가 다시 나타나면, 검증기는 캐싱된 출력과 그 검증 결과를 재사용하여 중복된 모델 호출을 제거합니다.

조기 종료 검증 (Early-Exit Validation)

모델의 원시 출력(raw output)에 대해 도구로 전달하기 전 가벼운 구문 체크(syntax check)를 수행할 수 있습니다. 유효하지 않은 구문은 즉시 폐기되어, 전체 도구 실행 비용을 절감합니다.

임계값 기반 토큰 가지치기 (Threshold-Based Token Pruning)

각 도구 호출에 대해 토큰 제한을 설정하면 검증기가 지나치게 장황한 응답을 잘라낼(truncate) 수 있습니다. 잘라낸 후 핵심 로직을 다시 검증하며, 로직이 온전하게 유지된다면 추가 토큰을 절약할 수 있습니다.