블로그
안정성 및 프로덕션

게시일 수정일

Anshu 및 Arag

Production AI agent checklist: 인프라, 보안, reliability

Markdown으로 읽기

AI agent가 production data를 다루기 전에 scoped identity를 부여하고, 재시도 가능한 모든 write를 idempotent하게 만들고, destructive 또는 financial action을 실행 전에 중단할 수 있게 하세요. 사람 없이 실행하기 전에는 bounded execution, end-to-end trace, 테스트된 recovery path를 추가하세요.

이 checklist는 dependency 순서대로 정리되어 있습니다. 뒤의 control은 앞의 control에 의존합니다. production agent에서 각 failure가 얼마나 자주 발생하는지 보여 주는 public dataset이 없으므로 probability ranking은 아닙니다.

agent가 production data를 다루기 전에

각 agent에 scoped identity를 부여하세요

  • 추적이 필요한 각 agent, deployment, session에 별도의 credential을 발급합니다.
  • task에 필요한 tenant, resource, action으로 범위를 제한합니다.
  • tool description에서 read-only라고 해도 downstream service에서 authorization을 적용합니다.
  • human user account를 삭제하지 않고도 credential을 revoke할 수 있게 합니다.

shared administrator key를 사용하면 명확한 audit trail을 만들 수 없고 secret 하나의 유출이 광범위한 access로 이어집니다. OWASP의 Excessive Agency 가이드는 tool functionality, permission, autonomy를 최소화한 뒤 downstream system에서 authorization을 적용할 것을 권장합니다.

high-impact action을 실행 전에 중단하세요

  • destructive, financial, unusually broad operation에는 human 또는 policy approval을 요구합니다.
  • approval step에서 정확한 resource, scope, consequence를 보여 줍니다.
  • 기반 system이 지원한다면 soft deletion 같은 reversible state change를 우선합니다.
  • audit log를 유지하되 deletion 후 작성된 record를 preventive control로 취급하지 않습니다.

Railway는 2026년 4월 agent가 disk에서 account-scoped token을 찾아 legacy volume deletion API를 호출한 incident를 공개했습니다. platform에는 네 개의 authorization layer가 있었지만 token scope와 immediate-delete behavior는 여전히 그 action을 허용했습니다. Railway는 volume을 복구하고 API deletion을 dashboard와 같은 48시간 soft-delete 기간으로 바꿨습니다. incident report는 scoped identity를 reversible 또는 approved destructive path와 결합해야 하는 구체적인 이유를 보여 줍니다.

write를 idempotent하게 만드세요

  • logical operation마다 idempotency key 하나를 만들고 모든 retry에 재사용합니다.
  • operation result를 server에 저장하고 같은 key가 다시 나타나면 반환합니다.
  • 재사용한 key의 parameter가 original request와 다르면 거부합니다.
  • key가 유효한 기간과 expiry 후 동작을 정의합니다.

Stripe API는 idempotency key의 첫 result를 저장하며 최대 255자의 key를 허용합니다. 현재 문서에서는 생성 후 최소 24시간이 지난 key를 제거할 수 있다고 설명합니다. 이 숫자는 보편적인 default가 아니라 Stripe의 contract입니다. retention window는 agent가 현실적으로 retry하거나 resume할 수 있는 가장 긴 기간을 포함해야 합니다. 관련 전체 흐름은 agent retry 및 recovery 가이드를 참고하세요.

agent가 사람 없이 실행되기 전에

각 run의 범위를 제한하세요

  • 같은 action에 대한 tool call, wall-clock time, model spend, repeated attempt에 상한을 둡니다.
  • model이 스스로 단속하게 하지 말고 agent가 policy limit에 도달하면 중단합니다.
  • read tool보다 write tool에 더 좁은 limit를 적용합니다.
  • 반복되는 authorization 및 validation failure는 재시도하지 말고 escalate합니다.

rate limit는 agent가 일으킬 수 있는 damage를 줄이지만 unsafe permission을 수정하지는 않습니다. identity와 authorization을 구현한 다음 containment layer로 사용하세요.

model, agent, tool을 함께 추적하세요

user request, model call, tool selection, tool execution, downstream API work 전체에 trace 하나를 기록하세요. tenant, agent identity, tool name, tool-call ID, outcome, duration, policy decision을 포함합니다. secret과 sensitive tool result는 제외하세요.

OpenTelemetry는 이제 GenAI agent 및 tool span을 정의합니다. tool-call identifier와 duration attribute도 포함됩니다. 이 shared field를 사용하면 model 및 application telemetry 전체에서 action 하나를 더 쉽게 추적할 수 있습니다. AI agent observability 가이드는 실용적인 trace shape를 다룹니다.

중단과 recovery를 테스트하세요

  • model response 뒤뿐 아니라 완료된 external side effect 뒤에도 checkpoint를 저장합니다.
  • 전체 run을 replay하지 말고 마지막으로 검증된 checkpoint에서 resume합니다.
  • write를 retry하기 전에 unknown outcome을 reconcile합니다.
  • agent credential revoke와 active run 중단을 연습합니다.

unknown outcome은 server가 request를 완료했을 수 있지만 client가 response를 받지 못한 경우입니다. recovery 과정에서는 반복 실행을 결정하기 전에 operation record나 idempotency key를 확인해야 합니다.

usage가 확장되기 전에

반복 가능한 evaluation set를 유지하세요

대표 task, expected tool choice, prohibited action, acceptance criteria를 고정하세요. model, prompt, tool description, permission, retry behavior가 바뀌면 set를 실행합니다. 성공적인 demo는 위 control을 검증하지 않으므로 failure case도 포함하세요.

incident path를 문서화하세요

on-call path는 실패한 agent에 의존하지 않고 네 가지 질문에 답해야 합니다.

  1. 새 run을 어떻게 중단하는가?
  2. 영향을 받은 credential을 어떻게 revoke하는가?
  3. agent가 어떤 resource와 operation을 다뤘는가?
  4. 완료된 action을 어떻게 recover하거나 compensate하는가?

team이 telemetry와 backend state에서 이 질문에 답할 수 없다면 사람 없는 production work를 맡길 준비가 되지 않은 것입니다.

production 전에 workflow 하나를 감사하세요

permission이 가장 넓은 workflow를 고르세요. 모든 write에 대해 identity, authorization rule, idempotency mechanism, approval requirement, trace field, recovery action을 기록합니다. 빈 cell 하나하나가 구체적인 task가 되므로 일반 checklist를 더 만들 필요는 없습니다.

Write action Identity 및 scope Idempotency Approval Trace Recovery
예시: test deployment 삭제 deployment-scoped agent operation key test tenant 밖에서는 필수 tool call과 resource ID 48시간 restore

빈칸이 가장 많은 row를 고르세요. 그 workflow를 먼저 테스트해야 합니다. 아래 프롬프트는 isolated Cohesivity tenant를 만들고 정상 run 하나와 중단된 run 하나를 시도한 뒤 실패한 control을 보고합니다. Production은 대상이 아닙니다.