현장에서 에이전트 PoC가 운영으로 넘어갈 때 가장 자주 빠지는 문서가 런북이다. 데모에서는 잘 돈다. 회의실에서는 더 잘 돈다. 그런데 실제 업무에 붙는 순간 문제가 달라진다. 에이전트가 같은 작업을 반복 호출한다. 승인 없이 외부 시스템을 건드린다. 토큰 사용량이 평소와 다르게 튄다. 담당자는 대시보드를 보고도 먼저 무엇을 끊어야 하는지 모른다.
에이전트는 챗봇이 아니다. 도구를 호출하고, 상태를 기억하고, 다음 행동을 계획한다. 그래서 장애도 답변 오류가 아니라 실행 오류로 다뤄야 한다.
에이전트 장애는 세 가지로 먼저 나눈다
런북의 첫 장은 원인 분석이 아니다. 분류다. 현장 대응에서 가장 위험한 문장은 “일단 로그를 보자”다. 로그를 보는 동안 에이전트는 계속 실행한다.
| 시나리오 | 즉시 판단 기준 | 첫 조치 |
|---|---|---|
| 오작동 | 잘못된 도구 호출, 잘못된 데이터 변경, 근거 없는 실행 | 쓰기 권한 차단 |
| 폭주 | 반복 루프, 과도한 재시도, 서브에이전트 연쇄 호출 | 세션·큐 중지 |
| 비용 폭발 | 토큰·툴 호출·검색·코드 실행 사용량 급증 | 예산 게이트 격리 |
오작동은 품질 이슈가 아니다. 권한 이슈다. 폭주는 추론 이슈가 아니다. 제어 이슈다. 비용 폭발은 사용량 이슈가 아니다. 회로 차단기 부재다.
OpenAI Responses API는 함수 호출과 웹 검색·파일 검색 같은 도구 연결을 전제로 하고, Anthropic Claude Code는 PreToolUse, PostToolUse, Stop 같은 hook으로 실행 전후 제어점을 둔다. 이 흐름은 이미 제품 기능의 문제가 아니라 운영 통제의 문제로 이동했다.
에이전트 런북의 목적은 “왜 틀렸는가”를 밝히는 것이 아니라 “더 실행하지 못하게 하는 것”이다.
런북은 중단 버튼보다 권한 계단이 먼저다
많은 조직이 kill switch를 만들면 충분하다고 생각한다. 부족하다. kill switch는 마지막 수단이다. 운영에서는 권한 계단이 먼저다.
첫째, 읽기·쓰기·전송·삭제 권한을 분리한다. 에이전트가 문서를 읽는 권한과 고객에게 메일을 보내는 권한은 같은 레벨이 아니다.
둘째, 도구별 예산을 둔다. 전체 API 월 예산만으로는 늦다. 워크플로우, 사용자, 에이전트, 실행 단위별로 제한을 둬야 한다. Anthropic 문서는 조직 단위 spend limit과 rate limit을 구분하고, OpenAI 프로젝트 관리 문서도 예산 알림과 모델 rate limit 관리를 다룬다.
셋째, 위험 행동은 프롬프트가 아니라 시스템 밖에서 막는다. OWASP LLM Top 10의 Excessive Agency와 MCP Top 10의 command injection류 위험은 같은 메시지를 준다. 에이전트에게 “하지 말라”고 말하는 것은 통제가 아니다. 권한이 없어야 통제다.
대응 시나리오는 15분 단위로 짜야 한다
에이전트 인시던트 런북은 긴 문서가 아니다. 당직자가 그대로 실행할 수 있는 순서여야 한다.
- 감지: 비정상 호출량, 실패율, 반복 tool call, 예산 소진 속도를 알림으로 받는다.
- 격리: 쓰기·삭제·외부 전송 권한을 먼저 차단한다.
- 중지: 실행 중인 세션, 큐, 예약 작업, 서브에이전트를 멈춘다.
- 보존: prompt, retrieved context, tool input/output, 승인 이력, 비용 로그를 고정한다.
- 복구: 재실행이 아니라 최소 권한 모드로 재개한다.
여기서 핵심은 “재시도 금지”다. 기존 소프트웨어 장애에서는 재시도가 유효할 때가 많다. 에이전트 폭주에서는 재시도가 비용과 피해를 키운다. 특히 검색, 코드 실행, 외부 API 호출이 붙은 에이전트는 재시도 정책 자체가 사고 원인이 된다.
AWS Bedrock의 model invocation logging, Anthropic Usage and Cost API 같은 기능은 사후 정산 도구가 아니다. 런북의 증거 보존 장치다. 비용 로그와 실행 로그가 분리돼 있으면 원인 분석은 늦어지고, 책임 소재만 먼저 흔들린다.
배포 전 런북 리허설이 운영 전환의 기준이다
AX Ops에서 에이전트 배포 기준은 “정확도가 충분한가”가 아니다. 사고가 났을 때 누가, 무엇을, 어떤 순서로 끊는지가 정해졌는가다.
출시 전 최소 세 가지 리허설을 해야 한다. 잘못된 도구 호출을 주입한다. 반복 루프를 만든다. 토큰과 외부 API 비용을 의도적으로 올린다. 이때 모델이 잘 버티는지를 보지 않는다. 조직이 멈출 수 있는지를 본다.
얕은 요약은 이렇다. 에이전트는 실행 주체다. 실행 주체에는 권한, 예산, 로그, 중단 절차가 필요하다. 런북은 운영 문서가 아니라 배포 승인 조건이다.
참고
- OpenAI API Reference, Responses API: https://platform.openai.com/docs/api-reference/responses
- OpenAI Help Center, Function Calling and Agents platform, 2025: https://help.openai.com/en/articles/8555517-function-calling-in-the-openai-api
- Anthropic Docs, Claude Code Hooks: https://docs.anthropic.com/en/docs/claude-code/hooks
- Anthropic Docs, Rate limits and spend limits: https://docs.anthropic.com/en/api/rate-limits
- Anthropic Docs, Usage and Cost API: https://docs.anthropic.com/en/api/data-usage-cost-api
- OWASP, Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/
- OWASP, MCP Top 10: https://owasp.org/www-project-mcp-top-10/
- AWS Docs, Amazon Bedrock model invocation logging: https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
에이전트를 운영에 붙이려면 먼저 멈추는 방법부터 설계해야 한다. AX Ops 방법론 →