AI 에이전트가 비용이 많이 드는 버튼을 함부로 클릭하게 두지 마세요
요약
AI 에이전트 도입 시 무조건적인 자율성보다는 인간의 승인을 거치는 '승인 게이트' 설계의 중요성을 강조합니다. 비용이 많이 들거나 되돌릴 수 없는 작업을 수행하기 전, 인간이 개입하는 Human-in-the-loop 패턴을 통해 비즈니스 리스크를 관리해야 합니다.
핵심 포인트
- 에이전트에게 모든 권한을 주기보다 최종 결정권은 사람이 보유해야 함
- 승인 게이트는 자동화의 실패가 아닌, 안전한 배포를 위한 핵심 기능임
- n8n과 같은 도구를 활용해 특정 도구 호출 시 승인 요청을 보내는 패턴 권장
- 도구의 영향 범위(Blast radius)에 따라 읽기 전용과 실행 도구를 분류하여 관리
소규모 비즈니스는 보통 완전히 자율적인 AI 직원을 필요로 하지 않습니다.
그들에게 필요한 것은 덜 화려하지만 훨씬 더 유용한 것입니다. 즉, 작업을 준비하고, 자신의 추론 과정을 설명하며, 수행하려는 정확한 동작을 보여준 뒤, 비용이 많이 들거나, 공개적이거나, 되돌리기 어려운 작업을 수행하기 전에 멈출 수 있는 에이전트입니다.
실제 도구(tools)에 연결된 에이전트를 지켜보기 전까지는 이 방식이 보수적으로 들릴 수 있습니다. 캘린더를 읽는 것은 해롭지 않습니다. 답장을 초안 작성하는 것은 유용합니다. 하지만 그 답장을 고객에게 전송하는 것은 다릅니다. 송장을 조회하는 것은 도움이 됩니다. 하지만 환불을 처리하거나, 가격을 변경하거나, 블로그 게시물을 발행하거나, 기록을 삭제하거나, 배송 날짜를 약속하는 단계에서는 리스크의 형태가 달라집니다.
이것이 소규모 팀이 설계의 기준으로 삼아야 할 경계선입니다.
현재 에이전트에 대한 논의는 마침내 "도구를 호출할 수 있는가?"를 넘어 "사람 없이 어떤 도구를 호출하도록 허용해야 하는가?"로 이동하고 있습니다. MCP는 AI 클라이언트에게 도구와 리소스를 노출하는 공통적인 방법을 제공합니다. n8n 및 유사한 워크플로우(workflow) 도구들은 결정을 일시 중지하고, 라우팅(route)하며, 승인하고, 기록할 수 있는 배관 역할을 제공합니다. 여기서 부족한 조각은 비즈니스 소유자가 이해할 수 있는 단순한 운영 모델입니다.
저는 이 모델을 사용합니다: 에이전트가 지게차를 운전하게 하되, 창고 문 열쇠는 사람이 쥐고 있어야 합니다.
승인 게이트(approval gate)는 실패 모드가 아닙니다
개발자들은 때때로 인간의 승인을 자동화가 불완전하다는 신호로 취급하곤 합니다. 하지만 소규모 비즈니스에 있어 승인은 자동화를 실제로 배포 가능하게 만드는 핵심 기능인 경우가 많습니다.
승인 게이트는 다음과 같이 말합니다:
- 에이전트는 지루한 조사를 수행할 수 있습니다.
- 에이전트는 동작의 초안을 작성할 수 있습니다.
- 에이전트는 뒷받침되는 증거를 수집할 수 있습니다.
- 에이전트는 다음 단계를 추천할 수 있습니다.
- 하지만 최종적인 되돌릴 수 없는 단계에는 인간의 "예"가 필요합니다.
이 방식이 더 안전하며, 내부적으로 설득하기도 더 쉽습니다. 소유자는 첫날부터 에이전트에게 최종 권한을 넘기지 않고도, 에이전트가 세 가지 깔끔한 옵션을 준비하도록 신뢰할 수 있기 때문입니다.
이것이 바로 n8n의 Human-in-the-loop (인간 참여형) 도구 호출 패턴이 중요한 이유입니다. n8n의 문서에 따르면, 인간의 검토(Human review) 기능이 활성화된 상태에서 AI 에이전트는 도구를 사용하고자 할 때 일시 중지한 후, Slack, Telegram 또는 n8n Chat과 같이 설정된 채널을 통해 승인 요청을 보냅니다. 이것이 올바른 사고 모델입니다. 즉, 승인 게이트(Approval gate)는 전체 워크플로우(Workflow)가 아니라 특정 도구 주변에 위치해야 합니다.
에이전트가 고객 지원 티켓(Support ticket)을 요약하는 데에는 허가가 필요하지 않아야 합니다. 하지만 환불과 함께 티켓을 종결하는 데에는 아마도 허가가 필요할 것입니다.
영향 범위(Blast radius)에 따라 도구 분류하기
에이전트를 비즈니스 시스템에 연결하기 전에, 에이전트가 호출할 수 있는 도구들을 나열하고 네 가지 범주로 분류하십시오.
1. 읽기 전용 도구 (Read-only tools)
이 도구들은 정보를 가져오지만 아무것도 변경하지 않습니다.
예시:
- 지식 베이스(Knowledge base) 검색
- 제품 재고 읽기
- 예약 가능 여부 가져오기
- 주문 상태 조사
- 최근 송장(Invoice) 검색
- 웹사이트 분석 데이터 확인
접근 제어(Access control)가 올바르고 개인 데이터가 적절하게 처리된다고 가정할 때, 이러한 도구들은 대개 자동으로 실행해도 안전합니다. 주요 위험은 운영상의 손상이 아니라 정보 노출입니다.
2. 초안 작성 도구 (Drafting tools)
이 도구들은 외부 세계에 영향을 미치기 전, 여전히 추가적인 단계가 필요한 무언가를 생성합니다.
예시:
- 고객 이메일 초안 작성
- 발행되지 않은 CMS 포스트 생성
- 송장을 준비하되 전송은 하지 않음
- 견적서(Quote) 생성
- CRM 메모 작성
- 일정 변경 제안
이 도구들은 출력물이 검토를 위해 어딘가에 머물러 있기 때문에 자동 실행이 가능한 경우가 많습니다. 초안 작성은 소규모 비즈니스가 빠르게 많은 가치를 얻을 수 있는 영역입니다. 최종 작업은 여전히 인간이 소유하지만, 백지 상태의 막막함은 사라집니다.
3. 되돌릴 수 있는 쓰기 도구 (Reversible write tools)
이 도구들은 상태를 변경하지만, 그 변경 사항의 가치가 낮거나, 되돌리기 쉽거나, 또는 내부적으로만 보이는 경우입니다.
예시:
- 리드(Lead)에 태그 달기
- 작업 상태 업데이트
- 내부 메모 추가
- 대기열(Queue) 간에 티켓 이동
- 캘린더 예약 보류(Hold) 생성
- 공개 데이터를 사용하여 레코드 보강(Enrich)
이러한 사항들은 더 많은 고민이 필요합니다. 어떤 것들은 테스트를 거친 후 자동화할 수 있습니다. 다른 것들은 팀이 몇 주간의 동작(Behaviour)을 지켜볼 때까지 승인(Approval) 단계를 거쳐야 합니다. 중요한 부분은 왜 특정 도구에 쓰기(Write) 권한이 허용되었는지, 롤백(Rollback) 경로는 무엇인지, 그리고 실행 시 누구에게 알림이 가는지 아는 것입니다.
4. 비용이 많이 드는 버튼 (Expensive buttons)
이것들은 비용을 발생시키거나, 약속을 하거나, 콘텐츠를 공개적으로 노출하거나, 법적 또는 재무적 기록에 영향을 미치거나, 잘못되었을 경우 고객을 불쾌하게 만드는 작업들입니다.
예시:
- 고객에게 이메일 또는 SMS 전송
- 웹사이트 또는 소셜 포스트 게시
- 환불(Refund) 처리
- 라이브 제품 가격 변경
- 고객 레코드 삭제
- 급여(Payroll) 승인
- 세무 또는 컴플라이언스(Compliance) 문서 제출
- 공급업체에 주문(Order) 넣기
이것들이 바로 비용이 많이 드는 버튼들입니다. 여기에 승인 게이트(Approval gates)를 가장 먼저 배치하세요.
MCP에는 기술적 인증뿐만 아니라 비즈니스 권한이 필요합니다
MCP 서버는 민감한 리소스와 작업을 노출할 수 있기 때문에 MCP 인증(Authorization)은 중요합니다. 공식 문서들은 제한된 서버와 보호된 리소스에 대한 액세스를 보안 처리하는 데 집중합니다. 이는 필수적이지만, 비즈니스 안전을 위해서는 한 단계가 더 필요합니다.
유효한 사용자 토큰(User token)은 다음과 같은 질문에 답합니다: "이 클라이언트가 서버에 액세스할 권한이 있는가?"
유용한 소규모 비즈니스 정책은 다음과 같은 질문도 던집니다:
- 이 도구는 읽기 전용(Read-only)인가, 아니면 쓰기(Write)가 가능한가?
- 이 작업은 되돌릴(Undo) 수 있는가?
- 금액 제한(Money limit)이 있는가?
- 고객에게 보이는 부작용(Side effect)이 있는가?
- 이 작업에 관리자, 소유자 또는 도메인 전문가가 필요한가?
- 작업을 요청한 동일한 사람이 이를 승인할 수 있도록 허용해야 하는가?
해당 정책이 복잡할 필요는 없습니다. 많은 팀에게는 간단한 YAML 파일이나 데이터베이스 테이블만으로도 충분합니다:
tools:
read_order:
risk: read_only
...
핵심은 형식이 아닙니다. 핵심은 에이전트 런타임(Agent runtime), MCP 게이트웨이(Gateway), 또는 워크플로 오케스트레이터(Workflow orchestrator)가 "이것을 조회하라"와 "이것을 지금 실행하라"의 차이를 알아야 한다는 것입니다.
승인 요청에 포함되어야 할 내용
잘못된 승인 요청은 다음과 같이 말합니다:
AI가
issue_refund를 사용하려고 합니다. 승인하시겠습니까?
좋은 승인 요청은 사람이 10초 이내에 결정을 내릴 수 있도록 충분한 맥락(Context)을 제공합니다:
- 요청된 작업 (requested action);
- 영향을 받는 고객 또는 기록 (customer or record affected);
- 금액 또는 비즈니스 영향 (amount or business impact);
- 에이전트의 이유 (agent's reason);
- 사용된 근거 (evidence it used);
- 전송될 정확한 페이로드 (exact payload it will send);
- 롤백 경로 (rollback path);
- 타임아웃 동작 (timeout behaviour).
예를 들어:
배송업체가 물품 분실로 표시했고 고객이 9일을 기다렸으므로 주문 #1842에 대해 £18.50를 환불합니다. 근거: 추적 링크, 고객 메시지, 정책 섹션 4.2. 승인 시 환불은 Stripe를 통해 전송되며 확인 이메일이 초안으로 작성됩니다. 거절 시 티켓은 열린 상태로 유지됩니다.
이것은 검토가 가능합니다. 담당자는 승인, 거절 또는 편집을 할 수 있습니다. 에이전트는 여전히 시간을 절약해 주었습니다. 에이전트가 주문을 찾고, 정책을 확인하고, 근거를 작성하고, 페이로드를 구성했기 때문입니다.
세 가지 게이트(Gate)로 시작하기
기존 비즈니스 워크플로우(Workflow)에 에이전트를 추가하는 경우, 거대한 거버넌스(Governance) 프로그램부터 시작하지 마세요. 세 가지 게이트부터 시작하세요.
- 공개 커뮤니케이션 게이트 (Public communication gate) — 회사 외부로 전송하거나 게시하는 모든 것.
- 금전 게이트 (Money gate) — 환불, 송장, 할인, 구매, 급여, 구독.
- 기록 파기 게이트 (Record destruction gate) — 삭제, 병합, 되돌릴 수 없는 CRM/회계 변경.
그 외의 모든 것은 도구별로 평가할 수 있습니다.
이는 n8n 스타일의 워크플로우에서 특히 잘 작동합니다. 에이전트가 프로세스의 처음 80%를 실행한 다음, 인간 참여(Human-in-the-loop) 노드 또는 승인이 활성화된 도구에서 일시 중지할 수 있습니다. 승인은 비즈니스가 이미 사용 중인 채널에서 이루어질 수 있습니다. 승인 후 워크플로우는 재개되고 결과가 로그에 기록됩니다.
실질적인 아키텍처 (Practical architecture)
소규모 비즈니스 에이전트 스택은 이색적일 필요가 없습니다:
- MCP 서버는 CRM, CMS, 캘린더, 회계, 문서, 이메일과 같은 비즈니스 도구(tools)를 노출합니다.
- 게이트웨이(gateway) 또는 정책 계층(policy layer)이 위험도에 따라 도구에 태그를 지정하고 승인 규칙을 강제합니다.
- n8n과 같은 워크플로 엔진(workflow engine)이 라우팅(routing), 대기, 리마인더(reminders) 및 알림을 처리합니다.
- 에이전트(agent)는 실행할 작업과 증거를 준비합니다.
- 사람이 비용이 많이 드는 버튼을 승인합니다.
- 모든 결정은 기록됩니다.
나중에 동적 도구 라우팅(dynamic tool routing), 관찰 가능성 트레이스(observability traces), 로컬 모델(local models), 감사 대시보드(audit dashboards)를 통해 이를 더 고도화할 수 있습니다. 하지만 핵심 패턴은 간단합니다: 에이전트는 준비하고, 사람은 승인하며, 워크플로는 실행하고, 로그는 기억합니다.
이것이 도입에 좋은 이유
소규모 비즈니스는 AI 데모가 부족한 것이 아닙니다. 그들에게 부족한 것은 복잡한 일상 업무에 적합한 신뢰할 수 있는 시스템입니다.
승인 게이트(approval gates)는 에이전트를 덜 마법 같게 만들고 더 사용 가능하게 만듭니다. 이는 소유자가 모든 권한을 넘겨주지 않고도 작게 시작할 수 있는 방법을 제공합니다. 또한 이는 학습 데이터(training data)를 생성합니다. 모든 승인, 거절, 수정 사항은 에이전트가 어디에서 신뢰할 수 있는지, 그리고 정책을 어디에서 강화해야 하는지를 팀에게 알려줍니다.
이것이 바로 자동화가 보여주기식(performative)이 아닌 운영 중심(operational)이 되는 방식입니다.
"에이전트가 업무 전체를 수행할 수 있는가?"라고 묻지 마세요.
"어떤 부분을 안전하게 수행할 수 있으며, 어디에서 멈춰야 하는가?"라고 물으세요.
그 질문에 답하는 것이 훨씬 쉽습니다. 또한 그 질문이야말로 AI 에이전트를 위험한 실험에서 소규모 비즈니스가 실제로 사용할 수 있는 무언가로 바꾸어 놓는 질문입니다.
출처 노트
- n8n 문서: Human-in-the-loop 도구 호출은 검토가 활성화된 도구 전에 AI 에이전트를 일시 중지할 수 있으며, Slack, Telegram 또는 n8n Chat을 통해 승인을 요청할 수 있습니다.
- MCP 문서: 권한 부여(authorization)는 MCP 서버가 노출하는 민감한 리소스 및 작업에 대한 액세스를 보호합니다.
- X 트렌드 스캔, 2026년 7월: 현재 소규모 비즈니스 자동화 논의는 에이전트, MCP, 워크플로 자동화, 그리고 중대한 작업(high-stakes actions)에 대한 인간의 감독(human oversight)을 중심으로 모이고 있습니다.
출처:
출처:
- https://docs.n8n.io/build/integrate-ai/ai-examples/human-in-the-loop-for-tools
- https://docs.n8n.io/advanced-ai/human-in-the-loop-tools/
- https://modelcontextprotocol.io/docs/tutorials/security/authorization
- https://modelcontextprotocol.io/specification/draft/basic/authorization
- https://x.com/HappyMonkeyAI/status/2073238780086042981
- https://x.com/GoodFellasTech/status/2073075934895153194
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기