Personal Agent Protocol 대비법: 쇼핑·계정 관리 API를 에이전트 친화적으로 준비하기

Sierra의 Personal Agent Protocol(PAP), Google의 agent registry 논의, Shopify·Stripe·Walmart 같은 파트너 참여 소식은 한 방향을 가리킨다. 사용자의 개인 AI 에이전트가 웹사이트를 사람처럼 클릭하는 대신, 신원을 밝히고 권한을 받아 기업 시스템과 직접 상호작용하는 시대가 오고 있다. 아직 PAP v0.1 같은 정식 스펙이 널리 고정된 것은 아니지만, 커머스와 계정 관리 API를 운영하는 팀은 지금부터 준비할 수 있다.

중요한 점은 “새 표준이 나오면 그때 붙이면 된다”가 아니라는 것이다. 에이전트 친화적인 API는 하루아침에 만들어지지 않는다. 주문 조회, 재고 확인, 환불 요청, 배송지 변경, 구독 해지, 예약 변경 같은 작업은 기존에도 API가 있지만, 사람 UI 기준으로 설계된 경우가 많다. 개인 에이전트가 호출하려면 신원, 동의, 범위, 취소 가능성, 감사 로그가 더 명확해야 한다.

에이전트는 사용자와 같지만 사용자는 아니다

개인 에이전트는 사용자를 대리한다. 하지만 보안 모델에서는 사용자와 완전히 같게 보면 안 된다. 사용자는 화면을 보고 맥락을 이해하고 실수를 감지할 수 있다. 에이전트는 도구 설명과 API 응답을 보고 행동한다. 그래서 같은 권한이라도 더 좁은 scope와 더 많은 확인이 필요하다.

예를 들어 사용자가 직접 배송지를 바꾸는 UI에서는 화면에 기존 주소, 새 주소, 예상 배송 영향이 표시된다. 에이전트 API에서는 이 정보를 구조화해서 제공해야 한다. “주소 변경 가능”, “배송 지연 가능성”, “추가 비용”, “취소 마감 시간” 같은 필드가 없으면 에이전트는 사용자에게 충분히 설명하지 못한다.

또한 에이전트 신원을 구분해야 한다. 요청에는 end user, agent provider, agent instance, consent id가 들어가야 한다. 단순 bearer token 하나로 “사용자가 한 요청”과 “사용자 에이전트가 한 요청”을 구분하지 못하면 사고 조사와 rate limit이 어렵다.

지금 만들 수 있는 API 원칙

첫 번째 원칙은 idempotency다. 에이전트는 네트워크 실패나 불확실한 응답에서 재시도할 수 있다. 주문 취소, 예약 변경, 환불 요청 같은 API에는 idempotency key가 있어야 한다. 같은 key로 같은 요청이 다시 오면 같은 결과를 반환해야 한다. 그래야 중복 환불이나 중복 취소를 막을 수 있다.

두 번째는 dry-run이다. 고위험 작업은 먼저 “실행하면 어떤 일이 생기는지”를 조회할 수 있어야 한다. 예를 들어 구독 해지 dry-run은 남은 기간, 환불 여부, 데이터 삭제 일정, 재가입 제한을 반환한다. 배송지 변경 dry-run은 변경 가능 여부, 예상 도착일 변화, 추가 비용을 반환한다. 에이전트는 이 정보를 사용자에게 보여주고 승인을 받아 실제 실행을 호출한다.

세 번째는 reversible action과 irreversible action의 분리다. 장바구니에 상품을 추가하는 것은 되돌리기 쉽다. 결제, 환불, 계정 삭제, 공개 리뷰 작성은 되돌리기 어렵다. API 문서와 schema에 risk level을 표시해야 한다. MCP나 PAP 같은 표준이 붙을 때도 이 정보는 도구 설명으로 들어가야 한다.

동의와 scope를 작게 만들기

개인 에이전트에게 “내 계정 전체 접근”을 주는 방식은 위험하다. scope는 작업 중심이어야 한다. orders:read, returns:create, address:update:shipping, subscription:cancel:dry_run, subscription:cancel:execute처럼 읽기, dry-run, 실행을 나눠야 한다. 특히 execute scope는 짧은 만료 시간을 가져야 한다.

동의 화면도 사람 친화적이어야 한다. “이 에이전트가 주문 정보를 읽고 반품 요청을 생성할 수 있습니다”처럼 기능 단위로 설명해야 한다. 기술 scope 이름만 보여주면 사용자는 의미를 모른다. 반대로 너무 포괄적인 설명은 나중에 분쟁을 만든다. 동의 기록에는 scope, 만료 시간, 요청 목적, agent id, user id가 들어가야 한다.

세션 기반 동의도 고려할 만하다. 예를 들어 “이번 대화에서 주문 1234의 반품 요청만 허용”처럼 객체 단위로 제한하면 사고 범위가 작다. 개인 에이전트가 여러 사이트를 돌아다니는 미래에는 이런 세밀한 동의가 차별점이 된다.

웹 UI 크롤링을 줄이는 방법

표준이 늦어질수록 에이전트는 웹 UI를 직접 조작한다. 이것은 사업자에게도 나쁘다. bot traffic이 늘고, 폼 제출 오류가 생기고, fraud detection이 오탐을 만들고, 접근성이나 프론트엔드 변경이 에이전트 행동을 깨뜨린다. 그래서 기업은 에이전트가 안전하게 쓸 수 있는 좁은 API를 먼저 제공하는 편이 낫다.

가장 좋은 시작점은 읽기 API다. 주문 상태, 배송 추적, 예약 가능 시간, 반품 정책, 계정 설정 조회처럼 사용자 문의가 많은 영역부터 구조화한다. 이 API가 있으면 개인 에이전트는 웹 페이지를 스크래핑하지 않아도 된다. 그다음 dry-run API를 붙이고, 마지막에 제한된 실행 API를 붙인다.

API 응답은 자연어보다 구조화가 중요하다. canCancel, cancelBy, refundAmount, requiresHumanReview, nextSteps 같은 필드가 있으면 에이전트가 사용자에게 정확히 설명할 수 있다. 긴 정책 문서만 반환하면 모델이 해석해야 하고, 해석 실수가 생긴다.

감사와 분쟁 대응

에이전트가 계정 작업을 대리하면 분쟁이 생긴다. “내 에이전트가 한 일이 맞나”, “내가 동의했나”, “사이트가 충분히 설명했나”, “에이전트가 잘못 이해했나”를 따져야 한다. 따라서 모든 agent action에는 audit trail이 필요하다.

감사 로그에는 user id, agent provider, agent instance, consent id, scope, object id, dry-run response hash, final approval timestamp, idempotency key, result가 들어가야 한다. 특히 dry-run response hash가 중요하다. 사용자가 승인한 조건과 실제 실행 조건이 같았는지 확인할 수 있기 때문이다.

rate limit도 사람 기준과 다르게 잡아야 한다. 개인 에이전트는 한 사용자를 위해 여러 사이트를 빠르게 조회할 수 있다. 정상 사용과 abuse를 구분하려면 user-level, agent-provider-level, endpoint-level limit을 분리해야 한다. 또한 agent traffic을 robots.txt처럼 무조건 막기보다, 인증된 에이전트 채널로 유도하는 정책이 필요하다.

실행 체크리스트

• 주문 조회, 배송 추적, 예약 가능 여부, 반품 정책처럼 조회 수요가 큰 API부터 정리한다.
• 모든 write API에 idempotency key를 요구한다.
• 환불, 취소, 주소 변경, 구독 해지에는 dry-run endpoint를 만든다.
• API 응답에 가능 여부, 마감 시간, 비용, 영향, 다음 단계를 구조화해서 넣는다.
• scope를 read, dry-run, execute로 분리하고 execute scope는 짧게 만료시킨다.
• agent provider, agent instance, end user, consent id를 요청 단위로 구분한다.
• irreversible action은 risk level을 명시하고 human confirmation을 요구한다.
• 동의 기록에는 scope, 목적, 객체, 만료 시간, agent id를 저장한다.
• dry-run response hash와 final execution result를 감사 로그에 남긴다.
• 웹 UI를 조작하는 에이전트 트래픽은 차단만 하지 말고 안전한 API 경로로 유도한다.

Personal Agent Protocol 같은 표준이 언제 어떤 형태로 고정될지는 아직 지켜봐야 한다. 하지만 준비 방향은 이미 분명하다. 깨끗한 API, 작은 scope, dry-run, idempotency, agent identity, 감사 로그다. 이 기반이 있으면 표준이 나오더라도 붙이기 쉽고, 표준이 늦어져도 웹 UI를 무리하게 긁는 에이전트보다 안전한 경로를 제공할 수 있다.