대부분의 승인 자동화는 리마인더(Reminder)에서 시작됩니다.

항목이 제출됩니다. 마감 기한이 다가옵니다. 시스템은 누군가에게 승인을 요청하는 이메일이나 Slack 알림을 보냅니다.

그것이 수동으로 추적하는 과정을 조금 줄여줄 수는 있겠지만, 완전한 **비즈니스 자동화 워크플로 (Business Automation Workflow)**는 아닙니다.

진정한 승인 워크플로는 무엇이 승인되고 있는지, 어떤 버전이 최신인지, 누구에게 권한이 있는지, 요청이 어떤 상태에 있는지, 결정 후에 어떤 일이 발생하는지, 그리고 무언가 실패했을 때 시스템이 어떻게 복구되는지를 반드시 알고 있어야 합니다.

그러한 제어 장치 없이는, 자동화는 그저 불명확한 프로세스 주변에 리마인더를 뿌리는 것에 불과합니다.

요약 (TL;DR)

실제 운영되는 승인 워크플로는 다음을 포함해야 합니다:

• 명시적인 상태 (Explicit states) 및 유효한 전이 (Valid transitions)
• 지속되는 워크플로 컨텍스트 (Persisted workflow context)
• 버전 관리되는 승인 패키지 (Version-controlled approval packages)
• 역할 및 권한 확인 (Role and authority checks)
• 마감 기한 및 에스컬레이션 (Escalation) 규칙
• 멱등성(Idempotent)을 가진 다운스트림 작업
• 완전한 감사 이력 (Audit history)
• 중대한 결정을 위한 인간 체크포인트 (Human checkpoints)

AI 에이전트는 정보를 준비하고, 누락된 컨텍스트를 감지하며, 후속 조치 초안을 작성할 수 있습니다. 하지만 허용되는 작업이 무엇인지는 여전히 결정론적(Deterministic)인 워크플로 로직이 제어해야 합니다.

승인 객체(Approval Object)부터 시작하기

알림을 설계하기 전에, 시스템이 실제로 추적하고 있는 것이 무엇인지 정의하십시오.

승인은 단순히 프로젝트에 부착된 상태 필드 그 이상이어야 합니다.

유용한 승인 객체는 다음과 같은 내용을 포함할 수 있습니다:

• 승인 ID (Approval ID)
• 프로젝트 ID (Project ID)
• 결정 카테고리 (Decision category)
• 현재 문서 버전 (Current document version)
• 요청 사용자 (Requesting user)
• 책임 승인자 (Responsible approver)
• 제출 타임스탬프 (Submission timestamp)
• 필수 응답 날짜 (Required response date)
• 현재 상태 (Current state)
• 상업적 또는 일정 영향 (Commercial or schedule impact)
• 관련 파일 (Related files)
• 댓글 및 결정 이력 (Comments and decision history)
• 실행을 위한 다운스트림 작업 (Downstream action to release)

이것은 워크플로에 안정적인 신뢰할 수 있는 단일 원천 (Source of truth)을 제공합니다.

고객이 바닥재 교체를 승인해야 하는 상업용 인테리어 프로젝트를 생각해 보십시오. 원래 선택한 자재가 설치 날짜를 맞출 수 없기 때문에 공급업체가 다른 자재를 제안했습니다.

이 워크플로는 단순히 "고객이 승인했는가?"라고 묻는 것이 아닙니다.

제안된 자재, 사양(specification), 비용 차이, 리드 타임(lead-time)에 미치는 영향, 증빙 파일 및 의사 결정권자의 권한을 반드시 보존해야 합니다.

버튼이 아닌 모델 상태 (Model States, Not Buttons)

인터페이스는 보통 다음과 같은 버튼으로 시작합니다:

• 제출 (Submit)
• 승인 (Approve)
• 거절 (Reject)
• 수정 요청 (Request revision)

하지만 버튼은 액션(action)입니다. 워크플로에는 상태(state)가 필요합니다.

자재 승인은 다음과 같은 단계를 거칠 수 있습니다:

초안 (draft) → 제출됨 (submitted) → 내부 검토 (internal_review) → 고객 승인 대기 중 (client_approval_pending) → 승인됨 (approved) → 조달 해제 (procurement_released) → 종료 (closed)

대안적인 전이(transition)로는 다음이 포함될 수 있습니다:

고객 승인 대기 중 (client_approval_pending) → 수정 요청됨 (revision_requested)

고객 승인 대기 중 (client_approval_pending) → 거절됨 (rejected)

고객 승인 대기 중 (client_approval_pending) → 만료됨 (expired)

각 전이는 다음 사항을 정의해야 합니다:

• 어떤 액터(actor)가 이를 시작할 수 있는지
• 어떤 정보가 필요한지
• 어떤 검증(validation)을 통과해야 하는지
• 어떤 이벤트(event)가 방출(emit)되어야 하는지
• 어떤 다음 액션(next actions)이 사용 가능해지는지

이를 통해 오래되었거나 거절된 승인으로부터 조달을 해제하는 것과 같은 잘못된 작업(invalid operations)을 방지할 수 있습니다.

대기 상태의 영속화 (Persist the Waiting State)

승인은 장기 실행 워크플로(long-running workflows)입니다.

사람은 10분 만에 응답할 수도 있고, 이틀 또는 이주일 뒤에 응답할 수도 있습니다. 워크플로는 대기하는 동안 요청이 메모리 내에서 활성 상태로 남아 있는 것에 의존할 수 없습니다.

시스템은 다음 사항을 영속화(persist)해야 합니다:

• 현재 상태 (current state)
• 승인 패키지 (approval package)
• 마지막으로 성공한 단계 (last successful step)
• 미결 마감 기한 (outstanding deadlines)
• 응답할 것으로 예상되는 액터 (actor expected to respond)
• 대기 중인 다운스트림 액션 (pending downstream actions)

승인자가 응답할 때, 워크플로는 이메일이나 로그로부터 프로세스를 재구성하는 대신 기록된 상태로부터 재개되어야 합니다.

이는 애플리케이션이 재시작되거나, 워커(worker)가 충돌하거나, 통합(integration)이 일시적으로 사용할 수 없는 경우에도 중요합니다.

내구성이 있는 워크플로(durable workflow)는 비즈니스 컨텍스트(business context)를 잃지 않고 계속 진행될 수 있어야 합니다.

의사 결정 패키지의 버전 관리 (Version the Decision Package)

버전 관리(version control) 없는 승인은 위험합니다.

고객이 도면 버전 3을 승인하는 동안 프로젝트 팀은 이미 버전 4를 배포했을 수도 있습니다. 리마인더 (Reminder)가 이전 파일로 연결될 수도 있습니다. 구매 부서 (Procurement)는 어떤 사양 (Specification)이 확정되었는지 모르는 상태에서 승인 알림을 받을 수도 있습니다.

모든 제출물은 불변의 승인 버전 (Immutable approval version)을 생성해야 합니다.

수정된 패키지는 다음과 같은 고유한 요소를 가진 새로운 버전이 되어야 합니다:

• 문서 (Documents)
• 제출 날짜 (Submission date)
• 결정 상태 (Decision status)
• 코멘트 (Comments)
• 변경 요약 (Change summary)

시스템은 이미 검토가 완료된 승인의 내용을 조용히 교체해서는 안 됩니다.

결정이 내려질 때, 해당 결정은 담당자가 확인했던 정확한 버전을 참조해야 합니다.

마감 기한을 워크플로 이벤트로 취급하라

마감 기한 (Due date)은 단순히 행의 색상을 빨간색으로 바꾸는 것 이상의 역할을 해야 합니다.

마감 기한에 도달했을 때, 워크플로 (Workflow)는 그 결과 (Consequence)를 평가해야 합니다.

예를 들어:

• 구매 부서 (Procurement)가 현재 차단되었는가?
• 현재 가격 견적 (Price quotation)이 곧 만료되는가?
• 건설 활동이 이 결정에 의존하고 있는가?
• 요청을 다른 승인자 (Approver)에게 넘겨야 하는가?
• 프로젝트 매니저 (Project manager)가 직접 개입해야 하는가?

다음 조치는 비즈니스 영향 (Business impact)에 따라 달라져야 합니다.

리스크가 낮은 장식 선택 (Decorative selection)은 추가 리마인더 (Reminder)만으로 충분할 수 있습니다. 현장 작업에 영향을 미치는 리드 타임이 긴 자재 (Long-lead material)는 즉각적인 에스컬레이션 (Escalation)이 필요할 수 있습니다.

운영 영향에 대한 더 자세한 맥락은 고객 승인 지연이 상업 프로젝트에 미치는 영향을 참조하십시오.

커맨드와 이벤트를 분리하라

커맨드 (Command)는 시스템에 특정 동작을 수행하도록 요청합니다:

Approve request (요청 승인)

이벤트 (Event)는 무언가가 발생했음을 기록합니다:

ApprovalGranted (승인됨)

이러한 구분은 다운스트림 자동화 (Downstream automation)를 더 쉽게 제어할 수 있게 해줍니다.

승인이 완료되면, 별도의 컨슈머 (Consumers)들이 다음과 같은 작업을 수행할 수 있습니다:

• 프로젝트 레지스터 (project register) 업데이트
• 조달 (procurement) 부서 통지
• 구매 주문서 (purchase order) 준비
• 프로그램 (programme) 업데이트
• 현장 팀 (site team) 통지
• 빌링 마일스톤 (billing milestone) 해제
• 승인된 문서 아카이브 (archive)

승인 서비스 (approval service)는 응답을 반환하기 전에 이러한 모든 작업을 동기적 (synchronously)으로 완료할 필요가 없어야 합니다.

대신, 명령을 검증하고, 상태 전이 (state transition)를 커밋하며, 다음 프로세스를 위한 이벤트를 발행 (emit)할 수 있습니다.

다운스트림 작업 (Downstream Actions)을 멱등하게 (Idempotent) 만들기

이벤트는 여러 번 전달될 수 있습니다. 사용자는 버튼을 더블 클릭할 수 있습니다. 통합 (Integrations) 시스템은 타임아웃 후 재시도할 수 있습니다.

워크플로 (workflow)는 중복이 발생할 수 있음을 가정해야 합니다.

만약 ApprovalGranted가 두 번 처리된다면, 시스템은 두 개의 구매 주문서를 생성하거나 상충하는 업데이트를 보내서는 안 됩니다.

모든 다운스트림 작업에는 일반적으로 다음을 기반으로 하는 멱등성 (idempotency) 규칙이 필요합니다:

• 승인 ID (approval ID)
• 승인 버전 (approval version)
• 이벤트 ID (event ID)
• 작업 유형 (action type)

시스템은 해당 작업이 이미 완료되었음을 인식하고 중복된 요청을 안전하게 무시해야 합니다.

워크플로 내부에 인간의 권한 (Human Authority) 배치하기

인간 참여형 (Human-in-the-loop) 자동화는 단순히 승인 버튼을 누르는 것만이 아닙니다.

워크플로는 해당 인물이 다음 사항을 충족하는지 확인해야 합니다:

• 해당 결정에 대한 권한을 보유하고 있는가
• 현재 버전을 승인하고 있는가
• 관련 비용 및 프로그램 (programme)에 미치는 영향을 확인할 수 있는가
• 요청이 만료되기 전에 조치를 취하고 있는가
• 거절하거나 수정을 요청할 때 사유를 제공했는가

승인 인터페이스 (approval interface)는 정보에 기반한 의사결정을 지원할 수 있도록 충분한 컨텍스트 (context)를 보여주어야 합니다.

“이 요청을 승인하십시오”라는 알림은 빠른 클릭을 유도할 뿐, 반드시 신뢰할 수 있는 승인을 보장하지는 않습니다.

AI 에이전트 (AI Agents)의 역할

AI 에이전트는 워크플로의 제어 장치를 대체하는 것이 아니라, 워크플로 주변에서 유용하게 활용됩니다.

에이전트는 다음과 같은 일을 할 수 있습니다:

• 승인 패키지 요약 (summarise the approval package)
• 누락된 문서 또는 필드 식별 (identify missing documents or fields)
• 현재 버전과 이전 버전 비교 (compare the current version with the previous one)
• 문맥을 고려한 후속 조치 초안 작성 (draft a context-aware follow-up)
• 이메일 회신에서 결정 사항 추출 (extract a decision from an email response)
• 댓글을 승인, 거절 또는 수정으로 분류 (classify comments as approval, rejection or revision)
• 상충하는 정보 표시 (flag conflicting information)
• 승인 지연 보고서 작성 (prepare an overdue-approval report)

하지만 에이전트가 단순히 메시지를 긍정적으로 해석했다는 이유만으로 최종 비즈니스 상태를 직접 변경해서는 안 됩니다.

결정론적 검증 계층 (deterministic validation layer)은 상태 전환을 실행하기 전에 승인자, 버전, 권한 및 필수 정보를 확인해야 합니다.

에이전트는 비정형 정보 (unstructured information)를 해석합니다.

워크플로 엔진 (workflow engine)은 비즈니스 규칙을 강제합니다.

자동화와 제어의 차이

리마인더 (reminders)를 보내는 것은 쉽습니다.

신뢰할 수 있는 비즈니스 프로세스 워크플로 자동화 시스템을 구축한다는 것은 대기, 수정, 권한, 재시도, 중복, 마감일, 실패 및 다운스트림 의존성 (downstream dependencies)을 모두 고려함을 의미합니다.

그러한 아키텍처는 내부 프로젝트를 훨씬 넘어 적용됩니다.

동일한 패턴이 다음 항목에도 적용됩니다:

• 구매 요청 (purchase requests)
• 송장 승인 (invoice approvals)
• 계약 검토 (contract reviews)
• 채용 결정 (hiring decisions)
• 비용 청구 (expense claims)
• 변경 요청 (change requests)
• 콘텐츠 게시 (content publishing)
• 프로덕션 배포 (production deployments)

도메인은 변하지만, 근본적인 워크플로 요구사항은 변하지 않습니다.

이 아키텍처가 반복적인 조율을 어떻게 제거할 수 있을지 평가하는 팀을 위해, AI Agents Playbook은 인간의 판단을 배제하지 않고도 자동화할 수 있는 승인, 조달, 후속 조치 및 프로젝트 보고 프로세스를 정리해 두었습니다.