사람이 정한 정책 아래의 에이전틱 결제

에이전틱 결제는 체크아웃에서 사람이 아니라 소프트웨어가 개시하는 결제입니다. AI 에이전트가 자격 증명을 보유하고, 구매가 필요하다고 판단하고, 직접 자금을 움직입니다. 사람이 마지막 버튼을 누르지 않아도 청구서를 지불하고, 구독을 갱신하고, 전세기를 예약합니다. 핵심은 결제를 개시하는 주체입니다. 사람이 구매 버튼을 누르는 것은 앞에 챗봇이 있을 뿐 평범한 카드 결제입니다. 에이전틱 결제는 돈이 실제로 움직이는 순간에 소프트웨어가 판단하고, 승인하고, 정산합니다. 이 분야의 어려움은 모두 이 한 가지 특성에서 나옵니다. 돈을 쓰는 주체가 사람이 아니며, 낯선 상대에게 송금하기 전에 사람처럼 지치거나 의심하거나 긴장하지 않는다는 점입니다.

그래서 흥미로운 질문은 에이전트가 돈을 쓸 것인가가 아니었습니다. 이미 쓸 수 있으니까요. 중요한 질문은 에이전트가 어떤 규칙 아래에서 쓰는지를 누가 정하는가, 그리고 그 규칙을 에이전트의 약속이 아니라 플랫폼이 강제하는가입니다.

실패 양상은 뻔하고, 바로 그 점이 핵심입니다

에이전트에게 사용 가능한 결제 자격 증명을 주고 한도를 두지 않으면, 아직 일어나지 않았을 뿐인 송금 사기 사고를 만든 셈입니다. 잘못되는 방식도 특별하지 않습니다. 웹 페이지에 숨겨진 프롬프트 인젝션이 에이전트에게 공격자에게 결제하라고 지시합니다. 잘못 작성된 도구 설명이 정상적인 구매를 엉뚱한 수취인에게 보냅니다. 성공 신호가 돌아오지 않아 재시도 루프가 같은 결제를 천 번 시도합니다. 이 중 영리한 공격자가 필요한 경우는 없습니다. 자율 소프트웨어에서 흔히 생기는 버그이고, 다만 결과물이 계좌에서 빠져나가는 돈이라는 점이 다릅니다.

솔깃한 해법은 에이전트를 더 신중하게 만드는 것입니다. 더 나은 시스템 프롬프트, 더 엄한 지시, 지출을 더 깊이 따져 보는 모델 같은 것입니다. 하지만 이는 통제를 시스템에서 가장 믿기 어려운 곳, 즉 설득으로 무너질 수 있는 에이전트 자신의 추론에 맡기는 일입니다. 에이전트가 논리로 넘어설 수 있는 예산은 예산이 아닙니다. 통제는 에이전트가 닿을 수 없는 곳, 즉 에이전트 바깥에 있어야 합니다.

핵심은 프롬프트가 아니라 정책입니다

통제 모델은 에이전트가 결정한 뒤가 아니라 돈이 움직이기 전에 플랫폼이 정책을 강제하는 방식입니다. 각 에이전트에는 건당 한도와 일일 한도가 설정됩니다. 데모 정책에서는 결제당 €150.00, 하루 €500.00이며, 그 위에 월 한도 €6,000.00이 있습니다. 이는 에이전트의 약속이 아니라 플랫폼이 확인하는 하드 월입니다. 데모의 여행 봇이 €640.00짜리 전세기를 예약하려 하자, 결제는 한도 초과로 즉시 거부되었고 1센트도 움직이지 않았습니다. 매일 완벽하게 동작하는 에이전트라도 한 달 한도를 넘어 흘러갈 수는 없습니다.

예산이 얼마까지인지를 정한다면, 허용 목록은 어디로인지를 정합니다. 에이전트는 미리 지정한 가맹점에만 결제합니다. 데모의 Ops Agent가 아는 가맹점은 정확히 네 곳이며, 목록에 없는 업체에 €180.00을 결제하려는 시도는 미등록 사유로 거부되었습니다. 두 가지가 합쳐져 하나의 상자를 그립니다. 이 금액까지, 이 수취인에게만. 상자 안에서 에이전트는 최고 속도로 움직이며 허락을 구할 필요가 없고, 그 상자는 사람이 소유합니다.

문제는 AI 에이전트가 돈을 쓰느냐가 아닙니다. 에이전트가 어떤 규칙 아래에서 쓰는지를 누가 정했느냐입니다. 그 답은 언제나 사람이어야 하고, 사전에, 문서로 정해져 있어야 합니다.

기준선 위에는 사람이

어떤 결정은 상자에 맡기기에는 너무 큽니다. 그래서 정책에는 임계값이 있습니다. 이 금액을 넘으면 결제가 진행되기 전에 사람의 승인이 필요하다는 기준입니다. 데모에서 이 기준선은 €100.00입니다. Ops Agent가 Nord Logistics의 #088번 청구서 €120.00을 확인했을 때, 일일 예산 €500.00 안에는 충분히 들어왔지만 승인 기준선은 넘었습니다. 에이전트는 결제하지 않았습니다. 멈춘 채 사람에게 제안을 올리고 기다렸습니다. 한 줄 답장으로 승인이 났고, 결제는 참조번호 9F21-0716으로 정산되어 09:41에 감사 로그에 기록되었습니다. 기준선 아래에서는 에이전트가 스스로 움직이고, 그 위에서는 사람이 먼저 답합니다.

승인은 흔적 없이 사라지는 체크박스가 아닙니다. 누가, 어떤 기기에서, 언제, 어떤 서명으로 승인했는지가 기록됩니다. 앱에서 승인, 휴대폰 키, 09:41:12 같은 식입니다. 나중에 누군가 결제가 왜 일어났는지 물으면, 답은 얼버무림이 아니라 실명의 담당자와 타임스탬프입니다.

킬 스위치, 그리고 몰래 고칠 수 없는 로그

튼튼한 벽 안에서도 에이전트는 오작동하고 정책은 틀릴 수 있습니다. 이를 다루는 통제가 두 가지 있습니다. 첫째는 킬 스위치입니다. 한 번의 탭으로 에이전트를 일시 중지하고, 에이전트가 개시할 수 있는 모든 결제를 즉시 차단합니다. 키는 유효한 상태로 유지되어 다른 기능에는 영향이 없습니다. 사람이 다시 켜기 전까지 에이전트가 지출할 수 없을 뿐이며, 대기 중인 제안은 사라지지 않고 그대로 멈춥니다. 데모 플릿에서 여행 봇은 지출 €0.00인 채 일시 중지되어 있고, 대기열도 그대로 남아 있습니다.

두 번째는 append-only 감사 로그입니다. 모든 결정이 기록으로 남습니다. 에이전트가 무엇을 시도했는지, 어떤 정책 검사를 통과하거나 실패했는지, 누가 무엇을 승인했는지, 키 교체까지 빠짐없이 담깁니다. 기록 하나만으로 결제 전체를 재구성할 수 있습니다. 결정 DEC-4471에는 요청, 각 정책 검사와 결과(허용 목록 통과, 한도 통과, 임계값 에스컬레이션), 담당자의 서명, 그리고 레일과 참조 번호가 포함된 정산 금액이 들어 있습니다. 각 항목은 자체 해시, 이전 항목의 해시, 체인 내 위치(데모에서는 #4,471)를 가지므로 어느 필드를 수정해도 이후의 모든 기록이 깨집니다. 로그는 해시를 포함한 JSON으로 내보낼 수 있습니다. 로그는 저희가 보관하는 것이 아니라, 고객이 감사인에게 직접 전달할 수 있는 고객의 자산입니다.

정산은 단조롭게, 새로움은 승인 단계에

에이전트 결제를 처음부터 끝까지 전부 새롭게 만들고 싶은 유혹이 있습니다. 새로운 레일, 새로운 결제 수단, 새로운 자금 이동 방식까지. 그러나 이 유혹은 피해야 합니다. 진짜 새로운 부분은 승인입니다. 에이전트가 결제할 권한이 있음을 어떻게 증명하는지, 누구의 정책에 따르는지, 어떤 승인을 거치는지가 핵심입니다. 이 관문을 통과한 결제는 수년간 검증된 단조로운 레일에서 정산되어야 합니다. 데모에서 승인된 €120.00 제안은 일반 SEPA 계좌이체가 되고, 승인 몇 분 뒤 SEPA Instant로 정산됩니다. 이후 단계에서는 사람이 한 결제와 구별되지 않습니다. 은행은 에이전트가 시작했다는 사실을 알지도, 신경 쓰지도 않습니다.

이 분리는 의도된 설계입니다. 단조로운 레일은 예측 가능하고, 결제망이 허용하는 범위에서 취소할 수 있으며, 앞으로 만날 모든 재무팀과 감사인이 이미 이해하고 있습니다. 새로움은 정책에 두고 결제는 검증된 레일에 올리면, 위험하고 빠르게 변하는 부분은 전적으로 직접 통제할 수 있고, 다른 은행과 맞닿는 부분은 누구도 새로 배울 필요가 없습니다. 에이전트는 로봇을 위해 따로 만든 평행 세계가 아니라, 다른 결제 제품군이 운영되는 것과 같은 코어에서 지출합니다. 자세한 내용은 /products/pay에서 확인할 수 있습니다.

프로토콜 환경은 아직 정리되지 않았습니다. 이를 전제로 설계하십시오

에이전트가 가맹점에 자신의 신원과 권한(mandate)을 어떻게 제시해야 하는지는 아직 열려 있는 질문입니다. 에이전트가 누구인지, 무엇을 구매할 권한이 있는지, 가맹점이 대금을 받기 전에 이를 어떻게 확인하는지를 두고 여러 제안이 경쟁하고 있습니다. 아직 승자는 없으며, 지금 어느 하나에 전부를 거는 것은 성급합니다. 방어적인 접근은 승인 프로토콜을 교체 가능하게 두고 그 뒤의 모든 것을 안정적으로 유지하는 것입니다. 앞단의 와이어 포맷이 바뀌어도 정책 엔진, 감사 모델, 정산 레일은 바뀌지 않습니다.

실무에서는 작고 단조로운 연동 범위를 뜻합니다. 에이전트는 mcp.protocore.io/agents에서 MCP로 연결하며, 이 프로토콜을 지원하는 어떤 프레임워크든 지갑을 보유할 수 있습니다. 인터페이스는 의도적으로 좁게 설계했습니다. 결제를 제안하고 결정을 받는 것이 전부입니다. 중요한 로직은 프롬프트가 아니라 플랫폼에 있기 때문입니다. 업계가 에이전트의 가맹점 증명 방식을 정리하면 앞단은 바뀌겠지만, 그 뒤의 방어선은 지금 그대로 유지됩니다.

전체 구조에서의 위치

에이전트 결제는 자율 소프트웨어가 한도 없이 지출해야 한다는 데 거는 베팅이 아닙니다. 오히려 정반대입니다. 소프트웨어는 어차피 지출하게 될 것이므로, 한도는 실질적이고 외부에 있으며 읽을 수 있어야 한다는 베팅입니다. 예산과 허용 목록이 범위를 정하고, 임계값이 큰 건을 담당자에게 넘기며, 킬 스위치가 모든 것을 멈추고, append-only 로그가 모든 결제를 사후에 재구성할 수 있게 합니다. /products/agents 제품 페이지에서는 여기에 쓰인 데모 데이터로 전체 흐름을 보여 줍니다. 에이전트를 만들고, 정책을 설정하고, 결제가 에스컬레이션되어 정산되는 과정까지 확인할 수 있습니다. /products/pay는 이 결제들이 동작하는 코어입니다. 자율성은 실재하고, 그것을 쥐는 고삐도 실재하며, 그 고삐는 사람이 쥡니다.