승인 워크플로

실무에서는

승인 워크플로는 워크플로 소프트웨어보다 훨씬 오래되었습니다. 구매 요청, 변경 자문 위원회, 여신 위원회, 임상 시험 승인은 모두 같은 패턴을 담고 있습니다. 진짜 승인 워크플로와 그렇게 보이기만 하는 알림을 가르는 성질은 세 가지입니다. 첫째, 요청이 대기 중인 동안 변경이 실제로 막혀야 합니다. 이메일이 읽히지 않은 채 놓여 있는 사이에 일이 그대로 진행되어서는 안 됩니다. 둘째, 결정은 공유 메일함이 아니라, 결정하던 그 순간에 권한을 가지고 있던 한 사람에게 귀속될 수 있어야 합니다. 셋째, 라우팅은 이름이 아니라 조직을 기준으로 해석되어야 합니다. 특정 사람에게 묶인 결재선은 다음 조직 개편 때 조용히 끊어지고, 이미 퇴사한 사람에게로 요청을 보내게 됩니다. 이 중 어느 것도 충족하지 못하는 프로세스는 지연이 붙은 알림일 뿐입니다.

ObjectStack에서 승인은 별도의 시스템이 아니라 플로우 안의 지속(durable) 노드입니다. 실행이 승인 노드에 도달하면 요청을 열고 일시 중단되었다가, 결정이 기록되면 approve 또는 reject 출력 엣지를 따라 재개됩니다. 승인자는 사용자, 역할, 팀, 또는 요청자의 관리자 계층으로 선언되며, 요청 시점에 실시간 신원 정보를 기준으로 해석됩니다. 직위는 현재 그 직위를 맡고 있는 사람으로 확장됩니다. 각 단계는 자체 동작을 설정하므로, 한 노드는 "첫 응답 우선", 다음 노드는 "만장일치"로 둘 수 있습니다. lockRecord는 레코드를 고정해 누구도 검토자를 건너뛰고 편집하지 못하게 하고, maxRevisions는 반려 후 재제출 루프에 상한을 두어 요청이 "수정해 주세요" 주위를 영원히 맴돌지 않게 하며, onEmptyApprovers는 승인자 명단이 아무도 없는 것으로 해석될 때의 처리를 정합니다. 기본값은 레코드를 조용히 통과시키는 것이 아니라 관리자에게 넘겨 구제하게 하는 것입니다. 결정은 실행이 진행되기 전에 감사 로그에 기록되므로, 결정이 기록되지 않은 채 승인을 지나치는 경로는 존재하지 않습니다. 승인 노드가 담는 것은 할인, 환불, 구매 같은 비즈니스 결정입니다. AI가 앱 자체에 가하는 변경은 다른 경로로 사람에게 전달됩니다. 오픈 소스 ObjectStack에서 코딩 에이전트의 변경은 누군가 리뷰하는 git diff 속 메타데이터이고, ObjectOS Cloud에서 이미 레코드를 보유한 운영 중인 앱에 대한 AI Builder의 변경은 사람이 게시할 초안으로 저장됩니다. 바로 이 점이 에이전트가 작성한 소프트웨어를, 나중에야 발견하는 무언가가 아니라 사람이 서명할 수 있는 무언가로 만듭니다.

어떤 승인 엔진에든 던져 볼 만한 질문은 그 기한이 어디에 있느냐이며, 여기서 정직한 답은 범위가 좁습니다. 플로우의 wait 노드에는 타임아웃이 전혀 없습니다. 한때 두 개의 키가 그렇지 않다고 주장했지만, 둘 다 런타임이 지키지 않는 약속으로 남겨 두는 대신 폐기되었습니다. 에스컬레이션은 승인 노드에만 존재하며, 전역 타이머 서비스가 아니라 노드별 SLA입니다. timeoutHours를 설정하면 주기적인 스윕이 생성 후 그 시간을 넘기고도 대기 중인 요청을 찾아, 각 요청을 통틀어 단 한 번만 에스컬레이션하고 설정된 action — notify, reassign, auto_approve, auto_reject — 을 수행합니다. escalateTo는 사용자를 지정하거나, 현재 맡고 있는 사람으로 확장되는 직위를 지정합니다. 에스컬레이션 감사 행이 먼저 기록되므로, 스윕이 중간에 죽거나 반복 실행되어도 이중으로 발동하지 않습니다. 설계상의 결론은 분명히 말해 둘 가치가 있습니다. 어떤 단계에 시간 제한이 꼭 필요하다면, SLA가 붙은 승인으로 모델링하거나 플로우 바깥에서 기한을 구동하십시오. 평범한 wait는 끈기 있게, 정확하게, 그리고 영원히 기다릴 것입니다.