AI가 주문까지 맡게 됐다면, 승인과 취소는 누가 쥐어야 하나
AI 에이전트가 장바구니를 채우고 주문 버튼까지 누를 수 있는 단계로 가면서 통제의 질문은 더 단순해졌다. 무엇을 할 수 있느냐보다, 누가 그 행동을 승인하고 누가 되돌릴 수 있느냐다. 2026년 10월 16일 기준으로 확인되는 공식 문서들을 종합하면, 최근의 에이전트 표준은 연결 방식과 작업 흐름은 넓히고 있지만 최종 승인과 권한 검사는 모델이 아니라 애플리케이션, 운영자, 사용자 쪽에서 설계하라고 요구하는 쪽에 가깝다.
이 점은 2025년 12월 9일 앤스로픽이 모델 컨텍스트 프로토콜, MCP를 리눅스 재단 산하 에이전틱 AI 파운데이션에 기증한다고 발표한 뒤 더 분명해졌다. MCP는 AI 애플리케이션과 외부 도구를 잇는 개방형 표준으로 자리 잡고 있지만, 표준이 연결을 열어준다고 해서 곧바로 결제 승인 책임까지 가져가는 것은 아니다. 실제 통제는 어떤 도구를 어떤 조건에서 호출하게 할지, 승인 단계를 어디에 둘지, 취소 요청이 실제로 어느 시점까지 효력을 가지는지 따로 정해야 한다.
읽기 권한과 쓰기 권한은 같은 위험이 아니다
MCP 공식 문서는 권한 부여를 서버 전체 단위와 도구별 단위로 나눠 설명한다. 모든 요청에 토큰을 요구하는 방식도 가능하고, 특정 도구 호출에만 별도 인증을 거는 방식도 가능하다는 뜻이다. 이 구조는 곧 읽기 권한과 쓰기 권한을 한 묶음으로 주지 말라는 설계 원칙으로 읽힌다.
예를 들어 재고 조회, 사내 문서 검색, 배송 상태 확인처럼 정보를 읽는 도구는 잘못 연결되면 정보 노출 문제가 생긴다. 그러나 주문 생성, 계정 수정, 관리자 권한 변경처럼 외부 상태를 바꾸는 도구는 손실이 즉시 현실화될 수 있다. MCP 문서가 보호 대상 도구를 요청 본문 단계에서 가려내 HTTP 401로 막도록 한 이유도, 민감한 도구를 일반 조회 도구와 같은 선상에 두지 말라는 뜻에 가깝다.
여기에 A2A 프로토콜은 다른 계층의 통제를 더한다. A2A 명세는 서버가 모든 요청마다 인증과 인가 검사를 해야 하고, 작업 조회나 취소 같은 후속 동작도 호출자의 권한 범위 안에서만 처리해야 한다고 적고 있다. 에이전트끼리 협업하더라도, 한 번 시작한 작업의 존재 여부와 진행 상태 자체가 권한 정보가 될 수 있다는 의미다.
금전 거래 권한은 승인 단계가 따로 있어야 한다
주문이나 결제는 읽기나 일반 쓰기보다 한 단계 더 높은 위험으로 봐야 한다. A2A 명세는 파괴적 행동 이전에 사람의 승인이 필요할 수 있다고 적고, 그런 경우 작업 상태를 인증 필요 상태로 돌려 클라이언트가 승인을 채우도록 할 수 있게 해 둔다. MCP의 태스크 확장도 사용자 승인 같은 입력이 들어올 때까지 작업을 멈춰 세우는 사람 개입형 흐름을 지원한다.
오픈AI의 공식 개발 문서는 이 지점을 더 직접적으로 말한다. 각 도구 호출마다 애플리케이션이 인수와 권한을 다시 검사해야 하며, 영향이 큰 행동은 호출 주체가 누구든 애플리케이션 수준의 승인을 요구하라고 권고한다. 또 에이전트 SDK는 배포와 저장 방식뿐 아니라 승인과 런타임 통합을 애플리케이션이 제어한다고 설명한다. 요컨대 모델이 결제 요청을 제안할 수는 있어도, 결제를 허용하는 마지막 열쇠는 별도 통제 계층에 있어야 한다는 얘기다.
구매 업무에 적용하면 흐름은 더 선명해진다. 상품 탐색, 견적 비교, 장바구니 초안 작성까지는 자동화 범위에 넣을 수 있다. 그러나 결제 수단 선택, 발주 확정, 실제 청구 전송은 승인 게이트를 별도로 둬야 한다. 이때 승인은 단순한 예외 처리 버튼이 아니라, 어떤 금액 이상부터 누가 승인하는지, 어떤 공급처는 자동 발주를 허용하는지, 승인 기록은 어디에 남는지까지 포함한 정책이어야 한다.
취소 버튼이 있어도 이미 끝난 거래는 되감기 어렵다
승인 못지않게 중요한 것이 철회권이다. 다만 공식 문서가 보여주는 현실은 예상보다 보수적이다. MCP 태스크 확장은 tasks/cancel을 취소 의사의 통지로 정의하고, 서버는 이를 확인만 할 의무가 있을 뿐 실제 작업 중단은 협조적이며 최종적으로 취소 상태가 보장되지 않는다고 적고 있다. A2A도 작업 취소를 시도할 수는 있지만 성공이 보장되지 않는다고 명시한다.
이 말은 주문 자동화에서 취소 기능을 과신하면 안 된다는 뜻이다. 결제 승인이 외부 결제망에 넘어간 뒤라면, 그 다음 단계는 단순 취소가 아니라 환불, 재주문, 한도 복구, 회계 정정 같은 별도 절차가 될 수 있다. 따라서 취소권 설계는 사후 중단 버튼보다 먼저, 실제 금전 거래 직전의 대기 구간과 재확인 절차를 얼마나 두느냐에서 시작해야 한다.
실무적으로는 세 겹의 분리가 필요하다. 첫째, 조회 도구와 변경 도구를 분리하고 각각 다른 자격 증명과 로그 정책을 둬야 한다. 둘째, 변경 도구 안에서도 금전 거래처럼 비가역적 비용이 생기는 기능은 별도 승인과 한도 규칙을 적용해야 한다. 셋째, 취소는 권한만 부여한다고 끝나지 않으므로 주문 전, 승인 직후, 정산 후를 나눠 서로 다른 복구 절차를 설계해야 한다.
표준이 해결한 것은 연결, 남은 것은 책임 경계
MCP와 A2A 같은 표준은 에이전트가 도구를 찾고, 다른 에이전트와 일을 나누고, 중간에 인증이나 사용자 입력을 요구하는 공통 형식을 마련하는 쪽으로 빠르게 진전하고 있다. 그러나 이번에 확인한 공식 문서만 놓고 보면, 누가 승인하고 누가 철회하느냐의 답은 프로토콜 안에 자동으로 들어 있지 않다. 그 답은 서비스를 운영하는 기업이 권한 모델, 승인 정책, 취소 후 복구 절차를 어디까지 세분화하느냐에 달려 있다.
결국 AI에게 구매를 맡기는 설계의 핵심은 자율성의 확대가 아니라 책임 경계의 명문화다. 읽기 권한만 준 보조 도구인지, 쓰기 권한을 가진 실행 도구인지, 실제 돈을 움직일 수 있는 거래 에이전트인지를 먼저 나누지 않으면 승인도 취소도 형식에 그칠 수 있다. 에이전트 시대의 통제는 모델 성능보다 권한 설계에서 먼저 실패하거나 성공할 가능성이 크다.
자료: Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation(2025-12-09); MCP Apps, Authorization(연도 미표기); Model Context Protocol, Tasks Extension Overview(연도 미표기); Model Context Protocol, Tasks Specification 2026-07-28(2026); A2A Protocol Working Group, A2A Protocol Specification v1.0.1(연도 미표기); OpenAI, Agents(연도 미표기); OpenAI, Programmatic Tool Calling(연도 미표기)