에이전틱 워크플로 설계: 데모 자동화에서 프로덕션 신뢰성으로

핵심 요점

• 데모가 진짜 워크플로가 되는 순간은, 나쁜 입력과 부분 실패, policy 경계를 만나도 위험한 즉흥 대응 없이 버틸 수 있을 때입니다.
• 핵심 설계 문제는 모델의 영리함이 아닙니다. 실행 전에 state, context, tool scope, approval, recovery 를 어떻게 정의하느냐입니다.
• 사람 리뷰는 약한 시스템을 위한 보조 장치가 아닙니다. 오히려 더 빨리 안전한 자동화를 배포하게 해주는 중요한 제어입니다.
• 신뢰할 수 있는 에이전틱 워크플로는 계획, 승인, 실행을 분리합니다. 같은 step 이 동시에 "판단"과 "행동"을 맡아서는 안 됩니다.
• puppyone 은 매번 흩어진 시스템에서 증거를 다시 조립하는 대신, 거버넌스된 context bundle 에 기대고 싶을 때 특히 유용합니다.

대부분의 에이전트 데모에 숨어 있는 운영자 문제

초기 에이전트 데모가 실제보다 더 좋아 보이는 이유는, 사람이 조용히 일부 작업을 대신하고 있기 때문입니다.

• 에이전트가 보기 전에 입력을 정리한다
• context 가 오래되었는지 알아챈다
• 어떤 tool 이 안전한지 판단한다
• 결과가 충분히 괜찮은지 판단한다
• 문제가 생기기 전에 실행을 멈춘다

그래서 첫 실서비스 투입에서 종종 "갑자기 망가졌다"는 느낌을 받습니다. 실제로는 신뢰성을 떠받치던 보이지 않는 인간 레이어가 사라졌을 뿐입니다.

좋은 에이전틱 워크플로 설계는 그래서 이런 질문에서 출발합니다.

운영자가 바쁘고 입력도 엉망이라면, 무슨 일이 벌어지는가.

이 질문에 대한 답이 "프롬프트가 알아서 해결한다"라면, 아직은 데모입니다.

Anthropic 의 effective context engineering for AI agents는 문제의 초점을 프롬프트 문구에서, 모델에게 실제로 전달되는 context state 전체로 옮겨 줍니다. 프로덕션 워크플로가 깨지는 지점도 바로 여기입니다. 모델이 문장을 "잊어서"가 아니라, 워크플로가 잘못된 state, 잘못된 tool, 혹은 아무 경계도 없는 실행 환경을 넘겨줬기 때문입니다.

프로덕션에서 먼저 점검할 여섯 가지 제어면

tool 을 더 늘리거나 agent persona 를 더 만들기 전에, 다음 여섯 가지 제어면을 먼저 분명히 해야 합니다.

이 표는 일부러 화려하지 않습니다. 신뢰할 수 있는 워크플로는 화려함보다 명확함으로 만들어집니다.

NIST 의 AI Risk Management Framework 역시 traceability, control, lifecycle management 를 계속 강조합니다. 에이전트 워크플로도 마찬가지입니다. 어떤 evidence 를 썼는지, 어떤 tool 이 열려 있었는지, 어떤 policy gate 가 적용되었는지, 왜 시스템이 계속되거나 멈췄는지를 설명할 수 있어야 합니다.

가장 중요한 분리선은 계획과 행동의 분리다

하나의 step 에 판단과 실행을 동시에 맡기는 것은 워크플로를 위험하게 만드는 가장 빠른 방법 중 하나입니다.

예를 들어 이런 식입니다.

• "티켓을 읽고 고객에게 최종 답변을 보낸다"
• "거래를 검토하고 환불을 승인한다"
• "문제를 요약하고 프로덕션 설정을 수정한다"

겉보기에는 효율적입니다. 하지만 실제로는 판단과 행동을 프롬프트 모양의 한 덩어리로 합쳐 버립니다.

더 강한 프로덕션 패턴은 다음과 같습니다.

1. evidence 를 수집한다
2. plan 을 제안한다
3. policy 를 확인하거나 approval 을 요청한다
4. 좁은 하나의 action 만 실행한다
5. audit record 를 남긴다

이 방식은 느려 보이지만, 실제로는 디버그하기 쉽고, 안전하게 배포할 수 있으며, 확장도 쉽습니다. 각 step 의 역할이 다르기 때문에 워크플로를 점검할 수 있게 됩니다.

"생각"과 "행동" 사이에서 review 가능한 artifact 를 만들 수 없다면, 그것은 설계상의 냄새입니다. artifact 는 작아도 됩니다.

• plan 요약
• 구조화된 diff
• 리스크 라벨
• confidence 와 evidence ID 를 포함한 action proposal

핵심은 관료주의가 아니라, side effect 가 발생하기 전에 decision seam 을 보이게 만드는 것입니다.

영웅 플레이가 아니라 재개 가능성을 위해 state 를 설계하라

프로덕션 워크플로는 기본적으로 재개 가능해야 합니다. 즉, 시스템은 무엇이 끝났는지, 무엇을 기다리는지, 무엇을 안전하게 다시 시도할 수 있는지를 알아야 합니다.

예시로는 다음과 같은 state shape 를 생각할 수 있습니다.

{
  "run_id": "wf_2026_04_02_1842",
  "status": "awaiting_approval",
  "current_step": "execute_change",
  "evidence_bundle_id": "ctx_8842",
  "proposal": {
    "action": "update_policy_exception",
    "reason": "ticket matches approved template",
    "confidence": 0.78
  },
  "approval": {
    "required": true,
    "requested_from": "ops-reviewers",
    "requested_at": "2026-04-02T14:20:00Z"
  },
  "side_effects": [
    {"step": "collect_context", "status": "complete"},
    {"step": "propose_plan", "status": "complete"}
  ]
}

중요한 것은 완벽한 schema 가 아니라, 명시성입니다.

이런 state 를 갖추면 다음이 가능해집니다.

• 실패한 한 step 만 재시도할 수 있다
• 운영자가 왜 pause 되었는지 바로 이해할 수 있다
• 사람은 chat history 전체가 아니라 compact 한 object 만 보면 된다
• audit log 가 action, evidence, decision state 를 연결할 수 있다

이것이 "에이전트가 알아서 기억하길 바란다"에서 "설계상 재개 가능하다"로 가는 전환입니다.

human-in-the-loop 는 decision seam 에 둘 때 가장 잘 작동한다

팀들은 종종 사람 승인을 너무 늦게, 그리고 잘못된 위치에 넣습니다. 에이전트가 읽은 모든 것을 사람이 다시 읽게 만들면, 자동화는 손작업으로 되돌아갑니다.

더 좋은 패턴은 비즈니스 리스크가 집중되는 seam 에 사람을 두는 것입니다.

• destructive write 이전
• 외부 커뮤니케이션 이전
• policy exception 이전
• 약한 evidence 를 바탕으로 action 하기 이전

그리고 리뷰어에게는 빠르게 판단할 수 있는 객체를 주어야 합니다.

사람 리뷰는 원래 워크플로를 손으로 다시 수행하기 위한 것이 아니라, 리스크를 제거하기 위한 것입니다.

리뷰어가 제안된 action 을 1분 안에 이해하지 못한다면, 문제는 대개 upstream 에 있습니다. context 가 너무 많거나, state 가 약하거나, action contract 가 불명확한 것입니다.

겉보기보다 프로덕션을 더 잘 버티는 워크플로 형태

신뢰할 수 있는 것을 배포하기 위해 거대한 orchestration platform 이 꼭 필요한 것은 아닙니다. 작지만 명시적인 워크플로만으로도 멀리 갈 수 있습니다.

trigger:
  source: inbound_request

steps:
  - collect_context
  - compact_evidence
  - propose_plan
  - check_policy
  - request_approval_if_needed
  - execute_one_narrow_action
  - write_audit_log
  - return_summary

fallbacks:
  on_missing_context: ask_for_more_input
  on_low_confidence: route_to_human
  on_tool_failure: retry_once_then_pause
  on_policy_violation: block_and_log

이 형태가 강한 이유는 세련되어서가 아니라, 각 step 이 하나의 일만 맡고 위험한 전환마다 clean 하게 멈출 수 있기 때문입니다.

첫 release 에는 이것만으로도 충분한 경우가 많습니다.

워크플로 신뢰성 스택에서 puppyone 이 들어가는 자리

많은 에이전틱 워크플로는 모델이 생각하기도 전에 실패합니다. 각 run 마다 너무 많은 시스템에서 evidence 를 다시 조립해야 하기 때문입니다.

• ticket system 에는 문제의 한 버전이 있다
• policy document 는 다른 곳에 있다
• 최신 exception note 는 chat 에 있다
• agent 는 중간중간 잘린 retrieval 조각 더미를 받는다

이것은 "agent reasoning" 의 실패라기보다 context assembly 의 실패입니다.

puppyone 은 각 step 이 매번 evidence 를 다시 모으는 대신, governed context bundle 을 소비하게 하고 싶을 때 유용합니다. 실제로는 다음을 돕습니다.

• step 간 context 일관성 유지
• 역할이나 tool 에 따라 다른 context slice 제공
• evidence bundle 이 이미 정리되어 있어 review 속도 향상
• 나중 검토를 위해 run state 와 stable context ID 연결

puppyone 이 workflow design 자체를 대신하는 것은 아닙니다. 다만 action 직전 context 가 흔들리는 큰 fragility source 를 줄여 줍니다.

version one 에서 먼저 잘라야 할 것들

프로덕션 수준의 agent workflow 를 만들고 싶다면, 출시 전에 다음을 먼저 제거하세요.

• "혹시 몰라서" 열어 둔 과도한 tool access
• review 가능한 중간 artifact 없이 바로 일어나는 autonomous write
• 같은 side effect 를 두 번 발생시킬 수 있는 retry logic
• 프롬프트에만 존재하는 approval rule
• 사람이 빠르게 검토할 수 없을 정도로 큰 context bundle

version one 은 작고, 읽기 쉽고, 멈추기 쉬워야 합니다.

데모가 보여 준 것보다 autonomy 가 적어도 괜찮습니다. bounded autonomy 가 더 신뢰하기 쉽고, 측정하기 쉽고, 개선하기 쉽기 때문입니다.

FAQ

Q1. 첫 에이전틱 워크플로를 배포하기 전에 workflow engine 이 꼭 필요할까요?

반드시 그렇지는 않습니다. 필요한 것은 명시적인 state, plan 과 action 의 분리, 그리고 confidence 가 낮거나 approval 이 필요할 때 clean 하게 pause 할 수 있는 경로입니다.

Q2. 에이전틱 워크플로 설계에서 가장 큰 실수는 무엇인가요?

너무 이른 시점에 autonomy 를 극대화하려는 것입니다. state, tool boundary, approval, recovery 가 정리되기 전에 그렇게 하면 화려한 데모와 fragile 한 프로덕션 동작만 남습니다.

Q3. 워크플로는 언제 사람에게 escalate 해야 하나요?

action 이 destructive 하거나, policy 민감하거나, confidence 가 낮거나, 되돌리기 어렵다면 그때입니다. 사람 리뷰는 side effect 이후가 아니라 decision seam 에 둘 때 가장 효과적입니다.