Stripe Link CLI는 AI 에이전트가 사용자의 실제 카드번호를 직접 들고 다니지 않고, 사용자가 승인한 지출 요청 안에서 일회용 결제 자격증명으로 구매를 진행하게 만드는 실험적 결제 도구다.
이 글은 실제 결제까지 돌린 후기가 아니다. 2026년 5월 18일 기준 공개된 Stripe Link CLI GitHub README, Stripe 공식 블로그, Stripe agentic commerce 문서, GeekNews 요약을 기준으로 운영자가 먼저 봐야 할 권한 경계를 정리한 글이다. 이 선을 먼저 그어야 나중에 “에이전트가 결제까지 한다더니 왜 로그에 카드가 남았지” 같은 장면을 피할 수 있다.
AI 에이전트에게 결제를 맡긴다는 말은 꽤 그럴듯하다. 장보기, SaaS 결제, API 호출 결제, 출장 예약 같은 작업을 자동화할 수 있으니까. 그런데 운영 관점에서 질문은 기능이 되는지가 아니라, 누가 얼마까지 어떤 판매자에게 결제하도록 허용했는지 설명할 수 있는가다.
먼저 보는 답변박스
| 체크 | 지금 기준 판단 |
|---|---|
| 사용 가능 범위 | 현재 Link CLI README는 US Link 계정만 가능하다고 안내 |
| 결제 자격증명 | 일반 checkout용 virtual card(PAN) 또는 MPP용 Shared Payment Token(SPT) |
| 승인 구조 | spend request마다 사용자 승인 요청 가능 |
| 에이전트 연결 | CLI, npx, skill 설치, 로컬 MCP 서버 실행 지원 |
| 가장 위험한 지점 | 카드 출력 파일, 로그, MCP 도구 호출, 금액·상점 범위 관리 |
| 한국 운영 판단 | 개인 실사용보다 구조 학습과 권한 설계 참고용으로 먼저 보는 편이 안전 |
이 표에서 제일 중요한 줄은 “사용 가능 범위”다. Stripe Link CLI가 흥미로운 이유는 분명하지만, 현재 README 기준으로 US Link 계정 제한이 있다. 한국 사용자가 바로 결제 자동화 도구로 붙이기보다는, AI 에이전트 결제 권한을 어떻게 설계할지 보는 레퍼런스로 다루는 게 맞다.
Link CLI가 바꾸는 지점
기존 자동화에서 결제는 늘 애매한 영역이었다. API 키는 자동화하기 쉽지만 결제는 사용자의 카드, 3D Secure, 주소, 영수증, 환불, 약관 동의가 섞인다. 그래서 에이전트가 상품을 찾아도 마지막 구매 버튼은 사람이 누르는 구조가 자연스러웠다.
Stripe Link CLI는 이 경계에 “지출 요청”이라는 단계를 넣는다. 에이전트가 판매자, 금액, 상품 맥락을 담아 spend request를 만들고, 사용자가 Link에서 승인하면 그 요청에 맞는 결제 자격증명이 나온다. Stripe 공식 글은 이 자격증명이 일회용 카드 또는 SPT가 될 수 있고, raw payment credential을 에이전트가 직접 보지 않게 하는 방향이라고 설명한다.
운영자가 봐야 할 포인트는 여기다. 에이전트가 돈을 쓰는 게 아니라, 사용자가 승인한 요청의 범위 안에서만 결제 재료를 받는 구조다. 자동화의 핵심이 “무인 결제”가 아니라 “승인 가능한 권한 위임”으로 바뀐다.
이 차이를 놓치면 글이 과장된다. “AI가 내 카드로 마음대로 산다”도 아니고, “이제 결제 보안 문제가 끝났다”도 아니다. 현재 공개 자료 기준으로는 매 요청 승인, 금액과 판매자 범위, 일회용 자격증명, 출력 위치 통제가 함께 붙어야 의미가 있다.
PAN과 SPT는 쓰임새가 다르다
Link CLI README는 두 가지 credential type을 설명한다. 하나는 일반 웹 checkout form에 넣을 수 있는 virtual card, 즉 PAN 방식이다. 다른 하나는 판매자가 Machine Payment Protocols, MPP를 받을 때 쓰는 Shared Payment Token, SPT 방식이다.
PAN 방식은 기존 웹 checkout과 맞닿아 있다. 에이전트가 승인된 spend request를 조회해 카드 번호, CVC, 만료월, 만료년, billing address 같은 값을 받아 checkout form에 넣는 흐름이다. 그래서 범용성은 있지만, 카드 상세가 파일이나 로그에 노출되지 않도록 더 신경 써야 한다.
SPT 방식은 조금 더 agent-native에 가깝다. Stripe 문서는 SPT를 고객 결제수단에 대한 scoped grant로 설명하고, 사용 한도와 만료 시간을 포함한다고 안내한다. 판매자는 SPT를 받아 PaymentIntent를 만들 수 있고, Stripe는 이후 환불이나 리포팅을 일반 PaymentMethod를 쓴 것처럼 다룬다고 설명한다.
MPP까지 붙으면 HTTP 402 기반으로 요청 자체에 결제가 붙는다. MPP 사이트는 API 요청, tool call, 콘텐츠에 대해 에이전트와 앱이 같은 HTTP 호출 안에서 per-request로 결제할 수 있다고 설명한다. 개발자 입장에서는 “월 구독 API key를 미리 발급받는 구조”와 “필요한 호출마다 결제하는 구조”가 갈라지는 지점이다.
설정 전에 볼 권한 경계
첫 번째 경계는 금액이다. Link CLI README는 spend request 생성의 required fields로 payment_method_id, merchant_name, merchant_url, context, amount를 제시하고, amount는 50,000 cents를 넘지 않는다고 설명한다. 금액 제한이 있더라도 운영자는 서비스별로 더 낮은 내부 제한을 둬야 한다.
두 번째 경계는 맥락이다. README 기준 context는 최소 100자가 필요하다. 이건 귀찮은 필드가 아니라 승인 화면에서 사람이 무엇을 승인하는지 이해하게 만드는 설명 필드다. “buy item” 같은 짧은 문장이 아니라, 어떤 상품을 왜 사는지, 사용자가 시작한 요청인지, 대체 선택지는 있었는지를 남기는 편이 안전하다.
세 번째 경계는 출력 위치다. README는 카드 상세를 agent transcript나 로그에 흘리지 않기 위해 --output-file을 쓰라고 안내한다. 이때 전체 card 정보는 로컬 파일에 쓰고, stdout에는 redacted data만 보여주는 구조다. 파일 권한도 0600으로 생성된다고 설명한다.
네 번째 경계는 MCP다. Link CLI는 npx @stripe/link-cli --mcp로 로컬 MCP 서버로 붙일 수 있다. 이건 AI 에이전트 워크플로에 잘 맞지만, 동시에 결제 도구가 에이전트 tool 목록에 들어간다는 뜻이다. MCP에 붙이는 순간 “도구 호출 권한”, “승인 요청 문구”, “출력 파일 경로”, “로그 보존”을 같이 봐야 한다.
다섯 번째 경계는 실패 처리다. README는 polling이 승인, 거절, 만료, 취소 같은 terminal status에 도달해야 성공으로 종료되고, 아직 pending이면 non-zero로 끝나도록 설계되어 있다고 설명한다. 자동화에서는 이게 중요하다. pending 상태를 성공으로 착각하면 에이전트가 다음 단계를 진행하면서 결제 상태와 실제 주문 상태가 어긋난다.
운영 기준표
| 상황 | 허용해도 되는 기본값 | 막아야 할 기본값 |
|---|---|---|
| 개인 구매 보조 | 요청마다 승인, 낮은 금액 제한, 상품 맥락 기록 | 상시 무승인 결제, broad merchant 허용 |
| 개발 테스트 | --test, 테스트 카드, demo flow |
실카드로 unknown merchant 테스트 |
| 일반 checkout | --output-file, redacted stdout, 짧은 보존 기간 |
카드 상세 stdout 출력, transcript 저장 |
| MPP 결제 | SPT, network/seller scope, expiry 확인 | seller scope 불명확한 token 전달 |
| MCP 연결 | 결제 tool 별도 agent에 격리, 로그 scrub | 모든 에이전트 세션에 결제 MCP 상시 연결 |
이 표는 보수적으로 보일 수 있다. 하지만 결제 자동화는 실패 비용이 다르다. 코드 생성이 틀리면 PR에서 막을 수 있지만, 결제는 영수증, 환불, 약관, 배송, 개인정보가 같이 따라온다.
TECHTAEK에서 MCP나 AI 코딩 에이전트 글을 다룰 때 계속 같은 기준을 썼다. 연결 수보다 권한 수가 중요하다. Stripe Link CLI도 “결제 기능 하나 더 붙었다”가 아니라 “에이전트 권한 체계에 돈 쓰는 tool이 들어왔다”로 보는 게 맞다.
언제 쓰지 않는 게 나은가
첫 번째는 승인 맥락을 사람이 이해하지 못하는 경우다. 에이전트가 10개 상품을 비교했고 그중 하나를 사겠다고 해도, 승인 화면에서 왜 이 상품인지 설명하지 못하면 아직 자동 구매로 넘길 단계가 아니다. 승인 가능한 자동화는 설명 가능한 자동화여야 한다.
두 번째는 판매자 경계가 흐릿한 경우다. Stripe 문서는 SPT가 판매자 계정에 grant되고 usage limits와 expiration windows를 포함한다고 설명한다. 반대로 판매자나 cart 범위를 흐릿하게 잡으면 token의 장점이 줄어든다.
세 번째는 로그 정책이 없는 경우다. 결제 credential은 “한 번 쓰고 끝”이어도 로그는 오래 남을 수 있다. agent transcript, 터미널 scrollback, MCP server 로그, CI 로그, Obsidian 자동 캡처까지 어디에 남는지 모르면 연결하지 않는 편이 낫다.
네 번째는 한국 사용자가 당장 실사용하려는 경우다. README 기준 US Link account 제한이 있으므로, 한국 계정·한국 카드·한국 쇼핑몰을 전제로 한 자동화 글로 밀면 위험하다. 지금은 구조 학습, 보안 설계, 제품 방향 관찰용으로 보는 게 정확하다.
기존 에이전트 워크플로와 연결하면
이 주제는 TECHTAEK의 AI 개발 워크플로우 허브와 잘 맞는다. Codex, Claude Code, Copilot cloud agent, MCP는 모두 “에이전트에게 어디까지 맡길 것인가”라는 같은 질문을 공유한다. 코드 권한 다음에는 브라우저 권한이 오고, 브라우저 권한 다음에는 결제 권한이 온다.
개발팀에서 적용한다면 결제 에이전트를 일반 코딩 에이전트와 분리하는 편이 낫다. 코드 작성 agent, 브라우저 확인 agent, 결제 승인 agent를 하나로 섞으면 편하지만, 사고가 났을 때 어느 tool이 어떤 판단으로 결제했는지 추적하기 어렵다.
개인 자동화에서도 비슷하다. 쇼핑 assistant가 물건을 찾아주는 것과 실제 구매 자격증명을 받는 것은 다른 단계다. 검색과 비교는 넓게 열어도 되지만, spend request 생성은 좁게 열어야 한다.
내가 운영한다면 첫 버전은 이렇게 나눌 것 같다. 일반 agent는 상품 후보와 이유만 만든다. 별도 결제 agent는 그 후보를 받아 spend request 초안을 만들되 --test 또는 낮은 금액 제한으로만 시작한다. 사용자가 승인한 뒤에도 카드 상세은 stdout에 찍지 않고 --output-file로만 남긴다.
FAQ
Q1. Stripe Link CLI는 Stripe CLI와 같은 건가?
아니다. Stripe CLI는 Stripe 리소스 관리, webhook 테스트, API 작업에 쓰는 개발자 CLI다. Link CLI는 Link wallet을 통해 에이전트가 일회용 결제 자격증명을 받는 흐름에 초점이 있다.
Q2. AI 에이전트가 카드번호를 그대로 받는 구조인가?
일반 checkout용 virtual card 방식에서는 승인된 요청 뒤 card object를 조회할 수 있다. 다만 README는 transcript나 로그 노출을 피하기 위해 --output-file을 쓰고 stdout에는 redacted data만 보여주는 방식을 안내한다. SPT 방식은 raw PAN을 직접 전달하지 않는 scoped token 쪽에 가깝다.
Q3. SPT는 왜 중요한가?
SPT는 고객 결제수단을 판매자에게 범위 제한된 grant로 전달하는 구조다. Stripe 문서는 usage limits와 expiry limits를 포함하고, primary account number 같은 raw credential을 포함하지 않는다고 설명한다.
Q4. MCP로 붙이면 바로 자동 결제가 되나?
MCP 서버로 실행할 수 있다는 것과 무승인 자동 결제가 된다는 것은 다르다. README와 Stripe 공식 글 기준 핵심은 spend request와 사용자 승인이다. MCP는 연결 방식이고, 결제 승인과 자격증명 관리는 별도 경계로 봐야 한다.
Q5. 한국에서도 바로 써도 되나?
공개 README 기준 현재는 US Link accounts only로 안내되어 있다. 한국 사용자는 실사용 도구로 보기보다, AI 에이전트 결제 권한 설계와 향후 agent commerce 방향을 이해하는 자료로 보는 편이 안전하다.
Q6. 개발팀이 지금 바로 할 수 있는 최소 액션은 뭔가?
실결제를 붙이지 말고 먼저 테스트 모드, 낮은 금액 한도, 명확한 context, --output-file, MCP 격리 agent를 기준으로 PoC 설계를 쓴다. 그 다음 로그에 credential이 남는 경로가 있는지 확인한다.