당신의 결제 API는 AI 에이전트를 위해 설계되지 않았습니다. Open Banking이 해결책이 될 수 있습니다.

Stripe는 방금 Agentic Commerce Suite를 출시했습니다. PayPal은 Agent Ready를 선보였습니다. Visa는 2026년 연말 시즌까지 수백만 명의 소비자가 구매를 완료하기 위해 AI 에이전트를 사용할 것이라고 예측합니다. Mastercard는 자체 검증 계층을 갖춘 Agent Pay를 도입했습니다. Google은 60개 이상의 파트너와 함께 Agent Payments Protocol을 출시했습니다.

모두가 AI 에이전트가 결제를 수행할 수 있도록 만들기 위해 서두르고 있습니다.

그리고 저는 이 모든 것을 보며 계속 이런 생각을 합니다. 여러분은 결제 페이지를 응시하는 인간을 위해 설계된 스택(Stack)에 에이전트 지원 기능을 억지로 끼워 맞추고 있습니다. 그것은 통합(Integration)이 아니라 개조(Retrofit)입니다.

저는 결제 인프라를 운영하고 있습니다. 저희 플랫폼은 영국 가맹점들을 위해 Open Banking(오픈 뱅킹) 결제를 처리합니다. 이는 카드 네트워크를 거치지 않고 고객의 은행 계좌에서 직접 돈이 이동하는 방식입니다. 제가 보기에, 에이전트 결제(Agentic payments)에 관한 논의에는 Visa의 가맹점 수수료(Interchange fee)만큼이나 큰 사각지대가 존재합니다.

설명해 보겠습니다.

카드 스택은 인간이 존재한다고 가정합니다

오늘날 카드 결제를 처리할 때 발생하는 과정은 다음과 같습니다:

사용자가 양식에 카드 번호를 입력합니다 (또는 저장된 카드를 탭합니다)
프론트엔드(Frontend)가 PAN 데이터를 수집하여 토큰화 계층(Tokenisation layer)으로 전송합니다
토큰이 매입사(Acquirer)로 전달되면, 매입사는 카드 네트워크와 통신하고, 카드 네트워크는 발급 은행(Issuing bank)과 통신합니다
3D Secure(3DS)가 작동합니다 — 사용자는 푸시 알림이나 SMS OTP를 받습니다
발급 은행이 승인(또는 거절)합니다
며칠 후 결제(Settlement)가 이루어집니다

이 흐름은 단 하나의 가정하에 설계되었습니다: 인간이 화면 앞에 앉아 인증 요구 사항에 응답할 준비가 되어 있다는 것입니다.

이제 인간을 AI 에이전트로 교체해 보십시오.

에이전트는 OTP를 읽을 눈이 없습니다. 뱅킹 앱의 푸시 알림에서

그렇다면 카드 네트워크(card networks)는 무엇을 할까요? 그들은 우회책(workarounds)을 만듭니다. Stripe의 에이전트 제품군(agentic suite)은 가상 카드(virtual cards)를 생성합니다. Mastercard의 Agent Pay는 에이전트를 사전 등록하고 일부 인증(auth) 단계를 건너뜁니다. 모두가 자신들이 구축한 인증 장벽(authentication wall)을 우회하기 위한 영리한 방법들을 찾아내고 있습니다.

이것이 바로 신호입니다. 생태계 전체가 스스로 만든 보안 계층(security layer)을 우회하기 위해 엔지니어링을 하고 있다면, 그 아키텍처(architecture)에는 문제가 있는 것입니다.

오픈 뱅킹(Open banking)은 기계 간의 통신을 위해 구축되었습니다

오픈 뱅킹(Open banking)은 다르게 작동합니다. 카드 번호가 없습니다. PAN(Primary Account Number)도 없습니다. 토큰화 금고(tokenisation vault)도 없습니다. 3DS iframe도 없습니다.

흐름은 다음과 같습니다:

귀하의 앱(또는 에이전트)이 결제 개시 API(payment initiation API)를 호출합니다.
API가 고객의 은행으로 리다이렉트 URL(redirect URL)을 반환합니다.
고객이 자신의 은행에서 직접 인증합니다 (생체 인식, 앱 기반 SCA).
은행이 결제를 확인합니다.
돈이 이동합니다. 결제(Settlement)는 즉시 또는 당일 이루어집니다.

무엇이 다른지 주목하십시오. 결제 API는 깔끔하고 상태가 없는(stateless) 요청-응답 인터페이스입니다. 인증은 귀하의 체크아웃 흐름(checkout flow) 내부가 아니라 은행 측에서 발생합니다. 귀하의 코드는 카드 번호를 절대 보지 않으며, OTP를 처리하지도 않고, 인증 챌린지(auth challenge)를 렌더링하지도 않습니다.

체크아웃 페이지를 사용하는 인간에게 이것은 훌륭한 UX 개선입니다. 결제 API를 호출하는 AI 에이전트에게 이것은 구조적인 이점입니다.

에이전트는 API 호출을 합니다. 결제 URL을 돌려받습니다. 그리고 일회성 은행 인증을 위해 그 URL을 인간에게 전달합니다. 끝입니다. 에이전트는 인증을 처리할 필요가 없습니다. 은행이 처리합니다. 관심사의 분리(separation of concerns)가 깔끔합니다.

그리고 이제 영국에서 VRP(Variable Recurring Payments, 가변 반복 결제)가 시행됨에 따라 상황은 더욱 좋아집니다. 인간이 한 번 인증하고 지출 한도를 설정하면, 에이전트는 추가적인 인간의 상호작용 없이 해당 한도 내에서 결제를 개시할 수 있습니다. 가상 카드도 필요 없고, 사전 등록된 에이전트 신원도 필요 없습니다. 그저 권한 부여(mandate)에 따른 API 호출만 있으면 됩니다.

이것은 우회책이 아닙니다. 아키텍처가 설계된 대로 실제로 작동하는 것입니다.

에이전트가 카드 API를 사용할 때 발생하는 문제

저는 개발자들이 카드 레일 (card rails) 상에서 에이전트 기반 결제 흐름 (agentic payment flows)을 구축하려고 시도하는 것을 지켜봐 왔습니다. 여기서 계속해서 문제가 발생하는 지점들은 다음과 같습니다:

PCI 범위의 폭발적 증가 (PCI scope explosion). 만약 당신의 에이전트가 가상 카드 (virtual cards)를 생성하거나, 카드 토큰 (card tokens)을 저장하거나, 카드 정보 저장 (card-on-file) 관계를 관리한다면, 당신의 PCI 준수 (PCI compliance) 범위는 방금 확장되었습니다. 카드 데이터 (card data)를 처리하는 AI 에이전트는 PAN (Primary Account Number)에 접촉하는 모든 시스템과 동일한 준수 태세를 갖춰야 합니다. 이것은 작은 문제가 아닙니다. 이는 SOC2 범위, 침투 테스트 (penetration testing), 분기별 스캔 등을 의미하며, 이 모든 것이 차라리 은행 간 API 호출 (bank-to-bank API call)을 할 수도 있었던 에이전트를 위해 수행되어야 한다는 뜻입니다.

인증 (Authentication)이 병목 현상입니다. 3D Secure는 인간이 개입하는 체크 (human-in-the-loop check) 방식으로 설계되었습니다. 에이전트를 위해 이를 건너뛰려는 모든 시도는 보안을 약화시키거나 (나쁜 결과), 별도의 인증 시스템을 생성하게 됩니다 (복잡하고 취약함). 오픈 뱅킹 (Open banking)의 방식 — 즉, SCA (Strong Customer Authentication, 강력한 고객 인증)가 결제 창(checkout)이 아닌 은행에서 발생하는 방식 — 은 에이전트가 인증할 필요가 없음을 의미합니다. 에이전트는 그저 API를 호출하기만 하면 됩니다.

결제 지연 (Settlement lag)은 상태 관리 (state management)의 악몽을 초래합니다. 카드 결제는 정산되는 데 며칠이 걸립니다. 에이전트가 다단계 워크플로우 (가격 비교 → 판매자 선택 → 결제 → 배송 확인)를 조율할 때, 에이전트는 결제가 실제로 완료되었는지 알아야 합니다. 카드의 경우, 취소될 수 있는 승인 (authorisation), 화요일에 도착하는 정산 (settlement), 그리고 몇 달 동안 열려 있는 차지백 (chargeback, 결제 취소 요청) 기간을 마주하게 됩니다. 오픈 뱅킹을 사용하면 결제 확인이 실시간으로 이루어집니다. 돈이 실제로 이동했기 때문에 상태 머신 (state machine)이 더 단순해집니다.

카드 레일 (card rails)에서는 마이크로 결제 (Micro-payments)가 작동하지 않습니다. AI 에이전트는 세션당 수백 건의 마이크로 트랜잭션 (micro-transactions)을 생성합니다. 카드 결제의 가맹점 수수료 (interchange fee) 하한선 때문에 1파운드 미만의 거래는 경제적으로 불합리합니다. 오픈 뱅킹의 수수료 구조는 카드 네트워크의 최소 수수료 없이 고정형이거나 백분율 기반입니다. 이것이 바로 오픈 뱅킹이 작고 빈번한 결제가 발생하는 에이전트 패턴 (agentic pattern)에 실제로 작동하는 이유입니다.

제가 실제로 구축할 것

만약 제가 오늘 영국 고객을 위해 에이전트 기반 커머스 통합 (agentic commerce integration)을 시작한다면, 제가 선택할 아키텍처는 다음과 같습니다:

일회성 에이전트 주도 구매의 경우: 오픈뱅킹 결제 개시 (Open banking payment initiation). 에이전트가 API를 통해 결제 요청을 생성하고, 동의 URL (consent URL)을 받아 사용자에게 전달합니다. 단 한 번의 SCA (Strong Customer Authentication, 강력한 고객 인증) 이벤트가 발생하면 자금이 이동합니다. 전체 스택 어디에도 카드 데이터가 존재하지 않습니다.

에이전트 (Agent) → 결제 API (결제 요청 생성)
      → 사용자가 은행 인증 링크를 받음
      → 사용자가 뱅킹 앱에서 승인 (생체 인증)
...

에이전트 관리형 정기 지출의 경우: VRP (Variable Recurring Payments, 가변 정기 결제) 권한 부여 (mandates). 사용자가 월간 한도, 거래당 한도, 승인된 가맹점을 설정하여 권한을 한 번만 부여합니다. 에이전트는 해당 범위 내에서 결제 API를 호출합니다. 재인증이 필요 없습니다. 가상 카드도, 3DS (3-D Secure)도 필요하지 않습니다.

사용자 (User) → VRP 권한 설정 (1회성 SCA)
에이전트 (Agent) → 권한 한도 내에서 결제 API 호출
      → 웹훅 (webhook)을 통한 즉각적인 확인
...

인증 계층 (auth layer)의 경우: 직접 구축하지 마세요. 진심입니다. 은행이 이를 처리합니다. 에이전트의 역할은 결제 흐름을 오케스트레이션 (orchestrate)하는 것이지, 사용자를 인증하는 것이 아닙니다. 이것이 관심사의 분리 (separation of concerns)이며, 에이전트를 위해 구축하든 인간을 위해 구축하든 올바른 결정입니다.

아무도 묻지 않는 진짜 질문

모두가 "어떻게 하면 카드 결제를 AI 에이전트가 사용할 수 있게 만들까?"라고 묻습니다.

저는 그것이 잘못된 질문이라고 생각합니다.

올바른 질문은 이것입니다: 왜 우리는 가장 많은 인간의 상호작용을 요구하는 결제 경로 (payment rail)에서 시작하여, 그 후에 인간을 배제하도록 엔지니어링하려 하는가?

오픈뱅킹은 소프트웨어가 은행 API와 통신한다는 전제하에 구축되었습니다. 인증 계층은 은행에 존재합니다. 결제 지시 (payment instruction)는 깔끔한 API 호출입니다. 결제 (settlement)는 즉각적입니다. 보호해야 할 카드 번호도 없고, 렌더링해야 할 3DS 챌린지도 없으며, 마이크로 트랜잭션 (micro-transactions)에서 마진을 갉아먹는 가맹점 수수료 (interchange fee)도 없습니다.

오픈뱅킹은 AI 에이전트를 위해 설계되지 않았습니다. 하지만 그 아키텍처는 카드 네트워크가 사후에 개조하고 있는 그 어떤 것보다 에이전트 패턴 (agentic pattern)에 더 잘 부합합니다.

때때로 미래는 가장 큰 R&D 예산을 가진 기업으로부터 오지 않습니다. 때때로 미래는 처음부터 올바른 추상화 (abstraction)를 바탕으로 구축된 인프라로부터 옵니다.

영국은 이미 활성화된 오픈 뱅킹 (open banking) 레일과 활성화된 VRP (Variable Recurring Payments)를 갖추고 있으며, FCA (Financial Conduct Authority)는 다음에 올 기술을 위한 규제 프레임워크 (regulatory framework)를 적극적으로 구축하고 있습니다. 만약 당신이 영국 고객을 위한 에이전트 기반 커머스 (agentic commerce)를 구축하는 개발자라면, 이미 유리한 고지를 선점한 것입니다. 이를 활용하십시오.

저는 Atoa의 CTO인 Arun입니다. 저희는 영국 가맹점들을 위한 오픈 뱅킹 결제 인프라를 구축합니다. API가 어떻게 구성되어 있는지 확인하고 싶다면 다음을 방문하세요: docs.atoa.me

샌드박스 (sandbox) 체험하기 → docs.atoa.me