Deployment Pattern과 Graceful Failure

~28 min · deployment, queues, fallback

Level 0Observer

0 XP0/40 lessons0/12 achievements

0/100 XP to next level100 XP to go0% complete

agent가 어떻게 실행되는지가 제품을 바꿔

synchronous API agent, background worker, scheduled monitor, event-driven webhook agent는 failure mode가 다르다. prompt가 architecture를 해결했다고 착각하기 전에 deployment shape부터 골라.

long-running agent는 보통 queue나 job runner 뒤에 있어야 해. 사용자는 멈춘 request 대신 status, cancellation, partial result를 받는다.

graceful failure는 기능이다

agent가 실패하면 state를 보존하고, 무엇이 완료됐는지 설명하고, 무엇이 실패했는지 식별하고, next action을 제안하고, 성공한 척하지 않아야 해.

가장 좋은 failure mode는 human, 더 단순한 workflow, saved draft로 handoff하는 경우가 많다. silent failure는 배신이고, state가 있는 loud failure는 회복 가능하다.

Code

Failure response·json

{"status":"paused","completed":["read logs","identified failing migration"],"failed_step":"apply fix","reason":"database credentials unavailable","safe_next_action":"ask operator for staging DB access","resume_state_id":"run_42_checkpoint_7"}

External links

Exercise

research agent와 deployment agent의 deployment shape를 각각 골라봐. 왜 같은 방식으로 돌면 안 되는지 설명해.

Hint

latency, risk, cancellation, external side effect를 생각해.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousPrompt Injection과 Tool Security Next →퀴즈 · 4 questions

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.