AI 에이전트 승인 큐 실전 가이드 2026: 자동 실행보다 사람 승인·대기 상태·재시도 경계를 먼저 설계해야 하는 이유

발행일: 2026-07-06 | 카테고리: ai활용법

1. 한 줄 문제 정의

핵심 한 줄: AI 에이전트 운영의 진짜 위험은 답변 생성이 아니라, 검증되지 않은 행동이 그대로 실행되는 순간에 생깁니다.

AI 에이전트는 이제 이슈를 맡아 코드를 고치고, PR을 열고, 리뷰를 남기고, 외부 도구를 호출합니다. 그래서 실무자가 먼저 풀어야 할 문제는 “에이전트가 똑똑한가”가 아니라 “어떤 행동은 자동 실행하고, 어떤 행동은 사람 승인을 기다리게 할 것인가”입니다.

이 글의 대상 독자는 업무 자동화, 코딩 에이전트, 내부 운영 봇, 고객 대응 에이전트를 실제 제품이나 팀 프로세스에 넣으려는 개발자와 PM입니다. 적용 범위는 이메일 발송, 데이터 변경, PR 생성, 배포 요청, 고객 응답처럼 현실의 부작용이 있는 작업입니다. 단순 문서 요약, 검색 보조, 개인 메모 생성처럼 실패해도 쉽게 버릴 수 있는 작업에는 여기서 다루는 승인 큐가 과할 수 있습니다.

2. 먼저 결론

핵심 한 줄: 승인 큐는 “AI를 느리게 만드는 장치”가 아니라 “AI가 더 많은 일을 맡아도 사고 범위를 작게 유지하는 장치”입니다.

에이전트가 외부 시스템을 바꾸는 순간에는 프롬프트보다 승인 큐가 먼저 필요합니다. 큐는 에이전트가 제안한 행동을 구조화해서 저장하고, 사람에게 검토 맥락을 보여주고, 승인 후에만 실행 계층으로 넘기는 대기 공간입니다.

지금 도입하면 좋은 팀은 자동화할 업무가 이미 반복되고, 실패 비용이 숫자로 설명되며, 승인자가 누구인지 정할 수 있는 팀입니다. 아직 관찰만 해도 되는 팀은 에이전트가 읽기 전용 작업만 하거나, 작업량이 적어 사람이 직접 실행해도 병목이 아닌 팀입니다. 제 판단은 분명합니다. “일단 자동 실행하고 나중에 로그로 보자”는 접근은 고객 데이터, 결제, 배포, 공개 메시지 영역에서는 피해야 합니다.

3. 핵심 구조 분해

핵심 한 줄: 승인 큐는 에이전트, 정책 엔진, 대기 레코드, 사람 인박스, 실행기, 감사 로그의 6개 층으로 나눠야 이해하기 쉽습니다.

1. 에이전트 층: 사용자의 요청을 해석하고 “무엇을 할지” 제안합니다. 예를 들어 “환불 요청 고객에게 답변 발송”이나 “이슈 #42 수정 PR 생성” 같은 행동 후보를 만듭니다.
2. 정책 엔진 층: 행동 후보를 위험도에 따라 자동 실행, 승인 대기, 차단으로 나눕니다. 이 판단은 프롬프트 안의 약속이 아니라 코드나 설정으로 고정해야 합니다.
3. 승인 큐 레코드: 제안된 행동을 저장하는 구조화 데이터입니다. 최소 필드는 id, agent_run_id, action_type, payload, risk_level, status, expires_at입니다.
4. 사람 인박스: 승인자가 실제로 보는 화면입니다. Slack, 이메일, GitHub PR, 내부 어드민, 채팅 UI 중 하나일 수 있습니다. 중요한 점은 버튼만 보여주는 것이 아니라 왜 이 행동이 제안됐는지 근거를 같이 보여주는 것입니다.
5. 실행기 층: 승인된 레코드만 실제 API 호출, DB 변경, 메시지 발송, PR 머지 같은 부작용으로 바꿉니다.
6. 감사 로그 층: 누가, 언제, 어떤 근거로 승인했는지와 실행 결과를 남깁니다. 나중에 사고가 났을 때 “AI가 그랬다”가 아니라 정확한 의사결정 흐름을 복원해야 합니다.

4. 설계 의도 해설

핵심 한 줄: 승인 큐를 별도 계층으로 두는 이유는 모델의 판단과 시스템의 책임을 분리하기 위해서입니다.

초보 개발자에게 쉽게 비유하면, 에이전트는 초안을 쓰는 직원이고 승인 큐는 결재함입니다. 결재함이 없으면 초안 작성자가 결제, 발송, 삭제까지 한 번에 처리합니다. 속도는 빠르지만 책임 경계가 흐려집니다.

반대로 모든 행동에 사람 승인을 요구하면 에이전트의 장점이 사라집니다. 그래서 핵심은 위험도 기반 분기입니다. 읽기 전용 조회, 임시 초안 생성, 테스트 브랜치 생성은 자동으로 처리하고, 고객에게 실제 메시지를 보내거나 운영 데이터를 바꾸거나 비용을 발생시키는 행동은 승인 큐로 보냅니다.

이 설계가 포기하는 것은 즉시성입니다. 대신 얻는 것은 복구 가능성, 감사 가능성, 역할 기반 권한 통제입니다. 특히 GitHub Copilot cloud agent와 OpenAI Codex처럼 PR을 만들고 리뷰하는 도구가 늘수록, 팀은 “에이전트가 만들었다”와 “사람이 승인했다”를 명확히 구분해야 합니다.

5. 근거 및 비교

핵심 한 줄: 승인 큐의 경쟁 상대는 단순 수동 검토가 아니라 자동 실행, PR 리뷰 게이트, 워크플로 엔진의 대기 신호입니다.

OpenAI Codex의 GitHub 연동 문서는 PR에서 @codex review를 호출하면 Codex가 심각한 이슈 중심으로 리뷰를 남기고, 이후 @codex fix 같은 후속 댓글로 cloud task를 시작할 수 있다고 설명합니다. GitHub Copilot cloud agent 문서는 에이전트가 GitHub Actions 기반 임시 개발 환경에서 코드를 바꾸고 테스트와 린터를 실행한 뒤, 사람이 diff를 검토하고 PR 흐름으로 이어갈 수 있다고 설명합니다.

Temporal의 Human-in-the-Loop 예시는 위험 작업을 분석한 뒤 승인 신호가 올 때까지 워크플로를 멈추고, 승인·거절·타임아웃에 따라 다른 결과로 끝나는 패턴을 제시합니다. 이 차이는 실무적으로 큽니다. 단순 채팅봇은 응답을 반환하면 끝나지만, 운영 에이전트는 사람의 결정을 기다리는 동안 상태를 잃지 않아야 합니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 승인 큐는 DB 테이블 하나로 시작할 수 있지만, 상태 전이와 실행 멱등성을 처음부터 같이 설계해야 합니다.

1. 행동 목록을 작성합니다.
   예: draft_email, send_email, create_pr, merge_pr, update_customer_plan, delete_record.
2. 위험 등급을 붙입니다.
   읽기 전용은 low, 되돌릴 수 있는 내부 변경은 medium, 고객·돈·운영 데이터·배포에 영향을 주는 행동은 high로 분류합니다.
3. 정책 함수를 먼저 만듭니다.
   모델에게 “위험하면 물어봐”라고만 시키지 말고, 실행 전 코드에서 반드시 한 번 더 분기합니다.
4. 승인 큐 레코드를 저장합니다.
   승인자가 볼 payload에는 최종 실행값뿐 아니라 에이전트의 근거, 관련 링크, 되돌리기 방법을 포함합니다.
5. 인박스를 연결합니다.
   팀이 이미 쓰는 곳이 좋습니다. 개발팀은 GitHub PR, 운영팀은 Slack, CS팀은 CRM 또는 어드민 화면이 자연스럽습니다.
6. 승인 후 실행기를 호출합니다.
   UI가 직접 외부 API를 때리지 않고, 승인 상태가 된 레코드를 실행기가 읽어 처리하게 합니다.
7. 타임아웃과 재시도를 둡니다.
   예를 들어 30분 안에 승인되지 않으면 고객에게 “검토 중” 상태를 표시하고, 24시간이 지나면 자동 취소합니다.

type ProposedAction = {
  id: string;
  agentRunId: string;
  actionType: "send_email" | "create_pr" | "update_plan";
  payload: Record<string, unknown>;
  riskLevel: "low" | "medium" | "high";
  status: "pending" | "approved" | "rejected" | "expired" | "executed" | "failed";
  expiresAt: string;
};

function routeAction(action: ProposedAction) {
  if (action.riskLevel === "low") return "execute";
  if (action.riskLevel === "medium" && action.actionType === "create_pr") return "execute_with_review";
  if (action.riskLevel === "high") return "queue_for_approval";
  return "block";
}

7. 실수/함정(Pitfalls)

핵심 한 줄: 승인 큐의 실패는 대부분 “승인 버튼은 있는데 운영 상태가 없다”에서 시작됩니다.

1. 함정: 승인 UI에서 바로 실행한다.
   예방: 승인 버튼은 레코드 상태만 바꾸고, 실행은 별도 worker가 처리하게 합니다.
   복구: 이미 직접 실행 중이라면 실행 요청에 idempotency key를 붙이고 중복 실행 로그를 먼저 정리합니다.
2. 함정: 타임아웃이 없다.
   예방: 모든 승인 요청에 expires_at과 SLA를 둡니다.
   복구: 24시간 이상 pending인 항목을 일괄 만료시키고 사용자에게 대체 경로를 안내합니다.
3. 함정: 승인자가 payload를 이해할 수 없다.
   예방: payload 원문, 변경 전후 차이, 예상 영향, 롤백 방법을 함께 보여줍니다.
   복구: 최근 거절된 항목 10개를 분석해 “정보 부족” 유형을 별도 필드로 보강합니다.
4. 함정: 사람 승인만 있으면 안전하다고 착각한다.
   예방: 승인 후에도 권한 검사, 입력 검증, 실행 결과 검증을 합니다.
   복구: 승인된 작업 실패율을 추적하고, 실패율이 5%를 넘는 action type은 자동으로 정책을 강화합니다.

8. 강점과 한계

핵심 한 줄: 승인 큐는 고위험 행동을 다루는 데 강하지만, 낮은 품질의 에이전트 출력을 자동으로 좋은 판단으로 바꿔주지는 않습니다.

강점은 세 가지입니다. 첫째, 자동화의 속도와 사람 판단의 책임을 분리합니다. 둘째, 승인 이력을 남겨 사고 대응과 감사가 쉬워집니다. 셋째, 에이전트가 여러 개로 늘어도 공통 정책 계층에서 위험 행동을 제어할 수 있습니다.

한계도 분명합니다. 승인자가 너무 많으면 병목이 됩니다. 승인자가 맥락을 이해하지 못하면 형식적인 결재가 됩니다. 그리고 승인 큐는 모델 품질 평가를 대체하지 않습니다. 에이전트가 계속 부정확한 제안을 만든다면 승인 큐는 그 문제를 늦게 드러낼 뿐입니다.

따라서 승인 큐는 평가 데이터셋, 실행 로그, 비용 한도, PR 리뷰 게이트와 함께 운영해야 합니다. 코드 작업이라면 Codex나 Copilot이 만든 결과를 PR과 CI에서 검증하고, 운영 자동화라면 승인 후 실제 실행 결과까지 확인해야 합니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 다음 학습 순서는 HITL 패턴, 워크플로 신호, GitHub PR 게이트, 멱등 실행, 감사 로그입니다.

• Human-in-the-loop: 사람이 어느 지점에서 개입해야 하는지 정하는 운영 패턴입니다. 모든 단계가 아니라 위험 행동 직전에 들어가야 합니다.
• Workflow signal: 오래 기다리는 작업에 외부 결정을 넣는 방법입니다. Temporal 예시처럼 승인 신호가 도착하면 멈춘 흐름이 이어집니다.
• PR review gate: 코딩 에이전트의 결과를 바로 머지하지 않고 diff, 테스트, 리뷰 코멘트로 검증하는 방식입니다.
• Idempotency: 같은 실행 요청이 두 번 들어와도 결과가 한 번만 반영되게 만드는 설계입니다. 결제, 메일 발송, 데이터 변경에 필수입니다.
• Audit log: “누가 승인했는가”뿐 아니라 “무엇을 보고 승인했는가”까지 남기는 기록입니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 저는 승인 큐를 AI 에이전트 도입 후 붙이는 보안 장치가 아니라, 첫 운영 설계에 포함해야 할 기본 골격으로 봅니다.

• 에이전트가 호출할 수 있는 action type 목록이 문서화되어 있다.
• 각 action type에 low, medium, high 위험 등급이 붙어 있다.
• high 등급 행동은 코드 레벨 정책에서 승인 큐로 강제 라우팅된다.
• 승인 레코드에 payload, 근거, 영향 범위, 만료 시각, 롤백 방법이 포함된다.
• 승인 UI는 실행을 직접 하지 않고 상태만 바꾼다.
• 실행기는 idempotency key와 재시도 정책을 갖고 있다.
• pending, approved, executed, failed, expired 상태가 대시보드에서 보인다.
• 승인 후 실행 실패율과 거절 사유를 주간 리뷰에서 확인한다.

Definition of Done: 고위험 action이 자동 실행되지 않고 승인 큐에 남으며, 승인자는 3분 안에 영향 범위와 롤백 방법을 이해하고, 승인 후 실행 결과가 감사 로그에 연결되면 1차 도입 완료로 봅니다.

제 추천은 작게 시작하는 것입니다. 처음부터 범용 에이전트 플랫폼을 만들기보다, “고객 이메일 발송 전 승인”이나 “운영 DB 변경 전 승인”처럼 실패 비용이 명확한 action type 하나로 시작하십시오. 반대로 읽기 전용 분석이나 개인 생산성 자동화에는 복잡한 승인 큐보다 로그와 취소 버튼이 더 현실적입니다.

11. 참고자료

• OpenAI Developers - Code review in GitHub with Codex (확인일: 2026-07-06)
• OpenAI - Introducing Codex (발행일: 2025-05-16, 업데이트: 2025-06-03, 확인일: 2026-07-06)
• GitHub Docs - About GitHub Copilot cloud agent (확인일: 2026-07-06)
• GitHub Changelog - GitHub Copilot coding agent in public preview (발행일: 2025-05-19, 확인일: 2026-07-06)
• Temporal Docs - Human-in-the-Loop AI Agent Python cookbook (확인일: 2026-07-06)
• Oracle Blog - Human Approval Node in Workflow Agents (확인일: 2026-07-06)