AI 에이전트가 다단계 작업에서 실패하는 이유 — 그리고 침묵하는 실패를 포착하는 방법

💻 이 시리즈의 모든 코드는 하나의 리포지토리(repo)에 있습니다: resilient-agent-harness-sample-for-aws. 이 포스트는 다단계 작업 계획 (Multi-Step Task Planning) 데모(03-multi-step-task-planning)입니다. 클론(Clone)하여 함께 따라와 보세요.

AI 에이전트에게 여러 단계로 구성된 작업과 조용히 오작동하는 도구(tool) 하나를 주면 다음과 같은 일이 발생합니다. 특정 단계의 도구가 `

– search_flights: Duffel 샌드박스에서 항공 요금을 찾습니다.
– book_flight: 백엔드에 예약을 작성합니다. 중간 비행(CDG에서 HND, 여행의 도쿄 구간)에는 조용한 실패가 내장되어 있습니다. 즉, 첫 번째 시도는 `

접근 방식	작동 방식	결과
이전 (BEFORE)	하나의 에이전트가 세 개의 항공권을 모두 예약하고 각 `

두 가지 설계 선택이 전체 시스템을 결정합니다. 검증기 (verifier)는 오직 list_booked_flights만을 가지므로, 실행기 (executor)의 말에 의존하는 것이 아니라 실제 정답 (ground truth)을 바탕으로 판단합니다. 그리고 재시도 (retry)는 검증기가 FAIL을 읽었을 때만 작동하여 verify에서 execute로 돌아가는 조건부 엣지 (conditional edge)입니다. set_max_node_executions(6)는 루프 (cycle)를 위해 필수적인 실행 횟수 제한을 설정하며, reset_on_revisit(True)는 실행기가 이전의 오래된 상태 (stale state)를 유지하는 대신 매 재시도마다 새롭게 시작하도록 만듭니다.

from strands import Agent
from strands.multiagent import GraphBuilder

...

각 항공편 노드 추적 (node trace)을 통해 복구 과정을 확인할 수 있습니다. 첫 번째 시도에서 성공한 두 개의 항공편은 execute, verify를 실행하고 종료됩니다. 도쿄행 항공편은 execute, verify, execute, verify를 실행합니다. 즉, 검증기가 FAIL을 읽었고, 조건부 엣지가 루프를 돌았으며, 실행기가 이를 다시 예약한 것입니다.

JFK-CDG: nodes ran -> ['execute', 'verify']                       saved = True
CDG-HND: nodes ran -> ['execute', 'verify', 'execute', 'verify']  saved = True   # 재시도됨!
HND-JFK: nodes ran -> ['execute', 'verify']                       saved = True
...

검증이 토큰을 더 많이 소모하나요?

네, 그리고 이 부분이 대부분의 "에이전트 효율성 (agent efficiency)" 포스트들이 생략하는 지점입니다. 토큰은 추정치가 아닌 실제 Strands 메트릭 (metrics)인 result.accumulated_usage에서 나옵니다. OpenAI gpt-4o-mini를 사용하여 측정한 실행 결과는 다음과 같습니다:

	이전 (before)	이후 (after)
실제로 예약된 항공편	2/3	3/3
...	...	...

솔직하게 말하자면, 검증은 토큰을 적게 쓰는 것이 아니라 더 많이 사용합니다. 백엔드를 읽고 재시도하는 데 비용을 지불해야 하기 때문입니다. 두 실행 모두 "모두 예약됨"이라고 주장하지만, 검증된 그래프 (Graph)만이 실제로 정확합니다. 승리 지점은 비용 절감이 아니라 **정확성 (correctness)**입니다. 모델이 비결정론적 (non-deterministic)이기 때문에 실행마다 정확한 총합은 달라질 수 있지만, 직접 실행해 보면 그 형태는 동일함을 알 수 있습니다. 즉, BEFORE 에이전트는 더 저렴하지만 틀렸고, AFTER 그래프는 비용이 더 들지만 완벽한 여행을 완성합니다.

자주 묻는 질문 (Frequently asked questions)

도구의 "확인됨(confirmed)" 상태가 왜 충분하지 않은가요?
도구가 성공을 반환하더라도 실제 쓰기 작업이 영구적으로 저장되지 않을 수 있기 때문입니다 (불안정한 백엔드, 일관성 지연 등). 에이전트는 실제 성공과 가짜 성공을 구분할 수 없으므로, 완료되지 않은 작업을 완료된 것으로 보고합니다. 사후에 백엔드를 읽는 것이 유일하고 신뢰할 수 있는 확인 방법입니다.

검증은 항상 더 많은 토큰을 소모하나요?
네, 초기 비용이 발생하며 이것이 트레이드오프(trade-off)입니다. 백엔드를 읽고 재시도하기 위해 추가 토큰을 사용하지만, 그 대가로 항공편이 조용히 누락된 여행 일정을 배송하는 일을 방지할 수 있습니다. 중요한 지표는 단순한 토큰 수가 아니라 정확성(correctness)입니다.

이를 위해 Strands나 OpenAI가 필요한가요?
아니요. 실행하고, 실제 정답(ground truth)과 대조하여 검증하며, 실패 시 재시도하는 것은 일반적인 에이전트 개념입니다. Strands는 모델에 구애받지 않습니다(model-agnostic). 제공자(providers)를 교체할 수 있으므로, 동일한 그래프(Graph)를 Amazon Bedrock(기본값), Anthropic, OpenAI 또는 Ollama를 통한 로컬 모델에서 실행할 수 있습니다. 데모는 테스트를 위해 API 키만 있으면 되기 때문에 OpenAI gpt-4o-mini를 기본값으로 사용하지만, 이 역시 여전히 클라우드 API 호출이며 사용자의 기기에 있는 모델은 아닙니다.

직접 실행해 보기

전체 데모(도구에서 직접 증명된 침묵하는 실패, 2/3만 완료한 단순한 에이전트, 그리고 3/3을 회복하는 네이티브 그래프)는 하나의 노트북에서 엔드 투 엔드(end-to-end)로 실행됩니다. 리포지토리(repo)를 클론하고 실행하세요:

git clone https://github.com/elizabethfuentes12/resilient-agent-harness-sample-for-aws.git
cd resilient-agent-harness-sample-for-aws/03-multi-step-task-planning

...

노트북을 선호하시나요? test_multi_step_task_planning.ipynb를 열고 위에서 아래로 실행하세요.

이 패턴은 별도의 학습 없이 추론 시점의 계획 (inference-time planning) 및 검증 (verification)을 추가하는 MiRA (Wang et al., Mar 2026)를 따릅니다. 벤치마크 수치와 전체 내용은 리포지토리의 README에서 확인할 수 있습니다. 이 데모가 생성하는 것은 네이티브 Strands Graph 상에서 실행(execute), 정답(ground truth)과 대조하여 검증(verify), 실패 시 재시도(retry)하는 메커니즘입니다.

당신의 에이전트를 괴롭혔던 침묵하는 실패 (silent failure)는 무엇이었나요? 아무것도 저장되지 않았는데 "완료"라고 말하는 도구였나요? 댓글로 알려주세요.

Gracias!

🇻🇪 Dev.to Linkedin GitHub Twitter Instagram Youtube

[

](/elizabethfuentes12)

Elizabeth Fuentes L 팔로우

저는 실습 튜토리얼과 오픈 소스 프로젝트를 통해 개발자들이 프로덕션 수준의 AI 애플리케이션을 구축할 수 있도록 돕습니다.