AI에게 주문 취소를 맡기려면 허락의 경계부터 보여야 합니다
AI에게 주문 취소를 맡길 때는 어느 주문에 무엇을 해도 되는지, 조건이 달라지면 어디서 멈출지까지 정할 수 있어야 합니다. Sierra와 Meta가 2026년 10월 6일 발표한 Personal Agent Protocol(PAP)은 개인 AI와 기업 사이의 접근·위임 관계를 다루려는 제안입니다. 연결이 빨라지는 만큼 사용자가 허락한 범위도 분명히 남는지 살펴볼 필요가 있습니다.
취소해줘라는 부탁이 끝나는 지점
잘못 주문한 물건을 AI에게 취소해달라고 부탁했다고 가정해보겠습니다. 판매자가 무료 취소를 허용하고 원래 결제수단으로 환불해준다면 판단은 비교적 간단합니다. 그런데 상품이 이미 출고돼 반품 배송비가 들거나, 판매자가 환불 대신 적립금을 제안하면 어떻게 해야 할까요. 주문을 정리한다는 목적은 같아도 사용자가 받아들이는 결과는 달라집니다.
주문 상태를 읽는 일, 취소 요청을 넣는 일, 비용을 수락하는 일, 환불 방식을 바꾸는 일은 각각 나누어 볼 필요가 있습니다. 사람이 직접 처리할 때는 화면을 넘기며 이런 조건을 확인합니다. AI에게 맡기면 그 화면을 보지 않아도 되지만, 결정해야 할 조건 자체가 사라지지는 않습니다. 사용자의 짧은 말을 시스템이 실행 가능한 허락으로 어떻게 옮기는지가 중요한 이유입니다.
Sierra의 발표에서 PAP는 사용자가 개인 에이전트의 접근 권한을 정하고, 기업은 열어줄 기능과 경로를 정하는 구조입니다. 개인 에이전트는 비회원으로 시작해 필요한 시점에 인증하고 읽기·쓰기 권한을 받으며, 웹사이트·API·기업 에이전트에 걸쳐 같은 세션을 이어간다는 구상입니다. Sierra 자료 1 처음에는 반품 규정을 알아보고, 계정에 들어간 뒤 특정 주문을 처리하는 흐름을 연결하려는 것입니다.
연결을 허락하는 것부터 업무 조건까지
PAP 세션의 기반으로 소개된 것은 OAuth입니다. Sierra 자료 1 OAuth 2.0에서 접근 토큰은 앱이 허용된 자원에 접근할 때 제시하는 수단이며, 권한 범위와 유효기간 같은 조건으로 접근을 제한할 수 있습니다. IETF / RFC Editor 자료 2 기업 쪽에서 어느 앱이 어떤 허가로 요청하는지 확인할 공통 기반이 있다는 뜻입니다. 소비자의 자연어 부탁을 그대로 기업 시스템의 권한으로 옮기는 일에는 더 구체적인 표현이 필요합니다.
예를 들어 주문 변경이라는 넓은 권한에는 취소뿐 아니라 배송지나 수량 변경도 들어갈 수 있습니다. 사용자의 의도가 “이 주문만, 추가 비용 없이 취소”였다면 대상과 행동과 비용 조건을 함께 묶어야 맞습니다. 읽기·쓰기 선택은 출발점이고, 실제로 맡기는 업무에는 그 아래의 구분이 필요합니다.
이런 문제는 기존 OAuth 표준에서도 다룹니다. IETF의 RFC 9396, Rich Authorization Requests는 넓은 scope 문자열로 표현하기 어려운 권한을 구조화해 전달하는 방법을 정의합니다. 특정 대상·행동·금액을 담은 요청이나 경로마다 다른 파일 권한이 그 예입니다. IETF / RFC Editor 자료 3 PAP가 이 표준을 채택했다는 뜻은 아닙니다. 새 사양을 평가할 때 구체적인 업무 조건을 서버가 검사할 수 있게 표현하는지 비교할 기준이 됩니다.
주문 취소에 적용한다면 아래처럼 질문을 나눠볼 수 있습니다. 이 표는 발표된 PAP의 기능표가 아니라, 앞의 가상 부탁을 처리하려면 필요한 조건을 정리한 것입니다. 승인 화면에 “쓰기 허용”만 남는지, 실제 부탁의 경계가 남는지 살펴보는 데 도움이 됩니다.
| 처리할 일 | 허락에 담아야 할 조건 | 조건이 바뀌면 |
|---|---|---|
| 주문 상태 확인 | 어느 주문을 조회할지 | 다른 주문·주소록까지 읽어야 하는지 확인 |
| 취소 요청 | 그 주문의 취소만 허용할지 | 배송지·수량 변경은 별도로 판단 |
| 비용·환불 확인 | 추가 비용과 환불 방식의 허용 범위 | 배송비 발생·적립금 전환이면 사용자에게 질문 |
| 처리 완료 | 요청 접수와 실제 완료를 어떻게 확인할지 | 응답이 끊기면 중복 요청 전에 기존 상태 확인 |
창구가 바뀌어도 부탁의 조건은 따라가야 합니다
웹사이트에서 주문을 확인하고 기업의 상담 에이전트에게 예외를 물어볼 수 있다면 처음부터 설명을 반복하는 수고가 줄어듭니다. PAP가 제안하는 채널 간 세션 연결은 이런 흐름에 맞닿아 있습니다. Sierra 자료 1 다만 같은 방문이라는 맥락을 잇는 것에 더해, 처음 허락한 조건도 다음 경로로 정확히 전달되어야 합니다.
앞의 예에서 웹페이지에는 무료 취소가 어렵다고 나오고 상담 에이전트가 유료 반품을 제안할 수 있습니다. 이때 사용자가 맡긴 것은 추가 비용 없는 취소였습니다. 경로를 바꿨다는 이유로 허용 조건까지 넓어져서는 곤란합니다. 다음 창구에서도 원래 조건을 확인하고, 조건이 맞지 않으면 실행을 멈춰 다시 묻는 과정이 필요합니다.
통신이 끊기는 경우도 생각해볼 만합니다. 기업이 취소 요청을 받았는데 개인 AI가 완료 응답을 못 받았다면, 사용자는 실패한 것으로 볼 수 있습니다. 다른 경로에서 다시 요청하기 전에 이전 작업이 접수됐는지 확인할 수 있어야 합니다. 빠르게 연결하는 표준이 실제 일 처리의 신뢰도를 높이려면 요청의 연속성과 결과를 추적하는 방법까지 읽혀야 합니다. 이 역시 공개 사양과 구현에서 확인할 질문입니다.
기록은 사용자가 이해하는 형태로 돌아와야 합니다. “작업 성공” 한 줄보다 어느 주문이 취소됐고, 어떤 환불 방식이 선택됐으며, 아직 판매자의 확인을 기다리는지 보여주는 편이 유용합니다. 요청을 전송한 사실과 실제 처리가 끝난 사실이 구분되면, 나중에 직접 고객센터에 문의해야 할 때도 같은 설명을 다시 조립할 부담이 줄어듭니다.
연결 해제로 이미 처리한 주문까지 돌아오지는 않습니다
위임의 끝도 구체적이어야 합니다. OAuth의 RFC 7009는 발급된 토큰을 무효화하는 절차를 정의합니다. 무효화는 즉시 이루어져야 하지만 서버들 사이에 전파 지연이 있을 수 있으며, 관련 토큰을 어디까지 함께 무효화하는지는 정책과 지원 방식에 영향을 받습니다. IETF / RFC Editor 자료 4 제품이 “연결 해제”를 제공할 때 무엇이 끊기는지 설명해야 하는 이유입니다.
토큰 철회는 이후 접근을 막는 절차입니다. 판매자 시스템에서 주문 취소를 이미 처리했다면, 접근 권한을 없애는 것만으로 그 주문이 복구되지는 않습니다. 접수된 반품 요청을 철회하거나 취소된 상품을 다시 주문하는 일은 별도의 업무입니다. 사용자가 권한을 거둬들일 때 진행 중인 요청과 확정된 결과도 함께 확인할 수 있어야 합니다.
이 차이는 특히 오래 걸리는 업무에서 중요합니다. 상담 답변을 기다리는 동안 사용자가 마음을 바꿨다면 개인 AI의 대기를 끝내는 것과 기업이 이미 시작한 처리를 중단하는 일이 어디까지 연결되는지 알아야 합니다. 읽을 권한, 실행할 권한, 접수된 업무의 상태를 나눠 보여주면 사용자가 다음 조치를 선택할 수 있습니다. 버튼 이름 하나로 이 모든 상태를 표현하려 하면 오해가 남습니다.
편리한 위임인지 판단할 기준은 사용자 쪽에도 있습니다
2026년 10월 7일 확인한 Sierra 발표에서 PAP v0.1 사양은 같은 달 중 공개 예정입니다. 더 세밀한 권한, 푸시 알림, 카드 정보를 공유하지 않는 결제 확장은 앞으로의 가능성으로 소개됐습니다. Sierra 자료 1 지금 공개된 구상에서 기대할 방향과, 사양·제품으로 확인할 부분을 구분해 읽을 시점입니다.
개인 AI와 기업이 요청마다 다른 연결 방식을 맞추는 부담을 줄이겠다는 취지는 유용합니다. 기업이 정한 경로로 필요한 정보를 받고 작업할 수 있다면 화면을 반복해서 읽고 클릭하는 과정도 줄일 수 있습니다. 다만 기업이 열어주는 기능이 소비자에게 필요한 일을 충분히 포함하는지는 별도로 봐야 합니다. 구매는 간단한데 취소·환불만 다른 창구를 여러 번 거쳐야 한다면, 연결 방식이 통일돼도 소비자가 느끼는 수고는 크게 줄지 않습니다.
이 제안을 평가할 때는 평범한 취소 요청 하나를 끝까지 따라가보는 편이 좋겠습니다. 추가 비용이 생겼을 때 다시 묻는지, 상담 창구로 옮겨도 같은 조건을 지키는지, 응답이 끊겼을 때 이미 접수된 일을 찾아내는지, 권한을 거둔 뒤 남은 작업을 알려주는지 보는 것입니다. 이런 장면에서 사용자가 자기 결정을 되찾을 수 있어야 AI에게 맡기는 일이 편해집니다.
주문 취소를 맡긴 사람은 프로토콜 이름을 알 필요가 없습니다. 부탁한 조건대로 끝났는지, 바뀐 조건이 있으면 결정하기 전에 물어왔는지 알면 됩니다. PAP가 만들어낼 공통 규칙의 가치는 그 짧은 부탁과 실제 결과 사이를 얼마나 분명하게 이어주는지에서 드러날 것입니다.