현장에서 에이전트 PoC를 보면 처음에는 모두 “스스로 끝까지 처리한다”는 장면에 집중한다. 하지만 운영 테이블에 올라오는 질문은 다르다. 오래 도는 루프를 누가 멈추는가. 멈췄을 때 어디까지 완료됐는가. 다시 시작하면 같은 일을 반복하는가. 결과가 완성되지 않았을 때 무엇을 회수할 수 있는가.
이 질문에 답하지 못하면 에이전트는 자동화가 아니라 긴 세션이다. 긴 세션은 장애와 비용과 책임 소재를 흐린다.
루프의 핵심은 실행보다 중단이다
에이전트 루프는 목표, 도구 호출, 관찰, 다음 행동의 반복이다. 문제는 반복 자체가 아니다. 문제는 반복이 조직의 운영 리듬과 맞지 않는다는 점이다.
업무에는 마감, 승인, 예산, 장애 대응, 고객 응대 시간이 있다. 루프가 그 경계를 모르고 계속 돌면 현장은 자동화를 신뢰하지 않는다. 그래서 루프 설계에는 시작 조건만큼 중단 조건이 먼저 들어가야 한다.
중단 조건은 세 가지로 나뉜다.
- 사용자가 명시적으로 멈춘다.
- 정책이 위험 또는 비용 초과를 감지해 멈춘다.
- 루프가 더 진행해도 품질이 개선되지 않아 스스로 멈춘다.
에이전트의 성숙도는 얼마나 오래 도는가가 아니라, 얼마나 안전하게 멈추고 이어갈 수 있는가로 판단한다.
graceful cancel은 kill switch가 아니다
graceful cancel은 프로세스를 죽이는 버튼이 아니다. “현재 작업을 정리하고, 이미 만든 산출물을 표시하고, 다음 재개 지점을 남기는 절차”다.
OpenAI Realtime API 문서는 진행 중인 응답을 response.cancel 이벤트로 취소하고, 서버가 response.done과 cancelled 상태를 반환하는 흐름을 명시한다. 이 수준의 취소는 대화형 인터페이스에 필요한 최소 단위다. 하지만 업무 에이전트에는 한 단계가 더 필요하다. 취소 이벤트 뒤에 정리 루틴이 실행돼야 한다.
Claude Code의 hooks 문서도 같은 방향을 보여준다. Stop, SubagentStop, PostToolUse 같은 lifecycle 지점에서 외부 스크립트를 연결한다. 중요한 것은 hook 자체가 아니라 위치다. 루프가 끝나거나 멈추는 지점에 검증, 로그, 산출물 정리, 후속 알림을 붙일 수 있어야 한다.
운영 설계에서는 cancel을 다음 네 필드로 기록한다.
| 항목 | 기록할 내용 |
|---|---|
| cancel_source | 사용자, 정책, 시스템, 상위 오케스트레이터 |
| last_safe_step | 부작용 없이 재개 가능한 마지막 단계 |
| partial_outputs | 회수 가능한 파일, 초안, 판단 근거 |
| resume_policy | 재개, 재시도, 폐기, 사람 검토 |
체크포인트는 로그가 아니라 재개 계약이다
많은 팀이 로그를 남기면 복구가 된다고 착각한다. 로그는 설명한다. 체크포인트는 이어간다. 둘은 다르다.
LangGraph 문서는 interrupt가 발생하면 graph state를 persistence layer에 저장하고, 이후 thread_id를 기준으로 같은 checkpoint에서 재개한다고 설명한다. persistence 문서도 graph state를 step마다 checkpoint로 저장하고, human-in-the-loop, time travel debugging, fault-tolerant execution에 사용한다고 정리한다.
이 말은 구현 선택을 넘어 운영 원칙이다. 에이전트가 외부 시스템을 건드리는 순간, 체크포인트는 “무엇을 다시 해도 되는가”와 “무엇을 다시 하면 안 되는가”를 나누는 계약이 된다.
체크포인트에는 프롬프트 전문보다 다음 정보가 중요하다.
- 현재 목표와 완료 기준
- 사용한 도구와 외부 side effect
- 승인 대기 중인 판단
- 회수 가능한 중간 산출물
- 다음 실행 후보와 금지 행동
특히 interrupt 앞에 실행된 side effect는 idempotent해야 한다. 같은 노드가 재실행될 때 결제가 두 번 나가거나 고객 알림이 두 번 발송되면, 그것은 모델 문제가 아니라 루프 설계 문제다.
부분 결과 회수가 ROI를 지킨다
중단 가능한 루프의 마지막 요소는 partial result다. 완성 결과만 성공으로 치는 에이전트는 운영에서 약하다. 중간에 멈춰도 초안, 근거 목록, 실패한 도구 호출, 검토 필요 항목을 회수해야 한다.
OpenAI Agents SDK의 tracing 문서는 agent run 동안 LLM generation, tool call, handoff, guardrail, custom event를 기록한다고 설명한다. 이런 trace는 디버깅용 화면이 아니라 부분 결과 회수의 원천이다. 무엇을 했고, 어디서 멈췄고, 어떤 판단을 남겼는지 보여줘야 사람이 이어받는다.
AX Ops에서 에이전트 루프를 설계할 때 우리는 “완료 화면”보다 “중단 화면”을 먼저 그린다. 중단 화면에 남는 것이 없으면 그 루프는 아직 운영 단위가 아니다.
참고
- LangGraph Interrupts, 2026년 7월 확인: https://docs.langchain.com/oss/python/langgraph/interrupts
- LangGraph Persistence, 2026년 7월 확인: https://docs.langchain.com/oss/python/langgraph/persistence
- OpenAI Realtime API
response.cancel, 2026년 7월 확인: https://platform.openai.com/docs/api-reference/realtime-client-events/response/cancel - OpenAI Agents SDK Tracing, 2026년 7월 확인: https://openai.github.io/openai-agents-python/tracing/
- Claude Code Hooks, 2026년 7월 확인: https://code.claude.com/docs/en/hooks
정리하면 루프는 빨리 만드는 것이 아니라 멈출 수 있게 만들어야 한다. graceful cancel, 체크포인트, 부분 결과 회수는 옵션이 아니라 운영 투입 조건이다. 에이전트 제품을 현장 운영 단위로 바꾸려면 AX Ops 방법론 →
