AI가 사람에게 확인받아야 하는 순간을 정하는 법

1. 개요: 좋은 자동화는 멈출 순간을 안다

대부분의 AI 데모는 멋진 장면을 보여줍니다. 에이전트가 검색하고, 초안을 쓰고, 파일을 고치고, tool을 호출하고, 결과물을 냅니다. 하지만 실제 운영은 덜 멋진 장면에서 깨집니다. 에이전트가 잘못된 메시지를 보내고, 잘못된 필드를 수정하고, 잘못된 데이터를 노출하고, 잘못된 record를 삭제하고, 약한 추정을 확신하듯 실행할 때입니다. 해결책은 agent를 피하는 것이 아니라 권한 경계를 주는 것입니다.

권한 경계는 "AI가 지금 해도 되는 일"과 "AI가 먼저 물어야 하는 일" 사이의 운영선입니다. 쉽게 말하면 신입 직원이 환불 안내문은 준비할 수 있지만 승인 없이 환불을 실행할 수는 없고, 영업 보조가 제안서는 만들 수 있지만 혼자 할인 약속을 할 수는 없는 것과 같습니다.

공식 문서들의 방향도 같습니다. OpenAI Agents guardrails/approvals 문서는 guardrail 결과에 따라 계속 진행, 중단, human review로 보낼 수 있다고 설명합니다. MCP tools 문서는 tool call을 사용자가 볼 수 있고, 민감한 호출은 확인하고, 상태와 결과를 log로 남기는 방식으로 다룹니다. Codex가 approval mode와 sandbox를 두는 이유도 파일 쓰기, shell command, network access가 단순 문장이 아니라 실제 세계를 바꾸는 행동이기 때문입니다.

2. 작은 용어집: 말은 어렵지만 개념은 단순하다

Human-in-the-loop는 AI가 일을 하되 중요한 순간에는 사람이 decision loop 안에 남아 있는 구조입니다. 모든 결과물을 사람이 다시 쓰라는 뜻이 아닙니다. 사람이 판단해야 하는 순간을 시스템이 알고 있어야 한다는 뜻입니다.

Approval gate는 실행 전 체크포인트입니다. 에이전트는 어떤 행동을 하려는지, 왜 하려는지, 근거가 무엇인지 보여줍니다. 사람은 approve, edit, reject 중 하나를 고릅니다. Escalation은 위험하거나 애매하거나 정보가 부족해서 에이전트가 사람에게 넘기는 것입니다.

Confidence threshold는 불확실성이 이 선을 넘으면 자동 실행하지 말자는 기준입니다. Side effect는 모델 바깥의 무언가를 바꾸는 행동입니다. 이메일 발송, CRM 수정, 돈 이동, database 변경, 콘텐츠 발행, command 실행, API 호출이 모두 포함됩니다. Audit log는 나중에 재구성할 수 있는 증거입니다. 누가 또는 무엇이, 언제, 왜, 어떤 입력으로, 어떤 결과를 만들었는지 남기는 기록입니다.

• Human-in-the-loop: AI가 일하지만 중요한 결정에는 사람이 남아 있는 구조입니다.
• Approval gate: 실제 행동이 일어나기 전의 승인 체크포인트입니다.
• Escalation: 에이전트가 위험하거나 애매한 일을 사람에게 넘기는 것입니다.
• Side effect: 고객, 파일, 시스템, 결제, 메시지, record를 바꾸는 행동입니다.
• Audit log: 나중에 행동을 재구성할 수 있게 남기는 기록입니다.

3. 1번 레인: AI가 대체로 자동 실행해도 되는 일

가장 안전한 자동화 레인은 내부용이고, 되돌리기 쉽고, 비용이 낮고, 검증하기 쉬운 일입니다. 예를 들면 회의 요약, support ticket 분류, invoice에서 필드 추출, 초안 formatting, 관련 SOP 페이지 찾기, customer feedback 묶기, 내부 메모 번역, 검토용 checklist 준비가 있습니다.

물론 자동 실행이 무통제라는 뜻은 아닙니다. 회사 지식에 근거한 답변이라면 출처를 보여줘야 합니다. log도 남겨야 합니다. 최신 정책이 중요한 업무라면 오래된 문서를 쓰지 않도록 해야 합니다. 하지만 모든 formatting, 모든 낮은 위험 분류까지 사람이 승인해야 한다면 시스템은 수작업보다 느려집니다.

실무 규칙은 단순합니다. 읽기 전용이고, 내부용이고, 되돌리기 쉽고, 고쳐도 비용이 낮다면 자동화를 기본값으로 둘 수 있습니다. 대신 나중에 sample review를 하고, prompt를 개선하고, 반복 실패는 eval case로 바꿔야 합니다.

• 승인된 문서 안에서 read-only 검색과 요약을 수행합니다.
• 내부 summary, classification, formatting, translation draft를 만듭니다.
• 검증 규칙이 있는 낮은 위험 data extraction을 처리합니다.
• 내부 task ticket, SOP update, handoff note 초안을 작성합니다.
• 사람이 무엇을 바꿀지 결정하기 전에 feedback을 묶고 패턴을 보여줍니다.

4. 2번 레인: AI가 초안을 만들고 사람이 승인해야 하는 일

대부분의 business value는 두 번째 레인에 있습니다. AI가 70퍼센트의 일을 처리하되 마지막 side effect는 사람이 승인하는 구조입니다. 고객 답변, 환불, outbound email, 계약 조항, lead qualification 변경, 공개 포스팅, support 약속, 민감한 CRM 업데이트가 여기에 들어갑니다.

핵심은 불신이 아니라 leverage입니다. AI가 근거를 모으고, 행동 초안을 만들고, 불확실성을 표시하고, 무엇이 바뀌는지 설명합니다. 사람은 결정에만 주의를 씁니다. 처음부터 사람이 다 쓰는 것보다 훨씬 빠르지만, agent에게 직접 실행 권한을 주는 것보다 안전합니다.

OpenAI의 approval pattern과 Codex의 permission mode는 좋은 참고 모델입니다. 에이전트가 tool call 직전에 멈추고, 제안된 행동을 보여주고, approval 이후에만 resume하는 방식입니다. business workflow에서 승인 화면은 다섯 질문에 답해야 합니다. 무엇이 바뀌는가, 누가 영향을 받는가, 근거는 무엇인가, 무엇이 잘못될 수 있는가, 되돌리는 방법은 무엇인가.

• 고객에게 나가는 email, chat reply, 안내문을 발송합니다.
• 환불, 쿠폰, 할인, upgrade, cancellation을 실행합니다.
• 블로그, landing page, sales page, social post를 공개합니다.
• pipeline, 가격, 고객 상태에 영향을 주는 CRM field를 바꿉니다.
• 계약 초안, 법무 관련 답변, 정책 예외, payment request를 만듭니다.

5. 3번 레인: 기본 금지, 또는 매번 명시 승인

어떤 행동은 모델이 tool을 호출할 수 있다는 이유만으로 자동화하면 안 됩니다. 돈 이동, account 삭제, credential 변경, 개인정보 공유, 되돌리기 어려운 production write, 법적 약속, 의료 또는 금융 판단, 대량 outbound, destructive file operation은 더 강한 경계가 필요합니다.

여기서 Human-in-the-loop는 UX 취향이 아니라 관리 규칙입니다. 시스템은 매번 명시 승인을 요구해야 하고, 경우에 따라 두 명의 승인도 필요합니다. agent는 모호한 continue 버튼 뒤에 행동을 숨기면 안 됩니다. 정확한 행동, 영향을 받는 system, 예상 blast radius, rollback plan을 보여줘야 합니다.

NIST AI Risk Management Framework가 도움이 되는 이유도 여기에 있습니다. AI 리스크는 모델 정확도만의 문제가 아닙니다. 누가 피해를 볼 수 있는지, 영향이 얼마나 큰지, 행동을 되돌릴 수 있는지, 조직이 나중에 어떤 증거를 제시할 수 있는지가 중요합니다.

• 돈을 이동하거나, billing을 바꾸거나, 일정 금액 이상의 refund를 승인하거나, payment detail을 수정합니다.
• account를 삭제하거나, data를 제거하거나, credential을 바꾸거나, access control을 수정합니다.
• 개인정보, 기밀 정보, 규제 대상 정보, 고객 민감 정보를 공유합니다.
• production deploy, destructive command, 중요 record overwrite를 실행합니다.
• 법률, 의료, 금융, compliance, HR 판단을 책임자 검토 없이 확정합니다.

6. MCP와 tool calling을 붙이기 전에 이 설계가 먼저다

MCP는 쉽게 말해 표준 connector입니다. AI application이 file, API, database, business tool에 공통 방식으로 접근하도록 돕습니다. Tool calling은 모델이 그 기능을 실제로 쓰겠다고 요청하는 순간입니다. Skill이나 playbook은 반복 업무를 수행하기 위해 저장해 둔 절차서입니다. 이 셋은 같은 것이 아니라 서로 다른 층입니다.

로컬 X 인박스에서도 이 신호가 강했습니다. builder들은 이제 prompt만 이야기하지 않습니다. tools가 실행되기 전 approval, MCP server management, 모든 tool call과 error에 대한 structured log, permission, hook, lifecycle check, safeguard를 이야기합니다. 실전 방향은 분명합니다. tool은 연결하되, 행동 경계는 보이게 만들어야 합니다.

실수는 모든 tool부터 연결하고 승인 규칙을 나중에 쓰는 것입니다. agent가 email을 보내고, CRM을 수정하고, private record를 가져오고, command를 실행하고, payment API를 호출할 수 있게 된 뒤에는 이미 failure surface가 커집니다. 더 나은 순서는 단순합니다. action을 지도화하고, risk를 표시하고, approval rule을 정하고, 첫 tool만 연결한 뒤, log로 안정성이 확인될 때 확장합니다.

7. 작은 회사가 바로 쓰는 승인 경계 표

작은 회사가 처음부터 거대한 governance 조직을 만들 필요는 없습니다. 간단한 표가 먼저입니다. workflow마다 action, 허용된 data source, 자동 레인, 승인 레인, 금지 레인, owner, log 위치, rollback 방법을 적습니다. Notion, Obsidian, repo Markdown, 내부 SOP 폴더 어디든 충분합니다.

숙소 운영자는 AI가 내부 FAQ 조회와 guest question grouping은 자동으로 하게 둘 수 있습니다. 하지만 refund, late checkout, damage, compensation 약속은 보내기 전에 물어야 합니다. Ecommerce에서는 ticket 분류와 reply draft는 자동화할 수 있지만, refund 실행, shipping address 변경, policy exception은 승인 대상입니다. Outbound에서는 lead research와 message draft는 AI가 맡되, 대량 발송은 사람이 승인해야 합니다.

내부 SOP lookup에서는 agent가 승인된 출처를 인용하며 답할 수 있지만, 문서가 충돌하거나 freshness가 불확실하면 escalation해야 합니다. Code나 operations에서는 diff 제안과 safe check 실행은 맡길 수 있지만, destructive command, production deploy, credential 작업, live system에 닿는 network action은 묻도록 해야 합니다.

• 질문: 이 행동은 외부에 나가거나, 비용이 들거나, 민감하거나, 되돌리기 어렵거나, 법적 의미가 있는가?
• 아니라면 log와 sample review를 전제로 자동 실행할 수 있습니다.
• 그렇다면 먼저 초안을 만들고, 근거를 설명하고, approval을 받아야 합니다.
• 피해 범위가 크다면 매번 명시 승인을 요구하고 rollback note를 남깁니다.
• 절대 하면 안 되는 행동은 조언이 아니라 forbidden rule로 적어야 합니다.

8. 승인을 학습 loop로 바꾸기

승인은 브레이크만이 아닙니다. 운영을 위한 training data입니다. approve, edit, reject, escalate된 행동은 모두 회사가 agent에게 무엇을 가르쳐야 하는지 알려줍니다. 팀은 반복 승인 사례를 보고 규칙을 더 명확히 할 수 있는지, 출처를 개선할 수 있는지, 해당 task를 더 안전한 자동 레인으로 옮길 수 있는지 확인해야 합니다.

그래서 audit log가 중요합니다. log는 관료주의가 아닙니다. "AI가 이상하게 했다"와 "이 날짜에 agent가 이 source를 사용했고, 이 action을 제안했고, 사람이 이 field를 수정했고, 결과가 승인됐다"의 차이입니다. 기록이 없으면 incident는 느낌으로 남습니다. 기록이 있으면 개선 작업이 됩니다.

loop는 단순합니다. approval case를 모으고, 왜 승인 필요였는지 label을 붙이고, SOP를 업데이트하고, 예시를 추가하고, eval case를 만들고, forbidden action을 더 명확히 하고, 그 다음 autonomy를 넓힙니다. 자율성은 낙관으로 주는 것이 아니라 증거로 벌어야 합니다.

9. AI가 발전할수록 사람도 함께 발전해야 하는 이유

AI가 좋아진다고 더 좋은 사람이 필요 없어지는 것은 아닙니다. 사람의 역량이 쓰이는 위치가 바뀝니다. 앞으로 가치 있는 operator는 모든 답변을 직접 쓰는 사람만이 아닙니다. 일을 정의하고, source of truth를 고르고, approval boundary를 정하고, failure pattern을 읽고, 반복 수정사항을 더 나은 운영체계로 바꾸는 사람입니다.

그래서 Human-in-the-loop 설계는 anti-automation이 아닙니다. 더 깊은 자동화로 가는 길입니다. 사람이 risk, evidence, ownership, rollback을 명확히 쓸 수 있게 되면 agent는 시간이 지날수록 더 많은 일을 안전하게 맡을 수 있습니다. 사람은 모든 작은 일을 직접 하는 위치에서, 시스템이 신뢰받을 조건을 설계하는 위치로 올라갑니다.

이번 주의 첫 행동은 작게 시작하면 됩니다. AI workflow 하나를 고르고 자동 실행, 승인 필요, 금지 세 레인으로 나눠보세요. owner 하나, log 위치 하나, rollback rule 하나를 붙이면 됩니다. 그 표 하나가 또 다른 막연한 prompt보다 다음 agent를 훨씬 낫게 만듭니다.