AI가 결제 직전까지 움직일 때, 승인과 취소는 누가 쥐나
AI 에이전트가 장바구니를 채우고 결제 화면까지 이동하는 일은 이제 기술적으로 낯선 장면이 아니다. 하지만 실제 도입 단계에서 더 중요한 질문은 다른 곳에 있다. 읽기만 하는 보조 기능과 달리, 쓰기와 금전 거래는 되돌리기 비용이 크기 때문에 ‘무엇을 할 수 있나’보다 ‘누가 언제 승인하고, 어디서 멈출 수 있나’가 먼저 설계돼야 한다는 점이다.
최근 공개 표준과 공식 문서를 보면 업계는 에이전트 간 연결 방식 자체보다 승인·권한·취소의 경계를 별도 층위에서 다루는 쪽으로 움직이고 있다. 2025년 12월 9일 앤스로픽은 모델 컨텍스트 프로토콜(MCP)을 리눅스재단 산하 에이전틱 AI 파운데이션에 기증한다고 발표했다. 다만 이런 표준의 확산이 곧바로 ‘AI가 대신 행동해도 책임이 정리됐다’는 뜻은 아니다. 연결 표준은 도구를 붙이는 방법을 제공할 뿐, 결제 승인 책임자와 취소 권한자를 자동으로 정해주지는 않는다.
읽기 권한과 거래 권한은 같은 문제가 아니다
에이전트 권한은 크게 읽기, 쓰기, 금전 거래로 나눠 볼 수 있다. 읽기 권한은 사내 문서 검색이나 재고 조회처럼 정보 확인이 중심이다. 잘못 읽거나 과다 조회하는 위험은 있지만, 시스템 상태를 직접 바꾸지는 않는다. 이 경우 핵심 통제는 데이터 범위 제한, 사용자별 접근권한, 토큰 만료, 감사기록에 가깝다.
반면 쓰기 권한은 성격이 달라진다. 일정 등록, 고객 정보 수정, 코드 배포, 발주서 작성처럼 외부 시스템의 상태를 바꾸기 때문이다. 여기서는 단순 로그인 여부만으로 부족하다. 어떤 필드를 수정할 수 있는지, 초안 저장과 최종 반영을 분리할지, 사람 승인 없이 허용되는 한도를 어디까지 둘지 같은 세부 규칙이 필요하다.
금전 거래 권한은 한 단계 더 엄격해야 한다. 구매, 송금, 환불, 유료 구독 신청은 실수 자체보다 실수의 회수 비용이 훨씬 크다. 취소가 가능하더라도 이미 주문이 접수됐거나 결제가 확정되면 원상복구가 늦어질 수 있다. 이 때문에 거래 권한은 읽기나 일반 쓰기와 분리해 별도 승인, 한도, 이중 확인, 사후 정산 절차를 두는 방식이 기본값에 가까워지고 있다.
MCP가 해결하는 것과 해결하지 않는 것
MCP는 AI 애플리케이션이 외부 도구와 데이터원에 연결되는 공통 방식을 제공하는 표준이다. 최근 사양과 공식 문서를 보면 이 프로토콜은 인증·인가를 강화하고, 민감한 도구를 서버 전체가 아니라 도구 단위로 보호하는 구조도 지원한다. 즉 같은 서버 안에서도 공개 도구와 보호 도구를 나눌 수 있고, 보호 도구 호출 시에는 HTTP 401 응답과 OAuth 흐름을 통해 사용자 인증을 다시 요구하는 식의 단계적 권한 상승이 가능하다.
중요한 점은 이것이 ‘도구 접근 권한’을 다루는 규격이지 ‘업무 승인 책임’을 대신 결정하는 규격은 아니라는 점이다. 공식 문서는 민감한 도구를 호출할 때 권한을 다시 확인하는 구조를 제시하지만, 승인 주체가 실무 담당자인지 팀장인지, 특정 금액 이상이면 재무 부서가 추가 승인해야 하는지는 각 서비스와 조직이 따로 정해야 한다. 다시 말해 MCP는 문을 잠그는 장치에 가깝고, 누가 열쇠를 쥐는지는 기업 정책의 영역이다.
최근 MCP 생태계에서 장기 작업을 다루는 태스크 확장도 비슷한 한계를 드러낸다. 이 확장은 작업 도중 추가 입력이 필요할 때 승인 요청을 받을 수 있게 하고, 진행 중인 작업에 대해 취소 요청도 보낼 수 있게 한다. 그러나 취소는 즉시 강제되는 방식이 아니라 서버가 가능한 범위에서 받아들이는 협조적 신호다. 이미 외부 시스템에 주문 전송이 끝났다면, 에이전트 실행은 멈춰도 거래 자체는 별도 취소 절차를 밟아야 할 수 있다는 뜻이다.
A2A도 승인 요청의 전달은 돕지만 책임자를 정하지는 않는다
에이전트 간 통신 표준인 A2A 역시 비슷한 방향을 택하고 있다. 최신 공식 사양은 작업 수행 중 추가 인증이나 인간 승인이 필요하면 작업 상태를 ‘인증 필요’로 바꿔 클라이언트에 넘길 수 있도록 한다. 필요하면 한 에이전트가 받은 승인 요청을 다시 상위 클라이언트나 다른 에이전트로 위임하는 것도 가능하다.
이 구조는 다단계 워크플로에는 유용하다. 예를 들어 구매 에이전트가 결제를 시도하기 전, 부서장 승인 에이전트나 사람 관리자에게 요청을 넘기는 식이다. 다만 여기서도 A2A가 정하는 것은 요청 전달 방식과 상태 관리이지, 누가 최종 승인권자인지 자체는 아니다. 승인 경로가 길어질수록 책임 추적과 감사기록이 더 중요해지는 이유다.
취소 역시 마찬가지다. A2A의 취소 요청은 진행 중인 작업을 멈추도록 시도하지만, 이미 끝났거나 취소 불가능한 단계에 들어간 작업은 되돌리지 못할 수 있다. 따라서 ‘취소 버튼이 있다’는 사실만으로 금전 거래 위험이 통제됐다고 보기는 어렵다.
공식 문서가 보여준 실제 경고, 브라우저 승인과 구매 확인은 다르다
실제 제품 문서는 이 차이를 더 분명하게 보여준다. 오픈AI의 에이전트 API 문서에서 컴퓨터 사용 기능은 새로운 웹사이트 원점에 접근할 때 사용자 승인을 받도록 설계돼 있다. 로그인이나 사이트 접근 같은 행동은 애플리케이션이 중간에서 승인 여부를 처리할 수 있다.
그러나 같은 문서는 이런 승인만으로 구매나 파괴적 변경에 대한 개별 확인이 자동 보장되지는 않는다고 적고 있다. 결제 같은 중대한 행동마다 반드시 사람 확인이 필요하다면, 위험한 행동이 가능한 브라우저 환경을 제한하거나 개발자가 직접 통제하는 런타임을 사용하라고 안내한다. 다시 말해 ‘사이트 접속 승인’과 ‘구매 승인’은 다른 층위의 통제라는 얘기다.
이 대목은 에이전트 도입 기업이 자주 놓치는 부분과 맞닿아 있다. 시연 단계에서는 브라우저 접근 승인 화면이 뜨는 것만으로 충분히 안전해 보일 수 있다. 하지만 실무에서는 접속 허용 뒤의 개별 행동, 특히 결제·삭제·배포 같은 고위험 행위를 어떤 규칙으로 끊어 세울지가 더 중요하다.
도입 설계의 핵심은 승인, 집행, 취소를 분리하는 일
결국 에이전트 통제 설계는 세 단계를 분리해 보는 것이 출발점이 된다. 첫째는 접근 승인이다. 어떤 데이터와 도구에 닿을 수 있는지, 누구 자격으로 로그인하는지, 읽기와 쓰기를 어떻게 나눌지 정해야 한다. 둘째는 집행 승인이다. 초안 작성과 실제 실행을 분리하고, 금액·대상·시점별로 사람 확인을 어디에 둘지 정해야 한다. 셋째는 사후 취소와 복구다. 에이전트 프로세스를 멈추는 것과 외부 시스템의 주문·결제·수정을 원복하는 절차를 따로 준비해야 한다.
이때 특히 금전 거래는 ‘승인 전에는 실행 불가’ 원칙이 유리하다. 읽기 권한은 사전 차단과 사후 감사의 조합으로 운영할 수 있지만, 결제는 사후 정정보다 사전 승인 비용이 더 싸다. 일정 금액 이상 결제 차단, 신규 거래처 자동주문 금지, 실결제 대신 초안 주문서만 생성, 승인 후 짧은 시간 안에만 토큰 유효 같은 방식이 그래서 거론된다.
에이전트 기술은 빠르게 표준화되고 있지만, 책임 경계는 아직 조직이 직접 그어야 한다. 연결 표준이 성숙할수록 오히려 더 분명해지는 사실은 하나다. AI가 구매까지 대신할 수 있느냐보다, 그 직전 단계에서 누가 멈출 수 있느냐가 실제 도입의 성패를 가른다는 점이다.
자료: Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation(2025-12-09); Model Context Protocol, Authorization(MCP Apps 문서, 2026); MCP Tasks Extension, Tasks Specification Draft·Overview(2026); A2A Protocol, Specification v1.0.1(2026); OpenAI, Manage sessions(Agents API 문서, 2026); OpenAI, Computer use(Agents API 문서, 2026)