승인 큐(Approval Queues)는 에이전트 기반 AI 워크플로우의 런타임이다 | Focused Labs

예외 큐(Exception queue)는 다음에 임베드해야 할 에이전트 인터페이스입니다.

지루하게 들릴 수도 있습니다. 예외 큐는 근본적으로 단순합니다. 모든 기업용 자율성(Enterprise autonomy)에 필요한 것은 에이전트가 검토 항목(예: 승인 항목)을 생성하고 자신의 상태를 보관(Park)하는 것입니다. 그런 다음 누군가가 결정을 내릴 때까지 기다렸다가, 결정이 완료되면 실행을 재개합니다. 만약 AI 에이전트 워크플로우가 누군가가 물리적으로 존재하여 AI를 "검토"하는 것(예: 채팅을 계속 주시하는 것)에 의존한다면, 그것은 단순히 일을 하기 위해 안전모를 쓴 또 다른 채팅 앱에 불과할 것입니다.

LangChain의 Listen, Act, Ask(알림, 질문, 검토)라는 앰비언트 에이전트(Ambient-agent) 프레임워크는 여기서 잘 적용됩니다. 이러한 앰비언트 에이전트들은 이벤트 스트림(Event streams)을 경청하고, 백그라운드에서 동작하며, 상황에 따라 알림(Notify), 질문(Question), 또는 검토(Review)를 위해 적절한 시점에 인간에게 요청하기 때문입니다 ambient agents listen to event streams, act in the background, and ask for notify, question, or review at the right moments.

이 지루한 객체는 승인 항목(Approval items)을 위한 프로덕션 설계의 중심에 있습니다.

이 항목은 작업(Action), 작업에 대한 인자(Arguments), 리스크 사유(Risk reason), 항목의 소유자(Owner), 허용된 결정(Decisions), 체크포인트 포인터(Checkpoint pointer), 트레이스 링크(Trace link), 항목에 대한 타임아웃(Timeout), 항목에 대한 에스컬레이션 경로(Escalation path), 그리고 마지막으로 항목이 승인되었을 때의 영수증(Receipt)을 반드시 포함해야 합니다. 이러한 정보 세트가 없다면 항목에 대한 검토는 그저 버튼을 누르는 것에 불과합니다. 하지만 이 정보 세트가 있다면, 승인 큐(Approval queue)는 런타임(Runtime)이 제어권을 인간에게 전달했다가 다시 깔끔하게 회수하는 장소가 됩니다.

인터페이스의 변화는 런타임의 변화입니다. 작업은 이벤트로부터 시작되며, 그 후 정책(Policy)이 어떤 작업에 큐가 필요한지를 결정합니다.

에이전트는 추상적으로 일시 정지하지 않는다

프로덕션 에이전트는 정확한 경계(Boundary)에서 일시 정지합니다.

이메일을 보내고 싶어 합니다. CRM 레코드를 업데이트하고 싶어 합니다. 데이터베이스 마이그레이션 (Database Migration)을 실행하고 싶어 합니다. 고객에게 환불을 해주고 싶어 합니다. "인간 참여 (Human-in-the-loop)"라는 문구는 단순히 체크박스 하나로 평면화되어 버렸습니다. 유용한 설계 질문은 모델이 비즈니스 리스크를 수반하는 부작용 (Side effect)을 제안할 때 런타임 (Runtime)이 무엇을 하느냐 하는 것입니다.

현재의 인간 참여 (Human-in-the-loop) 미들웨어는 도구 호출 정책 (Tool-call policy)으로 구현되어 있습니다. 따라서 HumanInTheLoopMiddleware, interrupt_on, 그리고 approve, edit, reject, respond와 같은 허용된 결정들`에 대한 문서는 모두 도구 호출 정책 문제로서 타당합니다. 즉, 모델이 행동을 제안하면 정책이 해당 행동을 실제로 실행할 수 있는지 결정하고, 인간의 결정이 구조화된 입력 (Structured input)으로서 그래프 (Graph)로 반환되는 방식입니다. 그리고 이 입력은 단순히 "느낌적인 느낌으로, 여기에 인간을 참여시켜서 어떻게 하는지 지켜보자"가 아니라 구조화되어 있습니다.

반면에, 프로덕션 에이전트의 런타임을 살펴보면, (HITL을 위해서도 사용되는) LangGraph의 인터럽트 (Interrupt) 모델이 런타임을 무시하기 더욱 어렵게 만든다는 것을 알 수 있습니다. HITL 요청에 의해 그래프 실행이 중단되는 동안 모든 상태 (State)는 저장되며, 요청은 지속성 계층 (Persistence layer)을 통해 처리됩니다. 그런 다음 런타임은 외부로부터의 입력을 무기한 기다리며, 그 이후에는 Command(resume=...)를 사용하여 중단되었던 지점부터 동일한 스레드, 즉 동일한 세션에서 그래프 실행이 재개됩니다. 여기서 thread_id는 실행이 중단된 스레드(즉, 세션)의 ID입니다. 인터럽트는 그래프 실행을 일시 중지하고, 지속성 계층을 통해 상태를 저장하며, 외부 입력을 무기한 기다린 다음, 동일한 thread_id를 사용하는 Command(resume=...)를 통해 재개합니다. 이것이 바로 큐 세맨틱스 (Queue semantics)입니다. 작업 단위가 일시 중지되고, 상태가 저장된 후에야 비로소 승인을 요청하는 것입니다.

OpenAI 또는 OpenAI의 Agents SDK도 유사한 접근 방식을 취했습니다. 이들의 Human-in-the-loop 흐름은 민감한 도구 호출(tool calls)을 중단(interruptions)으로 일시 중지하고, 결과를 RunState로 변환하며, 승인 또는 거절 후에 정확히 동일한 실행(run)을 재개합니다.

승인 항목(Approval item)이 진정한 인터페이스입니다

저는 UI가 너무 단순해 보인다는 이유로, 팀들이 액션(action)에 대한 승인 기능을 미흡하게 구축하는 것을 보았습니다. 단순히 목록, 카드, 생성·수정·삭제를 위한 세 개의 버튼, 그리고 아마도 차이점(diff) 정도가 있는 식이죠.

우리는 승인 액션을 위한 큐 항목(queue item)을 해당 액션에 대한 정전적 표현(canonical representation)으로 취급합니다. 해당 항목은 애초에 왜 이 액션이 승인을 위해 큐에 들어갔는지에 대한 정보를 포함해야 합니다. 해당 액션에 대해 전달된 원래의 인자(arguments) 정보를 포함해야 합니다. 에이전트가 내린 권장 사항(recommendation)에 대한 트레이스(trace)를 포함해야 합니다. 이 항목에 대해 누가 액션을 취할 수 있는지에 대한 정보를 포함해야 합니다. 이 도구에 대해 허용되는 액션 세트를 설명해야 합니다. 이 액션의 인자를 수정하는 것이 안전한지, 아니면 액션의 전체 브랜치(branch)를 통째로 거절할 것인지에 대한 결정을 내려야 합니다. 결정이 내려진 후에는 요약본으로부터 새로운 실행을 시작하는 대신, 동일한 그래프 상태(graph state)를 재개해야 합니다.

진정한 승인 항목은 나중에 재개(resume), 감사(audit), 그리고 결정으로부터 학습(learn)할 수 있을 만큼 충분한 상태(state)를 보유해야 합니다.

따라서 도구 호출 전 정책(policy before the tool call)에서 도구를 호출하기 전의 정책 결정은, 앱의 구석에 있는 일반적인 "승인(approval)" 모달창이 아니라, 실행 경계(action boundary) 내에 강력하게 내장된 승인 큐(approval queue)를 갖는 것이 중요합니다. 승인 큐는 신원(identity), 권한(permissions), 현재의 상태(state), 팀이 실행 중인 트레이스(trace), 그리고 이 승인의 결과로 팀이 수행하는 모든 작업의 부수 효과(side effects)가 모두 포함되는 곳이어야 합니다.

취약한 승인 항목은 "이메일을 승인하시겠습니까?"라고 표시되겠지만, 강력한 승인 항목은 다음과 같이 표시될 것입니다: "티켓 18422에서 생성되었고, 환불 관련 문구를 포함하며, 외부 통신 정책을 위반함. 수신자는 지원 팀장(support lead)이며, 허용된 결정은 승인, 수정, 거절임. 타임아웃은 영업일 기준 4시간, 체크포인트는 thread-9f2, 트레이스가 연결되어 있으며, 최종 영수증은 고객 기록에 첨부될 예정임. acct@example.com으로 이메일 발송."

이러한 차이는 첫 번째 사고가 발생하기 전까지는 단순한 사무적 차이처럼 보입니다.

사고가 발생한 후에는, 큐 레코드(queue record)가 공유 레코드(the shared record)가 됩니다. 해당 레코드에는 승인된 작업(approved action), 제안된 작업(proposed action), 변경 사항, 해당 작업을 큐에 넣은 정책(policy), 그래프(graph)가 올바르게 재개되었는지 여부, 그리고 도구 호출 후 영수증(receipt)이 저장되었는지 여부가 포함됩니다. 이 모든 질문들이 해당 워크플로우(workflow)가 운영 가능한(operable) 것인지, 아니면 단순히 운이 좋았던 것인지를 결정합니다.

자율성(Autonomy)에는 이미 개입(intervention)이 포함되어 있습니다

실제 운영 데이터가 이를 뒷받침합니다. MAP 논문인 "운영 환경에서의 에이전트 측정(Measuring Agents in Production)"에서 저자들은 306명의 실무자 설문 조사와 26개 도메인에서의 20개 상세 사례 연구를 보고했습니다. 설문 조사 결과, 운영 중인 에이전트의 68%가 인간의 개입이 있기 전까지 10단계 이하의 단계를 실행하며, 74%가 주로 인간의 평가에 의존하는 것으로 나타났습니다.

기업에서의 에이전트(Agents) 사용 시 에이전트는 경계가 있는 시스템(bounded systems)입니다. 즉, 이들은 "다음 불확실성 / 정책 경계 / 되돌릴 수 없는 행동 / 누락된 컨텍스트 / 책임 소재의 단절이 발생하기 전까지" 유효합니다. 그리고 이러한 핸드오프(handoff)는 저렴하고, 정밀하며, 검토 가능해야 합니다.

배포 후에도 에이전트 평가(Agent evaluation)는 프로덕션 에이전트가 실행 중인 규칙과 정책이 올바른지 확인하기 위해 계속되어야 합니다 [배포 후에도 에이전트 평가가 계속되어야 함]. 승인 결정은 워크플로우 내 다른 구성원들을 위한 프로덕션 라벨(production labels)이 됩니다. 수정(Edits)은 프롬프트의 공백을 보여줍니다. 거절(Rejections)은 정책의 허점을 보여줍니다. 타임아웃(Timeouts)과 오류(errors)는 소유권 문제나 리스크 라우팅(risk routing) 실수를 보여줍니다. 큐(queue) 그 자체가 프로덕션 에이전트의 워크플로우를 개선하기 위한 데이터 소스가 됩니다.

HumanLayer의 12 Factor Agents는 다른 각도에서 동일한 아키텍처 관점을 제시합니다: 프로덕션급 에이전트는 범위가 지정된 결정 지점(scoped decision points)에서 LLM을 사용하는 결정론적 소프트웨어(deterministic software)로서 작동할 때 더 잘 작동합니다 [프로덕션급 에이전트는 범위가 지정된 결정 지점에서 LLM을 사용하는 결정론적 소프트웨어로서 더 잘 작동함]. 검토 큐(review queue)는 이러한 결정론적 구성 요소 중 하나입니다. 모델이 경계 내부의 모호성(ambiguity)을 처리하는 동안, 검토 큐는 제어 흐름(control flow)을 소유합니다.

승인 피로(Approval fatigue)는 설계 실패입니다

모든 행동은 프롬프트로 던져질 수 있으므로, 검토자는 그저 권한 프롬프트를 클릭하며 지나가게 됩니다. Anthropic이 최근 코드를 생성하기 위한 Claude Code를 오토 모드(auto mode)로 도입하며 공개적으로 고백한 암묵적인 사실과, 권한 프롬프트의 승인 통계는 다음과 같습니다: 93% [Claude Code 사용자는 권한 프롬프트의 93%를 승인함]. 이토록 안전이 중요한 활동에 대한 승인 시스템은, 사용자가 창(window)을 하나씩 넘기며 연극 같은 상황을 반복하는 동안 주의력이 감퇴하는 와중에, 마치 안전한 일을 하고 있는 것처럼 연기하도록 요구하는 것에 불과합니다.

안전을 위한 격리 (Containment)는 인간 검토자의 위험을 줄이고 폭발 반경 (blast radius)을 제한하는 것에 관한 것입니다. Anthropic은 동일한 격리 지점에 대해 다음과 같이 기술했습니다: 인간의 감독 (human supervision)은 위험을 줄이지만, 폭발 반경 제어는 샌드박스 (sandboxes), 파일 시스템 제한 (filesystem limits), 네트워크 송신 규칙 (network egress rules), 자격 증명 경계 (credential boundaries), 그리고 제품별 격리 (product-specific containment)를 통해서도 이루어집니다.

저위험 작업은 흐름 (flow)을 타고, 중위험 작업은 배치 (batch) 처리되며, 고위험 작업은 인간 소유자 (human owner)의 흐름을 중단 (interrupt)시키고, 금지된 작업은 검토자에게 도달하기 전에 소멸합니다. 위험 라우팅 (risk routing) 기능이 있는 승인 큐 (approval queue)는 실제 시스템에서 작동하는 에이전트를 둘러싼 에이전트 제어 평면 (agent control plane): 레지스트리 (registry), ID (identity), 정책 (policy), 관측 가능성 (observability), 비용 (cost), 소유권 (ownership), 그리고 은퇴 (retirement)의 일부가 됩니다.

승인 정책 (approval policy)은 또한 검토자가 무엇을 할 수 있는지 기술해야 합니다. '승인 (Approve)'만으로는 충분하지 않습니다. 코드 상에서 '수정 (Edit)', '거절 (Reject)', '응답 (Respond)'은 서로 다른 의미를 갖습니다. LangChain 문서는 이 모든 것을 설명합니다.

소유자는 워크플로우를 실행하는 팀입니다

모델 제공업체 (Model providers)는 워크플로우에서 사용할 승인 프리미티브 (approval primitives)를 보낼 것이고, 프레임워크 (frameworks)는 지속 가능한 일시 중지 및 재개를 위한 인터럽트 (interrupts)를 노출할 것이며, 플랫폼 (platforms)은 데모에서 보기 좋은 검토 화면을 제공할 것입니다.

그다음 워크플로우의 큐 정책 (queue policy)은 비즈니스 프로세스 (business process)와도 일치해야 합니다. 영업 이메일, 결제 승인, 데이터베이스 변경 또는 취약점 수정은 동일한 승인 프로세스를 공유해서는 안 됩니다. 이러한 작업들은 서로 다른 소유권, 위험, 증거, 롤백 경로 (rollback paths), 그리고 감사 요구 사항 (audit needs)을 가집니다. 모델 제공업체는 이러한 조직적 지식 (organizational knowledge)을 모델에 구현하여 프레임워크에 승인 프리미티브를 전달할 수 없습니다.

고객 대면 작업 (customer-facing actions)은 실패 사례를 포함하는 하나의 패키지로 승인됩니다. 여기에는 생성된 출력물 (generated output), 해당 출력물로 수행된 작업, 승인자, 영수증을 수신하는 기록 시스템 (system of record), 그리고 사후 지원 대응 방식이 포함됩니다. 우리는 이미 이에 대해 상세히 다룬 바 있습니다: 고객 대면 작업에는 승인 경로가 필요합니다.

저는 계속해서 같은 실수를 반복하고 있습니다. 화려하고 수준 높은 부분만 보여주고 지루한 구현 세부 사항은 빠뜨리는 것입니다. 큐 항목 (queue item)을 모델 컨텍스트 (model context) 외부에 저장하십시오. 모든 결정에 트레이스 (trace)를 부착하십시오. 각 결정에 소유자를 지정하십시오. 전후 상태를 모두 캡처하십시오. 도구 영수증 (tool receipt)과 재개된 체크포인트 (resumed checkpoint)를 기록하십시오. 타임아웃 (timeouts)과 에스컬레이션 (escalation)을 열어보지 않는 실행 지침서 (runbook)에 두지 말고 큐 (queue)에 넣으십시오. 수정 사항과 거부 사항을 전체 감사 로그 (audit log)와 함께 평가 (evals)로 다시 피드백하십시오.