현장에서 long-running 에이전트를 붙이면 처음에는 모델 품질을 본다. 그런데 운영 로그를 열어보면 다른 장면이 반복된다. 에이전트가 같은 상태를 계속 조회한다. 이미 실패한 API를 같은 인자로 다시 친다. 사람 입력이 필요한데 스스로 다음 단계를 상상한다. 비용은 쓰였지만 일은 앞으로 가지 않는다.
이 문제는 프롬프트 문제가 아니다. 루프 페이싱 문제다.
오래 도는 에이전트는 답변기가 아니라 스케줄러다
짧은 챗봇은 한 번 묻고 한 번 답한다. long-running 에이전트는 다르다. 외부 시스템을 기다리고, 배치 작업을 확인하고, 승인자를 기다리고, 실패를 복구한다.
그래서 에이전트의 핵심 설계 단위는 “생각”이 아니라 “다음에 언제 깨어날 것인가”다. OpenAI Responses API 문서도 background response 완료·실패·취소·중단 이벤트를 webhook으로 다룬다. MCP 2025-11-25 사양도 Tasks를 통해 working, input_required, completed, failed, cancelled 같은 상태를 별도 생명주기로 다룬다. 둘 다 같은 방향을 가리킨다. 오래 도는 일은 대화가 아니라 상태 머신이다.
long-running 에이전트는 더 똑똑한 루프가 아니라 더 엄격한 루프 예산으로 안정화된다.
루프 페이싱 엔지니어링은 세 가지를 명시한다.
- wakeup schedule: 언제 다시 실행할지
- polling budget: 상태 확인을 몇 번, 어떤 간격으로 할지
- retry budget: 어떤 실패를 몇 번만 복구할지
폴링은 기본값이 아니라 비용 항목이다
많은 팀이 폴링을 “간단한 구현”으로 본다. 운영에서는 간단하지 않다. 폴링은 토큰, API rate limit, 외부 시스템 부하, 로그 소음을 동시에 만든다.
| 구분 | 나쁜 설계 | 운영 설계 |
|---|---|---|
| wakeup | 매 분 실행 | 상태별 다음 실행 시각 저장 |
| polling | 완료될 때까지 조회 | 최대 횟수와 backoff 지정 |
| retry | 실패하면 다시 시도 | 실패 유형별 retry 가능성 분리 |
| 중단 | timeout 후 로그만 남김 | task state와 사유를 남기고 에스컬레이션 |
| 관측 | run 성공 여부만 기록 | step, tool, latency, retry_count, cost를 trace로 기록 |
핵심은 “기다림”을 코드 바깥의 암묵적 시간으로 두지 않는 것이다. task record에 next_wakeup_at, poll_count, retry_count, last_observed_state, terminal_reason을 남긴다. 에이전트가 다시 깨어날 때마다 이 값을 먼저 읽는다. 모델 호출은 그 다음이다.
이 순서가 바뀌면 에이전트는 기억에 의존한다. 기억에 의존하는 루프는 재시작, 배포, 장애 복구에서 깨진다.
재시도는 복구가 아니라 의사결정이다
실패를 모두 retry로 처리하면 에이전트는 헛돈다. 401은 인증 문제다. 404는 대상 부재다. 409는 충돌이다. 429는 속도 문제다. 5xx와 timeout은 일시 장애일 가능성이 있다. 같은 “실패”가 아니다.
2026년 6월 공개된 self-healing agentic orchestrator 논문은 신뢰성을 무한 재시도가 아니라 “관측 가능한 실패 신호, 제한된 복구 예산, 검증된 회복 경로”의 문제로 다룬다. 이 관점이 현장 설계와 맞다. 재시도는 감정적 낙관이 아니라 정책이다.
AX Ops에서는 retry policy를 업무 단위로 둔다. 결재 상신, 고객 안내, 데이터 변경, 리포트 생성은 같은 retry 한도를 쓰면 안 된다. 외부 부작용이 있는 tool call은 idempotency key 없이 재시도하지 않는다. 읽기 작업은 backoff를 길게 잡고, 쓰기 작업은 중복 실행 방지부터 설계한다.
루프 페이싱은 배포 전에 정해야 한다
PoC에서는 에이전트가 끝까지 해내는지만 본다. 운영에서는 끝까지 못 했을 때 어떻게 멈추는지가 더 중요하다. 멈춤이 설계되지 않은 에이전트는 실패하지 않고 계속 비용을 쓴다.
Claude Code의 2026년 공식 글은 hooks, skills, subagents를 에이전트 주변의 harness로 설명한다. 이 흐름은 coding agent에만 해당하지 않는다. 업무 에이전트도 모델 바깥의 harness가 필요하다. wakeup scheduler, retry governor, polling ledger, escalation hook이 그 harness다.
다음 릴리스 전에 한 워크플로만 골라 점검하면 된다.
- 이 에이전트는 어떤 상태에서 다시 깨어나는가.
- 같은 외부 상태를 몇 번까지 조회하는가.
- 어떤 오류는 절대 retry하지 않는가.
- 예산 소진 시 누구에게 어떤 상태로 넘기는가.
요약하면 간단하다. long-running 에이전트의 운영 품질은 모델보다 루프가 먼저 결정한다. 루프를 설계하지 않으면 에이전트는 성실하게 헛돈다. AX LABS는 이 지점을 agent harness와 운영 지표까지 묶어 설계한다. 더 깊은 설계 원칙은 AX Ops 방법론 →에서 다룬다.
참고
- Anthropic, “Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents,” 2026. https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
- OpenAI API Reference, “Webhook Events,” 2026-07-20 확인. https://platform.openai.com/docs/api-reference/webhook-events
- OpenAI Platform Docs, “Data controls in the OpenAI platform,” 2026-07-20 확인. https://platform.openai.com/docs/models/default-usage-policies-by-endpoint
- Model Context Protocol, “2025-11-25 Release,” 2025. https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2025-11-25
- Model Context Protocol, “Tasks,” 2025. https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks
- arXiv, “Self-Healing Agentic Orchestrators for Reliable Tool-Augmented Large Language Model Systems,” 2026. https://arxiv.org/abs/2606.01416
