운영에 올린 에이전트가 실패할 때 가장 먼저 보이는 것은 에러가 아니다. 실행 시간은 길어지고, 토큰은 늘고, 도구 호출은 반복되는데 결과물은 제자리다. 반대로 너무 빨리 끝나서 사용자는 다시 질문한다. 로그에는 모두 정상 호출로 남는다. 그래서 루프 디버깅은 로그 분석이 아니라 실행 궤적 분석이다.
에이전트 장애는 세 가지 루프로 갈린다
에이전트 루프의 장애를 하나로 묶으면 처방이 틀어진다. 헛도는 스텝, 무한루프, 조기종료는 증상이 다르고 원인도 다르다.
헛도는 스텝은 실행은 계속되지만 상태가 전진하지 않는 상태다. 같은 문서를 다시 읽고, 같은 조건을 다시 검토하고, 이미 얻은 값을 다른 말로 재확인한다.
무한루프는 더 좁다. 같은 의도, 같은 도구, 같은 실패 패턴이 반복된다. LangGraph 문서가 GRAPH_RECURSION_LIMIT을 “stop condition에 도달하기 전 최대 스텝에 닿은 상태”로 설명하는 이유도 여기에 있다. 한도를 높이는 것은 복잡한 그래프에는 필요하지만, 반복 원인을 고치지는 않는다.
조기종료는 더 위험하다. 완료 조건을 충족하지 않았는데 에이전트가 스스로 끝났다고 판단한다. 이 장애는 비용이 적게 보이고 지연도 짧다. 그래서 대시보드만 보면 정상처럼 보인다.
루프 장애는 “몇 번 돌았나”가 아니라 “돌 때마다 무엇이 달라졌나”로 잡아야 한다.
관측 지표는 호출 단위가 아니라 스텝 단위여야 한다
일반 로그는 API 호출의 성공과 실패를 보여준다. 에이전트 운영에는 부족하다. OpenAI는 2026년 Agents SDK 업데이트에서 에이전트 루프용 harness와 sandbox 실행을 분리해 장시간 작업을 다루는 구조를 강조했다. LangSmith도 2026년 Engine 발표에서 생산 traces, evaluator feedback, source code를 함께 보고 recurring failure를 묶는 흐름을 제시했다. 방향은 같다. 루프를 실행 단위로 관측해야 한다.
| 장애 패턴 | 먼저 볼 지표 | 해석 | 튜닝 처방 |
|---|---|---|---|
| 헛도는 스텝 | state diff, 신규 근거 수, plan delta | 스텝은 늘지만 상태 변화가 없다 | 다음 스텝 조건을 “새 정보” 기준으로 제한 |
| 무한루프 | tool signature 반복, error class 반복, handoff 왕복 | 같은 실패를 다른 말로 재시도한다 | 동일 실패 누적 시 stop/escalation 분기 추가 |
| 조기종료 | success criterion 미충족, user re-open, 후속 질문 | 완료 판단이 업무 기준보다 느슨하다 | 종료 전 checklist evaluator 삽입 |
| 비용 폭주 | token burn per accepted step, tool latency per decision | 유효 전진 대비 비용이 크다 | context 축소, tool 결과 요약, budget breaker 적용 |
핵심은 trace에 의미 있는 metadata를 붙이는 일이다. agent name, node name, tool name만으로 부족하다. step goal, expected evidence, termination reason, retry reason, state hash를 남겨야 한다. OpenTelemetry가 traces, metrics, logs를 생성·수집·전송하는 vendor-neutral 관측 프레임워크로 자리 잡은 것도 이 구조와 맞다. 다만 에이전트에는 일반 span보다 한 층 위의 “의도와 상태 변화”가 필요하다.
튜닝은 프롬프트 수정 전에 정지 조건부터 한다
현장에서 가장 흔한 실수는 루프 장애를 프롬프트 문장으로만 고치려는 것이다. 프롬프트는 필요하다. 하지만 정지 조건, 재시도 정책, 도구 선택 규칙이 없으면 같은 장애가 다른 표현으로 돌아온다.
우리는 튜닝 순서를 고정한다.
- 종료 조건을 업무 언어로 쓴다. “충분하면 종료”가 아니라 “필수 필드가 모두 채워지고 근거 링크가 붙으면 종료”로 쓴다.
- 반복 감지 기준을 만든다. 같은 tool, 같은 argument shape, 같은 error class가 반복되면 재시도가 아니라 분기다.
- 상태 변화 없는 스텝을 비용으로 본다. 토큰이 아니라 accepted step 대비 비용을 본다.
- 실패 trace를 eval dataset으로 승격한다. 한 번 잡은 루프는 회귀 테스트에 들어가야 한다.
2026년 RAMP 논문이 runtime-observable 평가와 outcome quality, process efficiency를 함께 보자고 제안한 것도 이 흐름과 맞다. 에이전트 평가는 최종 답안 채점만으로 끝나지 않는다. 어떤 경로로 도달했는지, 그 경로가 운영 가능한지까지 봐야 한다.
참고는 튜닝 루프에 붙어야 한다
루프 디버깅의 목표는 예쁜 trace 화면이 아니다. 운영 중인 에이전트가 어디서 헛돌고, 어디서 멈춰야 하며, 어디서 사람에게 넘겨야 하는지 결정하는 것이다. AX Ops에서는 이 지표를 배포 전 테스트, 운영 모니터링, 개선 backlog에 같은 이름으로 연결한다.
참고 자료:
- OpenAI, “The next evolution of the Agents SDK”, 2026: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
- LangChain, “Introducing LangSmith Engine”, 2026: https://www.langchain.com/blog/introducing-langsmith-engine
- LangChain Docs, “GRAPH_RECURSION_LIMIT”, 2026 확인: https://docs.langchain.com/oss/python/langgraph/errors/GRAPH_RECURSION_LIMIT
- LangChain Docs, “Observability concepts”, 2026 확인: https://docs.langchain.com/langsmith/observability-concepts
- OpenTelemetry Docs, 2025: https://opentelemetry.io/docs/
- arXiv, “Benchmarks are Not Enough: RAMP for Runtime Assessing of Agentic Models in Production Systems”, 2026: https://arxiv.org/abs/2605.27492
PoC 이후 에이전트를 운영 체계로 묶으려면 루프 지표부터 설계해야 한다: AX Ops 방법론 →